also contain other, non-standard metadata pertaining to the image in
the PHDU in the forms of keywords and tables.
A FITS file described with the media type "image/fits" SHOULD be
principally intended to communicate the single data array in the
PHDU. This means that "image/fits" SHOULD NOT be applied to FITS
files containing MEF (multi-exposure-frame) mosaic images. Also,
random groups files MUST be described as "application/fits" and not
as "image/fits".
A FITS file described with the media type "image/fits" is also valid
as a file of media type "application/fits". The choice of
classification depends on the context and intended usage.
Recommendations for application writers:
An application that is intended to handle "image/fits" SHOULD be able
to provide a user with a manifest of all of the HDUs that are present
in the file and with all of the keyword/value pairs from each of the
HDUs. An application writer MAY choose to ignore HDUs beyond the
PHDU, but even in this case the application SHOULD be able to present
the user with the keyword/value pairs from the PHDU.
Note that an application intended to render "image/fits" for viewing
by a user has significantly more responsibility than an application
intended to handle, e.g., "image/tiff" or "image/gif". FITS data
arrays contain elements which typically represent the values of a
physical quantity at some coordinate location. Consequently they
need not contain any pixel rendering information in the form of
transfer functions, and there is no mechanism for color look-up
tables. An application SHOULD provide this functionality, either
statically using a more or less sophisticated algorithm, or
interactively allowing a user various degrees of choice.
Furthermore, the elements in a FITS data array may be integers or
floating-point numbers. The dynamic range of the data array values
may exceed that of the display medium and the eye, and their