Data Formats

IRAF Images

The IRAF system's native format is known simply as the IRAF format, or OIF (Old IRAF Format). The IRAF format is conceptually quite simple, an image consists of two files:

 The header (.imh) and pixel (.pix) files can either be in the same directory or in different directories. The header file contains a pointer to the name of the corresponding pixel file. The IRAF environment variable imdir is used to control the location of the pixel files for any newly-created images. On some systems imdir is set to point to a subdirectory of your IRAF home directory, or to a large scratch area elsewhere on the system.

Advantages and Problems with IRAF Images

The advantage of storing pixel files separate from header files is that the pixel files can be large, and don't clutter your main directory with large binary data files. Also, when you look at the contents of your IRAF directory, you see only the names of the header files, making the listing easier to read.

There are also some disadvantages to storing the pixel files separately:

Where Pixel Files Get Stored

You can control the location of your IRAF pixel files by reassigning the value of imdir in your login.cl file (or at the CL prompt). For example, the following command would direct your pixel files to the subdirectory pixfiles under your IRAF home directory.

cl> set imdir = home$pixfiles/
Another option is to keep IRAF pixel files in the same directory as the header files. This is how STSDAS format data files are stored (as described below), and will help manage your data consistently. To do this, set imdir to the value HDR$ (which means "same directory as header file"), as follows:

cl> set imdir = HDR$

Examining the Header

Note that neither an IRAF header nor pixel file can be printed using simple commands like type or page. To view an IRAF header file, you must use a task such as imheader in the IRAF images package.

The IRAF pixel file is not structured as a simple stream of data values. Depending on the length of the data axes, the file may have embedded null values that maximize I/O efficiency, even at the expense of having a larger file on disk. For example, look at the following long header listing for the standard IRAF test image dev$pix.

Partial Header Listing for IRAF Test Image

This listing indicates that this is a 512 x 512 image with short-integer pixel values. The third line tells you that the data is in line storage mode--each row, or line, of the image is stored sequentially in the binary pixel file. The pixel file is shown as having physdim[512,512]--that is, the data will map byte-for-byte to the binary file. (The warning NO PIXEL FILE on the last line is irrelevant; this appears when you have imdir = HDR$.)

In contrast, look at the header for an image called temp which is extracted as a subset from dev$pix (Figure 3.2).

Partial Listing of Partial Image Section

The listing indicates that the image is now of dimension 490 x 50, but on the third line it indicates that the physical storage space is 512 x 50. This is done to make I/O to an arbitrary row occur on a block boundary, which is more efficient. IRAF data files will often, as a result, have some wasted space in them. If you try to compute the size of a pixel file by just taking the product of the total number of pixels times the bytes per pixel, you will find that the actual size of the data file can be larger by 10 to 20 percent.

Advantages and Problems with IRAF Images
Where Pixel Files Get Stored
Examining the Header

Generated with WebMaker