[fitswcs] Status of WCS negotiations

[Mark Calabretta]

On Mon 1998/07/20 14:10:15 -0400, Don Wells wrote
in a message to: Mark Calabretta <Mark.Calabretta at atnf.csiro.au>
and copied to: fitswcs at fits.cv.nrao.edu

> >    3) CDELTn allows for easy change of units/scale.
>
>Yes, but changing scale for CDij is no big deal

True if you only allow one representation (i.e. no secondary axis
descriptions), but if you want to have secondary descriptions then it does
become a big deal.  You would have to reproduce the whole of the CD matrix
even for trivial things like changing the scale on just one axis.

My main gripe is with replicating the transformation matrix.  This also raises
the question of what constitutes a secondary description, that is, what do you
have to provide in the header for the second description?  Are you going to
have to reproduce the pixel regularization table/polynomial, the CD matrix,
the CRPIXn, CRVALn, and CTYPEn, and the projection parameters?  Or do you say
that if there's only one pixel table and one CD matrix then they apply to the
second as well as the first set of projection parameters?  What if you want to
have three representations, with one matrix applying to the first two sets of
projection parameters and the second (numbered as third?) applying to the
third set?

Adopting CD in preference to PC to me means dropping secondary axis
descriptions.

> >    4) Old FITS files look like new ones with a default PC matrix.
> >    5) New FITS files without a PC matrix look just like old ones.
>
>This is true for files that follow the Classic-AIPS notation, but
>isn't true for those that follow the IRAF/SDAS notation. By now, in
>1998, there are vast quantities of data in astronomy archives with
>both WCS notations.  Therefore, as Chair of IAU-FWG, I expect to have
>difficulty in getting the whole FITS community to accept this argument.

They may use CDij but do they recognize multiple versions of it?  They do
already have to recognize CDELTn for compatibility with old FITS files and
getting them also to recognize PC would be a trivial on-the-fly operation for
their FITS readers.

>Furthermore, the water has been muddied by the argument (primarily
>advanced by Pat Wallace I think) that the CDELTi are defined in a
>subtly different manner in G&C from the definition used in older WCS
>implementations, and that therefore the keyword names should be
>changed. Whether or not this argument is technically valid, it also
>makes it difficult for me to form a consensus of the FITS community.

My refutation of this argument (from previous email) is appended.  Technically
invalid arguments shouldn't be accepted by scientists.

>I recommend that we agree to limit axes requirements for WCS to 99.
>Real implementations are certainly entitled to limit themselves to
>much smaller dimensionality, like 9 (Eric Greisen told me that the
>worst case he has thought of has NAXIS=7).

And what limit on the number of representations?

>There are several existing astronomy data processing packages (IRAF,
>SDAS) which have used CDij notation in production for many years now;
>they write CDij into their headers currently and could easily support
>alternative keyword names for a compatible CDij concept. So, looking
>at the situation from their viewpoint, adopting CDELTi+PCij would
>introduce a complexity where it's not needed.

The translation of CDELTn+PC to/from CD is a trivial on-the-fly operation
which can be handled by the FITS readers/writers.  Indeed, WCSLIB uses CDij
internally, but that is not the point.  The real point of contention is
support for multiple CD matrices.  Do existing astronomy data processing
packages support multiple CDij?

>As I noted in another posting, an image pixel represents both a point
>on the sphere (celestial coordinates) and a point in an instrumental
>coordinate system (linear coordinates). This statement is true in a
>wide variety of detector systems.

This is a truism for G&C, it is fundamental to its formalism.


Cheers, Mark

>>>

The CDELTn differ only in having a more general interpretation.

Looking at the AIPS convention, firstly, if CROTAn = 0 then you can impute a
unity PC matrix (dimensionless) and say retrospectively that the CDELTn apply
to the product of the (unit) PC matrix and the pixel vector since it doesn't
make any difference.  Hence CDELTn trivially have the same meaning.

If CROTAn != 0 and CDELTi = CDELTj then the CDELT matrix is a scalar multiple
of the unit matrix so the order of matrix multiplication doesn't matter.
Hence CDELTn have the same meaning.

If CROTAn != 0 and CDELTi != CDELTj then G&C eqn 132 shows how to convert the
CROTA/CDELTn system into CDELTn/PC.  The CDELTn in this translated system have
the same values and *do not* have different meanings, they both describe
scaling in the un-CROTA'd or un-PC'd systems.  This is self-evident if you
think about it, after all the CDELTn do have the same values, including units,
apply to the same image and produce the same answers.  The confusion arises
because the PC matrix doesn't describe a rotated system, but a rotated, skewed
system.  If you look at the equation

   X = CDELT * PC * I

where PC is as given by G&C 132, and ask what lines in the (i,j) plane are
transformed into the x-, and y-axes the answer is

   y-axis:  i*CDELTi*cos(CROTAj) - j*CDELTj*sin(CROTAj) = 0
   x-axis:  i*CDELTi*sin(CROTAj) + j*CDELTj*cos(CROTAj) = 0

This is the system you get if you scale i by CDELTi, j by CDELTj and rotate by
CROTAj (which of course it must).

The point is that the CDELTn in G&C have a more general interpretation as a
consequence of the generality of the PC matrix.  In the above example, the
CDELTn scale the unrotated axes but if the PC matrix was a pure rotation then
the CDELTn would scale the rotated axes.  The new interpretation of the CDELTn
therefore is as determined by the human FITS writer who defines the WCS
algorithm chain so that FITS interpreters can mechanistically plug in pixel
coordinates and get out world coordinates and vice versa.