Bildformate: WebP

Google hat WebP ursprünglich als verlustbehaftetes Bildformat entwickelt, um JPEG zu ersetzen. Damit konnten Dateien erstellt werden, die kleiner als eine als JPEG codierte Bilddatei von vergleichbarer Qualität sind. Spätere Aktualisierungen des Formats boten die Möglichkeit einer verlustfreien Komprimierung, eine PNG-ähnliche Alphakanal-Transparenz und eine GIF-ähnliche Animation, die alle zusammen mit der verlustbehafteten Komprimierung im JPEG-Stil verwendet werden können. WebP ist ein unglaublich vielseitiges Format.

Der verlustbehaftete Komprimierungsalgorithmus von WebP basiert auf einer Methode, mit der der VP8-Videocodec Keyframes in Videos komprimiert. Auf übergeordneter Ebene ist sie der JPEG-Codierung ähnlich: WebP arbeitet eher mit "Blöcken" als einzelnen Pixeln und unterscheidet sich zwischen Helligkeit und Chrominanz. Die Luma-Blöcke von WebP haben eine Größe von 16 x 16, während die Chromablöcke 8 x 8 groß sind und diese "Makroblöcke" weiter in 4 x 4-Subblöcke unterteilt sind.

WebP unterscheidet sich radikal von JPEG in zwei Merkmalen: der Blockvorhersage und der adaptiven Blockquantisierung.

Blockvorhersage

Die Blockvorhersage ist der Prozess, durch den der Inhalt jedes Chrominanz- und Leuchtdichteblocks anhand der Werte der umgebenden Blöcke vorhergesagt wird, insbesondere der Blöcke oberhalb und links vom aktuellen Block. Wie Sie sich vorstellen können, sind die Algorithmen, die diese Arbeit leisten, ziemlich komplex. Einfacher ausgedrückt: „Wenn über dem aktuellen Block Blau und links vom aktuellen Block Blau angezeigt wird, gehen wir davon aus, dass dieser Block blau ist.“

Tatsächlich ist diese Art der Vorhersage in PNG und JPEG auch zu einem gewissen Grad möglich. WebP ist jedoch einzigartig, da es die Daten der umgebenden Blöcke stichprobenartig abtastet und dann versucht, den aktuellen Block über verschiedene "Vorhersagemodi" zu füllen, um effektiv den fehlenden Teil des Bildes zu "zeichnen". Die von jedem Vorhersagemodus bereitgestellten Ergebnisse werden dann mit den echten Bilddaten verglichen und die genaueste Vorhersageübereinstimmung wird ausgewählt.

Ein Diagramm der verschiedenen Blockvorhersagemethoden von WebP.

Selbst die genaueste prädiktive Übereinstimmung wird natürlich nicht vollständig korrekt sein. Daher werden die Unterschiede zwischen den vorhergesagten und tatsächlichen Werten dieses Blocks in der Datei codiert. Beim Decodieren des Bildes verwendet die Rendering-Engine dieselben Daten, um dieselbe Vorhersagelogik anzuwenden, was zu denselben vorhergesagten Werten für jeden Block führt. Die Differenz zwischen der Vorhersage und dem erwarteten Bild, das in der Datei codiert wurde, wird dann auf die Vorhersagen angewendet – ähnlich wie ein Git-Commit einen differenziellen Patch darstellt, der über die lokale Datei angewendet wird, anstatt eine neue Kopie der Datei.

Zur Verdeutlichung: Anstatt sich mit der komplexen Mathematik des eigentlichen Vorhersagealgorithmus zu befassen, werden wir eine WebP-ähnliche Codierung mit einem einzelnen Vorhersagemodus erfinden und verwenden, um ein Zahlenraster effizient wie bei den Legacy-Formaten umzuwandeln. Unser Algorithmus verfügt über einen einzelnen Vorhersagemodus, den wir "Vorhersagemodus eins" nennen: Der Wert jedes Blocks ist die Summe der Werte der Blöcke darüber und links davon, beginnend mit 1.

Angenommen, wir beginnen mit den folgenden echten Bilddaten:

111151111
122456389

Bei Verwendung unseres Vorhersagemodells zur Bestimmung des Inhalts eines 2x9-Rasters erhalten wir das folgende Ergebnis:

111111111
123456789

Unsere Daten passen gut zu unserem von uns erfundenen Vorhersagealgorithmus – die vorhergesagten Daten stimmen sehr stark mit unseren realen Daten überein. Natürlich nicht perfekt – die tatsächlichen Daten bestehen aus mehreren Blöcken, die sich von den vorhergesagten Daten unterscheiden. Die von uns gesendete Codierung umfasst also nicht nur die zu verwendende Vorhersagemethode, sondern auch eine Differenz aller Blöcke, die von ihren vorhergesagten Werten abweichen sollten:

_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _

Verwenden Sie die gleiche einfache Sprache wie einige der alten Formatcodierungen, die wir besprochen haben:

2x9-Raster mit Vorhersagemodus 1. +4 bis 1 x 5, -1 bis 2 x 3, -4 bis 2 x 7.

Das Endergebnis ist eine unglaublich effizient codierte Datei.

Adaptive Blockquantisierung

Die JPEG-Komprimierung ist ein pauschaler Vorgang, bei dem auf jeden Block im Bild dieselbe Quantisierungsstufe angewendet wird. Für ein Bild mit einer einheitlichen Komposition ergibt das durchaus Sinn – aber Fotos aus der realen Welt sind nicht gleichförmiger als die Welt um uns herum. In der Praxis bedeutet dies, dass unsere JPEG-Komprimierungseinstellungen nicht anhand der Details mit hoher Frequenz bestimmt werden, bei denen die JPEG-Komprimierung besonders gut ist, sondern von den Teilen des Bilds, in denen Komprimierungsartefakte am wahrscheinlichsten zu sehen sind.

Komprimiertes JPEG-Bild eines Monarchfalters

Wie Sie in diesem übertriebenen Beispiel sehen können, sehen die Flügel des Monarchen im Vordergrund relativ scharf aus – im Vergleich zum hochauflösenden Original etwas körnig, aber ohne das Original zum Vergleich mit dem Original definitiv nicht erkennbar. Auch die detaillierte Blütezeit des Milchgrases und die Blätter im Vordergrund können mit unseren geschulten Augen Spuren von Kompressionsartefakten sehen, aber selbst bei einer deutlich über einen angemessenen Pegel eingestellten Kompression ist der Vordergrund dennoch passiv gestochen scharf. Die niedrige Frequenz oben links im Bild – der verschwommene grüne Hintergrund der Blätter – sieht schrecklich aus. Selbst ein nicht trainierter Betrachter würde das Qualitätsproblem sofort bemerken – die dezenten Farbverläufe im Hintergrund werden zu gezackten, einfarbigen Blöcken abgerundet.

Um dies zu vermeiden, verfolgt WebP einen adaptiven Ansatz zur Quantisierung: Ein Bild wird in bis zu vier optisch ähnliche Segmente unterteilt, wobei die Komprimierungsparameter für diese Segmente unabhängig voneinander abgestimmt werden. Dieselbe komprimierte Komprimierung mit WebP:

Ein komprimiertes WebP-Bild eines Monarchfalters

Die Größe dieser beiden Bilddateien ist in etwa gleich. Die Qualität der Flügel des Monarchen ist ungefähr die gleiche. Wenn man sich die Flügel des Monarchen sehr genau ansieht, kann man kleine Unterschiede im Endergebnis erkennen, aber keinen wirklichen Unterschied in der Gesamtqualität. Im WebP sind die Blüten von Milchgras nur ein wenig schärfer – wahrscheinlich nicht genug, um erkennbar zu sein, es sei denn, Sie vergleichen die beiden Gegenüber und suchen wirklich nach Qualitätsunterschieden, wie wir sind. Der Hintergrund ist insgesamt eine andere: Er enthält kaum eine Spur der offensichtlichen Artefakte von JPEG. WebP liefert uns die gleiche Dateigröße, aber ein viel höheres Bild – geben oder nehmen Sie ein paar winzige Details, die unsere psychovisuellen Systeme nicht erkennen könnten, wenn wir die beiden nicht so genau vergleichen würden.

WebP verwenden

Das Interna von WebP mag wesentlich komplexer sein als die JPEG-Codierung, ist aber im Rahmen unserer täglichen Arbeit genauso einfach: Die gesamte Komplexität der WebP-Codierung basiert auf einem einzigen „Qualitätswert“, der wie bei JPEG von 0–100 ausgedrückt wird. Und das heißt noch einmal, dass das nicht heißt, dass Sie auf eine einzige übergreifende „Qualitätseinstellung“ begrenzt sind. Sie können und sollten mit allen Details der WebP-Codierung experimentieren, um besser zu verstehen, wie sich diese normalerweise nicht sichtbaren Einstellungen auf die Dateigröße und -qualität auswirken.

Google bietet einen cwebp-Befehlszeilen-Encoder, mit dem du einzelne Dateien oder ganze Bilderverzeichnisse konvertieren oder komprimieren kannst:

$ cwebp -q 80 butterfly.jpg -o butterfly.webp

Saving file 'butterfly.webp'
File:   butterfly.jpg
Dimension: 1676 x 1418
Output: 208418 bytes Y-U-V-All-PSNR 41.00 43.99 44.95   41.87 dB
        (0.70 bpp)
block count:    intra4:     7644  (81.80%)
               Intra16:     1701  (18.20%)
               Skipped:       63  (0.67%)
bytes used:  header:            249  (0.1%)
              mode-partition:  36885  (17.7%)
Residuals bytes  |segment 1|segment 2|segment 3|segment 4|  total
macroblocks:     |       8%|      22%|      26%|      44%|   9345
quantizer:       |      27 |      25 |      21 |      13 |
filter level:    |       8 |       6 |      19 |      16 |

Und wenn Sie nicht für die Befehlszeile geneigt sind, wird uns Squoosh bei der Codierung von WebP genauso gut nutzen. Sie bietet uns die Möglichkeit, verschiedene Codierungen, Einstellungen, Qualitätsstufen und Unterschiede in der Dateigröße der JPEG-Codierung direkt zu vergleichen.