% this is a true latex file *-* % % NOTE: Check setting of the XXX (XXX=final, index, ...) % variables below to % enable or suppress printing of an index or debugging statements % Also note possible LaTeX incompatibilities with \printindex at the % end of the document, which may become '\input standard.ind' on some % systems which do not understand the '\printindex' command... % <=== declarations of logical vars XXX (XXX=final,index...) \newif\iffinal \newif\ifindex % <=== set the logicals (make them either \XXXtrue or \XXXfalse) % in the source us \ifXXX ... \else ... \fi \finaltrue \indextrue % various DOCUMENTSTYLE, depending on chosen environment \ifindex \iffinal \documentstyle[11pt,nost,epsf,makeidx]{book} % final version \else \documentstyle[11pt,nost,epsf,makeidx,showidx]{book}% index debug version \fi \else \documentstyle[11pt,nost,epsf]{book} % no index \fi % %%%%%%%%%%%% \newcommand{\FITS}{\em FITS\/} \newcommand{\eg}{{\it e.g.},} %%%%%%%%%%%%% % \author{ } \shorttitle{NOST {\em FITS\/} Definition} \ifindex \makeindex \fi \title{ Definition of the Flexible Image Transport System (\FITS) } %\title{ Definition of the Flexible Image Transport System ({\em FITS\/}) } % \standardnumber{NOST 100-2.0} % \date{March 29, 1999} % \publisher{ NASA/Science Office of Standards and Technology \\ Code 633.2 \\ NASA Goddard Space Flight Center \\ Greenbelt MD 20771 \\ USA} \pubaddress{ NOST, Code 633.2, NASA Goddard Space Flight Center \\ Greenbelt MD 20771 \\ USA \\ electronic mail: nost@nssdca.gsfc.nasa.gov \\ +1-301-286-3575 \\ http://ssdoo.gsfc.nasa.gov/nost/ } \offaddress{ FITS Support Office \\ Code 631, NASA Goddard Space Flight Center \\ Greenbelt MD 20771 \\ USA \\ electronic mail: fits@fits.gsfc.nasa.gov \\ +1-301-286-6695 \\ http://fits.gsfc.nasa.gov/ } % \panel{ Robert J. Hanisch, Chair & {\raggedright Space Telescope Science Institute} \\ William D. Pence, Secretary & {\raggedright NASA Goddard Space Flight Center} \\ Barry M. Schlesinger, Past Secretary & {\raggedright Raytheon STX} \\ Allen Farris & {\raggedright Space Telescope Science Institute} \\ Eric W. Greisen & {\raggedright National Radio Astronomy Observatory} \\ Peter J. Teuben & {\raggedright University of Maryland} \\ Randall W. Thompson & {\raggedright Computer Sciences Corporation} \\ Archibald Warnock & {\raggedright A/WWW Enterprises} \\ \\ \multicolumn{2}{l} {Members of the previous Technical Panels also included:} \\ Lee E. Brotzman & {\raggedright Hughes STX} \\ Edward Kemper & {\raggedright Hughes STX} \\ Michael E. Van Steenberg & {\raggedright NASA Goddard Space Flight Center} \\ Wayne H. Warren Jr. & {\raggedright Hughes STX} \\ Richard A. White & {\raggedright NASA Goddard Space Flight Center} \\ } % % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%% % \begin{document} \maketitle \begin{titlepage} \vspace*{7.6cm} \vfill \end{titlepage} %%% Cannot add \index here - no pagenumbers available \begin{authority} The NASA/Science Office of Standards and Technology (NOST) of the National Space Science Data Center (NSSDC) of the National Aeronautics and Space Administration (NASA) has been established to serve the space science communities in evolving cost effective, interoperable data systems. The NOST performs a number of functions designed to facilitate the recognition, development, adoption, and use of standards by the space science communities. Approval of a NOST standard requires verification by the NOST that the following requirements have been met: consensus of the Technical Panel, proper adjudication of the comments received from the targeted space and Earth science community, and conformance to the accreditation process. A NOST standard represents the consensus of the Technical Panel convened by the NOST\@. Consensus is established when the NOST Accreditation Panel determines that substantial agreement has been reached by the Technical Panel. However, consensus does not necessarily imply that all members were in full agreement with every item in the standard. NOST standards are not binding as published; however, they may serve as a basis for mandatory standards when adopted by NASA or other organizations. A NOST standard may be revised at any time, depending on developments in the areas covered by the standard. Also, within five years from the date of its issuance, this standard will be reviewed by the NOST to determine whether it should 1) remain in effect without change, 2) be changed to reflect the impact of new technologies or new requirements, or 3) be retired or canceled. The Technical Panel that developed this version of the standard consisted of the following members: \end{authority} \tableofcontents \listoftables \listoffigures \chapter*{Introduction} \addcontentsline{toc}{chapter}{Introduction}\markboth{}{} The Flexible Image Transport System ({\em FITS\/}) evolved out of the recognition that a standard format was needed for transferring astronomical data from one installation to another. The original\index{Basic FITS} form, or Basic {\em FITS\/} [1], was designed for the transfer of images and consisted of a binary array, usually multidimensional, preceded by an ASCII text\index{ASCII text} header with information describing the organization and contents of the array. The {\em FITS\/} concept was later expanded to accommodate more complex data\index{format, data} formats. A new format for image transfer, {\em random groups}, was defined [2] in which the data\index{random groups} would consist of a series of arrays, with each\index{random groups array} array accompanied by a set of associated\index{parameter} parameters. These formats were formally endorsed [3] by the International Astronomical Union\index{IAU} (IAU) in 1982. Provisions for data structures other than simple arrays or groups were made later. These structures appear\index{extension} in {\em extensions}, each consisting of an ASCII header followed by the data whose organization it describes. A set of general rules governing such extensions [4] and a particular\index{ASCII table} extension, ASCII table [5], were endorsed by the IAU General Assembly [6] in 1988. At the same General\index{IAU, 1988 General Assembly} Assembly, an IAU {\em FITS\/} Working\index{FITS Working Group} Group (IAUFWG) was\index{IAUFWG} formed [7] under IAU Commission 5 (Astronomical Data) with the mandate to maintain the existing {\em FITS\/} standards and to review, approve, and maintain future extensions to {\em FITS}, recommended practices for {\em FITS}, implementations, and the thesaurus of approved {\em FITS\/} keywords. In 1989, the IAUFWG approved a formal agreement [8] for the representation of floating point\index{floating point FITS agreement} numbers. In 1994, the IAUFWG endorsed two additional extensions, the image\index{image extension} extension [9] and the binary table\index{binary table} extension [10]. {\em FITS\/} was originally designed and defined for 9-track half-inch\index{tape, 9-track half-inch} magnetic tape. However, as improvements in technology have brought forward other data storage and data distribution media, it has generally been agreed that the {\em FITS\/} format is to be understood as a logical format and not defined in terms of the physical characteristics of any particular data storage medium. In 1994, the IAUFWG adopted a set of rules [11] governing the relation between the {\em FITS\/} logical record size and the physical block\index{block size} size for sequential media and bitstream devices. The IAUFWG also approved in 1997 an agreement [12] defining a new format for encoding the date and time in the {\tt DATE}, {\tt DATE-OBS}, and other related {\tt DATExxxx} keywords to correct the ambiguity in the original DATE keyword format beginning in the year 2000. \chapter{Overview} \startstandard \begin{quote} {\em An {\em archival format} must be utterly portable and self-describing, on the assumption that, apart from the transcription device, neither the software nor the hardware that wrote the data will be available when the data are read.} {``Preserving Scientific Data on our Physical Universe,'' p.\ 60.} {Steering Committee for the Study on the Long-Term Retention of Selected Scientific and Technical Records of the Federal Government, [US] National Research Council, National Academy Press 1995.} \end{quote} \section{Purpose} This standard formally defines the {\em FITS\/} format for data structuring and exchange that is to be used where applicable as defined in \S\ref{s:appl}. It is intended as a formal codification of the {\em FITS\/} format that has been endorsed by the IAU\index{IAU} for transfer of astronomical data, fully consistent with all actions and endorsements of the IAU and the IAU {\em FITS\/} Working\index{FITS Working Group} Group (IAUFWG). Minor ambiguities and inconsistencies in {\em FITS\/} as described in the original papers are eliminated. % The eventual goal is to submit this document to the % IAUFWG\index{IAUFWG} % for endorsement as a universal standard for {\em FITS}. \section{Scope} This standard specifies the organization and content of {\em FITS\/} data sets, including the header and data, for all\index{format, standard} standard {\em FITS\/} formats: Basic {\em FITS}, the\index{Basic FITS} random groups\index{random groups} structure, the ASCII table\index{ASCII table} extension, the image\index{image extension} extension, and the binary table\index{binary table} extension. It also specifies minimum structural requirements for new extensions\index{extension} and general principles governing the creation of new extensions. It specifies the relation between physical block sizes\index{block size} and logical records for {\em FITS\/} files on bitstream devices and sequential media. For headers, it specifies the proper syntax for card images and defines required\index{keyword, required} and reserved\index{keyword, reserved} keywords. For data, it specifies character and value representations and the ordering of contents within the byte stream. It defines the general rules to which new extensions are required to conform. \section{Applicability} \label{s:appl} This standard describes an extensible data interchange format particularly well suited for transport and archiving of arrays and tables of astronomical data. The IAU\index{IAU} has recommended that all astronomical computer facilities support {\em FITS\/} for the interchange of binary data. It has been NASA policy for its astrophysics projects to make their data available in {\em FITS\/} format. This standard may also be used to define the format for data transport in other disciplines, as may be determined by the appropriate authorities. \section{Organization of This Document} \S\ref{s:def} is a glossary of definitions, acronyms, and symbols. In \S\ref{s:org}, this document describes the overall organization of a {\em FITS\/} file, the contents of the first (primary) header and data, the rules for creating new {\em FITS\/} extensions\index{extension}, and the relation between physical block\index{block size} sizes and logical records for {\em FITS\/} files on bitstream devices and sequential media. The next two sections provide additional details on the header and data, with a particular focus on the primary header\index{primary header}. \S\ref{s:head} provides details about header card image syntax and specifies those keywords required\index{keyword, required} and reserved\index{keyword, reserved} in a primary header. \S\ref{s:Drep} describes how different data types are represented in {\em FITS}\@. The following sections describe the headers and data of two standard {\em FITS\/} structures\index{FITS structure}, the now deprecated\index{deprecate} random groups\index{random groups} records (\S\ref{s:Rgrp}) and the current standard\index{ASCII table} extensions: ASCII table, image\index{image extension}, and binary table\index{binary table} (\S\ref{s:exts}). Throughout the document, deprecation of structures or syntax is noted where relevant. Files containing deprecated features are valid {\em FITS}, but these features should not be used in new files; the old files using them remain standard because of the principle that no change in {\em FITS\/} shall cause a valid {\em FITS\/} file to become invalid. The Appendixes contain material that is not part of the standard. The first, Appendix \ref{s:FormSyn}, provides a formal expression of the keyword/value syntax for header card images described in \S\ref{s:valC}. Appendix \ref{s:Bincon} provides examples of widely accepted {\em FITS\/} conventions that are not part of the formal {\em FITS\/} standard. It describes three conventions in use with the binary table\index{binary table} extension --- one for handling multidimensional\index{array, multidimensional} arrays, one for including variable length\index{array, variable length} arrays, and one for arrays\index{array, substring} of substrings. Appendix \ref{s:phy} describes aspects of the implementation of {\em FITS\/} on physical media not covered by the blocking agreement. Appendix \ref{s:tsys} is the appendix to the agreement endorsed by the IAUFWG for a new format for keywords expressing dates. The new format uses a four-digit value for the year, and thus eliminates any ambiguity in dates from the year 2000 and after. This appendix is not part of the formal agreement. It contains a detailed discussion of time systems. It has been slightly reformatted for stylistic compatibility with the remainder of this document. Appendix \ref{s:sdif} lists the differences between this standard and the specifications of prior publications; it also identifies those ambiguities in the documents endorsed by the IAU\index{IAU} on which this standard provides specific rules. The next four appendixes provide reference information: a tabular summary of the {\em FITS\/} keywords (Appendix \ref{s:summ}), a list of the ASCII character set\index{ASCII character} and a subset designated {\em ASCII text}\index{ASCII text} (Appendix \ref{s:Atxt}), a description of the IEEE\index{IEEE floating point} floating point format (Appendix \ref{s:IEEE754}), and a list of the extension type\index{extension name} names that have been reserved as of the date this document was issued (Appendix \ref{s:resn}). Appendix \ref{s:pubs} is a list of NOST documents, including earlier versions of this standard. \chapter{References} \begin{enumerate} \item Wells, D. C., Greisen, E. W., and Harten, R. H. 1981, ``{\em FITS\/}: A Flexible Image Transport System,'' {\em Astron. Astrophys. Suppl.}, {\bf 44}, 363--370. \item Greisen, E. W. and Harten, R. H. 1981, ``An Extension of {\em FITS\/} for\index{random groups} Small Arrays of Data,'' {\em Astron. Astrophys. Suppl.}, {\bf 44}, 371--374. \item IAU.\index{IAU} 1983, {\em Information Bulletin} No. 49. \item Grosb\o l, P., Harten, R. H., Greisen, E. W., and Wells, D. C. 1988, ``Generalized Extensions and Blocking Factors for {\em FITS},'' {\em Astron. Astrophys. Suppl.}, {\bf 73}, 359--364. \item Harten, R. H., Grosb\o l, P., Greisen, E. W., and Wells, D. C. 1988, ``The {\em FITS\/} Tables\index{ASCII table} Extension,'' {\em Astron. Astrophys. Suppl.}, {\bf 73}, 365--372. \item IAU. 1988, {\em Information Bulletin} No. 61. \item McNally, D., ed. 1988, Transactions\index{IAU Style Manual} of the IAU, {\em Proceedings of the Twentieth General Assembly} (Dordrecht: Kluwer). \item Wells, D. C. and Grosb\o l, P. 1990, ``Floating Point Agreement for\index{floating point FITS agreement} {\em FITS},'' (available electronically from {\tt ftp://nssdc.gsfc.nasa.gov/pub/fits/fp\_agree.ps}). \item Ponz, J. D., Thompson, R. W., and Mu\~{n}oz, J. R. 1994, ``The {\em FITS\/} Image\index{image extension} Extension,'' {\em Astron. Astrophys. Suppl.}, {\bf 105}, 53--55. \item Cotton, W. D., Tody, D. B., and Pence, W. D. 1995, ``Binary Table\index{binary table} Extension to {\em FITS},'' {\em Astron. Astrophys. Suppl.}, {\bf 113}, 159--166. \item Grosb\o l, P. and Wells, D. C. 1994, ``Blocking of Fixed-block Sequential\index{blocking} Media and Bitstream Devices,'' (available electronically from FITS Support Office at {\tt ftp://nssdc.gsfc.nasa.gov/pub/fits/blocking94.txt}). \item Bunclark, P. and Rots, A. 1997, ``Precise re-definition of DATE-OBS Keyword encompassing the millennium,'' (available electronically from \\ {\tt ftp://nssdc.gsfc.nasa.gov/pub/fits/year2000\_agreement.txt}). \item ANSI. 1978, ``American National Standard for Information Processing: Programming Language FORTRAN,'' ANSI X3.9--1978 (ISO 1539) (New York: American National\index{FORTRAN-77, ANSI manual}\index{ANSI, FORTRAN-77} Standards Institute, Inc.).\index{ANSI, X3.9--1978} \item ANSI. 1977, ``American National Standard for Information Processing: Code for Information Interchange,'' ANSI X3.4--1977 (ISO 646) (New York: American National Standards\index{ANSI, ASCII}\index{ASCII, ANSI} Institute, Inc.).\index{ANSI, X3.4--1977} \item IEEE. 1985, ``American National Standard --- IEEE Standard for Binary Floating Point Arithmetic''. ANSI/IEEE 754--1985 (New York: American\index{ANSI, IEEE}\index{IEEE, ANSI} National Standards Institute, Inc.). \item Jennings, D. G., Pence, W. D., Folk, M., and Schlesinger, B. M, 1997, ``A Hierarchical Grouping Convention for {\em FITS},'' preprint, available electronically from \\ {\tt http://fits.gsfc.nasa.gov/group.html} . \item ``Going AIPS,'' 1990, National Radio Astronomy Observatory, Charlottesville, VA.\index{Going AIPS}\index{AIPS, Going} \item Mu\~{n}oz, J. R. ``IUE data in\index{IUE} {\em FITS\/} Format,'' 1989, ESA IUE Newsletter, {\bf 32}, 12--45. \end{enumerate} \chapter{Definitions, Acronyms, and Symbols} \label{s:def} \begin{description} \item[\hbox{\tt\char`\ }] Used to designate an ASCII blank. \item[ANSI] American National Standards\index{ANSI} Institute. \item[Array] A sequence of data values.\index{array} This sequence corresponds to the elements in a rectilinear, n-dimension matrix ($0 \leq n \leq 999$). \item[Array value] The\index{array value} value of an element of an array in a {\em FITS\/} file, without the application of the associated linear transformation to derive the physical\index{physical value} value. \item[ASCII] American National Standard Code for Information\linebreak[1] Interchange. \item[ASCII blank] The ASCII character for blank\index{ASCII blank} which is represented by hexadecimal 20 (decimal 32). \item[ASCII character] Any\index{ASCII character} member of the 7-bit ASCII character set. \item[ASCII NULL] Hexadecimal\index{NULL, ASCII} 00. \item[ASCII text] ASCII characters\index{ASCII text} hexadecimal 20--7E. \item[Basic {\em\bf FITS}] The {\em FITS\/} structure\index{FITS structure} consisting of\index{Basic FITS} the primary header\index{primary header} followed by a single primary\index{primary data array} data array. \item[Bit] A single binary digit. \item[Byte] An ordered sequence of eight consecutive bits treated as a single entity. \item[Card image] A sequence of 80 bytes containing\index{card image} ASCII text\index{ASCII text}, treated as a logical entity. \item[Conforming extension] An extension whose keywords and organization\index{conforming extension} adhere to the requirements for conforming extensions defined in \S\ref{s:genext} of this standard.\index{extension, conforming} \item[DAT] 4mm Digital Audio Tape. \item[Deprecated] This term\index{deprecate} is used to refer to obsolete structures that should not be used for new applications but remain valid. \item[Entry] A single value in a table. \item[Extension] A\index{extension} {\em FITS\/} HDU appearing\index{HDU, extension} after the primary HDU in a {\em FITS\/} file. \item[Extension name] The identifier used to distinguish a particular extension HDU from others of the same type, appearing as the value of the\index{EXTNAME} {\tt EXTNAME} keyword.\index{extension name} \item[Extension type] An extension\index{format, extension} format. \item[Field] A set of zero or more table entries collectively described by a single format. \item[File] A sequence of one or more records terminated by an end-of-file indicator appropriate to the medium. \item[{\em\bf FITS}] Flexible Image Transport System. \item[{\em\bf FITS} file] A file with a format that conforms to the specifications in this document. \item[{\em\bf FITS} structure] One\index{FITS structure} of the components of a {\em FITS\/} file: the primary\index{HDU, primary} HDU, the random groups\index{random groups} records, an extension\index{extension}, or, collectively, the special records\index{special records} following the last extension. \item[Floating point] A computer representation of a real number. \item[Fraction]The\index{fraction} field of the mantissa\index{mantissa} (or significand) of a floating point number that lies to the right of its implied binary point. \item[Group parameter value] The\index{group parameter value} value of one of the parameters preceding a group in the random groups structure, without the application of the associated linear transformation. \item[GSFC] Goddard Space Flight Center. \item[HDU] Header and Data Unit. A data structure consisting of a header and the data the header describes. Note that an\index{HDU} HDU may consist entirely of a header with no data records. \item[Header] A series of card images organized within one or more {\em FITS\/} logical records that describes structures and/or data which follow it in the {\em FITS\/} file. \item[Heap] A supplemental data area, currently defined to follow the table in a\index{binary table} binary table extension. \item[IAU] International Astronomical\index{IAU} Union. \item[IAUFWG] \index{IAUFWG} International Astronomical Union {\em FITS\/} Working Group. \item[IUE] International Ultraviolet Explorer.\index{IUE} \item[IEEE] Institute of Electrical and Electronic\index{IEEE} Engineers. \item[IEEE NaN] IEEE Not-a-Number\index{IEEE NaN} value. \item[IEEE special values] Floating point number byte patterns that have a special, reserved meaning, such as $-0$, $\pm \infty$, $\pm$underflow, $\pm$overflow, $\pm$denormalized, $\pm$ NaN.\index{IEEE special values} (See Appendix \ref{s:IEEE754}). \item[Indexed keyword] A\index{keyword, indexed} keyword that is of the form of a fixed root with an appended positive integer count. \item[Keyword] The first eight bytes of a header card image. \item[Logical record] A record comprising 2880 8-bit bytes. \item[Mandatory keyword] A\index{keyword, required} keyword that must be used in all {\em FITS\/} files or a keyword required in conjunction with particular\index{FITS structure} {\em FITS\/} structures. \item[Mantissa] Also\index{mantissa} known as\index{significand} significand. The component of an IEEE floating point number consisting of an explicit or implicit leading bit to the left of its implied binary point and a fraction field to the right. \item[Matrix] A data array of two or more dimensions. \item[NOST] NASA/Science Office of Standards and Technology\index{NOST}. \item[Physical value] The\index{physical value} value in physical units\index{units} represented by an element of an array and possibly derived from the array value\index{array value} using the associated, but optional, linear transformation. \item[Picture element] A single location within an array. \item[Pixel] Picture element. \item[Primary data array] The\index{primary data array} data array contained in the\index{HDU, primary} primary HDU. \item[Primary HDU] The first HDU in a {\em FITS\/} file. \item[Primary header] The\index{primary header} first header in a {\em FITS\/} file, containing information on the overall contents of the file as well as on the primary data array. \item[Record] A sequence of bits treated as a single logical entity. \item[Reference point] The point along a given\index{coordinate axis} coordinate axis\index{reference point}, given in units\index{units} of pixel number, at which a value and increment are defined. \item[Repeat count] The\index{repeat count} number of values represented in a binary table\index{binary table} field. \item[Reserved keyword] An\index{keyword, reserved} optional keyword that may be used only in the manner defined in this standard. \item[Special records] A series of 23040-bit (2880 8-bit byte) records, following the primary\index{HDU, primary} HDU,\index{special records} whose internal structure does not otherwise conform to that for the primary HDU or to that specified for a conforming extension\index{conforming extension} in\index{extension, conforming} this standard. \item[Standard extension] A\index{standard extension} conforming\index{conforming extension} extension\index{extension, conforming} whose\index{extension, standard} header and data content are specified explicitly in this standard. \item[Type name] The value of the {\tt XTENSION} keyword\index{XTENSION}, used to identify the type\index{extension name} of the extension\index{extension} in the data following. \item[Valid value] A member of a data array or table corresponding to an actual physical quantity. \end{description} \chapter{FITS File Organization} \label{s:org} \section{Overall} % \label{s:overorg} A {\em FITS\/} file shall be composed of the following {\em FITS\/} structures\index{FITS structure}, in the order\index{order, {\em FITS\/} structures} listed: \begin{itemize} \item Primary HDU\index{HDU, primary} \item Conforming Extensions\index{conforming extension} (optional)\index{extension, conforming} \item Other special records (optional)\index{special records} \end{itemize} Each {\em FITS\/} structure\index{FITS structure} shall consist of an integral number of {\em FITS\/} logical records. The primary HDU\index{HDU, primary} shall start with the first record of the {\em FITS\/} file. The first record of each subsequent {\em FITS\/} structure\index{FITS structure} shall be the record immediately following the last record of the preceding {\em FITS\/} structure. The size of a {\em FITS\/} logical record shall be 23040 bits, corresponding to 2880 8-bit bytes. \section {Individual {\em\bf FITS\/} Structures} The primary HDU and every extension\index{extension} HDU\index{HDU, extension} shall consist of an integral number of header records consisting of ASCII\index{ASCII text} text, which may be followed by an integral number of data records. The first record of data shall be the record immediately following the last record of the header. \section{Primary Header and Data Array} The first component of a {\em FITS\/} file shall be the primary\index{primary header} header. The primary header may, but need not be, followed by a primary data\index{primary data array} array. The presence or absence of a primary data array shall be indicated by the values of the {\tt NAXIS} or\index{NAXIS} {\tt NAXISn} keywords\index{NAXISn} in the primary header (\S\ref{s:pman}). \subsection{Primary Header} The header of a primary HDU\index{HDU, primary} shall consist of a series of card images\index{card image} in ASCII\index{ASCII text} text. All header records shall consist of 36 card images. Card images without information shall be filled\index{fill} with ASCII blanks (hexadecimal 20). \subsection{Primary Data Array} In {\em FITS\/} format, the \label{s:pdata} primary\index{primary data array} data array shall consist of a single data array of 0--999~dimensions. The random groups convention in the primary data array is a more complicated structure (see \S\ref{s:Rgrp}). The data values shall be a byte stream with no embedded fill or blank space. The first value shall be in the first position of the first primary data array record. The first value of each subsequent row of the array shall be in the position immediately following the last value of the previous row. Arrays of more than one\index{array, multidimensional} dimension shall consist of a sequence such that the index along axis 1 varies most rapidly, that along axis~2 next most rapidly, and those along subsequent axes progressively less rapidly, with that along axis {\tt m}, where {\tt m} is the value of {\tt NAXIS}\index{NAXIS}, varying least rapidly; i.e., the elements of an array $A(x_{1}, x_{2}, \ldots, x_{m})$ shall be in the order\index{order, array index} shown in Figure \ref{f:array}. The index count along each axis shall begin with 1 and increment by 1 up to the value of the {\tt NAXISn}\index{NAXISn} keyword (\S\ref{s:pman}). \begin{figure}[t] \begin{center} \begin{tabular}{l} \\ A(1, 1, \ldots, 1), \\ A(2, 1, \ldots, 1), \\ \hspace{0.5in}\vdots, \\ A({\tt NAXIS1}, 1, \ldots, 1), \\ A(1, 2, \ldots, 1), \\ A(2, 2, \ldots, 1), \\ \hspace{0.5in}\vdots, \\ A({\tt NAXIS1}, 2, \ldots, 1), \\ \hspace{0.5in}\vdots, \\ A(1, {\tt NAXIS2}, \ldots, {\tt NAXISm}), \\ \hspace{0.5in}\vdots, \\ A({\tt NAXIS1}, {\tt NAXIS2}, \ldots, {\tt NAXISm}) \\ \end{tabular} \end{center} \caption[Array data sequence] {Arrays of more than one dimension shall consist of a sequence such that the index along axis 1 varies most rapidly and those along subsequent axes progressively less rapidly. Except for the\index{array, multidimensional} location of the first element, array structure is independent of record structure.} \label{f:array} \end{figure} If the data array does not fill the final record, the remainder of the record shall be filled by setting all bits to zero. % remainder of the record shall be filled\index{fill} with zero values with % the same data representation as the values in the array. For IEEE % floating point\index{floating point} data, % values of +0. shall\index{IEEE floating point +0.0} % be used to fill the remainder of the record. \section{Extensions} \subsection{Requirements for Conforming Extensions} \label{s:genext} All extensions\index{extension}, whether or not further described in this standard, shall fulfill the following requirements to be in conformance with this {\em FITS\/} standard. \subsubsection{Identity} \label{s:idy} Each extension\index{conforming extension} type\index{extension, conforming} shall have a unique type name, specified in the\index{extension name} header according to the syntax codified in \S\ref{s:conf}. To preclude conflict, extension type names must be registered\index{extension registration}\index{registration, extension} with the\index{IAUFWG} IAUFWG\@. The {\em FITS\/} Support Office\index{FITS Support Office} shall maintain and provide a list of the registered extensions. \subsubsection{Size Specification} The total number of bits in the data of each extension shall be specified in the header for that extension, in the manner prescribed in \S\ref{s:conf}. \subsubsection{Compatibility with Existing {\em\bf FITS\/} Files} No extension\index{extension} shall\index{FITS structure} be constructed that invalidates existing {\em FITS\/} files. \subsection{Standard Extensions} A standard\index{standard extension} extension\index{extension, standard} shall be a conforming\index{conforming extension} extension\index{extension, conforming} whose organization and content are completely specified in this standard. Only one {\em FITS\/} format shall be approved for each type of data organization. Each standard extension shall have a unique name \index{extension name} given by the value of the {\tt XTENSION} keyword (see Appendix \ref{s:resname}) \subsection{Order of Extensions} An extension may follow the primary HDU\index{HDU, primary} or another conforming\index{conforming extension} extension\index{extension, conforming}. Standard\index{standard extension} extensions\index{extension, standard} and other conforming extensions may appear in any order\index{order, extensions} in a {\em FITS\/} file. \section{Special Records} The first 8 bytes of special records must\index{special records} not contain the string\index{XTENSION} ``\verb+XTENSION+''. It is recommended that they not contain the string\index{SIMPLE, in special records} ``\verb*+SIMPLE +''. The records must have the standard {\em FITS\/} 23040-bit record length. The contents of special records are not otherwise specified by this standard. \section{Physical Blocking} \label{s:PhysBlk} \subsection{Bitstream Devices} \label{s:BitDev} For bitstream devices, including but not restricted to logical file systems, {\em FITS\/} files shall be written with fixed blocks of a physical block size equal to the 23040-bit {\em FITS\/} logical record size. \subsection{Sequential Media} \subsubsection{Fixed Block} \label{s:FixBlk} For fixed block length sequential media, including but not restricted to optical disks (accessed as a sequential set of records), QIC format 1/4-inch cartridge tapes, and local area networks, {\em FITS\/} files shall be written as a bitstream, using the fixed block size of the medium. If the end of the last logical record does not coincide with the end of a physical fixed block, all bits in the remainder of the physical block containing the last logical record shall be set to zero. After an end-of-file mark has been detected in the course of reading a {\em FITS\/} file, subsequent incomplete {\em FITS\/} logical records should be disregarded. \subsubsection{Variable Block} \label{s:VarBlk} For variable block length sequential media, including but not restricted to 1/2-inch 9-track tapes, DAT 4 mm cartridge tapes, and 8 mm cartridge tapes, {\em FITS\/} files may be written with an integer blocking factor equal to 1--10 logical records per physical block. \chapter{Headers} \label{s:head} \section{Card Images} \subsection{Syntax} Header card images\index{card image} shall consist of a keyword, a value indicator (optional unless a value is present), a value (optional), and a comment (optional). Except where specifically stated otherwise\index{order, keyword} in this standard, keywords may appear in any order. A formal syntax, giving a complete definition of the syntax of {\em FITS\/} card images, is given in Appendix \ref{s:FormSyn}. It is intended as an aid in interpreting the text defining the standard. \subsection{Components} \subsubsection{Keyword (bytes 1--8)} \label{s:keyw} The keyword shall be a left justified, 8-character, blank-filled, ASCII\index{fill} string with no embedded blanks. All digits (hexadecimal 30 to 39,``{\tt 0123456789}'') and upper case\index{case sensitivity} Latin alphabetic characters\index{keyword, valid characters} (hexadecimal 41 to 5A, ``{\tt ABCDEFG} {\tt HIJKLMN} {\tt OPQRST} {\tt UVWXYZ}'') are permitted; no lower case characters shall be used. The underscore\index{underscore} (hexadecimal 5F, ``{\tt \_}'') and hyphen\index{hyphen} (hexadecimal 2D, ``{\tt -}'') are also permitted. No other characters are permitted. For indexed\index{keyword, indexed} keywords with a single index the counter shall not have leading zeroes. \subsubsection{Value Indicator (bytes 9--10)} \label{s:ValInd} If this field contains the ASCII characters ``\verb*+= +'', it indicates the presence of a value field associated with the keyword, unless it is a commentary keyword\index{keyword, commentary} as defined in \S\ref{s:comk}. If the value indicator is not present or if it is a commentary keyword then columns 9--80 may contain any ASCII text. \subsubsection{Value/Comment (bytes 11--80)} \label{s:valcomm} This field, when used, shall contain the value, if any, of the keyword, followed by optional comments. The value field may be a null field; i.e., it may consist entirely of spaces. If the value field is null, the value associated with the keyword is undefined. If a comment is present, it must be preceded by a slash (hexadecimal 2F, ``{\tt /}''). A space between the value and the slash\index{slash} is strongly recommended. The value shall be the ASCII text representation of a string or constant, in the format specified in \S\ref{s:valC}. The comment may contain any ASCII\index{ASCII text} text. \section{Value} \label{s:valC} The structure of the value field shall be determined by the type of the variable. The value field represents a single value and not an array of values. The value field must be in one of two formats: fixed\index{format, fixed} or free\index{format, free}. The fixed format is required for values of mandatory keywords\index{format, keywords} and recommended for values of all others. This standard imposes no requirements on case sensitivity\index{case sensitivity} of character\index{character string} strings other than those explicitly specified. \subsection{Character String} \label{s:ffch} If the value is a fixed format character string, column 11 shall contain\index{character string} a single quote (hexadecimal code 27, ``\verb+'+''); the string shall follow, starting in column 12, followed by a closing single quote (also hexadecimal code 27) that should not occur before column 20 and must occur in or before column 80. The character string shall be composed only of ASCII\index{ASCII text} text. A single quote is represented within a string as two successive single quotes, e.g., O'HARA = {\tt 'O''HARA'}. Leading blanks are significant; trailing blanks are not. Free format character strings follow the same rules as fixed format character strings except that the starting and closing single quote characters may occur anywhere within columns 11--80. Any columns preceding the starting quote character and after column 10 must contain the space character. Note that there is a subtle distinction between the following 3 keywords: \begin{verbatim} KEYWORD1= '' / null string keyword KEYWORD2= ' ' / blank keyword KEYWORD3= / undefined keyword \end{verbatim} The value of {\tt KEYWORD1} is a null, or zero length string whereas the value of the {\tt KEYWORD2} is a blank string (nominally a single blank character because the first blank in the string is significant, but trailing blanks are not). The value of {\tt KEYWORD3} is undefined and has an indeterminate datatype as well, except in cases where the data type of the specified keyword is explicitly defined in this standard. The maximum allowed length of a keyword string is 68 characters (with the opening and closing quote characters in columns 11 and 80, respectively). In general, no length limit less than 68 is implied for character-valued keywords. \subsection{Logical} \label{s:ffl} If the value is a fixed format logical constant, it shall appear as a {\tt T} or {\tt F} in\index{logical value} column~30. A logical value is represented in free format by a single character consisting of {\tt T} or {\tt F}\@. This character must be the first non-blank character in columns 11--80. The only characters that may follow this single character are spaces, or a slash followed by an optional comment (see \S\ref{s:valcomm}). \subsection{Integer Number} \label{s:ffi} If the value is a fixed format integer, the ASCII representation shall be right justified in columns 11--30. An integer consists of a `+' (hexadecimal 2B) or `$-$' (hexadecimal 2D) sign, followed by one or more ASCII digits (hexadecimal 30 to 39), with no embedded spaces. The leading `+' sign is optional. Leading zeros are permitted, but are not significant. The integer representation described here is always interpreted as a signed, decimal number. A free format integer value follows the same rules as fixed format integers % except that it may occupy any columns 11--80. except that it may occur anywhere within columns 11--80. \subsection{Real Floating Point Number} \label{s:ffrfp} If the value is a fixed format real floating point number, the ASCII\index{floating point} representation shall appear, right justified, in columns 11--30. A floating point number is represented by a decimal number followed by an optional exponent, with no embedded spaces. A decimal number consists of a `+' (hexadecimal 2B) or `-' (hexadecimal 2D) sign, followed by a sequence of ASCII digits containing a single decimal point (`.'), representing an integer part and a fractional part of the floating point number. The leading `+' sign is optional. At least one of the integer part or fractional part must be present. If the fractional part is present, the decimal point must also be present. If only the integer part is present, the decimal point may be omitted. The exponent, if present, consists of an exponent letter followed by an integer. Letters in the exponential form (`E' or `D') shall be upper case. Note: The full precision of 64-bit values cannot be expressed over the whole range of values using the fixed format. A free format floating point value follows the same rules as fixed format % floating point values except that it may occupy any columns 11--80. floating point values except that it may occur anywhere within columns 11--80. \subsection{Complex Integer Number} \label{s:ffci} There is no fixed format for complex integer numbers. \index{integer, complex} \index{complex data representation} If the value is a complex integer number, the value must be represented as a real part and an imaginary part, separated by a comma and enclosed in parentheses. Spaces may precede and follow the real and imaginary parts. The real and imaginary parts are represented as integers (\S\ref{s:ffi}). Such a representation is regarded as a single value for the complex integer number. This representation may be located anywhere within columns 11--80. \subsection{Complex Floating Point Number} \label{s:ffcfp} There is no fixed format for complex floating point numbers. If the value is a complex floating point number, the value must be represented as a real part and an \index{floating point, complex} imaginary part, \index{complex data representation} separated by a comma and enclosed in parentheses. Spaces may precede and follow the real and imaginary parts. The real and imaginary parts are represented as floating point values (\S\ref{s:ffrfp}). Such a representation is regarded as a single value for the complex floating point number. This representation may be located anywhere within columns 11--80. \section{Units} \label{s:Units} The units\index{units} of all {\em FITS\/} header keyword values, with the exception of measurements of angles,\index{angle} should conform with the recommendations in the IAU Style Manual\index{IAU Style Manual} [7]. For angular measurements\index{angular measure} given as floating point values and specified with reserved keywords, degrees are the recommended units (with the units, if specified, given as {\tt 'deg'}). \section{Keywords} \label{s:key} \subsection{Mandatory Keywords} Mandatory\index{keyword, required} keywords are required in every HDU as described in the remainder of this subsection. They may be used only as described in this standard. \label{s:man} Values of the mandatory keywords must be written in fixed format. \subsubsection{Principal} The {\tt SIMPLE} keyword\index{SIMPLE, in primary header} is required to be the first keyword in\index{primary header} the primary header of all {\em FITS\/} files. Principal mandatory keywords other than {\tt SIMPLE} are required in all {\em FITS\/} headers. The card images of any primary header must contain the keywords shown in Table \ref{t:hdr1} in the order\index{keyword, order}\index{order, keyword} given. \label{s:pman} No other keywords may intervene between the {\tt SIMPLE} keyword and the last {\tt NAXISn} keyword. \begin{table}[thpb] \begin{center} \begin{tabular}{cl} 1 & {\tt SIMPLE} \\ 2 & {\tt BITPIX} \\ 3 & {\tt NAXIS} \\ 4 & {\tt NAXISn}, {\tt n} = 1, \ldots, {\tt NAXIS} \\ & \vdots \\ & (other keywords) \\ & \vdots \\ last & {\tt END} \\ \end{tabular} \end{center} \caption{Mandatory keywords for primary header.} \label{t:hdr1} \end{table} The total number of bits in the primary data array, exclusive of fill that is needed after the data to complete the last record (\S\ref{s:pdata}), is given by the\index{array size} following expression: \begin{eqnarray} \mbox{$N_{\rm bits}$} &=& |\mbox{{\tt BITPIX}}| \times (\mbox{{\tt NAXIS1}} \times \mbox{{\tt NAXIS2}} \times \cdots \times \mbox{{\tt NAXISm}}), \label{eq:prnbit} \end{eqnarray} \noindent where $N_{\rm bits}$ is\index{$N_{\rm bits}$} non-negative and the number of bits excluding fill, {\tt m} is the value\index{NAXIS} of {\tt NAXIS}, and\index{BITPIX} {\tt BITPIX} and\index{NAXISn} the {\tt NAXISn} represent the values associated with those keywords. \paragraph{{\tt SIMPLE} Keyword} The value field shall contain a logical constant with the value {\tt T} if the file conforms to this standard. This keyword is mandatory for the primary header and is not permitted in extension headers. A value of {\tt F} signifies that the file does not conform to this standard. \index{SIMPLE, in primary header} \paragraph{{\tt BITPIX} Keyword} The value field shall contain an integer. The\index{BITPIX} absolute value is used in computing the sizes of data structures. It shall specify the number of bits that represent a data value. The only valid values of {\tt BITPIX} are given in Table \ref{t:bitpix}. \begin{table}[thpb] \begin{center} \begin{tabular}{rl} \\ Value & \multicolumn{1}{c}{Data Represented} \\ \hline 8 & Character or unsigned binary integer \\ 16 & 16-bit twos-complement binary integer \\ 32 & 32-bit twos-complement binary integer \\ -32 & IEEE single precision floating point \\ -64 & IEEE double precision floating point \\ \end{tabular} \end{center} \caption{Interpretation of valid {\tt BITPIX} value.} \label{t:bitpix} \end{table} \paragraph{{\tt NAXIS} Keyword} The value field shall contain a non-negative integer no greater than 999, representing the number of axes in the associated data\index{NAXIS} array. A value of zero signifies that no data follow the header in the\index{HDU} HDU. \paragraph{{\tt NAXISn} Keywords} \label{s:naxisn} The value field of this indexed keyword\index{keyword, indexed} shall contain a non-negative integer, representing the number of elements along axis {\tt n} of a data array. The {\tt NAXISn} must be present for all values {\tt n = 1,...,NAXIS}, and for no other values of {\tt n}. A value of zero for any of the {\tt NAXISn} signifies that no data follow the header in the\index{HDU} HDU. If {\tt NAXIS} is equal to 0, there should not be any\index{NAXISn} {\tt NAXISn} keywords. \paragraph{{\tt END} Keyword} This keyword has no associated value. Columns 9--80\index{END} shall be filled with ASCII blanks. \subsubsection{Conforming Extensions} All conforming extensions must use the keywords\index{keyword, required} defined in Table \ref{t:hdr2} in the order\index{order, keyword}\index{keyword, order} specified. No other keywords may intervene between the {\tt XTENSION} keyword and the last {\tt NAXISn} keyword. This organization is required for any conforming extension, whether or not further specified in this standard. \begin{table}[thbp] \begin{center} \begin{tabular}{cl} 1 & {\tt XTENSION} \\ 2 & {\tt BITPIX} \\ 3 & {\tt NAXIS} \\ 4 & {\tt NAXISn}, {\tt n} = 1, \ldots, {\tt NAXIS} \\ & \vdots \\ & (other keywords, including \ldots ) \\ & {\tt PCOUNT} \\ & {\tt GCOUNT} \\ & \vdots \\ last & {\tt END} \\ \end{tabular} \end{center} \caption{Mandatory keywords in conforming extensions.} \label{t:hdr2} \end{table} The total number of bits in the extension data array exclusive of fill that is needed after the data to complete the last record %(\S\ref{s:overorg}) such as that for the such as that for the primary data array\index{primary data array} (\S\ref{s:pdata}) is given by the\index{array size} following expression: \begin{eqnarray} \mbox{$N_{\rm bits}$} &=& |\mbox{{\tt BITPIX}}| \times \label{eq:extbit} \mbox{{\tt GCOUNT}} \times \nonumber \\ & & (\mbox{{\tt PCOUNT}} + \mbox{{\tt NAXIS1}} \times \mbox{{\tt NAXIS2}} \times \cdots \times \mbox{{\tt NAXISm}}), \end{eqnarray} \noindent where $N_{\rm bits}$ is\index{$N_{\rm bits}$} non-negative and the number of bits excluding fill, {\tt m} is the value\index{NAXIS} of {\tt NAXIS}, and\index{BITPIX} {\tt BITPIX}, {\tt GCOUNT}, {\tt PCOUNT}, and\index{NAXISn} the {\tt NAXISn} represent\index{PCOUNT} the\index{GCOUNT} values associated with those keywords. \paragraph{{\tt XTENSION} Keyword} The value field shall contain a character string giving\index{XTENSION} the name\index{extension type name} of the extension type. This keyword is mandatory for an extension header and must not appear in the primary header\index{primary header}. For an extension that is not a standard\index{standard extension} extension, the type name must not be the same as that of a standard\index{extension, standard} extension. The IAUFWG\index{IAUFWG} may specify additional type names that must be used only to identify specific types of extensions; the full list shall be available from the {\em FITS\/} Support\index{FITS Support Office} Office. \paragraph{{\tt PCOUNT} Keyword} The value field shall contain an integer that shall be\index{PCOUNT} used in any way appropriate to define the data structure, consistent with Eq.\ \ref{eq:extbit}. \paragraph{{\tt GCOUNT} Keyword} The value field shall contain an integer that shall be\index{GCOUNT} used in any way appropriate to define the data structure, consistent with Eq.\ \ref{eq:extbit}. \paragraph{{\tt EXTEND} Keyword} \label{s:conf} The use of\index{conforming extension} extensions\index{extension, conforming} necessitates a single additional keyword\index{keyword, required} in the primary header\index{primary header} of the {\em FITS\/} file. \label{s:ext} If the {\em FITS\/} file may contain extensions, a card image\index{EXTEND} with the keyword {\tt EXTEND} and the value field containing the logical value {\tt T} must appear in the primary header immediately after the last {\tt NAXISn} card\index{NAXISn} image, or, if {\tt NAXIS}=0, the {\tt NAXIS} card\index{NAXIS} image. The presence of this keyword with the value {\tt T} in the primary header does not require that extensions be present. \subsection{Other Reserved Keywords} \label{s:resk} These\index{keyword, reserved} keywords are optional but may be used only as defined in this standard. They apply to any {\em FITS\/} structure\index{FITS structure} with the meanings and restrictions defined below. Any {\em FITS\/} structure may further restrict the use of these keywords. \subsubsection{Keywords Describing the History or Physical Construction of the HDU} \label{s:dhist} \paragraph{{\tt DATE} Keyword} Starting January 1, 2000, the following format shall be used. {\em FITS\/} writers should commence writing the value of the {\tt DATE} keyword in this format starting January 1, 1999 and before January 1, 2000. The value\index{value} field shall contain a character string\index{DATE, four-digit year form} giving the date on which the HDU was created, in the form {\tt YYYY-MM-DD}, or the date and time when the HDU was created, in the form {\tt YYYY-MM-DDThh:mm:ss}[{\tt .sss}\ldots], where {\tt YYYY} shall be the four-digit calendar year number, {\tt MM} the two-digit month number with January given by 01 and December by 12, and {\tt DD} the two-digit day of the month. When both date and time are given, the literal {\tt T} shall separate the date and time, {\tt hh} shall be the two-digit hour in the day, {\tt mm} the two-digit number of minutes after the hour, and {\tt ss}[{\tt .sss}\ldots] the number of seconds (two digits followed by an optional fraction) after the minute. No fields may be defaulted and no leading zeroes omitted. The decimal part of the seconds field is optional and may be arbitrarily long, so long as it is consistent with the rules for value formats of \S\ref{s:valC}. The value of the {\tt DATE} keyword shall always be expressed in UTC when in this format, for all data sets created on earth. The following format may appear on files written before January 1, 2000. The value\index{value} field contains a character string\index{DATE, two-digit year form} giving the date on which the HDU was created, in the form {\tt DD/MM/YY}, where {\tt DD} is the day of the month, {\tt MM} the month number with January given by 01 and December by 12, and {\tt YY} the last two digits of the year, the first two digits being understood to be 19. Specification of the date using Universal Time\index{Universal Time} is recommended but not assumed. Copying of a {\em FITS\/} file does not require changing any of the keyword values in the file's HDUs. \paragraph{{\tt ORIGIN} Keyword} The value field shall contain a character string\index{ORIGIN} identifying the organization or institution responsible for creating the {\em FITS\/} file. \paragraph{{\tt BLOCKED} Keyword} This keyword may be used only in the primary \label{s:block} header. It\index{BLOCKED} shall appear within the first 36 card images of the {\em FITS\/} file. (Note: This keyword thus cannot appear if {\tt NAXIS} is\index{NAXIS} greater than 31, or if {\tt NAXIS} is greater than 30 and the {\tt EXTEND} keyword\index{EXTEND} is present.) Its presence with the required logical value of {\tt T} advises that the physical block size of the {\em FITS\/} file on which it appears may be an integral multiple of the logical record length, and not necessarily equal to it. Physical block size and logical record length may be equal even if this keyword is present or unequal if it is absent. It is reserved primarily to prevent its use with other meanings. Since the issuance of version 1 of this standard, the {\tt BLOCKED} keyword\index{BLOCKED} has been deprecated\index{deprecate}. \subsubsection{Keywords Describing Observations} \label{s:kobs} \paragraph{{\tt DATE-OBS} Keyword} The format of the value field for {\tt DATE-OBS} keywords shall\index{DATE-OBS} follow the prescriptions for the {\tt DATE} keyword (\S\ref{s:dhist}). Either the 4-digit year format or the 2-digit year format may be used for observation dates from 1900 through 1999 although the 4-digit format is preferred. When the format with a four-digit year is used, the default interpretations for time shall be UTC for dates beginning 1972-01-01 and UT before. Other date and time scales are permissible. The value of the {\tt DATE-OBS} keyword shall be expressed in the principal time system\index{time system} or time scale of the HDU to which it belongs; if there is any chance of ambiguity, the choice shall be clarified in comments. The value of {\tt DATE-OBS} shall be assumed to refer to the start of an observation, unless another interpretation is clearly explained in the comment field. Explicit specification of the time scale is recommended. By default, times for TAI and times that run simultaneously with TAI, e.,g., UTC and TT, will be assumed to be as measured at the detector (or, in practical cases, at the observatory). For coordinate times such as TCG, TCB, and TDB which are tied to an unambiguous coordinate system, the default shall be time as if the observation had taken place at the origin of the coordinate time system. Conventions may be developed that use other time systems. Appendix \ref{s:tsys} of this document contains the appendix to the agreement on a four digit year, which discusses time systems in some detail. When the value of {\tt DATE-OBS} is expressed in the two-digit year form, allowed for files written before January 1, 2000 with a year in the range 1900-1999, there is no default assumption as to whether it refers to the start, middle or end of an observation. \paragraph{{\tt DATExxxx} Keywords} The value fields for all keywords beginning with the string {\tt DATE} whose value contains date, and optionally time, information shall\index{DATExxxx} follow the prescriptions for the {\tt DATE-OBS} keyword. \paragraph{{\tt TELESCOP} Keyword} The value field shall contain a character string\index{TELESCOP} identifying the telescope used to acquire the data associated with the header. \paragraph{{\tt INSTRUME} Keyword} The value field shall contain a character string\index{INSTRUME} identifying the instrument used to acquire the data associated with the header. \paragraph{{\tt OBSERVER} Keyword} The value field shall contain a character string\index{OBSERVER} identifying who acquired the data associated with the header. \paragraph{{\tt OBJECT} Keyword} The value field shall contain a character string\index{OBJECT} giving a name for the object observed. \paragraph{{\tt EQUINOX} Keyword} The value field shall contain a floating point number\index{EQUINOX} giving the equinox in years for the celestial coordinate system\index{coordinate system} in which positions are expressed. \paragraph{{\tt EPOCH} Keyword} The value field shall contain a floating point number\index{EPOCH} giving the equinox in years for the celestial coordinate system\index{coordinate system} in which positions are expressed. Starting with Version 1, this standard has deprecated\index{deprecate} the use of the {\tt EPOCH} keyword and thus it shall not be used in {\em FITS\/} files created after the adoption of this standard; rather, the {\tt EQUINOX} keyword\index{EQUINOX} shall be used. \subsubsection{Bibliographic Keywords} \paragraph{{\tt AUTHOR} Keyword} The value field shall contain a character string\index{AUTHOR} identifying who compiled the information in the data associated with the header. This keyword is appropriate when the data originate in a published paper or are compiled from many sources. \paragraph{{\tt REFERENC} Keyword} The value field shall contain a character string\index{REFERENC} citing a reference where the data associated with the header are published. \subsubsection{Commentary Keywords} \label{s:comk} \paragraph{{\tt COMMENT} Keyword} This\index{keyword, commentary} keyword shall have no associated value\index{COMMENT}; columns 9--80 may contain any ASCII\index{ASCII text} text. Any number of {\tt COMMENT} card images may appear in a header. \paragraph{{\tt HISTORY} Keyword} This keyword shall have no associated value\index{HISTORY}; columns 9--80 may contain any ASCII\index{ASCII text} text. The text should contain a history of steps and procedures associated with the processing of the associated data. Any number of {\tt HISTORY} card images may appear in a header. \paragraph{Keyword Field is Blank} Columns 1--8 contain ASCII blanks. Columns 9--80 may contain any ASCII\index{ASCII text} text. Any number of card images with blank keyword fields may appear in a header. \subsubsection{Array Keywords} \label{s:array} These keywords are used to describe the contents of an array, either alone or in a series of\index{array} random\index{random groups} groups (\S\ref{s:Rgrp}). They are optional, but if they appear in the header describing an array or groups, they must be used as defined in this section of this standard. They shall not be used in headers describing other structures unless the meaning is the same as that for a primary or groups array. \paragraph{{\tt BSCALE} Keyword} This keyword shall be used, along with the {\tt BZERO} keyword, when the array pixel values are not the true\index{BSCALE} physical\index{physical value} values, to transform the primary data array\index{primary data array} values to the true physical values they represent, using Eq.\ \ref{eq:bscl}. The value field shall contain a floating point number representing the coefficient of the linear term in the scaling equation, the ratio of physical value to array value\index{array value} at zero offset. The default value for this keyword is 1.0. \paragraph{{\tt BZERO} Keyword} This keyword shall be used, along with the {\tt BSCALE} keyword, when the array pixel values are not the true\index{BZERO} physical values, to transform the primary data array values to the true values. The value field shall contain a floating point number representing the physical value corresponding to an array value of zero. The default value for this keyword is 0.0. The transformation equation is as follows:\index{scaling, data} \begin{eqnarray} \mbox{physical\_value} & = & \mbox{{\tt BZERO}} + \mbox{{\tt BSCALE}} \times \mbox{array\_value} \label{eq:bscl} \end{eqnarray} \paragraph{{\tt BUNIT} Keyword} The value field shall contain a character string\index{BUNIT}, describing the physical units\index{units} in which the quantities in the array, after application\index{BSCALE} of {\tt BSCALE} and {\tt BZERO}, are\index{BZERO} expressed. These units must follow the prescriptions of \S\ref{s:Units}. \paragraph{{\tt BLANK} Keyword} This keyword shall be used only in headers with\index{BLANK} positive values of\index{BITPIX} {\tt BITPIX} (i.e., in arrays with integer data). Columns 1--8 contain the string, ``\verb*+BLANK +'' (ASCII blanks in columns 6--8). The value field shall contain an integer that specifies the representation of array values\index{array value} whose physical values\index{physical value} are undefined. \paragraph{{\tt CTYPEn} Keywords} The value field shall contain a character string, giving\index{CTYPEn} the name of the coordinate\index{coordinate axis} represented by axis {\tt n}. \paragraph{{\tt CRPIXn} Keywords} The value field shall contain a floating point number\index{CRPIXn}, identifying the location of a reference point\index{reference point} along axis {\tt n}, in units\index{units} of the axis index. This value is based upon a counter that runs from 1 to {\tt NAXISn} with\index{NAXISn} an increment of 1 per pixel. The reference point value need not be that for the center of a pixel nor lie within the actual data array. Use comments to indicate the location of the index point relative to the pixel. \paragraph{{\tt CRVALn} Keywords} The value field shall contain a floating point number\index{CRVALn}, giving the value of the coordinate\index{coordinate value} specified by\index{CTYPEn} the {\tt CTYPEn} keyword at the reference\index{CRPIXn} point {\tt CRPIXn}. Units must follow the prescriptions of \S\ref{s:Units}. \paragraph{{\tt CDELTn} Keywords} The value field shall contain a floating point number\index{CDELTn} giving the partial derivative of the coordinate specified by the {\tt CTYPEn} keywords\index{CTYPEn} with respect to the pixel index, evaluated at the reference\index{CRPIXn} point {\tt CRPIXn}, in units\index{units} of the coordinate specified by the {\tt CTYPEn} keyword. These units must follow the prescriptions of \S\ref{s:Units}. \paragraph{{\tt CROTAn} Keywords} This keyword is used to indicate a rotation from a\index{CROTAn} standard coordinate system\index{coordinate system} described by\index{CTYPEn} the {\tt CTYPEn} to a different coordinate system in which the values in the array are actually expressed. Rules for such rotations are not further specified in this standard; the rotation should be explained in comments. The value field shall contain a floating point number giving the rotation angle\index{angle} in degrees between axis {\tt n} and the direction implied by the coordinate system defined by {\tt CTYPEn}. \paragraph{{\tt DATAMAX} Keyword} The value field shall always contain a floating point\index{DATAMAX} number, regardless of the value of {\tt BITPIX}. This\index{BITPIX} number shall give the maximum valid physical value\index{physical value} represented by the array, exclusive of any\index{IEEE special values} special values. \paragraph{{\tt DATAMIN} Keyword} The value field shall always contain a floating point\index{DATAMIN} number, regardless of the value of {\tt BITPIX}. This\index{BITPIX} number shall give the minimum valid physical value represented by the array, exclusive of any special values. \subsubsection{Extension Keywords} These keywords are used to describe an\index{extension} extension and should not appear in the primary header. \paragraph{{\tt EXTNAME} Keyword} The value field shall contain a character string, to be\index{EXTNAME} used to distinguish\index{extension name} among different extensions of the same\index{XTENSION} type, i.e., with the same value of {\tt XTENSION}, in a {\em FITS\/} file. \paragraph{{\tt EXTVER} Keyword} The value field shall contain an integer, to be used to\index{EXTVER} distinguish among different extensions in a {\em FITS\/} file with the same type and name, i.e., the same values for {\tt XTENSION} and {\tt EXTNAME}. The values need not start with 1 for the first extension with a particular value of {\tt EXTNAME} and need not be in sequence for subsequent values. If the {\tt EXTVER} keyword is absent, the file should be treated as if the value were 1. \paragraph{{\tt EXTLEVEL} Keyword} The value field shall contain an integer, specifying the\index{EXTLEVEL} level in a hierarchy of extension levels of the extension header containing it. The value shall be 1 for the highest level; levels with a higher value of this keyword shall be subordinate to levels with a lower value. If the {\tt EXTLEVEL} keyword is absent, the file should be treated as if the value were 1. \subsection{Additional Keywords} \subsubsection{Requirements} New keywords\index{keyword, new} may be devised in addition to those described in this standard, so long as they are consistent with the generalized rules for keywords and do not conflict with mandatory or reserved keywords.\index{keyword, new} \subsubsection{Restrictions} No keyword in the primary header\index{primary header} shall specify the\index{keyword, restrictions} presence of a specific extension\index{extension} in a {\em FITS\/} file; only the {\tt EXTEND} keyword\index{EXTEND} described in \S\ref{s:ext} shall be used\index{keyword, restrictions} to indicate the possible presence of extensions. No keyword in either the primary or extension header shall explicitly refer to the physical block size, other than the deprecated {\tt BLOCKED} keyword\index{BLOCKED} of \S\ref{s:block}. \chapter{Data Representation} \label{s:Drep} Primary and extension\index{extension} data shall be represented in one of the\index{format, data} formats described in this section. {\em FITS\/} data shall be interpreted to be a byte stream. Bytes are in order\index{byte order}\index{order, byte} of decreasing significance. The byte that includes the sign bit\index{sign bit} shall be first, and the byte that has the ones bit shall be last. \section{Characters} Each character shall be represented by\index{ASCII character} one byte. A character shall be represented by its 7-bit ASCII [14] code in the low order seven bits in the byte. The high-order bit shall be zero. \section{Integers} \subsection{Eight-bit} Eight-bit integers shall be unsigned binary integers, contained in one byte.\index{integer, 8-bit} \subsection{Sixteen-bit} Sixteen-bit integers shall be twos-complement signed binary\index{twos-complement} integers, contained in two bytes.\index{integer, 16-bit} \subsection{Thirty-two-bit} Thirty-two-bit integers shall be twos-complement\index{twos-complement} signed binary integers, contained in four\index{integer, 32-bit} bytes. \subsection{Unsigned Integers} \label{s:Unsigned_Integers} Unsigned sixteen-bit integers can be represented in {\em FITS\/} files by subtracting 32768 from each value (thus offsetting the values into the range of a signed sixteen-bit integer) before writing them to the {\em FITS\/} file. The \verb+BZERO+ keyword (or the \verb+TZEROn+ keyword in the case of binary table columns with {\tt TFORMn = 'I'}) must also be included in the header with its value set to 32768 so that {\em FITS\/} reading software will add this offset to the raw values in the {\em FITS\/} file, thus restoring them to the original unsigned integer values. Unsigned thirty-two-bit integers can be represented in {\em FITS} files in a similar way by applying an offset of 2147483648 ($2^{31}$) to the data values. \section{IEEE-754 Floating Point} Transmission of 32- and 64-bit floating\index{IEEE floating point} point data within the {\em FITS\/} format shall use the\index{ANSI, IEEE} ANSI/IEEE-754 standard [15]. {\tt BITPIX = -32} and {\tt BITPIX = -64} signify 32- and 64-bit IEEE floating point\index{IEEE floating point} numbers, respectively; the absolute value of {\tt BITPIX} is\index{BITPIX} used for computing the sizes of data structures. The full IEEE set of number forms is allowed for {\em FITS\/} interchange, including all special\index{IEEE special values} values.\index{IEEE floating point} The {\tt BLANK} keyword\index{BLANK} should not be used when {\tt BITPIX = -32} or\index{BITPIX} {\tt -64}; rather, the IEEE NaN should be used to represent an undefined value. Use of\index{BSCALE} the {\tt BSCALE} and {\tt BZERO} keywords\index{BZERO} is not recommended. Appendix \ref{s:IEEE754} has additional details on the IEEE format. \chapter{Random Groups Structure} \label{s:Rgrp} Although it is standard {\em FITS}, the random groups structure\index{random groups} has been used almost exclusively for applications in radio\index{interferometry} interferometry; outside this field, few {\em FITS\/} readers can read data in random groups format. The binary table\index{binary table} extension (\S\ref{s:BTabl}) can accommodate the structure described by random groups. While existing {\em FITS\/} files use the format, and it is therefore included in this standard, its use for future applications has been deprecated\index{deprecate} since the issue of Version 1 of this standard. \section{Keywords} \label{s:rangr} \subsection{Mandatory Keywords} The {\tt SIMPLE} keyword\index{SIMPLE, before random groups} is required to be the first keyword in\index{primary header} the primary header of all {\em FITS\/} files, including those with random groups\index{random groups} records. If the random groups format records follow the primary header, the\index{keyword, required} card images of the primary header must use the keywords defined in Table \ref{t:hdrrg} in the order\index{order, keyword}\index{keyword, order} specified. No other keywords may intervene between the {\tt SIMPLE} keyword and the last {\tt NAXISn} keyword. \begin{table}[thbp] \begin{center} \begin{tabular}{cl} 1 & {\tt SIMPLE} \\ 2 & {\tt BITPIX} \\ 3 & {\tt NAXIS} \\ 4 & {\tt NAXIS1} \\ 5 & {\tt NAXISn}, {\tt n}=2, \ldots, value of {\tt NAXIS} \\ & \vdots \\ & (other keywords, which must include \ldots) \\ & {\tt GROUPS} \\ & {\tt PCOUNT} \\ & {\tt GCOUNT} \\ & \vdots \\ last & {\tt END} \\ \end{tabular} \end{center} \caption{Mandatory keywords in primary header preceding random groups.} \label{t:hdrrg} \end{table} The total number of bits in the random groups records exclusive of the fill described in \S\ref{s:grdata} is given by the following\index{array size} expression: \begin{eqnarray} \mbox{$N_{\rm bits}$} &=& |\mbox{{\tt BITPIX}}| \times \mbox{{\tt GCOUNT}} \times \nonumber \\ & & (\mbox{{\tt PCOUNT}} + \mbox{{\tt NAXIS2}} \times \mbox{{\tt NAXIS3}} \times \cdots \times \mbox{{\tt NAXISm}}), \end{eqnarray} \noindent where $N_{\rm bits}$ is\index{$N_{\rm bits}$} non-negative and the number of bits excluding fill, {\tt m} is the value\index{NAXIS} of {\tt NAXIS}, and\index{BITPIX} {\tt BITPIX}, {\tt GCOUNT}, {\tt PCOUNT}, and\index{NAXISn} the {\tt NAXISn} represent\index{PCOUNT} the\index{GCOUNT} values associated with those keywords. \subsubsection{{\tt SIMPLE} Keyword} The card image containing this keyword is structured in the\index{SIMPLE} same way as if a primary data array\index{primary data array} were present (\S\ref{s:man}). \subsubsection{{\tt BITPIX} Keyword} The card image containing this keyword is structured as prescribed in\index{BITPIX} \S\ref{s:man}. \subsubsection{{\tt NAXIS} Keyword} The value field shall contain an integer ranging from 1 to\index{NAXIS} 999, representing one more than the number of axes in each data array. \subsubsection{{\tt NAXIS1} Keyword} The value field shall contain the integer 0, a signature of\index{NAXIS1} random groups format indicating that there is no\index{primary data array} primary data array. \subsubsection{{\tt NAXISn} Keywords (n=2, \ldots, value of {\tt NAXIS})} The value field shall contain an integer, representing the\index{NAXISn} number of positions along axis {\tt n-1} of the data array in each group. \subsubsection{{\tt GROUPS} Keyword} The value field shall contain the logical constant {\tt T}. The\index{GROUPS} value {\tt T} associated with this keyword implies that random groups records are present. \subsubsection{{\tt PCOUNT} Keyword} The value field shall contain an integer equal to the number\index{PCOUNT} of parameters\index{parameter} preceding each array in a group. \subsubsection{{\tt GCOUNT} Keyword} The value field shall contain an integer equal to the\index{GCOUNT} number of random groups present. \subsubsection{{\tt END} Keyword} The card image containing this keyword is structured as described in\index{END} \S\ref{s:man}. \subsection{Reserved Keywords} \label{s:rgrrk} \subsubsection{{\tt PTYPEn} Keywords} \label{s:ptyp} The\index{keyword, reserved} value field shall contain a character string giving\index{PTYPEn} the name of parameter\index{parameter} {\tt n}. If the {\tt PTYPEn} keywords for more than one value of {\tt n} have the same associated name in the value field, then the data value for the parameter of that name is to be obtained by adding the derived data values of the corresponding parameters. This rule provides a mechanism by which a random parameter may have more precision than the accompanying data array elements; for example, by summing two 16-bit values with the first scaled relative to the other such that the sum forms a number of up to 32-bit precision. \subsubsection{{\tt PSCALn} Keywords} \label{s:pscl} This keyword shall be used, along\index{PSCALn} with the {\tt PZEROn} keyword, when the n$^{\rm th}$ {\em FITS\/} group parameter value\index{group parameter value} is not the true physical value\index{physical value}, to transform the group parameter value to the true physical values it represents, using Eq.\ \ref{eq:pscl}. The value field shall contain a floating point number representing the coefficient of the linear term in Eq.\ \ref{eq:pscl}, the scaling factor between true values and group parameter values at zero offset. The default value for this keyword is 1.0. \subsubsection{{\tt PZEROn} Keywords} \label{s:pzer} This keyword shall be used, along\index{PZEROn} with the {\tt PSCALn} keyword, when the {\tt n}$^{\rm th}$ {\em FITS\/} group parameter value\index{group parameter value} is not the true physical value, to transform the group parameter value to the physical value. The value field shall contain a floating point number, representing the true value corresponding to a group parameter value of zero. The default value for this keyword is 0.0. The transformation equation is as\index{scaling, data} follows: \begin{eqnarray} \mbox{physical\_value} & = & \mbox{{\tt PZEROn}} + \mbox{{\tt PSCALn}} \times \mbox{group\_parameter\_value} \label{eq:pscl} \end{eqnarray} \section{Data Sequence} \label{s:grdata} Random groups data shall consist of a set of groups. The number of groups shall be specified by the {\tt GCOUNT} keyword in the associated header record. Each group shall consist of the number of\index{GCOUNT} parameters\index{parameter} specified by the {\tt PCOUNT} keyword\index{PCOUNT} followed by an array with the number of elements $N_{\rm elem}$ given\index{random groups array} by the following\index{array size} expression: \begin{eqnarray} \mbox{$N_{\rm elem}$} &=& (\mbox{{\tt NAXIS2}} \times \mbox{{\tt NAXIS3}} \times \cdots \times \mbox{{\tt NAXISm}}), \end{eqnarray} \noindent where $N_{\rm elem}$ is the number of elements in the data array in a group, {\tt m} is the value\index{NAXIS} of {\tt NAXIS}, and\index{NAXISn} the {\tt NAXISn} represent the values associated with those keywords. The first parameter of the first group shall appear in the first location of the first data record. The first element of each array shall immediately follow the last parameter associated with that group. The first parameter of any subsequent group shall immediately follow the last element of the array of the previous group. The arrays shall be organized internally in the same way as an ordinary\index{primary data array} primary data array. If the groups data do not fill the final record, the remainder of the record shall be filled\index{fill} with zero values in the same way as a primary data array (\S\ref{s:pdata}). If random groups records are present, there shall be no primary data array. \section{Data Representation} Permissible data representations are those listed in \S\ref{s:Drep}. Parameters\index{parameter} and elements of associated data arrays shall have the same representation. Should more precision be required for an associated parameter than for an element of a data array, the parameter shall be divided into two or more addends, represented by the same value\index{PTYPEn} for the {\tt PTYPEn} keyword. The value shall be the sum of the physical values\index{physical value}, which may have been obtained\index{scaling, data} from the group parameter values\index{group parameter value} using\index{PSCALn} the {\tt PSCALn} and {\tt PZEROn} keywords.\index{PZEROn} \chapter{Standard Extensions} \label{s:exts} \section{The ASCII Table Extension} \label{s:ATabl} Data\index{standard extension} shall\index{extension, standard} appear as an ASCII table \index{ASCII table} extension if the primary header of the {\em FITS\/} file has the keyword\index{XTENSION} {\tt EXTEND} set\index{EXTEND} to {\tt T} and the first keyword of that extension\index{{\tt TABLE}, extension} header has \verb*+XTENSION= 'TABLE '+. \subsection{Mandatory Keywords} \label{s:atmk} The header of an ASCII table extension must use the keywords defined in Table \ref{t:hdr3}. The\index{keyword, mandatory} first keyword must be {\tt XTENSION}; the seven keywords following {\tt XTENSION} ({\tt BITPIX} \ldots {\tt TFIELDS}) must be in the order\index{order, keyword}\index{keyword, order} specified with no intervening keywords. \begin{table}[thbp] \begin{center} \begin{tabular}{cl} 1 & {\tt XTENSION} \\ 2 & {\tt BITPIX} \\ 3 & {\tt NAXIS} \\ 4 & {\tt NAXIS1} \\ 5 & {\tt NAXIS2} \\ 6 & {\tt PCOUNT} \\ 7 & {\tt GCOUNT} \\ 8 & {\tt TFIELDS} \\ & \vdots \\ & (other keywords, which must include \ldots ) \\ & {\tt TBCOLn}, n=1, 2, \ldots, k where k is the value of {\tt TFIELDS} \\ & {\tt TFORMn}, n=1, 2, \ldots, k where k is the value of {\tt TFIELDS} \\ & \vdots \\ last & {\tt END} \\ \end{tabular} \end{center} \caption{Mandatory keywords in ASCII table extensions.} \label{t:hdr3} \end{table} \paragraph{{\tt XTENSION} Keyword} The\index{XTENSION} value field shall contain the character\index{TABLE} string value text \verb*+'TABLE '+. \paragraph{{\tt BITPIX} Keyword} The value field shall contain the integer 8, denoting\index{BITPIX} that the array contains ASCII\index{ASCII character} characters. \paragraph{{\tt NAXIS} Keyword} The value field shall contain the integer 2, denoting\index{NAXIS} that the included data array is two-dimensional: rows and columns. \paragraph{{\tt NAXIS1} Keyword} The value field shall contain a non-negative integer, giving\index{NAXIS1} the number of ASCII characters in each row of the table. \paragraph{{\tt NAXIS2} Keyword} The value field shall contain a non-negative integer, giving\index{NAXIS2} the number of rows in the table. \paragraph{{\tt PCOUNT} Keyword} The value field shall contain the integer 0.\index{PCOUNT} \paragraph{{\tt GCOUNT} Keyword} The value field shall contain the integer 1; the data\index{GCOUNT} records contain a single table. \paragraph{{\tt TFIELDS} Keyword} The value field shall contain a non-negative integer representing\index{TFIELDS} the number of fields in each row. The maximum permissible value is 999. \paragraph{{\tt TBCOLn} Keywords} The value field of this indexed keyword shall contain an integer\index{TBCOLn} specifying the column in which field {\tt n} starts. The first column of a row is numbered 1. \paragraph{{\tt TFORMn} Keywords} The value field of this indexed keyword\index{TFORMn} shall contain a character string describing the format in which field {\tt n} is encoded. Only the formats\index{format} in Table \ref{t:tabF}, interpreted as ANSI FORTRAN-77 [13] input\index{FORTRAN-77} formats and discussed in more detail in \S\ref{s:ATEntry}, are permitted for encoding. Format codes must be specified in upper case. Other format editing codes common to ANSI FORTRAN-77 such as repetition, positional editing, scaling, and field termination are not permitted. All values in numeric fields have a number base of ten (i.e., they are decimal); binary, octal, hexadecimal, and other representations are not permitted. \begin{table}[thpb] \begin{center} \begin{tabular}{rl} \\ Field Value & Data Type \\ \hline \tt Aw & Character \\ \tt Iw & Decimal integer \\ \tt Fw.d & Single precision real \\ \tt Ew.d & Single precision real, exponential notation \\ \tt Dw.d & Double precision real, exponential notation \\ \end{tabular} \end{center} \caption{Valid {\tt TFORMn} format values in {\tt TABLE} extensions.} \label{t:tabF} \end{table} \paragraph{{\tt END} Keyword} This keyword has no associated value. Columns 9--80\index{END} shall contain ASCII blanks. \subsection{Other Reserved Keywords} \label{s:atork} In\index{keyword, reserved} addition to the mandatory keywords defined in \S\ref{s:atmk}, the following keywords may be used to describe the structure of an ASCII table data array. They are optional, but if they appear within an ASCII table extension header, they must be used as defined in this section of this standard. \paragraph{{\tt TSCALn} Keywords} This indexed keyword shall be used, along with the {\tt TZEROn} keyword, when the quantity in field {\tt n} does not\index{TSCALn} represent a true physical quantity. The value field shall contain a floating point number representing the coefficient of the linear term in Eq.\ \ref{eq:tscl}, which must be used to compute the true physical value\index{physical value} of the field. The default value for this keyword is 1.0. This keyword may not be used for A-format fields. \paragraph{{\tt TZEROn} Keywords} This indexed keyword shall be used, along with the {\tt TSCALn} keyword, when the quantity in field {\tt n} does not represent a true\index{TZEROn} physical quantity. The value field shall contain a floating point number representing the zero point for the true physical value of field {\tt n}. The default value for this keyword is 0.0. This keyword may not be used for A-format fields. The transformation equation used to compute a true physical value from the quantity in field {\tt n} is\index{scaling, data} \begin{eqnarray} \mbox{physical\_value} & = & \mbox{{\tt TZEROn}} + \mbox{{\tt TSCALn}} \times \mbox{field\_value}. \label{eq:tscl} \end{eqnarray} \paragraph{{\tt TNULLn} Keywords} The value field for this indexed keyword shall contain the character\index{TNULLn} string that represents\index{value, undefined} an undefined value for field {\tt n}. The string is implicitly blank filled\index{fill} to the width of the field. \paragraph{{\tt TTYPEn} Keywords} The value field for this indexed keyword shall contain a\index{TTYPEn} character string, giving the name of field {\tt n}. It is recommended that only letters, digits, and underscore\index{underscore} (hexadecimal code 5F, ``{\tt \_}'') be used in the name. String comparisons with the values of {\tt TTYPEn} keywords should not be case sensitive. The use of identical names for different fields should be avoided. \paragraph{{\tt TUNITn} Keywords} The value field shall contain a character string\index{TUNITn} describing the physical units\index{units} in which the quantity in field {\tt n}, after any application\index{TSCALn} of {\tt TSCALn} and {\tt TZEROn}, is\index{TZEROn} expressed. Units must follow the prescriptions in \S\ref{s:Units}. \subsection{Data Sequence} The table is constructed from a two-dimensional array of ASCII\index{ASCII character} characters. The row length and the number of rows shall be those specified, respectively, by the {\tt NAXIS1}\index{NAXIS1} and {\tt NAXIS2}\index{NAXIS2} keywords of the associated header records. The number of characters in a row and the number of rows in the table shall determine the size of the character array. Every row in the array shall have the same number of characters. The first character of the first row shall be at the start of the record immediately following the last header record. The first character of subsequent rows shall follow immediately the character at the end of the previous row, independent of the record structure. The positions in the last data record after the last character of the last row of the data array shall be filled\index{fill} with ASCII blanks. \subsection{Fields} Each row in the array shall consist of a sequence of fields, with one entry in each field. For every field, the ANSI FORTRAN-77 format\index{FORTRAN-77, format} of the information contained, location in the row of the beginning of the field and (optionally) the field name, shall be specified in keywords of the associated header records. A separate format keyword must be provided for each field. The location and format of fields shall be the same for every row. Fields may overlap. There may be characters in a table row that are not included in any field. \subsection{Entries} \label{s:ATEntry} All data in an ASCII table extension field shall be ASCII text\index{ASCII text} in a format that conforms to the rules for fixed field input in ANSI FORTRAN-77\index{FORTRAN-77, format} [13] format, as described below, including implicit decimal points. The only possible formats shall be those specified in Table \ref{t:tabF}. If values of -0 and +0 must be distinguished, then the sign character\index{sign character} should appear in a separate field in character format. {\tt TNULLn} keywords\index{TNULLn} may be used to specify a character string that represents\index{value, undefined} an undefined value in each field. The characters representing an undefined value may differ from field to field but must be the same within a field. Writers of ASCII tables should select a format appropriate to the form, range of values, and accuracy of the data in the table. The value of a character-formatted ({\tt A}{\tt w\/}) field is a character string of width $w$ containing the characters in columns {\tt TBCOL}{\tt n\/} through {\tt TBCOL}{\tt n}$ + {\tt w} - 1$. The value of an integer-formatted ({\tt I}{\tt w\/}) field is an integer number determined by removing all blanks from columns {\tt TBCOL}{\tt n\/} through {\tt TBCOL}{\tt n}$ + {\tt w} - 1$ and interpreting the remaining, right-justified characters as a signed decimal integer. A blank field has value 0. All characters other than blanks, the decimal integers (``{\tt 0}'' through ``{\tt 9}'') and a single leading sign character (``{\tt +}'' and ``{\tt -}'') are forbidden. The value of a real-formatted field ({\tt F}{\tt w.d\/}, {\tt E}{\tt w.d\/}, {\tt D}{\tt w.d\/}) is a real number determined from the {\tt w} characters from columns {\tt TBCOL}{\tt n\/} through {\tt TBCOL}{\tt n}$ + {\tt w} - 1$. The value is formed by \begin{enumerate} \item discarding all blank characters and right-justifying the non-blank characters, \item interpreting the first non-blank characters as a numeric string consisting of a single optional sign (``{\tt +}'' or ``{\tt -}'') followed by one or more decimal digits (``{\tt 0}'' through ``{\tt 9}'') optionally containing a single decimal point (``{\tt .}''). The numeric string is terminated by the end of the right-justified field or by the occurrence of any character other than a decimal point (``{\tt .}'') and the decimal integers (``{\tt 0}'' through ``{\tt 9}''). If the string contains no explicit decimal point, then the implicit decimal point is taken as immediately preceding the rightmost $d$ digits of the string, with leading zeros assumed if necessary. \item if the numeric string is terminated by a \begin{enumerate} \item ``{\tt +}'' or ``{\tt -}'', interpreting the following string as an exponent in the form of a signed decimal integer, or \item ``{\tt E}'', or ``{\tt D}'', interpreting the following string as an exponent of the form {\tt E} or {\tt D} followed by an optionally signed decimal integer constant. \end{enumerate} \item The exponent string, if present, is terminated by the end of the right-justified string. \item Characters other than those specified above are forbidden. \end{enumerate} The numeric value of the table field is then the value of the numeric string multiplied by ten (10) to the power of the exponent string, i.e., value = numeric\_string~$\times$ $10^{\rm (exponent\_string)}$. The default exponent is zero and a blankfield has value zero. There is no difference between the {\tt F}, {\tt D}, and {\tt E} formats; the content of the string determines its interpretation. Numbers requiring more precision and/or range than the local computer can support may be represented. It is good form to specify a {\tt D} format in {\tt TFORM}{\it n} for a column of an ASCII table when that column will contain numbers that cannot be accurately represented in 32-bit IEEE binary format (see Appendix \ref{s:IEEE754}). Note that the above definitions allow for embedded blanks anywhere in integer-formatted and real-formatted fields and implicit decimal points in real-formatted fields. {\em FITS\/} reading tasks will have to honor these flexibilities. However, since these flexibilities are likely to cause confusion and possible misinterpretation, it is recommended that {\em FITS\/} writing tasks write tables with explicit decimal points and no embedded or trailing blanks whenever possible. \section{Image Extension} \label{s:image} Data\index{standard extension} shall\index{extension, standard} appear as an image\index{image extension} extension if the primary header of the {\em FITS\/} file has the keyword {\tt EXTEND} set\index{EXTEND} to {\tt T} and the first keyword of that extension\index{XTENSION} header\index{IMAGE} has \\ {\verb*+XTENSION= 'IMAGE '+}. \subsection{Mandatory Keywords} \label{s:imk} The {\tt XTENSION} keyword is required to be the first keyword of all image extensions. The\index{keyword, required} card images in the header of an image extension must use the keywords defined in Table~\ref{t:hdr4} in the order specified. No other keywords may intervene between the {\tt XTENSION} and {\tt GCOUNT} keywords. \begin{table}[thpb] \begin{center} \begin{tabular}{cl} 1 & {\tt XTENSION} \\ 2 & {\tt BITPIX} \\ 3 & {\tt NAXIS} \\ 4 & {\tt NAXISn}, {\tt n} = 1, \ldots, {\tt NAXIS} \\ 5 & {\tt PCOUNT} \\ 6 & {\tt GCOUNT} \\ & \vdots \\ & (other keywords \ldots ) \\ & \vdots \\ last & {\tt END} \\ \end{tabular} \end{center} \caption{Mandatory keywords in image extensions.} \label{t:hdr4} \end{table} \paragraph{{\tt XTENSION} Keyword} The\index{XTENSION} value field shall contain the character\index{IMAGE} string value text \verb*+'IMAGE '+. \paragraph{{\tt BITPIX} Keyword} The value field shall contain an integer. The\index{BITPIX} absolute value is used in computing the sizes of data structures. It shall specify the number of bits that represent a data value. The only valid values of {\tt BITPIX} are given in Table \ref{t:bitpix}. \paragraph{{\tt NAXIS} Keyword} The value field shall contain a non-negative integer no greater than 999, representing the number of axes in the associated data\index{NAXIS} array. A value of zero signifies that no data follow the header in the image\index{image extension} extension. \paragraph{{\tt NAXISn} Keywords} \label{s:naxisni} The value field of this indexed keyword shall contain a non-negative integer, representing the number of elements along axis {\tt n} of a data array. The {\tt NAXISn} must be present for all values {\tt n = 1, \ldots, NAXIS}, and for no other values of {\tt n}. A value of zero for any of the {\tt NAXISn} signifies that no data follow the header in the\index{image extension} image extension. If {\tt NAXIS} is equal to 0, there should not be any {\tt NAXISn} \index{NAXISn} keywords. \paragraph{{\tt PCOUNT} Keyword} The value field shall contain the integer 0.\index{PCOUNT} \paragraph{{\tt GCOUNT} Keyword} The value field shall contain the integer 1; each\index{GCOUNT} image extension contains a single array. \paragraph{{\tt END} Keyword} This keyword has no associated value. Columns 9--80\index{END} shall be filled with ASCII blanks. \subsection{Units} The units\index{units} of all header keyword values in an image\index{image extension} extension shall follow the prescriptions in \S\ref{s:Units}. \subsection{Data Sequence} The data format shall be identical to that of a primary data array as\index{primary data array} described in \S\ref{s:pdata}. \section{Binary Table Extension} \label{s:BTabl} Data\index{standard extension} shall\index{extension, standard} appear as a binary table\index{binary table} extension if the primary header of the {\em FITS\/} file has the keyword\index{XTENSION} {\tt EXTEND} set\index{EXTEND} to {\tt T} and the first keyword of that extension\index{BINTABLE extension} header has \verb*+XTENSION= 'BINTABLE'+. \subsection{Mandatory Keywords} \label{s:btmk} The {\tt XTENSION} keyword is the first keyword of all binary table extensions. The seven keywords\index{keyword, required} following ({\tt BITPIX} \ldots {\tt TFIELDS}) must be in the order specified in Table \ref{t:hdrbin}, with no intervening keywords. \begin{table}[thbp] \begin{center} \begin{tabular}{cl} 1 & {\tt XTENSION} \\ 2 & {\tt BITPIX} \\ 3 & {\tt NAXIS} \\ 4 & {\tt NAXIS1} \\ 5 & {\tt NAXIS2} \\ 6 & {\tt PCOUNT} \\ 7 & {\tt GCOUNT} \\ 8 & {\tt TFIELDS} \\ & \vdots \\ & (other keywords, which must include \ldots ) \\ & {\tt TFORMn}, n=1, 2, \ldots, k where k is the value of {\tt TFIELDS} \\ & \vdots \\ last & {\tt END} \\ \end{tabular} \end{center} \caption{Mandatory keywords in binary table extensions.} \label{t:hdrbin} \end{table} \paragraph{{\tt XTENSION} Keyword} The\index{XTENSION} value field shall contain the character\index{BINTABLE} string \verb*+'BINTABLE'+. \paragraph{{\tt BITPIX} Keyword} The value field shall contain the integer 8, denoting\index{BITPIX} that the array is an array of 8-bit bytes. \paragraph{{\tt NAXIS} Keyword} The value field shall contain the integer 2, denoting\index{NAXIS} that the included data array is two-dimensional: rows and columns. \paragraph{{\tt NAXIS1} Keyword} The value field shall contain a non-negative integer, giving\index{NAXIS1} the number of 8-bit bytes in each row of the table. \paragraph{{\tt NAXIS2} Keyword} The value field shall contain a non-negative integer, giving\index{NAXIS2} the number of rows in the table. \paragraph{{\tt PCOUNT} Keyword} The value field\index{PCOUNT} shall contain the number of bytes that follow the table in the associated extension data. \paragraph{{\tt GCOUNT} Keyword} The value field shall contain the integer 1; the data\index{GCOUNT} records contain a single table. \paragraph{{\tt TFIELDS} Keyword} The value field shall contain a non-negative integer representing\index{TFIELDS} the number of fields in each row. The maximum permissible value is 999. \paragraph{{\tt TFORMn} Keywords} The value field of this indexed keyword shall contain a\index{TFORMn} character string of the form {\em r}{\tt T}{\em a}. The repeat count {\em r} is\index{repeat count} the ASCII representation of a non-negative integer specifying the number of elements in field {\tt n}. The default value of {\em r} is 1; the repeat count need not be present if it has the default value. A zero element count, indicating an empty\index{field, empty} field, is permitted. The data type {\tt T} specifies the data type of the contents of field {\tt n}. Only the data types in Table \ref{t:tabBF} are permitted. The format codes must be specified in upper case. For fields of type {\tt P}, the only permitted repeat counts are 0 and 1. The additional characters {\em a} are optional and are not further defined in this standard. Table \ref{t:tabBF} lists the number of bytes each data type occupies in a table row. The first field of a row is numbered 1. The total number of bytes $n_{\rm row}$ in a table row is given by \begin{eqnarray} n_{\rm row} & = & \sum_{i=1}^{\mbox{\tt TFIELDS}} {r_{i} b_{i}} \label{eq:binrow} \end{eqnarray} where $r_{i}$ is the repeat count for field $i$, $b_{i}$ is the number of bytes for the data type in field $i$, and {\tt TFIELDS} is the value of that keyword, must equal the value of\index{NAXIS1} {\tt NAXIS1}. \begin{table}[thpb] \begin{center} \begin{tabular}{ccc} \\ {\tt TFORMn} value & Description & 8-bit Bytes \\ \hline \tt L & Logical & 1 \\ \tt X & Bit & * \\ \tt B & Unsigned byte & 1 \\ \tt I & 16-bit integer & 2 \\ \tt J & 32-bit integer & 4 \\ \tt A & Character & 1 \\ \tt E & Single precision floating point & 4 \\ \tt D & Double precision floating point & 8 \\ \tt C & Single precision complex & 8 \\ \tt M & Double precision complex & 16 \\ \tt P & Array Descriptor & 8 \end{tabular} \end{center} $^*$ number of 8-bit bytes needed to contain all bits \caption{Valid {\tt TFORMn} data types in {\tt BINTABLE} extensions.} \label{t:tabBF} \end{table} \paragraph{{\tt END} Keyword} This keyword has no associated value. Columns 9--80\index{END} shall contain ASCII blanks. \subsection{Other Reserved Keywords} \label{s:btork} In\index{keyword, reserved} addition to the mandatory keywords defined in \S\ref{s:btmk}, these keywords may be used to describe the structure of a binary table data array. They are optional, but if they appear within a binary table extension header, they must be used as defined in this section of this standard. \paragraph{{\tt TTYPEn} Keywords} The value field for this indexed keyword shall contain a\index{TTYPEn} character string, giving the name of field {\tt n}. It is recommended that only letters, digits, and underscore (hexadecimal code 5F, ``{\tt \_}'') be used in the name. String comparisons with the values of {\tt TTYPEn} keywords should not be case sensitive. The use of identical names for different fields should be avoided. \paragraph{{\tt TUNITn} Keywords} The value field shall contain a character string\index{TUNITn} describing the physical units\index{units} in which the quantity in field {\tt n}, after any application\index{TSCALn} of {\tt TSCALn} and {\tt TZEROn}, is\index{TZEROn} expressed. Units must follow the prescriptions in \S\ref{s:Units}. \paragraph{{\tt TNULLn} Keywords} The value field for this indexed keyword shall contain the integer\index{TNULLn} that represents\index{value, undefined} an undefined value for field {\tt n} of data type {\tt B}, {\tt I}, or {\tt J}. The keyword may not be used if field {\tt n} is of any other data type. \paragraph{{\tt TSCALn} Keywords} This indexed keyword shall be used, along with the {\tt TZEROn} keyword, when the quantity in field {\tt n} does not\index{TSCALn} represent a true physical quantity. It may not be used if the format of field {\tt n} is {\tt A}, {\tt L}, or {\tt X}. The interpretation for fields of type {\tt P} is not defined. A proposed interpretation is described in Appendix \ref{s:app_varlen}. For fields with all other data types, the value field shall contain a floating point number representing the coefficient of the linear term in Eq.\ \ref{eq:tscl}, which is used to compute the true physical value\index{physical value} of the field, or, in the case of the complex data types C and M, of the real part of the field, with the imaginary part of the scaling factor set to zero. The default value for this keyword is 1.0. \paragraph{{\tt TZEROn} Keywords} This indexed keyword shall be used, along with the {\tt TSCALn} keyword, when the quantity in field {\tt n} does not\index{TZEROn} represent a true physical quantity. It may not be used if the format of field {\tt n} is {\tt A}, {\tt L}, or {\tt X}. The interpretation for fields of type {\tt P} is not defined. A proposed interpretation is described in Appendix \ref{s:app_varlen}. For fields with all other data types, the value field shall contain a floating point number representing the true physical value corresponding to a value of zero in field {\tt n} of the {\em FITS\/} file, or, in the case of the complex data types {\tt C} and {\tt M}, in the real part of the field, with the imaginary part set to zero. The default value for this keyword is 0.0. Equation \ref{eq:tscl} is used to compute\index{scaling, data} a true physical value from the quantity in field {\tt n}. \paragraph{{\tt TDISPn} Keywords} The value field of this indexed keyword shall contain a\index{TDISPn} character string describing the format recommended for the display of the contents of field {\tt n}. If the table value has been scaled, the physical value, derived using Eq.\ \ref{eq:tscl}, shall be displayed. All elements in a field shall be displayed with a single, repeated format. For purposes of display, each byte of bit (type {\tt X}) and byte (type {\tt B}) arrays is treated a an unsigned integer. Arrays of type {\tt A} may be terminated with a zero byte. Only the format codes in Table \ref{t:tabD}, discussed in \S\ref{s:BinDD}, are permitted for encoding. The format codes must be specified in upper case. If the {\tt Bw.m}, {\tt Ow.m}, and {\tt Zw.m} formats are not readily available to the reader, the {\tt Iw.m} display format may be used instead, and if the {\tt ENw.d} and {\tt ESw.d} formats are not available, {\tt Ew.d} may be used. The meaning of this keyword is not defined for fields of type {\tt P} in this standard but may be defined in conventions using such fields. \begin{table}[thpb] \begin{center} \begin{tabular}{rl} \\ Field Value & Data Type \\ \hline \tt Aw & Character \\ \tt Lw & Logical \\ \tt Iw.m & Integer \\ \tt Bw.m & Binary, integers only \\ \tt Ow.m & Octal, integers only \\ \tt Zw.m & Hexadecimal, integers only \\ \tt Fw.d & Single precision real \\ \tt Ew.dEe & Single precision real, exponential notation \\ \tt ENw.d & Engineering; E format with exponent multiple of 3 \\ \tt ESw.d & Scientific; same as EN but nonzero leading digit if not zero \\ \tt Gw.dEe & General; appears as F if significance not lost, else E. \\ \tt Dw.dEe & Double precision real, exponential notation \end{tabular} \end{center} \caption[Valid {\tt TDISPn} format values in {\tt BINTABLE} extensions]{Valid {\tt TDISPn} format values in {\tt BINTABLE} extensions. {\tt w} is the width in characters of displayed values, {\tt m} is the minimum number of digits displayed, {\tt d} is the number of digits to right of decimal, and {\tt e} is number of digits in exponent. The {\tt .m} and {\tt Ee} fields are optional.} \label{t:tabD} \end{table} \paragraph{{\tt THEAP} Keyword} The value field of this\index{THEAP} keyword shall contain an integer providing the separation, in bytes, between the start of the main data table and the start of a supplemental data area called the\index{heap} heap. The default value shall be the product\index{NAXIS1} of the values of {\tt NAXIS1} and\index{NAXIS2} {\tt NAXIS2}. This keyword shall not be used if the value of {\tt PCOUNT} is zero. A proposed application of this keyword is presented in Appendix \ref{s:app_varlen}. \paragraph{{\tt TDIMn} Keywords} The value field of this\index{TDIMn} indexed keyword shall contain a character string describing how to interpret the contents of field {\tt n} as a multidimensional array, providing the number of dimensions and the length along each axis. The form of the value is not further specified by this standard. A proposed convention is described in Appendix \ref{s:app_dim}. \subsection{Data Sequence} \label{s:btds} The data in a binary table extension shall consist of a Main Data Table which may, but need not, be followed by additional bytes. The positions in the last data record after the last additional byte, or, if there are no additional bytes, the last character of the last row of the data array, shall be filled\index{fill} by setting all bits to zero. \subsubsection{Main Data Table} \label{s:MbinT} The table is constructed from a two-dimensional byte array. The number of bytes in a row shall be specified by the value of the {\tt NAXIS1}\index{NAXIS1} keyword and the number of rows shall be specified by the {\tt NAXIS2}\index{NAXIS2} keyword of the associated header records. Within a row, fields shall be stored in order of increasing column number, as determined from the {\tt n} of the {\tt TFORMn} keywords. The number of bytes in a row and the number of rows in the table shall determine the size of the byte array. Every row in the array shall have the same number of bytes. The first row shall begin at the start of the record immediately following the last header record. Subsequent rows shall begin immediately following the end of the previous row, with no intervening bytes, independent of the record structure. Words need not be aligned along word boundaries. Each row in the array shall consist of a sequence of fields. The number of elements in each field and their data type shall be specified in keywords of the associated header records. A separate format keyword must be provided for each field. The location and format of fields shall be the same for every row. Fields may be\index{field, empty} empty, if the repeat count\index{repeat count} specified in the value of the {\tt TFORMn} keyword of the header is 0. The following data types, and no others, are permitted. \paragraph{Logical} If\index{TFORMn} the value of the {\tt TFORMn} keyword specifies data type {\tt L}, the contents of field {\tt n} shall consist of ASCII {\tt T} indicating true or ASCII {\tt F}, indicating false. A 0 byte (hexadecimal 0) indicates an invalid value. \paragraph{Bit Array} If the value of the {\tt TFORMn} keyword specifies data type {\tt X}, the contents of field {\tt n} shall consist of a sequence of bits starting with the most significant bit; the bits following shall be in order of decreasing significance, ending with the least significant bit. A bit array shall be composed of an integral number of bytes, with those bits following the end of the data set to zero. No null value is defined for bit arrays. \paragraph{Character} If the value of the {\tt TFORMn} keyword specifies data type {\tt A}, field {\tt n} shall contain a character string of\index{character string} zero or more members, composed of\index{ASCII text} ASCII text. This character string may be terminated before the length specified by the repeat count\index{repeat count} by\index{NULL, ASCII} an ASCII NULL (hexadecimal code 00). Characters after the first ASCII NULL are not defined. A string with the number of characters specified by the repeat count is not NULL terminated. Null strings are defined by the presence of an ASCII NULL as the first character. \paragraph{Unsigned 8-Bit Integer} If\index{TFORMn} the value of the {\tt TFORMn} keyword specifies data type {\tt B}, the data in field {\tt n} shall consist of unsigned 8-bit integers, with\index{integer, 8-bit} the most significant bit first, and subsequent bits in order of decreasing significance. Null values are given by the value of the\index{TNULLn} associated {\tt TNULLn} keyword. \paragraph{16-Bit Integer} If the value of the {\tt TFORMn} keyword specifies data type {\tt I}, the data in field {\tt n} shall consist of twos-complement signed 16-bit integers, contained\index{integer, 16-bit} in two bytes. The most significant byte shall be first. Within each byte the most significant bit shall be first, and subsequent bits shall be in order of decreasing significance. Null values are given by the value of the\index{TNULLn} associated {\tt TNULLn} keyword. Unsigned integers can be represented using the convention described in \S~\ref{s:Unsigned_Integers}. \paragraph{32-Bit Integer} If the value of the {\tt TFORMn} keyword specifies data type {\tt J}, the data in field {\tt n} shall consist of twos-complement signed 32-bit integers, contained\index{integer, 32-bit} in four bytes. The most significant byte shall be first, and subsequent bytes shall be in order of decreasing significance. Within each byte, the most significant bit shall be first, and subsequent bits shall be in order of decreasing significance. Null values are given by the value of the\index{TNULLn} associated {\tt TNULLn} keyword. Unsigned integers can be represented using the convention described in \S~\ref{s:Unsigned_Integers}. \paragraph{Single Precision Floating Point} If\index{TFORMn} the value of the {\tt TFORMn} keyword specifies data type {\tt E}, the data in field {\tt n} shall consist of\index{ANSI, IEEE} ANSI/IEEE-754 [15] 32-bit floating point\index{floating point} numbers, as described in Appendix \ref{s:IEEE754}. All IEEE special values\index{special values, IEEE} are recognized. The IEEE NaN is\index{NaN, IEEE} used to represent invalid values. \paragraph{Double Precision Floating Point} If the value of the {\tt TFORMn} keyword specifies data type {\tt D}, the data in field {\tt n} shall consist of ANSI/IEEE-754 [15] 64-bit double precision floating point\index{floating point} numbers, as described in Appendix \ref{s:IEEE754}. All IEEE special values\index{special values, IEEE} are recognized. The IEEE NaN is\index{NaN, IEEE} used to represent invalid values. \paragraph{Single Precision Complex} If\index{TFORMn} the value of the {\tt TFORMn} keyword specifies data type {\tt C}, the data in field {\tt n} shall consist of a sequence of pairs of 32-bit\index{complex data representation} single precision floating point\index{floating point, complex} numbers. The first member of each pair shall represent the real part of a complex number, and the second member shall represent the imaginary part of that complex number. If either member contains a NaN, the entire complex value is invalid. \paragraph{Double Precision Complex} If the value of the {\tt TFORMn} keyword specifies data type {\tt M}, the data in field {\tt n} shall consist of a sequence of pairs of 64-bit double precision floating point numbers. The first member of each pair shall represent the real part of a complex number, and the second member of the pair shall represent the imaginary part of that complex number. If either member contains a NaN, the entire complex value is invalid. \paragraph{Array Descriptor} If\index{TFORMn} the value of the {\tt TFORMn} keyword specifies data type {\tt P}, the data\index{array descriptor} in field {\tt n} shall consist of not more than one pair of\index{integer, 32-bit} 32-bit integers. The meaning of these integers is not defined by this standard. The proposed application of this data type is described in Appendix \ref{s:app_varlen}. \subsubsection{Bytes Following Main Table} The main data table shall be followed by zero or more bytes, as specified by the value of the {\tt PCOUNT} keyword. The meaning of these bytes is not further defined by this standard. One proposed application is described in Appendix \ref{s:app_varlen}. \subsection{Data Display} \label{s:BinDD} Character data are encoded under format code {\tt A}{\tt w\/}. If the character datum has length less than or equal to {\tt w}, it is represented on output right-justified in a string of {\tt w} characters. If the character datum has length greater than {\tt w}, the first {\tt w} characters of the datum are represented on output in a string of {\tt w} characters. Character data are not surrounded by single or double quotation marks unless those marks are themselves part of the data value. Logical data are encoded under format code {\tt L}{\tt w\/}. Logical data are represented on output with the character {\tt T} for true or {\tt F} for false right justified in a blank-filled string of {\tt w} characters. A null value may be represented by a completely blank string of {\tt w} characters. Integer data (including bit {\tt X} and byte {\tt B} type fields) are encoded under format codes {\tt I}{\tt w.m\/}, {\tt B}{\tt w.m\/}, {\tt O}{\tt w.m\/}, and {\tt Z}{\tt w.m\/}. The default value of {\tt m} is one and the ``{\tt .m}'' is optional. The first letter of the code specifies the number base for the encoding with {\tt I} for decimal (10), {\tt B} for binary (2), {\tt O} for octal (8), and {\tt Z} for hexadecimal (16). Hexadecimal format uses the upper-case letters A through F to represent decimal values 10 through 15. The output field consists of {\tt w} characters containing zero or more leading blanks followed by a minus if the internal datum is negative followed by the magnitude of the internal datum in the form of an unsigned integer constant in the specified number base with only as many leading zeros as are needed to have at least {\tt m} numeric digits. Note that {\tt m} $\leq$ {\tt w} is allowed if all values are positive, but {\tt m} $<$ {\tt w} is required if any values are negative. If the number of digits required to represent the integer datum exceeds {\tt w}, then the output field consists of a string of {\tt w} asterisk ({\tt *}) characters. Real data are encoded under format codes {\tt F}{\tt w.d\/}, {\tt E}{\tt w.d\/}{\tt E}{\tt e\/}, {\tt D}{\tt w.d\/}{\tt E}{\tt e\/}, {\tt EN}{\tt w.d\/}, and {\tt ES}{\tt w.d\/}. In all cases, the output is a string of {\tt w} characters including the decimal point, any sign characters, and any exponent including the exponent's indicators, signs, and values. If the number of digits required to represent the real datum exceeds {\tt w}, then the output field consists of a string of {\tt w} asterisk ({\tt *}) characters. In all cases, {\tt d} specifies the number of digits to appear to the right of the decimal point. The {\tt F} format code output field consists of ${\tt w} - {\tt d} - 1$ characters containing zero or more leading blanks followed by a minus if the internal datum is negative followed by the absolute magnitude of the internal datum in the form of an unsigned integer constant. These characters are followed by a decimal point (``{\tt .}'') and {\tt d} characters giving the fractional part of the internal datum, rounded by the normal rules of arithmetic to {\tt d} fractional digits. For the {\tt E} and {\tt D} format codes, an exponent is taken such that the fraction $0.1 \le |{\rm datum}| / 10^{\rm exponent} < 1.0$. The fraction (with appropriate sign) is output with an {\tt F} format of width $ {\tt w} - {\tt e} - 2$ characters with {\tt d} characters after the decimal followed by an {\tt E} or {\tt D} followed by the exponent as a signed ${\tt e} + 1$ character integer with leading zeros as needed. The default value of {\tt e} is 2 when the {\tt E}{\tt e} portion of the format code is omitted. If the exponent value will not fit in ${\tt e} + 1$ characters but will fit in ${\tt e} + 2$ then the {\tt E} (or {\tt D}) is omitted and the wider field used. If the exponent value will not fit (with a sign character) in ${\tt e} + 2$ characters, then the entire {\tt w}-character output field is filled with asterisks ({\tt *}). The {\tt ES} format code is processed in the same manner as the {\tt E} format code except that the exponent is taken so that $ 1.0 \leq {\rm fraction} < 10$. The {\tt EN} format code is processed in the same manner as the {\tt E} format code except that the exponent is taken to be an integer multiple of 3 and so that $ 1.0\leq {\rm fraction} < 1000.0$. All real format codes have number base 10. There is no difference between {\tt E} and {\tt D} format codes on input other than an implication with the latter of greater precision in the internal datum. The {\tt G}{\tt w.d\/}{\tt E}{\tt e\/} format code may be used with data of any type. For data of type integer, logical, or character, it is equivalent to {\tt I}{\tt w}, {\tt L}{\tt w}, or {\tt A}{\tt w}, respectively. For data of type real, it is equivalent to an {\tt F} format (with different numbers of characters after the decimal) when that format will accurately represent the value and is equivalent to an {\tt E} format when the number (in absolute value) is either very small or very large. Specifically, for real values outside the range $0.1\,-\,0.5\!\times\! 10^{-{\tt d}-1} \leq {\rm value} < 10^{\tt d}\,-\,0.5$, it is equivalent to {\tt E}{\tt w.d}{\tt E}{\tt e}. For real values within the above range, it is equivalent to {\tt F}{${\tt w}^{\prime}.{\tt d}^{\prime}\,$} followed by $2 + {\tt e}$ blanks, where ${\tt w}^{\prime} = {\tt w} - {\tt e} - 2$ and ${\tt d}^{\prime} = {\tt d} - k$ for $k = 0,1,\ldots,{\tt d}$ if the real datum value lies in the range $10^{k-1} \left(1\,-\, 0.5\!\times\!10^{-{\tt d}}\right) \leq {\rm value} \le 10^k \left(1\,-\, 0.5\!\times\!10^{-{\tt d}}\right)$. Complex data are encoded with any of the real data formats as described above. The same format is used for the real and imaginary parts. It is recommended that the 2 values be separated by a comma and enclosed in parentheses with a total field width of $2{\tt w} + 3$. \chapter{Restrictions on Changes} \label{s:Restrict} Any structure that is a valid {\em FITS\/} structure\index{FITS structure} shall remain a valid {\em FITS\/} structure at all future times. Use of certain valid {\em FITS\/} structures may be deprecated\index{deprecate} by this or future {\em FITS\/} standard documents. \appendix \chapter{Formal Syntax of Card Images} \label{s:FormSyn} (This Appendix is not part of the NOST {\em FITS\/} standard but is included for convenient reference.) The following notation is used in defining the formal syntax. \begin{tabbing} \null \hspace{0.5in} \= := \hspace{0.5in} \= means ``is defined to be'' \\ \>X $|$ Y \> means one of X or Y (no ordering relation is implied) \\ \>[X] \> means that X is optional \\ \>X... \> means X is repeated 1 or more times \\ \>`B' \> means the ASCII character B \\ \>`A'--`Z' \> means one of the ASCII characters A through Z \\ \>\verb+\+0xnn \> means the ASCII character associated with the hexadecimal code nn \\ \>\{...\} \> expresses a constraint or a comment (it immediately follows the syntax rule) \\ \end{tabbing} The following statements define the formal syntax used in {\em FITS\/} free format card images.\\ FITS\_card\_image := \\ \null \hspace{0.5in} FITS\_commentary\_card\_image $|$ FITS\_value\_card\_image \\ FITS\_commentary\_card\_image := \\ \null \hspace{0.5in} COMMENT\_keyword [ascii\_text\_char...] $|$ \\ \null \hspace{0.5in} HISTORY\_keyword [ascii\_text\_char...] $|$ \\ \null \hspace{0.5in} BLANKFIELD\_keyword [ascii\_text\_char...] $|$ \\ \null \hspace{0.5in} keyword\_field anychar\_but\_equal [ascii\_text\_char...] $|$ \\ \null \hspace{0.5in} keyword\_field '=' anychar\_but\_space [ascii\_text\_char...] \\ \{Constraint: The total number of characters in a FITS\_commentary\_card\_image must be exactly equal to 80.\} \\ \newpage FITS\_value\_card\_image := \\ \null \hspace{0.5in} keyword\_field value\_indicator [space...] [value] [space...] [comment] \\ \{Constraint: The total number of characters in a FITS\_value\_card\_image must be exactly equal to 80.\} \\ \{Comment: If the value field is not present, the value of the {\em FITS\/} keyword is not defined.\} \\ keyword\_field := \\ \null \hspace{0.5in} [keyword\_char...] [space...] \\ \{Constraint: The total number of characters in the keyword\_field must be exactly equal to 8.\} \\ keyword\_char := \\ \null \hspace{0.5in} `A'--`Z' $|$ `0'--`9' $|$ `\_' $|$ `-' \\ COMMENT\_keyword := \\ \null \hspace{0.5in} `C' `O' `M' `M' `E' `N' `T' space \\ HISTORY\_keyword := \\ \null \hspace{0.5in} `H' `I' `S' `T' `O' `R' `Y' space \\ BLANKFIELD\_keyword := \\ \null \hspace{0.5in} space space space space space space space space \\ value\_indicator := \\ \null \hspace{0.5in} `=' space \\ space := \\ \null \hspace{0.5in} `\verb+ +' \\ comment := \\ \null \hspace{0.5in} `/' [ascii\_text\_char...] \\ ascii\_text\_char := \\ \null \hspace{0.5in} space--`\verb+~+' \\ anychar\_but\_equal := \\ \null \hspace{0.5in} space--`$<$' $|$ `$>$'--`\verb+~+' \\ anychar\_but\_space := \\ \null \hspace{0.5in} `!'--`\verb+~+' \\ value := \\ \null \hspace{0.5in} character\_string\_value $|$ logical\_value $|$ integer\_value $|$ floating\_value $|$ \\ \null \hspace{0.5in} complex\_integer\_value $|$ complex\_floating\_value \\ character\_string\_value := \\ \null \hspace{0.5in} begin\_quote [string\_text\_char...] end\_quote \\ \{Constraint: The begin\_quote and end\_quote are not part of the character string value but only serve as delimiters. Leading spaces are significant; trailing spaces are not.\} \\ begin\_quote := \\ \null \hspace{0.5in} quote \\ end\_quote := \\ \null \hspace{0.5in} quote \\ \{Constraint: The ending quote must not be immediately followed by a second quote.\} \\ quote := \\ \null \hspace{0.5in} \verb+\+0x27 \\ string\_text\_char := \\ \null \hspace{0.5in} ascii\_text\_char \\ \{Constraint: A string\_text\_char is identical to an ascii\_text\_char except for the quote char; a quote char is represented by two successive quote chars.\} \\ logical\_value := \\ \null \hspace{0.5in} `T' $|$ `F' \\ integer\_value := \\ \null \hspace{0.5in} [sign] digit [digit...] \\ \{Comment: Such an integer value is interpreted as a signed decimal number. It may contain leading zeros.\} \\ sign := \\ \null \hspace{0.5in} `-' $|$ `+' \\ digit := \\ \null \hspace{0.5in} `0'--`9' \\ floating\_value := \\ \null \hspace{0.5in} decimal\_number [exponent] decimal\_number := \\ \null \hspace{0.5in} [sign] [integer\_part] [?.? [fraction\_part]] \\ \{Constraint: At least one of the integer\_part and fraction\_part must be present.\} \\ integer\_part := \\ \null \hspace{0.5in} digit $|$ [digit...] \\ fraction\_part := \\ \null \hspace{0.5in} digit $|$ [digit...] \\ exponent := \\ \null \hspace{0.5in} exponent\_letter [sign] digit [digit...] \\ exponent\_letter := \\ \null \hspace{0.5in} `E' $|$ `D' \\ complex\_integer\_value := \\ \null \hspace{0.5in} `(' [space...] real\_integer\_part [space...] `,' [space...] \\ \null \hspace{0.5in} imaginary\_integer\_part [space...] `)' \\ real\_integer\_part := \\ \null \hspace{0.5in} integer\_value \\ imaginary\_integer\_part := \\ \null \hspace{0.5in} integer\_value \\ complex\_floating\_value := \\ \null \hspace{0.5in} `(' [space...] real\_floating\_part [space...] `,' [space...] \\ \null \hspace{0.5in} imaginary\_floating\_part [space...] `)' \\ real\_floating\_part := \\ \null \hspace{0.5in} floating\_value \\ imaginary\_floating\_part := \\ \null \hspace{0.5in} floating\_value \\ \chapter{Proposed Binary Table Conventions} \label{s:Bincon} (This Appendix is not part of the NOST {\em FITS\/} Standard but is included for informational purposes only.) In the paper describing the binary table\index{binary table} extension\index{BINTABLE extension}, type name {\tt 'BINTABLE'} [10], the authors present three conventions: one for variable length arrays, one for multidimensional arrays and one for substring arrays. These conventions, discussed in appendixes to the proposal, are not part of the formal {\tt BINTABLE} rules adopted by the IAUFWG but are expected to enjoy wide acceptance. The draft text for those appendixes, available on-line in the directory {\tt http://www.cv.nrao.edu/fits/documents/standards/}, is reproduced here nearly verbatim; the only changes are those required for stylistic consistency with the rest of this document. %\appendix A of BINTABLE paper \section{``Variable Length Array'' Facility} \label{s:app_varlen} One of the most attractive features of binary tables is that any field of the table can be an array. In the standard case this is a fixed size array, i.e., a fixed amount of storage is allocated in each record for the array data---whether it is used or not. This is fine so long as the arrays are small or a fixed amount of array data will be stored in each record, but if the stored array length varies for different records, it is necessary to impose a fixed upper limit on the size of the array that can be stored. If this upper limit is made too large excessive wasted space can result and the binary table mechanism becomes seriously inefficient. If the limit is set too low then it may become impossible to store certain types of data in the table. The ``variable length array'' construct\index{array, variable length} presented here\index{variable length array} was devised to deal with this problem. Variable length arrays are implemented in such a way that, even if a table contains such arrays, a simple reader program which does not understand variable length arrays will still be able to read the main table (in other words a table containing variable length arrays conforms to the basic binary table standard). The implementation chosen is such that the records in the main table remain fixed in size even if the table contains a variable length array field, allowing efficient random access to the main table. Variable length arrays are logically equivalent to regular static arrays, the only differences being 1) the length of the stored array can differ for different records, and 2) the array data is not stored directly in the table records. Since a field of any datatype can be a static array, a field of any datatype can also be a variable length array (excluding type {\tt P}, the variable length array descriptor itself, which is not a datatype so much as a storage class specifier). Conventions such\index{TDIMn} as {\tt TDIMn} (see Appendix~\ref{s:app_dim}) apply equally to both variable length and static arrays. A variable length array is declared in the table header with a special field datatype specifier of the form % \[ r\mbox{{\tt P}}t\mbox{(}maxelem\mbox{)} \] \[ {\tt rPt}({\tt e}_{\rm max}) \] where the ``{\tt P}'' indicates the amount of space occupied by the array descriptor\index{array descriptor} in the data record (64 bits), the element count {\tt r} should be 0, 1, or absent, {\tt t} is a character denoting the datatype of the array data ({\tt L}, {\tt X}, {\tt B}, {\tt I}, {\tt J}, etc., but not {\tt P}), and ${\tt e}_{\rm max}$ is a quantity guaranteed to be equal to or greater than the maximum number of elements of type {\rm t} actually stored in a table record. There is no built-in upper limit on the size of a stored array; ${\tt e}_{\rm max}$ merely reflects the size of the largest array actually stored in the table, and is provided to avoid the need to preview the table when, for example, reading a table containing variable length elements into a database that supports only fixed size arrays. There may be additional characters in the {\tt TFORMn} keyword following\index{TFORMn} the ${\tt e}_{\rm max}$. For example, \[\mbox{{\tt TFORM8 = 'PB(1800)' / Variable byte array}} \] indicates that field 8 of the table is a variable length array of type byte, with a maximum stored array length not to exceed 1800 array elements (bytes in this case). The data for the variable length arrays in a table is not stored in the actual data records; it is stored in a special data area, the heap\index{heap}, following the last fixed size data record. What is stored in the data record is an {\em array descriptor}. This consists of two 32-bit integer values: the number of elements (array length) of the stored array, followed by the zero-indexed byte offset of the first element of the array, measured from the start of the heap area. Storage for the array is contiguous. The array descriptor for field $N$ as it would appear embedded in a data record is illustrated symbolically below: \begin{center} $\ldots$ [field $N$--1] [(nelem,offset)] [field $N$+1] $\ldots$ \end{center} If the stored array length is zero there is no array data, and the offset\index{offset} value is undefined (it should be set to zero). The storage referenced by an array descriptor must lie entirely within the heap area; negative offsets are not permitted. A binary table containing variable length arrays consists of three principal segments, as follows: %\[ [table\_header] [record\_storage\_area] [heap\_area] \] \begin{center} [table\_header] [record\_storage\_area] [heap\_area] \end{center} The table header consists of one or more 2880-byte {\em FITS\/} logical records with the last record indicated by the\index{END} keyword {\tt END} somewhere in the record. The record storage area begins with the next 2880-byte logical record following the last header record and is $\mbox{\tt NAXIS1} \times \mbox{\tt NAXIS2}$ bytes in length. The\index{NAXIS1} zero\index{NAXIS2} indexed byte offset of the heap measured from the start of the record storage area is given by the {\tt THEAP} keyword\index{THEAP} in the header. If this keyword is missing the heap is assumed to begin with the byte immediately following the last data record, otherwise there may be a gap between the last stored record and the start of the heap. If there is no gap the value of the heap offset is $\mbox{\tt NAXIS1}\times\mbox{\tt NAXIS2}$. The total length in bytes of the heap area following the last stored record (gap plus heap) is given by the {\tt PCOUNT} keyword\index{PCOUNT} in the table header. For example, suppose we have a table containing 5 rows each 168 byte records, with a heap area 2880 bytes long, beginning at an offset of 2880, thereby aligning the record storage and heap areas on {\em FITS\/} record boundaries (this alignment is not necessarily recommended but is useful for our example). The data portion of the table consists of 2 2880-byte {\em FITS\/} records, 840 bytes of which are used by the 5 table records, hence {\tt PCOUNT} is $2\times 2880-840$, or 4920 bytes; this is expressed in the table header as: \begin{verbatim} NAXIS1 = 168 / Width of table row in bytes NAXIS2 = 5 / Number of rows in table PCOUNT = 4920 / Random parameter count ... THEAP = 2880 / Byte offset of heap area \end{verbatim} \vskip 1em The values\index{TSCALn} of {\tt TSCALn} and {\tt TZEROn} for\index{TZEROn} variable length array column entries are to be applied to the values in the data array in the heap area, not the values of the array descriptor. These keywords can be used to scale data values in either static or variable length arrays. While the above description is sufficient to define the required features of the variable length array implementation, some hints regarding usage of the variable length array facility may also be useful. Programs which read binary tables should take care to not assume more about the physical layout of the table than is required by the specification. For example, there are no requirements on the alignment of data within the heap. If efficient runtime access is a concern one may want to design the table so that data arrays are aligned to the size of an array element. In another case one might want to minimize storage and forgo any efforts at alignment (by careful design it is often possible to achieve both goals). Variable array data may be stored in the heap in any order, i.e., the data for record $N$+1 is not necessarily stored at a larger offset than that for record $N$. There may be gaps in the heap where no data is stored. Pointer aliasing is permitted, i.e., the array descriptors for two or more arrays may point to the same storage location (this could be used to save storage if two or more arrays are identical). Byte arrays are a special case because they can be used to store a ``typeless'' data sequence. Since {\em FITS\/} is a machine-independent storage format, some form of machine-specific data conversion (byte swapping, floating point format conversion) is implied when accessing stored data with types such as integer and floating, but byte arrays are copied to and from external storage without any form of conversion. An important feature of variable length arrays is that it is possible that the stored array length may be zero. This makes it possible to have a column of the table for which, typically, no data is present in each stored record. When data is present the stored array can be as large as necessary. This can be useful when storing complex objects as records in a table. Accessing a binary table stored on a random access storage medium is straightforward. Since the data records in the main table are fixed in size they may be randomly accessed given the record number, by computing the offset. Once the record has been read in, any variable length array data may be directly accessed using the element count and offset given by the array descriptor stored in the data record. Reading a binary table stored on a sequential access storage medium requires that a table of array descriptors\index{array descriptor} be built up as the main table records are read in. Once all the table records have been read, the array descriptors are sorted by the offset of the array data in the heap\index{heap}. As the heap data is read, arrays are extracted sequentially from the heap and stored in the affected records using the back pointers to the record and field from the table of array descriptors. Since array aliasing is permitted, it may be necessary to store a given array in more than one field or record. Variable length arrays\index{variable length array} are more complicated than\index{array, variable length} regular static arrays and imply an extra data access per array to fetch all the data for a record. For this reason, it is recommended that regular static arrays be used instead of variable length arrays unless efficiency or other considerations require the use of a variable array. \vskip 1em This facility is still undergoing trials and is not part of the basic binary table definition. %\vfil\eject %\appendix B of BINTABLE paper \section{``Multidimensional Array'' Convention} \label{s:app_dim} It is anticipated that binary tables will need to contain data structures more complex that those describable by the basic notation. Examples of these are\index{array, multidimensional} multidimensional arrays and nonrectangular data structures. Suitable conventions may be defined to pass these structures using some combination of keyword/value pairs and table entries to pass the parameters of these structures. One case, multidimensional arrays, is so common that it is prudent to describe a simple convention. The ``Multidimensional array'' convention consists of the following: any column with a dimensionality of 2 or larger will have an associated character\index{TDIMn} keyword {\tt TDIMn ='($l$,$m$,$n$\ldots)'} where $l$, $m$, $n$,\ldots are the dimensions of the array. The data is ordered such that the array index of the first dimension given ($l$) is the most rapidly varying and that of the last dimension given is the least rapidly varying. The size implied by the {\tt TDIMn} keyword will equal the element count specified in the {\tt TFORMn} keyword. The adherence to this convention will be indicated by the presence of a {\tt TDIMn} keyword in the form described above. A character string\index{character string} is represented in a binary table by a one-dimensional character array, as described under ``Character'' in the list of datatypes in \S\ref{s:MbinT} (``Main Data Table ''). For example, a Fortran~77 {\tt CHARACTER*20} variable could be represented in a binary table as a character array declared as {\tt TFORMn = } \verb*/'20A '/. Arrays of character strings, i.e., multidimensional character arrays, may be represented using the {\tt TDIMn} notation. For example, if {\tt TFORMn = } \verb*/'60A '/ and \verb/TDIMn = '(5,4,3)'/, then the entry consists of a $4\times 3$ array of strings of 5 characters each. (Variable length character strings are allowed by the convention described in Appendix~\ref{s:app_char}. One dimensional arrays of strings should use the convention in Appendix~\ref{s:app_char} rather than the ``Multidimensional Array'' convention.) \vskip 1em This convention is optional and will not preclude other conventions. This convention is not part of the binary table definition. %\vfil\eject %\appendix C of BINTABLE paper \section{``Substring Array'' Convention} \label{s:app_char} This\index{substring arrays} appendix\index{array, substring} describes a layered convention for specifying that a character array field ({\tt TFORMn = 'rA '}) consists of\index{TFORMn} an array of either fixed-length or variable-length substrings within the field. This convention utilizes the option described in the basic binary table definition to have additional characters following the datatype code character in the {\tt TFORMn} value field. The full form for the value of {\tt TFORMn} within this convention is % \[ \mbox{{\tt '}}r\mbox{{\tt A:SSTR}}w/nnn\mbox{{\tt '}} \] \begin{center} \tt 'rA:SSTRw/nnn' \end{center} and a simpler form that may be used for fixed-length substrings only is % \[ \mbox{{\tt '}}r\mbox{{\tt A}}w\mbox{{\tt '}} \] \begin{center} \tt 'rAw' \end{center} where \begin{verse} {\tt r} is an integer giving the total length including any delimiters (in characters) of the field, \\ {\tt A} signifies that this is a character array field, \\ {\tt :} indicates that a convention indicator follows,\\ {\tt SSTR} indicates the use of the ``Substring Array'' convention,\\ {\tt w} is an integer $\leq$ {\tt r} giving the (maximum) number of characters in an individual substring (not including the delimiter), and \\ {\tt /nnn} if present, indicates that the substrings have variable-length and are delimited by an ASCII text character with decimal value {\tt nnn} in the range 032 to 126 decimal, inclusive. This character is referred to as the delimiter character. The delimiter character for the last substring will be an ASCII NUL. \end{verse} \noindent To illustrate this usage: \begin{verse} \verb+'40A:SSTR8'+ signifies that the field is 40 characters wide and consists of an array of 5 8-character fixed-length substrings. This could also be expressed using the simpler form as \verb+'40A8'+ \verb+'100A:SSTR8/032'+ signifies that the field is 100 characters wide and consists of an array of variable-length substrings where each substring has a maximum length of 8 characters and, except for the last substring, is terminated by an ASCII SPACE (decimal 32) character. \end{verse} Note that simple {\em FITS\/} readers that do not understand this substring convention can ignore the {\tt TFORM} characters following the {\tt rA} and can interpret the field simply as a single long string as described in the basic binary table definition. The following rules complete the full definition of this convention: \begin{enumerate} \item In the case of fixed-length substrings, if {\tt r} is not an integer multiple of {\tt w} then the remaining odd characters are undefined and should be ignored. For example if {\tt TFORMn ='14A:SSTR3'}, then the field contains 4 3-character substrings followed by 2 undefined characters. \item Fixed-length substrings must always be padded with blanks if they do not otherwise fill the fixed-length subfield. The ASCII NUL character must not be used to terminate a fixed-length substring field. \item The character following the delimiter character in variable-length substrings is the first character of the following substring. %\item %If an array of variable-length substrings does not completely %fill the binary table field, then the last substring must be %terminated with an ASCII NUL character (value 000), rather than the %substring %delimiter character. \item The method of signifying an undefined or null substring within a fixed-length substring array is not explicitly defined by this convention (note that there is no ambiguity if the variable-length format is used). In most cases it is recommended that a completely blank substring or other adopted convention (e.g. \verb+'INDEF'+) be used for this purpose although general readers are not expected to recognize these as undefined strings. In cases where it is necessary to make a distinction between a blank, or other, substring and an undefined substring use of variable-length substrings is recommended. \item Undefined or null variable-length substrings are designated by a zero-length substring, i.e., by a delimiter character (or an ASCII NUL if it is the last substring in the table field) in the first position of the substring. An ASCII NUL in the first character of the table field indicates that the field contains no defined variable-length substrings. \item The ``Multidimensional Array''convention described in Appendix~\ref{s:app_dim} of this paper provides a syntax using the {\tt TDIMn} keyword\index{TDIMn} for describing multidimensional arrays of any datatype which can also be used to represent arrays of fixed-length substrings. For a one dimensional array of substrings (a two dimensional array of characters) the ``Substring Array'' convention is preferred over the ``Multidimensional Array'' convention. Multidimensional arrays of (fixed length) strings require the use of the ``Multidimensional Array'' convention. \item This substring convention may be used in conjunction with the ``Variable Length Array'' facility described in Appendix~\ref{s:app_varlen} of this paper. In this case, the two possible full forms for the value of the {\tt TFORM} keyword are %\[ \mbox{{\tt TFORMn ='}}r\mbox{{\tt %PA}(}maxelem\mbox{){\tt:SSTR}}w {\tt /}nnn{\tt '} \] \begin{center} \tt TFORMn = 'rPA(${\tt e}_{\rm max}$):SSTRw/nnn' \end{center} and %\[ \mbox{{\tt TFORMn ='}r}\mbox{{\tt PA}(}maxelem\mbox{){\tt %:SSTR}}w\mbox{{\tt '}} \] \begin{center} \tt TFORMn = 'rPA(${\tt e}_{\rm max}$):SSTRw' \end{center} for the variable and fixed cases, respectively. \end{enumerate} \vskip 1em This convention is optional and will not preclude other conventions. This convention is not part of the binary table definition. \chapter{Implementation on Physical Media} \label{s:phy} (This Appendix is not part of the NOST {\em FITS\/} Standard, but is included as a guide to recommended practices.) \section{Physical Properties of Media} The arrangement of digital bits and other physical properties of any medium should be in conformance with the relevant national and/or international standard for that medium. \section{Labeling} \subsection{Tape} Tapes may be either ANSI standard labeled or unlabeled. Unlabeled tapes are preferred.\index{ANSI, tapes} \subsection{Other Media} Conventions regarding labels for physical media containing {\em FITS\/} files have not been established for other media. \section{{\em\bf FITS\/} File Boundaries} \subsection{Magnetic Reel Tape} Individual {\em FITS\/} files are terminated by a tape-mark. \subsection{Other Media} For fixed block length sequential media where the physical block size cannot be equal to or an integral multiple of the standard {\em FITS\/} logical record length, a logical record of fewer than 23040 bits (2880 8-bit bytes) immediately following the end of the\index{primary header} primary header, data, or an extension\index{extension} should be treated as an end-of-file. Otherwise, individual {\em FITS\/} files should be terminated by a delimiter appropriate to the medium, analogous to the tape end-of-file mark. If more than one {\em FITS\/} file appears on a physical structure, the appropriate end-of-file indicator should immediately precede the start of the primary headers of all files after the first. \section{Multiple Physical Volumes} Storage of a single {\em FITS\/} file on more than one unlabeled tape or on multiple units of any other medium is not universally supported in {\em FITS}\@. One possible way to handle multivolume unlabeled tape was suggested in [1]. A convention for logically grouping on-line {\em FITS\/} HDUs that may physically be located in different sites has been proposed in [16]. \chapter{Suggested Time Scale Specification} \label{s:tsys} [Not part of formal {\tt DATExxxx} agreement] \begin{enumerate} \item Use of the keyword {\tt TIMESYS} is suggested as an implementation of the time scale specification. It sets the principal time system for time-related keywords and data in the HDU (i.e., it does not preclude the addition of keywords or data columns that provide information for transformations to other time scales, such as sidereal times or barycenter corrections). Each HDU shall contain not more than one {\tt TIMESYS} keyword. Initially, officially allowed values are: \begin{description} \item[{\tt UTC}] Coordinated Universal Time; defined since 1972. \item[{\tt UT}] Universal Time, equal to Greenwich Mean Time (GMT) since 1925; the UTC equivalent before 1972; see: Explanatory Supplement, p.\ 76. \item[{\tt TAI}] International Atomic Time; ``UTC without the leap seconds''; 31 s ahead of UTC on 1997-07-01. \item[{\tt AT}] International Atomic Time; deprecated synonym of TAI. \item[{\tt ET}] Ephemeris Time, the predecessor of TT; valid until 1984. \item[{\tt TT}] Terrestrial Time, the IAU standard time scale since 1984; continuous with ET and synchronous with (but 32.184 s ahead of) TAI. \item[{\tt TDT}] Terrestrial Dynamical Time; = TT. \item[{\tt TDB}] Barycentric Dynamical Time. \item[{\tt TCG}] Geocentric Coordinate Time; runs ahead of TT since 1977-01-01 at a rate of approximately 22 ms/year. \item[{\tt TCB}] Barycentric Coordinate Time; runs ahead of TDB since 1977-01-01 at a rate of approximately 0.5 s/year. \end{description} For reference, see: Explanatory Supplement to the Astronomical Almanac, P. K. Seidelmann, ed., University Science Books, 1992, ISBN 0-935702-68-7, or \begin{center} {\tt http://tycho.usno.navy.mil/systime.html} \end{center} Use of Global Positioning Satellite (GPS) time (19 s behind TAI) is deprecated. \item By default, times will be deemed to be as measured at the detector (or in practical cases, at the observatory) for times that run synchronously with TAI (i.e., TAI, UTC, and TT). In the case of coordinate times (such as TCG and TCB) and TDB which are tied to an unambiguous coordinate origin, the default meaning of time values will be: time as if the observation had taken place at the origin of the coordinate time system. These defaults follow common practice; a future convention on time scale issues in {\em FITS\/} files may allow other combinations but shall preserve this default behavior. The rationale is that raw observational data are most likely to be tagged by a clock that is synchronized with TAI, while a transformation to coordinate times or TDB is usually accompanied by a spatial transformation, as well. This implies that path length differences have been corrected for. Note that the difference TDB $-$ UTC, in that case, is approximately sinusoidal, with period one year and amplitude up to 500 s, depending on source position. Also, note that when the location is not unambiguous (such as in the case of an interferometer) precise specification of the location is strongly encouraged in, for instance, geocentric Cartesian coordinates. \item Note that {\tt TT} is the IAU preferred standard. It may be considered equivalent to {\tt TDT} and {\tt ET}, though {\tt ET} should not be used for data taken after 1984. For reference, see: Explanatory Supplement, pp. 40-48. \item If the {\tt TIMESYS} keyword is absent or has an unrecognized value, the value {\tt UTC} will be assumed for dates since 1972, and {\tt UT} for pre-1972 data. \item Examples. The three legal representations of the date of October 14, 1996, might be written as: \begin{footnotesize} \begin{verbatim} DATE-OBS= '14/10/96' / Original format, means 1996 Oct 14. TIMESYS = 'UTC ' / Explicit time scale specification: UTC. DATE-OBS= '1996-10-14' / Date of start of observation in UTC. DATE-OBS= '1996-10-14' / Date of start of observation, also in UTC. TIMESYS = 'TT ' / Explicit time scale specification: TT. DATE-OBS= '1996-10-14T10:14:36.123' / Date and time of start of obs. in TT. \end{verbatim} \end{footnotesize} \item The convention suggested in this Appendix is part of the mission-specific {\em FITS\/} conventions adopted for, and used in, the RXTE archive, building on existing High Energy Astrophysics {\em FITS\/} conventions. See: \begin{center} {\tt http://heasarc.gsfc.nasa.gov/docs/xte/abc/time\_tutorial.html} {\tt http://heasarc.gsfc.nasa.gov/docs/xte/abc/time.html} \end{center} The VLBA project has adopted a convention where the keyword {\tt TIMSYS}, rather than {\tt TIMESYS}, is used, currently allowing the values {\tt UTC} and {\tt IAT}. See p.~9 and p.~16 of: \begin{center} {\tt http://www.cv.nrao.edu/fits/documents/drafts/vlba\_format.ps} \end{center} \end{enumerate} \chapter{Differences from IAU-endorsed Publications} \label{s:sdif} (This Appendix is not part of the NOST {\em FITS\/} Standard but is included for informational purposes only.) Note: In\index{IAU} this discussion, the term {\em the FITS papers} refers to [1], [2], [4], [5], [9], and [10] collectively, the term {\em Floating Point Agreement (FPA)} refers\index{floating point FITS agreement} to [8], the term\index{blocking} {\em Blocking Agreement\/} refers to [11]; and the term {\em DATExxxx Agreement\/} refers to the redefinition of the value format for date keywords approved by the IAUFWG in 1997. \begin{enumerate} \item \S\ref{s:def} --- Definitions, Acronyms, and Symbols \begin{description} \item[Array value] --- This\index{array value} precise definition is not used in the original {\em FITS\/} papers. \item[ASCII text] --- This\index{ASCII text} permissible subset of the ASCII character set, used in many contexts, is not precisely defined in the {\em FITS\/} papers. \item[Basic FITS] --- This definition\index{Basic FITS} includes the possibility of floating point data arrays, while the terminology in the {\em FITS\/} papers refers to {\em FITS\/} as described in [1], where only integer arrays were possible. \item[Conforming Extension] --- This terminology is not used in the\index{extension, conforming} {\em FITS\/} papers.\index{conforming extension} \item[Deprecate] --- The concept of deprecation does\index{deprecate} not appear in the {\em FITS\/} papers. \item[FITS structure] --- This\index{FITS structure} terminology is not used in the {\em FITS\/} papers in the precise way that it is in this standard. \item[Fraction] --- This\index{fraction} terminology and the distinction between {\em fraction\/} and {\em mantissa\/} do\index{mantissa} not appear in the Floating Point Agreement. \item[Header and Data Unit] --- This terminology is not used in the {\em FITS\/} papers. \item[Indexed keyword] --- This terminology is not\index{keyword, indexed} used in the original {\em FITS\/} papers. \item[Physical value] --- This\index{physical value} precise definition is not used in the original {\em FITS\/} papers. \item[Reference point] --- This term replaces the {\em reference pixel} of the\index{reference point} {\em FITS\/} papers. The new terminology is consistent with the fact that the array need not represent a digital image and that the reference point (or {\em pixel}) need not lie within the array. \item[Repeat count] ---This terminology is not used in the {\em FITS} papers. \item[Reserved keyword] --- The {\em FITS\/} papers\index{keyword, reserved} describe optional keywords but do not say explicitly that they are reserved. \item[Standard Extension] --- This\index{standard extension} precise\index{extension, standard} definition is new. The term {\em standard extension} is used in some contexts in the {\em FITS\/} papers to refer to what this standard defines as a {\em standard extension} and in others to refer to what this standard defines\index{conforming extension} as\index{extension, conforming} {\em conforming extension}. \end{description} \item \S\ref{s:pdata} Primary Data Array\\ Fill\index{fill} format --- This\index{primary data array} specification is new. The {\em FITS\/} papers and the FPA do not precisely specify the format\index{fill} of data fill for the primary data array. \item \S\ref{s:idy} Identity (of conforming extensions)\\ The {\em FITS\/} papers specify that creators of new\index{conforming extension} extension types\index{extension, conforming} should check with the {\em FITS\/} standards committee. This standard identifies the committee specifically, introduces the role of the {\em FITS\/} Support Office\index{FITS Support Office} as its\index{extension registration} agent, and mandates registration. \item \S\ref{s:PhysBlk} Physical Blocking \\ This material is based entirely on the\index{blocking} Blocking Agreement. Material in the early {\em FITS\/} papers [1,4] specifying the expression of {\em FITS\/} on specific physical media is not part of this standard. \item \S\ref{s:BitDev} Bitstream Devices\\ The Blocking Agreement specifies that this rule applies to {\em FITS\/} files written to logical file systems. This standard applies the rule to all bitstream devices, not only logical file systems. \item \S\ref{s:FixBlk} Fixed Block\\ The Blocking Agreement specifies that this rule applies to {\em FITS\/} files written to optical disks, (accessed as a sequential set of records), QIC format 1/4-inch cartridge tapes and Local Area networks. This standard extends the rule to other fixed block length sequential media. \item \S\ref{s:VarBlk} Variable Block\\ The Blocking Agreement specifies that this rule applies to {\em FITS\/} files written to 1/2-inch 9 track tapes, DDS/DAT 4mm cartridge tapes and 8mm cartridge tape (Exabyte). This standard extends the rule to all variable block length sequential media and eliminates references to specific products. \item \S\ref{s:keyw} Keyword (as header component)\\ The specification of permissible keyword characters is new. The {\em FITS\/} papers do not precisely define the permissible characters for keywords. \item \S\ref{s:ValInd} Value Indicator (bytes 9--10)\\ The {\em FITS\/} papers do not specifically address the permissibility of null values. This standard states explicitly that they are permitted. \item \S\ref{s:valcomm} Value/Comment (bytes 11--80) \\ In the {\em FITS\/} papers, the slash between the value and comment is optional. This standard requires the slash, consistent with the prescription of FORTRAN-77 list-directed input. \item \S\ref{s:valC} Value, including its subsections \\ The {\em FITS\/} papers specify that the value field is to be written following the rules of ANSI FORTRAN-77\index{FORTRAN-77, list-directed input} list-directed\index{list-directed input} input, with some restrictions. This standard explicitly describes the format of the value field. The {\em FITS} papers permit the value field to contain an array of values. This standard specifies that there shall be only one value in the value field. The {\em FITS} papers require the fixed format for the most essential parameters. This standard identifies those parameters with the values of the mandatory\index{keyword, mandatory} keywords. \item \S\ref{s:ffch} Character String \\ The standard explicitly describes how single quotes are to be coded into keyword values, a rule only implied by the FORTRAN-77 list-directed\index{list-directed read} read\index{format, fixed} requirements of the {\em FITS\/} papers. The standard states that in general, character-valued keywords can have lengths up to the maximum 68 character length. \item \S\ref{s:ffi} Integer \\ The standard explicitly notes that the fixed format for complex integers\index{format, fixed} \index{integer, complex} does not\index{complex data representation} conform to the rules for\index{FORTRAN-77, list-directed read} ANSI FORTRAN list-directed read.\index{list-directed read} \item \S\ref{s:ffrfp} Real Floating Point Number \\ The standard explicitly notes that the full precision of 64-bit values cannot be expressed as a single value using the fixed\index{floating point, 64 bit} format. \item \S\ref{s:ffci} Complex Integer Number \\ The standard does not support the fixed format for complex integers defined in the {\em FITS} papers but is consistent with FORTRAN-77 list-directed read\index{FORTRAN-77, list-directed read} as required in the {\em FITS} papers for free format. Because the fixed format of the {\em FITS} papers did not conform to the rules for FORTRAN-77 list-directed I/O, consistency with both was impossible. There are no known {\em FITS} files that use the fixed format for complex integers that was defined in the {\em FITS\/} papers. \item \S\ref{s:ffcfp} Complex Floating Point Number \\ The standard does not support the fixed format for complex floating point numbers \index{floating point, complex} defined in the {\em FITS} papers but is consistent with FORTRAN-77 list-directed read\index{FORTRAN-77, list-directed read} as required in the {\em FITS\/} papers for free format. Because the fixed format of the {\em FITS\/} papers did not conform to the rules for FORTRAN-77 list-directed I/O, consistency with both was impossible. There are no known {\em FITS\/} files that use the fixed format for complex floating point numbers that was defined in the {\em FITS\/} papers. \item \S\ref{s:Units} Units\\ The {\em FITS\/} papers recommend the use of SI units\index{units} and identify certain other units standard in astronomy. This standard codifies the recommendation and makes it more specific by referring to the IAU Style\index{IAU Style Manual} Manual [7], while explicitly recommending degrees for angular measure and requiring degrees for celestial coordinates. \item \S\ref{s:pman} Principal (mandatory keywords) \begin{enumerate} \item {\tt SIMPLE} keyword --- The explicit prohibition against the appearance of the {\tt SIMPLE} keyword in extensions does not appear in the {\em FITS\/} papers. \item {\tt NAXIS} keyword --- The\index{keyword, required} requirement that the {\tt NAXIS} keyword\index{NAXIS} may not be negative is not explicitly specified in the {\em FITS\/} papers. \item {\tt NAXISn} keyword --- The requirement that the {\tt NAXISn} keyword may not be negative\index{NAXISn} is not explicitly specified in the {\em FITS\/} papers. \end{enumerate} \item \S\ref{s:conf} Conforming Extensions \begin{enumerate} \item {$N_{\rm bits}$} --- The requirement\index{conforming extension} that\index{extension, conforming} $N_{\rm bits}$ may not be negative\index{$N_{\rm bits}$} is not explicitly specified in the {\em FITS\/} papers. \item {\tt XTENSION} keyword --- That this keyword\index{XTENSION} may not appear in the primary header is only implied by the {\em FITS\/} papers; the prohibition is explicit in this standard. The {\em FITS\/} papers name a {\em FITS\/} standards committee as the keeper of the list of accepted extension\index{extension} type names. This standard specifically identifies the committee and introduces the role of the {\em FITS\/} Support Office\index{FITS Support Office} as its agent. \end{enumerate} \item \S\ref{s:resk} Other Reserved Keywords\\ That\index{keyword, reserved} the optional keywords defined in the {\em FITS\/} papers are to be reserved for both the primary HDUs and all extensions with the meanings and usage defined in those papers, as in the standard, is not explicitly stated in all of them, although some keywords are explicitly reserved in the papers describing the image and binary table extensions. \pagebreak \item \S\ref{s:dhist} Keywords Describing the History or Physical Construction of the HDU \begin{enumerate} \item {\tt DATE} Keyword --- The notation for four-digit year number is {\tt YYYY} rather than the {\tt CCYY} of the ``DATExxxx Agreement''. The recommendation for use of Universal Time in the superseded format with a two-digit year is not in the {\em FITS\/} papers. \item {\tt BLOCKED} keyword --- The {\em FITS\/} papers require\index{BLOCKED} the {\tt BLOCKED} keyword to appear in the first record of the primary header\index{primary header} even though it cannot when the value of {\tt NAXIS} exceeds\index{NAXIS} the values described in the text. They do not address this contradiction. This standard deprecates the {\tt BLOCKED} keyword. \end{enumerate} \item \S\ref{s:kobs} Keywords Describing Observations \begin{enumerate} \item {\tt DATE-OBS} Keyword --- The recommendation\index{DATE-OBS} for use of Universal\index{Universal Time} Time in the superseded format with a two-digit year is not in the {\em FITS\/} papers. \item {\tt EQUINOX} and {\tt EPOCH} keywords --- This standard\index{EQUINOX} replaces the\index{EPOCH} {\tt EPOCH} keyword with the more appropriately named {\tt EQUINOX} keyword and deprecates\index{deprecate} the {\tt EPOCH} name. \end{enumerate} \item \S\ref{s:comk} Commentary keywords\\ Keyword field is blank --- Reference [1] contains the text ``{\tt BLANK}'' to represent a blank keyword field. The standard clarifies the intention.\index{BLANK} \item \S\ref{s:array} Array keywords \begin{enumerate} \item {\tt BUNIT} Keyword --- The {\em FITS\/} papers recommend the use of SI\index{BUNIT} units, degrees as the appropriate unit for\index{angle} angles, and identify\index{units} other units standard in astronomy. This standard specically applies the recommendations of \S\ref{s:Units} to the {\tt BUNIT} keyword. \item {\tt CTYPEn}, {\tt CRVALn}, {\tt CDELTn}, and {\tt CROTAn} Keywords\index{CTYPEn} --- This\index{CRVALn} standard\index{CDELTn} extends\index{CROTAn} the recommendations on units\index{units} to coordinate axes, explicitly requiring decimal degrees for coordinates. \item {\tt CRPIXn} Keywords --- This standard explicitly notes the ambiguity\index{CRPIXn} in the location of the index number relative to an image pixel. \item {\tt CDELTn} Keywords --- The definition in the standard differs from that in the {\em FITS\/} papers in that it provides for the case where\index{CDELTn} the spacing between index points varies over the grid. For the case of constant spacing, it is identical to the specification in the {\em FITS\/} papers. \item {\tt DATAMAX} and {\tt DATAMIN} Keywords --- The standard clarifies that the value refers to the physical value\index{physical value} represented by the\index{DATAMIN} array\index{DATAMAX}, after any\index{scaling, data} scaling, not the array value\index{array value} before scaling. The standard also notes that special values\index{IEEE special values} are not to be considered when determining the values of {\tt DATAMAX} and {\tt DATAMIN}, an issue not specifically addressed by the {\em FITS\/} papers or the FPA. \end{enumerate} \item \S\ref{s:Rgrp} Random Groups\index{random groups} Structure\\ The standard deprecates\index{deprecate} the Random Groups structure. \item \S\ref{s:rgrrk} Reserved Keywords (random groups)\\ That\index{keyword, reserved} the optional keywords defined in the {\em FITS\/} papers are to be reserved with the meanings and usage defined in those papers, as in the standard, is not explicitly stated in them. \item \S\ref{s:pscl} {\tt PSCALn} Keywords --- The default value is explicitly specified in the standard, whereas in the {\em FITS\/} papers it is assumed by analogy\index{PSCALn} with the\index{BSCALE} {\tt BSCALE} keyword. \item \S\ref{s:pzer} {\tt PZEROn} Keywords --- The default value is explicitly specified in the standard, whereas in the {\em FITS\/} papers it is assumed by analogy\index{PZEROn} with the\index{BZERO} {\tt BZERO} keyword. \item \S\ref{s:ATabl} ASCII Table Extension\\ The name {\em ASCII table} is given to the\index{ASCII table} ``tables'' extension discussed\index{TABLE extension} in the {\em FITS\/} papers to distinguish it from the binary table extension. \item \S\ref{s:atmk} Mandatory Keywords (ASCII table) \begin{enumerate} \item {\tt NAXIS1} keyword --- The\index{keyword, required} requirement that the {\tt NAXIS1} keyword may not be negative in an ASCII table header is not explicitly specified in\index{NAXIS1} the {\em FITS\/} papers. \item {\tt NAXIS2} keyword --- The requirement that the {\tt NAXIS2} keyword may not be negative in an ASCII table header is not explicitly specified in\index{NAXIS2} the {\em FITS\/} papers. \item {\tt TFIELDS} keyword --- The requirement that the {\tt TFIELDS} keyword may not be negative is not explicitly specified in\index{TFIELDS} the {\em FITS\/} papers. \item {\tt TFORMn} keyword --- The requirement that format codes must be specified in upper case is implied but not explicitly specified in\index{TFORMn} the {\em FITS\/} papers. \end{enumerate} \item \S\ref{s:atork} Other Reserved Keywords (ASCII table)\\ That\index{keyword, reserved} the optional keywords defined in the {\em FITS\/} papers are to be reserved with the meanings and usage defined in those papers, as in the standard, is not explicitly stated in them. \begin{enumerate} \item {\tt TUNITn} Keywords --- The {\em FITS\/} papers\index{TUNITn} do not explicitly recommend the use of any particular units\index{units} for this keyword, although the reference to the {\tt BUNIT} keyword may be considered an implicit extension of\index{BUNIT} the recommendation for that keyword. This standard makes the recommendation more specific for the {\tt TUNITn} keyword by requiring conformance to the prescriptions in \S\ref{s:Units}. \item {\tt TSCALn} Keywords --- The prohibition against use in {\tt A}-format fields is stronger than the statement in the {\em FITS\/} papers that the keyword\index{TSCALn} ``is not relevant''. \item {\tt TZEROn} Keywords --- The prohibition against use in {\tt A}-format fields is stronger than the statement in the {\em FITS\/} papers that the keyword\index{TZEROn} ``is not relevant''. \end{enumerate} \item \S\ref{s:btork} Other Reserved Keywords (Binary Table) \\ The {\tt EXTNAME}, {\tt EXTVER}, {\tt EXTLEVEL}, {\tt AUTHOR}, and {\tt REFERENC} keywords explicitly reserved for binary tables in the defining paper are reserved in the standard under the general prescription of \S\ref{s:resk}. \begin{enumerate} \item {\tt TUNITn} Keywords --- The {\em FITS\/} papers\index{TUNITn} do not explicitly recommend the use of any particular units\index{units} for this keyword. This standard makes the recommendation more specific for the {\tt TUNITn} keyword by requiring conformance to the prescriptions of \S\ref{s:Units}. \item {\tt TDISPn} Keywords --- The version \index{TDISPn} of the {\tt BINTABLE} paper upon which the {\em FITS\/} committees voted stated incorrectly that the values used to display bit and byte arrays should be considered {\em signed}. This standard follows the text in the published {\tt BINTABLE} paper, which specifies that these values should be {\em unsigned}. The {\tt BINTABLE} paper does not specify how a {\tt TDISPn} value for a field of type {\tt P} is interpreted; this standard explicitly mandates no interpretation but allows conventions to provide interpretations. The requirement that format codes must be specified in upper case is implied but not explicitly specified in the {\tt BINTABLE} paper. \item {\tt THEAP} Keywords --- The {\em FITS\/} papers\index{THEAP} state only that the keyword is reserved for use in the convention described in in Appendix \ref{s:app_varlen}. This standard makes the more specific statement that this keyword is used to provide the separation, in bytes, between the start of the main data table and the start of a supplemental data area called the\index{heap} heap and identifies the default value. \item {\tt TDIMn} Keywords --- The {\em FITS\/} papers state\index{TDIMn} only that the keyword is reserved for use in the convention described in Appendix \ref{s:app_dim}. This standard makes the more specific statement that the contents of the value field contain a character string describing how to interpret the contents of a field as a multidimensional array. \end{enumerate} \item \S\ref{s:BinDD} Data Display \\ The {\tt BINTABLE} paper suggests that the format for display suggested by the {\tt TDISPn} should be understood as a Fortran-90 format or, where Fortran-90 is unavailable, a FORTRAN-77 format. This standard explicitly describes the formats. The statement in the standard concerning differences between {\tt E} and {\tt D} format codes, which notes that the latter implies greater precision in the internal datum, does not appear in the {\tt BINTABLE} paper. \item \S\ref{s:Restrict} Restrictions on Changes\\ The {\em FITS\/} papers do not provide for the concept of deprecation. \item Appendix \ref{s:phy} Implementation on Physical Media\\ Material in the {\em FITS\/} papers specifying the expression of {\em FITS\/} on specific physical media is not part of this standard; what is provided in the appendix is purely as a guide to recommended practices. \end{enumerate} \chapter{Summary of Keywords} \label{s:summ} (This Appendix is not part of the NOST {\em FITS\/} Standard, but is included for convenient reference). \small \begin{table}[htpb] \begin{center} \begin{tabular}{llllll} \\ \multicolumn{1}{c}{Principal} & \multicolumn{1}{c}{Conforming} & \multicolumn{1}{c}{ASCII Table} & \multicolumn{1}{c}{Image} & \multicolumn{1}{c}{Binary Table}&\multicolumn{1}{c}{Random Groups} \\ \multicolumn{1}{c}{HDU} & \multicolumn{1}{c}{Extension} & \multicolumn{1}{c}{Extension} & \multicolumn{1}{c}{Extension} & \multicolumn{1}{c}{Extension}& \multicolumn{1}{c}{Records}\\ \hline {\tt SIMPLE} & {\tt XTENSION} & {\tt XTENSION}$^{1}$ & {\tt XTENSION}$^{2}$ & {\tt XTENSION}$^{3}$ & {\tt SIMPLE} \\ {\tt BITPIX} & {\tt BITPIX} & {\verb+BITPIX = 8+} & {\tt BITPIX} & {\verb+BITPIX = 8+} & {\tt BITPIX} \\ {\tt NAXIS} & {\tt NAXIS} & {\verb+NAXIS = 2+} & {\tt NAXIS} & {\verb+NAXIS = 2+} & {\tt NAXIS} \\ {\tt NAXISn}$^{4}$ & {\tt NAXISn}$^{4}$ & {\tt NAXIS1} & {\tt NAXISn}$^{4}$ & {\tt NAXIS1} & {\verb+NAXIS1 = 0+} \\ {\tt EXTEND}$^{5}$ & {\tt PCOUNT} & {\tt NAXIS2} & {\verb+PCOUNT = 0+} & {\tt NAXIS2} & {\tt NAXISn}$^{4}$ \\ {\tt END} & {\tt GCOUNT} & {\verb+PCOUNT = 0+} & {\verb+GCOUNT = 1+} & {\tt PCOUNT} & {\verb+GROUPS = T+} \\ & {\tt END} & {\verb+GCOUNT = 1+} & {\tt END} & {\verb+GCOUNT = 1+} & {\tt PCOUNT} \\ & & {\tt TFIELDS} & & {\tt TFIELDS} & {\tt GCOUNT} \\ & & {\tt TBCOLn}$^{6}$ & & {\tt TFORMn}$^{6}$& {\tt END} \\ & & {\tt TFORMn}$^{6}$ & & {\tt END} & \\ & & {\tt END} & & & \\ \hline \end{tabular} \end{center} $^1$ \verb+XTENSION= 'TABLE '+ for the ASCII table\index{TABLE extension} extension. \\ $^2$ \verb+XTENSION= 'IMAGE '+ for the image extension\index{image extension}. \\ $^3$ \verb+XTENSION= 'BINTABLE'+ for the binary table extension\index{binary table}\index{BINTABLE extension}.\\ $^4$ Runs from 1 through the value of {\tt NAXIS}.\\ $^5$ Required only if extensions are present.\\ $^6$ Runs from 1 through the value of {\tt TFIELDS}. \caption[Mandatory {\em FITS\/} keywords] {Mandatory {\em FITS\/} keywords for the structures described in this document.} \end{table} \normalsize \begin{table}[htpb] \begin{center} \begin{tabular}{llllll} \\ \multicolumn{1}{c}{All} & \multicolumn{1}{c}{Array$^{1}$} & \multicolumn{1}{c}{Conforming} & \multicolumn{1}{c}{ASCII Table} & \multicolumn{1}{c}{Binary Table}& \multicolumn{1}{c}{Random Groups} \\ \multicolumn{1}{c}{HDUs} &\multicolumn{1}{c}{HDUs} & \multicolumn{1}{c}{Extension} & \multicolumn{1}{c}{Extension} & \multicolumn{1}{c}{Extension} & \multicolumn{1}{c}{Records} \\ \hline {\tt DATE} & {\tt BSCALE} & {\tt EXTNAME} & {\tt TSCALn} & {\tt TSCALn} & {\tt PTYPEn} \\ {\tt ORIGIN} & {\tt BZERO} & {\tt EXTVER} & {\tt TZEROn} & {\tt TZEROn} & {\tt PSCALn} \\ {\tt BLOCKED}$^{2}$ & {\tt BUNIT} & {\tt EXTLEVEL} & {\tt TNULLn} & {\tt TNULLn} & {\tt PZEROn} \\ {\tt AUTHOR} & {\tt BLANK} & & {\tt TTYPEn} & {\tt TTYPEn} & \\ {\tt REFERENC} & {\tt CTYPEn} & & {\tt TUNITn} & {\tt TUNITn} & \\ {\tt COMMENT} & {\tt CRPIXn} & & & {\tt TDISPn} & \\ {\tt HISTORY} & {\tt CROTAn} & & & {\tt TDIMn} & \\ \verb*+ +& {\tt CRVALn} & & & {\tt THEAP} & \\ {\tt DATE-OBS} & {\tt CDELTn} & & & & \\ {\tt TELESCOP} & {\tt DATAMAX} & & & & \\ {\tt INSTRUME} & {\tt DATAMIN} & & & & \\ {\tt OBSERVER} & & & & & \\ {\tt OBJECT} & & & & & \\ {\tt EQUINOX} & & & & & \\ {\tt EPOCH}$^{2}$ & & & & & \\ \hline \end{tabular} \end{center} $^1$ Primary HDU, image extension, user-defined HDUs with same array structure. \\ $^2$ Deprecated. \caption[Reserved {\em FITS\/} keywords] {Reserved {\em FITS\/} keywords for the structures described in this document.} \end{table} \begin{table}[htpb] \begin{center} \begin{tabular}{llll} \\ \multicolumn{1}{c}{Production} & \multicolumn{1}{c}{Bibliographic} & \multicolumn{1}{c}{Commentary} & \multicolumn{1}{c}{Observation} \\ \hline {\tt DATE} & {\tt AUTHOR} & {\tt COMMENT} & {\tt DATE-OBS} \\ {\tt ORIGIN} & {\tt REFERENC} & {\tt HISTORY} & {\tt TELESCOP} \\ {\tt BLOCKED}$^{1}$& &\verb*+ + & {\tt INSTRUME} \\ & & & {\tt OBSERVER} \\ & & & {\tt OBJECT} \\ & & & {\tt EQUINOX} \\ & & & {\tt EPOCH}$^{1}$ \\ \hline \end{tabular} \end{center} $^1$ Deprecated. \caption[General Reserved {\em FITS\/} keywords] {General reserved {\em FITS\/} keywords described in this document. } \end{table} \chapter{ASCII Text} \label{s:Atxt} (This appendix is not part of the NOST {\em FITS\/} standard; the material in it is based on the ANSI standard for ASCII [14] and is included here for informational purposes.) In the following table, the first column is the decimal\index{ASCII character} and the second column the hexadecimal value for the character in the third column. The characters hexadecimal 20 to 7E (decimal 32 to 126) constitute the subset referred to in this document as ASCII text.\index{ASCII text} \begin{table}[hb] \begin{center} \begin{tabular}{|lll||lll|lll|lll|} \hline \multicolumn{3}{|c||}{ASCII Control} & \multicolumn{9}{|c|}{ASCII Text} \\ \hline \multicolumn{1}{|c}{dec} & \multicolumn{1}{c}{hex} & \multicolumn{1}{c||}{char} & \multicolumn{1}{|c}{dec} & \multicolumn{1}{c}{hex} & \multicolumn{1}{c}{char} & \multicolumn{1}{|c}{dec} & \multicolumn{1}{c}{hex} & \multicolumn{1}{c}{char} & \multicolumn{1}{|c}{dec} & \multicolumn{1}{c}{hex} & \multicolumn{1}{c|}{char} \\ \hline 0 & 00 & NUL & 32 & 20 & SP & 64 & 40 & \verb+@+ & 96 & 60 & \verb+`+ \\ 1 & 01 & SOH & 33 & 21 & \verb+!+ & 65 & 41 & A & 97 & 61 & a \\ 2 & 02 & STX & 34 & 22 & \verb+"+ & 66 & 42 & B & 98 & 62 & b \\ 3 & 03 & ETX & 35 & 23 & \verb+#+ & 67 & 43 & C & 99 & 63 & c \\ 4 & 04 & EOT & 36 & 24 & \verb+$+ & 68 & 44 & D &100 & 64 & d \\ 5 & 05 & ENQ & 37 & 25 & \verb+%+ & 69 & 45 & E &101 & 65 & e \\ 6 & 06 & ACK & 38 & 26 & \verb+&+ & 70 & 46 & F &102 & 66 & f \\ 7 & 07 & BEL & 39 & 27 & \verb+'+ & 71 & 47 & G &103 & 67 & g \\ 8 & 08 & BS & 40 & 28 & \verb+(+ & 72 & 48 & H &104 & 68 & h \\ 9 & 09 & HT & 41 & 29 & \verb+)+ & 73 & 49 & I &105 & 69 & i \\ 10 & 0A & LF & 42 & 2A & \verb+*+ & 74 & 4A & J &106 & 6A & j \\ 11 & 0B & VT & 43 & 2B & \verb-+- & 75 & 4B & K &107 & 6B & k \\ 12 & 0C & FF & 44 & 2C & \verb+, + & 76 & 4C & L &108 & 6C & l \\ 13 & 0D & CR & 45 & 2D & \verb+-+ & 77 & 4D & M &109 & 6D & m \\ 14 & 0E & SO & 46 & 2E & \verb+.+ & 78 & 4E & N &110 & 6E & n \\ 15 & 0F & SI & 47 & 2F & \verb+/+ & 79 & 4F & O &111 & 6F & o \\ 16 & 10 & DLE & 48 & 30 & 0 & 80 & 50 & P &112 & 70 & p \\ 17 & 11 & DC1 & 49 & 31 & 1 & 81 & 51 & Q &113 & 71 & q \\ 18 & 12 & DC2 & 50 & 32 & 2 & 82 & 52 & R &114 & 72 & r \\ 19 & 13 & DC3 & 51 & 33 & 3 & 83 & 53 & S &115 & 73 & s \\ 20 & 14 & DC4 & 52 & 34 & 4 & 84 & 54 & T &116 & 74 & t \\ 21 & 15 & NAK & 53 & 35 & 5 & 85 & 55 & U &117 & 75 & u \\ 22 & 16 & SYN & 54 & 36 & 6 & 86 & 56 & V &118 & 76 & v \\ 23 & 17 & ETB & 55 & 37 & 7 & 87 & 57 & W &119 & 77 & w \\ 24 & 18 & CAN & 56 & 38 & 8 & 88 & 58 & X &120 & 78 & x \\ 25 & 19 & EM & 57 & 39 & 9 & 89 & 59 & Y &121 & 79 & y \\ 26 & 1A & SUB & 58 & 3A & \verb+:+ & 90 & 5A & Z &122 & 7A & z \\ 27 & 1B & ESC & 59 & 3B & \verb+;+ & 91 & 5B & \verb+[+ &123 & 7B & \verb+{+ \\ 28 & 1C & FS & 60 & 3C & \verb+<+ & 92 & 5C & \verb+\+ &124 & 7C & \verb+|+ \\ 29 & 1D & GS & 61 & 3D & \verb+=+ & 93 & 5D & \verb+]+ &125 & 7D & \verb+}+ \\ 30 & 1E & RS & 62 & 3E & \verb+>+ & 94 & 5E & \verb+^+ &126 & 7E & \verb+~+ \\ 31 & 1F & US & 63 & 3F & \verb+?+ & 95 & 5F & \verb+_+ &127 & 7F & DEL$^{1}$ \\ \hline \end{tabular} \end{center} $^1$ Not ASCII Text \caption[ASCII character set]{ASCII character set} \label{t:ascii} \end{table} \chapter{IEEE Floating Point Formats} \label{s:IEEE754} (The\index{IEEE special values} material in this Appendix is not part of this standard; it is adapted from the IEEE-754 floating point\index{floating point} standard~[15] and provided for informational purposes. It is not intended to be a comprehensive description of the IEEE formats; readers should refer to the IEEE standard.) {\em FITS\/} recognizes all IEEE basic formats, including the special values. \section{Basic Formats} Numbers in the single and double formats are composed of the following three fields: \begin{enumerate} \item 1-bit sign $s$ \item Biased exponent $e=E+\mbox{{\it bias}}$ \item Fraction $f= \bullet b_{1} b_{2} \cdots b_{p-1}$ \end{enumerate} The range of the unbiased exponent $E$ shall include every integer between two values $E_{min}$ and $E_{max}$, inclusive, and also two other reserved values $E_{min}-1$ to encode $\pm 0$ and denormalized numbers, and $E_{max}$+1 to encode $\pm\infty$ and NaNs. The foregoing parameters are given in Table \ref{t:FormParm}. Each nonzero numerical value has just one encoding. The fields are interpreted as follows: \begin{table}[htpb] \begin{center} \begin{tabular}{lrrrr} \\ \hline\hline &\multicolumn{4}{c}{Format} \\ \cline{2-5} \multicolumn{1}{c}{Parameter} & &\multicolumn{1}{c}{Single} & & \multicolumn{1}{c}{Double} \\ & Single & Extended & Double & Extended \\ \hline $p$ & 24 & $\geq 32$ & 53 & $\geq 64$ \\ $E_{max}$ & $+127$ & $\geq +1023$ & $+1023$ & $\geq +16383$ \\ $E_{min}$ & $-126$ & $\leq -1022$ & $-1022$ & $\leq -16382$ \\ Exponent {\it bias} & $+127$ & unspecified & $+1023$ & unspecified \\ Exponent width in bits & 8 & $\geq 11$ & 11 & $\geq 15$ \\ Format width in bits & 32 & $\geq 43$ & 64 & $\geq 79$ \\ \hline\hline \end{tabular} \end{center} \caption[Summary of Format Parameters]{Summary of Format Parameters} \label{t:FormParm} \end{table} \subsection{Single} A 32-bit single format number $X$ is divided as shown in Fig. \ref{f:singl}. The value $v$ of $X$ is inferred from its constituent fields thus \begin{enumerate} \item If $e = 255$ and $f \neq 0$, then $v$ is NaN regardless of $s$ \item If $e = 255$ and $f = 0$, then $v = (-1)^{s} \infty$ \item If $0 < e < 255$, then $v = (-1)^{s} 2^{e-127} (1 \bullet f)$ \item If $e = 0$ and $f \neq 0$, then $v = (-1)^{s} 2^{e-126} (0 \bullet f)$ (denormalized numbers) \item If $e = 0$ and $f = 0$, then $v = (-1)^{s}0$ (zero) \end{enumerate} \begin{figure}[htb] \begin{center} \leavevmode \epsffile{ieee1.eps} \end{center} \caption[Single Format.]{Single Format. {\tt msb} means {\it most significant bit}, {\tt lsb} means {\it least significant bit}} \label{f:singl} \end{figure} \subsection{Double} A 64-bit double format number $X$ is divided as shown in Fig. \ref{f:doubl}. The value $v$ of $X$ is inferred from its constituent fields thus \begin{enumerate} \item If $e = 2047$ and $f \neq 0$, then $v$ is NaN regardless of $s$ \item If $e = 2047$ and $f = 0$, then $v = (-1)^{s} \infty$ \item If $0 < e < 2047$, then $v = (-1)^{s} 2^{e-1023} (1 \bullet f)$ \item If $e = 0$ and $f \neq 0$, then $v = (-1)^{s} 2^{e-1022} (0 \bullet f)$ (denormalized numbers) \item If $e = 0$ and $f = 0$, then $v = (-1)^{s}0$ (zero) \end{enumerate} \begin{figure}[htb] \begin{center} \leavevmode \epsffile{ieee2.eps} \end{center} \caption[Double Format.]{Double Format. {\tt msb} means {\it most significant bit}, {\tt lsb} means {\it least significant bit}} \label{f:doubl} \end{figure} \section{Byte Patterns} Table \ref{t:ieee} shows the types of IEEE floating point value, whether regular or special, corresponding to 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} \chapter{Reserved Extension Type Names} \label{s:resname} (This Appendix is not part of the NOST {\em FITS\/} Standard, but\index{extension} is included for\index{ASCII table} informational\index{BINTABLE extension} purposes. It describes the extension type names registered as of the date this standard was issued.) A current list is available from the {\em FITS\/} Support Office at \begin{quote} {\tt http://fits.gsfc.nasa.gov/xtension.html} \end{quote} or \begin{quote} {\tt ftp://nssdc.gsfc.nasa.gov/pub/fits/xtension.lis} \end{quote} \begin{small} \label{s:resn} \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 & [17] & NRAO & Prototype\index{NRAO} binary table design used\\ & & & & in AIPS\index{AIPS}; subset of\index{BINTABLE} {\tt BINTABLE}. \\ & & & & \\ \verb*+'BINTABLE'+ & S & [10] & IAU & Binary table extension. \\ & & & & Available at {\em FITS\/} Archives in files\index{BINTABLE} \\ & & & & /documents/standards/bintable.aa* \\ & & & & of 1995-Feb-06. Note: only main \\ & & & & document, excluding appendixes. \\ & & & & \\ \verb*+'COMPRESS'+ & R & none & GSFC & Suggested extension name\index{COMPRESS} by \\ & & & A/WWW & A. Warnock. Preliminary proposal \\ & & & & in {\em FITS} archives in the \\ & & & & files {\tt compress.*}.\\ & & & & \\ \verb*+'DUMP '+ & R & none & none & Suggested extension name for \\ & & & & binary\index{DUMP} dumps. \\ & & & & No full proposal submitted. \\ & & & & \\ \verb*+'FILEMARK'+ & R & none & NRAO & Suggested\index{FILEMARK} for equivalent \\ & & & & of tape mark on other media. \\ & & & & No full proposal submitted. \\ & & & & \\ \verb*+'IMAGE '+ & S & [9] & IAU & Image extension. \\ & & & & \\ \verb*+'IUEIMAGE'+ & L & [18] & IUE & Local extension originally \\ & & & & defined for archiving\index{IUEIMAGE} \\ & & & & special IUE data products, \\ & & & & Identical to {\tt IMAGE}. \\ & & & & \\ \verb*+'TABLE '+ & S & [5] & IAU & ASCII\index{TABLE extension} table extension.\\ & & & & \\ \verb*+'VGROUP '+ & R & none & GSFC & Suggested extension name for \\ & & & & HDF Vgroups (D. Jennings) \\ & & & & No formal proposal; not used in \\ & & & & current HDF-{\em FITS\/} \\ & & & & conversion proposals \\ & & & & \\ \hline \end{tabular} \end{center} \caption[Reserved Extension Type Names]{Reserved Extension Type Names} \label{t:resnt} \end{table} \end{small} \smallskip \begin{table}[thpb] \begin{center} \begin{tabular}{ll} \\ \multicolumn{1}{c}{Code} & \multicolumn{1}{c}{Significance} \\ \hline D & Draft extension proposal for discussion by regional {\em FITS\/} committees. \\ L & Local {\em FITS\/} extension. \\ P & Proposed {\em FITS\/} extension approved by regional {\em FITS\/} committees \\ & but not by IAU {\em FITS\/} Working Group. \\ R & Reserved type name for which a full draft proposal has not been submitted. \\ S & Standard extension approved by IAU {\em FITS\/} Working Group and \\ & endorsed by the IAU. \\ \\ \hline \end{tabular} \end{center} \caption[Status Codes]{Status Codes} \end{table} \medskip \begin{table}[htpb] \begin{center} \begin{tabular}{ll} \\ Acronym & Meaning \\ \hline NRAO & National Radio Astronomy Observatory\\ AIPS & Astronomical Image Processing System \\ A/WWW & A/WWW Enterprises \\ HDF & Hierarchical Data Format\\ \hline \end{tabular} \caption {Acronyms in List of Registered Extensions} \end{center} \end{table} \chapter{NOST Publications} \label{s:pubs} \begin{small} \begin{table}[htpb] \begin{center} \begin{tabular}{llll} \\ \multicolumn{1}{c}{Document} & \multicolumn{1}{c}{Title} & \multicolumn{1}{c}{Date} & \multicolumn{1}{c}{Status} \\ \hline NOST 100-0.1 & {\em FITS\/} Standard & December, 1990 & Draft Standard \\ & & \\ NOST 100-0.2 & {\em FITS\/} Implementation Standard & June, 1991 & Revised Draft Standard \\ NOST 100-0.3 & {\em FITS\/} Implementation Standard & December, 1991 & Revised Draft Standard \\ NOST 100-1.0 & {\em FITS\/} Definition Standard & March, 1993 & Proposed Standard \\ NOST 100-1.0 & {\em FITS\/} Definition Standard & June, 1993 & NOST Standard \\ NOST 100-1.1 & {\em FITS\/} Definition Standard & June, 1995 & Proposed Standard \\ NOST 100-1.1 & {\em FITS\/} Definition Standard & September, 1995 & NOST Standard \\ NOST 100-1.2 & {\em FITS\/} Definition Standard & April, 1998 & Draft Standard \\ NOST 100-2.0 & {\em FITS\/} Definition Standard & March, 1999 & NOST Standard \\ & & \\ \hline \end{tabular} \end{center} \caption[NOST Publications]{NOST Publications} \end{table} \end{small} % check if a \newpage or \clearpage is needed here - PJT \cleardoublepage \ifindex \addcontentsline{toc}{chapter}{Index} \printindex \fi \typeout{#### To make index, type "makeindex fits_standard.idx"} \end{document} %