### NDF2IRAF

Converts an NDF to an IRAF image

#### Description:

This application converts an NDF to an IRAF image. See the "Notes" for details of the conversion.

#### Parameters:

The input NDF data structure. The suggested default is the current NDF if one exists, otherwise it is the current value.
The value used to replace bad pixels in the NDF’s data array before it is copied to the IRAF file. A null value (!) means no replacements are to be made. This parameter is ignored if there are no bad values. [0]
##### OUT = LITERAL (Write)
The name of the output IRAF image. Two files are produced with the same name but different extensions. The ".pix" file contains the data array, and ".imh" is the associated header file that may contain a copy of the NDF’s FITS extension. The suggested default is the current value.
If TRUE, the contents of the FITS extension of the NDF are merged with the header information derived from the standard NDF components. See the "Notes" for details of the merger. [TRUE]
If TRUE, any NDF history records are written to the primary FITS header as HISTORY cards. These follow the mandatory headers and any merged FITS-extension headers (see parameter PROFITS). [TRUE]

#### Examples:

ndf2iraf abell119 a119
Converts an NDF called abell119 into the IRAF image comprising the pixel file a119.pix and the header file a119.imh. If there are any bad values present they are copied verbatim to the IRAF image.
ndf2iraf abell119 a119 noprohis
As the previous example, except that NDF HISTORY records are not transferred to the headers in a119.imh.
Converts the NDF called qsospe to an IRAF image comprising the pixel file qsospe.imh and the header file qsospe.pix. Any bad values in the data array are replaced by zero.
As the previous example, except that any FITS airlock information in the NDF are not transferred to the headers in qsospe.imh.

#### Notes:

The rules for the conversion are as follows:
• The NDF data array is copied to the ".pix" file. Ancillary information listed below is written to the ".imh" header file in FITS-like headers.

• The IRAF “Mini World Co-ordinate System” (MWCS) is used to record axis information whenever one of the following criteria is satisfied:

(1)
the dataset has some linear axes (system=world);
(2)
the dataset is one-dimensional with a non-linear axis, or is two-dimensional with the first axis non-linear and the second being some aperture number or index (system=multispec);
(3)
the dataset has a linear spectral/dispersion axis along the first dimension and all other dimensions are pixel indices (system=equispec).
• The NDF title, label, units are written to the header keywords TITLE, OBJECT, and BUNIT respectively if they are defined. Otherwise any values for these keywords found in the FITS extension are used (provided Parameter PROFITS is TRUE). There is a limit of twenty characters for each.

• The NDF pixel origins are stored in keywords LBOUNDn for the nth dimension when any of the pixel origins is not equal to 1.

• Keywords HDUCLAS1, HDUCLASn are set to "NDF" and the array-component name respectively.

• The BLANK keyword is set to the Starlink standard bad value, but only for the _WORD data type and not for a quality array. It appears regardless of whether or not there are bad values actually present in the array.

• HISTORY headers are propagated from the FITS extension when PROFITS is TRUE, and from the NDF HISTORY component when PROHIS is TRUE.

• If there is a FITS extension in the NDF, then the elements up to the first END keyword of this are added to the ‘user area’ of the IRAF header file, when PROFITS=TRUE. However, certain keywords are excluded: SIMPLE, NAXIS, NAXISn, BITPIX, EXTEND, PCOUNT, GCOUNT, BSCALE, BZERO, END, and any already created from standard components of the NDF listed above.

• A HISTORY record is added to the IRAF header file indicating that it originated in the named NDF and was converted by NDF2IRAF.

• All other NDF components are not propagated.

#### Related Applications

Convert: IRAF2NDF.

#### Pitfalls

The IMFORT routines refuse to overwrite an IRAF image if an image with the same name exists. The application then aborts.

Some of the routines required for accessing the IRAF header image are written in SPP. Macros are used to find the start of the header line section, this constitutes an ‘Interface violation’ as these macros are not part of the IMFORT interface specification. It is possible that these may be changed in the future, so beware.

#### References

IRAF User Handbook Volume 1A: A User’s Guide to FORTRAN Programming in IRAF, the IMFORT Interface, by Doug Tody.

#### Implementation Status:

• Only handles one-, two-, and three-dimensional NDFs.

• Of the NDF’s array components only the data array may be copied.

• The IRAF image produced has type SIGNED WORD or REAL dependent of the type of the NDF’s data array. (The IRAF IMFORT FORTRAN subroutine library only supports these data types.) For _BYTE, _UBYTE, and _WORD data arrays the IRAF image will have type SIGNED WORD; for all other data types of the NDF data array a REAL IRAF image is made. The pixel type of the image can be changed from within IRAF using the ‘chpixtype’ task in the ‘images’ package.

• Bad values may arise due to type conversion. These too are substituted by the (non-null) value of FILLBAD.

• See "Release Notes" for IRAF Version compatibility.