Zarr files are being written with a non-standard order.

[odinsbane]

This might be related to #44 When I write a multichannel volume stack there is an inconsistency. If I write the RandomAccessInterval with the shape [x, y, c, z] then the resulting .zarr file has the channel and z axes swapped. They're labelled correctly, but when shown in the ome_zarr validator the channel is shown as volume.

If however I swap the axis so that it is [x, y, z, c] the zarr file gets written correctly. But the N5IJUtils loads the zarr with the channels and slices ordered incorrectly for the ImagePlus.

xyzc-test-zarr.tar.gz

This is a sample zarr file that demonstrates the issue. The values of the slice pixels should be consecutive if the stack is ordered correctly.

The code is simple, but pretty large because of metadata writing and extracting hackery.

This saves an image plus and retains the metadata.
SaveImageToZarr

This loads the zarr file and gets the metadata.
LoadZarr

This is a set of tests to confirm the loading/metadata are correct.
IOTest

[bogovicj]

Work in progress here:
https://github.com/saalfeldlab/n5-ij/compare/ngff-export-axis-order