WebP-Containerspezifikation

Einführung

WebP ist ein Bildformat, das entweder (i) die VP8-Keyframe-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. Sie ist für die schnelle Bildübertragung über das Netzwerk optimiert (z. B. für Websites). Das WebP-Format weist auch die Funktionsparität (Farbprofil, Metadaten, Animation usw.) mit anderen Formaten auf. 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 über den grundlegenden Anwendungsfall von WebP (d. h. eine Datei mit einem einzelnen Bild, das als VP8-Keyframe codiert ist). Der WebP-Container bietet zusätzliche Unterstützung für Folgendes:

  • Verlustfreie Komprimierung: Ein Bild kann mit dem verlustfreien WebP-Format verlustfrei komprimiert werden.

  • Metadaten: Ein Bild kann Metadaten im EXIF-Format (Exchangeable Image File Format) oder XMP-Format (Extensible Metadata Platform) haben.

  • 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, wodurch es eine Animation wird.

Benennung

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

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

Terminologie und Grundlagen

Die Schlüsselwörter „MUSS“, „DARF NICHT“, „ERFORDERLICH“, „WIRD“, „WIRD NICHT“, „SOLLTE“, „SOLLTE NICHT“, „EMPFOHLEN“, „NICHT EMPFOHLEN“, „KÖNNEN“ und „OPTIONAL“ in diesem Dokument sind wie in BCP 14, RFC 2119 und RFC 8174 beschrieben zu interpretieren, wenn und nur wenn sie wie hier in Großbuchstaben erscheinen.

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

Die Bitnummerierung in Chunk-Diagrammen 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 16-Bit-Little-Endian-Ganzzahl ohne Vorzeichen.
uint24
Eine vorzeichenlose 24-Bit-Ganzzahl im Little-Endian-Format.
uint32
Eine 32-Bit-Little-Endian-Ganzzahl ohne Vorzeichen.
FourCC
Ein vierstelliger Code (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 Feld mit einer nicht signierten Ganzzahl, in dem Werte mit -1 versetzt gespeichert werden. In einem solchen Feld würde der Wert 25 beispielsweise als 24 gespeichert.
ChunkHeader('ABCD')
Wird verwendet, um die FourCC- und Chunk-Größe-Header einzelner Chunks zu beschreiben. Dabei ist „ABCD“ die FourCC für den Chunk. Dieses Element ist 8 Byte groß.

RIFF-Dateiformat

Das WebP-Dateiformat basiert auf dem RIFF-Dokumentformat (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 Chunks in Byte, ohne dieses Feld, den Chunk-Identifier oder Padding.
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 nur in Kleinbuchstaben geschrieben. 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, beginnend bei Offset 8. Der Maximalwert dieses Felds beträgt 2^32 minus 10 Byte. Die Größe der gesamten Datei liegt also bei höchstens 4 GiB minus 2 Byte.
„WEBP“: 32 Bit
Die ASCII-Zeichen „W“, „E“, „B“, „P“.

Eine WebP-Datei MUSS mit einem RIFF-Header mit dem FourCC-Wert „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 nach den Daten, die mit Dateigröße angegeben sind, KEINE Daten enthalten. Leser KÖNNEN solche Dateien parsen und die abschließenden Daten ignorieren. Da die Größe eines Chunks gerade ist, ist auch die Größe, die in der RIFF-Header angegeben ist, gerade. Der Inhalt einzelner Chunks wird in den folgenden Abschnitten beschrieben.

Simple File Format (verlustbehaftet)

Dieses Layout sollte verwendet werden, wenn für das Bild eine verlustbehaftete Codierung erforderlich ist und keine Transparenz oder andere erweiterten Funktionen des erweiterten Formats benötigt werden. 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 im VP8-FourCC ein ASCII-Leerzeichen (0x20) ist.

Die Spezifikation des VP8-Bitstream-Formats wird im VP8 Data Format and Decoding Guide (VP8-Datenformat- und Dekodierungsleitfaden) beschrieben. Der VP8-Frame-Header enthält die Breite und Höhe des VP8-Frames. Dabei wird davon ausgegangen, dass dies die Breite und Höhe des Canvas ist.

In der VP8-Spezifikation wird beschrieben, wie das Bild in das Y'CbCr-Format decodiert wird. Für die Umwandlung in RGB muss die Empfehlung BT.601 verwendet werden. Anwendungen KÖNNEN eine andere Konvertierungsmethode verwenden, aber die visuellen Ergebnisse können sich je nach Decoder unterscheiden.

Einfaches Dateiformat (verlustfrei)

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

Dieses Layout sollte verwendet werden, wenn das Bild eine verlustfreie Codierung (mit einem optionalen Transparenzkanal) erfordert und keine erweiterten Funktionen des erweiterten Formats erfordert.

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 davon ausgegangen, dass dies die Breite und Höhe des Canvas ist.

Erweitertes Dateiformat

Hinweis: Ältere Leser 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 optionaler „ICCP“-Block mit einem Farbprofil.

  • Ein optionaler ANIM-Chunk mit Daten zur Animation.

  • Bilddaten

  • Ein optionaler EXIF-Chunk mit EXIF-Metadaten.

  • Ein optionaler XMP-Block mit XMP-Metadaten.

  • Eine optionale Liste unbekannter Blöcke.

Bei einem Standbild bestehen die Bilddaten aus einem einzelnen Frame, der aus folgenden Elementen besteht:

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

Alle für die Rekonstruktion und Farbkorrektur erforderlichen Teile, d. h. „VP8X“, „ICCP“, „ANIM“, „ANMF“, „ALPH“, „VP8“ und „VP8L“, MÜSSEN in der zuvor beschriebenen Reihenfolge angezeigt werden. Leser sollten fehlschlagen, wenn Teile, die für die Rekonstruktion und die Farbkorrektur erforderlich sind, nicht in der richtigen Reihenfolge angeordnet sind.

Metadaten und unbekannte Blöcke KÖNNEN in der falschen Reihenfolge erscheinen.

Begründung:Die für die Rekonstruktion erforderlichen Chunks sollten zuerst in der Datei erscheinen, damit ein Leser mit der Dekodierung eines Bildes beginnen kann, bevor alle Daten empfangen wurden. Für eine Anwendung kann es vorteilhaft sein, die Reihenfolge der Metadaten und benutzerdefinierten Blöcke an die Implementierung anzupassen.

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
Wird festgelegt, wenn die Datei einen ICCP-Chunk enthält.
Alpha (L): 1 Bit
Legt fest, ob einer der Frames des Bilds Transparenzinformationen („alpha“) enthält.
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
Legt fest, ob es sich um ein animiertes Bild handelt. Die Daten in den Chunks „ANIM“ und „ANMF“ sollten zur Steuerung der Animation verwendet werden.
Reserviert (R): 1 Bit
MUSS 0 lauten. Leser MÜSSEN dieses Feld ignorieren.
Reserviert: 24 Bit
MUSS 0 lauten. Leser MÜSSEN dieses Feld ignorieren.
Canvas-Breite minus eins: 24 Bit
1-basierte Breite des Canvas in Pixeln. Die tatsächliche Leinwandbreite 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 Canvas-Höhe 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 durch ANIM- und ANMF-Chunks gesteuert.

Chunk „ANIM“:

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 Bytereihenfolge [Blau, Grün, Rot, Alpha]. 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.

Hinweise:

  • Die Hintergrundfarbe DARF einen nicht opaken Alphawert enthalten, auch wenn das Flag Alpha im Chunk „VP8X“ nicht festgelegt ist.

  • Wiedergabeanwendungen sollten den Wert für die Hintergrundfarbe als Hinweis behandeln und sind nicht verpflichtet, ihn zu verwenden.

  • Der Canvas wird zu Beginn jeder Schleife gelöscht. Die Hintergrundfarbe KANN dazu verwendet werden.

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 im Chunk „VP8X“ festgelegt ist. Wenn das Flag Animation nicht gesetzt ist und dieser Chunk vorhanden ist, MUSS er ignoriert werden.

ANMF-Chunk:

Bei animierten Bildern enthält dieser Chunk Informationen zu einem einzelnen Frame. Wenn das Animation-Flag nicht gesetzt 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.
Frame Width Minus One: 24 Bit (uint24)
Die auf 1 basierende Breite des Frames. Die Frame-Breite beträgt 1 + Frame Width Minus One.
Framehöhe minus eins: 24 Bit (uint24)
Die 1-basierte Höhe des Frames. Die Framehöhe beträgt 1 + Frame Height Minus One.
Frame Duration: 24 Bit (uint24)
Die Zeit, die gewartet werden soll, bevor der nächste Frame angezeigt wird, in Millisekunden. Die Interpretation der Framedauer von 0 (und oft <= 10) wird durch die Implementierung definiert. Viele Tools und Browser weisen eine ähnliche Mindestdauer wie GIF zu.
Reserviert: 6 Bit
MUSS 0 lauten. Leser MÜSSEN dieses Feld ignorieren.
Mischmethode (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 der vorherige Frame entsorgt wurde, rendern Sie den aktuellen Frame mit Alpha-Blending auf dem Canvas (siehe unten). Wenn der aktuelle Frame keinen Alphakanal hat, wird davon ausgegangen, dass der Alphawert 255 ist, wodurch das Rechteck effektiv ersetzt wird.

  • 1: Nicht verblenden. Nachdem Sie den vorherigen Frame entfernt haben, rendern Sie den aktuellen Frame auf dem Canvas, indem Sie das Rechteck überschreiben, das vom aktuellen Frame abgedeckt wird.

Entsorgungsmethode (D): 1 Bit

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

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

  • 1: Entfernen Sie die Hintergrundfarbe. Füllen Sie das Rechteck auf dem Canvas, das vom aktuellen Frame abgedeckt wird, mit der im ANIM-Block angegebenen Hintergrundfarbe.

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. Er kann das gesamte Canvas bedecken oder auch nicht.

  • 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. Hinweis: sRGB muss aufgrund eines Gammawerts von etwa 2,2 ebenfalls linearisiert werden.

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

Umfasst:

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
MUSS 0 lauten. Leser MÜSSEN dieses Feld ignorieren.
Vorverarbeitung (P): 2 Bit

Diese informativen Bit werden verwendet, um die Vorverarbeitung zu signalisieren, die während der Komprimierung durchgeführt wurde. Der Decoder kann diese Informationen verwenden, um beispielsweise die Werte vor der Anzeige zu ditheringen oder die Farbverläufe zu glätten.

  • 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 unten 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 versuchen, den Alphawert an Position X zu berechnen. Zuerst wird abhängig von der Filtermethode eine Vorhersage erstellt:

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

wobei clip(v) gleich ist:

  • 0, wenn v < 0,
  • 255, wenn v > 255, oder
  • v otherwise

Der endgültige Wert wird berechnet, 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 äußersten linken und oberen Pixelpositionen gelten Sonderfälle. Zum Beispiel verwendet der Wert oben links an der Position (0, 0) 0 als Prädiktorwert. Andernfalls:

  • Bei horizontalen oder Gradientenfilterungsmethoden werden die Pixel ganz links an der Position (0, y) anhand der Position (0, y-1) direkt darüber 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: Chunk-Größe in 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“-Chunks.

Die Daten des Alphakanals werden als unkomprimierte Rohdaten gespeichert (wenn die Komprimierungsmethode "0" ist) oder mit dem verlustfreien Format komprimiert (wenn die Komprimierungsmethode "1" ist).

  • Rohdaten: Diese bestehen aus einer Byte-Sequenz mit der Länge „Breite × Höhe“, die alle 8‑Bit-Transparenzwerte in der Scanreihenfolge enthält.

  • Verlustfreie Formatkomprimierung: Die Byte-Sequenz ist ein komprimierter Bildstream (wie unter "WebP Lossless Bitstream Format" beschrieben) mit impliziten Abmessungen (Breite x Höhe). Das heißt, dieser Bildstream enthält KEINE Überschriften, die die Bildabmessungen beschreiben.

    Begründung: Die Dimensionen sind bereits aus anderen Quellen bekannt. Daher wäre es redundant und fehleranfällig, sie noch einmal zu speichern.

    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 zusätzliche Transformationsschritte in der Spezifikation zulässig, die die Komprimierung verbessern können.

Bitstream (VP8/VP8L)

Dieser Block enthält komprimierte Bitstream-Daten für einen einzelnen Frame.

Ein Bitstream-Chunk kann entweder (i) ein „VP8“-Chunk mit „VP8“ (beachte den wichtigen Leerraum für das vierte Zeichen) als FourCC sein oder (ii) ein „VP8L“-Chunk mit „VP8L“ als 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 mehrere solcher Blöcke gibt, KÖNNEN Leser alle bis auf den ersten ignorieren. 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-Größe in Byte
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 finden Sie in den Richtlinien für den Umgang mit Metadaten der Metadata Working Group.

Unbekannte Chunks

Ein RIFF-Chunk (siehe Abschnitt RIFF-Dateiformat), dessen FourCC sich von allen in diesem Dokument beschriebenen Chunks unterscheidet, wird als unbekannter Chunk betrachtet.

Begründung: Wenn unbekannte Blöcke zulässig sind, kann das Format in Zukunft erweitert und auch anwendungsspezifische Daten gespeichert werden.

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.

Zuerst wird eine Leinwand mit den im VP8X-Chunk angegebenen Abmessungen (Canvas Width Minus One + 1 Pixel breit und Canvas Height Minus One + 1 Pixel hoch) erstellt. Mit dem Feld Loop Count aus dem Chunk „ANIM“ wird festgelegt, wie oft der Animationsvorgang wiederholt wird. 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, in der sie angezeigt werden. Vor dem Rendern jedes Frames wird die Disposal method des vorherigen Frames angewendet.

Das Rendering des decodierten Frames beginnt bei den kartesischen Koordinaten (2 * Frame X, 2 * Frame Y) und verwendet die linke obere Ecke des Canvas als Ursprung. 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 Frame Duration Millisekunden lang angezeigt. Dies geschieht so lange, bis alle Frames angezeigt wurden, die durch „ANMF“-Chunks angegeben wurden. Anschließend wird eine neue Schleifeniteration gestartet oder der Canvas bleibt im Endzustand, wenn alle Iterationen abgeschlossen sind.

Der folgende Pseudocode veranschaulicht den Rendering-Vorgang. Die Schreibweise VP8X.field bezieht sich auf das Feld im 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 verlustfrei 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 so 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)