Implicit Images in FITS?

Rob Seaman seaman at noao.edu
Tue May 27 17:51:07 EDT 1997


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





More information about the fitsbits mailing list