WIP: 0.9.dev1

[jni]

0.9.dev1 is intended to be:

• 0.6rc1
• with RFC3
• and RFC4
• and probably omero fields optional #87

in current WIP this only includes RFC3. I need to get RFC4 in before we merge this.

Edit 1 (2026-08-20): updated title to 0.9.dev1 to reflect discussion and match PEP-440.

Edit 2 (2026-08-21): This PR now contains all of the listed requirements (RFC3, RFC4, #87 omero fields optional) and should be ready to merge to allow implementations to start to be written against it. Some notes below.

notes

The limits removals on coordinate-transformations are the thing I'm least sure about, would appreciate extra eyes there.

In schemas/coordinate_transformations.schema, rotation is defined by a 2, 3, 4, or 5-dimensional rotation matrix. This is incompatible with RFC-3 but cannot be easily extended to an arbitrary number of dimensions.

Possible solutions:

• Amend RFC-3 to have a large number of max dimensions (say, 12? 16?), and continue the definition given the arbitrary rotations
• For higher-dimensional rotations, allow instead a sequence of 2-axis rotations, which compose into a high-dimensional rotation. (Can higher-dimensional rotations always be decomposed in this way?)
• Amend 0.6/RFC-5 to disallow >3D rotations, since they are very uncommon, and can already be decomposed (as a sequence of 2D rotations, because sequences are already a thing.)

I'm also not sure about 6199f0e and the difference to 93c1ba7.

Finally I don't know how to express that orientation can only be present if axis type is "space".

[github-actions]

Automated Review URLs

• Readthedocs

[sbesson]

@jni thanks for starting this work. We're looking forward to having a first rendered version of this specification as well as dev schemas that we can use to validate datasets generated by implementations!

Immediate question: is the next version number 0.9dev1 (as in this PR) or 0.9.dev1 (used in a few public discussions)?

We have no opinion one way or the other, but we have used the latter so far so if the consensus is to move towards the first form, we will need to update our implementation and regenerate sample data /cc @melissalinkert

[clbarnes]

is the next version number 0.9dev1 (as in this PR) or 0.9.dev1 (used in a few public discussions)

This came up with the dev versions in 0.6. Because we use python tooling in the build step of the repo, we normalised on PEP440-style version specifiers 0.6.dev0 and 0.6rc0. Overfitting to the language we happen to be using for the build is not ideal, but it's pretty well specified with implementations in many languages, while allowing a lot of flexibility in the information included in a version string. The inconsistency in . between the dev and a/b/rc is annoying, but I suppose it's intended so that you can have a dev version for an alpha release, and so on. This rust crate has a good run-down of the downsides of PEP440.

Standard SemVer would use something like 0.9-dev.1 but, other than .-delimiting, treats string and numeric components of the pre-release version as arbitrary, to be sorted lexicographically and numerically respectively. e.g. dev would come after alpha and beta. It also doesn't allow post-releases (probably fine, a post-release should probably be a patch release) or epochs e.g. if we decided we wanted to switch to calver later (also probably fine).

IMO we should stick with PEP440 (0.9.dev1), or switch to standard SemVer (0.9-dev.1) and separate the versioning of the project from the versioning of the python tooling used to build it, but I don't care too much about which.

[melissalinkert]

Just to be clear, then, is the use of 0.9dev1 now fully decided? I need to update glencoesoftware/bioformats2raw#330 and glencoesoftware/raw2ometiff#156 with the agreed-upon version number before merging and tagging release candidates, which we expect to do within the next few days. If the version number is still being discussed, I need to know so that merging/tagging can be delayed until the discussion is resolved.

[jni]

Apologies, for the confusion, my confusion indeed stemmed from the inconsistency between 0.6.devN and 0.6rcN noted by @clbarnes above. I think consistency with the 0.6 series makes sense, which means I'll update this PR to match that. In short @melissalinkert @sbesson, let's go with 0.9.dev1, no need to change your outputs, I will update this PR accordingly.

[jni]

Here's the current validation test failures:

FAILED tests/test_attributes.py::test_attributes[spec/invalid/image/missing_space_axes] - Failed: DID NOT RAISE ValidationError
FAILED tests/test_attributes.py::test_attributes[spec/invalid/image/non_existent_orientation] - Failed: DID NOT RAISE ValidationError
FAILED tests/test_attributes.py::test_attributes[spec/invalid/image/non_existent_orientation_type] - Failed: DID NOT RAISE ValidationError
FAILED tests/test_attributes.py::test_attributes[spec/invalid/transforms/bad_projectAxis_insert_too_high_dim] - Failed: DID NOT RAISE ValidationError
FAILED tests/test_attributes.py::test_attributes[spec/invalid/transforms/bad_projectAxis_insert_too_many] - Failed: DID NOT RAISE ValidationError
FAILED tests/test_attributes.py::test_attributes[spec/invalid/transforms/bad_projectAxis_remove_too_high_dim] - Failed: DID NOT RAISE ValidationError
FAILED tests/test_attributes.py::test_attributes[spec/invalid/transforms/bad_projectAxis_remove_too_many] - Failed: DID NOT RAISE ValidationError
FAILED tests/test_attributes.py::test_attributes[spec/valid/image/many_space_axes] - jsonschema.exceptions.ValidationError: {'ome': {'version': '0.9.dev1...

Most of these are because they have now become valid, so I'll move them. But these two:

FAILED tests/test_attributes.py::test_attributes[spec/invalid/image/non_existent_orientation] - Failed: DID NOT RAISE ValidationError
FAILED tests/test_attributes.py::test_attributes[spec/invalid/image/non_existent_orientation_type] - Failed: DID NOT RAISE ValidationError

I don't understand why they are failing. Here's the orientation schema, which specifies that the strings must come from specific lists:

https://github.com/jni/ngff-spec/blob/af560df45c0aa987d537e128195bc2dcd454c0a4/schemas/axis_orientation.schema#L11-L43

and here's the relevant part of the files that are unexpectedly passing validation:

https://github.com/jni/ngff-spec/blob/af560df45c0aa987d537e128195bc2dcd454c0a4/tests/attributes/spec/invalid/image/non_existent_orientation.json#L16-L18

https://github.com/jni/ngff-spec/blob/af560df45c0aa987d537e128195bc2dcd454c0a4/tests/attributes/spec/invalid/image/non_existent_orientation_type.json#L26-L29

I'm a noob with jsonschema so I would appreciate any tips or advice here!

[jni]

@joshmoore @clbarnes @jo-mueller This should be ready for review. I've also rebased my changes into logical commits to make review easier. Especially if you skip the last commit (which updates the version string in every file), the list of changes should be manageable.