Future World Coordinate System requirements

Data Management
,
4

This will probably be the first of several thoughts on this, as I’m sure I’ll forget some things now. And some may be design opinions that I’ve not yet realized aren’t actually requirements, so feel free to push back if it sounds like I’m being unreasonable.

  • I think our WCS system does need to include pixel distortion effects, but only those that are frozen into the chip for at least the duration of an exposure (i.e. not brighter-fatter). I expect these to be our only real exotic transformations; everything else we need is likely to just be a polynomial, spline, or some sort of standard trigonometric projection. Well, some variety of fancy full-sky pixelization is a possibility as well.

  • The transforms we use to define mappings between coordinate systems on the camera must be the same kind of transforms we use when mapping images to the sky, or be so interoperable that there’s no overhead in using them together.

  • Compositions of transformations must be possible, and should only simplify mathematically when this can be done exactly (well, up to machine precision). Fast approximations to composed transformations should also be available, and should provide some guarantees as to their accuracy.

  • I think we will at least sometimes want a transform class that knows its coordinate system endpoints (either by owning an object that describes that coordinate system, or maybe just a string or enum label), along with some way to guarantee that a chain of composed transforms is valid given those coordinate system labels. I don’t think this is necessary for all transform class use cases, and if it’s heavyweight, we may also want versions of the transforms that don’t have these labels.

  • I think we want to distinguish between spherical coordinate systems and Cartesian coordinate systems, at least so we can use the appropriate (spherical vs. Cartesian) geometry types as inputs and outputs.

  • I do not think our WCS system needs to be aware of color or wavelength. We’ll have to consider chromatic effects in the PSF, but if we define our PSFs with an offset centroid, I’m quite convinced we won’t also need a chromatic WCS, and I think that’s a huge win for simplicity.

  • The interface for transforms must provide a way to invert them, but I think it’s acceptable if some specific transforms are not invertible (if we don’t have a use case for the particular inverse transform). It could also be very useful to allow a pair of one-way transforms determined empirically to be inverses to be combined into a single bidirectional transform.

  • We need to be able to efficiently obtain the exact transform at a given point (in either input or output coordinates), mostly to support warping. I can’t imagine doing this efficiently enough (especially in a multithreaded context) while going through any layers of Python, even if there’s a C++ front-end over them. However, this requirement may only apply to certain frequently-used transforms, so having some pure-Python transform implementations for other use cases may be fine.

  • We need to be able to efficiently obtain a local linear approximation to the transform at a given point (in either input or output coordinates). This will almost certainly need to be done in a multithreaded context, so I’m also skeptical of having Python-implemented transforms here, but it’s not out of the question.

  • We need to be able to persist WCS objects as components of other arbitrary objects (not just Exposure, but certainly Psf, and probably some other things too).

  • We need to be able to persist groups of related composed transforms efficiently (e.g. WCSs of the same CCD on different visits, which share the same pixel distortion field), which I think means persisting (and unpersisting) heavyweight shared components only once. I think we also need to be able to persist non-WCS objects that hold some shared WCS components in a similar manner (by saving at least some heavyweight WCS components only once, and having only one in-memory representation).

  • Some transform objects need to expose some sort of parametrization, and provide the ability to compute at least first derivatives with respect to those parameters at a given set of points. I actually don’t think this is the same transform class we want to use everywhere else, but we want them to be closely related and highly interoperable.