Interchange File Format

from Wikipedia, the free encyclopedia

The Interchange File Format ( IFF ) was introduced in 1985 by Electronic Arts as the standard file format in their products.

It is actually a whole family of file formats that are characterized by the common TLV structure (abbreviation for Type-Length-Value ).

The best known is IFF-ILBM , a planar bitmap graphics format (originally only for 8 bits, later extended to 24/32 bits), which is used on Amiga computers. The painting program Deluxe Paint contributed significantly to the spread of the format. Since Deluxe Paint - in addition to Atari ST - has also been ported to IBM PCs, the IFF format has also found a new home and wider distribution; the file extension .LBM is mostly used on PCs . A similarly known IFF file format is AIFF , which is the most common format for uncompressed audio files on Macintosh .

Microsoft copied the principle of IFF files, organized the byte order (endianness) of the data in them, in contrast to the original from Big-Endian to Little-Endian, and named the result RIFF . Probably the most popular RIFF format is RIFF WAVE , also known as .wav . Other formats, such as the TIFF format developed by Aldus / Adobe or the related Exif, have a flexible file structure (here based on so-called tags). This structure also results in data blocks that can be freely defined in terms of size, but the internal file organization is completely different and more comparable to a file system such as FAT (consisting of a tabular directory of tags containing values ​​or offsets to values).

structure

IFF files usually begin with the FourCC (abbreviation for Four Character Code ) FORM , followed by a long word formed from four bytes that contains the length of the entire file without these first eight bytes. This is followed by another FourCC, which indicates the actual file type.

An even more general file type begins with the FourCC CAT  (with a space at the end, for catalog, for example list, compilation), which contains a series of FORM data records, as described here, one after the other. This means that completely different types of data, such as audio, animation and individual images, can be combined in a single file, a "container" format according to today's language rules.

The rest of the file content is divided into so-called chunks , which each consist of a FourCC, a 32-bit word chunk length and the actual data of the chunk. How the content of a chunk is structured depends on its type. There are some standard chunks that can appear in every IFF file, others are allowed in several or even just one file type.

All longwords in IFF format are big-endian , so the most significant byte comes first, as is common on the 68000 processor. Chunks that have an uneven length are always given a padding byte that is not included in the length specification of the chunk (" padding "). The reason for this is that the memory of the 68000 was organized in words and no words or long words could be read from odd addresses - apart from that, even with newer CPUs, the processing of data in the memory is faster if they are at 16 or 32 -Bit borders are aligned.

Standard chunks

  • AUTH - contains information about the author of the file
  • ANNO - usually contains the name of the program with which the file was created
  • NAME - describes the name of the work stored in the file
  • VERS - the version of the file
  • (c)  - Copyright information (with a space after the closing bracket)

Some IFF formats

  • ILBM - Interleaved Bit Map, most commonly used Amiga graphics format ( RLE compression)
  • PBM - Used by Deluxe-Paint IIe (PC version) to store 256-color images (RLE compression)
  • ACBM - Amiga Continuous Bit Map, like ILBM, but the image data are not interleaved (RLE compression)
  • RGBN - Impulse's Silver and Turbo Silver (12-bit RGB format)
  • RGB8 - Impulse's Silver and Turbo Silver (24-bit RGB format)
  • RGFX - SView5 (256 colors and 24 to 96-bit RGB format (HDR); XPK or ZIP / LZ77 compression)
  • 8SVX - Amiga Audio, uncompressed (opt. Fibonacci Delta-compressed), 8 bit, channels individually
  • AIFF - Macintosh audio, 8 to 32 bit, any number of channels
  • ANIM - animations used by Deluxe Paint, among others
  • DR2D - vector graphic
  • FTXT - text
  • SHRI - SHRINK compression, one of the strongest data compression algorithms of the XPKmaster.library under AmigaOS , comparable to LZ77
  • SMUS - music sequences, similar to MIDI files
  • WORD - document format of the Amiga text program ProWrite
  • META - General container for metadata (AUTH, ANNO, NAME, Exif, XMP0, XMP1, ICC, GeoT (IFF) etc.)

Complete list of formats and chunks

A list of all chunks / IDs is available at amigaos.net. It does not contain all third-party extensions, some of which were specified separately (see links at the end of the page).

ILBM format

The ILBM format ( I nter L eaved B it M ap ) is the most frequently used IFF format. Theoretically, the images can be saved in almost any color depth.

The most common are:

  • 1 to 8 bits (2 to 256 colors)
  • 24 bit (3 × 8 bit; 16.8 million colors)
  • 32 bit (3 × 8 bit; 16.8 million colors with alpha channel )
  • 48 bit (3 × 16 bit; HDR)
  • 64 bit (3 × 16 bit; HDR with alpha channel)
  • EHB (Extra-HalfBright, 64 colors)
  • HAM (Hold-And-Modify, 4096 colors)
  • HAM8 (Hold-And-Modify AGA , 262144 colors)

In order to be able to display an image, the correct color or display mode must first be determined. In addition to the number of planes ( BMHD chunk ), you also need the number of colors ( CMAP chunk ). Once you have determined the color mode, you know how the image data stored in the BODY Chunk is to be interpreted. It is also helpful if a CAMG chunk is available. Since the technology has continuously developed since the development of IFF-ILBM, requirements have also been added that make it necessary to transport more extensive color profile information ( gamma , chromaticity , ICC color profiles for color management ). For this purpose, extensions have been defined by third parties, which may also be necessary for the correct interpretation of image data (GAMA, CHRM, ICCP chunks).

Color fashion Bitplanes Color palette
1-8 bits 1-8 2-256 RGB triplets in CMAP
24 bit 24 CMAP does not exist; 3 × 8 bit true color
32 bit 32 CMAP does not exist; 4 × 8 bit truecolor
48 bit 48 CMAP does not exist; 3 × 16 bit true color
64 bit 64 CMAP does not exist; 4 × 16 bit true color
EHB 6th 32 RGB triplets in CMAP
HAM 6th 16 RGB triplets in CMAP
HAM8 8th 64 RGB triplets in CMAP

The following important chunks can be found within a FORM chunk:

BMHD chunk

The BMHD chunk ( B it M ap H ea D er) contains information about the saved image.

For example:

  • Width and height of the image in pixels
  • Number of bitplanes
  • compression

CMAP chunk

optional

The CMAP chunk ( C olor MAP ) provides the color palette (also CLUT ).

This chunk does not exist in 24/32/48/64 bit IFF frames.

Each entry in the color palette consists of three bytes that represent the RGB values. The number of colors is determined by dividing the chunk length by three.

Example: 

   CMAP               - Kennung
   00 00 00 C0        - Länge des Chunks 192 Byte -> 64 Farben
   04 04 00           -  1. Farbwert
   FB E7 EB           -  2. Farbwert
   …
   10 10 08           - 64. Farbwert

CRNG and CCRT chunk

optional

Both the CRNG ( C olor register R a NG e) and the CCRT ( C olor C ycling R ange and T iming) chunk define the data for the color cycling (see indexed colors ). This means that simple animations can be displayed that place extremely little stress on the graphics hardware. The two chunk formats are structured differently and usually do not both appear in the same file.

This chunk does not exist in 24/32/48/64-bit IFF images because a CMAP chunk (previous) is also required.

The chunks contain information on from which color number to which other a color area to be animated should extend. In addition, the length of the pause between the individual cycles is specified in seconds and microseconds.

A file can also contain several such color cycling chunks, so that different areas of the color palette can be animated simultaneously and even at different speeds.

CAMG chunk

optional

The CAMG-Chunk ( C ommdore- AM i G a) contains the Amiga-specific display mode .

This chunk only contains a 32-bit value with the display mode. The Amiga can process this value directly (it is directly the content of a hardware control register of its chipset ); other systems can use it to identify the display mode.

ICCP / ICCN, GAMA, CHRM chunks

optional

In terms of content, these chunks correspond to the chunks of the same name from the PNG format (except for the first letter, which is lowercase) and were defined by a third party in the 'ILBM64' format (64-bit extensions for IFF-ILBM) to allow gamma / Embed Chromacity and ICC color profile information in IFF. Its use is not restricted to ILBM, but can also be used with other IFF graphic formats.

Exif, IPTC, XMP0, XMP1, ICC, GEOT

optional

In terms of content, these chunks correspond roughly to the chunks or markers of the same name from the JPEG (JFIF), PNG or TIFF format and are used to transfer metadata according to the XMP standard, Exif tags, ICC color profiles, GeoTIFF data or IPTC keywords To be able to save IFF formats. Use is not restricted to IFF graphic formats, but can also be used with other IFF formats. They were defined by a third party in the "IFF-META" extensions.

BODY chunk

The BODY chunk contains the actual image data.

These can be compressed or uncompressed. The individual bitplanes are not one behind the other, but rather interleaved . All bitplanes of an image line are saved one after the other before the next image line is started.

The number of bytes in an image line must be divisible by 8.

Example for an 8-color picture (3 planes): 

 Zeile 0
   Plane 0
      Byte 0 - Bits für die ersten 8 Pixel
      Byte 1
      …
      Byte m
   Plane 1
   Plane 2
 Zeile 1
   Plane 0
   Plane 1
   Plane 2
 …
 Zeile n
   Plane 0
   Plane 1
   Plane 2

In order to determine the palette entry for a pixel, the individual bits of the plan are combined into an index.

Index value for the pixel at the image position (0.0)
Index bit calculation
2 Plan 0 / byte 0 / bit 7
1 Plan 1 / byte 0 / bit 7
0 Plan 2 / byte 0 / bit 7

For 24/32/48/64 bit images, the plane order is always RGBA (red-green-blue-alpha).

compression

The image data within the BODY chunk can be uncompressed (type 0) or in packed form, depending on the compression flag in the BMHD chunk. A simple RLE (run-length encoding) algorithm called CmpByteRun1 (Type 1) is used for compression , which is practically identical to similar procedures in PCX or TIFF. Later, the AmigaOS defined CmpByteRun2 (type 2) in version V44, but this was not documented and is therefore generally not in use.

The CmpByteRun1 encoder combines identical byte values ​​within one image line. The coding stops at the end of each picture line. The packed bytes are stored as two-byte codes. The first byte indicates the type of compression and the number.

  • If the value ( code ) is in the range from 0 to 127 (unsigned), the data is unpacked. The following code + 1 bytes are simply copied into the picture.
  • If the value ( code ) is in the range from −1 to −127 (signed), the data is packed. The byte following the code ( −code + 1 ) is repeated here.
  • A value of −128 is always ignored.

Extensions (special chunks)

Due to the limitations of certain combinations of screen resolution and color depth, attempts are made to artificially increase the color depth with the help of the cupper and the use of new chunks. The palette is constantly changing while the image is being built.

The most popular formats are (details follow below):

  • Dynamic Hires - non-HAM images (palette) with CTBL chunk
  • Dynamic HAM or DHAM - HAM images with CTBL chunk
  • Sliced ​​HAM or SHAM - HAM images with SHAM chunk
  • MultiPalette images - PCHG chunk

All of these extensions are uncommon because they are very hardware-dependent. Conventional HAM6 / 8 files, on the other hand, can easily be converted into other common truecolor bit graphic formats.

The 48 (64-bit) extensions correspond to the state of the art for color depths higher than 24 (32) bit. This enables HDR displays (16 bits per color channel).

CTBL chunk

CTBL stands for C olor T a BL e.

Starting from the top, this chunk contains a new 16-color palette for each line. However, this differs from the palette in the CMAP chunk in that the palette entries are only 16 bits wide and not the usual 24 bits. 4 bits are available per color component, the top 4 bits are unused.

Chunk length divided by 32 results in the number of color palettes stored in the chunk. The color palettes then follow one another; 16 × 2 bytes each = 32 bytes.

This extension is not common.

SHAM chunk

SHAM stands for S liced HAM .

This chunk has the same structure as the CTBL chunk. The only difference is the two bytes version number at the beginning of the chunk, but they are always 0.

This extension is not common.

PCHG chunk

PCHG stands for P alette CH an G es.

Web links

Individual evidence

  1. ↑ List of all chunks / IDs ( Memento from April 9, 2013 in the Internet Archive )