Open Microscopy Environment

Hi All,

In our lab, image acquisition data are partly in custom format so we transform them to OME-tiffs.
Then they become importable via Omero clients and everybody is happy.

However, there is (at least) one case that we don't resolve this way.
When uploading the data from our FLIM Plate Readers, we create programmatically the Plate, and then one needs to populate it by FOV images (loading from OME-tiffs that we know how to create.. as explained), everything is according to Plate metadata etc - that we take care of.

Problem is that this "import" should be done according to Omero 5 convention, - preserving the copy of original OME-tiff file that will be downloadable from Omero clients, therefore providing The Convenient Way of Data Sharing, which is among our Communal Goals (if not Duties ).

So far, the nearest example that possibly does what is needed I found in Balaji's recent code (very convenient as we also use Matlab) here - in "upload_image" function

https://gist.github.com/bramalingam/1d36f827add8f5342068

So our question is if that is doable at all (should be.. ), how far is it from an example above, is there any advise on possible caveats, and if there is closer example, - would be great to have.

Best,
Y.

HI Yuriy,

as far as I can tell there are two bottlenecks:

1- assuming you are generating one OME-TIFF per well, you will need to include metadata including the plate specification. This should be achievable by making the relevant calls from the MetadataStore interface to the OME-XML metadata object. Critical methods will likely be setPlatexxx, setWellxxx and linking the images using the TiffData blocks. Samples can be found here showing examples of metadata for the Screen-Plate-Well model and of multi-file linking.

2- importing the file into OMERO is possible in a couple of languages but not yet for MATLAB. As you said, Balaji's function is a good start and will hopefully get included as part of the toolbox. Additional work is required to make it work out-of-the box though. If you guys are interested in getting this included and are willing to help the development by testing it, we could try to speed up its integration into OMERO.matlab.

Let us know what you think,
Sebastien

Many thanks Sebastien,

Certainly, we are very interested in collaborating on these issues, and also have the data, both example and experimental, - so let us discuss it in due time.

Best,
Y.

...
just one update on our specs, related to what You describe as bottleneck 1 - we usually have more than one FOV per well, this is one of the essential features of these plate readers, as they look for non-empty FOVs during acquisition
moreover, there also might be several modalities for every FOV, for example FLIM + Acceptor image or Brightfield.
we have several examples of such data, they were uploaded to server according to pre Omero5 convention, and WellSample system handled it properly.
certainly our interest is to extend this to Omero5.

Best,
Y.