WebP-Containerspezifikation

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Einführung

WebP ist ein Bildformat, das entweder (i) die VP8-Keyframe-Codierung verwendet, um Bilddaten verlustbehaftet zu komprimieren, oder (ii) die verlustfreie WebP-Codierung (und möglicherweise andere Codierungen in der Zukunft). Diese Codierungsschemas sollten effizienter sein als derzeit verwendete Formate. Sie ist für die schnelle Übertragung von Bildern über das Netzwerk optimiert (z.B. für Websites). Das WebP-Format weist Funktionsmerkmale (Farbprofil, Metadaten, Animation usw.) und andere Formate auf. In diesem Dokument wird die Struktur einer WebP-Datei beschrieben.

Der WebP-Container (d.h. RIFF-Container für WebP ermöglichen die Feature-Unterstützung über den grundlegenden Anwendungsfall von WebP (d.h. eine Datei mit einem einzelnen Bild, das als VP8-Keyframe codiert ist). Der WebP-Container bietet zusätzliche Unterstützung für:

  • Verdichtete Kompression Ein Bild kann mit dem WebP Loss Loss Format verlustfrei komprimiert werden.

  • Metadaten: In einem Bild können Metadaten in Exif- oder XMP-Formaten gespeichert sein.

  • 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 zwischen den Bildern haben und so als Animation dienen.

Die in diesem Dokument verwendeten Schlüsselwörter "must", "must not", "required", "shall", "shall not", "should", "should not", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" sind wie in BCP 14 RFC 2114 beschrieben.

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

Benennung

Es wird EMPFOHLEN, die folgenden Typen zu verwenden, wenn auf den WebP-Container verwiesen wird:

ContainerformatnameWebP
DateinamenserweiterungWEBP
MIME-TypBild/WebP
Uniform Type Identifierorg.webmproject.webp

Terminologie und Grundlagen

Eine WebP-Datei enthält entweder ein Standbild (d.h. eine codierte Matrix von Pixeln) oder eine Animation. Optional kann sie auch Transparenzinformationen, ein Farbprofil und Metadaten enthalten. Wenn wir uns nur auf die Pixelmatrix beziehen möchten, nennen wir sie canvas des Bildes.

Im Folgenden finden Sie weitere Begriffe, die in diesem Dokument verwendet werden:

Leser/Autor
Code, der WebP-Dateien liest, wird als Reader bezeichnet. Code, der sie schreibt, wird als Writer bezeichnet.
uint16
Eine 16-Bit-Ganzzahl ohne Vorzeichen, Little-Endian.
uint24
Eine 24-Bit-Ganzzahl ohne Vorzeichen, Little-Endian.
uint32
Eine 32-Bit-Ganzzahl ohne Vorzeichen, Little-Endian.
FourCC
Ein FourCC (4-stelliger Code) ist eine uint32, die durch die Verkettung von vier ASCII-Zeichen in Little-Endian-Reihenfolge erstellt wird. Das bedeutet, dass „aaaa“ (0x61616161) und „AAAA“ (0x41414141) als unterschiedliche FourCCs behandelt werden.
1-basiert
Ein nicht signiertes Ganzzahlfeld, in dem die Werte von -1 verschoben werden. z. B. Ein solches Feld würde den Wert 25 als 24 speichern.
ChunkHeader(ABCD)
Die Beschreibung wird verwendet, um die Header FourCC und Chunk Size einzelner Blöcke zu beschreiben. Dabei ist „ABCD“ der FourCC-Block für den Block. Die Größe dieses Elements beträgt 8 Byte.

RIFF-Dateiformat

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

Das Grundelement 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
Ein vierstelliger ASCII-Code für die Chunk-Identifizierung.
Chunk-Größe: 32 Bit (uint32)
Die Größe des Chunks in Byte, ohne dieses Feld, die Chunk-ID oder das Padding.
Chunk-Nutzlast: Chunk-Größe Byte
Die Datennutzlast. Wenn die Chunk-Größe ungerade ist, wird ein einzelnes Byte hinzugefügt, das 0 entsprechen muss, um RIFF zu entsprechen.

Hinweis:RIFF hat eine Konvention, dass FourCC-Großbuchstaben Standardblöcke sind, die für jedes RIFF-Dateiformat gelten, während FourCCs, die spezifisch für ein Dateiformat sind, nur kleingeschrieben werden. WebP folgt dieser Konvention nicht.

WebP-Dateiheader

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'R'      |      'I'      |      'F'      |      'F'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           File Size                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'W'      |      'E'      |      'B'      |      'P'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'RIFF': 32 Bit
Die ASCII-Zeichen „R“, „I“, „F“ und „F“
Dateigröße: 32 Bit (uint32)
Die Größe der Datei in Byte ab Offset 8. Der maximale Wert dieses Feldes beträgt 2^32 minus 10 Byte. Die Größe der gesamten Datei beträgt daher maximal 4 GiB minus 2 Byte.
„WEBP“: 32 Bit
Die ASCII-Zeichen „W“, „E“, „B“ und „P“.

Eine WebP-Datei MUSS mit einem RIFF-Header mit FourCC „WEBP“ beginnen. Die Dateigröße im Header ist die Gesamtgröße der nachfolgenden Blöcke sowie 4 Byte für die FourCC-Datei „WEBP“. Die Datei DARF KEINE Daten nach den unter Dateigröße angegebenen Daten enthalten. Leser KÖNNEN solche Dateien parsen, wobei die angehängten Daten ignoriert werden. Da die Größe eines Blocks gerade ist, ist auch die Größe des RIFF-Headers gleichmäßig. Der Inhalt einzelner Blöcke wird in den folgenden Abschnitten beschrieben.

Einfaches Dateiformat (verlusthaft)

Dieses Layout sollte verwendet werden, wenn das Bild eine verlustbehaftete Codierung und keine Transparenz oder andere erweiterte Funktionen erfordert, die im erweiterten Format bereitgestellt 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-Block:

 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“ von „VP8“ ist ein ASCII-Leerzeichen (0x20).

Die VP8-Bitstream-Formatspezifikation finden Sie im VP8-Format für Datenformat und Decodierung. Der VP8-Frameheader enthält die Breite und Höhe des VP8-Frames. Es wird als Breite und Höhe des Canvas angenommen.

In der VP8-Spezifikation wird beschrieben, wie das Bild in das Y'CbCr-Format decodiert wird. Für die Konvertierung in RGB sollte Rec. 601 verwendet werden. Anwendungen KÖNNEN eine andere Conversion-Methode verwenden, die visuellen Ergebnisse können sich jedoch je nach Decoder unterscheiden.

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 des erweiterten Formats erfordert.

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-Block:

 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 verlustfreien BitP-Format von WebP. Der VP8L-Header enthält die VP8L-Bildbreite und -höhe. Es wird als Breite und Höhe des Canvas angenommen.

Erweitertes Dateiformat

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

Eine Datei mit erweiterten Formaten besteht aus:

  • Ein „VP8X“-Block mit Informationen zu den in der Datei verwendeten Funktionen.

  • Ein optionaler ICC-Block mit Farbprofil.

  • Ein optionaler Block "ANIM" mit Animationssteuerungsdaten.

  • Bilddaten.

  • Ein optionaler Teil des Typs „EXIF“ mit Exif-Metadaten.

  • Ein optionaler XMP-Block-Block mit XMP-Metadaten.

  • Eine optionale Liste unbekannter Blöcke.

Bei einem Standbild bestehen die Bilddaten aus einem einzelnen Frame, der Folgendes umfasst:

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

Alle Blöcke sollten sich in der oben angegebenen Reihenfolge befinden. Wenn ein Chunk an der falschen Stelle angezeigt wird, ist die Datei ungültig, aber Leser KÖNNEN die Datei parsen und die Stücke, die nicht in der richtigen Reihenfolge sind, ignorieren.

Grund: Wenn Sie die Reihenfolge der Blöcke festlegen, sollte die Datei schneller geparst werden können. Wenn beispielsweise ein „ALPH“-Block nicht an der erforderlichen Position angezeigt wird, kann ein Decoder die Suche damit beenden. Die Regel, dass späte Blöcke ignoriert werden, sollte dafür sorgen, dass Programme, die eine vollständige Suche durchführen müssen, die gleichen Ergebnisse wie Programme liefern, die vorzeitig beendet werden.

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. Dieses Feld muss von Lesern ignoriert werden.
ICC-Profil (I): 1 Bit
Legen Sie fest, ob die Datei ein ICC-Profil enthält.
Alpha (L): 1 Bit
Legen Sie fest, ob ein Frame 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. Daten in den Blöcken „ANIM“ und „ANMF“ sollten zur Steuerung der Animation verwendet werden.
Reserviert (R): 1 Bit
Muss 0 sein. Dieses Feld muss von Lesern ignoriert werden.
Reserviert: 24 Bit
Muss 0 sein. Dieses Feld muss von Lesern ignoriert werden.
Canvas Breite Minus: 24 Bit
1-basierte Breite der Zeichenfläche in Pixel. Die tatsächliche Canvas-Breite beträgt 1 + Canvas Width Minus One.
Canvas Height Minus One: 24 Bit
1-basierte Höhe der Zeichenfläche in Pixel. Die tatsächliche Höhe des Arbeitsbereichs beträgt 1 + Canvas Height Minus One.

Das Produkt für Canvasbreite und Canvashöhe darf höchstens 2^32 - 1 betragen.

Bei zukünftigen Spezifikationen werden unter Umständen weitere Felder hinzugefügt. Unbekannte Felder MÜSSEN ignoriert werden.

Animation

Eine Animation wird von ANIM- und ANMF-Blöcken 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 des Canvas in [Byte, Grün, Rot, Alpha]. Diese Farbe kann verwendet werden, um den ungenutzten Platz auf dem Canvas um die Frames sowie die transparenten Pixel des ersten Frames zu füllen. Die Hintergrundfarbe wird auch verwendet, wenn die Entsorgung 1 ist.

Hinweis:

  • Die Hintergrundfarbe darf einen nicht undurchsichtigen Alphawert enthalten, auch wenn das Alpha-Flag im Block VP8X nicht festgelegt ist.

  • Betrachteranwendungen sollten die Hintergrundfarbe als Hinweis behandeln und müssen sie nicht verwenden.

  • Der Canvas wird am Anfang jeder Schleife gelöscht. Damit lässt sich die Hintergrundfarbe erreichen.

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

Dieser Block MUSS angezeigt werden, wenn das Animations-Flag im VP8X-Block festgelegt ist. Wenn das Flag Animation nicht festgelegt ist und dieser Teil vorhanden ist, muss es ignoriert werden.

ANMF-Block:

Bei animierten Bildern enthält dieser Teil Informationen über einen einzelnen Frame. Wenn das Animations-Flag nicht festgelegt ist, MUSS dieser Teil nicht vorhanden sein.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      ChunkHeader('ANMF')                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Frame X                |             ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...          Frame Y            |   Frame Width Minus One     ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...             |           Frame Height Minus One              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Frame Duration                |  Reserved |B|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                         Frame Data                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Frame X: 24 Bit (uint24)
Die X-Koordinate der oberen linken Ecke des Frames ist Frame X * 2.
Frame Y: 24 Bit (uint24)
Die Y-Koordinate der linken oberen Ecke des Frames beträgt Frame Y * 2.
Frame Width Minus One: 24 Bit (uint24)
Die 1-basierte Breite des Frames. Die Rahmenbreite beträgt 1 + Frame Width Minus One.
Frame Height Minus One: 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 in 1-Millisekunden-Einheiten angezeigt wird. Die Interpretation der Framedauer 0 (oft <= 10) ist definiert. Viele Tools und Browser weisen eine ähnliche Mindestdauer wie GIF auf.
Reserviert: 6 Bit
Muss 0 sein. Dieses Feld muss von Lesern ignoriert werden.
Mischmethode (B): 1 Bit

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

  • 0: Alpha-Blending verwenden. Nach dem Entfernen des vorherigen Frames rendern Sie den aktuellen Frame auf dem Canvas mithilfe von Alpha-Blending (siehe unten). Wenn der aktuelle Frame keinen Alphakanal hat, wird ein Alphawert von 255 angenommen.

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

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 wurde:

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

  • 1: Hintergrundfarbe entfernen Fülle das Rechteck des Canvas, das durch den aktuellen Frame bedeckt ist, mit der im ANIM-Block angegebenen Hintergrundfarbe.

Hinweise:

  • Die Entsorgung des Frames 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 kann die gesamte Leinwand abdecken.

  • Alpha-Blending:

    Da jeder der R-, G-, B- und A-Kanäle 8-Bit- und die RGB-Kanäle nicht vorab mit der Alphaversion multipliziert wird, lautet die Formel für die Zusammenführung 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 Alphazusammenführung sollte im linearen Farbraum unter Berücksichtigung des Farbprofils des Bildes erfolgen. Ist kein Farbprofil vorhanden, wird von sRGB ausgegangen. (Beachten Sie, dass sRGB auch aufgrund eines Gamma von ~2,2 linearisiert werden muss.)

Framedaten: Chunk-Größe16 Byte

Besteht aus:

Hinweis: Die „ANMF“-Nutzlast (Frame-Daten oben) besteht aus einzelnen Auffüllungsblö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 sein. Dieses Feld muss von Lesern ignoriert werden.
Vorverarbeitung (P): 2 Bit

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

  • 0: Keine Vorverarbeitung.
  • 1: Verringerung der Stufe.
Filtermethode (F): 2 Bit

Die verwendete Filtermethode:

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

Für jedes Pixel wird die Filterung mit den folgenden Berechnungen durchgeführt. Angenommen, die Alphawerte, die die aktuelle X-Position umgeben, 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: 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
  • v andernfalls

Der endgültige Wert wird abgeleitet, indem der dekomprimierte Wert X zum Predictor hinzugefügt und mithilfe von Modulo-256-Arithmetik der Bereich [256..511] in den Wert [0..255] zusammengefasst wird:

alpha = (predictor + X) % 256

Es gibt Sonderfälle für die Pixelpositionen ganz links und ganz links:

  • Der Wert oben links am Standort (0, 0) verwendet 0 als Vorhersagewert. Andernfalls:
  • Bei horizontalen oder Farbverlaufsfiltermethoden werden die ganz links befindlichen Pixel an der Position (0, y) mithilfe der Position oberhalb (0, y-1) unmittelbar über ihnen prognostiziert.
  • Bei Methoden zum Filtern von vertikalen und Farbverläufen werden die obersten Pixel an der Position (x, 0) mithilfe der Position (x-1, 0) auf der linken Seite vorhergesagt.

Decoder müssen diese Informationen in keiner Weise verwenden.

Komprimierungsmethode (C): 2 Bit

Die verwendete Komprimierungsmethode:

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

Codierter Alpha-Bitstream.

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

Grund: Die Transparenzinformationen sind bereits Teil des „VP8L“-Blocks.

Die Daten des Alphakanals werden als unkomprimierte Rohdaten gespeichert (wenn die Komprimierungsmethode „0“) oder im verlustfreien Format (wenn die Komprimierungsmethode „1“) lautet.

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

  • Komprimierungsverlust beim Verlust: Die Bytesequenz ist ein komprimierter Bildstream (wie unter Verlust von WebP-verlustfreiem Bitstream beschrieben) der impliziten Dimensionsbreite x Höhe. Das heißt, dieser Bildstream enthält KEINE Header, die die Bilddimension beschreiben.

    Grund: Die Dimension ist bereits aus anderen Quellen bekannt. Ein erneutes Speichern wäre daher redundant und fehleranfällig.

    Sobald der Bildstream in ARGB-Farbwerte decodiert ist, müssen die Transparenzinformationen gemäß dem in der verlustfreien Formatspezifikation beschriebenen Prozess aus dem grünen Kanal des ARGB-Vaduplets extrahiert werden.

    Grund: Im 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-Block kann entweder (i) ein VP8-Block sein, wobei "VP8" (bedeutender Leerraum mit vier Zeichen) oder ii ein VP8L-Block mit Tag "VP8L" ist.

Die Formate von VP8- und VP8L-Blöcken werden wie in den Abschnitten Einfaches Dateiformat (verlusthaft) und Einfaches Dateiformat (verlustfrei) beschrieben.

Farbprofil

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

Dieser Teil MUSS vor den Bilddaten erscheinen.

Es sollte höchstens einen solchen Teil geben. Wenn es mehr solcher Blöcke gibt, können die Leser mit Ausnahme des ersten Teils alle ignorieren. Weitere Informationen finden Sie in der ICC-Spezifikation.

Wenn dieser Teil nicht vorhanden ist, MUSS SRGB VORGESCHLAGEN werden.

Metadaten

Metadaten können in Blöcken vom Typ „EXIF“ oder „XMP“ gespeichert werden.

Es sollte höchstens ein Teil pro Typ („EXIF“ und „XMP“) vorhanden sein. Wenn es noch mehr solcher Stücke gibt, MÖGLICHERWEISE ignorieren die Leser den ersten.

Die Blöcke sind so definiert:

EXIF-Block:

 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-Block:

 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.

Beachten Sie, dass das vierte Zeichen in „FMPCC“ von XMP ein ASCII-Leerraum (0x20) ist.

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

Unbekannte Chunks

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

Grund: Wenn Sie unbekannte Blöcke zulassen, können Sie das Format in Zukunft verbessern und anwendungsspezifische Daten speichern.

Eine Datei enthält möglicherweise unbekannte Blöcke:

Leser sollten diese Blöcke ignorieren. Sie werden in der ursprünglichen Reihenfolge beibehalten, sofern sie nicht explizit geändert werden sollen.

Canvas aus Rahmen zusammenbauen

Hier finden Sie einen Überblick darüber, wie Leser ein Canvas für ein animiertes Bild zusammenbauen MÜSSEN.

Als Erstes wird ein Canvas mit den im „VP8X“-Block angegebenen Abmessungen mit einer Breite von Canvas Width Minus One + 1 Pixeln und einer Höhe von Canvas Height Minus One + 1 Pixeln erstellt. Das Feld Loop Count aus dem Block „ANIM“ steuert, wie oft der Animationsprozess wiederholt wird. Dies ist Loop Count - 1 für Loop Count-Werte ungleich null oder unendlich, wenn Loop Count null ist.

Zu Beginn jeder Iteration wird der Canvas mit der Hintergrundfarbe des Blocks „ANIM“ oder einer anwendungsdefinierten Farbe ausgefüllt.

'ANMF'-Blöcke enthalten einzelne Frames in der Anzeigereihenfolge. Vor dem Rendering der einzelnen Frames wird die Disposal method des vorherigen Frames angewendet.

Das Rendering des decodierten Frames beginnt an den kartesischen Koordinaten (2 * Frame X, 2 * Frame Y) und verwendet oben links den Canvas als Ausgangspunkt. Frame Width Minus One + 1 Pixel breit und Frame Height Minus One + 1 Pixel hoch werden mit dem Blending method auf dem Canvas gerendert.

Der Canvas wird Frame Duration Millisekunden lang angezeigt. Dies wird fortgesetzt, bis alle von „ANMF“-Blöcken angegebenen Frames angezeigt wurden. Anschließend wird eine neue Wiederholungsschleife gestartet oder der Canvas bleibt in seinem endgültigen Zustand, wenn alle Iterationen abgeschlossen sind.

Der folgende Pseudocode veranschaulicht den Renderingprozess. Die Notation VP8X.field bedeutet das Feld im Block „VP8X“ mit derselben Beschreibung.

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 * 1ms.
    dispose_method = frame_params.disposeMethod

Beispiele für Dateilayouts

Ein verlustbehaftetes codiertes Bild mit Alpha könnte 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)
+- XYZW (unknown chunk)
+- VP8L (lossless bitstream)

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

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

Ein animiertes Bild mit EXIF-Metadaten könnte so aussehen:

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