[fitswcs] Status of WCS negotiations

[Mark Calabretta]

On Tue 1998/07/28 17:36:33 +0100, Patrick Wallace wrote
in a message to: fitswcs at fits.cv.nrao.edu

>On July 20th, Don Wells mentioned my having drawn attention to an
>apparent change in the meaning of the established CDELTn keyword.  I've
>known Don long enough to be confident that "the water has been muddied"
>was not meant to sound pejorative.  But Mark Calabretta's response
>(July 21st), "Technically invalid arguments shouldn't be accepted by
>scientists" is harder to ignore!

Don Wells wrote

   "Furthermore, the water has been muddied by the argument [...]  Whether or
    not this argument is technically valid, it also makes it difficult for me
    to form a consensus of the FITS community."

and I replied

   "Technically invalid arguments shouldn't be accepted by scientists."

This is a reflection on Don's suggestion that the FITS community might be
swayed by a technically invalid argument.  It's not meant to be a reference to
you, and certainly not meant to be pejorative to anyone!

>Drafts of Greisen & Calabretta c1993 used the CD matrix, albeit with a
>different subscript naming convention.  No CDELTs were required, because
>the scaling was defined by the CD matrix.  Sometime between 1993 and the
>1996 draft, the CD matrix was dropped.  The PC matrix had appeared in its
>place, and the CDELTs had returned...except the order in which they were
>applied had changed, giving this result:

More email archaeology: the draft was presented as a poster paper at the
Jun/1993 ADASS at Berkeley where Doug Tody persuaded Eric that the CDELTn
should be preserved so that (a) multiple representations could be implemented
without duplicating the matrix and (b) the matrix would have dimensionless
elements.  Eric did this almost immediately except that he left the matrix as
"CD", later changing to "PC" to avoid confusion with existing usage.

The first public announcement of G&C had occurred only a few months earlier on
Feb/4.  It stressed that it was a draft and called for comments.  The CDELTn
reappeared in the 1993/Aug draft, the first after ADASS, and Eric took pains
to draw attention to the change.

>My suspicions were strengthened when, as a check that I'd implemented the
>new design properly, I gave Bill Pence one of my sample headers and asked
>him to tell me the (RA,Dec) of the corner pixels.  Because his software
>supported the existing de facto methods rather than the new G+C proposals,
>he needed a CROTA2 angle, and so he used the obvious interpretation of the
>PC matrix to derive one.  He then used this CROTA2 estimate in conjunction
>with the CDELT1 and CDELT2 values that I had supplied, and duly got wrong
>answers.

WCSLIB has been provided to implement G&C.  What more can we do?

>for my money a bit kludgey.  But the important case that Mark has not
>dealt with is where (a) the pixels aren't square, (b) the rotation isn't
>zero, and (c) you want to write a new-style FITS file *that can be
>correctly interpreted by existing readers*.  In the next section, I'll
>give an example of this sort and demonstrate that the G+C precepts lead
>to incorrect results for an image generated in an obvious and legal way.

(See later.)

>But first, at the risk of labouring the point, let me prove that CDELTn
>has changed in meaning by writing down the two definitions.
>
>  AIPS convention:
>
>    CDELT1 is the distance on the sky between the centres of two
>    pixels whose detector coordinates differ by (1,0).  CDELT2
>    is the same for two pixels whose detector coordinates differ
>    by (0,1).

In the non-linear projective geometries in any convention the CDELTn can only
be interpreted as partial derivatives at the reference point.

>  G+C proposal:
>
>    CDELT1 is the distance on the sky between the centres of two
>    points whose "true plane pixel coordinates" differ by (1,0).
>    CDELT2 is the same for two points whose a "true plane pixel
>    coordinates" differ by (0,1).

The CDELTn in G&C have a more general interpretation.  My argument showed that
in translating the old way into the new the CDELTn do have the same meaning
(this may become clearer later in discussing your example).  This is only the
translation, if you were writing a new file from scratch you probably wouldn't
want to do it this way.

>arithmetic easier.)  The obvious way to generate the PC matrix (and I
>assume our FITS-writing program is entitled to do this, because G+C
>doesn't say otherwise) is as follows:

I don't want to defend writing CROTAn alongside PC to help old readers because
I disagree with it.  However, if you read section 5 closely it says

   "To assist older FITS-reading programs, however, these modern FITS writing
    programs should also write CROTAj for latitude axis j when the longitude/
    latitude pair fits Eq. 132."

Your PC matrix does not fit Eq. 132.  If you did make it fit you'd get a valid
CROTA2 and also end up with CDELT1 = 0.0001 and CDELT2 = 0.0002.  QED.

However, if old readers really are your concern in this very simple example,
I'd eschew the new machinery altogher and just write CDELTn and CROTAn, forget
the PC.  Old readers and systems understand the old, and new readers also have
to understand the old to fulfil the maxim "once FITS always FITS"; they use
Eq. 132 to help them (maybe WCSLIB should have an auxiliary routine to
implement this).

In a more complicated example, for example where the matrix may have some
skew, old readers and systems have no hope.  In such a case it would be quite
reasonable to make the PC serve as a CD by setting CDELT1 = CDELT2 = 1 (deg)
and setting the PC elements in the obvious way.

>Now we turn to Section 5 of G+C, where we are asked to help old FITS
>readers by writing a CROTA2 value (I know from private correspondence
>that Mark is against this, but that's what the present draft recommends
>we do).  Equation 133 shows us how to do this:
>
>   CROTA2 = (arg(0,1)+arg(0,1))/2 = 90 deg

Also, you overlooked the factor/divisor of S = CDELT2/CDELT1 in the equations
for rho_1 and rho_2 leading to Eq. 133.  If you had included this you would
have noticed rho_1 != rho_2 and realized something was amiss given that
section 5 prescribes rho_1 = rho_2 for the computation of CROTA2 (the
averaging in Eq. 133 simply being to reduce rounding error).

Your example, although flawed, does reinforce my view that CROTA2 shouldn't
be written alongside the PC matrix because it forces it into an awkward form,
like a toupee on a toucan.

The term "true plane pixel coordinates" may better be replaced with the non-
commital "transformed pixel coordinates" to show that they have no formal
definition (except for PLON/PLAT described before).

I agree that the draft needs to be revised with these and also a number of
other important enhancements which have been brewing for over a year - plan
C++.  Only Eric knows when (and if) this will happen.


Cheers, Mark