WebP (Web-Picture) ist ein Grafikformat für verlustbehaftete oder verlustfreie Bildkompression für statische oder animierte Bilder. Als weiterer Abkömmling des 2010 freigegebenen Video-Codecs VP8 ist es ein Schwesterprojekt des Videoformates WebM. Ursprünglich wurde WebP als Alternative zu JPEG beworben, weil die Qualität die gleiche ist, die Bilder aber weniger wiegen. Nach und nach entwickelte sich das Format weiter und erhielt Funktionen wie die Unterstützung von Transparenz, Animation und die Möglichkeit, Bilder ohne Qualitätsverlust zu komprimieren.
Im Durchschnitt verringert sich die Dateigrösse der Bilder um etwa 30 %, was es den Webmastern ermöglicht, mehr Bilder auf ihren Plattformen zu platzieren. WebP wird von den meisten bekannten Browsern unterstützt und ist somit eine Komplettlösung für die Arbeit mit Bildern im Web.
Die Verringerung der Grösse wirkt sich gleich auf vier Aspekte des Interneterlebnisses positiv aus:
- Websites mit komprimierten WebP-Bildern sind schneller. Die Verarbeitung kleiner Dateien nimmt weniger Zeit in Anspruch. Selbst wenn der Artikel etwa hundert Bilder enthält, erspart die Komprimierung lange Up- und Downloads.
- Durch das Hochladen kleiner Bilder kann man Festplattenspeicherplatz sparen.
- Die Benutzer verbrauchen weniger mobilen Datenverkehr, wenn sie Seiten von einem Telefon aus besuchen.
- Ein dedizierter Internetkanal zum Server wird weniger belastet, wenn die übertragenen Medieninhalte weniger gross sind.
Die Unterstützung für dieses Format durch Browser, Webanwendungen und Programme unter GNU/Linux ist gut. Sowohl die gängigen Browser, als auch die üblichen Bild-Editoren kommen mit WebP zurecht. Getestet habe ich es mit Firefox 111, gThumb 3.12, Thunar 4.18, Nautilus 43.2, LibreOffice 7.5 und Gimp 2.10.34. Lediglich bei den Werkzeugen für Bildschirmaufnahmen sieht es mau aus. GNOME Bildschirmfotos speichert Screenshots immer im PNG-Format ab. Diese Einstellung kann man nicht ändern. Der beliebte Screenshoter Flameshot bietet zwar verschiedene Zielformate beim Speichern an, WebP wird aber nicht unterstützt. Besser sieht es bei KDE Spectacle aus; das Werkzeug kann im WebP-Format speichern. Für GNOME Bildschirmfotos gibt es zwar ein Issue, das aber zwei Jahre alt ist.
ImageMagick hilft nur weiter, wenn man noch mit X unterwegs ist; unter Wayland funktioniert das Erstellen eines Bildschirmfotos mit ImageMagick nicht:
import -window root screenshot.webpFalls es bei einem bestimmten Anwendungsfall dennoch Probleme mit dem WebP-Format geben sollte, kann man die Datei in JPG oder PNG umwandeln. Dazu öffnet man die Datei in einer Anwendung, die WebP unterstützt, z. B. gThumb, und speichert sie in einem anderen Zielformat ab. Wer das lieber über die Kommandozeile erledigen möchte, ist mit ImageMagick gut bedient.
convert baum.webp baum.jpgDieser Befehl wandelt die WebP-Datei in das JPG-Format (oder ein beliebiges anderes Format) um. Damit steht auch der massenhaften Konvertierung nichts im Wege.
Mit den Tools grim (Screenshot), Slurp (Bildausschnitt), Swappy (Bearbeitung) und Imagemagick (Konvertierung) sollte es funktionieren.
Unter Archlinux:
pacman -S grim slurp swappy imagemagick
Befehl als Shortcut hinterlegen:
grim -g "$(slurp)" - | swappy -f - -o - | convert - test.webp
An „einfachem“ webp (
convert img.jpg img.webp) stört oder erfreut mich oft die verminderte Schärfe – je nachdem, ob ich feine Strukturen abbilden oder Moiré-Effekte vermindern mag.Das ist der schlechtest mögliche Tipp. Bestehende jpg sollten so bleiben. Jede Umwandlung bringt Qualitätseinbußen.
Hotshots mal ausprobieren - kann das webp format
WebP ist in manchen in Zukunft wichtigen Punkten schlechter als JPG. Encoder langsamer; Dimenionen bis 16383x16383 statt 65535x65535; schlechter bezüglich Generationenverlust; keine progressive Dekodierung.
Daher ist es irreführend, WebP hier als bessere Alternative darzustellen, insbesondere da es mit JPEG XL tatsächlich ein Format gibt, das sich viel eher als JPG-Alternative eignet, nicht nur da es es eine bessere Komprimierung als WebP bietet, sondern auch da es ohne Bitverluste in die originalen JPG zurückkonvertiert werden kann. Es braucht zudem nur eine JXL auf einem Webserver liegen, um ebenso eine JPG an alte Clients liefern zu können.
Tiefgehende Vergleiche zwischen Bildformaten gibt es beispielsweise bei Cloudinary, doch auch heise und golem haben Artikel zu dem Thema geschrieben und sprechen sich für das bessere Bildformat — JPEG XL — aus. Darüber hinaus existiert sehr wohl breite Unterstützung für JXL, nicht nur durch zahlreiche Software (Photoshop, IrfanView, ffmpeg, Krita, GIMP, Darktable, imagemagick sowie jeder popelige GTK- und Qt-Bildbetrachter sollte das Format bearbeiten oder zumindest darstellen können — einfach libjxl und kimageformats installieren) als auch durch Fürspruch (Leitende Leute bei Intel, VESA, Facebook, Adobe, flickr, shopify, uvm.). Von den großen IT-Unternehmen möchte eigentlich nur Google WebP pushen, dabei ist es irrational, dieses Format als Ersatz für JPEG zu propagieren, anstatt auf JXL zu setzen, das zudem keine Lizenzprobleme hat. Hab auch mit Leuten geschrieben, die WebP implementiert haben, da es verheißungsvoll gewesen ist und die nun eben festgestellt haben, dass es keine breite Adoption findet.
Zum Schluss: Ich verwende JXL seit zwei Jahren und bei Screenshots erziele ich mittlerweile eine Reduktion in der Dateigröße von in etwa 53% gegenüber den PNG-Dateien, die die von mir verwendete Screenshot-Software erstellt (die verwendet zlib-Level 5, da gdk-pixbuf das verwendet). Und da ist noch Luft nach oben. Die Referenzimplementierung zum Konvertieren von Dateien zu JXL — cjxl — beispielsweise ist eigentlich sogar noch ziemlich ineffizient (https://www.reddit.com/r/jpegxl/comments/11pf9kw/comment/jbxjkfw/), da es aktuell annimmt, dass alle Bilder eine Farbtiefe von 32 bit haben (in der Realität hat man deutlich weniger — meine PNG-Screenshots haben eine Farbtiefe von 8 bit). Das insbesondere geht nun eher zu Lasten der Geschwindigkeit (daher braucht cjxl mit den dafür im Schnitt am besten abschneidenden, nicht-experimentiellen Optionen, auch mal ne Minute, wenn man nicht parallelisiert, ältere Hardware verwendet und Screenshots mehrere Monitore umfassen. Doch praktisch hat das kaum Relevanz, wenn automatisiert und es ist eigentlich ziemlich gut, wenn man mal auf andere Bereiche schaut: lrzip braucht Stunden für allgemeine Kompression, mit schlechterer Kompressionsrate, von ein paar Gigabyte; Video-Konvertierung von Dateien > 1 GiB zu h.265 braucht Tage und zu h.266 braucht es aufgrund fehlender Hardware gar Wochen. Nun würde cjxl sicherlich bei solch großen Bildern auch einem Tag arbeiten, doch für den Nutzer ist eine Datei eine Datei und Bilder sind halt einfach idR kleiner).
WebP ist in manchen in Zukunft wichtigen Punkten schlechter als JPG. Encoder langsamer; Dimenionen bis 16383x16383 statt 65535x65535; schlechter bezüglich Generationenverlust; keine progressive Dekodierung.
Daher ist es irreführend, WebP hier als bessere Alternative darzustellen, insbesondere da es mit JPEG XL tatsächlich ein Format gibt, das sich viel eher als JPG-Alternative eignet, nicht nur da es es eine bessere Komprimierung als WebP bietet, sondern auch da es ohne Bitverluste in die originalen JPG zurückkonvertiert werden kann. Es braucht zudem nur eine JXL auf einem Webserver liegen, um ebenso eine JPG an alte Clients liefern zu können.
Tiefgehende Vergleiche zwischen Bildformaten gibt es beispielsweise bei Cloudinary, doch auch heise und golem haben Artikel zu dem Thema geschrieben und sprechen sich für das bessere Bildformat — JPEG XL — aus. Darüber hinaus existiert sehr wohl breite Unterstützung für JXL, nicht nur durch zahlreiche Software (Photoshop, IrfanView, ffmpeg, Krita, GIMP, Darktable, imagemagick sowie jeder popelige GTK- und Qt-Bildbetrachter sollte das Format bearbeiten oder zumindest darstellen können — einfach libjxl und kimageformats installieren), sonder auch durch Fürspruch (Leitende Leute bei Intel, VESA, Facebook, Adobe, flickr, shopify, uvm.). Von den großen IT-Unternehmen möchte eigentlich nur Google WebP pushen, dabei ist es irrational, dieses Format als Ersatz für JPEG zu propagieren, anstatt auf JXL zu setzen, das zudem keine Lizenzprobleme hat. Hab auch mit Leuten geschrieben, die WebP implementiert haben, da es verheißungsvoll gewesen ist und die nun eben festgestellt haben, dass es keine breite Adoption findet.
Zum Schluss: Ich verwende JXL seit zwei Jahren und bei Screenshots erziele ich mittlerweile eine Reduktion in der Dateigröße von in etwa 53% gegenüber den PNG-Dateien, die die von mir verwendete Screenshot-Software erstellt (die verwendet zlib-Level 5, da gdk-pixbuf das verwendet). Und da ist noch Luft nach oben. Die Referenzimplementierung zum Konvertieren von Dateien zu JXL — cjxl — beispielsweise ist eigentlich sogar noch ziemlich ineffizient (https://www.reddit.com/r/jpegxl/comments/11pf9kw/comment/jbxjkfw/), da es aktuell annimmt, dass alle Bilder eine Farbtiefe von 32 bit haben (in der Realität hat man deutlich weniger — meine PNG-Screenshots haben eine Farbtiefe von 8 bit). Das insbesondere geht nun eher zu Lasten der Geschwindigkeit (daher braucht cjxl mit den dafür im Schnitt am besten abschneidenden, nicht-experimentiellen Optionen, auch mal ne Minute, wenn man nicht parallelisiert, ältere Hardware verwendet und Screenshots mehrere Monitore umfassen. Doch praktisch hat das kaum Relevanz, wenn automatisiert und es ist eigentlich ziemlich gut, wenn man mal auf andere Bereiche schaut: lrzip braucht Stunden für allgemeine Kompression, mit schlechterer Kompressionsrate, von ein paar Gigabyte; Video-Konvertierung von Dateien > 1 GiB zu h.265 braucht Tage und zu h.266 braucht es aufgrund fehlender Hardware gar Wochen. Nun würde cjxl sicherlich bei solch großen Bildern auch einem Tag arbeiten, doch für den Nutzer ist eine Datei eine Datei und Bilder sind halt einfach idR kleiner).