Skip to content

fix: axes_order only virtualises canonical axes, unknown names raise - #286

Merged
lorenzocerrone merged 1 commit into
mainfrom
fix/axes-order-canonical-only
Nov 12, 2026
Merged

lorenzocerrone merged 1 commit into
mainfrom
fix/axes-order-canonical-only

Conversation

@lorenzocerrone

Copy link
Copy Markdown
Collaborator

Fixes #277.

axes_order kept any unresolvable name as a virtual (singleton) axis, so a typo ("czyq") became a phantom dimension with x dropped, and the failure surfaced much later in the caller's own code.

  • A name that is not on disk is accepted only if it is a canonical axis (t, c, z, y, x) or the name the AxesSetup maps to one; it normalises to the canonical name. "czyx" on a c,y,x image still gives (1, 1, y, x).
  • Any other name raises NgioValueError naming it, the full order, the image axes and the canonical set.
  • The duplicate-axis error names the repeated axis and echoes the order.
  • New validate_axes_order(dimensions, axes_order) in ngio.io_pipes._ops_axes; the five iterator constructors call it, so a bad order fails at construction rather than at the first read.
  • The existing container test asked for a "virtual" axis; it now asks for "z", keeping the coverage.
  • One sentence in the images and iterators getting-started pages.

Checklist before merging

  • I added an appropriate entry to CHANGELOG.md

🤖 Generated with Claude Code

@codecov

codecov Bot commented Nov 12, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@lorenzocerrone
lorenzocerrone merged commit 2e9e001 into main Nov 12, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

axes_order accepts arbitrary names as virtual axes; only canonical axes should qualify

1 participant