WebP-Containerspezifikation

Einleitung

WebP ist ein Bildformat, das entweder (i) die VP8-Keyframe-Codierung verwendet, um Bilddaten verlustbehaftet zu komprimieren, oder (ii) die verlustfreie WebP-Codierung. Diese Codierungsschemas sollten es effizienter machen als ältere Formate wie JPEG, GIF und PNG. Es ist für die schnelle Bildübertragung über das Netzwerk optimiert (z. B. für Websites). Das WebP-Format hat auch Funktionsgleichheit (Farbprofil, Metadaten, Animation usw.) mit anderen Formaten. In diesem Dokument wird die Struktur einer WebP-Datei beschrieben.

Der WebP-Container (RIFF-Container für WebP) ermöglicht die Funktionsunterstützung über den grundlegenden Anwendungsfall von WebP hinaus (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 Image kann im WebP Lossless-Format verlustfrei komprimiert werden.

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

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

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

  • Animation: Ein Bild kann mehrere Frames mit Pausen haben, wodurch es zu einer Animation wird.

Benennung

Für den WebP-Container werden die folgenden Typen empfohlen:

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

Terminologie und Grundlagen

Die in diesem Dokument verwendeten Schlüsselwörter „MÜSSEN“, „DÜRFEN NICHT“, „ERFORDERLICH“, „SELLE“, „SOLLTE NICHT“, „SOLLTE“, „SOLLTE NICHT“, „EMPFOHLEN“, „NICHT EMPFOHLEN“, „MAY“ und „OPTIONAL“ in diesem Dokument so interpretiert werden, wie in BCP 14 RFC 2119 beschrieben, wenn sie in RFC 8174 (RFC 8174) beschrieben werden. RFC 8174 wird hier nur in Großbuchstaben verwendet.

Eine WebP-Datei enthält entweder ein Standbild (eine codierte Pixelmatrix) oder eine Animation. Optional können auch Transparenzinformationen, ein Farbprofil und Metadaten enthalten sein. Die Pixelmatrix wird als Canvas des Bildes bezeichnet.

Die Bitnummerierung in Chunk-Diagrammen beginnt bei 0 für das wichtigste Bit („MSB 0“), wie in RFC 1166 beschrieben.

Nachfolgend finden Sie zusätzliche Begriffe, die in diesem Dokument verwendet werden:

Leser/Autor
Code, der WebP-Dateien liest, wird als Reader bezeichnet, während Code, der sie schreibt, als Writer bezeichnet wird.
uint16
Eine vorzeichenlose 16-Bit-Little-Endian-Ganzzahl.
uint24
Eine vorzeichenlose 24-Bit-Little-Endian-Ganzzahl.
uint32
Eine vorzeichenlose 32-Bit-Little-Endian-Ganzzahl
FourCC
Ein vierstelliger Code (FourCC) ist ein uint32, der durch Verkettung von vier ASCII-Zeichen in Little-Endian-Reihenfolge erzeugt wird. Das bedeutet, dass „aaaa“ (0x61616161) und „AAAA“ (0x41414141) als unterschiedliche FourCCs behandelt werden.
1-basiert
Ein vorzeichenbehaftetes Ganzzahlfeld mit Werten, die um -1 verschoben sind, z. B. den Wert 25 als 24.
ChunkHeader('ABCD')
Wird verwendet, um den Header FourCC und ChunkSize einzelner Chunks zu beschreiben, wobei ABCD der FourCC für den Block ist. 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
Vierstelliger ASCII-Code zur Identifizierung von Blöcken.
Chunk-Größe: 32 Bit (uint32)
Die Größe des Chunks in Byte ohne dieses Feld, die Chunk-ID oder das Padding.
Chunk-Nutzlast: Chunk-Größe Byte
Die Datennutzlast. Wenn die ChunkSize ungerade ist, wird ein einzelnes Padding-Byte hinzugefügt, das 0 sein MUSS, um RIFF zu entsprechen.

Hinweis:Für das RIFF-Framework gilt die Konvention, dass die FourCC-Blöcke in Großbuchstaben Standardblöcke sind, die für jedes RIFF-Dateiformat gelten, während FourCCs, die für ein Dateiformat spezifisch sind, nur kleingeschrieben werden. 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“, „F“
Dateigröße: 32 Bit (uint32)
Die Größe der Datei in Byte, beginnend bei Offset 8. Der Maximalwert dieses Feldes beträgt 2^32 minus 10 Byte, sodass die Größe der gesamten Datei höchstens 4 GiB minus 2 Byte beträgt.
„WEBP“: 32 Bit
Die ASCII-Zeichen „W“, „E“, „B“ und „P“.

Eine WebP-Datei MUSS mit einem RIFF-Header mit dem FourCC-Format „WEBP“ beginnen. Die Dateigröße im Header ist die Gesamtgröße der folgenden Blöcke plus 4 Byte für das FourCC-Element „WEBP“. Die Datei DARF KEINE Daten enthalten, die über die durch die Dateigröße festgelegten Daten hinausgehen. Leser KÖNNEN solche Dateien parsen und die nachgestellten Daten ignorieren. Da die Größe eines Blocks gerade ist, ist auch die vom RIFF-Header angegebene Größe gleichmäßig. Der Inhalt einzelner Blöcke wird in den folgenden Abschnitten beschrieben.

Einfaches Dateiformat (verlustbehaftet)

Dieses Layout SOLLTE verwendet werden, wenn das Bild eine verlustbehaftete Codierung und keine Transparenz oder andere erweiterte Funktionen des erweiterten Formats erfordert. 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                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chunk für „VP8“:

 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: Blockgröße Byte
VP8-Bitstream-Daten.

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

Die VP8-Bitstream-Formatspezifikation wird in der VP8-Anleitung zum Datenformat und zur Decodierung beschrieben. Der VP8-Frameheader enthält die Breite und Höhe des VP8-Frames. Dabei wird angenommen, dass es sich um die Breite und Höhe des Canvas handelt.

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

Einfaches Dateiformat (verlustfrei)

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

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

Einfaches WebP-Dateiformat (verlustfrei):

 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. Beachten Sie, dass der VP8L-Header die Breite und Höhe des VP8L-Bilds enthält. Hierbei wird angenommen, dass es sich um die Breite und Höhe des Canvas handelt.

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-Chunk“ mit einem Farbprofil.

  • Ein optionaler „ANIM“-Chunk mit Daten zur Animationssteuerung.

  • Bilddaten.

  • Ein optionaler EXIF-Chunk mit EXIF-Metadaten.

  • Ein optionaler XMP-Chunk mit XMP-Metadaten.

  • Eine optionale Liste von unbekannten Blöcken.

Bei einem Standbild bestehen die Bilddaten aus einem einzelnen Frame, der sich aus Folgendem zusammensetzt:

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 Chunks (VP8X, ICCP, ANIM, ANMF, ALPH, VP8 und VP8L) MÜSSEN in der oben beschriebenen Reihenfolge erscheinen. Leser sollten scheitern, wenn die für Rekonstruktion und Farbkorrektur erforderlichen Teile nicht richtig angeordnet sind.

Metadaten und unbekannte Blöcke MÖGLICHERWEISE in falscher Reihenfolge angezeigt werden.

Grund:Die für die Rekonstruktion erforderlichen Blöcke sollten zuerst in der Datei angezeigt werden, damit der Leser mit der Decodierung eines Bildes beginnen kann, bevor alle Daten empfangen werden. Eine Anwendung kann davon profitieren, die Reihenfolge der Metadaten und benutzerdefinierten Blöcke entsprechend der Implementierung zu variieren.

Erweiterter WebP-Datei-Header: 

 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
Legen Sie fest, ob die Datei einen „ICCP“-Chunk enthält.
Alpha (L): 1 Bit
Hiermit legen Sie fest, ob einer der Frames des Bildes Transparenzinformationen („Alpha“) enthält.
EXIF-Metadaten (E): 1 Bit
Legen Sie fest, ob die Datei EXIF-Metadaten enthält.
XMP-Metadaten (X): 1 Bit
Legen Sie 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 verwendet werden.
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.
Leinwandhöhe (minus eins): 24 Bit
Die 1-basierte Höhe des Canvas in Pixeln. Die tatsächliche Leinwandhöhe beträgt 1 + Canvas Height Minus One.

Das Produkt mit Leinwandbreite und Canvashöhe MUSS höchstens 2^32 - 1 sein.

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

Animation

Animationen werden von „ANIM“- und „ANMF“-Chunks gesteuert.

„ANIM“ Chunk:

Bei einem animierten Bild enthält dieser Code-Chunk 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]. Diese Farbe kann verwendet werden, um den ungenutzten Platz auf dem Canvas um die Frames sowie die transparenten Pixel des ersten Frames zu füllen. Die Hintergrundfarbe wird auch verwendet, wenn die Entsorgungsmethode 1 ist.

Hinweis:

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

  • Viewer-Anwendungen SOLLTE den Wert für die Hintergrundfarbe als Hinweis behandeln und müssen ihn nicht verwenden.

  • Der Canvas wird zu Beginn jeder Schleife gelöscht. Dafür kann die Hintergrundfarbe verwendet werden.

Schleifenanzahl: 16 Bit (uint16)
Die Häufigkeit, mit der die Animation als Schleife wiedergegeben werden soll. Wenn es 0 lautet, bedeutet dies unendlich.

Dieser Chunk MUSS angezeigt werden, wenn das Flag Animation im Chunk „VP8X“ festgelegt ist. Wenn das Flag Animation nicht festgelegt ist und dieser Block vorhanden ist, MUSS er ignoriert werden.

„ANMF“-Chunk:

Bei animierten Bildern enthält dieser Chunk Informationen zu einem einzelnen Frame. Wenn das Flag für die 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 1-basierte Breite des Frames. Die Framebreite beträgt 1 + Frame Width Minus One.
Framehöhe minus eins: 24 Bit (uint24)
Die 1-basierte Höhe des Frames. Die Frame-Höhe beträgt 1 + Frame Height Minus One.
Framedauer: 24 Bit (uint24)
Die Wartezeit, bis der nächste Frame angezeigt wird, in Einheiten von einer Millisekunde. Beachten Sie, dass die Interpretation der Framedauer von 0 (und oft <= 10) von der Implementierung definiert wird. Viele Tools und Browser weisen eine Mindestdauer ähnlich wie bei GIF zu.
Reserviert: 6 Bit
MÜSSEN 0 sein. 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 zusammengeführt werden:

  • 0: Alpha-Mischung verwenden. Nachdem Sie den vorherigen Frame verworfen haben, rendern Sie den aktuellen Frame auf dem Canvas mithilfe der Alpha-Überblendung (siehe unten). Wenn der aktuelle Frame keinen Alphakanal hat, nehmen wir an, dass der Alphawert 255 beträgt. Dadurch wird das Rechteck ersetzt.

  • 1: Nicht zusammenführen. Nachdem Sie den vorherigen Frame verworfen haben, rendern Sie den aktuellen Frame auf dem Canvas, indem Sie das vom aktuellen Frame abgedeckte Rechteck überschreiben.

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: Hintergrundfarbe verwenden. Fülle das Rechteck auf dem Canvas, das vom aktuellen Frame abgedeckt ist, mit der im ANIM-Chunk angegebenen Hintergrundfarbe aus.

Hinweise:

  • Die Entsorgung des Frames gilt nur für das Frame-Rechteck, also für das durch Frame X, Frame Y, Frame-Breite und Frame-Höhe definierte Rechteck. Es kann die gesamte Leinwand abdecken.

  • Alpha-Verschmelzung:

    Da jeder der R-, G-, B- und A-Kanäle 8 Bit groß ist und die RGB-Kanäle nicht mit Alpha multipliziert werden, lautet die Formel für das Einbinden von "dst" in "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, unter Berücksichtigung des Farbprofils des Bilds. Wenn kein Farbprofil vorhanden ist, wird von Standard-RGB (sRGB) ausgegangen. (Beachten Sie, dass sRGB aufgrund einer Gamma von ~2,2 linearisiert werden muss.)

Framedaten: Chunk-Größe – 16 Byte

Besteht aus:

Hinweis: Die ANMF-Nutzlast Frame Data besteht aus einzelnen aufgefüllten Blöcken, 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 zu signalisieren, die während der Komprimierung durchgeführt wurde. Der Decoder kann diese Informationen verwenden, um die Werte beispielsweise vor der Anzeige zu dippen oder die Farbverläufe zu glätten.

  • 0: Keine Vorverarbeitung.
  • 1: Levelreduzierung.

Die Decoder müssen diese Informationen nicht auf eine bestimmte Weise verwenden.

Filtermethode (F): 2 Bit

Die verwendeten Filtermethoden werden wie folgt beschrieben:

  • 0: Keine.
  • 1: Horizontaler Filter.
  • 2: Vertikaler Filter.
  • 3: Farbverlaufsfilter.

Für jedes Pixel wird das Filtern mithilfe der folgenden Berechnungen durchgeführt. Angenommen, die Alphawerte um die aktuelle X-Position sind wie folgt gekennzeichnet:

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

Es wird versucht, den Alphawert an Position X zu berechnen. Zuerst wird abhängig von der Filtermethode eine Vorhersage getroffen:

  • Methode 0: Predictor = 0
  • Methode 1: Predictor = A
  • Methode 2: Predictor = B
  • Methode 3: Predictor = Clip(A + B - C)

Dabei ist clip(v) gleich:

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

Der endgültige Wert wird abgeleitet, indem der dekomprimierte Wert X zum Prädiktor addiert und der Bereich [256..511] mithilfe der Modulo-256-Arithmetik in den Bereich [0..255] verpackt wird:

alpha = (predictor + X) % 256

Es gibt Sonderfälle für die Pixelpositionen ganz links und ganz oben. Beispielsweise wird für den Wert oben links an der Position (0, 0) 0 als Prädiktorwert verwendet. Andernfalls:

  • Bei horizontalen oder Farbverlaufsfiltermethoden werden die Pixel ganz links an der Position (0, y) mithilfe der direkt darüber liegenden Position (0, y-1) vorhergesagt.
  • Bei vertikalen oder Farbverlaufsfilterungsmethoden werden die obersten Pixel an der Position (x, 0) anhand der Position (x-1, 0) auf der linken Seite vorhergesagt.
Komprimierungsmethode (C): 2 Bit

Die verwendete Komprimierungsmethode:

  • 0: Keine Komprimierung.
  • 1: Wird im verlustfreien WebP-Format komprimiert.
Alpha-Bitstream: Chunk-Größe – 1 Byte

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.

Grund: Die Transparenzinformationen sind bereits Teil des Blocks "VP8L".

Die Alphakanaldaten werden als unkomprimierte Rohdaten (bei der Komprimierungsmethode auf "0") gespeichert oder im verlustfreien Format komprimiert (bei Komprimierungsmethode "1").

  • Rohdaten: Sie bestehen aus einer Bytesequenz der Länge = Breite * Höhe, die alle 8-Bit-Transparenzwerte in der Scanreihenfolge enthält.

  • Verlustfreie Formatkomprimierung: Die Bytesequenz 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 Header, die die Bildabmessungen beschreiben.

    Grund: Die Dimensionen sind bereits aus anderen Quellen bekannt, sodass eine erneute Speicherung redundant und fehleranfällig wäre.

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

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

Bitstream (VP8/VP8L)

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

Ein Bitstream-Chunk kann entweder (i) ein Chunk vom Typ „VP8“ mit „VP8“ (bedeutender Bereich des vierten Zeichens) als FourCC oder (ii) ein Chunk „VP8L“ mit „VP8L“ als FourCC sein.

Die Formate der Chunks „VP8“ und „VP8L“ werden in den Abschnitten Simple File Format (Lossy) bzw. 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 Byte
ICC-Profil.

Dieser Chunk MUSS vor den Bilddaten angezeigt werden.

Es DARF es höchstens einen solchen Block geben. Gibt es mehr solcher Blöcke, können Leser alle außer dem ersten ignorieren. Weitere Informationen finden Sie in der ICC-Spezifikation.

Wenn dieser Chunk nicht vorhanden ist, sollte von sRGB ausgegangen werden.

Metadaten

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

Von jedem Typ SOLLTEN es höchstens einen Block geben ("EXIF" und "XMP"). Wenn es mehrere solcher Chunks gibt, können Leser alle außer dem 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: Blockgröße Byte
Bildmetadaten im EXIF-Format.

Chunk für „XMP“:

 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: Chunkgröße Byte
Bildmetadaten im XMP-Format.

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

Weitere Informationen zum Umgang mit Metadaten finden Sie in den Richtlinien für den Umgang mit Metadaten der Arbeitsgruppe für Metadaten.

Unbekannte Chunks

Ein RIFF-Chunk (beschrieben im Abschnitt RIFF-Dateiformat), dessen FourCC sich von einem der in diesem Dokument beschriebenen Blöcke unterscheidet, wird als unbekannter Block betrachtet.

Grund: Das Zulassen unbekannter Blöcke ermöglicht eine künftige Erweiterung des Formats und ermöglicht außerdem das Speichern anwendungsspezifischer Daten.

Eine Datei KANN unbekannte Blöcke enthalten:

Leser SOLLTE diese Blöcke ignorieren. Autoren MÜSSEN sie in der ursprünglichen Reihenfolge beibehalten (es sei denn, sie möchten ausdrücklich vorsehen, diese Teile zu ändern).

Leinwandbau aus Rahmen

Hier bieten wir einen Überblick darüber, wie ein Leinwanddruck im Falle eines animierten Bildes erstellt werden muss.

Der Prozess beginnt mit dem Erstellen eines Canvas mit den im Chunk "VP8X" angegebenen Abmessungen (Canvas Width Minus One + 1 Pixel breit und Canvas Height Minus One + 1 Pixel hoch). Das Feld Loop Count aus dem Chunk „ANIM“ steuert, wie oft der Animationsprozess wiederholt wird. Dies ist Loop Count - 1 für Loop Count-Werte ungleich null oder unendlich, wenn Loop Count null ist.

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

ANMF-Chunks enthalten einzelne Frames, die in der Anzeigereihenfolge angegeben sind. Vor dem Rendern der einzelnen Frames wird die 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 Ausgangspunkt dient. Frame Width Minus One + 1 Pixel breit und Frame Height Minus One + 1 Pixel hoch werden mithilfe von Blending method auf dem Canvas gerendert.

Der Canvas wird Frame Duration Millisekunden angezeigt. Dies wird so lange fortgesetzt, bis alle durch ANMF-Chunks angegebenen Frames angezeigt werden. Dann wird eine neue Schleifeniteration gestartet oder der endgültige Zustand des Canvas wird beibehalten, wenn alle Iterationen abgeschlossen sind.

Der folgende Pseudocode veranschaulicht den Renderingprozess. Die Notation VP8X.field bedeutet das Feld im Chunk "VP8X" 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.
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
    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 Image 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 könnte 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)