Skip to content

RFC-3: review 1 #420

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
clbarnes wants to merge 3 commits into
base: main
Choose a base branch
from
Open

RFC-3: review 1 #420

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
67a787a
RFC-3: review 1
clbarnes Jan 14, 2026
cb385c9
fix typo
clbarnes Jan 14, 2026
522bb64
Fix typo
clbarnes Jan 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions rfc/3/reviews/1/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,38 @@
# RFC-3: Review 1

Copy link
Contributor

@jo-mueller jo-mueller Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor suggestion (unrelated to content): In rfc5, I added reference anchors in the reviews like so:

(rfcs:rfcX:reviewY)=

which makes it easy to cross-reference across the ngff page in a controlled manner. But since this comment is likely going to be the end of a discussion rather than the start of it, you might as well ignore this :)

## Review authors

Chris Barnes <chris.barnes@gerbi-gmb.de>

## Conflicts of interest

None.

## Summary

This RFC is an important step towards opening up OME-Zarr to different types of bioimaging.
The current axes specification is already flexible enough that implementations cannot blindly make assumptions about what a particular dimension index means,
while being restrictive enough to be a bit annoying to write validation for.

This RFC represents an opportunity to simplify the spec and its implementations,
while serving a broader audience.

## Significant comments and questions

N/A

## Minor comments and questions

The current specification optimises for particular access patterns in terms of memory locality,
and the RFC already makes good points that these optimisations may not hold for other access patterns.
Because of the Zarr transpose codec,
the conceptual layout of the array may not match its on-disk layout,
making the utility of such optimisations even more hazy.
Lastly, with the introduction of the mapAxis transformation in RFC-5,
viewers may not even be retrieving array subsets which match the conceptual layout in zarr.

Users should have the freedom to design their array layouts to suit their own data and use cases, which this RFC allows.

## Recommendation

Accept.
Loading