\documentstyle[12pt,guide]{book} 
% 
\author{ } 

\officename{NASA/GSFC Astrophysics Data Facility} 

\shorttitle{User's Guide $\cdot$ Version 4.0} 

\title{A User's Guide for the Flexible Image Transport System (FITS)} 

%
\versionnumber{Version 4.0} 

\date{April 14, 1997} 

\printingnumber{}

\printingdate{} 

%
\publisher{ NASA/GSFC Astrophysics Data Facility\\      
          Code 631 \\
            NASA Goddard Space Flight Center \\  
          Greenbelt MD 20771 \\
            USA}


%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%% % 


\begin{document} 
\maketitle 
\begin{titlepage}
\vspace*{7.6cm}
\vfill
\end{titlepage}
\raggedright 
\parskip\baselineskip 

\chapter*{Preface} 
\addcontentsline{toc}{chapter}{Preface}\markboth{}{} 

Since version 3.1 of 
{\em A User's Guide for the Flexible Image Transport System (FITS)\/}
was published, there have been several significant developments in the
FITS community:                                                          

\begin{itemize}

\item The International Astronomical Union FITS Working Group (IAUFWG)
has endorsed the image ({\tt IMAGE}) and binary table ({\tt BINTABLE})
extensions and the agreement on physical blocking.  

\item The proposal for treatment of world coordinate systems has been
expanded and refined.

\item A number of conventions that are not part of the formal FITS rules
have come into wide use.

\item A significant body of FITS resources has become available on the
World Wide Web.

\end{itemize}          

This new version of the {\em User's Guide\/} has been written to
reflect those changes.  The discussion of the image extension and
the rules for the binary table extension have been moved from
section \ref{s:AdvFITS} (Advanced FITS) to section \ref{s:FITSfund}
(FITS Fundamentals).  The papers describing the image and binary
table extensions have now been published in the {\em Astronomy and
Astrophysics Supplement Series\/} and are now considered to be among the
fundamental FITS papers.  Section \ref{s:wcs} on World Coordinates has
been updated to include the refinements incorporated in
the current proposals, and it also discusses in greater detail how
widely the different proposed conventions are used in the
general community.  The discussion of the three proposed binary table
conventions, which are not part of the formal structure endorsed by the
IAUFWG, remains in section \ref{s:AdvFITS}.  The discussion of
applications of binary tables has been significantly expanded, and
descriptions of a number of binary table and other conventions have
been added.  Section \ref{s:res} has been rewritten to emphasize network
sources of FITS information, and it discusses a number of sites on the
World Wide Web that contain FITS documents, software, and sample files. 
Many of these sites did not exist when version 3.1 of the 
{\em User's Guide\/} was written, and others have been greatly expanded
since.  Three additional sample FITS headers, one using an ASCII table
and two using binary tables, have been added to Appendix \ref{s:ex}. 
Appendix \ref{s:IEEEfp} lists the IEEE floating point number type
corresponding to every bit pattern.
                                                         
Thanks for comments on an earlier draft of version 4 go to 
M.~Calabretta, D.~Jennings, W.~Pence, and R.~Thompson.  Also, thanks to 
D.~Leisawitz for providing the DIRBE FITS header (example 6) and 
W.~Pence for providing the ASCA FITS header (example 7). 
To be of most use to readers, a guide such as this one must go beyond
the formal rules to discuss common practices that are not specified by
those rules. In addition, users who are designing and developing
FITS files need to know how FITS is likely to develop.  Developing
a formal standard for FITS has clarified a number of points that had
been unclear or ambiguous in the original FITS papers.  Some of the
issues were regarded as not appropriate for a formal standard but
deserving of further detailed discussion; at the recommendation of
the Technical Panel developing the NASA/Science Office of Standards
and Technology (NOST) standard, they are included in this {\em
Guide\/}. Queries to the FITS Support Office and discussion on the
FITS network newsgroup {\tt sci.astro.fits} and the associated {\tt
fitsbits} electronic mail exploder have identified other points in
need of explanation.                           
                                                   
This {\em Guide\/} also describes a number of conventions that are
widely used but have not been formally adopted by the FITS governing
structure under the IAUFWG. Description in this 
{\em Guide\/} of such conventions is intended neither as a NASA
endorsement nor as a requirement for use of these conventions
by NASA projects.  Where an issue is controversial, this 
{\em Guide\/} attempts to provide the arguments on all sides.

FITS is continually expanding: new conventions are proposed,
existing proposals are modified, new issues are raised; and the FITS
committees act.  Some of this progress will occur during the period
this Guide is being proofed and undergoing physical composition. 
Thus, some of these developments may, unfortunately, not make
it into the current {\em User's Guide\/}.    
To keep up with current events, use the resources
described in Section \ref{s:res}.  Similarly, Web sites may be
reorganized and the URLs corresponding to an individual page may
change.  In that case, the new location can generally be found 
by going to the main page for the site and following appropriate
links.

As always, comments about the {\em Guide}, in particular about areas
that need clarification or expansion, are encouraged. Send questions
or comments to 

\begin{tabular}{ll}FITS Support Office\\
Astrophysics Data Facility\\
Code 631\\ 
Goddard Space Flight Center\\ 
Greenbelt MD 20771\\
USA \\ 
\\
Telephone: +1-301-286-2899\\ 
\\ 
Electronic Mail: fits@nssdca.gsfc.nasa.gov\\ 
\end{tabular} 

\parskip=0in \tableofcontents \listoftables \parskip\baselineskip 

% 

%

\chapter{The Origin and Purpose of FITS}

\startguide

\section{The Need for FITS} 
In the late 1970s, the Westerbork Synthesis Radio Telescope (WSRT) in
Westerbork, Holland and the Very Large Array (VLA) in New Mexico
began producing high quality images of the radio sky. Since the two
groups were observing at different frequencies, they wished to
collaborate in constructing spectral index maps by combining data
obtained from the two instruments. It was clear from the outset that this
process would not be trivial. Two different institutions would normally
structure their data in different ways. Machines at the two different
installations might have different architecture, using a different
internal representation for the same number. Lacking a standard format
for transporting images, an astronomer taking data from an observatory
to a home institution would have to create special software to convert
the data to the format used at the home institution. Such software
would restructure the data to the format of the home institution and
perform whatever bit manipulations were necessary to convert numbers
from the representation in the originating machine to that for the
destination machine. 

While radio astronomers were making great strides towards producing
analog images of their normally digital data, optical astronomers were
making great strides toward producing high quality digital data through
the use of charge coupled devices (CCDs). Here too, transport of data
in one wavelength domain for comparison with data in another
wavelength domain was required. Because each installation had its own
internal storage format, new software was needed whenever two
installations exchanged data for the first time.
 
An obvious substitute for all these cumbersome processes was the
creation of a single standard interchange format for transporting
digital images among cooperating institutions. Then, each institution
would need only two software packages:~one to translate the transfer
format to the internal format used by the institution, and one to
transform the internal format to the transfer format. The Flexible
Image Transport System (FITS) was created to provide such a transfer
format.

From its initial applications---exchange of radio astronomy images
between Westerbork and the VLA and exchange of optical image data among
Kitt Peak, the VLA and Westerbork---the use of FITS has expanded to
include the entire spectrum of astronomical data.  It is being used for
a variety of data structures from past, current and future
NASA-supported projects, for example, X-ray data from the Einstein High
Energy Astrophysics Observatory (HEAO-2), the Compton Gamma Ray
Observatory, and the R\"{o}ntgen Satellite (ROSAT) where NASA is
cooperating with Germany and the United Kingdom; ultraviolet and visible
from the International Ultraviolet Explorer (IUE) and the Hubble Space
Telescope; and infrared data from the Infrared Astronomical Satellite
(IRAS) and the Cosmic Background Explorer (COBE)\@.  It is also the
standard for ground-based radio and optical observations, in use by such
organizations as the National Radio Astronomy Observatory (NRAO), 
National Optical Astronomy Observatories (NOAO), and the European
Southern Observatory (ESO).
                                    
\section{What FITS Is}
The fundamental unit of FITS is the FITS file, which is composed of a
sequence of Header Data Units (HDUs), optionally followed by a set of
special records.  (The rather prosaic name {\em HDU\/} was the result of
over a year's community discussion and failure to find anything better.)
The first part of each HDU is the header, composed of ASCII card images
containing keyword=value statements that describe the size, format,
and structure of the data that follow.  It may contain any information
about the data set that its creator regards as important, such as
information about the history of the data or the file, about the physical
entity the data describe, or about the instrument used to gather the data.
The data follow, structured as the header specifies.  The size of logical 
records in both header and data is 23040 bits, equivalent to 2880 8-bit
bytes or 36 header card images. The HDUs may be followed by special
records; the only restrictions on these special records are that they
have the standard 23040-bit logical record size and that they not begin
with the string  {\tt XTENSION}\@.  A FITS file is terminated by a
logical end of file, whose precise physical nature will depend on the
medium.
                
In its original form, a FITS file consisted solely of a single HDU,
consisting of the header and a data array that was regarded as
containing a digital image. This simple, one-HDU structure is known as
Basic FITS\@. The header card images would describe the data array---the
number and length of the axes and the data type of the values: unsigned
one-byte, signed two-byte or four-byte integers. The original use of
FITS to transport digital images is reflected in the ``Image'' in its
name.  However, even the data matrix of Basic FITS could be used to
transmit any kind of multidimensional array, not simply an image. The
first HDU of a FITS file, called the primary HDU, must still follow the
Basic FITS format, although it need not contain any data.            
                                               
FITS is no longer restricted to integer arrays.The array data may be
Institute of Electrical and Electronics Engineers (IEEE) 32-bit or
64-bit floating point.  The Basic FITS primary HDU may be followed other
HDUs, called extensions, containing different data structures. Standard
data formats include two kinds of tables: tables with ASCII entries and
tables with binary entries, as well a multidimensional array extension
format that allows extensions to contain the same type of data that is
in the primary HDU\@.  It is also possible to create non-standard
formats, for use locally or as prototype designs for new standard
formats.                              

Although its name implies ``image'' transport, FITS is not a graphics
format designed simply for the transfer of pictures;it does not
incorporate ``FITS viewers'', packages for decoding the data into an
image.  Users must develop or obtain separate software to read and
display the data from the FITS file. Because of its wide use, FITS is
supported by all the major astronomical imaging packages, and a number
of other packages of FITS utilities and software are publicly available. 
The data structure is an essential part of the format and is available
to the users.  This property distinguishes FITS from many other data
standards---those that are primarily labeling systems, and those for
which the user accesses a hidden data structure through a set of
standard tools. 
                              
                                                    
\section{The Philosophy of FITS}

FITS incorporates a philosophy along with the data format. The
underlying goal is to provide a standardized, simple, and extensible
means to transport data between computers or image processing
systems. Any FITS reader should be able to cope with any FITS
formatted file,  skipping over portions (extensions) and ignoring
keywords that the reader does not and need not understand. 

Simplicity requires that reading and writing FITS should be
implemented in a fairly straightforward way on any computer used for
astronomical reduction and analysis. Simplicity also implies that the
structure of the file should be self-defining and, to a large degree,
self-documenting. 

The first word in FITS is ``flexible''.  The format needs to be flexible to
facilitate extensibility for different applications.  Hence, the number of
strict rules is not large.  Because the files are self-defining, FITS can
fulfill a large range of data transport needs. FITS can be used not only
for unambiguous transportation of $n$-dimensional, regularly-spaced
data arrays, but also for additional information associated with such a
matrix.  FITS can also transport arbitrary amounts of text within
standard data files. The ``history'' of manipulations of the data can thus
easily be recorded in self-documenting data files. FITS is sufficiently
general for a wide variety of applications. The introduction of new
keywords permits addition of new information as needed, and the use
of extensions allows almost unlimited flexibility in the type of
information to be stored. Thus, FITS can grow with the needs of the
astronomical community.  

The great flexibility of FITS is a potential weakness as well as a strength.
While there is a great temptation to proliferate keywords and new
extension types, caution should be exercised in this process. Because
FITS is a worldwide medium of data exchange, extension
formats need to be coordinated under the International Astronomical Union
FITS Working Group (IAUFWG) to prevent duplication and inconsistencies in
usage, and agreements should be reached governing keyword conventions in
particular fields.  The structure under the IAUFWG provides an overall
authority for the FITS standard, but additions to FITS are not created by
the IAUFWG but are designed by FITS users and then acted upon by the
international structure.  Although the number of strict rules is not large,
there is an extensive set of recommended practices. Creators of FITS files
should adhere to these recommendations if at all possible; in particular,
the rules of FITS should not be exploited to create files that try to mimic
the local format, and, although in technical compliance with
the rules, depart from the recommendations to such an extent that they
don't look like FITS files.  General adherence to recommended
practice will simplify the task of the FITS software developers; if a
FITS file contains too many unconventional but permitted constructs,
many FITS readers may not be able to handle it.  Not everything that is
permitted is wise.                                            
                                           
Users who develop extensive libraries of FITS files need 
assurance that they will not have to periodically revise these 
files because of changes in the standard. This requirement gives rise to
one of the fundamental principles of FITS: no change in the rules should
render old FITS files unreadable or out of conformance---the principle
of ``once FITS, always FITS\@.'' This philosophy is reflected in data
reduction and analysis packages in which all obsolete implementations
are trapped and processed in the most accurate manner possible. While
adherence to this principle has perpetuated some constructs that have
proven with time to be awkward, it is better than the alternative of
requiring revision of existing FITS files. 

Changes in the FITS rules may add new structures that old software
cannot handle.  Revised software will be required for new standard
extensions, but revising a software package is a far smaller effort than
updating a full data library would be. As far as is possible, however,
FITS should be expanded in such a way that the old software will still
be able to process those parts of the file which it is capable of
handling. In such a case, software should not fail or give incorrect
results when confronted with the new extension or conventions; it should
simply ignore them and continue to process those parts of the file that
it can understand.               
                                                          
FITS is defined as a logical structure, not tied to the properties of
any particular medium, thus allowing its continued use as the
technology changes.  Conventions for its adaptation to any medium
are independent of the logical structure of FITS\@. Because its original
development was for 1/2-inch magnetic tape, its structure is well
adapted to that medium and the conventions are long established.
More recently, more generalized conventions have been adopted for the
expression of FITS on magnetic tape and on magnetic and optical disk. 
Conventions can be defined for new media as they develop.
                 
\chapter{ History}

\section{The First Agreement}
In November~1976, R.~Harten of the Netherlands Foundation for Radio
Astronomy (NFRA) and D.~Wells of the Kitt Peak National Observatory
(KPNO), now part of NOAO, began work on a solution to the problem of
exchanging data between observatories. In the spring of~1977, Harten
and Wells each built prototype data interchange programs, and they
exchanged tapes.  During 1977 and 1978, J.~Dickel (University of
Illinois) carried radio and optical imagery encoded in the two formats
between Westerbork and Kitt Peak.  

In January~1979, during the National Science Foundation (NSF) Image
Analysis meeting at KPNO, the exchange format problem was discussed.
P.~Boyce (NSF), the chair of the meeting, urged NOAO and NRAO to
come up with a solution and assigned a task force of R. Burns~(NRAO),
E. Groth~(Princeton), and Wells to begin the process.  Burns organized
a meeting at the VLA of this task force and the VLA programmers.  On
direction from the initial session of the meeting, E.~Greisen~(NRAO)
and Wells retired to the VLA conference room in the cafeteria building
and worked together to produce the Basic FITS Agreement in 36~hours
on March 27/28,~1979. It incorporated the lessons learned from the
Harten and Wells prototypes. One key issue during the development
process was the choice of a logical record size that would be both
convenient for all machines in use at the time and would at the same
time be close to filling a physical block on magnetic tape.  The
adopted 23040-bit logical record was an integral multiple of the
word sizes of all machines then in use and was close to the
30240-bit physical block size limit of the CDC 6000/7000 series
tapes.  One data structure was supported: an unsigned 8-bit, signed
16-bit, or signed 32-bit integer array with 0--999 axes.  However,
to permit future growth, additional records were permitted to follow
the data array, as long as the logical record size was the
23040-bit standard, a provision that served as the basis for the
later development of extensions.
                                                          
In May~1979, NOAO and NRAO exchanged FITS tapes, thereby showing that
the rules of the Basic Agreement would operate in practice. The first
FITS tape was written by a PL/I program executing on an IBM-360 under
OS/MVT (32-bits twos complement and EBCDIC) and was successfully read by
a FORTRAN program executing on a CDC-6400 under SCOPE (60-bits ones
complement and Display Code), very nearly the worst possible combination
of environments for interchange.  This insistence on testing the format
before it was presented set a precedent for future development: a
practical demonstration of transfer using a proposed FITS structure is
still required before it can be approved. 
             
On June~8,~1979, Basic FITS was presented at an International Image
Processing Workshop in Trieste, Italy (Wells and Greisen~1979). Harten
endorsed it, it won immediate acceptance; and within one year FITS
became the worldwide {\em de facto\/} standard in astronomy.  Wells,
Greisen, and Harten~(1981; hereafter FITS Paper I) published the
description. 

\section{Random Groups}
While FITS began as a means of transporting simple digitized images
from machine to machine, it was soon realized that FITS could provide
a framework for transporting other types of data. The first new FITS
structure, designed by Greisen and Harten during late~1979 --
early~1980 (Greisen and Harten 1981; hereafter FITS Paper II), was
composed of a set of ``random groups'', each consisting of a sequence
of parameters followed by a small array of data.  The number and
meaning of the parameters and the dimensions of the array would be the
same for all groups.  In some of the early literature, this structure is
described as an ``extension'', but such terminology is now inappropriate,
as the name ``extension'' refers to the structure described in
sections~\ref{s:genext} and \ref{s:exts}. 
The principal application of this format was to radio astronomical
aperture synthesis visibility data.  These data consist of small
groups of arrays that occur in a relatively random manner on one or
more axes.  

Random groups has failed to attain wide use in other areas and is now
being replaced even for aperture synthesis data by binary tables. Future
use is discouraged.

At the 1982 General Assembly, the IAU endorsed FITS, including the
Random Groups format, as the recommended format for transport of
binary data (IAU~1983). 
            
                  
\section{Generalized Extensions}
\label{s:genext}

The special records provision of the original FITS design made it
possible to extend the format.  There were two principal reasons for
wanting to extend FITS beyond the simple header/array structure: 

\begin{itemize}

\item to transfer new types of data structures while
adhering to the basic rules of FITS. 

\item to transfer collections of related data structures, thereby
creating a simple hierarchical data base capability. 

\end{itemize}

For example, the table extensions have allowed  tables, lists, etc.,
associated with a data matrix to be written in the same FITS file as
the data matrix, implicitly establishing the relationship among the
different pieces of information.  
                                            
The method chosen was to define ``extensions'', HDUs, which, like the
primary HDU, are composed of a header consisting of card images in
ASCII text with keyword=value syntax, followed by data.  There could be
many kinds of extensions, each with a different defined data format. 
Structuring extensions in this way made it easy to modify software that
read the FITS header for the primary array to read extension headers as
well. Information about the extension data would appear in the extension
header in a way specified by the rules for that extension. All logical
records would be 23040~bits (=2880~8-bit bytes), as the original paper
describing FITS prescribed for information following the primary HDU\@.
The HDU itself is called an extension. The design is called an extension
type.                    

The requirement that no revision to FITS could cause an existing FITS
file to go out of conformance dictated a number of the basic rules
governing the construction of new extensions.  

In the original FITS data sets, the Basic FITS structure of header and
array appeared at the start of the file. Therefore, extensions would
appear only after the primary Basic FITS header and array. Because the
initial array ended only at the end of a 23040-bit record, an extension
would always start a new record. 

It was envisioned that most FITS extensions would become standard in
the same way as Basic FITS, through acceptance by the astronomical
community and endorsement by the IAU\@.  An extension would go
through a development period, initially being used only by a subset
of the FITS community that would refine it. Other extensions might
be in use only within a limited group and might never become
standard at all. Now, a FITS file may include many extensions of
different types. Given that the order of adoption of extensions as
standard cannot be predicted with certainty, it would not have been
wise to prescribe an order of extension types within a file. 
Suppose standard extensions were required to appear first, and the
fourth extension on a data set were to become standard. Then, the
data set would go out of conformance. It was thus agreed that
extensions might appear in any order in a FITS file.                         

With extensions appearing in any order, those extensions a user might
want to or be able to read could be separated by extensions with which
the user would be unfamiliar; the user might wish to read, say, only the
third and seventh and skip all the rest. The user should not have to
know anything about the structure of the intervening extensions to be
able to read the ones of interest. To make this process possible, two
general rules were specified:

\begin{itemize}

\item Each type of extension must have a unique name, provided in the
header.

\item The header must provide information that will allow the software
reading it to calculate its size. 

\end{itemize}

The software reading the FITS file would have a list of types of
extensions that it could handle. By reading the type name from a
standard location in the header, the software would be able to
determine whether or not it could handle this extension. If it
couldn't, it could at least calculate how many records it would have to
skip to reach the beginning of the next extension.

A complete set of rules, described as the Generalized Extensions
agreement (Grosb\o l {\em et al.} 1988; hereafter FITS Paper III), was
endorsed by the IAU in 1988. These rules appear in
section~\ref{s:exts}. 
                  
\section{ASCII Tables}

The concept of a standard flexible format for the transfer of
astronomical data was so appealing that astronomical software
designers sought to apply the format to data and information structures
other than simple arrays. For example, astronomers make extensive use of
catalogs. Such information would most naturally be stored as a table.
The wide variety of tabular information led to the development of the
ASCII table extension. The following three main classes of potential
applications were envisioned:                                

\begin{enumerate} 

\item Standard catalogs such as star or source catalogs.

\item Observing information such as observing logs, calibration tables,
and intermediate tables related to the observing. The results of the
observations might appear as the Basic FITS matrix, and the auxiliary
information would follow in a table. 

\item Tabular results extracted from observational data by data
analysis software. As an example, many programs automatically detect
sources in digitized images and write parameters such as position,
flux, size, spectral index, and polarization into output files.
Astronomers need to transmit these output tabular files; recipients
can then use software designed to manipulate, merge, and
intercompare these tables.
                                   
\end{enumerate}

The ASCII table FITS extension (Harten {\em et al.} 1988; hereafter FITS
Paper IV) conforms to the standard FITS rules and to the generalized
rules for FITS extensions. The column headings are provided in an
extension header that describes the contents of the table. The table
data are stored as a large character array. Each row of the table
consists of a sequence of fields. Each field is described by a series of
keywords specifying the field format using FORTRAN-77 notation, the
location in the row where it begins, and possibly a column heading or
other information about the field.                                    
                                                     
\section{Floating Point}

In the original FITS format, the members of the data array were
required to be of integer data type. Non-integral values, or values
outside the range that could be expressed as integers, were stored
through the use of scaling. The actual physical values would be
derived from the numbers in the FITS file by a linear
transformation. The coefficients for this transformation were stored in
the header as values of keywords. This method of using integers to
represent floating point values has a number of limitations. Only a
limited dynamic range of values can be stored with precision using
scaled integers. Many astronomical data systems use floating point in
their internal data processing; conversion to integers consumes
significant amounts of computer time.          

The adoption by the IEEE of a standard format for floating point
numbers and its widespread implementation by many computer systems
provided the solution. On December~22,~1989, the IAU FITS Working
Group adopted the Floating Point Agreement, establishing IEEE-754
(IEEE~1985) 32-bit and 64-bit numbers as the standard FITS floating
point data types, effective January~1,~1990. 

\section{Physical Blocking}
\label{s:blokhist}
In 1979, when FITS was originally developed, the dominant medium for
data storage and transport was 1/2-inch nine-track magnetic tape.  In
FITS Paper~I, the physical block size was set equal to the logical
record size. As time passed, it became clear that many of the major data
producers regarded this block size as inefficient, in terms of both tape
length used and the number of I/O operations required to write data. 
The new generation of computers, with Megabyte size memory, could easily
read much larger blocks.  As a consequence, FITS Paper III included a
provision that there could be up to 10 logical records per physical
block on 1/2-inch nine-track magnetic tape.  New storage media, such as
cartridge tapes and optical disks were replacing magnetic tape.  Many of
the new media could access data only in blocks of fixed length,
typically $2^{n}$ bytes, and the FITS 23040-bit logical record length
would not correspond to an integral number of these blocks.  Whereas
FITS had been discussed in FITS Paper I in the context of files on
magnetic tape, the increasing use of electronic transport for files was
leading to the concept of a FITS file as a pure bit stream, without
special ties to any particular medium.  However, a set of prescriptions
for the physical expression of FITS files on different media was still
needed. General rules for all media, and in particular for how to write
FITS logical records to the $2^{n}$-byte physical blocks, were proposed
by Wells and P. Grosb\o l (ESO) in 1991. With minor changes, they were
approved by the IAUFWG in the spring of 1994.  They appear in section
\ref{s:phystr} of this {\em Guide}.
             
\section{Image Extension}

In the late 1980s, there had been some discussion in the  FITS
community about providing a mechanism for including multidimensional
arrays in extensions as well as in the primary data array.  The
IUE group was looking for a way to
include several related arrays in the same file, in particular, both their
data and a flag array in which the flag for each element would refer to
the data for that element.  Because the data types for the flag and the
data were different, they could not just 
add another axis and include the flag data in the primary data array. 
J.~D.~Ponz and J.~R.~Mu\~{n}oz of the ESA IUE group and
R.~Thompson~(CSC) of the GSFC IUE group made a detailed draft
available electronically early in 1992. The extension was given the
name {\tt IMAGE}\@.  The only significant discussion was
whether or not to provide for Random Groups records after an image
extension; because Random Groups have largely fallen into disuse and
are not recommended for future use, the decision was not to allow
Random Groups records. 

\section{Binary Tables}

One drawback of the ASCII table format was the space required by
tables with a large number of entries, such as gain and calibration
tables, because every number appeared in coded form. In addition,
conversion of the entries in these tables to ASCII would be very
time-consuming.  Initially, the ASCII form had been needed to
represent floating point numbers. The precise definition and general
acceptance of the IEEE floating point format made it possible to
include binary floating point numbers in table fields. Meanwhile,
developers of software to write FITS files for results of the Very
Long Baseline Array project found that it would be useful to be able
to put vectors in table fields. A design for binary tables with
vector fields was developed by W.~Cotton~(NRAO)\@. Because the
vector field might be thought of as a column rising out of the page,
it was imagined to be a third dimension of the table, and the
extension was given the type name {\tt A3DTABLE}\@. This name was
chosen rather than, for example, {\tt 3DTABLE}, to signify that the
extension might still undergo further development; the final version
would have a new name. This 3-D table extension was released as part
of the NRAO Astronomical Image Processing System (AIPS) early
in~1987. 
                                                            
At the beginning of 1990, NASA Headquarters specified that all NASA or
NASA-supported projects must make their data available in FITS format.
Many of the projects then in the process of developing their data plans
were high energy astrophysics experiments.  Their data would usually
appear as event lists.  These event tables could be very large.  Map
arrays would contain mostly zeroes and be inefficient. Binary tables would
be the best format.  Many of the FITS files designed by the high energy
astrophysics community were based on the AIPS 3D table concept.  This
growing demand gave impetus to the development of a formal proposal for
binary tables. Cotton distributed an initial proposal for a standard binary
table extension, to be called {\tt BINTABLE}, in April~1991. It
incorporated all the features of the original {\tt A3DTABLE} extension and
included a number of additional keywords and field formats that had been
suggested by readers of the original {\tt A3DTABLE} description. 
                       
In late~1989, at a meeting at Green Bank to develop a standard format
for single dish data, Wells had suggested the concept of including
multidimensional matrices, not just vectors, in the fields of binary
tables. The participants in the meeting had decided to adopt such a
format and proceeded to discuss possible designs. Subsequently, a number of
prospective binary table users expressed an interest in a mechanism for
including arrays whose dimension might vary from row to row in the
table. This issue was raised by D.~Tody at the April, 1991 European
FITS Committee meeting. Following discussions outside the formal
sessions by a number of the participants, Cotton and Tody presented a
design with a pointer data type, which was modified slightly in the
discussion at the meeting. A formal text with appendixes describing
possible formats for multidimensional fields and variable length arrays,
and incorporating the keywords and field formats to make these
structures possible, was released by Cotton and Tody in October,~1991.

As early as July,~1991, W. Pence (GSFC/HEASARC) had raised
questions about how an array of strings was to be distinguished
from a single long string.  The ensuing electronic discussion led to the
addition of a third appendix, describing a substring array convention. 
The revised {\tt BINTABLE} proposal with this appendix added was
released by Cotton, Tody, and Pence in May,~1993. In the spring of 1994,
after a few points had been clarified, the IAUFWG endorsed the main
proposal as part of standard FITS\@.  The three appendixes --
multidimensional arrays, variable length arrays, and arrays of strings
-- were not included as part of the endorsed standard; they are
considered recommended but not required conventions.  However, they have
a special place in that the {\tt BINTABLE} extension contains a number
of provisions especially designed to make them possible.  
                                           
Initial testing began in 1992, with an exchange of {\tt IMAGE} and 
{\tt BINTABLE} files among ESO, IUE, and the High Energy Science 
Archive Research Center (HEASARC) at Goddard Space Flight Center.  
In line with the evolution of FITS from a tape standard to a 
bit stream standard, the exchange was carried out by making files 
available through anonymous ftp rather than through exchange of tapes.
Early in 1994, following the revision of {\tt BINTABLE}, additional
tests were carried out in preparation for the votes by the FITS
committees.  Files from the Space Telescope Science Institute (STScI)
containing {\tt IMAGE} and {\tt BINTABLE} extensions were read at ESO,
and another set of files from ESO was read at GSFC/HEASARC.  The
successful tests allowed the two extensions to proceed to a vote.  On
June 15, 1994, Chair P.~Grosb\o l announced that the IAUFWG had endorsed
the blocking rules and the {\tt IMAGE} and {\tt BINTABLE} extensions. 
As both extensions are now standard FITS, they are now described in
Section \ref{s:FITSfund}, rather than in Section \ref{s:AdvFITS} as was
done in earlier versions of the Guide.  The discussion of the 
{\tt BINTABLE} appendixes remains in Section \ref{s:AdvFITS}, as they
were not part of the proposal adopted by the IAUFWG. 
                                                             
\section{How FITS Evolves}

The history of binary tables illustrates many of the aspects of the
way in which additions to the FITS format have developed in the past
and are likely to continue to evolve in the future. The initial
concept for a structure typically arises from the designer of a data
set who finds that none of the existing standard or proposed FITS
formats will organize the data properly. A proposal is developed and
a name chosen for the new extension type. This name must then be
registered with the IAUFWG\@.  It must be different from any name
previously registered. The FITS Support Office maintains a list of the
registered extension type names and will forward name registration
requests to the IAUFWG\@.  In some cases, a temporary local form of the
extension with a different name will be be defined as well. This local
name must also be registered with the IAUFWG\@.  The local or
developmental form may serve as the basis for designing data sets
elsewhere while the full proposal is being developed, as occurred with
{\tt A3DTABLE}\@. During this period, the developer will discuss
concepts of this new extension with others interested in the format and
may modify it based on this discussion.
                                                              
Eventually, a formal proposal will be made available for review by the
astronomical community, normally by announcing World Wide Web
(WWW) and ftp locations where it can be obtained.  With the more
general use of FITS and the increasing ease of electronic transmission
of documents, proposals are becoming available to a wider public at
earlier stages than was the case during the early days of FITS\@.  Tests
are run using the new format to confirm that it can be practically used
for data transport. After the community has reviewed the proposal, any
modifications have been made, and the format has been successfully used for
data transport, the proposal is submitted for approval to the regional
committees---the European FITS Committee, the Japanese FITS Committee, and
the American Astronomical Society Working Group on Astronomical Software
(WGAS) FITS Committee. Following approval by the regional committees, it is
submitted to the IAUFWG\@. Approval by the Working Group establishes it as a
standard extension. 
                        
A number of aspects of this process are worth noting. First,
FITS formats have been developed through the efforts of
individuals responding to particular practical problems. Although
there is extensive community review, most of the initial detailed
development is done by the people who actually need to use a format
for a particular purpose, rather than by a formal committee. A new
format must be demonstrated to work in practice through actual data
transport before it can be approved as standard, ensuring that the
standard is not purely theoretical but has actually been used.
Finally, the approval process occurs by community consensus, as is
customary in the world of standards.

                          

\chapter{FITS Fundamentals}
\label{s:FITSfund}
\section{Basic FITS}
      
The fundamental unit of a FITS data set is the file, which begins with the
ASCII string \verb+SIMPLE  =                    T+, where the first 6
bytes of the file contain {\tt SIMPLE}, the ``{\tt =}'' is in byte 9, the 
{\tt T} is in byte 30, and the intervening bytes contain ASCII blanks. This
30-character string is the signature of FITS, the way in which generalized
software can identify the file as FITS\@.  The string is not to be used if
the file deviates from the rules for FITS in any way.  In such a case, a
value of {\tt F} may be appropriate.   A FITS file ends with an end-of-file
mark appropriate to the medium on which it is written.  A FITS file is
composed  of 23040-bit (2880~8-bit byte) logical records, organized into a
sequence of header data units (HDUs).  This logical record length was
chosen because it was an integral multiple of the byte and word lengths of
all computers that had been sold in the commercial market in or before
1979, the time of the original FITS agreement.  Each HDU consists of one or
more logical records containing an ASCII header followed by zero or more
records of binary data.  The first HDU is called the primary HDU; those
following are called extensions. The last extension may be followed by
23040-bit {\em special records}, which need not be organized as HDUs. 
                 
Each FITS header record consists of 36~80-byte ``card images''
written in 7-bit printable ASCII code (ANSI~1977) with the sign bit
set to zero. The header may contain as many records as are needed for
the card images. The {\tt END} card image is the last. The remainder of the
last record of the header is filled with ASCII blanks to its full 23040-bit
length. These header records should contain all the
information necessary to read and label the associated data. In addition,
other information may be provided, such as the processing history or
instrument status.  The header records are followed by the data records.
                                                                  
The first or primary HDU is governed by special rules. Its data
records, if present, contain a matrix of data values, in one of
several binary formats, called the primary data array. The array may
have no more than 999~axes. There need not be data in the primary
data array. An empty primary data array is most likely to appear when
all the data of the FITS file are found in extensions.

\subsection{Primary Header}
\label{s:phdu}

Each ``card image'' in the header is in the following form:

\begin{quote}

keyword = value ~/comment

\end{quote}

Keywords can be no more than eight characters long.  The only
characters permitted for keywords are upper case (capital) Latin
alphabetic, numbers, hyphen, and underscore, with underscore
preferred over hyphen. Leading and embedded
blanks are forbidden. There are two special classes of 
keywords: ~required keywords and reserved keywords. If a keyword is
required, then a card image with that keyword must appear in the
header. Some keywords are required in all FITS headers; others are
required only in conjunction with certain FITS structures. Some
structures may require certain keywords to appear in a specific order.
Reserved keywords do not have to appear in any header, but they may
be used only with the reserved meaning if they do. Users may define
their own additional keywords for any FITS file. 

The contents of the keyword field determine the structure of the value
field. Keywords that have values associated must contain ``{\tt = }''
in columns~9 and 10; otherwise, columns~9--80 are regarded as
comment. Except for the special cases of the {\tt HISTORY} and 
{\tt COMMENT} keywords and a blank keyword field
(section~\ref{s:reskey}), if a keyword does not have a value, column~9
must not contain~``{\tt =}''. The name of the keyword governs whether a
value is present. Keyword values have one of four types:~logical,
character string, integer, or floating point. The following notation
will be used to show what type of value must be associated with each
keyword: 
     
\begin{quote}

{\tt KEYWORD} (value type)

\end{quote}

The discussion that follows the keyword name will describe the meaning of
the value.
                                             
The following content is required for the first ten columns of a
header card image:

\begin{itemize}
\item Keyword name beginning in column~1, ending in or before
column~8. The remainder of columns~1--8 is blank filled. 

\item If the keyword has a value associated with it, ``{\tt =}'' in 
column~9, followed by a blank in column~10. 

\item If the keyword has no value and is not the reserved 
{\tt HISTORY}, {\tt COMMENT}, or blank field, any content other than
``{\tt = }'' in columns~9 and 10. 

\item For the reserved {\tt HISTORY}, {\tt COMMENT}, and blank field
keywords, the contents of columns~9 and 10 are not restricted. 

\end{itemize}

To simplify the process of writing software to read FITS files, the
following fixed format is mandatory for values of the required keywords.
For the same reason, its use is strongly recommended for other
keywords. Departures should be restricted to cases where use of fixed
format is impossible for some reason. Use of the fixed format simplifies
the task of the software in determining the type of the value.  The
structure of a fixed format value field depends upon its type: 

\begin{itemize}

\item (Logical) {\tt T} or {\tt F} in column 30.

\item (Character string) A beginning ``{\tt '}''  in column~11 and
an ending ``{\tt '}'' in or after column~20 but no later than
column~80, with the string in between. To include a single quote
within a character string, use two successive single quotes; for
example:~{\em O'Hara\/} becomes {\tt 'O''HARA '}. Leading blanks in
a string are significant; trailing blanks are not.    
                          
\item Real part (integer or floating)
right justified, ending in column~30, 20~columns maximum. 

\item Imaginary part (integer or floating) right justified, ending in
column~50, 20~columns maximum, i.e., starting in column~31 or
after. 

\end{itemize}

The 20 columns specified in the fixed format may not always be
sufficient to hold the full precision of a real floating point number
or either the real or imaginary part of a complex floating point
number. None of the required keywords used for the primary header,
random groups or the ASCII table, binary table or image extensions
requires a floating point value, and developers of new extensions might
be well advised to avoid required keywords with floating point values.
Many reserved keywords have floating point values, but there is no
standard practice or recommended procedure for handling floating point
values with too many digits to fit in 20~columns. 

When the fixed format is not used, the value field must be written
in a notation consistent with the list-directed read operations in
FORTRAN-77. (With the exception of complex numbers, all the fixed
formats follow the rules for FORTRAN-77 list-directed read.)  Such a
notation has the following requirements for the different formats:
                                    
\begin{itemize}

\item (Logical) The first non-blank character in 
columns 11-80 is {\tt T} or {\tt F}.

\item (Character string) Begins with a ``{\tt '}''  in column 11 or later,
 and ends with a  ``{\tt '}'' no later than
column~80, with the string in between. Starting in column 11, only blanks
are permitted in the value field before the opening quote.  To include a
single quote within a character string, use two successive single quotes;
for example:~{\em O'Hara\/} becomes {\tt 'O''HARA '}. Leading blanks in a
string are significant; trailing blanks are not. 
                                                               
\item (Integer) May occupy any of columns 11-80.

\item (Floating) May occupy any of columns 11-80. The decimal point
must always appear explicitly, whether or not
exponential notation is used. When exponential notation is used, all
letters, (e.g., {\tt E}, indicating an exponential) must be in capitals. 
                                                    
\item (Complex) Consists of real and imaginary components (integer or
floating point), anywhere in columns 11-80, separated by at least one
column.
                                                  
\end{itemize}

Any information in a character string value that the reading
software needs to retrieve the data from the FITS file
should be in the first eight characters, for the benefit of primitive
systems.  Users should name their
strings accordingly. If the string is used only to provide descriptive
information or in the scientific interpretation of the file, it is not 
critical to have the meaning clear from the first eight characters, but
it is still a good idea. 
 
Comments may be incorporated in a header card image whether or not
a value is present. If a value is present, place a slash 
(hexadecimal {\tt 2F}) between the value and comment field, with at
least one blank between the end of the value and the slash. For the
fixed format, the slash and space are not required, but using them when
writing a FITS file will simplify the task of the reader. If the fixed
format is not used, a slash serving as a delimiter, a requirement
derived from FORTRAN list-directed read, is required before the comment. 
If the keyword has no associated value (which is immediately apparent
when column~9 does not contain ``{\tt =}''), then the entire content of
columns~9--80 is a comment. In such a case, it is best to leave column~9
blank.                       
                    
The first keyword in a header must be {\tt SIMPLE} and have a value
of {\tt T}~(true) if the file conforms to FITS standards. 
Subsequent keywords convey the form in which array values are stored,
the number of dimensions in the array, and the length of each axis.
The coordinate system, scaling, and other information may be given at
user option. 

Note that while the FITS required keywords will always be the same, the
interpretation of the associated values may be expanded. 
For example, negative values of the keyword {\tt BITPIX} are now used
to indicate IEEE floating point data, and the {\tt PCOUNT} keyword, which
originated in connection with random groups, was then used in the 
generalized extensions definition and has now been adopted to describe the
heap of variable length arrays logically included in a binary table. 
Neither later usage was part of the original definition. 
                                      
Many keywords, called {\em indexed} keywords, consist of an alphabetic
root and a number. If there is only one index, the number does not
have leading zeroes: {\tt NAXIS1}, not {\tt NAXIS001};  {\tt TTYPE11},
not {\tt TTYPE011}. Such keywords are represented in this {\em Guide\/}
by an upper case root followed by a lower case $n$, for example 
{\tt NAXIS}$n$, {\tt TTYPE}$n$.  If there is more than one index, as in
the {\tt PC} matrix discussed in section \ref{s:matphy}, leading zeroes
may be needed to delimit the indexes, for example {\tt PC012001}, as
{\tt PC121} does not distinguish between $P_{12,1}$ and $P_{1,21}$.     


\subsubsection{Required Keywords}
\label{s:reqkey}
The following keywords are {\em required\/} for {\em all Basic FITS
headers for all time}, and must appear in the order given
below. All except  {\tt SIMPLE} must appear in other headers as well, in
the same order. The value field must appear in the fixed format
described in section~\ref{s:phdu}.    
 
\begin{enumerate}

\item {\tt SIMPLE} (logical) - 
A value of ``{\tt T}'' signifies that the file conforms to FITS
standards. A value of ``{\tt F}'' is used  for files that resemble FITS
files but depart from the standards in some significant way. One example
would be files where the numbers are in the DEC VAX internal storage
format rather than the standard FITS most significant byte first.  The
``FITS'' files produced by some hardware that contain non-standard data
formats such as two-byte unsigned integers or give the month number
before the day number in date formats are another example.  Such files
might be convenient for internal use by a particular organization or for
exchange between users with the same hardware for whom convenience is
more important than standardization, when they wish the files to have an
overall FITS-like structure.   No installation should use them as the
standard format for communication with outside users. Files with 
{\tt SIMPLE~~}= F should not be described as FITS files.   

\item {\tt BITPIX} (integer) describes how an array value is represented:

\begin{tabular}{rl}
   {\bf 8} & ASCII characters or 8-bit unsigned integers \\
   {\bf 16} & 16-bit, twos complement signed integers \\
   {\bf 32} & 32-bit, twos complement signed integers \\
   {\bf \mbox{\boldmath $-$}32} & IEEE 32-bit floating point values \\
   {\bf \mbox{\boldmath $-$}64} & IEEE 64-bit floating point values
\end{tabular}

No other values for {\tt BITPIX} are valid.

The name comes from the original FITS design, in which the values of
the array were regarded as pixels in a digital image (BITs per
PIXel). With the use of negative values of {\tt BITPIX} to signify
floating point array values, the number of bits per data array member is
the absolute value of {\tt BITPIX}. 

\item {\tt NAXIS} (integer) is, for the primary header, the number of
axes in the data following the associated primary data array. A value
of zero is acceptable and indicates that no data are associated with
the current header. The most common reason for a primary HDU with
no data is that all the data in the file are extensions. The
maximum possible value is 999. Negative values are not allowed. 

\item {\tt NAXIS}$n, n=1, \ldots ,${\tt NAXIS} 
({\tt NAXIS}=0 --$>$ {\tt NAXIS1} not present)
(integer) is the number of elements along axis~$n$ of the array;
{\tt NAXIS1} describes the most rapidly varying index of the array,
{\tt NAXIS2} the second most rapidly varying, etc. This
convention is the same as the one used in FORTRAN\@.  A value of zero
for any of the {\tt NAXIS}$n$ signifies that no data array is associated
with the header. None of the {\tt NAXIS}$n$ may be negative. The rules
of FITS do not strictly forbid use of {\tt NAXIS}$n$ keywords for values
of $n>$NAXIS\@. While some groups use such keywords for special purposes,
the practice is not recommended as a general rule. 

\ldots the other keywords follow until\ldots

\item {\tt  END} (no value) - The last keyword must be {\tt END}. This
card image has no ``{\tt =}'' in column 9 or value field but is filled
with ASCII blanks. 

\end{enumerate}

Other keywords may appear only between the last {\tt NAXIS}$n$ and 
{\tt END} keywords. The remainder of the last header record should be
filled with ASCII blanks.  

These keywords prescribe the size of the primary data array in
bits, NBITS, through equation~\ref{eq:primnbit}, 
\begin{eqnarray} 
\mbox{NBITS} &=& \mbox{ABS(BITPIX)} \times\ \nonumber \\
             & & (\mbox{NAXIS1} \times
                \mbox{NAXIS2} \times \cdots \times \mbox{NAXIS$m$}), 
\label{eq:primnbit}
\end{eqnarray} 
where $m$ is the value of {\tt NAXIS} and the keyword names represent the
values of those keywords. 
         
Examples 1 and 2 in Appendix \ref{s:ex} illustrate primary headers
that precede data arrays.
         
\subsubsection{Reserved Keywords}
\label{s:reskey}

Many of the following reserved keywords were originally suggested by
Wells, Greisen, and Harten~(1981). If a reserved keyword is used, the
meaning and structure must be as described here.  Keywords other than
the reserved keywords should not be used in their place to express the
same concepts. Reserved keywords may appear in any order between the
required keywords and the {\tt END} keyword. 

Some of these keywords describe the data array.

\begin{itemize}

\item {\tt BUNIT} (character) represents the physical units of the
quantity stored in the array, e.g.,~Janskys, magnitudes/pixel. The name
comes from ``brightness units.'' Section~\ref{s:units} 
discusses recommendations for choice of units. 

\item {\tt BSCALE} (floating) is a scale factor used in converting
array elements stored on the FITS data set to physical
values:
 
\begin{equation}
\label{eq:bscal}
\mbox{physical\_value} = (\mbox{FITS\_value}) \times \mbox{BSCALE} + \mbox{BZERO}.
\end{equation}

If this keyword is not present, the scale factor is assumed to be 1.

\item {\tt BZERO} (floating) is the offset, the physical value
corresponding to a stored array value of zero, in
equation~\ref{eq:bscal}. If this keyword is not present, the
offset is assumed to be zero. 

Be careful about possible overflows when using {\tt BSCALE} and {\tt BZERO} if
the array elements are floating point (value of {\tt BITPIX} $<$ 0).
Pay attention to the likely order of magnitude of the
resulting values and be prepared to trap overflows if necessary.  
                                                
While the values of {\tt BZERO} and {\tt BSCALE} are floating point, the
rules of FITS do not specify the data type of the result of scaling, as
this result is not part of the FITS file.  Whether the result is to be
considered an integer or real number depends on the physical
significance of the number.      
                                                         
\item {\tt BLANK} (integer) - 
If the text ``{\tt BLANK~~~}'' appears in columns~1--8, then the value
will be stored in those elements of an {\em integer\/} array that have
an undefined physical value. The value of {\tt BLANK}  appears in the
actual data array, without scaling.  It should be regarded as a code,
not a number; a scaling transformation  with {\tt BSCALE} and 
{\tt BZERO}  should not be applied to array members that have the value
given by the  {\tt BLANK} keyword.  Do not use this keyword if the FITS
data array is IEEE floating point, becuse this function is performed by
the IEEE floating point NaN\@.  The {\tt BLANK} keyword does not have
the same meaning as filling columns~1-8 with ASCII blanks.

\end{itemize}

The reserved keywords permit complete specification of a linear
coordinate system for any axis. Other coordinate systems can be
identified through the name given by 
{\tt CTYPE}$n$, comments, and user-specified keywords.  

\begin{itemize}

\item {\tt CTYPE}$n$ (character) is the name of the physical coordinate
for axis $n$ (e.g.,~frequency, RA, Dec). 

\item {\tt CRPIX}$n$ (floating) is a location along axis~$n$ called the
reference pixel, or reference point, used in defining the range of
values for the physical coordinate of axis~$n$. It is given in units of
the counting index. The counting index for axis~$n$  runs from 1 to the
value of {\tt NAXIS}$n$,  incrementing by one for each pixel or array
position. The value of  {\tt CRPIX}$n$ may be a fractional index number
(e.g.,~2.5) and/or be outside the limits of the array; if the array runs
over index values 1--10, the reference point may still be~$-5$. The
term ``reference pixel'' originated in the days when the data array was
assumed to represent a digital image. The location of the index number
relative to an image pixel, i.e., center or corner, is not at present
specified in FITS, but the World Coordinates proposal currently under
consideration places it at the center, following the common usage in
astronomy.  A full discussion of this issue
appears in section~\ref{s:indcoor}.       

\item {\tt CRVAL}$n$ (floating) is the value of the physical coordinate
identified by {\tt CTYPE}$n$ at the reference point on axis~$n$. 

\item {\tt CDELT}$n$ (floating) is the rate of change of the physical
coordinate along axis~$n$ per unit change in the counting index,
evaluated at the reference point. 

\item {\tt CROTA}$n$ (floating) is the rotation angle, in degrees, of
actual axis $n$ of the array from the coordinate type given by 
{\tt CTYPE}$n$. As there is no prescribed rule for describing such
rotations, the nature of the rotation should be explained in detail
using comments. 
          
\end{itemize}

Default values have not been defined for any of these keywords.

These reserved keywords, from FITS Paper I, allow the definition of
simple rectangular coordinate systems, but they do not prescribe the
relation between the plane rectangular coordinate system of the FITS
array and the spherical coordinate region of the sky that it represents. 
This question, along with the current comprehensive proposal under
consideration by the FITS community, is discussed in
section~\ref{s:wcs}.  Part of the proposal replaces the simple 
({\tt CROTA}$n$, {\tt CDELT}$n$) method with a more comprehensive
method of defining coordinate transformations in three dimensions.

\begin{itemize}

\item {\tt DATAMAX} (floating) is the 
maximum data value in the array, after any scaling
transformation has been applied to the stored array value.

\item {\tt DATAMIN} (floating) is 
the minimum data value in the array, after any scaling
transformation has been applied to the stored array value.

\end{itemize}

Note that {\tt DATAMAX} and {\tt DATAMIN} apply to the physical
values represented, not to the numbers in the FITS file.  In determining
the values for {\tt DATAMAX} and {\tt DATAMIN}, special values such as the
IEEE special values and values derived from integer array members set to
the value of the {\tt BLANK} keyword are not considered.                
                           
Some keywords provide information on the observations represented or
the production of the data set.

\begin{itemize}

\item {\tt DATE} (character) is 
the date the file was written (\mbox{'dd/mm/yy'}---note
order). UT is recommended. The value may refer to the creation date of the
original file rather than that of the current copy. This rule allows
files to be copied without changing the value of the {\tt DATE} keyword.
Currently, date, month, and year are always two digits, with a leading zero
if necessary.  With this format, the century is ambiguous.  
          
\item {\tt DATE-OBS} (character) is the date of 
data acquisition (UT recommended); it tells when the observations were
made (\mbox{'dd/mm/yy'}--- note order). 
Whether this value (and that of {\tt DATE})
refers to the start, midpoint, or end of the relevant time interval is
not specified. Use comments to say. 

With the turn of the century approaching, there have been extensive
discussions as to how to distinguish the century when specifying a date. 
A proposal based on the ISO 8601 format is now under consideration by
the regional FITS committees.
                                           
\item {\tt ORIGIN} (character) is the installation where the FITS file is
being written.

\item {\tt TELESCOP} (character) is the data acquisition telescope.

\item {\tt INSTRUME} (character) is the data acquisition instrument.

\item {\tt OBSERVER} (character) is the observer name or other
identification.

\item {\tt OBJECT} (character) is the object observed.

\item {\tt AUTHOR} (character) identifies who compiled the data
associated with the header. Use this keyword when the data come from
a published paper or have been compiled from many sources. It refers
to the author of the data being carried by the FITS file, not to the creator of
the computer-readable form.  It should not be used to identify the
software that created the FITS file or the writer of that software. 
The {\tt CREATOR} keyword (section \ref{s:HFWGcon}) has been suggested
to identify the software creating a FITS file.

\item {\tt REFERENC} (character) is the bibliographic reference for
the data associated with the header. 

\item {\tt EQUINOX} (floating) is the equinox of the coordinate system
(in years). In early FITS data sets, the keyword {\tt EPOCH} was used
with this meaning. Since the term ``epoch'' has a different meaning,
referring to the actual date of observation, the correct term 
{\tt EQUINOX} should be used in the future. {\tt EPOCH} will still be
accepted with this meaning in old data sets and should not be otherwise
used. Software to read FITS data sets should interpret {\tt EPOCH} as
equivalent to {\tt EQUINOX}\@. The epoch or date of observation can be
given as the value of the  {\tt DATE-OBS} keyword.                            
                                                                
\item {\tt BLOCKED} (logical) - deprecated -  when set to the value 
{\tt T} advises that a tape may be blocked with more than one logical
record per physical block. A value of {\tt F}  has no meaning. Its
significance is now primarily historical and is discussed further in
section \ref{s:phystr}.  However, because the keyword name 
{\tt BLOCKED} has been reserved, it cannot be used for any other
purpose.         
\end{itemize}

Other keywords signal a card image with comments or other text.
\begin{itemize}

\item Columns~1--8 blank, no keyword, means columns~9--80 are a
comment.

\item {\tt COMMENT} (none) means columns~9--80 are a comment.

\item {\tt HISTORY} (none) means columns~9--80 are a comment. This
keyword is intended for use when the associated text discusses the
history of how the data contained in the array were processed. 

\end{itemize}

These keywords are the only ones without values 
that can have ``{\tt =}'' in column~9.  
Users may define other keywords to contain comments as well. For these
keywords, column~9 may not contain ``{\tt =}''.  The reason this
restriction does not apply to the {\tt COMMENT}, {\tt HISTORY} and
\verb*+        + keywords is principally historical; the original FITS
paper defined columns 9-80 as being a comment and did not restrict the
content. For the {\tt COMMENT}, {\tt HISTORY}, and blank field
keywords, the reader will be able to tell by the keyword name that there
is no value. However, for user-defined keywords, the reader has no other
way of telling {\em a priori\/} whether the field has a value or not. 
To minimize confusion, it is best to avoid ``{\tt =}'' in column~9
even after {\tt COMMENT}, {\tt HISTORY}, and blank keyword
fields as well. 

\subsubsection{Some Hints on Keyword Usage}

While only the keywords listed in \ref{s:reqkey}  and \ref{s:reskey} are
formally reserved by the rules of FITS, standard meanings for others may
be adopted by general agreement.  Section~\ref{s:wcs} discusses a number
of such keywords.  Conventions for keyword meanings can also be
developed within a given discipline, as has been done for high energy
astrophysics, radio interferometry, and single dish radio observations. 
Some of these conventions are discussed in section \ref{s:AdvFITS}. 
Keywords should not be used in a way that conflicts with a generally
accepted convention.  If the convention applies to all FITS files, avoid
using the keyword with a meaning other than that of the convention; if
the convention is discipline-specific, say, to high energy astrophysics
or radio astronomy, a different meaning may apply to a different
discipline.  Keyword meanings in conflict with widely accepted usage may
confuse readers.                                      
                                                                     
For keywords that have no value or are used to transfer text, such as
{\tt HISTORY}, {\tt COMMENT}, and {\tt REFERENCE}, the same keyword may
be used repeatedly to extend text over a sequence of card images.
However, repetition of a keyword with conflicting values may cause
confusion.  There is no standard interpretation in such a case
determining which value is to be retained as the true value of the
keyword. Different FITS readers may interpret the header differently. Do
not repeat a keyword on different card images if the values conflict. 
                                                        
The comment field following the keyword and value provides an
opportunity to explain the meanings. Such comments should supply
additional information. Some FITS writers automatically generate
comments such as ``Physical coordinate of axis'' following a 
{\tt CTYPE}$n$ keyword or ``Physical units of matrix'' following a 
{\tt BUNIT} keyword. Such comments provide no more information than has
been given by the FITS rules and are not very helpful for the human
reader. Comments should provide information not available from the FITS
syntax, for example, what the axis is (right ascension? declination?
frequency?) or the units of the values in the primary data array
(Janskys/beam?  magnitudes/arcsec$^{\rm 2}$?). The number of characters 
in a string value is often limited to accommodate reading software,
resulting in  abbreviations; the comment field can and should be used to
explain these abbreviations in full. While the meaning of an
abbreviation may be obvious at the writing installation, it may not be
so clear to a reader.  
     
\subsubsection{Units}
\label{s:units}
  
The units named in the IAU (1988) {\em Style Guide\/} 
are recommended for array and keyword values, with the exception of
measurements of angles. This set of units includes the SI units and
additional units that are standard in astronomy, for example,
magnitudes. Using {\tt BUNIT} and {\tt TUNIT}$n$ keywords will
remove any confusion; similarly, the comment field following 
{\tt CTYPE}$n$ keywords can be used to specify the units. Fractional
units should not be used. If, for example, for space reasons,
temperatures must be listed in the file in units of tens of degrees, the
units specified by {\tt BUNIT} should be degrees, and scaling
(section~\ref{s:scalint}) should be used to transform from the file
values to physical values. Always explicitly describe non-standard
units.  A copy of the IAU Style Guide recommendations is available on
the IAU World Wide Web site, currently at 
{\tt http://www.lsw.uni-heidelberg.de/iau/units.html}.

For celestial coordinate systems specified with the {\tt CTYPE}$n$, 
{\tt CRVAL}$n$, {\tt CDELT}$n$, and {\tt CROTA}$n$ keywords, or with the
keywords used in the world coordinates conventions described in section
\ref{s:wcs}, the use of
decimal degrees for the angular measurements is required, and degrees
are recommended as the units for other angular measurements (with, for
example, the value of {\tt BUNIT} = 'deg    ').
                                             
\subsection{Primary Data Array}
\label{s:PrimDat}

In the original design of FITS, the data array represented a digitized
image. Each array element would therefore correspond to a pixel of this
image. Consequently, while the elements of a FITS data array are often
called ``pixels'', the array does not represent an image and the term
``pixel'' may simply refer to a member of an array rather than a section
of an actual image.                          

The primary data array starts at the beginning of the record following
the last primary header record. The data occur in the order defined by
the header---pixel numbers increasing, with the index along axis~1
varying most rapidly and the index along the last axis varying least
rapidly. Data are packed into the 2880-byte records with no gaps. Each
entry in the array immediately follows the preceding entry; the first
pixel of any given axis does not necessarily appear in the first word of
a new record. If the last member of the data array is not at the end of
a record, the remaining bits of the record are filled with zeroes,
corresponding to 0 (integer) or +0.0 (floating point). 

The bytes in each word are in order of decreasing significance, with
the sign bit first. Thus, INTEL and VAX machines will have to reverse
the order of the bytes in 16- and 32-bit integers and make the
appropriate conversions between IEEE floating point and internal
storage order before writing or after reading. Numbers are stored in
twos-complement form; conversion will be required for ones-complement
machines. 

The data type of the array members may be any type
corresponding to a valid value of {\tt BITPIX}\@: unsigned eight-bit
integers or characters, signed 16- or 32-bit integers, or single or double
precision IEEE floating point.  Proposals to add 16- and 32-bit unsigned
integer types have been discussed from time to time, but a consensus in
favor of these proposals has not developed.  Data with the numerical
range corresponding to unsigned integers can be included in a FITS file
by using signed integers and then scaling, for example, setting 
{\tt BZERO} equal to 32768 ($2^{15}$) for 16-bit integers. 

Some detector systems produce files that conform to the FITS rules
except in their use of multibyte unsigned integers; these files should not
be described as FITS files and should not have {\tt SIMPLE} set equal
to {\tt T} in the first card image.  Such files are an example of a good
use for setting {\tt SIMPLE} equal to {\tt F}.  

\subsubsection{Scaled Integers}
\label{s:scalint}

When FITS was originally developed, there was no standard format for
the internal representation of floating point data.  Only
integer formats were allowed in the data array. The scaling scheme
using the keywords {\tt BZERO} and {\tt BSCALE} was devised in
order to make it possible to represent inherently floating point physical
values using a data array of integers.  The physical value of the data
represented by an array member would be derived from
equation~\ref{eq:bscal}.  While scaling is no longer required
to represent floating point numbers, it remains a useful tool.  
Representation of unsigned integer quantities is one application.

Be careful when attempting to scale data sets with large dynamic
range. If one converts such data to integers and then tries to convert
back to floating point, so much precision may be lost that the
original data values will be irretrievable. 

\subsubsection{Undefined Integers}

The value of the keyword {\tt BLANK} is used to identify undefined
integer array values, which might result from data dropouts or from
operations that are undefined  (like a divide by zero). For 16-bit
integers, the most commonly used value of {\tt BLANK} is $-32768$, but
users may choose the value most appropriate for their data. The 
{\tt BLANK} keyword is not used for floating point data, where the IEEE
NaN identifies undefined values.              
                 
\subsubsection{IEEE Floating Point Data}
\label{s:IEEEflt}

FITS allows transmission of 32- and 64-bit floating point data within
the FITS format using the IEEE (1985) standard. This Floating Point
Agreement also applies to random groups records and to any extensions
for which {\tt BITPIX} is not explicitly restricted  
(e.g., {\tt \mbox{BITPIX}}=8 for {\tt XTENSION= 'TABLE~~~'}).  Values
for {\tt BITPIX} of $-32$ and $-64$ indicate IEEE single- and
double-precision floating point data, respectively. 
                                     
The text of the Floating Point Agreement (Wells and Grosb\o l~1990) is
as follows: 

\begin{quote} 

The Basic FITS, Random Groups and Generalized Extensions
Agreements are revised to add IEEE-754 32- and 64-bit floating point
numbers to the original set of FITS data types. BITPIX=$-32$ and
BITPIX=$-64$ signify 32- and 64-bit IEEE floating point numbers; the
absolute value of
BITPIX is used for computing the sizes of data structures. The full
IEEE set of number forms are allowed for FITS interchange, including
all special values (e.g., the ``not-a-number'' cases). The order of the
bytes is sign and exponent first, followed by the mantissa bytes in
order of decreasing significance. The BLANK keyword is ignored by FITS
readers when BITPIX=$-32$ or~$-64$. 
\end{quote}

For a complete, precise description of the IEEE floating point format, 
refer to the IEEE standard. The following discussion is provided to help
in the interpretation of floating point data.

An ordinary IEEE floating point number consists of three components: a
sign, an exponent, and a fraction.  For regular IEEE 32-bit floating
point numbers, the sign is contained in  bit~1, the exponent in
bits~2--9, and the fraction in bits~10--32. The fraction has an implied
binary point in front.  The value is given by 
\begin{eqnarray}
\mbox{value} &=& (-1)^{\mbox{sign}} \times 2^{\mbox{(exponent-127)}} 
\times \mbox{(1+fraction)}.
\end{eqnarray}

For regular IEEE 64-bit floating point numbers, the sign is contained in
bit 1, the exponent in bits 2--12, and the fraction in bits 13--64. The
fraction has an implied binary point in front.  
The value is given by 
\begin{eqnarray}
\mbox{value} &=& (-1)^{\mbox{sign}} \times 2^{\mbox{(exponent-1023)}} 
\times \mbox{(1+fraction)}.
\end{eqnarray}
Fraction bytes are in order of decreasing significance 
(i.e., the standard non-byte-swapped order). 

For example, suppose the single precision
8-bit byte pattern is {\tt 40400000}.  The sign bit is {\tt 0}, the 
exponent bit pattern is {\tt 100 0000 0} (or 128), and the fraction
pattern is {\tt 1} followed by 22 {\tt 0}s with a binary point in front,
or 0.5 decimal. The entire number 
is interpreted as 
\begin{eqnarray}
\ (-1)^0 \times 2^{\mbox{(128-127)}} \times 1.5  &=&  3.
\end{eqnarray}

The IEEE standard specifies in addition a variety of special exponent
and fraction values in order to support the concepts of plus and minus
infinity, plus and minus zero, ``denormalized'' numbers and
``not-a-number'' (NaN)\@.  The  {\tt BLANK} keyword of the original FITS
Agreement is thus unnecessary and should be omitted by FITS writers and
ignored by FITS readers when {\tt BITPIX}~=~$-32$ or~-$64$ (the NaNs of
the IEEE format will act as the blank). FITS writers should not write
the  {\tt BLANK} keyword if {\tt BITPIX}~=~$-32$ or~$-64$.  For
denormalized numbers, 1 is not added to the fraction, and the offset
subtracted from the exponent is one smaller than for regular numbers:
126 for single precision and 1023 for double precision.  This convention
allows IEEE floating point to represent numbers that are smaller than
those represented by the regularly defined values, although the number
of significant digits decreases for smaller values. All of these special
cases are fully accepted for FITS interchange.  Appendix~\ref{s:IEEEfp}
lists the kind of value, regular or special, represented by all possible
bit patterns.   
                                                                    
The {\tt BSCALE} and {\tt BZERO} values 
should be applied by FITS readers if they
differ from 1.0 and 0.0. However, scaling parameters should be used
carefully with floating point values, because of the risk of generating
overflows and underflows after scaling has been applied. 

\section{Random Groups}
\label{s:RanGrp}

The random groups structure (Greisen and Harten 1981)  was originally
designed for applications in radio astronomy but was intended for other
applications as well.  It never gained acceptance outside the radio
interferometry community, and some FITS readers designed for other
communities cannot read it. In addition, the random groups records are a
structural anomaly in FITS, as they are the only records that do not
conform to the primary HDU~--~extensions~--~special records sequence. 
All of the original objectives originally intended for random groups can
now be achieved through the use of the now standard binary table format
described in  section~\ref{s:bintab}.  Even the interferometry
community, for whom random groups was originally intended, is developing
new conventions based upon binary tables.  Do not create FITS files
using random groups; use binary tables instead.  The description of
random groups presented here is intended as a reference for those who
may have to read old random groups FITS files, not as an encouragement
to write them.  A number of keywords have been reserved for the random   
groups structure, and may not be used for any other purpose, unless
specifically stated in the FITS rules.  Also, the random groups
structure is the original source of the {\tt PCOUNT} and {\tt GCOUNT}
keywords that were incorporated into the Generalized Extensions rules
discussed in section \ref{s:exts}.           
                               
While the basic array structure of FITS can handle a data matrix when
the data are distributed evenly along all axes, sometimes the data may
not be distributed uniformly along one or more axes.  The random
groups structure was created to handle such situations. Instead of being
followed by a data array, the primary header is followed by a special
set of records, of standard FITS 23040-bit size, called random groups
records. These records contain a series of groups, each consisting of a
sequence of parameters followed by an array. The parameters carry the
data whose spacing is not uniform and which are not ordered, i.e.,
random, hence the name. The number of random parameters and the
dimensions of the array must be the same in all groups. 
       
On application is for {\em uv\/} interferometric visibility data; 
in fact, random groups are
sometimes referred to as UV FITS\@. Consider a set of weighted complex
fringe visibilities for the four Stokes polarizations at a sequence of
evenly spaced frequencies. The axes are {\em u}, {\em v}, {\em w}, hour
angle, baseline, fringe visibility information (real part, complex part,
and weight), Stokes parameter, and frequency. The points along the
frequency axis are evenly spaced, and the fringe visibility and Stokes
axes can both be handled by using ``evenly spaced'' integer index points
to represent the separate components -- real, complex, and weight -- for the
visibility and the four Stokes parameters. Thus, an individual
observation can easily be structured as a matrix with axes of visibility
components, Stokes parameter, and frequency. However, the individual
matrices are at nonuniformly distributed values of baseline, hour angle,
and ({\em u},~{\em v},~{\em w}). 
        
Using the random groups structure, the values of baseline, hour angle,
and ({\em u},~{\em v},~{\em w}) would be specified as parameters before
each (visibility, polarization, frequency) matrix. The combination of
parameters and array constitutes a group. The structure of the group
would be given by the form
\begin{equation}
|r_{1}, r_{2}, r_{3}, r_{4}, \ldots , r_{N}| 
    p_{111}, p_{112}, \ldots , p_{lmn}|
\end{equation}
corresponding, in this example, to
\begin{quote}
$|u, v, w$, time, baseline$|$(visibility component, Stokes parameter, 
	frequency)$|$ 
\end{quote}
where $r_{1}, \ldots ,r_{N}$
are random parameters $1$ through $N$ and 
$p_{111}, \ldots , p_{lmn}$
are pixel values in the order defined for
a data matrix. The value of $p$ could, in principle, be as
large as 998 for each axis, as opposed to 
the 999 maximum for Basic FITS\@.
The data array $p_{ijk}$ starts immediately after the last
parameter, $r_{N}$. The storage order and internal
representation of a random groups data array are the same as for a
Basic FITS simple array. It is interesting to note that the Basic FITS
data structure is actually a subset of this more general structure,
with no parameters. 


\subsection{Header}
One of the signatures of the random groups structure is that the
{\tt NAXIS1} keyword is set equal to zero. 
The {\tt NAXIS} and {\tt NAXIS}$n$ keywords
will therefore have somewhat different meanings than in Basic FITS. 

\subsubsection{Required Keywords}

The keywords required for an ordinary array are also required for
random groups, in the same order. 

\begin{enumerate}

\item {\tt SIMPLE} (logical) ``{\tt T}'' indicates 
a file in conformance to standard FITS.

\item {\tt BITPIX} (integer) describes the representation of the values
of the individual arrays and of the parameters. The parameters must be
of the same data type as the array members. The values have the same
meaning as for Basic FITS.     

\item {\tt NAXIS} (integer) is one more than the number of axes in each
array (because {\tt NAXIS1} is used as a groups indicator instead of an
actual axis). The largest possible value is 999, representing 998 axes. 
                              
\item {\tt NAXIS1} (integer) is set to 0 
to indicate that no primary data array follows the primary header. 

\item {\tt NAXIS}$n$, $n=2, \ldots ,$ {\tt NAXIS} (integer) 
is the number of elements along
axis~$n-1$ of the array. The index varies most rapidly along the 
$n=2$ axis, least rapidly along the $n=$NAXIS axis. 

\end{enumerate}

There must be no other keywords between the ones listed above.
\smallskip
Additional keywords follow, which must include among them
\smallskip

\begin{itemize}

\item {\tt GROUPS} (logical) must have  the value ``{\tt T}'', to
indicate that the data records following the primary data array are
random groups. 
                             
\item {\tt PCOUNT} (integer) is 
the number of parameters preceding each data array.

\item {\tt GCOUNT} (integer) is the number of groups 
(parameters + array) in the random groups records. 

\item {\tt END} (no value) is the last keyword. 
The header is filled with ASCII blanks.

\end{itemize}

The {\tt PCOUNT} and {\tt GCOUNT} keywords 
tell the reader the number NBITS of bits in the
random groups records exclusive of fill: 
\begin{eqnarray}
\mbox{NBITS} & = & 
      \mbox{ABS(BITPIX)} \times \mbox{GCOUNT} \times \nonumber \\ 
         & & (\mbox{PCOUNT} + \mbox{NAXIS2} \times \mbox{NAXIS3} 
            \times \cdots \times \mbox{NAXIS$m$}),
\end{eqnarray}
where $m$ is the value of {\tt NAXIS}.
            
\subsubsection{Random Parameter Reserved Keywords}
\label{s:resrgr}

The random parameters may be labeled and scaled in a fashion similar
to the members and axes of a Basic FITS array, using the keywords
{\tt PSCAL}$n$ and {\tt PZERO}$n$: 
\begin{eqnarray}
\mbox{physical\_value} &=&
      (\mbox{FITS\_value}) \times \mbox{PSCAL$n$} + \mbox{PZERO$n$}.
\label{eq:pscal}
\end{eqnarray}

The following keywords are reserved for describing random parameters.

\begin{itemize}

\item {\tt PTYPE}$n$ (character) is the name of the quantity
represented by the $n$th random parameter. 

\item  {\tt PSCAL}$n$ (floating) gives the scale factor for random
parameter $n$. If this keyword is  absent, the scale factor is assumed
to be 1.
                                          
\item {\tt PZERO}$n$ (floating) gives 
the offset for random parameter $n$.
If this keyword is absent, the offset is assumed to be zero. 

\end{itemize} 

Even though the random parameters must have the same data type as the
array elements, greater precision can be achieved in the random
parameters than in the data array through the use of repeated  
{\tt PTYPE}$n$ keywords. If more than one {\tt PTYPE}$n$ keyword has the
same value, then the parameters associated with all those {\tt PTYPE}$n$
keywords are being used to represent the same quantity. The value of
that quantity is derived by summing the true values derived for the
parameters $n$ corresponding to those  {\tt PTYPE}$n$ keywords -- the
values derived using the stored values and the {\tt PSCAL}$n$ and 
{\tt PZERO}$n$ values. For example, if 
                                         
\begin{quote}
\begin{verbatim}

PTYPE1  = 'GLON    '
PTYPE2  = 'GLON    '
PSCAL1  =                  1.0
PSCAL2  =              1.0E-04

\end{verbatim}
\end{quote}

where {\tt GLON} stands for Galactic longitude, then the value of
Galactic longitude for each group is derived by adding the value of the
first random parameter for that group to 10$^{\rm -4}$ times the value
of the second random parameter.
                  
The rules governing units in random groups are the same as those for
a primary data array, as given in section \ref{s:units}. 



\subsection{Data Records}

The data records begin in the first record following the last header
record, similarly to the way a primary data array is stored. The first
parameter of the first group is at the start of the first data record.
The first member of the array in each group follows the last parameter,
with no spaces or fill. It does not start a new record. Similarly, each
parameter-array group immediately follows the previous one; a new group
need not begin a new record. The same data types are allowed as for
Basic FITS\@. The data type for the random parameters {\em must\/} be
the same as the data type for the data arrays. 
                                                    
      
\section{Extensions}
\label{s:exts}

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\o l {\em 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 {\tt SIMPLE} keyword, which is
replaced by an {\tt XTENSION} keyword, the header must use the
keywords required for the Basic FITS primary header
(section~\ref{s:reqkey}). 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 {\tt SIMPLE}
keyword of the primary header should have the value {\tt T}.            
           
Two basic rules govern all existing extensions and serve as the
foundation for the more detailed requirements for generalized
extensions: 

\begin{itemize}

\item All FITS extensions must appear after the main FITS header and
its associated primary data array. 

\item Each extension begins at the start of a new 2880-byte record.

\end{itemize}

The generalized requirements for FITS extensions are as follows:

\begin{itemize}

\item 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. 
                                   
\item Only the binary and character coding conventions specified in the
original FITS papers and the Floating Point Agreement should be used
in FITS extensions. 

\item It should be possible to append any number of extensions to a
primary header and its associated data array. 

\item If there is more than one type of extension in a FITS file, then the
extensions may appear in any order. 

\item 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. 

\item 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. 

\item 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. 
          
\item It must be possible to devise new types of extensions without
prior approval. {\em 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. 

\item 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.

\item 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~\ref{s:reskey} about
the {\tt BLOCKED} keyword). 
        
\end{itemize}

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: 

{\tt EXTEND} (logical) if true ({\tt T}) indicates that there 
{\em 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 {\tt EXTEND}~=~T, the primary HDU alone can be
copied unchanged. A value of {\tt F} has no meaning and should not be
used. The {\tt EXTEND} keyword must immediately follow the last 
{\tt NAXIS}$n$ keyword or an {\tt 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 
{\tt EXTEND} = T and  {\tt NAXIS} = 0 to indicate no primary data array. 
Examples 3 and 6 in Appendix \ref{s:ex} illustrate FITS primary headers
with no data that occur at the start of files where all the data are in
extensions.                                                         
                    
\subsection{Required Keywords for an Extension Header}
\label{s:extreq}

The first keywords of a FITS extension header, from {\tt XTENSION} to
the last {\tt NAXIS}$n$, {\em must\/} appear consecutively in the order
listed below.                          
                       
\begin{enumerate} 

\item {\tt XTENSION} (character) indicates the type of extension. This
keyword must appear on the first card image in the header. With this
keyword at the front, any software can immediately read the extension
type and determine whether or not it is a type that the software can
handle. 

\item {\tt BITPIX} (integer) gives 
the number of bits per ``pixel'' value. The
values allowed are the same as those for the primary data array.

\item {\tt NAXIS} (integer) gives  the number of ``axes'' or analogous
structures; a value of zero is allowed, which indicates there are no
data records in the current extension. The maximum possible value is
999. Negative values are not allowed.        

\item {\tt NAXIS}$n, n=1, \ldots,$ {\tt NAXIS} (integer) 
      ({\tt NAXIS$n$}=0 for any $n$ implies that the extension has no
      data) is the number of array elements along the $n$th
      axis or its analog.                 
          
\end{enumerate}

In order to allow FITS readers that are unfamiliar with an extension
to skip it, a header must specify the size of the extension in bits.
To do so, two parameters, 
{\tt PCOUNT} and {\tt GCOUNT}, are defined in the header: 

\begin{itemize}

\item {\tt PCOUNT} (integer) - The value may be zero.  Note that
although this keyword originated in the Random Groups
(section~\ref{s:RanGrp}) rules, the interpretation for an extension
may be different.

\item {\tt GCOUNT} (integer) - 
If simple image-like data (e.g., a table) are being
written, its value will be 1. 

The {\tt PCOUNT} and {\tt GCOUNT} keywords  may appear anywhere between
the last {\tt NAXIS}$n$  (or {\tt NAXIS}=0) ~keyword and the {\tt END}
keyword.  The best place is immediately after the last {\tt NAXIS}$n$
keyword; the existing standard extensions require that location, but
otherwise software to read FITS files should not assume they will be
there. They may be defined in any way that, along with the {\tt BITPIX}, 
{\tt NAXIS}, and {\tt NAXIS}$n$ values, gives the correct data size
using the following formula to derive NBITS, the number of bits
excluding fill:
\begin{eqnarray}
\mbox{NBITS} &=& 
     \mbox{ABS(BITPIX)} \times \mbox{GCOUNT} \times \nonumber \\
      & & (\mbox{PCOUNT} + \mbox{NAXIS1} \times \mbox{NAXIS2} 
            \times \cdots \times \mbox{NAXIS$m$})
\label{eq:extsiz}
\end{eqnarray}
where $m$ is the value of {\tt NAXIS}\@. NBITS may not be negative.

The number NRECORDS of data records following the header record is
then given by 
\begin{equation}
\mbox{NRECORDS} = \mbox{INT}[(\mbox{NBITS} + 23039)/23040)].
\end{equation}

Rules for individual extensions may place further restrictions on the
position of the {\tt PCOUNT} and {\tt GCOUNT} keywords.
                     
{\tt END} is always the last keyword in a header. The remainder of the
record following the {\tt END} keyword is filled with ASCII blanks. 

\end{itemize}

The data begin at the start of the first record following the last
record of the header.

\subsection{Reserved Keywords for Extension Headers}
\label{s:extres}

These keywords are not required but, if used, must have the meaning 
and syntax defined here.  They may appear anywhere between the 
required keywords and the {\tt END} keyword.  These keywords are
reserved for all extension headers and need not be specifically reserved
for an individual new extension.

\begin{itemize}

\item {\tt EXTNAME} (character) can be used  to give a name to the
extension to distinguish it from other extensions of the same type. For
example, if there are several tables on a tape, they could be
distinguished by their values of {\tt EXTNAME}\@.  The name may have a
hierarchical structure giving its relation to other files  (e.g.,
``map1.cleancomp''). Remember, however, that the reader should be able
to retrieve the data  properly using only the first eight characters of
the string. Conventions for hierarchical structures of extension names
have not been established.                

The distinction between the name and the type is that the type, the value
of {\tt XTENSION}, describes the structure of the extension, while 
the value of {\tt EXTNAME} provides a name for the extension but says
nothing about its structure.  For example, the header for an ASCII table
containing information about Seyfert galaxies could have
\verb+XTENSION = 'TABLE   '+ and {\tt EXTNAME  = 'SEYFERTS'}. 

\item {\tt EXTVER} (integer) is a version number 
which can be used with {\tt EXTNAME} to
identify an extension. The default value is 1.

\item {\tt EXTLEVEL} (integer) specifies the level of the extension in
a hierarchical structure. 
The default value for {\tt EXTLEVEL} should be 1. 

\end{itemize}

Because the term ``type'' refers to the structure of an extension as
given by the value
of {\tt XTENSION}, user definition of a {\tt EXTTYPE} keyword is not
recommended, though not strictly forbidden by the FITS rules. 

As a sample application of hierarchical structure, consider an observing
session in which several objects are observed. In addition to the actual
observations, other information, say, about the observing system
configuration or physical state, might be present. Some information
might apply to the entire observing session, while other information
would apply only to the observations of an individual object. In this
case, an extension  at {\tt EXTLEVEL}~=~1 could contain the information
applying to the entire observing session as part of the header, while
some information about the observations of individual objects could
appear in the associated data in a master table. Each row in the master
table would contain information about the observations of one object.
One entry in each row would be the name of a table containing
observations of that object. The observations would appear in separate
table extensions with  {\tt EXTLEVEL}~=~2 and  {\tt EXTNAME} equal to
the name given in the master table. This concept has yet to be
implemented in data for archive or distribution, and any software to
support it is still in the developmental stage.
            
The grouping proposal, discussed in section \ref{s:Grping}, describes an
alternative method of creating hierarchies.     

\subsection{Creating New Extensions}

Use an existing standard extension type if you can; to do so
facilitates use of existing analysis packages. New extension types are
necessary only when information is organized in a way that existing
extension types can't handle.  Before starting to develop a new
format, check with the FITS Support Office or IAUFWG to see if an
existing or developing extension can be used to organize your data. 
Inquiries on {\tt sci.astro.fits} (section \ref{s:NRAOFITS}) may also be
helpful. If a new proposed extension type under development can be used,
coordinate what you do with the developer. If a totally new extension is
needed, try to design an extension that has as
general an application as possible, with the eventual goal of adoption
as a new standard extension. The type name of any new extension must be
registered with the IAUFWG and be different from any already registered.
The FITS Support Office maintains the current list. Special purpose
extensions restricted to particular projects, with the exception of
prototypes for more general designs, should be avoided.                         
                    
\vfill

\section{ASCII Table Extension}

Astronomical data are frequently organized in tables, for example, a
standard source catalog or the results of a series of observations.
Another use for tables is to hold information related to observations,
such as observing logs and calibration data, which are more
conveniently transported in a table accompanying the observations than
as keywords. Not surprisingly, the first standard extension developed
and endorsed by the IAU was that for
tables (Harten~{\em et~al.}~1988). This ASCII table
extension uses ASCII records to carry the information.

The data appear as a character array, in which the rows
represent the lines of a table and the columns represent the
characters that make up the tabulated items. Each member of the array
is one character or digit. Each row consists of a sequence of fields.
The sequence of fields is the same for all rows, and all rows must
have the same length. Each field in the table contains one item in the
table, either a character string or the ASCII representation of a
number in FORTRAN-77 format. A particular field may consist of many
columns, as many as are needed to carry the full string or number.

The field organization is described by a series of keywords. These
keywords describe the initial column and number of columns for each
field. Other kinds of information that can be listed in the header
include the units of quantities in the field, scale factors between
the values in the table and the physical quantities they
represent---analogous to the {\tt BZERO} and {\tt BSCALE} values of
Basic FITS---and the string used to represent an undefined value. Fields
in the table may be reserved for comments, which would be skipped by
automatic decoding software but may be read by simply printing the
table. This property allows the transfer of tables that contain a large
quantity of comments.  Examples 3 and 5 illustrate ASCII table headers.     
                                                              
\subsection{Required Keywords for ASCII Table Extension}
\label{s:reqtab}

The following keywords are {\em required\/} for ASCII table extensions
and {\em must\/} appear in the first eight card images in the following
order:

\begin{enumerate}

\item {\tt XTENSION} (character) has 
the value \verb+'TABLE   '+ for ASCII table extensions.

\item {\tt BITPIX} (integer) must have the value of 8, indicating
printable ASCII characters. 

\item {\tt NAXIS} (integer) must have the value of 2 for ASCII table
extension headers. The axes are the rows and columns of the table.

\item {\tt NAXIS1} (integer) gives the number of characters in a table
row.

\item {\tt NAXIS2} (integer) gives the number of rows in the table.
The value can be 1. While a value of zero is permitted, that value
would indicate that no table is present. 

\item {\tt PCOUNT} (integer) is required 
with the value of 0 for the ASCII table extension.

\item {\tt GCOUNT} (integer) is required with the value of 1 for the
ASCII
table extension. Each extension contains one table; the total number
of bytes is NAXIS1 $\times$ NAXIS2. 

\item {\tt TFIELDS} (integer) has a value that gives the number of fields
in each table row. Values from 0 to 999 are allowed. 

\end{enumerate}

Note that while the rules for generalized extensions do not specify where
the {\tt PCOUNT} and {\tt GCOUNT} keywords appear between the last
{\tt NAXIS}$n$ keyword and the {\tt END} keyword, the ASCII table
extension requires that they appear immediately after the {\tt NAXIS2}
keyword.


The following required keywords may appear anywhere between the
{\tt TFIELDS} and the {\tt END} keywords. 

\begin{itemize}

\item {\tt TBCOL}$n$ (integer) is 
the column number of the first character in field
$n$. The first column of a row is numbered 1. 

\item {\tt TFORM}$n$ (character) is  the FORTRAN format of 
field $n$ (I, A, E, D, F)\@. To repeat a field, the format must be
repeated using separate {\tt TFORM}$n$  and {\tt TBCOL}$n$ card images;
the repeat count (e.g., 2Fx.x) of FORTRAN cannot be used. The 
{\tt TFORM}$n$ values specify the width of the field and are of the form
Iw, Aw, Fw.d, Ew.dEe, or Dw.dEe (integers, characters, single precision
floating point, single precision exponential, and double precision
exponential, respectively). The $w$ is the width of the field, $d$
the number of digits after the decimal point, and $e$ is the number of
digits in the exponent, as in FORTRAN\@. For integer
fields, if $-0$ needs  to be distinguished from $+0$ (e.g., degrees of
declination), the sign will have to be a separate character field. It is
better to use floating point. {\tt TBCOL}$n$ and {\tt TFORM}$n$ keywords
must be present for values of $n$ from 1 to the value of {\tt TFIELDS}. 
                  
\end{itemize}

{\tt END} is always the last keyword;  the remainder of the header
record is filled with ASCII blanks.
                 
\subsection{Reserved Keywords for ASCII Table Extension}

\label{s:restab}

These keywords may be used, in addition to the required keywords
described in section~\ref{s:reqtab}, to  describe the structure of ASCII
table data. They are not required, but if they are used in an ASCII
table header, they must be used as described here. These keywords should
not be used in other extensions unless they have a function analogous to
the one they have in the ASCII table extension. They may appear
anywhere between the {\tt TFIELDS} and {\tt END} keywords, in any order.     

\begin{itemize}

\item {\tt TTYPE}$n$ (character) is the heading for field $n$. The
recommended characters are letters, digits, and underscore. Upper case
values are preferred, but lowercase
letters may be used, and string comparisons involving the values
of {\tt TTYPE}$n$ keywords should not be case sensitive. The hyphen
is permitted but {\em not\/} recommended. While more
than one field may have the same heading (value of {\tt TTYPE}$n$), the
practice is not recommended. 

\item {\tt TUNIT}$n$ (character) is the physical units of field $n$.
The rules governing the units to be used in ASCII tables are the same
as those for a primary data array, as given in section~\ref{s:units}. 

\item {\tt TSCAL}$n$ (floating) is the scale factor for field $n$, as 
applied in equation~\ref{eq:tscal}. The default value is 1.0.

\item {\tt TZERO}$n$ (floating) is the offset for field $n$ 
(see equation~\ref{eq:tscal}). The default value is 0.0. 
\begin{eqnarray}
\mbox{Physical\_value} & = &
      (\mbox{Stored\_value}) \times \mbox{TSCAL$n$} + \mbox{TZERO$n$}.
\label{eq:tscal}
\end{eqnarray}
Note:~{\tt TSCAL}$n$ and {\tt TZERO}$n$ may not be 
used for A-format fields.

\item {\tt TNULL}$n$ (character) is the representation of an undefined
value.  The string chosen does not have to be readable in the
format specified by {\tt TFORM}$n$; for example, a null value of 
'{\tt ***}' might be used for an I3 field.  If the null string given as
the value of the keyword does not fill the field, it is assumed to begin
at the start of the field, and the part of the field following the
string is assumed to be filled with blanks.  A table will be more
efficiently read if {\tt TNULL}$n$ is specified only when null values
actually exist in the field, thus avoiding unnecessary string
comparisons for the other fields.                        
   
\end{itemize}

\subsection{Data Records in an ASCII Table Extension}

The table data records begin with the record immediately following the
last header record. Each record contains 2880 ASCII characters in the
order defined by the header.  The first entry of each row immediately
follows the last entry of the previous row, and table entries do not
necessarily begin at the beginning of a new record.  After the end of
the valid data, the last record should be filled with ASCII blanks. The
table consists of NAXIS2 rows of length NAXIS1.  Entries are in the
FORTRAN-77 formats specified in the associated header. A-format fields
should be encoded as plain text, without being encoded in string quotes.
Numbers decoded with the I~format may exceed the 16-bit integer range.
Blank characters in a field are not interpreted as zeroes; all zeroes,
even trailing zeroes, must be explicit. This rule is equivalent to
setting the FORTRAN-77 OPEN statement specifier BLANK to NULL.
                                                               
The $w$ in the value of {\tt TFORM}$n$ specifies the width of field $n$.
Field $n$ begins in the position  given by the value of {\tt TBCOL}$n$
and includes $w$ characters. The sum of the widths of the different
columns need not equal the value of {\tt NAXIS1}, the length of a row.
However, no field may extend beyond the end of the row, to column
numbers greater than the value of {\tt NAXIS1}. Blank columns may be
included between fields, a good practice that
enhances readability.                

\section{The Image Extension}

While multiple arrays of the same data type can be combined into a
single array by adding another dimension, there are cases where arrays
related to the main data array may have different data types, for
example, arrays of flags or weights.  Arrays of values with different
data types can in principle be stored in the same file by making them
different array fields in the same row of a binary table 
(section~\ref{s:multin1}), but, in practice, many find it simpler to put
the arrays containing data types different from the primary data array
in separate  extensions. For this purpose, the IUE project developed the
image extension type (Ponz, Thompson, and Mu\~{n}oz 1994). 
                         
\subsection{Header}

The image extension follows the rules for required keywords in
extensions stated in  section~\ref{s:extres}. The first keywords of a
FITS image extension header, through {\tt GCOUNT}, {\em must} appear
consecutively in the order listed below.                                       
              
\begin{enumerate} 

\item {\tt XTENSION} (character) has the value \verb*+'IMAGE   '+ for
image extensions. 

\item {\tt BITPIX} (integer) provides the number of bits per ``pixel''
value. The values allowed are the same as those for the primary data
array.
             
\item {\tt NAXIS} (integer) is, for an image extension, the number of
axes in the extension data array.  A value
of zero is acceptable and indicates that no data are associated with
the current header.  The
maximum possible value is 999. Negative values are not allowed. 

\item {\tt NAXIS}$n$, $n=1, \ldots ,${\tt NAXIS} 
({\tt NAXIS}=0 --$>$ {\tt NAXIS1} not present)
(integer) is the number of elements along axis~$n$ of the array.  The
{\tt NAXIS}$n$ keywords in an image extension are governed by the
same rules as those in a primary header. 

\item {\tt PCOUNT} (integer) has the value 0 for image extensions.

\item {\tt GCOUNT} (integer) has the value 1 for image extensions.

\end{enumerate}

(\ldots the other keywords follow until\ldots)

{\tt  END} (no value)  The last keyword must be {\tt END}. This
card image has no ``{\tt =}'' in column 9 or value field but is filled
with ASCII blanks. 

The remainder of the last header record should be filled with ASCII
blanks. 

Note that while the rules for generalized extensions do not specify where
the {\tt PCOUNT} and {\tt GCOUNT} keywords are located between the
last {\tt NAXIS}$n$ and the {\tt END} keywords, the image extension
rules require that they appear immediately after the last {\tt
NAXIS}$n$ card image.

\subsection{Data Records}
    
The rules for the data in image extensions
are the same as for the primary data array (section~\ref{s:PrimDat}).
An image extension header cannot be followed by random groups
records.

\section{Binary Tables}
\label{s:bintab}

With the development of the IEEE-754 standard for floating point
numbers, it became possible to incorporate binary values in tables. 
Tables with binary values are more compact, and the time spent
converting from ASCII is eliminated, although display is not as direct
as for ASCII tables.  In developing the binary table design, a provision
was made that a particular field or entry in the table could be a
vector, not just a single number.  The resulting binary table extension
(Cotton, Tody, and Pence~1995; hereafter CTP) was endorsed by the IAUFWG
in 1994. Like an ASCII table, a binary table contains a two-dimensional
data matrix mapped into the rows and columns of a table. The entries,
the values associated with a given row and column, are stored in one of
several prescribed binary formats, rather than coded into ASCII.  For
each field there is a repeat count, which is one for a single entry and
larger if the entry is to be a vector.  This main table may be followed
by additional data.                                            
                                            
Appendixes to the paper proposed three additional conventions: one to
handle fields where the length of an array might vary, one to allow the
vector in a field to be interpreted as a multidimensional array, and one
for delimiting arrays of strings.  While the Working Group endorsement
of binary tables did not include these conventions, the rules that were
adopted reserved a number of keywords and values specifically intended
for use by these conventions.  These conventions are discussed in
section~\ref{s:BinCon}.

In a binary table, each row consists of a series of entries in formats
specified by the header keywords. The header describes the size
and data type of each entry, and, optionally, provides a label, units,
and the representation for an undefined value where applicable. The
length and field structure of all rows of the main table in a
particular binary table extension must be the same. 

Every row in a particular binary table contains the same number of
entries, although the number can vary from one binary table extension
to the next in a FITS file. The header is a standard FITS extension
header. For each table entry it specifies 

\begin{enumerate}

\item The size and data type of the entry.

\item A label (optional).

\item The units (optional).

\item The representation of an undefined value (optional). 

\end{enumerate}

An entry may be omitted from the table but still defined in the header
by using a zero repeat count in the value of the {\tt TFORM}$n$
keyword.  Examples 4, 6, and 7 in Appendix \ref{s:ex} illustrate binary
tables.

\subsection{Required Keywords for Binary Table Extension Headers}
\label{s:Binreq}

The extension follows the rules for required keywords stated in 
section~\ref{s:extres}. The first eight keywords must appear
consecutively in the following order: 
              
\begin{enumerate}

\item {\tt XTENSION} (character) has the value 
{\tt 'BINTABLE'} for binary table extensions 

\item {\tt BITPIX} (integer) must have a value of 8. A binary table is
an array of bytes. 

\item {\tt NAXIS} (integer) must have a value of 2 for binary table
extensions. As with ASCII tables, the axes are the rows and columns of
the table.                        

\item {\tt NAXIS1} (integer) has a value equal to the number of 8-bit
bytes in a table row. 

\item {\tt NAXIS2} (integer) has a value equal to the number of rows
in the table. Values of 0 (no table) and 1 (one row), are allowed as 
well as larger values.

\item {\tt PCOUNT} (integer) is equal to the number of bytes in the
binary table extension data following the main table.  Note that this
meaning is significantly different from that in the rules for random
groups (section~\ref{s:RanGrp}).  This usage was designed for 
the variable length convention discussed in
section~\ref{s:varlen}.  While conflicting
uses would not be against the formal FITS rules, they would create
confusion and should be avoided.  Non-conflicting uses may be
developed for other conventions.  

\item {\tt GCOUNT} (integer) has the value of 1 for binary table
extensions.

The total number of bytes is PCOUNT + NAXIS1$\times$NAXIS2. 

\item {\tt TFIELDS} (integer) has a value equal to the number of
entries (fields) in each row of the table. 

\end{enumerate}

Also required, between the {\tt TFIELDS} and {\tt END} keywords, are
{\tt TFORM}$n$ keywords for \mbox{$n$=1, \ldots,TFIELDS}. 

{\tt TFORM}$n$ (character) has a value specifying the width and data
type of field $n$ and is of the form $rT$, where $T$ is the field type
and $r$ is the repeat count that tells how many values of type $T$ the
field contains. The value of $r$ gives the number of members in the
array that table item contains. If the repeat count is absent, it is
assumed to be 1. A repeat count of zero is permitted. Additional
characters may follow the data type code. While these characters are not
defined in the formal {\tt BINTABLE} rules, the variable length array
and string array conventions make particular interpretations, and
conflicting uses should be avoided, to prevent confusion.   The
following values of $T$ are permitted:                                 

\begin{description}

\item[L] Logical value.

\item[X] Bit array.

\item[A] Character.
The substring array convention (section~\ref{s:arrstr}) uses the 
characters {\tt :SSTR} immediately following the $rA$ to indicate that
the convention is being used to describe the substrings.  This usage
implies that a colon and different standard character string following the
$rA$ can be used as an indicator of other conventions for describing
character fields. While the formal FITS rules do not prohibit other uses,
such conflicting usage could be confusing and is to be avoided. 

\item[B] Unsigned 8-bit integer or byte.

\item[I] Signed 16-bit integer.

\item[J] Signed 32-bit integer.

\item[E] Thirty-two bit IEEE floating point.

\item[D] Sixty-four bit IEEE floating point.

\item[C] Complex pair of single precision floating point values.

\item[M] Complex pair of double precision floating point values.

\item[P] Sixty-four bit descriptor of variable length arrays (pointer).
The only allowed repeat counts are 0 and 1. This data type was designed
to contain information on the location of data in variable length arrays
(section~\ref{s:varlen}).  When used to indicate a variable length
array, the value takes the form {\tt rPt(maxelem)}, where {\tt r} is
the repeat count, {\tt t} is any of the data types discussed here except
P, and {\tt maxelem} is an integer.  While the binary table rules do not
specifically forbid the use of this data type for other purposes, any
use that conflicts with the variable length convention would cause
confusion and is to be avoided. 
                                 
\end{description}

For example, {\tt TFORM4~~=~'16E~~~~~'} means that the
fourth field of
the table will consist of 16 32-bit floating point values. The repeat
count represents a major enhancement over ASCII tables, where a field
can contain only one value. The number of bytes in a row is the sum of
the number of bytes in the individual fields and must equal the value of
{\tt NAXIS1}. Note that this rule differs from ASCII tables, which allow
the value of {\tt NAXIS1} to be greater than the sum of the 
{\tt TFORM}$n$. 
                                       
As with ASCII tables, to distinguish $-0$ from $+0$ in integer format,
for example in degrees of declination, the sign field should be declared
as a separate character field.  This
separation is unecessary for floating point. 

{\tt END} must always be the last keyword.  The remainder of the last
header record must be filled with ASCII blanks.

Note that while the rules for generalized extensions do not specify
where the {\tt PCOUNT} and {\tt GCOUNT} keywords are located after the
last {\tt NAXIS}$n$ keyword, the rules for binary table extensions
require that they appear between the {\tt NAXIS2} and {\tt TFIELDS}
keywords.       
                                                            
\subsection{Reserved Keywords for Binary Table Extension Header}

These keywords are optional in a binary table extension but may be used
only with the meanings specified below. They may appear in any order
between the {\tt TFIELDS} and {\tt END} keywords. Note that some of
these keywords are the same as those for an ASCII table extension. The
reason is that they are used for a binary table in a way analogous to
their use for an ASCII table. However, the allowed values and their
meaning may differ somewhat from those for an ASCII table, as the rows
of an ASCII table are composed of characters and those of a binary table
are composed of bytes. 
 
\begin{itemize}

\item{\tt TTYPE}$n$ (character) has a value giving the label or
heading for field $n$.  While the rules do not further prescribe the
value, following the recommendations for the {\tt TTYPE}$n$ keyword of
ASCII tables is a good practice: using letters, digits, and underscore
but not hyphen; also, string comparisons involving the values should
be case insensitive.  HEASARC has made this practice one of their
internal standards (section \ref{s:HFWGchar}). 

 \item{\tt TUNIT}$n$ (character) has a value giving the physical units of
field $n$.  The rules should follow the prescriptions given in
section~\ref{s:units}. 
                                                        
\item {\tt TSCAL}$n$ (floating) has a value providing a scale factor
for use in converting stored table values for field $n$ to physical
values. The default value is 1. 

\item {\tt TZERO}$n$ (floating) has a value providing the offset for
field $n$. The default value is 0. 
\begin{eqnarray}
\mbox{(Physical\_value)} & = &
      \mbox{(Stored\_value)} \times \mbox{TSCAL$n$} + \mbox{TZERO$n$}.
\end{eqnarray}

As is the case for arrays, care should be taken to avoid overflows when
scaling floating point numbers.

For L, X, and A format fields, the {\tt TSCAL}$n$ and 
{\tt TZERO}$n$ keywords have no meaning and should not be used.  The
meaning has not been formally defined for P format fields, but the
general understanding is that the scaling should apply to the heap data
pointed to by the array descriptors.

\item {\tt TNULL}$n$ (integer) has the value that signifies an 
undefined value for the integer data types B, I, and J. It should not
be used if the value of the corresponding {\tt TFORM}$n$ specifies any
other data type. Null values for other data types are discussed in
section~\ref{s:bintyp}. 

\item {\tt TDISP}$n$ (character) has a value giving the Fortran 90
format recommended for display of the contents of field $n$. (If
Fortran 90 formats are not available to the software printing a table,
FORTRAN-77 formats may be used instead.) All entries in a single field
are displayed with the same format. If the field data are scaled, the
physical values, derived by applying the scaling transformation, are
displayed. For bit and byte arrays, each byte is considered to be an
unsigned integer for purposes of display. Characters and logical values
may be null (zero byte) terminated. The following formats are
allowed:

\begin{description}

\item[Lw] Logical

\item[Aw] Character 

\item[Iw.m] Integer

\item[Bw.m] Binary, integers only

\item[Ow.m] Octal, integers only 

\item[Zw.m] Hexadecimal, integers only, 

\item[Fw.d] Single precision real, no exponent

\item[Ew.dEe] Single precision real, exponential notation

\item[ENw.d] Engineering format -  single precision real, exponential
notation with exponent a multiple of 3

\item[ESw.d] Scientific format - single precision real, exponential
notation with exponent a multiple of 3, nonzero leading digit (unless
value is zero)

\item[Gw.dEe] General - appears as F format if significance will not be
lost; otherwise appears as E 

\item[Dw.dEe] Double precision real, exponential notation

\end{description}

In these formats, $w$ is the number
of characters in the displayed values, $m$ is the minimum number of
digits (leading zeroes may be required), $d$ is the number of digits
following the decimal point, and $e$ is the number of digits in the
exponent of an exponential form. Usage of this keyword in some ways
parallels that of the {\tt TFORM}$n$ keyword of ASCII tables, in that
it provides a formatted value for the number. However, the format given
by the {\tt TFORM}$n$ keyword in an ASCII table describes the format
of the number in the FITS file, but the format given by the 
{\tt TDISP}$n$ keyword of a binary table is different from that of the
number in the file. 

\end{itemize}

The following keywords are reserved for proposed binary table
conventions:

\begin{itemize}

\item {\tt TDIM}$n$ (character) is used by the multidimensional array
convention (section~\ref{s:multi}). For that convention, it has a value
giving the number of dimensions of field $n$ in the table, when those
dimensions are two or more. The value is of form {\tt '(i,j,k,...)'}, 
where $i$,$j$,$k$,\ldots  are the dimensions of the array stored in
field $n$. This size must be consistent with the repeat count specified
by the value of {\tt TFORM}$n$. 
                                                            
\item {\tt THEAP} (integer) is used by the variable length array
convention (section~\ref{s:varlen}). For that convention, its value
gives the location of the start of the heap used to store variable
length arrays. The value is equal to the number of bytes of extension
data preceding the start of the heap, including the main table and any
gap between the main table and the heap.                                       

\end{itemize}

All keywords reserved under the generalized extensions agreement
(section~\ref{s:extres}) apply to binary tables. 

\subsection{Binary Table Extension Data Records}
\label{s:bintyp}

The data records in a binary table consist of the main data table and
possibly additional data after the main table.
The {\tt BINTABLE} main table logical data records
begin with the record immediately following the last header record. Each
record contains 2880 8-bit bytes in the order defined by the header.
Table rows do not necessarily begin at the beginning of a new record.
The size of the main table is the product of the values of the 
{\tt NAXIS1} and {\tt NAXIS2} keywords.  The additional data begin
immediately after the end of the main table; they do not start at the next
record.  The last record of the data should be zero filled past the end of
the valid data, with all bits cleared.  If there are no additional data after
the main table, this record will be the last record of the main table; if
there are additional data, this record will be the last record of the
additional data.

The data types are defined as follows:

\begin{description}

\item[L] A logical value consists of an ASCII ``T'' indicating true or
``F'' indicating false. A null character (zero byte) signifies an
invalid value. 

\item[X] A bit array starts in the most significant bit of the byte,
and the subsequent bits are in the order of decreasing significance in
the byte. A bit array field in a binary table consists of an integral
number of bytes with those bits that follow the array set to zero.  No
specific null value is prescribed for bit arrays, but the following
three conventions are suggested:      
                                                
\begin{itemize}

\item Designate one bit of the array to be a validity bit.

\item Add a type L field to the table to indicate the validity of the
bit array. 

\item Add a second bit array which contains a validity bit for each of the
bits of the original array.

\end{itemize}

Use of any of these conventions will be a decision of an individual
project or particular group of FITS users. Do not expect that general
software to read FITS will necessarily be able to interpret them. 

\item[B] An unsigned 8-bit integer has the bits in decreasing order of
significance. By applying scaling, this field may be used to store
quantities whose physical values are signed. 


\item[I] A 16-bit integer is a twos-complement integer with the bits in
decreasing order of significance. 

\item[J] A 32-bit integer is a twos-complement integer with the bits in
decreasing order of significance. 

\item[A] Character strings consist of 8-bit ASCII characters in their
natural order. An ASCII NULL (hexadecimal {\tt 00}) character may be
used to terminate a character string before the length specified by the
repeat count is reached. Strings occupying the full length of the field
are not NULL terminated. An ASCII NULL as the first character signifies
a NULL (undefined) string. The printable ASCII characters, that is,
those in the range hexadecimal 20-7E, and the ASCII NULL after the last
valid character are the only ones permitted.             

\item[E] Single precision floating point values are in IEEE 32-bit
precision format, as described in section~\ref{s:IEEEflt}. 

\item[D] Double precision floating point values are in IEEE 64-bit
precision format, as described in section~\ref{s:IEEEflt}. 

\item[C] A complex value is composed of a pair of IEEE 32-bit floating
point values: the first is the real part and the second the imaginary
part. 

\item[M] A double precision complex value is composed of a pair of
IEEE 64-bit floating point values: the first is the real part and the
second the imaginary part. 

\item[P] An array descriptor consists of two 32-bit twos-complement
integer values. 

\end{description}

For the floating point types---E, D, C, and M---the IEEE NaN values
represent undefined or null values; a value with all bits set is
recognized as a NaN\@. All IEEE special values are recognized: infinity,
NaN, and denormalized numbers. If either
the real or imaginary part of a complex value contains a NaN, the
entire complex value is regarded as invalid.

Alignment may be a problem when binary tables are read. Suppose the
sequence (1I,~1E) is read directly from the I/O buffer. Some machines
may require that the number of bytes between the start of this
sequence and the start of a 4-byte floating point number in it be evenly
divisible by 4. In that case, the floating point number will not begin
at a proper location, and a data alignment error will result. If
alignment is important, the data should be copied from the I/O buffer
into an aligned buffer before they are read. 
                                       

\section{Reading FITS Format}

It is more difficult to specify and give examples of the minimum
requirements to read FITS formats because reading FITS means a
translation of the FITS data set into the internal format of a data
analysis package. Each package has its own unique requirements. When
developing software to read FITS format, allow for the flexibility of
FITS\@. Don't assume that files will always follow practices that are
recommended but not required. For example, don't expect that values of
optional keywords will use the recommended, but not mandatory, fixed
format; be prepared to accept all formats consistent with FORTRAN-77
list-directed read. Also, assume that keywords will appear in a
particular order only when this order is specified by the rules of FITS.
Because  {\em values\/} of keywords may contain lower case letters,
comparisons should not be case sensitive.                                    

A FITS file may contain records after the end of the FITS primary
HDU and the extensions. Such special records can be
recognized by the fact that they begin where FITS would begin an
extension, at the end of the previous extension or the primary HDU,
but the first 8 bytes do not contain the string 
``{\tt XTENSION}.'' While the FITS rules do not forbid the string 
``{\tt SIMPLE~~}'', its presence would be confusing and should be
avoided. These records must have the standard FITS length of 23040 bits,
to make it easy for a FITS reader to go through them in a search for the
end of file. A generalized FITS reader should be prepared for them. 

\section{FITS Files and Physical Media}
\label{s:phystr}

FITS is defined as a logical structure, independent of the medium on
which the data appear.   FITS files are regarded as bit/byte streams
with a 2880-byte logical record length.  Data written in FITS format
can, for example, be on magnetic tape, magnetic disk, optical disk, or
simply on-line.  However, the reader of a FITS file must know its
physical structure in order to unpack it.                                  

Historically, magnetic tape was the original storage medium for FITS
formats.  The initial conventions for $1/2$-inch 9-track magnetic tape
were established in the original FITS paper (Wells, Greisen, and
Harten~1981) and modifications to these conventions were presented at
the same time as the rules for extensions (Grosb\o l {\em et~al.}~1988).
The IAUFWG has since endorsed an additional set of formal rules to
relate physical and logical structure for other media.  Each medium has
its own particular rules. The complete rules are as follows: 


\begin{itemize}

\item For $1/2$-inch 9-track magnetic tape, physical blocks may
contain one to ten logical records. Unlabeled tapes are strongly
recommended; however, tapes with ANSI
labels are permitted. Data reduction and analysis packages reading
labeled tapes must count the tape label as the first file.

\item For fixed block sequential media with a
physical block size that is not an integral multiple or fraction of
2880 (for example, 512), the 2880-byte logical records are not tied to
the physical block size but are written independently, over multiple
blocks if necessary. The end of the last logical record of the FITS
data set will probably not correspond to the end of a physical block.
A short logical record extending to the end of the physical block will
follow. Readers should regard a record of less than 2880 bytes as the
equivalent of an end-of-file mark.  Examples of media covered by these 
rules are optical disks accessed as a sequential set of records, QIC 
format $1/4$-inch cartridge tapes, and local area networks.

\item For bitstream devices, FITS files are written with a blocking 
factor of one, i.e., with a physical block size of 23040 bits, 
the same as the logical record length. 

\item For variable block length sequential media, such as DDS/DAT
4-mm and 8-mm Exabyte cartridge tape, physical blocks may contain an
integral number of logical records from one to ten, the same rule as for
$1/2$-inch 9-track magnetic tape.  In the case 
where the data system is able to generate only fixed blocks, the fixed 
block convention is used.

\end{itemize} 

Except where a logical record of fewer than 23040 bits serves as an 
end-of-file indicator, a file should be
terminated by the structure for the given medium that corresponds to
the tape end-of-file mark. If more than one FITS file appears on a
physical structure, the end-of-file indicator appropriate to the
medium should separate the files, appearing immediately before the
start of the primary header of the next file. 

In the original FITS specification, the physical block size was set
equal to the logical record length for simplicity. As time passed,
however, it became clear that a significant number of the major
institutes producing data regarded this physical block size as an
inefficient use of tape. On a 6250-bpi tape, only 55\% would contain
data and 45\% would be inter-record gaps; consequently, at the same time
as the rules for extensions were developed, it was agreed that physical
blocks  on $1/2$-inch 9-track magnetic tape could contain one to ten
logical records. Blocks containing more than one record were called long
blocks. At that time, because the multirecord blocks were new and might
not be expected by some FITS readers, the {\tt BLOCKED} keyword was
introduced as an indicator that there {\em might} be more than one
logical record per physical block on a tapes.  However, usage was not
universal; therefore, absence of the {\tt BLOCKED} keyword therefore did
not guarantee single record blocks, and by its definition, its presence
did not guarantee multiple-record blocks. It could thus not be used
effectively as intended.  As the multiple record block became
established as standard, and with the rise of the concept of FITS as a
purely logical structure,  the need for a {\tt BLOCKED} keyword has
disappeared.  Information describing how a tape is blocked should be
sent with it, and users should ask for blocking information when
receiving tapes.  The keyword itself should no longer be used as a
blocking indicator, but it remains formally reserved for its original
purpose and should also not be used for any other.
                                      
(The rules for the {\tt BLOCKED} keyword also were in conflict with
other rules in FITS\@.  This keyword was required to be in the first
logical record; however, if the value of {\tt NAXIS} was greater than 
33---or 32 when {\tt EXTEND} was present---it could not be put in the
first record without violating the rule that the {\tt NAXIS}$n$ keywords
must be consecutive.)

Conventions for writing a FITS file on more than one
physical unit (tape, disk) are only now being developed. In the original
FITS paper, Wells, Greisen, and Harten~(1979) suggested a method for
handling multivolume unlabeled tape, but this proposal has
not been put into practice widely.  Many current programs that read FITS
files will be unable to handle a multiple-unit file.  The grouping
proposal, discused in section \ref{s:Grping}, uses tables to
associate physically separated FITS HDUs into a logical unit. 
                               

\chapter{World Coordinate Systems}
 \label{s:wcs}

While every point in the FITS data array can be located in the cooordinate
system determined by the array axes, 
scientific interpretation requires knowledge of
the physical or world coordinates corresponding to the index points. For
example, in an array that represents a spectrum, the relation between
wavelength and index number on the wavelength axis must be known. The
original FITS papers reserved several keywords --- {\tt CTYPE$n$}, 
{\tt CRPIX}$n$, {\tt CRVAL}$n$, {\tt CDELT}$n$, and {\tt CROTA$n$} --- 
for use in specifying this relation.  While the original paper (Wells,
Greisen, and Harten 1981) defined these keywords only for linear
transformations, they can be also be adapted for non-linear transformations 
using the definitions in  Section \ref{s:reskey}.  However, for a
non-linear transformation, some keywords in addition to those reserved will
be required to provide a full description.       

To create FITS arrays representing the images of objects in the sky
requires projection of the celestial sphere onto the array plane.
The original FITS papers did not specify how this process was to be
carried out.  The first approach to this problem, implemented in the
Astronomical Image Processing System (AIPS) and described in AIPS Memo 27 
(Greisen 1983), has been widely used, but no conventions have been formally
endorsed by the IAU FITS Working Group.  E.~Greisen 
and M.~Calabretta~(1996; hereafter GC) have expanded the AIPS approach into
a comprehensive proposal for conventions to be used in projecting 
spherical coordinates onto a two-dimensional plane.  This proposal has
evolved in response to considerable community discussion and is intended
for formal submission to the IAUFWG.  Their proposal discusses a number of
other World Coordinates issues as well.  

The  remainder of
this section~(\ref{s:wcs}) will describe the GC proposal, some other
proposed conventions that are gaining acceptance, and additional FITS
community practices.  Following these conventions in creating a data set
will make it easier for many others to read and understand the data. In
particular, designers of FITS files that will be distributed outside the
originating site should not adopt conventions that conflict with those
described in this {\em Guide\/} without consulting with other members of
the FITS community, particularly the anticipated readers of the file. 
In particular, to prevent confusion, avoid using the keywords and
notation of the conventions described here with different meanings. 
Because these conventions have not been formally approved as part of
standard FITS, data sets that use other conventions are not out of
conformance.  However, these conventions are widely used and have the
best software support; creators of FITS data that use different
conventions will probably need to supply supporting software to their
users.
                              
\vfill
            
\section{Indexes and Physical Coordinates}
\label{s:indcoor}

When the data matrix represents a digital image, transformation
between the data matrix and the physical picture requires knowledge of
where in the pixel --- center or corner --- the data point is.
Historically, astronomers have generally assumed that the index point
in a FITS file represents the center of a pixel. This interpretation is
endorsed by GC.  It differs from the common practice in
computer graphics of treating the center of a pixel as a half-integral
point.  GC note that the pixel in a FITS file is
commonly regarded as a volume element in physical space, which
might be viewed from different
perspectives via transposition and rotation.  Under such operations,
only the center of an element remains invariant.  Pending adoption of
a standard convention by the astronomical community, FITS writers
should use appropriate comments in the comment
field of the card image or the {\tt COMMENT} keyword to inform readers
of the file which convention is being used.  Once the
community has accepted a convention, a single comment noting that the
convention is being used will be sufficient.

The relation between array order and position in the displayed image, for
example whether the first pixel is at the top or bottom, is also a matter of
convention.  GC recommend that FITS writers order pixels starting
in the lower left hand corner of the image, with the first axis
increasing to the right, as in the rectangular coordinate $x$-axis, and the
second increasing upward (the $y$-axis).  Readers may choose to use a
different display, as might be done when picturing how a field mapped
visually would look through a telescope.  Use of this convention does
not replace the description of the coordinate axes using {\tt CRVAL}$n$
and the other keywords.                                                    

Although the original description of the {\tt CRPIX}$n$, 
{\tt CRVAL}$n$, and {\tt CDELT}$n$ keywords was in the context of
linear transformations, these keywords can be used to define non-linear
transformations.  The key point is that in such a case {\tt CDELT}$n$
must represent the rate of change in the physical coordinate per unit
change in counting index {\em at the reference point given by\/
{\tt CRPIX}$n$}. For a non-linear scale, the ratio between change in
the physical coordinate and in the counting index could be different
at other pixels. Conventions for such transformations have not been
established. Development or use of any such convention, including the
definition of any new keywords, should be in cooperation with the
others in the FITS community who need such conventions. 
 
\section{Proposed Conventions}

Although they have not been formally endorsed by the IAUFWG, the AIPS 
conventions (Greisen~1983) have been widely used, in particular for
distribution of IRAS infrared and Einstein X-ray imagery. A detailed
discussion and analysis appears in AIPS memo~27 (Greisen~1983). Hanisch
and Wells~(1988; hereafter HW) proposed adopting these conventions
as standard within FITS\@. They also discussed a number of other
conventions recommended at a meeting held in Charlottesville, Virginia,
in January~1988, sponsored by NASA Code~EZ. The GC proposal marks
further movement in the directions begun at Charlottesville. The
discussion in the remainder of section~\ref{s:wcs} of the 
{\em User's Guide\/} is based primarily upon those three documents,
especially GC.  However, it does not necessarily reflect the views of
all the cited authors on all points.
                        
\subsection{Improved Axis Descriptions}
\label{s:impaxes}

The original FITS Paper (Wells, Greisen and Harten~1981), assumed that
the units of the axes would be the basic SI units appropriate to the 
{\tt CTYPE}$n$ axes.  But the choice of units may not be obvious.  GC
propose that a new keyword be reserved for such cases:

{\tt CUNIT}$n$ (floating) is the units in which both {\tt CRVAL}$n$ and
{\tt CDELT}$n$ for axis $n$ are expressed.

Units identified using this keyword should be chosen using the
principles defined in section \ref{s:units} and must conform to all the
requirements in that section.              

An axis may be described by more than one label.  For example, a
spectrum may be described by frequency, wavelength, and velocity, only
one of which can be linear.  GC propose reserving the following
additional keywords: 

\begin{itemize}

\item {\tt C}$m${\tt YPE}$n$ (floating) is label $m$ for axis $n$.

\item {\tt C}$m${\tt NIT}$n$ (floating) gives the units for axis $n$
when label $m$ is used. 

\item {\tt C}$m${\tt PIX}$n$ (floating) is the reference point of axis $n$
when label $m$ is used. 

\item {\tt C}$m${\tt VAL}$n$ (floating) is the coordinate value of the
reference point on axis $n$ when label $m$ is used.  

\end{itemize}

The values of $m$ may run from 2--9; the original {\tt CTYPE}$n$, 
{\tt CRPIX}$n$, {\tt CRVAL}$n$, and {\tt CDELT}$n$ keywords are used for
$m=1$.  Note that the reference pixel need not be the same for all
descriptions of an axis.  The values of a given pixel in the different
units must be consistent, e.g., 1420.4 MHz and 21.1 cm.  There are no
defaults assumed for $m\geq2$; all of these keywords should be
specified.                                         
                                                  
\subsection{Sky Images}

There are five steps in converting a digital array into an image on the 
sky:

\begin{enumerate}

\item (optional) Transform from actual image pixel numbers to those that
would be observed by an ideal instrument.

\item Transform from the origin and axes of the instrumental coordinate
matrix system to the origin and axes of a set of projected sky
coordinates. 
                                                             
\item Convert the scale along each axis from pixel to physical 
values, still in the projection plane. 

\item Determine the projection of the sky onto the coordinate
plane of the digital array and deproject from the array plane onto the 
sky.

\item Transform from sky coordinates derived by deprojection 
to a standard celestial coordinate system.

\end{enumerate}


\subsubsection{Pixel Regularization}
      
The first step above is for the case where the array positions of the 
coordinate points differ from those that would result from the projection
from the sky.  Examples are distortions of astrometric plates caused by
imperfect optics or emulsion shrinkage and the effects of ionospheric
refractions on radio maps.  GC describe how to carry out this process
through the use of a Pixel Regularization Image. This step involves only
the correction for small distortions; all aspects of the coordinate
transformation between the rectangular grid and physical space should
be incorporated into the subsequent steps. 

\subsubsection{Transforming to Projected Sky Coordinate}
\label{s:matphy}

The coordinate system of the FITS file data array, will, in general,
be determined by the geometry of the instrumentation; consequently,
the direction of the axes in the FITS file will need to be
transformed to a coordinate system more natural to the physical system
being measured. The initial FITS paper (Wells, Greisen, and Harten~1981)
specifies use of the {\tt CROTA}$n$ keywords for  describing how the
axes of the FITS array are rotated to yield physical coordinates but
does not define precisely how they are to be used.  AIPS uses the 
{\tt CROTA2} keyword to represent the angle, in decimal degrees, of the
declination or latitude axis with respect to the 2 axis of the data
array, measured in the counterclockwise direction. AIPS does not use the
{\tt CROTA1} keyword and assumes a default value of zero for the 
{\tt CROTA2} keyword. The {\tt CROTA}$n$  keywords are necessary only
when the physical coordinates are rotated relative to the array
coordinates.  These AIPS conventions were endorsed at the
Charlottesville meeting, have been widely used, and will be generally
understood. However, some individual FITS files may define the
{\tt CROTA}$n$ differently.  Check the comments.               

The {\tt CROTA}$n$ keywords cannot be applied in a straightforward way
to more than two dimensions or to cases where the axes are not
orthogonal. GC define the more general pixel coordinate (PC) matrix 
{\sf P} to transform between the FITS array axes $f_j$ and axes in the
direction of the physical coordinate system but on the array scale $a_i$,

 \begin{equation}
  \Delta a_{i} = \sum _{j} P_{ij} \Delta f_{j}
 \label{eq:coortr} 
 \end{equation} 

where the $\Delta$ signify that positions are with respect to the
reference point.  Keywords are used to specify the elements of the PC
matrix:

{\tt PC}$iiijjj$ (floating) is an multi-indexed keyword giving the value of
the pixel coordinate matrix element $P_{ij}$ in equation \ref{eq:coortr}. 


The PC matrix technique permits considerable flexibility in transforming
between axes, including axes that are not orthogonal.  Some of this
flexibility may be better left unused.  In particular, it is possible to
transpose the axes when going from the pixel axes ($i,j,\ldots$) to the
physical axes ($x,y,\ldots$).  Suppose the first two axes are
transposed, so that axis 2 in physical space corresponds to axis 1 in
pixel space and vice versa.  The most rapidly varying axis is axis 1
($i$ in pixel space), described by the values of {\tt NAXIS1} and 
{\tt CRPIX1}.  The corresponding physical axis is the one ($y$)
described by {\tt CTYPE2}, {\tt CRVAL2}, and {\tt CDELT2}.  {\tt CTYPE1}
describes the first axis in physical space, which is now not the most
rapidly varying. If these concepts take some time to think through here,
imagine trying to understand them in a FITS file.  Such complications
can be avoided if the tranformation is defined such that the diagonal
terms of the PC matrix predominate. Another potential application of the
PC matrix that is best unused is the ability to reverse the direction of
the axis.  GC strongly recommend that the elements of the PC matrix
should be positive.  Use the {\tt CDELT}$n$ keywords to reverse axis
directions. 
             
Because the AIPS convention has been widely used, new software that
uses the PC matrix will still need to interpret files using the AIPS
conventions.  Also, until FITS reading software routinely includes support
for the PC matrix, FITS files where the PC matrix represents a rotation
equivalent to that of the old {\tt CROTA}$n$ method should also include
the {\tt CROTA}$n$ keyword as well as the PC matrix.  If $\theta$ is
the latitude angle represented by {\tt CROTA}$n$ in the AIPS convention,
and $\delta_{n}$ is the value of {\tt CDELT}$n$, then               
\begin{eqnarray}
     P_{11} & = & \cos \theta \\ 
     P_{12} & = & - (\delta_{2}/\delta_{1}) \sin \theta \\
     P_{21} & = & (\delta_{1}/\delta_{2}) \sin \theta \\
     P_{22} & = & \cos \theta 
\end{eqnarray}
It is always possible to express the {\tt CROTA}$n$ rotation in the
PC matrix form.  However, not all of the more general rotations described
by the PC matrix can be described using {\tt CROTA}$n$.  When the
coordinate transformation follows the AIPS convention, the 
{\sf P}($\theta$) relation can be inverted to yield two separate and
equivalent expressions for $\theta$:
\begin{eqnarray}
 \theta & = & \tan^{-1} \{-[(\delta_{1}/\delta_{2})(P_{12}/P_{22})]\}\\
            & = & \tan^{-1} [(\delta_{2}/\delta_{1})( P_{21}/P_{11})]
\end{eqnarray}

For a coordinate transformation following the AIPS convention, both
expressions give the same value.  For more general tranformations, both
should be computed. If the difference between the two values of $\theta$
obtained is within the expected precision, use the average (to reduce
the round-off errors). If the difference is larger, then the coordinate
axes are not orthogonal and the {\tt CROTA}$n$ description cannot be
used (HW).                                                         

\subsubsection{From Pixel to Physical Values}

Application of the PC matrix yields a coordinate system in the direction
of the physical axes but in pixel units.  Conversion to physical units is
performed by applying the scaling specfied by the {\tt CDELT$n$}.   

In some past applications of this process, steps (2) and (3) have been
combined into a single step, using a matrix that is the product of the 
{\tt CDELT}$n$, which may be thought of as a diagonal matrix, and the
PC matrix.  This matrix, called the coordinate description (CD) matrix,
described the tranformation from the array coordinates in pixel units to
the physical coordinate in physical units.  It was represented using
keywords of the form {\tt CDi\_j}, by the Space Telescope Science Data
Analysis System/Image Reduction and Analysis Facility (STSDAS/IRAF), or 
{\tt CDiiijjj}, proposed by HW\@. This method was described in the
previous version (3.1) of this {\em Guide}.  FITS readers should be
prepared to encounter it in some existing data sets.
              
\subsubsection{Deprojection} 
\label{s:WCProj}

The plane coordinates in physical units represent a projection 
of the celestial sphere.  This projection is not unique, and different
projections may be useful for different purposes.  Maps of the earth, for
example may be Mercator, equal-area, or some other projection,
depending on the intended use. In this step, the projection is reversed,
and the plane coordinates are transformed back to the projected sphere.

AIPS memo~27 (Greisen~1983) identified four common choices, which
are discussed here because of their wide use. For three of these four
projections, the choice for the tangent point,
the point common to the celestial sphere and the plane on which
it is projected, is arbitrary. AIPS adopted the convention that
the reference pixel, given by the values of {\tt CRPIX}$n$, is at this
tangent point. If the tangent point of the projection is outside the
image, then the values of the {\tt CRPIX}$n$ will be outside the data
array. Note that the values of the {\tt CRVAL}$n$ do not change
between images in different regions of the same projection. 

In the TAN (tangent) or gnomic geometry, the projection of a point of
the celestial sphere onto the plane is found by extending the line
from the center of the sphere to the point on the tangent plane. This
projection is common in optical astronomy. In the SIN (sine) or 
orthographic geometry,
common in radio aperture synthesis, the projection point is on
the perpendicular between the point on the sphere and the surface of
the tangent plane. In the ARC geometry, the projection point is on an
arc passing through the point on the sphere and the tangent plane,
with the center of the arc at the reference point. This projection
preserves angular distances. It is the natural projection of Schmidt 
camera imagery, such as the Palomar Sky Survey, 
and is also used in single-dish radio
telescope mapping. GC note that the NCP geometry discussed in the AIPS
memo, a projection onto a plane perpendicular to the North Celestial
Pole used by the Westerbork Synthesis Radio Telescope and a few other
east-west radio interferometers, can be treated as a special case of the
orthographic (SIN) projection. The SIN and TAN projections are special
cases of the {\em perspective zenithal projections}, which are generated
from a point and carried through from the unit sphere to the plane of
projection.

The proposal adopts the notation that has been used in AIPS, using the
last four characters of the value field of the {\tt CTYPE}$n$ keywords to
identify the projection. Table~\ref{t:proj} shows the codes for the
projections described above. 

\begin{table}[htp]
  \caption{Common Projections}
  \begin{center}
    \begin{tabular}{ll}
{\tt -TAN} & tangent \\
{\tt -SIN} & sine \\
{\tt -ARC} & arc \\
    \end{tabular}
  \end{center}
  \label{t:proj}
\end{table}

GC define 25 projection codes in all, including the spherical cube
projection used by the COBE project ({\tt CSC})\@.  Many standard
projections are special cases of these 25. The {\tt -NCP} designation of
the original AIPS memo is no longer used.  For each projection they
provide the transformation equations and a diagram. 

The following indexed keyword is reserved under this proposal for
defining projections:

{\tt PROJP}$n$ (floating) is the $n$th projection parameter.  Projection
parameters are additional quantities that are must be specified in order
to define the projection completely.  The specfic meaning of the keyword
or keywords is defined separately for each projection.  Many projections
do not need these additional parameters. 

GC call the deprojected coordinate system that results from this 
step the {\em native coordinates}.

\subsubsection{Conversion to Standard Celestial Coordinates}

In the original AIPS convention, the native system was required to be
locally parallel to the standard celestial coordinate system at the tangent
point.  GC relax this requirement.  The axes of the native sky coordinate
system derived by deprojection need not be in the same direction as those
of the standard celestial coordinate system.  GC provide equations for
the transformation.  The following keywords are reserved:

\begin{itemize}

\item {\tt LONGPOLE}$n$ (floating) for {\em long\/}itude of the 
{\em pole}, is the longitude of the North Pole of the standard coordinate
system in the native coordinates.  
           
\item 

{\tt LATPOLE}$n$ (floating) is used in special cases when 
two values for declination of the north pole of the native system as
measured in the standard system are consistent with the projection and
the value of {\tt LONGPOLE}; it determines which is used. 

\end{itemize}

{\tt LONGPOLE} is understood to have a default value of $0^{o}$ or
$180^{o}$ where possible. The choice depends on the latitude of the 
reference point in the standard system and in the native system;  if the
latitude in the standard system is greater, {\tt LONGPOLE} is $0^{o}$;  if the
latitude in the native system is greater, it is $180^{o}$.   With this
convention, celestial latitude and native latitude  increase in the same
direction at the tangent point.  A detailed discussion of the
transformations and the application of the reserved keywords can be
found in GC and is beyond the scope of this {\em Guide\/}.

GC adopt the AIPS convention of using the first four characters of the
value field of the {\tt CTYPE}$n$ keywords to identify the standard
system, as shown in Table~\ref{t:skycoor}. 
            
\begin{table}[htp]
  \caption{Identification of Sky Coordinate Systems}
  \begin{center}
    \begin{tabular}{lll}
{\tt RA--}, & {\tt DEC-} & 
      equatorial coordinates ($\alpha$, $\delta$) \\
{\tt GLON}, & {\tt GLAT} & 
      galactic coordinates ($\ell^{\rm II}$, b$^{\rm II}$) \\
{\tt ELON}, & {\tt ELAT} & 
      ecliptic coordinates ($\lambda$, $\beta$) \\
{\tt SLON}, & {\tt SLAT} & 
      supergalactic coordinates \\
{\tt HLON}, & {\tt HLAT} & 
      helioecliptic coordinates \\
    \end{tabular}
    \end{center}
  \label{t:skycoor}
\end{table}

Galactic coordinates as defined above are in the ``new'' system  adopted
by the IAU in 1950, where the origin, $0^{o}$ latitude and $0^{o}$
longitude, is in the direction of the galactic center.  Identifications
for older systems or future systems should be in the form ($x${\tt LAT},
$x${\tt LON}) but not one of the designations used in Table
\ref{t:skycoor}.  Ecliptic coordinates refer to the mean ecliptic and
equinox of the date of observation, in the post-IAU~1976 system.
           
The values of the {\tt CTYPE}$n$ provide both the world coordinate
system and the projection used. For example, if the data matrix 
contained a sky map in right ascension and declination projected on the
plane using the tangent projection, the {\tt CTYPE}$n$ values would be 

\begin{quote}

{\tt CTYPE1~~=~'RA---TAN'}\\ \nopagebreak  
{\tt CTYPE2~~=~'DEC--TAN'}

\end{quote}

The coordinates must be logically consistent; 
for example, {\tt 'RA---TAN'}
should not be paired with {\tt 'GLON-ARC'}.


\section{Coordinate Keywords}
\label{s:eqcoor}

There are a 
number of standard equatorial coordinate systems.  HW proposed the 
following keywords to supplement the reserved keywords discussed
in section~\ref{s:reqkey}. 

\begin{itemize}

\item {\tt RADECSYS} (character) standing for 
{\em RA\/}/{\em Dec sys\/}tem specifies the reference frame for the
equatorial coordinate system. It should be used when the {\tt CTYPE}$n$
values are  an {\tt RA--}xxxx/{\tt DEC-}xxxx pair. Table~\ref{t:eqframe}
shows the  four values defined.                  

\end{itemize}

\begin{table}[htp]
  \caption{Reference Frames for Equatorial Coordinate Systems}
  \begin{center}
    \begin{tabular}{ll}
{\tt 'FK4~~~~~'} & mean place old (before the 1976 IAU) system \\
{\tt 'FK4-NO-E'} & mean place old system but without e-terms \\
{\tt 'FK5~~~~~'} & mean place new (after the 1976 IAU) system \\
{\tt 'GAPPT~~~'} & geocentric, apparent place, after the 1976 IAU
system
    \end{tabular}
  \end{center}
  \label{t:eqframe}
\end{table}

The default value is {\tt 'FK4~~~~~'}. Under the FK4, the date of
equinox (value of the {\tt EQUINOX} keyword) is interpreted as a
Besselian epoch and under FK5 as a Julian epoch. If there is no 
{\tt EQUINOX} keyword (or {\tt EPOCH} for old FITS files), the equinox 
is assumed to be 1950.0 for FK4 and 2000.0 for FK5.

\begin{itemize}

\item {\tt MJD-OBS} (floating) specifies the time of observation in the
form of a Modified Julian Date~(JD - 2400000.5), in the International
Atomic Time time scale. Whether this point refers to the starting,
midpoint, or ending time is not defined. Use comments to say.  Use of
this keyword permits greater precision than {\tt DATE-OBS}\@. Because the
FK4 reference frame is not inertial---there is a small but significant
rotation relative to distant objects---the epoch or time of observation
is required to specify when the mean place was correct. 
                                
\end{itemize}

\section {Current Status}

In support of this proposal, Calabretta has developed the WCSlib software
package.  It is available under a GNU Public License through the NRAO
FITS archive described in  Section \ref{s:NRAOFITS}.                            

The Greisen and Calabretta~(1996) proposal is still under discussion in
the FITS community and may undergo further changes.  The following
aspects of the proposal have wide acceptance already and should be
generally understood by FITS readers:
                                                        
\begin{itemize}   

\item Index point at the {\em center} of a pixel

\item Transformation matrix (future applications are expected to follow
the PC notation and usage, although there are many existing files with
the CD notation and combined rotation-scaling usage)                           

\item {\tt SIN}, {\tt TAN}, and {\tt ARC} projections, with the standard
coordinates and the native coordinates locally parallel at the tangent
point, as in the AIPS convention.

\item The conventions for including the name of the coordinate system
and projection in the value of {\tt CTYPE}$n$.

\item The coordinate keywords described in Section \ref{s:eqcoor}. 

\end{itemize}

Trial implementations and discussions will continue before a standard 
for world coordinates becomes part of the overall FITS standard.  
Among the questions still under discussion are the following:

\begin{itemize}

\item Is there a way to use this formalism for spectra, time series,
and unequally spaced data?

\item Is the notation of section \ref{s:impaxes} the best choice for
multiple WCS used for the same image?
                                                                
\item Can the pixel correction image method be implemented for
complicated FITS files, for example, those with many images, each with
its own correction? 

\item Should the parallel use of the {\tt CROTA}$n$ notation continue, 
and, if so, how long?

\item Can agreement be reached on a more specific algorithm for choosing
the {\tt CTYPE}$n$ values to be used to identify future coordinate
systems and projections?                                            

\item Is the description of the common projections 
(e. g., {\tt SIN},{\tt TAN}) now too complicated?
    
\item Should all of the projections be included if this proposal is adopted
as the standard, or should only the basic projections be included, with
the rest as appendixes?

\end{itemize}
 
Keep up with the current discussion in the forums described in section
\ref{s:res}.  Make certain that the community has reached agreement in
the areas described above before implementing any of those features in
archival data sets.  



\chapter{Advanced FITS}
\label{s:AdvFITS}
\section{Registered Extension Type Names}
\label{s:RegExt}
Extension type names must be unique; a particular type name may refer to
only one structure. In order to avoid duplication, all extension type
names must be registered with the IAU FITS Working Group, even if the
extension type is being used by only a single organization internally.
To register a FITS extension name, contact either the FITS Support
Office at {\tt fits@nssdca.gsfc.nasa.gov} or the chair of the IAUFWG at 
{\tt dwells@nrao.edu}.  Provide a short description and justification
with the request for registration. Reserve extension type names when
their use is planned, even though details of the structure have not been
worked out. 
                        
Table~\ref{t:regext} lists the FITS extension type names and their
registered status with the IAUFWG at the time this 
{\em Guide\/} is being written. Also included in the table are the
organization with current responsibility for the extension and its
development and, when available, a reference describing the extension.  
Table~\ref{t:extstat} explains the status codes in Table~\ref{t:regext}.

\begin{footnotesize}
\begin{table}[htpb]
\begin{center}
\begin{tabular}{lllll} \\ 
\multicolumn{1}{c}{Type Name} & \multicolumn{1}{c}{Status} & 
\multicolumn{1}{c}{Reference} & \multicolumn{1}{c}{Sponsor}& 
\multicolumn{1}{c}{Comments} \\ \hline
\verb*+'A3DTABLE'+ & L & NRAO(1990) & NRAO & Prototype binary table design\\ 
                   &   &            &      & supported in AIPS, superseded by\\
                   &   &            &      & {\tt BINTABLE}, which supports\\
                   &   &            &      & all {\tt A3DTABLE} features.\\ 
                   &   &            &      &               \\  
\verb*+'BINTABLE'+ & S & Cotton,    & IAU  & Binary Tables. Available at \\ 
                   &   & Tody, and  &      & FITS Archives in 
                                             files\index{BINTABLE}\\ 
                   &   & Pence(1995)&    &{\tt documents/standards/bintable*} \\
                   &   &            &      & for 1995-Feb-06 Note: only main\\ 
                   &   &            &      & document, excluding appendixes. \\
                   &   &            &      &                          \\  
\verb*+'COMPRESS'+ & R & Warnock    & GSFC & Suggested name by \\
                   &   &{\em et. al.}&A/WWW& A. Warnock \\ 
                   &   &(1990)      &      & Preliminary proposal   \\  
                   &   &            &      &                          \\  
\verb*+'DUMP    '+ & R & none       & none & Suggested name for binary dumps.\\ 
                   &   &            &      & No full proposal submitted. \\  
                   &   &            &      &                          \\  
\verb*+'FILEMARK'+ & R & none       & NRAO & Intended for structure to \\ 
                   &   &            &      & represent equivalent of \\
                   &   &            &      & tape mark on other media. \\
                   &   &            &      & No full proposal submitted. \\  
                   &   &            &      &                          \\  
\verb*+'IMAGE   '+ & S & Ponz,      & IAU  & Image extension, contains \\ 
                   &   & Thompson,  &      & an array of one or \\
                   &   & and Mu\~{n}oz&     & more dimensions. \\
                   &   & (1994)     &      &                          \\  
                   &   &            &      &                          \\  
\verb*+'IUEIMAGE'+ & L & Mu\~{n}oz   & IUE  & Prototype matrix \\
                   &   & (1989)     &      & extension used for archiving \\
                   &   &            &      & IUE products, 
                                             superseded by {\tt IMAGE}. \\
                   &   &            &      &                          \\  
\verb*+'TABLE   '+ & S & Harten     & IAU  & ASCII tables. \\
                   &   &{\em et al.}&      &                       \\ 
                   &   & (1988)     &      &                       \\ 
                   &   &            &      &                       \\ 
\verb*+'VGROUP  '+ & R & Jennings   & GSFC & Reserved for possible use in \\ 
                   &   &{\em et al.}&      & supporting analog of HDF group\\
                   &   & (1996)     &      & structures under FITS.\\ 
                   &   &            &      & Current proposal does not use \\  
                   &   &            &      & separate extension type.\\  
                   &     &        &                       \\ \hline

\end{tabular}
\end{center}
\label{t:regext}    
\caption[Reserved Extension Type Names]{Reserved Extension Type Names}
\end{table}
\end{footnotesize}

\begin{table}[htp]
  \caption{Possible Status Levels for FITS Extensions}
  \begin{center}
    \begin{tabular}{ll}
Status & Description\\
\hline
S & Standard FITS extension type accepted by the IAUFWG and \\ 
  &   endorsed by the IAU.\\
P & Proposal for FITS extension type accepted by regional \\
  & FITS committees but not yet by the IAUFWG.\\ 
D & Draft proposal, to be discussed in regional FITS committees and by \\
  &   community.\\ 
R & Reserved FITS extension type name for which a full draft proposal \\
  &     has not yet been submitted.\\ 
L & Local FITS extension type in use only by a particular group.
    \end{tabular}
  \end{center}
  \label{t:extstat}
\end{table}

The up-to-date official listing of extensions registered with the IAUFWG
is available on-line from the FITS Support Office at 
{\tt http://ssdoo.gsfc.nasa.gov/astro/fits/xtension.html} or 
{\tt ftp://nssdc.gsfc.nasa.gov/pub/fits/xtension.lis}. This listing is
revised as information is received from the IAUFWG about the
registration of new type names or progress of a particular extension
type through the approval process.             
                                                                     

\section{Conventions for Binary Tables}
\label{s:BinCon}

In the paper presenting the binary table extension (Cotton, Tody and
Pence~1995; hereafter CTP), three conventions are described in
appendixes.  While these conventions were not part of the formal
extension rules endorsed by the IAUFWG, a number of keywords were
reserved with the intention that those keywords would be used for these
conventions.  Those keywords should not be used for any purpose
inconsistent with these conventions.  Publication in the binary table
paper means that the these conventions will be widely recognized even
without formal IAUFWG endorsement.  Unless there is agreement by a
particular community or group of FITS users on an alternative
convention, the goal of standardizing formats for convenient data
transport will best be achieved if users adopt these conventions when
formatting their data in FITS.                                 
                                                          
The HEASARC FITSIO and FTOOLS packages support both variable length
arrays and multidimensional arrays.  The IUEDAC software in IDL can read
both variable length and multidimensional arrays and can write
multidimensional arrays but not variable length arrays.


\subsection{Variable Length Arrays}
\label{s:varlen}

In some tables, the number of elements in the array contained by a
particular field may vary from row to row. One approach would be to set
the repeat count equal to the largest number possible and use fill
values for the remaining elements in the field when the number of actual
values is smaller. However, if the variations from row to row are large,
the resulting binary table will contain a large number of fill values,
an inefficient use of storage. The binary table rules contain provisions
that support a convention for efficient storage of variable length
arrays, although the convention itself is not part of the formal
proposal.                                                     
                                                             
The basic concept is that the data for variable length arrays are not
stored physically in the main table but in a heap area that follows the
table. This heap area takes up part of or all of the space following the
main table reserved by the {\tt PCOUNT} keyword in the header. At the
entry in the table where the array would be located, there is instead an
array descriptor or pointer, which tells the user or software 

\begin{itemize}

\item where the data to be logically included as that entry of the table
are to be found in the heap. 

\item the size of the data.

\end{itemize}

The data identified in the heap are treated as if actually located in
that entry of the table instead of in the heap. Since an array
descriptor has a single, standard size, all rows in the main table will
have the same length. This structure allows software that is unable to
handle variable-length arrays to read the rest of the main table and
then use the value of {\tt PCOUNT} in the header to move on to the next
extension when it has finished reading the fixed-length entries in the
table. Variable length arrays may be of any of the data types used in
binary tables except array descriptor and may be multidimensional. 

The value of the {\tt TFORM}$n$ keyword in the header, which has the
form '{\tt rPt}(maxelem)', identifies the data type ({\tt t}) of the
array to be logically included in field $n$ and specifies the
largest number of elements the array can have (maxelem) in any row of
the table. The maxelem value, which the wording in CTP includes as an
essential component of the keyword value, allows software to read the
table directly into a data base that supports only fixed size data
arrays without first having to read the table solely to determine the
size of the arrays.  Without it, the task of the reader is more
complicated.  The {\tt P} tells the reader that the actual
contents of the field in the main table will not be the data array but
the descriptor. For example, the card image                       
                           
\begin{quote}
 \begin{tt}
    
TFORM8~~=~'PB(1800)'~~~~~~~~~~/~Variable~length~byte~array
 \end{tt}
\end{quote}

signifies that field 8 of the table should be regarded as logically
containing a byte array of up to 1800 elements (here bytes). The actual
physical contents of field 8 are two 32-bit integers. The first 32-bit
integer is the number of heap elements to be considered a part of the
current row. This value may differ from row to row, but, in the
illustration here, cannot exceed 1800. A row in the table data may have
a value of zero in  this field, thus providing for fields where data
are not present in every row. The second 32-bit integer is the offset of
the start of the byte array from the beginning of the heap, counted in
number of bytes. An array starting at the beginning of the heap has an
offset of zero. The remaining elements of the array follow in sequence
in the heap; the contents of a single field of a single row cannot be
broken up in the heap. However, different fields in the same row need
not appear in the heap in the order in which they appear in the table.
Gaps in the heap, with no data, are possible. If two or more table 
fields have identical contents, the descriptors for both may point to
the same area of the heap.             
       
The heap need not begin at the end of the main table data. The user
may choose to provide a gap between the main table and the beginning
of the heap. The size of this gap can be found using the value of the 
{\tt THEAP} keyword. If there is no gap, the value of {\tt THEAP} is
NAXIS1$\times$NAXIS2. If there is, the size of the gap is the difference
between the value of {\tt THEAP} and NAXIS1$\times$NAXIS2. 

As an example, suppose the main table consists of five 168-byte rows, 
840 bytes in all, but the user wishes to have the heap begin on a new 
record.  (This construct is provided for purposes of this example; it 
is not necessarily recommended usage.)  The value of {\tt NAXIS1} is
168, representing the length in bytes of a row in the table, and the
value of {\tt NAXIS2} is 5, signifying 5 rows. There is then a
($2880-840$)- or 2040-byte gap between the main table and the heap.  The
value of {\tt THEAP}, representing the number of bytes between the start
of the main table data and the start of the heap, is 2880. Suppose
further that the heap itself has a length of 5760 bytes.  The value of
{\tt PCOUNT} is equal to the size of the gap area (2040) plus the size
of the heap (5760), or 7800.                 
                                   
The storage location to which the array descriptor points must be
located entirely within the heap.  In particular, it may not be in the
main table. 
                                                          
Reading a variable-length array on a random access storage medium,
such as disk, is straightforward. When an array descriptor is
encountered, the information in it can be used immediately to find the
appropriate data in the heap and read them; the program can then move
to the next table entry. On sequential access storage media, such as
tape, the process is more complicated. As the main table is read, a
table of the array descriptors must be generated and stored. Space is
reserved in the output data set to hold the actual array, based upon
the specifications of the array descriptors. When the main data array
has been read, the array descriptors are first sorted in order of
appearance in the heap, and then the data are read from the heap in
order and stored as specified by the array descriptors. If more than one
field has the same stored descriptor, the same heap data may be stored
in more than one place. 

Because variable-length arrays are more complicated to deal with than
ordinary fixed-length arrays and require an extra data access per
array to obtain all the data for a field, they should be used only
when absolutely necessary. 

As this convention is not part of the formal rules for 
binary tables, not all binary tables software will
necessarily be able to read variable-length arrays, except for using
the value of {\tt PCOUNT} to skip the heap. In addition, before generally
distributing a file with variable length arrays, be sure, by means of
practical tests, that the file can be read on a machine other than the
one used to write it. 

\subsection{Arrays of Strings}
\label{s:arrstr}
A user may wish to include a series of strings rather than one single
string in a field of type A.  To distinguish the component strings from
the complete string field, they will be described as substrings in the 
remainder of this section.  The convention discussed in this section 
allows a reader to use the value of the {\tt TFORM}$n$ keyword to tell
whether a character string field contains a single string or a series of
substrings.  The convention provides for a simple fixed length case,
where all substrings are of the same length, and a variable length
option, where the length of the substrings may vary. The convention
makes use of the fact that additional characters are permitted after
the data type code in the value of {\tt TFORM}$n$.  It is signaled by
the presence of a string of the form  '{\tt rA:SSTRw}[{\tt /nnn}]' in
the value field of the {\tt TFORM}$n$ keyword, with the {\tt /nnn}
present only if the length of the substrings may vary.  The {\tt :SSTR}
is the indicator that the substring array convention is in use.  A FITS
reader that is not able to process substrings  under this convention can
treat the entire contents of the field as a  single string.
                                                    
In a fixed length field, {\tt w} is the length of the individual 
substrings, for example,

\begin{quote}
 \begin{tt}
     TFORM5~~=~'40A:SSTR8'~~~~~~~~~/Fixed length substrings
 \end{tt}
\end{quote}

tells the reader that field 5 is comprised of an array of five 
eight-character substrings.  If a substring does not fill its
specified subfield, the remainder must be padded with ASCII
blanks.  In the case above, for example, if the string in the first 
subfield were only six characters long, then bytes 7 and 8 would be 
blanks. 

If the total length of the field is not an integer multiple of the
length of the substring, the remainder of the field is undefined. 
For

\begin{quote}
 \begin{tt}
     TFORM5~~=~'14A:SSTR3'~~~~~~~~~/Fixed length substrings 
 \end{tt}
\end{quote}

field 5 contains four substrings of three bytes each followed by two 
undefined characters.  

For a table field composed of substrings of variable length, all
substrings but the last are terminated by an ASCII text character
deliminator, whose decimal value, which must be in the range 032-126,
is provided by the {\tt nnn} in the value of the {\tt TFORM}$n$
keyword.  Leading zeroes are included in the {\tt nnn}. The last substring is
terminated with an ASCII NULL 
(decimal 000; hexadecimal {\tt 00}) regardless of the value of {\tt nnn}. 
The value of {\tt w} is the maximum number of characters in any
substring of the array, not including the delimiter.  For example, for

\begin{quote}
 \begin{tt}
     TFORM6~~=~'100A:SSTR8/032'~~~~~/Variable length strings 
 \end{tt}
\end{quote}

field 6 is 100 characters wide and composed of substrings whose length
may vary, so long as no substring is longer than 8 characters. Each
substring except the last is terminated by an ASCII BLANK (decimal 032
or hexadecimal {\tt 20}); the character immediately following this
delimiter is the first character of the next substring. The last
substring is terminated by an ASCII NULL. 

Undefined or null variable length substrings are represented by a 
string of zero length; the first position of the substring contains 
the designated delimiter (or an ASCII NULL if it is the last substring 
of the field).  An ASCII NULL in the first position of the field 
signifies that the field contains no substrings.  There is no 
corresponding representation for an undefined or null substring in an 
array of fixed length substrings.  Possibilities include a blank 
substring or a user-defined substring, although general FITS readers 
won't necessarily recognize the special meaning of either.  If a 
distinction needs to be made between undefined and blank substrings, 
it is better to use the variable length convention. 
      
A possible alternative procedure for representing arrays of fixed length 
substrings is through the use of the {\tt TDIM}$n$ multidimensional
array convention  described in section~\ref{s:multi}.  The first
dimension is the number of characters in a string, and the remaining
dimensions are those of the array.  This convention must be used if the
array of strings is two or more dimensions.  CTP recommend use of the
substring array convention for a one dimensional array of strings.

\subsection{Multidimensional Arrays in Binary Tables}
\label{s:multi}

The original binary table proposal, the {\tt A3DTABLE} extension,
introduced the concept of a table entry or field of more than one
element, a vector. It provided this structure through the use of a
repeat count. However, since an array of more than one dimension can be
reduced to a one-dimensional vector, as occurs when arrays are stored in
a computer, the repeat count can be used to define multidimensional
arrays as well. To do so, conventions are needed to specify how such an
array is organized in the table field.
                                                      
\subsubsection{{\tt TDIM}$n$ Keyword} CTP propose one convention,
using the {\tt TDIMn} keyword, which has been reserved for
multidimensional array description. The value of the {\tt TDIMn}
keyword, {\tt '(i,j,k,...)'}, describes the dimensions of the array,
$i \times  j \times k \times \ldots$,  stored such that the index
along the first dimension ($i$) varies most rapidly, the same
convention used for the primary data array. The product of the
dimensions must be equal to the repeat count specified in the value
of the {\tt TFORM}$n$ keyword. This convention is not a formal part
of the proposed binary table definition. Other conventions are
possible and may be used.
     
\subsubsection{Green Bank Convention}
\label{s:GrnBnk}

This convention was developed at a meeting to discuss standard FITS
formats for interchange of single dish radio astronomy data, held at
Green Bank WV, in October, 1989.  It is designed primarily for the case
where only one field is a multidimensional array or where all array
fields in a row have the same dimensions.
 
The extension header keyword

\begin{quote}

{\tt MAXIS} (integer) gives the number of dimensions of the array in the
table field.

\end{quote}

The properties of the array would be given in columns in the table.  The
column labels would be the names of the keywords used to describe a
primary or image data array, except that {\tt NAXIS}$n$ would be
replaced by {\tt MAXIS}$m$.  These labels are given by the values of the
{\tt TTYPE}$n$ keywords in the binary table header.  Thus,

\begin{itemize}

\item {\tt TTYPE}$n${\tt   = 'MAXIS}$m${\tt   '} means that the number
of elements along axis $m$ in the array contained in the table is given in
column $n$ of the table.  {\tt MAXIS1} describes the most rapidly varying
axis of the array.

\item {\tt TTYPE}$n${\tt   = 'CTYPE}$m${\tt   '} means that the name of
the physical coordinate of axis $m$ in the array contained in the table is
given in column $n$ of the table.

\item {\tt TTYPE}$n${\tt   = 'CRPIX}$m${\tt   '} means that the reference
point for axis $m$ in the array contained in the table is given in column
$n$ of the table.

\item {\tt TTYPE}$n${\tt   = 'CRVAL}$m${\tt   '} means that the value of
the physical coordinate for axis $m$ at the reference point in the array
contained in the table is given in column $n$ of the table.

\item {\tt TTYPE}$n${\tt   = 'CDELT}$m${\tt   '} means that the rate of
change of the physical coordinate along axis $m$ per unit change in the
counting index at the reference point of the array contained in the table is
given in column $n$ of the table.

\end{itemize}

Because the array field must be the same size in all rows, the values of
the {\tt MAXIS}$m$ will usually be the same for all rows of the table,
and they can then be given as header keywords instead of table columns: 

{\tt MAXIS}$m, m=1, \ldots,$ {\tt MAXIS} (integer) gives the number of
elements along axis $m$ in the array contained in the table.

It is possible for array to have the same size in two rows but
different numbers of elements along the axes, for example $36 \times 6$
in one row and $24 \times 9$ in another. In that case, the number of
elements along each axis must be given in a table column.  
                                     
One field -- call it $k$ -- will contain the actual data array.  For this row, two
keyword-value pairs are required:  

\begin{quote}
 \begin{tt}
  TFORMk~~=~'DATA~~~~'   \\ \nopagebreak
  TMATXk~~=~~~~~~~~~~~~~~~~~~~~T
 \end{tt}
\end{quote}

A value of {\tt F} is understood for the {\tt TMATX}$m$ keyword for all
other columns and need not be included explicitly.

It is possible to combine this convention with the use of the 
{\tt TDIM}$n$ keyword proposed in the binary table paper by setting 

{\tt TDIMk~~~~= '(MAXIS1,MAXIS2,...)'} 

where the {\tt MAXIS}$m$ represent the number of elements along axis
$m$ that would otherwise be the values of the {\tt MAXIS}$m$ keywords.
The CLASS package for analysis of radio astronomical data supports the
Green Bank convention.

\subsection {Some Applications of Binary Tables}
\subsubsection{Replacing Random Groups}

As noted in section~\ref{s:RanGrp}, the random groups structure of
Greisen and Harten~(1981) has been used only for transporting radio
interferometry observations. The binary table structure with
multidimensional arrays can be used to hold the exact same data as the
random groups structure. Each parameters/array group corresponds to
a row in the table. The parameters map into single-item fields and the
array into a field with a multidimensional array. The names and
other information describing the parameters would be in the table
field headings. This format is more flexible than random groups. The
parameters in the random groups format must be of the same data type
(e.g., two-byte integer, double precision floating point) as the
members of the array they precede. In a binary table, on the other
hand, the data type of the fields containing the parameters does not
have such a restriction.

\subsubsection{Multiple Arrays in One HDU}
\label{s:multin1}

While a series of matrices can often be combined into a single primary
data array by adding another dimension, to do so is not always
possible. For example, consider an array that consists of a digital
image accompanied by an array of quality flags, each of which
corresponds to a pixel on the original image. If the data type of the
flags differs from that of the image pixels, the flags cannot be
combined into the primary data array.  One way is to have the data array
and flag arrays as separate image extensions.  An alternative is to use
binary tables.  Each row would contain data for one image.  One column
would be a multidimensional array in floating point format, containing the
image, and another would be a multidimensional array in integer format,
containing the flags.  

                            
\section{Hierarchical Grouping Proposal}
\label{s:Grping}
(Jennings {\em et al.} 1996) have proposed this convention, which
provides a mechanism for logically associating different HDUs that are
physically separated into
groups that may have a hierarchical structure.  It arose in part
from efforts to convert between FITS and the Hierarchical Data
Format (HDF)\@.  HDF is under continuous development at the National
Center for Supercomputing Applications (NCSA), and current information
is available from the NCSA World Wide Web site at 
{\tt http://hdf.ncsa.uiuc.edu/}.  The discussion in this 
{\em Guide\/} is taken from that paper.  Whether this convention
needs to be submitted for IAUFWG endorsement or may be
considered a recognized convention without being part of the formal
FITS rules is still under discussion.                
            
The grouping proposal provides several capabilities:
\begin{itemize}

\item It provides an alternative to {\tt EXTLEVEL} for creating a hierarchical
structure, one that has an explicitly defined tree structure identifying the
higher level groups to which each lower level group belongs.

\item It creates a FITS structure analogous to the Vgroup structure of
HDF. 

\item It provides a means for logically including a particular HDU in more
than one group without repeating the HDU.

\item It provides a means for associating HDUs that are in different files,
even those in different physical locations, into logical groups.

\end{itemize}

The last feature is becoming particularly useful as the fraction of data
available on-line has increased and access from one computer to data on
another has become routine.  Related data may now be stored in separate
locations and accessed electronically, instead of putting separate
copies of all the related data on several machines. 
             
Jennings {\em et al.\/} provide an illustration of where such a
convention would be useful.  Consider a set of observations, each of
which has associated with it an observation log, event list, derived
image, and calibration data, and for which many observations share the
same calibration data.  It would be possible to logically associate each
(log, event list, image, calibration) set into a separate group; in
addition, the same calibration data HDU could belong to many groups but
would only need to be stored once.  Another possible group would be one
of observations of the same object at different times, and these
observations could be combined into a group even though they might
reside on multiple FITS files.
                             
An extension HDU called a {\em group table\/} defines a group and its
members.  This table may be either an ASCII table extension 
({\tt  XTENSION=~'TABLE~~~'}) or a binary table 
({\tt XTENSION=~'BINTABLE'})\@.  Group tables are required to contain
the following keywords in the header:
                              
\begin{itemize}

\item  {\tt EXTNAME} (character) must have the value {\tt GROUPING}

\item {\tt EXTVER} (integer) has a value that serves as a group
identification number.  Every HDU with 
\verb+EXTNAME = 'GROUPING'+ in a given FITS file must have a
different value of {\tt EXTVER}. This number distinguishes the group
from any other defined in the file.   

\end{itemize}

The following keyword is not required but is strongly recommended:

\begin{quote}

{\tt GRPNAME} (character) provides a name for the group table.  This
name should contain only letters, digits, and underscore (hexadecimal 5F,
decimal 95); in particular, it should not contain any embedded ASCII
blanks (hexadecimal 20, decimal 32).  The value is case-insensitive.  

\end{quote}

A group can contain any number of members.  The members may be a mix of
HDU types, in any order. They may be primary HDUs, extensions of types
endorsed by the IAUFWG (currently {\tt TABLE}, {\tt IMAGE}, and  
{\tt BINTABLE}), and other extensions that conform to the general rules
for extensions provided in section \ref{s:exts} but have not been
endorsed specifically by the IAUFWG\@. Member tables may be group
tables, thus identifying subordinate groups.  Group members can be
identified by the group table in two ways: by reference or by position. 
Either or both can be used.  Both have potential drawbacks.  For
identification by reference, the HDU is identified using the values of
the {\tt XTENSION},  {\tt EXTNAME}, and {\tt EXTVER} keywords.  A
possible difficulty is that there may be more than one HDU with these
keywords in a previously created data set, making it impossible to
identify the HDU uniquely.  For identification by position, the
numerical order of the HDU in the data set is specified. Caution is
required in the use of this method because the order of HDUs in a FITS
file may be changed when the file is copied.  The location of group
members not in the same file as the group table is specified by the
World Wide Web Uniform Resource Identifier (URI)\@.  The table must
specify the kind of URI being used: Uniform Resource Locator (URL),
Uniform Resource Name (URN), or any future form of URI\@. The
identification information is provided in columns of the group table
with prescribed names, given as values of the {\tt TTYPE}$n$ keyword.   
                                                  
The following keywords are used to define columns of the group table if
all or some group members are identified by reference:                        

\begin{itemize}

\item {\tt TTYPEn  = 'MEMBER\_XTENSION'} is the heading for a column
whose entries are character strings with the values of the 
{\tt XTENSION} keyword, for extensions that belong
to the group.  For primary HDUs that are members, the string
\verb*+'PRIMARY '+ is be used.  If no value is given, as when the
group table contains a mix of identifications by reference and by
position and the HDU is identified by position, an ASCII NULL 
(hexadecimal {\tt 00}, decimal 000) may be used.

\item {\tt TTYPEn  = 'MEMBER\_NAME'} is the heading for a column whose
entries are character strings with the values of the {\tt EXTNAME}
keyword for group member extensions.  The treatment of extensions with
no value of {\tt EXTNAME} is the same as that for the case where no
value of {\tt XTENSION} is available.        
          
\item {\tt TTYPEn  = 'MEMBER\_VERSION} is the heading for a column
whose entries are integers with the values of the {\tt EXTVER} keyword
for group member extensions.  For primary headers or where the 
{\tt EXTVER} keyword is absent, the entry should be 1.

\end{itemize}

The following keyword is used to define a column needed if all or some
members are identified by position:
                                                       
\begin{itemize}

\item {\tt TTYPEn  = 'MEMBER\_POSITION'} is the heading for a column
of group member positions given as integers, with 0 (zero)
representing the primary HDU, 1 (one) the first extension, etc.  If
the value is invalid or undefined, the entry should contain the null
value specified by the  {\tt TNULLn} keyword for that column. 

\end{itemize}
          
The following keywords are required if some or all of the group members
are not in the same file as the group table:

\begin{itemize}

\item {\tt TTYPEn  = 'MEMBER\_URI\_TYPE'} is the heading for a column
containing the acronym for the URI type used to identify the member
location.  Entries permitted as this is written are URN and URL; other
entries will become acceptable as new URI types are defined.  

\item {\tt TTYPEn  = 'MEMBER\_LOCATION'} is the heading for a column
containing the URIs for the group members.  For group members in the
same file as the group table, the field may be filled with blanks; for
members on the same machine but in a different file, the relative URI may
be used instead of the absolute URI.

\end{itemize}

If either of the above fields is undefined, the field should contain an
ASCII NULL. 

A group table may contain any number of additional, user-defined
columns.  Group table columns may appear in any order.  The values of
{\tt TTYPE}$n$ are not case-sensitive.

To permit inclusion of HDUs from existing FITS files in groups, the
grouping proposal does not require any new keywords for group members. 
Use of the {\tt EXTNAME} and {\tt EXTVAL} keywords defined in section
\ref{s:extres}, the rules for generalized extensions, permitting
identification by reference, is strongly recommended.  Every member of a
group located in a particular file should have a unique combination of
{\tt XTENSION}, {\tt EXTNAME}, and {\tt EXTVER} keywords.  Group tables
that are members should have a unique combination of  {\tt EXTNAME} and 
{\tt EXTVER} keywords, and there should not be an ASCII group table and
a binary group table with the same ({\tt EXTNAME},  {\tt EXTVER}) in the
same file.  In addition, the use of {\tt EXTNAME} allows HDUs of a given
extension type and structure to be identified by a common name.                       
                                                                   
Use of the following two keywords also is strongly recommended:

\begin{itemize}

\item {\tt GRPID}$n$ (integer) gives the {\tt EXTVER} value of the $n$th 
group table of which the HDU is a member if the member is in the same
file as the group table and is the negative of the {\tt EXTVER} value if
the member and group table are in different files.   The presence of
this keyword also warns software that is changing the position of the
HDU that the HDU is a member of a group, naming the group table  where
entries used for identification by position will need to be changed.           
                                                              
\item {\tt GRPLC}$n$ (character) gives the URI for group table $n$.  It is
not necessary if the value of {\tt GRPID}$n$ is positive.  

\end{itemize}

An HDU may be a member of many groups. If the HDU is a member of
$m$ groups, then there will be {\tt GRPID1} $\ldots$ {\tt GRPID}$m$
keywords, each identifying one of these groups. If the value of 
a particular {\tt GRPID}$n$ is negative, it is the negative of the group
identification number (the value of {\tt EXTVER} in the group table), 
the group table is not in the same file as the member, and there
will be a {\tt GRPLC}$n$ keyword with the URI where the group table
is located. 

The Jennings {\em et al.} proposal presents a number of illustrations. 
As of this writing, it is available at 
{\tt http://wwwadf.gsfc.nasa.gov/other/convert/group.html}. 


\section{STScI Inheritance Convention}

The rules of FITS do not specify whether or not keywords in the primary
header apply to extension data in the same file.  STScI has adopted the
following conventions governing such inheritance of keywords (Zarate and
Greenfield 1996).
                                                  
\begin{enumerate}

\item Primary header keywords can be inherited only if there is
no primary data array.

\item Primary header keywords apply to extensions only if the
header contains the keyword {\tt INHERIT} with the value set to {\tt T}.

\item Required FITS keywords are not inherited.  

\item If a keyword appears both in the primary header and an extension
header, the value in the extension header will apply to the extension.

\item The reserved commentary keywords, {\tt COMMENT}, {\tt HISTORY}, and
\verb*+        +, are never inherited.

\item Changes to an inherited keyword appear only in the extension header,
not the primary header, i.e., the inherited keyword will appear in the
extension header with its new value and the primary header value remains
unchanged. 

\end{enumerate}

As with any FITS convention, software may allow for overriding the
inheritance convention for specific purposes. For example,
the IRAF FITS kernel has a mechanism to override the rules given in
items 1 and 2. 


\section{Checksum Proposal}

Seaman and Pence (1995) have proposed a means for embedding a checksum
within a FITS files.  The proposal has been presented for discussion to
the community as the first step in the process of seeking endorsement by
the IAUFWG.  This section summarizes their proposal; more details can be
found in the paper itself.  The purpose of such a checksum is to verify
that there has been no error in a data transmission.  A checksum is
calculated for the data that are to be sent and then calculated in the
same way where the data are received; the two are then compared.  All
checksums are calculated using ones-complement arithmetic; that is, the
result of overflow in addition in the most significant bit is carried
over to the least significant bit.
                                               
Three keywords are reserved for this proposal:

\begin {itemize}

\item {\tt CHECKSUM} (character) is a 16-character string containing an
ASCII encoding of the ones-complement of the checksum of the HDU
calculated with the value of the {\tt CHECKSUM} keyword set to 
{\tt '0000000000000000'} (ASCII 0s or hexadecimal {\tt 30}s) before the
checksum is computed.  

\item {\tt DATASUM} (character) is a character string, containing the
unsigned integer value of the checksum of the data of the HDU, formatted
as a string.  The string formulation is used because FITS does not
support unsigned integer keyword values. If the HDU has no data, the
value field may be set to {\tt '0'} (preferred) or the keyword is
omitted.  The single digit is used in the value field to distinguish it
from an actual zero data checksum.  Absence of a {\tt DATASUM} keyword
implies no knowledge of the checksum of the data records.             

\item {\tt CHECKVER} (character) is a character string that identifies the
checksum algorithm used.  The algorithm defined by Seaman and Pence
has the identification {\tt 'COMPLEMENT'} and is the default value. 
Development of future algorithms should be coordinated within the
community and governed by a registry under the IAUFWG
like the one for extension type names described in section \ref{s:exts}. 
It is recommended that this keyword appear only if an algorithm other
than the default {\tt COMPLEMENT} algorithm is used. 

\end{itemize}
 
For purposes of calculating the checksum, the header and data of each
HDU are treated as a series of 32-bit words.  Checksums are calculated
by adding these words, using ones-complement arithmetic, to yield a
32-bit integer.  First the ones-complement checksum of the data records
is calculated. The unsigned integer result is then formatted as a string
and put in the value of the {\tt DATASUM} keyword.  For example, if the
checksum of the data records is the unsigned integer 2503531142, then
the {\tt DATASUM} keyword in the header will appear as
\begin{quote}
\verb*+DATASUM = '2503531142'+
\end{quote}
The checksum keyword in the header is then set to an encoded ASCII zero: 
\begin{quote}
\verb*+CHECKSUM= '0000000000000000'+
\end{quote}


The ones complement checksum of the header is then calculated, including
the {\tt CHECKSUM} and {\tt DATASUM} keywords with the above values, and
the already calculated data checksum is added to it, yielding a checksum 
for the entire HDU\@.  The bit complement of the total, which is its
ones-complement additive inverse, is then calculated such that   
                                                             
\begin{displaymath}
\mbox{original\_checksum} + \mbox{bit\_complement} = 0
\end{displaymath}

This bit complement is then ASCII encoded.  As part of the encoding
process an  encoded ASCII zero is added:

\begin{displaymath}
\mbox{encoded\_complement} = 
       \mbox{bit\_complement} + \mbox{ASCII\_zero}
\end{displaymath}

This encoded complement replaces the original value of the checksum
keyword, the ASCII zero, in effect subtracting it out:
\begin{eqnarray*}
\mbox{new\_checksum} & = & \mbox{original\_checksum} +     
        \mbox{encoded\_complement} - \mbox{ASCII\_zero} \\
                     & = & \mbox{original\_checksum} + 
                            \mbox{bit\_complement} \\
                     & = & 0                        \\
\end{eqnarray*}
Thus, with the encoded complement in the header, the checksum of the
HDU is now zero.

Seaman and Pence recommend an algorithm for encoding the checksum
complement for inclusion as the value of the {\tt CHECKSUM} keyword.
This scheme encodes not only the meaning of the binary data but the
checksum's actual 32-bit unsigned integer value.  Each of the four bytes
in this value is numerically divided by four and the result placed in
the corresponding byte of four quotients in four successive integer
aligned fields;  the remainder for each byte is added to the first
quotient.  For example, the first byte of the second quotient field
contains a value equal to one-fourth of the first byte of the original
checksum value.  The sum of the four quotients is the original checksum;
in addition, the byte alignment is maintained: the sum of the first
bytes of the four quotients is the first byte of the original checksum
complement, similarly with the other three.  An ASCII zero is then added
to all the bytes, thus creating a 16-character printable ASCII string. 
To improve readability, if byte values are not alphanumeric, then the
values will be shifted by simultaneously incrementing one byte and
decrementing the corresponding byte in another of the four quotients in
a systematic way, until both are alphanumeric.  In this process, the sum
is not changed.  In accordance with the FITS fixed format rules for
character strings, the initial quote is in column 11 and the first byte
will be in column 12.  In order to maintain proper byte alignment within
the four byte word, the final byte of the encoded checksum is permuted
to column 12; thus, it remains the fourth byte of a four-byte word, the
next byte is the first, and all the rest maintain proper position.  This
value is then set in the value field of the checksum.  Seaman and Pence
present a detailed example.  The string can easily be decoded by
permuting the encoded string back to its original alignment, subtracting
the hexadecimal {\tt 30} offset, and summing the four parts.           
                                                              
This algorithm is not mandated by the proposal; other encodings are
possible but must satisfy the following constraints:

\begin{itemize}

\item The 32-bit unsigned integer {\tt CHECKSUM} value is encoded into
a 16-character ASCII string.

\item Only the ASCII alphanumberic characters 0-9, A-Z, and a-z are
permitted.

\item The quotes enclosing the ASCII string value of the {\tt CHECKSUM}
keyword must be in columns 11 and 28.

\item The encoded ASCII value will cause the 32-bit ones-complement
checksum of the HDU to be zero.

\end{itemize}

The checksum is zero for the entire file because it is zero for each
individual HDU\@ of 
.  Requiring a zero checksum for individual HDUs rather
than only for the file as a whole allows HDUs to be removed from or
added to the file without altering the checksum.

The following {\em strong recommendations\/} are made regarding the
usage of these keywords:                   

\begin{itemize} 

\item FITS files should include the checksum keywords.

\item The checksum keywords should be included in all HDUs of FITS
files that contain more than one HDU.

\item All HDUs of a single FITS file should use the same checksum
algorithm, i.~e., the values of {\tt CHECKVER} should be the same.

\item When an HDU is modified, FITS software should update the
checksum keywords if present and add them if not present.

\item At the very least, FITS software should delete the keywords if an
HDU is modified and the checksums are not recomputed.

\end{itemize}

The last two recommendations must be followed to avoid creating HDUs
containg checksum keywords with values inconsistent with the
HDU contents.
   
Seaman and Pence present a detailed example of the use of the checksum
convention and the encoding described above, as well as software to in
both C and FORTRAN 77 to implement the encoding.  The C routines are
adapted from the on-line software for the NOAO/IRAF {\em Save the Bits\/}
archive; the FORTRAN 77 routines are adapted from the FITSIO package.
                    
\section{Other Proposed Conventions}

\subsection{HEASARC}
\label{s:HFWGcon}

The HEASARC at Goddard Space Flight Center is responsible for archiving
a considerable volume of data from many different high energy
astrophysics missions, including missions under the auspices of NASA
and missions in which NASA has cooperated with and supported other
agencies.  Under the Office of Guest Investigator Programs (OGIP), the
HEASARC FITS Working Group has been organized to formulate
recommendations for FITS practice, required for files produced by
HEASARC/OGIP but intended for application throughout the high energy
astrophysics community.   

\subsubsection{Keywords and column names}
\label{s:HFWGchar}

In keywords and table column names, HEASARC recommends use of the
underscore (hexadecimal {\tt 5F}) rather than the hyphen (hexadecimal
{\tt 2D}\@).  The only cases where a hyphen is to be used in keywords
are  
                                                               
\begin{itemize}

\item where use of a hyphen is established usage, as for example in the 
      {\tt DATE-OBS} keyword.

\item to represent a minus (negation) sign

\end{itemize}

This set of recommendations is similar to those in the original paper
for ASCII table fields, as discussed in section \ref{s:restab}, but
extends them to keywords and binary table fields.  Extending the rules
for keywords to column names makes it possible to replace a table column
heading with a keyword with the same name if the value for that column
in every row of the table is the same, as in the Green Bank convention
(section \ref{s:GrnBnk}).                                           

HEASARC/OGIP requires the following additional conventions for column
names in all tables it produces and recommends them for others:

\begin{itemize}

\item Different columns in the same table cannot have the same name
      and all columns must be unique in the first 16 characters.

\item Embedded blanks are specifically forbidden, as they are for
      keywords.

\item Values of the {\tt TTYPE}$n$ keyword are case-insensitive, as
      specified for ASCII tables in the NOST standard described in
      section \ref{s:FITSdoc}.

\item Column names must begin with an alphabetic character 
	(A-Z, a-z), not a digit or underscore.

\item Column names may be up to 68 characters in length.

\end{itemize}

\subsubsection {Proposed {\tt CREATOR} Keyword}
      
\begin{quote}

{\tt CREATOR} (character) identifies the software that originally created
a FITS file. 

\end{quote}
      
The value refers to the software that originally defined the FITS
file structure and wrote the contents; it should not be changed if
the file is copied largely intact into another file.  Use 
{\tt HISTORY} keywords to document such travels of the file after it
has been created.  When appropriate, the value of the {\tt CREATOR}
keyword should identify the specific version of the software that
created the FITS file; e.g. {\tt 'WRITEFITS V3.2'}.  The {\tt AUTHOR}
keyword (section \ref{s:reskey}) has sometimes been misused for this
purpose, but {\tt AUTHOR} is reserved for the human author or
compiler of a document.  
                            
\subsubsection{Proposed {\tt TSORTKEY} Convention}

The purpose of this convention is to provide information on the ordering
of rows in a FITS ASCII or binary table.  How the table has been ordered
is useful information for users; indeed, it may be necessary for some
data processing operations. Usually, the rows are in order of increasing
values in a particular column in the table, for example, time or right
ascension.  To specify the order used in a particular FITS table, a new
keyword is used:
                                                    
\begin{quote}
{\tt TSORTKEY} (character) lists the name of the primary sort column,
      given by the value of the {\tt TTYPE}$n$ keyword, followed,
      optionally, by the names of secondary sort columns.  The names
      must be separated by a comma; there may be zero or more spaces
      between a comma and the next column name.  
\end{quote}

The default order for sorting in this convention is ascending order;
if the sort is in descending order, the name of the column is
preceded by a minus sign.
    
This convention prescribes the following ascending sort order for the FITS
data types:

\begin{description}
\item [Integer and floating point]  In numerical order for both ASCII and
      binary tables; ASCII tables are not sorted in order of the internal
      ASCII representation of their contents. 

\item [Complex] In numerical order of the real component first; rows
      with the same value of the real component are sorted in order of
      the imaginary component.

\item [Bit] Zero or ``unset'' bits precede ``set'' bits.

\item [Logical]  False ({\tt F}) values precede true ({\tt T}) values.
      
\item [Character and string] In order of the ASCII collating sequence;
      for a string, first in order of the first character, then in order
      of the second character, than in order of following characters in
      sequence.
      
\end{description}

In an ascending order search, null or undefined characters follow all
defined values.

The convention also provides a sort order for vector columns.  If the order
is not otherwise specified, rows are sorted first on the order of the value
of the first element, then in order of the value of the second element, and
on in sequence.  Other columns may be used for sorting.  If the column 
{\tt ARRAY} is being sorted first on element $i$, then on element $j$, and
then on element $k$, then

\begin{quote}
\verb*+TSORTKEY~='ARRAY(+$i${\tt ),ARRAY(}$j${\tt ),ARRAY(}$k${\tt )'}
\end{quote} 

If the sorting is on consecutive columns $m \ldots n$, then 

\begin{quote}
\verb*+TSORTKEY~='ARRAY(+$m${\tt :}$n${\tt )', ARRAY(}$k${\tt )'}
\end{quote} 
 
A string is treated as a vector of characters.  When sorting strings, a
blank element precedes any characters.  For an ascending order default
sort, shorter strings precede longer ones: ``\verb*+FORM  +'' precedes  
``\verb*+FORMAT+''.

This convention can be used only if 
the values of the {\tt TTYPE}$n$ keywords labelling the
columns of the table obey the following restrictions:


\begin{itemize}

\item There must be a {\tt TTYPE}$n$ for every column, and the name of
      every column (value of {\tt TTYPE}$n$) must be unique.
                                                    
\item The first character of a column name must not be a minus sign.

\item No column name may contain a comma (hexadecimal {\tt 2C}), or an open or close
      parenthesis (hexadecimal {\tt 28} and {\tt 29}).

\item Embedded blank characters are discouraged, with the underscore
      recommended to link separate words in a column name.

\end{itemize}

\subsubsection{Maximum and Mininum Values in Table Columns}
\label{s:HFWGlim}
      
HEASARC uses the following keywords to specify the limits on data in a
table column.  They are analogous to the {\tt DATAMAX} and 
{\tt DATAMIN} keywords used for arrays.

\begin{itemize}

\item {{\tt TDMAX}$n$} is the maximum value in column $n$ of a table,
      exclusive of null or fill values.

\item {{\tt TDMIN}$n$} is the minimum value in column $n$ of a table,
      exclusive of null or fill values.

\item {{\tt TLMAX}$n$} is the maximum permissible value in column
      $n$ of a table.

\item {{\tt TLMIN}$n$} is the minimum permissible value in column $n$
      of a table.

\end{itemize}

For example, if the third column in a table of positions was declination,
then the following keywords might be present.

\begin{verbatim}
TTYPE3  = 'DEC     '
TFORM3  = '1E      '
TUNIT3  = 'DEGREES '
TLMAX3  =                90.00
TLMIN3  =               -90.00
TDMAX3  =                46.00
TDMIN3  =               -63.10
\end{verbatim}

HEASARC also recommends the following restrictions when these
keywords are used:

\begin{itemize}

\item The data type of the keyword value should be the same as that of
      the data in the column it describes.

\item The keywords are to refer to {\em all} elements of a vector column

\item As with {\tt DATAMAX} and {\tt DATAMIN}, the keywords apply to
      the values after any scaling prescribed by the values of the 
      {\tt TZERO}$n$ and {\tt TSCAL}$n$ keywords has been applied.

\item Values of {\tt TDMIN}$n$ less than those of {\tt TLMIN}$n$ and
      values of {\tt TDMAX}$n$ greater than those of {\tt TLMAX}$n$
      are permissible; the meaning is not defined in this convention.

\item If the value of the keyword for the maximum is less than that of the
      value of that for the minimum, then the values are taken to be
      undefined. 

\end{itemize}

\subsection{World Coordinates in Tables}
\label{s:WCTab}

Primary data arrays and image extension arrays are not the only way in
which maps may be defined in FITS files.  The following applications are
also possible:

\begin{enumerate}

\item A vector column in a binary table may be a multidimensional array
      that represents a map in the same way as a primary data array or
      image extension array.

\item The entries in a binary table may represent objects and their
      positions on a map.  An event list would produce such a table.  
      The map axes could be, for example, sky positions (R.~A.,~Dec)
      or locations on a detector grid ($x$,$y$). One column in the table
      would be assigned to each coordinate of the positions of the
      objects.  The map coordinates and possibly the transformation
      between detector and sky position must be described in some way.
         
\item The user may wish to tabulate a set of coordinate transformation
      keywords applying to different images, for example, defining how
      the celestial pointing of an imaging instrument changed with time. 

\end{enumerate}

Standard keywords should have a consistent usage throughout FITS\@.  The
keywords reserved to describe primary arrays and images should be used
to describe coordinates in these other applications only if they have
they same meaning.  In particular, they should never be used in a way
that can or might lead to contradictory meanings in the same HDU.        
                                                                  
In the case of a multidimensional array in a table, the coordinate
keywords are being used in the same way; as for a data array, they
tell how to interpret a one-dimensional array of data values in the
FITS file as a multidimensional matrix.   If there is only one array
in the table, or if all the arrays in the table have the same
properties, the standard keywords that describe the meaning and
scaling of the axes---{\tt CTYPE}$n$, {\tt CRPIX}$n$, {\tt CRVAL}$n$,
and {\tt CDELT}$n$---can be used in the header.  On the other hand,
because they are already used in the header to define the table
as a two-dimensional array, the {\tt NAXIS}
and {\tt NAXIS}$n$ keywords cannot also be used to describe the
member arrays.  The Green Bank convention described in section
\ref{s:GrnBnk} avoids the problem of keyword conflict by using
different keywords, {\tt MAXIS} and {\tt MAXIS}$m$,  to describe the
array in the table.
                    
In the other two cases the usage is different.  

In array usage, the location of a data value relative to the axes is
associated with its {\em position} in an array.  In the table of
positions, on the other hand, the location of a data value relative
to one or more axes is associated with its actual {\em value}.  One
can even imagine a case where both kinds of coordinate might appear
in a table, two  fields giving $x$ and $y$ positions and another
field containing an array.  If the same keywords could be used in
both contexts, it would not be clear which coordinate system was
being described by the header keywords.  To avoid possible
confusion, the standard array keywords should not be used to
describe a coordinate system where the values of individual table
entries are located, such as the coordinate system of ($x$, $y$)
positions.

For a table of coordinate tranformations, the temptation may be to use
the standard keyword names as table headers.  Doing so, however, would
lead to a situation in which the same name had different meaning in the
header and body, for example, when {\tt NAXIS} = 2 in the header, it
refers to the dimensions of the data table in the same HDU, but in  
{\tt TTYPE}$n$\verb+   = 'NAXIS   '+, it refers to the dimensions of
arrays in a different HDU\@.  Again, the standard keyword names should
not be used.    
                                     
The most recent version of the World Coordinates proposal includes a
description of conventions proposed by HEASARC\@.  These conventions
are available on the HEASARC and NRAO World Wide Web sites discussed
in sections \ref{s:NRAOFITS} and \ref{s:HEsite}.

  \subsection{Compression}

Proposals for ways to include compressed data in FITS files are still
under development. A preliminary proposal by 
Warnock~{\em et al.}~(1990) is available from the NRAO ftp
directories described in section~\ref{s:NRAOFITS}. However, there are some
compression-related questions this proposal does not address.
Other installations are experimenting with local schemes. 

\subsection{Other Reserved Type Names} 

In the original FITS design, intended for half-inch magnetic tape, the
end of a file could easily be identified by a tape end-of-file mark. Not
all other media support such a clear hardware delimiter.  D.~Wells has
proposed the creation of a {\tt FILEMARK} extension, which would
represent an end-of-file on media where the end of the file cannot
easily be marked on the hardware. The name has been reserved for use in
developing this concept; as yet there is no detailed proposal.                 

A FITS file might contain a pure bit stream, such as telemetry. An
extension type name {\tt DUMP} has been proposed and reserved for
such data. Details of how this extension would be structured remain
to be developed.                     

\subsection{Developing New Conventions}
      
The conventions that have been described in this section are not formally
a part of the FITS rules and do not exclude others.  However, since the
purpose of such conventions is to develop a widely used and understood
set of practices, new conventions should be developed only if the existing
conventions in general use will not work for new data.  Community
comment and review should be part of development of any new convention. 
If design of a FITS data set is constrained by project deadlines, the
intended users of the data and other groups that are making similar data
publicly available should be consulted early in the development process. 
Proposed data designs with new conventions should be made available for
review and comment to the user community as soon as a draft is
available; opportunity for review should also be given to the general
astronomical community to the extent possible consistent with project
procedures.  Requests for review should emphasize any deadlines.  The
proposed conventions should then be revised on the basis of the response
before being incorporated in data sets.                      


\section{Keyword Domains}
\label{s:KeyDom}

Keywords that are not required or reserved for the standard FITS
structures might easily have different meanings for different
groups. Thus, the significance of a keyword would depend upon the
context. The FITS community has looked for possible ways to define
domains that would identify which keyword definitions apply. The
initial approach to defining keyword domains was the concept of
keyword hierarchies. In this method, syntax in the FITS file
would indicate that certain keywords were to be considered as part
of a named domain. Such domains might exist in a hierarchy of
levels. For example, the highest level might be a particular
institution, and lower levels could be individual projects within
the institution. However, consensus about what the structure should
be appears unlikely. 
                                  
The reasons for the lack of agreement become apparent from an
examination of the principal approaches. One approach would
use the string   ``{\tt HIERARCH}'' in columns~1--8 of a header card
image as domain indicator. Domain names, at progressively lower levels,
would follow in sequence in the card image, and, finally, the
keyword=value statement would appear after the lowest level domain name.
Critics of this approach argue that the {\tt HIERARCH} keyword and the
domain names would leave little room on the card image for the actual
keyword and value information, or for comment fields. Also,
many FITS readers would be looking in columns 1--8 to find the keyword,
and the keywords behind {\tt HIERARCH} would be inaccessible. Special
parsers would need to be built. 
                
The other approach would use a  ``{\tt KHBEGIN~}'' keyword to signal the
beginning of a domain; the value would be the domain name. Subsequent
keywords, beginning in column 1, would have the value for that domain. A
``{\tt KHEND~~~}'' keyword would signal the end of a domain. Domains
could be nested. Within the domains, keywords would begin in column 1,
as do the other FITS keywords. Critics of this approach argue that the
placement of the low-level hierarchical keywords in columns 1--8 would
mix them with other simple nonstandard FITS keywords, 
existing FITS readers might generate incorrect results, and special
code would be needed to interpret the keywords properly. 
             
The difference between these two approaches is not just a matter of
detail; it is the principle of whether keywords restricted to a
particular domain should appear in the first eight columns of the card
image or should start in a later column. Because this issue has not
been resolved by the FITS committees and resolution does not appear
imminent, {\em do not assume that FITS readers will recognize either
scheme}. For that reason, neither approach is discussed further in
this document. 

Some installations have implemented a convention similar to the
{\tt HIERARCH} proposal in which a keyword without values, such as
{\tt HISTORY} (or even {\tt HIERARCH}) appears in the first eight
columns, followed by one or more domain names and then the keyword.
The ESO Archive, for example, uses {\tt HIERARCH}\@. The first sample FITS
header in the first FITS  paper (Wells, Greisen, and Harten~1981)
illustrated this approach, but it was not formally proposed or  tested
for interoperability at the time. If a group chooses to use such a
convention, the header should always allow a reader unfamiliar with it
to interpret those card images as pure comments. An example of such
usage appears in Example 1 of Appendix~\ref{s:ex}. 

Existing constructs in FITS provide another approach to
domain definition. Some reserved FITS keywords---for example, 
{\tt ORIGIN}, {\tt TELESCOP}, and {\tt INSTRUME}---describe natural
domain limiters, the installation where the FITS file was written and
the telescope and instrument used to obtain the data. Keywords
following an {\tt ORIGIN} keyword in an HDU could be understood as
having the meaning defined for the particular installation given by
the value of the {\tt ORIGIN} keyword; similarly {\tt TELESCOP} and
{\tt INSTRUME}, when present, could signify that keywords following
have the meaning defined for data sets from the telescope and/or
instrument named. It is then possible to define keyword meanings
specific to a particular organization, telescope, and/or instrument
and use the values of the relevant keywords to signify that such a
particular set of keyword definitions applies. In this way, even
though a particular keyword might be used differently in different
contexts, the applicable context could be identified. 

The same problem can arise in naming table column headers as when 
choosing keyword names: different groups may use the same column
headings with different meaning. Again, some method of defining
project-specific meanings for the table headings is needed. The
proposal to use the {\tt ORIGIN}, {\tt TELESCOP}, and {\tt INSTRUME}
keywords as domain limiters works here, too. These keywords could be
either in the primary header of the file or the individual extension
header. Including these keywords in the extension headers has the
disadvantage that they will be repeated from header to header, using
extra space, but it has advantages: the domain indicators appear as
keywords in the same header as keywords giving the column labels they
describe, and they will remain associated with the table, should for
some reason the table but not the primary header be copied from the
FITS data set to another, say, to a data set with a different primary
header. The additional information gained by including domain keywords
in each extension thus appears worth the small extra overhead.

One possible problem that has been suggested for this approach is
that some local software systems might rearrange keyword order when
reading the FITS file into an internal format structure and so lose
the domain information.  If this approach is used, keyword order should
not be critical.

Because they are used in domain conventions, use of the keywords
{\tt HIERARCH}, {\tt KHBEGIN}, and {\tt KHEND} for other purposes is
discouraged. All keywords with important information must appear in
columns 1--8.
            
\section{Polarization} 
No convention has been formally and universally adopted within FITS to
describe polarization. The convention most widely used is the one
developed by NRAO that is supported in AIPS\@. This convention has also
been adopted in a proposed standard FITS form for interferometry
intended to replace Random Groups.           

When values of the Stokes parameters are mapped, an axis with the
{\tt CTYPE}$n$ value {\tt 'STOKES~~'} is used to describe which
Stokes or correlator parameters are displayed in the images. The
values and the parameters they denote are shown in
Table~\ref{t:stokes}. 
        
\begin{table}[htbp]
  \caption{NRAO Stokes Parameters Convention}
  \begin{center}
    \begin{tabular}{cccccccccccc}
 -8 & -7 & -6 & -5 & -4 & -3 & -2 & -1 & 1 & 2 & 3 & 4 \\
 YX & XY & YY & XX & LR & RL & LL & RR & I & Q & U & V
    \end{tabular}
  \end{center}
  \label{t:stokes}
\end{table}

X and Y are linear polarizations with fixed orientation relative
to the antenna. In the interferometry proposal, X is horizontal and Y
vertical. R and L refer to right and left circular polarization. The
convention has been suggested that -2 be used to refer to left
circularly polarized images and -1 to right circularly polarized
images. The definitions of circular polarization follow the IEEE
convention; right circular polarization corresponds to the electric
vector of an approaching wave rotating clockwise. This convention
should be noted in the comments; use of the opposite convention is not
unknown.

\section{Spectra} 

There is, as yet, no formal agreement or convention on encoding
spectra from random positions on the sky in FITS format. Conventions
for describing the mapping between pixel number and frequency need to
be developed. In fact, there has not even been agreement on whether
frequency should be the only independent variable for spectroscopic
data exchange or whether wavelength also should be used. Section
\ref{s:impaxes} discusses one proposal for attaching multiple labels to
one axis.  While the resolution of these issues is outside the scope of 
this {\em User's Guide}, it is important to recognize that they exist.        

Spectra can be transmitted as one-dimensional arrays, using the Basic
FITS format with {\tt NAXIS} = 1. However, such usage is inefficient.
Each spectrum would have its own header. Spectroscopic observations
generally need more ancillary parameters than do images. The header
may easily use more bytes than the data. Approaches that would reduce
header overhead are needed.

It may be possible to encode many spectra in a single array by adding
a second dimension---scan number. Information about the entire set of
observations would appear in the primary header; information about the
individual scans would appear in a table extension or extensions
following the data. This choice has the advantage that the data format
is the one most widely and easily read. A principal disadvantage is
that the ancillary information for individual scans is separated from
the results of the observations.

If there are not too many parameters and the individual spectrum
vectors are not long, ASCII tables may be a convenient format. One row
would correspond to an observation, containing the ancillary
information and the results. Each wavelength would be a separate field
of the table, and the other fields would contain the ancillary
parameters. However, as the spectra become longer and the number of
points in a data set increases, the inefficiencies in use of space by
the ASCII table format become a serious problem.

Space can be reduced by using binary tables. The binary form is more
compact than the ASCII representation, especially for exponential
formats and numbers with many significant digits. Also, because many
machines are now storing floating point numbers internally in IEEE
format, using binary tables eliminates time and cost associated with
internal conversion in the machine. Again, one row corresponds to one
observation, but now the spectrum vector appears formally as a single
field. Parameters whose values are constant for the entire set of
observations would remain in the header, while those applying to a
single observation matrix would appear in the same row of the table. 
Example 4 in Appendix~\ref{s:ex} presents the header that might be
written for a simplified binary table structure for spectra proposed
by D.~Wells. 

\section{High Energy Astrophysics Applications}

The natural form for storing data for high energy astrophysics is as a
table of events.  Consequently, binary tables are used extensively for
high energy astrophysics data.  One example of a design for such tables
is that for data from the High Resolution Imager on ROSAT\@. 
                      
\begin{itemize}
\item The primary header, in addition to the required keywords,
contains data set identification and history. {\tt NAXIS} is set to
zero; there is no primary data array. 

\item The first extension is a ``Good
Time Intervals''~table, identifying those time intervals during which
the data received from the satellite can be regarded as valid
measurements. Each row of this table consists of two double-precision
floating point fields, listing the start time and end time of a time
interval where the data are valid. 

\item The next extension is the
``Events''~table, including most of the data from the native
time-ordered event file. 

\item The actual columns in the ROSAT tables contain
an information structure governed by the way in which the ROSAT readings
are organized. 
\end{itemize}

The kind of information obtained from any
high-energy experiment could be organized in a similar table. The header
could, in addition to the card images describing the structure of the
table, use keyword=value statements to convey such information as the
conversion between instrument and sky coordinates, zero points for
temporal and spatial scales, conversion between table values and
physical values, and the instrument configuration. The table would
contain such information as the coordinates (in the detector reference
frame) of the individual events, the time of an event, the energy of an
event, and the strength or intensity of an event.  Example 7 in Appendix
\ref{s:ex} shows a different FITS header for high energy astrophysics
data, from the Advanced Satellite for Cosmology and Astrophysics (ASCA). 
                             
			
\chapter{Resources}
\label{s:res}

\section{The FITS Support Office}

NASA has established the Flexible Image Transport System Support
Office to assist FITS users and work with the astronomical community on
the development and documentation of FITS\@.  The FITS Support Office is
a service of the Astrophysics Data Facility at NASA Goddard Space Flight
Center.                                                

The principal purposes of the FITS Support Office are to assist NASA
projects in developing FITS data sets, to provide FITS information to
the astronomical community and the public, and to take an active role in
the evolution of FITS.  Toward these ends, it has developed an on-line
library of information, documents, and software, available either
through the World Wide Web or through anonymous ftp.  Documents
developed by the  FITS Support Office are available in printed form as
well.  The FITS Support Office also will answer questions about specific
issues and problems not covered in the on-line material. For NASA
projects, the FITS office also reviews whether proposed designs for FITS
data sets and software conform to the FITS rules and recommended
practices; designs from other organizations may be reviewed if they
appear to be of wide community interest.  From the kinds of inquiries
received, the FITS office can develop a sense of the common questions
about the existing standard formats, the problems with them, and what
data structures, if any, these formats do not handle well. This
experience enables the FITS office to provide recommendations on
directions for FITS development to the IAU FITS Working Group and the
regional FITS committees, and to work with developers of potential new
extensions and conventions. 
                                                             
The FITS Support Office is coordinated by Dr. Barry M. Schlesinger, a
member of the IAUFWG, whose research background is in the areas of
stellar structure and evolution and variations in solar radiation. The
FITS office can be reached by telephone at  +1-301-286-2899. 

\subsection{On-line Information}
\label{s:online}

The FITS Support Office maintains World Wide Web and ftp sites at
Goddard Space Flight Center.  The FITS Support Office home page is at 
{\tt http://ssdoo.gsfc.nasa.gov/astro/fits/fits\_home.html}.  It
describes the on-line material available from the FITS Support office
and provides links both to the available hypertext material and to the
material available at the ftp site
{\tt nssdc.gsfc.nasa.gov/pub/fits/}.  It also links to other FITS
resources on the Web.  The ftp site has an {\tt aareadme.doc} file that
can be accessed directly, for those without Web connections.
                                               
The FITS Basics and Information page can be reached from the home page. 
It contains the following material:

\begin{itemize}
\item An overview of FITS, with a one-paragraph description and a
      discussion of how FITS evolves  

\item Discussion of FITS documents, both those available from the FITS
      Support Office and those available elsewhere

\item Discussion of software packages, including software for various
      platforms that can display FITS images

\item Discussion of other FITS resources available on-line

\item Discussion of the FITS Support Office with contact information

\end{itemize}  

Where possible, links are provided to the documents, software, and
network locations described.  There is also a plain text version,
available at the ftp site.  It provides URLs or other access information
for the material described.  

The FITS Support Office maintains the official current IAUFWG list of
registered extensions, as its agent.  This list is
available in both hypertext and plain text forms.  
                        
The FITS Support Office documentation discussed in section
\ref{s:FITSdoc} and the software and test files described in section
\ref{s:FITSsoft} are available from the Web page or at the ftp
site.


\subsection{Documents}
\label{s:FITSdoc}
No current document precisely and formally describes the structure and
syntax of FITS\@. The IAUFWG has endorsed the six  FITS papers (Wells,
Greisen, and Harten~1981; Greisen and Harten~1981; 
Grosb\o l {\em et al.}~1988; Harten et al.~1988; Ponz, Thompson, and
Mu\~{n}oz~1994; Cotton, Tody, and Pence~1995) and the floating point
and blocking agreements. By permission of the copyright holder, the
European Southern Observatory, the FITS Support Office can furnish
copies of the the first four FITS papers to non-profit organizations.
The text of the Floating Point Agreement appears in
section~\ref{s:IEEEflt} of this {\em Guide}, and the Blocking Agreement
is available electronically from the FITS Support Office at 
{\tt ftp://nssdc.gsfc.nasa.gov/pub/fits/blocking94.txt}.       

Largely because the format has evolved incrementally, there are a
number of inconsistencies and ambiguities among the FITS papers,
especially the first four.  To provide a document with a clear and
unambiguous specification of the rules of FITS, the NASA/Science
Office of Standards and Technology (NOST) has developed a formal
FITS codification, the {\em Definition of FITS\/} (NOST~1995). This
NOST standard was developed by technical panels of astronomers
chaired by R. Hanisch (STScI), chair of the Working Group on
Astronomical Software of the American Astronomical Society. The FITS
Support Office coordinator served as secretary of the panel, and the
FITS office was responsible for writing the original text and for
the bulk of the editing during the revision process.  
    
Development of the standard follows a procedure developed at the NOST
that follows the common practices of other standardization bodies.  The
technical panel develops an initial {\em Draft Standard}.  When the
panel has reached consensus on this {\em Draft Standard}, the document
is made available to the astronomical community for comment, typically
for a period of two months.  Availability of the document for review is
announced to the {\tt sci.astro.fits} newsgroup and to the electronic
mailing lists described in section \ref{s:othres}.  The American
Astronomical Society Executive Office also is notified.  Special efforts
are made to ensure review by members of the IAUFWG and the regional FITS
committees.  After the period for review is over, the technical panel
reviews the comments and revises the standard in reponse.  Replies are
sent to all reviewers, describing the changes made by the technical
panel in response to the review, and explaining the reasons when the
recommended revision was not made.  This cycle is repeated until the
number of revisions recommended by the reviewers is so small that it is
evident that the astronomical community has reached consensus.               

The document that results from this process is called a 
{\em Proposed Standard}.  This document is then submitted to a NOST
accreditation panel, composed of the NOST Executive Board (the NOST
Secretary, two other members from the Space Science Data Operations
Office, and one from NASA Headquarters) and an outside astronomer.  The
role of this panel is to review the {\em process\/} of developing the
standard: whether the steps taken to publicize the availability for
review were adequate to reach the entire interested community, whether
the technical panel replies addressed all the reviewers' points, and
whether the resulting {\em Proposed Standard\/} represents a consensus
of the community.                                              
                                    
Version 1.0 of the standard covered the rules in the first four FITS
papers and the floating point agreement.  There were three technical
panel review cycles.  On June 18, 1993, the accreditation panel
voted to approve the {\em Definition of FITS\/} as the NOST standard
for the use of FITS\@.  Questions about the specifications of units
led to the development of a revision, version 1.1.  There was only
one review cycle; the number of comments was small and the community
members present at the 1995 business meeting of the Working Group on
Astronomical Software agreed that this lack of comments reflected
general satisfaction with these changes.  Version 1.1 was approved
by the accreditation panel on June 14, 1995.   The NOST 
{\em Definition\/} has been submitted to the chair of the IAUFWG as the
start of the process of seeking endorsement of the NOST document as the
international standard for FITS\@.  In the ongoing electronic discussions
of FITS, FITS rules are frequently quoted in the form in which they are
expressed in the NOST document.                         
                                                                 
A technical panel has been formed to add the {\tt IMAGE} and  
{\tt BINTABLE} extensions and the blocking agreement to the NOST
standard.  Clarifications arising from community discussion of the FITS
rules also will be made.  The result of this process will be Version 2
of the {\em Definition of FITS}.

The standard is available in both printed and electronic form.
Electronic copies are available in several forms:~flat ASCII,
uncompressed PostScript, compressed PostScript,and \LaTeX.  Style  
({\tt nost.sty}) and index files are provided for use with the \LaTeX\
form. The three forms have identical content, except that the ASCII
version may not preserve the font usage in the other versions.  The
standard may be obtained from the anonymous ftp site in files of the
form {\tt fits\_standard.*} through links starting at the FITS Support
Office home page. When a {\em Draft Standard\/} is announced for
community review, it is available in the \LaTeX and PostScript forms; a
text form is sometimes available.                        
                             
The FITS Support Office maintains and updates this  {\em User's Guide},
which is designed to provide a better introduction to FITS for the
novice than the precise but dry standard. In addition to providing the
rules, it explains them in more detail than the standard and discusses
their motivation. It discusses recommended and discouraged practices and
provides hints on how to use particular structures. Sample FITS headers
illustrate the different formats. Some widely used conventions that are
not specified in the formal rules of FITS are described. The 
{\em Guide}\/ also discusses current FITS developments, including
proposals for new rules or conventions. Copies are available in printed 
form and electronically in compressed or uncompressed PostScript and
\LaTeX, in files of the form {\tt users\_guide.*}.  The style file 
{\tt guide.sty} is provided for use with the \LaTeX\ form. 
                           
\subsection{Software and Test Files}
\label{s:FITSsoft}
                            
The FITS Support Office has developed a simple C program called 
{\tt headlist} to read and list all the FITS headers in a file,
including extension headers as well as the primary header. It reads the
file from standard input and writes to standard output.  This program
is useful when presented with a new and unfamiliar file.  It does not
evaluate the file and is not guaranteed to work if there are serious
errors in the file, for example, if the size of the data in an extension
is not correctly described by the values of {\tt BITPIX}, {\tt NAXIS},
the  {\tt NAXIS}$n$, {\tt PCOUNT}, and {\tt GCOUNT}.                 
           
The FITS Support Office has a software package written in C called
the FITS Product Conformance Tester (FPCT), which validates conformance
of primary HDUs to the FITS Standard.  While  limited to Basic FITS
structures, its diagnostics are more descriptive than those of other
packages; it is also more forgiving, as it attempts to continue past
errors by making its best guess at what was intended rather than
terminating on the first error.  It is thus most useful for those new to
FITS.  The FPCT checks the primary header of a FITS file for the
presence of all required keywords and their order. If it can retrieve
information (values of {\tt BITPIX}, {\tt NAXIS}, and the 
{\tt NAXIS}$n$) needed to read the primary data array, and the data in
the array are integer, it will, at the user's option, produce an output
file containing array members selected by the user.  If the header is in
conformance, it will print a message to that effect. If the header is
not in conformance, but the software has inferred a data description, it
will print a warning that retrieval of the data array may not be
correct, with an indication of the severity of the problem.  If the FPCT
has been unable to retrieve the information needed to read the primary
data array, it will print a diagnostic with information about the header
errors and stop.               
           
Both packages are available in the {\tt software} subdirectory of the FITS
anonymous ftp directories described in section~\ref{s:online} or can be
obtained electronically by request from the FITS Support Office.  The
FPCT is accompanied by an instructions file.  Read this file before using
the software. 

The {\tt errtest} subdirectory contains a number of primary HDUs
designed for checking the ability of FITS readers to cope with the
unexpected. It includes one that is in compliance with the standard and
a number of others that are identical except for deliberately inserted
errors in syntax.  One is simply a text extract, to test the behavior of
the FITS reader when confronted with such a file, as might occur if such
a file were mistakenly retrieved instead of a FITS file.   An 
{\tt aaareadme.doc} file describes the contents of this subdirectory.
These files must be retrieved in {\em binary}\/ format if they are to
work properly.  Many Web browsers interpret FITS files as text by
default.  
                                  
\subsection{Contact Information}

Printed copies of documentation are obtained from the Coordinated
Request and User Support Office (CRUSO) 

\begin{quote}

(Electronic mail) {\tt request@nssdca.gsfc.nasa.gov}

(Telephone) +1-301-286-6695  8:00 A. M. - 4:30 P. M. 

(FAX) +1-301-286-1635

\end{quote}

(Postal)
\begin{verse}
Coordinated Request and User Support Office\\
Code 633\\
National Space Science Data Center\\
NASA Goddard Space Flight Center\\
Greenbelt MD 20771 USA
\end{verse}

Times are U. S. Eastern time: GMT -0500 from the last Sunday in October
through the first Saturday in April, -0400 the rest of the year.  If no one
is available to answer the telephone, messages can be left on voice mail.

Contact information for the FITS Support Office is as follows:

\begin{quote}

(Electronic mail) {\tt fits@nssdca.gsfc.nasa.gov}

(Telephone) +1-301-286-2899

\end{quote}

Approximate hours are 8:30 A. M. - 5:30 P. M. Eastern time; voice mail is
available.  

\section{NRAO FITS Resources}
\label{s:NRAOFITS}

An archive of FITS material is available at NRAO, at  
{\tt http://fits.cv.nrao.edu/} or {\tt ftp://fits.cv.nrao.edu/fits/}
This site also supports a WAIS server named {\tt nrao-fits} which
has an index of all of the FITS-related text files in the archive;
the file {\tt nrao-fits.src} is available at {\tt think.com} and at 
{\tt ftp://fits.cv.nrao.edu/fits/wais-sources/nrao-fits.src}, as
well as through the NRAO FITS Web site.                                
     
The {\tt documents} directory contains a number of subdirectories with
various FITS documents.  The formats of the documents depend upon the
size.  Some small documents are available in ASCII text.  Larger
documents are in PostScript and often in \LaTeX.  The largest documents
will also have gzip-compressed PostScript versions as well.  The 
{\tt standards} subdirectory contains copies of the NOST standard
described in section \ref{s:FITSdoc}, text of the agreement on physical
blocking, and copies of preliminary drafts of the binary table and image
extension papers.  The {\tt overviews} subdirectory contains electronic
copies of this {\em User's Guide\/} and some FITS history.  The 
{\tt proposals} subdirectory is for proposals that are ready for
consideration by the FITS committees.  The {\tt drafts} subdirectory
contains drafts for extensions or conventions that may or may not be
submitted to the FITS committees at a future time.  The {\tt wcs}
subdirectory contains the current draft proposal for world coordinates
conventions (Greisen and Calabretta~1996), draft conventions for world
coordinates keywords that would be used in conjunction with this
proposal, some earlier documents, and documents discussing map
projections.
                       
A directory called {\tt os-support} is devoted to code for various
environments.  It contains some software, as well as copies of Usenet
postings and mailing list announcements discussing other software.  The
information extends back over four years.

The {\tt data} directory contains two subdirectories of FITS files.
The  {\tt samples}  subdirectory contains a set of FITS data files
from different installations covering a number of disciplines, 
e.g., Hubble Space Telescope, IUE ultraviolet, radio VLBA and single
dish measurements, and illustrating FITS conventions, e.g., world
coordinates and grouping. The {\tt tests} subdirectory has under it two
subdirectories of test files.  One, {\tt ftt4b}, is a set of FITS files
from the early 1980s, which contains a number of images from that era
designed for testing FITS files and illustrating possible applications
of the format, including the Mandrill to illustrate one way to store
RGB\@. One file also provides a random groups example, which can be used
for testing by anyone with a need to read older data in that format. 
The other subdirectory, {\tt pg93}, contains test files specially
designed for testing the ability of software to handle all standard FITS
files, including the primary data array and all standard FITS
extensions.  In particular, one file contains an array with all the IEEE
special values: infinity, NaN, and denormalized numbers.  The data are
artificial, with values specially selected for the purpose of validating
the software's ability to read the data.             
                                       
The {\tt traffic} directory contains archives of FITS-related traffic
from Usenet newsgroups and mailing list.  It includes all postings to
{\tt sci.astro.fits} (the fitsbits mailing list), and FITS-related
postings to other newsgroups.  It also includes Frequently Asked
Questions (FAQ) from selected Usenet newsgroups.  FITS-related mailing
lists and FITS-related messages from other mailing lists 
also are archived here.
                                                          
W. Cotton has developed a family of FITS viewers for Microsoft Windows,
Apple Macintosh, and Unix/X-Windows computer systems.  These viewers
have easy to use graphical controls and are suitable for use as external
FITS image viewers for World Wide Web browsers.  The programs contain
extensive on-line documentation.  NRAO distributes these viewers free of
charge.  Further information on the capabilities of the software and access
to it are at {\tt http://www.cv.nrao.edu/\~{ }bcotton/fitsview.html}.

\section{HEASARC}
\label{s:HEsite}

The High Energy Astrophysics Science Archive Research Center
(HEASARC) at Goddard Space Flight Center has been active in the
development of FITS software and data set design.  It has developed and
continues to enhance packages of FITS subroutines and tools, which are
publicly available and widely used.  It has formulated a number of internal
conventions, which are primarily related to high energy astrophysics but
may have applications in other areas.  A number of these conventions are
discused in Section \ref{s:HFWGcon}.  HEASARC material is available
through their World Wide Web page at 
{\tt http://heasarc.gsfc.nasa.gov/}.  It is also available at 
{\tt ftp://legacy.gsfc.nasa.gov/}.  
       
HEASARC has developed two major software packages.  FITSIO is a
machine-independent subroutine interface for reading or writing FITS
files.  By using these subroutines, the programmer can avoid having
to deal directly with the internal details of the FITS file.  FITSIO
supports all the standard FITS file formats discussed in section
\ref{s:FITSfund}.  Some of the functions performed are opening and
closing files, reading, writing or modifying header keywords, and
reading or writing any element of a FITS data array or table.  It
also includes the VERIFITS program to verify that a FITS file
conforms to the FITS standard. In addition to supporting the standard
FITS formats, VERIFITS supports the variable length array convention
discussed in section \ref{s:varlen}.
      
There are FITSIO versions in portable FORTRAN-77 and in ANSI C\@. 
Both versions run on Sun, DECstations, VAX/VMS, DEC Alpha (VMS and
OSF/1), SGI, HP, NeXT, IBM PCs (DOS and Linux), Amiga PCs and
Macintosh PCs; the FORTRAN version runs on Cray supercomputers and
IBM mainframes as well. FITSIO requires random access I/O to the file
and therefore does not support direct read or write access to sequential
devices such as magnetic tape drives.  

FITSIO source code and documentation are available through the Web
from the {\tt Software} item on the HEASARC menu bar or directly from 
{\tt ftp://legacy.gsfc.nasa.gov/software/fitsio}.

The other package, FTOOLS, is a collection of utility programs, in
ANSI Fortran or C, that allows the user to interactively create,
examine, or modify the contents of FITS files, utilizing the FITSIO
package.  Perl5 scripts are available for combining several FTOOLS
to perform complex tasks.  FTOOLS supports all the standard FITS
file formats discussed in Section \ref{s:FITSfund}.  

A general FITS file viewer and editor called fv is included as a
standard part of the FTOOLS distribution and is available as a
standalone package as well.  It can be used for viewing and plotting any
FITS format data file.  It has a graphical user interface (GUI) written
in Tcl/Tk that provides spreadsheet-like widgets to display and edit
data in any FITS table or image, a scrolling text window to display and
edit FITS header keywords, and an image display that uses either the 
Smithsonian Astrophysical Observatory - The Next Generation (SAOtng)
display tool or a custom designed Tk image widget. Users can also
produce line plots of the values in two or more columns of a FITS table
and export the plots to a PostScript file.
                                   
As of this writing, fv is supported on most Unix platforms; support for
IBM and Macintosh PCs is planned.

The FTOOLS
package, documentation, and installation instructions are available
from the {\tt Software} item on the HEASARC menu block or directly
from {\tt ftp://legacy.gsfc.nasa.gov/software/ftools}.  The fv tool is
available at the same location.   
 
The HEASARC FITS Working Group (HFWG), a body within HEASARC
established to support present and future multimission needs of the
OGIP at NASA, and, in particular, to ensure that the FITS formats and
keywords used do not violate the FITS standards, has developed a number
of conventions and designs.  While use of these conventions and designs
is required only for OGIP, the high energy astrophysics community has
been consulted during the development process, and many of these
conventions are used elsewhere for high energy astrophysics FITS
files and other FITS files.  A number of these conventions have been
described in section \ref{s:HFWGcon}.  Other conventions specify
keywords and strings to be used for such information as quality flags,
channel boundaries, exposure times, and units.  Among the standard file
formats are those for light curves and spectra.  Complete documentation
on the recommendations and formats that have been adopted by HFWG and on
those that are under consideration can be found at 
{\tt heasarc.gsfc.nasa.gov/docs/heasarc/ofwg/ofwg\_intro.html}
on the HEASARC main Web page or directly by
ftp to {\tt ftp://legacy.gsfc.nasa.gov/}.
                                                   
The archive of traffic on the {\tt heafits} mail exploder also is accessible
from the HFWG page. 

\section{Some Additional Software Resources}

FITS I/O software written in IDL is available as part of the IDL
Astronomy User's Library, a central repository for general purpose
astronomy procedures written in IDL, including procedures to convert
between spherical coordinates and plane map coordinates. The library is
not meant to be an integrated package but rather is a collection of
procedures from which users can pick and choose for their own use.
Submitted procedures are given a cursory testing but are basically
stored in the library as submitted.  The Astronomy User's Library is
supported under the NASA Astrophysics Software Aids program. The
material is available through 
{\tt idlastro.gsfc.nasa.gov/home\_page.html} or at 
{\tt ftp://idlastro.gsfc.nasa.gov} (IP~128.183.57.82). 
                                               
The Astronomical Data Center (ADC) at NASA/GSFC has developed a FITS
Table Browser, which has been tailored specifically for use with the
ADC CD-ROMs but may be used with other FITS ASCII tables.  It reads
standard FITS ASCII tables and allows the user to browse through
them interactively and selectively display any field or record in a
table.  File extraction facilities permit writing all or part of the
input table to disk in FITS or text file format.  It is available at 
{\tt ftp://adc.gsfc.nasa.gov/pub/adc/software/browsers/ftb}.  See
the file  {\tt ftb\_user\_guide.txt} for instructions on downloading,
installation, and use.    

The IUEDAC software (which is written in IDL) includes a FITS reader 
that can read primary HDUs and image extensions, ASCII tables, and
binary tables, including binary tables with variable-length and
multi-dimensional arrays.  The accompanying FITS writer can write
primary HDUs, image extensions, and binary tables including
multi-dimensional but not variable length arrays, but it cannot write
ASCII tables. The software is available from 
{\tt ftp://iuewww.gsfc.nasa.gov} and runs on Unix, Ultrix, VMS, MacOS,
and Windows 3.1 systems.           
                        
The National Center for Supercomputing Applications (NCSA) Hierarchical
Data Format (HDF) group is developing a FITS server-side browser. 
Among the things it can do now are the following:

\begin{itemize}

\item Retrieve the images from a FITS file

\item Allow viewing of a group of planes from a 3-D image

\item Get summary information from the primary or extension headers

\item Create an HTML table from an ASCII or binary table.

\end{itemize}

NCSA is also developing FITS--HDF conversion utilities.  Because this
site is evolving rapidly, the individual URLs have been changing, but it
should be possible to find the FITS material by starting at 
{\tt http://hdf.ncsa.uiuc.edu/}.

The three principal astronomical image processing software  packages---
AIPS, the ESO-Munich Interactive Data Analysis System (ESO-MIDAS), and
IRAF---incorporate substantial support for FITS. 

New software to display FITS images continues to be developed.  Some
nonproprietary packages are mentioned in one section of the FITS
Basics and Information.  A general discussion of software to convert
between formats, including FITS, is in part 2 of the Graphics File
Format FAQ, which is periodically posted to the newsgroups 
{\tt comp.graphics.misc},  {\tt comp.answers} and {\tt news.answers}. 
It is also archived at {\tt ftp://rtfm.mit.edu/pub/usenet/} and 
{\tt http://www.cis.ohio-state.edu/hypertext/faq/usenet-faqs/}.  The MIT
site is often busy.  The Ohio State site is occasionally reorganized
with changes in the lower level of the URL.                
                         
\section{Other Network Resources}
\label{s:othres}

A Usenet newsgroup, {\tt sci.astro.fits}, is devoted to FITS\@.  For
those who prefer, there is an associated {\tt fitsbits} mailing
list. To subscribe, send electronic mail to 
{\tt fitsbits-request@fits.cv.nrao.edu}. This newsgroup/mailing list
is the principal forum for FITS discussions and announcements.
Developments in the evolution of new extensions will appear there:
reservation of type names, information on where to find particular
proposals, discussions of the proposals, and notification of actions
by the regional and international FITS bodies. The FITS Support
Office uses this forum to announce developments such as
progress on updates to the standard or a new edition of this 
{\em User's Guide}. Developers of publicly available FITS software
packages also announce their packages here. In addition to the
announcements, there is general discussion of FITS practices. The
FITS Support Office maintains a monthly posting describing
where FITS information can be obtained, which is posted as well to
the newsgroups {\tt sci.answers} and {\tt news.answers} and is
consequently automatically available at Usenet FAQ archives.
    
The exploder {\tt dishfits@nrao.edu} was created to facilitate discussions
on the subject of FITS formats for single dish radio astronomy.  This
exploder is now gatewayed to the newsgroup {\tt adass.fits.dishfits}.
To subscribe send electronic mail to {\tt dishfits-request@nrao.edu}.
Traffic on this exploder is archived at the NRAO site.
 
HEASARC has set up an electronic mail listserver called {\tt heafits} for
FITS issues that are specific to high energy astrophysics.  To 
{\em subscribe}\/ to the {\tt heafits} list, send the following one-line
electronic mail message to {\tt listserv@legacy.gsfc.nasa.gov}:

\begin{quote}
{\tt subscribe heafits} Your Name
\end{quote}

where ``Your Name'' is your actual first and last names.  Messages to the
actual mailing list should be sent to {\tt heafits@legacy.gsfc.nasa.gov}.
An archive is at 
{\tt http://heasarc.gsfc.nasa.gov/listserv/heafits/maillist.html}.
There is a link to it from the HFWG page.

An anonymous ftp directory of FITS material is maintained at
the European Southern Observatory.  Its address is 
{\tt ftphost.hq.eso.org} (IP~134.171.8.4). 


\appendix

\chapter{Examples of FITS Headers}
\label{s:ex}

\raggedright

\section*{Example 1: ~VLA Image Header}

(Note: The first two lines following are provided to help the reader
determine column numbers. They are not part of FITS headers.)
\begin{verbatim}
00000000011111111112222222222333333333344444444445555555555666666666
12345678901234567890123456789012345678901234567890123456789012345678
SIMPLE  =                    T /
BITPIX  =                   16 /
NAXIS   =                    4 /
NAXIS1  =                 2048 /
NAXIS2  =                 1024 /
NAXIS3  =                    1 /
NAXIS4  =                    1 /
EXTEND  =                    T / TABLES FOLLOWING MAIN IMAGE
BLOCKED =                    T / FILE MAY BE BLOCKED
OBJECT  = '3C405   '           / SOURCE NAME
TELESCOP= '        '           /
INSTRUME= '        '           /
OBSERVER= 'PERL    '           /
DATE-OBS= '27/10/82'           /OBSERVATION START DATE DD/MM/YY
DATE-MAP= '14/07/83'           /DATE OF LAST PROCESSING DD/MM/YY
BSCALE  =    7.04625720812E-05 /REAL = FITS_VALUE * BSCALE + BZERO 
BZERO   =    2.18688869476E+00 /
BUNIT   = 'JY/BEAM '           /UNITS OF FLUX
EPOCH   =      1.950000000E+03 /EPOCH OF RA DEC
DATAMAX =      4.495524406E+00 /MAX PIXEL VALUE
DATAMIN =     -1.217470840E-01 /MIN PIXEL VALUE
CTYPE1  = 'RA---SIN'           /
CRVAL1  =    2.99435165226E+02 /
CDELT1  =     -4.166666986E-05 /
CRPIX1  =      1.024000000E+03 /
CROTA1  =      0.000000000E+00 /
CTYPE2  = 'DEC--SIN'           /
CRVAL2  =    4.05961940065E+01 /
CDELT2  =      4.166666986E-05 /
CRPIX2  =      5.130000000E+02 /
CROTA2  =      0.000000000E+00 /
CTYPE3  = 'FREQ    '           /
CRVAL3  =    4.86635000000E+09 /
CDELT3  =      1.250000000E+07 /
CRPIX3  =      1.000000000E+00 /
CROTA3  =      0.000000000E+00 /
CTYPE4  = 'STOKES  '           /
CRVAL4  =    1.00000000000E+00 /
CDELT4  =      1.000000000E+00 /
CRPIX4  =      1.000000000E+00 /
CROTA4  =      0.000000000E+00 /
HISTORY UVLOD /DATA BASE CREATED BY USER 76 AT 14-JUL-1983`10:17:08
HISTORY UVLOD OUTNAME='CYGA       ' OUTCLASS='XY    '
HISTORY UVLOD OUTSEQ=    1    OUTDISK= 3
ORIGIN  = 'AIPSNRAO VLA VAX3  '        /
DATE    = '19/08/83'                   / FILE WRITTEN ON DD/MM/YY
HISTORY AIPS   IMNAME='CYGA   '      IMCLASS='IMAP  ' IMSEQ=   1 /
HISTORY AIPS   USERNO=   76            /
END  
\end{verbatim}

(23 card images of ASCII blanks)

\newpage
\section*{Discussion of Example 1 (VLA Image Header)}

This header describes an image of 3C405 ({\tt OBJECT} keyword) on 27
October~1982 ({\tt DATE-OBS} keyword) by an observer with the
designation ``Perl'' ({\tt OBSERVER} keyword). The data matrix has four
axes: right ascension, declination, frequency, and polarization 
({\tt NAXIS}$n$ and {\tt CTYPE}$n$ keywords). The matrix here contains
an image for only one frequency and polarization. The sine projection
from the sky sphere to the tangent plane is used. The coordinates are
equinox 1950 (note the use of the {\tt EPOCH} keyword, now discouraged;
use {\tt EQUINOX} instead). Right ascension is in  {\em degrees},
extending from approximately 299.47779 degrees at point (pixel) 1 to
approximately 299.3925 at point 2048, with the value 299.435165226 at
point 1024 ({\tt CRVAL1}, {\tt CDELT1}, {\tt CRPIX1}). Declination, in
degrees, runs from approximately 40.57486 to approximately 40.61848,
with the value 40.5961940065 at pixel 513 ({\tt CRVAL2}, {\tt CDELT2},
{\tt CRPIX2}). The measurement is at 4866.35 MHz ({\tt CRVAL3}).  
{\tt CDELT3} is not significant here; there is only one point.  The
values are stored in 16-bit integer format ({\tt BITPIX} keyword).
Values in the matrix are converted to flux in Janskys per beam 
({\tt BUNIT} keyword) by multiplying by 7.04625720812 ({\tt BSCALE}
keyword) and adding 2.18688869476 ({\tt BZERO} keyword),
corresponding to a range of data matrix values of~$-0.121747084$
(physical value) or $-32764$ (in file) to 4.495524406 (physical
value) or  32764 (in file) Janskys per beam. The {\tt EXTEND}
keyword has the value {\tt T}, indicating that this Basic FITS unit
may be followed by extensions; the comment notes that it is followed
by tables. The use of the {\tt HISTORY} keywords may appear to be
analogous to the  {\tt HIERARCH} proposal; however, the embedded
``keywords'' have meaning only within AIPS; to the rest of the world
they are comments and can be treated as such.                          


\newpage
\section*{Example 2: ~M87 and Jet (KPNO)}

(Note: The first two lines following are provided to help the reader
determine column numbers. They are not part of FITS headers.)
\begin{footnotesize} 
 \begin{verbatim}
000000000111111111122222222223333333333444444444455555555556666666666777
123456789012345678901234567890123456789012345678901234567890123456789012
SIMPLE  =                    T  /  FITS TAPE WRITTEN AT KPNO, 04/18/80. 
BITPIX  =                   32  /  4-BYTE, 2-S COMPLEMENT INTEGERS. 
NAXIS   =                    2  /  NUMBER OF AXES. 
NAXIS1  =                  256  /  NUMBER OF PIXELS PER ROW. 
NAXIS2  =                  256  /  NUMBER OF ROWS. 
BSCALE  =          1.00000E-06  /  PHYSICAL=INTEGER*BSCALE+BZERO. 
BZERO   =                   0.  / 
BLANK   =          -2147483648  /  INTEGER VALUE FOR BLANK PIXEL. 

IPPS-RF = 'D      /013'         /  RASTER LFN/RASTER ORDINAL. 
IPPS-ID = 'N4486 NUCLEUS AND JET 4350 [9 BAD PIXELS BLANKED]        ' / 
IPPS-B/P=                   30  /  BITS/PIXEL OF IPPS RASTER. 
IPPS-MIN=         3.700018E-02  /  MINIMUM VALUE IN RASTER. 
IPPS-MAX=              1.19825  /  MAXIMUM VALUE IN RASTER. 
ORIGIN  = 'KPNO    -- WFITS OF 04/17/80.' / 
DATE    = '18/04/80'                             / 
TIME    = '10.11.54' 
JOBNAME = 'DCWGF27 ' 
COMMENT   THIS FILE TESTS THE 32-BIT PIXEL FORMAT. 
COMMENT   IT ALSO TESTS THE BLANK PIXEL CONVENTION. THERE ARE 9 BLANKS IN THIS 
COMMENT   IMAGE. THEY ARE A DETECTOR BLEMISH AREA. NOT ALL OF THE BLEMISH HAS
COMMENT   BEEN BLANKED. 

OBJECT  = 'NGC4486  =M87 AND JET' / 
TELESCOP= 'MAYALL4M'           / MAYALL 4-METER TELESCOPE AT KITT PEAK.
INSTRUME= 'VIDEOCAM - MAYALL 4M CASSEGRAIN' / 

COMMENT   THE KPNO "VIDEO CAMERA" IS AN INTEGRATING DIGITAL TELEVISION SYSTEM
COMMENT   WHICH USES AN  RCA ISIT VIDICON TUBE AND ACCUMULATES THE IMAGE IN 
COMMENT   A 256-SQUARE 20-BIT RAM DURING THE INTEGRATION. 
COMMENT   THIS IMAGE HAS BEEN CORRECTED FOR THE DARK CURRENT AND GAIN VARIATIONS
COMMENT   ACROSS THE FIELD. I.E., THE DARK IMAGE WAS SUBTRACTED, AND THE FLAT 
COMMENT   FIELD IMAGE WAS DIVIDED INTO THE RAW IMAGE. BECAUSE THE FLAT WAS NOT 
COMMENT   NORMALIZED IN THIS CASE, THE RESULTING RATIO IMAGE IS OF ORDER UNITY.
COMMENT   THIS IS A QUANTUM NOISE LIMITED IMAGE IN RELATIVE INTENSITY UNITS. 
COMMENT   THE GEOMETRY OF THIS IMAGE HAS NOT BEEN CORRECTED FOR THE PINCUSHION 
COMMENT   DISTORTION OF THE VIDEO CAMERA. 

END 
 \end{verbatim}
\end{footnotesize}
(33 card images of ASCII blanks)

\newpage
\section*{Discussion of Example 2 (M87 and Jet)}
                                                      
This header is based on the NRAO anonymous ftp collection of FITS files.
There have been some minor revisions, none of which affect required or
reserved keywords, to bring the style into conformance with recommended
practice. Internal comments explain most of the keywords in detail. The
data following this header will consist of a 256 x 256  ({\tt NAXIS1},
{\tt NAXIS2} keywords) matrix of 32-bit integers  ({\tt BITPIX}
keyword). To derive the physical value represented, the integer on the
original FITS tape must be multiplied by  10$^{\rm -6 }$  ({\tt BSCALE}
keyword). Array members (pixels) that contain a $-2147483648$ are to be
treated as not containing real data values  ({\tt BLANK} keyword). The
matrix represents KPNO video camera  ({\tt INSTRUME} keyword) pictures
of M87 ({\tt OBJECT} keyword) taken on the Mayall 4 meter telescope
({\tt TELESCOP} keyword). The tape was created on 18 April~1980 
({\tt DATE} keyword). The date of the observations is not given in this
header; if it were, there would be a  {\tt DATE-OBS} keyword. Note that
even though some of the character string values are more than eight
characters long, it is possible to obtain the essential information from
reading only the first eight characters. There are also five keywords
that are neither required nor reserved FITS keywords, those beginning
with {\tt IPPS-}. They illustrate how new keywords can be created for a
FITS data set. Note the blank lines. The blanks in columns 1--8 indicate
that columns 9--80 are to be treated as comment; in this case, they are
blank.                     
                                                      
\newpage
\section*{Example 3: ~ASCII Table}

(Note: The first two lines following are provided to help the reader
determine column numbers. They are not part of FITS headers.) 
\begin{verbatim}
00000000011111111112222222222333333333344444444445555555555666666666
12345678901234567890123456789012345678901234567890123456789012345678
SIMPLE  =                    T / STANDARD FITS FORMAT (REV OCT 1981)
BITPIX  =                    8 / CHARACTER INFORMATION
NAXIS   =                    0 / NO IMAGE DATA ARRAY PRESENT  
EXTEND  =                    T / THERE IS AN EXTENSION
ORIGIN  = 'ESO     '           / EUROPEAN SOUTHERN OBSERVATORY
OBJECT  = 'SNG - CAT.     '    / THE IDENTIFIER
DATE    = '27/ 5/84'           / DATE THIS TAPE WRITTEN DD/MM/YY  
END
\end{verbatim}

(28 card images of ASCII blanks)

\begin{verbatim}
XTENSION= 'TABLE   '           / TABLE EXTENSION
BITPIX  =                    8 / CHARACTER INFORMATION
NAXIS   =                    2 / SIMPLE 2-D MATRIX 
NAXIS1  =                   98 / NO. OF CHARACTERS PER ROW
NAXIS2  =                   10 / NO. OF ROWS
PCOUNT  =                    0 / RANDOM PARAMETER COUNT
GCOUNT  =                    1 / GROUP COUNT
TFIELDS =                    7 / NO. OF FIELDS PER ROW
TTYPE1  = 'IDEN.   '           / NAME OF ROW
TBCOL1  =                    1 / BEGINNING COLUMN OF THE FIELD
TFORM1  = 'E14.7   '           / FORMAT
TNULL1  = '        '           / NULL VALUE
TTYPE2  = 'RA      '           / NAME OF ROW
TBCOL2  =                   15 / BEGINNING COLUMN OF THE FIELD
TFORM2  = 'E14.7   '           / FORMAT
TNULL2  = '        '           / NULL VALUE  
TTYPE3  = 'DEC     '           / NAME OF ROW
TBCOL3  =                   29 / BEGINNING COLUMN OF THE FIELD
TFORM3  = 'E14.7   '           / FORMAT 
TNULL3  = '        '           / NULL NAME
TTYPE4  = 'TYPE    '           / NAME OF ROW
TBCOL4  =                   43 / BEGINNING COLUMN OF THE FIELD
TFORM4  = 'E14.7   '           / FORMAT
TNULL4  = '        '           / NULL VALUE
TTYPE5  = 'D25     '           / NAME OF ROW
TBCOL5  =                   57 / BEGINNING OF COLUMN OF THE FIELD
TFORM5  = 'E14.7   '           / FORMAT
TNULL5  = '        '           / NULL VALUE
TTYPE6  = 'INCL.   '           / NAME OF ROW
TBCOL6  =                   71 / BEGINNING COLUMN OF THE FIELD
TFORM6  = 'E14.7   '           / FORMAT
TNULL6  = '        '           / NULL VALUE
TTYPE7  = 'RV      '           / NAME OF ROW
TBCOL7  =                   85 / BEGINNING COLUMN OF THE FIELD
TFORM7  = 'E14.7   '           / FORMAT
TNULL7  = '        '           / NULL VALUE
END
\end{verbatim}

(35 card images of ASCII blanks)

\newpage
\section*{Discussion of Example 3 (A Galaxy Catalog in an ASCII Table)}

This pair of headers illustrates the case where all the data are in an
extension. Like Example 2, it is from the NRAO ftp collection. It is a
catalog of galaxies, probably of parent galaxies of supernovae 
({\tt OBJECT} keyword) originating at the European Southern Observatory
({\tt ORIGIN} keyword and comments). It was created on 27 May~1984 
({\tt DATE} keyword) and thus may not show how ESO-MIDAS would now write
an ASCII table, but it can still illustrate the format. The primary
header carries two additional pieces of information: that there is no
primary data array (value of zero for {\tt NAXIS} keyword) and that an
extension {\em may\/} be present ({\tt T} value for {\tt EXTEND}
keyword). The comment following the {\tt EXTEND} keyword notes that an
extension {\em is\/} present. The {\tt END} card image is followed by 28
card images consisting of ASCII blanks, to fill the record to 2880
bytes. The string  {\tt XTENSION= 'TABLE~~~'} at the start of the next
record introduces the header of an ASCII table extension. The 
{\tt BITPIX},  {\tt NAXIS}, {\tt PCOUNT}, and {\tt GCOUNT} keywords have
the values required for an ASCII table. The {\tt NAXIS}$n$ keywords show
that it is ten rows long with 98 characters per row. Each row consists
of seven fields ({\tt TFIELDS} keyword), all in FORTRAN format E14.7 
({\tt TFORM}$n$ keywords), with no blanks between ({\tt TBCOL}$n$
keywords). A null value in any field is represented by a blank 
({\tt TNULL}$n$ keywords). The seven fields in each row represent a
galaxy identifier, right ascension, declination, type, diameter of the
galaxy at the 25 mag/arcsec level, inclination, and radial velocity,
respectively ({\tt TTYPE}$n$ keywords).                        
                                                               
\newpage
\section*{Example 4: ~Binary Table Containing Spectra}

(Note: The first two lines following are provided to help the reader
determine column numbers. They are not part of FITS headers.) 

\begin{small}
 \begin{verbatim}
000000000111111111122222222223333333333444444444455555555556666666666
123456789012345678901234567890123456789012345678901234567890123456789
XTENSION= 'BINTABLE'         T / BINARY TABLE EXTENSION
BITPIX  =                    8 / BYTES
NAXIS   =                    2 / A TABLE IS A 2D MATRIX
NAXIS1  =                 4134 / BYTES PER ROW
NAXIS2  =                   20 / NUMBER OF ROWS
PCOUNT  =                    0 / NO `PARAMETERS'
GCOUNT  =                    1 / ONE TABLE
TFIELDS =                    6 / 6 FIELDS PER ROW  
EXTNAME = 'SPECTRUM'           / SAMPLE OF BINARY TABLE WITH SPECTRUM
EXTVER  =                    2 / SECOND VERSION OF TABLE
TFORM1  = '1J      '           / FIELD 1 - 32 BIT INTEGER
TTYPE1  = 'SCAN    '           / SCAN NUMBER
TFORM2  = '20A     '           / FIELD 2 - 20 CHARACTER STRING
TTYPE2  = 'SOURCE  '           / SOURCE NAME
TFORM3  = '1D      '           / FIELD 3 - DOUBLE PREC FLOATING POINT
TTYPE3  = 'BASEFREQ'           / REFERENCE CHANNEL
TUNIT3  = 'HZ      '           / FREQUENCIES IN HERTZ
TFORM4  = '1E      '           / FIELD 4 - SINGLE PREC FLOATING POINT
TTYPE4  = 'DELTFREQ'           / FREQUENCY INCREMENT
TUNIT4  = 'HZ      '           / FREQUENCIES IN HERTZ
TFORM5  = '1I      '           / FIELD 5 - 16 BIT INT
TTYPE5  = 'NCHAN   '           / NUMBER OF CHANNELS
TFORM6  = '1024E   '           / FIELD 6 1024 SNGL PREC FLT PT VALUES
TTYPE6  = 'SPECTRUM'           / MEASURED SPECTRUM
TUNIT6  = 'JY      '           / JANSKYS
COMMENT   FIELD 6 IS A VECTOR
END
 \end{verbatim}
\end{small}

(9 card images of ASCII blanks)

\newpage
\section*{Discussion of Example 4 (A Binary Table Containing Spectra)}

This extension header is the one that would be used for a structure
designed by D. Wells to illustrate an efficient use of a binary table
to hold spectra. The spectrometer for this illustration has 1024
channels, and the data are in floating point form. This design is,
intentionally, grossly simplified for the sole purpose of
illustration. Wells notes that real spectral observations would
probably require 50 table columns in each row in addition to the
spectra. The precise column labels are not part of the proposal; if
such a structure were to be adopted, an {\em ad hoc} group would work
out the details. Also, the data types used might vary among
installations. 

In this example, the primary header is not included, but, as with the
ASCII table extension example, there must be one to start the data set.
Other extensions might be present as well, so this extension isn't
necessarily going to be the second header-data unit on the data set. The 
{\tt XTENSION=~'BINTABLE'} string at the start of the record indicates
that the header is for a binary table extension. The {\tt BITPIX},  
{\tt NAXIS}, and {\tt GCOUNT} keywords have the values required
for a binary table extension.  The value of 0 for {\tt PCOUNT} shows
that there are no heap or other data following the table.  To describe
one spectrum, 4134 bytes are needed  ({\tt NAXIS1}); this particular
table has 20 spectra  ({\tt NAXIS2}). The {\tt NAXIS1} value is equal to
the sum of the number of bytes required by the different fields. Each
row of the table can hold a 1024-channel spectrum and five additional
items of information to describe it: scan number, source ID, frequency
of reference channel, channel-to-channel difference, and the total
number of channels. Frequencies are in Hertz ({\tt TUNIT3} and 
{\tt TUNIT4} keywords). There is room in field 6 for 1024 channels;
there could be fewer. The title or name of the table is SPECTRUM 
({\tt EXTNAME} keyword); this table could be the second version or
perhaps the second spectrum in the FITS file ({\tt EXTVER} keyword).        
                                                              
\newpage
\section*{Example 5: ADC FITS Table Header for AGK3 Catalog}

(Note: The first two lines following are provided to help the reader
determine column numbers.  They are not part of FITS headers.)        

\begin{footnotesize}
\begin{verbatim}

000000000111111111122222222223333333333444444444455555555556666666666777
123456789012345678901234567890123456789012345678901234567890123456789012
XTENSION= 'TABLE   '           / Table extension
BITPIX  =                    8 / Character data
NAXIS   =                    2 / Simple 2-D matrix
NAXIS1  =                   80 / Number of characters per record
NAXIS2  =               183145 / Number of records in the table
PCOUNT  =                    0 / No "random" parameters
GCOUNT  =                    1 / Only one group
TFIELDS =                   22 / Number of data fields per record
EXTNAME = 'AGK3    '           / AGK3 Star Catalogue of Positions
AUTHOR  = 'Dieckvoss, W.'
REFERENC= '1975, Hamburg-Bergedorf'
DATE    = '15/09/88'           / Date FITS file verified (dd/mm/yy)

HISTORY Source Catalog Reference:  AGK3 Star Catalogue of Positions and Proper
HISTORY Motions North of -2.5 Degrees Declination, Dieckvoss, W. (in
HISTORY collaboration with H. Kox, A. Guenther, and E. Brosterhaus) 1975,
HISTORY Hamburg-Bergedorf.
HISTORY
HISTORY A copy of "Documentation for the Machine-Readable Version of the
HISTORY AGK3 Star Catalogue of Positions and Proper Motions North of -2.5
HISTORY Degrees Declination (Dieckvoss and Collaborators 1975)", Warren Jr.,
HISTORY W.H. 1984, NSSDC/WDC-A-R&S 84-06, should accompany any computer-
HISTORY readable version of this catalog.

TTYPE1  = 'AGK3    '           / AGK3 zone and sequential number
TBCOL1  =                    1 / Start column
TFORM1  = 'A7      '           / Fortran format

TTYPE2  = 'AGK3_COMP'          / Component identification
TBCOL2  =                    8 / Start column
TFORM2  = 'A1      '           / Fortran format
TNULL2  = '0       '           / Null value

TTYPE3  = 'PMAG    '           / Photographic magnitude
TBCOL3  =                    9 / Start column
TFORM3  = 'I3      '           / Fortran format
TUNIT3  = 'mag     '           / Units are magnitudes
TSCAL3  =                  0.1 / Scale factor

TTYPE4  = 'SPTYPE  '           / Spectral type from HD, Yale, or McCormick
TBCOL4  =                   12 / Start column
TFORM4  = 'A2      '           / Fortran format

TTYPE5  = 'RAH     '           / Hours RA, epoch, equinox B1950
TBCOL5  =                   14 / Start column
TFORM5  = 'I2      '           / Fortran format
TUNIT5  = 'h       '           / Units are hours

TTYPE6  = 'RAM     '           / Minutes RA, epoch, equinox B1950
TBCOL6  =                   16 / Start column
TFORM6  = 'I2      '           / Fortran format
TUNIT6  = 'min     '           / Units are minutes of time

TTYPE7  = 'RAS     '           / Seconds RA, epoch, equinox B1950
TBCOL7  =                   18 / Start column
TFORM7  = 'I5      '           / Fortran format
TUNIT7  = 's       '           / Units are seconds of time
TSCAL7  =                0.001 / Scale factor

TTYPE8  = 'DECSIGN '           / Sign DEC, epoch, equinox B1950
TBCOL8  =                   23 / Start column
TFORM8  = 'A1      '           / Fortran format

TTYPE9  = 'DECD    '           / Degrees DEC, epoch, equinox B1950
TBCOL9  =                   24 / Start column
TFORM9  = 'I2      '           / Fortran format
TUNIT9  = 'deg     '           / Units are degrees

TTYPE10 = 'DECM    '           / Minutes DEC, epoch, equinox B1950
TBCOL10 =                   26 / Start column
TFORM10 = 'I2      '           / Fortran format
TUNIT10 = 'arcmin  '           / Units are minutes of arc

TTYPE11 = 'DECS    '           / Seconds DEC, epoch, equinox B1950
TBCOL11 =                   28 / Start column
TFORM11 = 'I4      '           / Fortran format
TUNIT11 = 'arcsec  '           / Units are seconds of arc
TSCAL11 =                 0.01 / Scale factor

TTYPE12 = 'NUMOBS  '           / Number of photog. obs. used to determine pos.
TBCOL12 =                   32 / Start column
TFORM12 = 'I2      '           / Fortran format

TTYPE13 = 'EPOCH   '           / (Epoch of AGK3 position) - 1900
TBCOL13 =                   34 / Start column
TFORM13 = 'I4      '           / Fortran  format
TUNIT13 = 'yr      '           / Units are years
TSCAL13 =                 0.01 / Scale factor
TZERO13 =               1900.0 / Zero offset

TTYPE14 = 'PM_RA_COSD'         / Annual proper motion in RA times Cos(delta)
TBCOL14 =                   38 / Start column
TFORM14 = 'I5      '           / Fortran format
TUNIT14 = 'arcsec/yr'          / Units are arcseconds per year
TSCAL14 =                0.001 / Scale factor

TTYPE15 = 'PM_DEC  '           / Annual proper motion in DEC
TBCOL15 =                   43 / Start column
TFORM15 = 'I5      '           / Fortran format
TUNIT15 = 'arcsec/yr'          / Units are arcseconds per year
TSCAL15 =                0.001 / Scale factor
COMMENT PM_DEC: If the calculated value for PM_RA_COSD or PM_DEC exceeded the
COMMENT PM_DEC: capacity of the field, a value of "+9999" is given.

TTYPE16 = 'EPOCH_DIFF'         / Difference in epoch (AGK3 - AGK2)
TBCOL16 =                   48 / Start column
TFORM16 = 'I4      '           / Fortran format
TUNIT16 = 'yr      '           / Units are years
TSCAL16 =                 0.01 / Scale factor

TTYPE17 = 'BD      '           / Bonner Durchmusterung number
TBCOL17 =                   52 / Start column
TFORM17 = 'A7      '           / Fortran format

TTYPE18 = 'BD_COMP '           / Numerical code for component of multiple system
TBCOL18 =                   59 / Start column
TFORM18 = 'I1      '           / Fortran format
TNULL18 = '0       '           / Null value

TTYPE19 = 'DISC_SUM'           / Sum of discrepancy codes, see comment
TBCOL19 =                   60 / Start column
TFORM19 = 'I2      '           / Fortran format
COMMENT DISC_SUM: The sum of discrepancy codes, or the sum of 2**V, where
COMMENT DISC_SUM: V = 0 (BD number), 1 (PMAG and/or spectral type), 2 (RA of
COMMENT DISC_SUM: AGK2), 3 (DEC of AGK2), 4 (RA of AGK3), 5 (DEC of AGK3).

TTYPE20 = 'PM_RA   '           / Annual proper motion in RA
TBCOL20 =                   62 / Start column
TFORM20 = 'I6      '           / Fortran format
TUNIT20 = 's/yr    '           / Units are seconds of time per year
TSCAL20 =               0.0001 / Scale factor

TTYPE21 = 'RA_RESID'           / Residual value in RA
TBCOL21 =                   68 / Start column
TFORM21 = 'I6      '           / Fortran format
TUNIT21 = 'arcsec  '           / Units are seconds of arc
TSCAL21 =               0.0001 / Scale factor

TTYPE22 = 'DEC_RESID'          / Residual value in DEC
TBCOL22 =                   74 / Start column
TFORM22 = 'I6      '           / 6 Fortran format
TUNIT22 = 'arcsec  '           / Units are seconds of arc
TSCAL22 =               0.0001 / Scale factor

END
\end{verbatim}
\end{footnotesize}

(1 card image of ASCII blanks)
\newpage
\section*{Discussion of Example ADC FITS Table Header for AGK3 Catalog}

This ASCII table ({\tt XTENSION} keyword) header was created by
L.~Brotzman on September 15, 1988 ({\tt DATE} keyword) as an
illustration of the FITS table headers that would appear on an ADC
CD-ROM and were distributed with a request for comments.  It is for the
AGK3 catalog ({\tt HISTORY} keywords; also {\tt EXTNAME}) as compiled by
W.~Dieckvoss ({\tt AUTHOR}) and collaborators ({\tt HISTORY}), published
in 1975 by the Hamburg-Bergedorf Observatory  ({\tt REFERENC})\@.  The
same catalog had been used for the example header in the FITS ASCII
table paper (Harten {\it et al.} 1988). 
                                            
The values of {\tt BITPIX}, {\tt NAXIS}, {\tt PCOUNT}, and  {\tt GCOUNT}
are those required by the rules for ASCII tables.  Each row consists of
22 fields ({\tt TFIELDS}) and is 80 characters long ({\tt NAXIS1}). The
sum of the field sizes specified in the  {\tt TFORM}$n$ keywords, where
$n$ refers to the field number, is 80, the same as the value of 
{\tt NAXIS1}; thus, for this table, the fields fill the entire row. 
There are 183145 rows ({\tt NAXIS2}).  The values of the {\tt TBCOL}$n$
keywords show where each column starts, the  {\tt TTYPE}$n$ keywords
give a column title, usually explained in the comment field of the same
keyword, and the {\tt TFORM}$n$ keywords the FORTRAN format of the data
in the field. Some keywords appear in only some fields: {\tt TUNIT}$n$
keywords provide units, all in lower case in this table although no
special significance is to be ascribed to the case, {\tt TSCAL}$n$ and
{\tt TZERO}$n$ keywords show where the value in the FITS table must be
transformed to yield the physical value; and {\tt TNULL}$n$ gives the
null string where needed.  Blank lines are treated as comments, because
the keyword field is blank.                                         
                                                                
The following list describes the contents of the fields, as described by
the header keywords.  
                
\begin{enumerate}

\item {\tt AGK3} starts in column 1 and contains a seven-character string
      giving the declination zone and sequence number within the zone
      of the star.

\item {\tt AGK3\_COMP} consists of a single character in column 8 giving
      a component identification for a member of a multiple star system. 
      The string ``{\tt 0}'' (zero) represents a single star. 

\item {\tt PMAG} starts in column 9 and contains a three-digit integer
      giving the photographic magnitude of the star in units of tenths of
      a magnitude.  The value in the field must be multiplied by 0.1, the
      value of {\tt TSCAL3}, to obtain the physical quantity in units
      given by {\tt TUNIT3}.

\item {\tt SPTYPE} starts in column 12 and contains a two-character
      string giving the spectral type. 

\item{\tt RAH} starts in column 14 and contains a two-digit integer with
      the hours of right ascension of the position of the star, equinox
      1950, Besselian.

\item{\tt RAM} starts in column 16 and contains a two-digit integer, with 
      the minutes of time of right ascension of the position of the star,
      to be added to the hours of the previous field, equinox 1950,
      Besselian.

\item{\tt RAS} starts in column 18 and contains a five-digit integer,
      which is 1000 times the number of seconds of time of the right
      ascension of the position of the star, to be added to the hours
      and minutes of the previous fields, equinox 1950, Besselian.  This
      design allows storage in integer fields of right ascension
      accurate to 0.001 second of time.                          
                                  
\item{\tt DECSIGN} is a single character in column 23 giving the sign of the
      declination.  Note that, as discussed in connection with the 
      {\tt TFORM}$n$ keywords in section \ref{s:reqtab}, the sign is in
      a separate field, rather than incorporated into the value of the
      declination, in order to express the distinction between $-0$ and
      $+0$. 
      
\item{\tt DECD} starts in column 24 and contains a two-digit integer
      with the absolute value of the number of degrees of declination of
      the position the star, equinox 1950, Besselian.
      
\item{\tt DECM} starts in column 26 and contains a two-digit integer,
      with the minutes of arc of the declination of the star, to be added
      to the degrees of the previous field, equinox 1950, Besselian.

\item{\tt DECS} starts in column 28 and contains a four-digit integer,
      which is 100 times the number of seconds of arc of declination of
      the star to be added to the degrees and minutes of the previous
      fields, equinox 1950, Besselian  This design allows storage in
      integer fields of declination accurate to 0.01 second of arc. 
                                                  
\item {\tt NUMOBS} starts in column 32 and contains a two-digit integer
      giving the number of photographic observations used to determine
      the position. 

\item {\tt EPOCH} starts in column 34 and contains a four-digit integer
      giving the epoch---when the measurement was made---of the AGK
      position in hundredths of years after 1900; to get the epoch, the
      number in this field is multiplied by 0.01 and added to 1900.  
      Because the {\tt EPOCH} keyword has been used in the past to give
      the equinox of the coordinate system (section \ref{s:reskey}), it
      generally better to use a different keyword ({\tt DATE-OBS}, 
      {\tt MJD-OBS}) for the time of observation.   
      
\item{\tt PM\_RA\_COSD} starts in column 38 and is a five-digit integer
      containing the product of the annual proper motion in right
      ascension and the cosine of the declination, in units of
      thousandths of arcseconds/year, allowing this five-digit field to
      contain values accurate to 0.001 arcsec/year.  Applying the 
      scaling transformation yields values that are in units of
      arcseconds/year, the value of {\tt TUNIT14}.                   

\item{\tt PM\_DEC} starts in column 43 and is a five-digit integer
      containing the annual proper motion in declination, in units of
      thousandths of arcseconds/year, allowing this five-digit field to
      contain values accurate to 0.001 arcsec/year.

\item{\tt EPOCH\_DIFF} starts in column 48 and is a four-digit integer
      giving the difference between the epoch of the AGK3 position and
      the epoch of the AGK2 position in hundredths of years.
                                            
\item {\tt BD} starts in column 52 and contains a seven-character string
      giving the {\em Bonner Durchmusterung} number of the star. 

\item {\tt BD\_COMP} consists of a one digit integer in column 59 giving
      a numerical code identification of a component of a multiple star
      system.  The string ``{\tt 0}'' is the null value that would be in
      the field if the star is single.  As discussed in section
      \ref{s:restab}, the value of the {\tt TNULL18} keyword is a 
      {\em character string} and need not be readable in the integer
      format specified by the {\tt TFORM18} keyword.                            
      
\item{\tt DISC\_SUM} is a two-digit integer starting in column 60
      containing a sum that expresses in one number which discrepancy
      codes are present.  A discrepancy code flags a value that is
      inconsistent with that in another catalog or is otherwise
      considered unreliable. The sum is \(\sum_{V} 2^V\) where V are the
      discrepancy codes for the particular position; all values from 0
      to 5 are possible.  The meaning is explained by the {\tt COMMENT}
      keywords immediately following the other column 19 keywords; the
      {\tt DISC\_SUM} following the {\tt COMMENT} allows the text to be
      associated with the appropriate column even if the keywords are
      rearranged by the reader or a new table is created using some of
      the data in the current table and the column number changes.  You
      could also think of the {\tt DISC\_SUM} as a hierarchy similar to
      those in the {\tt HIERARCH} proposal discussed in section 
      \ref{s:KeyDom}. 
                                                         
\item{\tt PM\_RA} is a six-digit integer starting in column 62
      containing the annual proper motion in right ascension, in
      ten-thousandths of seconds of time per year.
      
\item{\tt RA\_RESID} is a six-digit integer starting in column 68
      containing the difference between the ADK3 right ascension and the
      ADK2 right ascension in ten-thousandths of seconds of arc,
      corrected for changes in position due to proper motion.  

\item{\tt DEC\_RESID} is a six-digit integer starting in column 74
      containing the difference between the ADK3 declination and the
      ADK2 declination in ten-thousandths of seconds of arc, corrected
      for changes in position due to proper motion.   
      
\end{enumerate}

\newpage
\section*{Example 6: DIRBE FITS Headers}
         
(The first two lines following are provided to help the reader determine
column numbers.  They are not part of FITS headers.)

\begin{footnotesize}
\begin{verbatim}

00000000011111111111222222222233333333333444444444455555555556666666666777
12345678901234567890123456789012345678901234567890123456789012345678909012

SIMPLE  =                    T / file does conform to FITS standard             
BITPIX  =                   32 / number of bits per data pixel                  
NAXIS   =                    0 / number of data axes                            
EXTEND  =                    T / FITS dataset may contain extensions            
DATE    = '28/09/94'           / FITS file creation date (dd/mm/yy)             
DATE-MAP= '10/07/94'           / Date of original file creation (dd/mm/yy)      
ORIGIN  = 'CDAC    '           / Cosmology Data Analysis Center                 
TELESCOP= 'COBE    '           / COsmic Background Explorer satellite           
INSTRUME= 'DIRBE   '           / COBE instrument [DIRBE, DMR, FIRAS]        
OBJECT  = 'ALL-SKY '           / part of sky given [ALL-SKY, WEEKLY-SKY,      
COMMENT                        /                    GAL-SLICE]                  
EQUINOX =               2000.0 / equinox of coords in following tables          
REFERENC= 'DIRBE Explanatory Supplement' /                                      
COMMENT     COBE specific keywords                                              
DATE-BEG= '11/12/89'           / date of initial data represented (dd/mm/yy)    
DATE-END= '21/09/90'           / date of final data represented   (dd/mm/yy)    
PIXRESOL=                    9 / Quad tree pixel resolution [6, 9]              
COMMENT                                                                         
COMMENT     DIRBE specific keywords                                             
PRODUCT = 'B09_AAM '           / Band 9 Annual Average Sky Map                 
VERSION = 'Pass 2B '           / Version of Data Reduction Software             
WAVE9   = '140. microns'       / nominal wavelength of Band 9                   
SOLELONG= 'ALL     '           / all available solar elongations included       
APPVEC  = 'COMBINED'           / approach vectors combined                      
ZLREMOV = 'NO      '           / signal from zodiacal dust remains in map       
COMMENT                                                                         
COMMENT                                                                         
END                                                                             
\end{verbatim}
\end{footnotesize}

(8 card images of ASCII blanks)
\begin{footnotesize}
\begin{verbatim}
XTENSION= 'BINTABLE'           / Extension type is Binary Table                 
BITPIX  =                    8 / Binary data                                    
NAXIS   =                    2 / Data are in a table                            
NAXIS1  =                   27 / Number of 8 bit bytes in each row              
NAXIS2  =               393216 / Number of rows                                 
PCOUNT  =                    0 / Number of bytes of data following table        
GCOUNT  =                    1 / Group count (always 1 for bintable extensions) 
TFIELDS =                    7 / Number of fields (columns) in the table        
COMMENT                                                                         
TIMVERSN= 'OGIP/93-003'        / OGIP memo number where the convention  
COMMENT                        / is described                                   
COMMENT            The times reported in this file are atomic seconds elapsed 
COMMENT            since 00:00:00 UTC, 1 January 1981.  Time information is 
COMMENT            recorded in a manner consistent with the convention specified
COMMENT            in OGIP/93-003 with the understanding that time is counted 
COMMENT            in atomic seconds and the origin of time (MJDREF) is quoted  
COMMENT            in ephemeris MJD.                                            
TIMESYS = '1981.00 '           / time system (same as IRAS)                     
MJDREFI =                44605 / Integer portion of ephemeris MJD               
COMMENT                        / corresponding to 0h UTC 1 Jan 1981             
MJDREFF =        0.00059240741 / Fractional portion of ephemeris MJD       
COMMENT                        / corresponding to 0h UTC 1 Jan 1981             
TIMEUNIT= 's       '           / unit for TSTART, TSTOP, TIMEZERO = seconds 
TSTART  =        282185275.611 / observation start time in TIMESYS system  
TSTOP   =        306753235.358 / observation stop time in TIMESYS system   
COMMENT                                                                         
COMMENT   -------------------------------------------------------------------   
COMMENT   *******************************************************************   
COMMENT          Annual Average Sky Map -- 140. microns                         
COMMENT          Mission-averaged photometric measurements and cumulative 
COMMENT          sky coverage data for DIRBE Band 9 (140. microns).           
COMMENT          The photometry is computed from the weighted average of all 
COMMENT          available weekly-averaged maps for the entire mission,        
COMMENT          up to the time when the cryogen supply was exhausted.       
COMMENT          The foreground signal from Zodiacal dust remains in the map.
COMMENT   *******************************************************************   
COMMENT   -------------------------------------------------------------------   
COMMENT   ====================================================================
COMMENT   Coordinate Information (Spatial and Temporal):                        
COMMENT   ===================================================================
COMMENT   -------------------------------------------------------------------   
COMMENT       DIRBE Pixel number (resolution 9)                                 
TTYPE1  = 'Pixel_no'           / entire fieldname = Pixel_no                    
TUNIT1  = '        '           /                                                
TFORM1  = '1J      '           /                                                
COMMENT   --------------------------------------------------------------------- 
COMMENT        Sub-pixel containing the mean DIRBE LOS (line-of-sight)       
COMMENT         when pixel is divided into 256                                  
COMMENT         sub-pixels (16x16 grid) according to                            
COMMENT         standard quad-sphere rules.                                     
TTYPE2  = 'PSubPos '           / entire fieldname = Pixel_subpos                
TUNIT2  = '        '           /                                                
TFORM2  = '1B      '           /                                                
COMMENT   --------------------------------------------------------------------  
COMMENT       Time in TAI seconds since 01-JAN-1981:00:00:00.000 UTC.    
COMMENT       This is the average time of all observations of a pixel           
COMMENT       within the time interval TSTART to TSTOP,                         
COMMENT       regardless of the weight assigned to a particular observation.  
COMMENT       For this product, not a physically meaningful quantity.           
TTYPE3  = 'Time    '           / entire fieldname = Time                        
TUNIT3  = '        '           /                                                
TFORM3  = '1D      '           /                                                
COMMENT   -------------------------------------------------------------------   
COMMENT   ===================================================================   
COMMENT   DIRBE Sky Brightness Information:                                     
COMMENT   ===================================================================   
COMMENT   -------------------------------------------------------------------   
COMMENT       Cumulative weighted average of the 140. micron photometry.  
COMMENT        This average is calculated using the weighted number of        
COMMENT        observations from each Weekly Averaged Map ( WtNumObs from       
COMMENT        the Weekly Averaged Map) as the weight, such that                
COMMENT        annual_average =                                                 
COMMENT           sum( weekly_average * weekly_weight )/ sum( weekly_weight)   
COMMENT                                                                         
COMMENT        The photometric measurement is given as a                        
COMMENT        spectral intensity, I(nu) in MJy/sr, and                         
COMMENT        is quoted at the nominal wavelength                              
COMMENT        for a source with nu*I(nu) = constant  -- i.e.,                  
COMMENT        a color correction is required if the source                     
COMMENT        spectrum differs from nu*I(nu) = constant.                       
COMMENT        Data which have been replaced by flagged values                  
COMMENT        in processing have values .LE. -16375.                           
COMMENT                                                                         
TTYPE4  = 'Photomet'           / entire fieldname = Photometry                  
TUNIT4  = 'MJy/sr  '           /                                                
TFORM4  = '1E      '           /                                                
COMMENT   --------------------------------------------------------------------  
COMMENT        The standard deviation of the (weighted) average photometry 
COMMENT         values.                                                         
TTYPE5  = 'StdDev  '           / entire fieldname = Standard_deviation          
TUNIT5  = 'MJy/sr  '           /                                                
TFORM5  = '1E      '           /                                                
COMMENT   --------------------------------------------------------------------  
COMMENT        Sum of the weekly weighted number of observations that went into 
COMMENT         forming the annual averages.                                    
TTYPE6  = 'WtNumObs'           / entire fieldname = Weighted_num_obs          
TUNIT6  = '        '           /                                                
TFORM6  = '1I      '           /                                                
COMMENT   --------------------------------------------------------------------- 
COMMENT        Sum of the total number of observations available, regardless 
COMMENT         of assigned weight.                                             
TTYPE7  = 'SumNRecs'           / entire fieldname = Sum_numrecs                 
TUNIT7  = '        '           /                                                
TFORM7  = '1J      '           /                                                
COMMENT   --------------------------------------------------------------------- 
END                                                                             
\end{verbatim}
\end{footnotesize}
(20 card images of ASCII blanks)

\newpage

\section*{Discussion of Example 6: DIRBE FITS Headers}

These primary and binary table headers are for an all sky map 
({\tt OBJECT} keyword) from the ({\tt INSTRUME} keyword) Diffuse
Infrared Background Explorer (DIRBE) on the ({\tt TELESCOP} keyword)
Cosmic Background Explorer (COBE) from the Cosmology Data Analysis
Center ({\tt ORIGIN} keyword).  The primary header provides information
that applies to all HDUs in the file.  There are no primary data 
({\tt NAXIS} keyword); the {\tt EXTEND} keyword is set to true, advising
the reader that extensions may be present, as indeed they are. Since the
primary HDU has no data, the value of the {\tt BITPIX} keyword does not
matter, as long as it is one of the permitted values. This particular
file was created on September 28, 1994 ({\tt DATE} keyword), but the
original map file was created July 10, 1994 ({\tt DATE-MAP} keyword). 
The map coordinates are for equinox 2000 ({\tt EQUINOX} keyword). 
                       
COBE specific keywords ({\tt COMMENT}) show that the data cover a period
from December 11, 1989 {(\tt DATE-BEG}) through September 21, 1990 
({\tt DATE-END}) and give the size of the region of space projected on
to one pixel ({\tt PIXRESOL}\@).  DIRBE-specific keywords 
({\tt COMMENT}) identify the ({\tt PRODUCT}), the ({\tt VERSION}) of the
data reduction software, the nominal (intended) wavelength 
({\tt WAVE9}), and provide information about choices made in processing
the data  ({\tt SOLELONG}, {\tt APPVEC}, and {\tt ZLREMOV})\@.  The
blank cards used as separators have an explicit {\tt COMMENT}, in
contrast with the use of blank lines in Example 5.                     
                        
The {\tt COMMENT} following the {\tt OBJECT} keyword illustrates one
approach to the problem of a keyword/comment string that is longer than
the 80-columns of a card image.  

The binary table ({\tt XTENSION} keyword) has 393216 rows ({\tt NAXIS2})
each of which has seven fields ({\tt TFIELDS}), which take up a total of
27 bytes per row ({\tt NAXIS1}). There is no heap for variable length
arrays ({\tt PCOUNT})\@. {\tt BITPIX} and {\tt GCOUNT} have the required
values as described in section \ref{s:Binreq}.  Like the primary HDU,
the extension header uses a {\tt COMMENT} in the keyword field for blank
lines.                                         
                 
Before the table description are a number of keywords describing the
time of the observation. The {\tt COMMENT} lines outline the meaning of
the keywords and their values and provide a reference ({\tt TIMVERSN}) 
with more details. {\tt MJDREFI} and {\tt MJDREFF} give the ephemeris
Modified Julian Date corresponding to the zero point of the time system,
also specified by {\tt TIMESYS}\@. {\tt TSTART} and {\tt TSTOP} give the
time of the measurements in seconds ({\tt TIMEUNIT}) after the zero
point.                                                 

The keywords describing the table follow.  Detailed explanatory comments
are provided at the top and after the keywords for each field.  All
fields have a short title  ({\tt TTYPE}$n$) keyword of eight characters
or fewer.  The titles are mixed case, but FITS software should not
attribute any significance to the case; the value is to make it
easier for human readers to understand the file.  The {\tt COMMENT}s
furnish the full field titles and provide detailed explanations.  Other
{\tt COMMENT}s are used to format the table for easier examination by
human readers.  The creators of the file have chosen to include a 
{\tt TUNIT}$n$ keyword for every field, with a blank value if there are
no units for the field.  To do so is not required but this choice
provides a design with a consistent set of keywords for every field. 
{\tt TFORM$n$} keywords give the data type of each field. The header
keywords describe the following fields:
                                                                       
\begin{enumerate}

\item {\tt Pixel\_no} is a 32-bit integer giving the pixel number on the
      map. 

\item {\tt PSubPos} is an 8-bit unsigned integer giving the pixel
      subposition, as explained in the comments.

\item {\tt Time} is a double precision floating point number giving the
      average time for the observations of a pixel.  The comments note
      that the value is not physically meaningful for this data product.
      Including this item allows the designers to produce a set of data
      products with a a common format, simplifying the reading
      process. 

\item {\tt Photomet} is short for ``Photometry'' and is a single
      precision floating point number giving a weighted average spectral
      intensity in MegaJanskys/steradian.  The comments provide a
      precise definition and describe the weighting.   
             
\item {\tt StdDev} is a single precision floating point number giving
      the standard deviation of the mean in the previous field, in
      MegaJanskys/steradian.
                                                          
\item {\tt WtNumObs} is a 16-bit integer giving the sum of the weekly
      weighted number of observations used in deriving the annual
      averages.

\item {\tt SumNRecs} is a 32-bit integer giving the total number of
      observations. 

\end{enumerate}

Each row has one unsigned integer, of one byte, one two-byte integer, two
four byte-integers, two single precision floating point numbers (four bytes
each) and one double precision floating point number (eight bytes), for a
total of 27 bytes, equal to the value of the {\tt NAXIS1} keyword.  

A description of the DIRBE data products is available at 
{\tt http://ssdoo.gsfc.nasa.gov/astro/cobe/dirbe\_products.html}.

\newpage
\section*{Example 7: ASCA FITS Header}

(The first two lines following are provided to help the reader determine
column numbers.  They are not part of FITS headers.)
\begin{footnotesize}
\begin{verbatim}

00000000011111111111222222222233333333333444444444455555555556666666666777
12345678901234567890123456789012345678901234567890123456789012345678909012

XTENSION= 'BINTABLE'           / binary table extension
BITPIX  =                    8 / 8-bit bytes
NAXIS   =                    2 / 2-dimensional binary table
NAXIS1  =                   30 / width of table in bytes
NAXIS2  =                22990 / number of rows in the table
PCOUNT  =                    0 / size of special data area
GCOUNT  =                    1 / one data group (required keyword)
TFIELDS =                   11 / number of fields in each row

TTYPE1  = 'TIME    '           / arrival time of the X-ray
TFORM1  = '1D      '           / data format of the field: 8-byte DOUBLE
TUNIT1  = 's       '           / physical unit of field: seconds

TTYPE2  = 'PI      '           / pulse-height invariant energy of the event
TFORM2  = '1J      '           / data format: 4-byte INTEGER
TUNIT2  = 'channel '           / physical unit of field
TLMIN2  =                    0 / Minimum legal value of PI
TLMAX2  =                 4095 / Maximum legal value of PI

TTYPE3  = 'X       '           / projected X (RA) sky pixel coordinate
TFORM3  = '1I      '           / data format: 2-byte INTEGER
TUNIT3  = 'pixel   '           / physical unit of field
TLMIN3  =                    1 / minimum legal value for column 3
TLMAX3  =                 1280 / maximum legal value for column 3

TTYPE4  = 'Y       '           / projected Y (Dec) sky pixel coordinate
TFORM4  = '1I      '           / data format: 2-byte INTEGER
TUNIT4  = 'pixel   '           / physical unit of field
TLMIN4  =                    1 / minimum legal value for column 4
TLMAX4  =                 1280 / maximum legal value for column 4

TTYPE5  = 'RAWX    '           / raw X detector coordinate of the event
TFORM5  = '1I      '           / data format: 2-byte INTEGER
TUNIT5  = 'pixel   '           / physical unit of field
TLMIN5  =                    6 / minimum legal value for column 5
TLMAX5  =                  426 / maximum legal value for column 5

TTYPE6  = 'RAWY    '           / raw Y detector coordinate of the event
TFORM6  = '1I      '           / data format: 2-byte INTEGER
TUNIT6  = 'pixel   '           / physical unit of field
TLMIN6  =                    1 / minimum legal value for column 6
TLMAX6  =                  422 / maximum legal value for column 6

TTYPE7  = 'PHA     '           / Pulse-Height-Analyzer energy
TFORM7  = '1I      '           / data format: 2-byte INTEGER
TUNIT7  = 'channel '           / physical unit of field
TLMIN7  =                    0 / minimum legal value for column 7
TLMAX7  =                 4095 / maximum legal value for column 7

TTYPE8  = 'DETX    '           / corrected X detector coordinate
TFORM8  = '1I      '           / data format: 2-byte INTEGER
TUNIT8  = 'pixel   '           / physical unit of field
TLMIN8  =                    1 / minimum legal value for column 8
TLMAX8  =                 1280 / maximum legal value for column 8

TTYPE9  = 'DETY    '           / corrected Y detector coordinate
TFORM9  = '1I      '           / data format: 2-byte INTEGER
TUNIT9  = 'pixel   '           / physical unit of field
TLMIN9  =                    1 / minimum legal value for column 9
TLMAX9  =                 1280 / maximum legal value for column 9

TTYPE10 = 'GRADE   '           / event quality grade 
TFORM10 = '1I      '           / data format: 2-byte INTEGER
TUNIT10 = 'pixel   '           / physical unit of field
TLMIN10 =                    0 / minimum legal value for column 10
TLMAX10 =                    4 / maximum legal value for column 10

TTYPE11 = 'CCDID   '           / CCD number
TFORM11 = '1I      '           / data forma: 2-byte INTEGER
TLMIN11 =                    0 / minimum legal value for column 11
TLMAX11 =                    3 / maximum legal value for column 11

                 General Descriptive Keywords
EXTNAME = 'EVENTS  '           / Name of extension
HDUCLASS= 'OGIP    '           / format conforms to OGIP/GSFC conventions
HDUCLAS1= 'EVENTS  '           / Extension contains Events
INSTRUME= 'SIS1    '           / Instrument name
ORIGIN  = 'GSFC    '           / Origin of FITS file
OBJECT  = 'NGC 4151'           / Name of observed object
OBSERVER= 'I. N. Jones'        / Principal Investigator
TELESCOP= 'ASCA    '           / Telescope (mission) name
CREATOR = 'extractor10q'       / Program that created this FITS file
SEQNUM  =             71019020 / Sequential number from ODB
SEQPNUM =                  004 / Number of times sequence processed
PROCVER = 'A5.1.8  '           / Processing script version

                 Instrument mode keywords
MODAL_ID=                 1894 / Modal Configuration ID
BIT_RATE= 'HIGH    '           / Telemetry rate
OBS_MODE= 'POINTING'           / Observation mode
DATAMODE= 'BRIGHT2 '           / file generated by FAINT

                     Time Related Keywords
DATE    = '20/03/95'           / FITS file creation date (dd/mm/yy)
DATE-OBS= '05/12/93'           / date of observation start (dd/mm/yy)
TIME-OBS= '20:51:57'           / time of observation start (hh:mm:ss)
DATE-END= '06/12/93'           / date of observation end
TIME-END= '04:06:31'           / time of observation end
MJD-OBS =     4.9326869420E+04 / Modified Julian date of the data start time
MJDREF  =              48988.0 / MJD corresponding to SC clock start (1993.0)
TIMEREF = 'LOCAL   '           / Barycentric correction not applied to times
TIMESYS = '1993.0  '           / Time measured from 1993 Jan 1 00:00 UT
TIMEUNIT= 's       '           / unit for time related keywords: seconds
TSTART  =  2.92783178528423011303E+07 / time start
TSTOP   =  2.93043917384999990463E+07 / time stop
TELAPSE =  2.60738856576979160309E+04 / Elapsed time = TSTOP - TSTART
ONTIME  =  9.92793133954703807831E+03 / sum of the good time intervals
EXPOSURE=  9.92793133954703807831E+03 / Exposure
CLOCKAPP=                    F / Is mission time corrected for clock drift?
TASSIGN = 'SATELLITE'          / location of time assignment
TIMEDEL =     8.0000000000E+00 / time increment or time resolution of data
TIMEZERO=                  0.0 / offset to be applied to TIME column
ORBITBEG= '93120513'           / beginning orbit number
ORBITEND= '93120603'           / ending orbit number

              Position Related Keywords
RADECSYS= 'FK5     '           / World Coordinate System
EQUINOX =          2000.000000 / Equinox for coordinate system
RA_NOM  =               182.74 / Nominal RA
DEC_NOM =               39.429 / Nominal declination
RA_PNT  =           182.760681 / File average value of RA (degrees)
DEC_PNT =            39.434547 / File average value of DEC (degrees)
PA_PNT  =           237.685150 / File average value of ROLL (degrees)
RA_PNTE =             0.000556 / File standard deviation of RA (degrees)
DEC_PNTE=             0.000179 / File standard deviation of DEC (degrees)
PA_PNTE =             0.003630 / File standard deviation of ROLL (degrees)
TCRPX3  =       6.40500000E+02 / Sky X axis reference pixel
TCRPX4  =       6.40500000E+02 / Sky Y axis reference pixel
TCRVL3  =       1.82744003E+02 / Sky X coordinate at reference pixel (degrees)
TCRVL4  =       3.94291992E+01 / Sky Y coordinate at reference  pixel (degrees)
TCDLT3  =      -4.41999990E-04 / Sky X pixel scale (degrees/pixel)
TCDLT4  =       4.41999990E-04 / Sky Y pixel scale (degrees/pixel)
TCTYP3  = 'RA---TAN'           / Coordinate projection
TCTYP4  = 'DEC--TAN'           /  Coordinate projection
TCRPX8  =       6.40500000E+02 / Detector X ref pixel (center of address space)
TCRPX9  =       6.40500000E+02 / Detector Y ref pixel (center of address space)
TCRVL8  =       0.00000000E+00 / Detector X ref pixel value (pixels)
TCRVL9  =       0.00000000E+00 / Detector Y ref pixel value (pixels)
TCDLT8  =       2.70000007E-02 / Detector X pixel scale (mm/pixel)
TCDLT9  =       2.70000007E-02 / Detector Y pixel scale (mm/pixel)
OPTIC3  =       5.06579102E+02 / File mean optical axis X in sky coords (pixels)
OPTIC4  =       5.69040405E+02 / File mean optical axis Y in sky coords (pixels)
OPTIC8  =       6.18277771E+02 / Optical axis X in detector coords (pixels)
OPTIC9  =       7.73833313E+02 / Optical axis Y in detector coords (pixels)
FOV_X_MM=          23.00000000 / Detector X field of view (mm)
FOV_Y_MM=          23.00000000 / Detector Y field of view (mm)
END
\end{verbatim}
\end{footnotesize}

(32 card images of blanks)

\newpage

\section*{Discussion of Example 7: ASCA FITS Header}

This FITS table contains an event list of the X-rays detected with the
SIS1 detector on the ASCA  X-ray satellite during a particular pointed
observation.  Each row contains data for a single photon, and the table
contains information for all the events in this particular observation. 
Eleven different parameters are listed for each X-ray event.  The header
keywords supply additional information for deriving precise times or
positions for each event.  
 
This binary table ({\tt XTENSION} keyword, {\tt BITPIX} value of 8, 
{\tt NAXIS} value of 2, {\tt GCOUNT} value of 1) has 22990 rows 
({\tt NAXIS2} keyword) consisting of 30 bytes ({\tt NAXIS1} keyword)
distributed over 11 fields ({\tt TFIELDS} keyword) and no variable length
array heap ({\tt PCOUNT}).  

In this example, by contrast with examples 5 and 6, the keywords
describing the structure of the table  appear immediately after the
required header keywords, and the more general information follows. 
The field titles ({\tt TTYPE$n$}) are short, upper-case headings of five
characters or fewer; the comment fields of the keyword card image
explain the title. {\tt TFORM}$n$ keywords provide the format, and 
{\tt TUNIT}$n$ keywords provide the units, where appropriate.  All units
are lowercase; the case is not significant.   The quantity in field 11
is a pure number, and the designers of this table have chosen not to
have a {\tt TUNIT11} field, a different approach from that of example 6. 
For many fields, {\tt TLMAX}$n$ and {\tt TLMIN}$n$ keywords are used,
following the HEASARC convention discussed in section \ref{s:HFWGlim}. 
The table contains the following fields:
                                                       
\begin{enumerate}

\item{\tt TIME} is a double precision floating point number containing
      the arrival time (in seconds) of the X-ray photon.  The time system
      is described by the Time Related Keywords later in the file.
                                   
\item{\tt PI} is a 4-byte integer containing the gain-corrected
      pulse-height energy channel number of the photon.  The channel
      numbers run from 0 to 4095. 
                
\item{\tt X} is a 2-byte integer containing the projection of the event
      sky right ascension onto the X-axis of a rectangular pixel
      coordinate system; the axis runs from 1 to 1280 ({\tt TLMAX3}, 
      {\tt TLMIN3}).
                  
\item{\tt Y} is a 2-byte integer containing the projection of the event
      sky declination onto the Y-axis of a rectangular pixel coordinate
      system; the axis runs from 1 to 1280.  
       
\item{\tt RAWX} is a 2-byte integer containing the CCD X-axis pixel
      location of the event with no corrections; the axis runs from 6
      to 426. 

\item{\tt RAWY} is a 2-byte integer containing the CCD Y-axis pixel
      location of the event with no corrections; the axis runs from 1
      to 422. 

\item{\tt PHA} is a 2-byte integer containing the pulse-height energy
      channel number of the data for this photon, with no gain
      correction.  The channel numbers run from 0 to 4095. 

\item{\tt DETX} is a 2-byte integer containing the X-axis pixel location
      of the event in detector coordinates, corrected for instrument
      distortion; the axis runs from 1 to 1280. 
                   
\item{\tt DETY} is a 2-byte integer containing the Y-axis pixel location
      of the event in detector coordinates, corrected for instrument
      distortion; the axis runs from 1 to 1280. 

\item{\tt GRADE} is a 2-byte integer describing the shape of the event,
      used as a quality indicator.  Grade numbers run from 0 to 4. 

\item{\tt CCDID} is a 2-byte integer identifying the CCD number, which
      runs from 0 to 3.

\end{enumerate}

Each row has nine two-byte integers, one four byte-integer, and one
double precision floating point number (eight bytes), for a total of 30
bytes, equal to the value of the {\tt NAXIS1} keyword.  

The remaining keywords are grouped.  Each group is preceded by a
centered descriptive heading; the first eight characters are blanks, and
thus the headings are treated as comments. 

Under ``General Descriptive Keywords'' are keywords that identify the
extension and its content.  The name, corresponding to a table title, is
{\tt EVENTS} ({\tt EXTNAME} keyword).  The {\tt HDUCLASS} keyword
identifies the authors of the file format and conventions as OGIP, and 
{\tt HDUCLAS1} the type of data as {\tt EVENTS}\@.  Examples of other
types are {\tt SPECTRUM} and {\tt GTI} (Good Time Intervals).  The usage
of these two keywords follows OGIP/HEASARC convention; {\tt HDUCLASS}
identifies the source of the observation as one of NGC 4151 
({\tt OBJECT} keyword) with the SIS1 instrument  ({\tt INSTRUME}) of the
ASCA telescope ({\tt TELESCOP}), with the principal investigator being
I. N. Jones ({\tt OBSERVER})\@. The  {\tt ORIGIN}, {\tt CREATOR}, 
{\tt PROCVER}, {\tt SEQNUM}, and  {\tt SEQPNUM} keywords provide
information on the origin of the file and its processing history. The
``Instrument mode keywords'' provide information on the instrument and
data configuration.    
                                                                 
The ``Time Related Keywords'', except for the standard reserved 
{\tt DATE} keyword that identifies the file creation date as March 20,
1996, give the time of observation.  The observation started at 57
seconds after 8:51 P. M. on December~5,~1995 ({\tt DATE-OBS}, 
{\tt TIME-OBS}) and ended at 31 seconds after 4:06~A.~M. on December 6,
1993  ({\tt DATE-END}, {\tt TIME-END})\@.  Of these keywords, 
{\tt DATE-OBS} is a reserved FITS keyword; the others are user-defined
keywords but with names chosen by analogy with the reserved keyword.  In
this case, the {\tt DATE-OBS} keyword refers to the beginning of the
observation, but, as noted in section \ref{s:reskey}, whether the 
{\tt DATE-OBS} keyword refers to the beginning, middle, or end of the
observation is not specified by the FITS rules and must be described in
the file, as it is here.  The start time is also specified in Modified
Julian Date form using the widely used {\tt MJD-OBS}, intended as a
standard under the World Coordinates proposal. The {\tt MJDREF}, 
{\tt TIMEREF}, {\tt TIMESYS}, and {\tt TIMEUNIT} keywords define the
time system and scale used for the {\tt TIME} column of the main table
and for expressing the start and stop time of the observations using the
{\tt TSTART} and {\tt TSTOP} keywords.  The {\tt ORBITBEG} and 
{\tt ORBITEND} keywords identify the orbit numbers of the start and stop
of the observation. The other keywords provide information on the
elapsed times of observation and on defining the time scales.                           
                                                            
The ``Position Related Keywords'' describe coordinate systems.  The 
{\tt RADECSYS} keyword is the World Coordinates convention keyword
defined in section \ref{s:eqcoor} and identifies the coordinate system
used as the FK5, the system in use since the 1976 IAU; {\tt EQUINOX}
identifies the coordinate system as precessed to the year 2000.000000. 
The next eight keywords describe the direction in which the instrument
points.  Right ascension and declination are always given in degrees. 
The {\tt RA\_PNT} and {\tt DEC\_PNT} keywords are specifically listed
among the standard HFWG keywords.  The next 14 keywords describe the
coordinate systems in which the event positions of columns 3-4 and 8-9
are defined, one of the cases defined in section \ref{s:WCTab}. 
Keywords similar to the standard coordinate keywords of section
\ref{s:reskey} but with one intermediate letter omitted and prefaced by
{\tt T} are used.  Columns 3 and 4 describe a position in a tangent
projection  (section \ref{s:WCProj}) of the sky onto a FITS array.  For
the X-axis, the right ascension at array position 640.5, that is,
equivalent to halfway between 640 and 641 ({\tt TCRPX3}~keyword), is
182.744003 degrees  ({\tt TCRVL3}), and the right ascension changes by 
$4.4199999\times 10^{-4}$ degrees for a change of 1 in the array
position, decreasing with increasing index number ({\tt TCDELT3}). For
the Y-axis, the declination at array position 640.5 ({\tt TCRPX4}
keyword) is +39.4291992 degrees  ({\tt TCRVL4}), and changes by
$4.4199999\times 10^{-4}$degrees for a change of 1 in the array index,
increasing with increasing index number  ({\tt TCDELT4}).  Columns 8 and
9 provide positions of the events in a linearized focal plane pixel
coordinate system obtained by correcting the raw detector coordinates
for instrument distortion.  FITS array member  (640.5, 640.5)
corresponds to (0,0) of the pixel coordinate system  ({\tt TCRPX8}, 
{\tt TCRVL8}, {\tt TCRPX9}, {\tt TCRVL9}), with the scale on both axes
0.027 mm/unit change in index.  The {\tt OPTIC}$n$ keywords provide the
array position of the optical axis in both linearized detector
coordinates and sky coordinates, and the  {\tt FOV\_X\_MM} and 
{\tt FOV\_Y\_MM} keywords provide the size of the field of view at the
detector, 23 mm $\times$þ 23 mm.  The FITS conventions and a discussion
of the ASCA system are available on separate pages at the HEASARC sites
at {\tt http://heasarc.gsfc.nasa.gov/} and 
{\tt ftp://legacy.gsfc.nasa.gov/}.                                  
      

\chapter{IEEE Formats}
   \label{s:IEEEfp}

(The material in this appendix is adapted from the IEEE-754~(1985)
floating point standard.  It is not intended to be a comprehensive
description of the IEEE formats; readers should refer to the IEEE
standard.)                                                 
                                                                  

 FITS recognizes all IEEE basic formats, including the special values.
Table \ref{t:ieee} shows the type of IEEE floating point value, regular or
special, for all double and single precision hexadecimal byte patterns. 
\begin{table}[htpb]
\begin{center}
\begin{tabular}{lcc} \\
\multicolumn{1}{c}{IEEE value} & Double Precision 
                                              & Single Precision \\\hline
    $+0$                & {\tt 0000000000000000} & {\tt 00000000} \\
    denormalized        & {\tt 0000000000000001} & {\tt 00000001} \\
                        &             to         &         to     \\
                        & {\tt 000FFFFFFFFFFFFF} & {\tt 007FFFFF} \\
    positive underflow  & {\tt 0010000000000000} & {\tt 00800000} \\
    positive numbers    & {\tt 0010000000000001} & {\tt 00800001} \\
                        &             to         &         to     \\
                        & {\tt 7FEFFFFFFFFFFFFE} & {\tt 7F7FFFFE} \\
    positive overflow   & {\tt 7FEFFFFFFFFFFFFF} & {\tt 7F7FFFFF} \\
    $+\infty$           & {\tt 7FF0000000000000} & {\tt 7F800000} \\
    NaN$^{1}$           & {\tt 7FF0000000000001} & {\tt 7F800001} \\
                        &             to         &         to     \\
                        & {\tt 7FFFFFFFFFFFFFFF} & {\tt 7FFFFFFF} \\
    $-0$                & {\tt 8000000000000000} & {\tt 80000000} \\
    negative            & {\tt 8000000000000001} & {\tt 80000001} \\
     denormalized       &             to         &         to     \\
                        & {\tt 800FFFFFFFFFFFFF} & {\tt 807FFFFF} \\
    negative underflow  & {\tt 8010000000000000} & {\tt 80800000} \\
    negative numbers    & {\tt 8010000000000001} & {\tt 80800001} \\
                        &             to         &         to     \\
                        & {\tt FFEFFFFFFFFFFFFE} & {\tt FF7FFFFE} \\
    negative overflow   & {\tt FFEFFFFFFFFFFFFF} & {\tt FF7FFFFF} \\
    $-\infty$           & {\tt FFF0000000000000} & {\tt FF800000} \\
    NaN$^{1}$           & {\tt FFF0000000000001} & {\tt FF800001} \\
                        &             to         &         to     \\
                        & {\tt FFFFFFFFFFFFFFFF} & {\tt FFFFFFFF} \\
                        &                                         \\ \hline
\end{tabular}
\end{center}
$^1$ Certain values may be designated as 
{\em quiet} NaN (no diagnostic when used) 
or {\em signaling} (produces diagnostic when used) by
particular implementations. \\ \\ 
\caption[IEEE Floating Point Formats]{IEEE Floating Point Formats}
\label{t:ieee}
\end{table}


\setcounter{chapter}{0}
\chapter*{References}

ANSI 1977, ``American National Standard for Information Processing:
Code for Information Interchange,'' ANSI X3.4-1977 (ISO 646) (New York:
American National Standards Institute, Inc.). 

Cotton, W.D., Tody, D. B., and Pence, W. D. 1995, 
``Binary Table\index{binary tables} Extension to {\em FITS},'' 
{\em Astron. Astrophys. Suppl.}, {\bf 113}, 159-166. 
          
Greisen, E. W. 1983, ``Non-linear Coordinate Systems in AIPS,'' 
{\em AIPS Memo\/}~{\bf 27}. 

Greisen, E. W. 1986, ``Additional Non-linear Coordinates,'' 
{\em AIPS Memo\/}~{\bf 46}. 

Greisen, E. W., and Calabretta, M. 1996, ``Representation of Celestial 
Coordinates in FITS'' preprint, available in PostScript form at 
{\tt ftp://fits.cv.nrao.edu/fits/documents/wcs/wcs\_all.ps}.

Greisen, E. W., and Harten, R. H. 1981, ``An Extension of FITS for
Small Arrays of Data,'' {\em Astron. Astrophys. Suppl.}, {\bf 44},
371-374. 

Grosb\o l, P., Harten, R. H., Greisen, E. W., and Wells, D. C. 1988,
``Generalized Extensions and Blocking Factors for FITS,'' 
{\em Astron. Astrophys. Suppl.}, {\bf 73}, 359-364. 

Hanisch, R. J., and Wells, D. C. 1988, ``World Coordinate Systems
Representations Within the FITS Format'' (DRAFT preprint). 

Harten, R. H., Grosb\o l, P., Greisen, E. W., and Wells, D. C. 1988,
``The FITS Tables Extension,'' 
{\em Astron. Astrophys. Suppl.}~{\bf 73}, 365-372. 

{\em IAU Information Bulletin}~{\bf 49}, 14, 1983.

IAU 1988, {\em Transactions of the IAU Twentieth General Assembly},''
ed. D. McNally (Dordrecht:Kluwer). 

IEEE 1985, ``American National Standard - IEEE Standard for Binary
Floating Point Arithmetic,'' ANSI-IEEE 754-1985 (New York: American
National Standards Institute, Inc.). 

Jennings, D. G., Pence, W. D., Folk, M., and Schlesinger, B. M. 1996,
``A Hierarchical Grouping Convention for FITS, '' preprint, available
electronically from 
{\tt http://adfwww.gsfc.nasa.gov/other/convert/group.html}.   
                   
Mu\~{n}oz, J. R. 1989, ``IUE data in {\em FITS\/} Format,'' ESA IUE
Newsletter, {\bf 32}, 12-45.
               
National Radio Astronomy Observatory 1990, ``Going AIPS,''
(Charlottesville, VA: National Radio Astronomy Observatory).
                                                            
NOST 1995, ``Definition of the Flexible Image Transport System
(FITS)'', NOST 100-1.1 (Greenbelt: NASA/Goddard Space Flight Center). 

Ponz, J. D., Thompson, R. W., and Mu\~{n}oz, J. R. 1994,   
``The {\em FITS\/} Image\index{Image} Extension,''    
{\em Astron. Astrophys. Suppl.}, {\bf 105}, 53-55. 
  
Seaman, R. and Pence, W. D. 1995, ``FITS Checksum Proposal,'' available
in PostScript form at
{\tt ftp://iraf.noao.edu/misc/checksum/checksum.ps}.

Warnock, A., Hill, R. S., Pfarr, B. B., and Wells, D. C. 1990, ``An
Extension of FITS for Data Compression'', draft preprint, available
electronically at {\tt http://fits.cv.nrao.edu:80/documents/drafts/}. 

Wells, D. C., and Greisen, E. W. 1979, ``A Flexible Image Transport
System,'' {\em Proc. 5th Colloquium Astrophysics}, eds. G. Sedmak,
M. Capaccioli, and R. J. Allan, p. 445. 

Wells, D. C., Greisen, E. W., and Harten, R. H. 1981, ``FITS: A
Flexible Image Transport System,'' {\em Astron. Astrophys. Suppl.},
{\bf 44}, 363-370.

Wells, D. C., and Grosb\o l, P. 1990, ``Floating Point Agreement for
FITS,'' preprint, available from FITS Support Office. 

Zarate, N., and Greenfield, P. 1996, ``A FITS Image Extension Kernel for
IRAF,'' {\em Astronomical Data Analysis Software and Systems V}, eds. 
G. H. Jacoby and J. Barnes, pp. 331-334. 

\end{document}