PLEASE NOTE : This is the documentation for the avs module executable standard, which contains the following modules: fits2AVS mat2AVS pbm2AVS rast2AVS tga2AVS tiff2AVS AVS2fits AVS2mat AVS2pbm AVS2rast AVS2tiff AVS2xbm xbm2AVS Any mention of xvimage is actually a "field 2D". Also, the INPUTs and OUTPUTs, which are mapped to avs parameters, inputs, and outputs, are for the khoros library routine. ********************************************************************************* Documentation for avs module fits2AVS INPUT struct fits *fits_image - pointer to fits image struct xvimage **AVS_image - pointer to a pointer of an VIFF image file format. int color_model - the color space model specified by the user. OUTPUT struct xvimage **AVS_image - malloced and copied imagedata for VIFF image DESCRIPTION fits2AVS is a routine that converts a FITS image file for- mat into a VIFF file format. SEE ALSO fits2AVS(1), intro(3), vipl(3), verror(3), vutils(3) AUTHOR Robin Corbet, PSU COPYRIGHT Copyright 1991, University of New Mexico. All rights reserved. ********************************************************************************* Documentation for avs module mat2AVS INPUT image pointer to VIFF structure containing image data to be processed. procdir process direction: 0 indicated vector oriented processing, 1 indicates band oriented processing. OUTPUT image pointer to VIFF structure containing image data after processing. Return Value: 1 on success, 0 on failure. DESCRIPTION The mat2AVS routine will read a single matrix from the file specified and place it in an image structure. It expects to see all comments prefixed by a pound ('#') sign. Anything following this symbol on the same line will be ignored. Matrices are expected to be preceeded by either an open bracket ('[') or a "less than" symbol ('<') and suc- ceeded by a close bracket (']') or a "greater than" symbol ('>'). For example: [ 4.0 3.0 2.0 1.0 ] Specifies a single row matrix with 4 elements. Each row, with the exception of the final row, of the matrix is expected to be delimited by a semicolon (';'). For exam- ple: [ 4.0 3.0 2.0 1.0 ; 3.0 2.0 1.0 0.0 ] The above example specifies a two row matrix. Each row con- tains four elements. Carraige returns are insignificant. The matrix above could be equivelantly input as: [ 4.0 3.0 2.0 1.0 ; 3.0 2.0 1.0 0.0 ] or as: [ 4.0 3.0 2.0 1.0 ; 3.0 2.0 1.0 0.0 ] Complex numbers are entered by enclosing them in parentheses ('()') and separating their real and imaginary parts by a comma (','). For example: [ (4.0,3.0) ; (-3.0,2.0) ] If a complete row is not specified (i.e. not enough row ele- ments to complete a row), then the row will be zero padded. For example: [ 3.0 2.0 1.0 ; 3.0 -1.0 ;; 1.0 2.0 4 ] is equivelant to: [ 3.0 2.0 1.0 ; 3.0 -1.0 0.0 ; 0.0 0.0 0.0 ; 1.0 2.0 4.0 ] The only major limitation of the current implementation is that the first row should contain the maximum number of ele- ments that a row will have in the entire matrix explicitly specified. Failure to comply with this limitation will result in illogical, erroneous, and ridiculous results. SEE ALSO mat2AVS(1), intro(3), vipl(3), verror(3), vutils(3) AUTHOR Jeremy Worley COPYRIGHT Copyright 1992, University of New Mexico. All rights reserved. ********************************************************************************* Documentation for avs module pbm2AVS INPUT struct pbm *pbm: PBM image input OUTPUT struct xvimage **AVS: VIFF output image DESCRIPTION pbm2AVS converts a PBM image to a VIFF image. One of six possible PBM format images is converted to an appropriate VIFF image. The number of bands, data storage type, and map scheme of the resulting VIFF image is dependent upon the data storage type and class of the input PBM image. 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 have the data as either "ascii" or "raw", thus there are a total of six types of PBM file formats. 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 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 | |Type | | |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 name 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}; Other examples of X11 bitmap files (xbm) can be found in $KHOROS_HOME/data/bitmaps. SEE ALSO xbm2AVS(1), intro(3), vipl(3), verror(3), vutils(3) RESTRICTIONS Only the first bitmap definition is taken, the rest are ignored. AUTHOR Mark Young COPYRIGHT Copyright 1991, University of New Mexico. All rights reserved. *********************************************************************************