RFC-9: Comment 6#
Conflicts of interest (optional)#
None
Summary#
I strongly support standardizing single-file OME-Zarr via ZIP. This comment focuses on the browser-side random-access reader experience, where the RFC’s recommendations on disabled ZIP compression and root alignment have the largest impact.
I have built a browser-based, client-side viewer (Interactive-Zarr-Explorer), forked from the Allen Institute’s Vol-E, that opens local single-file OME-Zarr (.zip) and reads chunks lazily, per chunk, directly from the archive in TypeScript (a custom zarrita store on top of zip.js). The key recommendations in the RFC turn out to matter most precisely on this random-access read path.
Significant comments and questions#
Disabled ZIP compression is critical for random-access readers, not just an optimization#
After indexing the ZIP central directory once and resolving each entry’s data offset from its local file header, each chunk read for a STORE mode entry is a single stateless Blob.slice() of the entry’s stored bytes, with no zip.js reader lock, no CRC pass, and no decode step. This is the critical performance property: Blob.slice calls do not serialize, so concurrent chunk requests from the loader actually run in parallel. As soon as entries are DEFLATE compressed, the store must fall back to entry.getData via zip.js, which both wastes work since Zarr chunks are already codec compressed and serializes reads behind a shared reader lock.
From a reader’s standpoint, the “disabled compression” recommendation is therefore close to a usability requirement for browser side random access rather than a minor tuning knob, and I would support stating it more strongly. The ZipStore in the linked repository implements this path.
Requiring root alignment lets readers drop root detection entirely#
The requirement that the OME Zarr root level zarr.json MUST reside at the ZIP archive root rather than in a subfolder is valuable for readers, as it allows direct access to the metadata without any need to scan the archive structure.
My implementation currently keeps an auto-detection step (detectZarrRootPrefix) that scans all entry filenames for the shallowest occurrence of zarr.json, .zgroup, .zattrs, or .zarray. This step exists purely because non-conforming archives appear in practice: my own data is produced by ilastik (OME-Zarr 0.4 / Zarr v2) and, when zipped as-is, ends up nested under the .ome.zarr folder name. Making root alignment a hard requirement in the RFC would allow readers to drop this detection step entirely.
The jsonFirst zip-comment flag is a well-scoped primitive; a reader fallback should be specified#
Metadata-first (breadth-first) entry ordering is valuable on the read path: a random-access reader can set up the scene from a few leading entries without touching chunk data. The current draft already covers this well, with the root-level zarr.json recommended as the first entry and the jsonFirst flag in the ZIP comment letting a reader trust that ordering without scanning the full central directory.
ZipStore does not yet implement this optimization — it currently reads the full central directory unconditionally during index construction. The jsonFirst flag would allow a future implementation to short-circuit that scan once all metadata entries have been seen, avoiding traversal of potentially thousands of chunk entries. From an implementer’s standpoint this is the right design primitive. One small clarification I would welcome is an explicit statement of what a reader may assume when jsonFirst is absent or false, presumably a fall back to a full central-directory scan.
Minor comments and questions#
Upstream v2 tooling raises a repackaging cost for .ozx adoption#
.ozx is defined around Zarr v3 (zarr.json), but a significant share of upstream tools still emit OME-Zarr 0.4 / Zarr v2 (.zgroup/.zattrs). Consuming such data as a conforming .ozx requires a v2-to-v3 and flatten-root repackaging step. This is not an issue with the RFC itself, only a note that single-file adoption is partly gated on upstream writers reaching v3. ZipStore keys on whichever metadata file is present (zarr.json, .zgroup, .zattrs, .zarray) and stays version-agnostic, but only the v3 path can produce a conforming .ozx.
Single-file archives usefully carry non-image members#
This viewer reads from the same archive not only the image arrays but also an AnnData tables/measurements group (per-object features keyed by label_id) used for interactive analysis alongside the 3D view. The single-file container is valuable precisely because it bundles tables and labels with the image, and I would welcome the specification keeping the treatment of such non-array members inside a .ozx unambiguous.
Comment authors#
This comment was written by: Assa Diabira, Institut Cochin (IMAG’IC / Cochin Image Database), Université Paris Cité, Paris, France.