3.4. EXTENSIONS

15

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)

Figure 3.1 Arrays of more than one dimension shall consist of a sequence such that the

index along axis 1 varies most rapidly and those along subsequent axes progressively

less rapidly.

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 the

value appears first in the FITS file, followed by the remaining bytes, if any, in decreasing

order of significance.

3.4

Extensions

3.4.1

Requirements for Conforming Extensions

All extensions, whether or not further described in this standard, shall fulfill the follow-

ing requirements to be in conformance with 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 multi-extension 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 (§4.4.1.2). To preclude conflict, extension type names must be regis-

tered with the IAUFWG. The current list of registered extensions is given in Appendix

FITS Standard