WebP-Containerspezifikation

Einführung

WebP ist ein Bildformat, das entweder (i) die VP8-Schlüsselframe-Codierung zur verlustbehafteten Komprimierung von Bilddaten oder (ii) die verlustfreie WebP-Codierung verwendet. Durch diese Codierungsschemata sollte es effizienter sein als ältere Formate wie JPEG, GIF und PNG. Es ist für eine schnelle Bildübertragung über das Netzwerk (für z. B. für Websites). Das WebP-Format bietet dieselben Funktionen wie andere Formate (z. B. Farbprofil, Metadaten, Animation). In diesem Dokument wird die Struktur einer WebP-Datei beschrieben.

Der WebP-Container (d. h. der RIFF-Container für WebP) ermöglicht eine Funktionsunterstützung, die über den grundlegenden Anwendungsfall von WebP hinausgeht (d. h. eine Datei mit einem einzelnen Bild, das als VP8-Schlüsselframe codiert ist). Der WebP-Container bietet zusätzliche Unterstützung für Folgendes:

  • Verlustfreie Komprimierung: Ein Bild kann mithilfe der Methode Verlustfreies WebP-Format.

  • Metadaten: Für ein Bild können Metadaten in der austauschbaren Bilddatei gespeichert sein. Format (Exif) oder XMP (Extensible Metadata Platform).

  • Transparenz: Ein Bild kann Transparenz haben, d. h. einen Alphakanal.

  • Farbprofil: Ein Bild kann ein eingebettetes ICC-Profil enthalten, wie vom International Color Consortium beschrieben.

  • Animation: Ein Bild kann mehrere Frames mit Pausen dazwischen haben, in eine Animation verwandeln.

Benennung

Wir empfehlen, die folgenden Typen zu verwenden, wenn Sie sich auf den WebP-Container beziehen:

Name des ContainerformatsWebP
Dateinamenserweiterung.webp
MIME-TypBild/WebP
Uniform Type Identifierorg.webmproject.webp

Terminologie und Grundlagen

Die Keywords "MUSS", "DARF NICHT", "ERFORDERLICH", "WIRD", "WIRD NICHT", "SOLLTE", „Sollte nicht“, „EMPFOHLEN“, „NICHT EMPFOHLEN“, „KANN“ und „OPTIONAL“ in diesem Dokumente sind wie in BCP 14 RFC 2119 und RFC 8174 beschrieben zu interpretieren wann und nur wenn sie wie hier gezeigt in Großbuchstaben erscheinen.

Eine WebP-Datei enthält entweder ein Standbild (d. h. eine codierte Pixelmatrix) oder eine Animation. Optional können sie auch Transparenzinformationen, ein Farbprofil und Metadaten enthalten. Wir bezeichnen die Pixelmatrix als Canvas des Bildes

Die Bitnummerierung in Blockdiagrammen beginnt bei 0 für das höchstwertige Bit („MSB 0“), wie in RFC 1166 beschrieben.

Im Folgenden finden Sie weitere Begriffe, die in diesem Dokument verwendet werden:

Leser/Schreiber
Code, der WebP-Dateien liest, wird als Reader bezeichnet, während Code, der sie schreibt, als Writer bezeichnet wird.
uint16
Eine vorzeichenlose 16-Bit-Ganzzahl im Little-Endian-Format.
uint24
Eine vorzeichenlose 24-Bit-Ganzzahl im Little-Endian-Format.
uint32
Eine 32-Bit-Little-Endian-Ganzzahl ohne Vorzeichen
FourCC
Ein Vierzeichencode (FourCC) ist ein uint32, der durch Zusammenführen von vier ASCII-Zeichen in Little-Endian-Reihenfolge erstellt wird. Das bedeutet, dass „aaaa“ (0x61616161) und „AAAA“ (0x41414141) als unterschiedliche FourCCs behandelt werden.
1-basiert
Ein vorzeichenloses Ganzzahlfeld, in dem um -1 verschobene Werte gespeichert werden, z. B. eine solche würde den Wert 25 als 24 speichern.
ChunkHeader('ABCD')
Wird verwendet, um die Header FourCC und Chunk Size einzelner Blöcke zu beschreiben, wobei „ABCD“ ist der FourCC für den Chunk. Dieses Element ist 8 Byte groß.

RIFF-Dateiformat

Das WebP-Dateiformat basiert auf dem Dokumentformat RIFF (Resource Interchange File Format).

Das grundlegende Element einer RIFF-Datei ist ein Chunk. Sie besteht aus:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Chunk FourCC                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Chunk Size                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         Chunk Payload                         :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chunk FourCC: 32 Bit
ASCII-Vierzeichencode zur Chunk-Identifikation.
Blockgröße: 32 Bit (uint32)
Die Größe des Blocks in Byte, ohne dieses Feld, den Block Kennung oder Abstand.
Blocknutzlast: Blockgröße in Byte
Die Datennutzlast. Wenn die Chunk-Größe eine ungerade Zahl ist, wird ein einzelnes Padding-Byte hinzugefügt, das gemäß RIFF 0 sein MUSS.

Hinweis: Bei RIFF sind FourCCs in Großbuchstaben Standard-Chunks, die für jedes RIFF-Dateiformat gelten. FourCCs, die für ein Dateiformat spezifisch sind, sind dagegen in Kleinbuchstaben. WebP folgt dieser Konvention nicht.

WebP-Dateiheader

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'R'      |      'I'      |      'F'      |      'F'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           File Size                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'W'      |      'E'      |      'B'      |      'P'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
„RIFF“: 32 Bit
Die ASCII-Zeichen „R“, „I“, „F“ und „F“.
Dateigröße: 32 Bit (uint32)
Die Größe der Datei in Byte, ab Offset 8. Der Maximalwert von enthält dieses Feld 2^32 minus 10 Byte, sodass die Größe der gesamten Datei bei höchstens 4 GiB minus 2 Byte.
„WEBP“: 32 Bit
Die ASCII-Zeichen „W“, „E“, „B“ und „P“.

Eine WebP-Datei MUSS mit einem RIFF-Header mit dem FourCC 'WEBP' beginnen. Die Dateigröße im Header ist die Gesamtgröße der nachfolgenden Blöcke plus 4 Byte für das FourCC-Format „WEBP“. Die Datei DARF KEINE Daten im Anschluss an die Daten enthalten. die durch die Dateigröße festgelegt wird. Leser KÖNNEN solche Dateien parsen und die abschließenden Daten ignorieren. Da die Größe jedes Blocks gerade ist, ist die durch den RIFF-Header angegebene Größe und sogar gleichmäßig. Der Inhalt einzelner Blöcke wird im Folgenden beschrieben .

Simple File Format (verlustbehaftet)

Dieses Layout SOLLTE verwendet werden, wenn das Bild eine verlustbehaftete Codierung erfordert und die Transparenz oder andere erweiterte Funktionen des erweiterten Formats erfordern. Dateien mit diesem Layout sind kleiner und werden von älterer Software unterstützt.

Einfaches WebP-Dateiformat (verlustbehaftet):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    WebP file header (12 bytes)                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        'VP8 ' Chunk                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VP8-Chunk:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('VP8 ')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           VP8 data                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VP8-Daten: Chunk-Größe in Byte
VP8-Bitstream-Daten.

Beachten Sie, dass das vierte Zeichen in der Spalte "VP8 " FourCC ist ein ASCII-Leerzeichen (0x20).

Die VP8-Bitstream-Formatspezifikation wird unter VP8-Datenformat und Decodierungsleitfaden. Beachten Sie, dass der VP8-Frame-Header den VP8-Frame enthält. Breite und Höhe festlegen. Dabei wird von der Breite und Höhe des Canvas ausgegangen.

In der VP8-Spezifikation wird beschrieben, wie das Bild in das Y'CbCr-Format decodiert wird. Bis in RGB konvertieren möchten, sollte die Empfehlung BT.601 verwendet werden. Bewerbungen KÖNNEN eine andere Konvertierungsmethode verwenden, aber die visuellen Ergebnisse können je nach Decoder unterschiedlich sein.

Simple File Format (verlustfrei)

Hinweis: Ältere Lesegeräte unterstützen möglicherweise keine Dateien im verlustfreien Format.

Dieses Layout sollte verwendet werden, wenn für das Bild eine verlustfreie Codierung (mit einem optionalen Transparenzkanal) erforderlich ist und keine erweiterten Funktionen des erweiterten Formats benötigt werden.

Simple WebP (verlustfrei)-Dateiformat:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    WebP file header (12 bytes)                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         'VP8L' Chunk                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

„VP8L“ Chunk:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('VP8L')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           VP8L data                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VP8L-Daten: Blockgröße Byte
VP8L-Bitstream-Daten.

Die aktuelle Spezifikation des VP8L-Bitstreams finden Sie unter WebP Lossless Bitstream Format. Der VP8L-Header enthält die Breite und Höhe des VP8L-Bilds. Dabei wird die Breite und Höhe des Canvas.

Erweitertes Dateiformat

Hinweis: Ältere Lesegeräte unterstützen möglicherweise keine Dateien im erweiterten Format.

Eine Datei im erweiterten Format besteht aus:

  • Ein „VP8X“-Chunk mit Informationen zu den in der Datei verwendeten Funktionen.

  • Ein optionales „ICCP“ Chunk mit einem Farbprofil.

  • Ein optionaler ANIM-Chunk mit Daten zur Animation.

  • Bilddaten

  • Ein optionaler EXIF-Chunk mit EXIF-Metadaten.

  • Ein optionaler XMP-Chunk mit XMP-Metadaten.

  • Eine optionale Liste unbekannter Blöcke.

Bei einem Standbild bestehen die Bilddaten aus einem einzelnen Frame, der aus bis zu:

Bei einem animierten Bild bestehen die Bilddaten aus mehreren Frames. Mehr Weitere Informationen zu Frames finden Sie im Bereich Animation.

Alle für die Rekonstruktion und Farbkorrektur erforderlichen Teile, also 'VP8X', „ICCP“, „ANIM“, „ANMF“, „ALPH“, „VP8“ und 'VP8L', MÜSSEN in der Reihenfolge wie zuvor beschrieben. Leser MÜSSEN fehlschlagen, wenn die für die Rekonstruktion und Farbkorrektur erforderlichen Chunks nicht in der richtigen Reihenfolge sind.

Metadaten und unbekannte Blöcke KÖNNEN Reihenfolge.

Grund: Die für die Rekonstruktion erforderlichen Teile sollten zuerst in den damit der Leser mit der Decodierung eines Bildes beginnen kann, bevor alle mit den Daten. Eine Anwendung kann davon profitieren, die Reihenfolge der Metadaten und für die Implementierung anpassen.

Erweiterter WebP-Dateieheader: 

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                   WebP file header (12 bytes)                 |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('VP8X')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv|I|L|E|X|A|R|                   Reserved                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Canvas Width Minus One               |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...  Canvas Height Minus One    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserviert (Rsv): 2 Bit
MÜSSEN 0 sein. Leser MÜSSEN dieses Feld ignorieren.
ICC-Profil (I): 1 Bit
Legt fest, ob die Datei einen „ICCP“ enthält Chunk.
Alpha (L): 1 Bit
Legen Sie fest, ob einer der Frames des Bildes Transparenzinformationen enthält („Alpha“).
EXIF-Metadaten (E): 1 Bit
Legt fest, ob die Datei EXIF-Metadaten enthält.
XMP-Metadaten (X): 1 Bit
Legt fest, ob die Datei XMP-Metadaten enthält.
Animation (A): 1 Bit
Legen Sie fest, ob es sich um ein animiertes Bild handelt. Daten in „ANIM“ und „ANMF“ Chunks sollten zur Steuerung der Animation.
Reserviert (R): 1 Bit
MÜSSEN 0 sein. Leser MÜSSEN dieses Feld ignorieren.
Reserviert: 24 Bit
MÜSSEN 0 sein. Leser MÜSSEN dieses Feld ignorieren.
Canvas-Breite minus eins: 24 Bit
1-basierte Breite des Canvas in Pixeln. Die tatsächliche Canvas-Breite beträgt 1 + Canvas Width Minus One.
Canvas-Höhe minus eins: 24 Bit
1-basierte Höhe der Zeichenfläche in Pixeln. Die tatsächliche Höhe der Leinwand beträgt 1 + Canvas Height Minus One.

Das Produkt aus Leinwandbreite und Leinwandhöhe MUSS höchstens 2^32 - 1 betragen.

In zukünftigen Spezifikationen werden möglicherweise weitere Felder hinzugefügt. Unbekannte Felder MÜSSEN ignoriert werden.

Animation

Eine Animation wird von „ANIM“ gesteuert und „ANMF“ Stücke.

„ANIM“ Chunk:

Bei einem animierten Bild enthält dieser Block die globalen Parameter der Animation.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANIM')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Background Color                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Loop Count           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hintergrundfarbe: 32 Bit (uint32)
Die Standardhintergrundfarbe des Canvas in [Blau, Grün, Rot, Alpha] Byte-Reihenfolge. Mit dieser Farbe kann der nicht verwendete Bereich auf dem Canvas um die Frames herum sowie die transparenten Pixel des ersten Frames gefüllt werden. Die Hintergrundfarbe wird auch verwendet, wenn die Entsorgungsmethode 1 ist.

Hinweis:

  • Die Hintergrundfarbe KANN einen undurchsichtigen Alphawert enthalten, auch wenn das Flag Alpha in VP8X Chunk ist nicht festgelegt.

  • In Zuschaueranwendungen SOLLTEN die Hintergrundfarbe als Hinweis und sind nicht erforderlich.

  • Der Canvas wird zu Beginn jeder Schleife gelöscht. Die Hintergrundfarbe KÖNNEN die dazu verwendet wurden.

Schleifenzählung: 16 Bit (uint16)
Die Anzahl der Wiederholungen der Animation. Wenn es 0 ist, bedeutet das unendlich.

Dieser Chunk MUSS angezeigt werden, wenn das Flag Animation in VP8X Chunk ist bereit. Wenn das Flag Animation nicht festgelegt und dieser Chunk vorhanden ist, MUSS er ignoriert.

„ANMF“ Chunk:

Bei animierten Bildern enthält dieser Chunk Informationen über einen einzelnen Frame. Wenn das Flag „Animation“ nicht festgelegt ist, sollte dieser Chunk NICHT vorhanden sein.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANMF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Frame X                |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...          Frame Y            |   Frame Width Minus One     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |           Frame Height Minus One              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Frame Duration                |  Reserved |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         Frame Data                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame X: 24 Bit (uint24)
Die X-Koordinate der oberen linken Ecke des Frames ist Frame X * 2.
Frame Y: 24 Bit (uint24)
Die Y-Koordinate der oberen linken Ecke des Frames ist Frame Y * 2.
Framebreite minus eins: 24 Bit (uint24)
Die auf 1 basierende Breite des Frames. Die Frame-Breite beträgt 1 + Frame Width Minus One.
Framehöhe abzüglich 1: 24 Bit (uint24)
Die auf 1 basierende Höhe des Frames. Die Framehöhe beträgt 1 + Frame Height Minus One.
Framedauer: 24 Bit (uint24)
Die Zeit, die gewartet werden soll, bevor der nächste Frame angezeigt wird, in Millisekunden. Beachten Sie, dass die Interpretation der Frame Duration von 0 (und oft <= 10) von der Implementierung definiert wird. Viele Tools und Browser weisen eine Mindestdauer zu, die der von GIFs ähnelt.
Reserviert: 6 Bit
MÜSSEN 0 sein. Leser MÜSSEN dieses Feld ignorieren.
Methode für die Überblendung (B): 1 Bit

Gibt an, wie transparente Pixel des aktuellen Frames mit den entsprechenden Pixeln des vorherigen Canvas verschmolzen werden sollen:

  • 0: Alpha-Blending verwenden. Nachdem Sie den vorherigen Frame entsorgt haben, rendern Sie den aktuellen Frame auf dem Canvas mit Alpha-Überblendung (siehe unten). Wenn der Parameter Der aktuelle Frame hat keinen Alphakanal. Angenommen, der Alphawert ist 255 und ersetzt damit das Rechteck.

  • 1: Nicht verblenden. Nachdem Sie den vorherigen Frame entsorgt haben, rendern Sie den aktuellen Frame auf dem Canvas, indem Sie das Rechteck überschreiben, das von der aktuellen Frame.

Entsorgungsmethode (D): 1 Bit

Gibt an, wie der aktuelle Frame behandelt werden soll, nachdem er (vor dem Rendern des nächsten Frames) im Canvas angezeigt:

  • 0: Nicht entsorgen. Lassen Sie den Canvas unverändert.

  • 1: Entfernen Sie die Hintergrundfarbe. Fülle das Rechteck auf dem Canvas, das vom aktuellen Frame abgedeckt wird, mit der im Chunk „ANIM“ angegebenen Hintergrundfarbe aus.

Hinweise:

  • Die Frame-Entsorgung gilt nur für das Frame-Rechteck, also das Rechteck, das durch Frame X, Frame Y, Frame-Breite und Frame-Höhe definiert ist. Sie kann die gesamte Leinwand einnehmen.

  • Alpha-Blending:

    Da jeder der R-, G-, B- und A-Kanäle 8 Bit hat und die RGB-Kanäle nicht mit Alpha multipliziert werden, lautet die Formel für das Mischen von „dst“ mit „src“:

    blend.A = src.A + dst.A * (1 - src.A / 255)
if blend.A = 0 then
  blend.RGB = 0
else
  blend.RGB =
      (src.RGB * src.A +
       dst.RGB * dst.A * (1 - src.A / 255)) / blend.A

  • Die Alpha-Mischung sollte im linearen Farbraum erfolgen, wobei das Farbprofil des Bilds berücksichtigt wird. Wenn das Farbprofil nicht vorhanden ist, wird standardmäßig RGB (sRGB) angenommen. Bei sRGB werden auch aufgrund eines Gammas von ~2,2 linearisiert werden muss.)

Frame-Daten: Chunk-Größe in Byte – 16

Besteht aus:

Hinweis: Die ANMF-Nutzlast, Frame-Daten, besteht aus einzelnen ausgeglichenen Chunks, wie im RIFF-Dateiformat beschrieben.

Alpha

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ALPH')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rsv| P | F | C |     Alpha Bitstream...                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserviert (Rsv): 2 Bit
MÜSSEN 0 sein. Leser MÜSSEN dieses Feld ignorieren.
Vorverarbeitung (P): 2 Bit

Diese informativen Bits werden verwendet, um die Vorverarbeitung anzuzeigen, die während der Komprimierung durchgeführt wurde. Der Decoder kann anhand dieser Informationen zum Beispiel die Werte verdunkeln oder die Farbverläufe glätten, bevor sie angezeigt werden.

  • 0: Keine Vorverarbeitung.
  • 1: Stufenreduzierung.

Decodierer sind nicht erforderlich, um diese Informationen auf eine bestimmte Weise zu verwenden.

Filtermethode (F): 2 Bit

Die verwendeten Filtermethoden werden im Folgenden beschrieben:

  • 0: Keine.
  • 1: Horizontaler Filter.
  • 2: Vertikalfilter
  • 3: Gradientenfilter

Die Filterung wird für jedes Pixel mithilfe der folgenden Berechnungen durchgeführt. Angenommen, die Alphawerte um die aktuelle X-Position herum sind so beschriftet:

 C | B |
---+---+
 A | X |

Wir möchten den Alphawert an Position X berechnen. Zunächst ist eine Vorhersage je nach Filtermethode:

  • Methode 0: Predictor = 0
  • Methode 1: Prädiktor = A
  • Methode 2: Predictor = B
  • Methode 3: Prädiktor = clip(A + B - C)

wobei clip(v) gleich ist:

  • 0, wenn v < 0,
  • 255 wenn v > 255 oder
  • V sonst

Der endgültige Wert wird ermittelt, indem der dekomprimierte Wert X zum Predictor addiert und der Bereich [256..511] mithilfe der Modulo-256-Arithmetik in den Bereich [0..255] umgewandelt wird:

alpha = (predictor + X) % 256

Für die Pixelpositionen ganz links und ganz oben gibt es Sonderfälle. Für den Wert links oben an der Position (0, 0) wird beispielsweise 0 als Vorhersagewert verwendet. Andernfalls:

  • Bei der horizontalen oder Farbverlaufsfilterung werden die Pixel ganz links Standort (0, y) werden anhand des oben angegebenen Standorts (0, y-1) vorhergesagt.
  • Bei vertikalen oder Gradientenfiltermethoden werden die obersten Pixel an der Position (x, 0) anhand der Position (x-1, 0) links vorhergesagt.
Komprimierungsmethode (C): 2 Bit

Die verwendete Komprimierungsmethode:

  • 0: Keine Komprimierung.
  • 1: mit dem verlustfreien WebP-Format komprimiert.
Alpha-Bitstream: Blockgröße Byte – 1

Codierter Alpha-Bitstream.

Dieser optionale Chunk enthält codierte Alphadaten für diesen Frame. Ein Frame, der einen „VP8L“-Chunk enthält, DARF diesen Chunk NICHT enthalten.

Begründung: Die Transparenzinformationen sind bereits Teil des VP8L. Chunk.

Die Alphakanaldaten werden als unkomprimierte Rohdaten gespeichert (wenn der Komprimierungsmethode „0“ ist) oder mit dem verlustfreien Format komprimiert. (wenn die Komprimierungsmethode "1" ist).

  • Rohdaten: Diese bestehen aus einer Byte-Sequenz von Länge = Breite * Höhe, mit allen 8-Bit-Transparenzwerten in Scanreihenfolge.

  • Verlustfreie Formatkomprimierung: Die Bytesequenz ist eine komprimierte Bildstream (wie unter WebP Lossless Bitstream Format) mit impliziten Abmessungen (Breite x Höhe) beschrieben wird. Das bedeutet, dass In "image-stream" sind KEINE Kopfzeilen enthalten, die die Bildabmessungen beschreiben.

    Grund: Die Dimensionen sind bereits aus anderen Quellen bekannt. Das erneute Speichern wäre also redundant und fehleranfällig.

    Nachdem der Bildstream gemäß der in der Spezifikation für das verlustfreie Format beschriebenen Methode in Alpha-, Rot-, Grün- und Blau-Farbwerte (ARGB) decodiert wurde, müssen die Transparenzinformationen aus dem grünen Kanal des ARGB-Vierers extrahiert werden.

    Begründung: Im Gegensatz zu den anderen Kanälen sind für den grünen Kanal in der Spezifikation zusätzliche Transformationsschritte zulässig, die die Komprimierung verbessern können.

Bitstream (VP8/VP8L)

Dieser Chunk enthält komprimierte Bitstreamdaten für einen einzelnen Frame.

Ein Bitstream-Chunk kann entweder (i) ein 'VP8' sein Chunk, mit „VP8“ (Beachten Sie vierten Zeichens enthalten) als FourCC oder (ii) als VP8L Chunk mit „VP8L“ wie sein FourCC.

Die Formate von VP8- und VP8L-Chunks werden in den Abschnitten Simple File Format (Lossy) und Simple File Format (Lossless) beschrieben.

Farbprofil

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ICCP')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                       Color Profile                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Farbprofil: Chunk-Größe in Byte
ICC-Profil.

Dieser Block MUSS vor den Bilddaten stehen.

Es sollte maximal ein solcher Block geben. Wenn es mehr Blöcke gibt, KANN alle bis auf den ersten ignoriert werden. Weitere Informationen finden Sie in der ICC-Spezifikation.

Ist dieser Chunk nicht vorhanden, muss von sRGB ausgegangen werden.

Metadaten

Metadaten können in EXIF- oder XMP-Chunks gespeichert werden.

Es sollte maximal ein Block jedes Typs (EXIF und XMP) geben. Wenn es mehr solcher Blöcke gibt, können Leser alle bis auf den ersten ignorieren.

Die Blöcke sind so definiert:

„EXIF“ Chunk:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('EXIF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        Exif Metadata                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EXIF-Metadaten: Chunk Size Bytes
Bildmetadaten im EXIF-Format.

XMP-Chunk:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('XMP ')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        XMP Metadata                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
XMP-Metadaten: Chunk-Größe in Byte
Bildmetadaten im XMP-Format.

Das vierte Zeichen im FourCC-Wert „XMP“ ist ein ASCII-Leerzeichen (0x20).

Weitere Informationen zum Umgang mit Metadaten findest du in der Guidelines for Handling Metadata (Richtlinien für den Umgang mit Metadaten) der Arbeitsgruppe für Metadaten.

Unbekannte Chunks

Einen RIFF-Chunk (im Abschnitt RIFF-Dateiformat beschrieben) dessen FourCC sich von den in diesem Dokument beschriebenen Teilen unterscheidet, ist als unbekannter Chunk betrachtet.

Grund: Wenn Sie unbekannte Blöcke zulassen, ist eine zukünftige Verlängerung möglich. des Formats und ermöglicht außerdem die Speicherung anwendungsspezifischer Daten.

Eine Datei KANN unbekannte Blöcke enthalten:

Leser SOLLTEN diese Blöcke ignorieren. Autoren sollten sie in ihrer ursprünglichen Reihenfolge beibehalten, es sei denn, sie beabsichtigen ausdrücklich, diese Blöcke zu ändern.

Leinwandbilder aus Frames zusammensetzen

Hier finden Sie einen Überblick darüber, wie ein Leser im Fall eines animierten Bilds ein Canvas zusammenstellen MUSS.

Der Prozess beginnt mit der Erstellung eines Canvas mit den Abmessungen, die im „VP8X“ Chunk, Canvas Width Minus One + 1 Pixel breit und Canvas Height Minus One + 1 Pixel hoch. Das Feld Loop Count aus „ANIM“ Chunk-Steuerung wird der Animationsprozess wiederholt. Das ist Loop Count - 1 für nicht nullwertige Loop Count-Werte oder unendlich, wenn Loop Count = 0 ist.

Zu Beginn jeder Schleifeniteration wird der Canvas mit der Hintergrundfarbe aus dem Chunk „ANIM“ oder einer anwendungsdefinierten Farbe gefüllt.

„ANMF“ Chunks enthalten einzelne Frames in der Reihenfolge der Anzeige. Vor dem Rendern wird der Disposal method des vorherigen Frames angewendet.

Das Rendern des decodierten Frames beginnt bei den kartesischen Koordinaten (2 * Frame X, 2 * Frame Y), wobei die obere linke Ecke des Canvas als Ursprung verwendet wird. Mit dem Blending method wird ein Rechteck mit einer Breite von Frame Width Minus One + 1 Pixeln und einer Höhe von Frame Height Minus One + 1 Pixeln auf der Leinwand gerendert.

Der Canvas wird für Frame Duration Millisekunden angezeigt. Dies wird bis alle von "ANMF" vorgegebenen Frames Klötze wurden präsentiert. Anschließend wird eine neue Schleifeniteration gestartet oder der Canvas bleibt im Endzustand, wenn alle Iterationen abgeschlossen sind.

Der folgende Pseudocode veranschaulicht den Rendering-Prozess. Die Notation VP8X.field ist das Feld in "VP8X". Chunk mit derselben Beschreibung.

VP8X.flags.hasAnimation MUST be TRUE
canvas ← new image of size VP8X.canvasWidth x VP8X.canvasHeight with
         background color ANIM.background_color or
         application-defined color.
loop_count ← ANIM.loopCount
dispose_method ← Dispose to background color
if loop_count == 0:
  loop_count = ∞
frame_params ← nil
next chunk in image_data is ANMF MUST be TRUE
for loop = 0..loop_count - 1
  clear canvas to ANIM.background_color or application-defined color
  until eof or non-ANMF chunk
    frame_params.frameX = Frame X
    frame_params.frameY = Frame Y
    frame_params.frameWidth = Frame Width Minus One + 1
    frame_params.frameHeight = Frame Height Minus One + 1
    frame_params.frameDuration = Frame Duration
    frame_right = frame_params.frameX + frame_params.frameWidth
    frame_bottom = frame_params.frameY + frame_params.frameHeight
    VP8X.canvasWidth >= frame_right MUST be TRUE
    VP8X.canvasHeight >= frame_bottom MUST be TRUE
    for subchunk in 'Frame Data':
      if subchunk.tag == "ALPH":
        alpha subchunks not found in 'Frame Data' earlier MUST be
          TRUE
        frame_params.alpha = alpha_data
      else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L":
        bitstream subchunks not found in 'Frame Data' earlier MUST
          be TRUE
        frame_params.bitstream = bitstream_data
    apply dispose_method.
    render frame with frame_params.alpha and frame_params.bitstream
      on canvas with top-left corner at (frame_params.frameX,
      frame_params.frameY), using Blending method
      frame_params.blendingMethod.
    canvas contains the decoded image.
    Show the contents of the canvas for
    frame_params.frameDuration * 1 ms.
    dispose_method = frame_params.disposeMethod

Beispieldateilayouts

Ein verlustbehaftetes-codiertes Bild mit Alpha kann so aussehen:

RIFF/WEBP
+- VP8X (descriptions of features used)
+- ALPH (alpha bitstream)
+- VP8 (bitstream)

Ein verlustfreies codiertes Bild kann so aussehen:

RIFF/WEBP
+- VP8X (descriptions of features used)
+- VP8L (lossless bitstream)
+- XYZW (unknown chunk)

Ein verlustfreies Bild mit einem ICC-Profil und XMP-Metadaten kann so aussehen:

RIFF/WEBP
+- VP8X (descriptions of features used)
+- ICCP (color profile)
+- VP8L (lossless bitstream)
+- XMP  (metadata)

Ein animiertes Bild mit EXIF-Metadaten kann wie folgt aussehen:

RIFF/WEBP
+- VP8X (descriptions of features used)
+- ANIM (global animation parameters)
+- ANMF (frame1 parameters + data)
+- ANMF (frame2 parameters + data)
+- ANMF (frame3 parameters + data)
+- ANMF (frame4 parameters + data)
+- EXIF (metadata)