The programme reads a simple or a random-groups-format FITS file (Wells et al. 1981; Greisen & Harten 1981), and writes the data into an NDF , and the headers into the NDF's FITS extension. Table-format files (Grosbøl et al. 1988) are read, and the application creates two files: a text formatted table/catalogue and a FACTS description file (as used by SCAR) based upon the FITS header cards. Composite FITS files can be processed. You may specify a list of files, including wildcards. A record of the FITS headers, and group parameters (for a group-format file) can be stored in a text file.
There is an option to run in automatic mode, where the names of output NDF data structures are generated automatically, and you can decide whether or not format conversion is to be applied to all files (rather than being prompted for each). This is very useful if there is a large number of files to be processed. Even if you want unique file names, format-conversion prompting may be switched off globally.
In automatic mode the application generates a filename beginning with the input filename, less any extension. For example, if the input file was saturn.fits the filename of the output NDF would be saturn.sdf, and an output table would be saturn.dat with a description file dscfsaturn.dat. If there are sub-files (more than one FITS object in the file) a suffix _<subfile> is appended. So if saturn.fits comprised a simple file followed by a table, the table would be called SATURN_2.DAT and the description file DSCFSATURN_2.DAT. For group format a suffix G<groupnumber> is appended. Thus if saturn.fits is a group format file, the first NDF created would be called saturn.sdf, the second would be saturnG2.sdf. [FALSE]
A suggested filename for the description file is reported immediately prior to prompting in manual mode. It is the name of the catalogue, as written in the FITS header, with a "dscf" prefix.
It is very similar to FITS-IRAF but supports a wider range of projections and co-ordinate systems. Once the standard has been agreed, this encoding should be understood by any FITS-WCS compliant software and it is likely to be adopted widely for FITS data in future.
A comma-separated list of up to six values may be supplied, in which case the value actually used is in the first in the list for which corresponding keywords can be found in the FITS header.
A FITS header may contain keywords from more than one of these encodings, in which case it is possible for the encodings to be inconsistent with each other. This may happen for instance if an application modifies the keyword associated with one encoding but fails to make equivalent modifications to the others. If a null parameter value (!) is supplied for ENCODINGS, then an attempt is made to determine the most reliable encoding to use as follows. If both native and non-native encodings are available, then the first non-native encoding to be found which is inconsistent with the native encoding is used. If all encodings are consistent, then the native encoding is used (if present). [!]
Each group NDF contains the full header in the FITS extension, appended by the set of group parameters. The group parameters are evaluated using their scales and offsets, and made to look like FITS cards, whose keywords are derived from the values of PTYPEm in the main header. (m is the number of the group parameter.) The same format is used in the log file.
KAPPA --- Kernel Application Package