Description
Over at JuliaAstro/AstroImages.jl#29 (comment) we have a use case that OffsetArrays is almost perfect for.
In astronomy, it's common to have physical coordinates associated with the axes of a data cube. For instance, angular X/Y coordinates along the first and second axes and wavelength along the third axes (or polarization, or time, etc.).
This is represented by something called a WCS transform for which we have the library WCSTransforms.jl. The WCS transform has functions that allow us to map from image indices to physical coordinates and back.
What's unusual is that a WCSTransform can also contain an affine transformation matrix that describes for example, rotation between these axes. That means that in general, moving along the a third (say, spectral) axis might change the physical coordinates associated with indices along the first and second axes.
OffsetArrays could almost solve this for us, since we can track the image coordinates through slicing etc.
But if a user selects say a 2D slice of a 3+D cube, there's no way at the moment for an OffsetArray to track the offset along that third "droped" dimension.
What I propose is that the definition of OffsetArrays be expanded slightly so that
o = OffsetArray(rand(100,100), (1:100, 1:100, 5))
# where 5 is the position along a third axis
becomes valid.
Calling axes(o)
would then return something like
(OffsetArrays.IdOffsetRange(values=1:100, indices=1:100), OffsetArrays.IdOffsetRange(values=1:100, indices=1:100), 5)
But ndims(o)
would remain 2.
In general we would want this to work for more than 3 dimensions with integer offsets occurring at any position, not just at the end.
Apologies if this request is completely out there or out of scope for OffsetArrays, just curious to hear what people think.