Subject: Re: FITS header cards

From: [email-masked] (William Thompson)
Date: 26 Jan 94 22:17:52 GMT

> In article <[email-masked]>, [email-masked]
(Ron Watkins) wrote...

> >I was wondering if there is support for using CRVAL and CRDELT within
> >FITS tables? We have a data format that im looking into formatting into
> >a FITS table. Each record (of our data) contains various values and an
> >array. The values are of differing formats but the array is fixed at 126
> >single precision values representing counts at some wavelength. I had
> >wanted to use CRPIX, CRVAL, and CRDELT to specify the wavelengths for the
> >array but it doesn't apply to any of the other values in the table row other
> >than the array. Is there FITS support for doing this? I can only find
> >references for CRVAL and such in the primary HDU of the FITS files. I couldn't
> >find it for the FITS extensions. 

and then Barry Schlesinger wrote

> The above does not specify whether an ASCII table or a binary table is
> intended.  The proposed structure appears to fit most naturally in an
> extension of type BINTABLE, where the array could appear as a single
> field.  There has been some talk, particularly within the single dish
> community, of conventions for use of the terms CRVALn, CRPIXn and
> CDELTn to describe an array contained in one field of a binary table. 
> Perhaps one of the people involved could step forward and say where
> this discussion stands. 

Being one of those people, I am now stepping forward.

(Sorry this took a while.  You might have heard about the ice storm that
paralyzed the D.C. area last week, and I've been busy catching up this week.)

There have been a couple of proposals as to how to handle axis metadata.  My
own proposal is to define a set of keywords related to the table columns that
are related to CRPIX, CRVAL, etc., but which have a format ala TDIM.  These
keywords are as follows:

		  Additional Keyword	  Standard Equivalent

			TDESCn			CTYPEm
			TROTAn			CROTAm
			TRPIXn			CRPIXm
			TRVALn			CRVALm
			TDELTn			CDELTm

To illustrate how this would work, suppose that one had a two-dimensional
array, with dimensions representing energy and time, stored in a column of a
FITS binary table.  First of all, we would have the following standard
keywords:

	TTYPE2  = 'RATE    '		/Observed flux count rate
	TFORM2  = '80E     '		/Array has 80 data values, type Real*4
	TUNIT2  = 'counts/s'		/Units of the RATE values
	TDIM2   = '(8,10)  '		/Array is two-dimensional

In my system, the annotation for the individual dimensions are modelled
after the form of TDIM, and would appear in the FITS binary table header
this way:

	TDESC2  = '(ENERGY,TIME)'	/Dimension labels
	TRPIX2  = '(1.0,1.0)'		/Index of reference pixel
	TRVAL2  = '(2.5,0.0)'		/Axis values at reference pixel
	TDELT2  = '(0.1,4.0)'		/Pixel spacings along each axis

However, in the time since I proposed this, the High Energy Astrophysics group
at Goddard (HEASARC) has come up with an alternate plan to do the same thing.
In the HEASARC system, the same information would appear as follows:

	1CTYP2  = 'ENERGY  '		/Dimension labels
	2CTYP2  = 'TIME    '
	1CRPX2  =                  1.0	/Index of reference pixel
	2CRPX2  =                  1.0
	1CRVL2  =                  2.5	/Axis values at reference pixel
	2CRVL2  =                  0.0
	1_1CD2  =                  0.1	/Pixel spacings along each axis
	2_2CD2  =                  4.0

In other words, each keyword begins with the dimension number, and ends with
the column number.  The "CD" keywords really represent the elements of a
coordinate transformation matrix--in this case one that only transforms the
scale.  This is something that comes out of the World Coordinate System, which
is something fairly new in FITS.  In addition, the HEASARC proposal includes
the ability to express what the axis units are, e.g.:

	1CUNI2  = 'keV    '		/Axis units
	2CUNI2  = 's      '

The HEASARC people were aware of my proposal, but were concerned that the
length of the strings would be too long.  Also, they preferred that a single
FITS keyword point to a single value, rather than an array of values.

The downside of the HEASARC approach is that it takes more space than mine.

You should be able to get more information about the HEASARC approach from
William Pence ([email-masked]).

Hope this is of help,

Bill Thompson