A Beginner's Guide To Using IRAF
A Beginner's Guide To Using IRAF
CONTENTS
1. Introduction
1. Overview
2. Getting IRAF
3. Documentation
4. IRAF support services
5. Style conventions
6. Getting started
1. Host startup files
7. IRAF startup files
8. Logging in/out of IRAF
9. The basics
1. Setting up your IRAF environment
1. Defining your terminal type
10.Selecting hard copy devices
11.Choosing an editor
1. Packages and tasks
12.General help facilities
1. Simple tools
13.Online manual pages
14.The HELP task
15.The PHELP task
16.Printing online manual pages
17.Finding a task with a particular function (REFERENCES)
1. Doing things with directories
1. Creating/removing directories
18.Changing directories
1. Parameter files
1. Listing parameters
19.Editing parameters
20.Resetting task parameters
1. Executing tasks
1. General syntax
21.Running tasks in the background
22.Aborting tasks
1. Data files
23.IRAF image files
1. The IRAF image header
24.The IRAF pixel file
25.Pixel data types
26.Image dimensions
27.General image tools
28.Reading and writing data
1. General tape handling facilities
29.Setting tape densities
30.FITS facilities
1. Reading FITS images
31.Writing FITS images
1. Text files
32.Non-standard data formats
33.Tar file format
34.Miscellaneous I/O tasks
35.Plotting data
1. Interactive graphics cursor mode
36.One-dimensional (vector) plotting tasks
37.Two-dimensional plotting tasks
38.Tasks that manipulate graphics metacode files
39.Using the image display
1. Displaying IRAF images
40.Using the interactive image cursor
1. Reading the image cursor position
41.Examining and editing images
42.Coordinate systems within IRAF
43.Additional interesting topics
1. Input/output redirection
44.Image sections
45.File and image name templates
46.The @file
47.History and command logging
48.Using the CL as a calculator
49.IRAF networking
1. Syntax
50.The .irafhosts file
51.Writing your own software
1. Writing IRAF scripts
52.The IMFORT interface
53.Programming in IRAF with SPP
Appendix A The IRAF Packages
Appendix B The NOAO Packages
Appendix C IRAF Image Formats
Appendix D Fixing Pixel File Pathname
Appendix E The IRAF Network Archive
Appendix F IRAF Layered Packages
Appendix G A Selected List of IRAF Documentation
1. Introduction
1.1 Overview
IRAF is a general Image Reduction and Analysis Facility providing a wide range
of image processing tools for the user. IRAF is a product of the National Optical
Astronomy Observatories (NOAO) and was developed for the astronomical
community although researchers in other scientific fields have found IRAF to be
useful for general image processing. This document is intended to provide the
novice user with a brief introduction to IRAF and its Command Language (CL)
user interface.
Only the IRAF "core" system will be discussed in this document. The NOAO
science software (general spectroscopic and photometric reduction and analysis
tools) is included in all IRAF tributions, but a discussion of this software is better
covered elsewhere.
The IRAF core system provides the user with a wide selection of image
processing tools using a command line interface. Commands, called tasks, are
executed to perform various functions; each task has a parameter file that the
user can modify to affect the output of the task. Highlights of the system include:
• similar environment regardless of host system
• query and command line interface
• pipes and redirection
• background job queue
• extensive online help
• interactive graphics and image display
• text and graphics hardcopy
• tape I/O
• FITS image I/O
• several user programming environments
• world coordinate systems
Additional IRAF software packages, called layered packages, are available from a
variety of sources and can be installed to run under the IRAF environment. See
Appendix F for more information.
1.3 Documentation
A large selection of IRAF documentation is available. A selected list of documents
is provided in Appendix G. All IRAF documentation (excluding the online
help/manual pages, see §3.3.2.), is available in the IRAF network archive in the
iraf/docs directory. A README cross-reference file lists the documents and their
file names as they appear in the archive. These files are in either compressed
PostScript or compressed ASCII format. See Appendix E for more information
about the network archive. Printed copies of these documents are available upon
request.
An IRAF Newsletter is published periodically, and it is a valuable source of
information for even the casual IRAF user. Old newsletters are available in the
IRAF network archive. Anyone can receive the Newsletter; simply send your
name, address, and email address to [email protected] and request this service. The
IRAF Newsletter is distributed by posted mail; an electronic news service will be
implemented shortly as well.
2. Getting started
2. Now you will be asked to "Enter terminal type:" - enter here what your
graphics terminal type is, i.e., vt640, gterm, xterm, and so forth. See
§3.1.1. for more information on setting your terminal type.
MKIRAF saves the old login.cl file from a previous MKIRAF as login.cl.OLD. Any
changes that were made to this old file by the user in order to customize the
previous IRAF login must be merged back into the new one.
The user can also create a loginuser.cl file (see Figure 2) that will be executed by
the login.cl file (see Figure 1) at startup time. Commands in the loginuser.cl file
supersede those commands in the login.cl file that are executed prior to the
statement that calls the loginuser.cl file itself. The loginuser.cl file is not affected
by a new MKIRAF and so this file is the preferred way to customize your IRAF
login. The important thing to note about this file is that the last statement in it
must be keep.
# LOGIN.CL -- User login file for the IRAF command language.
if (defpar ("logver"))
if (envget("TERM") == "sun") {
if (!access (".hushiraf"))
print "setting terminal type to gterm..."
stty gterm
} else if (envget("TERM") == "xterm") {
if (!access (".hushiraf"))
print "setting terminal type to xterm..."
stty xterm nl=44
} else {
if (!access (".hushiraf"))
print "setting terminal type to gterm..."
stty gterm
}
# Default USER package; extend or modify as you wish. Note that this can
# be used to call FORTRAN programs from IRAF.
package user
task $adb $bc $cal $cat $comm $cp $csh $date $df $diff = "$foreign"
task $du $find $finger $ftp $grep $lpq $ls $mail $make = "$foreign"
task $man $mon $mv $nm $od $ps $rcp $rlogin $rsh $ruptime = "$foreign"
task $rwho $sh $spell $sps $strings $su $telnet $tip $top = "$foreign"
task $touch $vi $emacs $w $wc $less $rusers $sync $pwd = "$foreign"
if (access ("home$loginuser.cl"))
cl < "home$loginuser.cl"
;
keep; clpackage
prcache directory
cache directory page type help
# List any packages you want loaded at login time, ONE PER LINE.
images # general image operators
plot # graphics tasks
dataio # data conversions, import export
lists # list processing
tv # image display
utilities # miscellaneous utilities
noao # optical astronomy packages
keep
keep
Figure 2. An example of a loginuser.cl file for a UNIX host.
¹VMS users will need to type IRAF and then MKIRAF. Alternatively $ IRAF
can be entered into the login.com file for execution at VMS login time.
Otherwise it will be necessary to type IRAF at the beginning of each
session.
3. The basics
The SET command only modifies the variable temporarily, i.e., while the current
package is loaded (see more about packages in §3.2.). Using RESET will normally
change the value of the variable for the remainder of the current IRAF session.*
*Refer to the help page for RESET (see §3.3.3.) for details.
IRAF environment variables can also be used to define IRAF logical names for
directories. These logical names can be strings denoting either host level
pathnames or other IRAF logical names. For example, the test image, dev$pix,
that is used in many of the examples in this document, can be traced to the
following host directory with the SHOW task. The iraf logical directory will be a
different host level pathname for each installation, but the dev logical directory
will be the same on all hosts. IRAF logical directories are followed by a "$". In
the last example, the task PATH is used to print the equivalent host pathname
directly, including the node or machine name.
cl> show dev
iraf$dev/
cl> show iraf
/ursa/iraf/iraf/
cl> path dev$
ursa!/ursa/iraf/iraf/dev/
You can always check or reset your terminal type once IRAF is loaded.
cl> stty #check terminal type
cl> stty xtermjh nlines=24 #reset terminal type to xtermjh (24 lines)
The STTY command sets two environment variables, terminal (for text input and
output) and stdgraph (for graphics output). If there is some question about what
terminals and terminal emulators are supported by your IRAF distribution page
through the graphcap file in the dev directory and look at the STDGRAPH
entries.
cl> page dev$graphcap
Notice that in the default login.cl file (Figure 1) that some checking at the host
level is done first to attempt a first guess at the correct terminal type. The user
can do something similar in the loginuser.cl if he wants to modify this scheme.
Typing the command devices (if the appropriate file has been edited for your
site by your IRAF site manager) will list your options for these variables.
There are three built-in options for stdplot that do not send the output to a hard
copy device, but rather create Encapsulated PostScript files on disk with names
similar to "sgi12345.eps". These "device" names are eps (produces a plot in the
middle of the page), epsl (produces a landscaped plot), and epsh (produces a plot
at the top of the page).
3.1.3 Choosing an editor
IRAF does not have its own editor but rather uses host level editors. You can set
the IRAF environment variable editor to the host level editor that you want to use
(it of course must exist) and then execute the IRAF task EDIT to invoke this
editor. The editor that you choose must have a .ed entry in the IRAF dev
directory to work properly with the tasks EDIT, EPARAM and EHISTORY.
Currently there is support for vi, edt, emacs, and memacs.
cl> show editor # show default editor
cl> set editor=vi # set the editor to vi
cl> edit <filename> # invoke the editor
If you are uncertain about what package a task is in, use the HELP task. The first
line of the help page gives the package name for a task as well as the date of the
last modification of the help page. For example, the RFITS help page shows
RFITS (Jan90) dataio RFITS (Jan90)
There are other documents in IRAF that have the same format as the online
manual pages (file names ending in .hlp) but are not part of the IRAF online help
database. These files can also be accessed with the HELP task.
cl> cd mwcs # change directories to the logical
directory mwcs
cl> help MWCS.hlp f+ # read this file with HELP
cl> cd # change directories back to your IRAF home
directory
*The "!" is used as an escape to the host operating system and allows the
user to execute a host level command from within IRAF.
There are many ways in IRAF to work with directories. Remember that your
IRAF home directory is the host level directory from which you logged into IRAF.
The IRAF home directory and the uparm directory are also both environment
variables set to logical directories, at login time.
cl> show home # show pathname for IRAF home directory
cl> show uparm # show uparm pathname
*Be forewarned about long pathnames in IRAF. Many IRAF tasks have an
upper limit of 63 characters to file names, including the full host level
pathname.
Currently there is no way to remove a directory from within IRAF; the user must
do this at the host level. Again note the use of the escape character (!) in some of
the examples.
• The following is an example of how to remove a subdirectory called nite1,
assuming a UNIX host. Be sure to delete all IRAF images in the directory
first with IMDELETE (see §3.8.5.).
cl> cd nite1 # go to nite1 subdirectory
cl> imdelete *.imh # delete all images
cl> cd .. # go up one level of directories
cl> !rm -r nite1 # delete directory nite1
• On a VMS host you must first remove all of the files in a directory, then
change the protection on that directory, and then finally delete the
directory itself.
cl> cd nite1 # go to nite1 subdirectory
cl> imdelete *.imh # delete all IRAF images
cl> delete * # delete all remaining files
cl> cd .. # go up one level of directories
cl> !set protection=(O:RWED) nite1.dir;1 # unprotect directory
cl> !delete nite1.dir;1 # remove directory
There are two types of parameters, required (often called query or positional)
parameters and hidden parameters. In our example above the first three
parameters are required parameters; these parameters must be specified each
time the task is executed. The parameters in parentheses are called hidden
parameters; if these parameters are not specified at execution time the current
default parameter values will be used.
The user can customize the parameters for any task; these customized parameter
files are then stored in the user's uparm directory. Whenever a task is executed
IRAF first searches the user's uparm directory for a customized parameter file; if
one does not exist the system default file is used.
A parameter file name in the uparm directory is a combination of the package
and task name (the first two characters plus the last character of the package
name followed by the first five characters plus the last character of the task
name). Execute dir uparm to see what parameter files are in your uparm
directory.
It is also possible for packages to have parameter files. In this case the values of
the package parameters are used by all of the tasks in the package.
3.5.1 Listing parameters
Parameters are listed with the LPARAM task. The parent package for a task must
be loaded before its parameter file can be listed. If a customized parameter file
exists in the uparm directory then those parameter values will be listed and not
the system defaults.
cl> lpar rfits # list the parameters for RFITS
We say that the parameters have been learned. If EPARM is exited with a :q!
then the parameter file is left unchanged.
*The saved parameter file may be stored in memory for a bit before it
actually gets written to the uparm directory, but for the most part this
should be transparent to the user.
See IRAF Newsletter Number 7, June 1989, Using and Customizing the
EPARAM and EHISTORY Editors, for some helpful hints.
"Control" keys can also be used to exit EPARAM. An EOF that is defined at the
host level, e.g., Ctrl-Z or Ctrl-D, can be used to exit EPARAM and update the
parameters, while Ctrl-C can be used to exit EPARAM with no updating.
Parameters can also be changed by specifying the task, the parameter, and its
new value explicitly. Different syntaxes are used for the different types of
parameter values, in particular, boolean values are given as "yes" or "no" and
string values must by quoted. The last example shows a way to query for a
particular parameter value.
cl> rfits.scale=no
cl> rfits.datatype="real"
cl> rfits.offset=100
cl> =rfits.datatype
3.5.3 Resetting task parameters
Sometimes it is useful to UNLEARN or go back to the system default parameter
values for a task. It is also possible to UNLEARN all of the tasks for a particular
package including the parameter file for the package itself, if one exists. Note
that what UNLEARN really does is delete the appropriate parameter files from
the uparm directory!
cl> unlearn rfits # go back to system default parameters for RFITS
cl> unlearn dataio # go back to default parameters for all tasks in the
DATAIO package, including any package
parameters
images = Images
(fields = "image,npix,mean,stddev,min,max") Fields to be printed
(lower = INDEF) Lower cutoff for pixel values
(upper = INDEF) Upper cutoff for pixel values
(binwidth = 0.1) Bin width of histogram in sigma
(format = yes) Format output and print column labels?
(mode = "ql")
A simple way to execute IMSTATISTICS would be to use the "query" feature for
the required parameters (in this case the single parameter at the top of the list
that is not enclosed in parentheses). In this example the user simply types the
task name, is "queried" for the required parameter, and answers accordingly.
The current default values for the "hidden" parameters are used.
cl> imstat
Images: dev$pix
# IMAGE NPIX MEAN STDDEV MIN MAX
dev$pix 262144 108.3 131.3 -1.
19936.
The user can use the "query" feature and also change "hidden" parameters on
the command line at execution time. In this example the format parameter is
switched to no - note the syntax! The "=yes" and "=no" part of boolean
parameters can be specified with a "+" or a "-".
cl> imstat form-
Images: dev$pix
dev$pix 262144 108.3154 131.298 -1. 19936.
A task can also be executed putting all the parameters on the command line.
Note that this syntax uses the "positional" feature of the required parameters in
that these parameters must appear on the command line in the order that they
appear in the parameter list. It is not necessary to specify the parameter name
but only its value. Hidden parameters can also be specified on the command line
but since they include the name of the parameter as well as its value they can
appear in any order after the required parameters. Hidden parameters specified
on the command line are not learned; the command line values simply override
the defaults for that execution of the task.
cl> imstat dev$pix fields=mean,stddev
In this next example we extend the long command line to a second line with the
\e character. The break can come at the end of a parameter string, as in the
example, or after a comma in the parameter string itself (in this case no
preceding space is allowed).
cl> imstat dev$pix fields=mean,stddev,min,max \e
>>> format-
Of course, one can always run EPARAM on a task, modify the hidden parameters,
and then execute the task while not specifying any hidden parameters on the
command line.
cl> epar imstat
cl> imstat dev$pix
Another way to execute a task would be to run EPARAM on a task, modify all of
the parameters including the required parameters, and then execute the task
from within EPARAM with the :go command.
So there are many ways to execute tasks. Experience has shown that each user
has his own favorite style. Many new users to IRAF find that the EPARAM
technique mentioned just above is the most straightforward method for them.
3.6.2 Running tasks in the background
An IRAF task can be run in the background by ending the task execution
command line with an &. The following IMSTATISTICS command will run as a
background job. Since IMSTATISTICS prints information to the terminal during
its execution, by default, the terminal output is redirected to a new file with the >
sign (see §8.1. for more information on "redirection".
cl> imstat dev$pix form- > statfile &
If you do not specify all of the required parameters on the command line at
execution time the CL will stop and wait for you to respond, as in the following
sequence (the ">>" symbols are used to append to the statfile created earlier).
cl> imstat >> statfile &
[1] stopped waiting for parameter input
cl> service 1
Images: dev$pix
Background jobs submitted to UNIX hosts will continue to run even after the
user has logged out of IRAF and off the machine. VMS users must submit jobs to
a "batch" queue, as mentioned in the next paragraph, if they plan to log off the
computer before the job has completed properly.
Background jobs can also be submitted to batch queues, if they are supported by
the operating system. VMS is one such system. $ IRAF must be in the user's
login.com file on VMS hosts in order to submit jobs to the batch queues. IRAF
supports three logical batch queues - fast, batch and slow. See your local
systems manager for more on your local batch queues. In the following example
the task IMCOMBINE is executed with its terminal output being redirected to
the file logfile, and the job is submitted to the VMS "batch" queue.
cl> imcombine <filenames> check expos+ > logfile & batch
*There is a bug in VMS/IRAF that can cause problems with file names
containing capital letters. VMS users should avoid file names with capital
letters until this bug is fixed.
When we talk about IRAF data files it is useful to think in terms of three different
types of files: text (ASCII), simple binary, and image files. The discussion of IRAF
image files is left to the next section since these are files that require special
attention.
There are many tasks in the SYSTEMS package for working with text and simple
binary files. When working with image files it is better to use the tasks in the
IMAGES package.
The DIRECTORY task can be used to list files in the current or specified
directory. Wildcards can be used to search for a particular pattern. See §8.3. for
more on wildcards and file templates.
cl> dir # list current directory
cl> dir uparm # list files in "uparm" directory
cl> dir *cl* # list files with "cl" in the name
cl> dir login.?? # list files with "login." and any two characters at
the end
cl> dir *.imh # list all IRAF image files in this directory
Text files are used in many different ways in IRAF. They can be used as input to
some tasks and can be produced as output from other tasks, often as database or
log files. Terminal output from a task execution can be "redirected" to a text file
(see §8.1. for more on redirection). Text files can be edited using the EDIT
command in IRAF. Simple operations of text files (and binary files, where
appropriate) are done by many tasks in the SYSTEMS package.
Generally speaking the imtype variable only affects new images, i.e., those read
in with RFITS or some other reader. The output images from tasks will usually
inherit the imtype of the input images unless explicitly set, although this may
vary depending on the image format. (Again see Appendix C for further
discussion about other types of image formats.)
The OIF image format consist of two files: a header file (ending in .imh) and a
pixel file (ending in .pix). On UNIX hosts there is also a ".." file associated with
each .imh file that is used to protect the image from deletion accidentally with
the DELETE task (you must execute dir a+ to see these files).*
The image header has a finite length determined by the environment variable
min_lenuserarea. There is currently room for about 250 80-character records or
lines (20000 characters).
cl> show min_lenuserarea # show current value
cl> set min_lenuserarea = 40000 # set to larger value
The task HEDIT can be used to edit the header information, adding new
keywords and values or modifying existing ones. The task HSELECT can be used
to list selected keyword values from the image header. Try the following (the $I
in the HSELECT command assures that the image file name is listed as well).
cl> imcopy dev$pix newpix # make copy of \fIdev$pix
cl> hedit newpix newkey "string" add+ # add new keyword \fInewkey
cl> hselect newpix $I,newkey yes # list newkey value
cl> imdelete newpix # delete copy of image
The HDR$ and HDR$pixels/ logical directories are host independent directory
pathnames and will appear as such in the image header (.imh file). The other
examples are host dependent pathnames. Note the following headers produced
by executing
cl> imhead<imagename> l+ u-
• In this example imdir has been set to HDR$pixels/. The "[NO PIXEL FILE]"
comment after the pixel pathname is an IRAF "feature" - if you see the .pix
file in the pixels directory do not be fooled by this statement.
• In this example imdir has been set to a host dependent directory. If the
"[NO PIXEL FILE]" statement appears with the host dependent directory
name this is an indication that IRAF cannot truly find the .pix file. Note in
this example that the node name of the host machine is included with the
pixel pathname, tucana!<pathname>.
Generally speaking the IRAF core tasks produce the same pixel type on output as
that of the input image. The internal calculations may be done in reals or double
if complicated computations are performed on the input data, otherwise the
calculation type may also be done in the same data type as the input image.
Some tasks have parameters that allow the user to specify the calculation and
output pixel types. Let this be a caution to the user who has integer data: it may
be advisable to convert integer data to reals before doing any image processing
if disk space is not a concern, otherwise be alert to the possibility of truncation
or wraparound (large negative numbers suddenly appearing in the data).
Although a 1-d image can be represented by a 2-d image with one row/line or
column, it can also be represented by a vector with just one dimension. This has
been a popular format for 1-d data in the NOAO spectroscopic packages.
cl> imhead oned
oned[820][real]: FEIGE 98
An "image section", discussed in §8.2., can be used along with the task IMCOPY
to reduce the dimensionality of an image. For example, the output of this task
execution will be a 1-d vector image.
cl> imhead dev$pix
dev$pix[512,512][short]: m51 B 600s
cl> imcopy dev$pix[*,20] oned
cl> imhead oned
oned[512][short]: m51 B 600s
3.8.5 General image tools
A few general image tools will be highlighted in this section. It is important to
use these tools rather than the similar tools for text and simple binary files
provided in the SYSTEMS package since the image tools must deal with a more
complicated file structure (two files* rather than one).
*UNIX hosts really have three files associated with each IRAF image since
there is also the ".." protection file.
Three important tasks for image handling are IMCOPY, INRENAME, and
IMDELETE. IMCOPY makes a new copy of the input image. IMRENAME will
rename the current image. And IMDELETE will delete images. Using the
distributed image of M51, try the following,
cl> imcopy dev$pix newpix # make another copy of an image
cl> imrename newpix newcop # rename an image
cl> imdelete newcop # delete an image
The IMRENAME task has another useful feature besides simply renaming the
image. It also moves pixel files to the current directory specified by the
environment variable imdir. Thus whole directories of pixel files can be moved
using this task, and the image header will be updated properly to point to this
new directory. (Problems can arise with disconnected pixel files if these files are
moved with host level facilities. See Appendix D.) It is not necessary to actually
rename or move the headers to do this.
cl> set imdir=</tmp3/irafdir/> # set imdir
cl> imrename *.imh . # move pixel files to new imdir
The pixel values can be listed with the task LISTPIXELS. Note the use of "image
sections" in these examples. See §8.2. for more details. Again, we use M51 as our
input image. In the second example the output of LISTPIXELS is "piped" through
to the input of the TABLE task (in the LISTS package) for reformatting before
being displayed on the terminal.
cl> listpix dev$pix[20:25,30:32] # list the pixel values for an image
section
cl> listpix dev$pix[20:25,30:32] | table # list and reformat
There are other useful tools for dealing with images in the IMAGES package as
well as in the PROTO package. See Appendix A for a complete listing of the tasks
in these packages for the V2.10 release.
Each device that is available to you from within IRAF must have a workable entry
in this file. This file should be setup by your local IRAF systems manager; in
many cases it will only require a few modest modifications to a few existing
entries in the distributed file in order to have it work with your devices. At the
same time, your IRAF site manager should have modified the dev$devices.hlp file
so that typing devices will show the available local tape devices.
The general tools for tape handling are best demonstrated by examples. Tape
drives are accessed by the logical names defined in the tapecap file and not by
their host names. IRAF usually knows tape devices as mta, mtb, and so on. The
leading "mt" is important since it implies a tape device as the input/output device
and not a file name on disk.
cl> devices # list devices at your site
cl> allocate mta # allocate tape drive mta
cl> rewind mta # rewind tape drive mta
cl> devstatus mta # print tape status for mta
cl> deallocate mta # deallocate tape drive mta
The task DEVSTATUS will print the status of a tape drive, i.e., if it is available, if
it is allocated to another user, or if allocated to you what the current tape
position is. This information is obtained from a mtxxx.lok file that is created by
the ALLOCATE command in the IRAF logical directory tmp on the parent
machine of the device.*
*This statement is true for IRAF Version 2.10.2 and later; earlier releases of
IRAF Version 2.10 stored this file in the local IRAF tmp directory on the
user's machine.
The .lok file is updated after the completion of each IRAF tape task. IRAF must
know the correct posotion of the tape in order for subsequent tape handling
facilities to work correctly. When in doubt, REWIND the device first. Be aware
that a rewind at host level is not communicated to IRAF so it is possible to have
the actual tape position out of sync with the information in the .lok file. Again, a
REWIND at the IRAF level should put things back in sync. It is not a good idea to
abort tape tasks unless they have been submitted as background jobs (see
§3.6.2.). A Ctrl-C can leave things in a confused state and you may need to do a
FLPR; if this fails you may need to log out and back into IRAF (see §3.6.3). It
would be best to also REWIND the tape before executing any additional tape
tasks.
*The default density is set by a parameter in the dev$tapecap file and is site
configurable.
It is only necessary to be concerned about this when writing to a new tape; when
appending data to a tape the tape density is sensed and retained.
cl> allocate mta # allocate tape drive mta
cl> wfits mta6250 <image1> new+ # write one image to tape at 6250bpi
cl> wfits mta <image2> new- # append second image to tape
On a VMS host the density for a new tape must first be set at the host level by
writing a label on the tape before the tape is allocated in IRAF. The label must
then be overwritten by the IRAF tape writing task since labeled tapes are not
supported by IRAF. Again, this should only be done for a new tape; if there is
already data on the tape then subsequent data will be written at that same
density.
cl> !init/den=6250 mua1: label # initialize new tape to 6250bpi
cl> allocate mtb # allocate tape drive in IRAF
cl> wfits mtb <images> new+ # write images to tape
The following example shows a series of tasks that a user might execute to read
all the data from a FITS tape onto disk (assuming there are less than 999 files on
the tape!). In this example the output image names will be "n10001, n10002,
n10003....". The output pixel type (integer, reals, etc.) will depend on the type of
input data. Since this execution of RFITS can take awhile we have submitted the
task as a background job and redirected the terminal output (short header
listings) as well as any error messages to a file (see §8.1.) that can be later
reviewed or printed.
cl> show imdir # check location of pixel file directory
cl> diskspace # check to be sure there is enough space
for pictures
cl> allocate mta # allocate tape drive mta
da> rfits mta 1-999 n1 >& tlist & # read in all FITS images on the tape
da> page tlist # page through tlist
da> lprint tlist # print tlist to the default printer
A complete listing of a FITS header of one of the FITS files on a tape can be
generated as in the following example. In this example we are going to list all the
header information for the 35th FITS file on the tape and "pipe" this output to
the PAGE task for easy reading. Note the use of make_image=no or make- to
simply list the header but not write data to disk. The full listing of the FITS
header will be slightly different than that produced from IMHEADER for the
same image if it had been read onto disk since some descriptive keywords
defining the image format are not included explicitly in the IRAF image header.
cl> rfits mta 35 make- l+ | page
The output image type can be set explicitly when FITS files are read regardless
of the input format. Many users find it advantageous to read all data into IRAF as
"reals" to avoid any misunderstandings with the datatype later during
processing. In the following example the output datatype is set explicitly to
"reals" and only selected files are read in. Since short header information is
printed to the terminal by default, this output is redirected to a file to keep
things from getting messy on the terminal screen. In this example we do not
redirect any error messages so any messages of this type will be printed on the
terminal screen.
cl> rfits mta 1-10,30-56 dt data=r > dtlist &
The IRAF WFITS command writes the old disk image file name into the FITS
header using the keyword IRAFNAME. This keyword can be read by RFITS by
setting oldirafname=yes. In the following example we want to restore to disk
only certain images from a previous session that have been saved on tape. Keep
in mind that FITS files are read from tape by file position and not by image
name. So it is necessary to first list the tape along with the old IRAF image
name, then select the files we want to read, and then execute RFITS.
cl> rfits mta 1-999 make- old+ | page # list the tape by the IRAFNAME
image name
cl> rfits mta 20-25,45-47 junk old+ # read in images resetting the
output
image name to IRAFNAME
The user is not limited to reading FITS images from tape. RFITS will also read
FITS images that reside on disk.*
*VMS users should be aware that RFITS requires that disk files have fixed
length records.
In the following example we have a set of FITS images on disk called "fits001,
fits002, fits003..." that we wish to convert to IRAF images.
cl> rfits fits* 1 m31
If the FITS headers are unusually long it is possible that some of the keyword
information in the FITS headers (records) will be truncated and not be read into
the IRAF image header. An error will be printed: "Warning: User area too small
12 card images discarded", as an example. It will be necessary to increase the
image header size by setting the environment variable min_lenuserarea to a
larger number than the current default, and then read your images in again. The
current default for this variable is 20000 (equal to about 250 records).
cl> set min_lenuserarea=40000
Data can be added to a tape by setting the parameter new=no or new-. The
WFITS task will start writing at the double EOF written on the tape by the last
successful write, i.e., if WFITS aborts for some reason you may not have a double
EOF on the tape! In this next example let us set bitpix=32 to force autoscaling of
each image and set the blocking_factor=1*.
*The tape blocking factor default is set in the dev$tapecap file for each
device.
The terminal output from WFITS is appended to an already existing file. (See
&167;8.3. for more information on image templates.)
cl> wfits xred1??.imh mta new- bitpix=32 block=1 >> tlist &
In the example above we have changed the default values for two special
parameters, bitpix and blocking_factor. Thus WFITS issues a "warning" at the
beginning of its execution to that effect. This message is only meant to notify the
user that he has changed some important defaults and does not necessarily
indicate a problem.
WARNING: Default bitpix overridden.
Bitpix set to: 32
WARNING: FITS tape blocking factor is 1
WFITS allows the user to overwrite data starting at a particular file number on
the tape. In our example we will start writing at file 50. This syntax is invalid for
Exabytes since these devices do not allow overwriting in this manner. The IRAF
test image, dev$pix, has a pixel type integer so the FITS file will be written as 16
bit integer data, the default for this type of data unless specified otherwise.
cl> wfits dev$pix mta[50]
The user is not limited to writing FITS images to a tape device. FITS images can
also be written to disk.*
*VMS users should note that IRAF FITS images are written to disk as fixed
length 512 byte records.
In the following example the user writes the images m31red and m31blue to
FITS files on disk using the default IEEE floating point format. The disk file
names in this case will be fits001 and fits002. NOTE: disk names for files cannot
start with the letters "mt", otherwise IRAF will think the task is writing to a tape
drive!
cl> wfits m31red,m31blue fits
*This statement is true for IRAF Version 2.10.2 and later; earlier releases of
IRAF Version 2.10 did not support tar "tapes" but only disk files.
Three uses of the tar file format are noted here. Most of the IRAF external
software packages are distributed as source-only tar files allowing these
distributions to be machine independent, if they are read in by IRAF. Database
(ASCII) files produced by IRAF can be saved in a tar file, even if the user is using
a VMS/IRAF system; thus this backup is portable from one IRAF host to another.
IRAF images can also be saved in a tar file AFTER they have first been converted
to FITS file format on disk; these FITS files can then be tar'ed and moved from
one machine to another (tar'ing IRAF images directly is not recommended or
advised).
5. Plotting data
The general IRAF core system plotting tasks are in the PLOT package, although
graphics functionality is not limited to these tasks.
The STTY task must have been issued properly either at login time or later
during the IRAF session so that the graphics terminal type is known correctly by
IRAF (see §3.1.1.).
The current plot resides in a frame buffer. The upper limit of the size of this
frame buffer is determined by the environment variable cmbuflen. Complex plots
may appear with missing pieces; increasing the size of the frame buffer should
cure this problem. The GFLUSH command may need to be executed for this new
value to be used.
cl> show cmbuflen
cl> reset cmbuflen = 256000
cl> gflush
Plots sent to a hard copy device can be buffered for efficiency thus they may not
appear in hard copy form until they are explicitly forced out. This can be done in
interactive graphics
Cursor Mode Keystrokes (* = not yet implemented):
A draw and label the axes of current viewport
B backup over last instruction in frame buffer
C print the cursor position as it moves
D draw a line by marking the endpoints
E expand plot by setting window corners
F set fast cursor (for HJKL)
H step cursor left
J step cursor down
K step cursor up
L step cursor right
M move point under cursor to center of screen
P zoom out (restore previous expansion)
R redraw the screen
T draw a text string
U undo last frame buffer edit
V set slow cursor (for HJKL)
W select WCS at current position of cursor
X zoom in, X only
Y zoom in, Y only
Z zoom in, both X and Y
< set lower limit of plot to the cursor y value
> set upper limit of plot to the cursor y value
\ escape next character
: set cursor mode options
:! send a command to the host system
= shorthand for :.snap (make graphics hardcopy)
0 reset and redraw
1-9 roam
Cursor Mode Commands:
:.axes[+-] draw axes of viewport whenever screen is redrawn
:.case[+-] enable case sensitivity for keystrokes
:.clear clear alpha memory (e.g, this text)
:.cursor n select cursor (0=normal,1=crosshair,2=lightpen)
:.gflush flush plotter output
:.help print help text for cursor mode
:.init initialize the graphics system
:.markcur[+-] mark cursor position after each cursor read
:.off [keys] disable selected cursor mode keys
:.on [keys] enable selected cursor mode keys
:.page[+-] enable screen clear before printing help text
:.read file fill frame buffer from a file
:.show print cursor mode and graphics kernel status
:.snap [device] make hardcopy of graphics display
:.txqual qual set character generator quality (normal,l,m,h)
:.txset format set text drawing parameters (size,up,hj,vj,etc)
:.xres=value set X resolution (stdgraph only)
:.yres=value set Y resolution (stdgraph only)
:.viewport x1 x2 y1 y2 set workstation viewport in world coordinates
:.write[!][+] file save frame buffer in a spool file
:.zero reset viewport and redraw frame
mode by typing :.gflush. The task GFLUSH also "flushes" the frame buffer as
well as initializes the graphics system (the last plot will no longer be in the frame
buffer!). The CL performs a GFLUSH when you log out of IRAF properly (see
§2.3.).
The IMPLOT task is the major plotting task used for inspecting two-dimensional
data without using the image display (see IMEXAMINE for the image display
equivalent). It has its own set of cursor keystrokes (single lower-case letters and
":" commands) that allows a user to overplot line(s) or column(s) from the same
or another image plus other features that are unique to its operation. The user
should familiarize himself with this task since it is an important task in any data
reduction process. Note that the global set of cursor keystrokes are also
available as they are in all graphics tasks.
cl> implot dev$pix # plot center line of M51
? # list cursor keystrokes
q # quit cursor help
... # experiment with cursor keystrokes
q # quit the task
GRAPH is a versatile plotting task for non-interactive use. Input to GRAPH can
be either ASCII files or images. The user has a great deal of control over the axis
labels, thus GRAPH can produce nearly publication quality plots*.
*IRAF plots are not considered publication quality at this time; better fonts
and axis labelling control is needed.
As an aside, the CONTOUR task also has the capability of drawing into the image
display window for those sites that have a compatible image display (IIS model
70/75) or display server (IMTOOL or SAOimage). More information on this
capability can be found in the online manual pages for IMDKERN. This feature
will be expanded to other tasks in the future. In our example the full CONTOUR
task command line would not fit on one terminal line so we used the "\" to
continue the task to the next line, as mentioned in §3.6.1.
cl> display dev$pix 1 # display M51
cl> contour dev$pix \e # overlay contour on image
>>> xres=256 yres=256 perim- fill+ label- ceil=500 dev=imdg
The following tasks are useful for looking at or plotting metacode files.
A metacode file is distributed with your IRAF system and we will use it to
demonstrate these tasks.
cl> gkidir dev$vdm.gki # list the contents of the metacode file
dev$vdm.gki
cl> gkimos dev$vdm.gki # plot the metacode file in condensed form
on your terminal
cl> gkiextract dev$vdm.gki 2 | stdgraph
# extract and plot the second plot in
this file
cl> stdgraph dev$vdm.gki # plot all files to your terminal
cl> stdplot dev$vdm.gki # plot all files to your default plot device
Table of Contents Next: Using the Image Display Previous: Reading and
Writing Data
An image is always loaded into the center of the frame buffer, by default. If the
image is larger than the frame buffer only the central portion of the image will
be loaded. If the image is smaller than the frame buffer then a border will appear
around the image where there is no data.
Images larger than the frame buffer can be "squeezed" into this smaller frame
buffer while preserving the original aspect ratio. The following commands
demonstrate this capability.
cl> set stdimage=imt256 # set smaller frame buffer
cl> display dev$pix 1 fill+
Conversely, an image that is smaller than the frame buffer can be displayed so
that it fills the frame buffer by block replicating the pixel values. The following
commands will demonstrate this.
cl> set stdimage=imt1024 # set larger frame buffer
cl> display dev$pix 1 fill+ order=0
If you would like to set the intensity range used by the DISPLAY task rather than
accept the defaults, then the following execution of the task will prompt you for
the z1 and z2 values (the minimum and maximum intensity values to be mapped).
cl> set stdimage=imt512
cl> display dev$pix 1 zscale- zrange-
The sizes of the frame buffers can be changed in the workstation environment
but are fixed for the IIS and the Gould DeAnza. For IMTOOL and SAOimage the
frame buffer sizes are determined by the entries in the dev$imtoolrc file and the
similar entries in the dev$graphcap file.
As an example of displaying images in the workstation environment, let us
assume our images are 512 by 800. Thus we set the frame buffer size
accordingly and display an image. The size of the display window (IMTOOL or
SAOimage) may need to be adjusted to see the full image, or a panning option
available with both display servers could be used instead to roam around the
image within the smaller display window.
cl> gdevices | page
cl> set stdimage=imtcryo
cl> display dev$pix 1 # image not 512x800!
The DISPLAY task has many options and the user is encouraged to look at the
parameters and the online help pages for the task for further information.
While the user is in interactive image cursor mode the following "control"
characters can be used to control the image display, if the device or server
supports multiple frames or frame buffers (thus excluding SAOimage).
• Ctrl-F: go to the next frame
• Ctrl-R: go to the previous frame
• Ctrl-B: manually blink specified frames
CRPIX1 = 257.75
CRPIX2 = 258.93
CRVAL1 = 201.94541667302
CRVAL2 = 47.45444
CDELT1 = -2.1277777E-4
CDELT2 = 2.1277777E-4
CTYPE1 = 'RA---TAN'
CTYPE2 = 'DEC--TAN'
Most of the tasks in the IRAF core system have been modified so that they
recognize and use the world coordinate system information in the header and
update that information, when necessary. The tasks in the IMAGES package that
update the image header, as needed, are IMCOPY, SHIFTLINES, IMSHIFT,
MAGNIFY, BLKAVG, BLKREP, IMTRANSPOSE, ROTATE, IMLINTRAN,
REGISTER, GEOTRAN, IMSLICE, and IMSTACK. LISTPIXELS and RIMCURSOR
in the LISTS package have options for using the various coordinate information,
as do IMPLOT, GRAPH, PROW(S), PCOL(S) in the PLOT package and
IMEXAMINE in the TV package (these tasks read the logical coordinate system
by default). The task WCSRESET (in the PROTO package) can be used to delete
the physical or world coordinate system, and WCSEDIT (in the PROTO package)
can be used to modify or add coordinate system information.
Further user information about the WCS can be found in IRAF Newsletters
Number 9 (February/June 1990) and Number 12 (July 1992). Detailed technical
information can be found in the file iraf$sys/mwcs/MWCS.hlp. Users may find the
online help for WCSEDIT to be invaluable in understanding the WCS and the
associated keywords from the users point of view.
Some examples of a few common uses of the WCS may be in order at this time.
IMPLOT is a good place to start. This little exercise will demonstrate how to
switch the axes labels to the world coordinate system and reformat these labels
to a more readable form for RA and Dec.
The task LISTPIXELS prints the pixel values for an image; the coordinates of the
pixel values are also printed. In the following example we use this task to list the
RA and Dec associated with an image section.
cl> listpix dev$wpix[10:20,5:6] wcs=world format="%H %h"
The task RIMCURSOR reads the image display and returns the coordinate
position of the image cursor; this cursor value can be in any coordinate system.
In this example the RA and Dec values are returned in hh:mm:ss.s and dd:mm:ss.
The task WCSLAB will overlay a labelled world coordinate grid on an image. This
will work equally as well on a plot or on the image display.
cl> contour dev$wpix perimeter-
cl> wcslab dev$wpix dev=stdgraph append+
Table of Contents Next: Additional Interesting Topics Previo us: Using the
Image Display
The output of a task can also be redirected to the input of another task. This is
done with the pipe symbol,|.
cl> urand seed=5 | graph # redirect output from URAND to input of GRAPH
Graphics output that normally goes to the terminal can also be redirected to a
metacode file and plotted later with other plotting tools (see §5.). The symbols
for graphics redirection are >G and >>G (for appending). Note in the following
that in the last example the graphics is redirected to a special file called the null
file, meaning the graphics is actually discarded.
cl> contour dev$pix >G meta # redirect graphics output to new file
\fImeta
cl> surface dev$pix >>G meta # append graphics output to file \fImeta1
cl> gkidir meta # list contents of meta
cl> gkimos meta # plot \fImeta
q
cl> contour dev$pix >G dev$null # discard the plot
Redirection can also go the other way. A task that is expecting its input from the
terminal can have its input redirected from a file. A common use of this mode is
in the execution of a simple script task. In this example the CL itself has its input
redirected from a file.
cl> cl < <script.cl>
An image section can also be used to describe a new image that contains every n-
th pixel in that section. For example, the following execution of IMCOPY will
create a new image that has 25 columns and 30 rows.
cl> imcopy dev$pix[201:250:2,301:360:2] newim2
cl> imhead newim2
Not all tasks will accept image sections as part of the image name on output.
IMCOPY is one of the few tasks that allows this. This allows IMCOPY to be used
for generating mosaic images. The output image must already exist and be large
enough so that the output image section is defined.
cl> imcopy dev$pix newpix
cl> imcopy dev$pix[1:200,201:400] newpix[201:400,201:400]
cl> display newpix 1 # display, if possible
The image section can also be used to do simple image transformations. Some
examples using IMCOPY and IMTRANSPOSE are given below.
cl> imcopy dev$pix[*,-*] pix1 # flip the rows
cl> imcopy pix1[*,-*] pix1 # flip the rows in place
cl> imcopy dev$pix[-*,*] pix2 # flip the columns
cl> imcopy dev$pix[-*,-*] pix3 # rotate the image 180°
cl> imtranspose dev$pix[*,-*] pix4 # rotate the image 90° CCW
cl> imtranspose dev$pix[-*,*] pix5 # rotate the image 90° CW
The image section notation can also be used to select a "band" of a three
dimensional image, i.e., <imagename>[*,*,3].
In the last two examples above the "[]" are used to specify a range of characters.
This particular syntax can be confusing if the file names being expanded are
IRAF images, since this same syntax is used for image sections. See below, as
well as §8.2. and §8.4.
Image templates can be used as input to many IRAF tasks, but a more
sophisticated substitution syntax needs to be used to describe output image
names. In the following example the "n1" string in the input image name is
replaced with "n2red" in the output image name.
cl> imrename n1*.imh %n1%n2red%*.imh
A common error for many users is to try to execute the following. This will not
work! remember that templates require the file names to already exist, and of
course the "n2red" files do not.
cl> imrename n1*.imh n2red*.imh # NO!
There are two tasks that can be used to "test" templates. The FILES task can be
used on files in general, including image files when there is no image section
involved; the SECTIONS task can be used for image files that contain image
sections. These tasks simply generate lists of existing files that match the
template; no changes are made to any file names on disk.
cl> files *.imh # generate a list of all OIF image
files in the directory
cl> sections *.imh[200:233,100:800] # generate a list of all OIF image
files with appended
image sections
8.4 The @file
The @file (pronounced "at file") can be used for handling large lists of images for
input and output. The @file is a text file containing a list of images. The easiest
way to generate an @file is with the FILES or SECTIONS task. This is often the
preferred input/output to tasks rather than using templates directly. Since the
@file is a text file it can also be edited.
cl> files *.imh > inlist # generate list of images
cl> edit inlist # edit list as needed
cl> imstat @inlist # use list as input to task
cl> boxcar @inlist b//@inlist # use same list as input and output to
task;
output names will be the
same as input
names with a "b" prepended
cl> copy inlist outlist # make copy of input list
cl> edit outlist # edit output list to contain new names
cl> boxcar @inlist @outlist # use different lists for input and output
*See, also, the article Using and Customizing the EPARAM and EHISTORY
Editors, by Rob Seaman, in the IRAF Newsletter (Number 7, June 1989).
The HISTORY command will print out the last few commands executed (only the
information typed on the command line will appear). The number of commands
printed can be changed.
The EHISTORY command allows the user to edit and then execute a previous
command. When EHISTORY or just e is executed the user can then work back up
the history tree until the appropriate command is found. The arrow keys or the
Ctrl-[JK] keys can be used for this purpose. Simple editing can then be done
using the "left" and "right" arrow keys along with the "backspace" and "delete"
keys (modify to the left of the cursor). Both HISTORY and EHISTORY have online
manual pages for details.
cl> history # print out last few commands executed
cl> history 50 > histlog # redirect the last 50 commands executed to a
file
cl> e # call up the history editor
- use "return" to execute the task
after editing
cl> e rfits # edit last RFITS command - use "return" to
execute
There are also some quick recall commands. Some of them are demonstrated
below. These commands will be executed immediately unless the CL parameter
ehinit includes the string verify. (Yes, the CL has its own parameter file; type
lpar cl.) If ehinit has been modified then these commands will behave like
EHISTORY.
cl> history # print out last few commands executed
cl> ^35 # recall/execute command 35 from list
cl> ^rfits # recall/execute last RFITS command
cl> ^l+^l- # modify last command by replacing "l+" with "l-"
cl> ^rfits:p # recall and print only the last RFITS command
Beginning users may want to generate a log of the commands that they type
during their IRAF sessions for later review. And sometimes users will be asked
by the IRAF site support to turn on logging for assistance in debugging a local
problem. Logging is controlled by three parameters in the CL parameter file. See
the online manual pages for LOGGING for details.
(keeplog = yes) Record all interactive commands in logfile?
(logfile = "home$logfile.cl") Name of the logfile
(logmode = "commands nobackground noerrors notrace") Logging control
Check with your IRAF site manager for the status of IRAF networking at your
site. Setting up IRAF networking is described in the various site manager's
guides that each IRAF site manager should have in his possession. If you have
questions or problems in this area contact the IRAF site support for further
assistance. The task NETSTATUS can be used to see if IRAF networking has
been established for a particular host.
8.7.1 Syntax
Once you have established that IRAF networking is working at your site, it is
very easy to execute tasks using this feature. Let us assume that you wish to use
the tape drive on another computer (running IRAF) called orion. This tape drive
is known to IRAF as mta.
cl> devstatus mta # check tape status of mta on local machine
cl> devstatus orion!mta # check tape status of mta on \fIorion
cl> allocate orion!mta # allocate drive mta on \fIorion
cl> rfits orion!mta .... # read from tape drive on \fIorion
Similarly, directories and files can be accessed on orion by including the node
name in the directory pathname.
cl> dir orion!/scr3/richard/pixels/ # list files in remote
directory
cl> imcopy orion!/home/richard/n1005 pix1 # make new copy of image
n1005 in the current
directory
cl> set m51 = orion!/home/richard/ # define a logical variable,
\fIm51
cl> imcopy m51$n1006 pix2 # copy another image
IRAF networking can also be used to display images from another IRAF host. For
example, if you are remotely logged into the machine called orion and are
running IRAF on that host, you can display images from orion back onto your
local workstation using IRAF networking. You must be running a display server,
either SAOimage or IMTOOL, locally on your workstation. You will need to
identify the name of your local workstation to the IRAF session on orion.
cl> set node = <local_machine_name>
Users that are interested in writing scripts should see the document An
Introductory User's Guide to IRAF Scripts, revised by Rob Seaman, September
1989. The potential script writer should also familiarize himself with the tasks in
the LANGUAGE package.
Appendix A
The IRAF Packages
IRAF Version 2.10
(This list does not reflect any tasks added by the various patches to V2.10.)
• clpackage.clpackage:
• clpackage.dataio:
• clpackage.images:
• clpackage.images.tv.iis:
• clpackage.language:
Language components:
• clpackage.lists:
• clpackage.obsolete:
• clpackage.proto:
• clpackage.softools:
• clpackage.system:
• clpackage.utilities:
curfit - Fit data with Chebyshev, Legendre or spline
curve
detab - Replace tabs with tabs and blanks
entab - Replace blanks with tabs and blanks
lcase - Convert a file to lower case
polyfit - Fit polynomial to list of X,Y data
split - Split a large file into smaller segments
translit - Replace or delete specified characters in a
file
ucase - Convert a file to upper case
urand - Uniform random number generator
Note: Language package keywords are starred. To get help on a keyword enclose
it in quotes.
Appendix B
The NOAO Packages
IRAF Version 2.10
(This list does not reflect any tasks added by the various patches to V2.10.)
• noao:
• noao.artdata:
• noao.astutil:
• noao.digiphot:
• noao.digiphot.apphot:
• noao.digiphot.daophot:
• noao.digiphot.ptools:
• noao.imred:
• noao.imred.argus:
• noao.imred.bias:
• noao.imred.ccdred:
• noao.imred.ccdred.ccdtest:
• noao.imred.ctioslit:
• noao.imred.dtoi:
• noao.imred.echelle:
• noao.imred.generic:
• noao.imred.hydra:
• noao.imred.iids:
• noao.imred.irred:
• noao.imred.irs:
• noao.imred.kpnocoude:
• noao.imred.kpnoslit:
apall - Extract 1D spectra (all parameters in one
task)
apdefault - Set the default aperture parameters
apedit - Edit apertures interactively
apfind - Automatically find spectra and define
apertures
aprecenter - Recenter apertures
apresize - Resize apertures
apsum - Extract 1D spectra
aptrace - Trace positions of spectra
bplot - Batch plot of spectra with SPLOT
calibrate - Apply extinction and flux calibrations to
spectra
continuum - Fit and normalize the continuum of multispec
spectra
deredden - Apply interstellar extinction corrections
dispcor - Dispersion correct spectra
dopcor - Doppler correct spectra
identify - Identify arc lines and determine a dispersion
function
refspectra - Assign reference spectra to observations
reidentify - Reidentify arc lines and determine new
dispersion functions
sarith - Spectrum arithmetic
scombine - Combine spectra
scopy - Copy spectra including aperture selection and
format changes
sensfunc - Create sensitivity function
setairmass - Compute effective airmass and middle UT for an
exposure
setjd - Compute and set Julian dates in images
slist - List spectrum headers
specplot - Stack and plot multiple spectra
splot - Plot and analyze spectra
standard - Identify standard stars to be used in
sensitivity calc
doslit - Process slit spectra
demos - Demonstrations and tests
• noao.imred.specred:
• noao.imred.vtel:
• noao.mtlocal:
• noao.nproto:
• noao.onedspec:
• noao.twodspec:
• noao.twodspec.apextract:
• noao.twodspec.longslit:
background - Fit and subtract a line or column background
extinction - Apply atmospheric extinction corrections to
images
fitcoords - Fit user coordinates to image coordinates
fluxcalib - Apply flux calibration to images
identify - Identify features
illumination - Determine illumination calibration
reidentify - Reidentify features
response - Determine response calibration
setairmass - Compute effective airmass and middle UT for an
exposure
setjd - Compute and set Julian dates in images
transform - Transform longslit images to user coordinates
Many of the tasks in the NOAO packages are visible in several different
packages. Although these are the same tasks and provide the same functionality,
the default parameters are often set differently to account for different
instruments or uses.
Appendix C
IRAF Image Formats
IRAF supports several different image formats. The original IRAF format (OIF)
has been discussed throughout this document. A brief overview of the other
available formats will be give in this Appendix.
The STF (Space Telescope Format) is a fully supported IRAF image format. The
STF image has an image header file with a .??h extension and a pixel file with a
.??d extension. Both the header file and the pixel file are stored in the same
directory; the imdir environment variable plays no role. The header file is a text
file but can still be listed with the IMHEADER task. The STF image is not a
protected image and can be deleted with the DELETE task as well as with
IMDELETE.
The environment variable imtype may be set to the STF format so that all new
images generated by a reading task will be in this format. But as noted in §3.8.
the output image format for tasks will be the same as the input image format
unless explicitly set in the output image name, regardless of the value of imtype.
For example,
cl> set imtype = hhh # set image type to STF
cl> imcopy dev$pix newpixa # newpixa is OIF
cl> imcopy dev$pix newpixb.hhh # newpixb is STF
The QPOE (Quick Position Ordered Event) image format supports event (photon)
lists data. It is a read only format within IRAF. This image format can be
generated by special tasks in the XRAY package distributed by the Smithsonian
Astrophysical Observatory. The QPOE image is a single binary file with the .qp
extension. It is not a protected image file so it can be deleted with DELETE or
IMDELETE. Since the QPOE format is read only, the output image format is
determined by the value of the environment variable imtype, or the output image
extension. More information about this format is available in the technical paper,
Quick-POE (Position Ordered Event File) Interface Design, by Doug Tody, July,
1988. This paper can be found in the sys$qpoe/QPOE.hlp file in the IRAF system
or in the network archive.
Another format, not used extensively yet in the IRAF system, is the pixel list
format. This format has the .pl extension. It is a single binary file. This format
will be particularly useful in the future to create bad pixel mask files. The user
can generate a .pl file by including the extension as part of the output image
name. More information about this format can be found in the technical paper
iraf$sys/plio/PLIO.help, by Doug Tody, revised June 1988.
Appendix D
Fixing Pixel File Pathnames
If the IRAF image (OIF) pixel files have been moved to another directory other
than the one described in the IRAF image header, the image header keyword
"pixfile" will need to be modified to account for the new pixel file pathname
(which includes the node or machine name as well). These disconnected pixel
files can come about in a number of ways; the UNIX mv command may have been
used to move the pixel files to another disk, or the disk partition name may have
changed for some reason, as examples.
If only a few images need to be modified the task HEDIT can be used directly on
each image. In this example the node name was not entered as part of the new
pathname thus the host machine's name was automatically inserted when the
header was updated, as was intended.
cl> hedit
images to be edited: newpix
fields to be edited: pixfile
value expression: /tmp3/irafdir/newpix.pix
newpix,i_pixfile (tucana!/tmp3/jbarnes/newpix.pix -> /tmp3/irafdir/
newpix.pix):
newpix,i_pixfile: tucana!/tmp3/jbarnes/newpix.pix -> /tmp3/irafdir/
newpix.pix
update newpix ? (yes):
newpix updated
The task HSELECT will dump the file names along with the keyword values for
pixfile to the file "modlist". Now using your favorite editor modify the pixel file
pathnames in the file "modlist" so they point to the correct pixel file directory on
the proper node. Then execute the following.
cl> list="modlist"
cl> {
>>> while (fscan(list,s1,s2) != EOF)
>>> hedit (s1,"pixfile",s2,verify-)
}
The task IMHEADER will verify that the headers have been updated correctly
and that the pixel file pathnames have been modified, i.e., imhead *.imh l+ u-
| page.
Appendix E
The IRAF Network Archive
All IRAF distributions and associated documentation are available over the
Internet free of charge to all interested parties. The IRAF software has been
copyrighted but users are free to share their distributions with others, if this is
easier than obtaining individual copies. The IRAF network archive can be
accessed in the following manner.
% ftp iraf.noao.edu (or 140.252.1.1)
ftp> log in as anonymous
ftp> use your email address as the password
ftp> get README
ftp> quit
Appendix F
IRAF Layered Packages
Additional IRAF software is available to the IRAF user as layered or addon
packages. These addon packages are generally distributed as source only
systems and require an installed and running IRAF core system before the
addons themselves can be installed and executed.
Two major software packages are available as addon packages to the IRAF core
system from third party developers.
• STSDAS - developed by the SDAS group at the Space Telescope Science
Institute in Baltimore for the analysis of Hubble Space Telescope data
(email: [email protected]).
• XRAY - developed by the PROS group at the Smithsonian Astrophysical
Observatory in Cambridge for the analysis of X-ray data from the ROSAT
mission (email: [email protected])
Other contributed software from outside of NOAO can be found in the
iraf/contrib directory in the IRAF network archive (see Appendix E). See the
README file in this directory.
The directory iraf.old in the IRAF network archive contains a variety of addon
packages from NOAO, including a local package from CTIO. Some of these
packages are beta releases of IRAF software that will be included, after user
testing, in a subsequent IRAF release. There is no general README file in this
directory but there are "readme" files for each of the addon packages
themselves. The latest issue of the IRAF Newsletter is the best source for a list of
the currently available addon packages, or you can send mail to [email protected].
Appendix G
A Selected List of IRAF Documentation
IRAF Version 2.10
All IRAF documentation is available in the IRAF network archive in the iraf/docs
directory. A subset of these documents is listed below along with the associated
file names in the archive; this list was generated according to the document's
relevance to the latest release of IRAF, Version 2.10. Since new documents can
be added to the archive at any time please check there for an up-to-date list (see
the README file).
Introductory Materials
• A Beginner's Guide to Using IRAF (IRAF Version 2.10), Jeannette Barnes,
August 1993, beguide.ps.Z This Document!
• A User's Introduction to the IRAF Command Language Version 2.3, Peter
MB Shames and Doug Tody, August 1986, cluser.ps.Z (~85 pages)
• Preliminary Test Procedure for IRAF, IRAF Version 2.10, Jeannette Barnes,
revised May 1992, testproc2.ps.Z (14 pages)
Cookbooks and Guides
• A User's Guide to CCD Reductions with IRAF, Philip Massey, June 1992,
ccduser2.ps.Z (55 pages + postscript figures: large, 2+ M compressed)
• A User's Guide to Reducing Slit Spectra with IRAF, Phil Massey, Frank
Valdes, Jeannette Barnes, April 1992, spect.ps.Z (59 pages + postscript
figures: ~1.2 M compressed)
• Guide to the Coude Three Fiber Reduction Task DO3FIBER, Francisco
Valdes, April 1992, do3fiber.ps.Z (14 pages)
• Guide to the ARGUS Reduction Task DOARGUS, Francisco Valdes, April
1992, doargus2.ps.Z (17 pages)
• Guide to the Multifiber Reduction Task DOFIBERS, Francisco Valdes, April
1992, dofibers2.ps.Z (18 pages)
• Guide to the HYDRA Reduction Task DOHYDRA, Francisco Valdes, April
1992, dohydra.ps.Z (18 pages)
• Guide to the Slit Spectra Reduction Task DOSLIT, Francisco Valdes, April
1992, doslit2.ps.Z (16 pages)
• Guide to the Slit Spectra Reduction Task DOECSLIT, Francisco Valdes,
April 1992, doecslit.ps.Z (17 pages)
• Guide to the Fiber Optic Echelle Reduction Task DOFOE, Francisco Valdes,
April 1992, dofoe.ps.Z (15 pages)
• A User's Guide to Stellar CCD Photometry with IRAF, Philip Massey and
Lindsey Davis, April 1992, daophot2.ps.Z (69 pages + postscript figures)
Programming Guides
• A User's Guide to Fortran Programming in IRAF The IMFORT Interface,
Doug Tody, September 1986, imfort.ps.Z (27 pages)
• Specifying Pixel Directories with IMFORT, Doug Tody, June 1989,
imfortmem.ps.Z (1 page)
• An Introductory User's Guide to IRAF Scripts, revised by Rob Seaman,
September 1989, script.ps.Z (47 pages)
• An Introductory User's Guide to IRAF SPP Programming, Rob Seaman,
October 1992, sppguide.ps.Z (72 pages)
Other Useful Documents
• Table of Contents for IRAF Newsletters, TOC_news.txt (ASCII)
• Table of Contents for IRAF User Handbook Volume 1A, TOC210_vol1a.txt
(ASCII)
• Table of Contents for IRAF User Handbook Volume 2B, TOC210_vol2b.txt
(ASCII)
• The IRAF Packages, IRAF Version 2.10, glos210a.ps.Z Appendix A, this
document!
• The NOAO Packages, IRAF Version 2.10, glos210b.ps.Z Appendix B, this
document!
• IRAF Version 2.10 Revisions Summary, July 1992, v210revs.ps.Z (47 pages)