Fix BigEndian in OME/METADATA.ome.xml#317
Conversation
Default zarr-java behavior is to write little-endian data, so `OME/METADATA.ome.xml` should match this behavior.
sbesson
left a comment
There was a problem hiding this comment.
Given little-endianness is the default behavior of zarr-java, I agree updating the METADATA.ome.xml to match this for all pixels makes sense and will help with downstream tools that are using both the Zarr metadata and the OME-XML metadata like raw2ometiff.
In addition to the code updates, could we add a simple unit test (both in v2 and v3) that reads and tests this metadata value? Also, should the README be amended to document this storage decision?
sbesson
left a comment
There was a problem hiding this comment.
Tested in the context of the sample data that motivated glencoesoftware/raw2ometiff#151. The source files were converted to Zarr v2 and v3 using this PR
For --ngff-version 0.4
omero@ngff:/mnt/data/seb/raw2ometiff_151$ xmllint failing_dataset_0.12.0-SNAPSHOT_v2.zarr/OME/METADATA.ome.xml -format | grep Endian
<Pixels BigEndian="false" DimensionOrder="XYZCT" ID="Pixels:0" Interleaved="false" PhysicalSizeX="0.3425" PhysicalSizeXUnit="µm" PhysicalSizeY="0.3425" PhysicalSizeYUnit="µm" SignificantBits="8" SizeC="5" SizeT="1" SizeX="93986" SizeY="55958" SizeZ="1" Type="uint8">
<Pixels BigEndian="false" DimensionOrder="XYZCT" ID="Pixels:1" Interleaved="true" PhysicalSizeX="0.3425" PhysicalSizeXUnit="µm" PhysicalSizeY="0.3425" PhysicalSizeYUnit="µm" SignificantBits="8" SizeC="3" SizeT="1" SizeX="492" SizeY="668" SizeZ="1" Type="uint8">
<Pixels BigEndian="false" DimensionOrder="XYZCT" ID="Pixels:2" Interleaved="true" PhysicalSizeX="0.3425" PhysicalSizeXUnit="µm" PhysicalSizeY="0.3425" PhysicalSizeYUnit="µm" SignificantBits="16" SizeC="3" SizeT="1" SizeX="1535" SizeY="691" SizeZ="1" Type="uint16">
omero@ngff:/mnt/data/seb/raw2ometiff_151$ grep dtype failing_dataset_0.12.0-SNAPSHOT_v2.zarr/*/0/.zarray
failing_dataset_0.12.0-SNAPSHOT_v2.zarr/0/0/.zarray: "dtype" : "|u1",
failing_dataset_0.12.0-SNAPSHOT_v2.zarr/1/0/.zarray: "dtype" : "|u1",
failing_dataset_0.12.0-SNAPSHOT_v2.zarr/2/0/.zarray: "dtype" : "<u2",
For --ngff-version 0.5
omero@ngff:/mnt/data/seb/raw2ometiff_151$ xmllint failing_dataset_0.12.0-SNAPSHOT_v3.zarr/OME/METADATA.ome.xml -format | grep Endian
<Pixels BigEndian="false" DimensionOrder="XYZCT" ID="Pixels:0" Interleaved="false" PhysicalSizeX="0.3425" PhysicalSizeXUnit="µm" PhysicalSizeY="0.3425" PhysicalSizeYUnit="µm" SignificantBits="8" SizeC="5" SizeT="1" SizeX="93986" SizeY="55958" SizeZ="1" Type="uint8">
<Pixels BigEndian="false" DimensionOrder="XYZCT" ID="Pixels:1" Interleaved="true" PhysicalSizeX="0.3425" PhysicalSizeXUnit="µm" PhysicalSizeY="0.3425" PhysicalSizeYUnit="µm" SignificantBits="8" SizeC="3" SizeT="1" SizeX="492" SizeY="668" SizeZ="1" Type="uint8">
<Pixels BigEndian="false" DimensionOrder="XYZCT" ID="Pixels:2" Interleaved="true" PhysicalSizeX="0.3425" PhysicalSizeXUnit="µm" PhysicalSizeY="0.3425" PhysicalSizeYUnit="µm" SignificantBits="16" SizeC="3" SizeT="1" SizeX="1535" SizeY="691" SizeZ="1" Type="uint16">
omero@ngff:/mnt/data/seb/raw2ometiff_151$ grep endian failing_dataset_0.12.0-SNAPSHOT_v3.zarr/*/0/zarr.json
failing_dataset_0.12.0-SNAPSHOT_v3.zarr/0/0/zarr.json: "endian" : "little"
failing_dataset_0.12.0-SNAPSHOT_v3.zarr/0/0/zarr.json: "endian" : "little"
failing_dataset_0.12.0-SNAPSHOT_v3.zarr/1/0/zarr.json: "endian" : "little"
failing_dataset_0.12.0-SNAPSHOT_v3.zarr/1/0/zarr.json: "endian" : "little"
failing_dataset_0.12.0-SNAPSHOT_v3.zarr/2/0/zarr.json: "endian" : "little"
failing_dataset_0.12.0-SNAPSHOT_v3.zarr/2/0/zarr.json: "endian" : "little"
The endianness in the OME metadata is consistent with the Zarr storage decision which is captured and documented via the newly added unit tests and the README updates.
erindiel
left a comment
There was a problem hiding this comment.
Approving based on the functional testing documented here. 🫶
Default zarr-java behavior is to write little-endian data, so
OME/METADATA.ome.xmlshould match this behavior.