Plugin opens image, but does not display data (everything is 0); SOLVED: must use "/" dimension separator.
GFleishman opened this issue · 3 comments
Hello OME team,
Thank you so much for all your open source efforts, I'm really interested in using the ome-ngff-zarr format, especially if it becomes more widely used by an array of third party tools such as napari.
I've generated an ome-ngff-zarr file, which I can drag and drop into napari, I select this plugin to open it, and the file does open with no complaints. What I see is an image layer with the correct dimensions, but all voxels are 0 valued. If I read the datasets from this ome-ngff-zarr file as numpy arrays and write them as tiff files, those open just fine in napari, so the voxel data in the file is fine. So something about the file metadata is not correct, or not being processed correctly by napari-ome-zarr.
The file is 1 channel, 512 voxels along each spatial axis, and there are 5 scale levels. Here is the zarr.tree() representation:
Here are the contents of the top level .zattrs file. Can you tell me if anything in this looks suspicious or incorrect?
{
"multiscales": [
{
"@type": "ngff:Image",
"axes": [
{
"name": "c",
"type": "channel",
"unit": null
},
{
"name": "z",
"type": "space",
"unit": "micrometer"
},
{
"name": "y",
"type": "space",
"unit": "micrometer"
},
{
"name": "x",
"type": "space",
"unit": "micrometer"
}
],
"coordinateTransformations": [],
"datasets": [
{
"coordinateTransformations": [
{
"scale": [
1.0,
2.0,
1.0,
1.0
],
"type": "scale"
},
{
"translation": [
1.0,
0.0,
0.0,
0.0
],
"type": "translation"
}
],
"path": "scale0/image"
},
{
"coordinateTransformations": [
{
"scale": [
1.0,
4.0,
2.0,
2.0
],
"type": "scale"
},
{
"translation": [
1.0,
1.0,
0.5,
0.5
],
"type": "translation"
}
],
"path": "scale1/image"
},
{
"coordinateTransformations": [
{
"scale": [
1.0,
8.0,
4.0,
4.0
],
"type": "scale"
},
{
"translation": [
1.0,
3.0,
1.5,
1.5
],
"type": "translation"
}
],
"path": "scale2/image"
},
{
"coordinateTransformations": [
{
"scale": [
1.0,
16.0,
8.0,
8.0
],
"type": "scale"
},
{
"translation": [
1.0,
7.0,
3.5,
3.5
],
"type": "translation"
}
],
"path": "scale3/image"
},
{
"coordinateTransformations": [
{
"scale": [
1.0,
32.0,
16.0,
16.0
],
"type": "scale"
},
{
"translation": [
1.0,
15.0,
7.5,
7.5
],
"type": "translation"
}
],
"path": "scale4/image"
}
],
"name": "image",
"version": "0.4"
}
]
}
I do have an ome-ngff-zarr file that does open properly with napari-ome-zarr, an example my colleague downloaded from the IDR, I think the sample number is: 6001240. Internally it is formatted quite differently from the file I generated, but AFAIK they both conform to the ome-ngff spec. I compared the various metadata files and internal format structure of the two files and experimented with various changes, but nothing I did to make the two files more consistent enabled napari-ome-ngff to correctly present the data in my file.
SOLVED!
The ome-ngff-zarr I created used the default "." separator. When switching to "/" the image now opens and displays as expected with napari-ome-zarr.
@joshmoore Not sure if it's intentional to only support the nested format, or if that's the only thing officially allowed in ome-ngff-zarr(?), but in case anyone was wondering, using the non-nested format ("." separator) this is the behavior you get with no warning or error of any kind from the plugin. I may not be the only person behind the times using the "." separator, so maybe a check for this and a message back to the user if they have the wrong separator?
I haven't read the ome-ngff-zarr spec, I'm hoping to just be a user more or less, so maybe this is already stated somewhere - but if not - it's probably important to say somewhere upfront that the "/" separator is needed if napari-ome-zarr is your end point. For some zarr files it might be a lot of work to reformat them with a different separator if someone did it wrong the first time. (Luckily I haven't!)
Closing