Utah Raster Toolkit is a collection of programs and C routines for
dealing with raster images commonly encountered in computer graphics.
A device and system independent image format stores images
and information about them. Called the
format, it uses
run length encoding to reduce storage space for most images.
The programs (tools) currently included in the toolkit are listed above,
together with a short description of each one. Most of the tools read
one or more input RLE files and produce an output RLE file. Some
generate RLE files from other information, and some read RLE files and
produce output of a different form.
An input file is almost always specified by mentioning its name on the
command line. Some commands, usually those which take an indefinite
number of non-file arguments (e.g.,
rleaddcom) require a
-i flag to introduce the input file name.
If the input file name is absent the tool will usually
read from the standard input. An input file name of "-" also signals
that the input should be taken from the standard input.
systems, there are two other specially treated file name forms. A
file name starting with the character | will be passed to
to run as a command. The output from the command will be read by the
tool. A file whose name ends in ".Z" (and which does not begin with
a |) will be decompressed by the
program. Both of these options supply input to the tool through a
pipe. Consequently, certain programs (those that must read their
input twice) cannot take advantage of these features. This is noted
in the manual pages for the affected commands.
An output file is almost always specified using the option
outfile. If the option is missing, or if
outfile is "-", then the output will be written to the standard output.
On Unix systems, the special file name forms above may also be used
for output files. File names starting with | are taken as a command
to which the tool output will be sent. If the file name ends in ".Z",
compress will be used to produce a compressed output file.
Several images may be concatenated together into a single file, and
most of the tools will properly process all the images. Those that
will not are noted in their respective man pages.
Picture comments. Images stored in RLE form may have attached comments. There are
some comments that are interpreted, created or manipulated by certain
of the tools. In the list below, a word enclosed in <> is a
place-holder for a value. The <> do not appear in the actual comment.
Images are sometimes computed with a particular gamma value --
that is, the pixel values in the image are related to the actual
intensity by a power law, pixel_value=intensity^image_gamma.
Some of the display programs, and the buildmap(3) function will
look for this comment and automatically build a "compensation table"
to transform the pixel values back to true intensity values.
The display_gamma is just 1/image_gamma. That is, it is
the gamma of the display for which the image was computed. If an
image_gamma comment is not present, but a display_gamma
is, the displayed image will be gamma corrected as above. The
to8 program produces a display_gamma comment.
The length of the colormap stored in the RLE header must be a
power of two. However, the number of useful entries in the colormap
may be smaller than this. This comment can be used to tell some
of the display programs (getx11, in particular) how many of
the colormap entries are used. The assumption is that entries 0 -
colormap_length-1 are used. This comment is produced by
mcut, rlequant, and rledither.
This comment is used by getx11 to set the window title. If
present, the comment is used instead of the file name. (No other
programs currently pay attention to this comment.) The comments
IMAGE_TITLE, title, and TITLE are also recognized,
in that order. No programs produce this comment.
All toolkit programs (with the exception of rleaddcom) create or add
to a HISTORY comment. Each tool appends a line to this comment
that contains its command line arguments and the time it was run.
Thus, the image contains a history of all the things that were done to
it. No programs interpret this comment.
This comment should be present in a file stored in exponential
form. See unexp(1) and float_to_exp(3) for more
information. The unexp program expects to see this comment.