Also Known As: Andrew Formats, CMU Bitmap
| Type | Multimedia |
| Colors | NA |
| Compression | Uncompressed |
| Maximum Image Size | NA |
| Multiple Images Per File | NA |
| Numerical Format | NA |
| Originator | Carnegie Mellon University |
| Platform | All |
| Supporting Applications | Andrew Toolkit |
| See Also | None |
Usage
Used primarily at Carnegie Mellon University in conjunction with the Andrew Toolkit.
Comments
Included mainly for its architectural uniqueness.
Vendor specifications are available for this format.
Code fragments are available for this format.
Sample images are available for this format.
The Andrew Consortium at Carnegie Mellon University is the source of the Andrew Toolkit, which is associated with the Andrew User Interface System. The Toolkit API is the basis for applications in the Andrew User Interface System. Data objects manipulated by the Andrew Toolkit must adhere to conventions crystallized in the Andrew Data Stream specification, a draft of which is included on the CD accompanying this book. The system was designed to support multimedia data from a variety of programs and platforms.
Contents:
File Organization
File Details
For Further Information
We understand that there is a bitmap format which originated at Carnegie Mellon University, but were unable to locate information prior to publication. The PBM utilities may include some support for converting and manipulating a CMU Bitmap, however.
In the CMU formats, data is organized into streams and is written in 7-bit ASCII text. This is an interesting idea--nearly unique in the graphics file format world--which appears designed to enhance the portability of the format, at some cost in file size. Text may include tabs and newline characters and is limited to 80 characters of data per line.
Note that Andrew Toolkit files assume access by the user to the Andrew Toolkit. In the words of the documentation authors:
As usual in ATK, the appropriate way to read or write the data stream is to call upon the corresponding Read or Write method from the AUIS distribution. Only in this way is your code likely to continue to work in the face of changes to the data stream definition. Moreover, there are a number of special features--mostly outdated data streams--that are implemented in the code, but not described here.
Data files used by the Andrew Toolkit consist of data objects, which are marked in the file by a begin/end marker pair. The initial marker associated with each data object must include information denoting the object type, as well as a unique identifier, which may be used as a reference ID by other objects.
The following is an example from the documentation:
\begindata{text,1}
<text data>
\begindata{picture,2}
<picture data>
\enddata{picture,2}
\view {pictureview,2}
<more text data>
\enddata{text,1}
Text data streams are similar to other data streams. Their structure is as follows:
\begindata line \textdsversion line \template line definitions of additional styles the text body itself styled text embedded objects in text body \enddata line
Each of these elements is described below.
This line has the form:
\begindata{text,99999}
where 99999 is a unique identifier.
This line has the form:
\textdsversion{12}
There are apparently files written with data stream versions other than 12.
A file may use a style template, in which case there will be a line of the form:
\template{default}
where default is the name of the template used and is the prefix of a filename. The system appends a suffix .tpl and looks for the template along file paths defined in the Andrew Toolkit installation. Please see the specification for further information.
Additional styles may be defined and used on the fly; each style consists of two or more lines:
\define{internalstylename
menuname
attribute
. . .
attribute}
internalstylename is always written in lowercase and may not contain spaces. The menuname line is optional. If it is missing, there must be an empty line in its place. If present, it has the form:
menu:[Menu card name,Style name]
Attributes are also optional; if they are missing, the closing } appears at the end of the menuname line. Attribute lines are of the form:
attr:[attributename basis units value]
where value is a signed integer.
Text consists of any number of consecutive lines, each terminated by a newline character.
Text in the body may be displayed in a style, in which case it is preceded by a previously defined name:
\internalstylename{
and is followed by the corresponding closing brace.
Objects may be embedded in the text body. The documentation for the CMU formats describes the use of embedded objects as follows:
When an object is embedded in a text body, two items appear: the data stream for the object and a \view line. The \begindata for the object is always at the beginning of a line. (The previous line is terminated with a backslash if there is to be no space before the object.) The \enddata line for the object always ends with a newline (which is not treated as a space).
The \view line has the form:
\view{rasterview,8888,777,0,0}
The \enddata line has the form:
\enddata{text,99999}
A bitmap image is a standard data stream beginning with a \begindata line and ending with a \enddata line. These generally surround a header and an image body.
The first line of the header consists of the following:
2 0 65536 65536 0 0 484 603
The following describes the numbers in this header:
Raster version |
2 |
Denotes the second version of this encoding |
Options |
0 |
This field may specify changes to the image before displaying it: raster_INVERT(1>>0) /* exch black & white */ raster_FLIP(1>>1) /* exch top & bottom */ raster_FLOP(1>>2) /* exch left & right */ raster_ROTATE(1>>3) /* rotate 90 clockwise */ |
xScale, yScale: |
65536 65536 |
Affects the size at which the image is printed. The value raster_UNITSCALE (136535) prints the image at approximately the size on the screen. The default scale of 65,536 is approximately half the screen size. |
x, y, width, height: |
0 0 484 603 |
It is possible for a raster object to display a portion of an image. These fields select this portion by specifying the index of the upper-left pixel and the width and height of the image in pixels. In all instances so far, x and y are both zero, and the width and height specify the entire image. |
The second header line has three possible variations. Currently, only the first is used.
| RasterType: | bits |
| RasterId: | 10156544 |
| Width, Height: | 484 603 |
Width and Height describe the width of each row and the number of rows.
| RasterType: | refer |
| RasterId: | 10135624 |
The current data object refers to the bits stored in another data object that appears earlier in the same data stream.
| RasterType: | file |
| RasterId: | 10235498 |
The bit data is found in the file filename.
Please check the specification document on the CD-ROM for subtleties and further details of the format.
For further information about the CMU formats and the Andrew Toolkit, as well as the full Andrew source and binary code, other contributed software, and documentation, see the following Andrew Consortium online sites:
http://www.cs.cmu.edu/afs/cs.cmu.ed/project/atk-ftp/web/andrew-home.html
ftp://ftp.andrew.cmu.edu/pub/AUIS/
You can also contact:
Andrew Consortium
Attn: Ann Marie Zanger, Assistant Director
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213-3890
Voice: 412-268-6710
Email: info-andrew+@andrew.cmu.edu
Copyright © 1996, 1994 O'Reilly & Associates, Inc. All Rights Reserved.