FITS HEADER INHERITANCE CONVENTION Nelson Zarate, NOAO Perry Greenfield, STScI April 2007 INTRODUCTION There are many instances of FITS data files where the same set of keywords (e.g. 'TELESCOP' or 'INSTRUME') are duplicated with the same value in every extension of a multi-extension FITS file. It would be desirable in such cases to write the keyword only once, and have it be shared by every extension in the file. One (usually minor) benefit would be to reduce the size of the file, but more importantly, this would avoid duplicating information in the file. This can cause problems with, for example, dynamic updates, where every instance of the keyword would need to checked for consistency. The INHERIT keyword convention was developed to address these issues by allowing the extensions in a FITS file to implicitly inherit the keywords in the primary header; this prevents needless repetition of keywords in each extension header and provides a mechanism for software to easily access keywords that are shared between different extensions. In principle, the convention allows one to build software that requires the user to ask only once for the value of a specific keyword for a given extension (rather than explicitly doing two keyword lookups, one for the extension and one for the primary header). By using this convention software can treat the primary and extension headers as effectively one logical header. This convention was developed in 1995 and is extensively used in FITS files produced at the STScI for data sets from the the later genration of instruments on the Hubble Space Telescope, including STIS, NICMOS, and ACS. Software support for this convention has been built into the IRAF FITS Image kernel (Zarate & Greenfield 1996). This convention continues to be used in various data sets produced by NOAO. It is also used by various instruments and data pipelines operated by, or partly by, the United Kingdom, such as INT/WFC, UKIRT/WFCAM and ESO/VISTA/VIRCAM. IMPLEMENTATION DETAILS The INHERIT keyword in an extension header shall have a logical value of T or F to indicate whether or not the current extension should inherit the keywords in the primary header of the FITS file. The INHERIT keyword shall be defined in the extension header immediately after the mandatory keywords. This Inherit Convention should only be used in FITS files that have a null primary array (e.g., with NAXIS = 0) to avoid possible confusion if array-specific keywords (e.g., BSCALE and BZERO) were to be inherited. If INHERIT=F in an extension header, the keywords from the primary header should not be inherited. When an application that supports this convention reads an extension header with INHERIT = T, it should merge the keywords in the current extension with the primary header keywords. The exact merging mechanism is left up to the application, but, for example, all the extension keywords could be copied into a structure in memory, and then the keywords from the primary array could be appended to it. The value of the INHERIT keyword should be set to F after the keywords have been merged. The mandatory primary array keywords (e.g., BITPIX, NAXIS, and NAXISn) and any COMMENT, HISTORY, and blank keywords in the primary header are never inherited. If the same keyword is present in both the primary header and the extension header, the value in the extension header shall take precedence. If an application modifies the value of an inherited keyword in an extension, the value of that keyword in the primary header is not affected (i.e., the application must explicitly change the value of the primary header keyword if that is desired). PRACTICAL CONSIDERATIONS One disadvantage to using this convention is that it may be hard to preserve the separation of the primary and extension header keywords in software. For example, simply copying an extension to a new file could cause the primary and extension keywords to be merged, thus effectively negating the benefits of this convention unless the software takes special care to disable the automatic inheritance and propagates the primary header and extension header separately. Thus, the convenience of not requiring two keyword lookups has been transferred to an inconvenience of trying to preserve the separation in the face of automatic merging of the two. Another practical issue is that in applications where the bytes in the FITS file are interpreted serially (e.g., on tape or Internet downloads), the reader would need to cache the primary header in case it turns out that a later extension in the file uses the INHERIT convention. Another drawback is that users may become confused when adding or modifying keywords to files with this convention. If the keywords have become inadvertently duplicated (i.e., are present in both the primary and extension headers) and the user modifies the primary keyword, they are surprised that no change in the keyword value has taken place (because the extension value takes precedence). Users may also become confused if they use a mixture of software tools, some of which show the inherited keywords in the extension header and others that do not support this convention. Potential future users of this convention should carefully consider whether the benefits outweigh the disadvantages in their particular situation. REFERENCES Zarate, N & Greenfield, P 1996, "A FITS Image Extension Kernel for IRAF" Astronomy Data Analysis Software and Systems V, ASP Conference Series, Vol. 101