Closed blowekamp closed 1 year ago
This behavior is expected; bioformats2raw does not consider the system's native order, so will produce the same output independent of the system on which it is run.
@blowekamp : is this causing a problem, or is it something we just need to better document?
@melissalinkert Thank you for the response. It is something that certainly can be handled.
What was the reasoning to choosing big-endian over the more common CPU order of little endian?
P.S. Where I ran into the issue was with numpy/dask checking if the dtype was np.uint16 and it was not matching.
The choice to write only big-endian dates to a time when bioformats2raw wrote n5, which only supports big-endian data - see https://github.com/glencoesoftware/bioformats2raw/pull/16/commits/f9bfa0640d8b9a0dde7df367de16851bc4ff1169 and https://github.com/saalfeldlab/n5#file-system-specification. We've left that in place for simplicity, particularly as Java ByteBuffers default to big-endian.
I'll assume that choices were made to follow the "Network Byte Order" of big endian at some point.
The input which are unsigned int 16 are being written and big-endian unsigned int 16 in the zarr arrays when converted with bioformats to raw. I am using version 0.6.1 of bioformats2raw, and this is occurring on both a Mac M1, and a Linux Intel ( both little endian ).
The '>' character in the dtype field indicates the pixel data type is non-native big-endian.
The conversion from a czi file was also to a big-endian unsigned 16 bit in the zarr array too.
The expectation was that the byte order would match the system.