ome-zarr-py
ome-zarr-py copied to clipboard
rgb_to_5d image code does not follow the spec
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)]
.....
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?