ome-zarr-py icon indicating copy to clipboard operation
ome-zarr-py copied to clipboard

rgb_to_5d image code does not follow the spec

Open ktsitsi opened this issue 1 year ago • 1 comments

Hi all! According to the specification as a comment here the resulted array should be of shape (t, c, z, y, x). Instead with pixel.shape == 3 and channels = [np.array([pixels[:, :, c]]) for c in range(size_c)] when most likely the input ndarray has a shape (x, y, c) wouldn't it make sense to swapaxes like the following? In my test scenario the two output images are not the same of course.

....
elif len(pixels.shape) == 3:
        size_c = pixels.shape[2]
        channels = [np.array([pixels[:, :, c].swapaxes(0, 1)]) for c in range(size_c)]
.....

ktsitsi avatar Oct 10 '22 12:10 ktsitsi

It seems that rgb_to_5d() when len(pixels.shape) == 3 is only used when writing version 0.1 or 0.2, e.g. doing something like:

from ome_zarr.data import create_zarr, astronaut
from ome_zarr.format import FormatV01
create_zarr("astro_v01", astronaut,  fmt=FormatV01())

In that case, the data is provided by https://github.com/ome/ome-zarr-py/blob/13165f410c209cc4e50e81b9ac0ce850c367a9b5/ome_zarr/data.py#L38 and the shape is (c, y, x) - which is completely not expected. size_c is 1024 and this results in 5D shape of (1, 1024, 1, 3, 1024)!

So this is not really tested or used much.

I can fix the example above to expect (c, y, x) with:

    elif len(pixels.shape) == 3:
        size_c = pixels.shape[0]
        channels = [np.array([pixels[c, :, :]]) for c in range(size_c)]

I think the astronaut method https://scikit-image.org/docs/stable/api/skimage.data.html#skimage.data.astronaut gives (y, x, c) so that could also be expected, but probably not x, y, c?

What's your use-case for this?

will-moore avatar Oct 12 '22 11:10 will-moore