You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we load the array as is (using tifffile or the matlab loader) and save them in the same order in the zarr.
However, the dimensions in the zarr are named in reverse ([z, y, x]), whereas the data in these input matlab or tiff must often be interpreted as [x, y] or [x, y, z]. Also, in the OCT converter, we stack slices along the last zarr dimension (i.e. "x"), whereas "z" is more natural.
Should we permute the input arrays so that their natural ["x", "y", "z"] axes become ["z", "y", "x"] ?
The text was updated successfully, but these errors were encountered:
Ho you're right! So it seems we do things correctly in our LSM tiff converter, at least.
Is it the same for non-OME tiff? Can we always trust the "axes" metadata in tiffile, even in non-OME tiffs? I guess we should at least check what it contains and keep consistency with them if possible.
The "axes" metadata is only part of the OME specs. But yeah, if the tag is populated, it should be used.
I didn't check, but apparently these standards have other methods to indicate the axis order:
Axes information (e.g., X, Y, Z, time, channels) is not inherently standardized in non-OME TIFFs, but it can be added in custom tags or embedded using existing metadata standards like:
Exif (Exchangeable Image File Format)
XMP (Extensible Metadata Platform)
IPTC (International Press Telecommunications Council)
Currently we load the array as is (using tifffile or the matlab loader) and save them in the same order in the zarr.
However, the dimensions in the zarr are named in reverse ([z, y, x]), whereas the data in these input matlab or tiff must often be interpreted as [x, y] or [x, y, z]. Also, in the OCT converter, we stack slices along the last zarr dimension (i.e. "x"), whereas "z" is more natural.
Should we permute the input arrays so that their natural ["x", "y", "z"] axes become ["z", "y", "x"] ?
The text was updated successfully, but these errors were encountered: