RFC-5: Transformations and Coordinate systems

[bogovicj]

No description provided.

[github-actions]

Automated Review URLs

• Readthedocs
• render latest/index.bs
• diff latest modified

[normanrz]

Thanks for your continued work on the transformations proposal and for writing it up as an RFC.
OME-Zarr really needs expanded transformation capabilities and I like this proposal! Happy to endorse it.

One issue that I see is the use of absolute paths in the path attribute (i.e. starting with /). This seems somewhat ill-defined to me. The example in the RFC shows that "store.zarr" is the root, which I assume would be the starting point for the absolute paths. However, any group in a Zarr hierarchy is a valid hierarchy on its own and there is no mandate for a .zarr suffix to denote a root. Therefore, I would advocate for restricting paths to relative paths, which would be relative to the folder that holds the zarr.json.

Also, I want to mention that there is interest in the community to create a "collections" proposal for OME-Zarr. I haven't gotten the time to write an RFC yet but I think that could integrate nicely with this transformations proposal and might provide solutions for the path issue as well.

[d-v-b]

Why make the default name require information about where the array is stored in the container? This means that accessing the default coordinate system requires accessing the storage layer for the array, which rules out anything that acts exclusively on metadata.

Perhaps it would be simpler to reserve a string like "default" for the default coordinate system.

[bogovicj]

Because the coordinate systems of different arrays need to be different by default.

[d-v-b]

Suggested change

	For example, to map an array's discrete coordinate system to its corresponding physical coordinates.
	For example, coordinate transforms can be used to map an array's discrete coordinate system to its corresponding physical coordinates.

[LucaMarconato]

Thanks @bogovicj for opening the draft for the RFC, I have added my review. The points are mostly minor and I have only two more small comments, here below. After the above is resolved and the comments are addressed, for me we are good to go to officially submit the RFC.

1. I find this example of multiscale transformations vs "standard" transformations, very useful: https://github.com/bogovicj/ngff/blob/coord-transforms/latest/examples/multiscales_strict/multiscales_example_relative.json. I would stress this example more in the specs text.
2. Some things are not clear to me from the example above:
   2.1 are we allowed to use just scale, scale+translation or any transformation for the multiscale images? I am not sure what's the best here
   2.2 related to the point above is this issue of "what is a multiscale image and what not" Clarifying that multiscale images can only be the same image downscaled #260. I opened it outside the context of this PR, but I think it is still useful to decide how to proceed.

Regarding 2.1, I think that we should allow for scale + translation and not general transformations. Also, I think a scale alone is now enough because we may need small translations depending of the downsampling algorithm because the pixel 0 of a downscaled image may not correspond to the pixel 0 of the original image. Also some people may find useful to define a image origin.

[bogovicj]

Thanks @LucaMarconato and @d-v-b ,

I address most of your comments. While there are few left, I'll get to them soon, and they're more minor. So I'm going to take this PR off of draft status.

[joshmoore]

• Assigned RFC-5
• Added navigation links and changelog
• Corrected some minor formatting issues

Merging and sending for review once the build is green. If you would like to be added as an Endorser, please comment below or as always, PRs welcome.

Thanks to everyone involved! 🎉

[tischi]

I endorse this RFC