Subject: A question on keywords for 3-D images

From: bob at ipac.caltech.edu
Date: Thu, 29 Oct 1998 14:30:46 -0800

Hello,

The SIRTF project is designing the format of its output products.  One
of the products, for example, may contain 32-planes of 2-D data, all
with the same geometry.  This would normally be a straightforward
problem, just use a 3-D image, but there is a hitch ...

There is a set of at least 100 header keywords that have different
values for each of the 2-D planes.

There are a number of workable solutions to this and we could just
pick one and go with it.  However, a standard solution would be
preferable since it would be better understood and it could be used
directly in existing software.

Here are two of the options being considered:

 1) Append plane number to keywords

   Use a 3-D image and append the plane number to the keyword names,
   such as SIGMA01, SIGMA02, SIGMA03.  Is there any *STANDARD* way to
   do this (especially one that existing software uses) ?  Also, each
   plane may want to have its own BSCALE and BZERO. Is it possible to
   specify these values for the individual planes?

 2) Use FITS image extension

   Each extension would contain a 2D image and its own set of
   keywords.  Going to this form loses the 3-D nature of the data with
   each 2-D image looking like an independent image rather than being
   part of a 3-D cube.  Also, there is a concern is that many FITS
   readers and standard software may not be able to deal with files in
   this form.  It may not be supported well in IRAF, CFITSIO, etc. for
   3-D operations.

Thanks for any help,
 Bob Narron

---

From: Tom McGlynn <tam at silk.gsfc.nasa.gov>
Date: Thu, 29 Oct 1998 18:51:47 -0500

This sounds like an application for a binary table but
it's not clear whether it should have 32 rows or 32 columns.

If you use the 32 row approach, then each row would have
a field for the 2-D array and additional fields for your
variable 'keyword' information.  You could describe the
geometry of the images using a single set of of keywords.
E.g., you'd have something like
...
    NAXIS2 = 32   / Not trying to make the syntax here perfect!
...
    TTYPE1 = 'DATA '
    TTYPE2 = 'PARAM1'
    TTYPE3 = 'PARAM2'
...
    TFORM1 = '10000F'
    TDIM1  = '(100,100)'  / For a 100x100 image
    TFORM2 = 'F'          / If the parameter is a real...
...
in the header.

If you use the 32 column approach, then the table would only
have a single row with each field being one of your images.
You'd have the advantage of have separate scaling keywords
to scale each image, but at least in principle you'd need
to include geometry keywords for each of the fields.
You'd use field keywords encoding the 'keyword'
information.  This approach may be especially attractive if
the type of the information may be different for some of the
32 planes, e.g., perhaps some planes are binary masks, some
integers and some reals.   

Some fragments of the header might be like:
...
   TFIELDS = 32
...
   TTYPE1  = 'DATA_PLANE1'
   TTYPE2  = 'DATA_PLANE2'
...
   TFORM1  = '10000F'
   TDISP1  = '(100,100)'
   TFORM2  = '10000I'
   TDISP2  = '(100,100)'
...
   PONE1   = 'Value for first param for plane 1'
   PONE2   = 'Value for first param for plane 2'
   PTWO1   = 'Value for second param for plane 1'
...

Either of these formats is reasonably standard, so I wouldn't
anticipate problems with any but the simplest FITS readers.

		Regards,
		Tom McGlynn

---

From: Arnold Rots <arots at head-cfa.harvard.edu>
Date: Fri, 30 Oct 1998 09:20:32 -0500 (EST)

I tend to agree with Tom McGlynn's first solution: make a binary table
with 32 rows.  One column will contain the 2-D arrays in its fields,
the other columns the variable parameters.

The geometry of the 2-D images can be specified through the iCTYPnnn,
etc., keywords.  I would suggest solving the BSCALE/BZERO problem by
storing the data as floats (E, not F) or doubles (D).

If the 2-D images are really big, and you need the parameters for
browsing, you may want to consider putting the image data into the
heap - that should be transparent to most FITS readers.

This format is similar to what we plan to use for the AXAF PSF files:
columns for parameters like energy and off-axis coordinates, and one
column with the data.  The data column contains vectors holding either
a 1-D radial PSFs or 2-D PSF images.  Depending on the size of those
vectors, they may be physically included in the body of the table or
located in the heap.

Hope this helps,

  - Arnold Rots

>    this form.  It may not be supported well in IRAF, CFITSIO, etc. for

--------------------------------------------------------------------------
Arnold H. Rots                                         AXAF Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 81                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head-cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------