![[*]](/icons/foot_motif.gif){kind=icon}
A&A 376, 359-380 (2001)
DOI: 10.1051/0004-6361:20010923
R. J. Hanisch1 - A. Farris1 - E. W. Greisen2 - W. D. Pence3 - B. M. Schlesinger4 - P. J. Teuben5 - R. W. Thompson6 - A. Warnock III7
1 - Space Telescope Science Institute, 3700 San Martin Drive,
Baltimore, MD 21218, USA
2 -
National Radio Astronomy Observatory
3 -
NASA Goddard Space Flight Center
4 -
Raytheon ITSS
5 -
University of Maryland
6 -
Computer Sciences Corporation
7 -
A/WWW Enterprises
Received 29 May 2001 / Accepted 21 June 2001
Abstract
The Flexible Image Transport System - FITS - has been in use in the
astronomical community for over two decades. A newly updated version
of the standard has recently been approved by the International
Astronomical Union FITS Working Group. This new version of the
standard appears here in its entirety. As a preface we briefly
describe the process by which the standard evolves and revisions are
approved, and note two minor changes to NOST 100-2.0 which were
adopted by the IAU FWG.
Key words: instrumentation: miscellaneous - methods: miscellaneous - techniques: miscellaneous - astronomical databases: miscellaneous
The Flexible Image Transport System - FITS - was originally developed in the late 1970s to enable the exchange of astronomical image data between computers of different type, with different word lengths and different means of expressing numerical values. Although the IEEE numerical formats have been widely adopted by the computer industry during the past twenty years, and in 1989 the FITS Standard was revised to utilize them, to this day computer manufacturers have yet to agree upon a single standard for bit order. In addition, independent of the numerical values themselves, a standard is essential for expressing the relationship of the data to the instrument with which they were obtained, to the position on the sky or association with wavelength, or with other general descriptive information that collectively constitutes the metadata for the observation. FITS has evolved over the years, encompassing new and more complex data structures in accord with the increasing sophistication of new astronomical instruments, and providing support for much more than the "images'' implied by the name. Images, spectra, data cubes, text tables, and binary tables are all supported, and with a variety of conventions in nomenclature and structure these basic elements have been combined to accommodate data spanning the range from digital (and digitized) images to output from computational simulations. Moreover, FITS has been immensely successful as a community-wide data format standard. No other scientific community has had anything like the success the astronomy community has had with FITS, and we are envied by many other communities for this cohesiveness. We have a process for amending and adding to the standard that assures broad community participation, and although this sometimes makes the process of change rather slow it helps to assure community support and compliance. All major astronomical software packages read and write FITS format data, and many have adopted FITS not only for exchange with other programs and facilities, but as a native run-time data format. The inherent inefficiencies of FITS (such as sequential header records, which when the allocated space is filled and a new header record is desired to be written, requires all following data to be rewritten) have been offset by the tremendous improvements in CPU and I/O efficiencies of modern desktop computers.
In 1987 NASA developed plans for the Astrophysics Data System, an integrated approach to the management of data from all astrophysics missions. Although much of the original plan for the ADS failed to be realized (the current ADS abstract and bibliographic services being a notable exception), the policy decision was reached that all NASA astrophysics mission data sets should be made available to the community in the FITS format. In 1989 the NASA/Science Office of Standards and Technology - NOST - established the FITS Support Office to assist mission data managers in formatting their data in FITS. (Responsibility for the NASA FITS Support Office transitioned to the Astrophysics Data Facility group at GSFC in 1995.) NOST also commissioned the first of the FITS Technical Panels whose task was to recast the FITS papers (published in Astronomy and Astrophysics Supplements) into a form acceptable as an official NASA standard. The first draft standard, NOST 100-0.1, was released in December 1990. Since then there have been six revisions of the NOST standard, clarifying ambiguities and adding new features with each version. The accompanying paper represents NOST 100-2.0 and contains all FITS revisions and extensions that have been approved by the IAU-FWG through the end of 1998.
The NOST Technical Panel was responsible for developing the standards documents, making these available for public review and comment, and then evaluating each comment received and making additional revisions to the standard as necessary to address the comment. All comments and the NOST Technical Panel reactions to them were posted on the Internet and distributed by e-mail to all who submitted comments. This process of open review and discussion was audited by the NOST Accreditation Panel to assure that community input was open and unrestricted, and that the Technical Panel was fully accountable to the community. Once approved by the Accreditation Panel, the NOST FITS document becomes the official NASA standard.
FITS is used world-wide in astronomy, and thus a NASA FITS standard is not the final word. Recognizing the value-added of the NOST FITS Technical Panel's work, however, the community has taken the NASA standard as both a practical working document and has officially endorsed it through regional and international organizations. There are three regional FITS committees: the North American FITS Committee, which is convened under the auspices of the Working Group on Astronomical Software of the American Astronomical Society, the European FITS Committee, and the Japanese FITS Committee. Changes to the FITS standard are voted on in these committees and then forwarded for review to the FITS Working Group of the International Astronomical Union. The IAU FWG is the final voice of approval for revisions to the standard.
The NOST Technical Panel worked hard to resolve all discrepancies between the various FITS papers and to clarify all potentially ambiguous text. Nevertheless, some areas of the document may still be unclear to some readers or may be subject to misinterpretation. It is left to future Technical Panels to continue the effort to refine and clarify the document. These Technical Panels will also need to incorporate the results of future FITS negotiations into the document, such as the anticipated World Coordinate Systems (WCS) agreements (available at http://www.cv.nrao.edu/fits/documents/wcs/).
The NOST 100-2.0 document was approved by all three of the regional FITS Committees, without dissent, during 1999 and, in a vote taken on 12 October 2000, the IAU FITS Working Group adopted the following resolution, without dissent:
The IAU FITS Working [IAU-FWG] Group adopts the "Definition of the Flexible Image Transport System (FITS)'' [NOST 100-2.0] as the official version of the FITS standards, superseding Astron. Astrophys. Suppl. 44, 363-370 (1981) and the other FITS papers listed in Sect. 2 of NOST 100-2.0, with these interpretations/modifications of its text:
- 1.
- Use of the word "deprecated'' in the first paragraph of Sect. 7 "Random Groups Structure'' is understood to mean that binary table extensions should be used in new astronomical application areas instead of the random groups format where either is appropriate and where there is no historical precedent for random groups. Existing applications of the random groups structure (almost exclusively interferometry) may continue to use random groups as needed indefinitely;
- 2.
- It is noted that the following sentence in B.2, "The size implied by the TDIMn keyword will equal the element count specified in the TFORMn keyword.'' is not valid in the case of variable length array columns. This sentence should be replaced with wording similar to the following: "The total number of elements in the array equals the product of the dimensions specified in the TDIMn keyword. This size must be equal to the repeat count on the TFORMn keyword, or, in the case of columns which have a "P'' TFORMn datatype, equal to the array length specified in the variable length array descriptor (see Appendix B.1). In the special case where the variable length array descriptor has a size of zero, then the TDIMn keyword is not applicable.''
Acknowledgements
The authors acknowledge the support of NOST, in particular, Don Sawyer, for spearheading the standardization effort. The National Space Science Data Center and Astrophysics Data Facility at NASA Goddard Space Flight Center have sponsored the FITS Support Office, staffed for many years by Barry Schlesinger and overseen by Richard A. White. The community owes immeasurable thanks to Don Wells, National Radio Astronomy Observatory, for his tireless efforts in building consensus in the FITS community and his leadership of the IAU FITS Working Group. Preben Grosbøl, European Southern Observatory, preceded Don in this role and has also provided leadership within the European community. Bill Pence (HEASARC, NASA Goddard Space Flight Center) has written the most complete FITS I/O software package and this is widely used in the community. Peter Bunclark (IoA, Cambridge) and Arnold Rots (SAO) led the development of the DATExxxx keywords for year 2000 compatibility. The authors of the original FITS papers, Don Wells, Eric Greisen, Ron Harten, Preben Grosbøl, Daniel Ponz, Randy Thompson, José Muñoz, Bill Cotton, Doug Tody, and Bill Pence, deserve great credit for their ground-breaking work and ingenuity in adapting FITS to accommodate new data structures.The members of the regional FITS committees (as of October 1999) and the IAU FITS Working Group are listed below.
North American FITS Committee Peter Teuben, Chair U. Maryland Steve Allen Lick Observatory Daniel Durand HIA/CADC Allen Farris STScI Eric Greisen NRAO Arne Henden USNO Robert Kibrick Lick Observatory William Lupton Keck Observatory Eric Mandel CfA Robert Narron IPAC William Pence NASA GSFC Jeffrey Percival U. Wisconsin Arnold Rots CfA Skip Schaller Steward Observatory Barry Schlesinger Raytheon ITSS Randall Thompson Computer Sciences Corp. Doug Tody NOAO Stephen Walton Cal. State U. Northridge Archibald Warnock A/WWW Enterprises Don Wells NRAO Robert Hanisch STScI (ex officio)
European FITS Committee Preben Grosbøl, Chair ESO Peter Bunclark IoA, Cambridge Anatoly Piskunov IoA, Russian Acad. Sci. Ernst Raimond NFRA Patrick Wallace RAL
Japanese FITS Committee Shiro Nishimura, Chair NAOJ Osamu Kanamitsu Fukuoka U. Yasuhiro Murata ISAS Eiji Nishihara NAOJ Toshiyuki Sasaki NAOJ Shigeomi Yoshida U. Tokyo
IAU FITS Working Group Don Wells, Chair USA Bill Cotton USA John Glaspey USA Eric Greisen USA Preben Grosbøl Germany (ESO) Robert Hanisch USA Don Jennings USA Osamu Kanamitsu Japan Francois Ochsenbein France William Pence USA Bruce Peterson Australia Anatoly Piskunov Russia Ernst Raimond The Netherlands Peter Teuben USA Doug Tody USA Pat Wallace UK Wayne Warren USA
Definition of the Flexible Image Transport System (FITS)
March 29, 1999
Standard
NOST 100-2.0
NASA/Science Office of Standards and Technology
Code 633.2
NASA Goddard Space Flight Center
Greenbelt, MD 20771
USA
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:
| Robert J. Hanisch, Chair, Space Telescope Science Institute, |
| William D. Pence, Secretary, NASA GSFC, |
| Barry M. Schlesinger, Past Secretary, Raytheon STX, |
| Allen Farris, Space Telescope Science Institute, |
| Eric W. Greisen, National Radio Astronomy Observatory, |
| Peter J. Teuben, University of Maryland, |
| Randall W. Thompson, Computer Sciences Corporation, |
| Archibald Warnock, A/WWW Enterprises. |
| Members of the previous Technical Panels also included: |
| Lee E. Brotzman, Hughes STX, |
| Edward Kemper, Hughes STX, |
| Michael E. Van Steenberg, NASA GSFC, |
| Wayne H. Warren Jr., Hughes STX, |
| Richard A. White, NASA Goddard Space Flight Center. |
The Flexible Image Transport System (FITS) evolved out of the recognition that a standard format was needed for transferring astronomical data from one installation to another. The original form, or Basic FITS (Wells et al. 1981), was designed for the transfer of images and consisted of a binary array, usually multidimensional, preceded by an ASCII text header with information describing the organization and contents of the array. The FITS concept was later expanded to accommodate more complex data formats. A new format for image transfer, random groups, was defined (Greisen & Harten 1981) in which the data would consist of a series of arrays, with each array accompanied by a set of associated parameters. These formats were formally endorsed by the International Astronomical Union (IAU) in 1982 (IAU Information Bulletin No. 49, 1983). Provisions for data structures other than simple arrays or groups were made later. These structures appear in extensions, each consisting of an ASCII header followed by the data whose organization it describes. A set of general rules governing such extensions (Grosbøl et al. 1988) and a particular extension, ASCII table (Harten et al. 1988), were endorsed by the IAU General Assembly in 1988 (IAU Information Bulletin No. 61, 1988). At the same General Assembly, an IAU FITS Working Group (IAUFWG) was formed (McNally 1988) under IAU Commission 5 (Astronomical Data) with the mandate to maintain the existing FITS standards and to review, approve, and maintain future extensions to FITS, recommended practices for FITS, implementations, and the thesaurus of approved FITS keywords. In 1989, the IAUFWG approved a formal agreement (Wells & Grosbøl 1990) for the representation of floating point numbers. In 1994, the IAUFWG endorsed two additional extensions, the image extension (Ponz et al. 1994) and the binary table extension (Cotton et al. 1995). FITS was originally designed and defined for 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 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 (Grosbøl & Wells 1994) governing the relation between the FITS logical record size and the physical block size for sequential media and bitstream devices. The IAUFWG also approved in 1997 an agreement (Bunclark & Rots 1997) defining a new format for encoding the date and time in the DATE, DATE-OBS, and other related DATExxxx keywords to correct the ambiguity in the original DATE keyword format beginning in the year 2000.
An 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.
The Appendixes contain material that is not part of the standard.
The first, Appendix .1, provides a formal expression
of the keyword/value syntax for header card images described in
Sect. 5.2. Appendix .2 provides examples of
widely accepted FITS conventions that are not part
of the formal FITS standard.
It describes three conventions in use with the
binary table extension - one for handling
multidimensional arrays, one for
including variable length arrays,
and one for arrays of substrings.
Appendix .6 describes aspects of the implementation of
FITS on physical media
not covered by the blocking agreement. Appendix .11 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 .12 lists
the differences between this standard and the specifications of
prior publications; it also identifies those ambiguities in the
documents endorsed by the IAU on which
this standard provides specific rules.
The next four appendixes provide reference information: a tabular
summary of the FITS keywords
(Appendix .13), a list
of the ASCII character set
and a subset designated ASCII text
(Appendix .14), a description of the
IEEE floating point format
(Appendix .15), and a list of the
extension type names
that have been reserved as of the date this document was
issued (Appendix .18). Appendix .19 is a list of
NOST documents, including earlier versions of this standard.
[The references for this document have been moved to the end of the article, in conformance with the editorial policies of the journal. This section is retained in order to maintain consistency in section numbering with the NASA Standard.]
![\includegraphics[width=3mm,clip]{espace.eps}](/articles/aa/full/2001/34/aah2901/img1.gif){kind=small}
Used to designate an ASCII blank.
).
,
underflow, overflow, denormalized,
NaN (see Appendix .15).
A FITS file shall be composed of the following FITS structures , in the order listed:
Each FITS structure shall consist of an integral number of FITS logical records. The primary HDU shall start with the first record of the FITS file. The first record of each subsequent FITS structure shall be the record immediately following the last record of the preceding FITS structure. The size of a FITS logical record shall be 23040 bits, corresponding to 2880 8-bit bytes.
shall be in the
order shown in
Fig. 1. The index count along each axis shall begin
with 1 and increment by 1 up to the value of
the NAXISn keyword (Sect. 5.4.1.1).
 |
Figure 1: 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 location of the first element, array structure is independent of record structure. |
| Open with DEXTER | |
If the data array does not fill the final record, the remainder of the record shall be filled by setting all bits to zero.
XTENSION''. It is recommended that they not contain the
string
"SIMPLE
''.
The records must have the standard FITS 23040-bit
record length. The contents of special records are not otherwise
specified by this standard.
A formal syntax, giving a complete definition of the syntax of FITS card images, is given in Appendix .1. It is intended as an aid in interpreting the text defining the standard.
'') and
hyphen
(hexadecimal 2D, "-'') are also permitted. No other characters
are permitted. For indexed
keywords with a single index
the counter shall not have leading zeroes.
=
'', it indicates the
presence of a value field associated with the keyword, unless it is
a commentary keyword as defined in
Sect. 5.4.2.4.
If the value indicator is not present or if it is a commentary keyword
then Cols. 9-80 may contain any ASCII text.
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 or free . The fixed format is required for values of mandatory keywords and recommended for values of all others. This standard imposes no requirements on case sensitivity of character strings other than those explicitly specified.
'''); the string shall follow,
starting in Col. 12, followed by a closing single quote
(also hexadecimal code 27) that should not occur before Col. 20 and
must occur in or before Col. 80. The character string
shall be composed only of ASCII text.
A single quote is represented within a string as two successive
single quotes, e.g., O'HARA = '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 Cols. 11-80. Any columns preceding the starting quote character and after Col. 10 must contain the space character.
Note that there is a subtle distinction between the following 3 keywords:
KEYWORD1= '' / null string keyword KEYWORD2= ' ' / blank keyword KEYWORD3= / undefined keyword
The value of KEYWORD1 is a null, or zero length string whereas the value of the 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 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 Cols. 11 and 80, respectively). In general, no length limit less than 68 is implied for character-valued keywords.
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 occur anywhere within Cols. 11-80.
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 occur anywhere within Cols. 11-80.
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 (Sect. 5.2.3). Such a representation is regarded as a single value for the complex integer number. This representation may be located anywhere within Cols. 11-80.
If the value is a complex floating point 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 floating point values (Sect. 5.2.4). Such a representation is regarded as a single value for the complex floating point number. This representation may be located anywhere within Cols. 11-80.
| 1 | SIMPLE |
| 2 | BITPIX |
| 3 | NAXIS |
| 4 | NAXISn, n = 1, ..., NAXIS |
| (other keywords) | |
| last | END |
The total number of bits in the primary data array,
exclusive of fill that is needed after the data to complete the last record
(Sect. 4.3.2), is given by the
following expression:
is
non-negative and the number of bits excluding fill,
m is the value of NAXIS, and
BITPIX and the NAXISn represent
the values associated with those keywords.
| Value | Data Represented |
| 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 |
All conforming extensions must use the keywords defined in Table 3 in the order specified. No other keywords may intervene between the XTENSION keyword and the last NAXISn keyword. This organization is required for any conforming extension, whether or not further specified in this standard.
| 1 | XTENSION |
| 2 | BITPIX |
| 3 | NAXIS |
| 4 | NAXISn, n = 1, ..., NAXIS |
| (other keywords, including ...) | |
| PCOUNT | |
| GCOUNT | |
| last | END |
The total number of bits in the extension data array
exclusive of fill that is needed after the data to complete the last record
such as that for the primary data array
(Sect. 4.3.2) is given by the
following expression:
is
non-negative and the number of bits excluding fill,
m is the value of NAXIS, and
BITPIX, GCOUNT,
PCOUNT, and the NAXISn
represent
the values associated with those keywords.
The 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 FITS Support Office.
The value of the 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 field contains a character string giving the date on which the HDU was created, in the form DD/MM/YY, where DD is the day of the month, MM the month number with January given by 01 and December by 12, and YY the last two digits of the year, the first two digits being understood to be 19. Specification of the date using Universal Time is recommended but not assumed.
Copying of a FITS file does not require changing any of the keyword values in the file's HDUs.
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 DATE-OBS keyword shall be expressed in the principal 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 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 .11 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 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.
The transformation equation is as follows:
BLANK
'' (ASCII blanks in
Cols. 6-8).
The value field shall contain an integer that
specifies the representation of array values
whose physical values are undefined.
These keywords are used to describe an extension and should not appear in the primary header.
Unsigned sixteen-bit integers can be represented in 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 FITS file.
The BZERO keyword (or the TZEROn keyword in the case of binary
table columns with TFORMn = 'I') must also be included in the header
with its value set to 32768 so that FITS reading software will add this
offset to the raw values in the FITS file, thus restoring them to the
original unsigned integer values. Unsigned thirty-two-bit integers can be
represented in FITS files in a similar way by applying an offset of
2147483648 (231) to the data values.
The BLANK keyword should not be used when BITPIX = -32 or -64; rather, the IEEE NaN should be used to represent an undefined value. Use of the BSCALE and BZERO keywords is not recommended.
Appendix .15 has additional details on the IEEE format.
Although it is standard FITS, the random groups structure has been used almost exclusively for applications in radio interferometry; outside this field, few FITS readers can read data in random groups format. The binary table extension (Sect. 8.3) can accommodate the structure described by random groups. While existing FITS files use the format, and it is therefore included in this standard, its use for future applications has been deprecated since the issue of Version 1 of this standard.
| 1 | SIMPLE |
| 2 | BITPIX |
| 3 | NAXIS |
| 4 | NAXIS1 |
| 5 | NAXISn, n=2, ..., value of NAXIS |
| (other keywords, which must include ...) | |
| GROUPS | |
| PCOUNT | |
| GCOUNT | |
| last | END |
The total number of bits in the random groups records
exclusive of the fill described in Sect. 7.2 is
given by the following
expression:
 = |
|
 |
(4) |
is
non-negative and the number of bits excluding fill,
m is the value of NAXIS, and
BITPIX, GCOUNT,
PCOUNT, and the NAXISn
represent
the values associated with those keywords.
FITS group parameter
value is not the true
physical value , to transform the
group parameter value to the true physical values it represents,
using Eq. (5).
The value field shall contain a floating point number representing
the coefficient of the linear term in Eq. (5), the scaling
factor between true values and group parameter values
at zero offset. The default value for this keyword is 1.0.
given
by the following
expression:
 = |
(6) |
is the number of elements in the data array in a group,
m is the value of NAXIS,
and the 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 primary data array. If the groups data do not fill the final record, the remainder of the record shall be filled with zero values in the same way as a primary data array (Sect. 4.3.2). If random groups records are present, there shall be no primary data array.
XTENSION=
'TABLE
'.
| 1 | XTENSION |
| 2 | BITPIX |
| 3 | NAXIS |
| 4 | NAXIS1 |
| 5 | NAXIS2 |
| 6 | PCOUNT |
| 7 | GCOUNT |
| 8 | TFIELDS |
| (other keywords, which must include ...) | |
| TBCOLn, n=1, 2, ..., k where k is the value | |
| of TFIELDS | |
| TFORMn, n=1, 2, ..., k where k is the value | |
| of TFIELDS | |
| last | END |
'IMAGE
'
| Field Value | Data Type |
| Aw | Character |
| Iw | Decimal integer |
| Fw.d | Single precision real |
| Ew.d | Single precision real, exponential notation |
| Dw.d | Double precision real, exponential notation |
The transformation equation used to compute a true
physical value from the quantity in field n is
The value of a character-formatted (Aw) field is a
character string of width w containing the characters in columns
TBCOLn through TBCOLn
.
The value of an integer-formatted (Iw) field is an
integer number determined by removing all blanks from columns
TBCOLn through TBCOLn
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 ("0'' through "9'')
and a single leading sign character ("+'' and "-'') are
forbidden.
The value of a real-formatted field (Fw.d,
Ew.d, Dw.d) is a real number determined
from the w characters from columns TBCOLn through
TBCOLn
.
The value is formed by
.
The
default exponent is zero and a blankfield has value zero. There is
no difference between the F, D, and 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 D
format in TFORMn 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 .15).
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. 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 FITS writing tasks
write tables with explicit decimal points and no embedded or trailing
blanks whenever possible.
=
XTENSION=
'
IMAGE+
'.
| 1 | XTENSION |
| 2 | BITPIX |
| 3 | NAXIS |
| 4 | NAXISn, n = 1, ..., NAXIS |
| 5 | PCOUNT |
| 6 | GCOUNT |
| (other keywords ...) | |
| last | END |
'IMAGE
'.
XTENSION=
'
BINTABLE'.
The XTENSION keyword is the first keyword of all binary table extensions. The seven keywords following (BITPIX ...TFIELDS) must be in the order specified in Table 8, with no intervening keywords.
| 1 | XTENSION |
| 2 | BITPIX |
| 3 | NAXIS |
| 4 | NAXIS1 |
| 5 | NAXIS2 |
6 |
PCOUNT |
| 7 | GCOUNT |
| 8 | TFIELDS |
| (other keywords, which must include ...) | |
| TFORMn, n=1, 2, ..., k where k is the value | |
| of TFIELDS | |
| last | END |
'BINTABLE'.
in a table row, given by
| TFORMn | 8-bit | |
| value | Description | Bytes |
| L | Logical | 1 |
| X | Bit | * |
| B | Unsigned byte | 1 |
| I | 16-bit integer | 2 |
| J | 32-bit integer | 4 |
| A | Character | 1 |
| E | Single precision floating point | 4 |
| D | Double precision floating point | 8 |
| C | Single precision complex | 8 |
| M | Double precision complex | 16 |
| P | Array Descriptor | 8 |
* Number of 8-bit bytes needed to contain all bits.
| Field Value | Data Type |
| Aw | Character |
| Lw | Logical |
| Iw.m | Integer |
| Bw.m | Binary, integers only |
| Ow.m | Octal, integers only |
| Zw.m | Hexadecimal, integers only |
| Fw.d | Single precision real |
| Ew.dEe | Single precision real, exponential notation |
| ENw.d | Engineering; E format with exponent multiple of 3 |
| ESw.d | Scientific; same as EN but nonzero leading digit if not zero |
| Gw.dEe | General; appears as F if significance not lost, else E. |
| Dw.dEe | Double precision real, exponential notation |
The main data table shall be followed by zero or more bytes, as specified by the value of the PCOUNT keyword. The meaning of these bytes is not further defined by this standard. One proposed application is described in Appendix .3.
Integer data (including bit X and byte B type fields)
are encoded under format codes Iw.m,
Bw.m, Ow.m, and Zw.m. The
default value of m is one and the ".m'' is optional. The
first letter of the code specifies the number base for the encoding
with I for decimal (10), B for binary (2), O for
octal (8), and 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 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 m numeric
digits. Note that m 
w is allowed if all values are
positive,
but m < w is required if any values are negative.
If the number of
digits required to represent the integer datum exceeds w, then the
output field consists of a string of w asterisk (*)
characters.
Real data are encoded under format codes Fw.d,
Ew.dEe, Dw.dEe,
ENw.d, and ESw.d. In all cases, the output
is a string of 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 w, then the output field consists of a string of
w asterisk (*) characters. In all cases, d specifies the
number of digits to appear to the right of the decimal point. The
F format code output field consists of
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 (".'') and d
characters giving the fractional part of the internal datum, rounded
by the normal rules of arithmetic to d fractional digits. For the
E and D format codes, an exponent is taken such that the
fraction
.
The fraction (with
appropriate sign) is output with an F format of width
characters with d characters after the decimal followed by an E
or D followed by the exponent as a signed
character
integer
with leading zeros as needed. The default value of e is 2
when the Ee portion of the format code is omitted. If
the exponent value will not fit in
characters but will fit in
then the E (or D) is omitted and the wider field
used. If the exponent value will not fit (with a sign character) in
characters, then the entire w-character output field is
filled
with asterisks (*). The ES format code is processed in
the same manner as the E format code except that the exponent is
taken so that
.
The EN format code is
processed in the same manner as the E format code except that
the exponent is taken to be an integer multiple of 3 and so that
.
All real format codes have number base
10. There is no difference between E and D format codes
on input other than an implication with the latter of
greater precision in the internal datum.
The Gw.dEe format code may be used with
data of any type. For data of type integer, logical, or character, it
is equivalent to Iw, Lw, or
Aw, respectively. For data of type real, it is
equivalent to an F format (with different numbers of characters
after the decimal) when that format will accurately represent the value
and is equivalent to an E format when the number (in absolute
value) is either very small or very large. Specifically, for real
values outside the range
,
it is
equivalent to Ew.dEe. For real values
within the above range, it is equivalent to
F
followed by
blanks, where
and
for
if the real datum value lies in the range
.
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
.
(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 |
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 |
| {} |
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 :=
`!'-`~'
value :=
character_string_value | logical_value | integer_value |
floating_value | complex_integer_value |
7 complex_floating_value
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
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
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;
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
.
For example,
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:
[field N-1] [(nelem,offset)] [field N+1]
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
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
.
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
,
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.
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
'. Arrays of character strings, i.e.,
multidimensional character arrays, may be represented using the
TDIMn notation. For example, if TFORMn = '60A
'
and TDIMn = '(5,4,3)', then the entry consists of a
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.
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,To illustrate this usage:
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
/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.
'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:
'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;
TFORMn = 'rPA(
):SSTRw/nnn'
and
TFORMn = 'rPA(
):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.
(This Appendix is not part of the NOST FITS Standard, but is included as a guide to recommended practices.)
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.
[Not part of formal DATExxxx agreement]
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.
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
(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.
The standard states that in general, character-valued keywords can have lengths up to the maximum 68 character length.
- The requirement
that
may not be negative
is not explicitly specified in the FITS papers.
| Principal | Conforming | ASCII Table | Image | Binary Table | Random Groups |
| HDU | Extension | Extension | Extension | Extension | Records |
| SIMPLE | XTENSION | XTENSION1 | XTENSION2 | XTENSION3 | SIMPLE |
| BITPIX | BITPIX | BITPIX = 8 |
BITPIX | BITPIX = 8 |
BITPIX |
| NAXIS | NAXIS | NAXIS = 2 |
NAXIS | NAXIS = 2 |
NAXIS |
| NAXISn4 | NAXISn4 | NAXIS1 | NAXISn4 | NAXIS1 | NAXIS1 = 0 |
| EXTEND5 | PCOUNT | NAXIS2 | PCOUNT = 0 |
NAXIS2 | NAXISn4 |
| END | GCOUNT | PCOUNT = 0 |
GCOUNT = 1 |
PCOUNT | GROUPS = T |
| END | GCOUNT = 1 |
END | GCOUNT = 1 |
PCOUNT | |
| TFIELDS | TFIELDS | GCOUNT | |||
| TBCOLn6 | TFORMn6 | END | |||
| TFORMn6 | END | ||||
| END |
1 XTENSION= 'TABLE' for the
ASCII table extension.
2 XTENSION= 'IMAGE' for the
image extension .
3 XTENSION= 'BINTABLE' for the binary table
extension .
4 Runs from 1 through the value of NAXIS.
5 Required only if extensions are present.
6 Runs from 1 through the value of TFIELDS.
| All | Array1 | 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 |
| BLOCKED2 | BUNIT | EXTLEVEL | TNULLn | TNULLn | PZEROn |
| AUTHOR | BLANK | TTYPEn | TTYPEn | ||
| REFERENC | CTYPEn | TUNITn | TUNITn | ||
| COMMENT | CRPIXn | TDISPn | |||
| HISTORY | CROTAn | TDIMn | |||
|
CRVALn | THEAP | |||
| DATE-OBS | CDELTn | ||||
| TELESCOP | DATAMAX | ||||
| INSTRUME | DATAMIN | ||||
| OBSERVER | |||||
| OBJECT | |||||
| EQUINOX | |||||
| EPOCH2 |
1 Primary HDU, image extension, user-defined HDUs with same array
structure.
2 Deprecated.
| Production | Bibliographic | Commentary | Observation |
| DATE | AUTHOR | COMMENT | DATE-OBS |
| ORIGIN | REFERENC | HISTORY | TELESCOP |
| BLOCKED1 | |
INSTRUME | |
| OBSERVER | |||
| OBJECT | |||
| EQUINOX | |||
| EPOCH1 |
1 Deprecated.
(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.
| 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 | DEL1 |
1 Not ASCII Text
(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.
and 
, inclusive, and
also two other reserved values
to encode 
and
denormalized numbers, and +1 to encode and
NaNs. The foregoing parameters are given in Table .6.
Each nonzero numerical value has just one encoding. The fields are
interpreted as follows:
| Format | ||||
| Parameter | Single | Double | ||
| Single | Extended | Double | Extended | |
| p | 24 |  |
53 |  |
|
+127 |
 |
+1023 |
 |
|
-126 |
 |
-1022 |
 |
| Exponent bias | +127 | unspecified | +1023 | unspecified |
| Exponent width in bits | 8 |  |
11 |  |
| Format width in bits | 32 |  |
64 |  |
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
,
then v is NaN regardless of s
,
then
(denormalized numbers)
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
,
then v is NaN regardless of s
,
then
(denormalized numbers)
Table .7 shows the types of IEEE floating point value,
whether regular or special, corresponding to all double and single
precision hexadecimal byte patterns.
| 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 |
 |
7FF0000000000000 | 7F800000 |
| NaN1 | 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 |
 |
FFF0000000000000 | FF800000 |
| NaN1 | FFF0000000000001 | FF800001 |
| to | to | |
| FFFFFFFFFFFFFFFF | FFFFFFFF |
1 Certain values may be designated as quiet NaN (no diagnostic
when used) or signaling (produces diagnostic when used) by
particular implementations.
http://fits.gsfc.nasa.gov/xtension.html
or
ftp://nssdc.gsfc.nasa.gov/pub/fits/xtension.lis
| 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. |
Acronym |
Meaning |
NRAO |
National Radio Astronomy Observatory |
| AIPS | Astronomical Image Processing System |
| A/WWW | A/WWW Enterprises |
| HDF | Hierarchical Data Format |
| 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 |
