4D zarr datasets not loaded correctly in FIJI

[ptbrown1729]

I am using FIJI with ImageJ 1.53q. Looking in the installation direction jars subfolder I find n5-ij-3.2.2.jar and n5-zarr-0.0.7.jar

When I use File -> Import -> N5 to load a 4D zarr dataset, the resulting imagej hyperstack that is produced is not correct. This hyperstack has two sliders, "c" and "z". However, the data from the zarr is not put in the correct place. The data from the "c" and "z" dimensions in the zarr are mixed up in the imagej hyperstack.

A minimal example:
I create a zarr using the following python code

import zarr
import numpy as np

# zarr dimensions
nc = 5
nz = 30
nx = 256
ny = 256

# create zarr
fname = "test.zarr"
data = zarr.open(fname, "w")
data.create_dataset("test", shape=(nc, nz, ny, nx),
                    chunks=(1, nz, ny, nx), dtype='float32', compressor="none")

# zarr values are z-slice coordinates
for ii in range(nc):
    for jj in range(nz):
        data.test[ii, jj] = np.ones((ny, nx)) * jj

Next I open it in FIJI with File -> Import -> N5. Now I expect when I scroll through the "c" channel in the hyperstack that I will not see the value of the image change, since the image value only depends on the z-index. But I do see it change. For example, if I keep the z-index at value 1/30 and scroll the c index I see image values of 0, 1, 2, 3, and 4. If I increment the z-index to 2/30 and scoll c I see 5, 6, 7, 8, and 9.

[bogovicj]

@ptbrown1729

Thanks for reporting, I'll address this. Longer term, I'd like to give users control about axis/dimension order. (see issue #45).

For the time being, you can work around it with a macro:

run("Properties...", "channels=1 slices=30 frames=5 pixel_width=1.0000 pixel_height=1.0000 voxel_depth=1.0000");
run("Re-order Hyperstack ...", "channels=[Frames (t)] slices=[Slices (z)] frames=[Channels (c)]");	

Short explanation + caveat:
Since imageJ's dimensions have meaning (XYCZT) and zarr's don't, the current plugin doesn't promise the dimensions will be ordered "correctly" in imageJ unless using a supported metadata format (and there are not many of them); otherwise it makes a guess. In your case, it actually guessed correctly, but in the process messed up the interleaving of slices - causing the problem you observed. and that is a bug. I.e. correct behavior using this version would be for your image to open with 30 channels and 5 slices, but without the interleaving problem.

Note to self: look here.

[jingxuanlim]

I believe this is what I'm experiencing with my 4D dataset too. Moving either the c and z sliders change both the c and z values.