[fitswcs] NAXIS vs. WCSDIM

[Doug Tody]

On Tue, 25 Sep 2001, Doug Mink wrote:
> I have been dealing with WCS's independent of images, Doug Tody's case I,
> for quite some time.  Sometimes I need to fit a WCS to a set of pixel values
> in a separate file and create an output file which can be used for pixel to
> sky and sky to pixel conversions.  Since no image is really necessary, I have
> included in my WCSTools package a progam to create a header-only FITS file,
> with NAXIS=w and BITPIX=0.  This works as well as having a separate keyword,
> but it requires software that doesn't crash on a heretofore illegal BITPIX
> value.

It is good to hear that someone else is doing this too.  However, adding
a new WCS keyword to solve the above problem is preferable to changing
fundamental FITS keywords such as NAXIS and BITPIX.
 
> As for cases with NAXISn=1, I don't see any big problem, though I would prefer
> that the degenerate axes be defined after the real ones.  Most of my image
> software, because it is tested against radio data as well as optical/IR,
> looks for the first two axes with NAXISn > 1, and uses those axis for 2-D WCS
> determination.  Because so much radio data exists with degenerate axes and one
> of the purposes of the WCS standard is to be able to match radio and optical
> images, any general purpose WCS software will have to be able to deal with
> this data no matter what is decided, so I need to see stronger reasons for
> creating a new keyword.  In the dimensionally reduced case, it seems to me
> that leaving NAXIScut=1 is the best way to note the change; if the WCS depends
> on all three axes, you need all of the CRVAL's to compute the WCS for a given
> pixel.

It is true that general-purpose imaging software, if it is to be used for
multiwavelength studies, will have to deal with degenerate axes since so
much of this data already exists (and degenerate axes are always possible).
However the issue here is not whether you or I can deal with this problem
in our software.  Entire branches of astronomy and potentially thousands
of programs are affected if we start routinely writing FITS images with
degenerate axes throughout all of astronomy.  Much of this software does
not have to be capable of handling data from all branches of astronomy,
e.g., radio data.

I would also say that trying to make all programs deal with degenerate
axes would be a step backward: the concept of a simple 1D or 2D image
simplifies many programs and is well worth preserving.  Many programs deal
only with the pixel matrix and do not use the WCS at all.  WCS is already
complex, and indeed is still being defined, and we can easily deal with
the problem of higher dimensional WCS within the WCS framework.

If we can solve this problem rigorously for WCS interchange without
causing such problems with something as fundamental as NAXIS why even
consider it?  The radio convention is still permitted if we decouple the
WCS and image matrix: it is a special case which is supported (for the
WCS at least) without having to do anything extra.