To enable astronomers to compare data observed at various sites and in order to continue the processing of data, it is necessary to transport the data to the astronomer’s home site. This interchange of data has been traditionally hampered by the fact that each institute has generated its own computer facilities and unique data format and produced a large quantity of software based on that format (Wells et al., 1981). To counter this problem the FITS format has been developed.
An archival format must be utterly portable and self-describing, on the assumption that, neither the software nor the hardware that wrote the data will be available when the data are read (Dozier et al., 1995). This is the ethos of FITS.
The standard format for optical astronomical data is FITS. The IAU has recommended that all astronomical computer facilities support FITS for the interchange of data. The necessarily precise definition of the FITS format, issued by NOST (1999), runs to almost 100 pages and describes in detail what does and does not constitute FITS. While the FITS working group has only recently retired (1999), the format has been in use for sometime, originating in the 1970s as a data transport system, hence the name. Outlined here is the basic FITS structure necessary to understand the nature of the software written to manipulate FITS files within the PL. The information presented here has been extracted from many sources (see e.g., GSFC, 1997; NOST, 1999; Hanisch et al., 2001; Ponz et al., 1994; Wells et al., 1981), some of which duplicate and contradict each other due to the ongoing nature of the FITS project. The FITS implementation used in the PL is that described by NOST (1999).
Although its name implies image transport, FITS is no longer a graphics format designed
purely for the transfer of pictures; it does not incorporate “FITS viewers”, packages for
decoding the data into an image. Users must develop their own software to read and
display the data from the FITS file. The basic format of a FITS file is a sequence
of Header Data Units (HDUs). The first part of each HDU is the header, which
comprises an integer multiple of 36 card images. Each card image is a simple ASCII
string of 80 bytes or 2880 bytes per card. Each card image starts with a “keyword”
specifically in bytes 1 
8 - the keyword briefly describing the information following it.
Bytes 9 10 must contain “= ”, with bytes 11 30 containing right justified
numerical values or left justified strings beginning and ending with single quotes.
The information can be optionally followed by a comment of ASCII characters.
The final HDU must end with the keyword “END” in the first 3 bytes with bytes
4 80 filled with ASCII characters. The final HDU must also be an integer multiple
of 36 header cards long, space after the END keyword may be filled with ASCII
blanks.The first keywords must be both those given in, and in the same order as
Table 5.1.
|
Print
Email
News!