Notizen vom Team zu Handwerk, Formaten und den kleinen Entscheidungen hinter einem guten Ergebnis.
Warum WebP in Desktop-Programmen nicht überall unterstützt wird
WebP erschien 2010 bei Google, doch die Übernahme durch Desktop-Software hinkte der Browser-Unterstützung weit hinterher. Browser nahmen WebP früh auf, weil sie ihre eigenen Rendering-Engines kontrollieren und Google die WebP-Unterstützung in Chrome als Wettbewerbsvorteil aktiv förderte. Desktop-Anwendungen brauchen für ein neues Bildformat länger, denn jede pflegt ihren eigenen Bilddekodier-Stack und die Unterstützung eines neuen Formats verlangt Tests gegen eine lange Reihe von Sonderfällen. Adobe Photoshop, das Werkzeug der meisten professionellen Fotografen und Designer, lieferte native WebP-Unterstützung erst mit Version 23.2 Ende 2022. Microsoft-Office-Anwendungen behandeln WebP plattformübergreifend bis 2026 uneinheitlich. Print-RIP-Software und die meisten alten Archivierungswerkzeuge übernahmen WebP nie. In der Praxis heißt das, eine Datei, die im Browser perfekt aussieht, kann von genau der Software abgelehnt werden, die der Nutzer braucht, und die Umwandlung in PNG ist der verlässliche Ausweg.
Wie WebP seinen Kompressionsvorteil gegenüber PNG erreicht
PNG nutzt DEFLATE, einen verlustfreien Allzweck-Algorithmus von 1996. Er legt vor der Kompression eine Reihe umkehrbarer Scanline-Filter an und kodiert das Ergebnis mit einem zlib-Strom. Das ist wirksam, stammt aber aus der Zeit vor der Forschung an Videocodecs und maschinellem Lernen, die bessere Techniken hervorbrachte. Der verlustbehaftete WebP-Modus nutzt eine blockbasierte Transformation aus der VP8-Videokompression und wendet Intraframe-Vorhersage und eine diskrete Kosinustransformation auf 16x16-Makroblöcke an. Der verlustfreie WebP-Modus nutzt räumliche Vorhersage, eine Farbtransformation und eine LZ77-Stufe, die für typische Bildinhalte strukturell effizienter als DEFLATE ist. Googles veröffentlichte Messungen zeigen verlustfreies WebP rund 26 Prozent kleiner als PNG auf einem Standard-Testkorpus und verlustbehaftetes WebP mit Alpha rund dreimal kleiner als PNG bei vergleichbarer sichtbarer Qualität. Der Weg von PNG zu WebP nutzt diese Gewinne, der Weg von WebP zu PNG kehrt sie um, daher die größere Ausgabe.
Gemessene Beispiele für das Größenwachstum
Gemessen auf Chrome 148, Linux-Desktop, mit dem PNG-Schreibpfad der Plattform auf dekodierten WebP-Eingaben. Eine kleine Grafik im Vektorstil mit 400x300 Pixeln, gespeichert als WebP mit Qualität 80, wird in etwa 15 bis 25 ms als PNG neu geschrieben, mit einem typischen Größenzuwachs von 20 bis 30 Prozent. Ein fotografisches WebP mit 1024x768 Pixeln, kleiner Größe, wird in unter 100 ms als PNG neu geschrieben, mit einem typischen Wachstum vom Drei- bis Fünffachen. Ein großes fotografisches WebP mit 3840x2160 Pixeln, größerer Dateigröße, wird in etwa 1,2 Sekunden als PNG geschrieben, mit einem Wachstum vom Fünf- bis Zehnfachen je nach Bildkomplexität. Die praktische Obergrenze liegt bei einem großen WebP-Foto, das zu einem vielfach schwereren PNG wird. Diese Zahlen spiegeln den Unterschied in der Kompressionseffizienz zwischen den beiden Formaten und wachsen linear mit der Pixelzahl.
Alpha-Transparenz auf dem Hin- und Rückweg
Der 8-Bit-Transparenzkanal in WebP und PNG nutzt denselben Wertebereich, wobei 0 vollständig transparent und 255 vollständig deckend bedeutet. Dekodiert der Browser ein WebP mit Alpha, erzeugt er einen Pixelpuffer mit RGBA-Werten, deren A-Komponente die ursprünglichen Alphadaten widerspiegelt. Wird dieser Puffer als PNG neu geschrieben, schreibt der PNG-Schreiber die A-Werte direkt in den Transparenzkanal des PNG. Es findet kein Compositing statt, keine Hintergrundfarbe wird angewandt und keine Vormultiplikation verändert die Pixelwerte. Das Ergebnis ist eine verlustfreie Übergabe des Transparenzkanals, bei der die Deckkraft jedes Pixels im PNG dem entspricht, was das WebP gespeichert hatte. Bei Bildern mit feiner Kantenglättung übersteht jeder Zwischenwert den Weg unversehrt, etwa ein Pixel mit 40 Prozent Deckkraft an einer Textkante. Diese Treue macht PNG zur richtigen Wahl gegenüber JPG, wenn das Zielprogramm das Bild auf mehreren Hintergründen anzeigen muss.
Verhalten von EXIF und Metadaten
Der Neuschreib-Ablauf entfernt EXIF-, IPTC- und XMP-Metadaten aus der PNG-Ausgabe. WebP-Dateien können EXIF-Daten in ihrem Metadaten-Chunk tragen, und diese Daten gehen verloren, wenn der Browser das Bild dekodiert und neu schreibt. ICC-Farbprofile folgen einem anderen Weg, Chrome und Safari erhalten das sRGB-ICC-Profil im PNG nach dem Dekodieren des WebP, Firefox entfernt alle Metadaten einschließlich des ICC-Profils. In der Praxis heißt das sRGB-sichere Ausgabe in allen Browsern, doch ein im Quell-WebP eingebettetes Weitfarbraum-Profil übersteht Firefox nicht. Für professionelle Foto-Abläufe, die auf ICC-getaggten Hin- und Rückwegen beruhen, nimm ein metadatenbewusstes Umwandlungswerkzeug. Für die übliche Web-Bildverarbeitung ist das Entfernen der Metadaten meist akzeptabel und hat den kleinen Vorteil, die Ausgabedatei etwas zu verkleinern.
Datenschutz in der Praxis überprüfen
Die Behauptung, dass keine Dateidaten den Browser verlassen, lässt sich ohne Sonderwerkzeug prüfen. Öffne deinen Browser, geh zur webp-to-png-Seite und öffne dann die Entwicklertools mit F12 oder über das Rechtsklickmenü. Wechsle zum Netzwerk-Tab, leere die vorhandenen Anfragen und führe eine Umwandlung durch, indem du ein WebP ablegst. Filtere die Liste nach Fetch, XHR oder All. Die Liste zeigt während des Schreibens null ausgehende Anfragen mit Bilddaten. Die einzigen vorhandenen Anfragen sind die Ladeobjekte der Seite und übliche Analyse-Pings, die nur Seitenaufrufe und Core-Web-Vitals-Leistungsdaten erfassen, ohne Bildinhalt. Jeder große entfernte Konverter für WebP zu PNG erzeugt mindestens einen Upload-POST und einen Download-GET pro Umwandlung, beide auf dem Server protokolliert. Die Architektur auf dem Gerät bedeutet, dass diese Logeinträge nicht existieren, und das ist der bedeutsame Unterschied für Nutzer, die Dateien mit sensiblem Inhalt umwandeln.
