GEM raster description excerpted from: ST Picture Formats ------------------ Edited by: David Baggett Internet: dmb@ai.mit.edu (Please report errors or additions.) Copyright (C) 1988 -- 1995 by David M. Baggett Non-profit redistribution of this document is permitted, provided the document is not modified in any way. Reproduction of this document in whole or in part for commercial purposes is expressly forbidden without the prior written consent of David M. Baggett. The information presented here is not guaranteed to be correct. The editor and contributors will in no event be liable for direct, indirect, incidental, or consequential damages resulting from the use of the information in this document. This document is the product of many hours of volunteer work by a large number of people. Please respect this -- do not violate the distribution policy. CONTRIBUTORS Steve Belczyk Phil Blanchfield Marcel Boom Jason Blochowiak John Brochu** David Brooks Daniel Deimert Martyn Dryden Neil Forsyth Stefan Hoehn Gerfried Klein G. "Maddog" Knauss Ken MacLeod Shamus McBride Jim McCabe Lars Michael Darek Mihocka David Mumper George Nassas Jim Omura Chris Ridd George Seto Joe Smith Greg Wageman Roland Waldi* Gerry Wheeler Introductory Information ------------------------ word = 2 bytes long = 4 bytes palette = Hardware color palette, stored as 16 words. First word is color register zero (background), last word is color register 15. Each word has the form: Bit: (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB) -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 0 0 0 0 0 R2 R1 R0 0 G2 G1 G0 0 B2 B1 B0 R2 = MSB of red intensity R0 = LSB of red intensity G2 = MSB of green intensity G0 = LSB of green intensity B2 = MSB of blue intensity B0 = LSB of blue intensity Intensity ranges from 0 (color not present) to 7 (highest intensity). Example: { red = 7, green = 3, blue = 5 } -> 0735 (hex) Caveat: It is wise to mask off the upper four bits of each palette entry, since a few programs store special information there (e.g., Art Studio). *.IMG 1 word version number of image file [1] 1 word length of header in words [usually 8] 1 word number of color planes [1 for monochrome] 1 word pattern length in bytes [1-8, usually 2 for screen images] 1 word pixel width in microns (1/1000 mm, 25400 microns per inch) 1 word pixel height in microns 1 word line width in pixels 1 word number of lines ------- ? words header length defined in 2nd word of header ? bytes data NOTES: If the image is a color image (planes > 1), the planes are stored separately starting with plane 0 -- see the extended .IMG format description below for details. There is, however, no standard way of storing the color palette. Some programs may save the palette in separate files, some may extend the header. For this reason, you should never assume the header is 8 words long, always get the header length from the 2nd word of the header. Also, the line width in the 7th word is the number of pixels in a line. Since the data is encoded in byte-wide packets, the actual unpacked line width is always a multiple of 8, and may be 1-7 pixels longer than the length specified in the header. For each byte x in the data section, x = 0 Pattern/scanline run. Read the next byte, n (unsigned). If n > 0 then: Read a number of bytes equal to the "pattern length" word in the header. Repeat this pattern n times. If n = 0 then: Scanline run. Data for the next scanline is to be used multiple times. Read the following record: 1 byte flag byte [$FF] 1 byte number of times to use next scanline data The data for the next scanline follows, compressed normally. x = 80 (hex) Uncompressed bit string. The next byte determines the number of bytes to use literally. The literal data bytes follow. otherwise Solid run. The value of x determines what to draw. The high bit specifies whether the pixels are set or cleared. A 1 indicates a byte-run using $FF, a 0 indicates a byte-run using $00. The low 7 bits, taken as an unsigned quantity, specify the length of the run in bytes. *.IMG As mentioned above, there is no completely standard way to store color images in .IMG files. However, one approach is fairly common, and has become known as the "XIMG" format. Though there are many similarities between this and the previous format, I've given the two formats separate entries to underscore the fact that assuming a particular encoding of color images in .IMG files is risky. 1 word version number of image file 1 word length of header in words 1 word number of color planes [2, 4, 8, 16, or 24] 1 word pattern length in bytes [1-8, usually 2 for screen images] 1 word pixel width in microns (1/1000 mm, 25400 microns per inch) 1 word pixel height in microns 1 word line width in pixels 1 word number of lines 1 long ["XIMG" $58494D47] 1 word color format [0] If #planes is 2, 4, or 8, then for each color [there are 2^#planes colors] { 3 words RGB triple for first pen (0...1000, 0...1000, 0...1000) [This color specification can be passed directly to the standard vs_color function.] } ------- ? words header length defined in 2nd word of header ? bytes data If the third word specifies that there are 16 or 24 planes, the image data is true-color rather than palette-based, and the image is separated into "pseudo-planes" as follows: 16-bit data: 5 red planes, 6 green planes, 5 blue planes 24-bit data: 8 red planes, 8 green planes, 8 blue planes Note that the pseudo-planes appear *in this order* in the image data. Color image data is compressed as described above (in the standard .IMG format), and the image data is stored in the following order: line 0, plane 0 line 0, plane 1 ... line 0, plane p line 1, plane 0 ... Note that the scanline run compression is a bit more constrained for color images -- an entire *scanline* gets repeated, not a single *plane* of a scanline. In this case, the scanline run header [0, 0, $FF, n] is followed by the scanline data, in the typical order -- plane 0, plane 1, ... plane p. NOTE: There is another variant of .IMG that has 'STTT' in place of 'XIMG'. Chris Ridd says this format is no longer used because it's device dependent. In any case, we don't have enough examples to properly document it. * Roland Waldi contributed extensive information on the following formats: GEM, IMG, Doodle, STAD, Imagic Film/Picture, Art Director, IFF ** John Brochu, ST picture formats guru, provided sage advice and many corrections to the following formats: NeoChrome, DEGAS Elite Compressed, Spectrum 512 Compressed, GEM Bit Image, IFF, MacPaint Version of...........Sun Oct 30 12:40:13 EST 1994 (Last change: Extended GEM .IMG format updated)