Interchange File Format
Das Interchange File Format wurde von der Firma Electronic Arts als Standard-Dateiformat in ihren Produkten eingeführt.
Es handelt sich dabei eigentlich um eine ganze Familie von Dateiformaten, die sich durch eine gemeinsame Struktur auszeichnen. Das wohl bekannteste ist IFF-ILBM, das auf den Amiga-Rechnern benutzt wird. Das Malprogramm Deluxe Paint trug wesentlich zur Verbreitung des Formats bei. Nachdem Deluxe Paint für IBM-PC portiert wurde, fand auch das IFF-Format eine neue Heimat und weitere Verbreitung. Eine ähnlich bekanntes IFF-Dateiformat ist AIFF, das auf Macintoshs häufigste Format für Audio-Dateien.
Microsoft kopierte das Prinzip der IFF-Dateien, organisierte die Daten darin im Gegensatz zum Original little-endian und nannte das Ergebnis RIFF. Das bekannteste RIFF-Format ist wahrscheinlich RIFF-WAVE, auch bekannt als .wav . Auch das von Aldus entwickelte TIFF-Format ist in der Datenorganisation identisch.
Struktur
IFF-Dateien beginnen in der Regel mit vier ASCII-Großbuchstaben FORM, gefolgt von einem aus vier Bytes geformten Langwort, das die Länge der gesamten Datei hinter selbigem beinhaltet. Darauf folgen wieder vier ASCII-Buchstaben, die den eigentlichen Dateityp beschreiben.
Der weitere Dateiinhalt ist in sogenannte Chunks aufgeteilt, die jeweils aus vier ASCII-Buchstaben Typkennung, einem Langwort Chunklänge und den eigentlichen Daten des Chunks bestehen. Wie der Inhalt eines Chunks strukturiert ist, hängt von seinem Typ ab. Es existieren einige Standard-Chunks, die in jeder IFF-Datei vorkommen können, andere sind in mehreren oder auch nur einem einzigen Dateitypen zulässig.
Alle Langworte im IFF-Format sind big-endian, das höchstwertigste Byte kommt also zuerst, wie es auf dem 68000-Prozessor üblich ist. Chunks, die eine ungerade Länge haben, werden grundsätzlich mit einem Füllbyte versehen, das nicht in der Längenangabe des Chunks mitgezählt wird. Der Grund hierfür ist, dass der Speicher des 68000 in Worten organisiert war und keine Wort- oder Langworte von ungeraden Adressen gelesen werden konnten.
Standard-Chunks
- AUTH - beinhaltet Informationen über den Autor der Datei
- ANNO - enthält meist den Namen des Programms, mit dem die Datei erstellt wurde
- NAME - beschreibt den Namen des in der Datei gespeicherten Werkes
- VERS - die Version der Datei
- (c) - Copyright-Informationen (mit einem Leerzeichen hinter der schließenden Klammer)
Einige IFF-Formate
- ILBM - InterLeaved BitMap, am häufigsten genutztes Amiga-Graphik-Format
- ACBM - Amiga Continuous BitMap, wie ILBM, aber die Bilddaten liegen nicht interleaved vor
- RGBN - Impulse's Silver and Turbo Silver (12 Bit RGB Format)
- RGB8 - Impulse's Silver and Turbo Silver (24 Bit RGB Format)
- 8SVX - Amiga Audio, unkomprimiert, 8 Bit mono
- AIFF - Macintosh Audio, 8-32 Bit, beliebig viele Kanäle
- ANIM - Animationen, unter anderem verwendet von Deluxe-Paint
- DR2D - Vektorgraphik
- FTXT - Text
- SHRI
- SMUS - Musik-Sequenzen, ähnlich den MIDI-Files
- WORD
ILBM-Format
Das ILBM-Format (engl. InterLeaved BitMap) ist das am häufigsten verwendete IFF-Format. Die Bilder können theoretisch in fast allen Farbtiefen gespeichert werden.
Die gebräulichsten sind:
- 1-8 Bit (2-256 Farben)
- 24 Bit (16,8 Mio Farben)
- EHB [Extra-HalfBright] (64 Farben)
- HAM [Hold And Modify] (4096 Farben)
- HAM8 [Hold And Modify AGA] (262144 Farben)
Um ein ein Bild darstellen zu können, muss zunächst der richtige Farb- bzw. Darstellungsmodus ermittelt werden. Dazu benötigt man neben der Anzahl der Planes (BMHD Chunk) auch die Anzahl der Farben (CMAP Chunk). Hat man den Farbmodus bestimmt, weiss man wie die im BODY Chunk abgelegten Bilddaten zu interpretieren sind. Hilfreich ist es auch, wenn ein CAMG Chunk vorhanden ist.
| Farbmode | Bitplanes | Farbpalette |
|---|---|---|
| 1-8 Bit | 1-8 | 2-256 |
| 24 Bit | 24 | CMAP nicht vorhanden |
| EHB | 6 | 32 |
| HAM | 6 | 16 |
| HAM8 | 8 | 64 |
Innerhalb eins FORM-Chunks sind folgende wichtige Chunks zu finden:
BMHD-Chunk
Der BMHD-Chunk (BitMap HeaDer) enthält Informationen über das gespeicherte Bild.
Zum Beispiel:
- Breite und Höhe des Bildes in Pixel
- Anzahl der Bitplanes
- Kompression
CMAP-Chunk
optional
Der CMAP-Chunk (Color MAP) stellt die Farbpalette bereit.
Dieser Chunk ist in 24 Bit IFF Bildern nicht vorhanden.
Jeder Eintrag der Farbpalette besteht aus 3 Byte, die die RGB Werte representieren. Die Anzahl der Farben wird bestimmt indem man die Chunklänge durch 3 teilt.
Beispiel:
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
CAMG-Chunk
optional
Der CAMG-Chunk (Commdore-AMiGa) enthält den Amiga-spezifischen Darstellungsmode.
Dieser Chunk enthält nur einen 32-Bit Wert mit dem Darstellungsmode. Der Amiga kann diesen Wert direkt verarbeiten, andere Systeme können ihn benutzen, um den Darstellungsmode zu identifizieren.
BODY-Chunk
Der BODY-Chunk enthält die eigentlichen Bilddaten.
Diese können komprimiert oder unkomprimiert sein. Die einzelnen Bitplanes liegen hierbei nicht hintereinander sondern ineinander verschachtelt (engl. interleaved) vor. Hierbei werden alle Bitplanes einer Bildzeile hintereinander gespeichert, bevor mit der nächsten Bildzeile begonnen wird.
Die Anzahl der Bytes einer Bildzeile muss durch 8 teilbar sein.
Beispiel für ein 8 Farben Bild (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
Um den Paletteneintrag für einen Pixel zu ermitteln, werden die einzelnen Bits der Planes zu einen Index zusammengefasst.
Berechnung des Indexwertes für den Pixel an Bildposition (0,0):
Index Bit 2 = [Plane 0/ Byte 0/ Bit 7] Index Bit 1 = [Plane 1/ Byte 0/ Bit 7] Index Bit 0 = [Plane 2/ Byte 0/ Bit 7]
Kompression
Die Bilddaten innerhalb des BODY Chunks können in gepackter Form vorliegen, abhängig vom Compression-Flag im BMHD Chunk. Bei der Kompression kommt ein einfacher RLE (run-length encoding)-Algorithmus zum Einsatz.
Der Packer fasst identische Byte-Werte innerhalb einer Bildzeile zusammen. Die Kodierung stoppt am Ende jeder Bildzeile. Die gepackten Bytes werden als zwei-Byte-Codes gespeichert. Das erste Byte gibt den Typ der Komprimierung und die Anzahl an.
- Wenn der Wert (code) im Bereich von 0 bis 127 (unsigned) handelt es sich um ungepackte Daten. Die folgenden code+1 Bytes werden einfach ins Bild kopiert.
- Liegt der Wert (code) im Bereich von -1 bis -127 (signed), handelt es sich um gepackte Daten. Dabei wird das auf den code folgende Byte (-code+1)-mal wiederholt.
- Ein Wert von 128 wird immer ignoriert.
Erweiterungen (Spezielle Chunks)
Aufgrund der Beschränkungen bestimmter Kombinationen von Bildschirmauflösung und Farbtiefe wird versucht, unter Zuhilfenahme des Coppers und dem Einsatz neuer Chunks die Farbtiefe künstlich zu erhöhen. Dabei wird während des Bildaufbaus ständig die Palette verändert.
Die bekanntesten Formate sind:
- Dynamic Hires - nicht HAM Bilder (Palette) mit CTBL Chunk
- Dynamic HAM oder DHAM - HAM Bilder mit CTBL Chunk
- Sliced HAM oder SHAM - HAM Bilder mit SHAM Chunk
- MultiPalette Bilder - PCHG Chunk (Palette Changes)
CTBL-Chunk
CTBL steht für Color TaBLe.
Dieser Chunk enthält, von oben beginnent, für jede Zeile eine neue 16-Farb-Palette. Diese unterscheidet sich allerdings von der Palette im CMAP Chunk dadurch, dass die Paletteneinträge nur 16 Bit und nicht wie üblich 24 Bit sind. Pro Farbkomponente stehen 4 Bit zur Verfügung, die obersten 4 Bit sind ungenutzt.
Chunk-Länge geteilt durch 32 ergibt die Anzahl der im Chunk abgelegten Farbpaletten an. Die Farbpalette folgen dann direkt hintereinander; jeweils 16*2 Byte = 32 Byte.
SHAM-Chunk
SHAM steht für Sliced HAM.
Dieser Chunk hat den gleichen Aufbau wie der CTBL-Chunk. Der einzige Unterschied sind 2 Byte Versionsnummer am Anfang des Chunks, die aber immer 0 sind.