AFT

Definition of the Flexible Image Transport System(FITS)The FITS Standard

DR

Version 4.0: updated 2016 July 22 by the IAUFWG
Document publication date: 2016 July 22

FITS Working Group 1
Commission 5: Documentation and Astronomical Data 2International Astronomical Union
http://fits.gsfc.nasa.gov/iaufwg/

1
2

to be absorbed in Data Representation Working Group under new Commission B2
now Commission B2 Data and Documentation
1

0

DR

AF
T

i

Contentsi

1 Introduction
1.1 Brief history of FITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Version history of this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
1
1
2

2 Definitions, acronyms, and symbols
2.1 Conventions used in this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Defined terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33
3

3 FITS file organization
3.1 Overall file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Individual FITS Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Primary header and data unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Primary header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Primary data array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Requirements for conforming extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.2 Standard extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.3 Order of extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Special records (restricted use) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Physical blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.1 Bitstream devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.2 Sequential media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.7 Restrictions on changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4
4
4
4
4
5
5
5
5
5
5
5
5
6
6

4 Headers
4.1 Keyword records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Character string . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Logical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3 Integer number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4 Real floating-point number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.5 Complex integer number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.6 Complex floating-point number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.7 Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Construction of units strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Units in comment fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Mandatory keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Other reserved keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 Additional keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6
6
6
6
7
7
8
8
8
8
8
9
9
10
10
11
11
12
15

5 Data Representation
5.1 Characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Eight-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Sixteen-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Thirty-two-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4 Sixty-four-bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5 Unsigned integers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 IEEE-754 floating point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16
16
16
16
16
16
16
16
16
16

DR

AF
T

Contents

i

ii
16
16
16
17
17
17

7 Standard extensions
7.1 Image extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1 Mandatory keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.2 Other reserved keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.3 Data sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 The ASCII table extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1 Mandatory keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2 Other reserved keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.3 Data sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.4 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.5 Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Binary table extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Mandatory keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2 Other reserved keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.3 Data sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.4 Data display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.5 Variable-length arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.6 Variable-length-array guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18
18
18
18
18
18
18
19
21
21
21
22
22
22
25
26
27
28

8 World coordinate systems
8.1 Basic concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 World coordinate system representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1 Alternative WCS axis descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Celestial coordinate system representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4 Spectral coordinate system representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.1 Spectral coordinate reference frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.5 Conventional coordinate types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28
29
30
32
33
34
34
35

9 Representations of time coordinates
9.1 Time values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.1 ISO-8601 datetime strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.2 Julian and Besselian epochs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Time coordinate frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Time scale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2 Time reference value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.3 Time reference position . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.4 Time reference direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.5 Solar System Ephemeris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Time unit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4 Time offset, binning, and errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4.1 Time offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4.2 Time resolution and binning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4.3 Time errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.5 Global time keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.6 Other time coordinate axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.7 Durations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.8 Recommended best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.8.1 Global keywords and overrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.8.2 Restrictions on alternate descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.8.3 Image time axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36
36
36
37
37
37
37
38
40
40
40
41
41
41
41
41
42
42
43
43
43
43

DR

AF
T

6 Random groups structure
6.1 Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Mandatory keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Reserved keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Data sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Data representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ii

iii
43
43
44
44
45
46
46
47
47
47
48
48
49
49
49
49
49
49
50
50

A Syntax of keyword records

52

B Suggested time scale specification
C Summary of keywords
D ASCII text

AF
T

10 Representations of compressed data
10.1 Tiled Image Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1.1 Required Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1.2 Other Reserved Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.1.3 Table Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Quantization of Floating-Point Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.1 Dithering Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.2 Preserving undefined pixels with lossy compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Tiled Table Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.1 Required Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.2 Procedure for Table Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.3 Compression Directive Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.4 Other Reserved Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.5 Supported Compression Algorithms for Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3.6 Compressing Variable-Length Array Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4 Compression Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4.1 Rice compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4.2 GZIP compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4.3 IRAF/PLIO compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.4.4 H-Compress algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53
54
55
55
55
56
56
56

F Reserved extension type names
F.1 Standard extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.2 Conforming extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F.3 Other suggested extension names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58
58
58
58

G MIME types
G.1 MIME type ‘application/fits’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.1.1 Recommendations for application writers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.2 MIME type ‘image/fits’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.2.1 Recommendations for application writers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G.3 File extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58
58
59
59
59
60

H Past changes or clarifications to the formal definition of FITS
H.1 Differences between the requirements in this standard and the requirements in the original FITS papers. . . . . . .
H.2 List of modification to the FITS standard, version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H.3 List of modifications to the latest FITS standard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60
60
60
61

I

61

DR

E IEEE floating-point formats
E.1 Basic formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.1.1 Single . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.1.2 Double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E.2 Byte patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Random Number Generator

J CHECKSUM Implementation Guidelines
J.1 Recommended CHECKSUM Keyword Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
J.2 Recommended ASCII Encoding Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
J.3 Encoding Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
J.4 Incremental Updating of the Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
J.5 Example C Code for Accumulating the Checksum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
J.6 Example C Code for ASCII Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62
62
62
63
63
63
64

K Header inheritance convention

64
iii

iv
L Green Bank convention

64

References / Index

65

List of Tables

iv

AF
T

Significant milestones in the development of FITS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Version history of the standard. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IAU-recommended basic units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Additional allowed units. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Prefixes for multiples and submultiples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Characters and strings allowed to denote mathematical operations. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mandatory keywords for primary header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretation of valid BITPIX value. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example of a primary array header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mandatory keywords in conforming extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage of BZERO to represent non-default integer data types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mandatory keywords in primary header preceding random groups. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mandatory keywords in image extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mandatory keywords in ASCII table extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Valid TFORMn format values in TABLE extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Valid TDISPn format values in TABLE extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Valid TFORMn data types in BINTABLE extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mandatory keywords in binary table extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Usage of TZEROn to represent non-default integer data types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Valid TDISPn format values in BINTABLE extensions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WCS and celestial coordinates notation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserved WCS keywords (continues on next page) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserved celestial coordinate algorithm codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Allowed values of RADESYSa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserved spectral coordinate type codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Non-linear spectral algorithm codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Spectral reference systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example keywords for a 100 element array of complex values. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Conventional Stokes values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recognized Time Scale Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Standard Time Reference Position Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Compatibility of Time Scales and Reference Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Valid solar system ephemerides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recommended time units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Keywords for global time values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Valid mnemonic values for the ZCMPTYPE and ZCTYPn keywords . . . . . . . . . . . . . . . . . . . . . . . . . . .
Keyword parameters for Rice compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PLIO Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Keyword parameters for H-compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mandatory FITS keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reserved FITS keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General reserved FITS keywords. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASCII character set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of format parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IEEE floating-point formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DR

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
18
17
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
C.1
C.2
C.3
D.1
E.1
E.2

2
2
8
9
10
10
10
11
12
12
15
17
18
19
19
20
22
23
24
25
30
31
33
34
35
35
36
36
36
38
39
39
40
41
42
49
50
50
51
54
54
54
55
56
57

1

1. Introduction

AF
T

An archival format must be utterly portable and selfdescribing, on the assumption that, apart from the transcription device, neither the software nor the hardwarethat wrote the data will be available when the data
are read. ‘Preserving Scientific Data on our Physical
Universe,’ p. 60. Steering Committee for the Studyon the Long-Term Retention of Selected Scientific andTechnical Records of the Federal Government, [US]National Research Council, National Academy Press
1995.

an image interchange format was raised at a meeting of the
Astronomy section of the U.S. National Science Foundation in
January 1979, which led to the formation of a task force towork on the problem. Most of the technical details of the firstbasic FITS agreement (with files consisting of only a primaryheader followed by a data array) were subsequently developed
by Don Wells and Eric Greisen (NRAO) in March 1979. After
further refinements, and successful image interchange tests between observatories that used widely different types of computer
systems, the first papers that defined the FITS format were published in 1981 (Wells et al. 1981; Greisen & Harten 1981). The
FITS format quickly became the defacto standard for data interchange within the astronomical community (mostly on 9-trackmagnetic tape at that time) and was officially endorsed by the
IAU in 1982 (IAU 1983). Most national and international astronomical projects and organizations subsequently adopted the
FITS format for distribution and archiving of their scientific data
products. Some of the highlights in the developmental history of
FITS are shown in Table 1.

DR

This document, hereafter referred to as the ‘standard’, describes the Flexible Image Transport System (FITS) which isthe standard archival data format for astronomical data sets.
Although FITS was originally designed for transporting image
data on magnetic tape (which accounts for the ‘I’ and ‘T’ in thename), the capabilities of the FITS format have expanded to accommodate more complex data structures. The role of FITS has
also grown from simply a way to transport data between different analysis software systems into the preferred format for datain astronomical archives, as well as the on-line analysis format
used by many software packages.
This standard is intended as a formal codification of the
FITS format which has been endorsed by the International
Astronomical Union (IAU) for the interchange of astronomical
data (IAU 1983). It is fully consistent with all actions and endorsements of the IAU FITS Working Group (IAUFWG) which
was appointed by Commission 5 of the IAU to oversee further
development of the FITS format. In particular, this standard defines the organization and content of the header and data units forall standard FITS data structures: the primary array, the random
groups structure, the image extension, the ASCII table extension,and the binary table extension. It also specifies minimum structural requirements and general principles governing the creationof new extensions. For headers, it specifies the proper syntax for
keyword records and defines required and reserved keywords.
For data, it specifies character and numeric value representations
and the ordering of contents within the byte stream.
One important feature of the FITS format is that its structure, down to the bit level, is completely specified in documents(such as this standard), many of which have been published inrefereed scientific journals. Given these documents, which arereadily available in hard copy form in libraries around the world
as well as in electronic form on the Internet, future researchers
should be able to decode the stream of bytes in any FITS format
data file. In contrast, many other current data formats are only
implicitly defined by the software that reads and writes the files.
If that software is not continually maintained so that it can be
run on future computer systems, then the information encodedin those data files could be lost.
1.1. Brief history of FITS

The FITS format evolved out of the recognition that a standard
format was needed for transferring astronomical images fromone research institution to another. The first prototype developments of a universal interchange format that would eventually lead to the definition of the FITS format began in 1976 between Don Wells at KPNO and Ron Harten at the Netherlands
Foundation for Research in Astronomy (NFRA). This need for1.2. Version history of this document

The fundamental definition of the FITS format was originallycontained in a series of published papers (Wells et al. 1981;
Greisen & Harten 1981; Grosbøl et al. 1988; Harten et al.
1988). As FITS became more widely used, the need for a single document to unambiguously define the requirements of the
FITS format became apparent. In 1990, the NASA Science
Office of Standards and Technology (NOST) at the Goddard
Space Flight Center provided funding for a technical panel todevelop the first version of this standard document. As shownin Table 2, the NOST panel produced several draft versions,culminating in the first NOST standard document, NOST 1001.0, in 1993. Although this document was developed under aNASA accreditation process, it was subsequently formally approved by the IAUFWG, which is the international control authority for the FITS format. The small update to the standard in1995 (NOST 100-1.1) added a recommendation on the physicalunits of header keyword values.
The NOST technical panel was convened a second time tomake further updates and clarifications to the standard, resulting
in the NOST 100-2.0 version that was approved by the IAUFWG
in 1999 and published in 2001 (Hanisch et al. 2001). In 2005,
the IAUFWG formally approved the variable-length array convention in binary tables, and a short time later approved support for the 64-bit integers data type. New versions of the standard were released to reflect both of these changes (versions
IAUFWG 2.1 and IAUFWG 2.1b).
In early 2007 the IAUFWG appointed its own technical panel
to consider further modifications and updates to the standard.
The changes proposed by this panel, which were ultimately approved in 2008 by the IAUFWG after a formal public review
process, are shown in the 3.0 version of the document, publishedin Pence et al. (2010).
Since 2006 a Registry for FITS conventions submitted by thecommunity was established care of the IAUFWG at http://
fits.gsfc.nasa.gov/fits_registry.html. The Registry
was intended as a repository of documentation of usages which,although not endorsed as part of the FITS standard, are otherwise perfectly legal usages of FITS. In 2014 a small team wasformed to evaluate the possible incorporation of some conven1

2
Table 1: Significant milestones in the development of FITS.
Milestone
Initial FITS Agreement and first interchange of files
Published original (single HDU) definition (Wells et al. 1981)
Published random groups definition (Greisen & Harten 1981)
Formally endorsed by the IAU (IAU 1983)
Defined rules for multiple extensions (Grosbøl et al. 1988)
IAU FITS Working Group (IAUFWG) established
Extended to include ASCII table extensions (Harten et al. 1988)
Formal IAU approval of ASCII tables (IAU 1988)
Extended to include IEEE floating-point data (Wells & Grosbøl 1990)
Extended to multiple IMAGE array extensions (Ponz et al. 1994)
Extended to binary table extensions (Cotton et al. 1995)
Adopted 4-digit year date format (Bunclark & Rots 1997)
Adopted proposals for world coordinate systems (Greisen & Calabretta 2002)
Adopted proposals for celestial coordinates (Calabretta & Greisen 2002)
Adopted MIME types for FITS data files (Allen & Wells 2005)
Extended to support variable-length arrays in binary tables
Adopted proposals for spectral coordinate systems (Greisen et al. 2006)
Extended to include 64-bit integer data type
Adopted WCS HEALPix projection (Calabretta & Roukema 2007)
Established FITS convention registry
Adopted proposals for time coordinates (Rots et al. 2015)
Adopted proposals for compressed data
Adopted various registered conventions

AF
T

Date
1979
1981
1981
1982
1988
1988
1988
1988
1990
1994
1995
1997
2002
2002
2004
2005
2005
2005
2006
2006
2014
2016
2016

SectionSect. 6

Sect. 7.2
Sect. 7.2
Sect. 5.3
Sect. 7.1
Sect. 7.3
Sect. 4.4.2
Sect. 8
Sect. 8.3
App. G
Sect. 7.3.5
Sect. 8.4
Sect. 5.2.4
Sect. 8.3
Sect. 9Sect. 10
App. H.3

Table 2: Version history of the standard.
Date1990 December
1991 June
1991 December
1993 June
1995 September
1999 March
2005 April
2005 December
2008 July
2016 JulyDR

VersionNOST 100-0.1
NOST 100-0.2
NOST 100-0.3
NOST 100-1.0
NOST 100-1.1
NOST 100-2.0
IAUFWG 2.1
IAUFWG 2.1b
IAUFWG 3.0
IAUFWG 4.0

tions within the standard, as an offspring from a larger task force
in charge of proposing other updates to the standard (like e.g.
long keyword names and an extended character set), while another small team was in charge to update the standard documentwith a summary of the WCS time representation (Rots et al.
2015) which in the meanwhile had been voted natively as partof the FITS standard.

Details on the conventions incorporated (CONTINUE long
string keywords, blank header space, CHECKSUM, column limits,tiled image and table compression) or just mentioned (keyword
inheritance and Green Bank conventions) in the latest standard
is reported in Appendix H.3, which also lists the affected partsof the standard.

The latest version of the standard, as well as other information about the FITS format, can be obtained from the
FITS Support Office web site at http://fits.gsfc.nasa.
gov. This web site also contains the contact information for the
Chairman of the IAUFWG, to whom any questions or comments
regarding this standard should be addressed.
2

StatusFirst Draft Standard
Second Revised Draft Standard
Third Revised Draft Standard
NOST Standard
NOST Standard
NOST Standard
IAUFWG Standard
IAUFWG Standard
IAUFWG Standard
IAUFWG Standard

1.3. Acknowledgments

The members of the three technical panels that produced thisstandard are shown below.
First technical panel, 1990 – 1993
Robert J. Hanisch (Chair) Space Telescope Science Inst.
Lee E. Brotzman
Hughes STX
Edward Kemper
Hughes STX
Barry M. Schlesinger
Raytheon STXPeter J. Teuben
University of Maryland
Michael E. Van Steenberg NASA Goddard SFC
Wayne H. Warren Jr.
Hughes STX
Richard A. White
NASA Goddard SFC
Second technical panel, 1994 – 1999
Robert J. Hanisch (Chair) Space Telescope Science Inst.
Allen Farris
Space Telescope Science Inst.
Eric W. Greisen
National Radio Astr. Obs.
William D. Pence
NASA Goddard SFC
Barry M. Schlesinger
Raytheon STXPeter J. Teuben
University of Maryland
Randall W. Thompson
Computer Sciences Corp.
Archibald Warnock
A/WWW Enterprises

3
Third technical panel, 2007
William D. Pence (Chair) NASA Goddard SFC
Lucio Chiappetti
IASF Milano, INAF, Italy
Clive G. Page
University of Leicester, UK
Richard Shaw
National Optical Astr. Obs.
Elizabeth Stobie
University of ArizonaAF
T

Dedicated task forces, 2013-2016
Lucio Chiappetti
IASF Milano, INAF, Italy
Steve AllenUCO Lick Observatory
Adam Dobrzycki
European Southern Observatory
William D. Pence
NASA Goddard SFC
Arnold Rots
Harvard Smithsonian CfARichard Shaw
National Optical Astr. Obs.
William T. Thompson
NASA Goddard SFC

2. Definitions, acronyms, and symbols
2.1. Conventions used in this document

DR

Terms or letters set in Courier font represent literal strings
that appear in FITS files. In the case of keyword names, suchas ‘NAXISn’, the lower case letter represents a positive integerindex number, generally in the range 1 to 999. The emphasizedwords must, shall, should, may, recommended, and optional inthis document are to be interpreted as described in IETF standard, RFC 2119 (Bradner 1997).
2.2. Defined terms

Byte An ordered sequence of eight consecutive bits treated as asingle entity.
Card image An obsolete term for an 80-character keyword
record derived from the 80-column punched computer cards
that were prevalent in the 1960s and 1970s.
Character string A sequence of one or more of the restricted
set of ASCII text characters, decimal 32 through 126 (hexadecimal 20 through 7E).
Conforming extension An extension whose keywords and organization adhere to the requirements for conforming extensions defined in Sect. 3.4.1 of this standard.
Data block A 2880-byte FITS block containing data describedby the keywords in the associated header of that HDU.
Deprecate To express disapproval of. This term is used to refer
to obsolete structures that should not be used in new FITS
files but which shall remain valid indefinitely.
Entry A single value in an ASCII table or binary table standard
extension.
Extension A FITS HDU appearing after the primary HDU in a
FITS file.
Extension type name The value of the XTENSION keyword,
used to identify the type of the extension.
Field A component of a larger entity, such as a keyword record
or a row of an ASCII table or binary table standard extension.
A field in a table extension row consists of a set of zero or
more table entries collectively described by a single format.
File A sequence of one or more records terminated by an endof-file indicator appropriate to the medium.
FITS Flexible Image Transport System.
FITS block A sequence of 2880 8-bit bytes aligned on 2880
byte boundaries in the FITS file, most commonly either aheader block or a data block. Special records are another infrequently used type of FITS block. This block length waschosen because it is evenly divisible by the byte and word
lengths of all known computer systems at the time FITS wasdeveloped in 1979.
FITS file A file with a format that conforms to the specificationsin this document.
FITS structure One of the components of a FITS file: the primary HDU, the random groups records, an extension, or, collectively, the special records following the last extension.
FITS Support Office The FITS information web site that ismaintained by the IAUFWG and is currently hosted at
http://fits.gsfc.nasa.gov.
Floating point A computer representation of a real number.
Fraction The field of the mantissa (or significand) of a floatingpoint number that lies to the right of its implied binary point.
Group parameter value The value of one of the parameters
preceding a group in the random groups structure, without
the application of the associated linear transformation.
HDU Header and Data Unit. A data structure consisting of aheader and the data the header describes. Note that an HDU
may consist entirely of a header with no data blocks.
Header A series of keyword records organized within one ormore header blocks that describes structures and/or data
which follow it in the FITS file.
Header block A 2880-byte FITS block containing a sequenceof thirty-six 80-character keyword records.
Heap The supplemental data area following the main data table
in a binary table standard extension.
IAU International Astronomical Union.

Used to designate an ASCII space character.
ANSI American National Standards Institute.
Array A sequence of data values. This sequence corresponds
to the elements in a rectilinear, n-dimension matrix (1 ≤ n ≤999, or n = 0 in the case of a null array).
Array value The value of an element of an array in a FITS file,
without the application of the associated linear transformation to derive the physical value.
ASCII American National Standard Code for Information
Interchange.
ASCII character Any member of the 7-bit ASCII character set.
ASCII digit One of the ten ASCII characters ‘0’ through ‘9’which are represented by decimal character codes 48 through57 (hexadecimal 30 through 39).
ASCII NULL The ASCII character that has all eight bits set tozero.
ASCII space The ASCII character for space which is represented by decimal 32 (hexadecimal 20).
ASCII text The restricted set of ASCII characters decimal 32
through 126 (hexadecimal 20 through 7E).
Basic FITS The FITS structure consisting of the primaryheader followed by a single primary data array. This is also
known as Single Image FITS (SIF), as opposed to MultiExtension FITS (MEF) files that contain one or more extensions following the primary HDU.
Big endian The numerical data format used in FITS files inwhich the most significant byte of the value is stored first
followed by the remaining bytes in order of significance.
Bit A single binary digit.

3

4
dard, namely, an image extension, an ASCII table extension,or a binary table extension.

3. FITS file organization
3.1. Overall file structure

A FITS file shall be composed of the following FITS structures,in the order listed:– Primary header and data unit (HDU).
– Conforming Extensions (optional).
– Other special records (optional, restricted).

DR

AF
T

IAUFWG International Astronomical Union FITS Working
Group.
IEEE Institute of Electrical and Electronic Engineers.
IEEE NaN IEEE Not-a-Number value; used to represent undefined floating-point values in FITS arrays and binary tables.
IEEE special values Floating-point number byte patterns
that have a special, reserved meaning, such as −0, ±∞,±underflow, ±overflow, ±denormalized, ±NaN. (SeeAppendix E).
Indexed keyword A keyword name that is of the form of a
fixed root with an appended positive integer index number.
Keyword name The first eight bytes of a keyword record whichcontain the ASCII name of a metadata quantity (unless it isblank).
Keyword record An 80-character record in a header block consisting of a keyword name in the first eight characters followed by an optional value indicator, value and comment
string. The keyword record shall be composed only of therestricted set of ASCII text characters ranging from decimal
32 to 126 (hexadecimal 20 to 7E).
Mandatory keyword A keyword that must be used in all FITS
files or a keyword required in conjunction with particular
FITS structures.
Mantissa Also known as significand. The component of anIEEE floating-point number consisting of an explicit or implicit leading bit to the left of its implied binary point and afraction field to the right.
MEF Multi-Extension FITS, i.e., a FITS file containing a primary HDU followed by one or more extension HDUs.
NOST NASA/Science Office of Standards and Technology.
Physical value The value in physical units represented by anelement of an array and possibly derived from the array value
using the associated, but optional, linear transformation.
Pixel Short for ‘Picture element’; a single location within anarray.
Primary data array The data array contained in the primary
HDU.
Primary HDU The first HDU in a FITS file.
Primary header The first header in a FITS file, containing information on the overall contents of the file (as well as on the
primary data array, if present).
Random Group A FITS structure consisting of a collection of‘groups’, where a group consists of a subarray of data and aset of associated parameter values. Random groups are deprecated for any use other than for radio interferometry data.
Record A sequence of bits treated as a single logical entity.
Repeat count The number of values represented in a field in abinary table standard extension.
Reserved keyword An optional keyword that must be used
only in the manner defined in this standard.
SIF Single Image FITS, i.e., a FITS file containing only a primary HDU, without any extension HDUs. Also known as
Basic FITS.
Special records A series of one or more FITS blocks following
the last HDU whose internal structure does not otherwise
conform to that for the primary HDU or to that specified
for a conforming extension in this standard. Any use of special records requires approval from the IAU FITS Working
Group.
Standard extension A conforming extension whose header anddata content are completely specified in Sect. 7 of this stan-

4

A FITS file composed of only the primary HDU is sometimes
referred to as a Basic FITS file, or a Single Image FITS (SIF)
file, and a FITS file containing one or more extensions following
the primary HDU is sometimes referred to as a Multi-Extension
FITS (MEF) file.
Each FITS structure shall consist of an integral number of
FITS blocks which are each 2880 bytes (23040 bits) in length.
The primary HDU shall start with the first FITS block of the
FITS file. The first FITS block of each subsequent FITS structure shall be the FITS block immediately following the last FITS
block of the preceding FITS structure.
This standard does not impose a limit on the total size of a
FITS file, nor on the size of an individual HDU within a FITS
file. Software packages that read or write data according to thisstandard could be limited, however, in the size of files that aresupported. In particular, some software systems have historically
only supported files up to 231 bytes in size (approximately 2.1 ×
109 bytes).

3.2. Individual FITS Structures

The primary HDU and every extension HDU shall consist of
one or more 2880-byte header blocks immediately followed by
an optional sequence of associated 2880-byte data blocks. The
header blocks shall contain only the restricted set of ASCII text
characters, decimal 32 through 126 (hexadecimal 20 through7E). The ASCII control characters with decimal values less than
32 (including the null, tab, carriage return, and line feed characters), and the delete character (decimal 127 or hexadecimal 7F)
must not appear anywhere within a header block.
3.3. Primary header and data unit

The first component of a FITS file shall be the primary HDU
which always contains the primary header and may be followedby the primary data array. If the primary data array has zero
length, as determined by the values of the NAXIS and NAXISn
keywords in the primary header (Sect. 4.4.1), then the primary
HDU shall contain no data blocks.
3.3.1. Primary header

The header of a primary HDU shall consist of one or moreheader blocks, each containing a series of 80-character keyword
records containing only the restricted set of ASCII text characters. Each 2880-byte header block contains 36 keyword records.
The last header block must contain the END keyword (defined in
Sect. 4.4.1) which marks the logical end of the header. Keyword

5Fig. 1: Arrays of more than one dimension shall consist of a sequence such that the index along axis 1 varies most rapidly andthose along subsequent axes progressively less rapidly.

records without information (e.g., following the END keyword)
shall be filled with ASCII spaces (decimal 32 or hexadecimal
20).
3.3.2. Primary data arraywith this FITS standard. New extension types should be created
only when the organization of the information is such that it cannot be handled by one of the existing extension types. A FITS
file that contains extensions is commonly referred to as a multiextension FITS (MEF) file.
3.4.1.1. Identity

Each extension type shall have a unique type name, specified in the header by the XTENSION keyword (Sect. 4.4.1). To
preclude conflict, extension type names must be registered with
the IAUFWG. The current list of registered extensions is given
in Appendix F. An up-to-date list is also maintained on the FITS
Support Office web site.

AFT

A(1, 1, . . . , 1),
A(2, 1, . . . , 1),..
.,
A(NAXIS1, 1, . . . , 1),
A(1, 2, . . . , 1),
A(2, 2, . . . , 1),..
.,
A(NAXIS1, 2, . . . , 1),..
.,
A(1, NAXIS2, . . . , NAXISm),..
.,
A(NAXIS1, NAXIS2, . . . , NAXISm)DR

The primary data array, if present, shall consist of a single dataarray with from 1 to 999 dimensions (as specified by the NAXIS
keyword defined in Sect. 4.4.1). The random groups convention
in the primary data array is a more complicated structure andis discussed separately in Sect. 6. The entire array of data values are represented by a continuous stream of bits starting withthe first bit of the first data block. Each data value shall consist of a fixed number of bits that is determined by the value ofthe BITPIX keyword (Sect. 4.4.1). Arrays of more than one dimension shall consist of a sequence such that the index along
axis 1 varies most rapidly, that along axis 2 next most rapidly,
and those along subsequent axes progressively less rapidly, withthat along axis m, where m is the value of NAXIS, varying least
rapidly. There is no space or any other special character between
the last value on a row or plane and the first value on the next
row or plane of a multi-dimensional array. Except for the location of the first element, the array structure is independent of the
FITS block structure. This storage order is shown schematicallyin Fig. 1 and is the same order as in multi-dimensional arrays in
the Fortran programming language (ISO 2004). The index countalong each axis shall begin with 1 and increment by 1 up to thevalue of the NAXISn keyword (Sect. 4.4.1).
If the data array does not fill the final data block, the remainder of the data block shall be filled by setting all bits to zero.
The individual data values shall be stored in big-endian byte order such that the byte containing the most significant bits of thevalue appears first in the FITS file, followed by the remaining
bytes, if any, in decreasing order of significance.

3.4.1.2. Size specification

The total number of bits in the data of each extension
shall be specified in the header for that extension, in the mannerprescribed in Sect. 4.4.1.
3.4.2. Standard extensions

A standard extension is a conforming extension whose organization and content are completely specified in Sect. 7 of thisstandard. Only one extension format shall be approved for eachtype of data organization.
3.4.3. Order of extensions

An extension may follow the primary HDU or another conforming extension. Standard extensions and other conforming extensions may appear in any order in a FITS file.
3.5. Special records (restricted use)

Special records are 2880-byte FITS blocks following the last
HDU of the FITS file that have an unspecified structure that
does not meet the requirements of a conforming extension. The
first 8 bytes of the special records must not contain the string‘XTENSION’. It is recommended that they do not contain thestring ‘SIMPLE ’. The contents of special records are not otherwise specified by this standard.
Special records were originally designed as a way for the
FITS format to evolve by allowing new FITS structures to be
implemented. Following the development of conforming extensions, which provide a general mechanism for storing different
types of data structures in FITS format in a well defined manner,
the need for other new types of FITS data structures has been
greatly reduced. Consequently, further use of special records is
restricted and requires the approval of the IAU FITS Working
Group.
3.6. Physical blocking

3.4. Extensions
3.4.1. Requirements for conforming extensions

All extensions, whether or not further described in this standard,
shall fulfill the following requirements to be in conformance

3.6.1. Bitstream devices

For bitstream devices, including but not restricted to logical filesystems, FITS files shall be interpreted as a sequence of one ormore 2880-byte FITS blocks, regardless of the physical block5

6
ing structure of the underlying recording media. When writinga FITS file on media with a physical block size unequal to the2880-byte FITS block length, any bytes remaining in the last
physical block following the end of the FITS file should be set
to zero. Similarly, when reading FITS files on such media, any
bytes remaining in the last physical block following the end of
the FITS file shall be disregarded.

ably assigned to a variable) by a FITS reading program, was associated one to one to a single header keyword record. With theintroduction of continued (long-string) keywords (see 4.2.1.2),
such FITS keywords may span more than one header keyword
record, and the value shall be created by concatenation as explained in 4.2.1.2.
4.1.2. Components

3.6.2. Sequential media

4.1.2.1. Keyword name (bytes 1 through 8)

3.7. Restrictions on changes

AF
T

The FITS format was originally developed for writing files onsequential magnetic tape devices. The following rules on how
to write to sequential media (Grosbøl & Wells 1994) are now
irrelevant to most current data storage devices.
If physically possible, FITS files shall be written on sequential media in blocks that are from one to ten integer multiples of
2880-bytes in length. If this is not possible, the FITS file shall be
written as a bitstream using the native block size of the sequential device. Any bytes remaining in the last block following theend of the FITS file shall be set to zero.
When reading FITS files on sequential media, any files
shorter than 2880 bytes in length (e.g., ANSI tape labels) are
not considered part of the FITS files and should be disregarded.

4. HeadersDR

Any structure that is a valid FITS structure shall remain a valid
FITS structure at all future times. Use of certain valid FITS structures may be deprecated by this or future FITS standard documents.

The first two sections of this chapter define the structure and content of header keyword records. This is followed in Sect. 4.3 withrecommendations on how physical units should be expressed.
The final section defines the mandatory and reserved keywords
for primary arrays and conforming extensions.
4.1. Keyword records
4.1.1. Syntax

Each 80-character header keyword record shall consist of a keyword name, a value indicator (only required if a value is present),
an optional value, and an optional comment. Keywords may appear in any order except where specifically stated otherwise inthis standard. It is recommended that the order of the keywords
in FITS files be preserved during data processing operations
because the designers of the FITS file may have used conventions that attach particular significance to the order of certain
keywords (e.g., by grouping sequences of COMMENT keywords
at specific locations in the header, or appending HISTORY keywords in chronological order of the data processing steps) or
using CONTINUE keywords to generate long-string keyword values.
A formal syntax, giving a complete definition of the syntax
of FITS keyword records, is given in Appendix A. It is intended
as an aid in interpreting the text defining the standard.
In earlier versions of this standard a FITS keyword, assumed
as an item whose value is to be looked up by name (and presum6

The keyword name shall be a left justified, 8-character,space-filled, ASCII string with no embedded spaces. All digits
0 through 9 (decimal ASCII codes 48 to 57, or hexadecimal 30
to 39) and upper case Latin alphabetic characters ‘A’ through‘Z’ (decimal 65 to 90 or hexadecimal 41 to 5A) are permitted;
lower case characters shall not be used. The underscore (‘ ’,decimal 95 or hexadecimal 5F) and hyphen (‘-’, decimal 45
or hexadecimal 2D) are also permitted. No other characters
are permitted.3 For indexed keyword names that have a single
positive integer index counter appended to the root name,the counter shall not have leading zeroes (e.g.,NAXIS1, not
NAXIS001). Note that keyword names that begin with (orconsist solely of) any combination of hyphens, underscores, anddigits are legal.
4.1.2.2. Value indicator (bytes 9 and 10)

If the two ASCII characters '= ' (decimal 61 followed
by decimal 32) are present in bytes 9 and 10 of the keyword
record this indicates that the keyword has a value field associated with it, unless it is one of the commentary keywords
defined in Sect. 4.4.2 (i.e., a HISTORY, COMMENT, or completely
blank keyword name) which by definition have no value.
4.1.2.3. Value/comment (bytes 11 through 80)

In keyword records that contain the value indicator in bytes 9
and 10, the remaining bytes 11 through 80 of the record shallcontain the value, if any, of the keyword, followed by optionalcomments. In keyword records without a value indicator, bytes 9
through 80 should be interpreted as commentary text, however,this does not preclude conventions that interpret the content ofthese bytes in other ways.
The value field, when present, shall contain the ASCII text
representation of a literal string constant, a logical constant, or
a numerical constant, in the format specified in Sect. 4.2. The
value field may be a null field; i.e., it may consist entirely of
spaces, in which case the value associated with the keyword isundefined.
The mandatory FITS keywords defined in this standard must
not appear more than once within a header. All other keywords
that have a value should not appear more than once. If a keyword
does appear multiple times with different values, then the value
is indeterminate.
If a comment follows the value field, it must be precededby a slash (‘/’, decimal 47 or hexadecimal 2F).1 A space between the value and the slash is strongly recommended. The
3This requirement differs from the wording in the original FITS papers. See Appendix H.

7comment may contain any of the restricted set of ASCII text
characters, decimal 32 through 126 (hexadecimal 20 through7E). The ASCII control characters with decimal values less than
32 (including the null, tab, carriage return, and line feed characters), and the delete character (decimal 127 or hexadecimal 7F)
must not appear anywhere within a keyword record.

opening and closing quote characters in bytes 11 and 80, respectively. In general, no length limit less than 68 is implied forcharacter-valued keywords.
Whenever a keyword value is declared ‘string’ or said to‘contain a character string’, the length limits in this section apply. The next section 4.2.1.2 applies when the value is declared‘long-string’.

4.2. Value

4.2.1. Character string
4.2.1.1 Single record string keywords

DR

A character string value shall be composed only of the set of
restricted ASCII text characters, decimal 32 through 126 (hexadecimal 20 through 7E) enclosed by single quote characters(“'”, decimal 39, hexadecimal 27). A single quote is represented
within a string as two successive single quotes, e.g., O’HARA ='O''HARA'. Leading spaces are significant; trailing spaces arenot. This standard imposes no requirements on the case sensitivity of character string values unless explicitly stated in thedefinition of specific keywords.
If the value is a fixed-format character string, the starting
single quote character must be in byte 11 of the keyword record
and the closing single quote must occur in or before byte 80.
Earlier versions of this standard also required that fixed-format
characters strings must be padded with space characters to atleast a length of eight characters so that the closing quote character does not occur before byte 20. This minimum character
string length is no longer required, except for the value of the
XTENSION keyword (e.g., 'IMAGE' and 'TABLE'; seeSect. 7) which must be padded to a length of eight characters forbackward compatibility with previous usage.
Free-format character strings follow the same rules as fixedformat character strings except that the starting single quotecharacter may occur after byte 11. Any bytes preceding the starting quote character and after byte 10 must contain the space character.
Note that there is a subtle distinction between the following
three keywords:
KEYWORD1= ''KEYWORD2= 'KEYWORD3='

4.2.1.2 Continued string (long-string) keywords

AF
T

The structure of the value field depends on the data type of thevalue. The value field represents a single value and not an arrayof values.1 The value field must be in one of two formats: fixedor free. The fixed-format is required for values of mandatory
keywords and is recommended for values of all other keywords.

/ null string keyword/ empty string keyword/ undefined keyword

The value of KEYWORD1 is a null, or zero length string whereas
the value of the KEYWORD2 is an empty string (nominally a single
space character because the first space in the string is significant,but trailing spaces are not). The value of KEYWORD3 is undefinedand has an indeterminate data type as well, except in cases where
the data type of the specified keyword is explicitly defined in thisstandard.
The maximum length of a string value that can be represented on a single keyword record is 68 characters, with the

Earlier versions of this Standard only defined single record
string keywords as described in the previous section. The
Standard now incorporates a convention (originally developedfor use in FITS files from high-energy astrophysics missions) for
continuing arbitrarily long string values over a potentially unlimited sequence of multiple consecutive keyword records using thefollowing procedure:
1. Divide the long string value into a sequence of smaller substrings, each of which is no longer than 67 characters inlength. (Note that if the string contains any literal single
quote characters, then these must be represented as a pairof single quote characters in the FITS keyword value, andthese two characters must both be contained within a single
substring).
2. Append an ampersand character (‘&’) to the end of each substring, except for the last substring. This character serves asa flag to FITS reading software that this string value may becontinued on the following keyword in the header.
3. Enclose each substring with single quote characters. Nonsignificant space characters may occur between the ampersand character and the closing quote character.
4. Write the first substring as the value of the specified keyword.
5. Write each subsequent substring, in order, to a series of keywords that all have the reserved keyword name CONTINUE(see 4.4.2) in bytes 1 through 8 and have space charactersin bytes 9 and 10 of the keyword record. The substring may
be located anywhere in bytes 11 through 80 of the keyword
record and may be preceded by non-significant space characters starting in byte 11. A comment string may follow thesubstring; if present, the comment string must be separated
from the substring by a forward slash character (‘/’). Also, it
is strongly recommended that the slash character be precededby a space character.

The CONTINUE keyword must not be used with of any ofthe mandatory or reserved keywords defined in this standard unless explicitly declared of type long-string.
The following keyword records illustrate a string value thatis continued over multiple keyword records. (Note: the length of
the substrings have been reduced to fit within the page layout):
WEATHER = 'Partly cloudy during the evening f&'
CONTINUE 'ollowed by cloudy skies overnight.&'
CONTINUE ' Low 21C. Winds NNE at 5 to 10 mph.'
If needed, additional space for the keyword comment field
can be generated by continuing the string value with one or morenull strings, as illustrated schematically below:
STRKEY= 'This keyword value is continued &'7

8
CONTINUE
CONTINUE
CONTINUE
CONTINUE' over multiple keyword records.&''&' / The comment field for this'&' / keyword is also continued'' / over multiple records.

4.2.2. Logical

If the value is a fixed-format logical constant, it shall appear as
an uppercase T or F in byte 30. A logical value is represented infree-format by a single character consisting of an uppercase T or
F as the first non-space character in bytes 11 through 80.
4.2.3. Integer numberDR

If the value is a fixed-format integer, the ASCII representation
shall be right-justified in bytes 11 through 30. An integer consists of a ‘+’ (decimal 43 or hexadecimal 2B) or ‘−’ (decimal 45
or hexadecimal 2D) sign, followed by one or more contiguous
ASCII digits (decimal 48 to 57 or hexadecimal 30 to 39), withno embedded spaces. The leading ‘+’ sign is optional. Leading
zeros are permitted, but are not significant. The integer representation shall always be interpreted as a signed, decimal number.
This standard does not limit the range of an integer keyword
value, however, software packages that read or write data according to this standard could be limited in the range of values
that are supported (e.g., to the range that can be represented by
a 32-bit or 64-bit signed binary integer).
A free-format integer value follows the same rules as fixedformat integers except that the ASCII representation may occur
anywhere within bytes 11 through 80.
4.2.4. Real floating-point number

If the value is a fixed-format real floating-point number, theASCII representation shall be right-justified in bytes 11 through30.
A floating-point number is represented by a decimal number
followed by an optional exponent, with no embedded spaces.
A decimal number shall consist of a ‘+’ (decimal 43 or hexadecimal 2B) or ‘–’ (decimal 45 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.
8

QuantityUnit
SI base & supplementary units
length
m
mass
kg
time
s
plane angleradsolid anglesrtemperatureKelectric currentA
amount of substancemolluminous intensity
cd

meter
kilogram
secondradiansteradiankelvinamperemolecandelaIAU-recognized derived units
frequencyHz
energyJ
power
Welectric potential
V
force
N
pressure, stressPaelectric charge
Celectric resistanceOhmelectric conductanceS
electric capacitanceFmagnetic fluxWbmagnetic flux density T
inductanceH
luminous fluxlm
illuminance
lx

hertz
joule
watt
volt
newtonpascalcoulombohm
siemens
farad
weber
tesla
henry
lumen
lux

AF
T

FITS reading software can reconstruct the long string value
by following an inverse procedure of checking if the string value
ends with the ‘&’ character and is immediately followed by aconforming CONTINUE keyword record. If both conditions aretrue, then concatenate the substring from the CONTINUE record
onto the previous substring after first deleting the trailing ‘&’
character. Repeat these steps until all subsequent CONTINUE
records have been processed.
Note that if a string value ends with the ‘&’ character, but
is not immediately followed by a CONTINUE keyword that conforms to all the previously described requirements, then the ‘&’character should be interpreted as the literal last character in thestring. Also, any ‘orphaned’ CONTINUE keyword records (formally not invalidating the FITS file, although likely representing
an error with respect to what the author of the file meant) should
be interpreted as containing commentary text in bytes 9 – 80
(similar to a COMMENT keyword).

Table 3: IAU-recommended basic units.
MeaningNotes
g gram allowed

s−1
Nm
J s−1
J C−1
kg m s−2
N m−2
As
V A−1
A V−1
C V−1
Vs
Wb m−2
Wb A−1
cd sr
lm m−2

If the fractional part is present, the decimal point must also bepresent. If only the integer part is present, the decimal point may
be omitted, in which case the floating-point number is indistinguishable from an integer. The exponent, if present, consists ofan exponent letter followed by an integer. Letters in the exponential form (‘E’ or ‘D’)4 shall be upper case. The full precision of
64-bit values cannot be expressed over the whole range of values
using the fixed-format. This standard does not impose an upper
limit on the number of digits of precision, nor any limit on therange of floating-point keyword values. Software packages that
read or write data according to this standard could be limited,
however, in the range of values and exponents that are supported(e.g., to the range that can be represented by a 32-bit or 64-bit
floating-point number).
A free-format floating-point value follows the same rules asa fixed-format floating-point value except that the ASCII representation may occur anywhere within bytes 11 through 80.
4.2.5. Complex integer number

There is no fixed-format for complex integer numbers.5
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 e.g., (123, 45). Spaces
may precede and follow the real and imaginary parts. The realand imaginary parts are represented in the same way as integers
4The ‘D’ exponent form is traditionally used when representing values that have more decimals of precision or a larger magnitude than canbe represented by a single precision 32-bit floating-point number, butotherwise there is no distinction between ‘E’ or ‘D’.
5This requirement differs from the wording in the original FITS papers. See Appendix H.

9Table 4: Additional allowed units.

Unit
Meaningdeg
degree of arc
arcminminute of arc
arcsecsecond of arc
masmilli-second of arc
timeminminute
h
hour
d
day
† a
year (Julian)† yryear (Julian)∗energy† eVelectron volt
‡ erg
erg
Ry
rydbergmass∗
solMass solar massuunified atomic mass unit
luminosity
solLumSolar luminosity
length‡ Angstrom angstrom
solRadSolar radiusAUastronomical unit
lyr
light year
† pc
parsecevents
count
count
ct
count
photonphotonphphotonflux density† Jy
jansky† mag(stellar) magnitude† R
rayleighmagnetic field †‡ G
gauss
area
pixel
(image/detector) pixel
pix(image/detector) pixel†‡ barnbarn

DR

Miscellaneous units
D
Sun
chan
bin
voxel
† bit
† byte
adu
beam

Notes
π/180 rad1/60 deg
1/3600 deg
1/3 600 000 deg
60 s
60 min = 3600 s
86 400 s
31 557 600 s (365.25 d), peta a (Pa) forbidden
a is IAU-style1.6021765 × 10−19 J
10−7 J2
1 2πe2me c2 = 13.605692 eV
2hc
1.9891 × 1030 kg
1.6605387 × 10−27 kg
3.8268 × 1026 W
10−10 m6.9599 × 108 m
1.49598 × 1011 m
9.460730 × 1015 m
3.0857 × 1016 m

AF
T

Quantity
plane angle

10−26 W m−2 Hz−1

1010 /(4π) photons m−2 s−1 sr−1
10−4 T
10−28 m2

1
debye
× 10−29 C.m
3
relative to Sun
e.g., abundances(detector) channel
numerous applications(including the 1-d analogue of pixel)
3-d analogue of pixel
binary information unit
(computer) byte
8 bit
Analog-to-digital converterbeam area of observation
as in Jy/beamNotes. (†) Addition of prefixes for decimal multiples and submultiples are allowed. (‡) Deprecated in IAU Style Manual (McNally 1988) but still inuse. (∗) Conversion factors from CODATA Internationally recommended values of the fundamental physical constants 2002 (http://physics.
nist.gov/cuu/Constants/).

(Sect. 4.2.3). Such a representation is regarded as a single value
for the complex integer number. This representation may be located anywhere within bytes 11 through 80.
4.2.6. Complex floating-point number

There is no fixed-format for complex floating-point numbers.3
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, e.g., (123.23,-45.7). Spaces may precede and follow the real and imaginaryparts. The real and imaginary parts are represented in the same
way as floating-point values (Sect. 4.2.4). Such a representation is regarded as a single value for the complex floating-point
number. This representation may be located anywhere within
bytes 11 through 80.

4.2.7. Date

There is strictly no such thing as a data type for date valued
keywords, however a pseudo data type of datetime is defined in
Sect. 9.1.1 and must be used to write ISO-8601 datetime strings
as character strings.
If a keyword needs to express a time in JD or MJD (seeSect. 9), this can be formatted as an arbitrary precision number,
optionally separating the integer and fractional part as specified
in Sect. 9.2.2.
4.3. Units

When a numerical keyword value represents a physical quantity,
it is recommended that units be provided. Units shall be represented with a string of characters composed of the restricted
ASCII text character set. Unit strings can be used as values of
9

10

4.3.1. Construction of units strings

DR

Compound units strings may be formed by combining stringsof base units (including prefixes, if any) with the recommended
syntax described in Table 6. Two or more base units strings(called str1 and str2 in Table 6) may be combined using
the restricted set of (explicit or implicit) operators that provide
for multiplication, division, exponentiation, raising arguments topowers, or taking the logarithm or square-root of an argument.
Note that functions such as log actually require dimensionless arguments, so that log(Hz), for example, actually meanslog(x/1 Hz). The final units string is the compound string, ora compound of compounds, preceded by an optional numericmultiplier of the form 10**k, 10ˆk, or 10±k where k is an integer, optionally surrounded by parentheses with the sign character
required in the third form in the absence of parentheses. Creatorsof FITS files are encouraged to use the numeric multiplier only
when the available standard scale factors of Table 5 will not suffice. Parentheses are used for symbol grouping and are strongly
recommended whenever the order of operations might be subject to misinterpretation. A space character implies multiplication which can also be conveyed explicitly with an asterisk or aperiod. Therefore, although spaces are allowed as symbol separators, their use is discouraged. Note that, per IAU convention,case is significant throughout. The IAU style manual forbids theuse of more than one slash (‘/’) character in a units string.
However, since normal mathematical precedence rules apply inthis context, more than one slash may be used but is discouraged.
A unit raised to a power is indicated by the unit string followed, with no intervening spaces, by the optional symbols ** orˆ followed by the power given as a numeric expression, called
expr in Table 6. The power may be a simple integer, with orwithout sign, optionally surrounded by parentheses. It may also
be a decimal number (e.g., 1.5, 0.5) or a ratio of two integers(e.g., 7/9), with or without sign, which must be surrounded byparentheses. Thus meters squared may be indicated by m**(2),6These tables are reproduced from the first in a series of papers on
world coordinate systems (Greisen & Calabretta 2002), which provides
examples and expanded discussion.

10

Table 5: Prefixes for multiples and submultiples.
Submult
10−1
10−2
10−3
10−6
10−9
10−12
10−15
10−18
10−21
10−24

Prefix
deci
centi
milli
micro
nano
pico
femto
atto
zepto
yocto

Char
d
c
m
u
n
p
f
a
z
y

AF
T

keywords (e.g., for the reserved keywords BUNIT, and TUNITn),as an entry in a character string column of an ASCII or binary table extension, or as part of a keyword comment string (see Sect.
4.3.2, below).
The units of all FITS header keyword values, with the exception of measurements of angles, should conform with the recommendations in the IAU Style Manual (McNally 1988). For
angular measurements given as floating-point values and specified with reserved keywords, the units should be degrees (i.e.,deg). If a requirement exists within this standard for the units ofa keyword, then those units must be used.
The units for fundamental physical quantities recommended
by the IAU are given in Table 3, and additional units that arecommonly used in astronomy are given in Table 4. Further specifications for time units are given in Sect. 9.3. The recommended
plain text form for the IAU-recognized base units are given incolumn 2 of both tables.6 All base units strings may be preceded,with no intervening spaces, by a single character (two for deca)taken from Table 5 and representing scale factors mostly in stepsof 103 . Compound prefixes (e.g., ZYeV for 1045 eV) must not be
used.

Mult
10
102
103
106
109
1012
1015
1018
1021
1024

Prefix
deca
hecto
kilo
mega
giga
tera
peta
exa
zetta
yotta

Char
da
h
k
M
G
T
P
E
Z
Y

Table 6: Characters and strings allowed to denote mathematicaloperations.
StringMeaning

str1 str2
str1*str2
str1.str2
str1/str2
str1**expr
str1ˆexpr
str1expr
log(str1)ln(str1)
exp(str1)sqrt(str1)

Multiplication
Multiplication
Multiplication
Division
Raised to the power expr
Raised to the power expr
Raised to the power expr
Common Logarithm (to base 10)
Natural Logarithm
Exponential (estr1 )Square root

m**+2, m+2, m2, mˆ2, mˆ(+2), etc. and per meter cubed may be
indicated by m**-3, m-3, mˆ(-3), /m3, and so forth. Meters to
the three-halves power may be indicated by m(1.5), mˆ(1.5),
m**(1.5), m(3/2), m**(3/2), and mˆ(3/2), but not by mˆ3/2
or m1.5.
4.3.2. Units in comment fields

If the units of the keyword value are specified in the comment of
the header keyword, it is recommended that the units string be
enclosed in square brackets (i.e., enclosed by ‘[’ and ‘]’) at the
beginning of the comment field, separated from the slash (‘/’)
comment field delimiter by a single space character. An example, using a non-standard keyword, is
EXPTIME = 1200. / [s] exposure time in seconds
This widespread, but optional, practice suggests that square
brackets should be used in comment fields only for this purpose. Nonetheless, software should not depend on units being
expressed in this fashion within a keyword comment, and software should not depend on any string within square brackets in
a comment field containing a proper units string.
4.4. Keywords
4.4.1. Mandatory keywords

Mandatory keywords are required in every HDU as describedin the remainder of this subsection. They must be used only as
described in this standard. Values of the mandatory keywords
must be written in fixed-format.

11
Table 7: Mandatory keywords for primary header.

last

KeywordSIMPLE = T
BITPIXNAXISNAXISn, n = 1, . . . , NAXIS..
.
(other keywords)
..
.
END

Table 8: Interpretation of valid BITPIX value.
Value
8
16
32
64
-32
-64

Data represented
Character or unsigned binary integer
16-bit two’s complement binary integer
32-bit two’s complement binary integer
64-bit two’s complement binary integer
IEEE single precision floating point
IEEE double precision floating point

4.4.1.1. Primary header

END keyword. This keyword has no associated value. Bytes 9
through 80 shall be filled with ASCII spaces (decimal 32 or hexadecimal 20). The END keyword marks the logical end of theheader and must occur in the last 2880-byte FITS block of theheader.
The total number of bits in the primary data array, exclusiveof fill that is needed after the data to complete the last 2880-byte
data block (Sect. 3.3.2), is given by the following expression:

AF
T

#
1
2
3
4

NAXISn keywords are non-zero). If NAXIS is equal to 0, there
shall not be any NAXISn keywords.

The SIMPLE keyword is required to be the first keyword
in the primary header of all FITS files. The primary header must
contain the other mandatory keywords shown in Table 7 in theorder given. Other keywords must not intervene between the
SIMPLE keyword and the last NAXISn keyword.

Nbits = |BITPIX| × (NAXIS1 × NAXIS2 × · · · × NAXISm),(1)where Nbits must be non-negative and is the number of bits excluding fill, m is the value of NAXIS, and BITPIX and the NAXISn
represent the values associated with those keywords. Note thatthe random groups convention in the primary array has a more
complicated structure whose size is given by Eq. 4. The headerof the first FITS extension in the file, if present, shall start withthe first FITS block following the data block that contains thelast bit of the primary data array.
An example of a primary array header is shown in Table 9.
In addition to the required keywords, it includes a few of thereserved keywords that are discussed in Sect. 4.4.2.
4.4.1.2. Conforming extensions

All conforming extensions, whether or not further specified in this standard, must use the keywords defined in Table 10
in the order specified. Other keywords must not intervene
between the XTENSION keyword and the GCOUNT keyword. The
BITPIX, NAXIS, NAXISn, and END keywords are defined in Sect.
4.4.1.

BITPIX keyword. The value field shall contain an integer. The
absolute value is used in computing the sizes of data structures.
It shall specify the number of bits that represent a data value inthe associated data array. The only valid values of BITPIX aregiven in Table 8. Writers of FITS arrays should select a BITPIX
data type appropriate to the form, range of values, and accuracyof the data in the array.

XTENSION keyword. The value field shall contain a character
string giving the name of the extension type. This keyword is
mandatory for an extension header and must not appear in the
primary header.8 To preclude conflict, extension type names
must be registered with the IAUFWG. The current list of registered extensions is given in Appendix F. An up-to-date list isalso maintained on the FITS Support Office web site.

NAXIS keyword. The value field shall contain a non-negative
integer no greater than 999 representing the number of axes in
the associated data array. A value of zero signifies that no data
follow the header in the HDU.

PCOUNT keyword. The value field shall contain an integer thatshall be used in any way appropriate to define the data structure,
consistent with Eq. 2. In IMAGE (Sect. 7.1) and TABLE (Sect. 7.2)
extensions this keyword must have the value 0; in BINTABLE
extensions (Sect. 7.3) it is used to specify the number of bytes
that follow the main data table in the supplemental data area
called the heap. This keyword is also used in the random groups
structure (Sect. 6) to specify the number of parameters preceding
each array in a group.

DR

SIMPLE keyword. The value field shall contain a logical constant with the value T if the file conforms to this standard. This
keyword is mandatory for the primary header and must not appear in extension headers.7 A value of F signifies that the filedoes not conform to this standard.

NAXISn keywords. The NAXISn keywords must be present for
all values n = 1, ..., NAXIS, in increasing order of n, andfor no other values of n. The value field of this indexed keyword
shall contain a non-negative integer representing the number of
elements along axis n of a data array. A value of zero for any of
the NAXISn signifies that no data follow the header in the HDU(however, the random groups structure described in Sect. 6 has
NAXIS1 = 0, but will have data following the header if the other

GCOUNT keyword. The value field shall contain an integer thatshall be used in any way appropriate to define the data structure,
consistent with Eq. 2. This keyword must have the value 1 in

7
This requirement differs from the wording in the original FITS papers. See Appendix H.

8This requirement differs from the wording in the original FITS papers. See Appendix H.

11

12
Table 9: Example of a primary array header.
T / file does conform to FITS standard
16 / number of bits per data pixel
2 / number of data axes
250 / length of data axis 1
300 / length of data axis 2

AF
T

Keyword records
SIMPLE =BITPIX =NAXIS=NAXIS1 =NAXIS2 =OBJECT = 'Cygnus X-1'
DATE
= '2006-10-22'
END

the IMAGE, TABLE and BINTABLE standard extensions defined in
Sect. 7. This keyword is also used in the random groups structure(Sect. 6) to specify the number of random groups present.
The total number of bits in the extension data array (exclusive of fill that is needed after the data to complete the last 2880byte data block) is given by the following expression:
Nbits = |BITPIX| × GCOUNT ×(PCOUNT + NAXIS1 × NAXIS2 × · · · × NAXISm),DR

The reserved keywords described below are optional, but if
present in the header they must be used only as defined in thisstandard. They apply to any FITS structure with the meanings
and restrictions defined below. Any FITS structure may further
restrict the use of these keywords.
4.4.2.1. General descriptive keywords

DATE keyword. The value field shall contain a character string
giving the date on which the HDU was created, in the form
YYYY-MM-DD, or the date and time when the HDU was created, inthe form YYYY-MM-DDThh:mm:ss[.sss. . . ], where YYYY shallbe the four-digit calendar year number, MM the two-digit month
number with January given by 01 and December by 12, and DD
the two-digit day of the month. When both date and time are
given, the literal T shall separate the date and time, hh shallbe the two-digit hour in the day, mm the two-digit number ofminutes after the hour, and ss[.sss. . . ] the number of seconds(two digits followed by an optional fraction) after the minute.
Default values must not be given to any portion of the date/time
string, and leading zeros must not be omitted. The decimal partof the seconds field is optional and may be arbitrarily long, solong as it is consistent with the rules for value formats of Sect.
4.2. Otherwise said, the format for DATE keywords written afterJanuary 1, 2000 shall be the ISO-8601 datetime form describedin Sect. 9.1.1. See also Sect. 9.5.
The value of the DATE keyword shall always be expressed in
UTC when in this format, for all data sets created on Earth.
12

#
1
2
3
4
5
6

(2)

where Nbits must be non-negative and is the number of bits excluding fill; m is the value of NAXIS; and BITPIX, GCOUNT,PCOUNT, and the NAXISn represent the values associated withthose keywords. If Nbits > 0, then the data array shall be contained in an integral number of 2880-byte FITS data blocks. The
header of the next FITS extension in the file, if any, shall startwith the first FITS block following the data block that contains
the last bit of the current extension data array.
4.4.2. Other reserved keywords

Table 10: Mandatory keywords in conforming extensions.

last

KeywordXTENSION
BITPIXNAXISNAXISn, n = 1, . . . , NAXISPCOUNTGCOUNT..
.
(other keywords)
..
.
END

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 thelast 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.
When a newly created HDU is substantially a verbatim copyof another HDU, the value of the DATE keyword in the original
HDU may be retained in the new HDU instead of updating thevalue to the current date and time.

ORIGIN keyword. The value field shall contain a character
string identifying the organization or institution responsible forcreating the FITS file.
EXTEND keyword. The value field shall contain a logical value
indicating whether the FITS file is allowed to contain conforming extensions following the primary HDU. This keyword may
only appear in the primary header and must not appear in an
extension header. If the value field is T then there may be conforming extensions in the FITS file following the primary HDU.
This keyword is only advisory, so its presence with a value T
does not require that the FITS file contains extensions, nor does
the absence of this keyword necessarily imply that the file does
not contain extensions. Earlier versions of this standard statedthat the EXTEND keyword must be present in the primary header
if the file contained extensions, but this is no longer required.
BLOCKED keyword. This keyword is deprecated and should not
be used in new FITS files. It is reserved primarily to prevent its
use with other meanings. As previously defined, this keyword, if
used, was required to appear only within the first 36 keywords in13
the primary header. Its presence with the required logical valueof T advised that the physical block size of the FITS file on which
it appears may be an integral multiple of the FITS block lengthand not necessarily equal to it.
4.4.2.2. Keywords describing observations

AUTHOR keyword. The value field shall contain a character
string identifying who compiled the information in the data associated with the header. This keyword is appropriate when thedata originate in a published paper or are compiled from manysources.
REFERENC keyword. The value field shall contain a character string citing a reference where the data associated with theheader are published. It is recommended that either the 19-digit
bibliographic identifier9 used in the Astrophysics Data Systembibliographic databases (http://adswww.harvard.edu/) or
the Digital Object Identifier (http://doi.org) be included in
the value string when available (e.g., ’1994A&AS..103..135A’or ’doi:10.1006/jmbi.1998.2354’).

DR

AF
T

DATE-OBS keyword. The format of the value field for
DATE-OBS keywords shall follow the prescriptions for the DATE
keyword (Sect. 4.4.2 and Sect. 9.1.1 Either the four-digit year
format or the two-digit year format may be used for observation
dates from 1900 through 1999 although the four-digit format isrecommended.
When the format with a four-digit year is used, the default interpretations for time should be UTC for dates beginning 197201-01 and UT before. Other date and time scales are permissible.
The value of the DATE-OBS keyword shall be expressed in theprincipal time system or time scale of the HDU to which it belongs; if there is any chance of ambiguity, the choice should beclarified 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 andTT, will be assumed to be as measured at the detector (or, inpractical cases, at the observatory). For coordinate times such as
TCG, TCB and TDB, the default shall be to include light-timecorrections to the associated spatial origin, namely the geocenter for TCG and the solar-system barycenter for the other two.
Conventions may be developed that use other time systems. Timescales are now discussed in detail in Sect. 9.2.1 and Table 30.
When the value of DATE-OBS is expressed in the two-digit
year form, allowed for files written before January 1, 2000 witha 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.

4.4.2.3. Bibliographic keywords

DATExxxx keywords. The value fields for all keywords beginning with the string DATE whose value contains date, and optionally time, information shall follow the prescriptions for the
DATE-OBS keyword. See also Sect. 9.1.1 for the datetime format,
and Sect. 9.5 for further global time keywords specified by theStandard.
TELESCOP keyword. The value field shall contain a character
string identifying the telescope used to acquire the data associated with the header.

4.4.2.4. Commentary keywords

These keywords provide commentary information about thecontents or history of the FITS file and may occur any number oftimes in a header. These keywords shall have no associated valueeven if the value indicator characters `= ' appear in bytes 9 and
10 (hence it is recommended that these keywords not containthe value indicator). Bytes 9 through 80 may contain any of therestricted set of ASCII text characters, decimal 32 through 126(hexadecimal 20 through 7E).
In earlier versions of this standard continued string keywords(see 4.2.1.2) could be handled as commentary keywords if therelevant convention was not supported. Now CONTINUE keywords shall be honoured as specified in Section 4.2.1.2.

COMMENT keyword. This keyword may be used to supply any
comments regarding the FITS file.
HISTORY keyword. This keyword should be used to describe
the history of steps and procedures associated with the processing of the associated data.
Keyword field is blank. This keyword may be used to supply

any comments regarding the FITS file. It is frequently used foraesthetic purposes to provide a break between groups of related
keywords in the header.

OBSERVER keyword. The value field shall contain a character string identifying who acquired the data associated with theheader.

A sequence of one or more entirely blank keyword records(consisting of 80 ASCII space characters) that immediately precede the END keyword may be interpreted as non-significant fillspace that may be overwritten when new keywords are appended
to the header. This usage convention enables an arbitrarily large
amount of header space to be preallocated when the FITS HDU
is first created which can help mitigate the potentially timeconsuming alternative of having to shift all the following datain the file by 2880 bytes to make room for a new FITS header
block each time space is needed for a new keyword.

OBJECT keyword. The value field shall contain a character
string giving a name for the object observed.

9This bibliographic convention (Schmitz et al. 1995) was initiallydeveloped for use within NED (NASA/IPAC Extragalactic Database)and SIMBAD (operated at CDS, Strasbourg, France).

INSTRUME keyword. The value field shall contain a character
string identifying the instrument used to acquire the data associated with the header.

13

14ray, after application of BSCALE and BZERO, are expressed. These
units must follow the prescriptions of Sect. 4.3.

4.4.2.5. Keywords that describe arrays

These keywords are used to describe the contents of anarray, either in the primary array, in an image extension (Sect.
7.1), or in a series of random groups (Sect. 6). They are optional,
but if they appear in the header describing an array or groups,
they must be used as defined in this section of this standard.
They shall not be used in headers describing other structures
unless the meaning is the same as defined here.

AF
T

BSCALE keyword. This keyword shall be used, along with the
BZERO keyword, to linearly scale the array pixel values (i.e., theactual values stored in the FITS file) to transform them into thephysical values that they represent using Eq. 3.

BLANK keyword. This keyword shall be used only in headerswith positive values of BITPIX (i.e., in arrays with integer data).
Bytes 1 through 8 contain the string `BLANK' (ASCII spaces
in bytes 6 through 8). The value field shall contain an integerthat specifies the value that is used within the integer array torepresent pixels that have an undefined physical value.
If the BSCALE and BZERO keywords do not have the default
values of 1.0 and 0.0, respectively, then the value of the BLANK
keyword must equal the actual value in the FITS data array thatis used to represent an undefined pixel and not the corresponding physical value (computed from Eq. 3). To cite a specific,
common example, unsigned 16-bit integers are represented in asigned integer FITS array (with BITPIX = 16) by setting BZERO= 32768 and BSCALE = 1. If it is desired to use pixels that havean unsigned value (i.e., the physical value) equal to 0 to represent undefined pixels in the array, then the BLANK keyword must
be set to the value −32768 because that is the actual value of the
undefined pixels in the FITS array.

physical value = BZERO + BSCALE × array value.

(3)

The value field shall contain a floating-point number representing the coefficient of the linear term in the scaling equation, theratio of physical value to array value at zero offset. The default
value for this keyword is 1.0. Before support for IEEE floatingpoint data types was added to FITS (Wells & Grosbøl 1990), thistechnique of linearly scaling integer values was the only way torepresent the full range of floating-point values in a FITS array.
This linear scaling technique is still commonly used to reduce
the size of the data array by a factor of two by representing 32bit floating-point physical values as 16-bit scaled integers.

DR

BZERO keyword. This keyword shall be used, along with the
BSCALE keyword, to linearly scale the array pixel values (i.e., theactual values stored in the FITS file) to transform them into thephysical values that they represent using Eq. 3. The value fieldshall contain a floating-point number representing the physicalvalue corresponding to an array value of zero. The default value
for this keyword is 0.0.
Besides its use in representing floating-point values as scaled
integers (see the description of the BSCALE keyword), the BZERO
keyword is also used when storing unsigned integer values in the
FITS array. In this special case the BSCALE keyword shall havethe default value of 1.0, and the BZERO keyword shall have oneof the integer values shown in Table 11.
Since the FITS format does not support a native unsigned integer data type (except for the unsigned 8-bit byte data type), theunsigned values are stored in the FITS array as native signed integers with the appropriate integer offset specified by the BZERO
keyword value shown in the table. For the byte data type, theconverse technique can be used to store signed byte values asnative unsigned values with the negative BZERO offset. In eachcase, the physical value is computed by adding the offset specified by the BZERO keyword to the native data type value that isstored in the FITS file.10
BUNIT keyword. The value field shall contain a character string
describing the physical units in which the quantities in the ar10

A more computationally efficient method of adding or subtracting
the BZERO values is to simply flip the most significant bit of the binary
value. For example, using 8-bit integers, the decimal value 248 minus
the BZERO value of 128 equals 120. The binary representation of 248
is 11111000. Flipping the most significant bit gives the binary value
01111000, which is equal to decimal 120.
14

DATAMAX keyword. The value field shall always contain afloating-point number, regardless of the value of BITPIX. This
number shall give the maximum valid physical value represented
by the array (from Eq. 3), exclusive of any IEEE special values.
DATAMIN keyword. The value field shall always contain afloating-point number, regardless of the value of BITPIX. This
number shall give the minimum valid physical value represented
by the array (from Eq. 3), exclusive of any IEEE special values.
WCS keywords. An extensive set of keywords have been de-fined to describe the world coordinates associated with an array.
These keywords are discussed separately in Sect. 8.
4.4.2.6. Extension keywords

The next three keywords were originally defined for use
within the header of a conforming extension, however they also
may appear in the primary header with an analogous meaning.
If these keywords are present, it is recommended that they havea unique combination of values in each HDU of the FITS file.
EXTNAME keyword. The value field shall contain a character
string to be used to distinguish among different extensions of
the same type, i.e., with the same value of XTENSION, in a FITS
file. Within this context, the primary array should be considered
as equivalent to an IMAGE extension.
EXTVER keyword. The value field shall contain an integer to be
used to distinguish among different extensions in a FITS file withthe same type and name, i.e., the same values for XTENSION and
EXTNAME. The values need not start with 1 for the first extension
with a particular value of EXTNAME and need not be in sequence
for subsequent values. If the EXTVER keyword is absent, the fileshould be treated as if the value were 1.

15
Table 11: Usage of BZERO to represent non-default integer data types.
BITPIX
8
16
32
64

Nativedata typeunsignedsignedsignedsignedPhysicaldata typesigned byte
unsigned 16-bit
unsigned 32-bit
unsigned 64-bit

The following keyword is optional, but is reserved for use
by the convention described in Appendix K. If present it shallappear in the extension header immediately after the mandatory
keywords, and be used as described in the Appendix.
INHERIT keyword. The value field shall contain a logical valueof T or F to indicate whether or not the current extension should
inherit the keywords in the primary header of the FITS file.
4.4.2.7 Data Integrity Keywords

-128
32768
2147483648
9223372036854775808(−27 )(215 )(231 )(263 )CHECKSUM Keyword. The value field of the CHECKSUM keyword
shall consist of an ASCII character string whose value forcesthe 32-bit 1’s complement checksum accumulated over the entire FITS HDU to equal negative 0. (Note that 1’s complement
arithmetic has both positive and negative zero elements). It is
recommended that the particular 16-character string generated
by the algorithm described in Appendix J be used. A string containing only one or more consecutive ASCII blanks may be used
to represent an undefined or unknown value for the CHECKSUM
keyword.

AF
T

EXTLEVEL keyword. The value field shall contain an integer
specifying the level in a hierarchy of extension levels of the extension header containing it. The value shall be 1 for the highest
level; levels with a higher value of this keyword shall be subordinate to levels with a lower value. If the EXTLEVEL keyword isabsent, the file should be treated as if the value were 1.

BZERO

DR

The two keywords described here provide an integrity checkon the information contained in FITS HDUs.

DATASUM Keyword. The value field of the DATASUM keyword
shall consist of a character string that should contain the unsigned integer value of the 32-bit 1’s complement checksum of
the data records in the HDU (i.e., excluding the header records).
For this purpose, each 2880-byte FITS logical record should beinterpreted as consisting of 720 32-bit unsigned integers. The 4
bytes in each integer must be interpreted in order of decreasing
significance where the most significant byte is first, and the leastsignificant byte is last. Accumulate the sum of these integers using 1’s complement arithmetic in which any overflow of the mostsignificant bit is propagated back into the least significant bit of
the sum.

The DATASUM value is expressed as a character string (i.e.,
enclosed in single quote characters) because support for the fullrange of 32-bit unsigned integer keyword values is problematicin some software systems. This string may be padded with nonsignificant leading or trailing blank characters or leading zeros.
A string containing only one or more consecutive ASCII blanks
may be used to represent an undefined or unknown value forthe DATASUM keyword. The DATASUM keyword may be omitted in HDUs that have no data records, but it is preferable toinclude the keyword with a value of 0. Otherwise, a missing
DATASUM keyword asserts no knowledge of the checksum of
the data records. Recording in the comment field the ISO-8601formatted Datetime when the value of this keyword record iscreated or updated is recommended.

The CHECKSUM keyword value must be expressed in fixed
format, when the algorithm in Appendix J is used, otherwise theusage of fixed format is recommended. Recording in the comment field the ISO-8601-formatted Datetime when the value of
this keyword record is created or updated is recommended.

If the CHECKSUM keyword exists in the header of the HDU
and the accumulated checksum is not equal to -0, or if the
DATASUM keyword exists in the header of the HDU and its value
does not match the data checksum then this provides a strong indication that the content of the HDU has changed subsequent to
the time that the respective keyword value was computed. Suchan invalid checksum may indicate corruption during a prior file
copy or transfer operation, or a corruption of the physical media
on which the file was stored. It may alternatively reflect an intentional change to the data file by subsequent data processing if
the CHECKSUM value was not also updated.
Normally both keywords will be present in the header if either
is present, but this is not required. These keywords apply only
to the HDU in which they are contained. If these keywords are
written in one HDU of a multi-HDU FITS file then it is strongly
recommended that they also be written to every other HDU in
the file with values appropriate to each HDU in turn; in thatcase the checksum accumulated over the entire file will equal-0 as well. The DATASUM keyword must be updated before theCHECKSUM keyword. In general updating the two checksum keywords should be the final step of any update to either data orheader records in a FITS HDU. It is highly recommended that if
a FITS file is intended for public distribution, then the checksum
keywords, if present, should contain valid values.
4.4.3. Additional keywords

New keywords may be devised in addition to those describedin this standard, so long as they are consistent with the generalized rules for keywords and do not conflict with mandatory
or reserved keywords. Any keyword that refers to or depends
upon the existence of other specific HDUs in the same or otherfiles should be used with caution because the persistence of those
HDUs cannot always be guaranteed.
15

16

5. Data Representation

5.3. IEEE-754 floating point

Primary and extension data shall be represented in one of theformats described in this section. FITS data shall be interpreted
to be a byte stream. Bytes are in big-endian order of decreasing
significance. The byte that includes the sign bit shall be first, andthe byte that has the ones bit shall be last.

Each character shall be represented by one byte. A charactershall be represented by its 7-bit ASCII (ANSI 1977) code in
the low order seven bits in the byte. The high-order bit shall be
zero.

Transmission of 32- and 64-bit floating-point data within the
FITS format shall use the ANSI/IEEE-754 standard (IEEE1985). BITPIX = -32 and BITPIX = -64 signify 32- and 64bit IEEE floating-point numbers, respectively; the absolute valueof BITPIX is used for computing the sizes of data structures. The
full IEEE set of number forms is allowed for FITS interchange,
including all special 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 E has additional details on the IEEE format.

5.2. Integers

5.4. TimeAF
T

5.1. Characters

5.2.1. Eight-bit

Eight-bit integers shall be unsigned binary integers, contained in
one byte with decimal values ranging from 0 to 255.

6. Random groups structure

5.2.2. Sixteen-bit

Sixteen-bit integers shall be two’s complement signed binary integers, contained in two bytes with decimal values ranging from-32768 to +32767.

DR

5.2.3. Thirty-two-bit

Thirty-two-bit integers shall be two’s complement signed binary
integers, contained in four bytes with decimal values ranging
from -2147483648 to +2147483647.
5.2.4. Sixty-four-bit

Sixty-four-bit integers shall be two’s complement signed binary
integers, contained in eight bytes with decimal values ranging
from -9223372036854775808 to +9223372036854775807.
5.2.5. Unsigned integers

The FITS format does not support a native unsigned integer data
type (except for the unsigned 8-bit byte data type) therefore unsigned 16-bit, 32-bit, or 64-bit binary integers cannot be stored
directly in a FITS data array. Instead, the appropriate offset must
be applied to the unsigned integer to shift the value into the rangeof the corresponding signed integer, which is then stored in the
FITS file. The BZERO keyword shall record the amount of theoffset needed to restore the original unsigned value. The BSCALE
keyword shall have the default value of 1.0 in this case, and theappropriate BZERO value, as a function of BITPIX, is specified
in Table 11.
This same technique must be used when storing unsigned
integers in a binary table column of signed integers (Sect. 7.3.2).
In this case the TSCALn keyword (analogous to BSCALE) shallhave the default value of 1.0, and the appropriate TZEROn value(analogous to BZERO) is specified in Table 19.
16

There is strictly no such thing as a data type for time valued data,but rules to encode time values are given in Sect. 9 and in moredetail in Rots et al. (2015).

The random groups structure allows a collection of ‘groups’,
where a group consists of a subarray of data and a set of associated parameter values, to be stored within the FITS primarydata array. Random groups have been used almost exclusively
for applications in radio interferometry; outside this field, there
is little support for reading or writing data in this format. Other
than the existing use for radio interferometry data, the random
groups structure is deprecated and should not be further used.
For other applications, the binary table extension (Sect. 7.3) provides a more extensible and better documented way of associating groups of data within a single data structure.
6.1. Keywords
6.1.1. Mandatory keywords

The SIMPLE keyword is required to be the first keyword in the
primary header of all FITS files, including those with random
groups records. If the random groups format records follow theprimary header, the keyword records of the primary header must
use the keywords defined in Table 12 in the order specified. No
other keywords may intervene between the SIMPLE keyword andthe last NAXISn keyword.
SIMPLE keyword. The keyword record containing this keyword
is structured in the same way as if a primary data array were
present (Sect. 4.4.1).
BITPIX keyword. The keyword record containing this keyword
is structured as prescribed in Sect. 4.4.1.
NAXIS keyword. The value field shall contain an integer ranging from 1 to 999, representing one more than the number ofaxes in each data array.

17
Table 12: Mandatory keywords in primary header preceding random groups.

last

KeywordSIMPLE = T
BITPIXNAXISNAXIS1 = 0
NAXISn, n=2, . . . , value of NAXIS..
.
(other keywords, which must include . . . )GROUPS = T
PCOUNTGCOUNT..
.
END

PSCALn keywords. This keyword shall be used, along with the
PZEROn keyword, when the nth FITS group parameter value is
not the true physical value, to transform the group parametervalue to the true physical values it represents, using Eq. 5. The
value field shall contain a floating-point number representing thecoefficient 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.

AF
T

#
1
2
3
4
5

the value field, then the data value for the parameter of that nameis to be obtained by adding the derived data values of the corresponding parameters. This rule provides a mechanism by whicha random parameter may have more precision than the accompanying data array elements; for example, by summing two 16-bit
values with the first scaled relative to the other such that the sum
forms a number of up to 32-bit precision.

NAXIS1 keyword. The value field shall contain the integer 0,
a signature of random groups format indicating that there is no
primary data array.

NAXISn keywords (n=2, . . . , value of NAXIS). The NAXISn
keywords must be present for all values n = 2, ..., NAXIS,
in increasing order of n, and for no larger values of n. The value
field shall contain an integer, representing the number of positions along axis n-1 of the data array in each group.

DR

GROUPS keyword. The value field shall contain the logical constant T. The value T associated with this keyword implies that
random groups records are present.

PCOUNT keyword. The value field shall contain an integer equal
to the number of parameters preceding each array in a group.
GCOUNT keyword. The value field shall contain an integer equal
to the number of random groups present.

END keyword. This keyword has no associated value. Bytes 9
through 80 shall contain ASCII spaces (decimal 32 or hexadecimal 20).
The total number of bits in the random groups records exclusive of the fill described in Sect. 6.2 is given by the following
expression:
Nbits = |BITPIX| × GCOUNT ×(PCOUNT + NAXIS2 × NAXIS3 × · · · × NAXISm),(4)

where Nbits 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.
6.1.2. Reserved keywords

PTYPEn keywords. The value field shall contain a character
string giving the name of parameter n. If the PTYPEn keywords
for more than one value of n have the same associated name in

PZEROn keywords. This keyword shall be used, along with the
PSCALn keyword, when the nth FITS group parameter value
is not the true physical value, to transform the group parameter value to the physical value. The value field shall contain afloating-point number, representing the true value corresponding to a group parameter value of zero. The default value for thiskeyword is 0.0. The transformation equation is as follows:
physical value = PZEROn + PSCALn × group parm value. (5)6.2. Data sequence

Random groups data shall consist of a set of groups. The number of groups shall be specified by the GCOUNT keyword in theassociated header. Each group shall consist of the number of parameters specified by the PCOUNT keyword followed by an arraywith the number of elements Nelem given by the following expression:
Nelem = (NAXIS2 × NAXIS3 × · · · × NAXISm),(6)

where Nelem is the number of elements in the data array in agroup, m is the value of NAXIS, and the NAXISn represent thevalues associated with those keywords.
The first parameter of the first group shall appear in the firstlocation of the first data block. The first element of each array
shall immediately follow the last parameter associated with thatgroup. 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 data block, the remainder of the block shall be filled withzero values in the same way as a primary data array (Sect. 3.3.2).
If random groups records are present, there shall be no primarydata array.
6.3. Data representation

Permissible data representations are those listed in Sect. 5.
Parameters and elements of associated data arrays shall have thesame representation. If more precision is required for an associated parameter than for an element of a data array, the parameter shall be divided into two or more addends, represented by17

18
Table 13: Mandatory keywords in image extensions.

last

KeywordXTENSION= 'IMAGE'
BITPIXNAXISNAXISn, n = 1, . . . , NAXISPCOUNT = 0
GCOUNT = 1..
.
(other keywords . . . )
..
.
END

the same value for the PTYPEn keyword. The value shall be thesum of the physical values, which may have been obtained fromthe group parameter values using the PSCALn and PZEROn keywords.

7. Standard extensions

NAXISn keywords. The NAXISn keywords must be present for
all values n = 1, ..., NAXIS, in increasing order of n, andfor no other values of n. The value field of this indexed keyword
shall contain a non-negative integer, representing the number of
elements along axis n of a data array. If the value of any of the
NAXISn keywords is zero, then the image extension shall nothave any data blocks following the header. If NAXIS is equal to0, there should not be any NAXISn keywords.

AF
T

#
1
2
3
4
5
6

NAXIS keyword. The value field shall contain a non-negative
integer no greater than 999, representing the number of axes in
the associated data array. If the value is zero then the image extension shall not have any data blocks following the header.

A standard extension is a conforming extension whose organization and content are completely specified in this standard. The
specifications for the 3 currently defined standard extensions,
namely,PCOUNT keyword. The value field shall contain the integer 0.

GCOUNT keyword. The value field shall contain the integer 1;
each image extension contains a single array.
END keyword. This keyword has no associated value. Bytes 9
through 80 shall be filled with ASCII spaces (decimal 32 or hexadecimal 20).
7.1.2. Other reserved keywords

1. ’IMAGE’ extensions;
2. ’TABLE’ ASCII table extensions; and3. ’BINTABLE’ binary table extensions;7.1. Image extension

DR

are given in the following sections. A list of other conforming
extensions is given in Appendix F.

The FITS image extension is nearly identical in structure to thethe primary HDU and is used to store an array of data. Multiple
image extensions can be used to store any number of arrays in asingle FITS file. The first keyword in an image extension shallbe XTENSION= 'IMAGE'.
7.1.1. Mandatory keywords

The XTENSION keyword is required to be the first keyword of
all image extensions. The keyword records in the header of animage extension must use the keywords defined in Table 13 in
the order specified. No other keywords may intervene between
the XTENSION and GCOUNT keywords.

XTENSION keyword. The value field shall contain the character
string 'IMAGE'.
BITPIX keyword. The value field shall contain an integer. The
absolute value is used in computing the sizes of data structures.
It shall specify the number of bits that represent a data value.
The only valid values of BITPIX are given in Table 8. Writers of
IMAGE extensions should select a BITPIX data type appropriate
to the form, range of values, and accuracy of the data in the array.
18

The reserved keywords defined in Sect. 4.4.2 (except for EXTEND
and BLOCKED) may appear in an image extension header. The
keywords must be used as defined in that section.

7.1.3. Data sequence

The data format shall be identical to that of a primary data arrayas described in Sect. 3.3.2.
7.2. The ASCII table extension

The ASCII table extension provides a means of storing catalogs and tables of astronomical data in FITS format. Each rowof the table consists of a fixed-length sequence of ASCII characters divided into fields that correspond to the columns in thetable. The first keyword in an ASCII table extension shall be
XTENSION= 'TABLE'.
7.2.1. Mandatory keywords

The header of an ASCII table extension must use the keywords defined in Table 14. The first keyword must be XTENSION;
the seven keywords following XTENSION (BITPIX . . . TFIELDS)
must be in the order specified with no intervening keywords.
XTENSION keyword. The value field shall contain the character
string value text 'TABLE'.
BITPIX keyword. The value field shall contain the integer 8,denoting that the array contains ASCII characters.

19
Table 14: Mandatory keywords in ASCII table extensions.

last

KeywordXTENSION= 'TABLE'
BITPIX = 8
NAXIS = 2
NAXIS1NAXIS2PCOUNT = 0
GCOUNT = 1
TFIELDS..
.
(other keywords, including (if TFIELDS is not zero) . . . )TTYPEn, n=1, 2, . . . , k where k is the value of TFIELDS (Recommended)
TBCOLn, n=1, 2, . . . , k where k is the value of TFIELDS (Required)
TFORMn, n=1, 2, . . . , k where k is the value of TFIELDS (Required)
..
.
END

AF
T

#
1
2
3
4
5
6
7
8

NAXIS keyword. The value field shall contain the integer 2, denoting that the included data array is two-dimensional: rows andcolumns.

NAXIS1 keyword. The value field shall contain a non-negative
integer, giving the number of ASCII characters in each row of
the table. This includes all the characters in the defined fields
plus any characters that are not included in any field.

DR

NAXIS2 keyword. The value field shall contain a non-negative
integer, giving the number of rows in the table.
PCOUNT keyword. The value field shall contain the integer 0.

Table 15: Valid TFORMn format values in TABLE extensions.
Field value
Aw
Iw
Fw.d
Ew.d
Dw.d

Data type
Character
Decimal integer
Floating-point, fixed decimal notation
Floating-point, exponential notation
Floating-point, exponential notation

Notes. w is the width in characters of the field and d is the number ofdigits to the right of the decimal.

tions are not permitted. The TDISPn keyword, defined in Sect.
7.2.2, may be used to recommend that a decimal integer value inan ASCII table be displayed as the equivalent binary, octal, or
hexadecimal value.

GCOUNT keyword. The value field shall contain the integer 1;
the data blocks contain a single table.

TFIELDS keyword. The value field shall contain a non-negative
integer representing the number of fields in each row. The maximum permissible value is 999.
TBCOLn keywords. The TBCOLn keywords must be present for
all values n = 1, ..., TFIELDS and for no other values of n.
The value field of this indexed keyword shall contain an integer
specifying the column in which field n starts. The first columnof a row is numbered 1.

TFORMn keywords. The TFORMn keywords must be present for
all values n = 1, ..., TFIELDS and for no other values of n.
The value field of this indexed keyword shall contain a character
string describing the format in which field n is encoded. Only theformats in Table 15, interpreted as Fortran (ISO 2004) input formats and discussed in more detail in Sect. 7.2.5, are permitted for
encoding. Format codes must be specified in upper case. Other
format editing codes common to Fortran such as repetition, positional editing, scaling, and field termination are not permitted.
All values in numeric fields have a number base of ten (i.e., they
are decimal); binary, octal, hexadecimal, and other representa-

END keyword. This keyword has no associated value. Bytes 9
through 80 shall contain ASCII spaces (decimal 32 or hexadecimal 20).
7.2.2. Other reserved keywords

In addition to the reserved keywords defined in Sect. 4.4.2 (except for EXTEND and BLOCKED), the following other reserved
keywords may be used to describe the structure of an ASCII table data array. They are optional, but if they appear within an
ASCII table extension header, they must be used as defined inthis section of this standard.
TTYPEn keywords. The value field for this indexed keyword
shall contain a character string giving the name of field n. It isstrongly recommended that every field of the table be assigned
a unique, case-insensitive name with this keyword, and it is recommended that the character string be composed only of upperand lower case letters, digits, and the underscore (‘ ’, decimal95, hexadecimal 5F) character. Use of other characters is not recommended because it may be difficult to map the column names
into variables in some languages (e.g., any hyphens, ‘*’ or ‘+’
characters in the name may be confused with mathematical op19

20
Table 16: Valid TDISPn format values in TABLE extensions.
Data type
Character
Integer
Binary, integers only
Octal, integers only
Hexadecimal, integers only
Floating-point, fixed decimal notation
Floating-point, exponential notation
Engineering; E format with exponent multiple of three
Scientific; same as EN but non-zero leading digit if not zero
General; appears as F if significance not lost, else E.
Floating-point, exponential notation

AF
T

Field value
Aw
Iw.m
Bw.m
Ow.m
Zw.m
Fw.d
Ew.dEeENw.d
ESw.d
Gw.dEeDw.dEeNotes. w is the width in characters of displayed values, m is the minimum number of digits displayed, d is the number of digits to right of decimal,and e is number of digits in exponent. The .m and Ee fields are optional.

erators). String comparisons with the TTYPEn keyword values
should not be case sensitive (e.g., ’TIME’ and ’Time’ should beinterpreted as the same name).

TUNITn keywords. The value field shall contain a character
string describing the physical units in which the quantity in fieldn, after any application of TSCALn and TZEROn, is expressed.
Units must follow the prescriptions in Sect. 4.3.

DR

TSCALn keywords. This indexed keyword shall be used, alongwith the TZEROn keyword, to linearly scale the values in the table field n to transform them into the physical values that they
represent using Eq. 7. The value field shall contain a floatingpoint number representing the coefficient of the linear term inthe scaling equation. The default value for this keyword is 1.0.
This keyword must not be used for A-format fields.
The transformation equation used to compute a true physicalvalue from the quantity in field n is
physical value = TZEROn + TSCALn × field value(7)

played. All elements in a field shall be displayed with a single,
repeated format. Only the format codes in Table 16, interpreted
as Fortran (ISO 2004) output formats, and discussed in more detail in Sect. 7.3.4, are permitted for encoding. The format codes
must be specified in upper case. If the Bw.m, Ow.m, and Zw.m
formats are not readily available to the reader, the Iw.m display
format may be used instead, and if the ENw.d and ESw.d formats
are not available, Ew.d may be used.

The following four keywords may be used to specify minimum
and maximum values in numerical columns of a FITS ASCII or
binary table. These keywords must have the same data type as
the physical values in the associated column (either an integer ora floating point number). Any undefined elements in the column
shall be excluded when determining the value of these keywords.
TDMINn keywords. The value field shall contain a number giving the minimum physical value contained in column n of thetable. This keyword is analogous to the DATAMIN keyword thatis defined for arrays in Sect. 4.4.2.5.

where field value is the value that is actually stored in thattable field in the FITS file.

TZEROn keywords. This indexed keyword shall be used, alongwith the TSCALn keyword, to linearly scale the values in the table field n to transform them into the physical values that they
represent using Eq. 7. The value field shall contain a floatingpoint number representing the physical value corresponding toan array value of zero. The default value for this keyword is 0.0.
This keyword must not be used for A-format fields.

TNULLn keywords. The value field for this indexed keyword
shall contain the character string that represents an undefinedvalue for field n. The string is implicitly space filled to the widthof the field.
TDISPn keywords. The value field of this indexed keyword
shall contain a character string describing the format recommended for displaying an ASCII text representation of of thecontents of field n. This keyword overrides the default display
format given by the TFORMn keyword. If the table value has
been scaled, the physical value, derived using Eq. 7, shall be dis20

TDMAXn keywords. The value field shall contain a number giving the maximum physical value contained in column n of thetable. This keyword is analogous to the DATAMAX keyword thatis defined for arrays in Sect. 4.4.2.5.
TLMINn keywords. The value field shall contain a number thatspecifies the minimum physical value in column n that has avalid meaning or interpretation. The column is not required
to actually contain any elements that have this value, and thecolumn may contain elements with physical values less than
TLMINn, however, the interpretation of any such out-of-range
column elements is not defined.
TLMAXn keywords. The value field shall contain a number thatspecifies the maximum physical value in column n that has avalid meaning or interpretation. The column is not required toactually contain any elements that have this value, and the column may contain elements with physical values greater than
TLMAXn, however, the interpretation of any such out-of-range
column elements is not defined.

21
The TLMINn and TLMAXn keywords are commonly used whenconstructing histograms of the data values in a column. For example, if a table contains columns that give the X and Y pixel
location of a list of photons that were detected by a photon counting device, then the TLMINn and TLMAXn keywords could be used
to specify the minimum and maximum values that the detector
is capable of assigning to the X and Y columns.
7.2.3. Data sequence

7.2.4. Fields

Character fields. The value of a character-formatted (Aw) fieldAF
T

The table is constructed from a two-dimensional array of ASCII
characters. The row length and the number of rows shall be thosespecified, respectively, by the NAXIS1 and NAXIS2 keywords ofthe associated header. The number of characters in a row and thenumber of rows in the table shall determine the size of the character array. Every row in the array shall have the same number ofcharacters. The first character of the first row shall be at the startof the data block immediately following the last header block.
The first character of subsequent rows shall follow immediately
the character at the end of the previous row, independent of the
FITS block structure. The positions in the last data block after
the last character of the last row of the table shall be filled withASCII spaces.

accuracy of the data in that field. This standard does not impose
an upper limit on the number of digits of precision, nor any limiton the range of numeric values. Software packages that read or
write data according to this standard could be limited, however,in the range of values and exponents that are supported (e.g.,
to the range that can be represented by 32-bit or 64-bit binary
numbers).
The value of each entry shall be interpreted as described in
the following paragraphs.

DR

Each row in the array shall consist of a sequence of from 0 to
999 fields, as specified by the TFIELDS keyword, with one entry
in each field. For every field, the Fortran (ISO 2004) format of
the information contained (given by the TFORMn keyword), thelocation in the row of the beginning of the field (given by the
TBCOLn keyword), and (optionally, but strongly recommended)
the field name (given by the TTYPEn keyword), shall be specified in the associated header. The location and format of fields
shall be the same for every row. Fields may overlap, but this usage is not recommended. Only a limited set of ASCII character
values may appear within any field, depending on the field typeas specified below. There may be characters in a table row thatare not included in any field, (e.g., between fields, or before thefirst field or after the last field). Any 7-bit ASCII character may
occur in characters of a table row that are not included in a defined field. A common convention is to include a space character
between each field for added legibility if the table row is displayed verbatim. It is also permissible to add control characters,such as a carriage return or line feed character, following the last
field in each row as a way of formatting the table if it is printed
or displayed by a text editing program.
7.2.5. Entries

All data in an ASCII table extension field shall be ASCII text ina format that conforms to the rules for fixed field input in Fortran(ISO 2004) format, as described below. The only possible formats shall be those specified in Table 15. If values of −0 and+0 need to be distinguished, then the sign character should appear in a separate field in character format. TNULLn keywords
may be used to specify a character string that represents an undefined value in each field. The characters representing an undefined value may differ from field to field but must be the same
within a field. Writers of ASCII tables should select a format foreach field that is appropriate to the form, range of values, andis a character string of width w containing the characters incolumns TBCOLn through TBCOLn+w − 1. The character string
shall be composed of the restricted set of ASCII text characterswith decimal values in the range 32 through 126 (hexadecimal
20 through 7E).
Integer fields. The value of an integer-formatted (Iw) field isa signed decimal integer contained in columns TBCOLn through
TBCOLn+w − 1 consisting of a single optional sign (‘+’ or ‘-’)followed by one or more decimal digits (‘0’ through ‘9’). Nonsignificant space characters may precede and/or follow the integer value within the field. A blank field has value 0. All characters other than leading and trailing spaces, a contiguous string ofdecimal digits, and a single leading sign character are forbidden.

Real fields. The value of a real-formatted field (Fw.d, Ew.d,
Dw.d) is a real number determined from the w characters fromcolumns TBCOLn through TBCOLn+w − 1. The value is formedby

1. discarding any trailing space characters in the field and rightjustifying the remaining characters,
2. interpreting the first non-space characters as a numeric string
consisting of a single optional sign (‘+’ or ‘-’) followed
by one or more decimal digits (‘0’ through ‘9’) optionallycontaining a single decimal point (‘.’). The numeric stringis terminated by the end of the right-justified field or by theoccurrence of any character other than a decimal point (‘.’)
and the decimal integers (‘0’ through ‘9’). If the string
contains no explicit decimal point, then the implicit decimal point is taken as immediately preceding the rightmost
d digits of the string, with leading zeros assumed if necessary. The use of implicit decimal points is deprecated andis strongly discouraged because of the possibility that FITS
reading programs will misinterpret the data value. Therefore,real-formatted fields should always contain an explicit decimal point.
3. If the numeric string is terminated by a(a) ‘+’ or ‘-’, interpreting the following string as an exponent in the form of a signed decimal integer, or(b) ‘E’, or ‘D’, interpreting the following string as an exponent of the form E or D followed by an optionally signed
decimal integer constant.
4. The exponent string, if present, is terminated by the end of
the right-justified string.
5. Characters other than those specified above, including embedded space characters, are forbidden.
The numeric value of the table field is then the value of the numeric string multiplied by ten (10) to the power of the exponent
21

22

7.3. Binary table extension

The binary table extension is similar to the ASCII table in that itprovides a means of storing catalogs and tables of astronomical
data in FITS format, however, it offers more features and provides more-efficient data storage than ASCII tables. The numerical values in binary tables are stored in more-compact binary
formats rather than coded into ASCII, and each field of a binary
table can contain an array of values rather than a simple scalar
as in ASCII tables. The first keyword in a binary table extension
shall be XTENSION= 'BINTABLE'.
7.3.1. Mandatory keywords

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 17, withno intervening keywords.

DR

XTENSION keyword. The value field shall contain the character
string 'BINTABLE'.
BITPIX keyword. The value field shall contain the integer 8,denoting that the array is an array of 8-bit bytes.
NAXIS keyword. The value field shall contain the integer 2, denoting that the included data array is two-dimensional: rows andcolumns.

NAXIS1 keyword. The value field shall contain a non-negative
integer, giving the number of 8-bit bytes in each row of the table.
NAXIS2 keyword. The value field shall contain a non-negative
integer, giving the number of rows in the table.
PCOUNT keyword. The value field shall contain the number ofbytes that follow the table in the supplemental data area called
the heap.
GCOUNT keyword. The value field shall contain the integer 1;
the data blocks contain a single table.
TFIELDS keyword. The value field shall contain a non-negative
integer representing the number of fields in each row. The maximum permissible value is 999.
22

Table 18: Valid TFORMn data types in BINTABLE extensions.
TFORMn value
L
X
B
I
J
K
A
E
D
C
M
P
Q

Description
LogicalBit
Unsigned byte
16-bit integer
32-bit integer
64-bit integer
Character
Single precision floating point
Double precision floating point
Single precision complex
Double precision complex
Array Descriptor (32-bit)
Array Descriptor (64-bit)AFT

string, i.e., value = numeric string × 10(exponent string) . The default
exponent is zero and a blank field 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 acolumn of an ASCII table when that column will contain numbers that cannot be accurately represented in 32-bit IEEE binary
format (see Appendix E).

8-bit Bytes
1
†
1
2
4
8
1
4
8
8
16
8
16

Notes. (†) Number of 8-bit bytes needed to contain all bits.

TFORMn keywords. The TFORMn keywords must be present for
all values n = 1, ..., TFIELDS and for no other values of n.
The value field of this indexed keyword shall contain a character
string of the form rTa. The repeat count r is the ASCII representation of a non-negative integer specifying the number of elements in field n. The default value of r is 1; the repeat count neednot be present if it has the default value. A zero element count,indicating an empty field, is permitted. The data type T specifies
the data type of the contents of field n. Only the data types inTable 18 are permitted. The format codes must be specified inupper case. For fields of type P or Q, the only permitted repeat
counts are 0 and 1. The additional characters a are optional andare not further defined in this standard. Table 18 lists the numberof bytes each data type occupies in a table row. The first field of
a row is numbered 1. The total number of bytes nrow in a tablerow is given bynrow =TFIELDS
X

ri bi

(8)

i=1

where ri is the repeat count for field i, bi is the number of bytes
for the data type in field i, and TFIELDS is the value of that keyword, must equal the value of NAXIS1.
END keyword. This keyword has no associated value. Bytes 9
through 80 shall contain ASCII spaces (decimal 32 or hexadecimal 20).
7.3.2. Other reserved keywords

In addition to the reserved keywords defined in Sect. 4.4.2 (except for EXTEND and BLOCKED), the following other reserved
keywords may be used to describe the structure of a binary tabledata array. They are optional, but if they appear within a binary
table extension header, they must be used as defined in this section of this standard.
TTYPEn keywords. The value field for this indexed keyword
shall contain a character string giving the name of field n. It isstrongly recommended that every field of the table be assigned
a unique, case-insensitive name with this keyword, and it is recommended that the character string be composed only of upper

23
Table 17: Mandatory keywords in binary table extensions.

last

KeywordXTENSION= 'BINTABLE'
BITPIX = 8
NAXIS = 2
NAXIS1NAXIS2PCOUNTGCOUNT = 1
TFIELDS..
.
(other keywords, including (if TFIELDS is not zero) . . . )TTYPEn, n=1, 2, . . . , k where k is the value of TFIELDS (Recommended)
TFORMn, n=1, 2, . . . , k where k is the value of TFIELDS (Required)
..
.
END

AF
T

#
1
2
3
4
5
6
7
8

and lower case letters, digits, and the underscore (‘ ’, decimal95, hexadecimal 5F) character. Use of other characters is not recommended because it may be difficult to map the column names
into variables in some languages (e.g., any hyphens, ‘*’ or ‘+’
characters in the name may be confused with mathematical operators). String comparisons with the TTYPEn keyword values
should not be case sensitive (e.g., ’TIME’ and ’Time’ should beinterpreted as the same name).

DR

TUNITn keywords. The value field shall contain a character
string describing the physical units in which the quantity in fieldn, after any application of TSCALn and TZEROn, is expressed.
Units must follow the prescriptions in Sect. 4.3.

TSCALn keywords. This indexed keyword shall be used, alongwith the TZEROn keyword, to linearly scale the values in the table
field n to transform them into the physical values that they represent using Eq. 7. It must not be used if the format of field n is A,
L, or X. For fields with all other data types, the value field shallcontain a floating-point number representing the coefficient of
the linear term in Eq. 7, which is used to compute the true physical value of the field, or, in the case of the complex data types C
and M, of the real part of the field, with the imaginary part of thescaling factor set to zero. The default value for this keyword is1.0. For fields of type P or Q, the values of TSCALn and TZEROnare to be applied to the values in the data array in the heap area,
not the values of the array descriptor (see Sect. 7.3.5).
TZEROn keywords. This indexed keyword shall be used, alongwith the TSCALn keyword, to linearly scale the values in the table field n to transform them into the physical values that they
represent using Eq. 7. It must not be used if the format of field n
is A, L, or X. For fields with all other data types, the value fieldshall contain a floating-point number representing the true physical value corresponding to a value of zero in field n of the FITS
file, or, in the case of the complex data types C and M, in the realpart of the field, with the imaginary part set to zero. The default
value for this keyword is 0.0. Equation 7 is used to compute atrue physical value from the quantity in field n. For fields of typeP or Q, the values of TSCALn and TZEROn are to be applied to thevalues in the data array in the heap area, not the values of thearray descriptor (see Sect. 7.3.5).

In addition to its use in representing floating-point values
as scaled integers, the TZEROn keyword is also used when storing unsigned integer values in the field. In this special case the
TSCALn keyword shall have the default value of 1.0 and the
TZEROn keyword shall have one of the integer values shown in
Table 19
Since the binary table format does not support a native unsigned integer data type (except for the unsigned 8-bit ’B’ column type), the unsigned values are stored in the field as native
signed integers with the appropriate integer offset specified by
the TZEROn keyword value shown in the table. For the byte column type, the converse technique can be used to store signed
byte values as native unsigned values with the negative TZEROnoffset. In each case, the physical value is computed by adding theoffset specified by the TZEROn keyword to the native data typevalue that is stored in the table field.

TNULLn keywords. The value field for this indexed keyword
shall contain the integer that represents an undefined value forfield n of data type B, I, J or K, or P or Q array descriptor fields(Sect. 7.3.5) that point to B, I, J or K integer arrays. The keyword
must not be used if field n is of any other data type. The value of
this keyword corresponds to the table column values before applying any transformation indicated by the TSCALn and TZEROn
keywords.
If the TSCALn and TZEROn keywords do not have the default
values of 1.0 and 0.0, respectively, then the value of the TNULLn
keyword must equal the actual value in the FITS file that isused to represent an undefined element and not the corresponding physical value (computed from Eq. 7). To cite a specific,
common example, unsigned 16-bit integers are represented in asigned integer column (with TFORMn = ’I’) by setting TZEROn= 32768 and TSCALn = 1. If it is desired to use elements thathave an unsigned value (i.e., the physical value) equal to 0 to
represent undefined elements in the field, then the TNULLn keyword must be set to the value -32768 because that is the actual
value stored in the FITS file for those elements in the field.
TDISPn keywords. The value field of this indexed keyword
shall contain a character string describing the format recommended for displaying an ASCII text representation of the contents of field n. If the table value has been scaled, the physical23

24
Table 19: Usage of TZEROn to represent non-default integer data types.
TFORMnB
I
JK

Nativedata typeunsignedsignedsignedsignedPhysicaldata typesigned byte
unsigned 16-bit
unsigned 32-bit
unsigned 64-bit

-128
32768
2147483648
9223372036854775808(−27 )(215 )(231 )(263 )

The following four keywords may be used to specify minimum
and maximum values in numerical columns of a FITS ASCII or
binary table. These keywords must have the same data type as
the physical values in the associated column (either an integer ora floating point number). Any undefined elements in the column
or any other IEEE special values in the case of floating pointcolumns shall be excluded when determining the value of these
keywords.

AFT

value, derived using Eq. 7, shall be displayed. All elements in afield shall be displayed with a single, repeated format. For purposes of display, each byte of bit (type X) and byte (type B) arrays is treated as an unsigned integer. Arrays of type A may beterminated with a zero byte. Only the format codes in Table 20,
interpreted as Fortran (ISO 2004) output formats, and discussed
in more detail in Sect. 7.3.4, are permitted for encoding. The
format codes must be specified in upper case. If the Bw.m, Ow.m,and Zw.m formats are not readily available to the reader, the Iw.m
display format may be used instead, and if the ENw.d and ESw.dformats are not available, Ew.d may be used. In the case of fieldsof type P or Q, the TDISPn value applies to the data array pointed
to by the array descriptor (Sect. 7.3.5), not the values in the arraydescriptor itself.

TZEROnDR

THEAP keyword. The value field of this keyword shall containan integer providing the separation, in bytes, between the startof the main data table and the start of a supplemental data area
called the heap. The default value, which is also the minimum
allowed value, shall be the product of the values of NAXIS1 and
NAXIS2. This keyword shall not be used if the value of PCOUNT
is zero. The use of this keyword is described in in Sect. 7.3.5.

TDIMn keywords. The value field of this indexed keyword shallcontain a character string describing how to interpret the contents of field n as a multi-dimensional array with a format of’(l,m,n...)’ where l, m, n, . . . are the dimensions of the array. The data are ordered such that the array index of the first
dimension given (l) is the most rapidly varying and that of thelast dimension given is the least rapidly varying. The total number of elements in the array equals the product of the dimensions
specified in the TDIMn keyword. The size must be less than orequal to the repeat count on the TFORMn keyword, or, in the caseof columns that have a ’P’ or ’Q’ TFORMn data type, less than orequal to the array length specified in the variable-length array descriptor (see Sect. 7.3.5). In the special case where the variablelength array descriptor has a size of zero, then the TDIMn keyword is not applicable. If the number of elements in the array
implied by the TDIMn is less than the allocated size of the array in the FITS file, then the unused trailing elements should beinterpreted as containing undefined fill values.
A character string is represented in a binary table by a onedimensional character array, as described under ‘Character’ inthe list of data types in Sect. 7.3.3. For example, a Fortran
CHARACTER*20 variable could be represented in a binary table as a character array declared as TFORMn = '20A'. Arraysof strings, i.e., multi-dimensional 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
4 × 3 array of strings of five characters each.
24

TDMINn keywords. The value field shall contain a number giving the minimum physical value contained in column n of thetable. This keyword is analogous to the DATAMIN keyword thatis defined for arrays in Sect. 4.4.2.5.

TDMAXn keywords. The value field shall contain a number giving the maximum physical value contained in column n of thetable. This keyword is analogous to the DATAMAX keyword thatis defined for arrays in Sect. 4.4.2.5.
TLMINn keywords. The value field shall contain a number thatspecifies the minimum physical value in column n that has avalid meaning or interpretation. The column is not required
to actually contain any elements that have this value, and thecolumn may contain elements with physical values less than
TLMINn, however, the interpretation of any such out-of-range
column elements is not defined.
TLMAXn keywords. The value field shall contain a number thatspecifies the maximum physical value in column n that has avalid meaning or interpretation. The column is not required toactually contain any elements that have this value, and the column may contain elements with physical values greater than
TLMAXn, however, the interpretation of any such out-of-range
column elements is not defined.
The TLMINn and TLMAXn keywords are commonly used whenconstructing histograms of the data values in a column. For example, if a table contains columns that give the X and Y pixel
location of a list of photons that were detected by a photon counting device, then the TLMINn and TLMAXn keywords could be used
to specify the minimum and maximum values that the detector
is capable of assigning to the X and Y columns.
7.3.3. Data sequence

The data in a binary table extension shall consist of a main datatable which may, but need not, be followed by additional bytes inthe supplemental data area. The positions in the last data block
after the last additional byte, or, if there are no additional bytes,

25
Table 20: Valid TDISPn format values in BINTABLE extensions.
Data type
Character
LogicalInteger
Binary, integers only
Octal, integers only
Hexadecimal, integers only
Floating-point, fixed decimal notation
Floating-point, exponential notation
Engineering; E format with exponent multiple of three
Scientific; same as EN but non-zero leading digit if not zero
General; appears as F if significance not lost, else E.
Floating-point, exponential notation

AF
T

Field Value
Aw
Lw
Iw.m
Bw.m
Ow.m
Zw.m
Fw.d
Ew.dEeENw.d
ESw.d
Gw.dEeDw.dEeNotes. w is the width in characters of displayed values, m is the minimum number of digits displayed, d is the number of digits to right of decimal,and e is number of digits in exponent. The .m and Ee fields are optional.

the last character of the last row of the main data table, shall befilled by setting all bits to zero.

bytes, with those bits following the end of the data set to zero.
No null value is defined for bit arrays.

7.3.3.1. Main data table

Character. If the value of the TFORMn keyword specifies data
type A, field n shall contain a character string of zero or moremembers, composed of the restricted set of ASCII text characters. This character string may be terminated before the length
specified by the repeat count by an ASCII NULL (hexadecimalcode 00). Characters after the first ASCII NULL are not defined.
A string with the number of characters specified by the repeat
count is not NULL terminated. Null strings are defined by thepresence of an ASCII NULL as the first character.

DR

The table is constructed from a two-dimensional byte array. The number of bytes in a row shall be specified by thevalue of the NAXIS1 keyword and the number of rows shallbe specified by the NAXIS2 keyword of the associated header.
Within a row, fields shall be stored in order of increasing column
number, as determined from the n of the TFORMn keywords. The
number of bytes in a row and the number of rows in the tableshall determine the size of the byte array. Every row in the array
shall have the same number of bytes. The first row shall begin at
the start of the data block immediately following the last header
block. Subsequent rows shall begin immediately following theend of the previous row, with no intervening bytes, independentof the FITS block structure. Words need not be aligned along
word boundaries.
Each row in the array shall consist of a sequence of from 0
to 999 fields as specified by the TFIELDS keyword. The numberof elements in each field and their data type shall be specified
by the TFORMn keyword in the associated header. A separate format keyword must be provided for each field. The location andformat of fields shall be the same for every row. Fields may be
empty, if the repeat count specified in the value of the TFORMn
keyword of the header is 0. Writers of binary tables should selecta format appropriate to the form, range of values, and accuracyof the data in the table. The following data types, and no others,
are permitted.
Logical. If the value of the TFORMn keyword specifies data typeL, the contents of field n shall consist of ASCII T indicating trueor ASCII F, indicating false. A 0 byte (hexadecimal 00) indicatesa NULL value.
Bit array. If the value of the TFORMn keyword specifies data type

X, the contents of field n shall consist of a sequence of bits starting with the most significant bit; the bits following shall be inorder of decreasing significance, ending with the least significant bit. A bit array shall be composed of an integral number of

Unsigned 8-Bit integer. If the value of the TFORMn keyword

specifies data type B, the data in field n shall consist of unsigned
8-bit integers, with the most significant bit first, and subsequent
bits in order of decreasing significance. Null values are given by
the value of the associated TNULLn keyword. Signed integers canbe represented using the convention described in Sect. 5.2.5.

16-Bit integer. If the value of the TFORMn keyword specifies

data type I, the data in field n shall consist of two’s complement
signed 16-bit integers, contained in two bytes. The most significant byte shall be first (big-endian byte order). Within each byte
the most significant bit shall be first, and subsequent bits shallbe in order of decreasing significance. Null values are given by
the value of the associated TNULLn keyword. Unsigned integers
can be represented using the convention described in Sect. 5.2.5.

32-Bit integer. If the value of the TFORMn keyword specifies

data type J, the data in field n shall consist of two’s complement signed 32-bit integers, contained in four bytes. The mostsignificant byte shall be first, and subsequent bytes shall be inorder of decreasing significance (big-endian byte order). Withineach byte, the most significant bit shall be first, and subsequent
bits shall be in order of decreasing significance. Null values are
given by the value of the associated TNULLn keyword. Unsigned
integers can be represented using the convention described in
Sect. 5.2.5.
25

26
64-Bit integer. If the value of the TFORMn keyword specifies

7.3.4. Data display

The indexed TDISPn keyword may be used to describe the recommended format for displaying an ASCII text representationof the contents of field n. The permitted display format codes
for each type of data (i.e., character strings, logical, integer, orreal) are given in Table 20 and described below.
Character data. If the table column contains a character string(with TFORMn = ’rA’) then the TDISPn format code must be’Aw’ where w is the number of characters to display. If the character datum has length less than or equal to w, it is represented
on output right-justified in a string of w characters. If the character datum has length greater than w, the first w characters ofthe datum are represented on output in a string of w characters.
Character data are not surrounded by single or double quotation
marks unless those marks are themselves part of the data value.

AFTdata type K, the data in field n shall consist of two’s complement signed 64-bit integers, contained in eight bytes. The mostsignificant byte shall be first, and subsequent bytes shall be inorder of decreasing significance. Within each byte, the most significant bit shall be first, and subsequent bits shall be in order ofdecreasing significance (big-endian byte order). Null values are
given by the value of the associated TNULLn keyword. Unsigned
integers can be represented using the convention described in
Sect. 5.2.5.

Single precision floating point. If the value of the TFORMn keyword specifies data type E, the data in field n shall consist of
ANSI/IEEE-754 (IEEE 1985) 32-bit floating-point numbers, inbig-endian byte order, as described in Appendix E. All IEEE
special values are recognized. The IEEE NaN is used to represent null values.

Logical data. If the table column contains logical data (withDouble precision floating point. If the value of the TFORMn

keyword specifies data type D, the data in field n shall consist of ANSI/IEEE-754 (IEEE 1985) 64-bit double precision
floating-point numbers, in big-endian byte order, as described inAppendix E. All IEEE special values are recognized. The IEEE
NaN is used to represent null values.

TFORMn = ’rL’) then the TDISPn format code must be ’Lw’
where w is the width in characters of the display field. Logical
data are represented on output with the character T for true or F
for false right-justified in a space-filled string of w characters. A
null value may be represented by a string of w space characters.
Integer data. If the table column contains integer data (withSingle precision complex. If the value of the TFORMn keywordDR

specifies data type C, the data in field n shall consist of a sequence of pairs of 32-bit single precision floating-point numbers. The first member of each pair shall represent the real partof a complex number, and the second member shall represent
the imaginary part of that complex number. If either member
contains an IEEE NaN, the entire complex value is null.

Double precision complex. If the value of the TFORMn keyword

specifies data type M, the data in field n shall consist of a sequence of pairs of 64-bit double precision floating-point numbers. The first member of each pair shall represent the real partof a complex number, and the second member of the pair shallrepresent the imaginary part of that complex number. If either
member contains an IEEE NaN, the entire complex value is null.

Array descriptor. The repeat count on the P and Q array descriptor fields must either have a value of 0 (denoting an empty fieldof zero bytes) or 1. If the value of the TFORMn keyword specifies
data type 1P, the data in field n shall consist of one pair of 32-bit
integers. If the value of the TFORMn keyword specifies data type
1Q, the data in field n shall consist of one pair of 64-bit integers.
The meaning of these integers is defined in Sect. 7.3.5.

7.3.3.2. Bytes following main table

The main data table may be followed by a supplemental
data area called the heap. The size of the supplemental dataarea, in bytes, is specified by the value of the PCOUNT keyword.
The use of this data area is described in Sect. 7.3.5.
26

TFORMn = ’rX’, ’rB’, ’rI’, ’rJ’, or ’rK’) then the
TDISPn format code may have any of these forms: Iw.m, Bw.m,
Ow.m, orZw.m. The default value of m is one and the ‘.m’ isoptional. The first letter of the code specifies the number basefor 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 spaces followed by a minus sign if theinternal datum is negative (only in the case of decimal encoding with the I format code) followed by the magnitude of theinternal datum in the form of an unsigned integer constant in thespecified number base with only as many leading zeros as areneeded 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 stringof w asterisk (*) characters.
Real data. If the table column contains real data (with TFORMn= ’rE’, or ’rD’) or contains integer data (with any of the
TFORMn format codes listed in the previous paragraph) which
are recommended to be displayed as real values (i.e., especiallyin cases where the integer values represent scaled physical values using Eq. 7), then the TDISPn format code may have anyof these forms: Fw.d, Ew.dEe, Dw.dEe, ENw.d, or ESw.d. In allcases, 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.

27
mechanism becomes seriously inefficient. If the limit is set too
low then storing certain types of data in the table could become
impossible.
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 that does not understand variablelength arrays will still be able to read the main data table (inother words a table containing variable-length arrays conforms
to the basic binary table standard). The implementation chosen
is such that the rows in the main data table remain fixed in size
even if the table contains a variable-length array field, allowing
efficient random access to the main data table.
Variable-length arrays are logically equivalent to regularstatic arrays, the only differences being 1) the length of the stored
array can differ for different rows, and 2) the array data are notstored directly in the main data table. Since a field of any data
type can be a static array, a field of any data type can also be avariable-length array (excluding the type P and Q variable-length
array descriptors themselves, which are not a data type so muchas a storage-class specifier). Other established FITS conventions
that apply to static arrays will generally apply as well to variablelength arrays.
A variable-length array is declared in the table header with
one of the following two special field data type specifiers

DR

AF
T

The F format code output field consists of w − d − 1 characters containing zero or more leading spaces followed by a minus
sign if the internal datum is negative followed by the absolutemagnitude 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 thatthe fraction 0.1 ≤ |datum|/10exponent < 1.0. The fraction (withappropriate sign) is output with an F format of width w − e − 2characters with d characters after the decimal followed by an E
or D followed by the exponent as a signed e + 1 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 e + 1 characters but will fit in e + 2 then the E(or D) is omitted and the wider field used. If the exponent value
will not fit (with a sign character) in e + 2 characters, then theentire 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 1.0 ≤fraction < 10.
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 three and so that 1.0 ≤ fraction < 1000.0. 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 thedecimal) when that format will accurately represent the value
and is equivalent to an E format when the number (in absolutevalue) is either very small or very large. Specifically, for realvalues outside the range 0.1 − 0.5 × 10−d−1 ≤ value < 10d −0.5, it is equivalent to Ew.dEe. For real values within the above
range, it is equivalent to Fw′ .d′ followed by 2 + e spaces, wherew′ = w − e − 2 and d′ = d − k for k = 0, 1, . . . , d if the real
datum value lies in the range 10k−1 1 − 0.5×10−d ≤ value ≤
10k 1 − 0.5×10−d .
Complex data. If the table column contains complex data (withTFORMn = ’rC’, or ’rM’) then the may be displayed with anyof the real data formats as described above. The same format isused for the real and imaginary parts. It is recommended that thetwo values be separated by a comma and enclosed in parentheseswith a total field width of 2w + 3.
7.3.5. Variable-length arrays

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 ineach row for the array data—whether it is used or not. This is fineso long as the arrays are small or a fixed amount of array data
will be stored in each field, but if the stored array length varies
for different rows, it is necessary to impose a fixed upper limit on
the size of the array that can be stored. If this upper limit is madetoo large excessive wasted space can result and the binary tablerPt(emax )rQt(emax )where the ‘P’ or ‘Q’ indicates the presence of an array descriptor (described below), the element count r should be 0, 1, or
absent, t is a character denoting the data type of the array data
(L, X, B, I, J, K, etc., but not P or Q), and emax is a quantity guaranteed to be equal to or greater than the maximum number of
elements of type t actually stored in any row of the table. Thereis no built-in upper limit on the size of a stored array (other than
the fundamental limit imposed by the range of the array descriptor, defined below); emax merely reflects the size of the largest
array actually stored in the table, and is provided to avoid theneed to preview the table when, for example, reading a tablecontaining variable-length elements into a database that supports
only fixed-size arrays. There may be additional characters in the
TFORMn keyword following the emax .
For example,
TFORM8 = ’PB(1800)’ / Variable byte arrayindicates that field 8 of the table is a variable-length array oftype 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 are notstored in the main data table; they are stored in a supplemental
data area, the heap, following the main data table. What is stored
in the main data table field is an array descriptor. This consistsof two 32-bit signed integer values in the case of ‘P’ array descriptors, or two 64-bit signed integer values in the case of ‘Q’array descriptors: the number of elements (array length) of thestored array, followed by the zero-indexed byte offset of the firstelement of the array, measured from the start of the heap area.
The meaning of a negative value for either of these integers is
not defined by this standard. Storage for the array is contiguous.
The array descriptor for field N as it would appear embedded ina table row is illustrated symbolically below:
27

28. . . [field N–1] [(nelem,offset)] [field N+1] . . .
If the stored array length is zero there is no array data, andthe offset value is undefined (it should be set to zero). The storage referenced by an array descriptor must lie entirely within theheap area; negative offsets are not permitted.
A binary table containing variable-length arrays consists ofthree principal segments, as follows:

AFT[table header] [main data table] (optional gap) [heap area]

Programs that read binary tables should take care to not assume more about the physical layout of the table than is requiredby the specification. For example, there are no requirements on
the alignment of data within the heap. If efficient runtime access is a concern one might want to design the table so that dataarrays are aligned to the size of an array element. In anothercase one might want to minimize storage and forgo any efforts
at alignment (by careful design it is often possible to achieveboth goals). Variable-length array data may be stored in the heap
in any order, i.e., the data for row N+1 are not necessarily stored
at a larger offset than that for row N. There may be gaps in theheap where no data are stored. Pointer aliasing is permitted, i.e.,
the array descriptors for two or more arrays may point to thesame 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 machineindependent 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 ispossible that the stored array length may be zero. This makes
it possible to have a column of the table for which, typically,no data are present in each stored row. When data are present
the stored array can be as large as necessary. This can be usefulwhen storing complex objects as rows in a table.
Accessing a binary table stored on a random access storage
medium is straightforward. Since the rows of data in the main
data table are fixed in size they can be randomly accessed given
the row number, by computing the offset. Once the row has beenread in, any variable-length array data can be directly accessedusing the element count and offset given by the array descriptor
stored in that row.
Reading a binary table stored on a sequential access storage
medium requires that a table of array descriptors be built up as
the main data table rows are read in. Once all the table rows
have been read, the array descriptors are sorted by the offset ofthe array data in the heap. As the heap data are read, arrays are
extracted sequentially from the heap and stored in the affectedrows using the back pointers to the row and field from the tableof array descriptors. Since array aliasing is permitted, it might
be necessary to store a given array in more than one field or row.
Variable-length arrays are more complicated than regularstatic arrays and might not be supported by some software systems. The producers of FITS data products should consider thecapabilities of the likely recipients of their files when deciding
whether or not to use this format, and as a general rule should
use it only in cases where it provides significant advantages overthe simpler fixed-length array format. In particular, the use ofvariable-length arrays might present difficulties for applications
that ingest the FITS file via a sequential input stream because theapplication cannot fully process any rows in the table until after
the entire fixed-length table and potentially the entire heap has
been transmitted as outlined in the previous paragraph.

NAXIS1NAXIS2PCOUNT
...
THEAP

DR

The table header consists of one or more 2880-byte header
blocks with the last block indicated by the keyword END somewhere in the block. The main data table begins with the first data
block following the last header block and is NAXIS1 × NAXIS2
bytes in length. The zero indexed byte offset to the start of
the heap, measured from the start of the main data table, may
be given by the THEAP keyword in the header. If this keyword is missing then the heap begins with the byte immediately
following main data table (i.e., the default value of THEAP is
NAXIS1 × NAXIS2). This default value is the minimum allowed
value for the THEAP keyword, because any smaller value would
imply that the heap and the main data table overlap. If the THEAP
keyword has a value larger than this default value, then there isa gap between the end of the main data table and the start of
the heap. The total length in bytes of the supplemental data area
following the main data table (gap plus heap) is given by the
PCOUNT keyword in the table header.
For example, suppose a table contains five rows which areeach 168 bytes long, with a heap area 3000 bytes long, beginning at an offset of 2880, thereby aligning the main data table
and heap areas on data block boundaries (this alignment is notnecessarily recommended but is useful for this example). The
data portion of the table consists of three 2880-byte data blocks:
the first block contains the 840 bytes from the five rows of themain data table followed by 2040 fill bytes; the heap completely
fills the second block; the third block contains the remaining
120 bytes of the heap followed by 2760 fill bytes. PCOUNT gives
the total number of bytes from the end of the main data table to the end of the heap and in this example has a value of2040 + 2880 + 120 = 5040. This is expressed in the table header
as:
=
=
=

168 / Width of table row in bytes
5 / Number of rows in table
5040 / Random parameter count=2880 / Byte offset of heap area

The values of TSCALn and TZEROn for variable-length arraycolumn entries are to be applied to the values in the data array inthe heap area, not the values of the array descriptor. These keywords can be used to scale data values in either static or variablelength arrays.
7.3.6. Variable-length-array guidelines

While the above description is sufficient to define the requiredfeatures of the variable-length array implementation, some hints
regarding usage of the variable-length array facility might also
be useful.
28

8. World coordinate systems
Representations of the mapping between image coordinates andphysical (i.e., world) coordinate systems (WCSs) may be represented within FITS HDUs. The keywords that are used to express

29
these mappings are now rigorously defined in a series of papers
on world coordinate systems (Greisen & Calabretta 2002), celestial coordinate systems (Calabretta & Greisen 2002), spectral
coordinate systems (Greisen et al. 2006), and time coordinate
systems (Rots et al. 2015). An additional spherical projection,
called HEALPix, is defined in reference (Calabretta & Roukema2007). These WCS papers have been formally approved by the
IAUFWG and therefore are incorporated by reference as an official part of this Standard. The reader should refer to these papers
for additional details and background information that cannot be
included here. Various updates and corrections to the primary
WCS papers have been compiled by the authors, and are reflected in this section. Therefore, where conflicts exist, the description in this Standard will prevail.

Pixel
Coordinates

Linear transformation:translation, rotation,skew, scale

CRPIXj,
PCi_j or
CDi_j

AF
T

Intermediate Pixel
Coordinates

Rescale tophysical units

CDELTiIntermediate World
Coordinates

8.1. Basic concepts

DR

Rather than store world coordinates separately for each datum,
the regular lattice structure of a FITS image offers the possibility of defining rules for computing world coordinates at eachpoint. As stated in Sect. 3.3.2 and depicted in Fig. 1, image array data are addressed via integral array indices that range invalue from 1 to NAXISj on axis j. Recognizing that image data
values may have an extent, for example an angular separation,
spectral channel width or time span, and thus that it may makesense to interpolate between them, these integral array indicesmay be generalized to floating-point pixel coordinates. Integral
pixel coordinate values coincide with the corresponding array indices, while fractional pixel coordinate values lie between arrayindices and thus imply interpolation. Pixel coordinate values aredefined at all points within the image lattice and outside it (except along conventional axes, see Sect. 8.5). They form the basisof the world coordinate formalism in FITS depicted schematically in Fig. 2.
The essence of representing world coordinate systems in
FITS is the association of various reserved keywords with elements of a transformation (or a series of transformations), orwith parameters of a projection function. The conversion frompixel coordinates in the data array to world coordinates is simply a matter of applying the specified transformations (in order)
via the appropriate keyword values; conversely, defining a WCS
for an image amounts to solving for the elements of the transformation matrix(es) or coefficients of the function(s) of interest
and recording them in the form of WCS keyword values. The
description of the WCS systems and their expression in FITS
HDUs is quite extensive and detailed, but is aided by a carefulchoice of notation. Key elements of the notation are summarizedin Table 21, and are used throughout this section. The formal
definitions of the keywords appear in the following subsections.
The conversion of image pixel coordinates to world coordinates is a multi-step process, as illustrated in Fig. 2.
For all coordinate types, the first step is a linear transformation applied via matrix multiplication of the vector of pixel
coordinate elements, p j :
qi =

N
X

mi j (p j − r j )

(9)

j=1

where r j are the pixel coordinate elements of the reference point,j indexes the pixel axis, and i the world axis. The mi j matrix is a
non-singular, square matrix of dimension N × N, where N is the

Coordinate
projection, offset

CTYPEi,CRVALi
PVi_m

World
Coordinates

Fig. 2: A schematic view of converting pixel coordinates toworld coordinates.

number of world coordinate axes. The elements qi of the resulting intermediate pixel coordinate vector are offsets, in dimensionless pixel units, from the reference point along axes coincident with those of the intermediate world coordinates. Thus, theconversion of qi to the corresponding intermediate world coordinate element xi is a simple scale:xi = si qi .

(10)

There are three conventions for associating FITS keywords
with the above transformations. In the first formalism, the matrix
elements mi j are encoded in the PCi j keywords and the scale
factors si are encoded in the CDELTi keywords, which must have
non-zero values. In the second formalism Eqs. (9) and (10) are
combined as
xi =

N
X

(si mi j )(p j − r j )

(11)

j=1

and the CDi j keywords encode the product si mi j . The third convention was widely used before the development of the two previously described conventions and uses the CDELTi keywords
to define the image scale and the CROTA2 keyword to define abulk rotation of the image plane. Use of the CROTA2 keyword is
now deprecated, and instead the newer PCi j or CDi j keywords
are recommended because they allow for skewed axes and fully
general rotation of multi-dimensional arrays. The CDELTi and
CROTA2 keywords may co-exist with the CDi j keywords (butthe CROTA2 must not occur with the PCi j keywords) as an aid
to old FITS interpreters, but these keywords must be ignoredby software that supports the CDi j keyword convention. In allthese formalisms the reference pixel coordinates r j are encodedin the CRPIXi keywords, and the world coordinates at the reference point are encoded in the CRVALi keywords. For additional
details, see Greisen & Calabretta (2002).
29

30
Table 21: WCS and celestial coordinates notation.
Meaning
Index variable for world coordinates
Index variable for pixel coordinates
Alternative WCS version code
Pixel coordinates
Reference pixel coordinates
Linear transformation matrix
Coordinate scales
Projection plane coordinates
Native longitude and latitude
Celestial longitude and latitude
Native longitude and latitude of the fiducial point
Celestial longitude and latitude of the fiducial point
Celestial longitude and latitude of the native pole
Native longitude and latitude of the celestial pole

Notes. † Associated with longitude axis i.

DR

The third step of the process, computing the final world coordinates, depends on the type of coordinate system, which isindicated with the value of the CTYPEi keyword. For some simple, linear cases an appropriate choice of normalization for the
scale factors allows the world coordinates to be taken directly (orby applying a constant offset) from the xi (e.g., some spectra).
In other cases it is more complicated, and may require the application of some non-linear algorithm (e.g., a projection, as forcelestial coordinates), which may require the specification of additional parameters. Where necessary, numeric parameter values
for non-linear algorithms must be specified via PVi m keywords
and character-valued parameters will be specified via PSi m keywords, where m is the parameter number.
The application of these formalisms to coordinate systems ofinterest is discussed in the following sub-sections: Sect. 8.2 describes general WCS representations (see Greisen & Calabretta
2002), Sect. 8.3 describes celestial coordinate systems (seeCalabretta & Greisen 2002)), Sect. 8.4 describes spectral coordinate systems (see Greisen et al. 2006), and Sect. 9 describes
the representation of time coordinates (see Rots et al. 2015).
8.2. World coordinate system representations

A variety of keywords have been reserved for computing thecoordinate values that are to be associated with any pixel location within an array. The full set is given in Table 22; those inmost common usage are defined in detail below for convenience.
Coordinate system specifications may appear in HDUs that contain simple images in the primary array or in an image extension.
Images may also be stored in a multi-dimensional vector cell ofa binary table, or as a tabulated list of pixel locations (and optionally, the pixel value) in a table. In these last two types of image representations, the WCS keywords have a different naming
convention which reflects the needs of the tabular data structure
and the 8-character limit for keyword lengths, but otherwise follow exactly the same rules for type, usage, and default values.
See reference Calabretta & Greisen (2002) for example usage ofthese keywords. All forms of these reserved keywords must be
used only as specified in this Standard.
In the case of the binary table vector representation, it ispossible that the images contained in a given column of the table have different coordinate transformation values. Table 9 of30

Related FITS keywords

CRPIXja
CDi ja or PCi ja
CDELTia

AF
T

Variable(s)
i
j
a
pj
rj
mi j
si
(x, y)(φ, θ)(α, δ)(φ0 , θ0 )(α0 , δ0 )(α p , δ p )(φ p , θ p )PVi 1a† , PVi 2a†
CRVALia

LONPOLEa (=PVi 3a† ),LATPOLEa (=PVi 4a† )Calabretta & Greisen (2002) illustrates a technique (commonly
known as the “Green Bank Convention11”) which utilizes additional columns in the table to record the coordinate transformation values that apply to the corresponding image in each row of
the table. More information is provided in Appendix L.
The keywords given below constitute a complete set of fundamental attributes for a WCS description. Although their inclusion in an HDU is optional, FITS writers should include a complete set of keywords when describing a WCS. In the event thatsome keywords are missing, default values must be assumed, as
specified below.
WCSAXES – [integer; default: NAXIS, or larger of WCS indexes ior j]. Number of axes in the WCS description. This keyword,
if present, must precede all WCS keywords except NAXIS in
the HDU. The value of WCSAXES may exceed the number ofpixel axes for the HDU.
CTYPEi – [string; indexed; default: ' ' (i.e. a linear, undefinedaxis)]. Type for the intermediate coordinate axis i. Any coordinate type that is not covered by this standard or an officially recognized FITS convention shall be taken to be linear.
All non-linear coordinate system names must be expressedin ‘4–3’ form: the first four characters specify the coordinate
type, the fifth character is a hyphen (‘-’), and the remaining three characters specify an algorithm code for computing the world coordinate value. Coordinate types with namesof less than four characters are padded on the right withhyphens, and algorithm codes with less than three characters are padded on the right with blanks12 . Algorithm codesshould be three characters.
CUNITi – [string; indexed; default: ' ' (i.e., undefined)].
Physical units of CRVAL and CDELT for axis i. Note that units
should always be specified (see Sect. 4.3). Units for celestialcoordinate systems defined in this Standard must be degrees.
CRPIXj – [floating point; indexed; default: 0.0]. Location of thereference point in the image for axis j corresponding to r j in
Eq. (9). Note that the reference point may lie outside the im11
Named after a meeting held in Green Bank, West Virginia, USA
in 1989 to develop standards for the interchange of single dish radio
astronomy data.
12
Example: ‘RA---UV ’.

31
Table 22: Reserved WCS keywords (continues on next page)
BINTABLE vector
Primary Alternative
WCAXnaiCTYPniCTYnaiCUNIniCUNnaiCRVLniCRVnaiCDLTniCDEnajCRPXnjCRPnaiCROTnijPCnaijCDna
iPVn ma or iVn ma
iVn XaiPSn ma or iSn ma
WCSNnaiCNAnaiCRDnaiCSYnaWCSTnaWCSXnaLONPnaLATPnaEQUIna
EPOCH
EPOCH
RADECSYS4RADESYSa
RADEnaRESTFREQ4
RESTFRQa
RFRQnaRESTWAVa
RWAVnaSPECSYSa
SPECnaSSYSOBSa
SOBSnaSSYSSRCa
SSRCnaOBSGEO-X5OBSGXnOBSGEO-Y5
OBSGYnOBSGEO-Z5
OBSGZnVELOSYSa
VSYSnaZSOURCEaZSOUnaVELANGLa
VANGnaDate-time related keywords (see Sect.9)
DATE
DATE-OBS
DOBSn
MJD-OBSMJDOBnBEPOCHJEPOCHDATE-AVGDAVGn
MJD-AVG
MJDAn
DATE-BEG
MJD-BEGTSTARTDATE-END
MJD-ENDTSTOPXPOSURETELAPSETIMESYSCTYPEia
iCTYPniCTYna
MJDREF6JDREF6DATEREF
TREFPOSTRPOSnTREFDIR
TRDIRnPLEPHEMTIMEUNITCUNITia
iCUNIniCUNnaTIMEOFFSTIMSYERCSYERia
iCSYEniCSYnaTIMRDERCRDERia
iCRDEniCRDnaTIMEDELTIMEPIXRCZPHSia
iCZPHniCZPnaCPERIia
iCPERniCPRnaImage
WCSAXESa
CTYPEia
CUNITia
CRVALia
CDELTia
CRPIXja
CROTAiPCi jaCDi jaPVi ma...
PSi maWCSNAMEa
CNAMEia
CRDERia
CSYERia...
...
LONPOLEa
LATPOLEa
EQUINOXa

AF
T

GlobalDR

Keyword Description
Coordinate dimensionality
Axis type
Axis units
Reference value
Coordinate increment
Reference point
Coordinate rotation1
Transformation matrix2
Transformation matrix2
Coordinate parameter
Coordinate parameter array
Coordinate parameter
Coordinate nameCoordinate axis name
Random error
Systematic error
WCS cross-reference target
WCS cross reference
Coordinate rotation
Coordinate rotation
Coordinate epoch
Coordinate epoch3
Reference frameLine rest frequency (Hz)Line rest vacuum wavelength (m)Spectral reference frame
Spectral reference frame
Spectral reference frame
Observation X (m)Observation Y (m)Observation Z (m)Radial velocity (m s−1 )Redshift of source
Angle of true velocity
Date of HDU creation
Date/time of observation

Average date/time of observation
Start date/time of observation
End date/time of observation

Net exposure duration
Wall clock exposure duration
Time scale
Time zero-point (MJD)
Time zero-point (JD)
Time zero-point (ISO)Reference position
Reference direction
Solar system ephemeris
Time unit
Time offset
Time absolute error
Time relative error
Time resolution
Time location in pixel
Phase axis zero point
Phase axis period

Pixel list
Primary Alternative...
TCTYPn TCTYna
TCUNIn TCUNnaTCRVLn TCRVna
TCDLTn TCDEna
TCRPXn TCRPna
TCROTn
TPCn ka or TPn ka
TCDn ka or TCn ka
TPVn ma or TVn ma...
TPSn ma or TSn ma
WCSna or TWCSna
TCNAnaTCRDnaTCSYna...
...
LONPnaLATPnaEQUIna
EPOCH
RADEnaRFRQnaRWAVnaSPECnaSOBSnaSSRCnaOBSGXnOBSGYnOBSGZnVSYSnaZSOUnaVANGnaDOBSn
MJDOBnDAVGn
MJDAn

TCTYPnTCTYnaTRPOSnTRDIRnTCUNInTCUNna

TCSYn
TCRDn

TCSYnaTCRDnaTCZPHnTCPERnTCZPnaTCPRna31

32
Table 22 (continued)

AF
T

Notes. The indexes j and i are pixel and intermediate world coordinate axis numbers, respectively. Within a table, the index n refers to a column
number, and m refers to a coordinate parameter number. The index k also refers to a column number. The indicator a is either blank (for the primary
coordinate description) or a character A through Z that specifies the coordinate version. See text.
(1)
CROTAi form is deprecated but still in use. It must not be used with PC i j, PV i m, and PS i m. (2) PCi j and CDi j forms of the transformation
matrix are mutually exclusive, and must not appear together in the same HDU. (3) EPOCH is deprecated. Use EQUINOX instead. (4) These 8-character
keywords are deprecated; the 7-character forms, which can include an alternate version code letter at the end, should be used instead. (5) For
the purpose of time reference position, geodetic latitude/longitude/elevation OBSGEO-B, OBSGEO-L, OBSGEO-H or an orbital ephemeris keyword
OBSORBIT can be also used (see Sect. 9.2.3). (6) [M]JDREF can be split in integer and fractional values [M]JDREFI and [M]JDREFF as explainedin Sect. 9.2.2.

DR

age and that the first pixel in the image has pixel coordinates(1.0, 1.0, . . .).
CRVALi – [floating point; indexed; default: 0.0]. World
Coordinate value at the reference point of axis i.
CDELTi – [floating point; indexed; default: 1.0]. Increment of
the world coordinate at the reference point for axis i. The
value must not be zero.
CROTAi – [floating point; indexed; default: 0.0]. The amountof rotation from the standard coordinate system to a different
coordinate system. Further use of this of this keyword is deprecated, in favor of the newer formalisms that use the CDi j
or PCi j keywords to define the rotation.
PCi j – [floating point; defaults: 1.0 when i = j, 0.0 otherwise].
Linear transformation matrix between pixel axes j and intermediate coordinate axes i. The PCi j matrix must not be
singular.
CDi j – [floating point; defaults: 0.0, but see below]. Linear
transformation matrix (with scale) between pixel axes j andintermediate coordinate axes i. This nomenclature is equivalent to PCi j when CDELTi is unity. The CDi j matrix mustnot be singular. Note that the CDi j formalism is an exclusivealternative to PCi j, and the CDi j and PCi j keywords must
not appear together within an HDU.

In addition to the restrictions noted above, if any CDi j keywords
are present in the HDU, all other unspecified CDi j keywords
shall default to zero. If no CDi j keywords are present then theheader shall be interpreted as being in PCi j form whether or not
any PCi j keywords are actually present in the HDU.
Some non-linear algorithms that describe the transformation
between pixel and intermediate coordinate axes require parameter values. A few non-linear algorithms also require charactervalued parameters, e.g., table lookups require the names of thetable extension and the columns to be used. Where necessary
parameter values must be specified via the following keywords:
PVi m – [floating point]. Numeric parameter values for intermediate world coordinate axis i, where m is the parameter
number. Leading zeros must not be used, and m may have
only values in the range 0 through 99, and that are definedfor the particular non-linear algorithm.
PSi m – [string]. Character-valued parameters for intermediateworld coordinate axis i, where m is the parameter number.
Leading zeros must not be used, and m may have only values in the range 0 through 99, and that are defined for theparticular non-linear algorithm.
The following keywords, while not essential for a complete
specification of an image WCS, can be extremely useful for readers to interpret the accuracy of the WCS representation of theimage.
32

CRDERi – [floating point; default: 0.0]. Random error in coordinate i, which must be non-negative.
CSYERi – [floating point; default: 0.0]. Systematic error in coordinate i, which must be non-negative.

These values should give a representative average value of theerror over the range of the coordinate in the HDU. The total error
in the coordinates would be given by summing the individual
errors in quadrature.
8.2.1. Alternative WCS axis descriptions

In some cases it is useful to describe an image with more than
one coordinate type13 . Alternative WCS descriptions may be
added to the header by adding the appropriate sets of WCS keywords, and appending to all keywords in each set an alphabetic
code in the range A through Z. Keywords that may be used inthis way to specify a coordinate system version are indicated inTable 22 with the suffix a. All implied keywords with this encoding are reserved keywords, and must only be used in FITS HDUs
as specified in this Standard. The axis numbers must lie in therange 1 through 99, and the coordinate parameter m must lie in
the range 0 through 99, both with no leading zeros.
The primary version of the WCS description is that specified
with a as the blank character14 . Alternative axis descriptions are
optional, but must not be specified unless the primary WCS description is also specified. If an alternative WCS description is
specified, all coordinate keywords for that version must be given
even if the values do not differ from those of the primary version.
Rules for the default values of alternative coordinate descriptions
are the same as those for the primary description. The alternative descriptions are computed in the same fashion as the primary coordinates. The type of coordinate depends on the valueof CTYPEia, and may be linear in one of the alternative descriptions and non-linear in another.
The alternative version codes are selected by the FITS writer;
there is no requirement that the codes be used in alphabetic sequence, nor that one coordinate version differ in its parametervalues from another. An optional keyword WCSNAMEa is also defined to name, and otherwise document, the various versions of
WCS descriptions:
WCSNAMEa – [string; default for a: ' ' (i.e., blank, for the primary WCS, else a character A through Z that specifies the13

Examples include the frequency, velocity, and wavelength along aspectral axis (only one of which, of course, could be linear), or the position along an imaging detector in both meters and degrees on the sky.
14
There are a number of keywords (e.g. ijPCna) where the a could be
pushed off the 8-char keyword name for plausible values of i, j, k, n, andm. In such cases a is still said to be ‘blank’ although it is not the blankcharacter.

33
Table 23: Reserved celestial coordinate algorithm codes.
Default
φ0 θ0

AZP
SZP
TAN
STG
SIN
ARC
ZPN
ZEA
AIR

0◦
0◦
0◦
0◦
0◦
0◦
0◦
0◦
0◦

CYP
CEA
CAR
MER

0◦
0◦
0◦
0◦

SFL
PAR
MOL
AIT

0◦
0◦
0◦
0◦

COP
COE
COD
COO

0◦
0◦
0◦
0◦

BON
PCO

0◦
0◦

TSC
CSC
QSC

0◦
0◦
0◦

HPX

0◦

AF
T

Properties1
Projection name
Zenithal (azimuthal) projections
90◦ Sect. 5.1.1
Zenithal perspective
90◦ Sect. 5.1.2
Slant zenithal perspective
90◦ Sect. 5.1.3
Gnomonic
90◦ Sect. 5.1.4
Stereographic
90◦ Sect. 5.1.5
Slant orthographic
90◦ Sect. 5.1.6
Zenithal equidistant90◦ Sect. 5.1.7
Zenithal polynomial
90◦ Sect. 5.1.8
Zenithal equal-area
90◦ Sect. 5.1.9
Airy
Cylindrical projections
0◦
Sect. 5.2.1. Cylindrical perspective0◦
Sect. 5.2.2
Cylindrical equal area
0◦
Sect. 5.2.3
Plate carrée0◦Sect. 5.2.4
Mercator
Pseudo-cylindrical and related projections
0◦
Sect. 5.3.1
Samson-Flamsteed0◦Sect. 5.3.2
Parabolic
0◦Sect. 5.3.3
Mollweide
0◦Sect. 5.3.4
Hammer-Aitoff
Conic projections
θaSect. 5.4.1
Conic perspective
θaSect. 5.4.2
Conic equal-area
θaSect. 5.4.3
Conic equidistantθaSect. 5.4.4
Conic orthomorphic
Polyconic and pseudoconic projections
0◦
Sect. 5.5.1
Bonne’s equal area
0◦
Sect. 5.5.2
Polyconic
Quad-cube projections
0◦
Sect. 5.6.1
Tangential spherical cube
0◦Sect. 5.6.2
COBE quadrilateralized spherical cube
0◦Sect. 5.6.3
Quadrilateralized spherical cube
HEALPix grid projection
0◦
Sect. 62
HEALPix grid

DR

(1)

Code

Refer to the indicated section in Calabretta & Greisen (2002) for a detailed description. (2) This projection is defined in Calabretta & Roukema(2007).

coordinate version]. Name of the world coordinate systemrepresented by the WCS keywords with the suffix a. Its primary function is to provide a means by which to specify aparticular WCS if multiple versions are defined in the HDU.
8.3. Celestial coordinate system representations

The conversion from intermediate world coordinates (x, y) in theplane of projection to celestial coordinates involves two steps: aspherical projection to native longitude and latitude (φ, θ), defined in terms of a convenient coordinate system (i.e., native
spherical coordinates), followed by a spherical rotation of thesenative coordinates to the required celestial coordinate system(α, δ). The algorithm to be used to define the spherical projection must be encoded in the CTYPEi keyword as the three-letter
algorithm code, the allowed values for which are specified inTable 23 and defined in references Calabretta & Greisen (2002)
and Calabretta & Roukema (2007). The target celestial coordinate system is also encoded into the left-most portion of the
CTYPEi keyword as the coordinate type.
For the final step, the parameter LONPOLEa must be specified,
which is the native longitude of the celestial pole, φ p . For certain

projections (such as cylindricals and conics, which are less commonly used in astronomy), the additional keyword LATPOLEa
must be used to specify the native latitude of the celestial pole.
See Calabretta & Greisen (2002) for the transformation equations and other details.
The accepted celestial coordinate systems are: the standard
equatorial (RA-- and DEC-), and others of the form xLON andxLAT for longitude-latitude pairs, where x is G for Galactic, E forecliptic, H for helioecliptic and S for supergalactic coordinates.
Since the representation of planetary, lunar, and solar coordinate
systems could exceed the 26 possibilities afforded by the single
character x, pairs of the form yzLN and yzLT may be used as well.
RADESYSa – [string; default: ’FK4’, ’FK5’, or ’ICRS’: see
below]. Name of the reference frame of equatorial or ecliptic
coordinates, whose value must be one of those specified inTable 24. The default value is FK4 if the value of EQUINOXa< 1984.0, FK5 if EQUINOXa ≥ 1984.0, or ICRS if EQUINOXa
is not given.
EQUINOXa – [floating point; default: see below]. Epoch of themean equator and equinox in years, whose value must be
non-negative. The interpretation of epoch depends upon thevalue of RADESYSa if present: Besselian if the value is FK4
33

34
Table 24: Allowed values of RADESYSa.
Value
Definition
ICRS
International Celestial Reference System
FK5
Mean place, new (IAU 1984) system
FK41
Mean place, old (Bessel-Newcomb) system
FK4-NO-E1
Mean place: but without eccentricity terms
GAPPT
Geocentric apparent place, IAU 1984 system(1)
New FITS files should avoid using these older reference systems.

ditional description of the coordinate may be helpful beyond
what can be encoded in the first four characters of the CTYPEia
keyword; CNAMEia is reserved for this purpose. Note that thiskeyword provides a name for an axis in a particular WCS, while
the WCSNAMEa keyword names the particular WCS as a whole.
In order to convert between some form of radial velocity andeither frequency or wavelength, the keywords RESTFRQa and
RESTWAVa, respectively, are reserved.

DR

AF
T

or FK4-NO-E, Julian if the value is FK5; not applicable if thevalue is ICRS or GAPPT.
EPOCH – [floating point]. This keyword is deprecated andshould not be used in new FITS files. It is reserved primarily
to prevent its use with other meanings. The EQUINOX keyword shall be used instead. The value field of this keyword
was previously defined to contain a floating-point number
giving the equinox in years for the celestial coordinate system in which positions are expressed.
DATE-OBS – [floating point]. This reserved keyword is definedin Sect. 4.4.2.
MJD-OBS – [floating point; default: DATE-OBS if given, otherwise no default]. Modified Julian Date (JD – 2,400,000.5) of
the observation, whose value corresponds (by default) to thestart of the observation, unless another interpretation is explained in the comment field. No specific time system (e.g.
UTC, TAI, etc.) is defined for this or any of the other timerelated keywords. It is recommended that the TIMESYS keyword, as defined in Sect. 9.2.1 be used to specify the timesystem. See also Sect. 9.5.
LONPOLEa – [floating point; default: φ0 if δ0 ≥ θ0 , φ0 + 180◦
otherwise]. Longitude in the native coordinate system of thecelestial system’s north pole. Normally, φ0 is zero unless a
non-zero value has been set for PVi 1a, which is associatedwith the longitude axis. This default applies for all values ofθ0 , including θ0 = 90◦ , although the use of non-zero valuesof θ0 are discouraged in that case.
LATPOLEa – [floating point; default: 90◦ , or no default if(θ0 , δ0 , φ p − φ0 ) = (0, 0, ±90◦)]. Latitude in the native coordinate system of the celestial system’s north pole, or equivalently, the latitude in the celestial coordinate system of thenative system’s north pole. May be ignored or omitted incases where LONPOLEa completely specifies the rotation to
the target celestial system.
8.4. Spectral coordinate system representations

This section discusses the conversion of intermediate world coordinates to spectral coordinates with common axes such as frequency, wavelength, and apparent radial velocity (represented
here with the coordinate variables ν, λ, or v). The key point for
constructing spectral WCS in FITS is that one of these coordinates must be sampled linearly in the dispersion axis; the others
are derived from prescribed, usually non-linear transformations.
Frequency and wavelength axes may also be sampled linearly intheir logarithm.
Following the convention for the CTYPEia keyword, when i is
the spectral axis the first four characters must specify a code forthe coordinate type; for non-linear algorithms the fifth charactermust be a hyphen, and the next three characters must specify apredefined algorithm for computing the world coordinates fromthe intermediate physical coordinates. The coordinate type must
be one of those specified in Table 25. When the algorithm is linear, the remainder of the CTYPEia keyword must be blank. Whenthe algorithm is non-linear, the 3-letter algorithm code must be
one of those specified in Table 26. The relationships between
the basic physical quantities ν, λ, and v, as well as the relationships between various derived quantities are given in reference
Greisen et al. (2006).
The generality of the algorithm for specifying the spectral
coordinate system and its representation suggests that some ad34

CNAMEia – [string; default: default: ' ' (i.e. a linear, undefinedaxis)]. Spectral coordinate description which must not exceed 68 characters in length.
RESTFRQa – [floating point; default: none]. Rest frequency ofthe of the spectral feature of interest. The physical unit must
be Hz.
RESTWAVa – [floating point; default: none]. Vacuum rest wavelength of the of the spectral feature of interest. The physicalunit must be m.

One or the other of RESTFRQa or RESTWAVa should be given
when it is meaningful to do so.
8.4.1. Spectral coordinate reference framesFrequencies, wavelengths, and apparent radial velocities are always referred to some selected standard of rest (i.e., reference
frame). While the spectra are obtained they are, of necessity, inthe observer’s rest frame. The velocity correction from topocentric (the frame in which the measurements are usually made) tostandard reference frames (which must be one of those given in
Table 27) are dependent on the dot product with time-variablevelocity vectors. That is, the velocity with respect to a standard
reference frame depends upon direction, and the velocity (andfrequency and wavelength) with respect to the local standardof rest is a function of the celestial coordinate within the image. The keywords SPECSYSa and SSYSOBSa are reserved and,if used, must describe the reference frame in use for the spectral
axis coordinate(s) and the spectral reference frame that was held
constant during the observation, respectively. In order to compute the velocities it is necessary to have the date and time of theobservation; the keywords DATE-AVG and MJD-AVG are reserved
for this purpose. See also Sect. 9.5.
DATE-AVG – [string; default: none]. Calendar date of the midpoint of the observation, expressed in the same way as the
DATE-OBS keyword.
MJD-AVG – [floating point; default: none]. Modified Julian Date
(JD – 2,400,000.5) of the mid-point of the observation.
SPECSYSa – [string; default: none]. The reference frame in use
for the spectral axis coordinate(s). Valid values are given in
Table 27.

35
Table 25: Reserved spectral coordinate type codes.
Type
Frequency
EnergyWavenumber
Radio velocity2
Vacuum wavelength
Optical velocity2
Redshift
Air wavelength
Apparent radial velocity
Beta factor (v/c)

Symbol
ν
E
κ
V
λ
Z
z
λa
v
β

Assoc. variable
ν
ν
ν
ν
λ
λ
λ
λa
v
v

Default units
Hz
J
m−1
m s−1
m
m s−1
...
m
m s−1
...

AF
T

Code1
FREQ
ENER
WAVN
VRAD
WAVE
VOPT
ZOPT
AWAV
VELO
BETA

(1)
Characters 1 through 4 of the value of the keyword CTYPEia. (2) By convention, the ‘radio’ velocity is given by c(ν0 − ν)/ν0 and the ‘optical’velocity is given by c(λ − λ0 )/λ0 .

SSYSOBSa – [string; default: ’TOPOCENT’]. The spectral reference frame that is constant over the range of the non-spectral
world coordinates. Valid values are given in Table 27.

DR

The transformation from the rest frame of the observer to a
standard reference frame requires a specification of the location
on Earth15 of the instrument used for the observation in order tocalculate the diurnal Doppler correction due to the Earth’s rotation. The location, if specified, shall be represented as a geocentric Cartesian triple with respect to a standard ellipsoidal geoid
at the time of the observation. While the position can often be
specified with an accuracy of a meter or better, for most purposes positional errors of several kilometers will have negligible
impact on the computed velocity correction. For details, see reference Greisen et al. (2006).
OBSGEO-X – [floating point; default: none]. X−coordinate (inmeters) of a Cartesian triplet that specifies the location, withrespect to a standard, geocentric terrestrial reference frame,
where the observation took place. The coordinate must be
valid at the epoch MJD-AVG or DATE-AVG.
OBSGEO-Y – [floating point; default: none]. Y−coordinate (inmeters) of a Cartesian triplet that specifies the location, withrespect to a standard, geocentric terrestrial reference frame,
where the observation took place. The coordinate must be
valid at the epoch MJD-AVG or DATE-AVG.
OBSGEO-Z – [floating point; default: none]. Z−coordinate (inmeters) of a Cartesian triplet that specifies the location, withrespect to a standard, geocentric terrestrial reference frame,
where the observation took place. The coordinate must be
valid at the epoch MJD-AVG or DATE-AVG.

Information on the relative radial velocity between the observer and the selected standard of rest in the direction of thecelestial reference coordinate may be provided, and if so shallbe given by the VELOSYSa keyword. The frame of rest definedwith respect to the emitting source may be represented in FITS;
for this reference frame it is necessary to define the velocity withrespect to some other frame of rest. The keywords SPECSYSa andZSOURCEa are used to document the choice of reference frame
and the value of the systemic velocity of the source, respectively.

Table 26: Non-linear spectral algorithm codes.

Code1
Regularly sampled in Expressed as
F2W
Frequency
Wavelength
F2V
Apparent radial velocity
F2A
Air wavelength
W2F
Wavelength
Frequency
W2V
Apparent radial velocity
W2A
Air wavelength
V2F
Apparent radial vel.
Frequency
V2W
Wavelength
V2A
Air wavelength
A2F
Air wavelength
Frequency
A2W
Wavelength
A2V
Apparent radial velocity
LOG
Logarithm
Any four-letter type code
GRI
Detector
Any type code from Table 25
GRA
Detector
Any type code from Table 25
TAB
Not regular
Any four-letter type code(1)
Characters 6 through 8 of the value of the keyword CTYPEia.

SSYSSRCa – [string; default: none]. Reference frame for thevalue expressed in the ZSOURCEa keyword to document thesystemic velocity of the observed source. Value must be oneof those given in Table 27 except for SOURCE.
VELOSYSa – [floating point; default: none]. Relative radial velocity between the observer and the selected standard of restin the direction of the celestial reference coordinate. Units
must be m s−1 . The CUNITia keyword is not used for thispurpose since the WCS version a might not be expressed invelocity units.
ZSOURCEa – [floating point; default: none]. Radial velocity
with respect to an alternative frame of rest, expressed as aunitless redshift (i.e., velocity as a fraction of the speed oflight in vacuum). Used in conjunction with SSYSSRCa to
document the systemic velocity of the observed source.
VELANGLa – [floating point; default:+90.]. In the case of relativistic velocities (e.g., a beamed astrophysical jet) the transverse velocity component is important. This keyword may
be used to express the orientation of the space velocity vector with respect to the plane of the sky. See Appendix A ofreference Greisen et al. (2006) for further details.

15
The specification of location for an instrument on a spacecraft inflight requires an ephemeris; keywords that might be required in thiscircumstance are not defined here.

35

36
Table 27: Spectral reference systems.
Definition
Topocentric
Geocentric
Barycentric
Heliocentric
Local standard of rest (kinematic)
Local standard of rest (dynamic)
Galactocentric
Local Group
Cosmic microwave background dipole
Source rest frame

Notes. These are the allowed values of the SPECSYSa, SSYSOBSa, and
SSYSSRCa keywords.

Table 28: Example keywords for a 100 element array of complex
values.
KeywordSIMPLE =BITPIX =NAXIS=NAXIS1 =NAXIS2 =CTYPE1 = 'COMPLEX'CRVAL1 =CRPIX1 =CDELT1 =END

8.5. Conventional coordinate types

T
-32
2
2
100
0.
0.
1.

DR

The first FITS paper (Wells et al. 1981) listed a number of ‘suggested values’ for the CTYPEi keyword. Two of these have theattribute the associated world coordinates can assume only integer values and that the meaning of these integers is only definedby convention. The first ‘conventional’ coordinate is CTYPEia =’COMPLEX’ to specify that complex values (i.e., pairs of real andimaginary components) are stored in the data array (along with
an optional weight factor). Thus, the complex axis of the dataarray will contain two values (or three if the weight is specified).
By convention, the real component has a coordinate value of 1,
the imaginary component has a coordinate value of 2, and theweight, if any, has a coordinate value of 3. Table 28 illustrates
the required keywords for an array of 100 complex values (without weights).
The second conventional coordinate is CTYPEia = ’STOKES’
to specify the polarization of the data. Conventional values, theirsymbols, and polarizations are given in Table 29.

9. Representations of time coordinates
Time as a dimension in astronomical data presents challenges
for its representation in FITS files. This section formulates therepresentation of the time axis, or possibly multiple time axes,
into the World Coordinate System (WCS) described in Sect. 8.
Much of the basic structure is employed, while extensions aredeveloped to cope with the differences between time and spatial
dimensions; notable amongst these differences is the huge dynamic range, covering the highest resolution timing relative tothe age of the Universe.
36

Value
1
2
3
4
−1
−2
−3
−4
−5
−6
−7
−8

Symbol
I
Q
U
V
RR
LL
RL
LR
XX
YY
XY
YX

Polarization
Standard Stokes unpolarizedStandard Stokes linear
Standard Stokes linear
Standard Stokes circular
Right-right circular
Left-left circular
Right-left cross-circular
Left-right cross-circular
X parallel linear
Y parallel linear
XY cross linear
YX cross linear

AF
T

Value
TOPOCENT
GEOCENTRBARYCENTHELIOCEN
LSRK
LSRD
GALACTOCLOCALGRP
CMBDIPOL
SOURCE

Table 29: Conventional Stokes values.

The precision with which any time stamp conforms to any
conventional time scale is highly dependent on the characteristics of the acquiring system. The definitions of many conventional time scales vary over their history along with the precisionthat can be attributed to any time stamp. The meaning of any
time stamp may be ambiguous if a time scale is used for dates
prior to its definition by a recognized authority, or for dates after that definition is abandoned. However, common sense should
prevail: the precision in the description of the time coordinate
should be appropriate to the accuracy of the temporal information in the data.
9.1. Time values

The three most common ways to specify time are: ISO-8601(ISO 2004b), Julian Date (JD), or Modified Julian Date (MJD
= JD − 2, 400, 000.5; see IAU 1997). Julian Dates are counted
from Julian proleptic calendar date 1 January 4713 BCE at noon,
or Gregorian proleptic calendar date 24 November 4714 BCE,
also at noon. For an explanation of the calendars, see Rots et al.
(2015). Even though it is common to think of certain representations of time as absolute, time values in FITS files shall all
be considered relative: elapsed time since a particular reference
point in time. It may help to view the “absolute” values as merely
relative to a globally accepted zero point. For a discussion of
the precision required to represent time values in floating-point
numbers, see Rots et al. (2015).
9.1.1. ISO-8601 datetime strings

FITS datetime strings conform to a subset of ISO-8601 (whichin itself does not imply a particular time scale) for several timerelated keywords (Bunclark & Rots 1997), such as DATE-xxxx.
Here datetime will be used as a pseudo data type to indicate its
use, although its values must be written as a character string in
A format. The full specification for the format of the datetime
string has been:
CCYY-MM-DD[Thh:mm:ss[.s...]]All of the time part may be omitted (just leaving the date) or
the decimal seconds may be omitted. Leading zeroes must not
be omitted and timezone designators are not allowed. This definition is extended to allow five-digit years with a mandatory
sign, in accordance with ISO-8601. That is, one shall use either
the unsigned four-digit year format or the signed five-digit year
format:37[±C]CCYY-MM-DD[Thh:mm:ss[.s...]]
Note the following:

In relevant contexts (e.g., time axes in image arrays, table
columns, or random groups) TIMESYS may be overridden by atime scale recorded in CTYPEia, its binary table equivalents, or
PTYPEi (see Table 22).
The keywords TIMESYS, CTYPEia, TCTYPn, and TCTYna or
binary table equivalent may assume the values listed in Table
30. In addition, for backward compatibility, all except TIMESYS
and PTYPEi may also assume the value TIME (case-insensitive),
whereupon the time scale shall be that recorded in TIMESYS or,
in its absence, its default value, UTC. As noted above, local timescales other than those listed in Table 30 may be used, but theiruse should be restricted to alternate coordinates in order that the
primary coordinates will always refer to a properly recognizedtime scale.
See Rots et al. (2015), Appendix A, for a detailed discussionof the various time scales. In cases where high-precision timing is important one may append a specific realization, in parentheses, to the values in the table; e.g., TT(TAI), TT(BIPM08),
UTC(NIST). Note that linearity is not preserved across all timescales. Specifically, if the reference position remains unchanged(see Section 9.2.3), the first ten, with the exception of UT1, arelinear transformations of each other (excepting leap seconds), as
are TDB and TCB. On average TCB runs faster than TCG by approximately 1.6×10−8, but the transformation from TT or TCG (which
are linearly related) is to be achieved through a time ephemeris
as provided by Irwin & Fukushima (1999).
The relations between coordinate time scales and their dynamical equivalents have been defined as:
T (TCG) = T (TT) + LG × 86400 × (JD(TT) − JD0 )T (TDB) = T (TCB)−LB ×86400×(JD(TCB)− JD0 )+T DB0
where:
T is in seconds
LG = 6.969290134 × 10−10
LB = 1.550519768 × 10−8
JD0 = 2443144.5003725
T DB0 = −6.55 × 10−5 s
Linearity is virtually guaranteed since images and individual table columns do not allow more than one reference position to
be associated with them, and since there is no overlap between
reference positions that are meaningful for the first nine timescales on the one hand, and for the barycentric ones on the other.
All use of the time scale GMT in FITS files shall be taken tohave its zero point at midnight, conformant with UT, including
dates prior to 1925. For high-precision timing prior to 1972, see
Rots et al. (2015), Appendix A.
Some time scales in use are not listed in Table 30 because
they are intrinsically unreliable or ill-defined. When used, theyshould be tied to one of the existing scales with appropriate specification of the uncertainties; the same is true for free-running
clocks. However, a local time scale such as MET (Mission
Elapsed Time) or OET (Observation Elapsed Time) may be defined for practical reasons. In those cases the time reference
value (see Section 9.2.2) shall not be applied to the values, and
it is strongly recommended that such timescales be provided as

DR

AF
T

– In counting years, ISO-8601 follows the convention of including year zero. Consequently, for negative year numbers
there is an offset of one from BCE dates which do not recognize a year zero. Thus year 1 corresponds to 1 CE, year 0 to
1 BCE, year −1 to 2 BCE, and so on.
– The earliest date that may be represented in the four-digit
year format is 0000-01-01T00:00:00 (in the year 1 BCE);
the latest date is 9999-12-31T23:59:59. This representation of time is tied to the Gregorian calendar. In conformancewith the present ISO-8601:2004(E) standard (ISO 2004b)
dates prior to 1582 must be interpreted according to the proleptic application of the rules of Gregorius XIII. For dates
not covered by that range the use of Modified Julian Date
(MJD) or Julian Date (JD) numbers or the use of the signed
five-digit year format is recommended.
– In the five-digit year format the earliest and latest dates are-99999-01-01T00:00:00 (i.e., −100 000 BCE) and+99999-12-31T23:59:59.
– The origin of JD can be written as:-04713-11-24T12:00:00.
– In time scale UTC the integer part of the seconds field runs
from 00 to 60 (in order to accommodate leap seconds); in allother time scales the range is 00 to 59.
– The ISO-8601 datetime data type is not allowed in image
axis descriptions since CRVAL is required to be a floating
point value.
– ISO-8601 datetime does not imply the use of any particulartime scale (see Section 9.2.1).
– As specified by Bunclark & Rots (1997), time zones are explicitly not supported in FITS and, consequently, appending
the letter ‘Z’ to a FITS ISO-8601 string is not allowed. The
rationale for this rule is that its role in the ISO standard isthat of a time zone indicator, not a time scale indicator. As
the concept of a time zone is not supported in FITS, the useof time zone indicator is inappropriate.

TIMESYS – [string; default: ’UTC’]. The value field of this keyword shall contain a character string code for the time scaleof the time-related keywords. The recommended values forthis keyword in Table 30 have well defined meanings, butother values may be used. If this keyword is absent, ’UTC’
must be assumed.

9.1.2. Julian and Besselian epochs

In a variety of contexts epochs are provided with astronomical
data. Until 1976 these were commonly based on the Besselianyear (see Sect. 9.3), with standard epochs B1900.0 and B1950.0.
After 1976 the transition was made to Julian epochs based on
the Julian year of 365.25 days, with the standard epoch J2000.0.
They are tied to time scales ET and TDB, respectively. Notethat the Besselian epochs are scaled by the variable length of theBesselian year (see Sect. 9.3 and its cautionary note, which also
applies to this context). The Julian epochs are easier to calculate,
as long as one keeps track of leap days.
9.2. Time coordinate frame
9.2.1. Time scale

The time scale defines the temporal reference frame, and is specified in the header in one of a few ways, depending upon the context. When recorded as a global keyword, the time scale shall be
specified by:37

38
Table 30: Recognized Time Scale Values

TDT
ET
IAT
UT1
UTC

GMT
UT()1
GPS
TCG

TCB

TDB

LOCAL
1

Specific realization codes may be appended to these values, inparentheses; see text. For a more detailed discussion of timescales, see Rots et al. (2015), Appendix A.

alternate time scales, with a defined conversion to a recognizedtime scale.
It is useful to note that while UT1 is, in essence, an angle (ofthe Earth’s rotation – i.e., a clock), the others are SI-second counters (chronometers); UTC, by employing leap seconds, serves asa bridge between the two types of time scales.
9.2.2. Time reference value

The time reference value is not required to be present in an HDU.
However, if the time reference point is specified explicitly it must
be expressed in one of ISO-8601, JD, or MJD. These reference
values must only be applied to time values associated with one
38

MJDREF – [floating-point]; default: 0.0] The value field of thiskeyword shall contain the value of the reference time in
MJD.
JDREF – [floating-point; default: none] The value field of thiskeyword shall contain the value of the reference time in JD.
DATEREF – [datetime; default: none] The value field of this keyword shall contain a character string representation of thereference time in ISO-8601 format.

AF
T

TT

Meaning(International Atomic Time): atomic time standard
maintained on the rotating geoid(Terrestrial Time; IAU standard): defined on the rotating geoid, usually derived as TAI + 32.184 s(Terrestrial Dynamical Time): synonym for TT (deprecated)(Ephemeris Time): continuous with TT; should not
be used for data taken after 1984-01-01
synonym for TAI (deprecated)(Universal Time): Earth rotation time
(Universal Time, Coordinated; default): runs synchronously with TAI, except for the occasional insertion of leap seconds intended to keep UTC within
0.9 s of UT1; as of 2015 -07-01 UTC = TAI − 36 s
(Greenwich Mean Time): continuous with UTC; its
use is deprecated for dates after 1972-01-01(Universal Time, with qualifier): for high-precisionuse of radio signal distributions between 1955 and1972; see Rots et al. (2015), Appendix A(Global Positioning System): runs (approximately)synchronously with TAI; GPS ≈ TAI − 19 s
(Geocentric Coordinate Time): TT reduced to thegeocenter, corrected for the relativistic effects ofthe Earth’s rotation and gravitational potential; TCG
runs faster than TT at a constant rate
(Barycentric Coordinate Time): derived from TCG
by a 4-dimensional transformation, taking into account the relativistic effects of the gravitational potential at the barycenter (relative to that on the rotating geoid) as well as velocity time dilation variations due to the eccentricity of the Earth’s orbit,
thus ensuring consistency with fundamental physical constants; Irwin & Fukushima (1999) provide atime ephemeris(Barycentric Dynamical Time): runs slower than
TCB at a constant rate so as to remain approximately
in step with TT; runs therefore quasi-synchronouslywith TT, except for the relativistic effects introducedby variations in the Earth’s velocity relative to thebarycenter. When referring to celestial observations,a pathlength correction to the barycenter may beneeded which requires the Time Reference Directionused in calculating the pathlength correction.
for simulation data and for free-running clocks.

DR

Value
TAI

of the recognized time scales listed in Table 30, and that timescale must be specified explicitly or implicitly as explained in
Sect. 9.2.1.
The reference point in time, to which all times in the HDU
are relative, shall be specified through one of three keywords:

MJDREF and JDREF may, for clarity or precision reasons, be split
into two keywords holding the integer and fractional parts separately:
MJDREFI – [integer; default: 0] The value field of this keyword
shall contain the integer part of reference time in MJD.
MJDREFF – [floating-point; default: 0.0] The value field of thiskeyword shall contain the fractional part of reference time in
MJD.
JDREFI – [integer; default: none] The value field of this keyword shall contain the integer part of reference time in JD.
JDREFF – [floating-point; default: none] The value field of thiskeyword shall contain the fractional part of reference time inJD.

If [M]JDREF and both [M]JDREFI and [M]JDREFF arepresent, the integer and fractional values shall have precedence
over the single value. If the single value is present with one of
the two parts, the single value shall have precedence. In the following, MJDREF and JDREF refer to their literal meaning or the
combination of their integer and fractional parts. If a header contains more than one of these keywords, JDREF shall have precedence over DATEREF and MJDREF shall have precedence overboth the others. If none of the three keywords is present, there is
no problem as long as all times in the HDU are expressed in ISO8601; otherwise MJDREF = 0.0 must be assumed. If TREFPOS =’CUSTOM’ (Section 9.2.3) it is legitimate for none of the reference time keywords to be present, as one may assume the data
are from a simulation. Note that the value of the reference time
has global validity for all time values, but it does not have a particular time scale associated with it.
9.2.3. Time reference position

An observation is an event in space-time. The reference position
specifies the spatial location at which the time is valid, either
where the observation was made or the point in space for whichlight-time corrections have been applied. When recorded as a
global keyword, the time reference position shall be specified
by:
TREFPOS – [string; default: ’TOPOCENTER’]. The value fieldof this keyword shall contain a character string code for the
spatial location at which the observation time is valid. The
value should be one of those given in Table 31. This keyword
shall apply to time coordinate axes in images as well.

39
In binary tables different columns may represent completely
different Time Coordinate Frames. However, each column canhave only one time reference position, thus guaranteeing linearity (see Section 9.2.1).
TRPOSn – [string; default: ’TOPOCENTER’] The value field of
this keyword shall contain a character string code for the
spatial location at which the observation time is valid. This
table keyword shall override TREFPOS.

Table 31: Standard Time Reference Position Values

GEOCENTERBARYCENTER
RELOCATABLECUSTOM

Meaning
Topocenter: the location from where the observation was made (default)
Geocenter
Barycenter of the Solar System
Relocatable: to be used for simulation dataonly
A position specified by coordinates that is
not the observatory location

DR

Value1
TOPOCENTER

Less common, but allowed standard values are:HELIOCENTERGALACTICEMBARYCENTERMERCURY
VENUS
MARS
JUPITER
SATURNURANUSNEPTUNE

Reference
Position

TOPOCENTER
GEOCENTERBARYCENTER
RELOCATABLE
Other2

TT, TDT
TAI, IATGPS
UTC, GMTtls

Heliocenter
Galactic center
Earth-Moon barycenter
Center of Mercury
Center of Venus
Center of Mars
Barycenter of the Jupiter system
Barycenter of the Saturn system
Barycenter of the Uranus system
Barycenter of the Neptune system

Notes. (1) Recognized values for TREFPOS, TRPOSn; only the first threecharacters of the values are significant and solar system locations are as
specified in the ephemerides.

The reader is cautioned that time scales and reference positions cannot be combined arbitrarily if one wants a clock thatruns linearly at TREFPOS. Table 32 provides a summary of compatible combinations. BARYCENTER should only be used in conjunction with time scales TDB and TCB and should be the only
reference position used with these time scales. With proper care
GEOCENTER, TOPOCENTER, and EMBARYCENTER are appropriate
for the first ten time scales in Table 30. However, relativistic

Time scale1
TCG TDB TCB

re

LOCAL

ls
c
ls

AF
T

The reference position value may be a standard location(such as GEOCENTER or TOPOCENTER) or a point in space defined by specific coordinates. In the latter case one should beaware that a (3-D) spatial coordinate frame needs to be definedthat is likely to be different from the frame(s) that the data areassociated with. Note that TOPOCENTER is only moderately informative if no observatory location is provided or indicated. The
commonly allowed standard values are shown in Table 31. Notethat for the gaseous planets the barycenters of their planetarysystems, including satellites, are used for obvious reasons. While
it is preferable to spell the location names out in full, in order tobe consistent with the practice of Greisen et al. (2006) the values are allowed to be truncated to eight characters. Furthermore,in order to allow for alternative spellings, only the first threecharacters of all these values shall be considered significant. The
value of the keyword shall be case-sensitive.

Table 32: Compatibility of Time Scales and Reference Positions

c
c

re

Notes. (1) Legend (combination is not recommended if no entry); c: correct match; reference position coincides with the spatial origin of thespace-time coordinates; t: correct match on Earth’s surface, otherwise
usually linear scaling; ls: linear relativistic scaling; re: non-linear relativistic scaling. (2) All other locations in the solar system.

effects introduce a (generally linear) scaling in certain combinations; highly eccentric spacecraft orbits are the exceptions.
Problems will arise when using a reference position on anothersolar system body (including HELIOCENTER). Therefore it is recommended to synchronize the local clock with one of the timescales defined on the Earth’s surface, TT, TAI, GPS, or UTC (inthe last case: beware of leap seconds). This is common practicefor spacecraft clocks. Locally, such a clock will not appear to
run at a constant rate, because of variations in the gravitational
potential and in motions with respect to Earth, but the effects
can be calculated and are probably small compared with errors
introduced by the alternative: establishing a local time standard.
In order to provide a complete description, TOPOCENTER
requires the observatory’s coordinates to be specified. There
are three options: (a) the ITRS Cartesian coordinates definedin Sect. 8.4.1 (OBSGEO-X, OBSGEO-Y, OBSGEO-Z), which arestrongly preferred; (b) a geodetic latitude/longitude/elevation
triplet (defined below); or (c) a reference to an orbit ephemeris
file. A set of geodetic coordinates is recognized:
OBSGEO-B – [floating-point] The value field of this keyword
shall contain the latitude of the observation in deg, with
North positive.
OBSGEO-L – [floating-point] The value field of this keyword
shall contain the longitude of the observation in deg, with
East positive.
OBSGEO-H – [floating-point] The value field of this keyword
shall contain the altitude of the observation in meters.
An orbital ephemeris file can instead be specified:
OBSORBIT – [string] The value field of this keyword
shall contain the character-string URI, URL, or the name ofan orbit ephemeris file.
Beware that only one set of coordinates is allowed in a given
HDU. Cartesian ITRS coordinates are the preferred coordinate
system; however, when using these in an environment requiring nanosecond accuracy, one should take care to distinguishbetween meters consistent with TCG or with TT. If one uses
geodetic coordinates, the geodetic altitude OBSGEO-H is measured with respect to the IAU 1976 ellipsoid which is defined39

40

X = (N(B) + H) cos(L) cos(B)Y = (N(B) + H) sin(L) cos(B)Z = (N(B)(1 − e2 ) + H) sin(B)where:a
N(B) = q
1 − e2 sin2 (B)2e = 2f − f2

a is the semi-major axis, and f is the inverse of the inverse flattening. Nanosecond precision in timing requires thatOBSGEO-[BLH] be expressed in a geodetic reference frame defined after 1984 in order to be sufficiently accurate.

DR

9.2.4. Time reference direction

If any pathlength corrections have been applied to the timestamps (i.e., if the reference position is not TOPOCENTER for observational data), the reference direction that is used in calculating the pathlength delay should be provided in order to maintaina proper analysis trail of the data. However, this is useful only
if there is also information available on the location from where
the observation was made (the observatory location). The direction will usually be provided in a spatial coordinate frame thatis already being used for the spatial metadata, although it is conceivable that multiple spatial frames are involved, e.g., spherical
ICRS coordinates for celestial positions, and Cartesian FK5 forspacecraft ephemeris. The time reference direction does not byitself provide sufficient information to perform a fully correcttransformation; however, within the context of a specific analysis environment it should suffice.
The uncertainty in the reference direction affects the errors
in the time stamps. A typical example is provided by barycentriccorrections where the time error is related to the position error:
terr (ms) ≤ 2.4poserr (arcsec)

The reference direction is indicated through a reference to specific keywords. These keywords may hold the reference direction explicitly or (for data in BINTABLEs) indicate columns
holding the coordinates. In event lists where the individual
photons are tagged with a spatial position, those coordinates
may have been used for the reference direction and the reference
will point to the columns containing these coordinate values. The
time reference direction shall be specified by the keyword:
40

TREFDIR – [string] The value field of this keyword
shall contain a character string composed of: the name of the
keyword containing the longitudinal coordinate, followed
by a comma, followed by the name of the keyword containing the latitudinal coordinate. This reference direction
shall apply to time coordinate axes in images as well.
In binary tables different columns may represent completely
different Time Coordinate Frames. However, also in that situation the condition holds that each column can have only one
Time Reference Direction. Hence, the following keyword may
override TREFDIR:AFT

as having a semi-major axis of 6 378 140 m and an inverse flattening of 298.2577.
A non-standard location indicated by CUSTOM must be specified in a manner similar to the specification of the observatory location (indicated by TOPOCENTER). One should be careful with the use of the CUSTOM value and not confuse it with
TOPOCENTER, as use of the latter imparts additional informationon the provenance of the data.
ITRS coordinates (X,Y,Z) may be derived from geodetic coordinates (L,B,H) through:

TRDIRn – [string] The value field of this keyword shall containa character string consisting of the name of the keyword orcolumn containing the longitudinal coordinate, followed by
a comma, followed by the name of the keyword or column
containing the latitudinal coordinate. This reference direction shall apply to time coordinate axes in images as well.

9.2.5. Solar System Ephemeris

If applicable, the Solar System ephemeris used for calculating
pathlength delays should be identified. This is particularly pertinent when the time scale is TCB or TDB. The ephemerides thatare currently most often used are those from JPL (2014a,b).
The Solar System ephemeris used for the data (if required)shall be indicated by the following keyword:
PLEPHEM – [string; default: ’DE405’] The value fieldof this keyword shall contain a character string thatshould represent a recognized designation for the Solar
System ephemeris. Recognized designations for JPL Solar
System ephemerides that are often used are listed inTable 33.
Table 33: Valid solar system ephemerides
Value’DE200’’DE405’’DE421’’DE430’’DE431’’DE432’

Reference
Standish (1990); considered obsolete, but still in use
Standish (1998); default
Folkner, et al. (2009)
Folkner, et al. (2014)
Folkner, et al. (2014)
Folkner, et al. (2014)

Future ephemerides in this series shall be accepted and recognized as they are released. Additional ephemerides designations may be recognized by the IAUFWG upon request.
9.3. Time unit

When recorded as a global keyword, the unit used to express
time shall be specified by:
TIMEUNIT – [string; default: ’s’] The value field of this keyword shall contain a character string that specifies the time
unit; the value should be one of those given in Table 34. This
time unit shall apply to all time instances and durations that
do not have an implied time unit (such as is the case for JD,
MJD, ISO-8601, J and B epochs). If this keyword is absent,’s’ shall be assumed.

41
In an appropriate context, e.g., when an image has a time axis,
TIMEUNIT may be overridden by the CUNITia keywords andtheir binary table equivalents (see Table 22).
The specification of the time unit allows the values definedin Greisen & Calabretta (2002), shown in Table 34, with the addition of the century. See also Sect. 4.3 for generalities about
units.

this keyword affects the values of TSTART, and TSTOP, as well as
any time pixel values in a binary table. However, this construct
may only be used in tables and must not be used in images.
9.4.2. Time resolution and binning

The resolution of the time stamps (the width of the time sampling function) shall be specified by:

Table 34: Recommended time units

AF
T

Value
Definition’s’second (default)’d’day (= 86,400 s)’a’(Julian) year (= 365.25 d)’cy’(Julian) century (= 100 a)
The following values are also acceptable:’min’ minute (= 60 s)’h’day (= 86,400 s)’yr’(Julian) year (= a = 365.25 d)’ta’tropical year
’Ba’
Besselian year

TIMEDEL – [floating-point] The value field of this keyword
shall contain the value of the time resolution in the units of
TIMEUNIT. This construct, when present, shall only be usedin tables and must not be used in images.

The use of ta and Ba is not encouraged, but there aredata and applications that require the use of tropical years or
Besselian epochs (see Section 9.1.2). The length of the tropicalyear, ta, in days is:
1 ta = 365.24219040211236 − 0.00000615251349 T−6.0921 × 10−10 T 2 + 2.6525 × 10−10 T 3 (d)DRwhere T is in Julian centuries since J2000, using time scale TDB.
The length of the Besselian year in days is:
1Ba = 365.2421987817 − 0.00000785423 T (d)where T is in Julian centuries since J1900, using time scale ET,
although for these purposes the difference with TDB is negligible.
Readers are cautioned that the subject of tropical andBesselian years presents a particular quandary for the specification of standards. The expressions presented here are the mostaccurate available, but are applicable for use when creating data
files (which is strongly discouraged), rather than for interpreting existing data that are based upon these units. But there is
no guarantee that the authors of the data applied these particular definitions. Users are therefore advised to pay close attention
and attempt to ascertain what the authors of the data really used.

In tables this may, for instance, be the size of the bins for timeseries data or the bit precision of the time stamp values.
When data are binned in time bins (or, as a special case,events are tagged with a time stamp of finite precision) it is important to know to the position within the bin (or pixel) to which
the time stamp refers. Coordinate values normally correspondto the center of all pixels (see Sect. 8.2); yet clock readings are
effectively truncations, not rounded values, and therefore correspond to the lower bound of the pixel.
TIMEPIXR – [floating-point; default: 0.5] The value field of thiskeyword shall contain the value of the position within the
pixel, from 0.0 to 1.0, to which the time-stamp refers. This
construct, when present, shall only be used in tables and mustnot be used in images.

A value of 0.0 may be more common in certain contexts, e.g.
when truncated clock readings are recorded, as is the case foralmost all event lists.
9.4.3. Time errors

The absolute time error is the equivalent of a systematic error,
shall be given by the following keyword:
TIMSYER – [floating-point; default: 0.] The value field of thiskeyword shall contain the value of the absolute time error, inunits of TIMESYS.
This keyword may be overridden, in appropriate context (e.g.,time axes in image arrays or table columns; by the CSYERia keywords and their binary table equivalents (see Table 22).
The relative time error specifies accuracy of the time stamps
relative to each other. This error will usually be much smaller
than the absolute time error. This error is equivalent to a random
error, and shall be given by the following keyword:

9.4. Time offset, binning, and errors
9.4.1. Time offset

A uniform clock correction may be applied in bulk with the following single keyword.

TIMRDER – [floating-point; default: 0.] The value field of thiskeyword shall contain the value of the relative time error, i.e.
the random error between time stamps, in units of TIMESYS.
This keyword may be overridden, in appropriate context (e.g.,time axes in image arrays or table columns; by the CRDERia keywords and their binary table equivalents (see Table 22).

TIMEOFFS – [floating-point; default: 0.0] The value field of
this keyword shall contain the value of the offset in timethat shall be added to the reference time, given by one of:
MJDREF, JDREF, or DATEREF.

9.5. Global time keywords

The time offset may serve to set a zero-point offset to a relative time series, allowing zero-relative times, or just higher precision, in the time stamps. Its default value is zero. The value of

The time keywords in Table 35 are likely to occur in headerseven when there are no time axes in the data. Except for DATE,
they provide the top-level temporal bounds of the data in the41

42
HDU. As noted before, they may also be implemented as table
columns. Keywords not previously described are defined below;
all are included in the summary Table 22.
Table 35: Keywords for global time values

DATE-BEG
DATE-AVG
DATE-END
MJD-OBSMJD-BEGMJD-AVG
MJD-ENDTSTART
TSTOP

Notes
Defined in Sect. 4.4.2
Defined in Sect. 4.4.2. Keyword value was not restricted to mean the start time of an observation, andhas historically also been used to indicate some formof mean observing date and time. To avoid ambiguity
use DATE-BEG instead.
Defined in this section.
Defined in Sect. 8.4.1. The method by which average times should be calculated is not defined by thisStandard.
Defined in this section.
Defined in Sect. 8.3
Defined in this section.
Defined in Sect. 8.4.1. The method by which average times should be calculated is not defined by thisStandard.
Defined in this section.
Defined in this section.
Defined in this section.

DR

DATE-BEG – [datetime] The value field of this keyword
shall contain a character string in ISO-8601 format that specifies the start time of data acquisition in the time system specified by the TIMESYS keyword.
DATE-END – [datetime] The value field of this keyword
shall contain a character string in ISO-8601 format that specifies the stop time of data acquisition in the time system specified by the TIMESYS keyword.
MJD-BEG – [floating-point] The value field of this keyword
shall contain the value of the MJD start time of data acquisition in the time system specified by the TIMESYS keyword.
MJD-END – [floating-point] The value field of this keyword
shall contain the value of the MJD stop time of data acquisition in the time system specified by the TIMESYS keyword.
TSTART – [floating-point] The value field of this keyword
shall contain the value of the start time of data acquisition inunits of TIMEUNIT, relative to MJDREF, JDREF, or DATEREF
and TIMEOFFS, in the time system specified by the TIMESYS
keyword.
TSTOP – [floating-point] The value field of this keyword
shall contain the value of the stop time of data acquisition inunits of TIMEUNIT, relative to MJDREF, JDREF, or DATEREF
and TIMEOFFS, in the time system specified by the TIMESYS
keyword.

The alternate-axis equivalent keywords for BINTABLEs,
DOBSn, MJDOBn, DAVGn, and MJDAn, as defined in Table 22, arealso allowed. Note that of the above only TSTART and TSTOP are
relative to the time reference value. As in the case of the time reference value (see Section 9.2.2), the JD values supersede DATE
values, and MJD values supersede both, in cases where conflicting values are present.
It should be noted that, although they do not represent global
time values within an HDU, the CRVALia and CDELTia keywords,
42

JEPOCH – [floating-point] The value field of this keyword
shall contain the value of the Julian epoch, with an implied
time scale of ’TDB’.
BEPOCH – [floating-point] The value field of this keyword
shall contain the value of the Besselian epoch, with an implied time scale of ’ET’.

AF
T

KeywordDATE
DATE-OBS

and their binary table equivalents (see Table 22), also represent(binary) time values. They should be handled with the same careregarding precision when combining them with the time reference value as any other time value.
Finally, Julian and Besselian epochs (see Sections 9.1.2 and9.3) may be expressed by these two keywords – to be usedwith great caution, as their definitions are more complicated andhence their use more prone to confusion:

When these epochs are used as time stamps in a table column
their interpretation will be clear from the context. When the keywords appear in the header without obvious context, they must
be regarded as equivalents of DATE-OBS and MJD-OBS, i.e., withno fixed definition as to what part of the dataset they refer to.
9.6. Other time coordinate axes

There are a few coordinate axes that are related to time and thatare accommodated in this standard: (temporal) phase, timelag,
and frequency. Phase results from folding a time series on agiven period, and can appear in parallel with time as an alternate description of the same axis. Timelag is the coordinate ofcross- and auto-correlation spectra. The temporal frequency is
the Fourier transform equivalent of time and, particularly, thecoordinate axis of power spectra; spectra where the dependent
variable is the electromagnetic field are excluded here, but see
Greisen et al. (2006). These coordinate axes shall be specified
by giving CTYPEi and its binary table equivalents one of the values: PHASE, TIMELAG, or FREQUENCY.
Timelag units are the regular time units, and the basic unit
for frequency is Hz. Neither of these two coordinates is a linear
or scaled transformation of time, and therefore cannot appear inparallel with time as an alternate description. That is, a given
vector of values for an observable can be paired with a coordinate vector of time, or timelag, or frequency, but not with morethan one of these; the three coordinates are orthogonal.
Phase can appear in parallel with time as an alternate description of the same axis. Phase shall be recorded in the following
keywords:
CZPHSia – [floating-point] The value field of this keyword
shall contain the value of the time at the zero point of a phaseaxis. Its units may be deg, rad, or turn.
CPERIia – [floating-point] The value field of this keyword, if
present shall contain the value of the period of a phase axis.
This keyword can be used only if the period is a constant; ifthat is not the case, this keyword should either be absent or
set to zero.

CZPHSia may instead appear in binary table forms TCZPHn,
TCZPna, iCZPHn, and iCZPna. CPERIia may instead appear inbinary table forms TCPERn, TCPRna, iCPERn, and iCPRna. The
Phase, period and zero point shall be expressed in the globallyvalid time reference frame and unit as defined by the global keywords (or their defaults) in the header.

43
9.7. Durations

There is an extensive collection of header keywords that indicate time durations, such as exposure times, but there are many
pitfalls and subtleties that make this seemingly simple concept
treacherous. Because of their crucial role and common use, keywords are defined below to record exposure and elapsed time.

9.8.2. Restrictions on alternate descriptions

An image will have at most one time axis as identified by having the CTYPEi value of TIME or one of the values listed inTable 30. Consequently, as long as the axis is identified through
CTYPEi, there is no need to have axis number identificationon the global time-related keywords. It is expressly prohibitedto specify more than one time reference position on this axis
for alternate time coordinate frames, since this would give rise
to complicated model-dependent non-linear relations between
these frames. Hence, time scales TDB and TCB (or ET, to its precision) may be specified in the same image, but cannot be combined with any of the first nine time scales in Table 30; those firstnine can be expressed as linear transformations of each other,too, provided the reference position remains unchanged. Timescale LOCAL is by itself, intended for simulations, and should
not be mixed with any of the others.

AF
T

XPOSURE – [floating-point] The value field of this keyword
shall contain the value for the effective exposure duration forthe data, corrected for dead time and lost time in the units
of TIMEUNIT. If the HDU contains multiple time slices, thisvalue shall be the total accumulated exposure time over all
slices.
TELAPSE – [floating-point] The value field of this keyword
shall contain the value for the amount of time elapsed, inthe units of TIMEUNIT, between the start and the end of theobservation or data stream.

coordinate specified in a non-recognized time scale assumes thevalue of the axis pixels or the column cells, optionally modified
by applicable scaling and/or reference value keywords; see also
Section 9.2.1.

DR

Durations must not be expressed in ISO-8601 format, but
only as actual durations (i.e., numerical values) in the units ofthe specified time unit.
Good-Time-Interval (GTI) tables are common for exposureswith gaps in them, particularly photon-event files, as they makeit possible to distinguish time intervals with “no signal detected”
from “no data taken.” GTI tables in BINTABLE extensions
must contain two mandatory columns, START and STOP, andmay contain one optional column, WEIGHT. The first two define
the interval, the third, with a value between 0 and 1, the qualityof the interval; i.e., a weight of 0 indicates a Bad-Time-Interval.
WEIGHT has a default value of 1. Any time interval not coveredin the table shall be considered to have a weight of zero.
9.8. Recommended best practices

The following guidelines should be helpful in creating data products with a complete and correct time representation.

– The presence of the informational DATE keyword is strongly
recommended in all HDUs.
– One or more of the informational keywords DATE-xxxx
and/or MJD-xxxx should be present in all HDUs whenever ameaningful value can be determined. This also applies, e.g.,
to catalogs derived from data collected over a well-definedtime range.
– The global keyword TIMESYS is strongly recommended.
– The global keywords MJDREF or JDREF or DATEREF are recommended.
– The remaining informational and global keywords should bepresent whenever applicable.
– All context-specific keywords shall be present as needed andrequired by the context of the data.
9.8.1. Global keywords and overrides

For reference to the keywords that are discussed here, see Table
22. The globally applicable keywords listed in section B of thetable serve as default values for the corresponding C* and TC*
keywords in that same section, but only when axis and column
specifications (including alternate coordinate definitions) use atime scale listed in Table 30 or when the corresponding CTYPEor TTYPE keywords are set to the value ’TIME’. Any alternate

9.8.3. Image time axes

Section 8.2 requires keywords CRVALia to be numeric and theycannot be expressed in ISO-8601 format. Therefore it is requiredthat CRVALia contain the elapsed time in units of TIMEUNIT or
CUNITia, even if the zero point of time is specified by DATEREF.
If the image does not use a matrix for scaling, rotation andshear (Greisen & Calabretta 2002), CDELTia provides the numeric value for the time interval. If the PC form of scaling, rotation and shear (Greisen & Calabretta 2002) is used, CDELTia
provides the numeric value for the time interval, and PCi j, wherei = j = the index of the time axis (in the typical case of an image cube with axis 3 being time, i = j = 3) would take theexact value 1, the default (Greisen & Calabretta 2002). When
the CDi j form of mapping is used, CDi j provides the numericvalue for the time interval. If one of the axes is time and thematrix form is used, then the treatment of the PCi ja (or CDi ja)
matrices involves at least a Minkowsky metric and Lorentz transformations (as contrasted with Euclidean and Galilean).

10. Representations of compressed data
Minimizing data volume is important in many contexts, particularly for publishers of large astronomical data collections. The
following sections describe compressed representations of data
in FITS images and BINTABLES that preserve metadata andallow for full or partial extraction of the original data as necessary. The resulting FITS file structure is independent of the specific data compression algorithm employed. The implementation
details for some compression algorithms that are widely usedin astronomy are defined in Sect. 10.4, but other compression
techniques could also be supported. See the FITS convention by
White et al. (2013) for details of the compression techniques, but
beware that the specifications in this Standard shall supersede
those in the registered convention.
Compression of FITS files can be beneficial for sites that
store or distribute large quantities of data; the present section
provides a standard framework that addresses such needs. As im43

44
plementation of compression/decompression codes can be quite
complex, not all FITS reading and writing software is necessarily expected to support these capabilities. External utilities areavailable to compress and uncompress FITS files16 .
10.1. Tiled Image Compression

DR

10.1.1. Required Keywords

In addition to the mandatory keywords for BINTABLE extensions (see Sect. 7.3.1) the following keywords are reserved foruse in the header of a FITS binary table extension to describe thestructure of a valid compressed FITS image. All are mandatory.

ZIMAGE – [logical; value ’T’] The value field of this keyword
shall contain the logical value ’T’ to indicate that the FITS
binary table extension contains a compressed image, and that
logically this extension should be interpreted as an image
rather than a table.
ZCMPTYPE – [string; default: none] The value field of this keyword shall contain a character string giving the name of thealgorithm that was used to compress the image. Only the values given in Table 36 are permitted; the corresponding algorithms are described in Sect. 10.4. Other algorithms may be
added in the future.
ZBITPIX – [integer; default: none] The value field of this keyword shall contain an integer that gives the value of the
BITPIX keyword in the uncompressed FITS image.
ZNAXIS – [integer; default: none] The value field of this keyword shall contain an integer that gives the value of the
NAXIS keyword (i.e., the number of axes) in the uncompressed FITS image.
ZNAXISn – [integer; indexed; default: none) The value field of
these keywords shall contain a positive integer that gives the16e.g. fpack/funpack, see https://heasarc.gsfc.nasa.gov/
fitsio/fpack/44

The comment fields for the BITPIX, NAXIS, and NAXISn
keywords in the uncompressed image should be copied to thecorresponding fields in the ZBITPIX, ZNAXIS, and ZNAXISn
keywords.
10.1.2. Other Reserved Keywords

The compressed image tiles must be stored in the binary tablein the same order that the first pixel in each tile appears in the
FITS image; the tile containing the first pixel in the image must
appear in the first row of the table, and the tile containing thelast pixel in the image must appear in the last row of the binary
table. The following keywords are reserved for use in describing compressed images stored in BINTABLE extensions; they
may be present in the header, and their values depend upon thetype of image compression employed.

AF
TThe following describes the process for compressing
n−dimensional FITS images and storing the resulting byte
stream in a variable-length column in a FITS binary table, andfor preserving the image header keywords in the table header.
The general principle is to first divide the n−dimensional image
into a rectangular grid of subimages or “tiles.” Each tile is thencompressed as a block of data, and the resulting compressedbyte stream is stored in a row of a variable length column ina FITS binary table (see Section 7.3). By dividing the image
into tiles it is possible to extract and uncompress subsectionsof the image without having to uncompress the whole image.
The default tiling pattern treats each row of a 2-dimensional
image (or higher dimensional cube) as a tile, such that eachtile contains NAXIS1 pixels. This default may not be optimalfor some applications or compression algorithms, so any otherrectangular tiling pattern may be defined using keywords thatare defined below. In the case of relatively small images it may
suffice to compress the entire image as a single tile, resulting
in an output binary table with a single row. In the case of
3-dimensional data cubes, it may be advantageous to treat
each plane of the cube as a separate tile if application software
typically needs to access the cube on a plane-by-plane basis.

value of the corresponding NAXISn keywords (i.e., the sizeof axis n) in the uncompressed FITS image.

ZTILEn – [integer; indexed; default: 1 for n > 1] The value
field of these keywords (where n is a positive integer index
that ranges from 1 to ZNAXIS) shall contain a positive integer
representing the number of pixels along axis n of the compressed tiles. Each tile of pixels must be compressed separately and stored in a row of a variable-length vector column
in the binary table. The size of each image dimension (given
by ZNAXISn) need not be an integer multiple of ZTILEn, andif it is not, then the last tile along that dimension of the image will contain fewer image pixels than the other tiles. If the
ZTILEn keywords are not present then the default “row-byrow” tiling will be assumed, i.e., ZTILE1 = ZNAXIS1, andthe value of all the other ZTILEn keywords must equal 1.
ZNAMEi – [string; indexed; default: none] The value field of
these keywords (where i is a positive integer index starting with 1) shall supply the names of up to 999 algorithmspecific parameters that are needed to compress or uncompress the image. The order of the compression parameters
may be significant, and may be defined as part of the description of the specific decompression algorithm.
ZVALi – [string; indexed; default: none] The value field of these
keywords (where i is a positive integer index starting with
1) shall contain the values of up to 999 algorithm-specificparameters with the same index i. The value of ZVALi may
have any valid FITS data type.
ZMASKCMP – [string; default: none] The value field of this keyword shall contain the name of the image compression algorithm that was used to compress the optional null-pixel
data mask. This keyword may be omitted if no null-pixel datamasks appear in the table. See Sect. 10.2.2 for details.
ZQUANTIZ – [string; default: ’NO DITHER’] The value field of
this keyword shall contain the name of the algorithm thatwas used to quantize floating-point image pixels into integer values, which were then passed to the compression algorithm as discussed further in Sect. 10.2. If this keyword
is not present, the default is to assume that no dithering wasapplied during quantization.
ZDITHER0 – [integer; default: none] The value field of this keyword shall contain a positive integer (that may range from 1
to 10000 inclusive) that gives the seed value for the random

45
dithering pattern that was used when quantizing the floatingpoint pixel values. This keyword may be absent if no dithering was applied. See Sect. 10.2 for further discussion.

COMPRESSED DATA – [required; variable-length] Each row of
this column must contain the byte stream that is generated
as a result of compressing the corresponding image tile. The
data type of the column (as given by the TFORMn keyword)
must be one of ’1PB’, ’1PI’, or ’1PJ’ (or the equivalent’1QB’, ’1QI’, or ’1QJ’), depending on whether the compression algorithm generates an output stream of 8-bit bytes,
or integers of 16-, or 32-bits.

AF
T

The following keywords are reserved to preserve a verbatim
copy of the value and comment fields for keywords in the original uncompressed FITS image that were used to describe its strructure. These optional keywords, when present, shall be used
when reconstructing an identical copy of the original FITS HDUof the uncompressed image. They should not appear in the compressed image header unless the corresponding keywords were
present in the uncompressed image.

table is not significant. One of the table columns describes optional content; but when this column appears it must be used as
defined in this section. The column names (given by the TTYPEn
keyword) are reserved; they are shown here in upper case letters,
but case is not significant.

DRZSIMPLE – [logical; value ’T’] The value field of this keyword
must contain the value of the original SIMPLE keyword in theuncompressed image.
ZEXTEND – [string] The value field of this keyword must contain the value of the original EXTEND keyword in the uncompressed image.
ZBLOCKED – [logical] The value field of this keyword must contain the value of the original BLOCKED keyword in the uncompressed image.
ZTENSION – [string] The value field of this keyword must contain the original XTENSION keyword in the uncompressed
image.
ZPCOUNT – [integer] The value field of this keyword must contain the original PCOUNT keyword in the uncompressed image.
ZGCOUNT – [integer] The value field of this keyword must contain the original GCOUNT keyword in the uncompressed image.
ZHECKSUM – [string] The value field of this keyword must contain the original CHECKSUM keyword (see Sect. 4.4.2.7) in theuncompressed image.
ZDATASUM – [string] The value field of this keyword must contain the original DATASUM keyword (see Sect. 4.4.2.7) in theuncompressed image.

The ZSIMPLE, ZEXTEND, and ZBLOCKED keywords must not
be used unless the original uncompressed image was containedin the primary array of a FITS file. The ZTENSION, ZPCOUNT,and ZGCOUNT keywords must not be used unless the original uncompressed image was contained in an IMAGE extension.
The FITS header of the compressed image may contain otherkeywords. If a FITS primary array or IMAGE extension is compressed using the procedure described here, it is strongly recommended that all the keywords (including comment fields) in theheader of the original image, except for the mandatory keywords
mentioned above, be copied verbatim and in the same order into
the header of the binary table extension that contains the compressed image. All these keywords will have the same meaning and interpretation as they did in the original image, even incases where the keyword is not normally expected to occur in theheader of a binary table extension (e.g., the BSCALE and BZERO
keywords, or the World Coordinate System keywords such as
CTYPEn, CRPIXn and CRVALn).
10.1.3. Table Columns

Two columns in the FITS binary table are defined below to contain the compressed image tiles; the order of the columns in the

When using the quantization method to compress floatingpoint images that is described in Sect. 10.2, it sometimes may
not be possible to quantize some of the tiles (e.g., if the range of
pixels values is too large or if most of the pixels have the samevalue and hence the calculated RMS noise level in the tile isclose to zero). There also may be other rare cases where the nominal compression algorithm cannot be applied to certain tiles. In
these cases, an alternate technique may be used in which the raw
pixel values are losslessly compressed with the GZIP algorithm.
GZIP COMPRESSED DATA [optional; variable-length] If the raw
pixel values in an image tile are losslessly compressed with
the GZIP algorithm, the resulting byte stream must be stored
in this column (with a ’1PB’ or ’1QB’ variable-length array column format). The corresponding COMPRESSED DATA
column for these tiles must contain a null pointer (i.e., thepair of integers that constitute the descriptor for the column
must both have the value zero: see Sect. 7.3.5).

The compressed data columns described above may use either the ’1P’ or ’1Q’ variable-length array FITS column format
if the size of the heap in the compressed FITS file is < 2.1 GB. If
the the heap is larger than 2.1 GB, then the ’1Q’ format (whichuses 64-bit pointers) must be used.
When using the optional quantization method described in
Sect. 10.2 to compress floating-point images, the following
columns are required.
ZSCALE – [floating-point; optional] This column shall be used
to contain linear scale factors that, along with ZZERO, transform the floating-point pixel values in each tile to integersvia, F − ZZERO i
Ii = round(12)
ZSCALE
where Ii and Fi are the integer and (original) floating-pointvalues of the image pixels, respectively and the round function rounds the result to the nearest integer value.
ZZERO – [floating-point; optional] This column shall be used tocontain zero point offsets that are used to scale the floatingpoint pixel values in each tile to integers via Eq. 12.
Do not confuse the ZSCALE and ZZERO columns with the
BSCALE and BZERO keywords (defined in Sect. 4.4.2) which may
be present in integer FITS images. Any such integer images
should normally be compressed without any further scaling, andthe BSCALE and BZERO keywords should be copied verbatim into
the header of the binary table containing the compressed image.
45

46
Some images contain undefined pixel values; in uncompressed floating-point images these pixels have an IEEE NaN
value. However, these pixel values will be altered when using
the quantization method described in Sect. 10.2 to compress
floating-point images. The value of the undefined pixels may bepreserved in the following way.

AF
T

ZBLANK – [integer; optional] When present, this column
shall be used to store the integer value that represents undefined pixels in the scaled integer array. The recommended
value for ZBLANK is −2147483648, the largest negative 32bit integer. If the same null value is used in every tile of theimage, then ZBLANK may be given in a header keyword instead of a table column; if both a keyword and a table column
named ZBLANK are present, the values in the table column
must be used. If there are no undefined pixels in the image
then ZBLANK is not required to be present either as a table
column or a keyword.

given by log2 (Q) + 1.792. Q results directly related to the compressed file size: decreasing Q by a factor of 2 will decrease
the file size by about 1 bit/pixel. In order to achieve the greatest amount of compression, one should use the smallest valueof Q that still preserves the required amount of photometric andastrometric precision in the image. Image quality will remaincomparable regardless of the noise level.
A potential problem when applying this scaling method toastronomical images, in particular, is that it can lead to a systematic bias in the measured intensities in faint parts of the image:As the image is quantized more coarsely, the measured intensityof the background regions of the sky will tend to be biased towards the nearest quantize level. One very effective techniquefor minimizing this potential bias is to dither the quantized pixel
values by introducing random noise during the quantization process. So instead of simply scaling every pixel value in the sameway using Eq. 12, the quantized levels are randomized by using
this slightly modified equation:
 F − ZZEROi
Ii = round+ Ri − 0.5(13)
ZSCALE

If the uncompressed image has an integer data type
(ZBITPIX > 0) then the value of undefined pixels is given by the
BLANK keyword (see Sect. 5.3), which should be used insteadof ZBLANK. When using some compression techniques that do
not exactly preserve integer pixel values, it may be necessary tostore the location of the undefined pixels prior to compressing
the image. The locations may be stored in an image mask, whichmust itself be compressed and stored in a table column with thefollowing definition. See Sect. 10.2.2 for more details.

DR

NULL PIXEL MASK – [integer array; optional] When present,
this column shall be used to store, in compressed form, animage mask with the same original dimensions as the uncompressed image, that records the location of the undefined
pixels. The process defined in Sect. 10.2.2 shall be used toconstruct the compressed pixel mask.
Additional columns may be present in the table to supply
other parameters that relate to each image tile. However, theseparameters should not be recorded in the image HDU when theuncompressed image is restored.
10.2. Quantization of Floating-Point Data

While floating-point format images may be losslessly compressed, noisy images often do not compress very well. Higher
compression can only be achieved by removing some of thisnoise without losing the useful information content. One commonly used technique for reducing the noise is to scale thefloating-point values into quantized integers using Eq. 12, andusing the ZSCALE and ZZERO columns to record the two scaling coefficients that are used for each tile. Note that the absenceof these two columns in a tile-compressed floating-point image
is an indication that the image was not scaled and was instead
losslessly compressed.
An effective scaling algorithm for preserving a specified amount of noise in each pixel value is described by
White & Greenfield (1999) and by Pence et al. (2009). With thismethod, the ZSCALE value (which is numerically equal to thespacing between adjacent quantization levels) is calculated to besome fraction, Q, of the RMS noise as measured in backgroundregions of the image. Pence et al. (2009) shows that the numberof binary bits of noise that are preserved in each pixel value is46

where Ri is a random number between 0.0 and 1.0, and 0.5 issubtracted so that the mean quantity equals 0. Then restoring thefloating-point value, the same Ri is used with the inverse formula:
Fi = ((Ii − Ri + 0.5) ∗ ZSCALE) + ZZERO(14)This “subtractive dithering” technique has the effect of dithering
the zero-point of the quantization grid on a pixel by pixel basis
without adding any actual noise to the image. The net effect of
this is that the mean (and median) pixel value in faint regionsof the image more closely approximate the value in the original unquantized image than if all the pixels are scaled without
dithering.
The key requirement when using this subtractive dithering
technique is that the exact same random number sequence must
be used when quantizing the pixel values to integers, and when
restoring them to floating point values. While most computer
languages supply a function for generating random numbers,
these functions are not guaranteed to generate the same sequenceof numbers every time. An algorithm for generating a repeatablesequence of pseudo random numbers is given in Appendix I; thisalgorithm must be used when applying a subtractive dither.
10.2.1. Dithering Algorithms

The ZQUANTIZ keyword, if present, must have one of the following values to indicate the type of quantization, if any, that
was applied to the floating-point image for compression:
NO DITHER – No dithering was performed; the floating-point
pixels were simply quantized using Eq. 12. This option
shall be assumed if the ZQUANTIZ keyword is not present in
the header of the compressed floating-point image.
SUBTRACTIVE DITHER 1 – The basic subtractive dithering was
performed, the algorithm for which is described below. Notethat an image quantized using this technique can still be unquantized using the simple linear scaling function given by
Eq. 12, at the cost of introducing slightly more noise in theimage than if the full subtractive dithering algorithm wereapplied.

47
SUBTRACTIVE DITHER 2 – This dithering algorithm is identical to that for SUBTRACTIVE DITHER 1, except that any pixels in the floating-point image that are exactly equal to 0.0
are represented by the reserved value −2147483647 in thequantized integer array. When the image is subsequently uncompressed and unscaled, these pixels must be restored totheir original value of 0.0. This dithering option is useful if
the zero-valued pixels have special significance to the data
analysis software, so that the value of these pixels must not
be dithered.

10.2.2. Preserving undefined pixels with lossy compression

The undefined pixels in integer images are flagged by a reserved
BLANK value and will be preserved if a lossless compression algorithm is used. (ZBLANK is used for undefined pixels in floatingpoint images.) If the image is compressed with a lossy algorithm,
then some other technique must be used to identify the undefined
pixels in the image. In this case it is recommended that the undefined pixels be recorded with the following procedure:

AF
T

The process for generating a subtractive dither for a floatingpoint image is the following:

7. Writethecompressed
bytestream
into
the
COMPRESSED DATA column in the appropriate row of
the binary table corresponding to that tile.
8. Write the linear scaling and zero point values that were usedin Eq. 13 for that tile into the ZSCALE and ZZERO columns,
respectively, in the same row of the binary table.
9. Repeat Steps 4 through 8 for each tile of the image.

DR

1. Generate a sequence of 10000 single-precision floating-point
random numbers, RN, with a value between 0.0 and 1.0.
Since it could be computationally expensive to generate aunique random number for every pixel of large images, simply cycle through this look-up table of random numbers.
2. Choose an integer in the range 1 to 10000 to serve as an
initial seed value for creating a unique sequence of random
numbers from the array that was calculated in the previous
step. The purpose of this is to reduce the chances of applying the same dithering pattern to two images that are subsequently subtracted from each other (or co-added), because
the benefits of randomized dithering are lost if all the pixels
are dithered in phase with each other. The exact method forcomputing this seed integer is not important as long as thevalue is chosen more or less randomly.
3. Write the integer seed value that was selected in the previous
step as the value of the ZDITHER0 keyword in the header ofthe compressed image. This value is required to recomputethe same dithering pattern when uncompressing the image.
4. Before quantizing each tile of the floating point image, calculate an initial value for two offset parameters, I0 and I1 ,with the following formulae:
I0 = mod(Ntile − 1 + ZDITHER0, 10000)
I1 = INT(RN(I0 ) ∗ 500.)

(15)
(16)

where Ntile is the row number in the binary table that is used
to store the compressed bytes for that tile, ZDITHER0 is thatvalue of that keyword, and RN(I0 ) is the value of the I0th random number in the sequence that was computed in the firststep. Note that I0 has a value in the range 0 to 9999 and I1
has a value in the range 0 to 499. This method for computing
I0 and I1 was chosen so that a different sequence of random
numbers is used to compress successive tiles in the image,and so that the sequence of I1 values has a length of order
100 million elements before repeating.
5. Now quantize each floating-point pixel in the tile using
Eq. 13 and using random number RN(I1 ) for the first pixel.
Increment the value of I1 for each subsequent pixel in the
tile. If I1 reaches the upper limit of 500, then increment thevalue of I0 and recompute I1 from Eq. 16. If I0 also reaches
the upper limit of 10000, then reset I0 to 0.
If the floating-point pixel has an IEEE NaN value, then it is
not quantized or dithered but instead is set to the reserved
integer value specified by the ZBLANK keyword. For consistency, the value of I1 should also be incremented in this caseeven though it is not used.
6. Compress the array of quantized integers using the losslessalgorithm that is specified by the ZCMPTYPE keyword (use
RICE 1 by default).

1. Create an integer data mask with the same dimensions as theimage tile
2. For each undefined pixel in the image, set the corresponding
mask pixels to 1 and all the other pixels to 0.
3. Compress the mask array using a lossless algorithm such as
PLIO or GZIP, and record the name of that algorithm withthe keyword ZMASKCMP.
4. Store the compressed byte stream in a variable-length arraycolumn called ’NULL PIXEL MASK’ in the table row corresponding to that image tile.

The data mask array pixels should have the shortest integer
data type that is supported by the compression algorithm (i.e.,
usually 8-bit bytes). When uncompressing the image tile, thesoftware must check if the corresponding compressed data mask
exists with a length greater than 0, and if so, uncompress themask and set the corresponding undefined pixels in the image
array to the value given by the BLANK keyword.
10.3. Tiled Table Compression

The following section describes the process for compressing
the content of BINTABLE columns. Some additional details of
BINTABLE compression may be found in Pence et al. (2013),
but the specifications in this Standard shall supersede those in
the registered convention. The uncompressed table may be subdivided into tiles, each containing a subset of rows, then eachcolumn of data within each tile is extracted, compressed, andstored as a variable-length array of bytes in the output compressed table. The header keywords from the uncompressed table, with only a few limited exceptions, shall be copied verbatim to the header of the compressed table. The compressed tablemust itself be a valid FITS binary table (albeit one where thecontents cannot be interpreted without uncompressing the contents) that contains the same number and order of columns asin the uncompressed table, and that contains one row for eachtile of rows in the uncompressed table. Only the compression
algorithms specified in Sect. 10.3.5 are permitted.
10.3.1. Required Keywords

With only a few exceptions noted below, all the keywords andcorresponding comment fields from the uncompressed tablemust be copied verbatim, in order, into the header of the com47

48
pressed table. Note in particular that the values of the reserved
column descriptor keywords TTYPEn, TUNITn, TSCALn, TZEROn,
TNULLn, TDISPn, and TDIMn, as well as all the column-specific
WCS keywords defined in the FITS standard, must have thesame values and data types in both the original and in the compressed table, with the understanding that these keywords apply
to the uncompressed data values.

The procedure for compressing a FITS binary table consists ofthe following sequence of steps:
1. Divide table into tiles (optional)
In order to limit the amount of data that must be managed
at one time, large FITS tables may be divided into tiles, eachcontaining the same number of rows (except for the last tilewhich may contain fewer rows). Each tile of the table is compressed in order and each is stored in a single row in the output compressed table. There is no fixed upper limit on the allowed tile size, but for practical purposes it is recommended
that it not exceed 100 MB.
2. Decompose each tile into the component columns
FITS binary tables are physically stored in row-by-row sequential order, such that the data values for the first row ineach column are followed by the values in the second row,and so on (see Sect. 7.3.3). Because adjacent columns inbinary tables can contain very non-homogeneous types ofdata, it can be challenging to efficiently compress the native
stream of bytes in the FITS tables. For this reason, the table
is first decomposed into its component columns, and theneach column of data is compressed separately. This also allows one to choose the most efficient compression algorithm
for each column.
3. Compress each column of data
Each column of data must be compressed with one of thelossless compression algorithms described in Sect. 10.4. If
the table is divided into tiles, then the same compression algorithm must be applied to a given column in every tile. In
the case of variable-length array columns (where the data
are stored in the table heap: see Sect. 7.3.5), each individual
variable length vector must be compressed separately.
4. Store the compressed bytes
The compressed stream of bytes for each column must be
written into the corresponding column in the output table.
The compressed table must have exactly the same number and order of columns as the input table, however thedata type of the columns in the output table will all have avariable-length byte data type, with TFORMn = ’1QB’. Eachrow in the compressed table corresponds to a tile of rows in
the uncompressed table.
In the case of variable-length array columns, the array ofdescriptors that point to each compressed variable-length
array, as well as the array of descriptors from the input
uncompressed table, must also be compressed and written
into the corresponding column in the compressed table. See
Sect. 10.3.6 for more details.

AF
T

The only keywords that must not be copied verbatim fromthe uncompressed table header to the compressed table header
are the mandatory NAXIS1, NAXIS2, PCOUNT, and TFORMn keywords, and the optional CHECKSUM, DATASUM (see Sect. 4.4.2.7),
and THEAP keywords. These keywords must necessarily describe
the contents and structure of the compressed table itself. The
original values of these keywords in the uncompressed tablemust be stored in a new set of reserved keywords in the compressed table header. Note that there is no need to preserve a
copy of the GCOUNT keyword because the value is always equal
to 1 for BINTABLES. The complete set of keywords that have areserved meaning within a tile-compressed binary table are given
below:

10.3.2. Procedure for Table Compression

DR

ZTABLE – [logical; value: ’T’] The value field of this keyword
shall be ’T’ to indicate that the FITS binary table extension
contains a compressed BINTABLE, and that logically thisextension should be interpreted as a tile-compressed binary
table.
ZNAXIS1 – [integer; default: none] The value field of this keyword shall contain an integer that gives the value of the
NAXIS1 keyword in the original uncompressed FITS table
header. This represents the width in bytes of each row in theuncompressed table.
ZNAXIS2 – [integer; default: none] The value field of this keyword shall contain an integer that gives the value of the
NAXIS2 keyword in the original uncompressed FITS table
header. This represents the number of rows in the uncompressed table.
ZPCOUNT – [integer; default: none] The value field of this keyword shall contain an integer that gives the value of the
PCOUNT keyword in the original uncompressed FITS table
header.
ZFORMn – [string; indexed; default: none] The value field of
these keywords shall contain the character string values of
the corresponding TFORMn keywords that defines the data
type of column n in the original uncompressed FITS table.
ZCTYPn – [string; indexed; default: none] The value fieldof these keywords shall contain the character string valuemnemonic name of the algorithm that was used to compress
column n of the table. The only permitted values are given in
Sect. 10.3.5, and the corresponding algorithms are describedin Sect 10.4.
ZTILELEN – [integer; default: none] The value field of thiskeyword shall contain an integer representing the number ofrows of data from the original binary table that are containedin each tile of the compressed table. The number of rows
in the last tile may be less than in the previous tiles. Notethat if the entire table is compressed as a single tile, thenthe compressed table will only contains a single row, and the
ZTILELEN and ZNAXIS2 keywords will have the same value.
48

10.3.3. Compression Directive Keywords

The following compression-directive keywords, if present in theheader of the table to be compressed, are reserved to provide
guidance to the compression software on how the table should becompressed. The compression software should attempt to obey
these directives, but if that is not possible the software may disregard them and use an appropriate alternative. These keywords
are optional, but must be used as specified below.
– FZTILELN – [integer] The value field of this keyword
shall contain an integer that specifies the requested number

49
1. For each VLA in the column:– Read the array from the input table and compress it using
the algorithm specified by ZCTYP for this VLA column.
– Write the resulting bytestream to the heap of the compressed table.
– Store (or append) the descriptors to the compressed
bytestream (which must be 64-bit Q-type) in a temporary
array.
2. Append the VLA descriptors from the uncompressed table(which may be either Q-type or P-type) to the temporary array of VLA descriptors for the compressed table.
3. Compress the combined array of descriptors using GZIP 1,
and write that byte stream into the corresponding VLA column in the output table, so that the compressed array is appended to the heap.

10.3.4. Other Reserved Keywords

When uncompressing a VLA column, two stages of uncompression must be performed in order:AFTof table rows in each tile which are to be compressed as agroup.
– FZALGOR – [string] The value field of this keyword
shall contain a character string giving the mnemonic nameof the algorithm that is requested to be used by default tocompress every column in the table. The permitted values
are given in Sect. 10.3.5.
– FZALGn – [string; indexed] The value fields of these keywords shall contain a character string giving the mnemonicname of the algorithm that is requested to compress columnn of the table. The current allowed values are the same as for
the FZALGOR keyword. The FZALGn keyword takes precedence over FZALGOR in determining which algorithm to use
for a particular column if both keywords are present.

The following keywords are reserved to store a verbatim copyof the value and comment fields for specific keywords in theoriginal uncompressed BINTABLE. These keywords, if present,
should be used to reconstruct an identical copy of the uncompressed BINTABLE, and should not appear in the compressedtable header unless the corresponding keywords were present in
the uncompressed BINTABLE.

DRZTHEAP – [integer; default: none] The value field of this keyword shall contain an integer that gives the value of the
THEAP keyword if present in the original uncompressed FITS
table header.
ZHECKSUM – [string; default: none] The value field of this keyword shall contain a character string that gives the value of
the CHECKSUM keyword (see Sect. 4.4.2.7) in the original uncompressed FITS HDU.
ZDATASUM – [string; default: none] The value field of this keyword shall contain a character that gives the value of the
DATASUM keyword (see Sect. 4.4.2.7) in the original uncompressed FITS HDU.
10.3.5. Supported Compression Algorithms for Tables

The permitted algorithms for compressing BINTABLE columns
are RICE 1, GZIP 1, and GZIP 2 (plus NOCOMPRESS), which
are lossless and are described in Sect. 10.4. Lossy compression
could be allowed in the future once a process is defined to preserve the details of the compression.
10.3.6. Compressing Variable-Length Array Columns

Compression of BINTABLE tiles that contain variable-length array (VLA) columns requires special consideration because thearray values in these columns are not stored directly in the table,
but are instead stored in a data heap which follows the main table(see Sect. 7.3.5). The VLA column in the original, uncompressedtable only contains descriptors, which are composed of two integers that give the size and location of the arrays in the heap.
When uncompressing, these descriptor values will be needed towrite the uncompressed VLAs back into the same location in theheap as in the original uncompressed table. Thus, the following
process must be followed, in order, when compressing a VLA
column within a tile:

1. Uncompress the combined array of descriptors using the
gzip algorithm.
2. For each descriptor to a compressed array:– Read the compressed VLA from the compressed table and uncompress it using the algorithm specified by
ZCTYP for this VLA column.
– Write it to the correct location in the uncompressed table.

10.4. Compression Algorithms

Table 36: Valid mnemonic values for the ZCMPTYPE and ZCTYPn
keywords
Value’RICE 1’’GZIP 1’Sect.
10.4.1
10.4.2’GZIP 2’10.4.2’PLIO 1’’HCOMPRESS 1’’NOCOMPRESS’

10.4.310.4.4Compression Type
Rice algorithm for integer data
Combination of the LZ77 algorithmand Huffman coding, used in Gnu
GZIP
Like ’GZIP 1’, but with reshuffled
pixel values
IRAF PLIO algorithm for integer data
H-compress algorithm for 2-D images
The HDU remains uncompressed

The name of the permitted algorithms for compressing FITS
HDUs, as recorded in the ZCMPTYPE keyword, are listed inTable 36; if other types are later supported, they must be
registered with the IAUFWG to reserve the keyword values.
Keywords for the parameters of supported compression algorithms have also been reserved, and are described with eachalgorithm in the subsections below. If alternative compression
algorithms require keywords beyond those defined below, theymust also be registered with the IAUFWG to reserve the associated keyword names.
10.4.1. Rice compression

When ZCMPTYPE = ’RICE 1’ the Rice algorithm (Rice et al.
1993) shall be used for data (de)compression. When selected,
the keywords in Table 37 should also appear in the header with
one of the values indicated. If these keywords are absent, then49

50
their default values must be used. The Rice algorithm is lossless, but can only be applied to integer-valued arrays. It offersa significant performance advantage over the other compression
techniques (see White et al. 2013).
Table 37: Keyword parameters for Rice compression

10.4.2. GZIP compression+--+--------+-------------------+|16|1513|121|+--+--------+-------------------+| | opcode |data|+--+----------------------------+

AF
T

ValuesKeyword Permitted
Default Meaning
ZNAME1 ’BLOCKSIZE’−
Size of block in pixels
ZVAL1
16, 3232
No. of pixels in a block
ZNAME2 ’BYTEPIX’−
Size of pixel value in bytes
ZVAL2
1, 2, 4, 8
4
No. 8-bit bytes per original
pixel value

12 bits; therefore ’PLIO 1’ must only be used for integer image
types with values between 0 and 224 .
The compressed line lists are stored as variable length arraysof type short integer (16 bits per list element), regardless of themask depth. A line list consists of a series of simple instructions
which are executed in sequence to reconstruct a line of the mask.
Each 16 bit instruction consists of the sign bit (not used), a three
bit opcode, and twelve bits of data, i.e.:DR

When ZCMPTYPE = ’GZIP 1’ the gzip algorithm shall be used
for data (de)compression. There are no algorithm parameters,
so the keywords ZNAMEn and ZVALn should not appear in theheader. The gzip algorithm is used in the free GNU software
compression utility of the same name. It was created by J.L. Gailly and M. Adler, based on the DEFLATE algorithm(Deutsch 1996), which is a combination of LZ77 (Ziv & Lempel1977) and Huffman coding. The unix gzip program accepts an
integer parameter that provides a trade between optimization forspeed (1) and compression ratio (9), which does not affect theformat of the resultant data stream. The selection of this parameter is an implementation detail that is not covered by thisStandard.
When ZCMPTYPE = ’GZIP 2’ the gzip2 algorithm shall be
used for data (de)compression. The gzip2 algorithm is a variation on GZIP 1. There are no algorithm parameters, so the keywords ZNAMEn and ZVALn should not appear in the header. In
this case the bytes in the array of data values are shuffled so thatthey are arranged in order of decreasing significance before being compressed. For example, a 5-element contiguous array of
2-byte (16-bit) integer values, with an original big-endian byteorder of:A 1 A 2 B 1 B 2 C 1 C 2 D1 D2 E 1 E 2
will have the following byte order after shuffling:
A 1 B 1 C 1 D1 E 1 A 2 B 2 C 2 D2 E 2The significance of the data depends upon the instruction.
In order to reconstruct a mask line, the application executing
these instructions is required to keep track of two values, thecurrent high value and the current position in the output line.
The detailed operation of each instruction is given in Table 38.
Table 38: PLIO Instructions

Instr.
ZN
HN

Opcode
00
04

PN

05

SH

05

IH,DH

02,03

IS,DS

06,07

MeaningZero the next N output pixels.
Set the next N output pixels to the current
high value.
Zero the next N-1 output pixels, and set pixel
N to the current high value.
Set the high value (absolute rather than incremental), taking the high 15 bits from thenext word in the instruction stream, and thelow 12 bits from the current data value.
Increment (IH) or decrement (DH) the current high value by the data value. The current position is not affected.
Increment (IS) or decrement (DS) the current high value by the data value, and step,i.e., output one high value.

The high value must be set to 1 at the beginning of a line,
hence the IH,DH and IS,DS instructions are not normally needed
for Boolean masks.
10.4.4. H-Compress algorithm

where A1 , B1 , C1 , D1 , and E1 are the most significant bytes fromeach of the integer values. Byte shuffling shall only be performed for integer or floating-point numeric data types; logical,
bit, and character types must not be shuffled.

When ZCMPTYPE = ’HCOMPRESS 1’ the H-compress algorithm
shall be used for data (de)compression. The algorithm was described by White (1992), and can be applied only to images withtwo dimensions. Briefly, the compression method is to apply, inorder:

10.4.3. IRAF/PLIO compression

1. a wavelet transform called the H-transform (a Haar transform generalized to two dimensions), followed by
2. a quantization that discards noise in the image while retaining the signal on all scales, followed by
3. a quadtree coding of the quantized coefficients.

When ZCMPTYPE = ’PLIO 1’ the IRAF PLIO algorithm
shall be used for data (de)compression. There are no algorithm
parameters, so the keywords ZNAMEn and ZVALn should not appear in the header. The PLIO algorithm was developed to store
integer-valued image masks in a compressed form. The compression algorithm used is based on run-length encoding, withthe ability to dynamically follow level changes in the image,in principle allowing a 16-bit encoding to be used regardless of
the image depth. However, this algorithm has only been implemented in a way that supports image depths of no more than50

The H-transform is a two-dimensional generalization of theHaar transform. The H-transform is calculated for an image ofsize 2N × 2N as follows:
1. Divide the image up into blocks of 2 × 2 pixels. Call the four
pixel values in a block a00 , a10 , a01 , and a11 .

51

AF
T

2. For each block compute four coefficients:
h0 = (a11 + a10 + a01 + a00 )/(SCALE ∗ σ)
h x = (a11 + a10 − a01 − a00 )/(SCALE ∗ σ)hy = (a11 − a10 + a01 − a00 )/(SCALE ∗ σ)
hc = (a11 − a10 − a01 + a00 )/(SCALE ∗ σ)where SCALE is an algorithm parameter defined below, andσ characterizes the RMS noise in the uncompressed image.
3. Construct a 2N−1 × 2N−1 image from the h0 values for each2 × 2 block. Divide that image up into 2 × 2 blocks and repeat
the above calculation. Repeat this process N times, reducing
the image in size by a factor of 2 at each step, until only one
h0 value remains.

DR

This calculation can be easily inverted to recover the original image from its transform. The transform is exactly reversible using
integer arithmetic. Consequently, the program can be used for
either lossy or lossless compression, with no special approachneeded for the lossless case.
Noise in the original image is still present in the H-transform,
however. To compress noisy images, each coefficient can be divided by SCALE ∗ σ, where SCALE ∼ 1 is chosen according to
how much loss is acceptable. This reduces the noise in the transform to 0.5/SCALE, so that large portions of the transform arezero (or nearly zero) and the transform is highly compressible.
There is one user-defined parameter associated with the HCompress algorithm: a scale factor to the RMS noise in theimage that determines the amount of compression that can beachieved. It is not necessary to know what scale factor was used
when compressing the image in order to uncompress it, but it
is still useful to record it. The keywords in Table 39 should berecorded in the header for this purpose.
Table 39: Keyword parameters for H-compression

ValuesKeyword Permitted
Default Meaning
ZNAME1 ’SCALE’−
Scale factor
ZVAL1
0.0 or larger
0.0
Scaling of the RMS noise; 0.0
yields lossless compression

Scale Factor – The floating-point scale parameter determines
the amount of compression; higher values result in higher
compression but with greater loss of information. SCALE =0.0 is a special case that yields lossless compression, i.e. thedecompressed image has exactly the same pixel values as
the original image. SCALE > 0.0 leads to lossy compression,
where SCALE determines how much of the noise is discarded.

51

52

Appendix A: Syntax of keyword records
This Appendix is not part of the FITS standard but is included
for convenient reference.

[X]
X...
‘B’
‘A’–‘Z’
\0xnn
{...}

means ‘is defined to be’means one of X or Y
(no ordering relation is implied)means that X is optional
means X is repeated one or more times
means the ASCII character Bmeans one of the ASCII characters A
through Z in the ASCII collating
sequence, as shown in Appendix Dmeans the ASCII character associatedwith 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 keyword records, as well as for long-string
keywords spanning more than one keyword records).
FITS keyword :=single record keyword |long string keyword
single record keyword :=FITS keyword record

DR

FITS keyword record :=FITS commentary keyword record |FITS value keyword record

FITS commentary keyword record :=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 keyword record must be exactly equal
to 80.}
FITS value keyword record :=keyword field value indicator [space...] [value][space...] [comment]{Constraint: The total number of characters in a
FITS value keyword record must be exactly equal to 80.}
{Comment: If the value field is not present, the value of the FITS
keyword is not defined.}long string kewyord :=initial kwd record [continuation kwd record...]last continuation record{Comment: the value of a long string keyword is reconstructedconcatenating the partial string values of the initial kwd recordand of any continuation kwd records in the order they occur, andthe character string value of the last continuation record.}52

continuation kwd record :=CONTINUE keyword [space...][partial string value] [space...] [comment]{Constraint: The total number of characters in a continuation kwd record must be exactly equal to 80.}

AF
T

:=
X|Y

initial kwd record :=keyword field value indicator [space...][partial string value] [space...] [comment]{Constraint: The total number of characters in an initial kwd record must be exactly equal to 80.}

last continuation record :=CONTINUE keyword [space...][character string value] [space...] [comment]{Constraint: The total number of characterslast continuation record must be exactly equal to 80.}inakeyword field :=[keyword char...] [space...]{Constraint: The total number of characters in the keyword fieldmust 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
CONTINUE keyword :=‘C’ ‘O’ ‘N’ ‘T’ ‘I’ ‘N’ ‘U’ ‘E’ spacevalue 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 | complex floating value

53
character string value :=begin quote [string text char...] end quote{Constraint: The begin quote and end quote are not part of thecharacter 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.}

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

quote :=
\0x27
ampersand :=‘&’Appendix B: Suggested time scale specification
The content of this Appendix has been superseded by Section 9of the formal Standard, which derives from Rots et al. (2015).

DR

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’

complex integer value :=‘(’ [space...] real integer part [space...] ‘,’ [space...]imaginary integer part [space...] ‘)’AFTpartial string value :=begin quote [string text char...] ampersand end quote{Constraint: The begin quote, end quote and ampersand are notpart of the character string value but only serve respectively as
delimiters or continuation indicator. }exponent letter :=‘E’ | ‘D’

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

53

54

Appendix C: Summary of keywords
This Appendix is not part of the FITS standard, but is included for convenient reference.
All of the mandatory and reserved keywords that are defined in the standard, except for the reserved WCS keywords that are
discussed separately in Sect. 8, are listed in Tables C.1, C.2, and C.3. An alphabetized list of these keywords and their definitions isavailable online: http://heasarc.gsfc.nasa.gov/docs/fcg/standard_dict.html.
Table C.1: Mandatory FITS keywords for the structures described in this document.
Conforming
extension
XTENSION
BITPIXNAXISNAXISn4
PCOUNTGCOUNT
END

Image
extension
XTENSION1
BITPIXNAXISNAXISn4
PCOUNT = 0
GCOUNT = 1
END

ASCII table
extension
XTENSION2
BITPIX = 8
NAXIS
= 2
NAXIS1NAXIS2PCOUNT = 0
GCOUNT = 1
TFIELDS
TFORMn5
TBCOLn5
END

Binary table
extension
XTENSION3
BITPIX = 8
NAXIS
= 2
NAXIS1NAXIS2PCOUNTGCOUNT = 1
TFIELDS
TFORMn5
END

Compressed
images6
ZIMAGE =T
ZBITPIXZNAXISZNAXISnZCMPTYPE

Compressedtables6
ZTABLE =T
ZNAXIS1ZNAXIS2ZPCOUNTZFORMnZCTYPnZTILELEN

AF
T

PrimaryHDU
SIMPLEBITPIXNAXISNAXISn4END

Random groups
records
SIMPLEBITPIXNAXISNAXIS1 = 0
NAXISn4
GROUPS = T
PCOUNTGCOUNTEND(1)
XTENSION= 'IMAGE' for the image extension. (2) XTENSION= 'TABLE' for the ASCII table extension. (3) XTENSION= 'BINTABLE' forthe binary table extension. (4) Runs from 1 through the value of NAXIS. (5) Runs from 1 through the value of TFIELDS. (6) required in addition to the
mandatory keywords for binary tables.

Table C.2: Reserved FITS keywords for the structures described in this document.

(1)
(3)

Array2HDUs
BSCALE
BZERO
BUNIT
BLANK
DATAMAXDATAMIN

ASCII table
extension
TSCALnTZEROnTNULLnTTYPEnTUNITnTDISPnTDMAXnTDMINnTLMAXnTLMINnBinary table
extension
TSCALnTZEROnTNULLnTTYPEnTUNITnTDISPn
TDIMn
THEAP
TDMAXnTDMINnTLMAXnTLMINn

DR

All1
HDUs
DATE
EXTNAME
DATE-OBS EXTVERORIGIN
EXTLEVELAUTHOR
EQUINOXREFERENC EPOCH3
COMMENTBLOCKED3
HISTORY
EXTEND4TELESCOPOBJECT
INSTRUME
OBSERVERCONTINUEINHERIT 5CHECKSUMDATASUM

Compressed
imagesZTILEnZNAMEiZVALi
ZMASKCMPZQUANTIZ
ZDITHER0ZSIMPLEZEXTENDZBLOCKEDZTENSIONZPCOUNTZGCOUNTZHECKSUMZDATASUM

CompressedtablesFZTILELNFZALGORFZALGnZTHEAPZHECKSUMZDATASUM

These keywords are further categorized in Table C.3. (2) Primary HDU, image extension, user-defined HDUs with same array structure.
Deprecated. (4) Only permitted in the primary HDU. (5) Only permitted in extension HDUs, immediately following the mandatory keywords.

Table C.3: General reserved FITS keywords described in this document.
Production
DATE
ORIGINBLOCKED1(1)

Random groups
records
PTYPEnPSCALnPZEROnDeprecated.

54

Bibliographic
AUTHOR
REFERENC

Commentary
COMMENTHISTORY

Observation
DATE-OBSTELESCOP
INSTRUME
OBSERVEROBJECT
EQUINOXEPOCH1

55
Table D.1: ASCII character set.

1

Not ASCII Text

hex
20
21
22
23
24
25
26
27
28
29
2A
2B
2C
2D
2E
2F
30
31
32
33
34
35
36
37
38
39
3A
3B
3C
3D
3E
3F

char
SP
!
"
#
$
%
&
'
(
)
*
+
,
.
/
0
1
2
3
4
5
6
7
8
9
:
;
<
=
>
?

dec
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95

ASCII text
hex char
40
@
41
A
42
B
43
C
44
D
45
E
46
F
47
G
48
H
49
I
4A
J
4B
K
4C
L
4D
M
4E
N
4F
O
50
P
51
Q
52
R
53
S
54
T
55
U
56
V
57
W
58
X
59
Y
5A
Z
5B
[
5C
\
5D
]
5E
ˆ
5F
_

dec
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127

hex
60
61
62
63
64
65
66
67
68
69
6A
6B
6C
6D
6E
6F
70
71
72
73
74
75
76
77
78
79
7A
7B
7C
7D
7E
7F

AF
T

dec
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

DR

ASCII control
dec hex
char
0
00
NUL
1
01
SOH
2
02
STX
3
03
ETX
4
04
EOT
5
05
ENQ
6
06
ACK
7
07
BEL
8
08
BS
9
09
HT
10
0A
LF
11
0B
VT
12
0C
FF
13
0D
CR
14
0E
SO
15
0F
SI
16
10
DLE
17
11
DC1
18
12
DC2
19
13
DC3
20
14
DC4
21
15
NAK
22
16
SYN
23
17
ETB
24
18
CAN
25
19
EM
26
1A
SUB
27
1B
ESC
28
1C
FS
29
1D
GS
30
1E
RS
31
1F
US

char
`
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
z
{
|
}
˜
DEL1

Appendix D: ASCII text

This appendix is not part of the FITS standard; the material in it is based on the ANSI standard for ASCII (ANSI 1977) and isincluded here for informational purposes.)
In Table D.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 the restricted set of
ASCII text characters.

Appendix E: 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) andprovided for informational purposes. It is not intended to be a comprehensive description of the IEEE formats; readers should referto the IEEE standard.)
FITS recognizes all IEEE basic formats, including the special values.
E.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 + bias
3. Fraction f = •b1 b2 · · · b p−1
The range of the unbiased exponent E shall include every integer between two values Emin and Emax , inclusive, and also two otherreserved values Emin − 1 to encode ±0 and denormalized numbers, and Emax +1 to encode ±∞ and NaNs. The foregoing parameters
are given in Table E.1. Each nonzero numerical value has just one encoding. The fields are interpreted as follows:55

56
Table E.1: Summary of format parameters.
Parameter
Single
24
+127
−126
+127
8
32

Doubleextended≥ 64≥ +16383≤ −16382
unspecified
≥ 15
≥ 79

AF
T

p
Emax
Emin
Exponent bias
Exponent width in bits
Format width in bits

FormatSingleextended Double≥ 32
53≥ +1023+1023≤ −1022−1022
unspecified
+1023
≥ 11
11
≥ 43
64

Fig. E.1: Single Format. msb means most significant bit, lsb means least significant bit
1

8

23

s

e

f

msb

lsb

msb

....widths

lsb....order

Fig. E.2: Double Format. msb means most significant bit, lsb means least significant bit
1

11

52

s

e

f

msb

E.1.1. Single

lsb

msb

....widths

lsb....order

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

E.1.2. DoubleDR

1. If e = 255 and f , 0, then v is NaN regardless of s
2. If e = 255 and f = 0, then v = (−1) s ∞3. If 0 < e < 255, then v = (−1) s 2e−127 (1 • f )4. If e = 0 and f , 0, then v = (−1) s 2e−126 (0 • f ) (denormalized numbers)
5. If e = 0 and f = 0, then v = (−1) s 0 (zero)

A 64-bit double format number X is divided as shown in Fig. E.2. The value v of X is inferred from its constituent fields thus
1. If e = 2047 and f , 0, then v is NaN regardless of s
2. If e = 2047 and f = 0, then v = (−1) s∞
3. If 0 < e < 2047, then v = (−1) s2e−1023 (1 • f )4. If e = 0 and f , 0, then v = (−1) s 2e−1022 (0 • f ) (denormalized numbers)
5. If e = 0 and f = 0, then v = (−1) s 0 (zero)E.2. Byte patterns

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

56

57
Table E.2: IEEE floating-point formats.
IEEE value+0
denormalized
positive underflow
positive numbers

Single precision
00000000
00000001
to
007FFFFF
00800000
00800001
to
7F7FFFFE
7F7FFFFF
7F800000
7F800001
to
7FFFFFFF
80000000
80000001
to807FFFFF
80800000
80800001
toFF7FFFFE
FF7FFFFF
FF800000
FF800001
to
FFFFFFFF

AF
T

positive overflow+∞
NaN1

Double precision
0000000000000000
0000000000000001
to000FFFFFFFFFFFFF
0010000000000000
0010000000000001
to
7FEFFFFFFFFFFFFE
7FEFFFFFFFFFFFFF
7FF0000000000000
7FF0000000000001
to
7FFFFFFFFFFFFFFF
8000000000000000
8000000000000001
to800FFFFFFFFFFFFF
8010000000000000
8010000000000001
to
FFEFFFFFFFFFFFFE
FFEFFFFFFFFFFFFF
FFF0000000000000
FFF0000000000001
to
FFFFFFFFFFFFFFFF−0
negativedenormalized

negative underflow
negative numbers
negative overflow
−∞
NaN1

DR

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

57

58

Appendix F: Reserved extension type names

F.3. Other suggested extension names

This Appendix is not part of the FITS standard, but is included for informational purposes. It describes the extension
type names registered as of the date this standard was issued.)
A current list is available from the FITS Support Office web site
at http://fits.gsfc.nasa.gov.

There have been occasional suggestions for other extension
names that might be used for other specific purposes. These include a COMPRESS extension for storing compressed images, a
FITS extension for hierarchically embedding entire FITS files
within other FITS files, and a FILEMARK extension for representing the equivalent of an end-of-file mark on magnetic tape
media. None of these extension types have been implemented orused in practice, therefore these names are not reserved. These
extension names (or any other extension name not specificallymentioned in the previous sections of this appendix) should not
be used in any FITS file without first registering the name with
the IAU FITS Working Group.

F.1. Standard extensions

AF
T

These three extension types have been approved by the
IAUFWG and are defined in Sect. 7 of this standard document
as well as in the indicated Astronomy and Astrophysics journal
articles.

DR– 'IMAGE' – This extension type provides a means of storing a multi-dimensional array similar to that of the FITS primary header and data unit. Approved as a standard extension
in 1994 (Ponz et al. 1994).
– 'TABLE' – This ASCII table extension type contains
rows and columns of data entries expressed as ASCII characters. Approved as a standard extension in 1988 (Harten et al.
1988).
– 'BINTABLE' – This binary table extension type provides
a more flexible and efficient means of storing data structures than is provided by the TABLE extension type. The
table rows can contain a mixture of numerical, logical andcharacter data entries. In addition, each entry is allowed to
be a single dimensioned array. Numeric data are kept inbinary formats. Approved as a standard extension in 1994
(Cotton et al. 1995).
F.2. Conforming extensions

These conventions meet the requirements for a conforming extension as defined in in Sect. 3.4.1 of this standard, however they
have not been formally approved or endorsed by the IAUFWG.

– 'IUEIMAGE' – This name was given to the prototype of
the IMAGE extension type and was primarily used in the
IUE project data archive from approximately 1992 to 1994.
Except for the name, the format is identical to the IMAGE
extension.
– 'A3DTABLE' – This name was given to the prototype of
the BINTABLE extension type and was primarily used in
the AIPS data processing system developed at NRAO fromabout 1987 until it was replaced by BINTABLE in the early
1990s. The format is defined in the ‘Going AIPS’ manual(Cotton et al. 1990), Chapter 14. It is very similar to the
BINTABLE type except that it does not support the variablelength array convention.
– 'FOREIGN ' – This extension type is used to put a FITS
wrapper about an arbitrary file, allowing a file or tree of files
to be wrapped up in FITS and later restored to disk. A fulldescription of this extension type is given in the Registry of
FITS conventions on the FITS Support Office web site.
– 'DUMP' – This extension type can be used to store a
stream of binary data values. The only known use of this extension type is to record telemetry header packets for datafrom the Hinode mission. The more general FOREIGN extension type could also be used to store this type of data.
58

Appendix G: MIME types

This Appendix is not part of the FITS standard, but is included
for informational purposes.
RFC 4047 (Allen & Wells 2005) describes the registrationof the Multipurpose Internet Mail Extensions (MIME) sub-types‘application/fits’ and ‘image/fits’ to be used by the international astronomical community for the interchange of FITS
files. The MIME type serves as a electronic tag or label that istransmitted along with the FITS file that tells the receiving application what type of file is being transmitted. The remainder ofthis appendix has been extracted verbatim from the RFC 4047
document.
The general nature of the full FITS standard requires the useof the media type ‘application/fits’. Nevertheless, the principal intent for a great many FITS files is to convey a single
data array in the primary HDU, and such arrays are very often 2-dimensional images. Several common image viewing applications already display single-HDU FITS files, and the prototypes for virtual observatory projects specify that data provided by web services be conveyed by the data array in the primary HDU. These uses justify the registration of a second media type, namely ‘image/fits’, for files which use the subsetof the standard described by the original FITS standard paper.
The MIME type ‘image/fits’ may be used to describe FITS
primary HDUs that have other than two dimensions, however it
is expected that most files described as ‘image/fits’ will have
two-dimensional (NAXIS = 2) primary HDUs.
G.1. MIME type ‘application/fits’

A
FITS
file
described withthemedia type‘application/fits’ should conform to the publishedstandards for FITS files as determined by convention andagreement within the international FITS community. No otherconstraints are placed on the content of a file described as‘application/fits’.
A FITS file described with the media type‘application/fits’ may have an arbitrary number ofconforming extension HDUs that follow its mandatory primaryheader and data unit. The extension HDUs may be one of
the standard types (IMAGE, TABLE, and BINTABLE) or any
other type that satisfies the ‘Requirements for Conforming
Extensions’ (Sect. 3.4.1). The primary HDU or any IMAGE
extension may contain zero to 999 dimensions with zero or
more pixels along each dimension.

59
The primary HDU may use the random groups convention,in which the dimension of the first axis is zero and the keywords
GROUPS, PCOUNT and GCOUNT appear in the header. NAXIS1 =0 and GROUPS = T is the signature of random groups; see Sect.
6.
G.1.1. Recommendations for application writers

AFT

An application intended to handle ‘application/fits’ shouldbe able to provide a user with a manifest of all of the HDUs thatare present in the file and with all of the keyword/value pairs
from each of the HDUs.
An application intended to handle ‘application/fits’
should be prepared to encounter extension HDUs that containeither ASCII or binary tables, and to provide a user with accessto their elements.
An application which can modify FITS files or retrieve FITS
files from an external service should be capable of writing such
files to a local storage medium.
Complete interpretation of the meaning and intended use of
the data in each of the HDUs typically requires the use of heuristics that attempt to ascertain which local conventions were usedby the author of the FITS file.
As examples, files with media type ‘application/fits’
might contain any of the following contents:

non-standard metadata pertaining to the image in the primary
HDU in the forms of keywords and tables.
A FITS file described with the media type ‘image/fits’
should be principally intended to communicate the single dataarray in the primary HDU. This means that ‘image/fits’
should not be applied to FITS files containing multi-exposureframe mosaic images. Also, random groups files must be described as ‘application/fits’ and not as ‘image/fits’.
A FITS file described with the media type ‘image/fits’
is also valid as a file of media type ‘application/fits’. The
choice of classification depends on the context and intended usage.

DR– An empty primary HDU (containing zero data elements) followed by a table HDU that contains a catalog of celestial
objects.
– An empty primary HDU followed by a table HDU that encodes a series of time-tagged photon events from an exposure using an X-ray detector.
– An empty primary HDU followed by a series of IMAGE
HDUs containing data from an exposure taken by a mosaic
of CCD detectors.
– An empty primary HDU followed by a series of table HDUs
that contain a snapshot of the state of a relational database.
– A primary HDU containing a single image along with keyword/value pairs of metadata.
– A primary HDU with NAXIS1 = 0 and GROUPS = T followed by random groups data records of complex fringe visibilities.
G.2. MIME type ‘image/fits’

A FITS file described with the media type ‘image/fits’
should have a primary HDU with positive integer values for
the NAXIS and NAXISn keywords, and hence should containat least one pixel. Files with 4 or more non-degenerate axes
(NAXISn > 1) should be described as ‘application/fits’, notas ‘image/fits’. (In rare cases it may be appropriate to describe a NULL image – a dataless container for FITS keywords,
with NAXIS = 0 or NAXISn = 0 – or an image with 4+ nondegenerate axes as ‘image/fits’ but this usage is discouraged
because such files may confuse simple image viewer applications.)
FITS files declared as ‘image/fits’ may also have one
or more conforming extension HDUs following their primary
HDUs. These extension HDUs may contain standard, non-linear,world coordinate system (WCS) information in the form of tables or images. The extension HDUs may also contain other,

G.2.1. Recommendations for application writers

An application that is intended to handle ‘image/fits’ shouldbe able to provide a user with a manifest of all of the HDUs thatare present in the file and with all of the keyword/value pairs
from each of the HDUs. An application writer may choose toignore HDUs beyond the primary HDU, but even in this casethe application should be able to present the user with the keyword/value pairs from the primary HDU.
Note that an application intended to render ‘image/fits’
for viewing by a user has significantly more responsibility
than an application intended to handle, e.g., ‘image/tiff’ or‘image/gif’. FITS data arrays contain elements which typically represent the values of a physical quantity at some coordinate location. Consequently they need not contain any pixel rendering information in the form of transfer functions, and there
is no mechanism for color look-up tables. An application should
provide this functionality, either statically using a more or lesssophisticated algorithm, or interactively allowing a user various
degrees of choice.
Furthermore, the elements in a FITS data array may be integers or floating-point numbers. The dynamic range of the dataarray values may exceed that of the display medium and the eye,and their distribution may be highly nonuniform. Logarithmic,
square-root, and quadratic transfer functions along with histogram equalization techniques have proved helpful for rendering FITS data arrays. Some elements of the array may
have values which indicate that their data are undefined or invalid; these should be rendered distinctly. Via WCS Paper I(Greisen & Calabretta 2002) the standard permits CTYPEn =’COMPLEX’ to assert that a data array contains complex numbers(future revisions might admit other elements such as quaternions
or general tensors).
Three-dimensional data arrays (NAXIS = 3 with NAXIS1,NAXIS2 and NAXIS3 all greater than 1) are of special interest.
Applications intended to handle ‘image/fits’ may default todisplaying the first 2D plane of such an image cube, or they may
default to presenting such an image in a fashion akin to that used
for an animated GIF, or they may present the data cube as a mosaic of ‘thumbnail’ images. The time-lapse movie-looping display technique can be effective in many instances, and application writers should consider offering it for all three-dimensional
arrays.
An ‘image/fits’ primary HDU with NAXIS = 1 is describing a one-dimensional entity such as a spectrum or a timeseries. Applications intended to handle ‘image/fits’ may default to displaying such an image as a graphical plot rather thanas a two-dimensional picture with a single row.
59

60

G.3. File extensions

DR

The FITS standard originated in the era when files were stored
and exchanged via magnetic tape; it does not prescribe any
nomenclature for files on disk. Various sites within the FITS
community have long-established practices where files are presumed to be FITS by context. File extensions used at such sites
commonly indicate content of the file instead of the data format.
In the absence of other information it is reasonably safe topresume that a file name ending in ‘.fits’ is intended to be a
FITS file. Nevertheless, there are other commonly used extensions; e.g., ‘‘.fit’, ‘.fts’, and many others not suitable forlisting in a media type registration.

Appendix H: Past changes or clarifications to theformal definition of FITS

This Appendix is not part of the FITS standard, but is included
for informational purposes.
H.1. Differences between the requirements in this standard
and the requirements in the original FITS papers.

1. Sect. 4.1.2: The original FITS definition paper (Wells et al.
1981) disallows lower case letters in the keyword name, butdoes not specify what other characters may or may not appear in the name.
2. Sect. 4.1.2: The slash between the value and comment is‘recommended’ in the original paper (Wells et al. 1981)
whereas the standard requires that it be present, which is consistent with the prescription of Fortran list-directed input.
3. Sect. 4.2: The original paper (Wells et al. 1981) speculated
that FITS would eventually support the full range of flexibility that is allowed by Fortran list-directed input, including dimensioned parameters. The standard restricts the value
field to a single value, not an array.
4. Sect. 4.2.5 and Sect. 4.2.6: The original paper (Wells et al.
1981) defined a fixed format for complex keyword values,
with the real part right justified in bytes 11 through 30 and
the imaginary part right justified in bytes 31 through 50.
There are no known FITS files that use this fixed format.
The standard does not define a fixed format for complex
keyword values. Instead, complex values are represented in60

conformance with the rules for Fortran list-directed input,
namely, with the real and imaginary parts separated by acomma and enclosed in parentheses.
5. Sect. 4.4.1.1 and Sect. 4.4.1.2: The paper that defines generalized extensions (Grosbøl et al. 1988) does not prohibit
the appearance of the SIMPLE keyword in extensions nor the
XTENSION keyword in the primary header.
H.2. List of modification to the FITS standard, version 3

After the IAUFWG officially approved version 3 of the FITS
standard in 2008, the following additional corrections, clarifications, or format modifications have been made to the document.

AF
T

An application that cannot handle an image with dimensionality other than two should gracefully indicate its limitations to
its users when it encounters NAXIS = 1 or NAXIS = 3 cases,
while still providing access to the keyword/value pairs.
FITS files with degenerate axes (i.e., one or more NAXISn =1) may be described as ‘image/fits’, but the first axes should
be non-degenerate (i.e., the degenerate axes should be the highest dimensions). An algorithm designed to render only twodimensional images will be capable of displaying such an NAXIS= 3 or NAXIS = 4 FITS array that has one or two of the axes
consisting of a single pixel, and an application writer should consider coding this capability into the application. Writers of new
applications that generate FITS files intended to be describedas ‘image/fits’ should consider using the WCSAXES keyword(Greisen et al. 2006) to declare the dimensionality of such degenerate axes, so that NAXIS can be used to convey the numberof non-degenerate axes.

1. Two typographical errors in Table 21 (previously Table 8.1)
were corrected. The last 2 lines of the third column should
read ‘LONPOLEa (=PVi 3a)’ and ‘LATPOLEa (=PVi 4a)’,instead of PVi 1a and PVi 2a, respectively. (October 2008)
2. The latex text source document was reformatted to conformto the Astronomy & Astrophysics journal page style (June2010). The visible changes include the following:– The tables, figures, equations, and footnotes are numbered sequentially throughout the entire the document,
instead of sequentially within each chapter.
– The citations use the standard ‘Author (year)’ format instead of being referenced by a sequential number. Also,
the ‘Bibliography’ section at the end of the document has
been replaced by a ‘References’ section in which the citations are listed alphabetically by author.
3. The following minor corrections or clarifications were madeduring the refereeing process after submitting version 3of the FITS standard for publication in the Astronomy &Astrophysics journal (July 2010):– A sentence was added to the end of Sect. 1.2: ‘This
web site also contains the contact information for the
Chairman of the IAUFWG, to whom any questions orcomments regarding this standard should be addressed.’– A ‘Section’ column was added to Table 1 to reference therelevant section of the document.
– The wording of the second sentence in Sect. 4.1.1 wasrevised from ‘Except where specifically stated otherwise
in this standard, keywords may appear in any order.’ to‘Keywords may appear in any order except where specifically stated otherwise in this standard.’– A sentence was added to the end of the ‘Keyword name’
subsection in Sect. 4.1.2: ‘Note that keyword names thatbegin with (or consist solely of) any combination of hyphens, underscores, and digits are legal.’– A footnote to the description of the REFERENC keyword in Sect. 4.4.2 was added: ‘This bibliographic convention (Schmitz 1995) was initially developed for use
within NED (NASA/IPAC Extragalactic Database) and
SIMBAD (operated at CDS, Strasbourg, France).’– In Sect. 7.3.4, the phrase ‘TFORMn format code’ wascorrected to read ‘TDISPn format code’ (in four places).
– The wording in the ‘Expressed as’ column in Table 26 forthe ‘LOG’, ‘GRI’, ‘GRA’, and ‘TAB’ spectral algorithm
codes was clarified.
– In Table C.2 the EXTNAME, EXTVER, and EXTLEVEL keywords were moved under the ‘All HDUs’ column because they are now allowed in the primary array header.

61– The last paragraph of Sect. 4.1.2.3 was corrected to statethat the ASCII text characters have hexadecimal values
20 through 7E, not 41 through 7E.
H.3. List of modifications to the latest FITS standard

AFT

1. The representation of time coordinates has been incorporated by reference from Rots et al. (2015) and is summarized in Sect. 9. Cross-references have been inserted in preexisting sections of the Standard (namely in Sect. 4.2.7,
4.3, 4.4.2.1, 4.4.2.2 and 5.4, as well as in various placesof Sect. 8, like 8.3 and 8.4.1). New keywords are listed
in a rearranged Table 22. Contextually an erratum was applied in Sect. 8.4.1: keywords OBSGEO-[XYZ] were incorrectly marked as OBSGEO-[XYZ]a; the TAI-UTC differencein Table 30 was updated with respect to Rots et al. (2015)
taking into account the latest leap second; the possibility of
introducing more sources for the solar system ephemerides
was re-worded (at the end of Sect.9.2.5 and in Table 31).
2. The continued string keywords described in Sect. 4.2.1.2
were originally introduced as a FITS convention since 1994,
and registered in 2007. The text of the original convention
is reported at http://fits.gsfc.nasa.gov/registry/
continue_keyword.html. The differences with this standard concern:– The omission of some additional implementation guidelines.
– The omission of a discussion on alternate algorithms andrelevant additional references.
6. The table keywords described in Sect. 7.2.2 and 7.3.2 wereoriginally introduced as a FITS convention since 1993,
and registered in 2006. The text of the original convention
is reported at http://fits.gsfc.nasa.gov/registry/colminmax.html. The differences with this standard concern:– The exclusion of undefined or IEEE special values when
computing maximum and minimum is now mandatory
while it was optional.
– The original text included the possibility of using the fact
TDMINn were greater than TDMAXn (or TLMINn greaterthan TLMAXn) as an indication the values were undefined.
This clause has been removed– The original text contained usage examples and additional minor explanatory details.
7. The Green Bank convention, mentioned in Sect. 8.2 and described in Appendix L, has been in use since 1989, andwas registered in 2010. The text of the registered convention
is reported at http://fits.gsfc.nasa.gov/registry/greenbank/greenbank.pdf and contains some additional
details about the history of the convention.
8. The conventions for compressed data described in Sect. 10.
were originally introduced as a couple of FITS conventions registered in 2007 and 2013. The text of the original conventions is reported at http://fits.gsfc.nasa.
gov/registry/tilecompression.html for compressed
images and at http://fits.gsfc.nasa.gov/registry/
tiletablecompression.html for compressed binary tables. The differences with this standard concern:– In Sect. 10.3.3 the original text for FZALGn mentioned
the possibility that, ‘If the column cannot be compressedwith the requested algorithm (e.g., if it has an inappropriate data type), then a default compression algorithm will
be used instead.’ But there is no default algorithm. Thisis irrelevant for the Standard.
– In Sect. 10.4 the alias ’RICE ONE’ is not adopted in theStandard as a synonym for ’RICE 1’.
– In Sect. 10.4.3 a sentence was left out about requiring
additional instructions in PLIO to make it work for morethen 212 bits, since we aren’t allowing this possibility in
the Standard.
– In Sect. 10.4.4 the reference to a ‘smoothing flag’ wasdropped.
– Also in Sect. 10.4.4 the scale factor is now floating point,
while it was originally integer.
– In Table 36 (and Sect. 10.3.5) the NOCOMPRESS algorithm
is explicitly mentioned.

DR– In the convention, the LONGSTRN keyword was used tosignal the possible presence of long strings in the HDU.
The use of this keyword is no longer required or recommended.
– Usage of the convention was not recommended for reserved or mandatory keywords. Now it is explicitly forbidden unless keywords are explicitly declared longstring.
– To avoid ambiguities in the application of the previous
clause, the declaration of string keywords in sections 8,
9 and 10 has been reset from the generic ‘character’ to‘string’.
– It is also explicitly clarified there is no limit to the number of continuation records.
– The description of continued comment field is new.

3. The blank header space convention described in Sect. 4.4.2.4
was used since 1996, and registered in 2014. The text ofthe original convention is reported at http://fits.gsfc.
nasa.gov/registry/headerspace.html. It included a
recommendation about using the convention in a controlledenvironment, which does not appear in this standard.
4. The INHERIT keyword described in Sect. 4.4.2.6 wasoriginally introduced as a FITS convention in 1995, andregistered in 2007. The text of the original convention
is reported at http://fits.gsfc.nasa.gov/registry/
inherit.html. See also references and practical considerations therein. The differences with the present document
concern a more precise RFC-2219 compliant wording in acouple of sentences in Appendix K.
5. The checksum keywords described in Sect. 4.4.2.7 wereoriginally introduced as a FITS convention since 1994,
and registered in 2007. The text of the original convention
is reported at http://fits.gsfc.nasa.gov/registry/
checksum.html. The differences with this standard concern:

Appendix I: Random Number Generator
This Appendix is not part of the FITS standard, but is included
for informational purposes.
The portable random number generator algorithm below isfrom Park & Miller (1988). This algorithm repeatedly evaluates
the function
seed = (a ∗ seed) mod m61

62
where the values of a and m are shown below, but it is implemented in a way to avoid integer overflow problems.
int random_generator(void) {int ii;double a = 16807.0;
double m = 2147483647.0;
double temp, seed;float rand_value[10000];

AF
T/* initialize an array of random numbers *//* initialize the random numbers */seed = 1;
for (ii = 0; ii < N_RANDOM; ii++) {temp = a * seed;
seed = temp -m * ((int) (temp / m) );/* divide by m for value between 0 and 1 */rand_value[ii] = seed / m;}}

If implemented correctly, the 10 000th value of seed will
equal 1 043 618 065.

Appendix J: CHECKSUM Implementation Guidelines

DR

This Appendix is not part of the FITS standard, but is included
for informational purposes.
J.1. Recommended CHECKSUM Keyword Implementation

The recommended CHECKSUM keyword algorithm described here
generates a 16-character ASCII string that forces the 32-bit 1’scomplement checksum accumulated over the entire FITS HDU
to equal negative 0 (all 32 bits equal to 1). In addition, this string
will only contain alphanumeric characters within the ranges 0–9,
A–Z, and a–z to promote human readability and transcription.
If the present algorithm is used, the CHECKSUM keyword value
must be expressed in fixed format, with the starting single quotecharacter in column 11 and the ending single quote characterin column 28 of the FITS keyword record, because the relative
placement of the value string within the keyword record affects
the computed HDU checksum. The steps in the algorithm are as
follows:

1. Write the CHECKSUM keyword into the HDU header
with an initial value consisting of 16 ASCII zeros(’0000000000000000’) where the first single quote character is in column 11 of the FITS keyword record. This specificinitialization string is required by the encoding algorithm described in Sect. J.2 The final comment field of the keyword,
if any, must also be written at this time. It is recommended
that the current date and time be recorded in the comment
field to document when the checksum was computed.
2. Accumulate the 32-bit 1’s complement checksum over the
FITS logical records that make up the HDU header in thesame manner as was done for the data records by interpreting each 2880-byte logical record as 720 32-bit unsigned integers.
62

3. Calculate the checksum for the entire HDU by adding (using 1’s complement arithmetic) the checksum accumulated
over the header records to the checksum accumulated overthe data records (i.e., the previously computed DATASUM keyword value).
4. Compute the bit-wise complement of the 32-bit total HDU
checksum value by replacing all 0 bits with 1 and all 1 bitswith 0.
5. Encode the complement of the HDU checksum into a 16character ASCII string using the algorithm described in Sect.
J.2
6. Replace the initial CHECKSUM keyword value with this 16character encoded string. The checksum for the entire HDU
will now be equal to negative 0.

J.2. Recommended ASCII Encoding Algorithm

The algorithm described here is used to generate an ASCII string
which, when substituted for the value of the CHECKSUM keyword,
will force the checksum for the entire HDU to equal negative 0.
It is based on a fundamental property of 1’s complement arithmetic that the sum of an integer and the negation of that integer(i.e, the bitwise complement formed by replacing all 0 bits with
1s and all 1 bits with 0s) will equal negative 0 (all bits set to1). This principle is applied here by constructing a 16-character
string which, when interpreted as a byte stream of four 32-bit
integers, has a sum that is equal to the complement of the sum
accumulated over the rest of the HDU. This algorithm also ensures that the 16 bytes that make up the four integers all havevalues that correspond to ASCII alpha-numeric characters in therange 0–9, A–Z, and a–z.
1. Begin with the 1’s complement (replace 0s with 1s and 1s
with 0s) of the 32-bit checksum accumulated over all the
FITS records in the HDU after first initializing the CHECKSUM
keyword with a fixed-format string consisting of 16 ASCII
zeros (’0000000000000000’).
2. Interpret this complemented 32-bit value as a sequence offour unsigned 8-bit integers, A, B, C and D, where A is themost significant byte and D is the least significant. Generatea sequence of four integers, A1, A2, A3, A4, that are all equal
to A divided by 4 (truncated to an integer if necessary). If A
is not evenly divisible by 4, add the remainder to A1. The key
property to note here is that the sum of the four new integers
is equal to the original byte value (e.g., A = A1 + A2 + A3 +A4). Perform a similar operation on B, C, and D, resulting ina total of 16 integer values, 4 from each of the original bytes,
which should be rearranged in the following order:A1 B1 C1 D1 A2 B2 C2 D2 A3 B3 C3 D3 A4 B4 C4 D4Each of these integers represents one of the 16 charactersin the final CHECKSUM keyword value. Note that if this byte
stream is interpreted as 4 32-bit integers, the sum of the integers is equal to the original complemented checksum value.
3. Add 48 (hex 30), which is the value of an ASCII zero character, to each of the 16 integers generated in the previous
step. This places the values in the range of ASCII alphanumeric characters ’0’ (ASCII zero) to ’r’. This offset is effectively subtracted back out of the checksum when the initial
CHECKSUM keyword value string of 16 ASCII 0s is replacedwith the final encoded checksum value.

63
22222222222222222222222222222222222222222222222222222222222222222222222
222222222222222222222222222222222222222222222222222222222222222222222
11
1
1 31
2 32
3 33
4 34
5 35
6 36
7 37
8 38
9 39 1 1
1 1 0 30
1
1 1 : 3a
; 3b
< 3c
= 3d
> 3e
? 3f
@ 40
A 41
B 42
C 43 1 1
11
1
E 45
F 46
G 47
H 48
I 49
J 4a
K 4b
L 4c
M 4d 1 1
1 1 D 441
1 1 N 4e
O 4f
P 50
Q 51
R 52
S 53
T 54
U 55
V 56
W 57 1 1
11
1
Y 59
Z 5a
[ 5b
\ 5c
] 5d
^ 5e
_ 5f
‘ 60
a 61 1 1
1 1 X 58
1
1 1 b 62
c 63
d 64
e 65
f 66
g 67
h 68
i 69
j 6a
k 6b 1 1
11
11
l
6c
m
6d
n
6e
o
6f
p
70
q
71
r
72
11
11
1 1 Figure 1. Only ASCII alpha-numerics are used to encode the checksum — punctuation is excluded. 1 11212222222222222222222222222222222222222222222222222222222222222222222222
2222222222222222222222222222222222222222222222222222222222222222222221 1

c
c
c
c
c

D
E
F
G
H

j
j
j
j
j

j
j
j
j
j

c
c
c
c
c

final string"hcHjjc9ghcEghc9g"

J.3. Encoding Example

DR

To invert the ASCII encoding, cyclically shift the 16 characters in the encoded string one place to the left, subtract thehex 30 offset from each character, and calculate the checksumby interpreting the string as four 32-bit unsigned integers. Thiscan be used, for instance, to read the value of CHECKSUM into thesoftware when verifying or updating a HDU.

This example illustrates the encoding algorithm given in Sect.
J.2 Consider a FITS HDU whose 1’s complement checksum
is 868229149, which is equivalent to hex 33C0201D. This
number was obtained by accumulating the 32-bit checksum
over the header and data records using 1’s complement arithmetic after first initializing the CHECKSUM keyword value to’0000000000000000’. The complement of the accumulated
checksum is 3426738146, which is equivalent to hex CC3FDFE2.
The steps needed to encode this hex value into ASCII are shown
schematically below:
A

Byte
B C

D

A1 B1 C1 D1Preserve byte alignment
A2 B2 C2 D2 A3 B3 C3 D3 A4 B4 C4 D4

CC 3F DF E2 -> 33 0F 37 38+ remainder
0 3 3 2

33 0F 37 38

33 0F 37 38

33 0F 37 38= hex+ 0 offset

33 12 3A 3A
30 30 30 30

33 0F 37 38
30 30 30 30

33 0F 37 38
30 30 30 30

33 0F 37 38
30 30 30 30

= hex
ASCII

63 42 6A 6A
c B j j

63 3F 67 68
c ? g h63 3F 67 68
c ? g h63 3F 67 68
c ? g hinitial values
.

c
c

B
C

j
j

Eliminate punctuation charactersjc ? g hc ? g hc ?
jc > g hc @ g h
c >

g
g

h
h

=
<
;
:
9

g
g
g
g
g

h
h
h
h
h

c
c
c
c
c

A
B
C
D
E

g
g
g
g
g

h
h
h
h
h

c
c
c
c
c

=
<
;
:
9

g
g
g
g
g

h
h
h
h
h

(rotate 1 place to the right)

In this example byte B1 (originally ASCII B) is shifted higher(to ASCII H) to balance byte B2 (originally ASCII ?) being
shifted lower (to ASCII 9). Similarly, bytes B3 and B4 areshifted by opposing amounts. This is possible because the twosequences of ASCII punctuation characters that can occur inencoded checksums are both preceded and followed by longer
sequences of ASCII alphanumeric characters. This operation ispurely for cosmetic reasons to improve readability of the final
string.
This is how these CHECKSUM and DATASUM keywords would
appear in a FITS header (with the recommended time stamp in
the comment field).:

AFT

4. To improve human readability and transcription of the string,eliminate any non-alphanumeric characters by considering
the bytes a pair at a time (e.g., A1 + A2, A3 + A4, B1 +B2, etc.) and repeatedly increment the first byte in the pairby 1 and decrement the 2nd byte by 1 as necessary until theyboth correspond to the ASCII value of the allowed alphanumeric characters 0–9, A–Z, and a–z shown in Figure 1. Notethat this operation conserves the value of the sum of the 4equivalent 32-bit integers, which is required for use in thischecksum application.
5. Cyclically shift all 16 characters in the string one place to theright, rotating the last character (D4) to the beginning of thestring. This rotation compensates for the fact that the fixed
format FITS character string values are not aligned on 4-byte
word boundaries in the FITS file. (The first character of thestring starts in column 12 of the header card image, rather
than column 13).
6. Write this string of 16 characters to the value of the
CHECKSUM keyword, replacing the initial string of 16 ASCII
zeros.

.
.
.
.
final values

DATASUM = '2503531142'
CHECKSUM= 'hcHjjc9ghcEghc9g'//

2015-06-28T18:30:45
2015-06-28T18:30:45

J.4. Incremental Updating of the Checksum

The symmetry of 1’s complement arithmetic also means that after modifying a FITS HDU, the checksum may be incrementally updated using simple arithmetic without accumulating thechecksum for portions of the HDU that have not changed. The
new checksum is equal to the old total checksum plus the checksum accumulated over the modified records, minus the original
checksum for the modified records.
An incremental update provides the mechanism for end-toend checksum verification through any number of intermediate
processing steps. By calculating rather than accumulating the intermediate checksums, the original checksum test is propagatedthrough to the final data file. On the other hand, if a new checksum is accumulated with each change to the HDU, no information is preserved about the HDU’s original state.
The recipe for updating the CHECKSUM keyword following
some change to the HDU is: C ′ = C − m + m′ , where C
and C ′ represent the HDU’s checksum (that is, the complementof the CHECKSUM keyword) before and after the modificationand m and m′ are the corresponding checksums for the modified FITS records or keywords only. Since the CHECKSUM keyword contains the complement of the checksum, the correspondingly complemented form of the recipe is more directly useful:˜C ′ = ˜(C + ˜m + m′ ), where ˜ (tilde) denotes the (1’s) complement operation. See Braden et al. (1988); Mallory & Kullberg(1990); Rijsinghani (1994). Note that the tilde on the right handside of the equation cannot be distributed over the contents ofthe parentheses due to the dual nature of zero in 1’s complement
arithmetic (Rijsinghani 1994).
J.5. Example C Code for Accumulating the Checksum

The 1’s complement checksum is simple and fast to compute. This routine assumes that the input records are a multiple of 4 bytes long (as is the case for FITS logical records),
but it is not difficult to allow for odd length records if necessary. To use this routine, first initialize the CHECKSUM keyword
to ’0000000000000000’ and initialize sum32 = 0, then step
through all the FITS logical records in the FITS HDU.
63

64
for (i=0; i < 16; i++)/* permute the bytes for FITS */ascii[i] = asc[(i+15)%16];

void checksum (unsigned char *buf,/* Input array of bytes to be checksummed *//* (interpret as 4-byte unsigned ints)*/
int length,/* Length of buf array, in bytes*//* (must be multiple of 4)*/
unsigned int *sum32) /* 32-bit checksum*/{/*
Increment the input value of sum32 with the 1's complement sum
accumulated over the input buf array.
*/
unsigned int hi, lo, hicarry, locarry, i;/* fold carry bits from each 16 bit sum into the other sum */hicarry = hi >> 16;
locarry = lo >> 16;
while (hicarry || locarry) {hi = (hi & 0xFFFF) + locarry;lo = (lo & 0xFFFF) + hicarry;
hicarry = hi >> 16;
locarry = lo >> 16;}/* concatenate the full 32-bit value from the 2 halves */*sum32 = (hi << 16) + lo;}

J.6. Example C Code for ASCII Encoding

DR

This routine encodes the complement of the 32-bit HDU checksum value into a 16-character string. The byte alignment of thestring is permuted one place to the right for FITS to left justify
the string value starting in column 12.
unsigned int exclude[13] = {0x3a, 0x3b, 0x3c, 0x3d, 0x3e, 0x3f, 0x40,
0x5b, 0x5c, 0x5d, 0x5e, 0x5f, 0x60 };int offset = 0x30;/* ASCII 0 (zero) */unsigned long mask[4] = { 0xff000000, 0xff0000, 0xff00, 0xff };void char_encode (unsigned int value, /* 1's complement of the checksum*//*
value to be encoded*/char *ascii)/* Output 16-character encoded string */{int byte, quotient, remainder, ch[4], check, i, j, k;char asc[32];for (i=0; i < 4; i++) {/* each byte becomes four */byte = (value & mask[i]) >> ((3 - i) * 8);quotient = byte / 4 + offset;
remainder = byte % 4;
for (j=0; j < 4; j++)ch[j] = quotient;ch[0] += remainder;for (check=1; check;)/* avoid ASCII punctuation */for (check=0, k=0; k < 13; k++)for (j=0; j < 4; j+=2)
if (ch[j]==exclude[k] || ch[j+1]==exclude[k]) {ch[j]++;
ch[j+1]--;check++;}for (j=0; j < 4; j++)asc[4*j+i] = ch[j];}64/* terminate the string */Appendix K: Header inheritance convention
This Appendix is not part of the FITS standard, but is included
for informational purposes.
The reserved boolean INHERIT keyword described in
Sect. 4.4.2.6 is optional, but if present it shall appear in theextension header immediately after the mandatory keywords.
The INHERIT keyword must not appear in the primary header.
Keyword inheritance provides a mechanism to store keywords inthe primary HDU, and have them be shared by one or more extensions in the file. This mechanism minimizes duplication (andmaintenance) of metadata in multi-extension FITS files.
It should only be used in FITS files that have a null primary array (e.g., with NAXIS = 0). to avoid possible confusion
if array-specific keywords (e.g., BSCALE and BZERO) were to be
inherited.
When an application reads an extension header with
INHERIT = T, it should merge the keywords in the current extension with the primary header keywords. The exact merging
mechanism is left up to the application. The mandatory primaryarray keywords (e.g., BITPIX, NAXIS, and NAXISn) and any
COMMENT, HISTORY, and blank keywords in the primary header
must not be inherited. It is assumed also that the table-specifickeywords described in Sect. 7.2 and 7.3, and the table-specific
WCS keywords described in Sect. 8, cannot be inherited since
they will never appear in the primary header. If the same keyword is present in both the primary header and the extension
header, the value in the extension header shall take precedence.
If INHERIT = F in an extension header, the keywords from theprimary header should not be inherited.
An application which merely reads a FITS file is authorized
by INHERIT = T to look in the primary HDU for an expected
keyword not found in the current HDU. However if the application writes out a modified file, it has to be very careful to avoid
unwanted duplication of keywords, and preserve the separationof primary and extension headers. If an application modifies thevalue of an inherited keyword while processing an extension
HDU, then it is recommended to write the modified value ofthat keyword into the extension header, leaving the value of the
keyword in the primary header unchanged. The primary array
keywords should only be modified when the intent is to explicitly change the value that will subsequently be inherited in theextensions.
Also if the FITS file is read in sequentially (e.g., from tape orInternet downloads), the reader would need to cache the primaryheader in case it turns out that a later extension in the file uses
the INHERIT keyword.

AF
T/* Accumulate the sum of the high-order 16 bits and the *//* low-order 16 bits of each 32-bit word, separately. *//* The first byte in each pair is the most significant. *//* This algorithm works on both big and little endian machines.*/hi = (*sum32 >> 16);lo = *sum32 & 0xFFFF;
for (i=0; i < length; i+=4) {hi += ((buf[i]<< 8) + buf[i+1]);
lo += ((buf[i+2] << 8) + buf[i+3]);}

ascii[16] = 0;}/* assign the bytes */Appendix L: Green Bank convention
This Appendix is not part of the FITS standard, but is included
for informational purposes.
The Green Bank convention was developed at a meeting in October 1989 at the US National Radio Astrononomy
Observatory in Green Bank, West Virginia, to discuss the useof FITS for single dish radio astronomy data, and has since been

65
Calabretta, M. R. & Greisen, E. W. 2002, A&A, 395, 1077
Calabretta, M. R. & Roukema, B. F. 2007, MNRAS, 381, 865
Cotton, W. D., Tody, D. B., & Pence, W. D. 1995, A&AS, 113, 159
Cotton, W. D., et al. 1990, Going AIPS: A Programmer’s Guide to the NRAO
Astronomical Image Processing System, Charlottesville: NRAO
Deutsch P. 1996, RFC 1951, Network Working Group; available online:
http://tools.ietf.org/html/rfc1951
Folkner, W. M., Williams, J. G., & Boggs, D. H. 2009, Interplanetary Network
Progress Report 42-178, available online: http://tmo.jpl.nasa.gov/
progress_report/42-178/178C.pdf
Folkner, W. M. et al. 2014, Interplanetary Network Progress Report 42196, available online: http://ipnpr.jpl.nasa.gov/progress_report/
42-196/196C.pdf
Greisen, E. W. & Calabretta, M. R. 2002, A&A, 395, 1061
Greisen, E. W., Calabretta, M. R., Valdes, F. G., & Allen, S. L. 2006, A&A, 446,
747
Greisen, E. W. & Harten, R. H. 1981, A&AS, 44, 371
Grosbøl, P., Harten, R. H., Greisen, E. W., & Wells, D. C. 1988, A&AS, 73, 359
Grosbøl, P. & Wells, D. C. 1994, Blocking of Fixed-block Sequential Media and
Bitstream Devices, http://fits.gsfc.nasa.gov/blocking94.html
Hanisch, R., et al. 2001, A&A, 376, 359
Harten, R. H., Grosbøl, P., Greisen, E. W., & Wells, D. C. 1988, A&AS, 73, 365
IAU 1983, Transactions of the IAU, XVIIIB, 45
IAU 1988, Transactions of the IAU, XXB, 51
IAU 1997, Resolution B1 of the XXIIIrd General Assembly – Transactions of the
IAU Vol. XXIII B, Ed. J. Andersen, (Dordrecht: Kluwer). Available online:
http://www.iau.org/static/resolutions/IAU1997 French.pdf
IEEE 1985, American National Standard – IEEE Standard for Binary Floating
Point Arithmetic, ANSI/IEEE 754–1985, New York: American National
Standards Institute, Inc.
Irwin, A. W. & Fukushima, T. A. 1999, A&A348, 642
ISO 2004, Information technology – Programming languages – Fortran, ISO/IEC 1539-1:2004, Geneva: International Organization for Standardization
ISO 2004b, International Standard ISO 8601:2004(E), Data elements and interchange formats – Information interchange – Representation of dates andtimes
NASA/JPL Planetary Ephemerides 2014a, available online: http://ssd.jpl.
nasa.gov/?ephemerides
NASA/JPL Solar and Planetary Ephemerides 2014b, available online: http://
ssd.jpl.nasa.gov/?planet_eph_export
Mallory, T. & Kullberg, A. 1990, IETF RFC 1141,
https://tools.ietf.org/html/rfc1141
McNally, D., ed. 1988, Transactions of the IAU, Proceedings of the TwentiethGeneral Assembly (Dordrecht: Kluwer)
Park, X. & Miller, X. 1988, Comm. ACM, 31, Issue 10, 1192; available online:
http://dl.acm.org/citation.cfm?id=63042
Pence, W. D., Seaman, R., & White, R. L. 2009, PASP, 121, 414
Pence, W. D., Chiappetti, L., Page, C. G., Shaw, R. A., & Stobie, E. 2010, A&A,
524, A42
Pence, W. D., Seaman, R., & White, R. L. 2013, Tiled Table Convention for
Compressing FITS Binary Tables, FITS Support Office; available online:
http://fits.gsfc.nasa.gov/registry/tiletablecompression.
html
Ponz, J. D., Thompson, R. W., & Muñoz, J. R. 1994, A&AS, 105, 53
Rice, R. F., Yeh, P.-S., & Miller, W. H. 1993, in Proc. 9th AIAA Computing in
Aerospace Conf., AIAA-93-4541-CP, American Institute of Aeronautics andAstronautics
Rijsinghani, A. (ed.) 1994, IETF RFC 1624,
https://tools.ietf.org/html/rfc1624
Rots, A. H., Bunclark, P. S., Calabretta, M. R., Allen, S. L., Manchester, R. N.
& Thompson, W. T. 2015, A&A, 574, A36
Schmitz, M., et al. 1995, Information & On-line data in Astronomy, eds. D. Egret& M. A. Albrecht (Kluwer Academic Pub.), 259
Standish, E. M. 1990, A&A, 233, 252
Standish, E. M. 1998, JPL Memo IOM 312.F-98-048
Wells, D. C., Greisen, E. W., & Harten, R. H. 1981, A&AS, 44, 363
Wells, D. C. & Grosbøl, P. 1990, Floating Point Agreement for FITS, http://
fits.gsfc.nasa.gov/fp89.txt
White, R. L. 1992, in Proceedings of the NASA Space and Earth Science Data
Compression Workshop, ed. J. C. Tilton, Snowbird, UT; available online:
https://archive.org/details/nasa_techdoc_19930016742
White, R. L., & Greenfield, P. 1999, in ADASS VIII, ASP Conf. Ser. 172, eds.
D. M. Mehringer, R. L. Plante, & D. A. Roberts (San Francisco: ASP), 125
White, R. L., Greenfield, P., Pence, W., Tody, D. & Seaman, R. 2013, Tiled
Image Convention for Storing Compressed Images in FITS Binary Tables,

References

DR

AF
T

widely used in conjunction with the SDFITS convention17. It
was devised primarily to record WCS keywords independently
for each row of a table containing an image array column, but
subsequently it has found more general application.
The basic idea is that of expanding header keywords into
binary table columns, and vice versa, of collapsing unvarying
binary table columns into header keywords.
For example, the standard header keyword DATE-OBS, which
records the date and time of observation, could be expanded intoa column with TTYPEn = ’DATE-OBS’ to record the date andtime independently for each row of a binary table. Conversely,a binary table column with TTYPEn = ’HUMIDITY’ containing
the same value in each row, could be collapsed into a keyword,
HUMIDITY, that recorded the constant value.
When the Green Bank convention is used (and arguably otherwise) a keyword should not coexist with a column of the same
name within a single binary table. Should this situation occur,
the column value takes precedence over the keyword.
When expanding keywords into columns, the Green Bank
convention applies to all FITS keywords that may appear in a binary table except for the following, most ofwhich describe the structure or identity of a binary table
HDU: XTENSION, BITPIX, NAXIS, NAXISn, PCOUNT, GCOUNT,TFIELDS, EXTNAME, EXTVER, EXTLEVEL, TTYPEn, TFORMn,
TUNITn, TSCALn, TZEROn, TNULLn, TDISPn, THEAP, TDIMn,
DATE, ORIGIN, COMMENT, HISTORY, CONTINUE, and END.
In order to collapse a column into a keyword, the name of thecolumn (given by TTYPEn) must be a valid keyword name, andthe column’s constant value must be amenable to representation
as a valid keyvalue.
Software that implements the Green Bank convention musttake into account the possibility that any “keyword” (apart fromthose on the proscribed list), such as DATE-OBS, may change
value from row to row of a table. Moreover, when searching theheader for a particular keyword, it must first consider the values of the TTYPEn keywords in case the desired keyword has
been expanded as a column. Likewise, it must consider eachheader keyword potentially as a collapsed column, so that arequest for the value in a particular row or rows of the nonexistent ’HUMIDITY’ column would be satisfied by the valueof the HUMIDITY keyword.

Note: Many of these FITS references are available electronically from theNASA Astrophysics Data System (ADS) and/or the FITS Support Office web
sites athttp://adswww.harvard.edu andhttp://fits.gsfc.nasa.gov/fits_documentation.html.

Allen, S. & Wells, D. 2005, IETF RFC 4047,
http://www.ietf.org/rfc/rfc4047.txt
ANSI 1977, American National Standard for Information Processing: Code forInformation Interchange, ANSI X3.4–1977 (ISO 646) New York: American
National Standards Institute, Inc.
Braden, R. T., Borman, D.A., and Partridge, C. 1988 ACM Computer
Communication Review, 19, no. 2, 86, IETF RFC 1071,
https://tools.ietf.org/html/rfc1071
Bradner, S. 1997, IETF RFC 2119, http://www.ietf.org/rfc/rfc2119.
txt
Bunclark, P. & Rots, A. 1997, Precise re-definition of DATE-OBS Keyword encompassing the millennium,
http://fits.gsfc.nasa.gov/year2000.html
17

http://fits.gsfc.nasa.gov/registry/sdfits.html

65

66

DR

AF
T

FITS Support Office; available online: http://fits.gsfc.nasa.gov/
registry/tilecompression.html
Ziv, J., & Lempel, A. 1977, IEEE Transactions on Information Theory, 23 (3),33766Index

angular units, 10, 30
ANSI, 3, 55
ANSI, IEEE, 16, 26
array descriptor, 22–24, 26–28
array size, 11, 12, 17
array value, 3, 4, 14, 20
array, multi-dimensional, 5, 24, 29, 30, 58
array, variable-length, 1, 24, 27, 28, 58
ASCII character, 3, 16, 18, 21, 55
ASCII table, 18
ASCII text, 3, 4, 7, 13, 21, 25, 55
ASCII, ANSI, 65
AUTHOR, 13
binary table, 4, 16, 22, 54
BITPIX, 11, 12, 14, 16–18, 22
BLANK, 14, 16
blocking, 5
BSCALE, 14, 16
BUNIT, 14byte order, 5, 16, 25, 26
BZERO, 14, 16

DRcase sensitivity, 6, 7, 10, 19, 22
character string, 3, 7, 21, 24, 25
checksum, 15, 45, 48, 49, 61–64
COMMENT, 6, 13
complex data, 8, 9, 23, 26, 27
compressed binary tables, 47, 54, 61
compressed images, 44, 54, 61
compression algorithms, 44, 49
compression, lossy, 47
conforming extension, 3–5
CONTINUE, 6, 7, 61
coordinate systems, 28

DATAMAX, 14
DATAMIN, 14
DATE, 12, 42
DATE-OBS, 13, 42
DATExxxx, 13, 42
deprecate, 3, 4, 6, 9, 12, 16, 21, 29, 32, 34
dithering, 46
durations, 43
END, 5, 11, 17–19, 22, 28
EPOCH, 34
EQUINOX, 34
EXTEND, 12
extension, 3–5, 14, 16, 58, 60
extension registration, 5, 11
extension type name, 3, 5, 11, 14
extension, conforming, 3–5
extension, standard, 4, 5
EXTLEVEL, 15
EXTNAME, 14
EXTVER, 14

field, empty, 22, 25, 26
file size, 4fill, 5, 6, 11, 17, 18, 20, 21, 24, 25, 28
FITS structure, 3, 4, 6, 12
floating-point, 8, 26, 55
floating-point FITS agreement, 65
floating-point, complex, 9, 26
format, data, 16
format, fixed, 7
format, free, 7, 8, 52
format, keywords, 7
Fortran, 5, 19–21, 24, 65

AF
T

Nbits , 11, 12, 17

GCOUNT, 11, 12, 17–19, 22
Green Bank convention, 30, 61, 64
group parameter value, 3, 17, 18
GROUPS, 17
GTI tables, 43
GZIP compression, 50
H-compress algorithm, 50
HDU, 3, 11
HDU, extension, 3, 4
HDU, primary, 3–5
header space, preallocation, 13, 61
heap, 3, 11, 22–24, 26–28
HISTORY, 6, 13
hyphen, 6, 19, 23, 30, 34
IAU, 1, 3, 65
IAU Style Manual, 10, 65
IAUFWG, 1, 3, 5, 11, 29, 40, 58
IEEE floating-point, 16
IEEE special values, 4, 14, 16, 55
image extension, 18
INHERIT, 15, 61, 64
INSTRUME, 13
integer, 16-bit, 16, 25
integer, 32-bit, 16, 25, 26
integer, 64-bit, 16, 26
integer, 8-bit, 16, 25
integer, complex, 8
integer, unsigned, 14, 16, 23, 25, 26
ISO-8601 date, 36
JD, 36
keyword record, 4, 6
keyword, commentary, 6, 13
keyword, indexed, 4, 6, 11
keyword, mandatory, 6, 7, 10, 16, 18, 22, 54
keyword, new, 15
keyword, order, 11, 16, 18
keyword, required, 4, 10, 11, 16, 18, 22, 44, 47
keyword, reserved, 4, 12, 17–19, 22, 30, 32, 42, 44, 49, 54
keyword, valid characters, 6
logical value, 8, 25, 26
magnetic tape, 667

68
min and max in columns, keywords, 20, 24, 61
MJD, 36
NaN, IEEE, 16, 26, 55, 56
NAXIS, 4, 5, 11, 12, 16–19, 22
NAXIS1, 17, 19, 21, 22, 24, 25, 28
NAXIS2, 19, 21, 22, 24, 25, 28
NAXISn, 4, 5, 11, 12, 17, 18
NULL, ASCII, 3, 25

PCOUNT, 11, 12, 17–19, 22, 28
phase, 42
physical value, 3, 4, 14, 17, 18, 20, 23
PLIO compression, 50
primary data array, 3–5, 16–18
primary header, 3, 4, 11, 16
PSCALn, 17, 18
PTYPEn, 17, 18
PZEROn, 17, 18
quantization of data, 46, 61

DR

random groups, 3, 14, 16
random groups array, 17
REFERENC, 13
repeat count, 4, 22, 25
Rice compression, 49

underscore, 6, 19, 23
units, 4, 10, 14, 20, 23, 30, 35

AF
T

OBJECT, 13
OBSERVER, 13
order, byte, 5, 16, 25, 26
order, extensions, 5order, keyword, 6, 11, 16, 18
order, FITS structures, 4
ORIGIN, 12

scaling, data, 17, 18, 20, 23
sign bit, 16
sign character, 8, 21
SIMPLE, 5, 11, 16
slash, 6, 10
solar system ephemeris, 40
special records, 3–5
special values, IEEE, 26
standard extension, 4, 5

TABLE, 18
TBCOLn, 19
TDIMn, 24
TDISPn, 20, 23
TELESCOP, 13
TFIELDS, 19, 22
TFORMn, 19, 22, 25–27
THEAP, 24, 28
time, 12, 13, 34, 36
time keywords, 41
time reference, 38
time reference direction, 40
time reference position, 38, 39
time resolution, 41
time scale, 37, 38
time units, 40, 41
time, universal, 12, 37
68

timelag, 42
TIMESYS, 37
TNULLn, 20, 21, 23, 25, 26
TSCALn, 20, 23, 28
TTYPEn, 19, 22
TUNITn, 20, 23
two’s complement, 16, 25, 26
TZEROn, 20, 23, 28

value, 6, 7, 12
value, undefined, 6, 7, 14, 16, 20, 21, 23, 59
variable length arrays, compression, 49
variable-length array, 1, 24, 27, 28, 58
WCS, 28
WCS, celestial, 33
WCS, spectral, 34
WCS, timing, 36, 61

XTENSION, 3, 5, 11, 14, 18, 22