Subject: Implicit Images in FITS?

From: Wayne Landsman <landsman at mpb.gsfc.nasa.gov>
Date: Mon, 26 May 1997 21:27:08 -0400

Is anyone aware of any proposals to allow "implicit images" in FITS? 
For example, to store an image of constant intensity, one could specify
the size of the image and the constant value in the header.   This
information is sufficient to reconstruct the image, so that the explicit
data portion of the FITS file need not be specified.

--Wayne Landsman                           landsman at mpb.gsfc.nasa.gov

---

From: bushouse at chac.stsci.edu (Howard A. Bushouse)
Date: 27 May 1997 12:42:13 GMT

In article <338A4AC7.1FF70E8 at astro.umd.edu>, Peter Teuben <teuben at astro.umd.edu> writes:
|> Wayne Landsman wrote:
|> > 
|> > Is anyone aware of any proposals to allow "implicit images" in FITS?
|> > For example, to store an image of constant intensity, one could specify
|> > the size of the image and the constant value in the header.   This
|> > information is sufficient to reconstruct the image, so that the explicit
|> > data portion of the FITS file need not be specified.
|> > 
|> > --Wayne Landsman                           landsman at mpb.gsfc.nasa.gov
|> 
|> 
|> No, but I have a hard time cooking up such a proposal. Once the
|> BITPIX, NAXIS, NAXIS1, NAXIS2 etc. have been set to define the
|> image, it expects data....So an alternate IAXIS, IAXIS1, .... would
|> have to be defined.
|> The next thing this proposal would want to do it to allow the
|> image be an analytical expression. Another example of something
|> that can easily run over an 80-character card length.
|> 
|> - peter

Wayne and Peter,

The STScI recently adopted (as an internal convention only) such a
scheme, but have not proposed it as a supported mode. The convention
sets BITPIX to whatever is required for the implicit image, but NAXIS=0
because there is no actual image data. We then use the additional keywords
NPIX1, NPIX2 to define the size of the implicit image, and the keyword
PIXVALE to set its' (constant) value. Our data I/O interfaces are in turn
setup to recognize such an implicit image and when reading one, automatically
constructs the image portion to return to a calling program.

-Howard

---

From: seaman at noao.edu (Rob Seaman)
Date: 27 May 1997 21:51:07 GMT

Note that an "implicit image" is just a special case of the broader
issue of image compression.  While a method for representing a function
as an image is undoubtedly useful for certain purposes, we should
really attend to the larger problem.

This is also a variation of the question of how to support non-FITS
data structures within FITS.  FITS provides a particular model for
representing data, and it may not be obvious how to map an outside
data structure (especially non-array data) onto FITS objects.

It is not obvious (to me, anyway) that conveying such a functional
surface as an image is the best possible choice.  This just transfers
the burden from other I/O interfaces (e.g., IRAF parameter settings or
database files) for inputting and representing such a function.

An image representation does allow including the function with the data,
but at the cost of a non-standard FITS object.  Special tools will have
to used to create and edit the functions, rather than just editing a
parameter or a text file.  This also introduces the reverse problem of
how to represent these project specific FITS files as other image formats
(IRAF .imh images, whatever), since these other image formats won't
support these facilities.

As Peter points out, the fundamental FITS naxisN keywords can't be used
in a simple FITS file to define the extent of the implicit image (the
allowed domain of the function).  Allowing such FITS objects to closely
resemble real images would otherwise be among the strongest arguments
for supporting them.

Note that it would be possible for a FITS extension, however, to use
the naxisN keywords as normal, since PCOUNT could be provided with an
offsetting negative value, i.e.:

    PCOUNT = - (NAXIS1 x NAXIS2 x ... x NAXISm)

where NAXIS = m.  A negative PCOUNT is legal - does anybody know of
another example of negative values?

Such objects would likely be best represented as simple FITS tables.
This provides the same functionality of:

1) associating an extension header specifically with the FITS object

2) acting as a place holder extension - albeit of a different type
   (for error arrays or what have you that might only be generated
   later in the reduction pipeline)

but also supports:

3) an easy way to extract the information into a data object to be used
   with an alternate non-FITS image format - just copy the table into a
   separate FITS (or IRAF, or text, or whatever format) table

Rob Seaman
-- 
seaman at noao.edu, http://iraf.noao.edu/~seaman
NOAO, 950 N Cherry Ave, Tucson AZ 85719, 520-318-8248
PGP: 98 8D 8B 49 74 9A 41 88  3A 43 87 54 51 BF 30 4B