WebP-Containerspezifikation

Einführung

WebP ist ein Bildformat, das entweder (i) die VP8-Keyframe-Codierung verwendet, die verlustbehaftete Komprimierung von Bilddaten oder (ii) die verlustfreie WebP-Codierung. Diese Codierungsschemas effizienter machen als ältere Formate wie JPEG, GIF und PNG. Es ist für eine schnelle Bildübertragung über das Netzwerk optimiert (für 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 für Folgendes:

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

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

  • Transparenz: Ein Bild kann 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, Animation erstellt wird.

Benennung

Es wird EMPFOHLEN, die folgenden Typen für den WebP zu verwenden Container:

Name des ContainerformatsWebP
Dateinamenserweiterung.webp
MIME-Typimage/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 (eine codierte Pixelmatrix) oder eine Animation zu erstellen. Optional kann sie auch Transparenz Informationen, ein Farbprofil und Metadaten. Wir bezeichnen die Pixelmatrix als Canvas des Bildes

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

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

Leser/Autor
Code, der WebP-Dateien liest, wird als Reader bezeichnet, während Code, der die sie schreibt, wird als writer bezeichnet.
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 eine uint32, die durch die Verkettung von vier ASCII-Zeichen in Little-Endian-Reihenfolge Das bedeutet „aaaa“. (0x61616161) und „AAAA“ (0x41414141) werden als verschiedene FourCCs behandelt.
1-basiert
Ein vorzeichenloses Ganzzahlfeld, in dem um -1 verschobene Werte gespeichert werden, z. B. eine solche würde den Wert 25 als 24 speichern.
ChunkHeader('ABCD')
Wird verwendet, um die Header FourCC und Chunk Size einzelner Blöcke zu beschreiben, wobei „ABCD“ ist der FourCC für den Chunk. Dieses Element ist 8 Byte groß.

RIFF-Dateiformat

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

Das Grundelement 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
Vier-Zeichen-ASCII-Code zur Chunk-Identifizierung.
Blockgröße: 32 Bit (uint32)
Die Größe des Blocks in Byte, ohne dieses Feld, den Block Kennung oder Abstand.
Chunk-Nutzlast: Chunk Size Byte
Die Datennutzlast. Wenn die Blockgröße ungerade ist, wird ein einzelnes Padding-Byte – MÜSSEN 0 sein, um RIFF zu erfüllen, wird hinzugefügt.

Hinweis: Bei RIFF gilt die Konvention, dass FourCCs in Großbuchstaben standardmäßig verwendet werden. Chunks, die für jedes RIFF-Dateiformat gelten, und FourCCs, die für eine Datei spezifisch sind alle kleingeschrieben werden. WebP folgt dieser Konvention nicht.

Kopfzeile der 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      '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 'WEBP' beginnen. Die Dateigröße im Header ist die Gesamtgröße der folgenden Blöcke plus 4 Byte für das WEBP FourCC. Die Datei DARF KEINE Daten im Anschluss an die Daten enthalten. die durch die Dateigröße festgelegt wird. Leser KÖNNEN solche Dateien parsen, ohne den nachfolgenden Daten. Da die Größe jedes Blocks gerade ist, ist die durch den RIFF-Header angegebene Größe und sogar gleichmäßig. Der Inhalt einzelner Blöcke wird im Folgenden beschrieben .

Einfaches Dateiformat (verlustbehaftet)

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

Einfaches WebP-Dateiformat (verlustbehaftet):

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

„VP8“ Chunk:

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

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

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

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

Einfaches Dateiformat (verlustfrei)

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

Dieses Layout SOLLTE verwendet werden, wenn das Bild eine verlustfreie Codierung (mit einem optionaler Transparenzkanal) und erfordert keine erweiterten Funktionen. durch das erweiterte Format.

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: Blockgröße Byte
VP8L-Bitstreamdaten.

Die aktuelle Spezifikation des VP8L-Bitstreams finden Sie unter Verlustloses Bitstream-Format von WebP. 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 optionales „ICCP“ Chunk mit einem Farbprofil.

  • Ein optionales „ANIM“ Chunk mit Animationskontrolldaten.

  • Bilddaten.

  • Eine optionale EXIF-Datei 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 bis:

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

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

Metadaten und unbekannte Blöcke KÖNNEN Reihenfolge.

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

Erweiterter WebP-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“ 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
1-basierte Breite des Canvas in Pixeln. Die tatsächliche Canvas-Breite beträgt 1 + Canvas Width Minus One.
Canvas-Höhe minus eins: 24 Bit
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 von „ANIM“ gesteuert und „ANMF“ Stücke.

„ANIM“ Chunk:

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANIM')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Background Color                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Loop Count           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hintergrundfarbe: 32 Bit (uint32)
Die Standardhintergrundfarbe des Canvas in [Blau, Grün, Rot, Alpha] Byte-Reihenfolge. Diese Farbe KANN verwendet werden, um den ungenutzten Platz auf dem Canvas zu füllen. um die Frames herum sowie die transparenten Pixel des ersten Frames. Die Hintergrundfarbe wird auch verwendet, wenn die Entsorgungsmethode 1 ist.

Hinweis:

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

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

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

Schleifenanzahl: 16 Bit (uint16)
Die Häufigkeit, mit der die Animation als Schleife wiedergegeben werden soll. Der Wert 0 bedeutet, dass unendlich.

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

„ANMF“ Chunk:

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANMF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Frame X                |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...          Frame Y            |   Frame Width Minus One     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |           Frame Height Minus One              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Frame Duration                |  Reserved |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         Frame Data                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame X: 24 Bit (uint24)
Die X-Koordinate der 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 Framebreite beträgt 1 + Frame Width Minus One.
Framehöhe abzüglich 1: 24 Bit (uint24)
Die 1-basierte Höhe des Frames. Die Framehöhe beträgt 1 + Frame Height Minus One.
Frame Duration: 24 Bit (uint24)
Die Wartezeit, bevor der nächste Frame angezeigt wird, in 1-Millisekunden-Einheiten. Beachten Sie, dass die Interpretation der Frame Duration von 0 (und oft <= 10) von der Implementierung definiert wird. Viele Tools und Browser weisen ein Minimum ähnlich wie beim GIF.
Reserviert: 6 Bit
MÜSSEN 0 sein. Leser MÜSSEN dieses Feld ignorieren.
Zusammenführungsmethode (B): 1 Bit

Gibt an, wie transparente Pixel des aktuellen Frames überlagert werden. mit den entsprechenden Pixeln des vorherigen Canvas:

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

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

Entsorgungsmethode (D): 1 Bit

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

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

  • 1: Auf die Hintergrundfarbe anwenden. Füllen Sie das Rechteck auf dem Canvas aus. durch den aktuellen Frame mit der im „ANIM“ Chunk.

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: Sie kann die gesamte Leinwand einnehmen.

  • Alpha-Blending:

    Da jeder der R-, G-, B- und A-Kanäle aus 8 Bit besteht und der RGB- Kanäle werden nicht mit Alpha multipliziert, also der Formel für die Zusammenführung. "dst" auf "src" lautet:

    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-Blendung SOLLTE im linearen Farbraum erfolgen, unter Berücksichtigung der Das Farbprofil des Bildes. Wenn das Farbprofil nicht vorhanden, wird von Standard-RGB (sRGB) ausgegangen. Bei sRGB werden auch aufgrund eines Gammas von ~2,2 linearisiert werden muss.)

Framedaten: Blockgröße – 16 Byte

Besteht aus:

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

Diese informativen Bit werden verwendet, um der Vorverarbeitung zu signalisieren, während der Komprimierung durchgeführt wurden. 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: Gradreduzierung.

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

Filtermethode (F): 2 Bit

Die verwendeten Filtermethoden werden im Folgenden beschrieben:

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

Die Filterung wird für jedes Pixel mithilfe der folgenden Berechnungen durchgeführt. Angenommen, die Alphawerte rund um die aktuelle Position von X sind folgendermaßen gekennzeichnet:

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

Wir versuchen, den Alphawert an Position X zu berechnen. Zunächst ist eine Vorhersage abhängig von der Filtermethode vorgenommen:

  • 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
  • V sonst

Der endgültige Wert wird abgeleitet, indem der dekomprimierte Wert 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 Pixelpositionen ganz links und ganz oben gibt es Sonderfälle. Für Beispiel: Der Wert oben links an der Position (0, 0) verwendet 0 als Prädiktorwert. Andernfalls:

  • Bei der horizontalen oder Farbverlaufsfilterung werden die Pixel ganz links Standort (0, y) werden anhand des oben angegebenen Standorts (0, y-1) vorhergesagt.
  • Bei vertikalen oder 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 – 1 Byte

Codierter Alpha-Bitstream.

Dieser optionale Chunk enthält codierte Alphadaten für diesen Frame. Ein Frame mit einem „VP8L“ Chunk sollte 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 von Länge = Breite * Höhe, mit allen 8-Bit-Transparenzwerten in Scanreihenfolge.

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

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

    Sobald der Bildstream in Alpha, Rot, Grün, Blau (ARGB) decodiert wurde wie im verlustfreien Format beschrieben. müssen die Informationen zur Transparenz aus dem green-Kanal des ARGB-Quadruplets

    Grund: Der grüne Kanal ermöglicht 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 sind wie in den Abschnitten beschrieben. Einfaches Dateiformat (verlustbehaftet) und Simple File Format (Lossless).

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 Bytes
ICC-Profil.

Dieser Block MUSS vor den Bilddaten stehen.

Es sollte höchstens einen Block dieser Art 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 höchstens einen Chunk von jedem Typ geben ("EXIF" und "XMP"). Wenn es mehr solche Blöcke sind, können die 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: 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 in der Liste "XMP" FourCC ist ein ASCII-Leerzeichen (0x20).

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

Unbekannte Chunks

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

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

Eine Datei KANN unbekannte Blöcke enthalten:

Leser SOLLTEN diese Blöcke ignorieren. Autoren SOLLTEN sie in ihren ursprüngliche Reihenfolge (es sei denn, die Blöcke sollen ausdrücklich geändert werden)

Canvas-Set aus Frames

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 im Feld „VP8X“ Chunk, Canvas Width Minus One + 1 Pixel breit und Canvas Height Minus One + 1 Pixel hoch. Das Feld Loop Count aus „ANIM“ Chunk-Steuerung wird der Animationsprozess wiederholt. Das ist Loop Count - 1 für 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. Frame Width Minus One + 1 Pixel breit x Frame Height Minus One + 1 Pixel werden mit dem Blending method auf dem Canvas gerendert.

Der Canvas wird Frame Duration Millisekunden lang angezeigt. Dies wird bis alle von "ANMF" vorgegebenen Frames Stücke wurden präsentiert. 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-Prozess. Die Notation VP8X.field ist das Feld in "VP8X". Chunk mit derselben Beschreibung.

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

Beispieldateilayouts

Ein verlustbehaftetes-codiertes Bild mit Alpha kann so aussehen:

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

Ein verlustfreies codiertes Bild kann so aussehen:

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

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

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

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

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