The import of volume annotations in Zarr 3 format is not specification compliant

[amotta]

I have tried to generate and upload a hybrid tracing (ZIP file) with a Zarr 3 volume layer. In the process of getting this to work, I have noticed that the import of Zarr 3 volumes from hybrid tracings is not compliant with the Zarr 3 specification.

Let's consider the following file structure:

hybrid.zip
  skeleton.nml
  volume.zip
    1/
      zarr.json
      [chunk-data]

Importantly, WebKnossos assumes

• that period (".") is used as chunk key encoding separator, regardless of zarr.json (see here and here)
• that chunks are Blosc compressed, regardless of the codecs in zarr.json (see here)
• that the dimensions are C,A1,..,An,X,Y,Z, where A1 to An are n "additional dimensions", regardless of the dimension names in zarr.json (see here)

I am not entirely sure about this, but I think that WebKnossos also assumes

• that the buckets are in XYZ Fortran / ZYX C order, regardless of the dimension and codecs in zarr.json
• that the volume ZIP file (volume.zip, in this example) contains at most one zarr.json file.

For hybrid tracings downloaded from WebKnossos, the ZIP file looks as follows:

hybrid.zip
  skeleton.nml
  volume.zip
    volumeAnnotationData/
      1/
        zarr.json
        [chunk-data]

First, I interpreted this as a OME-Zarr 3 dataset, which led me to also add a volumeAnnotationData/zarr.json with a node_type of "group". This, however, breaks the import because WebKnossos assumes the "first" zarr.json file to have a node_type of "array".

It would be ideal if the import into WebKnossos were compliant with the Zarr 3 specification. Alternatively, it would be helpful it the assumptions of WebKnossos were documented.

[fm3]

I think you are correct on all points. When we implemented this, we did not expect users to craft their own volume annotation zips manually. This should at least be documented. We’ll discuss internally which approach we’ll take.