ILBM

From Just Solve the File Format Problem
(Difference between revisions)
Jump to: navigation, search
Line 29: Line 29:
  
 
=== Aspect ratio ===
 
=== Aspect ratio ===
Many ILBM images were designed for graphics modes having non-square pixels, so they will look squished if displayed directly on a modern computer. Fortunately, there is an "aspect ratio" field (and sometimes other fields, such as a <code>DPI</code> chunk), which can supply the information need to unsquish them. Unfortunately, though this field is very often correct and useful, it is incorrect in a significant minority of files. For example, it may contain the reciprocal of the correct value, or it may be based on the shape of the image as a whole, instead of the shape of a pixel. There is probably no perfect solution to this problem.
+
Many ILBM images were designed for graphics modes having non-square pixels, so they will look squished if displayed directly on a modern computer. Fortunately, there is an "aspect ratio" field (and sometimes other fields, such as a <code>DPI</code> chunk), which can supply the information needed to unsquish them. Unfortunately, though this field is very often correct and useful, it is incorrect in a significant minority of files. For example, it may contain the reciprocal of the correct value, or it may be based on the shape of the image as a whole, instead of the shape of a pixel. There is probably no perfect solution to this problem.
  
 
=== Palette precision ===
 
=== Palette precision ===
Line 78: Line 78:
  
 
=== VDAT ===
 
=== VDAT ===
In the ILBM variant we're calling VDAT (reportedly used by "the ST version of DPAINT"), instead of raw image data, the <code>BODY</code> chunk contains a sequence of <code>VDAT</code> chunks. It possibly uses compression type 2.
+
In the ILBM variant we're calling VDAT (reportedly used by "the ST version of DPAINT"), instead of raw image data, the <code>BODY</code> chunk contains a sequence of <code>VDAT</code> chunks. It uses compression type 2. The format is similar, but not identical, to that used in [[Tiny Stuff]] files.
  
 
== Specifications ==
 
== Specifications ==
Line 84: Line 84:
 
* [http://www.textfiles.com/programming/FORMATS/ilbm ILBM spec]
 
* [http://www.textfiles.com/programming/FORMATS/ilbm ILBM spec]
 
* [http://www.shikadi.net/moddingwiki/LBM_Format ModdingWiki: LBM Format]
 
* [http://www.shikadi.net/moddingwiki/LBM_Format ModdingWiki: LBM Format]
 +
* [http://www.atari-forum.com/wiki/index.php?title=ST_Picture_Formats ST Picture Formats]
 
* [http://www.textfiles.com/programming/FORMATS/pix_fmt.txt Picture format docs (of a number of formats including DeluxePaint LBM/IFF)]
 
* [http://www.textfiles.com/programming/FORMATS/pix_fmt.txt Picture format docs (of a number of formats including DeluxePaint LBM/IFF)]
 
* {{EGFF|iff|IFF File Format Summary}}, from the [[Encyclopedia of Graphics File Formats]]
 
* {{EGFF|iff|IFF File Format Summary}}, from the [[Encyclopedia of Graphics File Formats]]
Line 122: Line 123:
 
[[Category:IFF based file formats]]
 
[[Category:IFF based file formats]]
 
[[Category:Amiga]]
 
[[Category:Amiga]]
 +
[[Category:Atari graphics formats]]
 
[[Category:Electronic Arts]]
 
[[Category:Electronic Arts]]

Revision as of 13:48, 26 April 2015

File Format
Name ILBM
Ontology
Extension(s) .iff, .lbm, .ilbm, .pic, others
PRONOM fmt/338, x-fmt/424, x-fmt/301

ILBM (or IFF-ILBM, or LBM) is a loosely-defined family of raster image file formats that use the IFF container format. ILBM stands for InterLeaved BitMap.

It is also sometimes called IFF or Amiga IFF, though IFF more properly refers to the generic IFF format on which ILBM is based.

As seems to be common practice, we consider ILBM to include some similar formats whose type identifier is not "ILBM", and which are not necessarily interleaved. We exclude formats that use incompatible variants of IFF.

ILBM files were widely used on Amiga computers, but are not limited to that platform. The format originated with the Deluxe Paint program from Electronic Arts.

When "lost" computer graphics created by Andy Warhol on an Amiga computer were discovered and converted by retrocomputing buffs at the Carnegie Mellon University Computer Club in 2013, some of them were found to be in a slight variant of the ILBM format, with a .pic extension.

Contents

Identification

The file begins with the ASCII string FORM, and has a type identifier at offset 8 that is usually ILBM. A BMHD chunk appears somewhere in the file, usually immediately after ILBM.

Some variants formats have a "FORM type" that is something other than ILBM, such as "PBM ", ACBM, RGBN, or RGB8.

Format details

Compression

The image compression algorithm is indicated by a coded integer. The known compression types are 0 for no compression, 1 for PackBits, and 2 for a special "vertical" RLE format (see VDAT, below).

Color cycling

Some ILBM images are designed to be animated using palette color cycling, as indicated by CRNG chunks or other mechanisms. Many image viewers and converters don't support this feature.

Aspect ratio

Many ILBM images were designed for graphics modes having non-square pixels, so they will look squished if displayed directly on a modern computer. Fortunately, there is an "aspect ratio" field (and sometimes other fields, such as a DPI chunk), which can supply the information needed to unsquish them. Unfortunately, though this field is very often correct and useful, it is incorrect in a significant minority of files. For example, it may contain the reciprocal of the correct value, or it may be based on the shape of the image as a whole, instead of the shape of a pixel. There is probably no perfect solution to this problem.

Palette precision

Some viewers appear to display some ILBM images slightly too dark. For example, the whitest white may be (240,240,240) instead of (255,255,255). This happens because, though the palette in an ILBM file always has 8 bits of precision per sample, some graphics modes did not use all 8. Encoders targeting such modes would sometimes carelessly set the low (usually 4) bits to zero. Some ILBM viewers try to detect this situation, and correct for it.

Special types of ILBM

The plain ILBM format is reasonably well standardized. This section describes some of the other ILBM formats.

Hold-and-Modify

Hold-and-Modify (HAM) images are designed to work with the Amiga's oddball Hold-and-Modify graphics modes. There are two main kinds of HAM images: HAM6 (6 bits per pixel) and HAM8 (8 bits per pixel). The term HAM sometimes refers just to HAM6.

It is usually said that HAM6 supports up to 4096 different colors in an image, and HAM8 supports 262,144. This is probably true with regard to the actual Amiga graphics modes, but some not-so-carefully-written ILBM specifications imply that more colors are possible. Not that it matters much, because the real limitation is that, for each pixel, there are at most 64 or 256 available colors.

HAM6

HAM6 files have bit 11 of the CAMG chunk set, 6 planes (rarely 5), and 16 palette colors.

Reportedly, some HAM6 files are missing the CAMG chunk. A file with no CAMG chunk, 6 bit planes, and 16 palette colors is probably HAM6.

HAM8

HAM8 files have bit 11 of the CAMG chunk set, 8 planes (rarely 7), and 64 palette colors.

Multi-palette HAM

There are at least three extended HAM formats designed to take advantage of the Amiga's ability to make changes to the palette in the middle of an image:

  • SHAM (Sliced HAM) - Uses a SHAM chunk.
  • CTBL (Newtek Dynamic Ham) - Uses CTBL and DYCP chunks.
  • PCHG - Uses a PCHG (Palette Changes) chunk.

Extra-Halfbrite

Extra-Halfbrite (EBH) images are designed to work with the Amiga's Halfbrite graphics mode. They have 6 planes, but only 32 colors in the palette. In effect, the palette should be assumed to have an additional 32 colors that are half as bright as the first 32.

Extra-Halfbrite files are identified by bit 7 of the CAMG chunk being set.

Deep images

Non-paletted (for example, 24-bit RGB) ILBM images are sometimes called "deep images". This is not to be confused with IFF-DEEP, a different format.

PBM

PBM (Planar BitMap) files have FORM type of "PBM " instead of ILBM. Each pixel is stored contiguously, and there is only a single plane.

This is not to be confused with Netpbm's PBM format.

ACBM

ACBM (Amiga Contiguous Bitmap) is a variant of ILBM designed to be used efficiently by AmigaBASIC. The image is separated into bit-planes and then rows, instead of rows and then bit-planes.

The "FORM type" is ACBM (instead of ILBM), and instead of a BODY chunk there is an ABIT chunk.

RGBN and RGB8

RGBN (12-bit RGB) and RGB8 (24-bit RGB) were used by Impulse's Silver and Turbo Silver programs (see also TDDD).

VDAT

In the ILBM variant we're calling VDAT (reportedly used by "the ST version of DPAINT"), instead of raw image data, the BODY chunk contains a sequence of VDAT chunks. It uses compression type 2. The format is similar, but not identical, to that used in Tiny Stuff files.

Specifications

Software

It is possible that there is no single application that does a good job of decoding the full range of ILBM formats. More research is needed here.

Sample files

Links

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox