Previous chapter LLUs Home Next chapter
The primary components covered in this chapter are:
--------------------------------------------------------------------------- GUIs are supported by and require the X11 Window System. Text-based interfaces are typically equivalent in function to GUIs but only require a standard UNIX environment. ---------------------------------------------------------------------------
This section discusses the environment variables that must be set. Many of the environment variables are invariant from one session to the next, so you may want to place them in your .login or .cshrc file. Your site administrator may have already preconfigured your environment for you. To determine which variables are already set, type:
If you are running remotely on a machine named pebbles and your local workstation where your X11 server is running is named bambam, then you need to set your DISPLAY environment variable on pebbles with:
------------------------------------------------------------------------ The lpr command used above is simply an example. Printing commands vary widely from site to site. Your system administrator should be able to provide you with the printing command appropriate for your site. ------------------------------------------------------------------------
The command:
------------------------------------------------------------------------ The ANSI CGM standard defines three encoding schemes for CGMs: binary, character, and clear text. The clear text produced by the
ctrans -d CTXT option does not conform to the ANSI definition for clear text encoding and is not acceptable as input to other CGM clear-text interpreters. It is merely intended as a debugging aid for the user. ------------------------------------------------------------------------
The command for viewing a metafile frame is plot (you can type p for short). Typing plot at the ictrans> prompt will cause the first frame in the metafile to be displayed. ictrans is case sensitive; typing PLOT will not work. After the frame has been plotted, you can press RETURN to signal ictrans to re-enter command mode (you should see the ictrans> prompt). Entering a second plot command will cause the next frame, if any, to be displayed:
ictrans> p
Note to X users: When ictrans is displaying to an X window, you may find it convenient to operate in movie mode. When ictrans is in movie mode, a RETURN is not necessary to put ictrans into command mode after plotting a frame from your metafile. Enter movie mode by typing:
ictrans> movie 0
You can abbreviate the command plot by typing p; all ictrans commands may be abbreviated up to the point that they are unique. For a complete list of ictrans commands type:
ictrans> help
or just:
ictrans> h
ictrans> 5p
Relative addressing is also possible. To view the last frame in a file type:
ictrans> $p
Here, the $ is an alias for the last frame in the metafile.
For convenience, several frames may be listed on a single command line. To view the first through third, the fifth, and the last frame, type:
ictrans> 1,3 5 $p
After processing each frame, ictrans waits for you to press RETURN before proceeding with the next frame. For a complete description of ictrans frame-addressing syntax, see the man page for ictrans. You can read the man page for ictrans by typing:
ictrans> ! man ictrans
(Typing ! returns you to the UNIX shell for one command.)
ictrans> save save.ncgm
The current frame is the last frame plotted. (If no frames have been plotted the current frame is the first frame in the metafile.)
If you type:
ictrans> s save.ncgm
ictrans will tell you that the command is ambiguous because the s command could stand for either save or spooler. You can, however, abbreviate save with sa. The save command uses identical syntax to the plot command for addressing frames (as do all ictrans commands). To save the third through last frame to the file foo.ncgm, type:
ictrans> 3,$s foo.ncgm
The newly created file, foo.ncgm, may now be translated just like any other NCGM. If you type:
ictrans> file foo.ncgm
foo.ncgm will be read into the translator for processing. The file command is used to change the current file being processed.
ictrans> spooler
If ictrans responds with anything other than "" (null), then there exists at least one device to which ictrans can send translated code. The current printing device name is given by the spooler command when spooler is executed without any arguments as above. (The ictrans command alias, without any arguments, lists all available printing devices, if any.) For example, if spooler responds with a device named "postscript," then to send the first three frames of your file to this device after translation, type:
ictrans> 1,3Print
Don't forget to capitalize the P in Print. The P is capitalized so Print can be abbreviated and not conflict with p for plot.
For more information about configuring ictrans for printing metafiles, see the man pages for ictrans(1NCARG) and ncarv_spool(5NCARG).
ictrans> zoom .0 .0 .5 .5
The two pairs of numbers, (.0, .0) and (.5, .5), specify the lower left and upper right coordinates, respectively, of the frame to be viewed. The new coordinate specification remains in place until changed with a subsequent zoom command. To restore normal viewing type:
ictrans> zoom .0 .0 1. 1.
For example:
ictrans -e 'spooler postscript' -e '$ Print' bnchmk.ncgm
would translate the last frame (the $ frame) in the metafile, presumably into PostScript, and send it to the spooled device named "postscript". Don't forget to enclose all -e options in single quotes or the shell will mistakenly interpret special characters, like $, for you.
This section provides examples of using idt's more common features. For a complete description of idt functionality, see the idt man page.
Once again we assume that you have set your NCARG_ROOT and DISPLAY environment variables correctly as discussed in the "Environment" section. Furthermore, idt requires a device specification of X11. One way to accomplish this is by setting your GRAPHCAP environment variable to X11:
setenv GRAPHCAP X11
A note on entering text: In many of the examples that follow, you will be asked to enter text into a "text widget" that appears on your screen as part of the application. To enter text into a text widget, you must move the mouse sprite so that it is completely inside the surrounding text widget box. Depending on your system's configuration, the sprite should change appearances to confirm its position within the text widget. The Athena Text widget provides many keyboard editing commands. These commands allow you to edit the buffer. The default key bindings are patterned after those in the emacs editor. For example, typing CONTROL-k will delete from the cursor to the end of the line, and DELETE key will delete the previous character. If you are familiar with the emacs editor, you should have no trouble entering text into NCAR Graphics GUIs. If you are not familiar with emacs, you may have to experiment a little to get the hang of it.
Invoke idt by typing:
idt bnchmk.ncgm
Two windows should appear on your screen. The position and dimensions of these windows may be adjusted with the mouse after it appears, or it may be pre-set through your X resource file. The details for manipulating window geometry after the window appears depend on the window manager you are running. See your system administrator, or consult the document "The X Window System at NCAR," which offers some guidelines for customizing your X11 environment.
There are two ways to randomly access frames in your metafile: the first is by using the scrollbar in the upper left corner of the display panel. The second is by using the <goto> button in the third row. When you select <goto>, a small popup dialog box appears and prompts you for the number of the frame to display. If you enter 2 and then select <ok> from the <goto> popup, the second frame in the metafile will be displayed.
You may have already noticed when experimenting with the <play> and <playback> buttons that no matter how fast your X server is, the ensuing sequence of images displayed to your screen does not make a very acceptable animation: To your eye it appears as though images flicker and fail to proceed along in a smooth, animated motion. This is due to an anomaly known as "temporal aliasing." Temporal aliasing results partially from the fact that whatever is drawn on the drawing canvas (lines, filled areas, etc.) is immediately visible. Another factor is the speed at which objects are drawn. As the complexity of an image increases, so does the drawing time.
One way to help alleviate temporal aliasing is to postpone the display of an image until it is completely drawn. This is how the animate function works in idt; images (or frames) are predrawn into an area of memory managed by the X server. When it is time to display each frame in an animation sequence, the entire frame can be posted to the drawing canvas instantly. The rate at which successive images can be posted in this manner is not affected by the complexity of the image, but rather on its spatial resolution (width and height in pixels). If the images are small enough in terms spatial resolution, the X server will be able to display them rapidly and at a constant rate to produce a smooth, flicker-free animation.
There is one drawback to this approach, however: the amount of RAM (random access memory) required to store each predrawn image. RAM is a limited resource on any workstation or X terminal. Be aware that it is the X server memory that is of concern here. X servers run on the workstation that is physically attached to your graphics display.
On most systems, the amount of memory required by an animation sequence can be computed by multiplying the number of pixels in the drawing canvas by the number of frames in the sequence. For example, if your drawing canvas is 512 by 512 pixels and you have 10 frames, then the total memory required is about 512 * 512 * 10 = 2,621,440 bytes. The amount of memory that is actually available to your X server will vary depending on how much physical memory is installed on your machine and what other processes are currently running. So how do you determine how "big" an animation you can run? Experimentation is probably the best method. Start with something small, just a few frames, then move up. If the animation gets too big, there will be a noticeable degradation in performance.
One final word of caution: UNIX processes typically do not free up dynamically allocated memory for other processes to use until they exit. Using idt to animate imagery may cause your X server to grow substantially. On some systems, this is a trivial issue because each console login session starts a new X server. On other systems, it may be necessary to restart your server manually if it grows too big. Check with your system administrator. Your system administrator should also be able to tell you how to monitor the size of your X server.
Below are the steps, and some guidelines, for successfully animating a sequence of metafile imagery.
The first step is to determine how many and which frames you want to animate from your file. As discussed, it's likely that it will not be possible to animate your entire file at once. Fortunately, idt provides a convenient mechanism for selecting only a portion of your image file: segments (see the section on idt segments). When you enter animate mode, only the currently defined segment is preprocessed and loaded into server memory. By default, the current segment is the entire metafile, so you may need to define a new segment. Defining a new segment is a simple process and was discussed earlier in the "idt segments" section. We'll assume we are still working with the bnchmk.ncgm file, which only contains six frames. For this example, we will animate the entire file. You may want to check the value of the <start segment> and <stop segment> to verify that the current segment is indeed the entire file.
The next step is to select the <animate> button. idt will begin processing the frames in the segment and loading them into server memory. For our example, this should only take a few seconds. For a really large segment, this process might take several minutes (Note: the total preprocessing time also depends on the size of the drawing canvas.). The text window in the control panel will keep you informed of idt's progress.
When the preprocessing is complete, the text window in the control panel will display the message "Done loading x images," where x is the number of frames in your segment. Now you can start your animation. The animation is controlled the same way that the display of normal metafile imagery is controlled. Selecting the <play> button will "play" your animation in the forward direction. The <playback> button will cause your animation to play backward. If <loop> is turned on, the animation will loop repeatedly until the <stop> button is selected.
One animation feature that is only available in animation mode is the <delay> button. If your animation is moving too fast, you can slow it down by setting a delay time, in 1/100's of a second. By default, the delay time is 0.
To terminate your animation and go back to normal metafile processing, select the <animate> button a second time.
The uppermost box of the popup file selector contains a text widget with an asterisk (*) displayed. The asterisk is the metacharacter used in both the Bourne shell and the C shell for matching zero or more characters in a filename. Hence all the files in the current directory are displayed in the middle box. You can change the mask for the file finder by simply editing the file finder text widget and selecting <finder>. For example, if you enter:
*.ncgm
and select <finder> or press RETURN, all of the files in the current directory with the ".ncgm" name extension will be displayed. Or, if you enter:
/u1/joe/*
all of the files in the user directory /u1/joe will be displayed.
When the desired filename is displayed in the selection box, you may confirm your choice by selecting <ok>. You have now informed idt of the name of the next metafile to process. idt will pop up a new display panel with which to plot the new metafile.
All of med's editing functions are performed in a temporary buffer. This greatly improves the speed with which med can perform its actions. Changes made in the buffer have no effect on the original file until the buffer is written to disk with the write command. If you terminate a med session without saving the buffer, all changes will be lost.
Under normal invocation, med will enter command mode and display the prompt med>. The prompt is a signal that med is ready to accept commands from the user. The basic format of a med command is:
[address] command
where address is an optional field listing a range of frames on which to perform the named command. Frames are numbered starting with 1. A comma-separated pair of numbers specifies an inclusive range of frames on which to operate. If no address is given, the current frame is assumed as default. As with ictrans, med commands may be abbreviated up to the point that they are unique. A complete description of addressing syntax is given in the man page for med.
Assuming you have an NCAR CGM named bnchmk.ncgm, invoke med with the command:
med bnchmk.ncgm
med will respond with the number of frames in the file. The current frame is set to the last frame in the file. (Note that this is different from ictrans, which uses the first frame in the file as the default current frame). If bnchmk.ncgm was created with the ncargex utility described earlier, med should report the existence of six frames.
med> 1,6print
A listing for each of the six frames will appear.
med> 1,3write test.ncgm
The first three frames in bnchmk.ncgm will be written to test.ncgm. If the file already exists, it is overwritten.
med> 6 append test.ncgm
The file test.ncgm now contains the first through third and the sixth frame from the file bnchmk.ncgm.
med> read test.ncgm
This will read all of the frames contained in the file test.ncgm and append them after the current frame. med will report the number of frames read successfully. A destination other than the current frame offset may be specified as the target for the incoming frames. The command:
med> 1 read test.ncgm
will append the contents of the file test.ncgm after the first frame in the buffer. The first frame in test.ncgm will become the second frame in the buffer.
med> 1,$ split 10
to create a sequence of files named med001 through med010, each containing one hundred frames. med001 would contain the first hundred frames from the original file, med002 would contain the second hundred frames, and so forth.
The number of split files created does not have to be an integral divisor of the total number of frames. med will do its best to keep the same number of frames in each split file.
[source_frames] copy [destination]
where source_frames is a list of frames to copy and destination is the destination frame of the copy. The frames copied are appended after destination. For example, to make a copy of the first two frames and place them at the end of the file, use:
med> 1,2 copy $
In this example, the $ is an alias for the last frame in a file. This is helpful if you do not know how many frames are contained in the NCGM.
med> $-1,$ delete
The $-1 denotes the offset of the last frame minus 1, that is, the second from last frame. The second $ denotes the last frame, so $-1,$ denotes the last two frames in the buffer.
[source_frames] move [destination]
To move the first frame to the end of the file, making the second frame the first frame and the original first frame the last frame, type:
med> 1 move $
med> 1,2 merge
appends the drawing instructions contained in frame 2 to frame 1. This changes frame 1, and frame 2 is unaltered.
--------------------------------------------------------------------
This command may produce unexpected results depending on how
color and GKS point, line, and text attributes are specified in the
metafile.
--------------------------------------------------------------------
med> edit test.ncgm
will read the file test.ncgm into the buffer.
The edit command has a safeguard to prevent you from accidentally destroying changes made to a buffer that have not been saved. If unsaved changes exist, the edit command will fail and print a warning message. To prevent this, save the file before executing edit:
med> w
or append a ! to the edit command. This tells edit to disregard any unsaved changes:
med> edit ! test.ncgm
med> help delete
med will describe the syntax for the delete command.
Like ictrans, med performs commands from the command line using the -e option.
For example, when issued from the command line, the command:
med -e '1,$ split 3 bnch' bnchmk.ncgm
would split the file bnchmk.ncgm into three smaller files: bnch001.ncgm, bnch002.ncgm, and bnch003.ncgm.
The command:
med -e 'r bnch001.ncgm' -e 'r bnch002.ncgm' -e 'r bnch003.ncgm' \\
-e 'w all.ncgm'
would concatenate the bnch* files into a single metafile, all.ncgm. The all.ncgm file should be identical to the original bnchmk.ncgm.
------------------------------------------------------------------------ Raster imagery is a set of picture elements (pixels) arrayed on a grid; these are sometimes called pixmaps. Each pixel in the image contains color information specifying the appearance for that particular pixel. Raster images have an inherent spatial resolution determined by the number of pixels in the grid. By contrast, page-description imagery, such as NCGM, CGM, or PostScript, contains a set of instructions for drawing a graphic. There is no inherent spatial resolution for page- description formats. ------------------------------------------------------------------------
Because raster utilities often need to read or write raster data from the standard input or output, in which case filenames are not visible to the application, all NCAR Graphics raster commands accept a command line option for specifying file formats that overrides any filename extension. The -ifmt option specifies the format of a file to be read. The -ofmt option specifies the format of a file to be written.
rasview displays raster images on your workstation
rascat converts raster formats, concatenates files, resizes imagery, and inserts new color palettes
rassplit splits a multiframe raster file into single-frame raster files
rasgetpal extracts the color palette from a raster file
rasls lists raster files
rasview foo.sun
or:
rasview -ifmt sun < foo.sun
-------------------------------------------------------------------------
Make sure you place the mouse sprite inside the rasview window after
you invoke it. rasview will not show an image's true colors unless you
do so. If you do not have a raster file available, you may create one by
converting (rasterizing) an NCGM with the ctrans utility. For example,
the command:
ctrans -d sun bnchmk.ncgm > foo.sun
would convert the NCGM bnchmk.ncgm into a Sun-formatted raster
file named foo.sun, at the default resolution of 512x512.
-------------------------------------------------------------------------
If the raster file contains multiple images, clicking the left mouse button in the rasview window will advance to each successive image. In the event that you would just like the images to be displayed to your window as quickly as possible, you can specify the -movie option. The following command invokes rasview so that it displays all of the frames in the Hierarchical Data Format (HDF) file temp.hdf to your window without waiting for a mouse-click between frames:rasview -movie temp.hdf
The rasview utility will also allow you to specify a different color table from the one supplied with the image. This is only true for "indexed-color" imagery and does not work for "true-color" or "direct-color" imagery.
Assuming you have an HDF raster file with indexed-color imagery in it, and you've created a new color table using the National Center for Supercomputing Applications' (NCSA) XImage, you can tell rasview to use the new color palette:
rasview -pal new.pal temp.hdf
Color palettes are discussed in detail in the "Color palettes" section.
rascat bar.nrif -ofmt hdf > bar.hdf
or:
rascat bar.nrif -output bar.hdf
rascat will also allow you to concatenate several raster files of different formats into a single raster file. The raster files must all be the same size and encoding type (indexed, for example). The following command demonstrates the concatenation of an HDF file, a Sun file, and an X Window Dump (XWD) file to a Sun file:
rascat title.hdf temp.sun credit.xwd -output all.sun
The rascat utility also provides resolution conversion. Let's assume you have a Sun raster file named video.sun that has a resolution of 640x480 pixels, and that you would like to shrink it to 240x180. (Note that resizing can "warp" an image; these resolutions were carefully selected to maintain the same image aspect ratio.) Type:
rascat -res 240x180 video.sun -output small-video.sun
If you have indexed-color imagery, rascat will also allow you to insert a new color palette during conversion. (For information on color palette formats, see the "Color palettes" section.) Building on the previous example, we'll have rascat both scale the image down and insert a new color palette with the output image:
rascat -res 240x180 -pal new.txt -output small-video.sun
The lines below are the output of rasls when it was run in a directory that contained several different types of raster files.
rasls *
Sun RAS_DIRECT 2816X2176 above.256.sun
Sun RAS_INDEXED 215X215 all.sun
X Window Dump RAS_INDEXED 512X512 coex03.xwd
Abekas RGB RAS_DIRECT 720X486 new.a60
NRIF RAS_INDEXED 640X480 new.nrif
AVS RAS_DIRECT 440X440 sample.avs
SGI RAS_DIRECT 646X485 earthstars.rgb
Color palettes can be stored in a file in two formats, binary and textual. Palettes stored in binary format must have a file extension of .pal, and palettes stored in textual format must have a file extension of .txt. Detailed information on both of these formats is provided later in this section.
NCAR Graphics utilities rasview and rascat will both accept an option that specifies an alternate color palette. The rasgetpal utility lets you extract a color palette from an existing raster file.
The example below demonstrates the extraction of a textual color palette from the raster file temp.hdf:
rasgetpal temp.hdf temp.txt
Now that you have a textual copy of the color palette in temp.txt, you could change it with a standard text editor. You can now use temp.hdf's color palette, temp.txt, to view pres.hdf:
rasview -pal temp.txt pres.hdf
Binary color palette format: The binary format is compatible with NCSA HDF and must have the ".pal" file extension. The palette has a red, a green, and a blue table, each with 256 single unsigned byte entries. A 0 represents no intensity for a given color, and a 255 full intensity. In the file, the palette is stored as:
R0 R1 ... R255 G0 G1 ... G255 B0 B1 ... B255
for a total of 768 bytes.
index_number red green blue
where index_number, red, green, and blue are all integers in the range 0 to 255.
Set color index 0 to black: 0 0 0 0
Set color index 255 to white: 255 255 255 255
Grayscale ramp:
Let's suppose you have a file named my.txt and it has just two lines in it: the black entry and the white entry shown above. This will produce a grayscale color palette, where the table starts at black and ramps up to white; since only entries 0 and 255 are specified, the remaining indices are interpolated.
0 0 0 0
255 255 255 255
(Note: An empty palette file (such as empty.txt) is legal and, since the 0 index defaults to black and the 255 index to white, produces a grayscale ramp just as in the preceding example.)
0 0 0 0
1 0 0 255
255 255 0 0
rassplit temp.sun
This command will produce temp.0001.sun, temp.0002.sun, and so on for all the frames originally in temp.sun.
Now, to produce files from frames 5 and 7 of temp.sun:
rassplit -f 5 7 temp.sun
And, building on the previous example, to produce files from frames 5 and 7 but store the result as an HDF file:
rassplit -f 5 7 -ofmt hdf temp.sun
cgm2ncgm < vanilla.cgm > ncar.ncgm
will read in a vanilla CGM named vanilla.cgm and produce an NCAR CGM named ncar.ncgm.
Similarly, NCGMs cannot be parsed by non-NCAR Graphics applications. To convert the NCGM ncar.ncgm to the vanilla CGM vanilla.cgm, use:
ncgm2cgm < ncar.ncgm > vanilla.cgm
---------------------------------------------------------------------- A converted CGM may not produce entirely correct results when translated. NCAR Graphics translators operate on a subset of elements of the CGM standard (as do many CGM translators) and thus may encounter valid CGM elements that they do not know how to translate. Similarly, NCGMs converted to vanilla CGMs are not guaranteed to be correctly translated or even parsed by third-party translators. ----------------------------------------------------------------------
ctrans -d format -res resolution metafile > raster_file
For example, the command:
ctrans -d hdf -res 512x512 myfile.ncgm > myfile.hdf
converts the NCGM myfile.ncgm into an HDF raster file, myfile.hdf, with a 512x512 pixel resolution. HDF files are accepted by the NCSA application XImage.
The command:
ctrans -d avs -res 200x200 myfile.ncgm > myfile.avs
converts myfile.ncgm into a 200x200-pixel AVS file. The AVS raster file format is suitable for ingestion by the Application Visualization System. Finally, an SGI raster file may be created with a command like:
ctrans -d sgi -res 200x200 myfile.ncgm > myfile.sgi
SGI raster files are understood by Silicon Graphics Inc.'s Explorer.
Previous chapter LLUs Home Next chapter