fix: describe byDimension axes as indices, and a typo in image.schema - #195
Merged
Merged
Conversation
Automated Review URLs |
This was referenced Sep 3, 2026
vboussot
changed the title
Contributor
|
@vboussot thanks for the fix. I think this can go into the main branch. Also, feel free to add your name to the authors! (see contrib section on how/where to make the change). |
jo-mueller
approved these changes
Aug 26, 2026
vboussot
added a commit
to fideus-labs/ngff-zarr
that referenced
this pull request
Aug 27, 2026
Both are description text, so no document changes validity. "A sequence of a ingle scale followed by a single translation" in image.schema, present since 0.6rc0. And byDimension describing inputAxes and outputAxes as names of axes, while both arrays are typed number: the spec text says positions in three places, and ngff-spec ships an invalid fixture using ["x"] so that names are rejected. Both are proposed upstream in ome/ngff-spec#195 against the 0.9dev branch; these copies carry them until a later tag brings them back.
The two descriptions read "Names of the input axes" and "Names of the output axes" while both arrays hold numbers. The spec text is already explicit that these are positions: the transformation table gives "inputAxes": List[number], the byDimension section states that the values are arrays of integers, and tests/attributes/spec/invalid holds a fixture that uses axis names precisely so it is rejected. Also fixes a typo in the sequence description of image.schema. Closes ome#179
CITATION.cff regenerated with `jupyter book build --cff`, as the contribution guide asks.
vboussot
force-pushed
the
fix-bydimension-axes-description
branch
from
August 27, 2026 09:38
4f59cae to
8ffd84e
Compare
vboussot
added a commit
to fideus-labs/ngff-zarr
that referenced
this pull request
Aug 27, 2026
"Indices", which is what ome/ngff-spec#195 settles on, rather than the "Positions" this copy carried: a later tag then brings the same sentence back instead of a second wording.
Contributor
Author
|
Thanks @jo-mueller. Retargeted to |
clbarnes
approved these changes
Aug 27, 2026
jo-mueller
approved these changes
Aug 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two description fixes in the schemas, against
0.9devas suggested in fideus-labs/ngff-zarr#686.coordinate_transformations.schemaThe
byDimensionchild transformations describeinputAxesandoutputAxesas "Names of the ... axes", while both arrays are typednumber. The spec text is already unambiguous that these are positions:index.md:474) gives"inputAxes": List[number]and"outputAxes": List[number]index.md:1229: "The values ofinputAxesandoutputAxesare arrays of integers."index.md:1234requires every axis index of the parent output coordinate system to appear in exactly one childoutputAxesarraytests/attributes/spec/invalid/transforms/bad_byDimension_wrong axes_type.jsonuses["x"]and["y"]precisely so that it is rejectedSo it is the description that is out of sync, not the item type. That is #179, answered in its thread by @jo-mueller.
image.schema"A sequence of a ingle scale followed by a single translation" now reads "a single scale".
Both changes are description text only, so no document changes validity.
Noticed while vendoring the
0.9.dev1schemas into ngff-zarr, where they are used verbatim to backvalidate=True.Closes #179