OMERO client

[jacopoabramo]

OMERO is a server infrastructure to store datasets and enrich them with specific metadata information. Originally OMERO servers supported only the OME-TIFF format, but after visiting ELMI 2023 I learned that they're planning to a more sustainable and easy to stream data model using this OME-NGFF - in which the OME-Zarr will be central.

My idea would be to start integrating a client which can connect to an OMERO server using the Python APIs. Even better, visualizing the current folder structure from the server locally on the GUI would be interesting to add - and I think from the API it's relatively "easy" to access.

The major problem is always the streaming speed, which I don't think will be manageable to do a real-time acquisition AND streaming to server when using high speed acquisitions or very dense datasets.

They mentioned me a possibility to "mirror" the local file storage to the OMERO server you're currently connected but I find this a bit risky.

A preferable alternative would be to make sure you have enough space on disk, do your recording and launch in background a thread which starts streaming the sampled data with whatever bandwidth is available. To reduce the streaming time, some compression algorithms may help but these need to be implemented also on the server side and that's another world on its own.

[beniroquai]

Hey @jacopoabramo I appreciate your effort to mention Omero. First of all, I had a question if the current way of treating tiffs already follows some OME-TIF standards. We recently had some fun importing the data into ASHLAR (https://github.com/labsyspharm/ashlar) with little to no success. I guess having a standardized file format for multidimensional that is compatible with the vast majority of image processing routines would be awesome!

[jacopoabramo]

@beniroquai in #171 I tried implementing an OME-TIFF streaming class to store metadata using the tifffile package. That's as far as I got in manipulating OME-TIFFs (a.k.a. streaming data into a file and adding metadata information afterwards). I do reccomend starting a switch in using this Zarr file format because it seems much more versatile and less of an hassle than TIFFs, and using a chunked approach may provide some benefit in terms of writing speed to disk. I still have to try it myself though.

[beniroquai]

Quick follow-up question then. For Histological data you often have 5D data stacks (e.g. XYCBW, where B and W may be tiles along X/Y). The following code works for ASHLAR, but where should I implement it? In a dedicated manager or even the recorder?

# 5-channel image of size 30x30
imgs = [np.ones((5, 30, 30), dtype=np.uint8)*i for i in range(9)]
positions = np.array([np.unravel_index(i, (3, 3)) for i in range(9)])
# ashlar uses `PhysicalSizeX/Y` for pixel unit conversion
pixel_size = 0.3

with tifffile.TiffWriter('ashlar_generated.ome.tif', bigtiff=True) as tif:
    for img, p in zip(imgs, positions):
        metadata = {
            'Pixels': {
                'PhysicalSizeX': pixel_size,
                'PhysicalSizeXUnit': 'µm',
                'PhysicalSizeY': pixel_size,
                'PhysicalSizeYUnit': 'µm'
            },
            # a mock 10% overlap therefore each step is 27 pixels
            'Plane': {
                'PositionX': [p[1]*pixel_size*27]*img.shape[0],
                'PositionY': [p[0]*pixel_size*27]*img.shape[0]
            }
        }
        tif.write(img, metadata=metadata)

[jacopoabramo]

If you want to stream data using this format then you'll have to implement this into the RecordingManager class. I've been doing a rework of that in #171, since I needed concurrent acquisition from different cameras to work and also wanted a better metadata storage in my TIFF files. The Pixels dictionary is implemented already, what's missing is the Plane dictionary. If you look at the code I basically ready some meatadata from the detector but all the other metadata from the sharedAttribute class are not there. I wouldn't know right now how to integrate this plane dictionary... the sharedAttribute system should probably be adapted to work with OME-TIFF files as well.

But in all honesty if I were you I would probably consider using OME-Zarr directly for your data. That's the direction I'm thinking of going in terms of how to record with ImSwitch in the future.