[Contents] [Index] [Help] [Retrace] [Browse <] [Browse >]

IFF is based on data blocks called "chunk"s. Here's an example color map
chunk:

                         +------------------+ in an ILBM file, CMAP means
          char typeID[4] | "CMAP"           | "color map"
                         |------------------+
  unsigned long dataSize |  48              | 48 data bytes
                         |------------------+
             char data[] |  0,0,0,255,      | 16 3-byte color values:
                         |  255,255,255...  | black, white, ....
                         +------------------+

                         +------------------+ in an ILBM file, CMAP means
                         | "CMAP"           | "color map"
                         |------------------+
                         |  48              | 48 data bytes
                         |------------------+
                         |  0,0,0,255,      | 16 3-byte color values:
                         |  255,255,255...  | black, white, ....
                         +------------------+

A chunk is made of a 4-character type identifier, a 32 bit data byte
count, and the data bytes. It's like a Macintosh "resource" with a 32-bit
size.

Fine points:

 o Every 16- and 32-bit number is stored in 68000 byte order - highest
    byte first.

   An Intel CPU must reverse the 2- or 4-byte sequence of each number.
   This applies to chunk dataSize fields and to numbers inside chunk
   data.  It does not affect character strings and byte data because you
   can't reverse a 1-byte sequence.  But it does affect the 32-bit math
   used in IFF's MakeID macro.  The standard does allow CPU specific byte
   ordering hidden within a chunk itself, but the practice is discouraged.

 o Every 16- and 32-bit number is stored on an even address.

 o Every odd-length chunk must be followed by a 0 pad byte.  This pad
    byte is not counted in dataSize.

 o An ID is made of 4 ASCII characters in the range " " (space, hex 20)
    through "~" (tilde, hex 7E).  Leading spaces are not permitted.

 o IDs are compared using a quick 32-bit equality test.  Case matters.

A chunk typically holds a C structure, Pascal record, or an array.  For
example, an ilbm picture has a bmhd bitmap header chunk (a structure)
and a body raster body chunk (an array).

To construct an IFF file, just put a file type ID (like ilbm) into a
wrapper chunk called a "FORM" (Think "FILE").  Inside that wrapper place
chunks one after another (with pad bytes as needed).  The chunk size
always tells you how many more bytes you need to skip over to get to the
next chunk.

                  +------------------+
                  |                  |
                  |  "FORM"          |  FORM is a special chunk ID
                  |                  |
                  +------------------+
                  |   24070          |  24070 data bytes
               -- +------------------+
               |  |                  |
               |  |  "ILBM"          |  FORM type is ILBM
               |  |                  |
               |  | +--------------+ |
               |  | |  "BMHD"      | |  A BMHD bitmap header chunk
               |  | |--------------| |  (20 data bytes)
               |  | |   20         | |
               |  | |--------------| |
               |  | |  320, 200,   | |
               |  | |  0 ....      | |
               |  | +--------------+ |
               |  |                  |
               |  | +--------------+ |
               |  | |  "CMAP"      | |  A CMAP color map chunk
        24070 <   | |--------------| |  (21 data bytes = 1 pad)
        bytes  |  | |   21         | |
               |  | |--------------| |
               |  | |  0, 0, 0,    | |
               |  | |  255 ....    | |
               |  | +--------------+ |
               |  |   0              |  A pad byte
               |  | +--------------+ |
               |  | |  "BODY"      | |
               |  | |--------------| |  A BODY raster body chunk
               |  | |  24000       | |  (24000 data bytes)
               |  | |--------------| |
               |  | |  0, 0, 0.... | |
               |  | +--------------+ |
              -- +------------------+

A FORM always contains one 4-character FORM type ID (a file type, in this
case "ilbm") followed by any number of data chunk.  in this example, the
FORM type is "ILBM", which stands for "InterLeaved BitMap".  (ilbm is an
IFF standard for bitplane raster pictures.)  This example has 3 chunks.
Note the pad byte after the odd length chunk.

Within FORMs ilbm, bmhd identifies a bitmap header chunk, cmap a color
map, and body a raster body.  in general, the chunk ids in a form are
local to the FORM type ID.  The  exceptions are the 4 global chunk IDs
"FORM", list, cat , and prop.  (a form may contain other form
chunks.  E.g., an animation FORM might contain picture FORMs and sound
FORMs.)