ST Picture Formats

From AtariForumWiki
Jump to: navigation, search
                           ST Picture Formats
                           ------------------
                               Edited by:

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

  (Please report errors or additions to H.Wessels@C12H22O11_atari_.org.)
       (Please remove the _atari_ part when sending me an e-mail.)

        Copyright (C) 1988, 1989, 1990, 1991 by David M. Baggett
        Additions 2006-2007 Hans Wessels are public domain.

    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  Jason Blochowiak  John Brochu**
        David Brooks  Daniel Deimert  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  George Seto  Joe Smith
              Greg Wageman  Roland Waldi*  Gerry Wheeler


                                Contents 
                                --------

        NEOchrome                               *.NEO
        NEOchrome Animation                     *.ANI
        DEGAS                                   *.PI?   ? = 1, 2, 3 (4, 5, 6)
        DEGAS Elite                             *.PI?   ? = 1, 2, 3
        DEGAS Elite (Compressed)                *.PC?   ? = 1, 2, 3
        DEGAS Elite block                       *.BL?   ? = 1, 2, 3
        DEGAS Elite icon                        *.ICN
        CrackArt                                *.CA?   ? = 1, 2, 3
        ArtDirector                             *.ART
        Tiny                                    *.TN?   ? = 1, 2, 3, Y, (4, 5, 6)
        Spectrum 512                            *.SPU
        Spectrum 512 (Compressed)               *.SPC
        Spectrum 512 (Smooshed)                 *.SPS
        Spectrum 512 Extended                   *.SPX
        Photochrome                             *.PCS
        QuantumPaint                            *.PBX
        Art Director                            *.ART
        C.O.L.R. Object Editor Mural            *.MUR
        Doodle                                  *.DOO
        Cyber Paint Sequence                    *.SEQ
        Animatic Film                           *.FLM
        Animaster Sprite Bank                   *.ASB
        STOS                                    *.MBK
        GEM Bit Image                           *.IMG
        STAD                                    *.PAC
        Imagic Film/Picture                     *.IC?   ? = 1, 2, 3
        IFF                                     *.IFF
        HighresMedium                           *.HRM
        Overscan Interlaced                     *.PCI
        Picture Packer                          *.PP1?  ? = 1, 2, 3
        MacPaint                                *.MAC
        RGB Intermediate Format                 *.RGB
        ComputerEyes Raw Data Format            *.CE?   ? = 1, 2
        FuckPaint                               *.PI4 *.PI9
        TruePaint                               *.TPI
        DelmPaint                               *.DEL, *.DPH
        EggPaint                                *.TRP
        IndyPaint                               *.TRU
        GodPaint                                *.GOD
        PixArt                                  *.PIX
        Canvas                                  *.CNV *.CPT
        DuneGraph                               *.DGU *.DGC
        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 Studio).


                             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 to 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)
                (PI4, PI5, PI6)

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

Conny Pettersson of Unit Seventeen proposed to extend the Degas format with 
PI4 and PI5 for TT resolutions in a text file accompaning the viewst program:

For saving the pictures, I have extended the standard Degas-format PI0 to
the TT-resolutions. Following is a description of the format I use:
               ST-Low                  TT-Low                  TT-Medium
Extension      PI0                     PI4                     PI5
Resolution     1 word: $0000           1 word: $0007           1 word: $0004
Colormap       16 word                 256 word                16 word
Bitmap         32000 bytes             153600 bytes            153600 bytes
Total length   32034 bytes             154114 bytes            153634 bytes

This format is not in wide spread use as datacompression on those huge screens 
really makes sence. Nevertheless various file-extension decriptions on the 
internet assign the extensions PI4, PI5 and PI6 to TT Degas resolutions.

<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
                For high resolution pictures the least significant bit of
                the first word determines whether the picture is black on 
                white (bit set) or white on black (bit not set)
16000 words     picture data (screen memory)
4 words         left color animation limit table (starting color numbers)
4 words         right color animation limit table (ending color numbers)
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
                For high resolution pictures the least significant bit of
                the first word determines whether the picture is black on 
                white (bit set) or white on black (bit not set)
< 32000 bytes   control/data bytes
4 words         left color animation limit table (starting color numbers)
4 words         right color animation limit table (ending color numbers)
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.
 
Caveats:
 
   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.

<DEGAS Elite block>  *.BL1 (low resolution)
                     *.BL2 (medium resolution)
                     *.BL3 (high resolution)
Degas Elite block files are IFF files with a BL? extension. In a Degas 
block the following IFF chunks are found: ILBM, BMHD, CMAP and BODY. 
See the IFF format description.


<DEGAS Elite icon>  *.ICN
This file format is an ASCII file describing the ICON in C-format:#define ICON_W 0x00BF
#define ICON_H 0x????        : Height of the icon in lines (hexadecimal value)
#define ICONSIZE 0x????      : Width of the icon in pixels
int image[ICONSIZE] = 0x???? : Size of the icon in words (hexadecimal value)
{
??                           : ICONSIZE words, icon image data (hexadecimal values)
}


<CarckArt>      *.CA1 (low resolution)
                *.CA2 (medium resolution)
                *.CA3 (high resolution)
 
1 word          'CA' crackart magic
1 byte          compression: 00 = uncompressed, 01 = compressed
1 byte          resolution: 00 = low res, 01 = medium res, 02 = high res
?? words        palette
                For low res pictures there are 16 palette entries
                For med res pictures there are 4 palette entries
                For high res pictures there are 0 palette entries
?? bytes        Picture data:
                For uncompressed pictures 32000 bytes follow
                For compressed pictures the compressed data follows

-----------
< 32057 bytes   total

CrackArt data compression:
1 byte          Escape character
1 byte          Delta: initially the 32000 screen memory are 
                filled with the delta byte
1 word          Offset: offset between two packed bytes;
                Offset is added to the current byte position
                to calculate the next byte position. When the 
                next byte position is greater 32000, the next 
                byte position is the first position of screen 
                memory not written to
                if Offset = 0, the whole screen if filled with 
                the delta byte, no packed bytes follow

1 byte          Cmd: Command byte
                Cmd <> Escape character: Cmd = one literal byte
                Cmd = Escape charater:
                  read 1 control byte
                    0: read one byte, n, and one byte, b;
                       repeat b (n+1) times
                    1: read one word, n, and one byte, b;
                       repeat b (n+1) times
                    2: read one byte, if zero: stop else read 
                       one extra byte and to make word n:
                       repeat Delta (n+1) times
                    Escape character: output one escape charater
                    else: read one byte, b;
                       repeat b cmd times
Decompression stops when Escape 2,0 is found or 32000 bytes have been written


<ArtDirector>  *.ART

32000 bytes     Picture data
8x16  words     8 palettes
8     bytes     8 palette flags, the first pallete with a nonzero flag is used
248   bytes     ?? possibly animation infromation
-----------
32512 bytes   total

<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. The TN4 extension has been found on animated low
resolution files. One can assume the same person(s) will also use TN5 and 
TN6 for extensions for animated medium and high resolution.

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   Copy -x of unique words to take from the data section 
                (from 1 to 128)
        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 zeroes
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 image.

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

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.
 */
int 
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 repetition)
        -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 following:

        "... [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 entry)..."


<Spectrum 512 (Smooshed), or Anispec, see below>          *.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
<= 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 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 type is defined by the least significant 
bit of the last byte in the color bit map.

If the bit is set the data appears in the same order as *.SPC files:

        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

If the bit is not set the data is encoded as byte wide vertical strips:

        Picture data, bit plane 0, scan line   1, MSB.
        Picture data, bit plane 0, scan line   2, MSB.
        Picture data, bit plane 0, scan line   3, MSB.
        . . .
        Picture data, bit plane 0, scan line 199, MSB.
        Picture data, bit plane 0, scan line   1, LSB.
        Picture data, bit plane 0, scan line   2, LSB.
        . . .
        Picture data, bit plane 0, scan line 199, LSB.
        Picture data, bit plane 1, scan line   1, MSB.
        . . .
        Picture data, bit plane 3, scan line 198, LSB
        Picture data, bit plane 3, scan line 199, LSB.

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

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

<Spectrum 512 (Anispec)>          *.SPS
Format for animated Spectrum pictures.

1 word          5353 (hex) ("SS")
30 bytes        unknown header bytes
51104 bytes     uncompressed spectrum picture (see SPU format)
?? bytes        animation data (unknown format) 


<Spectrum 512 Extended>  *.SPX
SPX files are extended Spectrum files with more than 200 lines in the picture, 
designed by Gizmo of Electronic Images. With a SPX createor like SPXCRT14.PRG 
multiple spectrumpictures can be attachted to become one big .SPX file. There 
are two known versions of the format. Version 2 files of the format can be 
packed as a whole (including the header) with either Ice 2.10 or Atomik 3.5.

3  bytes        'SPX', SPX magic header
1  byte         version (01 or 02)
1  byte         graphics compression flag, 0 = unpacked
1  byte         palette compression flag, 0 = unpacked
1  byte         number of 32000 byte screens
3  bytes        reserved
?? bytes        NULL terminated author string
?? bytes        NULL terminated description string
4  bytes        size of (packed) graphics data in bytes
4  bytes        size of (packed) palette data in bytes
?? bytes        (packed) graphics data
?? bytes        (packed) palette data

The number of lines in the picture can be calculated by deviding the size of 
the unpacked graphics data by 160. The unpacked SPX picture can be treated as a 
Spectrum screen with more than 200 lines.

In version 1 when a compression flag is set the data is packed with Ice 2.10.

In version 2 a special packer is used, graphics and palettes are packed in one chunk.
4 bytes         depacked size
4 bytes         packed size
Like the Ice packer data is packed from end of file to start. The depakcer starts
to read data from packed data start+packed size and to write data to 
depacked data start+depacked size. A long is read form packed data into a bitbuffer, 
when the bitbuffer is empty it is refilled with a new long from the packed file. 
With getbits(n) the n most significat bytes are read from the bitbuffer.
while(bytes read<depacked size)
  getbits(1)
    0 : literals
        len = getbits(4*(getbits(2)+1))
        read len bytes with getbits(8) and write them to the destination
        if(len<>$ffff) do a ptr_len
    1 : ptr_len
        ptr = getbits(4*(getbits(2)+1))
        len = getbits(4*(getbits(2)+1))
        copy len+3 bytes from ptr
Note: after a literal there is always a ptr_len except when len was $ffff.


<PhotoChrome>   *.PCS (low resolution only)

1 word          0x0140 (hex) x-resolution (always 320)
1 word          0x00C8 (hex) y-resolution (always 200)
1 byte          00 = single screen mode
                nonzero value's = alternating screen mode,
                bit 0 (0x01) not set: second screen data is xor'ed with first screen
                bit 1 (0x02) not set: second color palette is xor'ed with first
1 byte          bit 0 (0x01) set: 50 Hz mode, when not set 60 Hz mode
?? bytes        compressed screen data
?? bytes        compressed palette
?? bytes        compressed second screen data (in case of alternating screens)
?? bytes        compressed second palette
-------------
 > 18 bytes      total

Screen compression scheme:
1 word          total number of control bytes that follow
1 control byte  x
                x < 0 : copy -x literal bytes (1 - 128)
                x = 0 : next word specifies the number of times the following byte 
                        has to be copied (0-65535)
                x = 1 : next word specifies the number of bytes to be copied (0-65535)
                x > 1 : repeat the next byte x times (2-127)

The 4 bitplanes are separated, first 8000 bytes of the first bitplane, then 8000 bytes 
for the second, 8000 bytes for the third and 8000 bytes for the fourth; a total of 32000 bytes.

Palette compression scheme:
the palette compression scheme is the same as the screen compression but it works with 
16 bit words
1 word          total number of control bytes that follow
1 control byte  x
                x < 0 : copy -x literal words (1 - 128)
                x = 0 : next word specifies the number of times the following word 
                        has to be copied (0-65535)
                x = 1 : next word specifies the number of words to be copied (0-65535)
                x > 1 : repeat the next word x times (2-127)

In total 9616 palette entries are stored. 200 scanlines with 3 palettes
(48 colors) each, plus one final palette (16 colors). PhotoChrome files
with a few extra entries have been found. The first scanline usually
contains no data.

/*
 *  Given an x-coordinate and a color index, returns the corresponding
 *  Photochrome palette index.
 *
 *  by Hans Wessels; placed in the public domain januari, 2008.
 */
int find_pcs_index(int x, int c)
{
	int x1=4*c;
	int index = c;
	if(x>=x1)
	{
		index+=16;
	}
	if((x>=(x1+64+12)) && (c<14))
	{
		index+=16;
	}
	if((x>=(132+16)) && (c==14))
	{
		index+=16;
	}
	if((x>=(132+20)) && (c==15))
	{
		index+=16;
	}
	x1=10*c;
	if((c&1)==1)
	{
	  x1-=6;
	}
	if((x>=(176+x1)) && (c<14))
	{
		index+=16;
	}
	return index;
}

<QuantumPaint>  *.PBX (low and medium resolution)

3 bytes         0
1 byte          mode, 0x00 =  128 color low resolution pciture, 
                      0x01 =   32 color medium resolution picture,
                      0x80 =  512 color picture low resolution picture
                      0x81 = 4096 color picture low resolution picture
1 word          0x8001 = compressed
                Quantumpaint v2.00 sets it to 0x8000 for uncompressed files
                Quantumpaint v1.00 seems to use 0x0000 for lowras and 0x0333
                for medium res bytes. The PBX viewer only tests for 0x8001.
122 bytes       ??
                total 128 header bytes
?? bytes        palette data;
                for uncompressed normal pictures 8 pallete datasets follow:
                    16 words: 16 palettes
                     1 word: number of the first line this pallet is used
                     1 word: 0 the palette is not active, else this pallete is active
                     1 word: first color of color cycle
                     1 word: last color of color cycle
                     1 word: cycle speed, number of vbl's between steps, 0 = fastest
                     1 word: 0: no cycling, 1 cycle right, 0xffff cycle left
                     2 word: ?? should be zero
                    __
                    48 bytes per palette
                    The first palette should always be active and start on line 0
                   ___
                   384 bytes palette data for low (128 color) and medium (32 color) pictures
                for uncompressed 512 color pictures 6400 words (32 colors per scanline)
                for uncompressed 4096 color pictures 12800 words (32 colors per scanline,
                2 palette sets for alternating screens, two 6400 word blocks)
?? bytes        screen data, for uncompressed pictures this is 32000 bytes for all modes
--------
> 128 bytes total

Compression scheme
Palette and screen data are compressed into one block using packbits compression.
The expanded screen 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
This colmn ordering is just the same as in the Tiny format.
for medium res it is the same only with two stes for the two medium res bitplanes.

/*
 *  Given an x-coordinate and a color index, returns the corresponding
 *  QuantumPaint palette index.
 *
 *  by Hans Wessels; placed in the public domain januari, 2008.
 */
int find_pbx_index(int x, int c)
{
	int x1 = 10 * c;
	if (1 & c)
	{	/* If c is odd */
		x1 = x1 - 5;
	}
	else
	{	/* If c is even */
		x1 = x1 + 1;
	}
	if(c>7)
	{
	  x1+=12;
	}
	if(x>=(x1+75))
	{
		c = c + 16;
	}
	return c;
}


<Art Director>  *.ART (low resolution only)

16000 words     picture data (screen memory)
16 words        palette
 7 * 16 words   7 more palettes for animation
 8 *  1 byte    display time for palettes, use first palette with non zero display time
    248 bytes   unknown
-------------
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 times.
 
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 below)
1 word          height of this frame, in pixels (may be 0, see below)
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 32767).
        x > 0   Specifies the number of times to repeat the next word
                taken from the data section (from 1 to 32767).

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


<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 STOS)
1 byte          width in words (multiply by 16 to get width in pixels)
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 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.
 

<STAD>          *.PAC (high resolution only)

4 bytes         "pM86" (vertically packed) or "pM85" (horizontally packed)
1 byte          id byte
1 byte          pack byte (most frequently occurring byte in bitmap)
1 byte          "special" byte
-------
7 bytes         total for header

? bytes         data

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

        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 order).
                                Use byte d n + 1 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 unsigned).

                                If n >= 2, use the next byte n times.
                                If n = 1, keep reading bytes until a
                                byte k not equal to 1 is encountered.
                                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) {
                                                o++;
                                                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 unsigned).

                                If n >= 3, use the next byte n times.
                                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
                                        picture.
                                        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, 3=lasso)
                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, 20=320x400]
                1 byte = y-aspect [11]
                1 word = page width (usually the same as image width)
                1 word = page height (usually the same as image height)

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 second)
                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  2 = interlaced
                  bit  7 = half-bright
                  bit 11 = HAM
                  bit 15 = high res

4 bytes         "BODY" (BODY chunk ID)
1 long          length of chunk [# bytes of image data that follow]
? 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)

The ST version of DPAINT has a different format in the body data. Within 
the BODY chunk there is a VDAT chunk. In every VDAT chunk data is compressed 
in columns, like in the Tiny format. Only the compression routine is slightly 
different.
4 bytes          'VDAT' vertical bitplane data
4 bytes          length of cunk
?? bytes         compressed data

Data compression format:
2 bytes          cmd_cnt number of cmd bytes

while(cmd_cnt>0)
  1 byte cmd     0: read two bytes, count
                    output 2*count literal bytes
                 1: read two bytes, count and read 2 bytes, data (1 word)
                    output data count times
                <0: output 2*(128-(cmd&0x7f)) literal bytes
                >2: read 2 bytse, data (1 word)
                    output data (cmd&0x7f) times


<HighresMedium>   *.HRM

This format is found in only one demo: "HighResMode" by Paradox. The 
pictures are interlaced in medium resolution with 35 colors per line. 
The files are packed with Ice. The unpacked format is as follows:
64000 bytes      screen data, 160 bytes per scanline, 400 lines
28000 bytes      palette data, 70 bytes per line
-----
96000 bytes

/*
 *  Given an x-coordinate and a color index, returns the corresponding
 *  HighResMedium palette index.
 *
 *  by Hans Wessels; placed in the public domain januari, 2008.
 */
int find_hrm_index(int x, int c)
{
  x+=80;
	if(c==0)
	{
	  return -1+4*(int)((x+0)/80);
	}
	else if(c==1)
	{
	  return 4*(int)((x-8)/80);
	}
	else if(c==2)
	{
	  return 1+4*(int)((x-40)/80);
	}
  return 2+4*(int)((x-48)/80);
}


<Overscan Interlaced>  *.PCI

This format is found in only one demo: "Tobias Richter Fullscreen 
Slideshow". The pictures are in an interlaced overscan format and 
use a separate pallette per scanline (16 colors). The resolution of
the screendata is 352 x 278 pixels, with 176 words per line.
The files are packed with the Ice. The unpacked format is as follows:
 48928 bytes     screen data first screen
 48928 bytes     screen data second screen
  8896 bytes     color data first screen
  8896 bytes     color data second screen
------
115648 bytes total

The screen data is stored in 4 seperate bitplane blocks: first all data 
of bitplane 0, then all data of bitplane 1, then the data of bitplane 2 
and last the data of bitplane 3.


<Picture Packer>  *.PP1 (low resolution)
                  *.PP2 (medium resolution)
                  *.PP3 (high resolution)

This is a STOS packed screen without the STOS MBK header in front of the 
data. Although the STOS screen format has a flag for the resolution this 
flag is set to medium resolution for all *.PP? files. The only correct 
resolution info is in the extension. A realy brainded format.


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


<FuckPaint>     *.PI4, *.PI9

   Fuckpaint was an early Atari Falcon drawing program. The format is 
still popular because its simplicity. The PI4 extension is used for 
320x240 pictures, the PI9 for 320x200 pictures. Except for the extension 
the two formats are exact the same.

  256 long      Palette 256 colors, in Falcon format, R, G, 0, B
38400 words     Picture data, 8 interleaved bitplanes
-----------
77824 bytes     total


<TruePaint>     *.TPI
<PrismPaint>    *.PNT

  1 long        $504e5400 'PNT ' TruePaint Magic
  1 word        $0100            ???? file version
  1 word        palette_size     Might be there in true color
  1 word        x_size
  1 word        y_size
  1	word        bits_per_pixel
  1 word        compression, $0000 uncompressed, $0001 prsimpaint compressed
  1	long        picture_data_size = ((x_size+15)&0xffff0)*y_size*bits_per_pixel/8 
                (uncompressed)
108 bytes       $0
---------
128 bytes       total for header

3*palette_size     words   Palette data, RGB, values 0..1000. The colors are in 
                           VDI order
                          
picture_data_size  bytes   Interleaved bitplanes for bits_per_pixel<16, a 16 bit 
                           word per pixel for 16-bit pictures, RRRRrGGGGGgBBBBBb.
                           The line length is a multiple of 16 pixels for all bit depths
The prismpaint compressed format uses the packbits compression algorithm. For every 
scanline the bitplanes are compressed seperately. The falcon high color resolution 
(16 bit) is compressed as if there were 16 bitplanes, which there are not.


<DelmPaint>     *.DEL, *.DPH

Delmpaint is a 256 color painting package. It works in 320x200 and 320x240 but
there is no difference in the file type. From a .DEL file you can not tel whether
it is a 320x200 or a 320x240 file. The same is true for a *.DPH file, which is 
either a 640x400 or a 640x480 file. The bigger format is always assumed.

*.DEL format:
The *.DEL format contains 3 compressed blocks which are decompressed 32000 bytes.
Those three blocks joined together are the depacked file.
Paked:
  1 long        length of 1st packed block
  1 long        length of 2nd packed block
??? bytes       1st packed block, depacked 32000 bytes
??? bytes       2nd packed block, depacked 32000 bytes
??? bytes       3rd packed block, depacked 32000 bytes
The blocks are packed with the same algorithm as used in Crackart

Depacked:
  256 longs     Palette 256 colors, in Falcon format, R, G, 0, B
38400 words     Picture data, 8 interleaved bitplanes

*.DPH format:
The *.DPH format contains 11 compressed blocks which are decompressed 32000 bytes.
Those three blocks joined together are the depacked file.
Paked:
 10 long        length of 11st to 10th packed block
  
??? bytes       1st packed block, depacked 32000 bytes
??? bytes       2nd packed block, depacked 32000 bytes
....
??? bytes       1th packed block, depacked 32000 bytes
The blocks are packed with the same algorithm as used in Crackart

Depacked:
  256 longs     Palette 256 colors, in Falcon format, R, G, 0, B
38400 words     Picture 1 320x240 data, 8 interleaved bitplanes
38400 words     Picture 2 320x240 data, 8 interleaved bitplanes
38400 words     Picture 3 320x240 data, 8 interleaved bitplanes
38400 words     Picture 4 320x240 data, 8 interleaved bitplanes
Finally you have to join the pictures into one huge 640x480 picture.
Take 320 bytes from picture 1, then 320 from 2, repeat 240 times, do
the same for picture 3 and 4.


<EggPaint>      *.TRP

   1 long       'TRUP' file ID
   1 word       xres
   1 word       yres
xres*yres*2 bytes Falcon true color data,  word RRRRRGGGGGGBBBBB
Packed EggPaint pictures are packed with ICE 2.4.


<IndyPaint>     *.TRU

   1 long       'Indy' file ID
   1 word       xres
   1 word       yres
 248 bytes      0
xres*yres*2 bytes Falcon true color data,  word RRRRRGGGGGGBBBBB


<GodPaint>      *.GOD

   1 word       file ID, 'G4' and $0400 have been seen. The GodPaint 
                program ignores the ID.
   1 word       xres
   1 word       yres
xres*yres*2 bytes Falcon true color data,  word RRRRRGGGGGGBBBBB

<PixArt>        *.PIX

   1 long       'PIXT' file ID
   1 word       version, $0001 or $0002
   1 byte       chunky (0) or planar (1)
   1 byte       #bitplanes
   1 word       xres (always a multiple of 16)
   1 word       yres
   1 word       unknown
   1 word       unknown (version $0002 only)
---------
14 or 16 byte toltal headersize

 3*n bytes       palette, only for bitdepth 2, 4, 8.
???? bytes       image data, chunky or planar for bit depth 2, 4, 8
                 for bit depth 16 alway chunkey, Falcon RGB format 
                 (RRRRRGGGGGGBBBBB)


<Canvas>         *.CNV, *.CPT

Canvas is a simple drawing program for the Atari ST. The simplest file
format it uses is .CNV. The format has no infor on the resolution of 
the image. The colors are stored in VDI order.

   48 bytes       palette, value 0-7 per byte, RGB in VDI order.
32000 bytes       image data


The CPT format is a compressed format:
   16 words       palette
    1 word        resolution (0=low, 1=med, 2=high resolution)
  ??? words       compressed data, uncompressed 32000 bytes
  
Packing algorithm: first all runlength data is transfered. Then the
gaps that haven't been filled with runlengthdata is filled with the 
remaining data from file.
Runlength data:
    1 word        repeat count
    1 word        offset
    n words       run length data (n=4 low, 2 med, 1 high)
The n words run length data are repeated (repeat count +1) times from 
offset bytes from the start of the file. When repeat count $FFFF signifies 
the end of the run length data (the offset and run length data still folow 
the $FFFF repeat count).
  ??? words       data to fill the gaps that haven't been filled with run 
length data.
  

<DuneGraph>       *.DGU, *.DGC
The *.DGU is a simple uncompressed format:
    3 bytes       'DGU' file ID ($444755)
    1 byte        version number (1)
    1 word        xres (320)
    1 word        yres (200)
  256 long        palette, Falcon format, RG0B
64000 bytes       picture data, 320x200, 8 bitplanes (other resolutions have not been seen)

The *.DC1 is a simple compressed format:
    3 bytes       'DGC' file ID  ($444743)
    1 byte         packing method (0, 1, 2 or 3)
    1 word        xres
    1 word        yres
    1 word        unknown ($00ff)
  256 long        palette, Falcon format, RG0B
  ??? bytes       compressed picture data
Compressed picture data:
Method 0: no compression, 64000 bytes, 320x200, 8 bitplanes
For method 1 to 3 the bit planes are unmixed, so first you get all
data for bit plane 0, then bit plane one etc.
Method 1: simple runlength on byte level
     1 long       size of compressed data, including this long
     do
       1 byte       repeat count
       1 byte       data
       write (repeat count+1) times data
     until you run out of compressed data
Method 2: simple runlength on word level
     1 long       size of compressed data, including this long
     do
       1 word       repeat count
       1 word       data
       write (repeat count+1) times data
     until you run out of compressed data
Method 3: simple runlength on long level
     1 long       size of compressed data, including this long
     do
       1 word       repeat count
       1 long       data
       write (repeat count+1) times data
     until you run out of compressed data


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


Back to Graphics