home *** CD-ROM | disk | FTP | other *** search
/ Fujiology Archive / fujiology_archive_v1_0.iso / !MAGS / ICTARI / ICTARI46.ZIP / MISC / PIC_FMTS / PIC_FMTS.TXT
Internet Message Format  |  1993-04-21  |  50KB
  1. Path: cix.compulink.co.uk!uknet!marble.uknet.ac.uk!mcsun!uunet!enterpoop.mit.edu!ai-lab!case!dmb
  2. From: dmb@case.ai.mit.edu (David Baggett)
  3. Newsgroups: comp.sys.atari.st,comp.sys.atari.st.tech
  4. Subject: Latest Picture Formats List
  5. Keywords: atari picture formats
  6. Message-ID: <1pck2jINNicr@life.ai.mit.edu>
  7. Date: 31 Mar 93 17:23:31 GMT
  8. Reply-To: dmb@ai.mit.edu
  9. Followup-To: comp.sys.atari.st.tech
  10. Organization: MIT Artificial Intelligence Lab
  11. Lines: 1210
  12. NNTP-Posting-Host: case.ai.mit.edu
  13.  
  14. *-----------------------------------------------------------------------------*
  15. New this time: GEM Metafiles, courtesy of Marcel Boom.
  16.  
  17. Dave
  18. *-----------------------------------------------------------------------------*
  19.  
  20.                            ST Picture Formats
  21.                            ------------------
  22.                                Edited by:
  23.  
  24.                               David Baggett
  25.  
  26.                                 Internet:
  27.                              dmb@ai.mit.edu
  28.  
  29.                    (Please report errors or additions.)
  30.  
  31.             Copyright (C) 1988 -- 1993  by David M. Baggett
  32.  
  33.  
  34.     Non-profit redistribution of this document is permitted, provided
  35.     the document is not modified in any way.
  36.  
  37.     Reproduction of this document in whole or in part for  commercial
  38.     purposes is expressly forbidden without the prior written consent
  39.     of David M. Baggett.
  40.  
  41.     The  information  presented here is not guaranteed to be correct.
  42.     The editor and contributors will in no event be liable for direct,
  43.     indirect, incidental, or consequential damages resulting from the 
  44.     use of the information in this document.
  45.  
  46.     This document is the product of many hours of volunteer work by a
  47.     large number of people. Please respect this -- do not violate the
  48.     distribution policy.
  49.  
  50.  
  51.                               CONTRIBUTORS
  52.   
  53.              Steve Belczyk  Phil Blanchfield  Marcel Boom
  54.     Jason Blochowiak  John Brochu**  David Brooks  Daniel Deimert
  55.     Neil Forsyth  Stefan Hoehn  Gerfried Klein  G. "Maddog" Knauss
  56.         Ken MacLeod  Shamus McBride  Jim McCabe  Lars Michael
  57.         Darek Mihocka  David Mumper  George Nassas  Jim Omura
  58.                  George Seto  Joe Smith  Greg Wageman
  59.                      Roland Waldi*  Gerry Wheeler
  60.  
  61.  
  62.                                 Contents 
  63.                                 --------
  64.  
  65.         NEOchrome                               *.NEO
  66.         NEOchrome Animation                     *.ANI
  67.         DEGAS                                   *.PI?   ? = 1, 2, 3
  68.         DEGAS Elite                             *.PI?   ? = 1, 2, 3
  69.         DEGAS Elite (Compressed)                *.PC?   ? = 1, 2, 3
  70.         Tiny                                    *.TN?   ? = 1, 2, 3, Y
  71.         Spectrum 512                            *.SPU
  72.         Spectrum 512 (Compressed)               *.SPC
  73.         Spectrum 512 (Smooshed)                 *.SPS
  74.         Art Director                            *.ART
  75.         C.O.L.R. Object Editor Mural            *.MUR
  76.         Doodle                                  *.DOO
  77.         Cyber Paint Sequence                    *.SEQ
  78.         Animatic Film                           *.FLM
  79.         Animaster Sprite Bank                   *.ASB
  80.         STOS                                    *.MBK
  81.         GEM Bit Image                           *.IMG
  82.         GEM Metafile (vector graphics)          *.GEM
  83.         STAD                                    *.PAC
  84.         Imagic Film/Picture                     *.IC?   ? = 1, 2, 3
  85.         IFF                                     *.IFF
  86.         RGB Intermediate Format                 *.RGB
  87.         ComputerEyes Raw Data Format            *.CE?   ? = 1, 2
  88.         MacPaint                                *.MAC
  89.         PackBits Compression Algorithm
  90.  
  91.  
  92.                         Introductory Information
  93.                         ------------------------
  94. word    = 2 bytes
  95. long    = 4 bytes
  96. palette = Hardware color palette, stored as 16 words.  First word is
  97.           color register zero (background), last word is color register
  98.           15.  Each word has the form:
  99.  
  100.           Bit:  (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB)
  101.                       -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  102.                        0  0  0  0  0 R2 R1 R0  0 G2 G1 G0  0 B2 B1 B0
  103.  
  104.           R2 = MSB of red intensity
  105.           R0 = LSB of red intensity
  106.  
  107.           G2 = MSB of green intensity
  108.           G0 = LSB of green intensity
  109.  
  110.           B2 = MSB of blue intensity
  111.           B0 = LSB of blue intensity
  112.  
  113.           Intensity ranges from 0 (color not present) to 7 (highest
  114.           intensity).
  115.  
  116.           Example: { red = 7, green = 3, blue = 5 } -> 0735 (hex)
  117.  
  118.           Caveat:  It is wise to mask off the upper four bits of each
  119.                    palette entry, since a few programs store special
  120.                    information there (most notably Art Studio).
  121.  
  122.  
  123.                              The Formats
  124.                              -----------
  125.  
  126. <NEOchrome>     *.NEO
  127.  
  128. 1 word          flag byte [always 0]
  129. 1 word          resolution [0 = low res, 1 = medium res, 2 = high res]
  130. 16 words        palette
  131. 12 bytes        filename [usually "        .   "]
  132. 1 word          color animation limits.  High bit (bit 15) set if color
  133.                 animation data is valid.  Low byte contains color animation
  134.                 limits (4 most significant bits are left/lower limit,
  135.                 4 least significant bits are right/upper limit).
  136. 1 word          color animation speed and direction.  High bit (bit 15) set
  137.                 if animation is on.  Low order byte is # vblanks per step.
  138.                 If negative, scroll is left (decreasing).  Number of vblanks
  139.                 between cycles is |x| - 1
  140. 1 word          # of color steps (as defined in previous word) to display
  141.                 picture before going to the next.  (For use in slide shows)
  142. 1 word          image X offset [unused, always 0]
  143. 1 word          image Y offset [unused, always 0]
  144. 1 word          image width [unused, always 320]
  145. 1 word          image height [unused, always 200]
  146. 33 words        reserved for future expansion
  147. 16000 words     picture data (screen memory)
  148. -----------
  149. 32128 bytes     total
  150.  
  151.  
  152. <NEOchrome Animation>        *.ANI
  153.  
  154. NOTE:      To get this feature on versions 0.9 and later select the Grabber
  155.         icon and click both mouse buttons in the eye of the second R in the
  156.         word GRABBER.
  157.            Interestingly enough, some versions of NEO only require you
  158.         to press the right button, not both.  Hmmm...
  159.  
  160. 1 long          magic number BABEEBEA (hex) (seems to be ignored)
  161. 1 word          width of image in bytes (always divisible by 8)
  162. 1 word          height of image in scan lines
  163. 1 word          size of image in bytes + 10 (!)
  164. 1 word          x coordinate of image (must be divisible by 16) - 1
  165. 1 word          y coordinate of image - 1
  166. 1 word          number of frames
  167. 1 word          animation speed (# vblanks to delay between frames)
  168. 1 long          reserved; should be zero
  169. --------
  170. 22 bytes        total for header
  171.  
  172. ? words         image data (words of screen memory) for each frame, in 
  173.                 order
  174.  
  175.  
  176. <DEGAS>         *.PI1 (low resolution)
  177.                 *.PI2 (medium resolution)
  178.                 *.PI3 (high resolution)
  179.  
  180. 1 word          resolution (0 = low res, 1 = medium res, 2 = high res)
  181.                 Other bits may be used in the future; use a simple bit
  182.                 test rather than checking for specific word values.
  183. 16 words        palette
  184. 16000 words     picture data (screen memory)
  185. -----------
  186. 32034 bytes     total
  187.  
  188.  
  189. <DEGAS Elite>   *.PI1 (low resolution)
  190.                 *.PI2 (medium resolution)
  191.                 *.PI3 (high resolution)
  192.  
  193. 1 word          resolution (0 = low res, 1 = medium res, 2 = high res)
  194.                 Other bits may be used in the future; use a simple bit
  195.                 test rather than checking for specific word values.
  196. 16 words        palette
  197. 16000 words     picture data (screen memory)
  198. 4 words         left color animtion limit table (starting color numbers)
  199. 4 words         right color animation limit table (ending color numbers)
  200. 4 words         animation channel direction flag (0 = left, 1 = off, 2 = right)
  201. 4 words         128 - animation channel delay in 1/60's of a second. [0 - 128]
  202.                 (I.e., subtract word from 128 to get 1/60th's of a second.)
  203. -----------
  204. 32066 bytes     total
  205.  
  206.  
  207. <DEGAS Elite (Compressed)>      *.PC1 (low resolution)
  208.                                 *.PC2 (medium resolution)
  209.                                 *.PC3 (high resolution)
  210.  
  211. 1 word          resolution (same as Degas, but high order bit is set;
  212.                 i.e., hex 8000 = low res, hex 8001 = medium res,
  213.                 hex 8002 = high res).  Other bits may be used in the
  214.                 future; use a simple bit test rather than checking
  215.                 for specific word values.
  216. 16 words        palette
  217. < 32000 bytes   control/data bytes
  218. 4 words         left color animation limit table (starting color numbers)
  219. 4 words         right color animation limit table (ending color numbers)
  220. 4 words         animation channel direction flag [0 = left, 1 = off, 2 = right]
  221. 4 words         128 - animation channel delay in 1/60's of a second. [0 - 128]
  222.                 (I.e., subtract word from 128 to get 1/60th's of a second.)
  223. -----------
  224. < 32066 bytes   total
  225.  
  226. Compression Scheme:
  227.  
  228.    PackBits compression is used (see below).  Each scan line is compressed
  229. separately; i.e., all data for a given scan line appears before any data
  230. for the next scan line.  The scan lines are specified from top to bottom
  231. (i.e., 0 is first).  For each scan line, all the data for a given bit plane
  232. appears before any data for the next higher order bit plane.  Note that this
  233. is identical to the IFF 'BODY' image data.
  234.    To clarify:  The first data in the file will be the data for the lowest
  235. order bit plane of scan line zero, followed by the data for the next higher
  236. order bit plane of scan line zero, etc., until all bit planes have been
  237. specified for scan line zero.  The next data in the file will be the data
  238. for the lowest order bit plane of scan line one, followed by the data for
  239. the next higher order bit plane of scan line one, etc., until all bit planes
  240. have been specified for all scan lines.
  241.  
  242. Caveats:
  243.  
  244.    DEGAS Elite's picture loading routine places some restrictions on
  245. compressed DEGAS files:
  246.  
  247.         o Elite uses a 40-byte buffer to store data being decompressed.
  248.  
  249.         o Whenever a control command is encountered, bytes are stuffed
  250.         in this buffer.
  251.  
  252.         o The buffer is only emptied when there are EXACTLY 40
  253.         characters in it.
  254.  
  255. The important conclusion here is that
  256.  
  257.         No control command may cause the buffer to have more than 40
  258.         bytes in it.  In other words, all control commands must end on
  259.         or before the 40-byte boundary.
  260.  
  261. Any picture violating the last condition will cause Elite to get a bus
  262. error when the picture is loaded.
  263.  
  264.  
  265. <Tiny>  *.TNY (any resolution)
  266.         *.TN1 (low resolution)
  267.         *.TN2 (medium resolution)
  268.         *.TN3 (high resolution)
  269.  
  270.    Several people have reported sightings of mutated Tiny pictures that
  271. do not follow the standard format, so let's be careful out there.  What
  272. is described here is the format that David Mumper's original
  273. TNYSTUFF.PRG produces.
  274.  
  275. 1 byte          resolution (same as NEO, but +3 indicates rotation
  276.                 information also follows)
  277.  
  278. If resolution > 2 {
  279. 1 byte          left and right color animation limits.  High 4 bits
  280.                 hold left (start) limit; low 4 bits hold right (end) limit
  281. 1 byte          direction and speed of color animation (negative value
  282.                 indicates left, positive indicates right, absolute value
  283.                 is delay in 1/60's of a second.
  284. 1 word          color rotation duration (number of iterations)
  285. }
  286.  
  287. 16 words        palette
  288. 1 word          number of control bytes
  289. 1 word          number of data words
  290. 3-10667 bytes   control bytes
  291. 1-16000 words   data words
  292. -------------
  293. 42-32044 bytes  total
  294.  
  295. Control byte meanings:
  296.  
  297.         For a given control byte, x:
  298.  
  299.         x < 0   Absolute value specifies the number of unique words to
  300.                 take from the data section (from 1 to 127)
  301.         x = 0   1 word is taken from the control section which specifies
  302.                 the number of times to repeat the next data word (from
  303.                 128 to 32767)
  304.         x = 1   1 word is taken from the control section which specifies
  305.                 the number of unique words to be taken from the data
  306.                 section (from 128 - 32767)
  307.         x > 1   Specifies the number of times to repeat the next word
  308.                 taken from the data section (from 2 to 127)
  309.  
  310. Format of expanded data:
  311.  
  312.    The expanded data is not simply screen memory bitmap data; instead, the 
  313. data is divided into four sets of vertical columns.  (This results in
  314. better compression.)  A column consists of one specific word taken
  315. from each scan line, going from top to bottom.  For example, column 1 
  316. consists of word 1 on scanline 1 followed by word 1 on scanline 2, etc., 
  317. followed by word 1 on scanline 200.
  318.    The columns appear in the following order:
  319.  
  320.    1st set contains columns 1, 5,  9, 13, ..., 69, 73, 77 in order
  321.    2nd set contains columns 2, 6, 10, 14, ..., 70, 74, 78 in order
  322.    3rd set contains columns 3, 7, 11, 15, ..., 71, 75, 79 in order
  323.    4th set contains columns 4, 8, 12, 16, ..., 72, 76, 80 in order
  324.  
  325. Note that Tiny partitions the screen this way regardless of resolution; i.e., 
  326. these aren't bitplanes.  For example, medium resoltion only has two bitplanes, 
  327. but Tiny still divides medium resolution pictures into four parts.
  328.  
  329.  
  330. <Spectrum 512>  *.SPU
  331.  
  332. 80 words        first scan line of picture (unused) -- should be zeroes
  333. 15920 words     picture data (screen memory) for scan lines 1 through 199
  334. 9552 words      3 palettes for each scan line (the top scan line is
  335.                 not included because Spectrum 512 can't display it)
  336. -----------
  337. 51104 bytes     total
  338.  
  339. Note that the Spectrum 512 mode's three palette changes per scan
  340. line allow more colors on the screen than normally possible, but a
  341. tremendous amount of CPU time is required to maintain the image.
  342.  
  343. The Spectrum format specifies a palette of 48 colors for each scan line.
  344. To decode a Spectrum picture, one must be know which of these 48 colors
  345. are in effect for a given horizontal pixel position.
  346.  
  347. Given an x-coordinate (from 0 to 319) and a color index (from 0 to 15),
  348. the following C function will return the proper index into the Spectrum
  349. palette (from 0 to 47):
  350.  
  351. /*
  352.  *  Given an x-coordinate and a color index, returns the corresponding
  353.  *  Spectrum palette index.
  354.  *
  355.  *  by Steve Belczyk; placed in the public domain December, 1990.
  356.  */
  357. int 
  358. FindIndex(x, c)
  359.         int x, c;
  360. {
  361.         int x1;
  362.  
  363.         x1 = 10 * c;
  364.  
  365.         if (1 & c)              /* If c is odd */
  366.                 x1 = x1 - 5;
  367.         else                    /* If c is even */
  368.                 x1 = x1 + 1;
  369.  
  370.         if (x >= x1 && x < x1 + 160) 
  371.                 c = c + 16;
  372.         else if (x >= x1 + 160) 
  373.                 c = c + 32;
  374.  
  375.         return c;
  376. }
  377.  
  378.  
  379. <Spectrum 512 (Compressed)>        *.SPC
  380.  
  381. 1 word          flag word [$5350 or "SP"]
  382. 1 word          reserved for future use [always 0]
  383. 1 long          length of data bit map
  384. 1 long          length of color bit map
  385. <= 32092 bytes  compressed data bit map
  386. <= 17910 bytes  compressed color bit map
  387. --------------
  388. <= 50014 bytes  total
  389.  
  390. Data compression:
  391.  
  392.    Compression is via a modified run length encoding (RLE) scheme,
  393. similar to DEGAS compressed and Tiny.  The data map is stored as a
  394. sequence of records.  Each record consists of a header byte followed by
  395. one or more data bytes.  The meaning of the header byte is as follows:
  396.  
  397.         For a given header byte, x:
  398.  
  399.            0 <= x <= 127   Use the next x + 1 bytes literally (no repetition)
  400.         -128 <= x <=  -1   Use the next byte -x + 2 times
  401.  
  402. The data appears in the following order:
  403.  
  404.         1. Picture data, bit plane 0, scan lines 1 - 199
  405.         2. Picture data, bit plane 1, scan lines 1 - 199
  406.         3. Picture data, bit plane 2, scan lines 1 - 199
  407.         4. Picture data, bit plane 3, scan lines 1 - 199
  408.  
  409. Decompression of data ends when 31840 data bytes have been used.
  410.  
  411. Color map compression:
  412.  
  413.    Each 16-word palette is compressed separately.  There are three
  414. palettes for each scan line (597 total).  The color map is stored as a
  415. sequence of records.  Each record starts with a 1-word bit vector which
  416. specifies which of the 16 palette entries are included in the data
  417. following the bit vector (1 = included, 0 = not included).  If a palette
  418. entry is not included, it is assumed to be zero (black).  The least
  419. significant bit of the bit vector refers to palette entry zero, while the
  420. most significant bit refers to palette entry 15.  Bit 15 must be zero,
  421. since Spectrum 512 does not use palette entry 15.  Bit 0 should also be
  422. zero, since Spectrum 512 always makes the background color black.
  423.    The words specifying the values for the palette entries indicated in
  424. the bit vector follow the bit vector itself, in order (0 - 15).
  425.  
  426. NOTE:   Regarding Spectrum pictures, Shamus McBride reports the following:
  427.  
  428.         "... [The Picture Formats List] says bit 15 of the color map vector
  429.         must be zero. I've encountered quite a few files where [bit 15] is 
  430.         set (with no associated palette entry)..."
  431.  
  432.  
  433. <Spectrum 512 (Smooshed)>          *.SPS
  434.  
  435.    This format compresses Spectrum 512 pictures better than the standard
  436. method.  There are at least two programs that support this format, SPSLIDEX
  437. and ANISPEC, although the two seem to differ slightly in their interpretation
  438. of the format.
  439.    One point of interest: Shamus McBride deciphered this format without an ST!
  440.  
  441. 1 word          5350 (hex) ("SP")
  442. 1 word          0 (reserved for future use)
  443. 1 long          length of data bit map
  444. 1 long          length of color bit map
  445. <= ? bytes      compressed data bit map
  446. <= ? bytes      compressed color bit map
  447. ----------
  448. < ?  bytes      total
  449.  
  450. Data compression:
  451.  
  452.    Compression is via a modified run length encoding (RLE) scheme,
  453. similar to that used in Spectrum Compressed (*.SPC) pictures.
  454.  
  455. The data map is stored as a sequence of records.  Each record consists of a
  456. header byte followed by one or more data bytes.  The meaning of the header
  457. byte is as follows:
  458.  
  459.         For a given header byte, x (unsigned):
  460.  
  461.           0 <= x <= 127    Use the next byte x + 3 times
  462.         128 <= x <= 255    Use the next x - 128 + 1 bytes literally
  463.                            (no repetition)
  464.  
  465. There are two kinds of *.SPS files.
  466.  
  467. The data may appear in the same order as *.SPC files (SPSLIDEX format?):
  468.  
  469.         1. Picture data, bit plane 0, scan lines 1 - 199
  470.         2. Picture data, bit plane 1, scan lines 1 - 199
  471.         3. Picture data, bit plane 2, scan lines 1 - 199
  472.         4. Picture data, bit plane 3, scan lines 1 - 199
  473.  
  474. The second variant (ANISPEC format?) encodes the data as byte wide vertical
  475. strips:
  476.  
  477.         Picture data, bit plane 0, scan line   1, columns   0 -   7.
  478.         Picture data, bit plane 0, scan line   2, columns   0 -   7.
  479.         Picture data, bit plane 0, scan line   3, columns   0 -   7.
  480.         . . .
  481.         Picture data, bit plane 0, scan line 199, columns   0 -   7.
  482.         Picture data, bit plane 0, scan line   1, columns   8 -  15.
  483.         Picture data, bit plane 0, scan line   2, columns   8 -  15.
  484.         . . .
  485.         Picture data, bit plane 0, scan line 199, columns 312 - 319.
  486.         Picture data, bit plane 1, scan line   1, columns   0 -   7.
  487.         . . .
  488.         Picture data, bit plane 3, scan line 198, columns 312 - 319
  489.         Picture data, bit plane 3, scan line 199, columns 312 - 319.
  490.  
  491. A for loop to process that data would look like
  492.  
  493.         for (plane = 0; plane < 4; plane++)
  494.             for (x = 0; x < 320; x += 8)
  495.                 for (y = 1; y < 200; y++)
  496.                     for (x1 = 0; x1 < 8; x1++)
  497.                         image[y, x + x1] = ...
  498.  
  499. Color map compression:
  500.  
  501.    Color map compression is similar to *.SPC color map compression, but
  502. the map is compressed as a string of bits, rather than words.  There are
  503. 597 records (one for each palette). Each record is composed of a 14-bit
  504. header followed by a number of 9-bit palette entries.  The 14-bit header
  505. specifies which palette entries follow (1 = included, 0 = not included).
  506. The most significant bit of the header refers to palette entry 1, while
  507. the least significant bit refers to palette 14.  Palette entries 0 and 15
  508. are forced to black (zero).  Each palette entry is encoded as "rrrgggbbb".
  509.  
  510. The format of the palette is described above in the section on uncompressed
  511. Spectrum pictures (*.SPU).
  512.  
  513.  
  514. <Art Director>  *.ART (low resolution only)
  515.  
  516. 16000 words     picture data (screen memory)
  517. 16 words        palette
  518. 15 * 16 words   15 more palettes for animation
  519. -------------
  520. 32512 bytes     total
  521.  
  522.  
  523. <C.O.L.R. Object Editor Mural>        *.MUR (low resolution only)
  524.  
  525. 16000 words     picture data (screen memory)
  526.                 (palettes are stored in separate files)
  527. -----------
  528. 32000 bytes     total
  529.  
  530.  
  531. <Doodle>        *.DOO (high resolution only)
  532.  
  533. 16000 words     picture data (screen memory)
  534. -----------
  535. 32000 bytes     total
  536.  
  537.  
  538. <Cyber Paint Sequence>  *.SEQ (low resolution only)
  539.  
  540.    This format, while fairly complex, yields excellent compression of animated
  541. images while offering reasonably fast decompression times.
  542.  
  543. 1 word          magic number [$FEDB or $FEDC]
  544. 1 word          version number
  545. 1 long          number of frames
  546. 1 word          speed (high byte is vblanks per frame)
  547. 118 bytes       reserved
  548. ---------
  549. 128 bytes       total for .SEQ header
  550.  
  551. for each frame {
  552. 1 long          offset to data for this frame, in bytes [basically useless]
  553. }
  554.  
  555. for each frame {
  556. 1 word          type (ignored?)
  557. 1 word          resolution [always 0]
  558. 16 words        palette
  559. 12 bytes        filename [usually "        .   "]
  560. 1 word          color animation limits [not used]
  561. 1 word          color animation speed and direction [not used]
  562. 1 word          number of color steps [not used]
  563. 1 word          x offset for this frame [0 - 319]
  564. 1 word          y offset for this frame [0 - 199]
  565. 1 word          width of this frame, in pixels (may be 0, see below)
  566. 1 word          height of this frame, in pixels (may be 0, see below)
  567. 1 byte          operation [0 = copy, 1 = exclusive or]
  568. 1 byte          storage method [0 = uncompressed, 1 = compressed]
  569. 1 long          length of data in bytes (if the data is compressed, this
  570.                 will be the size of the compressed data BEFORE decompression)
  571. 60 bytes        reserved                
  572. --------
  573. 128 bytes       total for frame header
  574.  
  575. ? bytes         data
  576. }
  577.  
  578.    Frames are "delta-compressed," meaning that only the changes from one
  579. frame to the next are stored.  On the ST, .SEQ files are always full-screen
  580. low resolution animations, so the sequence resulting from expanding all the
  581. data will be n 320 by 200 pixel low resolution screens, where n is given in
  582. the .SEQ header.
  583.   
  584.    Since only the changes from frame to frame are stored, image data for a
  585. frame will rarely be 320x200 (except for the very first frame, which will 
  586. always be a full screen).  Instead what is stored is the smallest rectangular
  587. region on the screen that contains all the changes from the previous frame to
  588. the current frame.  The x offset and y offset in the frame header determine
  589. where the upper left corner of the "change box" lies, and the width and height
  590. specify the box's size.
  591.  
  592.    Additionally, each "change box" is stored in one of five ways.  For each
  593.    of these, the screen is assumed to have the full-screen image from the last
  594.    frame on it.
  595.    
  596.    o uncompressed copy:  The data for this frame is uncompressed image data,
  597.      and is simply copied onto the screen at position (x, y) specified
  598.      in the frame header.
  599.  
  600.    o uncompressed eor:  The data for this frame is exclusive or'ed with the
  601.      screen at position (x, y).
  602.  
  603.    o compressed copy:  The data for this frame must be decompressed (see 
  604.      below), and then copied onto the screen at position (x, y) specified
  605.      in the frame header.
  606.  
  607.    o compressed eor:  The data for this frame must be decompressed (see 
  608.      below), and then exclusive or'ed with the screen RAM at position (x, y).
  609.  
  610.    o null frame:  The width and/or height of this frame is 0, so this
  611.      frame is the same as the previous frame.
  612.    
  613.    Of the 5 methods above, the one that results in the smallest amount
  614.    of data being stored for a particular is used for that frame.
  615.   
  616. Compression Scheme:
  617.  
  618.    Compression is similar to that employed by Tiny, but is not quite as
  619. space-efficient.
  620.  
  621. Control word meanings:
  622.  
  623.         For a given control word, x:
  624.  
  625.         x < 0   Absolute value specifies the number of unique words to
  626.                 take from the data section (from 1 to 32767).
  627.         x > 0   Specifies the number of times to repeat the next word
  628.                 taken from the data section (from 1 to 32767).
  629.  
  630.         Note that a control word of 0 is possible but meaningless.
  631.  
  632. Format of expanded data:
  633.  
  634.    The expanded data is not simply screen memory bitmap data; instead the four
  635. bitplanes are separated, and the data within each bitplane is presented
  636. vertically instead of horizontally.  (This results in better compression.)
  637.  
  638.    To clarify, data for a full screen would appear in the following order:
  639.    
  640.    bitplane 0, word 0, scanline 0
  641.    bitplane 0, word 0, scanline 1
  642.    ...
  643.    bitplane 0, word 0, scanline 199
  644.    bitplane 0, word 1, scanline 0
  645.    bitplane 0, word 1, scanline 1
  646.    ...
  647.    bitplane 0, word 1, scanline 199
  648.    ... 
  649.    bitplane 0, word 79, scanline 199
  650.    bitplane 1, word 0, scanline 0
  651.    ... 
  652.    bitplane 3, word 79, scanline 199
  653.  
  654. Note however, that the data does not usually refer to an entire screen, but
  655. rather to the smaller "change box," whose size is given in the frame header.
  656.  
  657.  
  658. <Animatic Film> *.FLM (low resolution only)
  659.  
  660. 1 word          number of frames
  661. 16 words        palette
  662. 1 word          speed (0 - 99; value is 99 - # vblanks to delay between frames)
  663. 1 word          direction (0 = forwards, 1 = backwards)
  664. 1 word          end action (what to do after the last frame)
  665.                 0 = pause, then repeat from beginning
  666.                 1 = immediately repeat from beginning
  667.                 2 = reverse (change direction)
  668. 1 word          width of film in pixels
  669. 1 word          height of film in pixels
  670. 1 word          Animatic version number (major) [< 2]
  671. 1 word          Animatic version number (minor)
  672. 1 long          magic number 27182818 (hex)
  673. 3 longs         reserved for expansion (should be all zeros)
  674. --------
  675. 32 words        total for header
  676.  
  677. ? words         image data (words of screen memory) for each frame, in order
  678.  
  679.  
  680. <Animaster Sprite Bank> *.ASB (low resolution only)
  681.  
  682. 1 word          number of frames - 1
  683. 1 word          ?
  684. 1 byte          maximum width, in pixels
  685. 1 byte          maximum height, in pixels
  686. 16 words        palette
  687. --------
  688. 38 bytes        total for header
  689.  
  690. For each frame {
  691. 1 word          width of this frame (in pixels) - 1
  692. 1 word          height of this frame (in pixels) - 1
  693. 1 word          ? 
  694. ? words         image data (words of screen memory)
  695. }
  696.  
  697.  
  698. <STOS>  *.MBK
  699.  
  700. 9 words         ?
  701. 1 long          $19861987 (magic number?)
  702. 1 long          offset from this long to header for low resolution 
  703.                 parameter block (if past end of file, no low res frames)
  704. 1 long          offset from this long to header for med resolution 
  705.                 parameter block (if past end of file, no med res frames)
  706. 1 long          offset from this long to header for high resolution 
  707.                 parameter block (if past end of file, no high res frames)
  708. 1 word          number of low resolution frames
  709. 1 word          number of medium resolution frames
  710. 1 word          number of high resolution frames
  711.  
  712. For each frame {
  713. 1 long          offset to data (probably only used internally by STOS)
  714. 1 byte          width in words (multiply by 16 to get width in pixels)
  715. 1 byte          height in pixels
  716. 1 byte          X hotspot location
  717. 1 byte          Y hotspot location
  718. }
  719.  
  720. (The format implies other stuff could be here.)
  721.  
  722. 1 long          ["PALT" $50414C54]
  723. 16 words        palette
  724.  
  725. ?               words of data for each frame, in the order mentioned in the
  726.                 header.  Monoplanar mask data follows image data for each frame.
  727. ----------
  728. ? words         total
  729.  
  730.    The frames often seem to be in semi-random order, not necessarily in 
  731. the order they are to be animated. 
  732.  
  733.  
  734. <GEM Bit Image> *.IMG
  735.  
  736. 1 word          version number of image file [1]
  737. 1 word          length of header in words [usually 8]
  738. 1 word          number of color planes [1 for monochrome]
  739. 1 word          pattern length in bytes [1-8, usually 2 for screen images]
  740. 1 word          pixel width in microns (1/1000 mm, 25400 microns per inch)
  741. 1 word          pixel height in microns
  742. 1 word          line width in pixels
  743. 1 word          number of lines
  744. -------
  745. ? words         header length defined in 2nd word of header
  746.  
  747. ? bytes         data
  748.  
  749. NOTES:  If the image is a color image (planes > 1), the planes are stored
  750. separately starting with plane 0.  There is, however, no standard way of
  751. storing the color palette.  Some programs may save the palette in separate
  752. files, some may extend the header.  For this reason, you should never
  753. assume the header is 8 words long, always get the header length from the
  754. 2nd word of the header.  Also, the line width in the 7th word is the number
  755. of pixels in a line.  Since the data is encoded in byte-wide packets, the
  756. actual unpacked line width is always a multiple of 8, and may be 1-7 pixels
  757. longer than the length specified in the header.
  758.  
  759. For each byte x in the data section,
  760.  
  761.         x = 0           Pattern/scanline run.
  762.                         Read the next byte, n (unsigned).
  763.  
  764.                         If n > 0 then:
  765.                                 Read a number of bytes equal to the "pattern
  766.                                 length" word in the header.  Repeat this
  767.                                 pattern n times.
  768.  
  769.                         If n = 0 then:
  770.                                 Scanline run.  Data for the next scanline
  771.                                 is to be used multiple times.  Read the
  772.                                 following record:
  773.  
  774.                                 1 byte          flag byte [$FF]
  775.                                 1 byte          number of times to use
  776.                                                 next scanline data
  777.  
  778.                                 The data for the next scanline follows,
  779.                                 compressed normally.
  780.  
  781.         x = 80 (hex)    Uncompressed bit string.  The next byte
  782.                         determines the number of bytes to use
  783.                         literally.  The literal data bytes follow.
  784.  
  785.         otherwise       Solid run.  The value of x determines
  786.                         what to draw.  The high bit specifies whether
  787.                         the pixels are set or cleared.  A 1 indicates
  788.                         a byte-run using $FF, a 0 indicates a byte-run
  789.                         using $00.  The low 7 bits, taken as an unsigned
  790.                         quantity, specify the length of the run in bytes.
  791.  
  792.  
  793. <GEM Metafile>  *.GEM
  794.  
  795. Marcel Boom <mboom@mswe.dnet.ms.philips.nl> recently sent me this
  796. format description.  I have reproduced it here, largely unchanged.
  797.  
  798. The file consists out of a header and the data records. The header has
  799. the following format:
  800.  
  801. word mf_header:         should be -1, which indicates a metafile
  802. word mf_hlength:        The length of the header part (usually 24 words)
  803. word mf_version:        Version number (usually 101)
  804. word mf_ndcrcfl:        0: NDC coordinates, 2: Raster coordinates
  805. word mf_extends1:       Optional, minimal used x coordinate
  806. word mf_extends2:       Optional, minimal used y coordinate
  807. word mf_extends3:       Optional, maximal used x coordinate
  808. word mf_extends4:       Optional, maximal used y coordinate
  809. word mf_width:          Optional, page width in 0.1 mm
  810. word mf_height:         Optional, page height in 0.1 mm
  811. word mf_coords1:        Optional, coordinate system param 1
  812. word mf_coords2:        Optional, coordinate system param 2
  813. word mf_coords3:        Optional, coordinate system param 3
  814. word mf_coords4:        Optional, coordinate system param 4
  815. word mf_imgflag:        0: No images, 1 contains bit images
  816. word mf_reserved1:      reserved.
  817. .
  818. .
  819. word mf_reserved9:      reserved.
  820.  
  821. After the header follows the data records of the following format:
  822.  
  823. word 0:                 VDI command number
  824. word 1:                 n: Number of parameters for ptsin array
  825. word 2:                 m: Number of parameters for intin array
  826. word 3:                 Subopcode
  827. word 4 to 4+n:          ptsin array
  828. word 4+n to 4+n+m:      intin array
  829.  
  830. A VDI command number of -1 signals the end of file.
  831.  
  832. VDI command numbers:
  833.    5:   Escape functions:
  834.         Subopcode:
  835.                 1:      Inquire addressable character cells
  836.                 2:      Exit alpha mode
  837.                 3:      Enter alpha mode
  838.                 20:     Form advance
  839.                 21:     Output window
  840.                 22:     Clear display list
  841.                 23:     Output bit image file
  842.                 98:     Update metafile extents
  843.                 99:     Write metafile item
  844.                 100:    Change GEM VDI filename
  845.     6:  Polyline
  846.     7:  Polymarker
  847.     8:  Text
  848.     9:  Filled area
  849.     11: GDP:
  850.         subopcode:
  851.                 1:      Bar
  852.                 2:      Arc
  853.                 3:      Pie
  854.                 4:      Circle
  855.                 5:      Ellipse
  856.                 6:      Elliptical arc
  857.                 7:      Elliptical Pie
  858.                 8:      Rounded rectangle
  859.                 9:      Filled rounded rectangle
  860.                 10:     Jutified graphic text
  861.     12: Set character height, absolute mode
  862.     13: Set character baseline vector
  863.     14: Set color representation
  864.     15: Set polyline linetype
  865.     16: Set polyline line width
  866.     17: Set polyline color index
  867.     18: Set polymarker type
  868.     19: Set polymarker height
  869.     20: Set polymarker color index
  870.     21: Set text face
  871.     22: Set graphic text color index
  872.     23: Set fill interior style
  873.     24: Set fill style index
  874.     25: Set fill color index
  875.     26: Inquire color representation    
  876.     32: Set writing mode
  877.     35: Inquire current polyline attributes
  878.     36: Inquire current polymarker attributes
  879.     37: Inquire current fill area attributes
  880.     38: Inquire current graphic text attributes
  881.     39: Set graphic text allignment
  882.     102: Extended inquire function
  883.     103: Countour fill
  884.     104: Set fill perimeter visibility
  885.     106: Set graphic text special effects
  886.     107: Set character cell height, points mode
  887.     108: Set polyline end styles
  888.     112: Set user defines fill pattern
  889.     113: Set user defined line style pattern
  890.     114: Fill rectangle
  891.     117: Inquire character cell width
  892.     129: Set clipping rectangle
  893.     131: Inquire current face information
  894.  
  895. The meaning of the arrays can be found in the several GEM programming books. 
  896.  
  897. NOTE: The word qualifier is not the Motorola word, but the Intel word,
  898. so high and low byte are swapped!
  899.  
  900.  
  901. <STAD>          *.PAC (high resolution only)
  902.  
  903. 4 bytes         "pM86" (vertically packed) or "pM85" (horizontally packed)
  904. 1 byte          id byte
  905. 1 byte          pack byte (most frequently occuring byte in bitmap)
  906. 1 byte          "special" byte
  907. -------
  908. 7 bytes         total for header
  909.  
  910. ? bytes         data
  911.  
  912. The data is encoded as follows.  For each byte x in the data section:
  913.  
  914.         x = id byte             Read one more byte, n.  Use pack byte 
  915.                                 n + 1 times.
  916.         x = "special" byte      Read two more bytes, d, and n (in order).
  917.                                 Use byte d n times.
  918.         otherwise               Use byte x literally.
  919.  
  920.  
  921. <Imagic Film/Picture>           *.IC1 (low resolution)
  922.                                 *.IC2 (medium resolution)
  923.                                 *.IC3 (high resolution)
  924.  
  925. 4 bytes         "IMDC"
  926. 1 word          resolution (0 = low res, 1 = medium res, 2 = high res)
  927. 16 words        palette
  928. 1 word          date (GEMDOS format)
  929. 1 word          time (GEMDOS format)
  930. 8 bytes         name of base picture file (for delta compression), or zeroes
  931. 1 word          length of data (?)
  932. 1 long          registration number
  933. 8 bytes         reserved
  934. 1 byte          compressed? (0 = no, 1 = yes)
  935.  
  936. If compressed {
  937. 1 byte          delta-compressed? (-1 = no, > -1 = yes)
  938. 1 byte          ?
  939. 1 byte          escape byte
  940. }
  941. -------
  942. 65 bytes        total for header (68 bytes if compressed)
  943.  
  944. ? bytes         data
  945.  
  946.    Compressed data may be either stand-alone or delta-compressed (relative
  947. to the base picture named in the header).  Delta compression involves
  948. storing only how the picture differs from the base picture (i.e., only
  949. portions of the screen that have changed are stored).  This is used to
  950. to encode animated sequences efficiently.
  951.  
  952. Compressed data, stand-alone:
  953.  
  954. For each byte x in the data section:
  955.  
  956.         x = escape byte         Read one more byte, n.  (n is unsigned).
  957.  
  958.                                 If n >= 2, use the next byte n times.
  959.                                 If n = 1, keep reading bytes until a
  960.                                 byte k not equal to 1 is encountered.
  961.                                 Then read the next byte d.
  962.                                 If the number of 1 bytes encountered is o,
  963.                                 use d (256 * o + k) times.  I.e.,
  964.  
  965.                                 if (n == 1) {
  966.                                         o = 0;
  967.                                         while (n == 1) {
  968.                                                 o++;
  969.                                                 n = next byte;
  970.                                         }
  971.  
  972.                                         k = n;
  973.                                         d = next byte;
  974.  
  975.                                         Use d (256 * o + k) times.
  976.                                 }
  977.                                 else {
  978.                                         d = next byte;
  979.                                         Use d (n) times.
  980.                                 }
  981.  
  982.         x != escape byte        Use x literally.
  983.  
  984. Compressed data, delta compressed:
  985.  
  986. For each byte x in the data section:
  987.  
  988.         x = escape byte         Read one more byte, n.  (n is unsigned).
  989.  
  990.                                 If n >= 3, use the next byte n times.
  991.                                 If n = 1, do the same as for n = 1 in
  992.                                 stand-alone compression (above).
  993.                                 If n = 2, then set n = next byte.
  994.                                         If n = 0, end of picture.
  995.                                         If n >= 2, take n bytes from base
  996.                                         picture.
  997.                                         If n = 1, do the same as for n = 1
  998.                                         in stand-alone compression (above),
  999.                                         but take (256 * o + k) bytes from 
  1000.                                         base picture.
  1001.  
  1002.         x != escape byte        Use x literally.
  1003.  
  1004.  
  1005. <IFF Format>    *.IFF
  1006.  
  1007. 4 bytes         "FORM" (FORM chunk ID)
  1008. 1 long          length of file that follows
  1009. 4 bytes         "ILBM" (InterLeaved BitMap file ID)
  1010.  
  1011. 4 bytes         "BMHD" (BitMap HeaDer chunk ID)
  1012. 1 long          length of chunk [20]
  1013. 20 bytes        1 word = image width in pixels
  1014.                 1 word = image height in lines
  1015.                 1 word = image x-offset [usually 0]
  1016.                 1 word = image y-offset [usually 0]
  1017.                 1 byte = # bitplanes
  1018.                 1 byte = mask (0=no, 1=impl., 2=transparent, 3=lasso)
  1019.                 1 byte = compressed [1] or uncompressed [0]
  1020.                 1 byte = unused [0]
  1021.                 1 word = transparent color (for mask=2)
  1022.                 1 byte = x-aspect [5=640x200, 10=320x200/640x400, 20=320x400]
  1023.                 1 byte = y-aspect [11]
  1024.                 1 word = page width (usually the same as image width)
  1025.                 1 word = page height (usually the same as image height)
  1026.  
  1027. 4 bytes         "CMAP" (ColorMAP chunk ID)
  1028. 1 long          length of chunk [3*n where n is the # colors]
  1029. 3n bytes        3 bytes per RGB color.  Each color value is a byte
  1030.                 and the actual color value is left-justified in the
  1031.                 byte such that the most significant bit of the value
  1032.                 is the MSB of the byte.  (ie. a color value of 15 ($0F)
  1033.                 is stored as $F0)  The bytes are stored in R,G,B order.
  1034.  
  1035. 4 bytes         "CRNG" (Color RaNGe chunk ID)
  1036. 1 long          length of chunk [8]
  1037. 8 bytes         1 word = reserved [0]
  1038.                 1 word = animation speed (16384 = 60 steps per second)
  1039.                 1 word = active [1] or inactive [0]
  1040.                 1 byte = left/lower color animation limit
  1041.                 1 byte = right/upper color animation limit
  1042.  
  1043. 4 bytes         "CAMG" (Commodore AMiGa viewport mode chunk ID)
  1044. 1 long          length of chunk [4]
  1045. 1 long          viewport mode bits (bit 11 = HAM, bit 3 = interlaced)
  1046.  
  1047. 4 bytes         "BODY" (BODY chunk ID)
  1048. 1 long          length of chunk [# bytes of image data that follow]
  1049. ? bytes         actual image data
  1050.  
  1051. NOTES: Some of these chunks may not be present in every IFF file, and may
  1052. not be in this order.  You should always look for the ID bytes to find a
  1053. certain chunk.  All chunk IDs are followed by a long value that tells the
  1054. size of the chunk (note that "ILBM" is not a chunk ID).  This is the number of
  1055. bytes that FOLLOW the 4 ID bytes and size longword.  The exception to this is
  1056. the FORM chunk.  The size longword that follows the FORM ID is the size of the
  1057. remainder of the file.  The FORM chunk must always be the first chunk in an
  1058. IFF file.
  1059.  
  1060. The R,G,B ranges of AMIGA and ST are different (AMIGA 0...15, ST 0...7),
  1061. as is the maximum number of bitplanes (AMIGA: 5, ST: 4).
  1062.  
  1063. Format of body data
  1064.  
  1065. An expanded picture is simply a bitmap.  The packing method is PackBits
  1066. (see below), and is identical to MacPaint and DEGAS Elite compressed.
  1067.  
  1068. The (decompressed) body data appears in the following order:
  1069.  
  1070.         line 1 plane 0 ... line 1 plane 1 ... ... line 1 plane m
  1071.         [line 1 mask (if appropriate)]
  1072.         line 2 plane 0 ... line 2 plane 1 ... ... line 2 plane m
  1073.         [line 2 mask (if appropriate)]
  1074.         ...
  1075.         line x plane 0 ... line x plane 1 ... ... line x plane m
  1076.         [line x mask (if appropriate)]
  1077.  
  1078. The FORM chunk identifies the type of data:
  1079.  
  1080.         "ILBM" = interleaved bit map
  1081.         "8SVX" = 8-bit sample voice
  1082.         "SMUS" = simple music score
  1083.         "FTXT" = formatted text (Amiga)
  1084.  
  1085.  
  1086. <MacPaint>      *.MAC
  1087.  
  1088. 1 long          version number [0=ignore header, 2=header valid]
  1089. 38 * 8 bytes    8x8 brush/fill patterns.  Each byte is a pattern row,
  1090.                 and the bytes map the pattern rows top to bottom.  The
  1091.                 patterns are stored in the order they appear at the bottom
  1092.                 of the MacPaint screen top to bottom, left to right.
  1093. 204 bytes       unused
  1094. -------------
  1095. 512 bytes       total for header
  1096.  
  1097. < 51200 bytes   compressed bitmap data
  1098. -------------
  1099. < 51712 bytes   total
  1100.  
  1101. NOTE:  The version number is actually a flag to MacPaint to indicate if
  1102. the brush/fill patterns are present in the file.  If the version is 0,
  1103. the default patterns are used.  Therefore you can simply save a MacPaint
  1104. file by writing a blank header (512 $00 bytes), followed by the packed
  1105. image data.
  1106.  
  1107. Bitmap compression:
  1108.  
  1109.    The bitmap data is for a 576 pixel by 720 pixel monochrome image.
  1110. The packing method is PackBits (see below).  There are 72 bytes per
  1111. scan line.  Each bit represents one pixel; 0 = white, 1 = black.
  1112.  
  1113.  
  1114. <RGB Intermediate Format>       *.RGB (low resolution only)
  1115.  
  1116.    This format was invented by Lars Michael to facilitate conversions between
  1117. standard ST picture formats and higher resolution formats like GIF and IFF.
  1118. It supports 12 bits of color resolution by keeping the red, green and blue
  1119. components in separate bit planes.
  1120.  
  1121. 1 word          resolution (ignored)
  1122. 16 word         palette (ignored)
  1123. 16000 words     red plane (screen memory)
  1124. 1 word          resolution (ignored)
  1125. 16 word         palette (ignored)
  1126. 16000 words     green plane (screen memory)
  1127. 1 word          resolution (ignored)
  1128. 16 word         palette (ignored)
  1129. 16000 words     blue plane (screen memory)
  1130. ------------
  1131. 96102 bytes     total
  1132.  
  1133. The format was derived by concatenating three DEGAS .PI1 files together -- 
  1134. one for each color gun.  The RGB value for a pixel is constructed by looking
  1135. at the appropriate pixel in the red plane, green plane, and blue plane.  The
  1136. bitplanes are in standard ST low resolution screen RAM format, but where pixel
  1137. values in screen RAM refer to palette entries (0 through 15), pixel values
  1138. here correspond to absolute R, G, and B values.  The red, green, and blue
  1139. components for each pixel range from 0 to 15 (4 bits), yielding a total of
  1140. 12 bits of color information per pixel.  Not coincidentally, this is exactly
  1141. the format of ST palette entries (although on ST's without the extended 
  1142. palette only the lower 3 bits of each color component are used).
  1143.  
  1144. You can view a single bit plane on a standard ST by splitting the .RGB file
  1145. into its three DEGAS .PI1 components and setting the palette to successively
  1146. brighter shades of gray.
  1147.  
  1148.  
  1149. <ComputerEyes Raw Data Format>  *.CE1 (low resolution)
  1150.                                 *.CE2 (medium resolution)
  1151.                                 
  1152. 1 long          [$45594553 or "EYES"]
  1153. 1 word          resolution [0 = low res, 1 = medium res]
  1154. 8 words         ?
  1155. If resolution = 0 {
  1156. 64000 bytes     red plane, 320 x 200, 1 pixel per byte
  1157. 64000 bytes     green plane, 320 x 200, 1 pixel per byte
  1158. 64000 bytes     blue plane, 320 x 200, 1 pixel per byte
  1159. ------------
  1160. 192022 bytes    total
  1161. } 
  1162. else If resolution = 1 {
  1163. 128000 words    640 x 200, 1 pixel per word
  1164. ------------
  1165. 256022 bytes    total
  1166. }
  1167.  
  1168.    This is almost two formats in one:
  1169.    
  1170.         Low resolution:
  1171.  
  1172.            The planes are arranged vertically, instead of horizontally.
  1173.         The first byte is the red component of pixel (0,0), the second is (0,1),
  1174.         and the third (0,2).  The 201st corresponds to (1,0), etc.  The 64001st
  1175.         byte is the green component of (0,0).
  1176.            Only the low six bits of each byte are used.
  1177.  
  1178.         Medium resolution:
  1179.  
  1180.            The picture is arranged vertically, instead of horizontally.
  1181.         The first word is pixel (0,0), the second is (0,1), and the third
  1182.         (0,2).  The 200th is (1,0) etc.
  1183.            Each word is divided up into the RGB values for the corresponding
  1184.         pixel, as follows:
  1185.  
  1186.           Bit:  (MSB) 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00 (LSB)
  1187.                       -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
  1188.                        0 B4 B3 B2 B1 B0 G4 G3 G2 G1 G0 R4 R3 R2 R1 R0
  1189.  
  1190.         Bit 15 is not used.
  1191.  
  1192.  
  1193. <PackBits Compression Algorithm>
  1194.  
  1195. The following packing algorithm originated on the Mac, was adopted by
  1196. Electronic Arts/Commodore for use in the IFF standard, and then by Tom
  1197. Hudson for use in DEGAS Elite.  The algorithm is currently used in
  1198. MacPaint, IFF, and DEGAS Elite compressed file formats.  Each scan line
  1199. is packed separately, and packing never extends beyond a scan line.
  1200.  
  1201. For a given control byte 'n':
  1202.     0 <= n <= 127   : use the next n + 1 bytes literally (no repetition).
  1203.  -127 <= n <= -1    : use the next byte -n + 1 times.
  1204.          n = -128   : no operation, not used.
  1205.  
  1206. -------------------------------------------------------------------------
  1207.  
  1208. * Roland Waldi contributed extensive information on the following formats:
  1209.  
  1210.         GEM, IMG, Doodle, STAD, Imagic Film/Picture, Art Director, IFF
  1211.  
  1212. ** John Brochu, ST picture formats guru, provided sage advice and many
  1213.    corrections to the following formats:
  1214.  
  1215.         NeoChrome, DEGAS Elite Compressed, Spectrum 512 Compressed,
  1216.         GEM Bit Image, IFF, MacPaint
  1217.  
  1218. Version of...........Wed Mar 31 12:17:26 EST 1993
  1219. (Last change: GEM format decription added)
  1220. __
  1221. dmb@ai.mit.edu            Natural Language Processing            MIT AI Lab                                                                                  
  1222. ADVENTIONS: We make Kuul text adventures!  Ask about Unnkulian 1, 2, 0, 1/2
  1223.   PO Box 851 Columbia, MD 21044 USA / CIS: 76440,2671 / GEnie: ADVENTIONS
  1224.  
  1225.  
  1226.