Update to handle input with less than 5 dimensions#144
Update to handle input with less than 5 dimensions#144sbesson merged 3 commits intoglencoesoftware:masterfrom
Conversation
sbesson
left a comment
There was a problem hiding this comment.
Tested using the representative samples generated as part of the review of glencoesoftware/bioformats2raw#279 both with and without the --compact option as the input data.
The images were imported into OMERO Plus and compared visually with the source Zarr datasets
Functionally everything worked as expected.
On the code changes, consolidating the logic makes sense. Since PyramidSeries represents the multiscales Zarr group while ResolutionDescriptor represents individual resolution Zarr arrays, I agree that thes axes metadata feels like it would belong in PyramidSeries for consistency with the current specification. Would it make sense for ResolutionDescriptor to include a reference to the PyramidSeries so that it could retrieve the axes via getPyramidSeries().getAxes()?
Regarding tests, do we want to work towards a release candidate or a full release of bioformats2raw with the --compact functionality that can be consumed here?
Moved in 6b706a5. I don't think it's necessary at this point for
Definitely. As discussed a bit ago, https://github.com/glencoesoftware/bioformats2raw/milestone/2 is nearly complete so we should be able to release a 0.11.0 soon. |
sbesson
left a comment
There was a problem hiding this comment.
Retested the conversion of Zarr datasets generated from public samples using glencoesoftware/bioformats2raw#279 including:
- the
NIRHTa+001386 wells plate from https://bbbc.broadinstitute.org/BBBC017 - see also https://downloads.openmicroscopy.org/images/Cellomics/BBBC017/ - the
Leica-1.scnbrightfield whole slide image from https://openslide.cs.cmu.edu/download/openslide-testdata/Leica/ - the
LuCa-7color_Scan1.qptifffluorescent whole slide image from https://downloads.openmicroscopy.org/images/Vectra-QPTIFF/perkinelmer/PKI_scans/
For all samples, the conversion times are consistent with the timing of the latest release of raw2ometiff
| raw2ometiff 0.7.1 | raw2ometiff 0.8.0-SNAPSHOT | |
|---|---|---|
| NIRHTa+001_XYC.zarr | fail | 17m30.925s |
| NIRHTa+001_XYZCT.zarr | 19m26.335s | 17m44.705s |
| LuCa-7color_Scan1_XYC.zarr | fail | 0m41.634s |
| LuCa-7color_Scan1_XYZCT.zarr | 0m40.326s | 0m39.979s |
| Leica-1_XYC.zarr | fail | 1m4.214s |
| Leica-1_XYCZT.zarr | 0m42.737s | 0m53.366s |
Confirmed the binary equivalence of the different OME-TIFF files for the same source sample using Bio-Formats test-equivalent functionality.
Happy to either merge this and have unit tests added as a follow-up when we have a (pre)release of bioformats2raw with the --compact option or wait for the latter to happen here before merging.
With bioformats2raw 0.11.0 just released, e5869f2 adds a few tests. |
See glencoesoftware/bioformats2raw#279.
Tested with the output of
bioformats2raw --compacton a few fake datasets that result in 2, 3, or 4 dimensions.Definitely want to add tests that cover this case, but likely need a release of bioformats2raw that includes glencoesoftware/bioformats2raw#279 in order to do so.
Note this moves some of the dimension mismatch checking - I think that still checks everything it needs to, it just seemed nicer to consolidate into
PyramidSeriesrather than duplicating logic.Arguably the axes metadata and mapping to 5D could be done in
PyramidSeriesinstead ofResolutionDescriptoras well, since there is only oneaxesdefinition permultiscales(not one per resolution). I chose to put this inResolutionDescriptorbecause each resolution is a distinct Zarr array, and this would make it easier to update if the specification is ever changed to allow a separateaxesdefinition per resolution (e.g. ome/ngff#102, ome/ngff#200).