IRAF Newsletter -- Number 14 -- April 1998

[ Previous ] [ Next ] [ Table of Contents ] [ Search this issue ]

The IMEXTN and IMTYPE Environment Variables

A new CL environment variable "imextn" has been added to IRAF with V2.11. The imextn variable associates image file name extensions, e.g., ".imh", ".fits", etc., with the external image formats supported by IRAF, allowing custom filename extensions to be assigned. A file that does not have an extension listed in either the user-defined imextn variable or in the builtin system defined default imextn will not be recognized as an image by IRAF.

The default value of imextn is as follows:

Here OIF, FXF, PLF, QPF, and STF are the internal names of the runtime image formats supported by IRAF, and the valid file extensions associated with each format are listed following the colon ":". Valid internal image format names (image kernel names) are "oif" for the original IRAF format, "fxf" for the FITS extension format, "plf" for the compressed pixel list format, "qpf" for the QPOE position ordered event list format, and "stf" for the Space Telescope GEIS image format. Additional image formats may be added in the future. The imextn string is case insensitive.

File extensions may be fixed strings or simple patterns. The "??h" in the STF kernel entry means that the STF kernel will recognize any image with a 3 letter extension ending in "h" as an STF image, unless the extension is already assigned to another kernel, for example "imh". All kernels currently impose some limit on the length of an extension, usually 3 or 4 characters.

Not all image kernels permit file extensions to be arbitrarily assigned. The OIF, PLF, and QPF image kernels do not permit the file extension to be changed. The FXF and STF image kernels support multiple image file name extensions, and permit the user to add new extensions to the list, to change the default extension, and to remove unwanted extensions as shown below.

For example the following command will add the new extension "fts" to the file extension list for the FXF (FITS) image kernel without affecting the builtin default settings for the other image formats.

After the above commands, disk files which end in ".fts" will be interpreted as FITS files although "fits" is still the default extension for the FXF kernel (because it is listed first in the imextn entry). The flpr command flushes the CL process cache to ensure that any imaging tasks pick up the new value of imextn. In the current system imextn is only parsed once when a process starts up. Environment variables are not intended to be used as runtime parameters, they are generally used for things that should be set once at the beginning of a session (e.g., in the file) and left unchanged thereafter.

The next command makes "fts" the default extension for the FXF image format.

New FITS images will now be created with the extension "fts" instead of "fits", since "fts" is the first extension assigned to the FXF format.

The environment variable "imtype" defines the default image format for new images created by IRAF. The default image type is only used if no explicit image type is specified by including an explicit image extension in the output image name. You can always force an image of a certain type to be created by explicitly giving the image extension.

The default value of imtype is "imh" which means that the default output image format is OIF or the original, native, IRAF image format. By default the following command will create an "imh" image.

To change the default output image type to FITS change the value of imtype as shown below.

Including the file name extension as part of the new image name will, provided that it is one of the valid extensions listed in imextn, override the default typing mechanism. For example, the following commands will produce FITS files regardless of the setting of imtype.

Imtype can also be set to the name of the image format rather than to one of the permitted extensions, a feature that can be useful if the default image extensions change. The following two commands are equivalent

The imtype variable has an "inheritance" attribute which is new in IRAF V2.11. If image type inheritance is enabled, the type of a new image is the type of the parent image in a "new copy" operation. If the type of a new image is determined by inheritance the default image format specified by imtype is ignored. The default type will still be used if a new image is created which is not derived from some other image, e.g., images created by tasks such as mkpattern or rfits .

By default imtype inheritance is disabled, meaning that the value of imtype determines the type of new images to be created unless the type is explicitly specified by the image extension. The following example shows the results of inheritance in some imcopy operations.

The following examples illustrate how the image extension may be used to force the type of image to be created, regardless of the value of imtype.

When working in mixed image type environments one should be aware that imtype is not used to determine which type of image to read or access. To be safe, when in doubt one should always explicitly include the extension in the image name. In IRAF V2.11.1 and later versions, if there are multiple images with the same root name and different extensions, an error will occur if only the root name is given.

In this example two or more images exist with the same root name (newpix4) and IRAF does not know which image is being referred to, so an ambiguous image name error occurs. A command such as "imdel newpix4.fits" is necessary to delete the desired image.

Lindsey Davis, Doug Tody

[ Previous ] [Next ] [ Table of Contents ] [ Search this issue ]

IRAF Group, National Optical Astronomy Observatories, P.O. Box 26732, Tucson, AZ 85726, Phone: (520) 318-8160, FAX: (520) 318-8360, Email

Posted: 07May1998