3.3 Extensions

  The data to be transported do not always fit conveniently into an array format. Also, auxiliary information associated with an image or data set may need to be saved in the same file, but may not fit into the array structure. To handle such cases, the concept of FITS extensions has been introduced (Grosbøl et al. 1988). Extensions have the same overall organization as Basic FITS: a header consisting of keyword = value ASCII card images followed by data. As in Basic FITS, the header and data each consists of an integral number of 23040-bit records. Except for the SIMPLE keyword, which is replaced by an XTENSION keyword, the header must use the keywords required for the Basic FITS primary header (section 3.1.1.1). As in Basic FITS, the data start in the first record following the last header record. However, as the data structure need not be a simple array, there are additional required and reserved keywords for particular structures.

The developers of the extension concept realized that a set of rules was needed to prevent conflicts between a new extension and Basic FITS, random groups, or an existing extension. The rules that were developed are called the Generalized Extensions Agreement. An extension that conforms to these rules is called a conforming extension. An extension that has been endorsed by the IAU FITS Working Group or other appropriate authority is called a standard extension. All standard extensions are conforming extensions. The detailed structure of a conforming extension does not need approval by any authority, but the type name must be unique and registered with the IAUFWG. A file whose extensions all conform to the rules for generalized extensions is in FITS conformance, even if the extensions are not standard extensions, and the SIMPLE keyword of the primary header should have the value T.

Two basic rules govern all existing extensions and serve as the foundation for the more detailed requirements for generalized extensions:

• All FITS extensions must appear after the main FITS header and its associated primary data array.
• Each extension begins at the start of a new 2880-byte record.

The generalized requirements for FITS extensions are as follows:

• Extensions should have the same structure as the Basic FITS HDU: header plus data. The extension should be self-defining and the header readable both by people and machines. The rules that apply to creating FITS headers also apply to extension headers; they should contain a required set of standard keywords and consist of ASCII text card images. While the information in an extension may be of any length, the extension as a whole must be filled to an integral number of 23040-bit records.
• Only the binary and character coding conventions specified in the original FITS papers and the Floating Point Agreement should be used in FITS extensions.
• It should be possible to append any number of extensions to a primary header and its associated data array.
• If there is more than one type of extension in a FITS file, then the extensions may appear in any order.
• Existing FITS formatted data, including those with standard extensions, must be compatible with the new extension standard. FITS files that contain combinations of new and standard extensions must be allowed in order to facilitate the transition to a new design.
• The presence of a new extension in a FITS file should not affect the operation of a program that does not know about the new type of extension.
• Any program scanning a FITS file, on any medium, should be able to locate the beginning of any extension and find the start of the next one. This rule implies that the extension header must specify in a consistent and standardized manner the total number of data bits that are associated with it.
• It must be possible to devise new types of extensions without prior approval. Keywords in the primary FITS header may not be used to announce the existence of a particular type of extension because such keywords would need to be approved by the IAUFWG.
• Anyone wishing to create a new extension format is free to do so. Creators of new extensions should check the list of extension type names registered with the IAUFWG, which is maintained on-line by the FITS Support Office, and register a new type name for their format.
• No information in either the primary header or the extension header should specify the physical block sizes of FITS blocks on tape or any other medium (but see the discussion of section 3.1.1.2 about the BLOCKED keyword).

The detailed rules for FITS extensions implement these requirements. Keyword syntax for extension headers is governed by the same rules as for primary headers. The standards concerning data types and bit order for the main FITS data records also apply to extensions.

The Generalized Extensions Agreement requires the use of a single additional keyword in the main header only:

EXTEND (logical) if true (T) indicates that there may be extensions that conform to the generalized extension standards following the data records. Its absence guarantees that there are no extensions, but its presence does not guarantee that extensions are present. Because extensions are not required following a primary header with EXTEND = T, the primary HDU alone can be copied unchanged. A value of F has no meaning and should not be used. The EXTEND keyword must immediately follow the last NAXISn keyword or an NAXIS keyword with a value of zero. FITS data in a file may consist entirely of extensions, with no primary data. In such cases, the primary header must still be present, with EXTEND = T and NAXIS = 0 to indicate no primary data array. Examples 3 and 6 in Appendix A illustrate FITS primary headers with no data that occur at the start of files where all the data are in extensions.