[fitswcs] Comments on Paper III

[Mark Calabretta]

On Sat 2003/11/22 15:02:45 CDT, Jonathan McDowell wrote
in a message to: fitswcs at donar.cv.nrao.edu

>The current CTYPE-first-four values
>
>FREQ;  ENER;  WAVN; WAVE, AWAV; VRAD, VOPT, ZOPT, BETA, VELO
>
>do not bring out the key fact that WAVE and AWAV are basically the same
>thing but different from FREQ; similarly VRAD, VOPT, VELO are closer to
>each other than they are to FREQ - in the pragmatic sense that
>applications programs are likely to care more often about whether the
>spectrum is WAVE or FREQ than whether it is WAVE or AWAV.

Dear Jonathan,

In terms of non-linearity there are only four types; WAVE and AWAV
differ fundamentally in this respect - the other two are FREQ and
VELO.  These four define equivalence classes (in the algebraic sense)
under the operation of scaling, i.e. FREQ != WAVE != AWAV != VELO and
FREQ = VRAD = ENER = WAVN,   WAVE = VOPT = ZOPT, etc.

Hence radioastronomers, whose instruments produce spectra linear in
FREQ, habitually use VRAD.  Optical spectra are linear in WAVE, so
optical astronomers habitually use VOPT.  VRAD and VOPT differ
fundamentally as seen in Fig. 1.

The coordinate calculation therefore divides naturally into a non-linear
transformation *between* equivalence classes (e.g. WAVE->FREQ) and a
linear transformation *within* an equivalence class (FREQ->ENER).

> Isn't the WAVE
>vs AWAV distinction more like the kind of distinction covered by
>SPECSYS?

No...

> Why have SPECSYS rather than CTYPE keys WTOPO, WBARY, etc...?

...SPECSYS is similar to EQUINOX and RADESYS in Paper II.  CTYPE has two
parts, one part says how to calculate the coordinate value, the other
says how to interpret it (what the coordinate system is).  However, some
coordinate systems are parameterized (e.g. equatorial coords) and need
extra defining parameters such as EQUINOX, RADESYS, SPECSYS, etc.

(I feel that Paper III suffers in this respect in not defining the two
parameters that would allow a proper interpretation of the relativistic
velocity, namely an orientation angle, which would allow the radial and
tangential components of the velocity to be resolved, and a systemic
velocity, which would allow the velocity-induced redshift - e.g. of a
jet - to be resolved from the cosmology-induced redshift - e.g. of its
host galaxy.)

>... well I know why, but I would argue the WAVE/AWAVE distinction should
>be in another keyword, not in CTYPE. (Aside: If Paper 2 provided a way
>to distinguish between RA, DEC positions which have/have not been
>corrected for atmospheric refraction, I'm missing it.)

Paper II did not address topocentric coordinate systems - the closest it
got was GAPPT (geocentric apparent place).  The reason was that too many
additional parameters would have been required to define topocentric
coordinates, and these would have required time, geographic location,
and other concepts that are undefined in FITS.

In short, the WCS papers are all about defining non-linear
transformations and only incidently about defining the terms of
fundamental astronomy.

>I am uncomfortable with the definition of -LOG. The equation S = Sr exp(
>w/Sr ) is indeed pretty, and its expansion to S ~ Sr + w a nice touch,

We think of this as an important element, not just a nice feature.
However, we are aware of the unpleasant consequences in this case.

>but at the cost of being very unnatural to astronomers. Can you adduce
>any examples of astronomical data in which the coordinate systems are
>described using natural logarithms? 

No, but if astronomers are still content to deal with magnitudes
(5 mag = x100) then base-e logs shouldn't present a problem!

>I suggest there is a subtle conceptual difference between an axis with
>logarithmic steps and a world coordinate of frequency, and an axis with
>linear steps (in log frequency) in which the world coordinate is the
>log of the frequency (which latter tends to be the mindset in spectral
>energy distribution work).
>
>In non-spectral cases with logarithmic axes, too, I believe
>that most astronomers would prefer to interpret CDELTn
>as the base 10 logarithmic step:
>  S = Sr . 10 ** w
>Then looking at the value of CDELT in the header would
>immediately make sense to the user, I feel. 
>For example, compare
>  CTYPE1='FLUX-LOG'
>  CRVAL1=    5500.0
>  CUNIT1=     'Jy'
>  CRPIX1=       0.0
>  CDELT1=      -0.4   /  Logarithmic step
>with
>  CDELT1=  -5065.7    /  -0.4 ln 10 * CRVAL1
>
>The first case is instantly recognizable to optical astronomers
>as meaning the pixel axis is in magnitudes. The second
>case is obscure. I think that losing the 'derivative is one
>at the ref point' is a legitimate concern of elegance, but
>should be trumped by user-friendliness.

We really don't claim to be overjoyed with this either!  I will simply
make the observation that you can coerce CDELT1 = -0.4 in your example
by adjusting CRPIX1 so that CRVAL1 = log10(e).  The header becomes

  CTYPE1='FLUX-LOG'
  CRVAL1= 0.4342945   / log10(e)
  CUNIT1=     'Jy'
  CRPIX1=  10.25644
  CDELT1=      -0.4   / Logarithmic step

After all, what is so special about CRPIX1 and CRVAL1 in your example?
(Note that you get exactly the same answer, i.e. CRVAL1 = log10(e), if
you look at S = Sr 10^w and ask what value of Sr should be chosen to
give S ~ Sr + w; the two forms are identical for that value of CRVAL1.)

Another way to look at it is that CRVAL1/CDELT1 is the e-folding length
in pixels.

However, I don't claim this is very elegant.  Maybe someone has a better
idea?  (Some of the projections in Paper II do not have the S ~ Sr + w
property so there is a precedent to drop it.)

>I like the idea of the TAB transform. However I wonder if
>this fundamental addition to FITS should be in yet a
>separate paper.

It should have been in Paper I but unfortunately came too late to be
included.  RGB/CMYK/HSV conventional coordinates would have been another
nice addition to Paper I.

>Why the horizontal (1 row, array column) arrangement? For the simple
>case (separable 1D axes) a vertical (many rows, scalar column)
>arrangement seems much more natural and allows many existing calibration
>lookup files to be used without change. You could then go to a 1D array
>per cell for the 2D case, and so on, perhaps not as elegant then for the
>higher dimensional cases - but these are rare!

Probably just allowing the column form as an alternative for a 1-D array
would be better.  And maybe just in ASCII tables.

>I understand that some concern was expressed that a vertically
>arranged table might be mis-sorted by the user. I think that's only
>a greater danger for vertical than horizontal tables because
>more software currently exists to deal with them, and implementation
>of the proposed convention will change that.

Sorting the contents of an array is generally not a good idea!  Paper III
explicitly states that the indexing and coordinate arrays must not be
sorted, and with good reason.

>I find the use of PS.. and PV... keywords to be obscure. I think for
>this usage more explicit keywords like say CTBEXTn, CTBCOLn, CTBIDXn
>or something of the kind would be easier to deal with. I guess PS and PV
>are proposed as general WCS parameters, but -TAB is a pretty special case.

There are already four keywords that should have been encoded as PVi_ma
but were treated specially (LONPOLEa, LATPOLEa, RESTWAVa, RESTFRQa;
these are the only ones that define parameters that enter into the
transformation equations, others such as RADESYSa and SPECSYSa qualify
parameterized coordinate systems).  WCS header parsers must recognize
every one of these keywords so the fewer the better.

Also, the 8-character restriction on keyword names would require
severely abbreviated forms of CTBEXTn, CTBCOLn, CTBIDXn for use in
binary tables.

Thanks for the comments, the other co-authors will probably also want
to reply.

Mark Calabretta
ATNF