Comments - begin with a '#' to the next end-of-line.
May be placed anywhere in the header.
pgm - portable graymap file format
This file format is used as the lowest common
deonominator grayscale file format.
The header contains the following information:
ascii raw
----- -----
Magic Number - P2 or P5
Whitespace - (blanks, TABs, CRs, LFs)
Width - formatted as ASCII characters in decimal.
Whitespace -
Height - formatted as ASCII characters in decimal.
Whitespace -
Max Value - formatted as ASCII characters in decimal.
Whitespace -
Data:
ASCII (P2) - characters specifying the gray value in
ASCII decimal. These values may range
anywhere from 0 to the maximum gray value.
Each character is separated by whitespace,
and starts at the top left corner of the
graymap. A value of 0 means black, and
the maximum value means white. No line
should be longer than 70 characters.
RAW (P5) - The gray values are stored as plain bytes
instead of ASCII decimal. No whitespace
is allowed in this section. Note that
values in this section are limited to
maxvalues less than or equal to 255.
Comments - begin with a '#' to the next end-of-line.
May be placed anywhere in the header.
ppm - portable pixmap file format
This file format is used as the lowest common
deonominator color image file format.
The header contains the following information:
ascii raw
----- -----
Magic Number - P3 or P6
Whitespace - (blanks, TABs, CRs, LFs)
Width - formatted as ASCII characters in decimal.
Whitespace -
Height - formatted as ASCII characters in decimal.
Whitespace -
Max Value - formatted as ASCII characters in decimal.
Whitespace -
Data:
ASCII (P3) - characters specifying the maximum color-
component value, in ASCII decimal. Three
values are required to represent each pixel.
One value for each component of "r" "g" "b".
Each character is separated by whitespace,
and starts at the top left corner of the
pixmap. The three values for each pixel
represent red, green, and blue respectively.
A value of 0 means that the color is turned
off and the maxvalue represents the maximum
intensity for that color. No line should be
longer than 70 characters.
RAW (P6) - The gray values are stored as plain bytes
instead of ASCII decimal. No whitespace
is allowed in this section. Note that
values in this section are limited to
maxvalues less than or equal to 255.
Comments - begin with a '#' to the next end-of-line.
May be placed anywhere in the header.
The PBM file formats described above were created by Jef Poskanzer,
Copyright (C) 1989.
The resulting VIFF image will of data storage type, BIT, BYTE,
SHORT, and INTEGER.
The map sheme will be none, since a multiband color image will be
stored as three bands in the VIFF image. Therefore the VIFF image
will be either a 1-band image or a 3-band image with no color map.
The resulting VIFF image will be stored as data type BIT if the
input image was a pbm image. A 1-band VIFF image of type INTEGER
will result if the input image is of type pgm stored as ASCII data.
If the pgm image was stored as raw data, then the resulting VIFF
will be stored as a 1-band BYTE image. A ppm image stored as ASCII
data will result in a 3-band INTEGER image, whereas a ppm image
Since the PBM file format does not contain any color map information,
the resulting output VIFF image will not contain a color map.
The valid input files must be one of the PBM file format types discussed
above.
SEE ALSO
pbm2AVS(1), intro(3), vipl(3), verror(3), vutils(3)
AUTHOR
Mark Young
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module rast2AVS
INPUT
Input to rast2AVS :
rast_image A SUN raster image of type struct rast that
has the correct byte order for the machine
processing the image
invert_flag resulting image is either photopositive (1)
or photonegaative (0)
OUTPUT
AVS_image A pointer to struct xvimage, this image will
contain the converted image from SUN rast to
VIFF.
DESCRIPTION
rast2AVS : rast2AVS is a library that converts a SUN
raster image into a VIFF image.
This library will convert SUN raster image of depth 1, 8 or
24 into a VIFF image. This routine does not support SUN ras-
ter images that have been encoded using run-length compres-
sion. If the SUN raster image contains colormaps, those maps
will be preserved in the VIFF image. The resulting VIFF
image will be a BIT image if the SUN rater image had a depth
of 1, or BYTE if the SUN raaster image had a depth of 8 or
24. In the case that the depth of the SUN image is equal to
24, then the VIFF image will contain 3 data bands (red,
green and blue).
If the SUN raster image is of type bit (depth = 1), then the
invert flag may be used to invert the image. If the image is
not of type bit (depth = 1) then the -p option is ignored.
The SUN raster image is defined as follows:
A Sun raster image file is composed of three parts: a
header containing 8 integers, a possibly empty set of
colormap values, and the pixel image, stored a line at
a time, in increasing y order. The image is layed out
in the file as in a memory pixrect. Each line of the
image is rounded up to the nearest 16 bits.
The header is defined as follows:
int ras_magic;
int ras_width;
int ras_height;
int ras_depth;
int ras_length;
int ras_type;
int ras_maptype;
The ras_magic field always contains the value
0x59a66a95 (hex).
The ras_width and ras_height are the width and height
of the image given pixels.
The ras_depth is the number of bits used per pixel (1,
8, or 24).
The ras_length is the number of bytes used to store the
data of the image.
The ras_type field is one of the following:
RT_OLD 0 -- Raw pixrect image in 68000 byte order
RT_STANDARD 1 -- Raw pixrect image in 68000 byte order
RT_BYTE_ENCODED 2 -- Run-length compression of bytes
RT_EXPERIMENTAL 0xffff -- Reserved for testing
For historical reasons, files of type RT_OLD will usu-
ally have a 0 in the ras_length field and therefore the
actual image length will need to be computed.
The ras_maptype will be one of the following:
RMT_NONE 0 --ras_maplength is expected to be 0
RMT_EQUAL_RGB 1 --red[ras_maplength/3],green[],blue[]
RMT_RAW 2 --Sun's registered maptype
If ras_maptype is not RMT_NONE and the ras_maplength is
not 0, then the colormap values are the ras_maplength
bytes immediately following the header. The ras-
maplength is the number of bytes used to store the
images colormap. These values are either uninterpreted
bytes (usually with the ras_maptype set to RMT_RAW) or
the equal length red, green and blue vectors, in that
order (when the ras_maptype is RMT_EQUAL_RGB). In the
latter case, the ras_maplength must be three times the
size in bytes of any one of the vectors.
RESTRICTIONS
vrast2AVS always assumes that the SUN raster image is in
IEEE or Big Endian byte order (SUN's Byte Order).
AUTHOR
Tom Sauer
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module tga2AVS
INPUT
*tga_image _ a tga structure
**image _ a pointer on a xvimage
OUTPUT
returns FALSE upon failure and TRUE upon sucess.
DESCRIPTION
The purpose of this routine is to convert tga image into
AVS image. The tga format is described below. the AVS for-
mat can be read in the KHOROS manual.
Only the tga image 1,2 and 3 (respectively Uncompressed
Color Mapped Image, Uncompressed True-Color Image and
Uncompressed Black and White Image) are converted.
The Extension Area, the Developer Fields and the TGA Footer
are not processed yet, but will be if anybody needs it.
This section defines the file formats recommended for
storing images for the AT&T Truevision product family.
These formats should be used by all software developed
for the Truevision product family. This standard is
recommended since it allows software products to be
compatible with our telecommunications and imaging
software.
Truevision Inc. has currently defined eleventypes of
data files.
The File Format is the following one:
BYTE ||| FIELD NAME |
__________________________________________
------------------------------------------ -----
0 ||| I.D. Length | |
__________________________________________ |
------------------------------------------ |
1 ||| Color Map Type | |
__________________________________________ |
------------------------------------------ | T G A
File
2 ||| Image Type | | (Fixed
Length)
__________________________________________ |
------------------------------------------ |-----
3 ||| Color Map Specification | |
||| ( 5 bytes ) | |
__________________________________________ |
------------------------------------------ |
8 ||| Image Specification | |
||| ( 10 bytes) | |
__________________________________________ |
------------------------------------------ ----|
Variable||| Image I.D. | | Image /
__________________________________________ | Color Map
------------------------------------------ | DATA
Variable||| Color Map Data | | Variable
__________________________________________ | Length
------------------------------------------ |
Variable||| Image Data | |
__________________________________________ |
------------------------------------------ |
Variable||| Developer Fields | |
__________________________________________ |
------------------------------------------ |
Variable||| Developer Directory | |
||| | |
__________________________________________ |
------------------------------------------ ----|
0 ||| Extension Size |Short |
------------------------------------------ |
2 ||| Author Name |ASCII |
------------------------------------------ |
43 ||| Authors Comments |ASCII |
------------------------------------------ |
367 ||| Date / Time Stamp |Shorts |
------------------------------------------ |
379 ||| Job Name / ID |Short |
------------------------------------------ |
420 ||| Job Time |Shorts |
------------------------------------------ |
426 ||| Software I.D. |ASCII |
------------------------------------------ | Extension
Area
467 ||| Software Version |3 Bytes| Variable
------------------------------------------ | Length
470 ||| Key Color |Long |
(Optional)
------------------------------------------ |-----
474 ||| Pixel Aspect Ratio |Shorts |
------------------------------------------ |
478 ||| Gamma Value |ASCII | only for
------------------------------------------ | version
2.0
482 ||| Color Correction Offset |long | and +
------------------------------------------ |
486 ||| Postage Stamp Offset |long |
------------------------------------------ |
490 ||| Scan Line Offset |Long |
------------------------------------------ |
494 ||| Attributes Type |Byte |
__________________________________________ |
------------------------------------------ |
Variable||| Scan Line Table | |
------------------------------------------ |
Variable||| Postage Stamp Image | |
------------------------------------------ |
2 kbytes||| Color Correction Table | |
__________________________________________ ____|
------------------------------------------ ----|
0 ||| Extension Area Offset |Long | T G A
File
------------------------------------------ | Footer
4 ||| Developper Directory Offs |Long | Fixed
Length
------------------------------------------ |-----
8 ||| Extension / Order Signatu |ASCII |
--------------------------------------------------
(Optional)
Description of the different Usefull fields
1 Field 1:
2 Number of characters in IDENTIFICATION FIELD (1 byte).
This field identifies the number of bytes in field 6,
the image identification field. The maximum number of
characters is 255. A value of 0 indicates that no iden-
tification field is included.
1 Field 2:
2 Color_Map Type (1 byte).
1 Field 3:
2 Image Type Code (1 byte).
1 Field 4:
2 Color_Map Specification (5 bytes).
1 Field 4.1:
2 Color Map Origin (2 bytes). Index of first color_map
entry.
1 Field 4.2:
2 Color Map Length (2 bytes). Number of color_map
entries.
1 Field 4.3:
2 Color Map Entry Size (1 byte). Number of bits in
color_map entry.
1 Field 5:
2 Image Specification (10 bytes).
1 Field 5.1:
2 X-origin of image (2 bytes). 5.1 and 5.2 specify the
lower left corner of the image.
1 Field 5.2:
2 (2 bytes). See previous subfield.
1 Field 5.3:
2 (2 bytes). Width of the image in pixels.
2 Field 5.4:
2 (2 bytes). Height of the image in pixels.
1 Field 5.5:
2 Image Pixel Size (1 byte). Number of bits in a stored
pixel.
1 Field 5.6:
2 Image Descriptor Byte (1byte).
3 Bit 3-0: Number of attribute bits associated with each
pixel.
3 Bit 4 : Reserved. Must be 0.
3 Bit 5 : Screen origin bit:
4 0 _ Origin in lower left-hand corner
4 1 _ Origin in upper left-hand corner
4 Must be set to 0 for Truevision images.
3 Bit 7-6: Data storage Interleaving Flag
4 00 - Non Interleaved.
4 01 Two way interleaving.
4 10 Four way interleaving.
4 11 Reserved
2 Bits 7 through 4 must be set to 0 for the Truevision
products.
1 Field 6:
2 Image Identification Field (variable):
3 Contains an identification field whose length in bytes
is specified in field 1. If required, additionnal iden-
tification information may be stored after the image
data field (field 8).
2 Field 7:
3 Color Map Data (variable): Field 4.3 specifies the
width in bits of each color map entry while field 4.2
specifies the number of color-map entries in this
field. Each color map is stored using an integral
number bytes. The RGB specification for each color map
entry is stored in successive bit-fields in the multi-
byte entries are assumed to be (Field 4.3)/3 bits in
length. Unused bit(s) in the multi-byte entries are
assumed to specify attribute bits.
2 Field 8:
3 Image data field (variable): This field specifies
(width x height) pixels. Each pixel specifies a color
map index. The values for Width and Height are speci-
fied in fields 5.3 and 5.4 respectively. The attribute
and color definition bits for each picxel are defined
in fields 5.5 and 5.6, respectively. Each pixel is
stored as an integral number of bytes and the color-map
index is stored in the least significant bits of the
field.
1 All fields are assumed to be unsigned. The low-order
byte of two-byte field is stored first.
---------
------------------------------------------------------
|Data | Description
|
|
|
|Field|
|
|---------
------------------------------------------------------
| 0 | No Image Data Included
|
|---------
------------------------------------------------------
| 1 | Uncompressed, Color Mapped (VDA/D and Targa M8)
images |
|---------
------------------------------------------------------
| 2 | Uncompressed, RGB Images
|
|---------
------------------------------------------------------
| 3 | Uncompressed, Black and White Images
|
|---------
------------------------------------------------------
| 9 | Run-Length Encoded Color Mapped Images
|
|---------
------------------------------------------------------
| 10 | Run-Length Encoded RGB
|
|---------
------------------------------------------------------
| 11 | Compressed, Black and White Images
|
|---------
------------------------------------------------------
| 32 | Compressed Color-Mapped Data using Huffman, Delta,
and |
| | Run_Length Encoding.
|
|---------
------------------------------------------------------
| 33 | Compressed Color-Mapped Data using Huffman, Delta,
and |
| | Run_Length Encoding. Data encoded for presentation
in |
| | 4 passes.
|
----------
------------------------------------------------------
Data type codes 0 to 127 (field 3) are reserved for use by
Truevision Inc. for general applications. Data types 128 to
255 may be used for user-specific applications. Similarly,
the first 128 map types codes (field 2) are reserved and the
second set of 128 map type codes may be used for user-
specific applications.
The information in this file was derived from Appendix C:
TRUEVISION IMAGE FILE FORMATS of the TRUEVISION manual.
If The tag image type has not been implemented, a error mes-
sage will be sent to the user.
An Option called EXTRASKIP LENGTH has been added due to
problem encountered when converting tga images produced on a
MACINTOSH.
The -e flag is to get around a problem with some methods of
transfering files from the Mac world to the Unix world.
Most of these methods leave the Mac files alone, but a few
of them add the "finderinfo" datia onto the front of the
Unix file. This means an extra 128 bytes to skip over when
reading the file. The symptom to watch for is that the
resulting PBM file looks shifted to one side. If you get
this, try -e 128, and if that still doesn't look right try
another value.
SEE ALSO
tga2AVS(1), intro(3), vipl(3), verror(3), vutils(3)
tga2AVS (1) lAVS2tga (3) AVS2tga (1)
AUTHOR
Pascal ADAM
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module tiff2AVS
INPUT
TIFF *tif - pointer to the tif image structure (header
returned by TIFFOpen)
struct xvimage **AVS - pointer to a pointer of a VIFF
image file (malloced in this routine)
int verbose - if set prints Tiff image header informa-
tion
char *filename - the name of the input file
OUTPUT
struct xvimage **AVS_image - malloced and copied
imagedata for VIFF image
DESCRIPTION
tiff2AVS converts a TIFF image to a Khoros VIFF image. The
verbose flag specifies verbose mode. In verbose mode, infor-
mation about the input TIFF image and output VIFF image is
printed out.
Tiff2AVS will convert TIFF images setting the TIFF header
with the following information:
BitsPerSample
If the TIFF image has 1 bit per sample the resulting
VIFF image will be of type BIT. Otherwise the resulting
image will be of type BYTE. Tiff2AVS will not accept
a TIFF image with the bits per sample greater than 8.
SamplesPerPixel
Tiff2AVS will convert TIFF images that contain either
1, 3 or 4 samples per pixel. If the samples per pixel
is 1, then the resulting VIFF image will contain one
data band. If the samples per pixel is 3 or 4, then the
resulting VIFF image will contain 3 data bands. In the
3 data band case, the image is most likely a true RGB
image (24 bits).
PhotometricInterpretation
Tiff2AVS will convert TIFF images with a photometric
interpretation of Min Is Black, Min Is White, RGB, and
Palette. In the case that the TIFF image is Min Is
Black, the resulting VIFF image will be a single band
grey scale image with the black pixel equal to 0. In
the case that the TIFF image is Min Is White, the
resulting VIFF image will be a single band grey scale
image with the white pixel equal to 0 (this is an
inverted image). If the TIFF image's photometric
interpretation is set to RGB, the resulting VIFF image
will contain 3 data bands, one for red, one for green
and one for blue (true RGB). The color space model is
set to generic_RGB. Finally, if the TIFF image's pho-
tometric interpretation is set to Palette, the result-
ing VIFF image will contain a 3 column by N color
colormap. The color space model is set to generic RGB.
Note, Tiff2AVS does not support photometric interpre-
tation of Mask and Depth.
PlanerConfiguration
Tiff2AVS supports a TIFF image that contains a con-
tiguous planer configuration or a separate configura-
tion. Planer Configuration is only important with the
TIFF image is a true 24 or 32 bit RGB image. The TIFF
contiguous planer configuration implies that the pixels
are arranged as RGBRGBRGB..., where as a separate
planer configuration implies that the pixels are for
each color component (red, green and blue) are stored
as planes of bands. Note, a VIFF image always stores an
image with the color compenents in separate bands.
Compression
The compression type supported are limited to the sup-
port provided by the public domain TIFF library utili-
ties. The current compression types supported are:
None, LZW, CCITTFAX3, CCITTRLEW and PACKBITS.
Tiff2AVS uses the public domain TIFF library utilities.
This routine is based on Release 2.2 of libtiff. The source
for libtiff is as follows: The software is available for
public ftp on
ucbvax.berkeley.edu pub/tiff/tiff.tar.Z
(128.132.130.12)
uunet.uu.net graphics/tiff.tar.Z
(192.48.96.2) Libtiff provides the mechanisms to
read, write, uncompress and compress TIFF images.
Becasue the TIFF (Tag Image File Format) image specification
is long and involved, please see the TIFF 5.0 specification.
This specification can be obtained from: Developers' Desk
Aldus Corp. 411 First Ave. South Suite 200 Seattle, WA
98104 (206) 622-5500
SEE ALSO
tiff2AVS(1), intro(3), vipl(3), verror(3), vutils(3)
AVS2tiff(1), lAVS2tiff(3), libtiff(3)
RESTRICTIONS
Ltiff2AVS does not support TIFF images that contain more
that 8 bit per sample. Also, the photometric interpretation
of transparency mask and depth are not supported.
AUTHOR
Tom Sauer
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module AVS2fits
INPUT
struct xvimage *AVS_image - input image to be con-
verted
OUTPUT
struct fits **fits_image - resulting fits image.
DESCRIPTION
AVS2fits is a routine that converts a VIFF image file for-
mat into a FITS file format.
SEE ALSO
AVS2fits(1), intro(3), vipl(3), verror(3), vutils(3)
file_formats(3)
RESTRICTIONS
The output FITS image should be in IEEE order, but is
currently written in the native byte order of the machine
executing the code. This should be fixed... SRW
AUTHOR
Robin Corbet, PSU
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module AVS2mat
INPUT
fname specify ouput file
image input matrix image to operate on.
style input the control string for style of output.
In normal C style format control string for
printf. ex: %-5.2f specifies left justified
floating point number with a total
size of 5 spaces with 2 for the
fractional part. Note: Does not include hex-
idecimal or octal output format.
numcols the number of columns per line.
delimiter the type of element delimiter. 0-> space 1->
comma
bracket determines the type of bracket used in the
matrix. 0-> "[ ]" 1-> "< >"
OUTPUT
errnum errnum returns an error number which speci-
fies the reason for failure. 1-> Output file
not specified. 2-> Matrix parameter is
empty. 3-> Rows or Cols value is invalid.
4-> Style string not specified. 5-> Number
of Cols specification invalid. 6-> Invalid
element delimiter specified. 7-> Invalid
bracket type specified. 8-> Can't open out-
put file.
Return Value: 1 on success, 0 on failure.
DESCRIPTION
SEE ALSO
AVS2mat(1), intro(3), vipl(3), verror(3), vutils(3)
AUTHOR
Matthew Lawrence,Jeremy Worley
COPYRIGHT
Copyright 1992, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module AVS2pbm
INPUT
struct xvimage *AVS: VIFF input image
int raw: flag specifying ascii or raw output
OUTPUT
struct pbm **pbm: PBM output image
DESCRIPTION
AVS2pbm converts a VIFF image to a PBM image. The VIFF
image is converted to one of the six possible types of PBM
format images depending on the characteristics of the VIFF
input image, and the output data storage type selected.
There are three basic categories of PBM file formats with
two types in each category. The three categories of PBM
file formats are "pbm", "pgm", and "ppm". Within each
category it is possible to store the data as either "ascii"
or "raw", thus there are a total of six types of PBM file
formats. The resulting data storage type is user selectable
between "ascii" and "raw". If no selection is made, the
default is to type "ascii".
The three categories of PBM file formats are explained as
follows:
pbm - portable bitmap file format
This file format is used as the lowest common
deonominator monochrome file format.
The header contains the following information:
ascii raw
----- -----
Magic Number - P1 or P4
Whitespace - (blanks, TABs, CRs, LFs)
Width - formatted as ASCII characters in decimal.
Whitespace -
Height - formatted as ASCII characters in decimal.
Whitespace -
Data:
ASCII (P1) - characters '1' (black) or '0' (white)
starting in top left corner and proceeding
from left to right. No line should exceed
70 characters. Whitespace in this section
is ignored.
RAW (P4) - the bits are stored eight per byte, high
bit first and low bit last. No whitespace
is allowed in this section. These files
are eight times smaller than the ASCII (P1)
files.
Comments - begin with a '#' to the next end-of-line.
May be placed anywhere in the header.
pgm - portable graymap file format
This file format is used as the lowest common
deonominator grayscale file format.
The header contains the following information:
ascii raw
----- -----
Magic Number - P2 or P5
Whitespace - (blanks, TABs, CRs, LFs)
Width - formatted as ASCII characters in decimal.
Whitespace -
Height - formatted as ASCII characters in decimal.
Whitespace -
Max Value - formatted as ASCII characters in decimal.
Whitespace -
Data:
ASCII (P2) - characters specifying the gray value in
ASCII decimal. These values may range
anywhere from 0 to the maximum gray value.
Each character is separated by whitespace,
and starts at the top left corner of the
graymap. A value of 0 means black, and
the maximum value means white. No line
should be longer than 70 characters.
RAW (P5) - The gray values are stored as plain bytes
instead of ASCII decimal. No whitespace
is allowed in this section. Note that
values in this section are limited to
maxvalues less than or equal to 255.
Comments - begin with a '#' to the next end-of-line.
May be placed anywhere in the header.
ppm - portable pixmap file format
This file format is used as the lowest common
deonominator color image file format.
The header contains the following information:
ascii raw
----- -----
Magic Number - P3 or P6
Whitespace - (blanks, TABs, CRs, LFs)
Width - formatted as ASCII characters in decimal.
Whitespace -
Height - formatted as ASCII characters in decimal.
Whitespace -
Max Value - formatted as ASCII characters in decimal.
Whitespace -
Data:
ASCII (P3) - characters specifying the maximum color-
component value, in ASCII decimal. Three
values are required to represent each pixel.
One value for each component of "r" "g" "b".
Each character is separated by whitespace,
and starts at the top left corner of the
pixmap. The three values for each pixel
represent red, green, and blue respectively.
A value of 0 means that the color is turned
off and the maxvalue represents the maximum
intensity for that color. No line should be
longer than 70 characters.
RAW (P6) - The gray values are stored as plain bytes
instead of ASCII decimal. No whitespace
is allowed in this section. Note that
values in this section are limited to
maxvalues less than or equal to 255.
Comments - begin with a '#' to the next end-of-line.
May be placed anywhere in the header.
The PBM file formats described above were created by Jef Poskanzer,
Copyright (C) 1989.
The user has control over the output image data type (ASCII or RAW),
but the PBM file category depends on the characterisics of the input
VIFF image. That is, if the input image is BIT, then the output
image is "pbm", however if the input image is BYTE, SHORT, or INTEGER,
the output image may be either "pgm" or "ppm". This depends on whether
the input VIFF image is a 1 or 3 band image, and has a color map.
If the VIFF image is multiband, then the output image will be "ppm".
If the VIFF image is 1-band, then the output image will be "pgm",
unless a color map is present, in which case the output image will be
"ppm".
The acceptable VIFF input data types are BIT, BYTE, SHORT, or INTEGER.
The input VIFF image may be either 1-band or 3-band, and contain a
map scheme of NONE, SHARED, or ONEPERBAND. If the input image contains
a map, then the data will be mapped through the maps prior to conversion
The input parameters for AVS2pbm() are as follows:
struct xvimage *AVS - pointer to a AVS image structure
struct pbm **pbm - pointer to a pointer of a pbm structure.
int raw - flag specifying whether to output ascii or raw.
"ascii" - set raw = 0
"raw" - set raw = 1
SEE ALSO
AVS2pbm(1), intro(3), vipl(3), verror(3), vutils(3)
lpbm2AVS(3)
RESTRICTIONS
will only work on BIT, BYTE, SHORT, or INTEGER images.
will only accept VIFF images with bands = 1 or bands = 3,
since PBM format will only handle bitmap, gray, or rgb color
images.
AUTHOR
Charlie Gage and Mark Young
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module AVS2rast
INPUT
Input to AVS2rast :
AVS_image A pointer to struct xvimage, this image will
contain the image to be converted from VIFF
to SUN rast.
invert_flag resulting image is either photopositive (1)
or photonegaative (0), if the type is BIT.
OUTPUT
rast_image A pointer to struct rast, this image will
contain the converted VIFF image.
DESCRIPTION
AVS2rast : AVS2rast is a routine to convert a khoros VIFF
image to a SUN raster image.
This library will convert a BYTE (8 bit) or BIT (1 bit) VIFF
image to a SUN raster image. Valid VIFF images are:
1. Must be of type BYTE or BIT
2. If the image is of type BYTE, then it can have either
one data band or three data bands.
3. Image with one data band: This image is vaild with a
colormap of the BYTE or without a colormap. If the
colormap exists it must be of type BYTE and must con-
tain either 1 or 3 columns. If the colormap only con-
tains one column, that column will be repicated three
times when put in the SUN raster image, otherwise the
colormap has 3 columns red, green and blue. If the
image does not contain a colormap the rast image image
will not contain a colormap.
4. Image with three data bands: This is considered an RGB
image or a 24 bit image. The color_space_model must be
set to generic_RGB or NTSC_RGB.
The invert flag is only valid if the input VIFF image is of
type BIT. Since different machines intreprete black and
white values differently, one may want to "flip" the bit
values to produce a desirable image.
The resulting SUN rast image will be stored in IEEE or Big
Endian byte order. The following is a listing of the SUN
rast header used by this routine:
A Sun raster image file is composed of three parts: a
header containing 8 integers, a possibly empty set of
colormap values, and the pixel image, stored a line at
a time, in increasing y order. The image is layed out
in the file as in a memory pixrect. Each line of the
image is rounded up to the nearest 16 bits.
The header is defined as follows:
int ras_magic;
int ras_width;
int ras_height;
int ras_depth;
int ras_length;
int ras_type;
int ras_maptype;
The ras_magic field always contains the value
0x59a66a95 (hex).
The ras_width and ras_height are the width and height
of the image given pixels.
The ras_depth is the number of bits used per pixel (1,
8, or 24).
The ras_length is the number of bytes used to store the
data of the image.
The ras_type field is one of the following:
RT_OLD 0 -- Raw pixrect image in 68000 byte order
RT_STANDARD 1 -- Raw pixrect image in 68000 byte order
For historical reasons, files of type RT_OLD will usu-
ally have a 0 in the ras_length field and therefore the
actual image length will need to be computed.
The ras_maptype will be one of the following:
RMT_NONE 0 --ras_maplength is expected to be 0
RMT_EQUAL_RGB 1 --red[ras_maplength/3],green[],blue[]
RMT_RAW 2 --Sun's registered maptype
SEE ALSO
AVS2rast(1), intro(3), vipl(3), verror(3), vutils(3)
lrast2AVS(3), rast2AVS(1), vfileinfo(1)
RESTRICTIONS
This library routine will only accept BYTE or BIT VIFF
images. The resulting SUN raster image will be in IEEE or
Big Endian byte order regardless of the machine type exe-
cuted on.
AUTHOR
Tom Sauer
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for AVS2tiff
INPUT
TIFF *tif - pointer to the tif image structure (header
returned by TIFFOpen opened for reading)
struct xvimage *AVS - pointer to a pointer of a VIFF
image file.
int verbose - if set prints image header information
int compression - defines the compression type, valid
inputs are COMPRESSION_NONE, COMPRESSION_LZW,
COMPRESSION_CCITTFAX3, COMPRESSION_CCITTRLEW,
COMPRESSION_PACKBITS
char *filename - the name of the input file
OUTPUT
TIFF *tif - pointer to the tif image structure contain-
ing the converted image
AVS2tiff returns a 1 upon sucess and a 0 upon
failure.
DESCRIPTION
LAVS2tiff converts a Khoros VIFF image to a TIFF image.
TIFF stands for Tag Image File Format. The verbose flag
specifies verbose mode. In verbose mode (verbose = 1),
information about the input VIFF image and output TIFF image
is printed out.
The AVS2tiff converter is somewhat limited. Input VIFF
images must be either 1 band or 3 band images. If the image
is a 1 band image, it may contain a map with either 1 column
or 3 columns. The resulting TIFF image will contain a 256 by
3 colormap (RGB). So, if a VIFF file has a 1 column map,
that column is duplicated to form the 3 column TIFF image
colormap. Also, the input VIFF image must be of data storage
type BIT or BYTE.
The AVS2tiff routine supports a few different compression
schemes. These are:
COMPRESSION_NONE
COMPRESSION_LZW
CCOMPRESSION_CITTFAX3 - only works if the input VIFF
image is of type BIT
CCOMPRESSION_CITTRLEW
COMPRESSION_ACKBITS - used for the Machintosh
The resulting TIFF image will have all fields set appropri-
atly based on the information from the VIFF image. The TIFF
image is always written out with the pixels stored on
separate "sample planes"
LAVS2tiff uses the public domain TIFF library utilities to
write the resulting TIFF image. This routine (AVS2tiff) is
based on Release 2.2 of libtiff. The source for libtiff is
as follows:
The software is available for public ftp on
ucbvax.berkeley.edu pub/tiff/tiff.tar.Z
(128.132.130.12)
uunet.uu.net graphics/tiff.tar.Z
(192.48.96.2)
Libtiff provides the mechanisms to read, write, uncompress
and compress TIFF images.
Because the TIFF (Tag Image File Format) image specification
is long and involved, please see the TIFF 5.0 specification.
This specification can be obtained from:
Developers' Desk
Aldus Corp.
411 First Ave. South
Suite 200
Seattle, WA 98104
(206) 622-5500
SEE ALSO
AVS2tiff(1), intro(3), vipl(3), verror(3), vutils(3)
tiff2AVS(1), ltiff2AVS(3), tiff(n)
RESTRICTIONS
LAVS2tiff works only on VIFF images that have a data
storage type of BIT or BYTE, and either 1 or 3 data bands.
If the image has 1 data band and is byte, it is valid to
have an either 1 column or 3 column map.
AUTHOR
Tom Sauer
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module AVS2xbm
INPUT
FILE *file: will contain the X11 bitmap file
struct xvimage *image: xvimage to convert
char *xbmname: string (description name)
int photo_neg: logical, photonegative(0) photoposi-
tive(1)
OUTPUT
DESCRIPTION
AVS2xbm takes an AVS bitmap image and converts it into a
X11 bitmap format commonly known as xbm. The xbm file can
be used in conjunction with X resources, such as icons,
mouse pointers, stipple paterns, etc. The xbm format is in
the form of a C include file, which the user is expected to
use when programming with X windows or with such programs as
xsetroot (ie. xsetroot -bitmap file.xbm). The following is
an example of the kill button from a cantata glyph:
#define kill_width 17
#define kill_height 21
static unsigned char kill_bits[] = {
0x20, 0x40, 0x00, 0x41, 0x22, 0x00, 0x84, 0x10, 0x00, 0x10, 0x89, 0x00,
0x80, 0x00, 0x00, 0x50, 0x1a, 0x00, 0x0c, 0x62, 0x00, 0xc0, 0x83, 0x00,
0xc0, 0x13, 0x00, 0x40, 0x00, 0x00, 0xf0, 0x01, 0x00, 0xf8, 0x03, 0x00,
0xfc, 0x07, 0x00, 0xfe, 0x0f, 0x00, 0xfe, 0x0f, 0x00, 0xfe, 0x0f, 0x00,
0xfe, 0x0f, 0x00, 0xfe, 0x0f, 0x00, 0xfc, 0x07, 0x00, 0xf8, 0x03, 0x00,
0xf0, 0x01, 0x00};
If the input image has more than one band the output xbm
file will contain each band as the bitmap name followed by
the band number. ie) bitmap1, bitmap2. etc.
SEE ALSO
AVS2xbm(1), intro(3), vipl(3), verror(3), vutils(3)
RESTRICTIONS
Input image must be a bit image.
AUTHOR
Mark Young, Mike Lang
COPYRIGHT
Copyright 1991, University of New Mexico. All rights
reserved.
*********************************************************************************
Documentation for avs module xbm2AVS
INPUT
FILE *file: X11 image file.
struct xvimage **newimage: will return the VIFF image.
int photo_neg: Determines if photonegative or pho-
topositive
OUTPUT
struct xvimage **newimage: will return the VIFF image.
DESCRIPTION
xbm2AVS takes an X11 bitmap file (xbm) and converts it into
an AVS bitmap image. The xbm file is used in conjunction
with X resources, such as icons, mouse pointers, stipple
paterns, etc. The xbm format is in the form of a C include
file, which the user is expected to use when programming
with X windows or with such programs as xsetroot (ie.
xsetroot -bitmap file.xbm). The following is an example of
the kill button from a cantata glyph:
#define kill_width 17
#define kill_height 21
static unsigned char kill_bits[] = {
0x20, 0x40, 0x00, 0x41, 0x22, 0x00, 0x84, 0x10, 0x00, 0x10, 0x89, 0x00,
0x80, 0x00, 0x00, 0x50, 0x1a, 0x00, 0x0c, 0x62, 0x00, 0xc0, 0x83, 0x00,
0xc0, 0x13, 0x00, 0x40, 0x00, 0x00, 0xf0, 0x01, 0x00, 0xf8, 0x03, 0x00,
0xfc, 0x07, 0x00, 0xfe, 0x0f, 0x00, 0xfe, 0x0f, 0x00, 0xfe, 0x0f, 0x00,
0xfe, 0x0f, 0x00, 0xfe, 0x0f, 0x00, 0xfc, 0x07, 0x00, 0xf8, 0x03, 0x00,
0xf0, 0x01, 0x00};