When opening the different resolution series from a BDV xml/hdf5 file, the properties has incorrect image dimensions.

[odinsbane]

trafficstars

If I create an xml/hdf5 dataset then open the dataset with fiji the bio-formats plugin gets used. When there are multiple series for the different resolutions, all of the series have the same pixel dimensions in properties.

To reproduce.

1 open an image stack 2 save the file as bdv dataset.

plugins -> bigdataviewer-> export current image as xml/hdf5

Make sure there are multiple resolutions being exported.

3. Open the resulting .xml with Fiji and check the box for open all series.
4. Select each window, and check the image properties. They all have the same pixel dimensions.

I'm not sure if this is an issue for the bigdataviewer or an issue for bioformats. I can create an example if necessary.

Thank you

[sbesson]

@odinsbane by pixel dimensions, do you refer to the XYZTC dimensions or the physical sizes? A public representative sample would definitely be handy to track down the issue if you can create a minimal one.

[odinsbane]

Here is an image that I converted to xml/h5. When you open it there are two series, they're the same image at different resolutions. When I go to image -> properties it shows the pixel sizes as 0.173 um for both image stacks.

https://www.dropbox.com/sh/ni1cvclnno71v9k/AAAcIhrlR7HOSFpSU-RBKGSCa?dl=0

[sbesson]

Thanks @odinsbane, using the current Bio-Formats, I confirm that the physical sizes are indeed identical when the resolutions are flattened (which is the default ImageJ behavior)

build@8838e5e462e8:/tmp$ /bio-formats-build/bioformats/tools/showinf -nopix -omexml sample-prediction.xml | grep Physical
      <Pixels BigEndian="false" DimensionOrder="XYZTC" ID="Pixels:0" Interleaved="false" PhysicalSizeX="0.173806673793899" PhysicalSizeXUnit="µm" PhysicalSizeY="0.173806673793899" PhysicalSizeYUnit="µm" PhysicalSizeZ="0.17380666226108724" PhysicalSizeZUnit="µm" SignificantBits="16" SizeC="1" SizeT="1" SizeX="447" SizeY="447" SizeZ="479" Type="uint16">
      <Pixels BigEndian="false" DimensionOrder="XYZTC" ID="Pixels:1" Interleaved="false" PhysicalSizeX="0.173806673793899" PhysicalSizeXUnit="µm" PhysicalSizeY="0.173806673793899" PhysicalSizeYUnit="µm" PhysicalSizeZ="0.17380666226108724" PhysicalSizeZUnit="µm" SignificantBits="16" SizeC="1" SizeT="1" SizeX="223" SizeY="223" SizeZ="239" Type="uint16">

When using the sub-resolution API with -noflat, the issue does not apply anymore as the additional images become sub-resolutions:

build@8838e5e462e8:/tmp$ /bio-formats-build/bioformats/tools/showinf -nopix -omexml -noflat sample-prediction.xml | grep Physical
      <Pixels BigEndian="false" DimensionOrder="XYZTC" ID="Pixels:0" Interleaved="false" PhysicalSizeX="0.173806673793899" PhysicalSizeXUnit="µm" PhysicalSizeY="0.173806673793899" PhysicalSizeYUnit="µm" PhysicalSizeZ="0.17380666226108724" PhysicalSizeZUnit="µm" SignificantBits="16" SizeC="1" SizeT="1" SizeX="447" SizeY="447" SizeZ="479" Type="uint16">

I think the issues comes from https://github.com/ome/bioformats/blob/ef26436c2d079f05c1047816e564ffcc63bb0b04/components/formats-bsd/src/loci/formats/in/BDVReader.java#L585-L587

I see two options to fix the incorrect metadata:

• either compute the true physical size using the scaling factor for each series in flattened mode
• or only set the physical size for the first resolution

@dgault @melissalinkert what is the standard expectation for other pyramidal formats?

[melissalinkert]

I don't think we've ever really decided what the correct behavior for physical pixel sizes in flattened sub-resolutions should be. There is at least one other report of a similar issue (https://trello.com/c/INs2Dw2I/147-incorrect-physical-pixel-sizes-with-pyramids), and it wouldn't surprise me if other readers have this same problem.

Computing would be consistent with https://github.com/glencoesoftware/bioformats2raw/pull/134, but I'm not entirely convinced that the readers should be doing that.

[sbesson]

:+1: let's discuss this on MOnday at the weekly @ome/formats meeting

[dgault]

Another report of this issue in https://forum.image.sc/t/bio-formats-xml-hdf5-reader-voxel-dimensions/29645/5. I have added this to the 6.10.1 milestone to make a final decision and update the BDVReader with the chosen solution.

[imagesc-bot]

This issue has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/bio-formats-xml-hdf5-reader-voxel-dimensions/29645/7