[fitswcs] WCS Paper III approved

[William Pence]

Announcement of IAU-FWG Approval of the FITS WCS Paper III

I am pleased to announce that the 22 members of the IAU FITS Working Group
have unanimously approved the current draft of the paper "Representations of
spectral coordinates in FITS" by Greisen, Calabretta, Valdes, and Allen.
This is the 3rd in a series of papers on representing world coordinate
systems in FITS files; these papers serve to promote the standardization and
interoperability of FITS data.

The latest version of this paper is available from the lead author's web
site at http://www.aoc.nrao.edu/~egreisen/ or from the astroph service at
http://lanl.arxiv.org/archive/astro-ph (abstract number 0507293).  While the
current version of this paper is considered to be quite mature, it still may
undergo further revisions in response to the recent suggestions from the
IAU-FWG or from the journal editors before it is accepted for publication
and before it is officially incorporated into the rules and recommendations
of the FITS Standard.  In particular, several of the IAU-FWG members have
offered some suggestions for improving the current draft.  All these 
comments or suggestions are appended below to the end of this message.

Bill Pence
Chairman, IAU FITS Working Group


The following comments regarding the WCS Paper III were submitted by the 
IAU-FWG members along with their vote of approval

========================================================================

I believe that this is a well developed standard, applicable to a broad
range of spectroscopy applications.  For me, one of the principal tests of a
standard such as this is whether it can handle the complicated cases without
putting an undue burden on simpler cases, and I think the authors have
achieved that here.

=========================================================================

I have read (or at least tried to read the whole paper) but cannot pretend
to understand more than a small part of it.  What I understand looks
sensible, so I have to trust that the experts who drafted the rest were
indeed experts.  Clearly we need standards for these things, so I'm all in
favour.

==========================================================================

I realise I am reacting rather late, but I find that the multi-dimensional
-TAB does not really belong with the rest of the paper. It is undoubtly
useful, but it has very little to do with spectral coordinates. If it were
a simple  addition I would not worry about that, but by itself it is
responsible for  about half the complexity of the paper which is not
simple. I am still voting yes because I don't want to hold the process
(and out of guilt for not checking earlier ;-)), but I'd really like the
authors to consider splitting this part to a separate paper or moving it
to paper IV, leaving only the simple case of a single axis in paper III.

Very minor detail, but I'd suggest replacing "Snell law's of refraction"
by "The Snell-Descartes law of refraction". I don't quite remember which of
them actually had the legitimate prior claim, but some fraction of the
readership learned the refraction law under Descartes' name and will scratch
their heads on Snell's law

==========================================================================

I read Paper III and, in consideration of the large effort spent (and
competence shown) by the authors, I decided to give a favourable vote,
although I feel the paper is rather specific and difficult (and/or I am
rather incompetent in the matter ! ... which would have called for an
abstention).

I have two general orders of comments (non-technical).

One is that, as said, the paper is quite specific (mainly to technical
details of "optical" spectroscopy) and difficult (also because it aims to
handle general mechanisms), and somehow lacks of two things : one are
COMPLETE examples (I mean e.g. including FULL header examples - but see
what the referee says on this formal aspect). The other thing is that is
not in a prescriptive form, it does not provide a step-by-step recipe to
writing headers ... but possibly this is not a matter for a paper, but
more for a "WCS cookbook" (could this be an idea for the FWG or some
dedicated task force when reviewing manuals and guidebooks ?).


The second order of comments stems in part from the fact I've so far
considered the WCS (or the "2-d WCS" in Paper I and II) as a sort of
"black box" (and paid no attention to what is inside) to describe
"projections" for data where the distinction between raw and reduced data
is blurred, while, on the other hand, pixel-by-piexl re-projection is
complex or not worthwhile.

In this respect I found very useful (and up to my expectations as "user")
to be able to have tools which e.g. get sky coordinates clicking on a
pixel image "simply" writing the proper header kwds and not modifying the
image itself.

For spectra however my expectations where different. I'm inclined to make
a stronger distinction between "raw" data (the IMAGE on the focal plane of
a spectrometer, for the few cases where I had direct experience, limited
essentially to old IUE low dispersion spectra, and to VIMOS multi-object
spectra) and "reduced" data (essentially a - calibrated - spectrum seen as
a TABLE with flux vs energy - or frequency or wavelength).  OK ... the
table could also be a 1-d image, but anyhow I'd expected it to be a
reprojection and rebinning and reprocessing of the raw data.

So I'd expected something quite simpler like essentially a list of
convention on physical units and scales (lin, log, sparse or tabular),
which could be used e.g. to make composite spectra from multiwavelength
observations (from the REDUCED data of such observations).

I see in such respect no reference at all e.g. to high-energy count or
photon spectra  ... even from
the trivial fact that customary "keV" are missing as "preferred" energy
units in Tab. 1.  I noticed you [PENCE] did not make any specific comment
on behalf of the high energy community. Are you (also as HEASARC) thinking
somehow of using things like -TAB to describe X-ray PHA or PI spectra, or
instead want to leave them alone and consider them something "totally
different" ?

Another (partially related) issue I did not see (and I could have
expected), is handling of "error bars" or "large bins" .... think of the
lower and upper channel boundaries in a photon spectrum and the way to
properly convert them from dN/dE to FE, Fnu or Flambda, also using a
spectral model. But the same may apply to any "broad band" spectra (either
rebinned or simply derived from photometric points).

Now I find in paper III something DIFFERENT, which is clearly more
consistent with the "philosophy" of the "image" papers (leave the raw
data intact and provide a way to read world coordinates point-by-point),
and also addresses problematics specific of other frequency domains and
communities (see emphasis on "velocities", "air wavelengths" or "grisms").

None of the above considerations is however such to deny a favourable vote
on the content of Paper III, which is likely to be very valuable for the
communities for which it was intended.

======================================================================

  The solution in chapter 6 for non-linear non-separable coordinates,
  which occur very often in spectroscopy (particularly IR spectroscopes
  which are compact), is very complicated.  A
  "distortion correction" possibly as described in "Paper IV" is highly
  desirable for a workable solution, and should be given a
  high priority.

  The suggested formulae for refractive indices in Chapter 4 are
  inappropriate for IR wavelengths > 2microns, which are in
  common use.

  In another context, it would be desirable to be able to specify the
  "true" wavelength (freq,velocity..) coverage of each pixel, i.e.
  the spread of wavelengths contributing to the flux.
  It is commonly assumed by naive users that this equals the coordinate
  difference with the preceding and following pixels, but this
  is seldom the case.  This is of course equivalent to specifying the
  "resolution" of an image, which is very different from the pixel
  spacing.

======================================================================

I would have added a little section on VO.  But after thinking about it,
it would be probably better to do the VO stuff in a separate paper.

Paper III represents an impressive amount of work. Examples are clear  and
concise.

======================================================================

I think the simpler forms of the -TAB table lookup capability will
be popular.  I would have preferred to see a simpler mechanism than
currently specified - I suspect the advanced indexing capability will be
infrequently used.  The important case of a spectrum stored as a row of
a table, with one cell used as the spectral coordinate vector, appears to
be adequately supported.  Another common and important case is a spectral
data cube where each 2D image is at a different spectral coordinate.
For cubes with a limited number of spectral planes, ideally one would
like to describe the spectral axis entirely within the primary image HDU
(i.e., without requiring a separate table extension), however it did not
appear to me that that was possible.

======================================================================

After pondering the FITS paper on spectral coordinate systems, I will
vote in the affirmative--to accept it as part of the definition of
the FITS standard. I think the problem domain is defined clearly in
the paper, it is dealt with thoroughly, and the solutions in terms
of FITS conventions and techniques are generally elegant and
occasionally quite clever.

I have a few concerns though, which I thought I would pass on. The
first is that this paper is a pretty tough read. While there are a
lot of technical issues to sort through, I fear that a lot of the
academic community--and even many of those who would attempt to
implement the standard in their data systems, will find the paper
nearly impenetrable. I feel that community standards ought to be
both enabling and approachable, but to achieve the latter goal will
almost certainly require a much longer "user" document if we expect
mere mortals to implement the standard correctly. The subject is deep,
but the paper does not do enough in my view to make the problems
simpler to understand for the purpose of explaining the correct
application of the standard.

The second concern relates to section 6.2.3 on the use of -TAB portion
of the convention, as it applies to multiple exposures. I find the
argument for creating a higher-dimensional structure to relate
sequences of 2-D images to be unpersuasive. The analysis of time-
sequence images, or of images in different bandpasses of the same
location, is in my view unlikely to benefit much from the proposed FITS
conventions in this area (e.g., generation of light curves,
multi-wavelength modelling of source SEDs, etc.). The major benefit
identified in the paper is for the case of an image display application,
where a cursor read-out of coordinates would be perhaps more informative.
In my view, the suggested convention would add complexity to the standard
without much benefit. I have a feeling that the relationships between
images in a sequence would be more effectively dealt with in a VO
standard, rather than within FITS.

My third concern is really more of a question. It relates to section 7,
and the definition of the SSYSOBSa keyword & associated values. While
I believe I understand the argument for making plain the velocity
reference frame to which the coordinates apply, I'm not sure I follow
the choice of values for this keyword. By selecting a particular system,
does that mean that a particular magnitude for a velocity correction has
been applied to the data? Wouldn't a change to the convention (such as
the magnitude or direction of CMBDIPOL, as cited in the paper) degrade
the accuracy of the coordinates represented in those FITS files created prior
to said change in convention? Clearly the definition of these conventions
lies outside the control of the FITS standard. If I understand correctly,
it would be unfortunate for a change to a velocity convention to have
the side effect of degrading the validity of all FITS files in existence
at that time, where this portion of the standard is used.  A possible
improvement would be to define yet another keyword that would state
explicitly the numerical values for the reference velocity vector that is
being referenced. That way if the velocity convention is changed, it will be
apparent how to interpret the data files.
[I readily confess that I may not have understood the issue, and that my
comment may not make any sense. If so I apologize.]

-- 
____________________________________________________________________
Dr. William Pence                          William.D.Pence at nasa.gov
NASA/GSFC Code 662         HEASARC         +1-301-286-4599 (voice)
Greenbelt MD 20771                         +1-301-286-1684 (fax)