[fitswcs] Detector distortion correction representations in FITS

Mark Calabretta Mark.Calabretta at atnf.csiro.au
Sun Jan 30 23:38:29 EST 2000


On Fri 2000/01/28 11:05:10 BST, Richard Hook wrote
in a message to: Mark Calabretta <Mark.Calabretta at atnf.csiro.au>
and copied to: fitswcs at NRAO.EDU, sparks at stsci.edu, clampin at stsci.edu,
      koekemoer at stsci.edu, rfosbury at eso.org, jwalsh at eso.org,
      apasqual at eso.org, rhook at eso.org

>Thanks for the detailed and clear reply to my question of representing
>non-linear distortions modelled in pixel-space in the non-linear options
>of the new FITS world coordinate systems. It is roughly what
>I thought you would say! What you suggest is of course perfectly possible 
>and very simple for the cases I was discussing (HST cameras).  Having 
>said that it does have some obvious disadvantages: Firstly one loses the 
>orientation and scale information in the CD matrix which becomes rather 
>redundant. Having the first-order solution held in the CD+CRPIX+CRVAL set
>of 8 numbers (for a 2d image) has its attractions particularly in a world
>where software may well take some time to catch up with the new standards.
>Secondly one loses the fact that the pixel distortion coefficients may be 
>pretty
>constant for a given camera independently of the telescope pointing - I feel
>it would be nice for them to be constant in the header as well. Finally (and 
>I think this has been discussed by other contributors to the mailing list) 
>you are forced to go with TAN+poly whereas separating the detector related
>"poly" bit from the sky projection would allow poly+SIN and other possibly
>useful combinations (although this is not relevant for HST cameras).

I agree that combining the affine transformation with the polynomial is
less than ideal, particularly for keeping the setup-specific and
instrument-specific effects separate.

However, doesn't this argue against you?  Perhaps I am misunderstanding but
shouldn't you do your solution the other way around?  That is, shouldn't
you first do a six-constant solution (i.e. CRPIX + CD) to account for
translation, rotation and scale (setup-specific effects) then do a
separate polynomial fit for the residual instrument-specific effects?

>Very early in the life of this mailing list, Doug Mink listed very clearly
>several ways in which a non-linear component could be added to a WCS
>description (5th May 1998). I think that the proposal adopted one of these 
>and I am here pointing out the merits of another of them (type 1).

Unfortunately that predates my presence on this list.
 
>I certainly don't think any of my arguments are strong enough to justify
>modifying your proposal which is very impressive and the result of a great 
>deal of work. I am probably taking a rather narrow optical imaging 
>perspective. But I do think they are worth pointing out. I am sure everyone 
>feels that this
>proposal is "nearly there" and it would be great for everyone when it is
>finally formally accepted and can be widely adopted.

It's becoming clear that there are many ways to do a "plate" solution!  I
think it would be a mistake for CCS to try to accomodate every variation
by adding more steps to the algorithm chain.

However, I view the last element of the algorithm chain, the projections
themselves, as "plug-in modules" which serve as a freedom layer where you
can do pretty-well anything you want.  This has a number of advantages:

   a) Additional projections of arbitrary complexity (e.g. splines or
      whatever, up to a limit of 200 parameters) can be added later when
      needed by defining and formally publishing them.

   b) If someone receives a FITS header containing the new "XYZ"
      projection which their software doesn't know about they'll realize
      that it's new and upgrade their software to handle it.

   c) The complexity of astrometric solutions may be confined to a
      particular projection so that Joe Bloggs, radio astronomer, who just
      wants a SIN projection can focus on that and ignore all the
      astrometry stuff packaged up with TAN.

Adding more components to the algorithm chain may have unpleasant
consequences.  For example, consider adding a polynomial before the CD
matrix:

   a) A static definition wouldn't be good enough since this would have to
      be defined once and for all and wouldn't admit the possibility of
      extension later with more terms when someone comes up with an even
      more distorted camera.

   b) A polynomial solution may not be good enough in all cases.  For
      example, adequate description of the Faint Object Camera distortion
      is best done with spline functions rather than polynomials.

   c) Thus the proper way to do it would be by analogy with the projections
      themselves, i.e. define a separate keyword which selects a pre-CD
      distortion algorithm (e.g. polynomial) then define these algorithms
      with their own separate set of parameter keywords.

   d) FITS images may have more than two axes.  For a general WCS your
      polynomial would have to be defined over N axes allowing for all
      cross terms.  For a linear transformation that gives N*N matrix
      elements.  For a general polynomial solution the number blows out
      horribly.

   e) All this astrometry machinery becomes visible to Joe Bloggs,
      radioastronomer, who just doesn't want to know about it.

We've already seen that TAN+poly won't do for the FOC without resorting to
use of the pixel regularization correction.  Therefore it seems inevitable
that new special-purpose, instrument-specific projections will have to be
developed in future.

This also suggests that variations in the method of doing plate solutions
might be handled via special-purpose projections - a pragmatic rather than
an ideal solution since it would be much better if one formulation could
be found for TAN+poly which satisfies most cases.  In your case, for
example, you might define a new projection (with a new keyword) which
looks somewhat like TAN+poly but reserves some additional PVj_ms for a
linear transformation which comes after the polynomial transformation.
Perhaps this is of such general use that we should incorporate it into
TAN+poly itself.  I don't know.  However, I will offer to support such
projections in WCSLIB and also include them in an appendix to CCS provided
that the supporting text and rigorous mathematical description is provided
by publication time.  (This also includes ARC+poly.)

>Your final question - whether there are enough terms in the polynomial - may
>be particularly important for the HST Advanced Camera for Surveys (ACS) which 
>has very large distortion. There is a current, preliminary model of this
>use a cubic polynomial but it is quite likely that something considerably
>more complex may be needed for an adequate representation for high-quality
>geometric distortion correct once the instrument flies, probably early next
>year. Several of the ACS group are copied on this message so they may
>comment.

As above, we'd be unhappy if TAN+poly didn't already have enough terms to
accomodate these systems.  If you could give us a better idea of what's
needed in the short term then we could add more terms if necessary.  It
would probably still be possible to extend TAN+poly after publication of
CCS but this is obviously less desirable.  However, if all else fails you
could define an "ACS" projection of whatever complexity you like.

Regards, Mark





More information about the fitswcs mailing list