Graphics Output:
Displays, Printing and Plotting

Image display is fairly straightforward in the IRAF environment--you use imtool or SAOimage.
Still, some problems come up with users not understanding where files are going or in what format they are being written. Similarly, plotting is straightforward but users still become confused with how graphics are mapped to the hardware or when plots get printed. Figure 8.4 shows some common problems when working with images and plots on various printers and displays.

Imaging and Plotting Problem Areas

In this section, we will describe:


There are two environment variables that control how images are stored:

imdir--the Image Directory

Images--both IRAF (OIF) and STSDAS (GEIS) format--comprise two disk files, an image header and a pixel file. In the case of IRAF images, the pixel files do not necessarily appear in the same directory as the header. However, you can override the default and specify where to put the pixel files. There are a few options and each has its advantages and disadvantages.

When you ran mkiraf to initialize IRAF, the that was created had a statement that looked like the following:

set imdir = "/usr/stsci/temp/user/"
The directory path specified by the value of the imdir variable is where the pixel files will be written whenever you create a new OIF image. You can change this to be any directory you wish. A special value you can use for imdir is

set imdir = "HDR$"
The HDR$ tells
IRAF to put the pixel files in the same directory as the header files, regardless of where those headers are located. An extension to this is an additional path after the HDR$ that would specify a subdirectory to that of the header files. For example, if you use imcopy to create a new copy of an image:

im> imcopy dev$pix home$images/mypix
And you set imdir as:

set imdir = "HDR$pixels/"
Your header file (mypix.imh)
would be in home$images and the pixel file (mypix.pix) would be in home$image/pixels.

The disadvantage of specifying an absolute directory path in imdir has to do with IRAF networking. In order to locate the pixel file, there is a pointer in the image header to the pixel file. If you specify an absolute path for imdir, as is the default, then IRAF prepends the host name onto the pointer to the pixel file in the image file header, for example:

The disadvantage of this is that if you then log onto a different host, even if it uses the same file system (say a Sun cluster sharing a file system through a server), then each time you access the image, IRAF will prompt you for your password. This is because it sees the host name followed by the "!" in the pointer to the pixel file, which indicates that it must use networking to access the pixel file.

imtype--Image Formats

New data files, such as those created by the rfits task, will be written in the format specified by the environment variable imtype (unless overridden). Any task that reads an input image and produces an output image will write the output image in the same format as the input image unless the output file extension is specified, for example:

cl> imcopy input.hhh output
would produce files output.hhh and output.hhd in the STSDAS (GEIS) format, and

cl> imcopy input.hhh output.imh
would convert the STSDAS format file input to IRAF format. The value of imtype can be defined using the reset command:

cl> reset imtype=imh     # IRAF format 
cl> reset imtype=hhh     # STSDAS format
When image files are created or updated, they use the file
dev$pix as a template. If you ever encounter a problem where an image header created on one system is different from that created on another system, compare the two dev$pix files. They should be identical, but have (on rare occasions) been known to get corrupted. Image formats are discussed in detail in Chapter 3.


When you print a plot, remember:

Disappearing Plots

When plots disappear, it is usually a sign that you need to clear the CL's graphics buffer. This is done using the gflush command after writing a hardcopy plot.

If gflush doesn't produce your plot, and the printer is working, then the batch job that handles output may have failed. On a VAX, you can check for a file called sgiqueue.log which contains a log of the job. This file is located in your login root directory (SYS$LOGIN), not the IRAF home directory. There are two reasons a plot job might fail:

$ if f$environment ("INTERACTIVE") .eqs. "FALSE"
then exit
$ set process/name="<witty name>"

Printed Plots Differ From Screen

There are two reasons that your printed plot may be different from that on the screen:

IRAF hides device-dependent details, particularly when handling graphics. However, devices are inherently different and a terminal screen has a different size and shape than a page from a printer. Therefore, plots do not necessarily appear identical on the screen and on the printed page. This is most noticeable if you compare printed plots made in two ways. First, you might run a plotting task to display a graph on a terminal and use =gcur and :.snap to print the plot. Later, you might run the same task and set device=stdplot to send the graph directly to the printer. You will notice that these two plots look different, particularly if the task draws features with some particular scale or aspect ratio. For example, a circle will be circular on the screen but not on the printed plot. In the second case, circles should be circular on the printed plot.

Lines will not appear in a printed plot exactly as they appear on your screen because different terminals support different types of lines and IRAF graphics use whatever line types are supported for a particular type of terminal. These line types are defined in the file dev$graphcap. Lines drawn on a printed plot are drawn explicitly, they are not predefined. If there is a problem with the line types on a particular terminal type, contact the HotSeat.

The other reason for plots appearing differently is that the IRAF graphics buffer is too small. This buffer is a piece of memory maintained by the CL; it contains a copy of the instructions for drawing the plot. The CL uses the graphics buffer to interact with the plot, for example, in cursor mode to zoom, scroll, make hardcopies, etc. If you have a plot with many lines, (such as a contour map), then the graphics buffer can get filled. This will not affect the appearance of the original plot on the screen, However, if you replot on the screen or make a hardcopy, part of the plot will be missing. You can enlarge the buffer by setting the IRAF environment variable cmbuflen either on the command line or in your file. The default value is 64000, so for a very large plot, you may wish to increase this, for example:

cl> set cmbuflen = 512000

Your printer may not support plots of this size (512000).

Other Plot Problems

There are a few problems that come up occasionally in graphics tasks. These include:


In this section we describe problems related:


If you're using DecWindows and interacting between text, graphics, and images, you need to understand where the task is expecting to receive its input. This is called
input focus. You set the input focus by clicking in the appropriate window--preferably in the menu bar to prevent the click from being interpreted as a keyboard interrupt. The input focus concept is especially important when using apphot tasks.

Below are a few additional questions that have come up related to image displays:

SAOimage Problems

IRAF can communicate with only one execution of SAOimage on a given workstation at any one time. It is possible to run multiple copies but IRAF will hang or produce unpredictable results if there's more than one.

Note that there may even be copies of SAOimage for which there is no visible display. You can determine how many copies are running on a given host by using the Unix command

ps -aux | grep saoimage
If there is only one copy, the output should look something like the following (the second line echoes the "grep" command used with ps):

levay 3772 0.0 0.0 1444 0 p1 IW 16:07 0:00 saoimage
levay 3778 0.0 0.7 32 220 p1 S  16:08 0:00 grep saoimage
If there is more than one copy, you can use the Unix kill command with the process number listed in output from the ps command:

kill -9 3778


If you have problems when printing:

If you're trying to make a hardcopy of the image on your display and you think you sent the image to the printer but nothing came out, you might try checking the environment variables in your login file. It could be that you set variables such as SHINKO to send the file to a Shinko printer. If you run into problems with SAOimage when displaying images from hosts to clients or across the network, check to make sure that you're only running one version of SAOimage on one machine.

If you get an error printing a file to a certain printer, but not to other printers, there could be a problem with a missing driver or font file. This might give you an error message like:

ERROR: cannot close file 
/nem/p1/stsdasx/bin.f68881/x_cdroms.e: Command not found 
If you get these errors, notify your local system administrator.

imdir--the Image Directory
imtype--Image Formats
Disappearing Plots
Printed Plots Differ From Screen
Other Plot Problems
SAOimage Problems

Generated with WebMaker