IDR / idr-metadata

Curated metadata for all studies published in the Image Data Resource
https://idr.openmicroscopy.org
14 stars 24 forks source link

idr0008 - 2 plates missing channel-4.TIFFs #700

Open will-moore opened 4 months ago

will-moore commented 4 months ago

As reported https://github.com/IDR/idr-metadata/issues/696#issuecomment-2188560610

2024-06-25 10:13:03,452 ERROR [         ome.io.bioformats.BfPixelBuffer] (.Server-11) Failed to instantiate BfPixelsWrapper with /data/OMERO/ManagedRepository/demo_2/2015-09/14/20-06-35.749/005B30_S2R.HTD
2024-06-25 10:13:03,453 ERROR [                ome.io.nio.PixelsService] (.Server-11) Error instantiating pixel buffer: /data/OMERO/ManagedRepository/demo_2/2015-09/14/20-06-35.749/005B30_S2R.HTD
java.lang.RuntimeException: java.io.FileNotFoundException: /data/OMERO/ManagedRepository/demo_2/2015-09/14/20-06-35.749/005B30_S2R_P24_s2_w4.TIF (No such file or directory)
    at ome.io.bioformats.BfPixelBuffer.reader(BfPixelBuffer.java:79)
    at ome.io.bioformats.BfPixelBuffer.setSeries(BfPixelBuffer.java:124)

The file at /data/OMERO/ManagedRepository/demo_2/2015-09/14/20-06-35.749/005B30_S2R_P24_s2_w4.TIF is not found on idr-testing or idr-next or idr itself! Image 38517 gives ResouceError above on idr-testing and idr-next but not on idr.openmicroscopy.org!?

Actually, for those 2 plates (5th and 7th of idr008), there are NO ...w4.TIF images and the 4th channel (DAPI) is black (idr.openmicroscopy.org), whereas for all other idr0008 plates, there are 768 images like ...w4.TIF and DAPI is viewable. Images from these 2 plates are not viewable in idr-testing, possibly due to a change in Bio-Formats?

Seb: likely due to https://github.com/ome/bioformats/pull/3806

JM: https://openmicroscopy.slack.com/archives/C0K5WAD8A/p1719395174513279

dgault commented 4 months ago

Following up on this after investigating further:

Option 1 - The exception is occurring during setID so this is not going to be a solution in this case

Option 2 - This option works as expected, and testing with it as a symlinked image also works. As a bonus it appears that we do not need to create a symlink for every image but instead only the very last one. For example, testing 005B30_S2R I was only required to create a blank plane for 005B30_S2R_P24_s2_w4.TIF. I have a suitably sized blank plane that can be used, it has been copied over to uod/idr/scratch/inbox/idr0008-blankTif

Option 3 - This also works as expected, though it does mean modifying the original file and the metadata (ie the number of channels) would differ from current production IDR

My proposal would be to go for the option 2 approach as the quickest and least intrusive solution. It would mean having just 1 new symlink which makes it Having seen how the exception occurs I could also see the argument for a fix at the reader level to make the reader more lenient. That could be an option for an upcoming patch release.