Image Cooperative’s first order of business: helping push the OME-Zarr standard forward
Summary
(The 0th order of business was standing up the business.)
TLDR: Biohub is supporting the development of the OME-Zarr standard through a contract managed by Image Cooperative and supporting many other stakeholders from the OME-Zarr community. Our ambitious goal is to deliver at least an alpha version of OME-Zarr 1.0 in the first quarter of 2027.
Read on for the details!
Announcing our first partnership
We’re pleased to announce that Biohub is supporting the further development of OME-Zarr through a project coordinated by Image Cooperative. Rather than concentrating this work within a single organisation, the funding allows us to distribute effort across a group of initial partners who are already deeply involved in the OME-Zarr ecosystem, including Fideus Labs, scalable minds, German BioImaging, University of Dundee and Glencoe Software.
This is exactly the model Image Cooperative was created to support: shared ownership of both the work and its outcomes, with resources flowing to the people actively building and maintaining the ecosystem. We’re excited to be working together—and with the wider community—to move OME-Zarr forward.
What is OME-Zarr?
For those unfamiliar, Zarr is a file format for storing numeric array data, and corresponding metadata. OME-Zarr is an evolving metadata standard on top of Zarr for storing image data. Together, they solve many of the issues working with image data today, particularly microscopy image data:
- Data often comes in multiple competing proprietary file formats1.
- The most widespread open format, and predecessor to OME-Zarr, OME-TIFF, has complex metadata, resulting in incomplete support across software platforms.
- Large TIFF files are difficult to share in cloud environments, often requiring a complete download to inspect and analyse the data.
- Modern image data can span many gigabytes or even terabytes, making TIFF impractical.
The Zarr file format addresses most of these issues: it is an open file format, and the array data is “chunked”, which means that, to look at a small subset of data, you only need to download a correspondingly small subset of chunks, dramatically improving the experience of working with remote data. It also supports advanced (and customisable) compression algorithms, which helps with data size.
Missing, though, is a description of how to interpret these chunks as (bio-)imaging data. By default, a Zarr file contains just the array data and a little bit of extra information about how to decode and reshape that data into, say, an array of “height” 1080 by “width” 1920 by “depth” 30. There’s nothing there about these elements being pixels, whether one of the dimensions is temporal (as in a sequence of frames), how far those pixels extend in physical space, and certainly not about whether the camera was rotated relative to some scientifically important frame.
This is where OME-Zarr comes in. Zarr has room in its “extra information” file for custom metadata. You could put just about anything in there, but there is power in everyone agreeing on what to call things (like the distance between pixels: that is a “scale” “coordinateTransformation”, in OME-Zarr parlance). Then, scientific software developers can all look in the same place for that information and process the data correctly. OME-Zarr is the standard for how to organise image metadata within the Zarr metadata store.
Those who have followed the development of OME-Zarr will know that progress has sometimes felt slower than the format’s clear utility and growing adoption might suggest. That is not unexpected: standards work is inherently difficult, especially when it is done in the open and aims to incorporate broad community input, as OME-Zarr has. Long timelines are not unusual in this space—the Protein Data Bank (PDB) format, for example, took decades to mature.
At the same time, this process can be frustrating. Good proposals can take years to converge on, sometimes over relatively small points of disagreement. And in a largely volunteer-driven effort, it is not uncommon for valuable ideas to stall simply because there is no time to write them up, refine them, or turn them into working implementations. This is exactly the gap we are trying to help address: turning community energy into maintained momentum, and helping reduce the friction between ideas, agreement, and implementation.
How are we helping?
Our goal is to move the OME-Zarr format forward to version 1.0 by building community capacity. The Biohub contract funds our time to shepherd community discussion through the established specification process. Some of our work will be performing mundane, but important tasks that are difficult to ask of volunteers, such as coordinating reviews on proposals (“RFCs” in OME-Zarr parlance). We will also be working on implementations of the specification, with the aim of extending existing software over creating new software. But before doing so, our first step is to listen. In the coming weeks, we will be meeting with the community to get a better sense of the needs and pains — for contributors to the spec, developers of implementations, and users of the format. This information will help us build a roadmap towards a “version 1.0”. We will do this through attending conferences (e.g., the 2026 OME Community Meeting), sharing surveys, and meeting with folks who have participated in OME-Zarr development thus far. We look forward to chatting with you!
Now you might be wondering, “what is this mythical version 1.0?” With version 1.0, the OME-Zarr community aims to release a version of the specification and implementations that meet all currently-identified critical needs, as documented by current RFCs. While the logistics of long-term support are still being worked out, we want version 1.0 to be complete enough that the community would want to support it long term. To be clear, we don’t intend version 1.0 to be the spec-to-end-all-specs. We know that the format specification is a living document that has to evolve with the needs of the scientific community. However, we also know that lack of support for some of the key features covered by in-flight RFCs is a barrier to adoption for many teams, and we hope that version 1.0 can lower those barriers for a wide range of use cases.
Where do we go from here?
This is our first partnership in this form—hopefully one of many. We see it as a template for how cooperative, distributed development can support shared infrastructure projects like OME-Zarr. We’re excited to learn from this work, to improve it as we go, and to keep building it together with the community.
Want to learn more?
For readers who want to go deeper, the OME community maintains a central NGFF/OME-Zarr hub with specifications, example data, and community resources, including a calendar listing community meetings and office hours — all are welcome to join!