Should we permute axes when converting from tiff/mat?

[balbasty]

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"] ?

[kabilar]

Should we permute the input arrays so that their natural ["x", "y", "z"] axes become ["z", "y", "x"] ?

+1

[chourroutm]

@balbasty why do you assume XYZ for the TIFF files?

Using the tifffile package with OME-TIFF, it seems OME-TIFF forces the ZYX order (it fails when I try to keep the XYZ order):

import tifffile as tiff

# ...

dataset_in_memory = dataset.transpose((2,1,0)).rechunk((512,)*3).compute()
tiff.imwrite(data_path / "{:.2f}um_binned_{}_{}.tif".format(new_resolution_full_um,donor,organ),dataset_in_memory,metadata={'axes': 'ZYX'},ome=True)

[balbasty]

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.

[chourroutm]

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)