Introduction To IDL

Introduction to IDL http://www.astro.virginia.edu/class/oconnell/astr511/guide-bw.
html
1 of 22 12/14/04 12:01 AM
VERSION: JULY 2003 Click here for printable (B&W) version
A GUIDE TO IDL FOR ASTRONOMERS
R. W. O'Connell
Contents
I. Introduction
1. IDL in Context
2. IDL Applications Packages
3. IDL Limitations
II. Guide to Image Processing with IDL
1. The IDL Environment, Demos, Software List
2. Starting & Stopping IDL
3. Help
4. Program Execution
5. Image Retrieval
6. Image Display
7. Image Inspection & Manipulation
8. Image Storage
9. Image Photometry
10. ASCII Files
11. Database Access
12. Plots
13. Graphics Hardcopy
14. IDL Hints and Annoyances
III. Appendices
Appendix A: IDL Setup
Appendix B: Environment Setup Example
Appendix C: MOUSSE Startup File Example
Appendix D: X-Windows Notes
I. INTRODUCTION
1. IDL In Context
Interactive Data Language (IDL) is a proprietary software system distributed by Research Systems, Inc., of Boulder, CO (http://www.rsinc.com), now a division of
Kodak. IDL grew out of programs written for analysis of data from NASA missions such as Mariner and the International Ultraviolet Explorer. It is therefore oriented
toward use by scientists and engineers in the analysis of one-, two-, or three-dimensional data sets. RSI claims over 150,000 users.
IDL is currently available in UNIX, LINUX, Windows, and Macintosh versions for most of the popular scientific data processing platforms including Sun, HP, IBM,
SGI, PC's and Mac's (see list at http://www.rsinc.com/idl/detail.cfm). IDL device drivers are available for most standard hardware (terminals, image displays, printers) for
interactive display of image or graphics data.
The data reduction and display software that most astronomers are familiar with, including IRAF, STSDAS, AIPS, CIAO, MIDAS, and SUPERMONGO, consists
primarily of specialized, task-oriented routines not intended for customization or enhancement by the user. These mostly function like "black boxes" and do not
provide the user with easily understandable access to their inner workings.
By contrast, IDL is genuinely a versatile computer language, readily understandable by any computer-literate user. It offers all the power, adaptability, and
programmability of high level languages like FORTRAN, C, and C++. But it adds two capabilities which are essential for modern data analysis: interactivity and
graphics display.
In practice, IDL behaves like an inherently interactive, streamlined, graphics- and array-oriented version of FORTRAN. It is array-oriented in the sense that arrays
may be referenced without the use of subscripts or do-loops and that code is automatically optimized for array operations. A brief functional description of IDL is
available at http://www.rsinc.com/idl/detail.cfm.
IDL provides the scientist better understanding of and control over an interactive session by virtue of a large number of special features in addition to array-oriented
operations, including:
rapid response time, immediate access to all variables (stored in RAM), immediate access to all source code (except RSI-written proprietary routines),
on-demand compilation of routines, interactive session journal-keeping, command recall/edit, command scripts, data structures, flexible parameter
specification in subroutine calls, structured syntax, full integration with windows systems, support for all common scientific I/O protocols, versatile
built-in plotting and graphics routines, widgit and object-oriented programming, and a variety of special interactive support utilities.
Users who are conversant with FORTRAN, C, C++, or other high level languages will have little trouble understanding IDL. Its syntax and operation are transparent
and convenient. Because it is interactive, learning IDL through on-line trial-and-error is rapid. Without leaving IDL, test data sets can be created and displayed, and
programs can be written, executed, debugged, and revised with great efficiency. IDL code can be written in as little as one fifth the time of the equivalent
Introduction to IDL http://www.astro.virginia.edu/class/oconnell/astr511/guide-bw.html
2 of 22 12/14/04 12:01 AM
FORTRAN, C, or C++. Like these languages, IDL code is largely site-independent.
Five versions of IDL have appeared to date. Version 5 is now the standard.
2. IDL Applications Packages
[Up to Contents]
Because of its power, versatility, transportability, and ease of use, IDL has already become the basis of a large, user-written public library of interactive software,
now approaching 4000 programs.
How is this software distinguished from other packages available to astronomers?
FORTRAN, C, or C++ cannot satisfactorily serve the need for interactive data analysis because they do not provide a standard interactive environment with
supplied device-drivers.
IRAF, STSDAS, CIAO, and AIPS are interactive, but they operate only in a pre-compiled form which offers the user little opportunity for upgrade or
customization. These are primarily collections of task-specific routines. They can be executed from scripts, but they are not intended as the basis of user-written
applications. They are complex enough that professional programmers are required to maintain and enhance them. They adjust only slowly to user requirements.
By contrast, not only does IDL offer greater modularity, versatility and efficiency but also the whole computer-literate user community may be drawn on to
extend and improve IDL applications packages.
For those tasks (e.g. CCD data reduction) where the large astronomical reduction packages or stand-alone utilities such as DAOPHOT or SExtractor offer
powerful, reliable, and convenient packages for standard astronomical applications, these are the systems of choice. IDL should not be thought of as an
alternative there. Rather it should be used as a means of bridging the gaps in those packages and extending their capabilities.
Comparison with other popular systems:
MATHEMATICA, MAPLE, or MATLAB provide powerful interactive capability for mathematical computations and display. The first two of these also
offer symbolic manipulation and equation-solving, which IDL does not. However, these systems are more oriented toward mathematical analysis than data
analysis. They offer fewer capabilities than IDL for image display and processing, and they are less versatile for user-written programs and file I/O. They
offer none of the specialized utilities needed by astronomers (e.g. FITS file I/O, coordinate systems & astrometry, photometry and spectroscopy packages,
extinction laws and K-corrections, databasing, etc.). For an apples-to-apples comparison of these four systems in a variety of applications, see the
University of Colorado Applied Math page (http://amath.colorado.edu/computing/mmm/) .
SUPERMONGO and PGPLOT are widely-used packages for making graphical displays of previously-computed data. IDL offers comparable capabilities
but in the context of a fully programmable, high-level language, so that computation and display are simultaneously available.
Many astronomy-oriented IDL applications routines and packages are in the public domain. Early IDL packages were written at Goddard Space Flight Center for
analysis of images and two-dimensional spectra in support of the International Ultraviolet Explorer, Astro, and Hubble Space Telescope (GHRS and STIS) missions.
Other packages have been written by groups associated with Chandra, ROSAT, COBE, GRO, HST/NICMOS, HST/ACS, SOHO, ISO, SDSS, Los Alamos, Lawrence
Livermore, and NRL, among others. There is also a large body of remote-sensing and environmental research IDL software.
These packages contain many programs of general interest (e.g. statistical analysis, databasing) as well as specialized functions. All source code is automatically
available, so the user can use the routines as written or, alternatively, readily modify their components (as one would FORTRAN subroutines) to customize them.
Existing C or FORTRAN programs can also be executed from within IDL.
Unlike IRAF, STSDAS, and AIPS, there is no central distribution point for "authorized" IDL software other than the RSI-supplied intrinsic IDL language. However,
neither does one have to depend on a small cadre of expert programmers to fix bugs, explain program operation, or provide new capabilities.
IDL is ideally suited for software exchange over the Web. Because no pre-compilation is required, installation of a new package, for instance, is simply a matter of
putting the ASCII source files in your IDL path.
The built-in journal-keeping and command recall/edit features of IDL are so important to efficient and reliable data analysis that it is something of a mystery why
most other astronomical software packages do not offer them.
For examples of IDL computational and graphical applications, run the idldemo demonstration.
Sources of IDL applications code:
The IDL User's Library contains many routines of general interest and is made available with each IDL license.
The IDL Astronomy User's Library, maintained by Wayne Landsman at Goddard Space Flight Center, contains ovr 500 astronomically-oriented routines. See
http://idlastro.gsfc.nasa.gov/homepage.html for information and links to other important IDL sites.
Searchable directories of publicly-available IDL libraries can be found at the Astronomy User's Library (http://idlastro.gsfc.nasa.gov/idllibsrch.html) and also at
the University of Washington IDL homepage: http://www.astro.washington.edu/deutsch/idl/.
Useful links to local and remote IDL resources
Advice from the IDL users community is available through the comp.lang.idl-pvwave newsgroup and David Fanning's IDL Tips & Tricks, among other sites.
3. IDL Limitations
[Up to Contents]
IDL has many virtues, but what are its limitations?
An obvious limitation, and a significant barrier for some people, is that IDL is a proprietary system, which means that each site must purchase an IDL license. Some
astronomers object in principle to paying for software. But, needless to say, even our ostensibly "free" software packages like IRAF, CIAO, or AIPS++ carry a
tremendous community price, levied indirectly on us all. The purchase price of IDL must be weighed against the user effort necessary to obtain the same level of
performance by learning or adapting a less capable system. My own view is that since the most expensive element of any such system is always the scientist labor
3 of 22 12/14/04 12:01 AM
involved, the dollar investment in IDL is clearly justified. Current UNIX prices are comparable to 1.5 months of a postdoc's salary, and for that you get access to
perhaps 1000 person-years of good, astronomically-oriented software. One would have to have a very good postdoc not to consider IDL a bargain.
IDL is an interpreted rather than a compiled language. This means that large IDL programs will execute less rapidly than equivalent compiled programs written in
FORTRAN, C, or C++. However, this is also an important source of IDL's efficiency and versatility. Most scientist effort in data analysis is devoted not to large-scale
"pipeline" processing, where speed matters, but instead to interactive inspection, evaluation, and special cases---exactly where IDL excels.
IDL works best on moderate-sized data sets (say up to 100 MB) and where one does not need to reference individual array elements. Users needing to batch-process
large amounts of data with more sophisticated algorithms may find FORTRAN, C, or C++ routines to be preferable, though these can be linked into the IDL interactive
environment and executed from within IDL. That would provide the best of both worlds: computational efficiency in number-crunching combined with versatility and
convenience in display/evaluation.
Because of its optimization for interactive computing, IDL is not the system of choice for large scale numerical simulations. However, it is valuable as a medium to
explore new computational approaches in a smaller setting where raw speed is not important, and it is also excellent for visualizing, analyzing, editing, and displaying
numerical data sets generated by other programs.
A problem for novices is that help with IDL may be hard to come by at a new installation. There are, however, consultants available at RSI, Web-based advice sites, and
the examples of thousands of working IDL routines in the public libraries that can help solve many software difficulties. IDL's interactive operating environment makes
debugging much easier than is typical of data analysis software.
Data reduction packages are not available in IDL for most of the specific instrumentation available at the major observatories (e.g. for CCD mosaic imagery, multi-object
spectrographs, echelle spectra, etc.). But there is not any real reason to re-write good packages existing in other languages. For pipeline reduction of data from standard
instrumentation, where the needs of the typical user can be reasonably thoroughly anticipated, IRAF, STSDAS, AIPS and other existing packages are entirely
satisfactory. It is the data analysis phase, as opposed to the reduction phase, where the versatility of IDL is most useful. The IDL Astronomy Users Library supports the
standard data formats for STSDAS, IRAF, AIPS, and MIDAS, and can read and write FITS image or table files.
Finally, the rapidly proliferating set of IDL applications routines is both a strength and a weakness. While one has access to a wide variety of useful software, this is
not always fully tested since the authors typically apply it to problems of limited scope. The hardest part of using IDL often is determining what routines are available
for a given application and deciding which is best to use.
Overall, in exchange for its improved versatility and power, IDL requires a higher level of computer skill than do systems like IRAF, STSDAS or AIPS. The user must
take greater responsibility for the reliability of the results. On the other hand, IDL offers more robust and efficient trial-and-error exploration and ready tests of program
function on real or synthetic datasets. It is easier to diagnose difficulties and validate the proper execution of software in IDL.
On balance, IDL is an invaluable tool for most computer-literate observational or theoretical astronomers.
II. GUIDE TO IMAGE PROCESSING
WITH IDL
[Up to Contents]
This section provides an introduction to intrinsic IDL and user-supplied applications routines frequently used in 2-D image processing. Only the most common
options for each command are listed. Assumed are: UNIX, IDL V.5, and a SUN Workstation environment. Most of the listed non-intrinsic procedures are
Astronomy Users Library routines.
This guide is oriented toward the UVa/ASTSUN installation of IDL. However, I have tried to clearly distinguish details which are specific to the local system so that
others will be able to use the guide.
1. THE IDL ENVIRONMENT, DEMOS, SOFTWARE LIST
The IDL Environment
Once you start IDL and begin typing at your console, you are communicating with the main level of an arbitrarily large computer program over which you have
(nearly) complete control.
As you type, each line is interpreted and immediately executed. The commands you give are similar to those in a FORTRAN or C program, the main
difference being that each line must stand alone (you cannot, for instance, loop back to an earlier command).
You can dynamically create, modify, or delete data elements. Unlike FORTRAN and C, you do not have to define variable characteristics in advance.
Memory storage expands as needed to accommodate new variables. All types of elements possible in other languages (e.g. byte, integer, floating point,
strings, logical; 1-D, 2-D, and 3-D arrays; structures) are available.
You have full access to utilities for graphical displays on your computer terminal (images, plots, videos, widgits) and for file input/output in a wide
variety of formats, matched to standard printers and other auxiliary devices.
You have immediate access to a large suite of mathematical tools. For instance, most of the functionality of Numerical Recipes is available.
There is a sophisticated on-line help system.
You can execute previously written files of commands in the form of "main programs" or "procedures" (subroutines). These can use the full panoply of
programming structures (loops, blocks, common blocks, etc.) of any high level language.
You can also execute "scripts," files which contain lists of commands similar to those you would type in. Scripts and procedures can easily be created on
the fly by copying from your interactive session, using a journal utility.
People who are familiar with IRAF, STSDAS, CIAO, or AIPS will immediately recognize major new features in the IDL environment.
Most calculations with those packages begin and end with data stored as files, an artifact of the era when computers had very limited random access
memory capacity. Most commands therefore involved use of cumbersome unique file names. By contrast, all active data in IDL are normally stored in
4 of 22 12/14/04 12:01 AM
RAM, where one has immediate access and can examine, manipulate, rename, or reconfigure them at will without file transfers.
IDL conveys a "hands-on" feel, and a corresponding confidence that you know (or can find out) what is going on, that is largely absent in these other
systems.
Synthetic benchmark data sets can be quickly created interactively for reality checks on program execution.
Subroutine parameters and "keywords" replace, in a more streamlined way, the parameter files used in IRAF-like systems.
Using the built-in IDL journal-keeping facility, you can maintain an exact record of your commands and IDL responses...making it more likely that your
work is actually reproducible. Journal files are an efficient basis for crafting scripts or procedure code.
Using the built-in IDL command recall/edit feature, it is trivial to iterate commands, thereby reducing typos, facilitating exploration of parameter space, and
speeding repetitive tasks. This even allows the creation of recall-based mini-programs in lieu of scripts.
Unlike most other astronomy packages, which require extensive pre-compilation and linkage of software components, new IDL programs can easily be
incorporated during your interactive session. You can create a new capability in the form of a subroutine as quickly as you can think and type and then
link it into your interactive session with a single .run command. Similarly, you can download and instantly begin using IDL software you find on the
Web.
You can modify the functioning of any user-supplied routine (though not intrinsic IDL routines). Your ability to customize computations is enormously
enhanced in IDL.
IDL is oriented toward data analysis and signal processing, but by comparison to IRAF, etc. it also opens a new dimension of capability to make other
kinds of important numerical calculations with great efficiency and to create graphical or tabular representations of them. In this regard, it duplicates much
of the functionality of MATHEMATICA, MAPLE and MATLAB (though without symbolic manipulation).
Simple examples might include computing the volume element as a function of redshift in different cosmologies, calculating line shapes with simple
radiative transfer methods and comparing to observed spectra, simulation of Malmquist bias and other selection effects, generation of
bremsstrahlung or synchrotron spectra, and so forth. A great variety of such problems, for which (if they undertook a careful computation at all)
many astronomers would have written stand-alone FORTRAN or C programs, can be handled efficiently and beautifully by IDL and immediately
linked into associated data analysis tasks.
Basic IDL functionality has not changed for the last several major releases. Instead, additions have involved areas like GUI support and object-oriented
programming, which are directed more at software developers than users interested in data analysis.
Demonstrations: To get a feel for what IDL can do, try running the package of standard IDL demos supplied by RSI. Start from the UNIX prompt and type idldemo.
Tutorials: A set of introductory IDL exercises which introduce its basic features is available on the UVa ASTR 511 home page. Other sites offering IDL tutorials are
linked to the Astronomy User's Library.
Software List: Five different levels of IDL procedures and functions will be useful to you:
Intrinsic IDL: written by RSI, Inc. and described in the IDL manuals and online help system invoked by the ? command (V.5 1997-- ). Intrinsic IDL code is
proprietary. At UVa, intrinsic IDL is maintained by ITC on an all-University server. 50 users can have simultaneous access. Information on the UVa installation
is available here.
The IDL User's Library: routines of general interest (statistics, image conversion, etc.) verified and maintained by RSI but non-proprietary. Packaged by RSI as
part of the standard IDL distribution. By default, these are located in the directory $IDL_DIR/lib.
The IDL Astronomy User's Library: a large set of routines suitable for astronomical data analysis, image processing, and databasing, largely written by
scientists at Goddard Space Flight Center. Usually well documented internally and well verified in standard applications. Updates occur typically several times
per year. Code and other documentation are available through an Internet browser or FTP from http://idlastro.gsfc.nasa.gov. A listing of their purpose, sorted by
function, is available from the AstUseLib site. Updates are listed in reverse chronological order in a news file. The AstUseLib provides a large set of links to
other sites containing IDL software, advice, and tutorials. At UVa, the AstUseLib routines are stored in /astro8/idl/Astrolib.
MOUSSE (Multi-Option UIT Software System Environment): a set of routines largely written by the Ultraviolet Imaging Telescope team at GSFC. The more
generalized MOUSSE routines have been transferred to the AstUseLib, but MOUSSE still contains some convenient image processing routines not distributed in
the AstUseLib. You can obtain updated versions of these particular routines from: http://idlastro.gsfc.nasa.gov/ftp/contrib/landsman/mousse/ .
A PostScript file containing a list of MOUSSE routines as of 1996 (including those later transferred to the AstUseLib), sorted by function, is given in "Current
MOUSSE Software".
If you want a full set of the MOUSSE routines, a gzipped UNIX TAR file containing the most recent versions (through 2001) is available here.
Note: the STScI MAST archive distributes an older version of MOUSSE, ca. 1993, from http://archive.stsci.edu/uit/analysis.html. That has been
superceded by the versions in the TAR file.
Some MOUSSE routines employ special common blocks to track image displays, etc., so MOUSSE requires that a special "startup" file be executed (see below).
MOUSSE routines are self-documented. Older routines have not been updated since 1996 and may exhibit incompatibilities with more recent IDL releases, new
data formats, and so forth. Let me know if you encounter such difficulties. At UVa, Mousse software is stored in /astro8/idl/Mousse.
Personal routines, written by you. IDL users quickly discover the advantages of writing their own IDL procedures and functions. They may begin with scripts
of IDL commands, move to simple accelerator routines or customized modifications of user library routines, and ultimately write complete data analysis or
theoretical computational packages. It is convenient, though not essential, to keep all such routines in one directory. In this document, we refer to this directory
as your "idl directory." The UVa system default IDL environment file assumes that the directory will be named, or aliased to, idl under your home directory.
Acknowledgements: In any published work utilizing the Goddard software, the GSFC Astronomy User's Library group and Wayne Landsman should receive an
acknowledgement. Modified versions of this software should propagate the authorship list in the header section of each routine.
2. STARTING & STOPPING IDL
[Up to Contents]
5 of 22 12/14/04 12:01 AM
To enter IDL: type idl. This starts an IDL session running in "command-line mode" in the window from which is was called. In Version 5 you can instead use
a more elaborate graphical interface, the IDL Development Environment. To enter that, type idlde. IDLDE offers a number of convenience features for the
experienced user. The descriptions below are for the command-line environment invoked by idl.
Troubleshooting
If you get messages complaining about the "license server" or stating that you have been shifted into the "7 minute demo mode," then there is a
problem with the licensing software which authorizes individual users to access the IDL executables. This may be because too many users (at UVa,
more than 50) are trying to access IDL (in which case, you just have to wait). Alternatively, there may have been a failure in the license daemon
which authorizes you to link to the IDL source code. You will need systems-level help to address the latter difficulties. At UVa, IDL source code is
maintained by ITC on the server jeeves in directories under /net/jeeves.common/rsi.
If you have difficulty accessing certain routines, or the windows environment does not respond properly, check to be sure you have defined all the
necessary shell variables and aliases to point properly to the various IDL directories. See the "Setup" section at the end of this writeup. An
incorrect path is one of the most common sources of problems in IDL sessions.
If you log onto the UVa Astronomy network and do not specifically define any IDL environment variables, you will be automatically set up
to run IDL V.5 in the MOUSSE environment with proper links to all current software directories.
Your personal "idl directory", if you have one, will not be accessible unless you called IDL from that directory OR it is included in the IDL_PATH
C-shell environment variable. At UVa, this will be automatic if the directory is in your root directory and is named, or aliased to, "idl". (See the
environment setup file example below.)
This guide assumes you are executing IDL from within an X-windows environment. See "X-Windows Notes" at end of the writeup.
To customize the IDL environment (e.g. to create special windows for plots or establish main-level common blocks), you can execute special initialization files
at the start of each session. IDL will always execute the special "Startup" file defined in the $IDL_STARTUP environment variable. A standard version of this file
must be executed before the MOUSSE routines will run properly. This is done by default for UVa ASTSUN users. See the "Setup" section below.
You can also execute personal startup files to further customize your session. These are usually batch files (see "Program Execution" below), executed by
typing @[filename]
To give UNIX system commands from within IDL: enter $ as the first character on the command line
To interrupt and resume IDL: use the standard ^z and fg UNIX commands.
To interrupt an IDL routine: type ^c. If in cursor mode, you may have to move the cursor to the active window and press mouse buttons to complete the
interrupt. On some commands (e.g. array calculations or I/O) the interrupt may require some time to take effect. To continue the same routine, type .con. To exit
the routine after an interrupt and return to the main level, type retall.
To repeat or edit and execute an earlier command.
During an interactive session, your command line entries are stored in a command recall buffer (as in UNIX tcsh). You can use the "up arrow" ("down
arrow") keys to move backwards (forwards) thru the command buffer to recall or edit commands. Use EMACS-like editing commands (see Chapter 2 of
Using IDL). The default for the command buffer length is 20 commands. (It is useful to set this to a higher number by defining the system variable
!EDIT_INPUT=100 in the startup file. This is done by default in the MOUSSE startup files.) Recall/edit is an exceptionally useful means of iteration
during an IDL session.
In editing, be careful not to give the ^d command on an empty line, since this will terminate your session!
To continue a long statement on the following line: end the line with a dollar sign ($). You may do this anywhere in the line where a space would be allowed
except within a string variable. If you need to create a long string (e.g. in format statements), you can define pieces of the string on separate lines and then
concatenate them. (E.g. stringtot = string1+string2).
To give multiple commands on a single line: separate them with the ampersand (&). E.g.:
find=where(x gt 100, count) & print,count.
A small set of &-linked commands is a quick way to generate "micro-programs" which can be re-executed with a couple of keystrokes.
To leave IDL: type exit or ^d. All data and windows will be flushed. If you want to save data, use the save command or various other file writing
commands before exiting.
3. HELP
[Up to Contents]
Documentation: IDL is thoroughly documented in electronic and printed manuals. Regrettably, RSI no longer issues a full set of printed manuals with each license,
though PDF versions are made available. If the PDF versions have been installed on your computer system, they can be accessed through the UNIX command idlman.
The most important manuals are Using IDL, The IDL HandiGuide, Building IDL Applications, and The IDL Reference Guide. The on-line hyper-linked help facility (see
below) is good, if less comprehensive than the full manuals.
The current introductory IDL guide is called Getting Started with IDL---click for a PDF version. The printed versions of the older IDL Basics for V.3 and 4 take
you through a number of interesting sample applications and provide helpful hints.
The best way to remind yourself quickly of the operation of intrinsic IDL routines is to keep a copy of the printed IDL Handiguide at hand.
Learn by Example: One of the best ways to learn how to write and use IDL programs is simply to inspect existing IDL programs in the AstUseLib directories. You
can more them in UNIX, or use the AstUseLib getpro routine to copy them to your local directory. To view public routines during an IDL session, type .run -t
[routine name].
Browser Access: To access documentation for IDL_5.1 in HTML using a Web browser, click here. and bookmark the page.
IDL Links: Click here for links to other useful IDL resources
6 of 22 12/14/04 12:01 AM
Informational Commands
idlhelp: given from the UNIX prompt, this command invokes the RSI-written IDL HyperHelp graphics page.
idlman: given from the UNIX prompt, this command opens the PDF versions of the standard IDL manuals (if they are loaded on your system).
? : given from within IDL, this invokes the IDL HyperHelp graphics page. Lists a menu for the IDL manuals and descriptions of intrinsic IDL commands. If your
workstation does not support a GUI, information is provided in text form.
?[command] : provides HyperHelp information on the given intrinsic IDL command. Does not work for user-supplied routines. Note: no space (or quote mark)
between ? and name.
[command without arguments] : Most AstUseLib and other user-supplied procedures are coded such that if you enter the name of the routine without
arguments, a list of expected arguments is printed on your screen. Does not work for intrinsic IDL routines (but see help,/rou below). Does not work on most
functions (as opposed to procedures).
This is a useful convention to code into your own programs. Use the n_params function to sense the absence of input parameters, as in the following:
if (n_params(0) eq 0) then begin
print,'CALLING SEQUENCE: program-name,var1,var2,var3'
return
endif

man: The man command without arguments produces a graphics menu display similar to that generated by ? but which provides information on AstUseLib,
MOUSSE, and other user-written routines. man is a program distributed by Wayne Landsman from: http://idlastro.gsfc.nasa.gov/ftp/contrib/landsman/help/.
Note: the topics included are only those "pro" files which have been parsed by a special documentation extraction routine (mk_library_help) and
placed in a special help directory. This is usually done by the person who maintains your IDL system.
man,[command-name-string]: This version of the man command, in which you enter a string containing the name of the command you want information
on, prints the information header of the routine in your IDL command window. It works on any properly formatted IDL routine in the IDL_PATH. For instance, if
you want information on the AstUseLib STRD command, you would type:
man,'strd
Note that the argument of MAN must be an IDL string---i.e. it must be quoted (but the trailing quote mark can be omitted). If you already know the name
of the command of interest, this is faster and more convenient than using the graphics version.
The man function operates by finding the first file with the name "[command].pro" in the IDL_PATH and listing all those lines in the file between the
two lines starting with ";+" and ";-" in the first column. It is strongly recommended that you place headers of this type in your own *.pro routines. There
is a standard header format adopted by most IDL coders, though you do not have to follow this in your own routines.
Unfortunately, intrinsic IDL routines cannot be accessed by man.
$more [directory/command.pro] : lists any local program. You can define UNIX shell variables named $MOUSSE_DIR, $ASTUSE_LIB, etc, to point to
the appropriate directories to avoid having to remember which these are.
getpro,[command] : writes a copy of any non-proprietary procedure file to the current directory. Does not work on intrinsic IDL software. You can display or
edit the procedure to modify its function as desired. If you do not alter the name, and place it in the IDL path ahead of its original location, then your version
will be compiled and executed instead of the nominal one. It may be safer to change the name (both the file name and the procedure name within the file) to
prevent inadvertent errors.
Note: one deficiency of current user-supplied procedure documentation is that the dependencies (routines called by a given procedure) are not listed. If
you use getpro to obtain and edit a supplied routine to behave differently, this may have unintended consequences for the functioning of other
procedures. One method of looking for such interactions would be to grep the library directories for other references to the routine you intend to change.
A quick way to identify what subroutines are called by a given program is to .run the program as the first step in an IDL session. Each subroutine is
listed on the screen as it is compiled.
.run -t [command] : an alternative way of obtaining a listing of a routine. This will compile [command.pro] and simultaneously send a listing to the screen
with line numbers appended (same numbers as printed in IDL error statements, so is useful for debugging). To save the listing in a file, use the form: .run -l
(filename) [command].
print,[variable]: display the value of any active variable on your terminal. Works for any variable type, but beware(!) in the case of large arrays.
Formatting: row vectors are printed across the screen, column vectors are printed down the screen.
[Note: The printf command is used to send output to a selected file or other external unit.]
help : lists all active variables, their characteristics, active programs, information on storage areas, etc.; various options. But does not explain commands. There
are many optional keywords for use with help. Examples are given below. To get a full list, type ?help.
help,/rou : prints argument list for all active procedures. Lists procedure and functions separately.
help,/sy : prints current values of all "system variables", which are special variables known to all routines. Names of these begin with a "!", e.g. !dir,
!path, etc.
help,/rec : prints contents of command recall buffer in reverse order
help,/dev : prints parameter settings for current graphics device
help,/mem : lists current memory usage
print,!d or print,!p : print the system variables which control the device display and the plotting environment, respectively. See the IDL manuals for
details.
print,!path : print the current path list of directories searched for *.pro routines. Since many instances of failed or missing software occur because your path
is incorrectly set, it is useful to remember to check !path if you run into trouble. If the !path string is too long to print, use the strmid routine to make and
print extractions from it.
$ printenv : will list all default shell parameters, including the IDL directory defaults, if defined.
tvstatus : a MOUSSE routine that lists properties of active windows
7 of 22 12/14/04 12:01 AM
journal,[filename]: the journal utility records in a file all entries you make and most IDL responses. Certain responses (e.g. to help requests) are not
recorded to prevent cluttering up the file. Some user routines also disable journal output.
Any text you enter on a given line preceded by a semicolon will be included in the file as a comment (i.e. is ignored by the compiler), so you can
annotate your session on-line to your heart's content.
Your journal file will be written and closed when you type journal again or exit your IDL session.
If you edit out the blunders and undesirable clutter of your journal files, you will have a handy running record of your research.
It is hard to exaggerate the value of keeping IDL journal files for serious work. It is good practice always to use a journal file so that you can check
or reproduce what you have done, recover errors, and so forth.
Journal files permit rapid re-creation of an IDL session without having to write an independent main program, for instance. You can cut and paste between
a window with a more listing of a journal file and an active IDL command window to re-create the old session.
Alternatively, you can edit the journal file and save the result as a main program, subroutine, or script. Compared to the inevitably "blind" programming
with FORTRAN, C, or C++, the interactive environment of IDL coupled with its journal and command recall/edit facilities is a tremendously more
efficient way of writing reliable code.
Warning: the journal routine will overwrite existing files with the given [filename] without warning. Use unique names for each session. Also, the
journal file may be lost in the case of an IDL crash or a system failure (e.g. power outage). For long sessions, you may want to plan for more than one
journal file.
4. PROGRAM EXECUTION
[Up to Contents]
All intrinsic IDL programs are compiled and ready for execution when you begin your session. Other programs are normally compiled only when you request them. A
list of the latter is presented if you type help,/rou.
NOTE: all IDL procedures/functions are assumed to be in files with the explicit extension '.pro'.
.run [name] : compiles the IDL procedure(s) or function(s) in the file [name].pro. If this is a main program, also executes it.
IDL will locate the first file with this name in the IDL path. Beware of using names for your own procedures which are the same as those of intrinsic or
supplied library routines (unless you specifically intend to replace those).
You do not have to give a separate .run command in order to execute a routine which is in your path and has a file name identical with its procedure
name except for the '.pro' extension. Simply type the command's name, with all required parameters, and IDL will automatically search the path for such a
file and execute it. If the file name does not match the procedure name it contains, then you must .run the file separately.
You must re-run any command whose procedure file you have edited during your session or the revisions will not take effect.
You DO have to use a .run [name] command to execute a main program the first time. To re-execute, you can use .go.
The .run [name] command will compile but not execute a procedure or function file.
@[name] : Execute the "batch" file [name].pro containing a list of IDL commands in the same form as they would be entered from the keyboard. Each line is
executed separately so that multiple line commands involving do-loops etc. cannot be included. (But subroutines which are called from the batch file can, of
course, include such features.) Can be used to run a large background job, as a user-specific initialization file at the beginning of a session, or to duplicate a set
of commands (a "script") derived from an earlier IDL session. You can set up common blocks, compile procedures, and so forth in this mode. Text after a
semi-colon (;) on a given line is ignored by the compiler.
An efficient way to update or execute parts of a script---e.g. a command sequence captured using the journal utility---is to run an editor on the script in one
window while executing IDL in another and cutting-and-pasting snatches of code between them. This method is especially useful when you have a large
number of options you may or may not wish to execute (e.g. doing statistics, histograms, and plots on a data file containing many different variables).
.con : Continue a program interrupted by a pre-programmed stop command.
.go : Restart a previously compiled main program from beginning.
Main programs: a main program is simply a file of IDL commands which can be executed interactively by a .run command. They behave just as though you
were typing the same commands from the keyboard except that you have full access to multiple line entries, blocks, loops, etc, which can't be used from the
terminal. Main programs will recognize any variables or routines already active in your interactive session, and these remain active when the program completes.
Main programs cannot be executed by a procedure or function, however.
Main program files do not have a special header. Simply start with the first executable statement. A main program file must close with an end statement.
Procedures: IDL "procedures" perform like subroutines in FORTRAN. All inputs and outputs must be specified on the command line which calls the routine
(or passed through common blocks or IDL system variables). Procedures can be called from the main level or by any other procedure. Procedure calls look like
this (note the absence of parentheses):
PROCEDURE_NAME,input1,input2...output1,output2...keyword1=value1,$
keyword2=value2....
Parameters for input/output are separated by commas. If the parameter sequence is too long for a single line, break into several lines using the dollar sign
continuation convention (as here). Information can also be passed by common blocks or system variables.
Procedures (and functions) cannot recognize variables active in your interactive session unless they are passed as parameters, in common blocks, or as
system variables.
As in FORTRAN, ordinary parameters must be entered in the specified order. Trailing parameters can be omitted, if there are defaults for them coded into
the subroutine.
Keywords are parameters that pass information to subroutines, but unlike the standard parameters such as those listed in the preceding example
(input1,input2...output1,output2..), they are optional. They do not have to appear in the subroutine call, and if present they can appear in
any order. They therefore represent a powerful extension to the rigid subroutine call conventions of FORTRAN and are especially useful in the case of
complex interactive data processing subroutines. Values of keywords are usually determined by assignment statements:
8 of 22 12/14/04 12:01 AM
PROCEDURE_NAME,parm1,parm2.....KEYWORD1=100.,KEYWORD2='dumbo',...
Alternatively, in the case of switches, keywords can be set to a value of 1 by using the following syntax:
NAME,parm1,parm2...../KEYWORD1,.....
The keyword_set(name) function is used within a subroutine to sense whether a particular keyword was set by the user in the current call to the
subroutine.
IDL allows keyword "inheritance" such that keywords which may not actually be defined in the procedure declaration can be passed on to other
procedures that do recognize them. This adds considerable flexibility to writing interactive software.
Procedure files must start with a special header line, as follows:
PRO Name,parm1,parm2,...
and must close with a return and an end statement.
Functions: IDL "functions" perform like functions in FORTRAN. They return output to a single variable which appears on the left hand side of an assignment
statement:
result = FUNCTION_NAME(parm1,parm2...keyword1=keyword1...)
The parentheses are required, and parameters within them must be separated by commas.
Don't be misled by the format of the function call. Functions can return a large amount of information. The variable on the left hand side can be an array or
structure. The parameters can also be used to return output (as in the where function). Information can also be passed by common blocks or system
variables.
Note the potential confusion which can arise because the format of a function call is similar to an assignment statement involving an array on the right
hand side. In IDL V.5, the default format for specifying indices in arrays now uses brackets, rather than parentheses (e.g. array[i,j,k]), although V.5
still permits the use of parentheses. In older versions of IDL, the way to avoid confusion between arrays and functions is to pre-compile (non-intrinsic)
functions using .run before you compile any procedures which use them or attempt to use them interactively. You will get an "Undefined Variable" error
message if you neglect to do this.
Function files must start with a special header line, as follows:
FUNCTION Name,parm1,parm2,...
and must close with a return,[output] and an end statement.
retall : important utility which returns you to the MAIN program if an error occurs in a subroutine. The default in this case is to remain under control of the
subroutine (so that you can debug the routine by examining the current values of its variables, for instance).
The danger if you do not return to MAIN is that you will perform other tasks (e.g. reading in new data) under control of the subroutine but later exit the
routine, leading to the disposal of all such data. Type retall to escape the subroutine.
An alternative is to set on_error,1 at the beginning of a session, which automatically returns to the MAIN level after an error. on_error,0 sets the
default mode (stay in the subroutine).
You can check where you are by typing help, which prints your current location.
To create variables: simply use them in an assignment statement.
E.g.: name = "Maxwell"; z = 1.0e-8; testdata = findgen(512,512); etc.
To delete variables (e.g. when you have too much memory in use), use delvar. Another way to flush arrays is to simply set them equal to a scalar (e.g. a=0). If
you use a lot of files, it is also good to prevent file quota errors by occasionally giving a close,/all command.
If using the cursor, remember to place it on the active window (defined by the wset or chan routine); errors result otherwise. Return the cursor to the
command window when finished with cursor function.
Importing software. There are dozens of sites on the Web that distribute IDL programs. To use these, all you need do is download them, unpack (if necessary)
to source-file format (ASCII), and place them in a directory in your IDL path. You can do this before or during an interactive IDL session (though you cannot
change your IDL path during a session). The path-search protocol described above under the .run command will then locate and execute the program when you
ask for it. You must, of course, be sure you have all the programs called by the new software also in your path.
5. IMAGE RETRIEVAL
[Up to Contents]
Data transfer to memory: During an active session, IDL maintains relevant data in random-access memory, stored in variables with arbitrary names chosen by the
user. The first step in IDL image analysis is normally therefore to read image data files from disk storage into IDL variables. These variables can be manipulated at
will using arithmetic, extraction, compression, expansion, renaming, conversion, and a multitude of other built-in and user-supplied functions. This is in contrast to
IRAF/STSDAS, where there is no intermediate data storage, all manipulation involves files, and one must refer to images by their file names at all stages in the analysis
process.
sd,[directory] or cd,[directory] : change directory to the image directory, like cd in UNIX. The directory name must be a string--i.e. it must be quoted,
unless it is a pre-defined string variable. Example: sd,'datadir (the trailing quote mark can be omitted). sd, without an argument, is equivalent to $pwd. Note:
a $cd command to the shell will not change your default IDL directory.
dir, fitsdir, stdir: list directory contents in various forms; the latter two routines list FITS files and SDAS files, respectively.
strd,[image variable name],[header variable name]: routine to read an SDAS image and header file from disk into current variables in memory. A
pop-up menu window appears listing headers available in the current directory. Alternatively, enter the file name as a string (extensions not needed) as the third
parameter. Image and header files must be in SDAS format (extensions .hhd and .hhh respectively). Use normal UNIX conventions for identifying the files in the
directory tree (current directory is default).
Example: strd,m87,hdm87,'m87_nucleus'
9 of 22 12/14/04 12:01 AM
reads the image data in the SDAS image file m87_nucleus.hhd in the current directory into active variable m87 and the corresponding header file
(m87_nucleus.hhh) into active string array variable hdm87. m87 will have the characteristics (byte, integer, float, etc.) of the *.hhd file.
If the header does not contain parameters which properly match the file (e.g. NAXIS, BITPIX, DATATYPE), then an error message will appear. However,
you can create a dummy header which does match the data in this case and store it on the image directory; see "Image Storage" below.
FITS file information utilities:
To obtain a brief file description from the header of a FITS file on disk without reading the entire file, use fits_info. This can be important to confirm
the type of file (image, table, etc.) you are dealing with.
To read the full header of a FITS file (without reading the data) into an IDL variable use headfits. You can display the contents of the header with either
the print or hprint commands (the latter intended for FITS headers). headfits will work on compressed files (*.Z or *.gz).
E.g.: hprint,headfits('m87_nucleus.fits.gz')
fits_read,[filename],[image variable name],... : read a FITS disk file into IDL image and header variables.
Example: fits_read,'m87_nucleus.fits',m87,hdm87,/noscale
The noscale keyword used here prevents the (default) automatic scaling that converts the image values to fluxes using calibration parameters in the
header. For many purposes, the scaling is a nuisance.
fits_read can handle extensions and groups in FITS files. There are several alternative sets of routines for reading/writing FITS files, but fits_read is
the best current choice for HST data sets for instance. See http://idlastro.gsfc.nasa.gov/ftp/pro/fits/README for more details.
There is an entire suite of Astronomy User's Library routines to read, write, or manipulate FITS ASCII or binary tables. For instance, to read a FITS file
containing a binary table of sources and extract coordinate information:

fits_read,'sources_file.fits',table,hdtable
tbhelp,hdtable ; List contents of each field
; from the header
; Extract RA and DEC information, based on
; tbhelp listing:
rad = tbget(hdtable,table,1)
decd = tbget(hdtable,table,2)

irafrd... : like strd, but reads IRAF disk images (extensions .pix and .imh).
hprint,[header variable]: print header to terminal.
FITS header keyword extraction/manipulation: There are many commands, mostly starting with the prefix sx, which permit extraction and manipulation of
FITS keywords.
For instance, to extract and print the name of a target from a FITS image header:
targ = sxpar(hdm87,'TARGNAME') & print,targ.
To add a history comment to a FITS header variable:
sxaddhist,'22 AUG 99: Subtracted mean sky background',hdm87
Other formats: IDL users have produced IDL routines to read most of the other standard image storage formats. See: read_gif, read_jpeg, read_srf,
tiff_read, etc. There are corresponding write routines for all of these.
6. IMAGE DISPLAY
[Up to Contents]
General:
There are two steps in displaying an image on your computer screen.
First, you must transfer the image to a buffer. For a pseudo-color display (the most widely available), the buffer is only one byte deep (values between 0 and
255); it matches the display window in format. This transfer usually involves scaling between the values in the original image and the buffered array.
Second, you must define the color lookup tables which convert between the byte values in the buffer and the displayed intensities (and colors) on the screen.
In a pseudo-color display, color tables are three vectors, each 256 elements long, containing values between 0 and 255. The three vectors R,G,B determine
intensities in the red, green, and blue guns, respectively, on your computer display. If a given pixel in the buffer contains the value n, the three guns at that
pixel are set to the values [R(n),G(n),B(n)].
The resulting appearance on your computer screen therefore depends both on the array values and the color tables. Most of the standard display commands (e.g.
ctvscl) transfer scaled data to the image buffer and then display the buffer with previously-defined color tables.
For a "grey-scale" set of color tables, R(n)=G(n)=B(n). For a color display, the three vectors contain different entries. However, there is a direct correspondence
between the intensity values in the buffer and the color which appears on the screen. Although it does not add fundamental information, pseudo-color display of a
1-byte buffer can be very useful in exploring different brightness levels in a complex image. True-color displays require the equivalent of three image buffers, each
feeding a color gun independently.
The default color table is a linear grey-scale runnning from 0 to 255.
The command to change ("load") the individual color tables is tvlct,R,G,B, where you must have defined the three vectors beforehand.
To capture the current color tables to vectors (e.g. to inspect them or as a basis for revising them), use tvlct,rr,gg,bb,/get.
10 of 22 12/14/04 12:01 AM
A set of 41 predefined color tables is supplied with IDL; these can be loaded with the loadct,N command. The default grey-scale is loaded by the command
loadct,0.
The human eye cannot really distinguish 256 levels of either grey scale or color, and astronomical images usually contain much more than a 256:1 intensity range.
Therefore, the hardest part of displaying images is selecting those ranges you want to display and making them distinct on the screen. Intrinsic IDL and the user
libraries provide a variety of tools for doing this. Once you have made a good visible display, transferring it to hardcopy such that its quality is preserved is yet
another challenging step. See Graphics Hardcopies below.
Color Display Technical Issues:
The number of available colors: On your workstation, the number of "shared" color values available for IDL to use will normally be less than 256. Other
values will have been reserved by other applications (X-windows, Netscape, CDE, Acrobat, etc). If you have an 8-bit display, the maximum number of colors
available for all applications is 256. When IDL is invoked, it will normally be able to obtain only a fraction of these, say 215, for its use from your windows
manager. The number will vary depending on the number of competing applications. The standard transfer and display routines like ctvscl and tvlct take
this into account by using the smaller number of color levels but adjusting them to the full dynamic range possible on your terminal display. For instance, the
color tables may be only 215 elements long, but these will range in value from 0 to 255. The number of colors available is contained in the system variable
!d.n_colors or can be displayed with help,/dev---but only after the first IDL window has been opened on your terminal.
"Color Flashing:" if the rest of your terminal display blinks out or changes color when you move the cursor into an IDL window, then IDL is using a "private
color table" which gets applied to your whole screen when the cursor activates it. This probably means IDL is attempting to use more colors than were free in the
shared color table. To ameliorate the problem, try this:
Exit IDL
Restart IDL
As the very first two commands, type:
device,pseudo_color=8
window,0,col=k
...where k is the minimum number of color levels you think you will be able to use (probably not more than 100).
For more information on IDL's use of color displays, see http://www.dfanning.com/documents/tips.html#UsingColors.
Commands:
Note: The routines chan,cdel,ctv,ctvscl described below are MOUSSE versions of the intrinsic IDL routines window/wset/wshow,wdelete,tv,tvscl,
respectively. They have several important convenience features (e.g. rescaling of window sizes to the image size, combination of the window set and show functions,
etc.) and make use of common blocks which can be accessed by other routines. To use these routines, you must run the Mousse Startup File (see Appendix C).
chan,n: select window n for display. This becomes the "active" window, i.e. available for I/O. The cursor will only work on the active window. Creates the
window if it did not exist before. n can be between 0 and 31. [Although a display window will be automatically opened by any display procedure the first time
it is called, you should use the chan procedure first if you want to take advantage of Mousse functionality. It is also a good idea to keep plotting and image
display windows separate.]
cdel,n: Delete window n. You can also quit or close (i.e. iconify) windows during an IDL session by using the regular window manager functions.
ctv,image: display image in current window (or window 0 if no other window has been opened) without scaling by transferring image pixel values directly to
the window buffer. The image buffer will contain byte(image)---i.e. values between 0 and 255 only---and will "wrap" for values of 256 and higher. Only N
different values can be displayed, where N is the number of color levels possible (!d.n_colors). [N on a black-and-white display is 255. On a color
workstation, N depends on the number of display levels IDL was able to acquire from your windows manager and is usually in the range 210-245.] Among
other things, ctv can be useful for locating low contrast data in an image with a large dynamic range.
ctvscl,image: as for ctv except that the buffer values are scaled linearly between the sky value (set to screen pixel value 0) and a high point determined by
the variance of the fluxes in the image. There is no wrapping. The maximum number of color levels displayed on the screen is !d.n_colors. ctvscl is
generally much more useful than ctv.
If you don't like the defaults, you can specify the high and low values by using the optional keywords max and min. E.g.
ctvscl,m87,min=30,max=8000
[From this example you can see the advantages of rescaling images to convenient values in the range 0 to a few thousand rather than using actual
flux values. To rescale, use commands like m87 = 1.0e15*m87. In fact, if the quality of the display is your only concern, there is no point in
retaining actual flux values in your working image set. Just remember not to use the scaled image for computations where the units matter.]
ctvscl is one of the most used routines in image processing; it has a number of other options you should become familiar with.
loadct,[n]: load pre-defined color table set n. n=0 to 40. 0 = B&W (and is the default if no color table is explicitly loaded). The other tables are all varieties
of pseudo-color transformations.
The appearance of images will change dramatically depending on the color table and contrast settings. There is a set of about 20 routines to adjust or
customize the color tables.
There are various ways to reverse the standard white-on-black color table 0 to the black-on-white sense preferred by astronomers, which is more sensitive
to faint features. One is the following; another is to use contrast.

loadct,0
tvlct,rr,gg,bb,/get
rr=reverse(rr)
tvlct,rr,rr,rr
contrast: A MOUSSE routine which interactively adjusts, using the cursor, the color tables without affecting entries in the image buffer. Adjusts a linear
transform function in zero point and slope. The appearance on the screen of the result of contrast is identical to specifying the MIN and MAX parameters in
ctvscl, although the means by which this is achieved is different. The cursor must be placed in the current active window.
Note that on workstations, changes in the color tables apply to all image display windows. In order to compare images with different ranges of values,
load them using ctvscl or the equivalent with different low/high windowing cuts or with non-linear transforms (see below) before using contrast.
Color tables adjusted by contrast remain in effect unless they are explicitly reset (e.g. by using the loadct command). If a new image looks strange, it
may be because you have forgotten to reset the color tables.
You can "flip" the color table using the mouse buttons during contrast.
11 of 22 12/14/04 12:01 AM
Note that the type of linear transformation between the image value and the display value adjusted by contrast is only one of a very large set of
possibly useful transformation functions. You may want to experiment with various logarithmic, powerlaw, segmented, and other types of transforms to
find the best display for your image.
refscl... : A MOUSSE routine which displays a reference scale for the current color tables. Shows the response of the display to a buffer containing a linear
range of values between 0 and 255. Setting keyword over places the scale in the current window. Useful when making fine adjustments in color tables and in
making images for publication.
Other useful displays:
To display logarithmically stretched images: ctvscl,alog10(image). Obviously, you need to insure that image does not contain zero or negative
numbers. A quick way to truncate low values in this kind of command is to use the syntax alog10(image > k). where k is a scalar. The notation (x >
y) means "the maximum of the pair x,y."
Use a pre-defined lookup table to transform image values, e.g. to their logarithms. Faster than actually converting values using the alog function. E.g.:
for integer image arrays with values in the range 0 to 1000, try this:

t=findgen(1000) & t(0) = 1
quiklog=alog10(t)
ctvscl,quiklog(image)
Note: In IDL, the form array1(array2) returns the values of array1 in the elements specified by the values in array2. array2 must be an integer or
longword integer array.
The same technique works with other forms of nonlinear displays: e.g. power laws with fractional exponents (0.3, 0.5) to increase dynamic range;
arctangents, etc.
To display a smoothed image in one line: ctvscl,smooth(image,5).
image=tvrd() : Read the (byte) contents of the active window buffer into an image variable. Note the empty parentheses (if you wish to copy the whole
window). Often useful in the process of making hardcopies of graphics displays. Warning: make the desired window active first, by using the chan,N
command, and be sure the window is fully visible on your terminal screen before calling tvrd.
tvrd is useful in preserving the appearance of an image after you have used contrast or another color table adjustment routine. You may wish to save
the resulting image so you do not have to adjust it manually in the future. For black and white images, do the following. First, copy the buffered byte
version of the displayed image as follows: pix=tvrd(). Then, save the color tables with tvlct,rr,gg,bb,/get. Then, transform the copied image
with new = rr(pix); this reproduces what you saw on the screen. To display the result, simply ctv,new, being sure to reset the color tables to their
default values.
blink,windowlist : blink between windows. Windowlist is a vector containing numbers of windows to blink (in order). E.g. blink,[0,2,1]. To compare
different exposures of the same field (e.g. two different filters), you will want to adjust the scaling of the two independently with ctvscl before calling blink.
To terminate, you must type in the command window, which may require you to use the window manager to bring it up. Blink rate is adjustable.
tvbox...; tvcircle...; tvellipse...; etc : draw various shapes in active window, e.g. to locate point sources identified by other routines. To remove
these, you must re-load the image in the window. Adjust the color or darkness of the overlays by using the color keyword.
xyouts... : write text to active window. To remove, you must re-load window.
curs,type : select graphics cursor type
To read the cursor position on an active window: use the cursor routine.
set_plot,[device-name] : allows you to change the current output device. On a Sun workstation, you will normally be using X-windows graphical
output, for which the command is set_plot,'x. (This will be set by default when you begin your IDL session.) If you are using VT100 or Tektronix-type
terminal emulation, you should type set_plot,'tek before using graphics commands. The only other output device type you would commonly deal with is a
PostScript file. You can switch output to a PostScript file by typing set_plot,'ps . Return to X-windows by typing set_plot,'x . (The chan command
automatically returns you to the X-windows default.) You can determine the currently assumed device parameters by typing help,/dev.
The ATV Image Display Tool
ATV is an IDL widgit-based display program which combines much of the functionality just described with many of the image inspection capabilities described
in the next section. Its appearance and behavior is like SAOimage (example here). It was written by Aaron Barth. It's a quick and easy way of inspecting images
and doing rough analysis like getting FWHM's and brightnesses of sources. Oriented toward CCD data.
At UVa, ATV software is kept in /astro8/idl/atv and is included by default in your IDL path.
ATV Links
General info (Caltech)
Instructions on how to use ATV
7. IMAGE INSPECTION & MANIPULATION
[Up to Contents]
Inspection:
print,max(a); print,min(a); print,minmax(a); print,mean(a); print,variance(a); print,median(a); print,moment(a): print
various statistical properties of image array. (moment prints first four moments.)
curval,image : read off image values in each pixel interactively with cursor in current window. Option to convert to fluxes, RA, DEC using the image header.
tvlist,image : prints matrix of image values in vicinity of cursor location in current window. Options to write to file. imlist is similar, but coordinates are
typed in (does not use the window/cursor).
12 of 22 12/14/04 12:01 AM
zoom : displays an enlarged segment of image in current window centered on cursor. Middle mouse button changes zoom factor. Right button exits. Works by
copying currently displayed window buffer, not original image values. Zoomed window vanishes on exit. Keyword /continuous can be used to follow the
motion of the cursor, but you may want to restrict the region displayed, depending on the speed of your computer.
To extract and examine a subarray, you can use standard IDL array notation. E.g.
part=image(100:200,150:250)
extracts a 101x101 subarray from the image.
To enlarge (or compress) an array: new=rebin(image,N,N). N must be an integer multiple of the current dimensions of image, (assumed square here).
Compression is needed with images which are too large to fit on your CRT display (typically limited to about 1000x900). Packages like ATV and SAOIMAGE do
this compression automatically (but possibly in a non-optimal fashion).
For magnification, add the keyword /sample if you want to preserve the original pixel structure. This substitutes nearest neighbor sampling for the
bilinear interpolation which is the default.
To regrid an image to non-integer multiples of its original format, use frebin or congrid If you intend to make flux measures from the compressed or
expanded images, be sure to check that the routine you used has conserved flux in a given region of the original image.
To plot a column: plot,image(N,*).
To plot a row: plot,image(*,N).
To interactively select & plot rows or columns with the cursor: use profiles. (Plot scaling needs work).
To plot the mean of 5 adjacent columns: plot,avg(image(c0:c4,*),0). For 5 adjacent rows: plot,avg(image(*,r0:r4),1).
To extract an image slice with arbitrary start and end points (selected by the cursor from the active window and marked with "rubber band"):
slice=profile(image). You can then plot the extraction.
To estimate the background level, use sky.
sky works by estimating the mode of the image values. It therefore assumes there are many more pixels near the sky background level than there are
source pixels. It will not work well in the case of very low sky backgrounds where the sky histogram is not smoothly continuous.
surface,image: produces surface plot (projected 3-D) of image. Slow for larger images, so test on extractions. See the IDL manuals for many enhancements
available in surface plotting.
plothist,image: evaluate histogram of pixel values in the image and plot the result. The default histogram runs from the minimum to the maximum of the
array. But it is assumed that the array contains integer values, and the default bin size is 1.0 unit. Beware when the array contains erroneous values which are
very large or very small. Optional parameters adjust cutoffs and binning.
contour,image: plot a contour diagram. To specify the contour levels, use the levels keyword. E.g. to plot 10 contour levels at values of 25, 50, 100,
200...:
nup = findgen(10)
clev = 25.*2^nup
contour,image,levels=clev
Flagging values in given range: use the where function. E.g.: to highlight pixels containing a -666 flag:
tx=image ; create temporary copy (unless you don't
; mind corrupting the original array)
finder=where(tx eq -666)
tx(finder)=10000 ; we assume normal tx values are << 10000
ctvscl,tx,min=0,max=9000 ; flagged pixels will now stand out

To convert coordinates between decimal and sexigesimal form, use sixty [decimal to sexigesimal], ten [sexigesimal to decimal], or radec [RA and DEC
from degrees to sexigesimal]. For instance:
radegrees=15.0*ten(22,30,17.5)
ATV includes the abilities to zoom an image and to roam around parts of an image too large for direct display. It produces row, column, surface, or contour
plots using keyboard commands. In the ImExam mode, it also offers evaluation of source structures & crude photometry. Does aperture photometry, shows
source profile, integrated flux, background. Intended for point sources.
Manipulation:
You can operate on image arrays using any IDL routine which accepts 2-D inputs, including the full range of standard arithmetic and other mathematical
functions. Most such routines are array-oriented and do not require you to worry about do-loops or element structure in arrays.
Most IDL mathematical functions behave sensibly and give you the results you intuitively expect. E.g. if a and b are arrays with the same dimensions, then c =
a*b produces an array with the same dimensions in which each element is the product of the corresponding elements in a and b. (There are separate
functions--#,##---for other types of matrix multiplication.)
Many kinds of image manipulation can be executed with one-line commands in IDL. E.g.:
Edge detection: ctvscl, a-shift(a,1,1)
Unsharp masking: ctvscl, a-smooth(a,k) displays the difference between the original image and a boxcar-smoothed version with a smoothing
length of k pixels. This is fast, but the smoothed image includes the effects of any sharp structures (like stars). Better, though slower to execute, is
ctvscl, a-median(a,k).
Changes are, of course, made to the temporary data sets stored in RAM. The original files from which the data was transferred into your IDL session are not
affected (unless you call special file manipulation routines). However, this also means that permanent versions of the modified images are not kept at the end of
13 of 22 12/14/04 12:01 AM
your IDL session unless you deliberately save the dataset or write new output files (see next section).
If you want to maintain the applicability of the image header to the manipulated image, then you must update the header after each change. You can add
comments to the existing header by using the sxaddhist routine. Changes which don't affect the keywords included in the header (e.g. sky subtraction,
excision of foreground stars) can be simply documented this way. However, changes in the flux scale or, especially, the image format (through extraction,
rotation, rebinning, etc) usually require that the keywords be changed in order that later routines will function properly. A special set of AstUseLib routines,
including hextract, hrot, hastrom, hrebin, etc. will do standard manipulations on images and image headers simultaneously. Astrometric information,
for instance, will be preserved.
8. IMAGE STORAGE
[Up to Contents]
stwrt,[image variable],[header variable],[filename]: Write images to disk in SDAS format. The resulting files will have the [filename].hhh and
[filename].hhd extensions.
If the images have been manipulated and you did not employ the AstUseLib header-tracking commands such as hextract, hrot, hastrom,
hrebin, and so forth, then you must create a new header (use mkhdr) or update the existing one to properly match the stored image. stwrt will
optionally produce a simple header, or you can use the sx* commands, such as sxaddhist or sxaddpar to do this. (Although headers in SDAS are
ASCII files, they cannot be edited with standard text editors because of blocking conventions.) It is particularly important to be sure that the parameters
BITPIX, NAXIS*, and DATATYPE are properly entered. stwrt writes to the current directory.
FITS files: To write a FITS file from IDL variables, use fits_write. See comments on header tracking under stwrt above. File transfer between SDAS format
and FITS format can be troublesome since not all modes have been carefully tested. This is true in both IDL and IRAF/STSDAS. Always check results to be
sure.
IRAF files: To write IRAF-style output files (*.imh, *.pix) from IDL variables, use irafwrt. Alternatively, and preferably, use fits_write and then use IRAF
FITS-reading routines.
Other formats: other popular, but not specifically astronomical, file formats are supported by IDL. See write_gif, write_jpeg, write_srf,
tiff_write, etc. GIF format is a good way to store processed images with special color tables embedded, although there is no way to save header information
in a GIF. GIF and JPEG are the most widely used default formats for Internet browsers.
save... : The intrinsic IDL save command will save variables and programs from the current session in a specially formatted binary file. All this material can be
restored in a later IDL session with a single command. Delete all redundant or otherwise uninteresting variables (especially large arrays) before calling
save. Review the save keywords before use. On a UNIX system, the output file will be in a universal XDR format which can be ported to non-UNIX computers.
Use the restore command to read a save file.
save can be very useful for storage of intermediate results, but is not recommended for permanent records. Why? For one thing, it's too easy to forget
what all the variables mean; if you are forced to write SDAS, FITS, or ASCII files, you are more likely to document the work. For another, save
encourages soaking up mass storage with redundant copies of arrays which may be only slightly changed from their original values. It is more efficient to
save and then rerun a script which makes relatively simple changes in images rather than to store the intermediate versions. Finally, the restoration of save
files depends on the availability of IDL---not guaranteed if you move somewhere else. Standard IDL FITS or ASCII file-writing routines are preferable for
permanent data.
The default name of the output file is idl.dat, and this file name will be overwritten on the next save. Best to change to something informative like
ngc1068.sav.
Image transfer between computers: The most foolproof way to transport astronomical images between environments is to use FITS files. However, always
verify the transportability of the FITS files you write before you invest effort in a major data conversion.
FTP readily transfers SDAS images from one SUN machine to another. Transfer the header (*.hhh) and data (*.hhd) files using BINARY protocol. You
may also readily transfer data this way between VAX/VMS machines and SUNs as long as the data is in INTEGER or LONG format. The problem is that
VAX and SUN have reversed byte storage conventions. You can read such images using STRD, but before using them, you must use the byteswap
function. [The symptom of a non-byteswapped image is that it will contain very large values, such as 1.0e+38.] You cannot successfully transfer floating
point arrays between SUN and VAX. Beware of similar incompatibilities between SUNs and other computers.
9. IMAGE PHOTOMETRY
[Up to Contents]
Native IDL lends itself to rectangular aperture photometry through simple commands such as mean=total(array)/n_elements(array), where array is
a piece of a larger image (defined, for example, using the simple index notation: array=bigarray(x1:x2,y1:y2)). Refined versions of this simplest
approach may be found in avg.
Point Source Photometry: The AstUseLib contains an IDL version of the DAOPHOT 1987 FORTRAN release, described at
http://idlastro.gsfc.nasa.gov/contents.html#C2. This performs aperture photometry and PSF-fitting photometry on point sources. It is functionally very similar to
DAOPHOT-87 but offers the added versatility of the IDL interactive environment. The basic routines find and aper are especially useful. The IDL source code
is available. None of these routines include the improved features of the DAOPHOT 1991 or later releases. To do PSF-fitting deconvolution of blended images
where you want maximum software firepower, you should use the more recent stand-alone DAOPHOT or DOPHOT releases. However, IDL remains very useful in
preliminary assessment of data frames prior to setting loose the mechanical scroungers and in analyzing the results. (The output files of standard photometry
programs can easily be read back into IDL.) It is also an excellent way to create synthetic data sets with known properties on which to verify photometry package
operation.
Surface Photometry: A number of basic routines such as dist_circle and dist_ellipse are available to support surface photometry, but there are no
"official" AstUseLib surface photometry programs. Several individual users, including RWO, have their own routines which others may use on an "at your own
risk" basis.
The ATV image viewer contains a circular aperture photometry utility which is very useful for exploring fluxes, FWHM's, and backgrounds of point sources. It
does not, however, operate from a pre-defined list of coordinates or produce output files.
A number of other user-written photometry packages, mostly for point sources, are available through the AstUseLib site (at
http://idlastro.gsfc.nasa.gov/idlfaq.html#B4.)
10. ASCII FILES
14 of 22 12/14/04 12:01 AM
[Up to Contents]
The best way to save small data sets (e.g. photometry output) is in the form of ASCII files, since these are easily edited and transported. Intrinsic IDL supports reading
and writing ASCII files; see the IDL manuals. A sample script to write a file containing target names, coordinates, and brightnesses might look like the following:
get_lun,unit
openw,unit,'OutputFile'
form='(a15,3x,f9.5,3x,f9.5,3x,f6.2)'
for i=0,numtarg-1 do printf,unit,format=form,$
targid(i),radeg(i),decdeg(i),vmag(i)
close,unit

Note: you can check the output formatting by doing a test print to your terminal, using statements like:
form='(a15,3x,f9.5,3x,f9.5,3x,f6.2)'
for i=0,numtarg-1 do print,format=form,$
targid(i),radeg(i),decdeg(i),vmag(i)

Handy utilities to read simple ASCII files consisting of separate columns of data are readcol, for free-format entries, and readfmt, for fixed-format entries. Both have
the nice feature that they will skip over comment lines (or other lines with non-matching formats) without choking. An example of the use of readcol is given in
Plotting Example 3 below. A related utility for printing several vectors to either the screen or an ASCII file is forprint.
11. DATABASE ACCESS
[Up to Contents]
Thanks to the efforts of Don Lindler, Wayne Landsman and others at GSFC, the IDL Astronomy User's Library offers convenient and powerful access to a number
of on-line databases. Information from these can be directly incorporated into your IDL image processing or other computational sessions. For instance, the MOUSSE
routine tvdbase marks the locations of sources in selected catalogues on your current image display (assuming you have accurate astrometry for your image.)
Individual commands in the database package are described on the IDL Astronomy User's Library home page. A more detailed manual (in PostScript) is also available.
The databases must have been put in a special IDL-readable format before you can access them (commands to do this are part of the package). A selection of IDL
databases of wider interest is publicly available from the IDL Astronomy User's Library.
At UVa, approximately 95 such databases, weighted toward UV science, are available. They are presently linked to: /astro8/idl/zdbase.
In order to use the databases, you must have defined the environment variable ZDBASE to point to the directory containing them.
To see what databases are available, use the command dbhelp,1. To see what information is included in a given database and to display information for selected
entries (here numbers 10,100,1000), type
dbopen,'[data base name]
dbhelp,1
dbprint,[10,100,1000],'*
To retrieve and use the data entries, you will need to use the more sophisticated commands described in the documentation cited above.
12. PLOTS
[Up to Contents]
The basic IDL commands for making plots are plot, for creating a new plot, and oplot, for overplotting on an existing plot. Plots can be made to a terminal graphics
window or to a variety of external devices.
This, however, is only the tip of an immense iceberg. IDL contains many options for making plots---so many, in fact, that the hardest part of the job can be keeping
track of the multiplicity of optional parameters. Options in the form of keywords can be specified in the calls to the plotting functions or they can be invoked in the
form of system variables, such as !p.title, which will apply to all later plot calls until changed.
Standard plotting and graphics keywords are explained on-line by typing ? and then selecting "Graphics Keywords" from the "Language Features Quick
Reference" menu.
The most frequently used plotting keywords and system variables follow. All are optional. Examples of use are given below.
psym or !p.psym: determines symbol type. A value of 0 (the default) produces a solid line with no discrete point symbols; values 1 through 10 select
other types of (unconnected) symbols. 8 indicates that the user has defined a special symbol using the usersym procedure.
xrange and yrange: 2-element vectors giving the minimum and maximum for each axis. If not defined, autoscaling will occur.
linestyle: selects style of line drawn (solid, dotted, dash-dot, etc) if psym=0.
xstyle and ystyle: set axis options (e.g. exact range rather than rounded up)
!p.title,!x.title, and !y.title: strings for the plot title (centered over upper x-axis), x-axis title, y-axis title.
The IDL defaults are not as "nice" as those in SUPERMONGO, for example. However, you can quickly customize to obtain as sophisticated a plotting style as you
like. All the functionality of SUPERMONGO and other astronomical graphics packages is inherent in IDL. Many of the 2-D and 3-D graphics routines are illustrated in
the IDL Demos which come with the system.
Color tables for plots:
The plot commands accept the keywords background, which sets the background color of a plot, and color, which determines the color used for lines and
15 of 22 12/14/04 12:01 AM
symbols. By default on a pseudo-color X-windows display, background is set to index 0 and color is set to index 255. These therefore display the "bottom"
and "top" of your current color table, respectively. [Color tables are explained under Image Display.] The actual appearance of your plot will then depend on
what color table you have loaded (e.g. with loadct,N). The default table (N=0) produces a black background and white symbols. Your display will change if
you use a different color table or plot/background indices. You can create a special set of color tables to produce a defined set of, say, 10 standard colors for
your plots.
Sample plotting scripts for displaying plots on your terminal follow. These involve a mixture of intrinsic IDL and AstUseLib routines:
Plot galaxy surface brightness data (in magnitudes) with error bars versus radius to the one-quarter power. 1.
Use discrete symbols (not a connected line). On this plot, a galaxy with a standard "de Vaucouleurs" brightness profile will produce a straight line.
Assume that the vectors flux, rads, and fluxerr already exist, with fluxes in units of ergs/s/cm^2/Angstrom. Assume that you must truncate the plot to
eliminate the first 3 entries and those after the 20th.

mags=-2.5*alog10(flux(3:19)) -21.1 ; Convert fluxes to magnitudes,
; ignoring bad data
; Assumes all flux entries ge 0

r25=rads(3:19)^0.25 ; Compute fourth root of radius vector
magerr=1.086*fluxerr(3:19)/flux(3:19) ; Convert uncertainties
; in flux to magnitudes
!y.range=[25,18] ; Set a non-default y-axis range.
; Note: this magnitude scale has smaller values
; higher on the y-axis
; Make the titles
!p.title='Sample Surface Brightness Profile"
!x.title='Radius(arcsec)^0.25'
!y.title='Surface Bright (mags/arcsec^2)'
plotsym,4,1.5,/fill ; Choose filled triangles for plotting symbol,
; 50% larger than the default
ploterror,r25,mags,magerr,psym=8
; Make plot on terminal screen with error bars;
; The keyword psym selects the plotting symbol;
; Psym=8 specifies a user-created symbol, which
; in this case was defined by plotsym
; Plot will appear in active window, or in
; Window 0 if none have been opened yet.

Make a contour plot of a smoothed image.

chan,3 ; open plotting window
!x.title='X' ; make titles
!y.title='Y'
!p.title=' Contours for Image'
square ; set aspect ratio to make square plot
; (Note that you must also give this command
; after the PostScript device is called
; when making hardcopies.)
smooth_one=smooth(image,5) ; smooth the image by a 5 pixel boxcar
clev=[10,20,40,80,160] ; define trial contour levels--assume
; these values span range of interest
contour,smooth_one,levels=clev ; do fast test of contour plot. Check &
; iterate clev for best appearance

contour,smooth_one,levels=clev,/follow ; do more accurate (slow) plot,
; with labels

2.
Read, sort, and plot data from an ASCII file; make & display trial polynomial fits
Assume x is a vector containing values in the range 0 to 5 and that y is the corresponding dependent variable. Assume that these are to be read from an ASCII
file named xy.dat, which contains x and y in separate columns. xy.dat can contain an initial explanatory section and other separator headers, as long as none of
these contain only one or two floating point numbers (since readcol will mistake those for data lines). The readcol routine will read in the numerical x,y
data ignoring (in this example) any line containing alphabetic characters.

readcol,'xy.dat',xx,yy ; Read data from the file. Note that format
; statements are not required
index=sort(xx) ; Sort the arrays in order of increasing x
x=xx(index)
y=yy(index)
chan,1 ; Open Window 1 for plotting
plot,x,y,psym=5 ; Plot the data with open triangles
quadcoeff=poly_fit(x,y,2) ; Derive coefficients for best quadratic
; polynomial fit
print,quadcoeff ; Print these out (optional) [Note:
; quadcoeff is a vector]
tx=findgen(101)/20. ; Create independent variable vector for fitted
3.
16 of 22 12/14/04 12:01 AM
; values (uniform interval of 0.05 x units)
quadtesty=poly(tx,quadcoeff) ; Create the fitted quadratic values
oplot,tx,quadtesty,psym=1 ; Overplot the quadratic fit with plus signs
cubcoeff=poly_fit(x,y,3) ; Derive coefficients for cubic fit
cubtesty=poly(tx,cubcoeff) ; Create the fitted cubic values
oplot,tx,cubtesty,psym=3 ; Overplot the cubic values with small dots
delta=y-poly(x,quadcoeff) ; Compute the difference between y data and
; the best quadratic fit
nix=where(abs(delta) gt 2.) ; Locate those y values which are more
; than 2 units from the best fit
weight=fltarr(n_elements(x))+1. ; Create a weight vector corresponding to
; x with unit entries
weight(nix)=0.0 ; Give deviant points zero weight
newquadcoeff=polyfitw(x,y,weight,2) ; Derive improved quadratic coeff.
final=poly(tx,newquadcoeff) ; Create improved fit values
chan,2 ; Open Window 2 for final, clean plot.
; (Window 1 is retained for comparison.)
plot,x,y,psym=5,xrange=[1,3.5] ; Plot the data with open triangles in
; Window 2.
; Assume interest is limited to only
; part of data x-range.
oplot,tx,final,psym=0 ; Overplot final fit with solid line

13. GRAPHICS HARDCOPIES
[Up to Contents]
The most common method of obtaining hardcopies or permanent storage of graphics output (plots or images) is to use PostScript files, since these can be printed on
most laser printers. PostScript files can be later edited and reformatted, though special (non-IDL) programs are needed. IDL also supports output of GIF, JPEG, TIFF,
SRF, and other file formats. GIF and JPEG are standard for Internet Web browsers. GIF or TIFF are recommended for transporting files to local vendors to make
photographic prints or slides.
You should always experiment on the terminal screen with your plot format before dumping to an output file. It is easy to do this by working out the set of commands
you want by plotting to the screen, then typing set_plot,'ps (in the case of PostScript output) and repeating the commands using the command recall buffer. For
more complex plots, use the journal utility, then edit and re-execute the resulting file (or cut and paste across windows).
The set_plot command determines which output graphics device you are using. The most common versions of this command are:

set_plot,'x : Send output to X Windows (default)
set_plot,'ps : Send output to the PostScript file "idl.ps"
The subsequent commands for sending data to the PS file are (mostly) the same as for putting data on your monitor screen, since monitors and PS files are
interchangeable output devices for IDL.
You can always check the properties of the current graphics output device by typing help,/dev. You can change these defaults by using the device command.
The hardware/software interfaces are sometimes non-trivial, and you will want to plan for a significant learning curve in doing things which are not "vanilla." Before
sending large jobs to printers, vendors, etc., be sure to check the files using UNIX ghostview, xv, or other screen display programs.
Here are some graphics output methods for common situations:
To make a PostScript hardcopy of a plot.
Type set_plot,'ps to send output to "idl.ps" 1.
Optionally, make adjustments to the plot size, aspect ratio, orientation, lettering fonts, etc. using the device command 2.
Give the set of plotting commands here---just as for a screen plot; all system variables will still be in force 3.
Type device,/close to close the file idl.ps. (Note: the PostScript file is not actually written to disk until the close command is given.) 4.
Type $lp idl.ps to print the file on the default printer. 5.
The next plotting command will overwrite idl.ps. If you want to save it, you must change its name. E.g. $mv idl.ps bossplot.ps. 6.
Example (based on continuing Sample Script #1 under Plots above.)
set_plot,'ps ; Plot will be sent to PostScript file "idl.ps",
; not to the screen
ploterror,r25,mags,magerr,psym=8
; Make plot (in PostScript file) with error bars;
; The keyword psym selects the plotting symbol;
; Psym=8 specifies a user-created symbol, which
; in this case was defined by plotsym
; System variables for labels are still in force

device,/close ; Close file
7.
17 of 22 12/14/04 12:01 AM
$lp idl.ps ; Send file to printer
$mv idl.ps surbriteplot.ps ; Rename PS file to save it.
set_plot,'x ; Send further output to the terminal
cleanplot ; Reset the plotting system variables to defaults
The output file will have the expected "black-on-white" sense, unless you make use of the keywords described next. 8.
You can make color PostScript files by setting device,/color and using the background and color keywords (see the Plots section). However, the
treatment of color tables differs from the X-windows case. Consult the IDL manuals.
9.
Making a PostScript hardcopy of a displayed image: use tvlaser. This dumps a bitmap of the current window (as selected by the chan routine) to a
PostScript file and prints it on the default PS printer. Various options to add comments, information from the header, change the format, and so forth. If you want
to save the PostScript file, answer no to the query about "removing" it.
Color image output: tvlaser supports PS image output in both greyscale and color. For color output, use the colorps keyword.
As an example of how to handle IDL image output in color, here are the steps that tvlaser uses to make color PS files:

First create the image as you want it to appear, complete with
your chosen color table (load with loadct or
tvlct). Put it in the current window.
pic = tvrd() ; copy the (byte) window buffer to a variable

tvlct,r,g,b,/get ; save the current color tables to vectors
set_plot,'ps ; put further output in the "idl.ps" file

device,/color,bits_per_pixel=8 ; set pseudo-color output
tvlct,r,g,b ; write the color tables to idl.ps
tv,pic ; write the image to idl.ps
device,/close ; close the file
$mv idl.ps colimage.ps ; rename the file to save it
[Option: check the *.ps file with UNIX ghostview or equivalent.]
$lp -d chroma colimage.ps ; send the file to a color printer
set_plot,'x ; return graphics output to your screen
GIF file output. For image output in GIF, JPEG, TIFF, and other formats, you do not need to use the set_plot command. Simply send the appropriate picture
elements to an output file, as in the following:
pic = tvrd() ; copy the (byte) window buffer to a variable
tvlct,r,g,b,/get ; save the current color tables to vectors
write_gif,'picname.gif',pic,r,g,b ; write to a GIF file
Tip: when producing PostScript output files of images for publication, it's useful to also make a GIF version, since this can be read back into IDL later if
touch-ups are needed. IDL cannot read PS files (though UNIX xv can convert PS's to GIF's).
Note: some slide-making software assumes that images will be in LANDSCAPE mode---i.e. long axis horizontal. If you are exporting images intended for slides,
it is easiest to adopt landscape mode here. If your image is significantly higher than wide, rotate it 90 degrees using one of the IDL utilities before saving it. E.g.
picname = rotate(picname,3).
Technical Issues:
PostScript files are the best way to get high quality line-drawing plots and are generally well treated by publishers. Greyscale or color images are another matter,
however, and should be approached in an iterative way. A published PS image may look very different from the one you printed locally. GIF or TIFF files may
yield better results than PS.
There can also be difficulties with the finite resolution of screen displays copied using the tvrd routine. This is true for the quality of both the image and any
lettering which may have been added to it. On a typical computer screen, you will not get more than about 900x900 resolution. However, a PostScript file at
300 dpi can yield much higher resolution (1800x1800 in a 6" image). As an alternative to the screen-capture tvlaser method described above, you can write
images and labeling directly to a PostScript file using the standard tv, tvscl, xyouts and other routines. The main difficulty is understanding the
coordinate system used within the PS file and placing the various elements of an output page in the right positions. People wind up using trial and error (easy
by writing the PS file, then giving a $ghostview [filename] command from within IDL). For more information on the use of PS files with IDL, see
http://www.dfanning.com/documents/tips.html#PostScript
If you store copies of your graphics output in GIF or JPG (or several other popular format) files, you can use the UNIX utility xv to manipulate them further: in
size, rotation, contrast, color table, and by applying various image enhancements. xv can convert between GIF and PostScript---and also, in more recent releases,
vice versa. Especially useful for compressing image sizes for use on the Internet, the Los Alamos Preprint Server, and so forth. You can also, of course, use PC
software such as Photoshop.
14. IDL HINTS AND ANNOYANCES
[Up to Contents]
Not many people have experienced fully interactive computing before they start to use IDL. There are tremendous advantages but also many pitfalls for the unwary.
The pitfalls will, of course, mostly seem obvious and trivial in retrospect---i.e. after you have learned to avoid them. A number of tips & warnings for IDL beginners are
discussed in this section.
Paths, Procedures, Directories
18 of 22 12/14/04 12:01 AM
If a procedure name is unrecognized or gives unexpected error messages, check to be sure your directory path (!path inside IDL) is set properly. The initial
value of !path is taken from the shell variable $IDL_PATH. Check the directories in the path for the procedure.
The notation :+/directoryname in the $IDL_PATH definition expands the path to include all subdirectories of the named directory which contain *.pro
files. Use sparingly to avoid picking up "old" versions of routines, which are often stored in subdirectories of active versions.
Errors will also occur if you try to call a function as a procedure or vice-versa. A procedure requires a [name],parm,... call while a function requires a
[var]=[name](parm,...) call. Use help,/rou to keep functions and procedures straight. If you try to execute a main program by typing its name rather
than by typing .run [name], a strange set of error messages will appear.
Remember that data output will be written to the directory which is current when the output command was given. If you use sd frequently to move through
directories, you may lose track of where the output went (though a journal file can tell you). If you are currently in someone else's directory on which you do
not have write permission, the output commands will not function. Some commands (e.g. tvlaser) produce large scratch files. "Unrecognized file" errors
during input commands often mean that you are in the wrong default directory. Check with sd.
After modifying a [name].pro procedure file, be sure to recompile it with .run [name] before attempting to use it. If the routine had been compiled before
you modified it, simply entering [name] will execute the OLD version.
Special IDL Interactive Aids & Accelerators
In programming, note the great usefulness of interactive aids in intrinsic IDL. such as size, n_params, n_elements, keyword_set, and others. These
allow you to assess the state of the variables in your program at any time.
print allows you to print the current value of any variable to the screen at any time during an interactive session (beware, however, in the case of large
arrays). A format statement is optional. Default formatting: row vectors are printed across the screen; column vectors, down. printf is the corresponding
command to print to an output file. Both commands can be used within programs.
readf is the standard interactive command to read data from an ASCII file. A format statement is optional. The same command can be used within programs.
To read input from the keyboard from within a program, use the read command.
readcol is a handy AstUseLib utility for reading in ASCII files of columnar data. A format statement is optional (depending on the content of the files); lines
containing unexpected characters are automatically skipped. For fixed-format ASCII I/O, see readfmt and forprint.
IDL array-oriented mathematics often eliminates the need for do-loops or index-specific programming, and you should use index-free notation wherever
possible. (IDL is significantly slower when data elements are referenced by indices.)
There are about 20 intrinsic IDL functions for creating arrays of different types and filling them with initial values, including intarr, fltarr, indgen,
findgen, replicate and make_array.
There is a large set of other array-oriented arithmetic functions, such as expand, mean, rebin, reverse, smooth, sort, total, transpose, and so forth.
You will find a large set of uses for the where function. E.g. to find all non-positive values in an array in order to prevent errors when taking logarithms, type
find=where(a le 0). The subarray a(find) then will contain all those points.
For example: to replace all values less than 1 in an array with 1, type
a(where(a lt 1))=1.
In this case, IDL offers an even more compact alternative. a = (a>1) accomplishes the same thing (the notation a>1 means "an array containing the
maximum of 1 and the original elements of a").
The recall/edit and journal utilities are indispensable means to iterating and recording IDL code.
Definition & Stability of Variables
Remember that the first element of vectors and arrays is always at index 0. (This is to preserve the conventional axis notation for plots.) If b contains ten
elements, element indices run from 0 to 9, not 1 to 10. A reference to b(10) is out of the vector's bounds. This will kill a subroutine, though it only generates
an error message if it occurs on the command line.
If some previously defined variables seem to have "vanished" or other peculiar behavior occurs, check to see that you are in the main program and not a
subroutine. See retall above. To return automatically to the main program whenever an error occurs in a subroutine, type on_error,1 at the beginning of
your IDL session (strongly recommended for all users, except when debugging).
To create test arrays/vectors in order to experiment with IDL procedures, use indgen, findgen, etc. For instance a=findgen(100,100) creates a 100x100
floating point array with unique element values running between 0 and 9999.0; a=fltarr(100,100)+10. creates a 100x100 array containing 10.0
everywhere. Create vectors with simple definition statements like z=[1,3,9,27]; statements like z=[z,81] are useful for enlarging vectors. You can extract
subarrays using index notation, as in piece=a(100:156,200:296). Experiment with display/cursor routines by adding "hot pixels" (e.g.
a(50,50)=20000), steps, gradients, and so forth. Synthetic point sources can be created by placing "hot pixels" where desired and then convol-ving the
result with a point spread function.
The maximum value of an IDL floating point constant is about 3e38. To deal with larger numbers, you must use double-precision. E.g. in computations
involving the speed of light, good practice is to define c = 3.0d10 rather than c = 3.0e10. The largest double-precision constant allowed is about 4d88.
(Minimum values are the inverses of these.) Computations which produce out-of-range values will lead to "overflow" or "underflow" error messages.
Beware of implicit redefinition of variables. IDL dynamically defines variable type, and this is a classic source of IDL novice errors. For instance, x=5/2 returns
the value 2 (integer) while x=5./2 returns 2.5 (floating point); x has different values and attributes in consequence. Watch out!
Implicit redefinition of array variables can lead to big difficulties as in the following:
A=fltarr(200,200) ; Define floating point array with all elements
; = 0.0
A(*,*)=1. OR A=A+1. ; Proper way to fill array A with 1.0
A=1.0 ; Wrong way to fill array A with 1.0. You
; have just changed A to the scalar 1.0!

Another potential problem area lies in extracting vectors from arrays. In IDL a 1-D vector is assumed to be a ROW vector. Thus, if A is a 100x100 array,
B=A(*,40) will create a row-vector of dimension (100), but B=A(40,*) will create a 2-D ARRAY with dimension (1,100) (= a column vector). To convert a
column vector into a standard row vector, use the transpose function. You can check the current structure for a variable using the help command. Also, the
print command prints row vectors across the screen and column vectors down the screen.
19 of 22 12/14/04 12:01 AM
Here is an example of another problem you can encounter with IDL's implicit definition of variable type involving a dependent variable array from which you
want to extract a particular value. If time is the independent variable and value is the dependent variable, you might want to locate a particular entry in value
as follows and renormalize the value array:

find=where(time eq 1000.)
norm0=value(find)
normalval=value/norm0
Naively, you expect norm0 to be a scalar, as it would be if you typed norm0=value(151), for instance. However, if you try this, you will find that here
it is not a scalar, but instead has type array(1). This is because the where routine returns a vector, which definition propagates through to the definition
of norm0. The resulting quantity, normalval, which divides two vectors of different lengths, is therefore a scalar, not a vector! To get the intended
result, you must convert norm0 to a scalar using an array function with a scalar output: e.g. norm0=total(value(find)) or norm0=
max(value(find)).
If you are writing code for general application, you would also want to confirm that find returns only a single (non-negative) element; the number of
elements returned by the where function can be determined, for instance, as follows:

find=where(time eq 1000.,count)
if (count eq 1 ) then begin...
When working with data arrays (e.g. of CCD or HST data) where the data has limited dynamic range and does not require more than 2-byte precision, it may be
faster and more convenient to convert them to integer form after multiplying by a scale factor than to leave them in floating-point form. This saves storage,
increases execution speed, and often reduces typing. You can save manipulated versions by back-converting, but you have to be careful to check that you
haven't lost any bits off the end.
Procedures which require vector arguments include max and min. If a,b,c,d are scalars, you must enter print,max([a,b,c,d]) rather than
print,max(a,b,c,d). Miswriting statements like x = max(a,b) can actually result in a changed value for b. Beware.
Functions such as smooth, rebin, and other resampling routines usually preserve the variable type. When applied to integer arrays, numerical errors
introduced by truncation can be introduced. If you are interested in preserving data values with such routines, you should apply them only to floating point
arrays. To convert an integer array to floating point, enter a = float(a).
Remember that the main level of IDL will not recognize variables which are defined in procedures (subroutines) but are not passed through calling parameters
back to the main program. (Same as in FORTRAN.) Internal variables vanish on a normal exit from a procedure. To determine which variables are active, use
help. You can, however, use common blocks (as in FORTRAN) to establish links between main level and subroutine level variables which are not in the calling
sequence. Main programs have access to all variables which have been defined at the "main" level.
You can also define your own system variables, which are known to all programs, using defsysv.
IDL structures provide a compact and convenient way of moving large numbers of related variables of various types (scalars, arrays, strings) between procedures
and main programs.
Differences from FORTRAN & C
A frequent source of minor trouble for users of other high level languages are the small differences in IDL syntax for if, then, for, do, etc., statements
and in logical expressions. It is worth spending some time reviewing these before writing IDL code.
IDL's element subscripting convention for 2-D arrays is reversed from FORTRAN. In FORTRAN, A(i,j) corresponds to the element in the ith ROW and jth
COLUMN. But in IDL, A(i,j) corresponds to the element in the ith COLUMN and jth ROW. A(*,j) is a row vector. A(i,*) is a column vector.
This convention was adopted for IDL because it produces the standard sense for (x,y) displays. The default display commands will show an array
A(x,y) starting with column 0 at the left of the screen and row 0 at the bottom. When displayed, A(4,1) will be four units to the right and one unit up
from the origin. This change in convention obviously requires care if one is trying to operate on a given dataset with both IDL and FORTRAN.
Punctuation Issues
IDL is not case-sensitive, though UNIX is. Commands which will involve the operating system (e.g. reading/writing files) therefore must observe case
conventions.
The period in executive commands (e.g. .run) must appear as the first character of the command line (no preceding blanks).
The "single-quote" mark for strings, filenames, etc., is the apostrophe ('), not the "leading-single-quote-mark" (`). Syntax errors occur if you switch these.
Unfortunately, on many terminal screens, these are hard to distinguish. On some keyboards, they are also on adjacent keys, which often leads to typing errors.
Strings must always appear in quotes; file names are treated as strings in most routines involving files. If a string is the last entry on a line (no further
parameters or punctuation), then the trailing quote mark need not be entered. But in this case, be sure you don't enter an extra blank space or two on the terminal
before pressing "return", or the string may be incorrectly read.
A common typo which can lead to a syntax error is the substitution of a period for a comma in a procedure argument list.
Recall that a vector is identified by enclosing brackets, not parentheses: x=[47,29,135], not x=(47,29,135).
Other Issues
It is a good idea to make liberal use of the sxaddhist routine to update the comments on your data set as you read, process, and save SDAS or FITS images.
Since interactive IDL sessions often produce a large number of active variables, it is useful to be systematic in naming each new variable. E.g. in reading
arrays, use conventions like: strd,pic2,hdpic2,'filename' to keep the image and header arrays straight.
To keep directories straight, and save typing, it's useful to define special string variables which contain the fully qualified names of your program, data, and
other frequently used directories. Then you can just sd,[stringname] to change directories.
If you manipulate the color tables with contrast or similar routines, you will probably want to reload the standard tables before displaying a new image.
Programming Philosophy
Some IDL users like to write a specific, single-purpose main program to perform a particular task and then change it, or proliferate multiple versions, to deal
with similar but slightly different applications (e.g. a new data set). Others prefer to write more generalized procedures (subroutines), which take defined sets of
input parameters but which can perform the function on a variety of different inputs. They then journal the sessions in which the routine is actually applied. In
20 of 22 12/14/04 12:01 AM
this method, the specific input to and output from each subroutine are clearly and concisely documented. (Since main program input/output is not made explicit
when you .run the program, the journal file cannot capture it.)
The latter approach produces software which is usually more reliable and stable over long periods (not to mention usable by others), and it is easier to
reconstruct what was done at a particular time. Other advantages, which can be crucial, are that in writing a more generalized subroutine, you are more likely to
spend the time to review the logic, to adequately document what the routine does, and to catch typing errors (which can sink you in the main program
approach). I have found this to be much more reliable than the "single-shot" main program approach. Whichever method you use, you should journal
everything if you are doing serious work.
Although it is possible to concatenate many IDL procedures into a single *.pro file and to compile them all with one command, this prevents you from using
the man help procedure, which lists headers based on their location in files. It's actually cleaner and less confusing in the long run to keep all procedures in
separate files. You can always write batch compilation files which catch all procedures needed for a given task (or you can simply let the automatic compilation
system compile programs when they are first referenced; this is less trouble and just as fast).
APPENDICES
APPENDIX A: IDL SETUP
[Up to Contents]
Before executing IDL, you must define a special set of IDL environment variables, so that UNIX and IDL know where to look for the various IDL executable and
programs packages.
If you use the UVa Astronomy Department system defaults, you will be set up to use IDL Version 5, with the MOUSSE package as installed on our local
servers. If you want to use the system defaults, you can ignore the rest of this section, except for morbid curiosity. On the other hand, if you want to customize your
IDL configuration, you need to know the details of the various environment variables.
To define the IDL environment variables you should source a special idl_env file from your .cshrc file. You cannot change the contents of the idl_env file or the
defined environment variables after IDL begins execution. The file which configures a default session on the Astronomy Department network is named
/astro8/idl/idl_env. The first item which must be defined is the location of the main IDL directories, whose shell variable name is $IDL_DIR. Intrinsic IDL executables
are kept there. Which $IDL_DIR you define determines which version of IDL you will execute. Each set of executables is authorized by RSI to run on only certain
hosts, so you must point $IDL_DIR to the appropriate directory for your current host to run IDL other than in a "demo" mode. The executables must be compatible
with the current version of the operating system running on your host.
You must also specify the search path for all *.pro routines you wish to use (other than the intrinsic RSI routines). IDL's default in the absence of a specified path is
to use the current directory only. The path is defined in the UNIX shell variable $IDL_PATH, which is converted to the IDL system variable !path. The search path
should include the IDL User's Library (distributed with native IDL), the IDL Astronomical Users Library, and the MOUSSE directory. It should also include your own
idl directory and any other directories containing customized routines which you wish to invoke without making them the current directory.
Separately, if you wish to use the databasing software, you must specify the location of the IDL databases.
Beware of multiple versions of the same program (e.g. an AstUseLib version and a Users Library version)! You must arrange your path so that the preferred
version occurs first in the path. At UVa, the AstUseLib versions are preferred, and should be placed first in your path except for your own idl directory. At
execution, IDL will source your .cshrc file, so that only the $IDL_PATH definition determined by that file will be active during your session.
Recommended path structure (see examples below for syntax):
[current directory], [your idl directory], [other special local
*.pro libraries, if any], [Astronomy Users Library], [MOUSSE], [IDL
Users Library].
You also need to specify your default printer and the MOUSSE startup file defined by the $IDL_STARTUP environment variable. This is executed when the IDL
session begins and tailors your session to the graphics devices available and the MOUSSE environment.
When you give the command "idl" under the following setup, this is what happens:
The executable idl located in $IDL_DIR is retrieved and executed on your host 1.
The shell variables starting with IDL are converted to corresponding internal IDL system variables 2.
The file $IDL_STARTUP is executed, if defined. If you wish to use the MOUSSE system, you must execute a special set of initialization commands as part of this
file. They establish graphics and display defaults within MOUSSE. You can use the supplied default version (mousse_startup.pro), or you can specify a
personalized version which includes all the statements in the default plus customizing statements.
3.
The startup file executes the MOUSSE procedure cinit.pro which configures your session to use the MOUSSE common blocks and display procedures.
Many MOUSSE routines will fail if cinit is not executed.
4.
APPENDIX B: ENVIRONMENT SETUP EXAMPLE
[Up to Contents]
### This is the UVa ASTSUN system default for IDL Version 5
### as installed on the ITC servers, August 2002.
# C shell commands to define IDL environment variables and aliases.
#
# Script name: idl_env
#
# This script is used by C shell users
# to define the environment variables and aliases required by IDL
# related commands (idl, idlde, idlhelp, idldemo).
#
# idl_env is automatically loaded for tcsh users by the default file
# /etc/csh.cshrc using the following command
#
# source /astro8/idl/idl_env
#
21 of 22 12/14/04 12:01 AM
# To overwrite the defaults set in this file, users can source other
# setup files from their individual .cshrc file.
#
# bd4r 97- -07 added ZDBASE and IUER_DAT
# eww6n 97-21-97 changed lib in IDL_PATH with preceeding +, added examples
# eww6n 97-08-22 added mousse_...pro routine to set up Mousse routines at
# startup
# eww6n 97-09-01 changed path to IUER_DAT, removed unsetenv from idl alias
# eww6n 97-10-01 added + to ~ in IDL+PATH
# eww6n 97-10-15 added PIA routine sources and PATH for cvc3f
# IDL_STARTUP /astsun2 -> /home/astsun2
# eww6n 97-10-28 added IUEDAC stuff for Ben Dorman
# eww6n 98-06-06 changed default idl directory to be a symlink to idl_5.1;
# this will make it transparent to this script when future
# upgrades are installed. Added idldeclient (new with 5.1)
# eww6n 99-04-26 changed path for new astsun (i.e., replaced all occurrences
# of /home/astsun2 with /astrosw)
# kx8u 00-02 changed default directory for license and executable to the
# ITC-maintained UVA site license. Default executable is
# now IDL_5.3.
# kx8u 00-04-04 corrected error in path for ZDBASE
# rwo 00-04-11 updated documentation, added ATV to path, placed ASTROLIB_DIR
# ahead of MOUSSE_DIR in path
# kx8u 02-02-20 default executable is not idl_5.5 on jeeves
#
# kx8u 02-08-05 on solaris 2.6 default idl_5.4 on solaris 2.8 is 5.5
# rwo 07-29-03 changed paths to reflect new /astro8 directory structure;
# removed references to IUE RDAF s/w
set sys=`uname -a | awk '{print $3}'`
if ( $sys == 5.6 ) then
setenv IDL_DIR /net/jeeves.common/rsi/idl_5.4/
else
setenv IDL_DIR /net/jeeves.common/rsi/idl/
endif
#setenv IDL_DIR /net/jeeves.common/rsi/idl/
setenv IDL_HOME ${IDL_DIR}
# License file
setenv LM_LICENSE_FILE /net/jeeves.common/rsi/license/license.dat
# Local packages
setenv ASTROLIB_DIR /astro8/idl/Astrolib
setenv MOUSSE_DIR /astro8/idl/Mousse
setenv PIA_LOC_GEN /astro8/idl/PIA/
setenv ATV_DIR /astro8/idl/atv
setenv IDL_HELP_PATH "+${MOUSSE_DIR}:+${ASTROLIB_DIR}"
# ZDBASE is the location of the IDL-formatted databases
setenv ZDBASE /astro8/idl/zdbase
# Notes on IDL_PATH
#
# Symbol "+" means that path will be expanded to include all
# subdirectories within given directory.
# User's own IDL programs are assumed to be in directory named,
# or linked to, "idl" under user's home directory
# Directory $IDL_HOME/lib contains the IDL User's Library of
# standard user-written utility routines.
setenv IDL_PATH ".:+~/idl:/astro8/idl/UVAlocal:+${ASTROLIB_DIR}:${ATV_DIR}:+${MOUSSE_DIR}:+${IDL_HOME}/lib:+${IDL_HO
setenv UIT_DATA ${IDL_HOME}/data
setenv IDLUSR ${HOME}
setenv IDLUSER ${HOME}
setenv IUER_DAT ${IUERDAF}/iuelib/dat/
alias idl $IDL_DIR/bin/idl
alias idlde $IDL_DIR/bin/idlde
alias idldeclient $IDL_DIR/bin/idldeclient
alias idlhelp $IDL_DIR/bin/idlhelp
alias idlrpc $IDL_DIR/bin/idlrpc
alias insight $IDL_DIR/bin/insight
alias idldemo $IDL_DIR/bin/idldemo
alias pia $PIA_LOC_GEN/PIA
# The following IDL startup file will be executed before
# each IDL session. User can specify a different
# startup in his/her .cshrc file.
setenv IDL_STARTUP /astro8/idl/mousse_startup.pro
APPENDIX C: MOUSSE STARTUP FILE EXAMPLE
[Up to Contents]
"Startup" files are batch files which are automatically executed when IDL begins running. They enable to user to customize his/her IDL session.
The startup file is often placed in $IDL_DIR. However, it can be anywhere. In order for IDL to locate it, you must point the environment variable $IDL_STARTUP to it.
If this variable is not defined, no startup file will be executed.
This particular example defines special "systems variables" and common blocks used by the MOUSSE image processing package. These improve the efficiency of the
package and reduce the number of typed entries the user must make to use it.
Contents of mousse_startup.pro:
22 of 22 12/14/04 12:01 AM
; STARTUP FILE mousse_startup.pro
; Last Modified: 15 May 1992, 30 Sep 93, 27 Dec 93, 22 Aug 97
print , "Running mousse_startup.pro..."
print , "For help on AstUseLib and Mousse routines, use the Mousse MAN procedure."
setplot, 'X'
DEFSYSV,'!DEBUG',0
DEFSYSV,'!TEXTUNIT',0
DEFSYSV,'!TEXTOUT',1
DEFSYSV,'!PRIV',0
defsysv,'!psprinter','astro-hp' ; UVA default printer
cinit ; CINIT sets up MOUSSE common blocks
!PROMPT = 'IDL>'
!EDIT_INPUT = 100
on_error,1 ; Return to main program in case of error
print,' *** on_error,1 is default ***'
print,' *** If terminal is vt100/tek, type SETPLOT,0'
APPENDIX D: X-WINDOWS NOTES
[Up to Contents]
This guide assumes you are executing IDL from within an X-WINDOWS or SUN OPENWINDOWS environment. So: first, you must start your windows system and
open an appropriate window to enter IDL commands. The location of display windows opened by various IDL applications can be controlled in many instances.
Consult the description of xpos under the window command. It is useful to place display windows away from your command window, wherever possible. You can
move existing windows using your mouse.
Normally, you run IDL on your local machine with display on your local terminal. To run IDL on a remote host which supports X-windows with display on your local
terminal, do the following:
Edit the .xinitrc file on your local machine to include the statement xhost [remote host], where [remote host] = the fully qualified network name of the
IDL host you wish to use. E.g.:
xhost parfait.gsfc.nasa.gov
1.
Start X-windows on your local machine. 2.
ssh or telnet to the remote IDL host and login 3.
To obtain X-windows output from the IDL host on your local machine, type
setenv DISPLAY [local]:0.0
where [local] is the fully qualified network name of your local machine, e.g.
setenv DISPLAY bonkers.astro.virginia.edu:0.0
4.
Start IDL on the remote machine 5.
New windows created by IDL should now appear on your local terminal. Of course, data display in this mode will be slower than if you were running on the
local machine since the images must be transferred over the network.
6.
[To top of IDL GUIDE ]
This Guide is copyright 1991-2003 by Robert W. O'Connell. All rights reserved.
Reproduction, distribution, and commercial uses are prohibited.
Last modified July 2003 by rwo

Introduction To IDL

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Introduction To IDL

Hochgeladen von

Copyright:

Verfügbare Formate

Introduction to IDL http://www.astro.virginia.edu/class/oconnell/astr511/guide-bw.

Das könnte Ihnen auch gefallen