Up: Definition of the Flexible (FITS)

Online Material

Appendix A: Formal syntax of card images

(This Appendix is not part of the NOST FITS standard but is included for convenient reference.)

The following notation is used in defining the formal syntax.

:= 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 $\ldots$ 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

\0xnn means the ASCII character associated with the hexadecimal code nn

{ $\ldots$ } expresses a constraint or a comment (it immediately follows the syntax rule).

The following statements define the formal syntax used in FITS free format card images.

FITS_card_image :=
FITS_commentary_card_image | FITS_value_card_image

FITS_commentary_card_image :=
COMMENT_keyword [ascii_text_char...] |
HISTORY_keyword [ascii_text_char...] |
BLANKFIELD_keyword [ascii_text_char...] |
keyword_field anychar_but_equal [ascii_text_char...] |
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.}

FITS_value_card_image :=
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 FITS keyword is not defined.}

keyword_field :=
[keyword_char...] [space...]
{Constraint: The total number of characters in the keyword_field must be exactly equal to 8.}

keyword_char :=
`A'-`Z' | `0'-`9' | `_' | `-'

COMMENT_keyword :=
`C' `O' `M' `M' `E' `N' `T' space

HISTORY_keyword :=
`H' `I' `S' `T' `O' `R' `Y' space

BLANKFIELD_keyword :=
space space space space space space space space

value_indicator :=
`=' space

space :=
` '

comment :=
`/' [ascii_text_char...]

ascii_text_char :=
space-`~'

anychar_but_equal :=
space-`<' | `>'-`~'

anychar_but_space :=
`!'-`~'

character_string_value :=
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 :=
quote

end_quote :=
quote
{Constraint: The ending quote must not be immediately followed by a second quote.}

quote :=
\0x27

string_text_char :=
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 :=
`T' | `F'

integer_value :=
[sign] digit [digit...]
{Comment: Such an integer value is interpreted as a signed decimal number. It may contain leading zeros.}

sign :=
`-' | `+'

digit :=
`0'-`9'

floating_value :=
decimal_number [exponent]

decimal_number :=
[sign] [integer_part] [`.' [fraction_part]]
{Constraint: At least one of the integer_part and fraction_part must be present.}

integer_part :=
digit | [digit...]

fraction_part :=
digit | [digit...]

exponent :=
exponent_letter [sign] digit [digit...]

exponent_letter :=
`E' | `D'

complex_integer_value :=
`(' [space...] real_integer_part [space...] `,' [space...]
imaginary_integer_part [space...] `)'

real_integer_part :=
integer_value

imaginary_integer_part :=
integer_value

complex_floating_value :=
`(' [space...] real_floating_part [space...] `,' [space...]
imaginary_floating_part [space...] `)'

real_floating_part :=
floating_value

imaginary_floating_part :=
floating_value

Appendix B: Proposed binary table conventions

(This Appendix is not part of the NOST FITS Standard but is included for informational purposes only.) In the paper describing the binary table extension , type name 'BINTABLE' (Cotton et al. 1995), 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 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 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.

B.1 ``Variable length array'' facility

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 presented here 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 P, the variable length array descriptor itself, which is not a datatype so much as a storage class specifier). Conventions such as TDIMn (see Appendix .4) 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

$\begin{displaymath}{\tt rPt}({\tt e}_{\rm max}) \end{displaymath}$

where the "P'' indicates the amount of space occupied by the array descriptor in the data record (64 bits), the element count r should be 0, 1, or absent, t is a character denoting the datatype of the array data (L, X, B, I, J, etc., but not P), and ${\tt e}_{\rm max}$ is a quantity guaranteed to be equal to or greater than the maximum number of elements of type 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 TFORMn keyword following the ${\tt e}_{\rm max}$ .

For example,

$\begin{displaymath}\mbox{{\tt TFORM8 = 'PB(1800)' / Variable byte array}} \end{displaymath}$

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 , following the last fixed size data record. What is stored in the data record is an 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:

$\ldots$ [field N-1] [(nelem,offset)] [field N+1] $\ldots$

If the stored array length is zero there is no array data, and the 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]

The table header consists of one or more 2880-byte FITS logical records with the last record indicated by the keyword 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 zero indexed byte offset of the heap measured from the start of the record storage area is given by the THEAP keyword 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 PCOUNT keyword 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 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 FITS records, 840 bytes of which are used by the 5 table records, hence PCOUNT is $2\times 2880-840$ , or 4920 bytes; this is expressed in the table header as:

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

The values of TSCALn and TZEROn for 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 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 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 . 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 are more complicated than 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.

This facility is still undergoing trials and is not part of the basic binary table definition.

B.2 ``Multidimensional array'' convention

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 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 keyword TDIMn ='(l,m,n...)' where l, m, n, ...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 TDIMn keyword will equal the element count specified in the TFORMn keyword. The adherence to this convention will be indicated by the presence of a TDIMn keyword in the form described above.

A character string is represented in a binary table by a one-dimensional character array, as described under "Character'' in the list of datatypes in Sect. 8.3.3 ("Main Data Table''). For example, a Fortran 77 CHARACTER*20 variable could be represented in a binary table as a character array declared as TFORMn = '20A $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ '. Arrays of character strings, i.e., multidimensional character arrays, may be represented using the TDIMn notation. For example, if TFORMn = '60A $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ ' and 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 .5. One dimensional arrays of strings should use the convention in Appendix .5 rather than the "Multidimensional Array'' convention.)

This convention is optional and will not preclude other conventions. This convention is not part of the binary table definition.

B.3 ``Substring array'' convention

This appendix describes a layered convention for specifying that a character array field (TFORMn = 'rA') consists of 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 TFORMn value field. The full form for the value of TFORMn within this convention is

'rA:SSTRw/nnn'

and a simpler form that may be used for fixed-length substrings only is

'rAw'

where

r is an integer giving the total length including any delimiters (in characters) of the field,
A signifies that this is a character array field,
: indicates that a convention indicator follows,
SSTR indicates the use of the "Substring Array'' convention,
w is an integer $\leq$ r giving the (maximum) number of characters in an individual substring (not including the delimiter), and
/nnn if present, indicates that the substrings have variable-length and are delimited by an ASCII text character with decimal value 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.

To illustrate this usage:

'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 '40A8',
'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.

Note that simple FITS readers that do not understand this substring convention can ignore the TFORM characters following the 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:

1.

In the case of fixed-length substrings, if r is not an integer multiple of w then the remaining odd characters are undefined and should be ignored. For example if TFORMn ='14A:SSTR3', then the field contains 4 3-character substrings followed by 2 undefined characters;

2.

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;

3.

The character following the delimiter character in variable-length substrings is the first character of the following substring;

4.

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. '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;

5.

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;

6.

The "Multidimensional Array'' convention described in Appendix .4 of this paper provides a syntax using the TDIMn keyword 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;

7.

This substring convention may be used in conjunction with the "Variable Length Array'' facility described in Appendix .3 of this paper. In this case, the two possible full forms for the value of the TFORM keyword are

TFORMn = 'rPA( ${\tt e}_{\rm max}$ ):SSTRw/nnn'

and

TFORMn = 'rPA( ${\tt e}_{\rm max}$ ):SSTRw'

for the variable and fixed cases, respectively.

This convention is optional and will not preclude other conventions. This convention is not part of the binary table definition.

Appendix C: Implementation on physical media

(This Appendix is not part of the NOST FITS Standard, but is included as a guide to recommended practices.)

C.1 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.

C.2 Labeling

C.2.1 Tape

Tapes may be either ANSI standard labeled or unlabeled. Unlabeled tapes are preferred.

C.2.2 Other media

Conventions regarding labels for physical media containing FITS files have not been established for other media.

C.3 FITS file boundaries

C.3.1 Magnetic reel tape

Individual FITS files are terminated by a tape-mark.

C.3.2 Other media

For fixed block length sequential media where the physical block size cannot be equal to or an integral multiple of the standard FITS logical record length, a logical record of fewer than 23040 bits (2880 8-bit bytes) immediately following the end of the primary header, data, or an extension should be treated as an end-of-file. Otherwise, individual FITS files should be terminated by a delimiter appropriate to the medium, analogous to the tape end-of-file mark. If more than one 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.

C.4 Multiple physical volumes

Storage of a single FITS file on more than one unlabeled tape or on multiple units of any other medium is not universally supported in FITS. One possible way to handle multivolume unlabeled tape was suggested in Wells et al. (1981). A convention for logically grouping on-line FITS HDUs that may physically be located in different sites has been proposed in (Jennings et al. 1997).

Appendix D: Suggested time scale specification

[Not part of formal DATExxxx agreement]

1.

Use of the keyword 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 TIMESYS keyword. Initially, officially allowed values are:

UTC: Coordinated Universal Time; defined since 1972.
UT: Universal Time, equal to Greenwich Mean Time (GMT) since 1925; the UTC equivalent before 1972; see: Explanatory Supplement, p. 76.
TAI: International Atomic Time; "UTC without the leap seconds''; 31 s ahead of UTC on 1997-07-01.
AT: International Atomic Time; deprecated synonym of TAI.
ET: Ephemeris Time, the predecessor of TT; valid until 1984.
TT: Terrestrial Time, the IAU standard time scale since 1984; continuous with ET and synchronous with (but 32.184 s ahead of) TAI.
TDT: Terrestrial Dynamical Time; = TT.
TDB: Barycentric Dynamical Time.
TCG: Geocentric Coordinate Time; runs ahead of TT since 1977-01-01 at a rate of approximately 22 ms/year.
TCB: Barycentric Coordinate Time; runs ahead of TDB since 1977-01-01 at a rate of approximately 0.5 s/year.

For reference, see: Explanatory Supplement to the Astronomical Almanac, P. K. Seidelmann, ed., University Science Books, 1992, ISBN 0-935702-68-7, or

http://tycho.usno.navy.mil/systime.html

Use of Global Positioning Satellite (GPS) time (19 s behind TAI) is deprecated.

2.

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

3.

Note that TT is the IAU preferred standard. It may be considered equivalent to TDT and ET, though ET should not be used for data taken after 1984. For reference, see: Explanatory Supplement, pp. 40-48.

4.

If the TIMESYS keyword is absent or has an unrecognized value, the value UTC will be assumed for dates since 1972, and UT for pre-1972 data.

5.

Examples. The three legal representations of the date of October 14, 1996, might be written as shown in Table .1.

**Table D.1:** Three legal representations of the date October 14, 1996.
$\begin{table}\par {\small \begin{tex2html_preform}\begin{verbatim}DATE-OBS= '14/... ...nd time of start of obs. in TT.\end{verbatim}\end{tex2html_preform}} \end{table}$

6.

The convention suggested in this Appendix is part of the mission-specific FITS conventions adopted for, and used in, the RXTE archive, building on existing High Energy Astrophysics FITS conventions. See:

http://heasarc.gsfc.nasa.gov/docs/xte/abc/ time_tutorial.html
http://heasarc.gsfc.nasa.gov/docs/xte/abc/ time.html

The VLBA project has adopted a convention where the keyword TIMSYS, rather than TIMESYS, is used, currently allowing the values UTC and IAT. See p. 9 and p. 16 of:

http://www.cv.nrao.edu/fits/documents/ drafts/vlba_format.ps

Appendix E: Differences from IAU-endorsed publications

(This Appendix is not part of the NOST FITS Standard but is included for informational purposes only.)

Note: in this discussion, the term the FITS papers refers to Wells et al. (1981), Greisen & Harten (1981), Grosbøl et al. (1988), Harten et al. (1988), Ponz et al. (1994), and Cotton et al. (1995) collectively; the term Floating Point Agreement (FPA) refers to Wells & Grosbøl (1990); the term Blocking Agreement refers to Grosbøl & Wells (1994); and the term DATExxxx Agreement refers to the redefinition of the value format for date keywords approved by the IAUFWG in 1997.

1.

Section 3 - Definitions, Acronyms, and Symbols.

Array value: - This precise definition is not used in the original FITS papers.
ASCII text: - This permissible subset of the ASCII character set, used in many contexts, is not precisely defined in the FITS papers.
Basic FITS: - This definition includes the possibility of floating point data arrays, while the terminology in the FITS papers refers to FITS as described in Wells et al. (1981), where only integer arrays were possible.
Conforming Extension: - This terminology is not used in the FITS papers.
Deprecate: - The concept of deprecation does not appear in the FITS papers.
FITS structure: - This terminology is not used in the FITS papers in the precise way that it is in this standard.
Fraction: - This terminology and the distinction between fraction and mantissa do not appear in the Floating Point Agreement.
Header and Data Unit: - This terminology is not used in the FITS papers.
Indexed keyword: - This terminology is not used in the original FITS papers.
Physical value: - This precise definition is not used in the original FITS papers.
Reference point: - This term replaces the reference pixel of the 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 pixel) need not lie within the array.
Repeat count: - This terminology is not used in the FITS papers.
Reserved keyword: - The FITS papers describe optional keywords but do not say explicitly that they are reserved.
Standard Extension: - This precise definition is new. The term standard extension is used in some contexts in the FITS papers to refer to what this standard defines as a standard extension and in others to refer to what this standard defines as conforming extension.

2.

Section 4.3.2. Primary data array
Fill format - This specification is new. The FITS papers and the FPA do not precisely specify the format of data fill for the primary data array.

3.

Section 4.4.1.1. Identity (of conforming extensions)
The FITS papers specify that creators of new extension types should check with the FITS standards committee. This standard identifies the committee specifically, introduces the role of the FITS Support Office as its agent, and mandates registration.

4.

Section 4.6. Physical blocking
This material is based entirely on the Blocking Agreement. Material in the early FITS papers [1,4] specifying the expression of FITS on specific physical media is not part of this standard.

5.

Section 4.6.1. Bitstream devices
The Blocking Agreement specifies that this rule applies to FITS files written to logical file systems. This standard applies the rule to all bitstream devices, not only logical file systems.

6.

Section 4.6.2.1. Fixed block
The Blocking Agreement specifies that this rule applies to 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.

7.

Section 4.6.2.2. Variable block
The Blocking Agreement specifies that this rule applies to FITS files written to 1/2-inch 9 track tapes, DDS/DAT 4 mm cartridge tapes and 8 mm cartridge tape (Exabyte). This standard extends the rule to all variable block length sequential media and eliminates references to specific products.

8.

Section 5.1.2.1. Keyword (as header component)
The specification of permissible keyword characters is new. The FITS papers do not precisely define the permissible characters for keywords.

9.

Section 5.1.2.2. Value indicator (bytes 9-10)
The FITS papers do not specifically address the permissibility of null values. This standard states explicitly that they are permitted.

10.

Section 5.1.2.3. Value/comment (bytes 11-80)
In the 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.

11.

Section 5.2. Value, including its subsections
The FITS papers specify that the value field is to be written following the rules of ANSI FORTRAN-77 list-directed input, with some restrictions. This standard explicitly describes the format of the value field. The 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 FITS papers require the fixed format for the most essential parameters. This standard identifies those parameters with the values of the mandatory keywords.

12.

Section 5.2.1. 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 read requirements of the FITS papers.

The standard states that in general, character-valued keywords can have lengths up to the maximum 68 character length.

13.

Section 5.2.4. 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 format.

14.

Section 5.2.5. Complex integer number
The standard does not support the fixed format for complex integers defined in the FITS papers but is consistent with FORTRAN-77 list-directed read as required in the FITS papers for free format. Because the fixed format of the FITS papers did not conform to the rules for FORTRAN-77 list-directed I/O, consistency with both was impossible. There are no known FITS files that use the fixed format for complex integers that was defined in the FITS papers.

15.

Section 5.2.6. Complex floating point number
The standard does not support the fixed format for complex floating point numbers defined in the FITS papers but is consistent with FORTRAN-77 list-directed read as required in the FITS papers for free format. Because the fixed format of the FITS papers did not conform to the rules for FORTRAN-77 list-directed I/O, consistency with both was impossible. There are no known FITS files that use the fixed format for complex floating point numbers that was defined in the FITS papers.

16.

Section 5.3. Units
The FITS papers recommend the use of SI 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 Manual (McNally 1988), while explicitly recommending degrees for angular measure and requiring degrees for celestial coordinates.

17.

Section 5.4.1.1. Principal (mandatory keywords)

(a): SIMPLE keyword - The explicit prohibition against the appearance of the SIMPLE keyword in extensions does not appear in the FITS papers.
(b): NAXIS keyword - The requirement that the NAXIS keyword may not be negative is not explicitly specified in the FITS papers.
(c): NAXISn keyword - The requirement that the NAXISn keyword may not be negative is not explicitly specified in the FITS papers.

18.

Section 5.4.1.2. Conforming extensions

(a): $N_{\rm bits}$ - The requirement that $N_{\rm bits}$ may not be negative is not explicitly specified in the FITS papers.
(b): XTENSION keyword - That this keyword may not appear in the primary header is only implied by the FITS papers; the prohibition is explicit in this standard. The FITS papers name a FITS standards committee as the keeper of the list of accepted extension type names. This standard specifically identifies the committee and introduces the role of the FITS Support Office as its agent.

19.

Section 5.4.2. Other reserved keywords
That the optional keywords defined in the 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.

20.

Section 5.4.2.1. Keywords describing the history or physical construction of the HDU

(a): DATE keyword - The notation for four-digit year number is YYYY rather than the 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 FITS papers.
(b): BLOCKED keyword - The FITS papers require the BLOCKED keyword to appear in the first record of the primary header even though it cannot when the value of NAXIS exceeds the values described in the text. They do not address this contradiction. This standard deprecates the BLOCKED keyword.

21.

Section 5.4.2.2. Keywords describing observations

(a): DATE-OBS keyword - The recommendation for use of Universal Time in the superseded format with a two-digit year is not in the FITS papers.
(b): EQUINOX and EPOCH keywords - This standard replaces the EPOCH keyword with the more appropriately named EQUINOX keyword and deprecates the EPOCH name.

22.

Section 5.4.2.4. Commentary keywords
Keyword field is blank - Wells et al. (1981) contains the text "BLANK'' to represent a blank keyword field. The standard clarifies the intention.

23.

Section 5.4.2.5. Array keywords

(a): BUNIT keyword - The FITS papers recommend the use of SI units, degrees as the appropriate unit for angles, and identify other units standard in astronomy. This standard specifically applies the recommendations of Sect. 5.3 to the BUNIT keyword.
(b): CTYPEn, CRVALn, CDELTn, and CROTAn keywords - This standard extends the recommendations on units to coordinate axes, explicitly requiring decimal degrees for coordinates.
(c): CRPIXn keywords - This standard explicitly notes the ambiguity in the location of the index number relative to an image pixel.
(d): CDELTn keywords - The definition in the standard differs from that in the FITS papers in that it provides for the case where the spacing between index points varies over the grid. For the case of constant spacing, it is identical to the specification in the FITS papers.
(e): DATAMAX and DATAMIN keywords - The standard clarifies that the value refers to the physical value represented by the array , after any scaling, not the array value before scaling. The standard also notes that special values are not to be considered when determining the values of DATAMAX and DATAMIN, an issue not specifically addressed by the FITS papers or the FPA.

24.

Section 7. Random groups structure
The standard deprecates the Random Groups structure.

25.

Section 7.1.2. Reserved keywords (random groups)
That the optional keywords defined in the 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.

26.

Section 7.1.2.2. PSCALn keywords - The default value is explicitly specified in the standard, whereas in the FITS papers it is assumed by analogy with the BSCALE keyword.

27.

Section 7.1.2.3. PZEROn keywords - The default value is explicitly specified in the standard, whereas in the FITS papers it is assumed by analogy with the BZERO keyword.

28.

Section 8.1. ASCII table extension
The name ASCII table is given to the "tables'' extension discussed in the FITS papers to distinguish it from the binary table extension.

29.

Section 8.1.1. Mandatory keywords (ASCII table)

(a): NAXIS1 keyword - The requirement that the NAXIS1 keyword may not be negative in an ASCII table header is not explicitly specified in the FITS papers.
(b): NAXIS2 keyword - The requirement that the NAXIS2 keyword may not be negative in an ASCII table header is not explicitly specified in the FITS papers.
(c): TFIELDS keyword - The requirement that the TFIELDS keyword may not be negative is not explicitly specified in the FITS papers.
(d): TFORMn keyword - The requirement that format codes must be specified in upper case is implied but not explicitly specified in the FITS papers.

30.

Section 8.1.2. Other reserved keywords (ASCII table)
That the optional keywords defined in the 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.

(a): TUNITn keywords - The FITS papers do not explicitly recommend the use of any particular units for this keyword, although the reference to the BUNIT keyword may be considered an implicit extension of the recommendation for that keyword. This standard makes the recommendation more specific for the TUNITn keyword by requiring conformance to the prescriptions in Sect. 5.3.
(b): TSCALn keywords - The prohibition against use in A-format fields is stronger than the statement in the FITS papers that the keyword "is not relevant''.
(c): TZEROn keywords - The prohibition against use in A-format fields is stronger than the statement in the FITS papers that the keyword "is not relevant''.

31.

Section 8.3.2. Other reserved keywords (Binary Table)
The EXTNAME, EXTVER, EXTLEVEL, AUTHOR, and REFERENC keywords explicitly reserved for binary tables in the defining paper are reserved in the standard under the general prescription of Sect. 5.4.2.

(a): TUNITn keywords - The FITS papers do not explicitly recommend the use of any particular units for this keyword. This standard makes the recommendation more specific for the TUNITn keyword by requiring conformance to the prescriptions of Sect. 5.3.
(b): TDISPn keywords - The version of the BINTABLE paper upon which the FITS committees voted stated incorrectly that the values used to display bit and byte arrays should be considered signed. This standard follows the text in the published BINTABLE paper, which specifies that these values should be unsigned. The BINTABLE paper does not specify how a TDISPn value for a field of type 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 BINTABLE paper.
(c): THEAP keywords - The FITS papers state only that the keyword is reserved for use in the convention described in Appendix .3. 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 heap and identifies the default value.
(d): TDIMn keywords - The FITS papers state only that the keyword is reserved for use in the convention described in Appendix .4. 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.

32.

Section 8.3.4. Data display
The BINTABLE paper suggests that the format for display suggested by the 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 E and D format codes, which notes that the latter implies greater precision in the internal datum, does not appear in the BINTABLE paper.

33.

Section 9. Restrictions on changes
The FITS papers do not provide for the concept of deprecation.

34.

Appendix .6 implementation on physical media
Material in the FITS papers specifying the expression of 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.

Appendix F: Summary of keywords

(This Appendix is not part of the NOST FITS Standard, but is included for convenient reference). Tables F.1, F.2, and F.3 list the mandatory and reserved FITS keywords.

Table F.1: Mandatory FITS keywords for the structures described in this document.
Principal Conforming ASCII Table Image Binary Table Random Groups

HDU Extension Extension Extension Extension Records

SIMPLE XTENSION XTENSION¹ XTENSION² XTENSION³ SIMPLE

BITPIX BITPIX BITPIX = 8 BITPIX BITPIX = 8 BITPIX

NAXIS NAXIS NAXIS = 2 NAXIS NAXIS = 2 NAXIS

NAXISn⁴ NAXISn⁴ NAXIS1 NAXISn⁴ NAXIS1 NAXIS1 = 0

EXTEND⁵ PCOUNT NAXIS2 PCOUNT = 0 NAXIS2 NAXISn⁴

END GCOUNT PCOUNT = 0 GCOUNT = 1 PCOUNT GROUPS = T

END GCOUNT = 1 END GCOUNT = 1 PCOUNT

TFIELDS TFIELDS GCOUNT

TBCOLn⁶ TFORMn⁶ END

TFORMn⁶ END

END

**Table F.1:** Mandatory *FITS* keywords for the structures described in this document.
Principal	Conforming	ASCII Table	Image	Binary Table	Random Groups
HDU	Extension	Extension	Extension	Extension	Records
SIMPLE	XTENSION	XTENSION¹	XTENSION²	XTENSION³	SIMPLE
BITPIX	BITPIX	`BITPIX = 8`	BITPIX	`BITPIX = 8`	BITPIX
NAXIS	NAXIS	`NAXIS = 2`	NAXIS	`NAXIS = 2`	NAXIS
NAXISn⁴	NAXISn⁴	NAXIS1	NAXISn⁴	NAXIS1	`NAXIS1 = 0`
EXTEND⁵	PCOUNT	NAXIS2	`PCOUNT = 0`	NAXIS2	NAXISn⁴
END	GCOUNT	`PCOUNT = 0`	`GCOUNT = 1`	PCOUNT	`GROUPS = T`
	END	`GCOUNT = 1`	END	`GCOUNT = 1`	PCOUNT
		TFIELDS		TFIELDS	GCOUNT
		TBCOLn⁶		TFORMn⁶	END
		TFORMn⁶		END
		END

¹ XTENSION= 'TABLE' for the ASCII table extension.
² XTENSION= 'IMAGE' for the image extension .
³ XTENSION= 'BINTABLE' for the binary table extension .
⁴ Runs from 1 through the value of NAXIS.
⁵ Required only if extensions are present.
⁶ Runs from 1 through the value of TFIELDS.

Table F.2: Reserved FITS keywords for the structures described in this document.
All Array¹ Conforming ASCII Table Binary Table Random Groups

HDUs HDUs Extension Extension Extension Records

DATE BSCALE EXTNAME TSCALn TSCALn PTYPEn

ORIGIN BZERO EXTVER TZEROn TZEROn PSCALn

BLOCKED² BUNIT EXTLEVEL TNULLn TNULLn PZEROn

AUTHOR BLANK TTYPEn TTYPEn

REFERENC CTYPEn TUNITn TUNITn

COMMENT CRPIXn TDISPn

HISTORY CROTAn TDIMn

$\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ CRVALn THEAP

DATE-OBS CDELTn

TELESCOP DATAMAX

INSTRUME DATAMIN

OBSERVER

OBJECT

EQUINOX

EPOCH²

**Table F.2:** Reserved *FITS* keywords for the structures described in this document.
All	Array¹	Conforming	ASCII Table	Binary Table	Random Groups
HDUs	HDUs	Extension	Extension	Extension	Records
DATE	BSCALE	EXTNAME	TSCALn	TSCALn	PTYPEn
ORIGIN	BZERO	EXTVER	TZEROn	TZEROn	PSCALn
BLOCKED²	BUNIT	EXTLEVEL	TNULLn	TNULLn	PZEROn
AUTHOR	BLANK		TTYPEn	TTYPEn
REFERENC	CTYPEn		TUNITn	TUNITn
COMMENT	CRPIXn			TDISPn
HISTORY	CROTAn			TDIMn
$\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$	CRVALn			THEAP
DATE-OBS	CDELTn
TELESCOP	DATAMAX
INSTRUME	DATAMIN
OBSERVER
OBJECT
EQUINOX
EPOCH²

¹ Primary HDU, image extension, user-defined HDUs with same array structure.
² Deprecated.

Table F.3: General reserved FITS keywords described in this document.
Production Bibliographic Commentary Observation

DATE AUTHOR COMMENT DATE-OBS

ORIGIN REFERENC HISTORY TELESCOP

BLOCKED¹ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ INSTRUME

OBSERVER

OBJECT

EQUINOX

EPOCH¹

**Table F.3:** General reserved *FITS* keywords described in this document.
Production	Bibliographic	Commentary	Observation
DATE	AUTHOR	COMMENT	DATE-OBS
ORIGIN	REFERENC	HISTORY	TELESCOP
BLOCKED¹		$\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$	INSTRUME
			OBSERVER
			OBJECT
			EQUINOX
			EPOCH¹

¹ Deprecated.

Appendix G: ASCII text

(This Appendix is not part of the NOST FITS standard; the material in it is based on the ANSI standard for ASCII (ANSI 1977) and is included here for informational purposes.)

In Table G.1, the first column is the decimal 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.

Table G.1: ASCII character set.
ASCII Control ASCII Text

dec hex char dec hex char dec hex char dec hex char

0 00 NUL 32 20 SP 64 40 @ 96 60 `

1 01 SOH 33 21 ! 65 41 A 97 61 a

2 02 STX 34 22 " 66 42 B 98 62 b

3 03 ETX 35 23 # 67 43 C 99 63 c

4 04 EOT 36 24 $ 68 44 D 100 64 d

5 05 ENQ 37 25 % 69 45 E 101 65 e

6 06 ACK 38 26 & 70 46 F 102 66 f

7 07 BEL 39 27 ' 71 47 G 103 67 g

8 08 BS 40 28 ( 72 48 H 104 68 h

9 09 HT 41 29 ) 73 49 I 105 69 i

10 0A LF 42 2A * 74 4A J 106 6A j

11 0B VT 43 2B + 75 4B K 107 6B k

12 0C FF 44 2C , 76 4C L 108 6C l

13 0D CR 45 2D - 77 4D M 109 6D m

14 0E SO 46 2E . 78 4E N 110 6E n

15 0F SI 47 2F / 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 : 90 5A Z 122 7A z

27 1B ESC 59 3B ; 91 5B [ 123 7B {

28 1C FS 60 3C < 92 5C \ 124 7C |

29 1D GS 61 3D = 93 5D ] 125 7D }

30 1E RS 62 3E > 94 5E ^ 126 7E ~

31 1F US 63 3F ? 95 5F _ 127 7F DEL¹

**Table G.1:** ASCII character set.
ASCII Control	ASCII Text
dec	hex	char	dec	hex	char	dec	hex	char	dec	hex	char
0	00	NUL	32	20	SP	64	40	`@`	96	60	`
1	01	SOH	33	21	`!`	65	41	A	97	61	a
2	02	STX	34	22	`"`	66	42	B	98	62	b
3	03	ETX	35	23	`#`	67	43	C	99	63	c
4	04	EOT	36	24	`$`	68	44	D	100	64	d
5	05	ENQ	37	25	`%`	69	45	E	101	65	e
6	06	ACK	38	26	`&`	70	46	F	102	66	f
7	07	BEL	39	27	`'`	71	47	G	103	67	g
8	08	BS	40	28	`(`	72	48	H	104	68	h
9	09	HT	41	29	`)`	73	49	I	105	69	i
10	0A	LF	42	2A	`*`	74	4A	J	106	6A	j
11	0B	VT	43	2B	`+`	75	4B	K	107	6B	k
12	0C	FF	44	2C	`,`	76	4C	L	108	6C	l
13	0D	CR	45	2D	`-`	77	4D	M	109	6D	m
14	0E	SO	46	2E	`.`	78	4E	N	110	6E	n
15	0F	SI	47	2F	`/`	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	`:`	90	5A	Z	122	7A	z
27	1B	ESC	59	3B	`;`	91	5B	`[`	123	7B	`{`
28	1C	FS	60	3C	`<`	92	5C	`\`	124	7C	`\|`
29	1D	GS	61	3D	`=`	93	5D	`]`	125	7D	`}`
30	1E	RS	62	3E	`>`	94	5E	`^`	126	7E	`~`
31	1F	US	63	3F	`?`	95	5F	`_`	127	7F	DEL¹

¹ Not ASCII Text

Appendix H: IEEE floating point formats

(The material in this Appendix is not part of this standard; it is adapted from the IEEE-754 floating point standard (IEEE 1985) 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.) FITS recognizes all IEEE basic formats, including the special values.

H.1 Basic formats

Numbers in the single and double formats are composed of the following three fields:

1.: 1-bit sign s
2.: Biased exponent $e=E+\mbox{{\it bias}}$
3.: Fraction $f= \bullet b_{1} b_{2} \cdots b_{p-1}.$

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 .6. Each nonzero numerical value has just one encoding. The fields are interpreted as follows:

Table H.1: Summary of format parameters.
Format

Parameter Single Double

Single Extended Double Extended

p 24 $\geq 32$ 53 $\geq 64$

$E_{\max}$ +127 $\geq +1023$ +1023 $\geq +16383$

$E_{\min}$ -126 $\leq -1022$ -1022 $\leq -16382$

Exponent 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$

**Table H.1:** Summary of format parameters.
	Format
Parameter		Single		Double
	Single	Extended	Double	Extended
p	24	$\geq 32$	53	$\geq 64$
$E_{\max}$	+127	$\geq +1023$	+1023	$\geq +16383$
$E_{\min}$	-126	$\leq -1022$	-1022	$\leq -16382$
Exponent 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$

H.1.1. Single

A 32-bit single format number X is divided as shown in Fig. .1. The value v of X is inferred from its constituent fields thus

1.: If e = 255 and $f \neq 0$ , then v is NaN regardless of s
2.: If e = 255 and f = 0, then $v = (-1)^{s} \infty$
3.: If 0 < e < 255, then $v = (-1)^{s} 2^{e-127} (1 \bullet f)$
4.: If e = 0 and $f \neq 0$ , then $v = (-1)^{s} 2^{e-126} (0 \bullet f)$ (denormalized numbers)
5.: If e = 0 and f = 0, then v = (-1)^s0 (zero).

$\begin{figure} \par\resizebox{\hsize}{!}{\includegraphics{h2901f1.eps}}\end{figure}$

Figure H.1: Single Format. msb means most significant bit, lsb means least significant bit.

H.1.2. Double

A 64-bit double format number X is divided as shown in Fig. .2. The value v of X is inferred from its constituent fields thus

1.: If e = 2047 and $f \neq 0$ , then v is NaN regardless of s
2.: If e = 2047 and f = 0, then $v = (-1)^{s} \infty$
3.: If 0 < e < 2047, then $v = (-1)^{s} 2^{e-1023} (1 \bullet f)$
4.: If e = 0 and $f \neq 0$ , then $v = (-1)^{s} 2^{e-1022} (0 \bullet f)$ (denormalized numbers)
5.: If e = 0 and f = 0, then v = (-1)^s0 (zero).

$\begin{figure}\par\resizebox{\hsize}{!}{\includegraphics{h2901f2.eps}}\end{figure}$

Figure H.2: Double Format. msb means most significant bit, lsb means least significant bit.

H.2. Byte patterns

Table .7 shows the types of IEEE floating point value, whether regular or special, corresponding to all double and single precision hexadecimal byte patterns.

Table H.2: IEEE floating point formats.
IEEE value Double Precision Single Precision

+0 0000000000000000 00000000

denormalized 0000000000000001 00000001

to to

000FFFFFFFFFFFFF 007FFFFF

positive underflow 0010000000000000 00800000

positive numbers 0010000000000001 00800001

to to

7FEFFFFFFFFFFFFE 7F7FFFFE

positive overflow 7FEFFFFFFFFFFFFF 7F7FFFFF

$+\infty$ 7FF0000000000000 7F800000

NaN¹ 7FF0000000000001 7F800001

to to

7FFFFFFFFFFFFFFF 7FFFFFFF

-0 8000000000000000 80000000

negative 8000000000000001 80000001

denormalized to to

800FFFFFFFFFFFFF 807FFFFF

negative underflow 8010000000000000 80800000

negative numbers 8010000000000001 80800001

to to

FFEFFFFFFFFFFFFE FF7FFFFE

negative overflow FFEFFFFFFFFFFFFF FF7FFFFF

$-\infty$ FFF0000000000000 FF800000

NaN¹ FFF0000000000001 FF800001

to to

FFFFFFFFFFFFFFFF FFFFFFFF

**Table H.2:** IEEE floating point formats.
IEEE value	Double Precision	Single Precision
+0	0000000000000000	00000000
denormalized	0000000000000001	00000001
	to	to
	000FFFFFFFFFFFFF	007FFFFF
positive underflow	0010000000000000	00800000
positive numbers	0010000000000001	00800001
	to	to
	7FEFFFFFFFFFFFFE	7F7FFFFE
positive overflow	7FEFFFFFFFFFFFFF	7F7FFFFF
$+\infty$	7FF0000000000000	7F800000
NaN¹	7FF0000000000001	7F800001
	to	to
	7FFFFFFFFFFFFFFF	7FFFFFFF
-0	8000000000000000	80000000
negative	8000000000000001	80000001
denormalized	to	to
	800FFFFFFFFFFFFF	807FFFFF
negative underflow	8010000000000000	80800000
negative numbers	8010000000000001	80800001
	to	to
	FFEFFFFFFFFFFFFE	FF7FFFFE
negative overflow	FFEFFFFFFFFFFFFF	FF7FFFFF
$-\infty$	FFF0000000000000	FF800000
NaN¹	FFF0000000000001	FF800001
	to	to
	FFFFFFFFFFFFFFFF	FFFFFFFF

¹ Certain values may be designated as quiet NaN (no diagnostic when used) or signaling (produces diagnostic when used) by particular implementations.

Appendix I: Reserved extension type names

(This Appendix is not part of the NOST FITS Standard, but is included for informational purposes. It describes the extension type names registered as of the date this standard was issued.) Tables I.1 and I.2 give the currently reserved FITSextension type names. A current list is available from the FITS Support Office at

http://fits.gsfc.nasa.gov/xtension.html

ftp://nssdc.gsfc.nasa.gov/pub/fits/xtension.lis

Table I.1: Reserved extension type names.
Type Name Status Reference Sponsor Comments

'A3DTABLE' L NRAO 1990 NRAO Prototype binary table design used

in AIPS ; subset of BINTABLE.

'BINTABLE' S Cotton et al. 1995 IAU Binary table extension.

Available at FITS Archives in files

/documents/standards/bintable.aa*

of 1995-Feb.-06. Note: only main

document, excluding appendixes.

'COMPRESS' R none GSFC Suggested extension name by

A/WWW A. Warnock. Preliminary proposal

in FITS archives in the

files compress.*.

'DUMP $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ ' R none none Suggested extension name for

binary dumps.

No full proposal submitted.

'FILEMARK' R none NRAO Suggested for equivalent

of tape mark on other media.

No full proposal submitted.

'IMAGE $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ ' S Ponz et al. 1994 IAU Image extension.

'IUEIMAGE' L Muñoz 1989 IUE Local extension originally

defined for archiving

special IUE data products,

Identical to IMAGE.

'TABLE $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ ' S Harten et al. 1988 IAU ASCII table extension.

'VGROUP $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ ' R none GSFC Suggested extension name for

HDF Vgroups (D. Jennings)

No formal proposal; not used in

current HDF- FITS

conversion proposals

Table I.2.: Status codes.
Code Significance

D Draft extension proposal for discussion by regional FITS committees.

L Local FITS extension.

P Proposed FITS extension approved by regional FITS committees

but not by IAU FITS Working Group.

R Reserved type name for which a full draft proposal has not been submitted.

S Standard extension approved by IAU FITS Working Group and

endorsed by the IAU.

**Table I.2.:** Status codes.
Code	Significance
D	Draft extension proposal for discussion by regional FITS committees.
L	Local FITS extension.
P	Proposed FITS extension approved by regional FITS committees
	but not by IAU FITS Working Group.
R	Reserved type name for which a full draft proposal has not been submitted.
S	Standard extension approved by IAU FITS Working Group and
	endorsed by the IAU.

Table I.3: Acronyms in list of registered extensions.
Acronym
Meaning

NRAO
National Radio Astronomy Observatory

AIPS Astronomical Image Processing System

A/WWW A/WWW Enterprises

HDF Hierarchical Data Format

**Table I.3:** Acronyms in list of registered extensions.
Acronym	Meaning
NRAO	National Radio Astronomy Observatory
AIPS	Astronomical Image Processing System
A/WWW	A/WWW Enterprises
HDF	Hierarchical Data Format

Appendix J: NOST publications

Table J.1 lists NOST publications pertaining to the FITS Standard.

Table J.1: NOST publications.
Document Title Date Status

NOST 100-0.1 FITS Standard December, 1990 Draft Standard

NOST 100-0.2 FITS Implementation Standard June, 1991 Revised Draft Standard

NOST 100-0.3 FITS Implementation Standard December, 1991 Revised Draft Standard

NOST 100-1.0 FITS Definition Standard March, 1993 Proposed Standard

NOST 100-1.0 FITS Definition Standard June, 1993 NOST Standard

NOST 100-1.1 FITS Definition Standard June, 1995 Proposed Standard

NOST 100-1.1 FITS Definition Standard September, 1995 NOST Standard

NOST 100-1.2 FITS Definition Standard April, 1998 Draft Standard

NOST 100-2.0 FITS Definition Standard March, 1999 NOST Standard

**Table J.1:** NOST publications.
Document	Title	Date	Status
NOST 100-0.1	FITS Standard	December, 1990	Draft Standard

NOST 100-0.2	FITS Implementation Standard	June, 1991	Revised Draft Standard
NOST 100-0.3	FITS Implementation Standard	December, 1991	Revised Draft Standard
NOST 100-1.0	FITS Definition Standard	March, 1993	Proposed Standard
NOST 100-1.0	FITS Definition Standard	June, 1993	NOST Standard
NOST 100-1.1	FITS Definition Standard	June, 1995	Proposed Standard
NOST 100-1.1	FITS Definition Standard	September, 1995	NOST Standard
NOST 100-1.2	FITS Definition Standard	April, 1998	Draft Standard
NOST 100-2.0	FITS Definition Standard	March, 1999	NOST Standard

Up: Definition of the Flexible (FITS)

:=	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 $\ldots$	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
`\`0xnn	means the ASCII character associated with the hexadecimal code nn
{ $\ldots$ }	expresses a constraint or a comment (it immediately follows the syntax rule).

Type Name	Status	Reference	Sponsor	Comments
`'A3DTABLE'`	L	NRAO 1990	NRAO	Prototype binary table design used
				in AIPS ; subset of BINTABLE.

`'BINTABLE'`	S	Cotton et al. 1995	IAU	Binary table extension.
				Available at FITS Archives in files
				/documents/standards/bintable.aa*
				of 1995-Feb.-06. Note: only main
				document, excluding appendixes.

`'COMPRESS'`	R	none	GSFC	Suggested extension name by
			A/WWW	A. Warnock. Preliminary proposal
				in FITS archives in the
				files compress.*.

`'DUMP` $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ '	R	none	none	Suggested extension name for
				binary dumps.
				No full proposal submitted.

`'FILEMARK'`	R	none	NRAO	Suggested for equivalent
				of tape mark on other media.
				No full proposal submitted.

`'IMAGE` $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ '	S	Ponz et al. 1994	IAU	Image extension.

`'IUEIMAGE'`	L	Muñoz 1989	IUE	Local extension originally
				defined for archiving
				special IUE data products,
				Identical to IMAGE.

`'TABLE` $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ '	S	Harten et al. 1988	IAU	ASCII table extension.

`'VGROUP` $\includegraphics[width=3mm,clip]{espace.eps}$ $\includegraphics[width=3mm,clip]{espace.eps}$ '	R	none	GSFC	Suggested extension name for
				HDF Vgroups (D. Jennings)
				No formal proposal; not used in
				current HDF- FITS
				conversion proposals