Diese Seite wurde von der Cloud Translation API übersetzt.

WebP-Containerspezifikation

Einführung

WebP ist ein Bildformat, das entweder (i) die VP8-Schlüsselframe-Codierung zum verlustbehafteten Komprimieren von Bilddaten oder (ii) die verlustfreie WebP-Codierung verwendet. Mit diesen Codierungsschemas sollte es effizienter sein als mit älteren Formaten wie JPEG, GIF und PNG. Sie ist für die schnelle Übertragung von Bildern über das Netzwerk optimiert (z. B. für Websites). Das WebP-Format weist ebenfalls die gleichen Merkmale (Farbprofil, Metadaten, Animation usw.) wie andere Formate auf. In diesem Dokument wird die Struktur einer WebP-Datei beschrieben.

Der WebP-Container (der RIFF-Container für WebP) ermöglicht die Unterstützung von Funktionen über den grundlegenden Anwendungsfall von WebP hinaus (also 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: Mit dem WebP Loss Loss Format kann ein Bild verlustfrei komprimiert werden.
Metadaten: Ein Bild kann Metadaten im Format von Exchangeable Image File (Exif) oder Extensible Metadata Platform (XMP) enthalten.
Transparenz: Ein Bild kann Transparenz haben, 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

Wir empfehlen, für den WebP-Container die folgenden Typen zu verwenden:

Name des Containerformats	WebP
Dateinamenserweiterung	WEBP
MIME-Typ	Bild/WebP
Uniform Type Identifier	org.webmproject.webp

Terminologie und Grundlagen

Die in diesem Dokument verwendeten Schlüsselwörter „MUSS“, „MÜSSEN NICHT“, „ERFORDERLICH“, „SOLLTE“, „WIRD NICHT“, „SOLLTE“, „SOLLTE NICHT“, „EMPFOHLEN“, „NICHT EMPFOHLEN“, „MAY“ und „OPTIONAL“ wie in BCP 14 RFC 2119 beschrieben werden.

Eine WebP-Datei enthält entweder ein Standbild (d. h. eine codierte Matrix von Pixeln) oder eine Animation. Optional können sie auch Transparenzinformationen, ein Farbprofil und Metadaten enthalten. Die Matrix der Pixel wird als Canvas bezeichnet.

Die Bitnummerierung in Blockdiagrammen beginnt mit 0 für das stärkste Bit („MSB 0“), wie in RFC 1166 beschrieben.

Die folgenden Begriffe werden in diesem Dokument verwendet:

Leser/Autor: Code, der WebP-Dateien liest, wird Leser genannt. Code, der sie schreibt, wird Autor.
Uint16: Eine 16-Bit-Little-Endian-Ganzzahl ohne Vorzeichen.
Uint24: Eine 24-Bit-Little-Endian-Ganzzahl ohne Vorzeichen.
uint32: Eine 32-Bit-Little-Endian-Ganzzahl ohne Vorzeichen.
FourCC: Ein vierstelliger Code (FourCC) ist ein uint32, der durch die Verkettung von vier ASCII-Zeichen in kleinem Ende erstellt wird. Das bedeutet, dass „aaaa“ (0x61616161) und „AAAA“ (0x41414141) als unterschiedliche FourCCs behandelt werden.
1-basiert: Ein nicht signiertes Ganzzahlfeld, das Werte enthält, die durch -1 verschoben werden, z. B. würde ein Wert 25 als 24 speichern.
ChunkHeader('ABCD'): Wird verwendet, um die Header FourCC und Chunk Size einzelner Segmente zu beschreiben. Dabei ist „ABCD“ der FourCC für den Block. Die Größe dieses Elements beträgt 8 Byte.

RIFF-Dateiformat

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

Das grundlegende Element einer RIFF-Datei ist ein Block. 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-Code mit vier Zeichen, der zur Identifizierung des Blocks verwendet wird.
Chunk-Größe: 32 Bit (uint32): Die Größe des Blocks in Byte, ohne dieses Feld, die Chunk-ID oder den Abstand.
Chunk-Nutzlast: Chunk Size-Byte: Die Datennutzlast. Wenn Chunk-Größe ungerade ist, wird ein einzelnes Padding-Byte – das 0 sein muss, um RIFF zu entsprechen – hinzugefügt.

Hinweis:RIFF hat die Konvention, dass FourCC-Großbuchstaben Standardblöcke sind, die für jedes RIFF-Dateiformat gelten. FourCCs, die für ein Dateiformat spezifisch sind, werden dagegen kleingeschrieben. 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 Höchstwert dieses Feldes ist 2^32 minus 10 Bytes und damit ist die Größe der gesamten Datei 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 beginnen, der mit dem „FPCC WEBP“ verknüpft ist. Die Dateigröße im Header entspricht der Gesamtgröße der nachfolgenden Teile sowie 4 Byte für den „WEBP“-FourCC. Die Datei dürfte nach den durch Dateigröße angegebenen Daten keine Daten enthalten. Leser können solche Dateien parsen, wobei die nachgestellten Daten ignoriert werden. Da die Größe eines Blocks gleichmäßig ist, ist die vom RIFF-Header angegebene Größe auch gerade. Der Inhalt einzelner Chunks wird in den folgenden Abschnitten beschrieben.

Einfaches Dateiformat (verloren)

Dieses Layout SOLLTE VERWENDET WERDEN, wenn das Bild eine verlustbehaftete Codierung erfordert und keine Transparenz oder andere erweiterte Funktionen erfordert. Dateien mit diesem Layout sind kleiner und werden von älteren Softwareanwendungen unterstützt.

Einfaches WebP-Dateiformat (loslos):

 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 Byte: VP8-Bitstream-Daten.

Das vierte Zeichen in FourCC „VP8“ ist ein ASCII-Leerzeichen (0x20).

Die VP8-Bitstream-Formatspezifikation wird im VP8-Datenformat und -Decodierungsleitfaden beschrieben. Der VP8-Frame-Header enthält die VP8-Frame-Breite und -Höhe. Dabei wird von der Breite und Höhe des Canvas ausgegangen.

In der VP8-Spezifikation wird beschrieben, wie das Bild im Y'CbCr-Format decodiert wird. Für die Umwandlung in RGB SOLLTEN Sie die Empfehlung BT.601 verwenden. Anwendungen KÖNNEN mit einer anderen Conversion-Methode arbeiten. Die visuellen Ergebnisse können jedoch je nach Decoder unterschiedlich sein.

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 optionalem Transparenzkanal) und keine erweiterten Funktionen erfordert, die im erweiterten Format bereitgestellt werden.

Einfaches verlustfreies WebP-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: Chunk-Größe Byte: VP8L-Bitstream-Daten.

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

Erweitertes Dateiformat

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

Eine Datei im erweiterten Format besteht aus folgenden Teilen:

Ein „VP8X“-Block mit Informationen zu den in der Datei verwendeten Funktionen.
Ein optionaler „ICCP“- Chunk mit einem Farbprofil.
Ein optionaler „ANIM“-Block mit Animationssteuerungsdaten.
Bilddaten
Ein optionaler „EXIF“-Block mit Exif-Metadaten.
Ein optionaler „XMP“-Block mit XMP-Metadaten.
Eine optionale Liste mit unbekannten Teilen.

Bei einem Standbild bestehen die Bilddaten aus einem einzelnen Frame, der sich folgendermaßen zusammensetzt:

Ein optionaler Alpha-Unterblock.
Ein Bitstream-Unterstück.

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

Alle Teile sollten in der gleichen Reihenfolge wie oben aufgeführt platziert werden. Wenn ein Block an der falschen Stelle angezeigt wird, ist die Datei ungültig, aber Leser können die Datei parsen, wobei die einzelnen Abschnitte ignoriert werden.

Grund:Wenn Sie die Reihenfolge der Segmente festlegen, sollte die Datei schneller geladen werden. Wenn beispielsweise der Chunk „ALPH“ an der erforderlichen Position nicht angezeigt wird, kann der Decoder die Suche beenden. Die Regel, dass späte Teilstücke ignoriert werden, sollte dafür sorgen, dass Programme, die eine vollständige Suche durchführen müssen, dieselben Ergebnisse liefern wie Programme, die frühzeitig stoppen.

Header der erweiterten WebP-Datei:

 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: Muss 0 sein. Die Leser müssen dieses Feld ignorieren.
ICC-Profil (I): 1 Bit: Legen Sie fest, ob die Datei einen „ICCP“-Block enthält.
Alpha (L): 1 Bit: Legen Sie fest, ob einer der Frames des Bildes Transparenzinformationen enthält („Alpha“).
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. Die Animationen in den Spalten „ANIM“ und „ANMF“ sollten zur Steuerung der Animation verwendet werden.
Reserviert (R): 1 Bit: Muss 0 sein. Die Leser müssen dieses Feld ignorieren.
Reserviert: 24 Bit: Muss 0 sein. Die Leser müssen dieses Feld ignorieren.
Canvas Breite Minus One: 24 Bit: 1-basierte Breite des Canvas in Pixeln. Die tatsächliche Canvasbreite beträgt 1 + Canvas Width Minus One.
Canvas Höhe Minus One: 24 Bit: 1-basierte Höhe der Canvas in Pixel. Die tatsächliche Canvashöhe beträgt 1 + Canvas Height Minus One.

Das Produkt Canvasbreite und Canvashöhe dürfte maximal 2^32 - 1 sein.

In Zukunft werden möglicherweise weitere Felder hinzugefügt. Unbekannte Felder MUSS ignoriert werden.

Animation

Eine Animation wird durch die Spalten 'ANIM' und 'ANMF' gesteuert.

'ANIM' Chunk:

Bei einem animierten Bild enthält dieser Teil 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 der Leinwand in Bytereihenfolge [Blau, Grün, Rot, Alpha]. Diese Farbe kann verwendet werden, um den nicht genutzten Platz auf dem Canvas um die Rahmen herum 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 Alpha-Flag im 'VP8X' Chunk nicht festgelegt ist.
Betrachteranwendungen dürfen die Hintergrundfarbe als Hinweis behandeln und sind nicht erforderlich.
Der Canvas wird zu Beginn jeder Schleife gelöscht. Die Hintergrundfarbe kann verwendet werden.

Anzahl der Schleifen: 16 Bit (uint16): Die Häufigkeit, mit der die Animation in einer Schleife wiedergegeben wird. Wenn es 0 ist, bedeutet dies unbegrenzt.

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

„ANMF“ Chunk:

Bei animierten Bildern enthält dieser Abschnitt Informationen über einen einzelnen Frame. Wenn das Animations-Flag nicht festgelegt ist, MUSS dieser Teil 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 Rahmens ist Frame X * 2.

Frame Y: 24 Bit (uint24)

Die y-Koordinate der oberen linken Ecke des Rahmens ist Frame Y * 2.

Frame Width Minus One: 24 Bit (uint24)

Die 1-basierte Breite des Rahmens. Die Rahmenbreite beträgt 1 + Frame Width Minus One.

Framehöhe, Minus One: 24 Bit (uint24)

Die 1-basierte Höhe des Rahmens. Die Rahmenhöhe beträgt 1 + Frame Height Minus One.

Frame-Dauer: 24 Bit (uint24)

Die Zeit, die gewartet wird, bis der nächste Frame in einer Millisekunde angezeigt wird. Die Interpretation der Framedauer von 0 (oft <= 10) wird durch die Implementierung definiert. Viele Tools und Browser weisen eine ähnliche Mindestzeit auf, ähnlich wie bei GIF.

Reserviert: 6 Bit

Muss 0 sein. Die 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 sollen:

0: Alphamischen. Nachdem Sie den vorherigen Frame verworfen haben, können Sie den aktuellen Frame auf dem Canvas mithilfe von Alpha-Rendering rendern (siehe unten). Wenn der aktuelle Frame keinen Alphakanal hat, nehmen Sie an, dass der Alphawert 255 ist, wodurch das Rechteck effektiv ersetzt wird.
1 nicht zusammenführen. Wenn Sie den vorherigen Frame verworfen haben, können Sie den aktuellen Frame auf dem Canvas rendern, indem Sie das von dem 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, bevor er den nächsten Frame gerendert hat:

0: Nicht entsorgen. Lassen Sie den Canvas unverändert.
1: Entwerfen Sie die Hintergrundfarbe. Füllen Sie das Rechteck auf dem Canvas aus, das mit dem aktuellen Frame bedeckt ist, und legen Sie die Hintergrundfarbe im ANIM-Block fest.

Hinweise:

Die Frameentsorgung gilt nur für das Frame-Rechteck, also das Rechteck, das durch Frame X, Frame Y, Frame-Breite und Frame-Höhe definiert wurde. Sie deckt unter Umständen die gesamte Leinwand ab.
Alpha-Blending:

Da die Kanäle R, G, B und A jeweils 8 Bit umfassen und die RGB-Kanäle nicht vorab mit Alpha multipliziert werden, würde die Formel zum Zusammenführen von „dst“ mit „src“ so berechnet:
```
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
```
Für das Zusammenführen von Alphadateien sollte ein linearer Farbraum verwendet werden. Dabei muss das Farbprofil des Bildes berücksichtigt werden. Ist das Farbprofil nicht vorhanden, wird Standard-RGB (sRGB) verwendet. (sRGB muss außerdem aufgrund eines Gamma von ~2,2 linearisiert werden.)

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

Bestehen aus:

Ein optionales Alpha-Unterstück für den Frame.
Ein Bitstream-Unterstück für den Frame.
Eine optionale Liste mit unbekannten Teilen.

Hinweis: Die oben beschriebene Nutzlast „ANMF“ (Framedaten) besteht aus einzelnen aufgefüllten Teilen, 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 sein. Die 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 ausgeführt wurde. Der Decoder kann diese Informationen verwenden, um beispielsweise die Werte abzuschwächen oder die Farbverläufe vor der Anzeige zu glätten.

0: Keine Vorverarbeitung.
1: Level-Reduzierung.

Decoder sind nicht verpflichtet, diese Informationen auf irgendeine Weise zu verwenden.

Filtermethode (F): 2 Bit

Die verwendeten Filtermethoden werden so beschrieben:

0: Keine.
1: Horizontaler Filter.
2: Vertikaler Filter.
3: Filter mit Farbverlauf.

Für jedes Pixel wird die Filterung anhand der folgenden Berechnungen durchgeführt. Nehmen wir an, dass die Alphawerte um die aktuelle Position von X so beschriftet sind:

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

Wir möchten den Alphawert an Position X berechnen. Erstens wird je nach Filtermethode eine Vorhersage getroffen:

Methode 0: Vorhersage = 0
Methode 1: Vorhersage = A
Methode 2: Vorhersage = B
Methode 3: Vorhersage = Clip(A + B – C)

wobei clip(v) gleich ist:

0, wenn v < 0,
255, wenn v > 255, oder
V, andernfalls

Der endgültige Wert wird abgeleitet, indem der dekomprimierte Wert X zum Vorhersager hinzugefügt und mit dem Modulo-256-arithmetischen Bereich der Bereich [256..511] in den Bereich [0..255] verpackt wird:

alpha = (predictor + X) % 256

Es gibt Sonderfälle für die Pixelpositionen ganz links und ganz oben. Der Wert oben links am Standort (0, 0) verwendet beispielsweise 0 als Vorhersagewert. Andernfalls:

Bei horizontalen oder Farbverlaufsmethoden wird die Position ganz links an der Position (0, y) mithilfe der Position (0, y-1) unmittelbar oben prognostiziert.
Bei Methoden zum Filtern von vertikalen oder Farbverläufen werden die obersten Pixel am Standort (x, 0) mithilfe des Standorts (x-1, 0) auf der linken Seite prognostiziert.

Komprimierungsmethode (C): 2 Bit

Die verwendete Komprimierungsmethode:

0: Keine Komprimierung.
1: Komprimiert im verlustfreien WebP-Format.

Alpha-Bitstream: Chunk-Größe – 1 Byte

Codierter Alpha-Bitstream.

Dieser optionale Teil enthält codierte Alphadaten für diesen Frame. Ein Frame mit einem „VP8L“-Chunk sollte diesen Teil nicht enthalten.

Grund: Die Informationen zur Transparenz sind bereits Bestandteil des „VP8L“-Chunk.

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

Rohdaten: Der Wert besteht aus einer Bytesequenz mit der Länge = Breite × Höhe, die alle 8-Bit-Transparenzwerte in der Scanreihenfolge enthält.
Verlustfreie Komprimierung von Formaten: Die Bytesequenz ist ein komprimierter Bildstream (wie unter "WebP Lossless Bitstream Format" beschrieben) mit der impliziten Größe x Höhe. Das bedeutet, dass dieser Bildstream KEINE Header enthält, die die Bildabmessungen beschreiben.

Grund: Die Dimensionen sind bereits aus anderen Quellen bekannt, sodass eine erneute Speicherung redundant und anfälliger für Fehler ist.

Sobald der Bildstream gemäß den in der Spezifikation zum verlustfreien Format beschriebenen Farbwerten in Alpha, Rot, Grün, Blau (ARGB) decodiert wurde, müssen die Transparenzinformationen aus dem grünen Kanal des ARGB-Quaduplets extrahiert werden.

Rationale: Dem grünen Kanal sind im Gegensatz zu den anderen Kanälen zusätzliche Transformationsschritte in der Spezifikation erlaubt, die die Komprimierung verbessern können.

Bitstream (VP8/VP8L)

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

Ein Bitstream-Abschnitt kann entweder (i) ein „VP8“- oder ein „VP8“-Zeichen sein. Er enthält „4“. Dies ist der Name des vierten Zeichens als FourCC. Oder (ii) ein „VP8L“-Chunk, wobei „VP8L“ als FourCC verwendet wird.

Die Formate „VP8“ und „VP8L“ werden in den Abschnitten Einfaches Dateiformat (Lossy) und Einfaches Dateiformat (Loss) 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 Size-Byte: ICC-Profil

Dieser Teil MUSS vor den Bilddaten erscheinen.

Es sollte höchstens ein solches Stück geben. Wenn es mehr solche Segmente gibt, können die Leser alle ignorieren, mit Ausnahme des ersten. Weitere Informationen finden Sie in der ICC-Spezifikation.

Ist dieser Teil nicht vorhanden, wird von sRGB SOLLTEN angenommen.

Metadaten

Metadaten können in den Spalten „EXIF“ oder „XMP“ gespeichert werden.

Es sollte höchstens ein Teil jedes Typs („EXIF“ und „XMP“) vorhanden sein. Wenn es mehr solche Segmente gibt, können die Leser alle ignorieren, mit Ausnahme des ersten.

Die Segmente 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 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 Byte: Bildmetadaten im XMP-Format.

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

Weitere Informationen zum Umgang mit Metadaten finden Sie in den Richtlinien zum Umgang mit Metadaten in der Metadaten-Arbeitsgruppe.

Unbekannte Chunks

Ein RIFF-Block (im Abschnitt RIFF-Dateiformat beschrieben), dessen FourCC sich von den in diesem Dokument beschriebenen Teilen unterscheidet, wird als unbekannter Teil betrachtet.

Grund: Wenn Sie unbekannte Teile zulassen, können die Formate dieses Formats weiter erweitert werden. Außerdem werden alle anwendungsspezifischen Daten gespeichert.

Eine Datei enthält möglicherweise unbekannte Teile:

am Ende der Datei verwenden, wie im Abschnitt Erweiterte WebP-Dateiheader beschrieben, oder
am Ende der „ANMF“-Spalten, wie im Abschnitt Animation beschrieben.

Die Leser sollten diese Textteile ignorieren. Die Autoren SOLLTEN sie in ihrer ursprünglichen Reihenfolge beibehalten, sofern sie diese Segmente nicht ausdrücklich ändern möchten.

Canvas-Baugruppe aus Rahmen

Hier zeigen wir Ihnen, wie ein Nutzer ein Canvasbild erstellen muss, wenn ein animiertes Bild verwendet wird.

Der Prozess beginnt damit, einen Canvas mit den Abmessungen im „VP8X“-Block zu erstellen. Dieser ist Canvas Width Minus One + 1 Pixel breit und Canvas Height Minus One + 1 Pixel hoch. Das Feld Loop Count aus dem Chunk „ANIM“ legt fest, wie oft der Animationsprozess wiederholt wird. Das ist Loop Count - 1 für Loop Count-Werte ungleich null oder unendlich, wenn Loop Count null ist.

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

Chunks in 'ANMF' enthalten einzelne Frames, die in der Anzeigereihenfolge angegeben sind. Vor dem Rendern jedes Frames wird der Disposal method des vorherigen Frames angewendet.

Das Rendering des decodierten Frames beginnt an den kartesischen Koordinaten (2 * Frame X, 2 * Frame Y) und beginnt mit dem linken oberen Rand des Canvas. 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 lang angezeigt. Dies wird fortgesetzt, bis alle von „ANMF“-Frames angegebenen Frames angezeigt wurden. Danach wird eine neue Iterationsaktualisierung gestartet oder der Canvas wird in seinem letzten Zustand ausgeführt, wenn alle Iterationen abgeschlossen sind.

Der folgende Pseudocode veranschaulicht den Renderingprozess. Die Notation VP8X.field bedeutet, dass das Feld im "VP8X"-Block mit derselben Beschreibung verwendet wird.

assert VP8X.flags.hasAnimation
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
assert next chunk in image_data is ANMF
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
    assert VP8X.canvasWidth >= frame_right
    assert VP8X.canvasHeight >= frame_bottom
    for subchunk in 'Frame Data':
      if subchunk.tag == "ALPH":
        assert alpha subchunks not found in 'Frame Data' earlier
        frame_params.alpha = alpha_data
      else if subchunk.tag == "VP8 " OR subchunk.tag == "VP8L":
        assert bitstream subchunks not found in 'Frame Data' earlier
        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

Beispiel für Dateilayouts

Ein verlustbehaftetes codiertes Bild mit Alpha sieht in etwa so aus:

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 ifif-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)