JPEG File Interchange Format – Wikipedia
Bilddateiformat mit mehreren Editionen
Das JPEG File Interchange Format ((JFIF) ist ein Standard für das Bilddateiformat. Es definiert zusätzliche Spezifikationen für das Containerformat, das die mit dem JPEG-Algorithmus codierten Bilddaten enthält. Die Basisspezifikationen für ein JPEG-Containerformat sind in Anhang B des JPEG-Standards definiert, der als JPEG Interchange Format (JIF) bezeichnet wird. JFIF baut auf JIF auf, um einige der Einschränkungen von JIF zu lösen, einschließlich unnötiger Komplexität, Registrierung von Komponentenproben, Auflösung, Seitenverhältnis und Farbraum. Da JFIF ein zusätzlicher Standard ist, kann das resultierende Dateiformat als “JPEG / JFIF” bezeichnet werden.
JFIF ist nicht mit dem neueren austauschbaren Bilddateiformat (Exif) kompatibel.
Zweck[edit]
JFIF definiert eine Reihe von Details, die in der JPEG Part 1-Norm (ISO / IEC 10918-1, ITU-T-Empfehlung T.81) nicht spezifiziert sind.[1]
Registrierung von Komponentenmustern[edit]
Mit JPEG können mehrere Komponenten (wie Y, Cb und Cr) unterschiedliche Auflösungen haben, es wird jedoch nicht definiert, wie diese unterschiedlichen Sample-Arrays ausgerichtet werden sollen. Der JFIF-Standard verlangt, dass Abtastwerte “interstitiell” angeordnet werden – was bedeutet, dass der Decodierer jedes Komponentenarray so behandeln kann, dass es ein Array gleichgroßer rechteckiger Pixel darstellt, die in ihren Zentren abgetastet werden, wobei jedes Array die gleichen Außengrenzen wie das Bild aufweist. Dies ist praktisch für Computerbenutzer, entspricht jedoch nicht der Ausrichtung, die in MPEG-2 und den meisten Videoanwendungen verwendet wird.
Auflösung und Seitenverhältnis[edit]
Der JPEG-Standard enthält keine Methode zum Codieren der Auflösung oder des Seitenverhältnisses eines Bildes. JFIF bietet Informationen zur Auflösung oder zum Seitenverhältnis mithilfe einer Anwendungssegmenterweiterung für JPEG. Es verwendet das Anwendungssegment Nr. 0 mit einem Segmentheader, der aus der nullterminierten Zeichenfolge “JFIF” in ASCII gefolgt von einem Byte gleich 0 besteht, und gibt an, dass dies das erste Segment in der Datei sein muss, wodurch es einfach wird eine JFIF-Datei erkennen. Von Digitalkameras aufgenommene Exif-Bilder enthalten dieses Segment im Allgemeinen nicht, entsprechen jedoch in der Regel im Übrigen dem JFIF-Standard.
Farbraum[edit]
Der für die Komprimierungscodierung in JFIF-Dateien verwendete JPEG-Standard definiert nicht, welche Farbcodierung für Bilder verwendet werden soll. JFIF definiert das zu verwendende Farbmodell: entweder Y für Graustufen oder YCbCr, abgeleitet von RGB-Farbprimären gemäß CCIR 601 (jetzt bekannt als Rec. ITU-R BT.601), außer mit einer anderen “Vollbereich” -Skalierung von die Y-, Cb- und Cr-Komponenten. Im Gegensatz zu dem in CCIR 601 definierten “Studio-Bereich”, in dem Schwarz durch Y = 16 und Weiß durch Y = 235 dargestellt wird und Werte außerhalb dieses Bereichs für die Signalverarbeitung “Headroom” und “Footroom” verfügbar sind, verwendet JFIF alle 256 Ebenen der 8-Bit-Darstellung, so dass Y = 0 für Schwarz und Y = 255 für Peak White. Die in JFIF über CCIR 601 definierten RGB-Farbprimäre unterscheiden sich ebenfalls etwas von der in neueren Anwendungen üblichen Praxis (z. B. unterscheiden sie sich geringfügig von den in sRGB definierten Farbprimären). Darüber hinaus lieferte CCIR 601 (vor 2007) keine genaue Definition der RGB-Farbprimäre; es stützte sich stattdessen auf die zugrunde liegenden Praktiken der Fernsehindustrie.
Die Farbinterpretation eines JFIF-Bildes kann verbessert werden, indem ein ICC-Profil, Farbraum-Metadaten oder ein sRGB-Tag eingebettet und eine Anwendung verwendet wird, die diese Informationen interpretiert.
Dateiformatstruktur[edit]
Eine JFIF-Datei besteht aus einer Folge von Markern oder Markersegmenten (Einzelheiten siehe JPEG, Syntax und Struktur). Die Marker sind in Teil 1 des JPEG-Standards definiert.[1] Jeder Marker besteht aus zwei Bytes: an FF Byte gefolgt von einem Byte, das nicht gleich ist 00 oder FF und gibt den Typ des Markers an. Einige Marker stehen für sich allein, aber die meisten zeigen den Beginn eines Markersegments an, das Datenbytes gemäß dem folgenden Muster enthält:
FF xx s1 s2 [data bytes]
Die Bytes s1 und s2 werden zusammengenommen, um eine Big-Endian-16-Bit-Ganzzahl darzustellen, die die Länge der folgenden “Datenbytes” plus die 2 Bytes angibt, die zur Darstellung der Länge verwendet werden. Mit anderen Worten, s1 und s2 Geben Sie die Nummer der folgenden an Datenbytes wie
.
.
Gemäß Teil 1 des JPEG-Standards können Anwendungen APP-Markersegmente verwenden und eine anwendungsspezifische Bedeutung der Daten definieren. Im JFIF-Standard sind die folgenden APP-Markersegmente definiert:
- JFIF APP0-Markersegment (kurz JFIF-Segment) (obligatorisch)
- JFIF-Erweiterung APP0-Markersegment (kurz JFXX-Segment) (optional)
Sie werden unten beschrieben.
Der JFIF-Standard verlangt, dass das JFIF APP0-Markersegment unmittelbar auf den SOI-Marker folgt. Wenn ein JFIF-Erweiterungs-APP0-Markersegment verwendet wird, muss es unmittelbar auf das JFIF-APP0-Markersegment folgen.[2] Eine JFIF-Datei hat also die folgende Struktur:
| JFIF-Dateistruktur | ||
|---|---|---|
| Segment | Code | Beschreibung |
| SOI | FF D8 |
Start des Bildes |
| JFIF-APP0 | FF E0 s1 s2 4A 46 49 46 00 ... |
siehe unten |
| JFXX-APP0 | FF E0 s1 s2 4A 46 58 58 00 ... |
optional, siehe unten |
| … Zusätzliche Markersegmente (zum Beispiel SOF, DHT, COM) |
||
| SOS | FF DA |
Start des Scans |
| komprimierte Bilddaten | ||
| EOI | FF D9 |
Bildende |
JFIF APP0-Markersegment[edit]
Im obligatorischen JFIF APP0-Markersegment werden die Parameter des Bildes angegeben. Optional kann eine unkomprimierte Miniaturansicht eingebettet werden.
| JFIF APP0-Markersegment | ||
|---|---|---|
| Feld | Größe (Bytes) | Beschreibung |
| APP0-Marker | 2 | FF E0
|
| Länge | 2 | Länge des Segments ohne APP0-Marker |
| Kennung | 5 | 4A 46 49 46 00 = “JFIF” in ASCII, abgeschlossen durch ein Nullbyte
|
| JFIF-Version | 2 | Erstes Byte für Hauptversion, zweites Byte für Nebenversion (01 02 für 1,02)
|
| Dichteeinheiten | 1 | Einheiten für die folgenden Pixeldichtefelder
|
| Dichte | 2 | Horizontale Pixeldichte. Darf nicht Null sein |
| Dichte | 2 | Vertikale Pixeldichte. Darf nicht Null sein |
| Xthumbnail | 1 | Horizontale Pixelanzahl der folgenden eingebetteten RGB-Miniaturansicht. Kann Null sein |
| Ythumbnail | 1 | Vertikale Pixelanzahl der folgenden eingebetteten RGB-Miniaturansicht. Kann Null sein |
| Miniaturbilddaten | 3 × n | Unkomprimierte 24-Bit-RGB-Raster-Miniaturdaten (8 Bit pro Farbkanal) in der Reihenfolge R0, G0, B0, … Rn-1, Gn-1, Bn-1; mit n = Xthumbnail × Ythumbnail |
JFIF-Erweiterung APP0-Markersegment[edit]
Unmittelbar nach dem JFIF-APP0-Markersegment kann sich ein JFIF-Erweiterungs-APP0-Markersegment befinden. Dieses Segment ist möglicherweise nur für JFIF-Versionen 1.02 und höher vorhanden. Es ermöglicht das Einbetten eines Miniaturbilds in 3 verschiedenen Formaten.
| JFIF-Erweiterung APP0-Markersegment | ||
|---|---|---|
| Feld | Größe (Bytes) | Beschreibung |
| APP0-Marker | 2 | FF E0
|
| Länge | 2 | Länge des Segments ohne APP0-Marker |
| Kennung | 5 | 4A 46 58 58 00 = “JFXX” in ASCII, abgeschlossen durch ein Nullbyte
|
| Miniaturbildformat | 1 | Gibt an, welches Datenformat für die folgende eingebettete Miniaturansicht verwendet wird:
|
| Miniaturbilddaten | Variable | Abhängig vom Miniaturbildformat, siehe unten |
Die Miniaturbilddaten hängen wie folgt vom Miniaturbildformat ab:
| Miniaturansicht mit JPEG-Codierung gespeichert | ||
|---|---|---|
| Feld | Größe (Bytes) | Beschreibung |
| SOI | 2 | FF D8
|
| Variable | Muss das JIF-Format mit YCbCr oder nur Y haben und darf keine JFIF- oder JFXX-Segmente enthalten | |
| EOI | 2 | FF D9
|
| Miniaturansicht mit einem Byte pro Pixel gespeichert | ||
|---|---|---|
| Feld | Größe (Bytes) | Beschreibung |
| Xthumbnail | 1 | Horizontale Pixelanzahl der folgenden eingebetteten Miniaturansicht. Darf nicht Null sein |
| Ythumbnail | 1 | Vertikale Pixelanzahl der folgenden eingebetteten Miniaturansicht. Darf nicht Null sein |
| Miniaturbild-Palette | 768 | 256 Paletteneinträge mit jeweils einem 24-Bit-RGB-Farbwert |
| Miniaturbilddaten | n | Ein Byte pro Pixel, das den Index der Farbe in der Palette enthält.
mit n = Xthumbnail × Ythumbnail |
| Miniaturansicht mit drei Byte pro Pixel gespeichert | ||
|---|---|---|
| Feld | Größe (Bytes) | Beschreibung |
| Xthumbnail | 1 | Horizontale Pixelanzahl der folgenden eingebetteten Miniaturansicht. Darf nicht Null sein |
| Ythumbnail | 1 | Vertikale Pixelanzahl der folgenden eingebetteten Miniaturansicht. Darf nicht Null sein |
| Miniaturbilddaten | 3 × n | Unkomprimierte 24-Bit-RGB-Raster-Miniaturdaten (8 Bit pro Farbkanal) in der Reihenfolge R0, G0, B0, … Rn-1, Gn-1, Bn-1; mit n = Xthumbnail × Ythumbnail |
Kompatibilität[edit]
Das neuere austauschbare Bilddateiformat (Exif) ist mit JFIF vergleichbar, aber die beiden Standards sind nicht miteinander kompatibel. Dies liegt daran, dass beide Standards festlegen, dass ihr bestimmtes Anwendungssegment (APP0 für JFIF, APP1 für Exif) unmittelbar dem SOI-Marker folgen muss. In der Praxis erzeugen viele Programme und Digitalkameras Dateien mit beiden Anwendungssegmenten. Dies wirkt sich bei den meisten Decodern nicht auf die Bilddecodierung aus, aber schlecht gestaltete JFIF- oder Exif-Parser erkennen die Datei möglicherweise nicht richtig.
JFIF ist mit den JPEG-Erweiterungen “Information Resource Block” von Adobe Photoshop und den Metadaten des IPTC Information Interchange Model kompatibel, da JFIF andere Anwendungssegmente nicht ausschließt und die Photoshop-Erweiterungen nicht die ersten in der Datei sein müssen. In Photoshop werden CMYK-Puffer jedoch im Allgemeinen als Vierkomponenten-Adobe JPEGs gespeichert, die nicht mit JFIF kompatibel sind. Da sich diese Dateien nicht in einem YCbCr-Farbraum befinden, können sie normalerweise nicht von Webbrowsern und anderer Internet-Software dekodiert werden.
Geschichte[edit]
Die Entwicklung des JFIF-Dokuments wurde von Eric Hamilton von C-Cube Microsystems geleitet. Die Vereinbarung über die erste Version wurde Ende 1991 bei einem Treffen bei C-Cube getroffen, an dem etwa 40 Vertreter verschiedener Computer-, Telekommunikations- und Bildgebungsunternehmen teilnahmen. Kurz darauf wurde eine geringfügige Überarbeitung veröffentlicht – JFIF 1.01.[3] Fast 20 Jahre lang war die neueste verfügbare Version v1.02, veröffentlicht am 1. September 1992.[2]
In RFC 2046 wurde 1996 festgelegt, dass das für die Übertragung von JPEG-Bildern über das Internet verwendete Bildformat JFIF sein sollte. Der MIME-Typ “image / jpeg” muss als JFIF codiert sein. In der Praxis kann jedoch praktisch jede Internet-Software jede Basislinie dekodieren JIF Bild, das Y- oder YCbCr-Komponenten verwendet, unabhängig davon, ob es JFIF-kompatibel ist oder nicht.
Im Laufe der Zeit wurde C-Cube umstrukturiert (und schließlich in Harmonic, LSI Logic, Magnum Semiconductor, Avago Technologies, Broadcom und GigOptix, GigPeak usw. umgewandelt) und verlor das Interesse an dem Dokument, und die Spezifikation hatte keinen offiziellen Herausgeber bis es um 2009 von Ecma International und der Joint Photographic Experts Group von ITU-T / ISO / IEC aufgegriffen wurde, um zu vermeiden, dass es in der Geschichte verloren geht, und eine Möglichkeit bietet, es in Standardpublikationen formell zu zitieren und seine redaktionelle Qualität zu verbessern. Es wurde 2009 von der ECMA als Technischer Bericht Nr. 98 veröffentlicht, um den Verlust der historischen Aufzeichnung zu vermeiden.[3]
und es wurde 2011 von ITU-T als Empfehlung T.871 formell standardisiert[4]
und von ISO / IEC im Jahr 2013 als ISO / IEC 10918-5,[5] Die neueren Veröffentlichungen enthielten redaktionelle Verbesserungen, jedoch keine wesentlichen technischen Änderungen.
Recent Comments