ILBM

File format

In essence LBM files consist of a number of consecutive chunks, whose order can, to some extent, be varied. Each chunk has a different function and has the same basic format. This means that a program does not have to read or decode every chunk in a file, only the ones it wants to deal with or the ones it can understand. For example, a program might use a TIME chunk to store the date and time that a file was last edited. Another program does not need to know about this and can just skip the chunk and leave it unchanged, or drop the chunk entirely, although that is not an advisable thing for a tool to do automatically.

For details on the chunk structure and how to read them, see Interchange File Format (IFF).

LBM files usually contain enough information to allow them to be displayed by an image editing program, including image dimensions, palette and pixel data. Some files were designed to act as palettes for paint programs (pixel data left blank) or to be merged into another image. This makes them much more flexible, but also much more complex than other formats such as BMP.

For LBMs the BMHD chunk and any other 'vital' chunks must appear before the BODY chunk. Any chunks appearing after BODY are considered 'extra' and many programs will leave them unread and unchanged.

There are many possible chunk types. However, there are only a limited number of common chunk types used and understood by most programs, and descriptions of these follow. Again refer to Interchange File Format for further detail about finding and handling chunks.

BMHD: Bitmap Header

The BMHD chunk specifies how the image is to be displayed and is usually the first chunk inside the FORM. It not only defines the image's height/width, but where it is drawn on the screen, how to display it in various screen resolutions and if the image is compressed. The content of this chunk is as follows:

BODY: Image data

The BODY chunk is usually the last chunk in a file, and the largest.

In ILBM files the BODY chunk stores the actual image data as interleaved bitplanes (and optional mask) by row. The bitplanes appear first from 1 to n, followed by the mask plane. If the image is uncompressed then each line will be made up of (width + 15) / 16 16-bit values (i.e. one bit per pixel, rounded up to the nearest multiple of 16-bits.) If it is compressed then each line is compressed individually and is always a multiple of 16-bits long when compressed.

In PBM files the BODY chunk is simpler as uncompressed it is just a continuous stream of bytes containing image data.

Compression

If an image is compressed, each row of data (but not each bitplane) is compressed individually, including the mask data if present. The compression is a variety of RLE Compression using flags. It can be decoded as follows:

For the compression routine, it's best to encode a 2 byte repeat run as a replicate run except when preceded and followed by a literal run, in which case it is best to merge the three into one literal run. Always encode >3 byte repeats as replicate runs.

CAMG: Amiga mode

A CAMG chunk is specifically for the Commodore Amiga computer. It stores a LONG "viewport mode". This lets you specify Amiga display modes like "dual playfield" and "hold and modify". It is, not surprisingly, rare outside of Amiga games.

If you need to convert or display files that might contain meaningful CAMG chunks, see the 'Notes on working with LBM files' below.

CMAP: Palette

The CMAP chunk contains the image's palette and consists of 3-byte RGB values for each colour used. Each byte is between 0 and 255 inclusive. The chunk is 3 × numColours bytes long. The number of colours in the palette will be 2 ^ numBitplanes. This chunk is optional and a default palette will be used if it is not present. It is possible to have fewer entries than expected (e.g. 7 colours for a 4-plane '16 colour' bitmap for example.) Remember that if this has an odd number of colours, as per the IFF specification the chunk will be padded by one byte to make it an even number of bytes long, but the pad byte is not included in the chunk's length field.

CRNG: Colour range

The colour range chunk is 'nonstandard'. It is used by Electronic Arts' Deluxe Paint program to identify a contiguous range of colour registers or a "shade range" and colour cycling. There can be zero or more CRNG chunks in an LBM file, but all should appear before the BODY chunk. Deluxe Paint normally writes 4 CRNG chunks in an LBM when the user asks it to "Save Picture".

CCRT: Colour cycling

Commodore's Graphicraft program uses CCRT for Colour Cycling Range and Timing. This chunk contains a CycleInfo structure. Like CRNG it is a nonstandard chunk.

The data is similar to a CRNG chunk. A program would probably only use one of these two methods of expressing colour cycle data. You could write out both if you want to communicate this information to both DeluxePaint and Graphicraft.

DEST: Bitplane combining

The optional property DEST is a way to control how to scatter zero or more source bitplanes into a deeper destination image. Some readers may ignore DEST.

The low order depth number of bits in planePick, planeOnOff, and planeMask correspond one-to-one with destination bitplanes. Bit 0 with bitplane 0, etc. (Any higher order bits should be ignored.)

"1" bits in planePick mean "put the next source bitplane into this bitplane", so the number of "1" bits should equal numPlanes. "0" bits mean "put the corresponding bit from planeOnOff into this bitplane".

Bits in planeMask gate writing to the destination bitplane: "1" bits mean "write to this bitplane" while "0" bits mean "leave this bitplane alone". The normal case (with no DEST chunk) is equivalent to planePick = planeMask = (2 ^ numPlanes) - 1.

Remember that color numbers are formed by pixels in the destination bitmap (depth planes deep) not in the source bitmap (numPlanes planes deep).

GRAB: Hotspot

The optional GRAB chunk locates a "handle" or "hotspot" of the image relative to its upper left corner, e.g. when used as a mouse cursor or a "paint brush". It is optional.

SPRT: Z-order

The SPRT chunk indicates that an image is intended to be a sprite. It should thus have a mask plane or transparent colour and shouldn't be fullscreen. How this is handled depends on the program using the image. The only data stored here is the sprite order, used by many programs to place the sprite in the foreground (a sprite of order 1 appears behind one of order 0, etc.) It is optional.

TINY: Thumbnail

The TINY chunk contains a small preview image for various graphics programs, including Deluxe Paint. It is compressed and is similar in format to the BODY chunk.

Utilities

Most utilities that work with LBM and BBM files are rather dated, such as MacPaint or Deluxe Paint.