[fitswcs] Status of WCS negotiations

[Mark Calabretta]

On Mon 1998/07/20 11:21:15 -0400, Don Wells wrote
in a message to: fitswcs at fits.cv.nrao.edu

>I recommend that the TAN projection be augmented with radial terms

Sure, but won't you also need a plate solution projection which allows for
non-radial terms (such as DSS which includes pincushion and barrel
distortion). 

>information). These terms are exactly equivalent to CDij keywords of
>higher order, which we could agree to define. My current opinion is
>that this would be a bad idea, but Doug Mink may want to argue in

Optical astrometry/spectroscopy would probably be the most demanding WCS
application so it's not surprising that it may need sophisticated machinery
which is never going to be used elsewhere in astronomy.  I would argue that
the extra complexity required should be quarantined as far as possible from
those who don't need it, so extending the CDij in this way would not be a good
solution.  Anyway, it's virtually ruled out on practical grounds by the
requirement for inverse coordinate transformations.

>I recommend that we define a pixel correction matrix/function rather
>than adding terms to CDij or to PROJk. Originally, four or five years
>ago, I argued for a functional form. Doug Tody convinced me that we
>might agree on a correction matrix more easily. This dialog between
>Doug and me led to the appendix-A "Pixel Regularization Image"
>proposal in the existing G&C draft. Later we realized that we need to

The history as determined by the archeology of my WCS email folder:
circa 1993/Feb, Pat Wallace proposed a table to transform pixel coordinates
all the way to celestial coordinates.  I gather that at about the same time,
apparently independently, you proposed a table just for tweaking pixel
coordinates.  Pat advised me of this a month after his original email and of
his agreement.  Nothing further happened until I wrote Appendix A in 1995/Aug
using interpolation methods supplied by Pat.  He also proof-read it.  Eric
changed the initial implementation as a table extension to an image extension
shortly afterwards.

>use a simple polynomial pixel correction function with origin at
>CRPIXi, and with the convention that the correction is zero at
>CRPIXi. Probably we should add the additional convention that the
>first order terms should be nearly zero (i.e., their information
>should be carried by CDij).

I agree that the main thing about this correction, whether implemented as a
table or polynomial (I personally don't care which though not forgetting that
it must easily support subimaging), is that it should only provide a residual
correction.  Appendix A currently states that the correction may be ignored
with consequent introduction of a small error.  So as you suggest, it should
not be used for bulk corrections such as could be applied by the linear
transformation.  However, I go further and say that it should not be used for
corrections that can be applied via a pre-defined projection type.

You didn't say anything about allowing multiple correction tables.  The
introduction of multiplicity is where we begin to disagree.  I would say that
we should have one pixel correction table, one linear transformation and
multiple projections on the grounds of parsimony since it is enough to do the
job.  Do optical people want multiple correction tables to go with multiple CD
matrices and multiple projections?

>I contend that a functional form which perturbs the pixel coordinates
>before the CDij/CRVALi transformation to standard coordinates is
>mathematically equivalent to the higher-order terms of the plate
>constant solutions of traditional astrometry.

Certainly, for plate solutions.  However, I say it shouldn't be used for this.
Use a plate solution projection instead - your generalized TAN, DSS, or define
something better.

>represent the primary geometric properties of the long slit. However,
>real slits are not straight, real telescopes often have corrector
>optics before the spectrograph slit and real spectrograph cameras have
>distortions. These facts imply that there is work for a pixel
>correction function to do. I hope that we can agree on a correction
>function notation which not only supports the direct imaging case, but
>also supports the long-slit case.

Agreed, this is a good example of where you'd need to use this machinery.


Cheers, Mark