Skip to main content

 "Life is what happens to you while you're busy making plans." 
                     ST PICTURE FILE FORMATS 
                        by David Baggett
                     (layout modified by RK)

 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.

Steve Belczyk  Phil Blanchfield  Jason Blochowiak  John Brochu**
    David Brooks  Daniel Deimert  Neil Forsyth  Stefan Hoehn
     Gerfried Klein  G. "Maddog" Knauss  Ken MacLeod  Shamus
      Jim McCabe  Lars Michael  Darek Mihocka  David Mumper
        George Nassas  Jim Omura  George Seto  Joe Smith
           Greg Wageman  Roland Waldi*  Gerry Wheeler

NEOchrome                               *.NEO 
NEOchrome Animation                     *.ANI 
DEGAS                                   *.PI?   ? = 1, 2, 3 
DEGAS Elite                             *.PI?   ? = 1, 2, 3 
DEGAS Elite (Compressed)                *.PC?   ? = 1, 2, 3 
Tiny                                    *.TN?   ? = 1, 2, 3, Y 
Spectrum 512                            *.SPU 
Spectrum 512 (Compressed)               *.SPC 
Spectrum 512 (Smooshed)                 *.SPS 
Art Director                            *.ART 
C.O.L.R. Object Editor Mural            *.MUR 
Doodle                                  *.DOO 
Cyber Paint Sequence                    *.SEQ 
Cyber Studio Delta                      *.DLT 
Animatic Film                           *.FLM 
Animaster Sprite Bank                   *.ASB 
STOS                                    *.MBK 
GEM Bit Image                           *.IMG 
STAD                                    *.PAC 
Imagic Film/Picture                     *.IC?   ? = 1, 2, 3 
IFF                                     *.IFF 
RGB Intermediate Format                 *.RGB 
ComputerEyes Raw Data Format            *.CE?   ? = 1, 2 
MacPaint                                *.MAC 
PackBits Compression Algorithm
                    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 (most  notably  Art

                           The Formats 
<NEOchrome>     *.NEO 
1 word          flag byte [always 0] 
1 word          resolution [0=low res, 1=medium res, 2=high res] 
16 words        palette 
12 bytes        filename [usually "        .   "] 
1 word          color animation limits.  High bit (bit 15) set if
                color animation data is valid.  Low byte contains
                color  animation limits (4 most significant  bits
                are  left/lower limit,  4 least significant  bits
                are right/upper limit). 
1 word          color  animation speed and direction.   High  bit
                (bit 15) set if animation is on.   Low order byte
                is  # vblanks per step.  If negative,  scroll  is
                left  (decreasing).   Number of  vblanks  between
                cycles is |x| - 1 
1 word          # of color steps (as defined in previous word) to
                display picture before going to the  next.   (For
                use in slide shows) 
1 word          image X offset [unused, always 0] 
1 word          image Y offset [unused, always 0] 
1 word          image width [unused, always 320] 
1 word          image height [unused, always 200] 
33 words        reserved for future expansion 
16000 words     picture data (screen memory) 
32128 bytes     total 
<NEOchrome Animation>        *.ANI                               
NOTE:    To get this feature on versions 0.9 and later select the
        Grabber  icon and click both mouse buttons in the eye  of
        the second R in the word GRABBER.
         Interestingly enough,  some versions of NEO only require
        you to press the right button, not both. Hmmm...
1 long          magic number BABEEBEA (hex) (seems to
                 be ignored) 
1 word          width of image in bytes (always divisible by 8) 
1 word          height of image in scan lines 
1 word          size of image in bytes + 10 (!) 
1 word          x coordinate of image (must be divisible by 16)-1 
1 word          y coordinate of image - 1 
1 word          number of frames 
1 word          animation speed (# vblanks delay between frames) 
1 long          reserved; should be zero 
22 bytes        total for header
? words         image  data  (words of screen  memory)  for  each
                frame, in order

<DEGAS>         *.PI1 (low resolution)
                *.PI2 (medium resolution) 
                *.PI3 (high resolution)                          
1 word          resolution (0=low res, 1=medium res, 2=high res)
                Other  bits  may be used in  the  future;  use  a
                simple bit test rather than checking for specific
                word values. 
16 words        palette 
16000 words     picture data (screen memory) 
32034 bytes     total

<DEGAS Elite>   *.PI1 (low resolution)
                *.PI2 (medium resolution) 
                *.PI3 (high resolution)                          
1 word          resolution (0=low res, 1=medium res, 2=high res)
                Other  bits  may be used in  the  future;  use  a
                simple bit test rather than checking for specific
                word values. 
16 words        palette 
16000 words     picture data (screen memory) 
4 words         left  color animtion limit table (starting  color
4 words         right  color animation limit table (ending  color
4 words         animation channel direction flag (0 = left,  1  =
                off, 2 = right) 
4 words         128  -  animation channel delay in  1/60's  of  a
                second.  [0 - 128] (I.e.,  subtract word from 128
                to get 1/60th's of a second.) 
32066 bytes     total

<DEGAS Elite (Compressed)>      *.PC1 (low resolution)
                                *.PC2 (medium resolution) 
                                *.PC3 (high resolution)          
1 word          resolution (same as Degas,  but high order bit is
                set;  i.e., hex 8000 = low res, hex 8001 = medium
                res,  hex  8002 = high res).   Other bits may  be
                used in the future;  use a simple bit test rather
                than checking for specific word values. 
16 words        palette 
< 32000 bytes   control/data bytes 
4 words         left color animation limit table (starting  color
4 words         right  color animation limit table (ending  color
4 words         animation channel direction flag [0 = left,  1  =
                off, 2 = right] 
4 words         128  -  animation channel delay in  1/60's  of  a
                second.  [0 - 128] (I.e.,  subtract word from 128
                to get 1/60th's of a second.) 
< 32066 bytes   total
Compression Scheme:

 PackBits  compression is used (see below).   Each scan  line  is 
compressed  separately;  i.e.,  all  data for a given  scan  line 
appears before any data for the next scan line.   The scan  lines 
are specified from top to bottom (i.e.,  0 is first).   For  each 
scan line,  all the data for a given bit plane appears before any 
data  for  the next higher order bit plane.   Note that  this  is 
identical to the IFF 'BODY' image data.
 To clarify:  The first data in the file will be the data for the 
lowest  order bit plane of scan line zero,  followed by the  data 
for  the  next higher order bit plane of scan  line  zero,  etc., 
until all bit planes have been specified for scan line zero.  The 
next  data in the file will be the data for the lowest order  bit 
plane of scan line one,  followed by the data for the next higher 
order bit plane of scan line one, etc., until all bit planes have 
been specified for all scan lines.

 DEGAS  Elite's picture loading routine places some  restrictions 
on compressed DEGAS files:
o Elite uses a 40-byte buffer to store data being decompressed.
o Whenever a control command is encountered, bytes are stuffed in
   this buffer.
o The buffer is only emptied when there are EXACTLY 40 characters
   in it.
The important conclusion here is that

 No  control  command may cause the buffer to have more  than  40 
bytes in it.  In other words, all control commands must end on or 
before the 40-byte boundary.

 Any picture violating the last condition will cause Elite to get 
a bus error when the picture is loaded.

<Tiny>  *.TNY (any resolution)
        *.TN1 (low resolution)
        *.TN2 (medium resolution) 
        *.TN3 (high resolution)                                   
 Several people have reported sightings of mutated Tiny  pictures 
that do not follow the standard format,  so let's be careful  out 
there.   What is described here is the format that David Mumper's 
original TNYSTUFF.PRG produces.
1 byte          resolution  (same  as  NEO,   but  +3   indicates
                rotation information also follows)
If resolution > 2 { 
1 byte          left  and right color animation limits.   High  4
                bits  hold left (start) limit;  low 4  bits  hold
                right (end) limit 
1 byte          direction and speed of color animation  (negative
                value indicates left,  positive indicates  right,
                absolute value is delay in 1/60's of a second. 
1 word          color rotation duration (number of iterations) 
16 words        palette 
1 word          number of control bytes 
1 word          number of data words 
3-10667 bytes   control bytes 
1-16000 words   data words 
42-32044 bytes  total
Control byte meanings:

        For a given control byte, x:

        x < 0   Absolute  value  specifies the number  of  unique
                words  to take from the data section (from  1  to
        x = 0   1  word is taken from the control  section  which
                specifies the number of times to repeat the  next
                data word (from 128 to 32767)
        x = 1   1  word is taken from the control  section  which
                specifies the number of unique words to be  taken
                from the data section (from 128 - 32767)
        x > 1   Specifies the number of times to repeat the  next
                word taken from the data section (from 2 to 127)

 Format of expanded data:

 The  expanded  data  is not simply screen  memory  bitmap  data; 
instead,  the data is divided into four sets of vertical columns. 
(This  results in better compression.)  A column consists of  one 
specific  word  taken  from each scan line,  going  from  top  to 
bottom.   For example,  column 1 consists of word 1 on scanline 1 
followed  by word 1 on scanline 2,  etc.,  followed by word 1  on 
scanline 200.
 The columns appear in the following order:

   1st set contains columns 1, 5,  9, 13, ..., 69, 73, 77 in order
   2nd set contains columns 2, 6, 10, 14, ..., 70, 74, 78 in order
   3rd set contains columns 3, 7, 11, 15, ..., 71, 75, 79 in order
   4th set contains columns 4, 8, 12, 16, ..., 72, 76, 80 in order

 Note  that  Tiny partitions the screen this  way  regardless  of 
resolution;  i.e.,  these aren't bitplanes.   For example, medium 
resolution only has two bitplanes,  but Tiny still divides medium 
resolution pictures into four parts.
<Spectrum 512>  *.SPU                                            
80 words        first scan line of picture (unused) -- should  be
15920 words     picture  data  (screen memory) for scan  lines  1
                through 199 
9552 words      3 palettes for each scan line (the top scan  line
                is  not  included  because  Spectrum  512   can't
                display it) 
51104 bytes     total

 Note that the Spectrum 512 mode's three palette changes per scan 
line allow more colors on the screen than normally possible,  but 
a  tremendous  amount  of CPU time is required  to  maintain  the 

 The  Spectrum format specifies a palette of 48 colors  for  each 
scan line.  To decode a Spectrum picture,  one must be know which 
of  these  48 colors are in effect for a given  horizontal  pixel 

 Given an x-coordinate (from 0 to 319) and a color index (from  0 
to  15),  the following C function will return the  proper  index 
into the Spectrum palette (from 0 to 47):
 *  Given an x-coordinate and a color index, returns the
 *  corresponding Spectrum palette index.
 *  by Steve Belczyk; placed in the public domain December, 1990.
FindIndex(x, c)
        int x, c; 
        int x1;

        x1 = 10 * c;

        if (1 & c)              /* If c is odd */
                x1 = x1 - 5;
        else                    /* If c is even */
                x1 = x1 + 1;
        if (x >= x1 && x < x1 + 160)
                c = c + 16;
        else if (x >= x1 + 160)
                c = c + 32;

        return c; 

<Spectrum 512 (Compressed)>        *.SPC                         
1 word          flag word [$5350 or "SP"] 
1 word          reserved for future use [always 0] 
1 long          length of data bit map 
1 long          length of color bit map 
<= 32092 bytes  compressed data bit map 
<= 17910 bytes  compressed color bit map 
<= 50014 bytes  total
Data compression:

 Compression is via a modified run length encoding (RLE)  scheme, 
similar to DEGAS compressed and Tiny.   The data map is stored as 
a  sequence of records.   Each record consists of a  header  byte 
followed  by one or more data bytes.   The meaning of the  header 
byte is as follows:

        For a given header byte, x:

           0 <= x <= 127   Use the next x + 1 bytes literally (no
        -128 <= x <=  -1   Use the next byte -x + 2 times

 The data appears in the following order:

        1. Picture data, bit plane 0, scan lines 1 - 199
        2. Picture data, bit plane 1, scan lines 1 - 199
        3. Picture data, bit plane 2, scan lines 1 - 199
        4. Picture data, bit plane 3, scan lines 1 - 199

 Decompression of data ends when 31840 data bytes have been used.

 Color map compression:

 Each 16-word palette is compressed separately.   There are three 
palettes for each scan line (597 total).  The color map is stored 
as a sequence of records.   Each record starts with a 1-word  bit 
vector  which  specifies  which of the  16  palette  entries  are 
included in the data following the bit vector (1 = included,  0 = 
not included).  If a palette entry is not included, it is assumed 
to be zero (black).   The least significant bit of the bit vector 
refers  to  palette entry zero,  while the most  significant  bit 
refers to palette entry 15.   Bit 15 must be zero, since Spectrum 
512  does not use palette entry 15.   Bit 0 should also be  zero, 
since Spectrum 512 always makes the background color black.
 The  words  specifying  the  values  for  the  palette   entries 
indicated  in  the bit vector follow the bit  vector  itself,  in 
order (0 - 15).
NOTE:   Regarding Spectrum pictures,  Shamus McBride reports  the

        "...  [The Picture Formats List] says bit 15 of the color
        map  vector must be zero.  I've encountered quite  a  few
        files  where [bit 15] is set (with no associated  palette

<Spectrum 512 (Smooshed)>          *.SPS 

 This  format  compresses Spectrum 512 pictures better  than  the 
standard  method.   There are at least two programs that  support 
this  format,  SPSLIDEX  and ANISPEC,  although the two  seem  to 
differ slightly in their interpretation of the format.
 One  point of interest:  Shamus McBride deciphered  this  format 
without an ST!
1 word          5350 (hex) ("SP") 
1 word          0 (reserved for future use) 
1 long          length of data bit map 
1 long          length of color bit map 
<= ? bytes      compressed data bit map 
<= ? bytes      compressed color bit map 
< ?  bytes      total

 Data compression:

 Compression is via a modified run length encoding (RLE)  scheme, 
similar to that used in Spectrum Compressed (*.SPC) pictures.

 The  data map is stored as a sequence of records.   Each  record 
consists  of  a header byte followed by one or more  data  bytes. 
The meaning of the header byte is as follows:

        For a given header byte, x (unsigned):

          0 <= x <= 127    Use the next byte x + 3 times
        128 <= x <= 255    Use  the  next  x  -  128  +  1  bytes
                           literally (no repetition)

 There are two kinds of *.SPS files.

 The  data may appear in the same order as *.SPC files  (SPSLIDEX 

        1. Picture data, bit plane 0, scan lines 1 - 199
        2. Picture data, bit plane 1, scan lines 1 - 199
        3. Picture data, bit plane 2, scan lines 1 - 199
        4. Picture data, bit plane 3, scan lines 1 - 199

 The  second variant (ANISPEC format?) encodes the data  as  byte 
wide vertical strips:

     Picture data, bit plane 0, scan line   1, columns   0 -   7.
     Picture data, bit plane 0, scan line   2, columns   0 -   7.
     Picture data, bit plane 0, scan line   3, columns   0 -   7.
     . . .
     Picture data, bit plane 0, scan line 199, columns   0 -   7. 
     Picture data, bit plane 0, scan line   1, columns   8 -  15.
     Picture data, bit plane 0, scan line   2, columns   8 -  15.
     . . .
     Picture data, bit plane 0, scan line 199, columns 312 - 319.
     Picture data, bit plane 1, scan line   1, columns   0 -   7.
     . . .
     Picture data, bit plane 3, scan line 198, columns 312 - 319
     Picture data, bit plane 3, scan line 199, columns 312 - 319.

 A for loop to process that data would look like

        for (plane = 0; plane < 4; plane++)
            for (x = 0; x < 320; x += 8)
                for (y = 1; y < 200; y++)
                    for (x1 = 0; x1 < 8; x1++)
                        image[y, x + x1] = ...

 Color map compression:

 Color map compression is similar to *.SPC color map compression, 
but the map is compressed as a string of bits, rather than words. 
There  are  597 records (one for each palette).  Each  record  is 
composed of a 14-bit header followed by a number of 9-bit palette 
entries.   The  14-bit  header specifies  which  palette  entries 
follow (1 = included, 0 = not included). The most significant bit 
of  the  header  refers  to palette  entry  1,  while  the  least 
significant bit refers to palette 14.   Palette entries 0 and  15 
are  forced to black (zero).   Each palette entry is  encoded  as 

 The  format of the palette is described above in the section  on 
uncompressed Spectrum pictures (*.SPU).

<Art Director>  *.ART (low resolution only)                      
16000 words     picture data (screen memory) 
16 words        palette 
15 * 16 words   15 more palettes for animation 
32512 bytes     total

<C.O.L.R. Object Editor Mural>        *.MUR (low resolution only) 
16000 words     picture data (screen memory)
                (palettes are stored in separate files) 
32000 bytes     total

<Doodle>        *.DOO (high resolution only)                     
16000 words     picture data (screen memory) 
32000 bytes     total

<Cyber Paint Sequence>  *.SEQ (low resolution only)              
 This format,  while fairly complex, yields excellent compression 
of  animated images while offering reasonably fast  decompression 
1 word          magic number [$FEDB or $FEDC] 
1 word          version number 
1 long          number of frames 
1 word          speed (high byte is vblanks per frame) 
118 bytes       reserved 
128 bytes       total for .SEQ header
for each frame { 
1 word          type (ignored?) 
1 word          resolution [always 0] 
16 words        palette 
12 bytes        filename [usually "        .   "] 
1 word          color animation limits [not used] 
1 word          color animation speed and direction [not used] 
1 word          number of color steps [not used] 
1 word          x offset for this frame [0 - 319] 
1 word          y offset for this frame [0 - 199] 
1 word          width  of this frame,  in pixels (may be  0,  see
1 word          height of this frame,  in pixels (may be  0,  see
1 byte          operation [0 = copy, 1 = exclusive or] 
1 byte          storage method [0 = uncompressed, 1 = compressed] 
1 long          length   of  data  in  bytes  (if  the  data   is
                compressed,   this  will  be  the  size  of   the
                compressed data BEFORE decompression) 
60 bytes        reserved 
128 bytes       total for frame header
? bytes         data 

 Frames  are  "delta-compressed," meaning that only  the  changes 
from one frame to the next are stored.  On the ST, .SEQ files are 
always  full-screen low resolution animations,  so  the  sequence 
resulting from expanding all the data will be n 320 by 200  pixel 
low resolution screens, where n is given in the .SEQ header.

 Since  only the changes from frame to frame  are  stored,  image 
data  for  a frame will rarely be 320x200 (except  for  the  very 
first frame,  which will always be a full screen).   Instead what 
is  stored is the smallest rectangular region on the screen  that 
contains  all the changes from the previous frame to the  current 
frame.   The x offset and y offset in the frame header  determine 
where  the upper left corner of the "change box"  lies,  and  the 
width and height specify the box's size.

 Additionally,  each "change box" is stored in one of five  ways. 
For each of these,  the screen is assumed to have the full-screen 
image from the last frame on it.

   o uncompressed copy:   The data for this frame is uncompressed
     image data, and is simply copied onto the screen at position
     (x, y) specified in the frame header. 

   o uncompressed  eor:   The  data for this frame  is  exclusive
     or'ed with the screen at position (x, y).

   o compressed   copy:   The  data  for  this  frame   must   be
     decompressed (see below), and then copied onto the screen at
     position (x, y) specified in the frame header.

   o compressed   eor:    The  data  for  this  frame   must   be
     decompressed (see below),  and then exclusive or'ed with the
     screen RAM at position (x, y).

   o null frame:   The width and/or height of this frame is 0, so
     this frame is the same as the previous frame.

     Of the 5 methods above, the one that results in the smallest
     amount  of  data being stored for a particular is  used  for
     that frame.

 Compression Scheme:

 Compression  is  similar to that employed by Tiny,  but  is  not 
quite as space-efficient.
Control word meanings:

        For a given control word, x:

        x < 0   Absolute  value  specifies the number  of  unique
                words  to take from the data section (from  1  to
        x > 0   Specifies the number of times to repeat the  next
                word  taken  from  the data section  (from  1  to

        Note that a control word of 0 is possible but meaningless.

 Format of expanded data:

 The  expanded  data  is not simply screen  memory  bitmap  data; 
instead  the four bitplanes are separated,  and the  data  within 
each  bitplane is presented vertically instead  of  horizontally. 
(This results in better compression.)

 To clarify, data for a full screen would appear in the following 

   bitplane 0, word 0, scanline 0
   bitplane 0, word 0, scanline 1
   bitplane 0, word 0, scanline 199
   bitplane 0, word 1, scanline 0
   bitplane 0, word 1, scanline 1
   bitplane 0, word 1, scanline 199
   bitplane 0, word 79, scanline 199
   bitplane 1, word 0, scanline 0
   bitplane 3, word 79, scanline 199 

 Note however,  that the data does not usually refer to an entire 
screen,  but  rather to the smaller "change box," whose  size  is 
given in the frame header.

<Cyber Studio Delta>    *.DLT (low resolution only)               
 This format's main feature is that it is simple enough to  allow 
real-time decompression of animated images,  while still offering 
reasonable compression ratios.  Like Cyber Paint .SEQ files, .DLT 
files only store the changes from one frame to the  next,  rather 
than the frames themselves. The .DLT format compresses animations 
with few frame-to-frame changes best, and will in fact make files 
bigger  than  normal  if on average more  than  half  the  screen 
changes from frame to frame on average.
for each frame { 
1 word          number of deltas for this frame (0 = end of file) 
for each delta { 
1 word          offset (in bytes) from start of screen RAM  where
                next data goes 
1 long          data to be exclusive-or'ed with the screen at the
                given offset 

Note:   Even  if  a frame is identical to  its  predecessor,  you
        still  have to store at least one  delta,  otherwise  the
        .DLT reader will assume end of file.

 The first screen of a .DLT-encoded sequence is stored in a  .PI1 
or .PC1 file with the same name.

<Animatic Film> *.FLM (low resolution only) 
1 word          number of frames 
16 words        palette 
1 word          speed (0 - 99;  value is 99 - # vblanks to  delay
                between frames) 
1 word          direction (0 = forwards, 1 = backwards) 
1 word          end action (what to do after the last frame)
                0 = pause, then repeat from beginning
                1 = immediately repeat from beginning
                2 = reverse (change direction) 
1 word          width of film in pixels 
1 word          height of film in pixels 
1 word          Animatic version number (major) [< 2] 
1 word          Animatic version number (minor) 
1 long          magic number 27182818 (hex) 
3 longs         reserved for expansion (should be all zeros) 
32 words        total for header
? words         image  data  (words of screen  memory)  for  each
                frame, in order

<Animaster Sprite Bank> *.ASB (low resolution only) 
1 word          number of frames - 1 
1 word          ? 
1 byte          maximum width, in pixels 
1 byte          maximum height, in pixels 
16 words        palette 
38 bytes        total for header
For each frame { 
1 word          width of this frame (in pixels) - 1 
1 word          height of this frame (in pixels) - 1 
1 word          ? 
? words         image data (words of screen memory) 

<STOS>  *.MBK                                                    
9 words         ? 
1 long          $19861987 (magic number?) 
1 long          offset   from  this  long  to  header   for   low
                resolution parameter block (if past end of  file,
                no low res frames) 
1 long          offset   from  this  long  to  header   for   med
                resolution parameter block (if past end of  file,
                no med res frames) 
1 long          offset   from  this  long  to  header  for   high
                resolution parameter block (if past end of  file,
                no high res frames) 
1 word          number of low resolution frames 
1 word          number of medium resolution frames 
1 word          number of high resolution frames
For each frame { 
1 long          offset to data (probably only used internally  by
1 byte          width  in words (multiply by 16 to get  width  in
1 byte          height in pixels 
1 byte          X hotspot location 
1 byte          Y hotspot location 
(The format implies other stuff could be here.)
1 long          ["PALT" $50414C54] 
16 words        palette
?               words  of  data  for each  frame,  in  the  order
                mentioned  in the header.   Monoplanar mask  data
                follows image data for each frame. 
? words         total

 The  frames  often  seem  to  be  in  semi-random   order,   not 
necessarily in the order they are to be animated.

<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.   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 

 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

        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.

<STAD>          *.PAC (high resolution only)                     
4 bytes         "pM86"    (vertically    packed)    or     "pM85"
                (horizontally packed) 
1 byte          id byte 
1 byte          pack  byte  (most  frequently  occuring  byte  in
1 byte          "special" byte 
7 bytes         total for header
? bytes         data

 The  data is encoded as follows.   For each byte x in  the  data 

        x = id byte           Read one more byte,  n.   Use  pack
                              byte n + 1 times.
        x = "special" byte    Read two more bytes,  d,  and n (in
                              Use byte d n times.
        otherwise             Use byte x literally.

<Imagic Film/Picture>           *.IC1 (low resolution)
                                *.IC2 (medium resolution) 
                                *.IC3 (high resolution)          
4 bytes         "IMDC" 
1 word          resolution (0=low res, 1=medium res, 2=high res) 
16 words        palette 
1 word          date (GEMDOS format) 
1 word          time (GEMDOS format) 
8 bytes         name   of   base   picture   file   (for    delta
                compression), or zeroes 
1 word          length of data (?) 
1 long          registration number 
8 bytes         reserved 
1 byte          compressed? (0 = no, 1 = yes)
If compressed { 
1 byte          delta-compressed? (-1 = no, > -1 = yes) 
1 byte          ? 
1 byte          escape byte 

65 bytes        total for header (68 bytes if compressed)
? bytes         data

 Compressed  data may be either stand-alone  or  delta-compressed 
(relative  to  the  base picture named  in  the  header).   Delta 
compression  involves storing only how the picture  differs  from 
the  base picture (i.e.,  only portions of the screen  that  have 
changed  are  stored).   This  is  used  to  to  encode  animated 
sequences efficiently.

 Compressed data, stand-alone:

 For each byte x in the data section:

        x = escape byte       Read  one  more  byte,  n.   (n  is

                              If  n  >= 2,  use the next  byte  n
                              If n = 1,  keep reading bytes until
                              a   byte  k  not  equal  to  1   is
                              Then read the next byte d.
                              If   the   number   of   1    bytes
                              encountered is o,  use d (256 * o +
                              k) times.  I.e.,

                              if (n == 1) {
                                      o = 0;
                                      while (n == 1) {
                                              n = next byte;

                                      k = n;
                                      d = next byte;

                                      Use d (256 * o + k) times.
                              else {
                                      d = next byte;
                                      Use d (n) times.

        x != escape byte        Use x literally.

 Compressed data, delta compressed:

 For each byte x in the data section:

        x = escape byte       Read  one  more  byte,  n.   (n  is

                              If  n  >= 3,  use the next  byte  n
                              If n = 1,  do the same as for n = 1
                              in stand-alone compression (above).
                              If n = 2, then set n = next byte.
                               If n = 0, end of picture.
                               If n >= 2,  take n bytes from base
                               If n = 1, do the same as for n = 1
                                   in   stand-alone   compression
                                   (above),  but take (256 * o  +
                                   k) bytes from base picture.

        x != escape byte       Use x literally. 

<IFF Format>    *.IFF                                             
4 bytes         "FORM" (FORM chunk ID) 
1 long          length of file that follows 
4 bytes         "ILBM" (InterLeaved BitMap file ID)
4 bytes         "BMHD" (BitMap HeaDer chunk ID) 
1 long          length of chunk [20] 
20 bytes        1 word = image width in pixels
                1 word = image height in lines
                1 word = image x-offset [usually 0]
                1 word = image y-offset [usually 0]
                1 byte = # bitplanes
                1 byte = mask  (0=no,   1=impl.,   2=transparent,
                1 byte = compressed [1] or uncompressed [0]
                1 byte = unused [0]
                1 word = transparent color (for mask=2)
                1 byte = x-aspect [5=640x200, 10=320x200/640x400,
                1 byte = y-aspect [11]
                1 word = page  width (usually the same  as  image
                1 word = page  height (usually the same as  image
4 bytes         "CMAP" (ColorMAP chunk ID) 
1 long          length of chunk [3*n where n is the # colors] 
3n bytes        3  bytes per RGB color.   Each color value  is  a
                byte and the actual color value is left-justified
                in the byte such that the most significant bit of
                the value is the MSB of the byte.   (ie.  a color
                value  of 15 ($0F) is stored as $F0)   The  bytes
                are stored in R,G,B order.
4 bytes         "CRNG" (Color RaNGe chunk ID) 
1 long          length of chunk [8] 
8 bytes         1 word = reserved [0]
                1 word = animation  speed (16384 = 60  steps  per
                1 word = active [1] or inactive [0]
                1 byte = left/lower color animation limit
                1 byte = right/upper color animation limit
4 bytes         "CAMG" (Commodore AMiGa viewport mode chunk ID) 
1 long          length of chunk [4] 
1 long          viewport mode bits (bit 11=HAM, bit 3=interlaced)
4 bytes         "BODY" (BODY chunk ID) 
1 long          length  of  chunk  [# bytes of  image  data  that
? bytes         actual image data

 NOTES:  Some  of  these chunks may not be present in  every  IFF 
file,  and may not be in this order.   You should always look for 
the ID bytes to find a certain chunk.  All chunk IDs are followed 
by  a  long  value that tells the size of the  chunk  (note  that 
"ILBM"  is  not a chunk ID).   This is the number of  bytes  that 
FOLLOW the 4 ID bytes and size longword.   The exception to  this 
is the FORM chunk.  The size longword that follows the FORM ID is 
the  size  of the remainder of the file.   The  FORM  chunk  must 
always be the first chunk in an IFF file.

 The R,G,B ranges of AMIGA and ST are different (AMIGA 0...15, ST 
0...7), as is the maximum number of bitplanes (AMIGA: 5, ST: 4).

 Format of body data

 An expanded picture is simply a bitmap.   The packing method  is 
PackBits  (see  below),  and is identical to MacPaint  and  DEGAS 
Elite compressed.
The (decompressed) body data appears in the following order:

        line 1 plane 0 ... line 1 plane 1 ... ... line 1 plane m
        [line 1 mask (if appropriate)]
        line 2 plane 0 ... line 2 plane 1 ... ... line 2 plane m
        [line 2 mask (if appropriate)]
        line x plane 0 ... line x plane 1 ... ... line x plane m
        [line x mask (if appropriate)]
The FORM chunk identifies the type of data:

        "ILBM" = interleaved bit map
        "8SVX" = 8-bit sample voice
        "SMUS" = simple music score
        "FTXT" = formatted text (Amiga)

<MacPaint>      *.MAC                                            
1 long          version number [0=ignore header, 2=header valid] 
38 * 8 bytes    8x8 brush/fill patterns.   Each byte is a pattern
                row,  and  the bytes map the pattern rows top  to
                bottom.   The  patterns are stored in  the  order
                they appear at the bottom of the MacPaint  screen
                top to bottom, left to right. 
204 bytes       unused 
512 bytes       total for header
< 51200 bytes   compressed bitmap data 
< 51712 bytes   total

 NOTE:   The  version  number is actually a flag to  MacPaint  to 
indicate if the brush/fill patterns are present in the file.   If 
the version is 0,  the default patterns are used.   Therefore you 
can  simply save a MacPaint file by writing a blank  header  (512 
$00 bytes), followed by the packed image data.

 Bitmap compression:

 The  bitmap  data  is for a 576 pixel by  720  pixel  monochrome 
image.  The packing method is PackBits (see below).  There are 72 
bytes per scan line.  Each bit represents one pixel; 0 = white, 1 
= black.

<RGB Intermediate Format>       *.RGB (low resolution only)       
 This   format  was  invented  by  Lars  Michael  to   facilitate 
conversions  between  standard  ST  picture  formats  and  higher 
resolution formats like GIF and IFF. It supports 12 bits of color 
resolution  by  keeping the red,  green and  blue  components  in 
separate bit planes.
1 word          resolution (ignored) 
16 word         palette (ignored) 
16000 words     red plane (screen memory) 
1 word          resolution (ignored) 
16 word         palette (ignored) 
16000 words     green plane (screen memory) 
1 word          resolution (ignored) 
16 word         palette (ignored) 
16000 words     blue plane (screen memory) 
96102 bytes     total

 The  format was derived by concatenating three DEGAS .PI1  files 
together -- one for each color gun.  The RGB value for a pixel is 
constructed by looking at the appropriate pixel in the red plane, 
green plane,  and blue plane.   The bitplanes are in standard  ST 
low  resolution  screen RAM format,  but where  pixel  values  in 
screen RAM refer to palette entries (0 through 15),  pixel values 
here correspond to absolute R,  G, and B values.  The red, green, 
and  blue components for each pixel range from 0 to 15 (4  bits), 
yielding a total of 12 bits of color information per pixel.   Not 
coincidentally,  this is exactly the format of ST palette entries 
(although  on ST's without the extended palette only the lower  3 
bits of each color component are used).

 You  can view a single bit plane on a standard ST  by  splitting 
the  .RGB file into its three DEGAS .PI1 components  and  setting 
the palette to successively brighter shades of gray.

<ComputerEyes Raw Data Format>  *.CE1 (low resolution) 
                                *.CE2 (medium resolution)        
1 long          [$45594553 or "EYES"] 
1 word          resolution [0 = low res, 1 = medium res] 
8 words         ? 
If resolution = 0 { 
64000 bytes     red plane, 320 x 200, 1 pixel per byte 
64000 bytes     green plane, 320 x 200, 1 pixel per byte 
64000 bytes     blue plane, 320 x 200, 1 pixel per byte 
192022 bytes    total 

else If resolution = 1 { 
128000 words    640 x 200, 1 pixel per word 
256022 bytes    total 
   This is almost two formats in one:

        Low resolution:

         The   planes  are  arranged   vertically,   instead   of
        horizontally.  The  first  byte is the red  component  of
        pixel (0,0),  the second is (0,1),  and the third  (0,2).
        The 201st corresponds to (1,0), etc.  The 64001st byte is
        the green component of (0,0).
         Only the low six bits of each byte are used.

        Medium resolution:

         The   picture  is  arranged   vertically,   instead   of
        horizontally.  The first word is pixel (0,0),  the second
        is (0,1), and the third (0,2).  The 200th is (1,0) etc.
         Each  word  is divided up into the RGB  values  for  the
        corresponding pixel, as follows:

  Bit: (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB)
             -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
              0 B4 B3 B2 B1 B0 G4 G3 G2 G1 G0 R4 R3 R2 R1 R0

        Bit 15 is not used.

<PackBits Compression Algorithm>                                 

 The  following  packing algorithm originated  on  the  Mac,  was 
adopted by Electronic Arts/Commodore for use in the IFF standard, 
and then by Tom Hudson for use in DEGAS Elite.   The algorithm is 
currently used in MacPaint,  IFF, and DEGAS Elite compressed file 
formats.   Each scan line is packed separately, and packing never 
extends beyond a scan line.
For a given control byte 'n':
    0 <= n <= 127   : use  the  next n + 1  bytes  literally  (no
 -127 <= n <= -1    : use the next byte -n + 1 times.
         n = -128   : no operation, not used.
*    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

        This is the version of Monday November 18th 1991.

                          David Baggett
                     5640 Vantage Point Road
                       Columbia, MD  21044
                         (301)  596-4779

               (Please report errors or additions)

    Copyright (C) 1988, 1989, 1990, 1991 by David M. Baggett 

The text of the articles is identical to the originals like they appeared in old ST NEWS issues. Please take into consideration that the author(s) was (were) a lot younger and less responsible back then. So bad jokes, bad English, youthful arrogance, insults, bravura, over-crediting and tastelessness should be taken with at least a grain of salt. Any contact and/or payment information, as well as deadlines/release dates of any kind should be regarded as outdated. Due to the fact that these pages are not actually contained in an Atari executable here, references to scroll texts, featured demo screens and hidden articles may also be irrelevant.