Image objects are used to specify pixmap data for either textures (see Texture Mapping), or for background images of cameras (see Camera objects).
At the time of this writing images are comprised of 1 to 4 channels, a
channel provides a single number in the range from 0 to maxval
for each pixel; and maxval is tied to 255. The interpretation of the image data depending on the number of channels is like follows:
| #Channels | Channel No. | Interpretation |
|---|---|---|
| 1 | 1 | greyscale or luminance data |
| 2 | 1 | greyscale or luminance data |
| 2 | alpha channel (0: transparent, maxval: opaque) |
| 3 | 1 | red channel |
| 2 | green channel | |
| 3 | blue channel | |
| 4 | 1 | red channel |
| 2 | green channel | |
| 3 | blue channel | |
| 4 | alpha channel (0: transparent, maxval: opaque) |
Image data can be specified inline (embedded into the current data stream) or via file references; in both cases the data is read in and interpreted at the time the image object is parsed. This is different from the old (and deprecated) texture image specification, where the the image data on-disk would eventually be re-read by Geomview.
The general syntax of image objects is like follows:
<image> ::=
[ "{" ] (curly brace, generally needed to make
the end of the object unambiguous.)
[ "image" ] (optional keyword; unnecessary if the type
is determined by the context, which it
usually is.)
[ "define" <name> ]
(defines an image named <name>, setting
its value from the stuff which follows)
|
"<" <filename> (meaning: read image from that file)
|
":" <name> (meaning: use variable name,
defined elsewhere; if undefined the image
carries no data)
|
(actual stuff defining the image; image data
must come last, after defining the width and
height and number of channels)
"width" (width of the image, auto-detected from image data
if possible)
"height" (height of the image, auto-detected from image data
if possible)
"channels" (number of channels, auto-detected from image data
and data specifications, if possible)
"maxval" (unsupported, must be 255 if specified)
"data DESTMASK [FILTER] [{] < FILENAME [}]"
"data DESTMASK [FILTER] DATASIZE [{][\n]LITERAL_IMAGE_DATA[}]"
(either external or embedded image data, see below
for a detailed description of the meaning of
MASK and FILTER. An image can (and
has, in general) multiple data sections.)
[ "}" ] (matching curly brace)
Details concerning the image data specification:
This is a bit-field describing where the specified image data should be
placed in the destination pixmap. The bit-field is specified by an
integer in one of the known formats (decimal, octal, hexadecimal). The
channels of the source data are always enumbered consecutively. If,
e.g. ‘FILENAME’ or ‘LITERAL_IMAGE_DATA’ specify a
three-channel (probably RGB …) image and ‘DESTMASK’ equals
0xD (i.e. bit 1 is 0), then the 3rd channel of the source pixmap
would be placed in the 4th channel of the destination image object (the
alpha channel), the 2nd source channel would determine the ‘blue’
destination value and the 1st source channel the ‘red’ destination
value.
The number of channels of the source data always has to match the number of bits set in ‘DESTMASK’. Exception: if the source pixmap has only one channel, then it can be used to fill any number of destination channels; all channels specified in ‘DESTMASK’ are filled with the data of the single channel source pixmap.
Geomview knows the following symbolic constants, which can be used instead of specifying the ‘DESTMASK’ bit-field numerically:
LUMINANCEsame as ‘1’, ‘0x1’, ‘\01’
LUMINANCE_ALPHAsame as ‘3’, ‘0x3’, ‘\03’
RGBsame as ‘7’, ‘0x7’, ‘\07’
RGBAsame as ‘15’, ‘0xf’, ‘\017’
ALPHAdepends on the context: the absolute number of channels must be known; i.e. ‘data ALPHA …’ must be prepended by something determining the number of channels of the image, e.g.
... data RGB ... data ALPHA ...
is valid, but
<no other channel or image data specification> data ALPHA ... <whatever else ...>
is not valid, because Geomview has not means to determine the destination channel from the context.
AUTOPGM image data is interpreted as single grey-scale channel, RGB PNM data
as RGB image data. AUTO cannot work with ‘raw’ image data.
The ‘FILTER’ specification is optional. If it is missing, then Geomview tries to determine the image type from the ‘FILENAME’ suffix. If there is no suffix or the suffix is unknown, or for embedded image data, Geomview is able to auto-detectc SGI image file formats (for historical reasons …) and NetPBM image formats (for practical reasons). The auto-detection of NetPBM formats includes the new PAM image format which allows (among other things) to store an alpha channel together with the luminance or RGB data. Likewise, the final output of any of the specified filters must either be in SGI image file format, or specify a PAM, PNM or PGM image. If the image file format cannot be determined by either the filenmae suffix or the filter specification or by auto-deteciong of SGI or NetPBM data, then Geomview assume that it is raw-data. See below.
The decompression filters may be prepended to either one of the know image formats or an explicitly specified filter, e.g. the following is valid:
data LUMINANCE raw.gzip { < gzippedgreymapfile }
The above should be equivalent to
data LUMINANCE raw { < greymapfile },
provided that the decompressed data carries single channel data, with the first pixel corresponding to the lower-left corner (because of the ‘raw’ image format, see below).
Geomview has builtin knowledge for the following filters/suffixes:
data is piped through ‘gzip -dc’
data is piped through ‘bzip2 -dc’
TIFF image file format. Only supported if the tifftopnm
executable can be fond in the current excution path.
PNG image file format. Only supported if the pngtopnm
executable can be fond in the current excution path.
JPEG image file format. Only supported if the jpegtopnm
executable can be fond in the current excution path.
GIF image file format. Only supported if the giftoppm
executable can be fond in the current excution path.
Raw image data; the number of channels must match the number of bits set in ‘DESTMASK’. Pixels are specified with 1 byte per channel. The pixels are organized in rows as ‘liminance[-alpha]’ or ‘RGB[A]’ samples. The left-most pixel is the first pixel in each data-row, the top-most image row must come first (this is just the same as the NetPBM convention, the image co-ordinate systems has its origin in the left/top corner, as usual).
If none of the suffixes specified above should match, then the
suffix/filter is interpreted as an external filter program; the filter
program must read from STDIN and write to STDOUT. The
output must either be in SGI image format, or in PNM or PGM
format. Otherwise the output data is interpreted as raw image data (see
above).
Something like the following should work, provided that the program ${HOME}/bin/bububfilter exists, is executable and does something useful:
...
data RGB "${HOME}/bin/bububfilter.bzip2" 7 { # binary data follows
bububub
}
...
Note that – prior to feeding the data to the ‘bububfilter’ – Geomview will try to decompress the stuff with ‘bzip2 -dc’.
Missing image data: Normally, the number of image channels is
determined automatically from the image data specifications; if
the image specification carries an explicit number of channels via the
channels keyword which exceeds the number of channels found in
the image data specifications, or if the union of all
‘DESTMASK’ specfications has holes, then missing luminance and RGB
channels are initialized to 0, and a missing alpha-channel is
initialized to maxval, i.e. omitting the alpha channel data for
an RGBA image is just the same as defining an RGB image.