Interchange File Format
The Interchange File Format (IFF ) was introduced in 1985 by the company Electronic Arts as the default file format in their products.
It is actually a whole family of file formats that are characterized by the common TLV structure (abbr. for Type - Length-Value ).
The most famous is IFF ILBM, a planar bitmap format ( originally only for 8-bit, later extended to 24/32 bit), which is used on Amiga computers. The Deluxe Paint paint program contributed significantly to the spread of the format. After Deluxe Paint - next to Atari ST - has been ported to the IBM PC, and the IFF format found a new home and more widely, on the PC the file extension LBM is mostly used. . A similarly known IFF file format is AIFF, the. Most common on Macintosh format for audio files
Microsoft copied the principle of IFF files, organized the byte order ( endianness ) of the data is in contrast to the original Big - Endian to Little Endian and called the result RIFF. The most common RIFF format is probably RIFF WAVE, also known as wav. . Other formats, such as that developed by Aldus / Adobe TIFF format or the related Exif thus have a flexible file structure (in this case on the basis of so-called tags). This structure also results in user-definable in terms of size data blocks, but the internal file organization is a completely different and more with a file system such as FAT comparable (consisting of a tabular list of tags, the values or offsets to values included).
- 2.1 BMHD - Chunk
- 2.2 CMAP chunk
- 2.3 CRNG and CCRT - Chunk
- 2.4 CAMG - Chunk
- 2.5 ICCP / ICCN, GAMA, CHRM chunks
- 2.6 Exif, IPTC, XMP0, XMP1, ICC, GEOT
- 2.7 BODY chunk
- 2.8 compression
- 2.9 Extensions (special chunks ) 2.9.1 CTBL - Chunk
- 2.9.2 SHAM - Chunk
- 2.9.3 PCHG - Chunk
Structure
IFF files usually begin with the FourCC ( Four Character Code abbreviation for ) shape, followed by a molded four-byte long word that contains the length of the entire file without these first eight bytes. This is followed by another FourCC that specifies the actual file type.
An even more general file type starts with the FourCC CAT (with spaces at the end, for Catalog, dt about list, compilation ), which contains a number of FORM data sets, such as those described here in a row. This can also completely different types of data such as audio, animation and frames are combined into a single file, that is a "container " format, according to current language regime.
The other file content is in so-called chunks (English: piece, block, lump ) divided, each consisting of a FourCC, a long word ( four bytes ) Chunklänge and the actual data of the chunk exist. As the content of the chunk is structured depends on its type. There are a few standard chunks that can appear in any IFF file, others are permitted in several or even a single file type.
All long words in IFF format is big-endian, ie the most significant byte comes first, as is customary on the 68000 processor. Chunks that have an odd length, are generally provided with a padding byte, which is not counted in the length specification of the chunk ( " padding "). The reason for this is that the memory was organized 68000 in words and no words or long words could be read from odd addresses - is apart with newer CPUs to process data faster when they are aligned with Wort-/Langwortgrenzen.
Standard chunks
- AUTH - includes 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 file stored in the work
- VERSE - the version of the file
- ( c ) - Copyright information ( with a space after the closing parenthesis )
Some IFF formats
- ILBM - Interleaved Bit Map, the most commonly -used Amiga graphics format ( RLE compression )
- PBM - If IIe of Deluxe Paint ( PC version ) used to store 256-color images ( RLE compression )
- ACBM - Amiga Continuous Bit Map, as ILBM, but the image data is not interleaved before ( RLE compression )
- RGBN - Impulse 's Turbo Silver and Silver ( 12 -bit RGB format )
- RGB8 - Impulse 's Turbo Silver and Silver ( 24 -bit RGB format )
- RGFX - SView5 (256 colors and 24 to 96 -bit RGB format (HDR ); XPK or ZIP/LZ77-Kompression )
- 8SVX - Amiga audio, uncompressed ( opt. Fibonacci delta compressed), 8 bits, channels individually
- AIFF - Macintosh audio, 8 to 32 bits, as many channels
- ANIM - animations, among other uses of Deluxe Paint
- DR2D - vector graphics
- FTXT - text
- SHRI - SHRINK compression, one of the strongest data compression algorithms of XPKmaster.library under AmigaOS, similar to LZ77
- SMUS - music sequences, similar to MIDI Files
- WORD - Document Format Amiga text program ProWrite
- META - General container for metadata (AUTH, ANNO, NAME, Exif, XMP0, XMP1, ICC, GeoT (IFF ), etc.)
Complete format and Chunkliste
A list of all chunks / IDs is available at amigaos.net. It does not contain any third- extensions, some of which were specified separately ( see links at bottom of page).
ILBM format
The ILBM format (English Interleaved Bitmap ) is the most commonly used IFF format. The images can theoretically be stored in almost all color depths.
The most common are:
In order to display an image, the right color or display mode must first be determined. This requires not only the number of the plan ( BMHD - Chunk ), the number of colors ( CMAP chunk ). If you have the color mode determines you know how the data stored in the BODY chunk image data are to be interpreted. It is also helpful if a CAMG chunk is present. As the technology has evolved steadily since the development of IFF ILBM, are also added requirements that make it necessary to carry further color profile information (gamma, chromaticity, ICC color profiles for color management ). For this purpose, extensions have been defined by a third party, which may also be necessary for the correct interpretation of image data ( GAMA, CHRM, ICCP chunks ).
Within a FORM chunk following important chunks can be found:
BMHD - Chunk
The BMHD - Chunk ( BitMap header) 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 ( Color MAP ) represents the color palette ( also CLUT ) ready.
This chunk is not present in 24-/32-/48-/64-Bit-IFF-Bildern.
Each entry of the color palette is composed of three bytes, representing the RGB values. The number of colors is determined by dividing the Chunklänge by three.
Example:
CMAP - ID 00 00 00 C0 - Length of the chunk 192 bytes -> 64 colors 04 04 00 - 1 color value FB EB E7 - 2 color value ... 10 10 08 - 64 color value CRNG and CCRT - Chunk
Optional
Both the CRNG ( Color Range register ) and the CCRT - Chunk ( colorcycling Range and timing) gather the data for the colorcycling (see Indexed Color ). This means simple animations can be shown, the burden is extremely low, the graphics hardware. The two chunk formats are structured differently and are not normally found both in the same file before.
This chunk is not present in 24-/32-/48-/64-Bit-IFF-Bildern, as well as a CMAP chunk ( above ) is required.
Add the chunks to find information, from which color number should be enough to animating color range up to which other. In addition, the length of the pause between cycles is specified in seconds and microseconds.
A file can also contain a number of such color- cycling chunks, so that different areas of the color palette can be animated at once and even at different speeds.
CAMG - Chunk
Optional
The CAMG - Chunk ( Commdore Amiga ) contains the Amiga - specific display mode.
This chunk contains only a 32 -bit value with the display mode. The Amiga can handle this value directly ( it is directly the contents of a status register its chipset ), other systems can use it to identify the display mode.
ICCP / ICCN, GAMA, CHRM chunks
Optional
These chunks correspond in substance the same chunk from the PNG format (except for the first letter, which is written in small letters ) and were from a third party defined in the ' ILBM64' format ( 64 bit extensions for IFF ILBM ) to gamma - to embed / Chromacity and ICC color profile information in IFF. The use is not limited to ILBM, but equally with other IFF graphics file formats possible.
Exif, IPTC, XMP0, XMP1, ICC, GEOT
Optional
These chunks correspond in substance roughly the same chunks or markers in the JPEG ( JFIF), PNG or TIFF format and are designed according to XMP metadata standard Exif tags, ICC color profiles, GeoTIFF data or IPTC tags into be able to save IFF formats. The use is not limited to IFF graphics formats, but equally with other IFF formats possible. 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 bit planes are in this case not one behind the other, but nested (English interleaved) before. Here, all bitplanes of an image line are successively stored before starting the next image line.
The number of bytes of an image line must be divisible by 8.
Example of an 8-color image (3 planes):
Line 0 Plane 0 Byte 0 - bits for the first 8 pixels byte 1 ... byte m Plane 1 Plane 2 line 1 Plane 0 Plane 1 Plane 2 ... line n Plane 0 Plane 1 Plane 2 To determine the palette entry for the pixel, the individual bits of the plan are combined into one section.
In 24/32/48/64 bit images, the plane sequence is always RGBA (red -green-blue - alpha).
Compression
The image data inside the BODY chunk can uncompressed ( type 0) or in a packaged form, depending on the compression flag in BMHD chunk. In compression, a simple RLE (run - length encoding ) algorithm names CmpByteRun1 (Type 1) is used, which is practically identical to similar procedures in PCX or TIFF. Later, the AmigaOS defined in version V44 still CmpByteRun2 (type 2), but this was not documented and therefore is generally uncommon.
The CmpByteRun1 encoder summarizes identical byte values together within one image line. The encoding stops at the end of each image line. The packed bytes are stored as two -byte code. The first byte indicates the type of compression and the number.
- If the value (code) in the range of 0 to 127 is (unsigned ) is unpacked data. The following code 1 bytes are simply copied into the picture.
- If the value (code ) in the range from -1 to -127 (signed ), is packed data. Here, the code to the following byte ( code 1 ) is repeated times.
- A value of -128 is always ignored.
Extensions (special chunks )
Because of the limitations of certain combinations of screen resolution and color depth is attempted with the aid of the Coppers and the use of new chunks to increase the color depth artificially. It is constantly changing the palette during image construction.
The most common formats are (details follow below):
- Multi - range images - PCHG - Chunk
All these extensions are unusual because of the very hardware - dependent. Conventional HAM6/8-Dateien can, however, easily convert to other common TrueColor -bit graphics formats.
The prior art for higher color depths than 24 (32) bits corresponding to the 48 ( 64-bit) extensions. This means that HDR displays are possible (16 bits per color channel).
CTBL - Chunk
CTBL stands for Color Table.
This chunk contains, starting from the top, for each row, a new 16- color palette. However, this differs from the range in the CMAP chunk fact that the palette entries only 16 bits instead of the usual 24 bits wide. Per color component are 4 bits are available, the top 4 bits are unused.
Chunk length divided by 32 is the number of stored in the chunk color palettes. The color palettes then follow directly one behind the other; each 16 × 2 bytes = 32 bytes.
This extension is uncommon.
SHAM - Chunk
SHAM stands for Sliced HAM.
This chunk has the same structure as the CTBL chunk. The only difference is 2 byte version number at the beginning of the chunk, but they are always 0.
This extension is uncommon.
PCHG - Chunk
PCHG stands for palette changes.