Googles „Guetzli“ senkt JPEG-Größen um bis zu 35 % bei konstanter Qualität
von André Westphal | 24 Kommentare
Irgendjemand bei Google hat eine Vorliebe für Schweizerdeutsch: Denn auch der neueste Bildkompressions-Encoder des Unternehmens bedient sich bei diesem speziellen Dialekt. Letztes Jahr hatte ich noch über „Brotli“ gebloggt. Jetzt legt Google wiederum mit „Guetzli“ nach. Es handelt sich dabei um einen neuen Encoder, der JPEG-Dateien bei gleichbleibender Bildqualität im Vergleich mit aktuellen Methoden deutlich stärker komprimieren kann. Dadurch sollen die Dateigrößen bei identischer Bildqualität um bis zu 35 % sinken. Alternativ kann man bei gleichbleibender Dateigröße bessere Bildqualität erreichen.
Die via Guetzli komprimierten JPEG-Dateien sind zu allen gängigen Programmen kompatibel, die auch aktuelle JPEGs nutzen – das war in der Vergangenheit bei anderen Methoden von Google (WebP, WebM) nicht immer der Fall. Der urige Name dürfte übrigens daher rühren, dass Guetzli bei Google Research in Zürich entwickelt wurde. Offenbar lässt man den Mitarbeitern bei der Namensgebung dort etwas freie Hand.
Guetzli setzt übrigens bei der Stufe der Quantisierung an, in welcher im Wesentlichen ungeordnete Daten neu geordnet werden, um die Kompression zu erleichtern. Jeder Encoder arbeitet hier etwas unterschiedlich. Google legt Guetzli ein „psychovisuelles“ Modell zugrunde, was bedeutet, dass man sich daran orientiert, wie das menschliche Auge Bilder verarbeitet. Dadurch soll Guetzli dann auch gegenüber anderen Encodern die sichtbaren Vorteile erreichen.
Links Original, Mitte Libjpeg, Rechts Guetzli
Während Google mit der Hilfe von Guetzli primär im Auge hat die Größe von Bilddateien zu reduzieren, wäre natürlich je nach Anwendungsgebiet auch bei gleichbleibender Dateigröße bessere Bildqualität zu erreichen.
Links Original, Mitte Libjpeg, Rechts Guetzli
Im obigen Beispielbild wird z. B. Guetzli mit dem Encoder Libjpeg verglichen: Bei geringerer Dateigröße zeigt Guetzli im Vergleich dennoch weniger Kompressionsartefakte.
Wer Guetzli nutzen bzw. einbinden möchte, findet den offenen Quellcode komplett bei Github. Sicherlich interessant für all diejenigen, die viel aktiv mit Bildern arbeiten und sich nach geringeren Dateigrößen sehnen. Erwähnenswert ist allerdings, dass Guetzli aufgrund der verbesserten Quantisierung zum Encodieren von Bildern länger braucht als Libjpeg. Das überrascht natürlich nicht, denn irgendein Trade-Off war zu erwarten.
Wird geladen ...
Die große News an der News ist das es kompatibel mit allem ist ohne das man irgendwas machen muss. Das JPEG richtig schlecht ist weiß jeder der sich ein wenig in die Richtung beschäftigt, aber es wird eben zu 100% unterstützt. Die weit besseren Formate sind nie in großer Verbreitung angekommen – da kann man diesen Weg hier nur begrüßen. Im Endeffekt könnte man es schon heute großflächig ausrollen und jeder könnte es nehmen.
Bzw derzeit sind noch keinerlei CPU Optimierungen im Code, dementsprechend ist er richtig langsam. Da sich das ganze in einem frühen Stadium befindet ist das aber zu erwarten. Bei zstandard sah es am Anfang ja auch so aus und das ist mittlerweile richtig gut.
> Das JPEG richtig schlecht ist weiß jeder
Nach 22 Jahren Arbeit in der grafischen Branche ist mir merkwürdigerweise noch nie jemand begegnet, der JPEG „richtig schlecht“ fand. Im Gegenteil, haben wir Ende der 90er noch ausschliesslich TIFF verwendet, gibt es inzwischen selbst für anspruchsvolle Anwendungen nur noch JPEG (und PSD, klar). Ich weiss nicht, wann ich das letzte mal ein anderes Bildformat gesehen habe (Vektorformate natürlich außen vorgelassen)
Möglicherweise ist es für deine Zwecke nicht geeignet, weil Du z.B. Transparenz per Alphakanal brauchst, oder Strichzeichnung hast, oder so etwas — für Spezialprobleme wird eine Speziallösung immer überlegen sein, siehe animierte GIFs im Netz.
Aber ein JPEG eines Fotos mit 100% Qualität ist auch in Photoshop mit maximalem Zoom und Ebenenvergleich vom Original nicht zu unterscheiden, und wer für eine Spezialanwendung nichts riskieren will, kann lossless JPEGs encodieren.
Einfach mal folgendes in Photoshop machen: Das Original öffnen, als JPEG exportieren, diese Datei dann als zweite Ebene über das Original legen und den Ebenenmodus auf „Differenz“ stellen. Viel Spaß beim Suchen der Unterschiede. 😉
Bei genauem Hinsehen gibt Libjpeg die Details besser wieder. Aber den Unterschied kann man am Ende nicht erkennen. Guetzli hat weniger Artefakte auf der Fläche, sieht besser aus. Für den Privatanwender bringt das eher nichts. Ein paar MB mehr oder weniger auf der SSD/HD machen keinen Unterschied. Für Google hingegen, die Milliarden Fotos auf ihren Servern liegen haben, macht es schon einen Unterschied.
@Kalle: Ich finde schon, dass ein paar MB mehr oder weniger schon etwas ausmachen, gerade in Zeiten, in denen insbesondere große SSD doch noch recht teuer sind.
@Kalle Festplatte ist verhältnismäßig billig. Ich denke Google geht es eher um Bandbreite bei der Übertragung und insbesondere um die Schnelligkeit des kompletten Downloads. Das gesamte Chrome Projekt zielt ja auch zu einem großen Teil auf online user experience ab und gerade bei mobilen Verbindungen sind 30% weniger Traffic schon spürbar
@ratti
Du sagst es ja auch, du hast nur jpeg gesehen – weil nur jpeg 100% garantiert das es auch „überall“ funktioniert. Du/Ihr kompensiert die Probleme von JPEG mit Dateigröße – das will aber im Normalfall (Grafiken im Web) keiner (von anderen Features reden wir ja nicht erst).
https://xooyoozoo.github.io/yolo-octo-bugfixes/#zoo-bird-head&jpg=t&bpg=t
Nur mal ein Beispiel wie JPEG gegenüber aktuellen Techniken absinkt, das Problem an denen ist jedoch das es keinen großflächigen Support gibt. Das einzige positive an JPEG ist dessen Verbreitung – Technisch gesehen ist es aber heutzutage nutzlos weil es weit bessere alternativen gibt.
@Kalle
kommt drauf an, zu Hause würde ich es auch nicht machen (und wenn dann gleich nach BPG) – zuviel Aufwand, aber auf einer Webseite macht es schon einen riesen Unterschied ob die Datei 200kb oder 140kb ist bei „gleicher“ Qualität bzw gleicher Größe und gesteigerter Qualität
Ich wünsche mir weitere Verbreitung vom WebP Format. Warum muß an 1000 Jahre alten Code rumoptimiert werden? Was kommt als nächstes 24bit GIFs?
> Kalle 19. März 2017 um 13:27 Uhr
> Für den Privatanwender bringt das eher nichts. Ein paar MB mehr oder weniger auf der > SSD/HD machen keinen Unterschied.
Dann warte mal ab, wenn bald mal mobiles Surfen eingeführt wird…
@Namerp : Ich verstehe deinen Link nicht. Da ist ein Bild mit einer grauseligen Kompression.
Was auch immer der Autor uns damit sagen will, es handelt sich mit Sicherheit nicht um ein auch nur halbwegs normal abgespeichertes JPEG.
Mach doch bitte mal den Test, den ich oben empfohlen habe. Du wirst feststellen, dass ein normales JPEG von den Quelldaten nur um vollkommen irrelevante Nachkommastellen differiert. Der Unterschied ist vollkommen unsichtbar.
@Kasupke
lolwut
@ratti
Siehe Dateigrösse, 13,2 und 13,3 KB. Für eine ähnliche Qualität müsste man das JPEG mit weniger Kompression speichern. Das benötigt mehr Speicherplatz. Mit BPG könnte man so einiges an Bandbreite und Platz auf SSDs/HDs sparen. Wie gesagt, für Privatanwender oder gar im Druckbereich ist das egal. Aber Cloudanbieter könnten so Kosten sparen.
Das Format wird sich aber nicht durchsetzen. Im Grunde ist es nur ein Container für HEVC Stills (Standbilder) mit extra Metadaten für Exif und Farbprofil. Kann daher nur auf Geräten oder Software funktionieren für die eine HEVC (H.265) Lizenz gilt.
Viel wichtiger wäre mal wenn SVG komplett von den wihtigen Browserengines unterstützt wird.
@Kalle: danke für den Hinweis auf die Patentierungs-/Lizensierungs-Scheisse die mal wieder den Fortschritt behindert
@Kalle
ne BPG läuft überall und in jeder Engine (über irgendeinen kleinen JS decoder der nachgeladen werden kann) zusätzlich kann es per Hardware beschleunigt werden wenn das Gerät HEVC Beschleunigung unterstützt. An sich eine super Sache, aber Patente/Lizenzen stehen da einer verbreitung im Weg.
@ratti
Sry, ich hatte bei 22 Jahren in der Grafischen Branche Grundkenntnisse von Bildkompression vorausgesetzt.
Auf gut Deutsch:
ein 4mb Jpeg ist in gleicher Qualität in BPG nur 1,5mb groß
@ratti
„Nach 22 Jahren Arbeit in der grafischen Branche … gibt es inzwischen selbst für anspruchsvolle Anwendungen nur noch JPEG (und PSD, klar). Ich weiss nicht, wann ich das letzte mal ein anderes Bildformat gesehen habe…“
ehm, das aktuelle Raster-Format der Wahl ist natürlich das verlustlose PNG-Format inklu. Alpha-Transparenz
https://de.m.wikipedia.org/wiki/Portable_Network_Graphics
@ratti Ich! Ich finde JPG richtig schlecht. 🙂 – Das ist natürlich überspitzt, aber PNG ist mir dennoch 100mal lieber und mit Programmen wie ImageOptim kann man es auch immer gut noch ein bisschen in der Größe drücken ohne Bildinformation zu verlieren.
@ratti das ist ne vergleichsseite, da wo deine maus ist ist eine vertikale trennung zwischen 2 bildformaten in dem fall jpg und bpg und es ist offensitlich dass bei gleicher dateigröße die bpg weit besser aussieht (mMn)
@4nd sehe ich auch so ich bevorzuge immer noch PNG, es ist weit verbreitet, verlustlos und kann auch noch transparenz, also quasi das FLAC der bildformatel.
@caschy, der satz „Erwähnenswert ist allerdings, dass Guetzli aufgrund der verbesserten Quantisierung zum Encodieren von Bildern länger braucht als Libjpeg“ ist etwas schwammig weil es nicht nur länger dauert, sondern extrem länger. da kann man je nach bild mal ohne probleme 10 minuten pause machen, während der codiert.
@Namerp
Ich hab ja nicht geschrieben dass es nicht funktioniert sondern nur die Lizenz erwähnt. Das ist auch nichts schlimmes. Schliesslich kommt die wesentliche Funktion des Formats von HEVC.
@HAL9000
PNG benutzt niemand im grafischen Bereich. Ausnahme sind Webseiten (steht schon im Namen, Portable *Network* Graphics), und dort auch eher selten (Grund war lange Zeit Internet Explorer 6, Microsoft’s ultimativer Fail). Davon abgesehen ist PNG auch kein Ersatz für JPEGs sonder für GIFs. PNG eignen sich für Infografiken, Interface-Elemente, etc. Aber nicht für Fotos.
PNG kann kein CMYK und ist deswegen für Druck ungeeignet. Ein JPEG mit 1200 dpi ist Standard und man sieht am Ende keinen Unterschied mehr zu TIFF. Darum kann man auch seit einer Ewigkeit ein TIFF mit JPEG-Kompression speichern.
@Kalle
hier geht’s glaube ich nicht um prof. Anwender in der Druckvorstufe sondern um den typischen ‚Consumer‘ der sich sowieso nur im RGB-Farbraum bewegt. Selbstverständlich lassen sich auch Fotos problemlos im PNG-Format abspeichern, bei naturgemäss grösserer Dateigrösse. Was mich allerdings deutlich weniger stört als der Verlust an Qualität bei jedem Speichern im JPEG-Format… so ähnlich wie seinerzeit beim Kopieren von VHS-Kassetten.
TIFFs werden praktisch ausschliesslich mit der verlustlosen LZW-Kompression gespeichert, zumindest in dem von dir referenzierten „grafischen Bereich“.
Wer druckt denn heutzutage noch aus CMYK-Daten? Seit Anfang der 2000er Jahre hat sich AdobeRGB als am ehesten „medienneutrales“ Format durchgesetzt. Natürlich kommt aus der Maschine hinten CMYK raus, aber die Zeiten, in denen einer mit’m Proof an der Maschine stand und die Farbe „abgenommen“ hat, die sind nun wirklich lange vorbei.
Man profiliert seine Daten, und man profiliert seine Maschinen. Das mag bei Graf Cox’s Geburtstagseinladung auf mungeblasenem Büttenpapier noch anders sein, aber wer heute Druckerzeugnisse erstellt, benötigt eine verlässlich kalibrierte Farbsicherheit auf x Maschinen in aller Welt, und da bietet RGB nunmal den umfangreicheren Farbraum. Mit CMYK sind die Daten von Anfang an kaputt.
@HAL9000 Wo siehst Du denn PNGs? Ich sehe kaum welche, allenfalls mal für Web-Assets. Die Qualität von JPEG ist einfach viel zu gut, als dass man sich wegen einer Abweichung in den Nachkommestellen PNG ans Bein binden würde, das viel größere Dateien generiert.
Generell sind vollkommen verlustfrei Dateien eigentlich Exoten.