Interchange File Format

Das Interchange File Format (IFF) wurde 1985 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 die gemeinsame TLV-Struktur (Abk. für Type-Length-Value) auszeichnen.

Das wohl bekannteste ist IFF-ILBM, ein planares Bitmap-Grafikformat (ursprünglich nur für 8 Bit, später auf 24/32 Bit erweitert), das auf Amiga-Rechnern benutzt wird. Das Malprogramm Deluxe Paint trug wesentlich zur Verbreitung des Formats bei. Seit Deluxe Paint – neben Atari ST – auch für IBM-PC portiert wurde, fand auch das IFF-Format eine neue Heimat und weitere Verbreitung, auf PCs wird meistens die Dateiendung .LBM benutzt. Ein ähnlich bekanntes IFF-Dateiformat ist AIFF, das auf Macintoshs häufigste Format für unkomprimierte Audio-Dateien.

Microsoft kopierte das Prinzip der IFF-Dateien, organisierte die Byte-Reihenfolge (Endianness) der Daten darin im Gegensatz zum Original von Big-Endian nach Little-Endian und nannte das Ergebnis RIFF. Das bekannteste RIFF-Format ist wahrscheinlich RIFF WAVE, auch bekannt als .wav. Auch andere Formate, wie das von Aldus/Adobe entwickelte TIFF-Format oder das damit verwandte Exif besitzen eine flexible Dateistruktur (hier auf Basis von sogenannten Tags). Diese Struktur resultiert ebenfalls in von der Größe her frei definierbaren Datenblöcken, die interne Dateiorganisation ist jedoch eine vollkommen andere und eher mit einem Dateisystem wie FAT vergleichbar (bestehend aus einem tabellarischen Verzeichnis von Tags, die Werte oder Offsets zu Werten enthalten).

Struktur

IFF-Dateien beginnen in der Regel mit dem FourCC (Abk. für Four Character Code) FORM, gefolgt von einem aus vier Bytes geformten Langwort, das die Länge der gesamten Datei ohne diese ersten acht Bytes beinhaltet. Darauf folgt wieder ein FourCC, der den eigentlichen Dateityp angibt.

Ein noch allgemeinerer Dateityp beginnt mit dem FourCC CAT  (mit Leerzeichen am Ende, für Catalog, dt. etwa Liste, Zusammenstellung), der eine Reihe von FORM-Datensätzen, wie sie hier beschrieben werden, hintereinander enthält. Damit können auch völlig verschiedene Arten von Daten, wie Audio, Animation und Einzelbilder, in einer einzigen Datei zusammengefasst werden, also ein „Container“-Format nach heutiger Sprachregelung.

Der weitere Dateiinhalt ist in sogenannte Chunks (engl.: Stück, Klotz, Klumpen) aufgeteilt, die jeweils aus einem FourCC, einem 32-Bit-Wort Chunk-Lä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 Dateityp zulässig.

Alle Langworte im IFF-Format sind big-endian, das höchstwertige 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 („Padding“). 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 – davon abgesehen ist auch mit neueren CPUs die Verarbeitung von Daten im Speicher schneller, wenn sie an 16- bzw. 32-Bit-Grenzen ausgerichtet sind.

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 Bit Map, am häufigsten genutztes Amiga-Grafik-Format (RLE-Kompression)
  • PBM – Wird von Deluxe-Paint IIe (PC-Version) zur Speicherung von 256-Farben-Bildern genutzt (RLE-Kompression)
  • ACBM – Amiga Continuous Bit Map, wie ILBM, aber die Bilddaten liegen nicht interleaved vor (RLE-Kompression)
  • 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 Farben und 24 bis 96-Bit-RGB-Format (HDR); XPK- oder ZIP/LZ77-Kompression)
  • 8SVX – Amiga Audio, unkomprimiert (opt. Fibonacci Delta-komprimiert), 8 Bit, Kanäle einzeln
  • AIFF – Macintosh Audio, 8 bis 32 Bit, beliebig viele Kanäle
  • ANIM – Animationen, unter anderem verwendet von Deluxe-Paint
  • DR2D – Vektorgraphik
  • FTXT – Text
  • SHRI – SHRINK-Kompression, einer der stärksten Datenkompressionsalgorithmen der XPKmaster.library unter AmigaOS, vergleichbar mit LZ77
  • SMUS – Musik-Sequenzen, ähnlich den MIDI-Files
  • WORD – Dokumentformat des Amiga Textprogramms ProWrite
  • META – Allgemeiner Container für Metadaten (AUTH, ANNO, NAME, Exif, XMP0, XMP1, ICC, GeoT(IFF) etc.)

Vollständige Format- und Chunkliste

Eine Liste aller Chunks/IDs ist bei amigaos.net verfügbar.[1] Sie enthält nicht alle Dritterweiterungen, die teilweise gesondert spezifiziert wurden (siehe Links am Ende der Seite).

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äuchlichsten sind:

  • 1 bis 8 Bit (2 bis 256 Farben)
  • 24 Bit (3×8 Bit; 16,8 Mio. Farben)
  • 32 Bit (3×8 Bit; 16,8 Mio. Farben mit Alphakanal)
  • 48 Bit (3×16 Bit; HDR)
  • 64 Bit (3×16 Bit; HDR mit Alphakanal)
  • EHB (Extra-HalfBright, 64 Farben)
  • HAM (Hold-And-Modify, 4096 Farben)
  • HAM8 (Hold-And-Modify AGA, 262144 Farben)

Um 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, weiß man, wie die im BODY Chunk abgelegten Bilddaten zu interpretieren sind. Hilfreich ist es auch, wenn ein CAMG-Chunk vorhanden ist. Da sich die Technik seit der Entwicklung von IFF-ILBM stetig weiterentwickelt hat, sind außerdem Anforderungen hinzugekommen, die es nötig machen, weitergehende Farbprofil-Informationen zu transportieren (Gamma, Chromatizität, ICC-Farbprofile für Color Management). Hierfür wurden Erweiterungen von dritter Seite definiert, die zur korrekten Interpretation von Bilddaten ebenfalls nötig sein können (GAMA, CHRM, ICCP Chunks).

Farbmode Bitplanes Farbpalette
1–8 Bit 1–8 2–256 RGB-Triplets in CMAP
24 Bit 24 CMAP nicht vorhanden; 3×8 Bit Truecolor
32 Bit 32 CMAP nicht vorhanden; 4×8 Bit Truecolor
48 Bit 48 CMAP nicht vorhanden; 3×16 Bit Truecolor
64 Bit 64 CMAP nicht vorhanden; 4×16 Bit Truecolor
EHB 6 32 RGB-Triplets in CMAP
HAM 6 16 RGB-Triplets in CMAP
HAM8 8 64 RGB-Triplets in CMAP

Innerhalb eines 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 (auch CLUT) bereit.

Dieser Chunk ist in 24-/32-/48-/64-Bit-IFF-Bildern nicht vorhanden.

Jeder Eintrag der Farbpalette besteht aus drei Bytes, die die RGB-Werte repräsentieren. Die Anzahl der Farben wird bestimmt, indem man die Chunk-Länge durch drei 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

CRNG- und CCRT-Chunk

optional

Sowohl der CRNG- (Color register RaNGe) als auch der CCRT-Chunk (Color Cycling Range and Timing) legen die Daten für das Color Cycling fest (siehe Indizierte Farben). Mit diesem Mittel sind einfache Animationen darstellbar, die die Grafikhardware extrem gering belasten. Die beiden Chunk-Formate sind unterschiedlich aufgebaut und kommen normalerweise nicht beide in derselben Datei vor.

Dieser Chunk ist in 24-/32-/48-/64-Bit-IFF-Bildern nicht vorhanden, da auch ein CMAP-Chunk (vorangehend) erforderlich ist.

In den Chunks finden sich Angaben, von welcher Farbnummer bis zu welcher anderen ein zu animierender Farbbereich reichen soll. Zusätzlich wird die Pausenlänge zwischen den einzelnen Zyklen in Sekunden und Mikrosekunden angegeben.

Eine Datei kann auch mehrere solcher Color-Cycling-Chunks enthalten, so dass verschiedene Bereiche der Farbpalette gleichzeitig und sogar mit verschiedenen Geschwindigkeiten animiert werden können.

CAMG-Chunk

optional

Der CAMG-Chunk (Commdore-AMiGa) enthält den Amiga-spezifischen Darstellungsmodus.

Dieser Chunk enthält nur einen 32-Bit-Wert mit dem Darstellungsmodus. Der Amiga kann diesen Wert direkt verarbeiten (es ist direkt der Inhalt eines Hardwaresteuerregisters seines Chipsatzes); andere Systeme können ihn benutzen, um den Darstellungsmodus zu identifizieren.

ICCP/ICCN, GAMA, CHRM Chunks

optional

Diese Chunks entsprechen inhaltlich den gleichnamigen Chunks aus dem PNG-Format (bis auf den ersten Buchstaben, der klein geschrieben ist) und wurden von dritter Seite im 'ILBM64'-Format (64 Bit-Erweiterungen für IFF-ILBM) definiert, um Gamma-/Chromacity- und ICC-Farbprofilinformationen in IFF einbetten zu können. Die Verwendung ist nicht auf ILBM beschränkt, sondern gleichermaßen mit anderen IFF-Grafikformaten möglich.

Exif, IPTC, XMP0, XMP1, ICC, GEOT

optional

Diese Chunks entsprechen inhaltlich in etwa den gleichnamigen Chunks bzw. Markern aus dem JPEG (JFIF), PNG oder TIFF-Format und dienen dazu, Metadaten nach XMP-Standard, Exif-Tags, ICC-Farbprofile, GeoTIFF-Daten oder IPTC-Schlagworte in IFF-Formaten abspeichern zu können. Die Verwendung ist nicht auf IFF-Grafikformate beschränkt, sondern gleichermaßen mit anderen IFF-Formaten möglich. Sie wurden von dritter Seite in den "IFF-META"-Erweiterungen definiert.

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 ein Pixel zu ermitteln, werden die einzelnen Bits der Planes zu einem Index zusammengefasst.

Indexwert für das Pixel an Bildposition (0,0)
Index BitBerechnung
2 Plane 0/ Byte 0/ Bit 7
1 Plane 1/ Byte 0/ Bit 7
0 Plane 2/ Byte 0/ Bit 7

Bei 24/32/48/64 Bit-Bildern ist die Plane-Reihenfolge stets R-G-B-A (Rot-Grün-Blau-Alpha).

Kompression

Die Bilddaten innerhalb des BODY-Chunks können unkomprimiert (Typ 0) oder in gepackter Form vorliegen, abhängig vom Compression-Flag im BMHD-Chunk. Bei der Kompression kommt ein einfacher RLE (run-length encoding)-Algorithmus names CmpByteRun1 (Typ 1) zum Einsatz, der praktisch identisch zu ähnlichen Verfahren in PCX oder TIFF ist. Später definierte das AmigaOS in der Version V44 noch CmpByteRun2 (Typ 2), was jedoch nicht dokumentiert wurde und daher allgemein ungebräuchlich ist.

Der CmpByteRun1-Encoder 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) liegt, 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 (Details folgen unten):

  • 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

All diese Erweiterungen sind ungebräuchlich, da sehr Hardware-abhängig. Konventionelle HAM6/8-Dateien lassen sich dagegen einfach in andere übliche Truecolor-Bit-Grafikformate konvertieren.

Dem Stand der Technik für höhere Farbtiefen als 24 (32) Bit entsprechen die 48 (64 Bit)-Erweiterungen. Damit sind HDR-Darstellungen möglich (16 Bit pro Farbkanal).

CTBL-Chunk

CTBL steht für Color TaBLe.

Dieser Chunk enthält, von oben beginnend, 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 breit 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 Farbpaletten folgen dann direkt hintereinander; jeweils 16×2 Byte = 32 Byte.

Diese Erweiterung ist ungebräuchlich.

SHAM-Chunk

SHAM steht für Sliced HAM.

Dieser Chunk hat den gleichen Aufbau wie der CTBL-Chunk. Der einzige Unterschied sind zwei Bytes Versionsnummer am Anfang des Chunks, die aber immer 0 sind.

Diese Erweiterung ist ungebräuchlich.

PCHG-Chunk

PCHG steht für Palette CHanGes.

Einzelnachweise
  1. Liste aller Chunks/IDs (Memento vom 9. April 2013 im Internet Archive)
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.