From c307c7930db88eb86a956439935a819d0d4e1840 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Wed, 24 Jun 2026 22:45:44 +0200 Subject: [PATCH 01/17] Update 0.4 references to 0.5 --- rfc/3/index.md | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index 0bf741e3..ebda1bc1 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -114,9 +114,9 @@ bioimaging data and metadata to make it findable, accessible, interoperable, and reusable. The [paper describing NGFF and OME-Zarr][nat methods paper] notes that "the diversity of [biological imaging's] applications have prevented the establishment of a community-agreed standardized data format", but, [for -historical reasons][ome-model], [version 0.4 of the OME-Zarr -specification][ngff 0.4] [imposes][ngff 0.4 multiscales metadata] strict -restrictions on the +historical reasons][ome-model], [versions 0.4][ngff 0.4], [0.5][ngff 0.5], and +[0.6 (draft)][ngff 0.6] of the OME-Zarr specification +[impose][ngff 0.5 multiscales metadata] strict restrictions on the applications: > The length of "axes" must be between 2 and 5 and MUST be equal to the @@ -126,7 +126,7 @@ applications: > entry of "type:channel" or a null / custom type. The order of the entries MUST > correspond to the order of dimensions of the zarr arrays. In addition, the > entries MUST be ordered by "type" where the "time" axis must come first (if -> present), followed by the "channel" or custom axis (if present) and the axes +> present), followed by the "channel" or custom axis (if present) and the axes > of type "space". If there are three spatial axes where two correspond to the > image plane ("yx") and images are stacked along the other (anisotropic) axis > ("z"), the spatial axes SHOULD be ordered as "zyx". @@ -303,8 +303,10 @@ This RFC is placed in the public domain. [nat methods paper]: https://www.nature.com/articles/s41592-021-01326-w [ome-model]: https://github.com/ome/ngff/pull/239/files#r1609781780 -[ngff 0.4]: https://ngff.openmicroscopy.org/0.4/index.html -[ngff 0.4 multiscales metadata]: https://ngff.openmicroscopy.org/0.4/index.html#multiscale-md +[ngff 0.4]: https://ngff.openmicroscopy.org/specifications/0.4/index.html +[ngff_0 5]: https://ngff.openmicroscopy.org/specifications/0.5/index.html +[ngff_0 6]: https://web.archive.org/web/20260520043202/https://ngff.openmicroscopy.org/specifications/dev/index.html +[ngff 0.5 multiscales metadata]: https://ngff.openmicroscopy.org/specifications/0.5/index.html#multiscales-metadata [ngff 0.4 axes metadata]: https://ngff.openmicroscopy.org/0.4/index.html#axes-md [czi format dimensions]: https://web.archive.org/web/20240521085825/https://zeiss.github.io/libczi/imagedocumentconcept.html#autotoc_md7 [spec update]: https://github.com/ome/ngff/pull/235 From 812a8b75eb40fd41db553eb61f4b6de94af7b880 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Wed, 24 Jun 2026 22:59:05 +0200 Subject: [PATCH 02/17] Note RFC-5/current developments don't change things --- rfc/3/index.md | 30 ++++++++++++++++++++++++++---- 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index ebda1bc1..a73e954f 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -114,10 +114,9 @@ bioimaging data and metadata to make it findable, accessible, interoperable, and reusable. The [paper describing NGFF and OME-Zarr][nat methods paper] notes that "the diversity of [biological imaging's] applications have prevented the establishment of a community-agreed standardized data format", but, [for -historical reasons][ome-model], [versions 0.4][ngff 0.4], [0.5][ngff 0.5], and -[0.6 (draft)][ngff 0.6] of the OME-Zarr specification -[impose][ngff 0.5 multiscales metadata] strict restrictions on the -applications: +historical reasons][ome-model], [versions 0.4][ngff 0.4] and [0.5][ngff 0.5] +of the OME-Zarr specification [impose][ngff 0.5 multiscales metadata] strict +restrictions on the applications: > The length of "axes" must be between 2 and 5 and MUST be equal to the > dimensionality of the zarr arrays storing the image data (see @@ -136,6 +135,29 @@ And: > Each "datasets" dictionary MUST have the same number of dimensions and MUST > NOT have more than 5 dimensions. +The currently-in-development [v0.6 specification][ngff 0.6], which incorporates +RFC-5, maintains these limitations: + +> - The length of `axes` must be between 2 and 5 and MUST be equal to the +> dimensionality of the Zarr arrays storing the image data (see +> `datasets:path`). +> +> - `axes` MUST contain 2 or 3 entries of `type:space` +> +> - `axes` MAY contain one additional entry of `type:time` +> +> - `axes` MAY contain one additional entry of `type:channel` or a null / +> custom type. +> +> - axes entries MUST be ordered by type where the time axis must come first +> (if present), followed by the channel or custom axis (if present) and the +> axes of type space. +> +> - If there are three spatial axes where two correspond to the image plane +> (yx) and images are stacked along the other (anisotropic) axis (z), the +> spatial axes SHOULD be ordered as zyx. + + These restrictions prevent users from converting existing datasets to OME-Zarr. For example, Zeiss .czi datasets [may contain][czi format dimensions] dimensions such as H, I, and V to store different phases, From 7401e11b06ef0a0c27d70644413377edf99bdba8 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Thu, 25 Jun 2026 00:13:56 +0200 Subject: [PATCH 03/17] Improve mentions of 'normal' microscopy datasets and add FLIM --- rfc/3/index.md | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index a73e954f..2f825006 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -149,30 +149,37 @@ RFC-5, maintains these limitations: > - `axes` MAY contain one additional entry of `type:channel` or a null / > custom type. > -> - axes entries MUST be ordered by type where the time axis must come first -> (if present), followed by the channel or custom axis (if present) and the -> axes of type space. +> - `axes` entries MUST be ordered by `type` where the `time` axis must come +> first (if present), followed by the `channel` or custom axis (if present) +> and the axes of type `space`. > > - If there are three spatial axes where two correspond to the image plane -> (yx) and images are stacked along the other (anisotropic) axis (z), the -> spatial axes SHOULD be ordered as zyx. +> (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the +> spatial axes SHOULD be ordered as `zyx`. These restrictions prevent users from converting existing datasets to OME-Zarr. For example, Zeiss .czi datasets [may contain][czi format dimensions] dimensions such as H, I, and V to store different phases, -illumination directions, or views respectively. To say nothing of synthetic data -that may contain "artificial" dimensions such as principal components or axes of -other dimensionality reduction-techniques from many images. They may also hamper -the adoption of OME-Zarr as an acquisition-time format due to performance concerns -when data must be manipulated to accommodate a strict dimension order. +illumination directions, or views respectively. They also hamper +the adoption of OME-Zarr as an acquisition-time format due to performance +concerns: many acquisitions happen in TZCYX order (all channels are acquired +together for each z-slice), which violates the "axes must be ordered by type" +requirement. In such cases, scientists must first acquire their data and *then* +transpose it — an expensive proposition for large datasets. ## Motivation -In addition to the .czi datasets mentioned in the preceding paragraph, this -section describes six dataset types that are currently impossible to represent -in OME-Zarr: +In addition to the .czi datasets mentioned in the preceding paragraph, and +alternate axis orderings driven by acquisition concerns, this section describes +real datasets that are currently impossible to represent in OME-Zarr: +- in [Fluorescence Lifetime Imaging Microscopy (FLIM)][flim], there is an + additional time dimension containing the fluorophore decay over a much + shorter time scale (nanoseconds) than the typical spacing between time + points. This constitutes an additional time axis called `u` or `µ` and + can result in a 6-dimensional dataset with axes `CTUZYX`. (See, for example, + [this paper][flim-paper].) - in [electron backscatter diffraction (EBSD)][ebsd], a microscopy technique common in materials science, a beam of electrons is scanned over a surface, and for each (2D) position in the scan, a full 2D diffraction pattern is @@ -180,7 +187,7 @@ in OME-Zarr: - from the diffraction patterns, it is possible to obtain an *orientation map*, containing a 3D angle at each 2D position of the material. - the same principles apply to [diffusion tensor imaging][dti], where a - three-dimensional diffusion tensor is measured at each voxel. + three-dimensional diffusion tensor is measured at each voxel position. - it is common to compute Fourier transforms of 3D images. The datasets have three dimensions but they are measured in *frequency*, not space. - when computing segmentations, one may use finer or coarser priors, resulting @@ -337,6 +344,8 @@ This RFC is placed in the public domain. [trafo spec]: https://github.com/ome/ngff/pull/138 [space dims comment]: https://github.com/ome/ngff/pull/138#issuecomment-1852891720 [ebsd]: https://en.wikipedia.org/wiki/Electron_backscatter_diffraction +[flim]: https://en.wikipedia.org/wiki/Fluorescence-lifetime_imaging_microscopy +[flim-paper]: https://onlinelibrary.wiley.com/doi/10.1111/jmi.70036 [dti]: https://en.wikipedia.org/wiki/Diffusion-weighted_magnetic_resonance_imaging [CryoET]: https://en.wikipedia.org/wiki/Cryogenic_electron_tomography From 5c7bb1232f24b933c1e8c1faf2833d0d35b6013b Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Thu, 25 Jun 2026 00:47:42 +0200 Subject: [PATCH 04/17] Add specific changes --- rfc/3/index.md | 46 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/rfc/3/index.md b/rfc/3/index.md index 2f825006..f4aa302c 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -226,6 +226,52 @@ appropriate action depends on the tool, but some suggestions include: - arbitrarily choose which axes to treat as spatial. - choose how to treat each axis based on heuristics such as size and position. +Here are the concrete changes that this RFC makes to the specification +document, taking as base the current development version: + +1. The following lines are removed from "multiscales metadata": + +> - The length of `axes` must be between 2 and 5 and MUST be equal to the +> dimensionality of the Zarr arrays storing the image data (see +> `datasets:path`). +> +> - `axes` MUST contain 2 or 3 entries of `type:space` +> +> - `axes` MAY contain one additional entry of `type:time` +> +> - `axes` MAY contain one additional entry of `type:channel` or a null / +> custom type. +> +> - `axes` entries MUST be ordered by `type` where the `time` axis must come +> first (if present), followed by the `channel` or custom axis (if present) +> and the axes of type `space`. +> +> - If there are three spatial axes where two correspond to the image plane +> (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the +> spatial axes SHOULD be ordered as `zyx`. + +2. The following lines are *added* to "multiscales metadata": + +> 0. The length of the axis names MUST match the number of axes of the array. +> 1. *If* a dataset contains exactly 2 spatial dimensions, those dimensions +> SHOULD be named `y` and `x`, except where rule 4 applies. +> 2. *If* a dataset contains exactly 3 spatial dimensions, those dimensions +> SHOULD be named 'z', 'y', and 'x', except where rule 4 applies. +> 3. *If* a dataset contains exactly 1 time dimension, it should be named `t`. +> 4. When image data axes map straightforwardly to axes with common names in +> the relevant field of practice, those axes SHOULD be named according to +> such conventions. For example, spatial frequency axes resulting from a +> Fourier transformation of `z', 'y', and 'x' SHOULD be named 'w', 'v', and +> `u`, respectively. Similarly, a temporal frequency axis resulting from +> a Fourier transformation of the `t` axis SHOULD be named `w` or `ω`. +> 5. Axis names SHOULD NOT be repeated within a dataset, even in a different +> case. That is, the same dataset SHOULD NOT have both an `X` and an `x` +> axis. +> 6. The order of the axes MUST match their ordering within the data if +> applicable. For example, if the axes are ordered as `DZYX`, where `D` is a +> field of displacement vectors, then the vectors must be ordered as `ZYX` +> within the array. + ## Prior art and references All of the above removals are part of the draft proposed [transformations From 638ea50c34ba7a495698952f8d66eae1a2fb15d4 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Thu, 25 Jun 2026 00:48:01 +0200 Subject: [PATCH 05/17] Acknowledge transpose codec and mapAxis transform --- rfc/3/index.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index f4aa302c..217cbebe 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -166,7 +166,11 @@ the adoption of OME-Zarr as an acquisition-time format due to performance concerns: many acquisitions happen in TZCYX order (all channels are acquired together for each z-slice), which violates the "axes must be ordered by type" requirement. In such cases, scientists must first acquire their data and *then* -transpose it — an expensive proposition for large datasets. +transpose it — an expensive proposition for large datasets. (Note: Admittedly, +Zarr transpose codecs, as well as the mapAxis transformation from RFC-5, +already offer solutions to this problem. However, the *simplest* solution of +flexible array ordering with default codecs and only scale and translation +transforms is only open after this RFC.) ## Motivation From c781a211c908be6188687fe9d7a6ec86f9ac344c Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Sat, 27 Jun 2026 22:43:57 +0200 Subject: [PATCH 06/17] Use dev text as basis as its clearer --- rfc/3/index.md | 44 +++++++++++++++----------------------------- 1 file changed, 15 insertions(+), 29 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index 217cbebe..cc96b759 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -114,51 +114,37 @@ bioimaging data and metadata to make it findable, accessible, interoperable, and reusable. The [paper describing NGFF and OME-Zarr][nat methods paper] notes that "the diversity of [biological imaging's] applications have prevented the establishment of a community-agreed standardized data format", but, [for -historical reasons][ome-model], [versions 0.4][ngff 0.4] and [0.5][ngff 0.5] -of the OME-Zarr specification [impose][ngff 0.5 multiscales metadata] strict -restrictions on the applications: - -> The length of "axes" must be between 2 and 5 and MUST be equal to the -> dimensionality of the zarr arrays storing the image data (see -> "datasets:path"). The "axes" MUST contain 2 or 3 entries of "type:space" and -> MAY contain one additional entry of "type:time" and MAY contain one additional -> entry of "type:channel" or a null / custom type. The order of the entries MUST -> correspond to the order of dimensions of the zarr arrays. In addition, the -> entries MUST be ordered by "type" where the "time" axis must come first (if -> present), followed by the "channel" or custom axis (if present) and the axes -> of type "space". If there are three spatial axes where two correspond to the -> image plane ("yx") and images are stacked along the other (anisotropic) axis -> ("z"), the spatial axes SHOULD be ordered as "zyx". - -And: - -> Each "datasets" dictionary MUST have the same number of dimensions and MUST -> NOT have more than 5 dimensions. - -The currently-in-development [v0.6 specification][ngff 0.6], which incorporates -RFC-5, maintains these limitations: +historical reasons][ome-model], [versions 0.4][ngff 0.4], [0.5][ngff 0.5], and +the currently-in-development [0.6 specification][ngff 0.6], which incorporates +RFC-5, all [impose][ngff 0.5 multiscales metadata] strict restrictions on the +applications: + +> Here, "image" refers to 2 to 5 dimensional data representing image or +> volumetric data with optional time and channel axes. + +and, > - The length of `axes` must be between 2 and 5 and MUST be equal to the > dimensionality of the Zarr arrays storing the image data (see > `datasets:path`). -> > - `axes` MUST contain 2 or 3 entries of `type:space` -> > - `axes` MAY contain one additional entry of `type:time` -> > - `axes` MAY contain one additional entry of `type:channel` or a null / > custom type. -> > - `axes` entries MUST be ordered by `type` where the `time` axis must come > first (if present), followed by the `channel` or custom axis (if present) > and the axes of type `space`. -> > - If there are three spatial axes where two correspond to the image plane > (`yx`) and images are stacked along the other (anisotropic) axis (`z`), the > spatial axes SHOULD be ordered as `zyx`. -These restrictions prevent users from converting existing +and, + +> - Every Zarr array referred to by a `path` MUST have the same number of +> dimensions and datatype and MUST NOT have more than 5 dimensions. + +These restrictions prevent users and prospective users from converting existing datasets to OME-Zarr. For example, Zeiss .czi datasets [may contain][czi format dimensions] dimensions such as H, I, and V to store different phases, illumination directions, or views respectively. They also hamper From 9360b2369205fc09f0f521c40248a486dfe8d8a0 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Sat, 27 Jun 2026 22:44:50 +0200 Subject: [PATCH 07/17] Reflow to fix hyperlink --- rfc/3/index.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index cc96b759..2f590978 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -145,18 +145,18 @@ and, > dimensions and datatype and MUST NOT have more than 5 dimensions. These restrictions prevent users and prospective users from converting existing -datasets to OME-Zarr. For example, Zeiss .czi datasets [may contain][czi format -dimensions] dimensions such as H, I, and V to store different phases, -illumination directions, or views respectively. They also hamper -the adoption of OME-Zarr as an acquisition-time format due to performance -concerns: many acquisitions happen in TZCYX order (all channels are acquired -together for each z-slice), which violates the "axes must be ordered by type" -requirement. In such cases, scientists must first acquire their data and *then* -transpose it — an expensive proposition for large datasets. (Note: Admittedly, -Zarr transpose codecs, as well as the mapAxis transformation from RFC-5, -already offer solutions to this problem. However, the *simplest* solution of -flexible array ordering with default codecs and only scale and translation -transforms is only open after this RFC.) +datasets to OME-Zarr. For example, Zeiss .czi datasets +[may contain][czi format dimensions] dimensions such as H, I, and V to store +different phases, illumination directions, or views respectively. They also +hamper the adoption of OME-Zarr as an acquisition-time format due to +performance concerns: many acquisitions happen in TZCYX order (all channels are +acquired together for each z-slice), which violates the "axes must be ordered +by type" requirement. In such cases, scientists must first acquire their data +and *then* transpose it — an expensive proposition for large datasets. (Note: +Admittedly, Zarr transpose codecs, as well as the mapAxis transformation from +RFC-5, already offer solutions to this problem. However, the *simplest* +solution of flexible array ordering with default codecs and only scale and +translation transforms is only open after this RFC.) ## Motivation From e0653e5fbbfd289cd837b6186aa4fd9fce16c3f2 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Sat, 27 Jun 2026 23:45:21 +0200 Subject: [PATCH 08/17] Elaborate on EBSD use case --- rfc/3/index.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index 2f590978..f50a360b 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -173,7 +173,11 @@ real datasets that are currently impossible to represent in OME-Zarr: - in [electron backscatter diffraction (EBSD)][ebsd], a microscopy technique common in materials science, a beam of electrons is scanned over a surface, and for each (2D) position in the scan, a full 2D diffraction pattern is - recorded, resulting in a 4-dimensional data array. + recorded, resulting in a 4-dimensional data array, with axes `x`, `y`, and + `dx`, `dy` for the diffraction pattern, also of `type:space`, typically + measured in `mm`. Scientists may want to compare the inferred crystal map + (`x`, `y`) with the original patterns, thus overlaying a 2D array onto a 4D + array. - from the diffraction patterns, it is possible to obtain an *orientation map*, containing a 3D angle at each 2D position of the material. - the same principles apply to [diffusion tensor imaging][dti], where a From d2f96c07a2471d1226e9b1e53617e39220a1fdfb Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Mon, 29 Jun 2026 17:42:08 +0200 Subject: [PATCH 09/17] Change MUST NOT to SHOULD NOT use same letter / different case --- rfc/3/index.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index f50a360b..6986f602 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -258,9 +258,9 @@ document, taking as base the current development version: > Fourier transformation of `z', 'y', and 'x' SHOULD be named 'w', 'v', and > `u`, respectively. Similarly, a temporal frequency axis resulting from > a Fourier transformation of the `t` axis SHOULD be named `w` or `ω`. -> 5. Axis names SHOULD NOT be repeated within a dataset, even in a different -> case. That is, the same dataset SHOULD NOT have both an `X` and an `x` -> axis. +> 5. Axis names MUST NOT be repeated within a dataset, and SHOULD NOT be +> different only by upper/lower-case. For example, the same dataset SHOULD +> NOT have both an `X` and an `x` axis. > 6. The order of the axes MUST match their ordering within the data if > applicable. For example, if the axes are ordered as `DZYX`, where `D` is a > field of displacement vectors, then the vectors must be ordered as `ZYX` From a4aeabccaea3d9d753e23a3155df71b9c76eac44 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Mon, 29 Jun 2026 17:51:23 +0200 Subject: [PATCH 10/17] Finalise full text of changes proposed. --- rfc/3/index.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/rfc/3/index.md b/rfc/3/index.md index 6986f602..484d5747 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -266,6 +266,23 @@ document, taking as base the current development version: > field of displacement vectors, then the vectors must be ordered as `ZYX` > within the array. +3. The following lines are amended as noted: + +> Note that the number of dimensions is variable ~~between 2 and 5~~ and that +> axis names are arbitrary, see multiscales metadata for details. + +> ~~Here, "image" refers to 2 to 5 dimensional data representing image or +> volumetric data with optional time or channel axes. It is stored in a +> multiple resolution representation.~~ +> Here, "image" refers to data stored in a Zarr Array representing image, +> volumetric, time lapse, or similar data. It MAY be stored in multiple +> resolutions. + +> Every Zarr array referred to by a path MUST have the same number of +> dimensions and datatype.~~, and MUST NOT have more than 5 dimensions.~~ + +No further changes to the specification document are proposed by this RFC. + ## Prior art and references All of the above removals are part of the draft proposed [transformations From 7c36c726cac19bbab2610acd3d5867922f0a0f64 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Tue, 30 Jun 2026 00:00:22 +0200 Subject: [PATCH 11/17] Add Cornelia as a commenter --- rfc/3/index.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/rfc/3/index.md b/rfc/3/index.md index 484d5747..0c64a87b 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -93,6 +93,12 @@ This RFC is currently in RFC state `R1` (send for review). - German BioImaging - 2026-02-05 - [Comment](./comments/2/index) +* - Commenter + - Cornelia Wetzker + - [cwetzker](https://github.com/cwetzker) + - Technische Universität Dresden + - 2026-03-19 + - [Comment](./comments/3/index) ``` ## Overview From 581b53ad084c7a2c3569e208dc0407c3db7e2ed4 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Tue, 30 Jun 2026 00:01:37 +0200 Subject: [PATCH 12/17] Expand on user stories --- rfc/3/index.md | 150 ++++++++++++++++++++++++++++++++++++------------- 1 file changed, 110 insertions(+), 40 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index 0c64a87b..b5ad359e 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -164,46 +164,116 @@ RFC-5, already offer solutions to this problem. However, the *simplest* solution of flexible array ordering with default codecs and only scale and translation transforms is only open after this RFC.) -## Motivation - -In addition to the .czi datasets mentioned in the preceding paragraph, and -alternate axis orderings driven by acquisition concerns, this section describes -real datasets that are currently impossible to represent in OME-Zarr: - -- in [Fluorescence Lifetime Imaging Microscopy (FLIM)][flim], there is an - additional time dimension containing the fluorophore decay over a much - shorter time scale (nanoseconds) than the typical spacing between time - points. This constitutes an additional time axis called `u` or `µ` and - can result in a 6-dimensional dataset with axes `CTUZYX`. (See, for example, - [this paper][flim-paper].) -- in [electron backscatter diffraction (EBSD)][ebsd], a microscopy technique - common in materials science, a beam of electrons is scanned over a surface, - and for each (2D) position in the scan, a full 2D diffraction pattern is - recorded, resulting in a 4-dimensional data array, with axes `x`, `y`, and - `dx`, `dy` for the diffraction pattern, also of `type:space`, typically - measured in `mm`. Scientists may want to compare the inferred crystal map - (`x`, `y`) with the original patterns, thus overlaying a 2D array onto a 4D - array. -- from the diffraction patterns, it is possible to obtain an *orientation map*, - containing a 3D angle at each 2D position of the material. -- the same principles apply to [diffusion tensor imaging][dti], where a - three-dimensional diffusion tensor is measured at each voxel position. -- it is common to compute Fourier transforms of 3D images. The datasets have - three dimensions but they are measured in *frequency*, not space. -- when computing segmentations, one may use finer or coarser priors, resulting - in overlapping, equally valid segmentations, for example, of organelles at - one level, cells at another, and tissues at yet another. One common way to - store such a segmentation is to add a dimension for "coarseness". -- computed spaces may have arbitrary dimensions related to the computation. For - example, in subtomogram averaging of [cryo electron tomography][CryoET], - single particles from a tomogram are picked and aligned, producing many - instances of the same 3-dimensional particle. One may wish to store all the - instances in a single 4-dimensional array (one dimension being the *instance - number*). Or, one may use dimension-reduction techniques such as PCA, then - browse average particles along each PCA axis. This creates a virtual 5D space - containing the three spatial dimensions, then a "component number" axis for - the PCA components and a "position" axis for the position along that - component. +## Motivation / User stories + +Dimensions other than TCZYX have many existing uses in microscopy, which are +currently cumbersome or even impossible to do in OME-Zarr. We detail some +below: + +### Conversion of existing microscopy data formats to OME-Zarr + +As noted in [background](#background), existing microscopy image data formats +already have dimensions other than OME's TCZYX. Zeiss's .czi file format [can +include][czi format dimensions] H, I, and V, representing different phases, +illumination directions, or views. Leica's .lif format uses [many other +dimensions][lif dimensions], including λ (lambda) for different emission +wavelengths, A for different rotations, Λ (capital lambda) for different +emission wavelengths, and M for a "mosaic" dimension. + +In order for OME-Zarr to gain broad adoption, it should be able to represent +datasets from common microscope vendors. Although workaround exist (such as +using the current "Custom" dimension and interleaving other dimensions into it, +or splitting the image into several TCZYX images), they are cumbersome and make +the resulting data difficult to manage. + +### Fluorescence Lifetime Imaging Microscopy (FLIM) + +In [Fluorescence Lifetime Imaging Microscopy (FLIM)][flim], there is an +additional time dimension containing the fluorophore decay over a much shorter +time scale (nanoseconds) than the typical spacing between time points. The +fluorophore decay lifetime can be used to get more information about the +sample, for example by separating fluorophores not only according to their +emission spectra but also their lifetime. The decay measurement constitutes an +additional time axis called `u` or `µ` and can result in a 6-dimensional +dataset with axes `CTUZYX`. (See [comment 3](./comments/3/index), and [this +paper][flim-paper].) + +FLIM data currently cannot be represented in OME-Zarr, causing users to use +proprietary formats, bare Zarr arrays missing critical metadata (e.g. +[S-BIAD1967][S-BIAD1967] on BioImage Archive), or datasets +split along an arbitrary axis in order to be represented e.g. as OME-TIFF (see +[above dataset in OMERO][flim-omero]), making exploration and analysis +needlessly difficult. + +### Electron backscatter diffraction (EBSD) + +In [electron backscatter diffraction (EBSD)][ebsd], a microscopy technique +common in materials science, a beam of electrons is scanned over a surface, +and for each (2D) position in the scan, a full 2D diffraction pattern is +recorded, resulting in a 4-dimensional data array, with axes `x`, `y`, and +`dx`, `dy` for the diffraction pattern, also of `type:space`, typically +measured in `mm`. From EBSD spectra, scientists may detect the orientation of a +crystal at any (x, y) position, and thus infer the crystal boundaries. +Comparing the inferred crystal boundaries with the original patterns is an +important part of data quality checks. Currently, this kind of microscopy data +cannot be stored in OME-Zarr. + +Within the same workflow, the crystal orientation is usually encoded as three +*Euler angles* or four *quaternion* components stored at each pixel position. +Although it's possible to use the "custom" axis for this purpose, a dedicated +axis with a clear naming convention is more ergonomic for scientists. + +### Diffusion Tensor Imaging (DTI) + +3-dimensional [DTI][dti] measures the ease with which water diffuses in +different directions in a tissue. At each pixel, you then have a symmetric +2-dimensional diffusion tensor with components `Dzz`, `Dzy = Dyz`, `Dzx = Dxz`, +`Dyy`, `Dyx = Dxy`, and `Dxx`. These could be represented either as a +specialised single axis, or, with a custom Zarr codec for symmetric matrices, +as the mathematical, 2-axis symmetric matrix per pixel. + +### Fourier analysis + +Transforming images into Fourier space (spatial frequency) is common in many +image analysis pipelines, for example for filtering, artifact removal, +denoising, and deconvolution. For computational efficiency, scientists may want +to save these intermediate image products for later reprocessing. + +### Overlapping labels + +OME-Zarr can represent not only raw images, but also *label images*, or +segmentations. Traditionally, segmentations assigned a single integer value to +each pixel in the source image. However, newer segmentation methods produce +*coarse-to-fine* segmentations, with semantic meaning. For images spanning many +scales, as produced by modern microscopes, we may want to segment tissues, +cells within those tissues, and organelles within those cells. These three +levels of segmentations can be stacked along a new "coarseness" axis. + +Similarly, new segmentation methods can produce *overlapping binary masks*. Due +to the overlap, they *cannot* be stored as traditional integer masks (one value +per pixel), but are typically instead stored as *n* boolean masks. For this +mask, an extra "instance" axis is needed in addition to the [TCZ]YX axes of a +source image. + +### Other computational outputs + +Downstream computational products are necessary for the analysis of microscopy +data, and these should ideally be stored in formats compatible with the tooling +used to work with the raw data. The format aims to be flexible enough to +accommodate these products, such as segmentations (the `label-image` section), +or the outputs of registrations (see [rfc-5](../5/index)). + +Some outputs may naturally contain arbitrary dimensions, for example, a grid +search of the parameter space for a denoising algorithm may contain an +additional axis per parameter. + +Similarly, when creating a deep learning dataset, we may wish to store original +image instances along one axis and augmented instances along another. + +In general, the space of downstream products is quite literally endless, and it +would serve the community to be able to store those products in OME-Zarr, with +proper metadata, relating back to the original data, rather than having to use +custom containers and manage metadata separately. ## Proposal From 96381ff3bdddd9f45c8aead48c627617aaee9ee4 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Tue, 30 Jun 2026 00:03:01 +0200 Subject: [PATCH 13/17] Remove outdated sections --- rfc/3/index.md | 31 +++++++++++-------------------- 1 file changed, 11 insertions(+), 20 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index b5ad359e..658841a3 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -359,28 +359,19 @@ document, taking as base the current development version: No further changes to the specification document are proposed by this RFC. -## Prior art and references - -All of the above removals are part of the draft proposed [transformations -specification][trafo spec], with one exception: the draft currently specifies -that a dataset may only have up to three spatial axes. However, this limitation -is [not set in stone][space dims comment] and could be removed, partly to -improve backwards compatibility. - ## Stakeholders -Who has a stake in whether this RFC is accepted? - -* Facilitator: Josh Moore (OME) -* Proposed reviewers: - - John Bogovic (HHMI Janelia Research Campus): lead author of draft - [transformations specification proposal][trafo spec] - - Will Moore (OME): maintainer of ome-zarr-py library - - Norman Rzepka (Scalable Minds): maintainer of zarrita -* Consulted: - - Every commenter [on this thread](https://github.com/ome/ngff/pull/239). -* Socialization: - - image.sc: +Extensive prior discussion of this RFC has happened on [PR 239][gh-239], on +[image.sc][imagesc-rfc-3-thread], and on [Zulip][zulip-rfc-3-thread]. There is +emphatic support from the image acquisition community, which has been stifled +from supporting OME-Zarr by the restrictions removed in this RFC. Additionally, +users of less-common imaging modalities, such as FLIM, also strongly support +the RFC. + +Developers of visualization libraries and software are concerned that this PR +may result in a "wild west" of OME-Zarr datasets that have little in common, +making it difficult for tools to decide *which* axes to display. More details +about these concerns are developed below in the "Drawbacks" section. ## Backwards Compatibility From 71d37072e6f79e6b2f4e28e494535014a3d3f600 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Tue, 30 Jun 2026 00:03:10 +0200 Subject: [PATCH 14/17] Add references --- rfc/3/index.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/rfc/3/index.md b/rfc/3/index.md index 658841a3..47533458 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -462,6 +462,7 @@ This RFC is placed in the public domain. [ngff 0.5 multiscales metadata]: https://ngff.openmicroscopy.org/specifications/0.5/index.html#multiscales-metadata [ngff 0.4 axes metadata]: https://ngff.openmicroscopy.org/0.4/index.html#axes-md [czi format dimensions]: https://web.archive.org/web/20240521085825/https://zeiss.github.io/libczi/imagedocumentconcept.html#autotoc_md7 +[lif dimensions]: https://github.com/cgohlke/liffile/blob/f79868ebad77d9848bcae09f99db8f0737b0f94b/liffile/liffile.py#L916-L931 [spec update]: https://github.com/ome/ngff/pull/235 [this pr]: https://github.com/ome/ngff/pull/239 [recap comment]: https://github.com/ome/ngff/pull/239#issuecomment-2327451719 @@ -472,6 +473,11 @@ This RFC is placed in the public domain. [flim-paper]: https://onlinelibrary.wiley.com/doi/10.1111/jmi.70036 [dti]: https://en.wikipedia.org/wiki/Diffusion-weighted_magnetic_resonance_imaging [CryoET]: https://en.wikipedia.org/wiki/Cryogenic_electron_tomography +[S-BIAD1967]: https://www.ebi.ac.uk/biostudies/bioimages/studies/S-BIAD1967 +[flim-omero]: https://omero.med.tu-dresden.de/webclient/?show=project-1401 +[gh-239]: https://github.com/ome/ngff/pull/239 +[imagesc-rfc-3-thread]: https://forum.image.sc/t/ome-ngff-update-postponing-transforms-previously-v0-5/95617/2 +[zulip-rfc-3-thread]: https://imagesc.zulipchat.com/#narrow/channel/328251-NGFF/topic/RFC-3.3A.20remove.20dimension.20restrictions/near/568178521 [^1]: https://github.com/ome/ngff/pull/239#issuecomment-2122809286 [^2]: https://github.com/ome/ngff/pull/239#issuecomment-2149119404 From ef1452a676486daf7d5464aa9e6c565850201b70 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Sat, 4 Jul 2026 02:24:00 +0200 Subject: [PATCH 15/17] Add information about testing --- rfc/3/index.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index 47533458..586d6777 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -446,8 +446,13 @@ time. ## Testing -If the RFC is accepted, sample datasets matching the new spec will be -produced for implementations to test against. +Datasets conforming to the new specification can be found at: + +https://github.com/clbarnes/ome-zarr-rfc3-data + +including two real (subsampled) datasets, as well as a script for synthetic +data generation. Implementations may check their compliance with these +datasets. ## License From b82fa230a21e0dae9013465a08e5a53ccc643728 Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Sat, 4 Jul 2026 12:55:26 +0200 Subject: [PATCH 16/17] Add this update to the changelog --- rfc/3/index.md | 1 + 1 file changed, 1 insertion(+) diff --git a/rfc/3/index.md b/rfc/3/index.md index 586d6777..a743d24a 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -492,3 +492,4 @@ This RFC is placed in the public domain. | Date | Description | Link | | ---------- | ---------------------------- | ---------------------------------------------------------------------------- | | 2024-10-08 | RFC assigned and published | [https://github.com/ome/ngff/pull/239](https://github.com/ome/ngff/pull/239) | +| 2026-07-04 | Updated to address comments, elaborate on use cases, include specific changes to spec doc, and add test data | [https://github.com/ome/ngff/pull/560](https://github.com/ome/ngff/pull/560) | From 3d96c5396c30bc16d06bd8b592bce4c29b0ad8ec Mon Sep 17 00:00:00 2001 From: Juan Nunez-Iglesias Date: Tue, 14 Jul 2026 14:44:27 +0200 Subject: [PATCH 17/17] Update sample data paragraph --- rfc/3/index.md | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/rfc/3/index.md b/rfc/3/index.md index a743d24a..954d514f 100644 --- a/rfc/3/index.md +++ b/rfc/3/index.md @@ -450,9 +450,26 @@ Datasets conforming to the new specification can be found at: https://github.com/clbarnes/ome-zarr-rfc3-data -including two real (subsampled) datasets, as well as a script for synthetic -data generation. Implementations may check their compliance with these -datasets. +This includes three synthetic datasets and (in progress, pull request #1) two +real (subsampled) datasets. + +HTTP access to the datasets is currently available at: + +``` +# synthetic data +https://huggingface.co/buckets/clbarnes/ome-zarr-rfc3-data/resolve/astronaut_xcy.ome.zarr +https://huggingface.co/buckets/clbarnes/ome-zarr-rfc3-data/resolve/ecg_1d.ome.zarr +https://huggingface.co/buckets/clbarnes/ome-zarr-rfc3-data/resolve/ramp_6d.ome.zarr +# subsampled real data +https://test-bucket.image.coop/rfc3/flim-tmr31-3-reduced64.ome.zarr +https://test-bucket.image.coop/rfc3/CP-Ti-abnormal-grains.zarr +``` + +Implementations may check their compliance with this RFC using these datasets. +As a reminder, this RFC explicitly takes the position that partial +implementations are OK, and software is considered compliant if it provides +an informative error message (e.g. "The given dataset contains an unknown axis +'U', which is not supported by this viewer."). ## License