imported>Invisigoth67: typo

2025-06-21T12:56:48Z

typo

Neue Seite

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 [[Type-Length-Value|TLV]]-Struktur (Abk. für ''Type-Length-Value'') auszeichnen.

Das wohl bekannteste ist '''IFF-ILBM''', ein planares [[Rastergrafik|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 [[Audio Interchange File Format|AIFF]], das auf [[Macintosh]]s 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 [[Resource Interchange File Format|RIFF]]. Das bekannteste RIFF-Format ist wahrscheinlich [[RIFF WAVE]], auch bekannt als ''.wav''. Auch andere Formate, wie das von [[Aldus Corporation|Aldus]]/[[Adobe Inc.|Adobe]] entwickelte [[Tagged Image File Format|TIFF]]-Format oder das damit verwandte [[Exchangeable Image File Format|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 [[Byte]]s 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 [[Motorola 68000|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 (Informatik)|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-Format|ILBM]] – Interleaved Bit Map, am häufigsten genutztes Amiga-Grafik-Format ([[Lauflängenkodierung|RLE]]-Kompression)
* [[IFF-PBM|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-Farbraum|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
* [[Audio Interchange File Format|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 [[Musical Instrument Digital Interface|MIDI]]-Files
* [[WORD (Dateiformat)|WORD]] – Dokumentformat des Amiga Textprogramms ProWrite
* [[META (Dateiformat)|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.<ref>{{Webarchiv|url=http://wiki.amigaos.net/index.php/IFF_FORM_and_Chunk_Registry | wayback=20130409163508 | text=Liste aller Chunks/IDs}}</ref> Sie enthält nicht alle Dritterweiterungen, die teilweise gesondert spezifiziert wurden (siehe Links am Ende der Seite).

== ILBM-Format ==
Das ILBM-Format (engl. '''''I'''nter'''L'''eaved '''B'''it'''M'''ap'') 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)
* [[Extra-Halfbright-Modus|EHB]] (Extra-HalfBright, 64 Farben)
* [[Hold-And-Modify-Modus|HAM]] (Hold-And-Modify, 4096 Farben)
* [[Hold-And-Modify-Modus|HAM8]] (Hold-And-Modify [[Advanced Graphics Architecture|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|BMHD-Chunk]]) auch die ''Anzahl der Farben'' ([[#CMAP-Chunk|CMAP-Chunk]]). Hat man den Farbmodus bestimmt, weiß man, wie die im [[#BODY-Chunk|BODY Chunk]] abgelegten Bilddaten zu interpretieren sind. Hilfreich ist es auch, wenn ein [[#CAMG-Chunk|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 ([[Gammakorrektur|Gamma]], [[Farbsättigung|Chromatizität]], [[ICC-Profil|ICC-Farbprofile]] für [[Farbmanagement|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).

{| class="wikitable toptextcells"
|- class="hintergrundfarbe6"
! Farbmode
! Bitplanes
! [[Indizierte Farben|Farbpalette]]
|-
|class="hintergrundfarbe5"| 1–8 Bit
| 1–8
| 2–256 RGB-Triplets in CMAP
|-
|class="hintergrundfarbe5"|24 Bit
| 24
| CMAP nicht vorhanden; 3×8 Bit Truecolor
|-
|class="hintergrundfarbe5"| 32 Bit
| 32
| CMAP nicht vorhanden; 4×8 Bit Truecolor
|-
|class="hintergrundfarbe5"| 48 Bit
| 48
| CMAP nicht vorhanden; 3×16 Bit Truecolor
|-
|class="hintergrundfarbe5"| 64 Bit
| 64
| CMAP nicht vorhanden; 4×16 Bit Truecolor
|-
|class="hintergrundfarbe5"| EHB
| 6
| 32 RGB-Triplets in CMAP
|-
|class="hintergrundfarbe5"| HAM
| 6
| 16 RGB-Triplets in CMAP
|-
|class="hintergrundfarbe5"| HAM8
| 8
| 64 RGB-Triplets in CMAP
|}

Innerhalb eines FORM-Chunks sind folgende wichtige Chunks zu finden:

=== BMHD-Chunk ===
Der BMHD-Chunk ''('''B'''it'''M'''ap '''H'''ea'''D'''er)'' 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 ''('''C'''olor '''MAP''')'' stellt die Farbpalette (auch [[Indizierte Farben|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:
<syntaxhighlight lang="text">
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
</syntaxhighlight>

=== CRNG- und CCRT-Chunk ===
''optional''

Sowohl der CRNG- ''('''C'''olor register '''R'''a'''NG'''e)'' als auch der CCRT-Chunk ''('''C'''olor '''C'''ycling '''R'''ange and '''T'''iming)'' legen die Daten für das ''Color Cycling'' fest (siehe [[Indizierte Farben#Farbtabellenrotation|Indizierte Farben]]). Mit diesem Mittel sind einfache [[Animation]]en 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 ('''C'''ommdore-'''AM'''i'''G'''a) 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 [[Hardwaresteuerregister]]s seines [[Original Chip Set|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 [[Portable Network Graphics|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 File Interchange Format|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 [[Bitplane]]s 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):
<syntaxhighlight lang="text">
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
</syntaxhighlight>

Um den Paletteneintrag für ein Pixel zu ermitteln, werden die einzelnen Bits der Planes zu einem Index zusammengefasst.

{| border="0"
|+ Indexwert für das Pixel an Bildposition (0,0)
! Index Bit!! Berechnung
|-
! 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 [[Lauflängenkodierung|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 [[Amiga Copper|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 '''C'''olor '''T'''a'''BL'''e.

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 '''S'''liced '''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 '''P'''alette '''CH'''an'''G'''es.

== Weblinks ==
* [https://www.dcs.ed.ac.uk/home/mxr/gfx/2d/IFF.txt Electronic Arts’ IFF standard for Interchange File Format] (englisch)
* [https://www.digitalpreservation.gov/formats/fdd/fdd000115.shtml IFF] in den Digitalformaten der ''Library of Congress Collections'' (englisch)
* {{Webarchiv|url=http://www.users.bigpond.com/james.jacobs/reg/iff.html | wayback=20060318152340 | text=IFF-FORM- und Chunk-Registrierung}} (englisch)
* {{Webarchiv|url=http://www.gangstah.net/portal/Fileformats/IFFILBM.stm | wayback=20040614214731 | text=IFF}} in ''Cool Intelligent Algorithms'' (englisch)
* [https://aminet.net/docs/misc/IFF-metadata.zip IFF-META-Spezifikation] ([[ZIP-Dateiformat|ZIP]]; 3 kB) im Aminet (englisch)
* [https://aminet.net/docs/misc/ILBM64.zip IFF-ILBM 64-Bit-Spezifikation] ([[ZIP-Dateiformat|ZIP]]; 1 kB) im Aminet (englisch)
* [https://aminet.net/dev/misc/IFF-RGFX.zip IFF-RGFX-Spezifikation] ([[ZIP-Dateiformat|ZIP]]; 10 kB) im Aminet (englisch)

== Einzelnachweise ==
<references />

[[Kategorie:Datenformat]]
[[Kategorie:Grafikformat]]
[[Kategorie:Containerformat]]

Interchange File Format - Versionsgeschichte

imported>Invisigoth67: typo