RFC-5 from viewpoint of astronomy

[timj]

I was very interested to see that you are working on a more complete transformation model. At the Rubin observatory we are looking at Zarr and were trying to see how our coordinate transformations could be included.

In astronomy we have had a system for 30 years that allows complex combination of distinct mappings in parallel and in serial attached to different types of Frames. I assume it's a bit late now but maybe a mention of this could be added to the prior art? We support shifts, scaling, matrix rotations, polynomials, splines, chebyshevs and spherical geometry plus many others. We handle frames including sky, spectral, and time frames. You can chain frames and mappings together in arbitrary ways.

For example we have a C library in https://github.com/Starlink/ast that implements the system and I'm working on a Rust port and a JSON serialization. There is a write up of the entire system on arXiv at https://arxiv.org/abs/1602.06681 (https://doi.org/10.1016/j.ascom.2016.02.003).

[lubianat]

Oh, that is interesting, thank you for reaching out. My 2c is that we should yes find a place to mention it, but maybe not the "prior art" section, because it did not influence the design AFAIK.

Thoughts @jo-mueller ? I'll add @Tom-TBT to the loop for the astronomy context.

If you have the time/interest, it could be very useful for us to have a "Comment" (like this one) sharing your thoughts from the astronomy perspective with your background.

[timj]

The other thing that is super important in the way we do transformation chaining is that there is a simplification phase that can work out, for example, that matrix maps followed by zoom map can be simplified into a scaled matrix map. This is really important for transformation performance since it allows people to chain the mappings how they want and then simplify them without having to think about it.

[jo-mueller]

@timj oh wow, I'll never cease to be amazed by what kinds of use cases this can be tailored to. I think at least some of these questions point more in the direction of RFC3, which revolves around making ome-zarr more broadly applicable beyond the current 5D image limit (tczyx). I could see the above terms as an interesting addition there, i.e., could the axes spec defined over there be used to express spherical geometry (Not sure how this is typically expressed to begin with :) ) or spectral imaging (probably pretty easy in a post RFC3-world).

The question for RFC5 I am seeing here is how the above-listed transforms can be expressed within the confines of the transforms that RFC5 currently gives you? I guess if nothing else, you can bake pretty much everything into a coordinates/displacement transform with the correct interpolator, but that would probably rob you of the underlying mathematical model's precision. I.e., it's probably more desirable to write out a transform's parameters rather a sampled version of it.

I'm very interested in how chaining transforms works on your end though and I think @clbarnes, our Rust-person will be, too! Especially collapsing multiple chained transforms into a single operation will be an important step for performance down the road.

[clbarnes]

We are building out transformnd as a generic frontend for any kind of coordinate transformation, which happens to implement all the transforms we need from RFC-5 (plus some others), as well as adapters to apply these transformations to types other than plain arrays. It is also generic over python array API types, including dask and jax. That library has a TransformSequence.simplify method which does as you describe - checking for consecutive transforms which can be represented as affines and composing them by multiplication (as well as getting rid of identity transforms and a couple of ther bits and bobs).

transformnd could happily use your C library as an alternative backend. I was also working on a rust implementation of the RFC-5 transformations; I found there are some interesting optimisations available for certain transforms depending on the memory order of the coordinate arrays.

[timj]

The AST library (C and soon Rust) has a concept of "Channels" that allow external representations to be mapped into the internal form for execution so if you have a JSON schema I can definitely look at adding support for reading and writing JSON to be able to use the AST library for the transformation and simplification machinery. We have channels for reading in the YAML WCS serialization used by JWST and the standard astronomy FITS file WCS headers so it's doable so long as AST has an equivalent mapping known to it.

My rust port is about 90% complete and is pretty fast.