

                   THE IMG AND IFF ILBM PICTURE FILE FORMATS
                    (plus the EDT sprite file of Art Studio)
                              BY: Mrten Lindstrm
                   -----------------------------------------

     As a small addition to  Dave  Baggett's  file on picture formats, here
     are some bits that were missing,  some  of  which I have found through
     investigations of my own, and  some  of  which  I owe to other sources
     (mainly articles in old ST World and German ST Magazine):

       1)    Fuller  descriptions  of  the  two   general  -  not  hardware
             dependent - picture formats presented  in Baggett's file, i.e.
             IMG and  IFF  ILBM  (and  of  the  general  IFF  system). This
             includes colour IMG  files  (XIMG,  True  and  High colour and
             HyperPaint), some more chunk types  that  could be found in an
             IFF (ILBM) file, and what  I've  found  out about the IFF ILBM
             compression type 2 of Deluxe Paint.
       2)    The Art Studio EDT sprite file, for anyone interested.

     I have not got the Commodore  IFF  DOCUMENTS file referred to in Guido
     van Rossum's file (sound.txt in ICTARI  4).  If anyone has, I would be
     very interested to see it.

                  WHAT PICTURE FORMAT IS THE 'ATARI STANDARD'?
                  --------------------------------------------

     Anyone wading through the  plethora  of  ST  picture formats listed in
     Dave Baggett's file,  must  feel  impressed  or  even  dismayed by the
     useless multitude. And be depressed by the fact that of these the only
     truly 'device independent' format,  usable  with screen dimensions and
     colour ranges outside the standard ST  ones,  is the IFF ILBM, defined
     by Commodore and Electronic Arts 1985.

     Closely hardware dependent file formats can  be quite useful as simple
     to program screen dumps (basic  Degas),  or  for instant show, without
     any data conversion, of full  colour  pictures  on  the ST screen (the
     clever Spectrum 512).

     But you don't need a TT or  Falcon  to have sometimes wished there was
     an agreed system  on  how  to  store  larger  than  screen (scrolling)
     pictures or smaller  than  screen  blocks,  or  emulated extra colours
     (shown on screen as two-colour patterns for instance).

     The apparent reason for the existing  mess  seems  to be that IMG, the
     otherwise natural picture standard for  the Atari GEM environment, was
     for a long  time  poorly  or  even  incorrectly  documented by Digital
     Research (the makers of GEM) and  in addition lacked adequate rules on
     how to deal with colour which  left able programmers without organised
     support and guidance, to define their own formats.

     Tom Hudson, the very man who  defined Degas, soon realised the problem
     and made  an  admirable  effort  to  replace  the  growing  jungle  of
     inadequate ST picture formats with  IFF  (Note  that Degas Elite could
     handle IFF images long before  any  other  ST paint program could) but
     sadly he succumbed to the dark forces of picture Chaos.

     Later Dimitri Koveos, who wrote the Atari registered HyperPaint, tried
     to re-establish IMG as the Atari  picture  standard and designed a way
     to store a colour palette with his IMG files (which he published in ST
     World). But he made the serious  mistake  of  - like Degas - using the
     hardware format for the colours of  the  palette (which means that the
     HyperPaint format is unusable with Falcon pictures for example).


     There now - a bit late - DOES  seem to exist a standard for colour IMG
     files, as anyone with the Atari  Compendium will have noticed, capable
     of dealing with ANY bitmapped image including all Falcon screens (just
     like the IFF system could already do almost a decade ago). The palette
     colours are now stored  in  GEM  VDI  format  as  was  always the only
     logical solution considering that the  IMG  format  was supposed to be
     part of GEM.


     So what picture file format should be chosen by anyone now writing his
     own image handling ST program, who  needs  a more flexible format than
     Degas/NEO?

     Below are descriptions of IMG and  IFF  ILBM. I don't however know the
     PC formats GIF or TIFF  (yet,  but  am  expecting to get some material
     here soon), and maybe these are the ones  to adopt on the ST as every-
     thing is revolving more and more around  the PC? Any views (and infor-
     mation) are welcome.

     And here are the  file  descriptions,  beginning  with  the EDT sprite
     file:-

                         EDT sprite files of Art Studio
                         ------------------------------

     16 words        Hardware palette
     1 byte          Colour cycling: 1st nybble =  start,  2nd nybble = end
                     colour.
     1 byte          Colour cycling: Period (in VBLs I think) between moves
                     (left to right). Negative: reverse direction. 0: Off.
     1 word          Sprite size (0-7):
                     0:  8x8   1: 16x16  2: 16x32  3: 32x16
                     4: 32x32  5: 32x64  6: 64x32  7: 64x64  (WxH)
     1 word          Animation: # of start sprite (First sprite = 0)
     1 word          Animation: # of end sprite
     1 word          Animation: Period (in VBLs?) between frames
     1 word          Animation: ? (Appears to  take  values   between 0 and
                     Period. Perhaps just a counter?)
     1 word          ? (Has always been zero in my tests)
     1 word          Output: "Output byte" (31 default)
     1 word          Output: 0:File 1:RS232
     1 word          Output: Number of lines/sprite
     1 word          Output: 0:Lines 1:Words

     40960 bytes Data (E.g. 1024 8x8 sprites, 256 16x16 sprites
                     64 32x32 sprites or
                     16 64x64 sprites each with mask + 4 colour planes)
     ---------
     41014 bytes total

     Data are stored sprite by sprite, line  by line and, within each line,
     plane by plane. First comes the mask for a line and sprite, thereafter
     each of the four planes. Then the  mask  for  a new line of the sprite
     etc.

     Note that in the mask, empty  positions  are  marked with ones and the
     sprite is marked with zeroes. In  spite  of this, Art Studio zeroes in
     its entirety any 'empty' sprite slot in  the EDT file, where no sprite
     has been placed, thus actually  letting  it  represent a sprite filled
     with colour number zero.

                                   IMG files
                                   ---------
     ~~~~~~~~~~~ First eight words present in EVERY IMG file:
     1 word  IMG file version (usually 1)

     1 word  Header length IN WORDS. (Multiply by  2  and add to address of
             file start to determine where picture data start.)
     1 word  Number of colour planes (1=mono,2-8=palette,16=hi,24=true)
             (This word should also be possible  to  use, it struck me, for
             anyone wanting his program to cope with PC-imported IMG files.
             In these the first byte of the word should be non-zero and the
             second byte zero; in ST files  vice  versa. A PC file needs to
             have the bytes of  every  word  in  its header swapped, except
             anything to be read as  bytes  -  see  XIMG below. The picture
             byte data are identical on ST and PC.)
     1 word  Pattern length in bytes (usually 2)
     1 word  Source device pixel width (in principle in the unit m)
     1 word  Source device pixel height
             The unit is formally m (microns or micrometres i.e. thousands
             of millimetres). In reality however, these two values (usually
             taken from the VDI WORKOUT array)  seem to be implemented only
             as relative dimensions (to  be  compared  to each other only),
             except for ST high  res  where  the  pixel  size of 372x372 m
             given by the VDI can  be  accepted  in absolute terms as well.
             (For ST medium and low the  VDI values 169x372 and 338x372 are
             obviously way too small.)
     1 word  Line width in pixels
     1 word  Number of lines

     ~~~~~~~~~~~ Should be present for 2-8 planes (but don't count on it)
     4 bytes 'XIMG' in ascii
     1 word  Should be 0 for RGB colour format.
     3 words GEM RGB-components for 'colour 0'  (0-1000 in each word)
     3 words GEM RGB-components for 'colour 1' etc.
     ......  (Colours must be listed in 'hardware' order - see below.)
     ~~~~~~~~~~~ Header length determines where data start
     ? bytes picture data

                                ----------------

     XIMG is (or so  I  would  like  to  believe)  the standard that anyone
     should now use when creating  colour  IMG  pictures  of his own. But a
     program could also come across  IMG  pictures  with 2-8 planes without
     the XIMG header  extension.  You  might  then,  if  you  are a zealous
     person, want your program to check for a HyperPaint hardware palette:

     ~~~~~~~~~~~ After the first 8 header words
     1 word     $80 (hexadecimal = 128 in decimal) HyperPaint flag
     16 words   (for 4 planes) Hardware palette data: 1 word per colour
     ~~~~~~~~~~~ Also check header length (=25 for 4-plane HyperPaint IMG)

     The Atari Compendium mentions  a  colour  IMG  format called 'STTT'. I
     assume this is the HyperPaint format, but since the Compendium seems -
     understandably perhaps - to be  very  reluctant  to go any deeper into
     the subject  of  alternatives  to  the  one  hardware  independent IMG
     standard, XIMG, I don't know. (Perhaps anyone else does?)

     If you can't find any  (recognizable)  palette  data, and there are no
     external means to  determine  colours  you  may  possibly,  as  a last
     resort, use the standard palette (the  one that goes 'hardware' colour
     0=White, 1=Red - except if last colour when black, 2=Green, 3=Yellow -
     except if last colour when black,  4=Blue, 5=Magenta, 6=Cyan, 7= Light
     Gray, 8=Dark gray,  9=Light  Red,  10=L.Green, 11=L.Yellow, 12=L.Blue,
     13=L.Magenta, 14=L.Cyan  15=Black).  This  seems  to  be  how  Digital
     Research had intended multi colour pictures to work in those days when
     GEM and IMG were  conceived,  with  old  fixed  palette PC machines in
     mind.
                                ----------------

     When the  number  of  colour  planes  is  16  (High  Colour,  by Atari
     misleadingly called true colour) or 24  (True Colour) any extra header
     data can be ignored. There should  be  no palette. Data will be stored
     in planes as usual, with each  plane  containing  one RGB bit (of each
     pixel) in the order: RRRRR GGGGGG BBBBB (5R,6G,5B) for High Colour and
     RRRRRRRR GGGGGGGG BBBBBBBB (8R,8G,8B) for True Colour.

     Neither are any palette data needed with a 1 plane - i.e. monochrome -
     picture. In this case all ones  are  automatically assumed to be black
     and zeros white.

     Note that plane  numbers  9-15  aren't  really  defined  (in the Atari
     Compendium anyway). But should an IMG with  9,  12 or 15 planes and no
     XIMG palette appear, I think  it  would  be  natural  to consider it a
     direct colour RGB picture analogue to the High and True Colour ones. A
     Spectrum 512 picture could thus be translated into an IMG with 9 or 12
     RGB planes, depending on whether the extended 4096 colour range of the
     STE is used or not.

                                ----------------

     IMG picture data are stored a line at  a time and, within each line, a
     plane at a time. Each  line  (and  plane)  is  padded to the next byte
     boundary, and is stored as  a  series  of  commands (none of which can
     span over a line/plane boundary):

     BYTE 1  BYTE 2  BYTE 3  BYTE 4
       00      00     $FF      #     Precedes line to repeat  # times (Thus
                                     occurs only at line starts).
       00      #    pattern  pattern Pattern to repeat # times (Bytes per
                                     pattern given in file header).
      $80      #                     Precedes # bytes to use as they are.
       00+#                          # zero-bytes to write (# = 1-127).
      $80+#                          # $FF-bytes to write (# = 1-127).

                (All numbers unsigned; $ stands for hexadecimal)

                       The order of XIMG palette colours
                       ---------------------------------

     As everybody knows, the ST built  in  VDI has a weird colour numbering
     system of its own. (I don't  know  why. Does anyone?) Which raises the
     question of the colour order.

        .--------------------------------------------------------------.
        | NOTE: Although the XIMG palette is made up from VDI colours, |
        | these have to appear in the 'hardware' order!!!              |
        '--------------------------------------------------------------'

     This is NOT mentioned in the Atari  Compendium, but if the XIMG format
     is to be at all 'device  independent'  the colour index numbers of the
     palette have got to correspond to the bit plane data of the image. And
     since VDI image  transformation  with  VR_TRNFM,  contrary  to what is
     stated in the Compendium, DOES  NOT  translate colour numbers, it must
     be reasonable to expect a program to do this translation itself, if it
     is to use VS_COLOR to set colours.

     Note that you cannot use a  fixed  translation  table if you want your
     program to work with graphic  cards  for  instance.  (I know there are
     cards with VDI colours = hardware colours.)

     The 100% compatible way of  handling  colours,  is to let your program
     create an 'on the fly' translation table from hardware to VDI colours.
     For this the VDI function V_GET_PIXEL can be used, since - as given in
     the Compendium - it  returns  two  values  the  first  of which is the
     'hardware' (or as I would like to  call it 'bit plane related') colour
     number, and the second  is  the  VDI  colour  number  for the examined
     pixel.

     Assuming both marker type and write  mode  are = 1 (the normal value),
     the routine to do this would look like:

       1)    Set VDI colour number for markers with VSM_COLOR
       2)    Write pixel (0,0) with V_PMARKER
       3)    Read pixel (0,0) with  V_GET_PIXEL  and  use  the first return
             value (the bitplane related colour)  as  an index in the table
             to enter the VDI colour.
       4)    Go back to 1) and do next VDI colour.

     (Of course, you should  restore  the  original  colour  of pixel (0,0)
     afterwards).

     Again, the conclusion that the 'bitplane'  -  rather than VDI - colour
     order must always be used in  any  palette,  whether GEM or not, is my
     own. If anyone knows differently, I would be interested to hear it (in
     which case XIMG would be unusable as I see it).

                             Using XIMG without GEM
                             ----------------------

     The (less compatible) alternative is to  not  use VS_COLOR at all, but
     to set the palette with some XBIOS  function. This is what you have to
     do anyway if you don't use GEM.

     You can then use the colours in the order given, but need to translate
     between hardware and GEM  colour  intensities.  For  which I think the
     following formulas will serve well:

     VDI -> hardware:
                      (Max hard intensity + 1) * VDI intensity
     Hard intensity = ----------------------------------------  truncated
                                    1001

     Hardware -> VDI:
                             1000 * hardware intensity
     VDI intensity  =        --------------------------   truncated
                               max hardware intensity

     E.g. for STFM, STE/TT, Falcon and 24-bit ("TRUE") respectively:
             STFM hard = VDI*8/1001  VDI =    STFM*1000/7
             STE hard = VDI*16/1001  VDI =    STE*1000/15
             Falcon =   VDI*64/1001  VDI = Falcon*1000/63
             TRUE  =   VDI*256/1001  VDI =  TRUE*1000/255

     The second formula (hard->VDI) corresponds to how it's done by the VDI
     (of TOS 1.4 on an STF).  The  first  one doesn't, but it's simpler and
     works just as well with the  second  one (translations hardware -> VDI
     and back will return to same  values).  In addition it even happens to
     be more logical, I think, since it maps approximately equal numbers of
     possible VDI levels onto each of  the  hardware  ones. (The VDI uses a
     'closest match' method that approaches the  extreme values - 0 and max
     - only half as often as other values.)

                   The general IFF (Interchange File Format)
                   -----------------------------------------

     Every IFF file consists of a single "FORM chunk" which contains a type
     ID and a number of subordinate  chunks.  Most often these will only be
     so called "local" chunks with the  hard  data,  but a general FORM can
     also contain subordinate FORMs (or other structural chunks) with their
     own subordinates. (For instance a slideshow  FORM  could be made up of
     many picture FORMs and possibly sound FORMs.)

     Note that wherever a chunk ends on  an odd address, a zero fillbyte is
     added, to make sure that every chunk starts on an even address.

                                The IFF picture
                                ---------------

     For pictures, the FORM type is  "ILBM"  and the subordinate chunks may
     be as few as three: "BMHD"  with  general information, "CMAP" with the
     palette and "BODY" with the picture data.

     4 bytes "FORM" -  identifies  the  parent  FORM  chunk.  (A  file that
             doesn't start with these four letter isn't an IFF file)
     1 long  length of chunk (= of file minus 8 byte chunk header)

     4 bytes "ILBM" = the FORM type (InterLeaved BitMap i.e. a picture)
             (Not all IFF files  are  pictures;  those  of  type "8SVX" are
             samples, type "FTXT" means formatted text etc.)

     4 bytes "BMHD" - BitMap HeaDer chunk
     1 long  length of chunk [20]
     20 bytes        1 word  image width in pixels
                     1 word  image height in pixel lines
                     1 word  x-offset on screen (for a sprite or brush)
                     1 word  y-offset on screen        - " -
                     1 byte  number of colour planes
                     1 byte  mask  (0=no,   1=yes,   2=transparent  colour,
                             3=lasso) Interesting  only  for  sprite/brush,
                             except that if mask=1  you  will  have to take
                             into account (skip) an  extra  "plane" of mask
                             data when reading the image.
                     1 byte  compression type  (0, 1 or 2 - See below)
                     1 byte  unused [0]
                     1 word  transparent colour number (for mask=2)
                     1 byte  x-aspect (usually 10 for ST low;  5 for med)
                     1 byte  y-aspect (usually 11 for ST low or med)
                             x-  and  y-aspects   together   form  a  ratio
                             describing  the  "pixel   shape"  of  original
                             screen. (1/1 for perfect squares)
                     1 word  "page" (=original screen)  width  [320  for ST
                             low]
                     1 word  page height [200 for  ST  low] (Note that page
                             dimensions are  totally  unrelated  to  actual
                             picture size! They just  give  the size of the
                             screen where  the  picture  was  created,  for
                             anyone interested)

     4 bytes "CMAP" - ColourMAP chunk
     1 long  length of chunk [3*n where n is the number of colours]
     3n bytes        the palette - 3 bytes per  colour: red, green, blue  8
                     bit  colour  components  (0-255).  Note  that  when  a
                     computer uses less than  8  bit colour resolution (the
                     STFM uses 3, STE/TT 4, Falcon  6) these will always be
                     the "leftmost" (most significant)  bits  of each byte.
                     (To use CMAP colours on  an  STFM  shift right 5 bits,
                     i.e. divide by 32.)

     4 bytes "BODY" - BODY chunk
     1 long  length of chunk
     ? bytes image data (at last!)

     This 'completes the picture'.


     Unfortunately I don't know how to store a 16-bit High Colour or 24-bit
     True Colour image as an IFF ILBM  picture.  It  may be as simple as to
     just state 16 or 24 for number of planes, leave out a palette and then
     store data as usual as RGB bit  planes, analogically to how it is done
     in IMG files (see above). But  I  don't  know this. Maybe someone else
     does?

                          The compression of BODY data
                          ----------------------------

     COMPRESSION TYPE 0 AND  1:  (uncompressed  and  Byterun) have the data
     stored in order:
             line 0 { in order plane 0, plane 1  ... (mask) }
             line 1 { ditto }
             ...
     NOTE: Not even when  uncompressed  are  the  colour planes stored word
     interleaved as in ST screen memory.

     Compression 1 is the same as in  DEGAS.PC?,  i.e. data are stored as a
     series of commands each lead by a signed control byte:
             x >= 0:    use next x+1 bytes as they are (1-128).
             x < 0      repeat the one next byte |x|+1 times (2-128).
             x = -128   not used.
     No command may extend over more than one plane and line.


     COMPRESSION TYPE 2: - as I found  it  to work in (the demo version of)
     Deluxe Paint - is a vertical  word compression algorithm, very similar
     to the one used in  the  TINY  format,  where  each plane is done word
     column by word column, rather than line  by line, and is completed for
     the full picture before starting with the next plane.

     Decompressed word sequences CAN extend over  more than one column (but
     not more than one plane).

     The data of the BODY chunk are split into as many "VDAT" sub-chunks as
     there are planes (+ plus an ending one for any mask) - beginning right
     after the 8  byte  BODY  chunk  header.  Each  VDAT  sub-chunk has the
     following format:

     4 bytes         "VDAT" (Presumably stands for "Vertical DATa")
     1 long          length of chunk
     1 word          offset to word data (Add to the address of this word).
     ? bytes         control bytes
     ? words         data words

     And the control byte meanings are:

     x<0     Use next |x| data words as they are (1-128).
     x=0     Next data word is the number of following words to use as they
             are (1-65536, ie any 0 interpreted as $10000 =65536).
     x=1     Next data word is the number  of times to repeat the following
             data word (1-65536).
     x>1     Repeat next data word x times (2-127).

     The (colour plane of the) picture is  built  up in word (i.e. 16 pixel
     wide) columns, top to bottom  and  left  to  right.  Note that the de-
     compression routine has to keep track of when to change columns (using
     the image height got from the BMHD header), and that this can occur in
     the middle of a  command.  (In  fact  a  complete  blank screen can be
     compressed into one single command - per plane that is - consisting of
     only one control byte = 1, one  count  word  and one data word to fill
     with.)

                         Extensions to the ILBM format
                         -----------------------------

     In addition to the basic chunks already  mentioned, you may in an ILBM
     picture come across a number of  extra chunks, needed only for special
     purposes. When reading an IFF file, you  should make it a habit always
     to look for the IDs of the chunks you need, and never to assume that a
     chunk will start at a certain position in the file.

     (The order in which the basic  chunks  of  the  ILBM FORM appear is in
     fact standard, but special extra chunks  can  be inserted in any order
     between the CMAP and BODY chunks.)

     When reading the chunk  formats  below,  remember  that EVERY chunk is
     preceded by an eight byte header  -  first  the four-byte ID, and then
     always - as a longword - the length of the chunk (Use this, rounded up
     to next even address, to find the next chunk).

     Colour cycling (more than one chunk can be used in one picture):
     ----------------------------------------------------------------
     "CRNG" (eight bytes)
      W:     reserved [0].
      W:     rate. A rate of  $1000  (=  4096  in  decimal) means 15 colour
             moves per second (or  4  screen  VBLs  per  move if the screen
             frequency is 60 Hz).  $2000  means  30 moves/sec (2 VBLs/move)
             etc. The move is 'from left to right' (lower colour numbers to
             higher), except if the rate  is  negative which should reverse
             the direction, although  (the  demo  version  of) Deluxe Paint
             doesn't seem to recognize this.
      W:     activity flag (0=OFF, 1=ON).
      B:     lower colour limit.
      B:     upper colour limit

     Information for sprites/brushes:
     --------------------------------
     "DEST" (8 bytes) used with  sprites  of  fewer  colour planes than the
     screen for which they were designed.
      B:     Number of planes of the screen for which sprite was designed.
      B:     unused.
      W:     Bitmap: screen planes to be used by this sprite.
      W:     Bitmap: (unused) planes to be set (the others are cleared).
      W:     Bitmap:  planes  to  be  at   all   touched  (either  used  or
             set/clear).
             For each of the  bitmap  words,  each  bit  corresponds to the
             plane of the same number (bit 0 to plane 0 etc.), and each set
             bit marks a plane to be used, set or touched respectively.
     "GRAB" (4 bytes)
      W:     x  position  on  screen   for   the   upper   left  corner  of
             sprite/brush.
      W:     y position.
     "SPRT" (2 bytes)
      W:     Precedence (0-65535) of this sprite compared to others.

     Amiga hardware information:
     ---------------------------
     "CAMG" (4 bytes)
      L:     viewport mode (bit 11=HAM, bit 3=interlaced)


     Other chunks could also be found. For  instance in the IFF images that
     come with the game CIVILISATION (file name extension = .LBM, and there
     are 32 colour Amiga piccies, although only the first 4 planes are used
     by ST Civilization) I found  a  DPPS  chunk,  the  meaning of which is
     unknown to me. But again, this is  not  a big problem, since any chunk
     that isn't needed can be skipped.  All  the really crucial data should
     be contained in the three basic chunks anyway - BMHD, CMAP and BODY.

                  More on the general IFF:  Structuring chunks
                  --------------------------------------------

     Let's finally leave the pure picture file  and look at the general IFF
     system. In a general IFF file there can occur chunks of the types:

             FORM, CAT, LIST, PROP and local chunks.

     The purpose of the first four types  is  only to give structure to the
     IFF file, similar to what folders do to a file structure.

     Every structuring chunk has a type ID (e.g. "ILBM" for pictures) which
     is found as the first longword  after  the  8 byte chunk header. Local
     chunks don't have type IDs.  Data  are  always placed in local chunks,
     never directly in a structure chunk.

     FORM    has  already  been  explained  I   think.   It  is  the  basic
             structuring unit. Any IFF  file  always constitutes one single
             FORM, which can represent  one  single  image,  sound, text or
             other data block,  but  can  also  represent  a  collection of
             images, sounds etc. in which  case  the individual images etc.
             will be contained in subordinate FORMs.

     Every FORM has a type ID which should be identical only for FORMs with
     identical types of  data.  E.g.  any  FORM  that  represents  a single
     bitmapped image should  have  type  ID  "ILBM",  but  for  a FORM that
     represents a collection  of  images  a  separate  type  ID  has  to be
     invented.

     CAT     ("CAT " - note the ending  space  character)  is just a way to
             group together a number of FORMs.  A CAT can contain FORMs and
             groups of  FORMs  only  (i.e.  FORMs,  CATs  and  LISTs).  For
             instance the pictures of a slide-show can be put together in a
             CAT chunk while a title  picture  is  left outside of this, to
             mark that it doesn't belong to the others.

     The type ID of CATs (and  LISTs)  should  be  the same as of the FORMs
     they are containing if all FORMs are of the same type (e.g. "ILBM" for
     a CAT with only pictures). For a  CAT/LIST with mixed FORMs (e.g. both
     picture and sound) a special type ID will have to be invented.

     LIST      = CAT, with only one difference: it can contain PROP chunks.

     PROP    in its turn contains local chunks  that are common PROPerty of
             all the FORMs of the LIST. This  means that if a certain local
             chunk isn't found  in  a  FORM  (e.g.  a  palette  chunk  in a
             picture), then it is to be  looked  for  in the common PROP of
             the LIST.

     All PROP chunks of a LIST  have  to  be placed before any other chunks
     (the FORMs and groups of FORMs), right after the type ID of the LIST.

     The type ID of a PROP chunk should  be  the same as of the FORMs, with
     which it is intended to be used.

     Local chunks are all the other chunks,  - those which contain the hard
     data. These can occur only  inside  FORM  or  PROP chunks, and have no
     type ID.

     (The VDAT sub-chunks, within  the  local  BODY  chunk  of DELUXE PAINT
     compression 2 pictures (see  above),  are  not  called  for by the IFF
     standard. They must just have  been  considered  to  be  a neat way to
     split the plane data.)

     So a sprite collection file could for instance look like this:

     4 bytes "FORM" (Every IFF file starts like this, remember?)
     1 long  length of this parent chunk (file length minus 8)
     4 bytes "xxxx" - form type. (How about "BLST" for Bitmap LiST?)

     4 bytes "LIST"
     1 long  length of LIST chunk
     4 bytes "ILBM" LIST type (This list contains only pictures)

     4 bytes "PROP"
     1 long  length of PROP chunk (= 60 in this example)
     4 bytes "ILBM" PROP type (PROP is to be used with picture forms)
     4 bytes "CMAP"
     1 long  length of CMAP (=48 for a 16 colour palette)
     48 bytes        (for a 16 colour palette) palette data

     Of course the PROP could also  have  included  a common BMHD chunk and
     possibly other chunks as well.

     And then the ILBM FORMs of the  list  follows. These can in their turn
     be grouped in sub-lists - e.g.  one  list with 16*16 sprites, one with
     32*32 sprites, special lists with 3 plane sprites etc.

