What data formats are supported?

  Data for use with IRAF can be stored as images, text files, or binary
tables.  The currently supported image types are OIF format (used for most
applications), FITS format, STF format (used for HST data w/ STSDAS), QPOE format (used
for event list data such as from the XRAY satellites), and PLIO for pixel
list (used to flag individual pixels in a region of interest).  V2.11.x IRAF
includes a FITS image kernal to support disk FITS images directly.
        Text files are typically used as database or configuration files with
tasks, image data in text files may be converted to an image format in a
number of ways (see below).  Binary tables are manipulated using the TABLES
layered package, some tasks accept these directly as input.

How can I convert my data to the IRAF image format?

Starting in version 2.11, IRAF can access directly FITS format files. 
Iraf will read, modify or create images in standard FITS format as either 
a single FITS file or as an IMAGE extension within a file. 
See IRAF Fits Kernel User's Guide.

Various tasks for converting data to IRAF image format exist in the
DATAIO package, for example, RFITS converts FITS files to IRAF image files.
A complete list of data conversion tasks can be found using the command:
		cl> refer convert
Starting with V2.11 the new tasks IMPORT/EXPORT in the DATAIO package are
available to convert a wide variety of formats in and out of the IRAF format.

How do I convert my ascii text file of wavelength and flux into an IRAF image?

 There are currently 3 ways to do this.  One is to use the SINTERP task,
which can be used to interpolate a table of x,y pairs and create a spectrum.
If your data are linear, no interpolation is necessary, and SINTERP can
create an output image with as many pixels as input values.
Another method is to use RTEXTIMAGE, optionally piping the data through FIELDS
to extract the correct column of pixel data, followed by hand editing with
HEDIT to define required header fields.
The third method is to use the RSPECTEXT task in the ONEDSPEC package.

Does IRAF support world coordinate systems in images?

	IRAF does support various coordinate systems in addition to the
pixel array coordinates.  This was described in IRAF Newsletter #12, July 1992,
"World Coordinate System Support in IRAF V2.10".  These coordinate systems are
specified in the image headers under specific keywords.  The most common type
of world coordinate system is linear.  The linear coordinate systems are de-
scribed using the standard keywords defined by the basic FITS documentation.
Hence images in FITS with linear coordinates can be easily imported into IRAF.
The astronomical celestial projections are also supported.  This follows a
description similar to current FITS proposals.  A description of the syntax
used in IRAF is given in the help for the task WCSEDIT.  This task may be
used to create or modify such world coordinate systems.
	There are more complex non-linear coordinate systems used in
spectra.  These are described in the document "" in the IRAF
documentation archive.  For export to other systems one should "linearize"
such spectra since the formats are not generally adopted.
	The world coordinate systems relate the pixel coordinates to user
"world" coordinates.  If one extractions sections of an image the world
coordinates continue to be valid.  This is done by adding a transformation
between the current pixel (called logical) coordinates and the original
pixel (call physical) coordinates.  This may even involve changes in
dimension.  The transformation is defined by the LT keywords.  One may
reset the physical coordinate systems (for linear or celestial systems)
using the task WCSRESET.  This does not apply to the nonlinear spectral
coordinates.  One may also remove a world coordinate system with WCSRESET.
In this case the world coordinate system is then the physical coordinates.
	In many IRAF tasks, such as LISTPIXELS and IMPLOT, there is a
parameter called "wcs".  This allows these tasks to use either "logical",
"physical", or "world" coordinates.  The values of this parameters are the
quoted names.

What is the IRAF disk image format?

      The IRAF disk image format is intentionally not documented, outside
the source files (e.g., imio$iki/oif).  This is because the format is
subject to change with time (e.g. the format changed dramatically between
V2.10 and V2.11), and should never be written directly from a user program.
IRAF images should only be written through a standard interface such as
IMFORT or SPP/IMIO. At present the CVOS interface in STSDAS V2.1 may be used
by host or iraf C programs to access the image interfaces.

How do I convert my GIF/JPEG images to IRAF?

 There are several paths you can take to get GIF/JPEG images into IRAF
format.  For GIF images the simplest method is to use the IMPORT task in
the DATAIO package to convert directly.  Unfortunately IMPORT does not
support JPEG.  If you want to convert to FITS we suggest using the
ImageMagick package (available from, which is mirrored at other
X11 FTP sites that may be closer to you) also has a conversion task called
CONVERT that will go from JPEG or GIF to FITS automatically.  For interactive
conversion the XV task is recommended.
        Note that the process can also be reversed to get back to a GIF/JPEG
image, in this case using the EXPORT task to go to GIF and the above tools
for a final conversion to JPEG.

What are the "..image.imh" files associated with each of my images? Can I delete them to free up disk space?

  The ..*.imh files are hard links to the *.imh files used to protect
the headers from being deleted with DELETE, rather than deleting the image
with IMDELETE.  They don't take up any more disk space than the image
files they are links to, i.e. in a directory with both the ..imh files
and the headers, deleting the .. files doesn't free up any disk space.
Silimarly deleting the imh files doesn't actually free up space because
the link still points to it, but if you IMDELETE the files (getting rid of
both the .. and imh files) you only recover space occupied by the header
files, not twice that.
        A hard link (what the .. files are) is just a standard directory
entry like the file to which it's linked, to remove the file from the
system all hard links to it must be removed, even if the original file
was moved/renamed.
	You can use the UNPROTECT command to remove these protection files
(but that isn't recommended), similarly the PROTECT command will create
them for images that don't have them.