Closed talonchandler closed 1 year ago
It's possible that napari-ome-zarr
throws KeyError: 'Row_0/Col_0/0/0/.zarray'
because it expects a newer version of OME-NGFF format. Taking a look at its source, it does not use the fmt: Format = FormatV04
option of ome-zarr.reader.Reader
:
https://github.com/ome/napari-ome-zarr/blob/1d423d21a76b6cda8f5feb2b7292ace96df708ae/napari_ome_zarr/_reader.py#L33-L35
Possibly introduced in: 0.2.0 | 2021-03-29 | Change chunk dimension separator to "/"
Taking a look at its source, it does not use the
fmt: Format = FormatV04
option ofome-zarr.reader.Reader
First line of the traceback indicates the problem:
18:06:35 WARNING version mismatch: detected: FormatV01, requested: FormatV04
While ome-zarr-py
should be capable of reading data in earlier OME-NGFF versions, napari-ome-zarr
does not utilize this feature.
Now implemented as https://github.com/czbiohub/iohub/pull/31.
We can keep this issue until iohub is released and used by recOrder, and waveorder.io
can be removed from waveorder
v1.0.0.
iohub
has been released, so this is fixed. Closing.
I first noticed this issue during a
recOrder
session when I tried to drag and drop a zarr store saved by a recOrder acquisition into napari. The layers and shape populated correctly, but the actual pixel values were set to zero.Digging further, I've realized that this is a
WaveorderWriter
issue. Here's a minimal example:results in this traceback:
It seems related to our naming convention of
Row_0/Col_0/Pos_000
. Do we need to change this convention, or change the metadata so thatome-zarr
can read our zarrs?I think this is reasonably important because there are lots of cases when I'd like to use the
ome-zarr
reader to split zarr's channels into layers (it's native behaviour) instead of therecOrder-napari
reader that opens as a single array (also convenient in some cases). It also causes confusion because the reader seems to work but has zeros---did the reconstruction get saved? (It does)