RFC-9: Review 2#

Review authors#

Kola Babalola, Matthew Hartley, the BioImage Archive, EMBL-EBI.

Conflicts of interest#

None.

Summary#

This RFC represents highly valuable work, and we are in favour of adoption. The proposal would solve many real world problems for our work with OME-NGFF. We already strongly recommend submitters to the BioImage Archive to zip OME-Zarr files, as this simplifies the process of transferring them into the archive and reduces errors associated with transferring numerous files. The recommendations associated with creating the single file and the introduction of the ozx extension are particularly useful.

Significant comments and questions#

Versions of OME Zarr#

The RFC only applies to OME-Zarrs with metadata in zarr.json (not .zattr / .zarray) which implies at least OME Zarr v0.5. Is it worth explicitly mentioning this in the RFC? This might make sense in the ‘Compatibility’ section.

Recommendations on maximum archive size#

The RFC in places alludes to the size of OME Zarrs and explicitly mentions 4GiB in the recommendation to use ZIP64 in the Proposal section. In the User experience-related challenges subsection of the Background section “a few small images” is mentioned. Additionally, the recommendations prohibit multi-volume archives.

However, no explicit guidance is given on size limitations associated with the single file format. Presumably the upper limit of size of a single file on filesystems is a hard limit, but there are practical limitations to the storage and transfer of extremely large files below the filesystem-imposed limit. Since the RFC explicitly prohibits multi-part archives, it would be useful to include a brief discussion of the limitations this imposes, and guidance for users with OME-Zarrs above this size.

Minor comments and questions#

  1. The specification section has the line “Amend the specification with the following section:” Is this a reference to the section that immediately follows?

  2. The example json for the ome attribute in the zip archive has an extraneous comma on the line "jsonFirst": true

  3. The phrase: “These disadvantages were considered to be outweighed by other aspects (see Proposal section).” looks like it should be unindented so it applies to the whole “Drawbacks” section

  4. Is the limitation (imposed by enforcing single-file archival) of the total size of an OME-Zarr image that can be represented as a single file this way a Drawback?

  5. Compatibility: Is it fully compatible with zarr < 0.5?

  6. Is the example dataset at https://static.webknossos.org/misc/6001240.ozx supposed to be accessible by viewers? I can download, but I cannot access with bioNGFF using https://biongff.github.io/biongff-viewer/?source=https://static.webknossos.org/misc/6001240.ozx. I get: Access to fetch at ‘https://static.webknossos.org/misc/6001240.ozx/zarr.json’ from origin ‘https://biongff.github.io’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

  7. Neuroglancer link does not seem to work (on 26/01/2026 @ 16:04GMT) Changing the url to be served from EBI S3 Embassy with acl to public and CORS to allow all origins works.

  8. Tutorials and Examples -> I see an example dataset and a Neuroglancer link (see above comments). A short worked example of how to write/construct .ozx would be valuable. The comment at ome/ngff#316 contains useful information, perhaps this could be turned into a gist and linked from the RFC?

Recommendation#

Minor changes