Strings in GEMRAS.TXT
GEM raster description excerpted from:
ST Picture Formats
------------------
Edited by:
David Baggett
Internet:
[email protected]
(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).
<GEM Bit Image> *.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.
<GEM Bit Image, Extended> *.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
* 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)
