RFC 7: Channel Metadata (collective scoping)

[lubianat]

Some background:

• RFC-7: where is it? #392

• hi! would you welcome feedback? chanzuckerberg/dynamic-cell-atlas-specs#1 (specimen/sample)
  about https://chanzuckerberg.github.io/dynamic-cell-atlas-specs/v0.2/channel-metadata.html

• GDocs with rough drafts

• Metadata: User stories for named channels #173 (structural)

• EPIC: rendering settings #537 (rendering)

• Metadata for color and contrast limits #23 (rendering)

image.sc:

OME-Zarr: how “transitional” is the omero metadata? (Jan 2026)

How to represent Channel Metadata in OME-Zarr?

what

There are at least 5 kinds of "channel metadata" that could be useful:

• structural (i.e. where the bytes for each channel are located; that is in the OME-Zarr spec)
• acquisition (e.g. mostly the “Channel” part of the OME Model, indirectly via bioformats2raw layout in OME-Zarr)
• rendering metadata (e.g. the channels field of “omero” metadata in OME-Zarr)
• specimen/sample (e.g. DCA's Channel Metadata spec, covering the biological aspects particular to that channel)
• pre-computed metadata (e.g. DCA's Normalization Statistics , which may be used for rendering/processing

how

• to be defined, depending on progress of extensibility proposals and RFC-8

scope

(this section may change)

For a first draft RFC-7 for channel metadata, the goal would be:

• agreeing on a way to represent structural metadata for channels (and perhaps discrete axis in general)
• agreeing on a design that would allow future extensions with rendering/specimen/acquisition/pre-computed metadata for channels
• re-locating omero.channels metadata to a dedicated, core part of the NGFF spec

Why?

• structural is needed for user stories (named channel; channels by reference vs by index)
• rendering is broad and complex (multiple agreement points, multiple proposals)
• specimen/bio is broad and complex (multiple agreement-building points)
• precomputed is similarly broad
• acquisition is a large epic (e.g. Quarep LiMi), too early to go into decisions

[d-v-b]

it might be helpful to separate some concerns.

one big concern is how to model an array where one or more dimensions has indices that only make sense in relation to some other array. For multichannel data, there's often an array dimension that can only be interpreted by consulting another array, e.g. a 1D array of channel names, ["dapi", "gfp", "dsred"], or just ["channel_0", "channel_1", ...].

this structure -- one array requires another dimensionally-aligned array for its interpretation -- is not specific to multichannel data. Image segmentations of overlapping entities also use this structure, as does tiled imaging, etc. it's actually very common. So any solution for this particular aspect of multichannel data should be designed so that it also covers these other uses cases. That means you should not make the "data array relates to a 1D array of labels" relationship specific to multichannel images.

xarray already uses this general data model (where an array can be indexed by values defined in another array), so if you bake it in to ome-zarr you get a big xarray compatibility boost for free.

[jluethi]

Thanks a lot @lubianat for summarising the thinking about this & linking to relevant issues!

I've added our user story over here: #173 (comment)

My main question from it is whether channel identifiers for image processing count as structural information or are its own "what". The only way this is currently in the OME-Zarr spec (that I'm aware of) is the (marked transitional) optional Omero metadata. Getting to a single, non-transitional space for named channels would be great!

For multichannel data, there's often an array dimension that can only be interpreted by consulting another array, e.g. a 1D array of channel names, ["dapi", "gfp", "dsred"], or just ["channel_0", "channel_1", ...].

One of the interesting questions to me is whether the core spec should "just" have a list like this associated to channels or slightly more complex objects similar to the current omero objects. I could see a case made that "just" a list of strings is core and any more complex metadata about those channels is a potential extension that can then refer to the channels by name.

[lubianat]

@d-v-b

this structure -- one array requires another dimensionally-aligned array for its interpretation -- is not specific to multichannel data.

Thanks, I had not thought about that. If you have links, I'd love to read more on how other specs handle it. Do you have a concrete suggestion of how to not make it specific to channels?

and @jluethi

whether channel identifiers for image processing count as structural information

yes! I am broadly thinking as "structural" anything that directly affects storage/retrieval of the bytes (i.e., getting it wrong means messing up viewing/analysis/conversion etc)

[d-v-b]

Thanks, I had not thought about that. If you have links, I'd love to read more on how other specs handle it.

I would look at the relevant section of the CF conventions: https://cfconventions.org/Data/cf-conventions/cf-conventions-1.7/cf-conventions.html#discrete-axis.

Do you have a concrete suggestion of how to not make it specific to channels?

yes, I would formally define how two arrays can be related along one or more co-equal axes. in netcdf / xarray these relationships are implicitly derived from the structure of individual zarr arrays in a zarr group. yall might want something more explicit, but it doesn't need to be super complex, just a rule that defines how the axes of different arrays can be associated. I would also consider allowing inline JSON arrays instead of separate zarr arrays, for simple cases like RGB data. The metadata might look like this:

// inline JSON array
"coordinate_arrays": {
   "channel": { // the key here is the name of the relationship
     "array": ["name", "of", "channels"],
     "dimension_names" : ["channel"] // this would match an element of the image array's dimension_names attribute
  }}

or

// external zarr array (e.g., with string data type)
// at least one element from the dimension_names attribute of that array would match the dimension_names element
// of the image array
"coordinate_arrays": {"channel": {"path": "channels"}} // names an array named "channels" in the same namespace as the bearer of this metadata

I would then define some kind of scheme that clearly instructs visualization applications to treat a channel axis as a channel axis. This can take a variety of forms, but you could also reserve a relationship name "channel"

and application that doesn't care about multichannel visualization can still use this metadata -- it would treat the literal channel names as labels for elements along the channel axis of the image array. an application that does care about multichannel visualization would use the channel names as keys. This way, the "this axis is described by a coordinate array" concern is largely separated from the "this image has import per-channel metadata". They relate via a very small contact patch: the elements of the coordinate array act as a set of keys, which any consumer can use. For must use cases, a single channel identifier should only appear once in the coordinate array, but that constraint should be critically evaluated.

[jburel]

@lubianat I will avoid embedding directly the rendering metadata in the channel metadata spec itself. We may want to revisit #78.
The grouping of channels is also important for images with very large number of channels (in that case a color is assigned to a group of channels). Different levels to consider

[lubianat]

@jburel thanks!

I agree rendering is a huge work packages on its own, and indeed involves many other aspects.

My current thought for avoiding endless dicussions would be just moving omero.channels to a channels field.

So for this RFC, we perhaps avoid new decisions on rendering metadata an just create a home for channel-specific metadata without being under omero?

[d-v-b]

One of the interesting questions to me is whether the core spec should "just" have a list like this associated to channels or slightly more complex objects similar to the current omero objects. I could see a case made that "just" a list of strings is core and any more complex metadata about those channels is a potential extension that can then refer to the channels by name.

I would definitely start here, and see if the core needs anything more than:

• a way to generate a canonical list of channel identifiers
• a way to associate a channel identifier with an element along an axis of an image

then non-core stuff can work with the channel identifiers + the assumption that an implementation knows how to relate a channel identifier to a selection of an array.

something else worth considering: some arrays might pack different channels into the data type of the array, instead of using an extra array dimension. yall could handle this option, or require that channels be done with extra dimensions.