Subject: FITS bintable for LUTs

From: alberto at cfa0 (Alberto Accomazzi)
Date: Wed, 15 Sep 1993 17:50:09 GMT

I am rewriting some software that converts X-window dumps into
FITS format and decided to make it adhere more strictly to
the FITS standard.

I would like to be able to store the color lookup tables
(or, to use the X jargon, the installed colormap) at the
end of the FITS data as a binary extension table.
The main data in the FITS file is the image pixmap from the
window dump.

The colormap would consist of 3 (RGB) byte arrays containing
256 elements each.  This is how I thought the extension header
would look like:

XTENSION= 'BINTABLE'
BITPIX  =                    8
NAXIS   =                    2
NAXIS1  =                  256
NAXIS2  =                    3
PCOUNT  =                    0
GCOUNT  =                    1
TFIELDS =                    1
TFORM1  = '256B    '
TDISP1  = 'B4.1    '
EXTNAME = 'LUTS    '          / Color lookup tables
END

Does anybody have comments/suggestions about this?
In particular, I'm trying to decide what the best
EXTNAME for this kind of data should be.

I'd like to incorporate a check for extension tables
containing these LUTS in some of my utility programs
(such as pnmtofits and fitstopnm), and it would be 
nice if we could agree on some EXTNAME keyword value 
that should be looked for by display/conversion programs.  
I looked at the NOST 100-1.0 document but could not
find anything about EXTNAME values.

- Alberto

--
==========
Alberto Accomazzi              Harvard-Smithsonian Center for Astrophysics
alberto at cfa.harvard.edu        60 Garden Street, MS 39
(617) 495-7076                 Cambridge, MA  02138  USA

---

From: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Thu, 16 Sep 93 12:17:57 EDT

>EXTNAME = 'LUTS    '          / Color lookup tables

What about the TTYPE1 keyword?  It is good practice to always provide
a name for each column (e.g. TTYPE1 = 'LUT     ') and then have the software
locate the desired column by it name, rather than assuming a particular
location for the column.  This decouples the software somewhat from the internal
structure of the table. 

If this is to be a general format for storing LUTS, you might also consider
putting each LUT color into a separate column; with your proposed scheme
it is not clear which color is in which row of the table.  Also,
putting the colors into separate columns makes it easy to store
multiple LUTS in different rows of the table.  In this case it would
also be useful to provide a 'NAME' column to identify which LUT is
which.  So the table would end up with 4 columns something like this:

XTENSION= 'BINTABLE'
BITPIX  =                    8
NAXIS   =                    2
NAXIS1  =                  784
NAXIS2  =                    1
PCOUNT  =                    0
GCOUNT  =                    4
TFIELDS =                    1
TTYPE1  = 'LUT_NAME'
TFORM1  = '16A     '
TTYPE2  = 'R_LUT   '
TFORM2  = '256B    '
TDISP2  = 'B4.1    '
TTYPE3  = 'G_LUT   '
TFORM3  = '256B    '
TDISP3  = 'B4.1    '
TTYPE4  = 'B_LUT   '
TFORM4  = '256B    '
TDISP4  = 'B4.1    '
EXTNAME = 'LUTS    '          / Color map lookup tables
END

The order of the columns should not be considered significant and could vary
from table to table.

Using EXTNAME = 'LUTS    ' seems like the obvious choice.  For the FITS files
we produce here at the HEASARC, we are in addition providing a HDUCLASn keyword
to provide a more detailed hierarchical description of the content of the
FITS extension or primary array.  This is probably not really needed here,
but in principle this could be used to further describe the type of LUT it is:

HDUCLAS1= 'LUT     '          / This is a color map look-up-table
HDUCLAS2= 'GREYSCALE'         / this is a grey-scale LUT (as opposed to pseudo color)
HDUCLAS3= 'LINEAR  '          / this is a linear ramp LUT

I'm not really suggesting you use the HDUCLAS2 and higher keywords, but this 
illustrates the concept.

-Bill Pence
pence at tetra.gsfc.nasa.gov