Preserve OMERO rendering metadata #82
Conversation
|
@sbesson @melissalinkert Is it possible to move the annotation from a key-value pair to xml annotation like below?: |
|
@muhanadz a priori, I think the writing code can use any OME structured annotation that suports storing a string value - see the full list here. So Since this is not a native XML string, from your side, what is the primary benefit of using |
|
Discussed with @sbesson and @muhanadz earlier today. 9938304 now writes the rendering metadata into several different annotations, so that we can evaluate which is best suited to balancing the three main considerations here:
This PR has been switched to draft status to reflect the fact that it should not be merged as-is. The only annotation type I added here that we didn't discuss is to have two The next step is to convert a few files to OME-TIFF using bioformats2raw 0.5.0 and this PR, and then import the OME-TIFFs to OMERO. Test cases should include brightfield, fluorescence with 4-6 or so channels, and multiplex with a large number of channels (60-80?). Once we decide which annotation strategy to use, this PR should also bump to bioformats2raw 0.5.0 and add test cases. |
Nice finding. At least from my side, this is definitely the most elegant solution with regards to respecting all the constraints exposed in #82 (comment). Assuming channel annotation is the preferred solution, my main caveat is that relying exclusively on
|
|
94eea04 now gives just two options:
Definitely going to be important to try this out with larger channel counts and an HCS dataset before making a final decision. |
|
Tested using the representative OME-TIFF plate from BBBC017, both in its original form and converted using The data was imported into OMERO under both format both with the default options and skipping min/max calculation + thumbnail generation steps. The table below summarizes the time spent in the different steps of the import process (as rerported by
A few comments:
All in all, it is very possible there is not an universal workflow that will work with all modalities and we will need to make decisions based on the domain. For instance, it is very likely that preserving the rendering metadata when converting single large floating-point images will be valuable but this might be something that we don't want to do for HCS data simply because some of the costs outweigh the benefits. |
There was a problem hiding this comment.
Tested in the context of 3 imaging modalities:
- HCS: using the representative BBBC017 plate
- fluorescence: using the tubhiswt-4D sample
- EM: using the sample available at https://downloads.openmicroscopy.org/images/OME-TIFF/2016-06/sub-resolutions/EM/.
In all three cases, the original OME-TIFF files was converted using bioformats2raw 0.5.0 (including the min/max statistics) followed by raw2ometiff with this PR included.
Both original and converted OME-TIFF datasets were imported into OMERO and tested with post-import scripts comparing the speed of recomputing the min/max values and regenerating the thumbnails with and without the new channel annotations.
Testing reveals the outcome largely depends on the ratio between the number of images and the volume of pixels data per image. More specifically
- HCS is the most adverse scenario as the annotations per channel represent a significant increase of objects in the database as mentioned above. For typical HCS acquisitions where individual well samples are only multi-channel, the new annotation does not significantly speed up import time and instead increased it by a factor 1.5x-2x
- for all other modalities, the new functionalities is a game changer as it prevents iterating over all the tiles for computing the values either at import time or post-import. The bigger the volume of pixel data / channel, the more advantageous this feature will be
- for the large floating-point example, this feature is particularly valuable if the image is imported in a OMERO.server 5.6.5 with https://omero.readthedocs.io/en/stable/sysadmins/config.html#omero.pixeldata.max_plane_float_override set to
falseas the pixel type dynamic range makes the data almost
It is worth noting that the domain where the annotation is the most disadvantageous is also not the one which drove the development of these conversion utilities. For multi-acquisitions scenarios like HCS, I would argue that large single-file OME-TIFF offer more disadvantages than advantages and I would not recommend using this whole pipeline with the current output.
In summary, I would be inclined to move forward with this new feature but try to be defensive about its scope. One idea would be to disable the channel annotation generation for now when HCS metadata is present in the source NGFF file. I know (and understand) that Melissa is not particularly keen on special-casing so happy to hear other's feedback.
|
I think I'm OK with HCS vs non-HCS being handled separately, since those are already two distinct output formats. We were at one point discussing checking channel counts etc., which is where I'm less comfortable. Is the idea then to write the channel annotations when any of the following are true:
and so omit the channel annotations when any of the following are true:
|
I agree. Anything that would force us to define a hardcoded arbitrary maximum channel limit is worth avoiding.
The second condition makes sense to me but I think this means the channel annotations should be written when:
Interesting, I could definitely imagine some HCS scenarios which could benefit from storing these annotations. Floating-point wells are one example, long timelapse HCS acquisitions such as https://idr.openmicroscopy.org/webclient/?show=well-1351622 (182 timepoints / well sample) could be another. Thoughts about adding an opt-in flag allowing the user to override the omission conditions described above and unconditionally write the channel annotations if |
|
My thinking was |
Just to clarify, are you talking about a new |
…hannel-annotations is used
|
Sorry, ignore me. My whole line of thinking yesterday was around turning off the potentially expensive min/max calculation at the bioformats2raw level. No min/max calculation in bioformats2raw then means the channel annotations can't be written here. 63b5cf4 is one way to do this. If there is plate metadata, there will be no channel annotations by default. If you add the new |
|
This is a tricky one. Nice issue! 😉 Trying to capture my brainstorming from the formats meeting, though it doesn't help with the lack of an API for retrieving min/max values from arbitrary readers, another possible route for injecting this information is to consider everything that doesn't get converted into OME-XML from the intermediate OME-Zarr to be a file annotation in the OME-TIFF. (That leads us to the secondary issue of having file attachments for OME-TIFF, but that's a problem that would be good to solve regardless). |
|
After discussion with @sbesson / @muhanadz / @erindiel / @emilroz / @DavidStirling , closing this in favor of encouraging OME-Zarr usage in cases where min/max data needs to be used. Agreed it would be nice to explore the file annotation concept, but I don't think we're realistically going to be able to work on that any time soon. |
See glencoesoftware/bioformats2raw#160
Discussed with @mgheirat, @muhanadz, and @sbesson that it would be nice to keep any calculated min/max values when converting to OME-TIFF. Since there isn't really a place in the OME schema to do that, this PR uses a
MapAnnotationlinked to eachImage. TheMapAnnotationhas the namespaceglencoesoftware.com/ngff/rendering, and a single key (omero) whose value is the JSON described here: https://ngff.openmicroscopy.org/latest/#omero-md.Namespace, annotation type, etc. all up for debate if anyone has better ideas. Not necessarily expecting this to be merged as-is, it's just a place to start. I thought about using an
XMLAnnotationinstead, like we do for the JSON annotation described here: https://github.com/glencoesoftware/ome-omero-roitool/blob/master/src/main/java/com/glencoesoftware/roitool/OMEOMEROConverter.java#L199.MapAnnotationseemed less likely to break things that might try to parse anXMLAnnotationvalue.It should be possible to convert an input dataset to OME-TIFF with glencoesoftware/bioformats2raw#160 and this PR, and see the linked annotations with
showinf -nopix -noflat -omexmlon the output OME-TIFF. Importing the OME-TIFF to OMERO should allow the annotations to be queried - get theImagefirst, then look for linked annotations with theglencoesoftware.com/ngff/renderingnamespace.No tests (yet) because we'd need a released version of bioformats2raw that generates OMERO metadata.