TRUE, any FITS extension is written to start of the output file, unless there is no extension whereupon a minimal FITS header is written to the unformatted file.
[The first dimension of the NDF
cluster.dat. The number of data values per record is equal to the size of the first dimension of the NDF.
cluster.dat. The number of variance values per record is equal to the size of the first dimension of the NDF.
cluster.dat. There are twelve data values per record in
ndf234.dat. The number of data values per record is equal to the size of the first dimension of the NDF. If there is a FITS extension, it is copied to
ndf234.datwith substitution of certain keywords, otherwise a minimal FITS header is produced.
the NDF array as selected by COMP is written to the unformatted file in records following an optional header.
HISTORY is not propagated.
ORIGIN information is lost.
When a header is to be made, it is composed of FITS-like card images as follows:
The number of dimensions of the data array is written to the keyword NAXIS, and the actual dimensions to NAXIS1, NAXIS2 etc. as appropriate.
If the NDF contains any linear axis structures the information necessary to generate these structures is written to the FITS-like headers. For example, if a linear AXIS(1) structure exists in the input NDF the value of the first data point is stored with the keyword CRVAL1, and the incremental value between successive axis data is stored in keyword CDELT1. By definition the reference pixel is 1.0 and is stored in keyword CRPIX1. If there is an axis label it is written to keyword CTYPE1, and axis unit is written to CUNIT1. (Similarly for AXIS(2) structures etc.) FITS does not have a standard method of storing axis widths and variances, so these NDF components will not be propagated to the header. Non-linear axis data arrays cannot be represented by CRVALn and CDELTn, and must be ignored.
If the input NDF contains TITLE, LABEL or UNITS components these are stored with the keywords TITLE, LABEL or BUNIT respectively.
If the input NDF contains a FITS extension, the FITS items may be written to the FITS-like header, with the following exceptions:
An extra header record with keyword UNSIGNED and logical value T is added when the array data type is one of the HDS unsigned integer types. This is done because standard FITS does not support unsigned integers, and allows (in conjunction with BITPIX) applications reading the unformatted file to determine the data type of the array.
The last header record card will be the standard FITS END.
Other extensions are not propagated.
The value of bad pixels is not written to a FITS-like header record with keyword BLANK.