WebP-Containerspezifikation

Einführung

WebP ist ein Bildformat, das entweder (i) die VP8-Schlüsselframe-Codierung zur verlustbehafteten Komprimierung von Bilddaten oder (ii) die verlustfreie WebP-Codierung verwendet. Durch diese Codierungsschemata sollte es effizienter sein als ältere Formate wie JPEG, GIF und PNG. Sie ist für die schnelle Bildübertragung über das Netzwerk optimiert (z. B. für Websites). Das WebP-Format hat Funktionsparität (Farbprofil, Metadaten, Animationen usw.) mit anderen Formaten verknüpfen. In diesem Dokument wird Folgendes beschrieben: die Struktur einer WebP-Datei.

Der WebP-Container (d. h. der RIFF-Container für WebP) ermöglicht die Funktionsunterstützung. über den grundlegenden Anwendungsfall von WebP (d. h. eine Datei mit als VP8-Keyframe codiertes Bild). Der WebP-Container bietet zusätzliche Unterstützung für Folgendes:

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

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

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

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

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

Benennung

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

Name des ContainerformatsWebP
Dateinamenserweiterung.webp
MIME-typeimage/webp
Einheitliche Kennungorg.webmproject.webp

Terminologie und Grundlagen

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

Eine WebP-Datei enthält entweder ein Standbild (d. h. eine codierte Pixelmatrix) oder eine Animation. Optional können sie auch Transparenzinformationen, ein Farbprofil und Metadaten enthalten. Wir bezeichnen die Pixelmatrix als Canvas des 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 die sie schreibt, wird als writer bezeichnet.
uint16
Eine vorzeichenlose 16-Bit-Ganzzahl im Little-Endian-Format.
uint24
Eine vorzeichenlose 24-Bit-Ganzzahl im Little-Endian-Format.
uint32
Eine 32-Bit-Little-Endian-Ganzzahl ohne Vorzeichen.
FourCC
Ein vierstelliger Code (FourCC) ist eine uint32, die durch die Verkettung von vier ASCII-Zeichen in Little-Endian-Reihenfolge 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 hat eine Größe von 8 Byte.

RIFF-Dateiformat

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

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

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

Hinweis: Bei RIFF ist es üblich, dass FourCCs von Chunks in Großbuchstaben Standard-Chunks sind, die für jedes RIFF-Dateiformat gelten, während FourCCs, die für ein Dateiformat spezifisch sind, nur Kleinbuchstaben enthalten. WebP folgt dieser Konvention nicht.

WebP-Dateiheader

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

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

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

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

Simple File Format (verlustfrei)

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

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

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 in Byte
VP8L-Bitstream-Daten.

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

Erweitertes Dateiformat

Hinweis: Ältere 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 Animation.

  • Bilddaten

  • Ein optionaler EXIF-Chunk mit EXIF-Metadaten.

  • Ein optionales XMP Chunk 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 Chunks, also „VP8X“, „ICCP“, „ANIM“, „ANMF“, „ALPH“, „VP8“ und „VP8L“, MÜSSEN in der oben beschriebenen Reihenfolge erscheinen. Leser SOLLTEN scheitern, wenn für die Rekonstruktion erforderliche Blöcke erforderlich sind. und Farbkorrektur nicht in der richtigen Reihenfolge.

Metadaten und unbekannte Blöcke können von Reihenfolge.

Grund: Die für die Rekonstruktion erforderlichen Teile sollten zuerst in den damit der Leser mit der Decodierung eines Bildes beginnen kann, bevor alle mit den Daten. Für eine Anwendung kann es vorteilhaft sein, die Reihenfolge der Metadaten und benutzerdefinierten Blöcke an die Implementierung anzupassen.

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
MUSS 0 lauten. Leser MÜSSEN dieses Feld ignorieren.
ICC-Profil (I): 1 Bit
Legt fest, ob die Datei einen „ICCP“ enthält Chunk.
Alpha (L): 1 Bit
Legen Sie fest, ob einer der Frames des Bildes Transparenzinformationen enthält („Alpha“).
EXIF-Metadaten (E): 1 Bit
Legt fest, ob die Datei EXIF-Metadaten enthält.
XMP-Metadaten (X): 1 Bit
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.
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.
Canvasbreite minus eins: 24 Bit
Breite der Zeichenfläche in Pixeln (basierend auf 1). Die tatsächliche Leinwandbreite beträgt 1 + Canvas Width Minus One.
Canvas-Höhe minus eins: 24 Bit
Die 1-basierte Höhe des Canvas in Pixeln. Die tatsächliche Höhe der Leinwand beträgt 1 + Canvas Height Minus One.

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

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

Animation

Eine Animation wird durch ANIM- und ANMF-Chunks gesteuert.

„ANIM“ Chunk:

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANIM')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Background Color                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Loop Count           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hintergrundfarbe: 32 Bit (uint32)
Die Standard-Hintergrundfarbe der Leinwand in der 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.

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

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

Schleifenzählung: 16 Bit (uint16)
Die Häufigkeit, mit der die Animation als Schleife wiedergegeben werden soll. Wenn es 0 ist, bedeutet das unendlich.

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

„ANMF“ Chunk:

Bei animierten Bildern enthält dieser Block Informationen zu einem einzelnen Frame. Wenn das Animation-Flag nicht gesetzt ist, DARF 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 linken oberen Ecke des Frames ist Frame X * 2.
Frame Y: 24 Bit (uint24)
Die Y-Koordinate der oberen linken Ecke des Frames ist Frame Y * 2.
Framebreite minus eins: 24 Bit (uint24)
Die auf 1 basierende Breite des Frames. Die Frame-Breite beträgt 1 + Frame Width Minus One.
Frame-Höhe − 1: 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, bevor der nächste Frame angezeigt wird, in 1-Millisekunden-Einheiten. Die Interpretation der Framedauer von 0 (und oft <= 10) wird durch die Implementierung definiert. Viele Tools und Browser weisen eine Mindestdauer zu, die der von GIFs ähnelt.
Reserviert: 6 Bit
MUSS 0 lauten. Leser MÜSSEN dieses Feld ignorieren.
Methode für die Überblendung (B): 1 Bit

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

  • 0: Alphaverbund 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 vermischen. 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ülle das Rechteck auf dem Canvas, das vom aktuellen Frame abgedeckt wird, mit der im Chunk „ANIM“ angegebenen Hintergrundfarbe aus.

Hinweise:

  • Die Entsorgung von Frames gilt nur für Frame Rectangle, d. h. Rechteck definiert durch Frame X, Frame Y, Frame-Breite und Frame Höhe: 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.

Framedaten: Blockgröße Byte – 16

Umfasst:

Hinweis: Das 'ANMF' Frame-Daten, 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
MUSS 0 lauten. Leser MÜSSEN dieses Feld ignorieren.
Vorverarbeitung (P): 2 Bit

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

  • 0: Keine Vorverarbeitung.
  • 1: Stufenreduzierung.

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

Filtermethode (F): 2 Bit

Die verwendeten Filtermethoden werden im Folgenden beschrieben:

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

Für jedes Pixel wird der Filter mithilfe der folgenden Berechnungen angewendet. 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 je nach Filtermethode eine Vorhersage getroffen:

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

wobei clip(v) gleich ist:

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

Der endgültige Wert ergibt sich aus der Addition des dekomprimierten Werts X zur Predictor und mithilfe der Modulo-256-Arithmetik den [256...511]-Bereich in den [0..255] ein:

alpha = (predictor + X) % 256

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

  • Bei horizontalen oder Gradientenfiltermethoden werden die Pixel links an der Position (0, y) anhand der Position (0, y-1) direkt darüber vorhergesagt.
  • Bei vertikalen oder Farbverlaufsfilterungsmethoden werden die obersten Pixel Standort (x, 0) werden mithilfe des Standorts (x-1, 0) links vorhergesagt.
Komprimierungsmethode (C): 2 Bit

Die verwendete Komprimierungsmethode:

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

Codierter Alpha-Bitstream.

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

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

Die Alphakanaldaten werden als unkomprimierte Rohdaten gespeichert (wenn der Komprimierungsmethode „0“) 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 Komprimierung: Die Bytefolge ist ein komprimierter Bildstream (wie im WebP Lossless Bitstream Format beschrieben) mit impliziten Abmessungen „Breite × Höhe“. Das bedeutet, dass In "image-stream" sind KEINE Kopfzeilen enthalten, die die Bildabmessungen beschreiben.

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

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

    Grund: Der grüne Channel erlaubt eine zusätzliche Transformation. Schritte in der Spezifikation, die im Gegensatz zu den anderen Kanälen um die Kompression zu verbessern.

Bitstream (VP8/VP8L)

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

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

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

Farbprofil

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

Dieser Block MUSS vor den Bilddaten erscheinen.

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

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

Metadaten

Metadaten können in „EXIF“ gespeichert werden oder XMP Stücke.

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

Die Blöcke sind so definiert:

„EXIF“ Chunk:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('EXIF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        Exif Metadata                          :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
EXIF-Metadaten: Chunk Size 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: Blockgröße 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

Einen RIFF-Chunk (im Abschnitt RIFF-Dateiformat beschrieben) dessen FourCC sich von den in diesem Dokument beschriebenen Teilen unterscheidet, ist 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 ihren ursprüngliche Reihenfolge (es sei denn, die Blöcke sollen ausdrücklich geändert werden).

Leinwandbilder aus Frames zusammensetzen

Hier geben wir einen Überblick darüber, wie ein Leser im Fall eines animierten Bildes.

Der Prozess beginnt mit der Erstellung eines Canvas mit den Abmessungen, die im „VP8X“ Chunk, Canvas Width Minus One + 1 Pixel breit und Canvas Height Minus One + 1 Pixel hoch. Mit dem Feld Loop Count aus dem Chunk „ANIM“ wird festgelegt, wie oft der Animationsvorgang wiederholt wird. Das ist Loop Count - 1 für Loop Count-Werte ungleich null oder unendlich, wenn Loop Count Null ist.

Zu Beginn jeder Schleifeniteration wird der Canvas mit den Hintergrundfarbe von ANIM Chunk oder eine anwendungsdefinierte Farbe.

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

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

Der Canvas wird für Frame Duration Millisekunden angezeigt. Dies wird so lange fortgesetzt, bis alle Frames angezeigt wurden, die durch „ANMF“-Chunks angegeben wurden. Eine neue Schleifeniteration ist wird gestartet oder das Canvas bleibt in seinem endgültigen Zustand, wenn alle Iterationen abgeschlossen.

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 könnte 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)