Dr. Jyrki Alakuijala, Google, Inc.
Vincent Rabaud, Ph.D., Google, Inc.
Zuletzt aktualisiert: 01.08.2017
Zusammenfassung: Wir vergleichen die Ressourcennutzung des WebP-Encoders/-Decoders mit der von PNG im verlustfreien und verlustbehafteten Modus. Wir verwenden einen Korpus von 12.000 zufällig ausgewählten durchscheinenden PNG-Bildern aus dem Web und einfachere Messungen, um Leistungsschwankungen anzuzeigen. Wir haben die PNGs in unserem Korpus komprimiert, um WebP-Bilder mit größenoptimierten PNGs zu vergleichen. Unsere Ergebnisse zeigen, dass WebP sowohl in Bezug auf Größe als auch Verarbeitungsgeschwindigkeit ein guter Ersatz für PNG ist, um es im Web zu verwenden.
Einführung
WebP unterstützt verlustfreie und durchscheinende Bilder und ist damit eine Alternative zum PNG-Format. Viele der bei der PNG-Komprimierung verwendeten grundlegenden Techniken wie Wörterbuchcodierung, Huffman-Codierung und Farbindexierungstransformation werden auch in WebP unterstützt, was im schlimmsten Fall zu einer ähnlichen Geschwindigkeit und Komprimierungsdichte führt. Gleichzeitig ermöglichen eine Reihe neuer Funktionen – wie separate Entropiecodes für verschiedene Farbkanäle, den 2D-Ort der Rückwärtsreferenzabstände und ein Farbcache mit kürzlich verwendeten Farben – eine verbesserte Komprimierungsdichte bei den meisten Bildern.
Bei dieser Arbeit vergleichen wir die Leistung von WebP mit PNGs, die mit pngcrush und ZopfliPNG stark komprimiert wurden. Wir haben unseren Referenzkorpus von Webbildern mithilfe von Best Practices neu komprimiert und sowohl die verlustfreie als auch die verlustbehaftete WebP-Komprimierung mit diesem Korpus verglichen. Zusätzlich zum Referenzkorpus wählten wir für Geschwindigkeits- und Arbeitsspeichernutzungs-Benchmarking zwei größere Bilder, ein fotografisches und ein grafisches Bild.
Es wurden Decodierungsgeschwindigkeiten als PNG und eine um 23 % stärkere Komprimierung als mit dem heutigen PNG-Format gezeigt. Wir sind der Ansicht, dass WebP ein effizienterer Ersatz für das heutige PNG-Bildformat ist. Darüber hinaus bietet die verlustbehaftete Bildkomprimierung mit verlustfreier Alpha-Unterstützung weitere Möglichkeiten zur Beschleunigung von Websites.
Methoden
Befehlszeilentools
Wir verwenden die folgenden Befehlszeilentools, um die Leistung zu messen:
cwebp und dwebp. Die folgenden Tools, die Teil der libwebp-Bibliothek (aus dem Head kompiliert) sind.
Conversion ausführen. Dies ist ein Bestandteil des Befehlszeilentools der ImageMagick-Software (6.7.7-10 21.07.2017).
pngcrush 1.8.12 (30. Juli 2017)
ZopfliPNG (17. Juli 2017)
Wir verwenden die Befehlszeilentools mit den jeweiligen Kontroll-Flags. Wenn wir beispielsweise auf cwebp -q 1 -m 0 verweisen, bedeutet dies, dass das cwebp-Tool mit den Flags -q 1 und -m 0 aufgerufen wurde.
Bildkorpora
Es wurden drei Korpora ausgewählt:
Ein einzelnes Foto (Abbildung 1)
Ein einzelnes grafisches Bild mit Transparenz (Abbildung 2) und
Ein Webkorpus: 12.000 zufällig ausgewählte PNG-Bilder mit oder ohne Durchlässigkeit, die aus dem Internet gecrawlt wurden. Diese PNG-Bilder werden mithilfe von Convert, PNGcrush oder ZopfliPNG optimiert. Für die Studie wird die kleinste Version der einzelnen Bilder berücksichtigt.
Abbildung 1. Foto mit 1024 × 752 Pixeln. Feueratmung "Jaipur Maharaja Brass Band" Chassepierre Belgien, Autor: Luc Viatour, Foto lizenziert unter der Creative Commons Attribution-Share Alike 3.0 Unported License. Die Website des Autors finden Sie hier.
Abbildung 2. Grafikbild im Format 1.024 x 752 Pixel. Collagenbilder aus Google Chart Tools
Um die volle Leistungsfähigkeit des vorhandenen Formats PNG zu messen, haben wir alle diese ursprünglichen PNG-Bilder mit mehreren Methoden komprimiert:
Auf 8 Bit pro Komponente festlegen: Konvertieren Sie „input.png -depth 8-output.png“.
ImageMagick(1) ohne Prädiktoren: convert input.png -quality 90 output-candidate.png
ImageMagick mit adaptiven Predictors: convert input.png -quality 95 output-candidate.png
Pngcrush(2): pngcrush -brute -rem tEXt -rem tIME -rem iTXt -rem zTXt -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text input.png output-candidate
ZopfliPNG(3): zopflipng --lossy_transparent input.png output-candidate.png
ZopfliPNG mit allen Filtern: zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparent input.png output-candidate.png
Ergebnisse
Wir haben die Komprimierungsdichte für jedes Bild im Webkorpus im Verhältnis zu den optimierten PNG-Bildgrößen für drei Methoden berechnet:
WebP – verlustfrei (Standardeinstellungen)
WebP verlustfrei mit der kleinsten Größe (-m 6 -q 100)
beste verlustfreies WebP und verlustbehaftetes WebP mit Alpha (Standardeinstellungen).
Wir haben diese Kompressionsfaktoren sortiert und in Abbildung 3 dargestellt.
Abbildung 3. Als Referenz wird die PNG-Komprimierungsdichte von 1, 0 verwendet. Dieselben Bilder werden sowohl mit verlustfreien als auch mit verlustbehafteten Methoden komprimiert. Für jedes Bild wird das Größenverhältnis zu komprimiertem PNG berechnet, die Größenverhältnisse sortiert und sowohl für die verlustfreie als auch für die verlustbehaftete Komprimierung angezeigt. Für die verlustbehaftete Komprimierungskurve wird die verlustfreie Komprimierung ausgewählt, wenn damit ein kleineres WebP-Bild erzeugt wird.
WebP geht über die PNG-Komprimierungsdichte sowohl für libpng bei maximaler Qualität (konvertieren) als auch für ZopfliPNG (Tabelle 1) hinaus, wobei die Codierungs- (Tabelle 2) und Decodierungsgeschwindigkeiten (Tabelle 3) ungefähr mit denen von PNG vergleichbar sind.
Tabelle 1. Durchschnittliche Bits pro Pixel für die drei Korpora mit den verschiedenen Komprimierungsmethoden.
| Bildsatz | konvertieren - Qualität 95 | ZopfliPNG | WebP verlustfrei -q 0 -m 1 | WebP – verlustfrei (Standardeinstellungen) | WebP verlustfrei -m 6 -q 100 | Verlustbehaftetes WebP mit Alpha |
|---|---|---|---|---|---|---|
| foto | 12.3 | 12.2 | 10.5 | 10.1 | 9.83 | 0.81 |
| grausam [if not including sexual activity], nicht jugendfrei [if including sexual activity] | 1.36 | 1,05 | 0.88 | 0.71 | 0,70 | 0,51 |
| web | 6.85 | 5.05 | 4.42 | 4.04 | 3.96 | 1.92 |
Tabelle 2 Durchschnittliche Codierungszeit für die Komprimierungskorpora und für verschiedene Komprimierungsmethoden.
| Bildsatz | konvertieren - Qualität 95 | ZopfliPNG | WebP verlustfrei -q 0 -m 1 | WebP – verlustfrei (Standardeinstellungen) | WebP verlustfrei -m 6 -q 100 | Verlustbehaftetes WebP mit Alpha |
|---|---|---|---|---|---|---|
| foto | 0,500 s | 8,7 s | 0,293 s | 0,780 s | 8,440 s | 0,111 s |
| grausam [if not including sexual activity], nicht jugendfrei [if including sexual activity] | 0,179 s | 14 Sek. | 0,065 s | 0,140 s | 3,510 s | 0,184 s |
| web | 0,040 s | 1,55 s | 0,017 s | 0,072 s | 2,454 s | 0,020 s |
Tabelle 3 Durchschnittliche Decodierungszeit für die drei Korpora für Bilddateien, die mit unterschiedlichen Methoden und Einstellungen komprimiert wurden.
| Bildsatz | konvertieren - Qualität 95 | ZopfliPNG | WebP verlustfrei -q 0 -m 1 | WebP – verlustfrei (Standardeinstellungen) | WebP verlustfrei -m 6 -q 100 | Verlustbehaftetes WebP mit Alpha |
|---|---|---|---|---|---|---|
| foto | 0,027 s | 0,026 s | 0,027 s | 0,026 s | 0,027 | 0,012 s |
| Grafiken | 0,049 s | 0,015 s | 0,005 s | 0,005 s | 0.003 | 0,010 s |
| web | 0,007 s | 0,005 s | 0,003 s | 0,003 s | 0.003 | 0,003 s |
Speicherprofilerstellung
Für die Arbeitsspeicherprofilerstellung haben wir die maximale Größe des residenten Satzes aufgezeichnet, wie in /usr/bin/time -v angegeben.
Im Webkorpus definiert die Größe des größten Bildes allein die maximale Speichernutzung. Damit die Messung des Arbeitsspeichers besser definiert wird, verwenden wir ein einzelnes Foto (Abbildung 1), um einen Überblick über die Speichernutzung zu geben. Das grafische Bild liefert ähnliche Ergebnisse.
Wir haben 10 bis 19 MiB für libpng und ZopfliPNG und 25 MiB bzw. 32 MiB für die verlustfreie WebP-Codierung in den Einstellungen -q 0 -m 1 bzw. -q 95 (mit dem Standardwert -m) gemessen.
In einem Decodierungsexperiment verwendet die Konvertierung -resize 1x1 10 MiB sowohl für die libpng- als auch für die ZopfliPNG-generierten PNG-Dateien. Mit cwebp verwendet die verlustfreie WebP-Decodierung 7 MiB und die verlustbehaftete Decodierung 3 MiB.
Ergebnisse
Wir haben gezeigt, dass sich die Codierungs- und die Decodierungsgeschwindigkeiten im selben Domainbereich wie PNG befinden. Während der Codierungsphase nimmt die Speichernutzung zu, aber die Decodierungsphase zeigt einen gesunden Rückgang, zumindest beim Vergleich des Verhaltens von cwebp mit dem von ImageMagicks Konvertierung.
Die Komprimierungsdichte ist für mehr als 99% der Webbilder besser, was darauf hindeutet, dass sich ein Bild relativ leicht von PNG zu WebP ändern lässt.
Wenn WebP mit den Standardeinstellungen ausgeführt wird, wird es um 42% besser komprimiert als libpng und um 23% besser als ZopfliPNG. Dies deutet darauf hin, dass WebP sich dafür eignet, Websites mit vielen Bildern zu beschleunigen.
Verweise
Externe Links
Die folgenden unabhängigen Studien werden nicht von Google gesponsert. Google ist nicht für die Richtigkeit aller Inhalte verantwortlich.