Add add axis transform

[jo-mueller]

Relevant for ome/ngff#499. This PR adds a new, super-simple transform to broadcast coordinates from N to N+1 dimensionality by prepending the coordinates with a singleton dimension. I considered to add a field to indicate at which position the singleton should be inserted, but I figures that it would be easier to interpret a simpler newAxis + mapAxis transform sequence. Also, different programming languages may treat indices a bit differently, so this may be more foolproof.

Also, affine transformations currently already allow for input dimensionality != output dimensionality. So instead of baking an up-projection into an affine, this can now be declared more explicitly.

I think this transform is super useful, for instance to project 2D images (histology images) into 3D space, where they may have been aligned with some sort of volumetric images (see ABBA tool).

I figured it'd be now or never to slip it in and it adds or takes nothing from the current 0.6 state of the art.

cc @bogovicj @dstansby @clbarnes @LucaMarconato @d-v-b

[github-actions]

Automated Review URLs

• Readthedocs

[clbarnes]

I still can't decide whether this should be defined as a newaxis or a dropaxis.

If we want to co-visualise a multichannel YXC image and its YX labels, putting the label coordinates into a specific channel doesn't seem to make sense, where I think putting a multichannel pixel into strictly YX coordinate system does. Even saying "I have a coordinate in YX space and want all the channel data at that point" doesn't quite make sense in the context of this transform because for a 3-channel image you need to convert your 1 label coordinate into 3 image coordinates (0,Y,X) (1,Y,X) (2,Y,X).

On the other hand, only defining a dropaxis means we can't line up a YX slice of a ZYX volume by adding the axis and then translating in Z.

[jo-mueller]

@clbarnes I'm not 100% sold on the dropaxis transform, mostly because it addresses a problem that viewers seem to get right intuitively? I.e., would viewers generally accept scale values for a channel axis? They definitely exist in the ngff spec, but many readers pop out the corresponding scale values before handing them over to viewers. Attributing a labels image correctly to a particular channel (dimension) seems more like something that collections will be better at solving?

I am thinking of adding something like The corresponding axis in the output coordinate system MUST be of type space or time in the transform's spec, to navigate around the channel dimension/labels issue.

[LucaMarconato]

Thanks for sharing! I wonder if achieving the dropAxis and newAxis should be as part of the specs or as an helper function that returns an affine transformation.

[jo-mueller]

Thanks for sharing! I wonder if achieving the dropAxis and newAxis should be as part of the specs or as an helper function that returns an affine transformation.

Also a good point; Both can already be baked into an affine transform 🤔 But then again, so can a scale, translation or rotation.