[fitsbits] which WCS keywords?

[Mark Calabretta]

On Wed 2005/09/14 15:14:21 -0400, Phil Hodge wrote
in a message to: fitsbits at donar.cv.nrao.edu

>Because of the large data volume, most of the data will be discarded; 
>pixel values in a small region around each of the 170,000 or so targets 
>will be returned from the spacecraft to Earth.  The (proposed) FITS data 
>format is a BINTABLE extension for each chip, with two columns; one 
>column has the raw pixel values and the other column has the calibrated 
>pixel values.  It will not be possible to tell from the data file alone 
>where a given table element is on the CCD; to avoid redundancy the pixel 
>numbers are given in a separate reference table which is identified by a 
>header keyword.

In splitting the files I assume that you will associate each row of one
with the corresponding row of the other?  Why not just have a bintable
with four columns: the two pixel coords, and the raw and calibrated
pixel values (and maybe other columns as well)?  This is in keeping
with the model established in Sect. 3.2 of Paper I.

>If the pixel numbers were in the data file, this would 
>be case (c), a tabulated list of pixels.  The keywords for case (c) 
>cannot be used for the Kepler data format,
>however, because the keywords include the column numbers of the pixel 
>coordinates, and those columns don't exist.  

The pixlist WCS keywords must be associated with the pixel coordinate
values, even if they're in a separate file, not with the pixel
brightness values.  Specifically the "n" in keywords like TCTYPn refers
to the column containing the pixel coordinate value, p_j.

>It seems to me that case 
>(b) is reasonably close, even though the element at a given row and 
>column is only a single value (1-D array of length 1).  The value in 
>each row really is an image, albeit a very small one!  The keywords for 
>case (b) include a column number, which in this case would be 1 for the 
>raw data and 2 for the calibrated data.

You would need to add four columns to record iCRVLn for both the raw
(1CRVL1, 2CRVL1) and calibrated values (1CRVL2, 2CRVL2) - the other
bintable WCS keywords, being constant, could be stored in the header
via the Greenbank convention.  But in fact you'd be better off just
storing the ra and dec in separate columns, i.e. no WCS at all.
 
>My question is whether I would be stretching the limits of the FITS 
>standard to use the WCS keywords for a "multidimensional array in a 
>BINTABLE column" for Kepler data.

One-element arrays are within the limits of the formalism, it's just
that it doen't make much sense to use them.  What you have is a clear-
cut case of a pixel-list.

Mark Calabretta
ATNF