Analyse der Vor- und Nachteile der WebP-Technik (2021)

 (eng.aurelienpierre.com)
2 Punkte von GN⁺ 2023-12-17 | 1 Kommentare | Auf WhatsApp teilen
  • Durch die WebP-Unterstützung in WordPress und den großen Browsern ist die Migration von Fotobibliotheken einfacher geworden, doch bei echten Fotos fallen Schäden wie Posterization und Ringing stärker auf als die Einsparung bei der Dateigröße
  • Google und mehrere WordPress-Plugins weisen darauf hin, dass WebP kleiner als JPEG sei und lossy 80 ausreiche; wandelt man bestehende JPEGs jedoch erneut in WebP um, kann sich verlustbehaftete Kompression aufsummieren
  • Bei Bildern, in denen weiche Gradienten wichtig sind, etwa Studio-Porträts und Film-Scans, liefert selbst WebP 95–96 Ergebnisse, die ähnlich groß oder größer sind als JPEG 85 mit Rauschen
  • Vergleiche von durchschnittlichem SSIM und durchschnittlicher Dateigröße garantieren Fotografen keine Absicherung gegen Worst Cases; auf Websites, auf denen sich die Qualität nicht pro Bild feinjustieren lässt, ist Verlässlichkeit wichtiger
  • Wenn Bildqualität wichtig ist, sind JPEG 85–90 beibehalten, Dithering oder feines Rauschen hinzufügen, Re-Encoding bestehender JPEGs nach WebP vermeiden sowie CDN, responsive Bilder und Lazy Loading nutzen die realistischeren Maßnahmen

Erwartungen an die Einführung von WebP und die realen Probleme

  • Seit WordPress Uploads mit dem MIME-Typ image/webp akzeptiert und die großen Browser seit September 2020 WebP anzeigen können, ist es einfacher geworden, Fotobibliotheken auf WebP umzustellen
  • WebP wirkt attraktiv, weil es Vergleiche gibt, nach denen es bei gleicher Qualität 15 % kleiner als JPEG ist, sowie Googles Angaben von 25–34 % geringerer Größe
  • Für WordPress gibt es viele Plugins, die bestehende Mediatheken in WebP umwandeln; viele davon arbeiten als SaaS-Lösung mit Konvertierung auf externen Servern
  • Einige Plugins und technische Dokumentationen empfehlen, dass eine WebP-Qualität über lossy 80 für die meisten Fotos unnötig sei, doch Logo-Beispiele repräsentieren die Probleme realer Fotoarbeit nicht ausreichend

Schäden beim erneuten Komprimieren bestehender JPEGs als WebP

  • Nach der Stapelkonvertierung von WordPress-Medien mit der Qualität lossy 80 erschienen im Hintergrund posterized Ringe
  • Das betroffene Bild war ein 6×7-cm-Mittelformat-Scan, aufgenommen auf Ilford Delta 400 mit einer Mamiya RB 67; das Original ging von einem 16-Bit-Scan aus
  • Die Silberhalogenid-Körnung von Delta 400 wirkt wie natürliches Dithering und hilft, Posterization in weichen Bereichen zu verhindern; nach der WebP-Konvertierung brach der Gradient jedoch stufenartig auf
  • Auch das ursprüngliche JPEG mit Qualität 85 war nicht völlig sauber, sah aber besser aus als die WebP-Version; entscheidend war, dass auf ein bereits verlustbehaftet komprimiertes JPEG noch einmal verlustbehaftete WebP-Kompression gelegt wurde
  • Google Page Speed Insights und mehrere Plugins empfehlen oder erleichtern solche Re-Encoding-Abläufe, doch die tatsächlichen Qualitätsverluste sind nicht unproblematisch

Vergleichstests mit echten Fotos

  • Selbst unter der Bedingung, RAW-Fotos direkt aus darktable zu encodieren und nur einmal zu komprimieren, zeigten sich die Schwächen von WebP
  • Das Testbild ist ein reales Studio-Headshot, bei dem sanft abfallendes Licht und Hintergrundgradienten wichtig sind
  • JPEG und WebP wurden jeweils mit Qualität 90 gespeichert und mit 8-Bit-Floyd-Steinberg-Dithering versehen. Das Ergebnis:
    • JPEG 85 und WebP 90 wurden beide als Fehlschlag bewertet
    • Bei WebP war der Kontrast der posterized Ringe höher, wodurch es schlechter aussah
    • WebP 90 liegt 10 Punkte über dem empfohlenen Wert lossy 80, dennoch blieb das Problem bestehen
    • JPEG 90 sah ordentlich aus, hatte aber eine größere Datei
  • Beim Speichern von WebP verlustfrei war die Qualität sauber, die Dateigröße jedoch unbefriedigend; JPEG 90 war bei etwa einem Drittel der Größe kaum zu unterscheiden, und JPEG 95 sah bei etwas mehr als der halben Größe ähnlich aus
  • Auch in einem Test mit hinzugefügtem Zufallsrauschen von -48 dB PSNR statt Floyd-Steinberg-Dithering blieb WebP anfälliger für Posterization
    • Die WebP-Qualität, die ähnlich weich wie JPEG 85 mit Rauschen wurde, lag zwischen 95 und 96
    • Unter diesen Bedingungen war WebP 39 % größer als JPEG 85 mit Rauschen und auch 30 % größer als JPEG 90 mit Floyd-Steinberg-Dithering
    • Im WebP-Ergebnis blieb weiterhin leichtes Ringing zurück

Die Lücke zwischen Durchschnittsmetriken und Fotoqualität

  • Bewertungen der Überlegenheit von WebP stützen sich stark auf den durchschnittlichen SSIM und die durchschnittliche Bitgröße von Bilddatensätzen
  • Durchschnittswerte garantieren nicht die Ausgabestabilität, die Fotografen für ein Web-Portfolio benötigen
    • Ein Fotoportfolio ist kein Bereich, in dem ein Kompressions-Backend beliebig scheitern darf
    • Die WebP-Qualität für jedes Bild fein abzustimmen ist zeitaufwendig; in WordPress gilt ein solcher Ansatz zudem als schwierig
  • SSIM ist ein auf Mittelwert, Varianz und Kovarianz basierender Bildähnlichkeitsindex, der reale Wahrnehmungsmetriken nicht ausreichend abbildet und umstritten ist
  • Bei Kompressionsschäden ist nicht nur die Größe numerischer Abweichungen wichtig, sondern auch die Art der Artefakte
    • Zufälliges Rauschen kann bis zu einem gewissen Grad akzeptabel sein
    • Gemusterte Flecken oder stufenförmige Gradienten zerstören ein Foto deutlich stärker

Szenen, in denen WebP besonders schwach ist

  • In der Fotoarbeit sind die schwierigsten Motive oft nicht solche mit scharfen Details, sondern mit weichen Gradienten
  • Wenn nahezu punktförmiges Licht auf eine Wand fällt und einen natürlichen Hintergrund erzeugt, muss der Hintergrund genügend Textur haben, ohne den Blick vom Motiv abzulenken
  • WebP-Kompressionsbeispiele zeigen häufig scharfe Szenen mit großer Schärfentiefe und vielen hochfrequenten Details; solche Szenen haben aber ein geringes Posterization-Risiko und legen die Schwächen des Algorithmus kaum offen
  • Mangelnde Schärfe ruiniert ein Foto nicht zwangsläufig, doch wenn eine weiche Vignettierung stufenartig aufbricht, ist das ein schwer akzeptabler Schaden

Formatdesign und Farbprobleme

  • WebP nutzt RGB oder RGBalpha und kann Schwarzweißbilder daher nicht als einkanalige Graustufenbilder speichern
  • Die im Test sichtbare Posterization wurde durch magenta- und grünfarbene Ringe verschlimmert und als Farbverschiebung durch Chroma-Subsampling interpretiert
  • Könnte ein reines Schwarzweißformat einkanalig gespeichert werden, ließen sich zusätzliche Chroma-Verschiebungen vermeiden
  • AVIF hat diesen Punkt gelöst, doch bis die Technik breit in der Praxis angekommen ist, werden nach Einschätzung des Autors mindestens zehn Jahre vergehen

Maßnahmen zum Schutz der Bildqualität

  • Für Websites, auf denen Bilder wichtig sind, insbesondere Portfolios bildender Künstler, erscheint es besser, JPEG-Qualität 90 oder mindestens 85 beizubehalten
  • Um weiche Gradienten zu schützen, wird empfohlen, Bildern stets Dithering oder sehr leichtes Rauschen hinzuzufügen
  • Bestehende JPEGs sollten besser nicht in WebP umgewandelt werden; Ausnahmen gelten nur, wenn Schäden auf dem Niveau der genannten Beispiele akzeptabel sind
  • Um Ladegeschwindigkeit und gefühlte Reaktionsfähigkeit zu verbessern, ist es sicherer, statt einer Formatkonvertierung CDN, responsive Bildgrößen und Lazy Loading für Bilder zu nutzen
  • SaaS-Ansätze mit Konvertierung auf externen Servern verursachen Kosten, legen die tatsächlichen Qualitätsfaktoren nicht offen und können in WordPress-Umgebungen, die etwa durch Security-Plugins gehärtet sind, HTTP-Verbindungsfehler verursachen
  • Besser ist es, ImageMagick oder GraphicsMagick direkt auf dem Server auszuführen; empfohlen wird ein Ansatz, der das Serverprogramm direkt nutzt statt einer PHP-Schnittstelle
  • Wenn Technikentwickler und Designer von Bildalgorithmen die Formatwahl allein auf Basis von Durchschnittsmetriken vorantreiben, kann das echten Künstlern Zeit- und Kostenverluste verursachen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-17
Meinungen auf Hacker News

  • Ich habe bei WebP dasselbe Problem gesehen und bin deshalb größtenteils wieder zu JPG/PNG zurückgekehrt: Fotos als jpg, UI-artige Bilder als png.
    Das eigentliche Problem scheint zu sein, dass viele Leute den Unterschied gar nicht bemerken, vermutlich weil Desktop-Monitore in den letzten 10 Jahren ein innovationsarmes Niemandsland waren. Die Hälfte hier schaut sich die Beispielbilder wahrscheinlich auf einem 1920x1080-LCD von etwa 2012 an, und das ist auch Teil des Problems.
    Seltsamerweise haben kleine Displays wie bei Smartphones und große Displays wie 4K-TVs im Verhältnis zur Betrachtungsdistanz eine hervorragende Pixeldichte erreicht, aber 20- bis 40-Zoll-Panels stecken auf dem Niveau der Mitte der 2000er fest.
    Außerdem wäre es wohl besser gewesen, wenn der Autor Beispielfotos mit hellem Hintergrund verwendet oder den Hintergrund des Artikels auf Schwarz geändert hätte. Schwarze Bilder auf weißem Hintergrund machen es den Augen schwer, sich anzupassen, wodurch die Probleme schwerer zu erkennen sind; auf dunklem Hintergrund sieht man die Unterschiede viel leichter.

    • Selbst auf zwei Displays aus den 2010er-Jahren sind Kompressionsartefakte gut sichtbar. Eines ist ein für damalige Verhältnisse ziemlich guter 30-Zoll-IPS-Monitor mit 2560x1600, das andere ein günstiger 27-Zoll-TN-Fernseher mit 1080p.
      Daher glaube ich nicht, dass die Displayqualität das Kernproblem ist. Es könnte auch an Treibern oder Nachbearbeitungsfiltern liegen, oder einfach daran, dass nicht jeder einen Blick für so etwas hat.
      Wenn man sich für Bildverarbeitung interessiert, entwickelt man aus Erfahrung ein Auge für solche Details. Der Autor hat offensichtlich mehr Erfahrung als ich, und vielleicht gehört es beruflich dazu, solche Feinheiten zu sehen. Wahrscheinlich könnte er die Probleme sogar auf einem miserablen Monitor erkennen und erklären, auf welche Weise genau dieser miserabel ist.
    • Selbst auf einem 27-Zoll-4K-Monitor ist es sehr schwer, einen Unterschied zu erkennen, und ich bin mir nicht einmal sicher, ob überhaupt einer sichtbar ist.
      Das Beispiel ist schlecht. Wenn man etwas zeigen will, sollte man den Screenshot vergrößern, um die Artefakte sichtbar zu machen.
    • Bei Apple haben sich Laptop- und Desktop-Monitore schon seit fast 10 Jahren recht gut entwickelt: hohe PPI, Helligkeit und Farbgenauigkeit sind dort fast zum Standard geworden. Sie sind allerdings teuer, und auf dem PC wird darauf meist kein Wert gelegt, deshalb ist das oft einer der ersten Punkte, die gestrichen werden.
    • Bei JPG stimme ich zu, aber wenn man statt PNG verlustfreies WebP verwendet, bleiben die Pixel doch gleich und nur die Datei wird etwa 30 % kleiner als das betreffende PNG, oder? Selbst im Vergleich zu bereits stark mit zopfli/optipng optimierten PNGs ist sie noch etwa 15 % kleiner.
      Bedeutet „lossless“ bei „lossless WebP“ beim Konvertieren von PNG zu WebP etwa nicht tatsächlich verlustfrei?
      Zur Referenz: Wenn man ein PNG in verlustfreies WebP umwandelt, dann wieder zu PNG zurückkonvertiert und dieses PNG erneut in WebP umwandelt, erhält man exakt dieselbe verlustfreie WebP-Datei. Ob man direkt vom PNG verlustfrei encodiert oder von demselben PNG, das zuvor mit einem PNG-Optimierer „gecrusht“ wurde, man erhält dasselbe WebP.
    • Ich nutze hier ein 27-Zoll-4K-IPS-Display, und um den vom Autor beschriebenen Unterschied zu sehen, müsste ich die Augen zusammenkneifen oder hineinzoomen.
      Es ist gut, dass es Leute gibt, denen das bestmögliche Ergebnis wirklich wichtig ist, aber die meisten werden es vermutlich weder bemerken noch sich darum kümmern.

  • Ich habe die ersten beiden Bilder jeweils in einem Tab geöffnet und schnell zwischen ihnen gewechselt, aber es gab überhaupt keinen Unterschied. Ich habe es auf zwei verschiedenen Monitoren in Chrome und Firefox ausprobiert, und auch die letzten Bilder des Mannes sahen gleich aus.
    Korrektur: Beim letzten Vergleich war WebP zweimal enthalten und der Link war falsch. Hier ist das jpg, aber ich sehe trotzdem keinen Unterschied.
    https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

    • Ich habe es auf einem Macbook 16 M2 Max mit dem Standard-Preset P3-1600 nits in Chrome 120.0.6099.109 geprüft, und bei allen WebP-Bildern gab es eine ziemlich starke Posterisierung, bei den JPEG-Beispielen dagegen nicht.
      Korrektur: Um die Wahrheit zu sehen, muss man tatsächlich klicken und das Bild in voller Größe ansehen. Die im Artikel eingebetteten Bilder hatten ziemlich starke Kompressionsartefakte, sogar das als verlustfrei bezeichnete.
      Daher sieht https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... als verlustfreies WebP in voller Größe gut aus, aber die eingebettete Version desselben Bildes https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... sieht schrecklich aus.
      Korrektur 2: Die Unterschiede zwischen den folgenden drei sind ziemlich deutlich.
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... lossy-noise.jpg (216 kB JPEG)
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (150 kB WebP)
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (301 kB WebP)
      Bei beiden WebP-Beispielen, sogar bei der 301-kB-Version, ist die Posterisierung deutlich sichtbar.
      Ich frage mich, ob mit dem verwendeten WebP-Encoder oder den Einstellungen etwas nicht stimmt.
      Korrektur 3: Monitor-Gamma und Farbprofil können die Sichtbarkeit von Gradations-Posterisierung beeinflussen.
    • Ein leicht erkennbarer Unterschied ist bei diesem Paar, dass der Hintergrund in webp posterisiert ist, in jpg aber nicht: https://en.wikipedia.org/wiki/Posterization
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
    • Es gibt einen klaren Unterschied. Er ist auf allen Monitoren sichtbar, vom Desktop über den Laptop bis zum Mobilgerät, besonders im oberen rechten Viertel.
      Wenn man sich allerdings nicht für Fotografie interessiert, stört es einen möglicherweise nicht genug, um es zu bemerken.
    • Mit 50 beginnt zwar meine Sehkraft nachzulassen, aber die Unterschiede in den Fotos sind absurd deutlich. Es ist fast unmöglich, nicht zu sehen, wie groß der Unterschied ist.
      Solche Unterschiede sind nicht klein. Leute, die den Unterschied nicht sehen oder ihn erst bei genauer Betrachtung erkennen, sollten wissen, dass er für viele Menschen sofort sichtbar ist.
    • Beim ersten Bild fand ich es persönlich sehr schwer, etwas zu erkennen, und anfangs musste ich ein wenig hineinzoomen. Links im Bild, ungefähr auf Höhe des Kopfes, ist die Blockbildung in der WebP-Version etwas stärker.
      Beim zweiten Bild habe ich die Versionen jpeg 90 [1] und webp 90 [2] geöffnet, und im Vergleich der beiden gibt es rechts am Hals ein deutliches Banding-Problem. Das dunklere Band, das ein wenig um das ganze Bild herumläuft, ist zwar etwas weniger sichtbar, aber wenn man weiß, worauf man achten muss, sieht man es immer noch.
      Vergleicht man jpeg 90 mit webp lossless, jpeg 100 oder jpeg 95, dann ist rechts am Hals auch ein sehr schwaches Banding in jpeg 90 zu erkennen. Ohne Hineinzoomen ist das aber sehr schwer zu sehen.
      [1] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
      [2] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

  • Meiner Meinung nach ist der schlimmste und am leichtesten erkennbare Nachteil von WebP das erzwungene 4:2:0-Chroma-Subsampling. Bei vielen Bildern mit hellen Farben sind Farb- und Helligkeitsverluste auch ohne geschultes Auge deutlich sichtbar.
    Im Vergleich [1] ist klar zu sehen, dass der Ballon oben rechts sein kräftiges Rot verloren hat, und im Vergleich [2] hat das hellblaue Neonkunstwerk in der Mitte an Helligkeit verloren.
    [1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
    [2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...

    • Ich will hier keine Debatte anheizen, aber bei beiden verlinkten Beispielen kann ich überhaupt keinen Unterschied erkennen. Es hätte geholfen, wenn die Seite wenigstens einen vertikalen Vergleichsbalken zum Ziehen hätte. Angesehen auf einem iPhone-14-Display.
    • Danke für die Links, ich kann es zwar mit meinen Augen erkennen, aber für den Einsatz auf Websites wirkt es für mich vernachlässigbar. Wie sieht es mit der Sättigung aus?
      Ich frage mich, warum dieser Befehl bei der Umwandlung von jpg > webp ein blasses Blau erzeugt, während andere Farben halbwegs in Ordnung aussehen.
      cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -o

  • Dieser Artikel behandelt nicht das größte Problem, das ich persönlich mit WebP habe. Außerhalb des Browsers ist die Unbequemlichkeit dieses Formats größer als die geringe Einsparung bei der Dateigröße.
    Es gibt bessere Formate. Formate wie HEIF, AVIF, aus Video-Codecs inspirierte Formate wie das, was mit H.266 möglich wäre, oder auch JPEG XL; WebP wirkt wie ein Kompromiss ohne genug Vorteile.

    • Da ist dieser Schmerz von Rechtsklick, Speichern unter, und dann ... ach nein, schon wieder WebP.
    • WebP basiert tatsächlich ebenfalls auf einem Video-Codec. Nur scheint sich VP8 bei Hardware-Encodern/Decodern kaum durchgesetzt zu haben.
    • Noch schlimmer als der Originalartikel ist die Realität, dass man es mit einem JPEG zu tun haben könnte, das in WEBP umgewandelt und dann wieder zurück in JPEG konvertiert wurde. Und danach hat vielleicht noch jemand dieses JPEG bearbeitet, und es wurde erneut in WEBP umgewandelt.
      Viele streiten darüber, ob man bei nahezu idealen WEBP-Bildern Banding sieht oder nicht, aber reale WEBP-Bilder sehen meistens schrecklich aus. Das fällt mir erst seit Kurzem wirklich auf.
      Natürlich kann man Bilder inzwischen mit generativem Upscaling wieder „aufräumen“, aber es ist ziemlich ironisch, so viel Strom dafür zu verbrauchen, nur weil jemand 45 KB sparen wollte.
      Das erinnert mich auch an die Zeit, als GIFs in JPEG umgewandelt wurden. Vor etwa 25 Jahren gab es viele saubere GIF-Screenshots, bei denen 256 Farben völlig ausreichten, und JPEG hat sie ruiniert.
      Google sagt Entwicklern, sie sollen WEBP verwenden, hat aber keinerlei Problem damit, Videowerbung in Petabyte-Größenordnungen auszuliefern, die ohnehin niemand sehen will.
    • Und jetzt reden wir auch noch über HEIF. Auf dem Desktop ist das innerhalb wie außerhalb des Browsers ein unbequemes Format.

  • Wenn es heißt: „Für das Auge eines Nicht-Fachmanns mag es okay aussehen, aber für einen Fotografen nicht“, dann braucht es wohl bessere Beispiele, die einem „Nicht-Fachmann“ zeigen, warum WebP schlecht ist, und die zugleich den Text und den Tonfall rechtfertigen.
    Vielleicht liegt es daran, dass ich es auf Android anschaue, aber für mich sehen alle Fotos qualitativ gleich aus.
    Und wenn man Fotos für das „Auge eines Profis“ erstellt, dann benutzt man doch einfach keine Technik, die für professionelle Ansprüche nicht geeignet ist? Oder man überlässt solche Entscheidungen eben nicht anderen?

    • Der Punkt des Autors ist, dass jemand, der solche Technik entwickelt, das Auge eines Profis haben sollte.
      Wenn man sich in diesem Thread die Kommentare ansieht, in denen Leute selbstsicher behaupten, der Autor rede Unsinn und es gebe keinen Unterschied, dann wirkt seine Frustration berechtigt. Es ist okay, in den ersten Bildern keinen Unterschied zu sehen, aber dann sollte man nicht selbstbewusst behaupten, es besser zu wissen als der Autor, oder Bild-Codecs entwerfen.
    • Ich schaue es mir auch auf Android an.
      Ich konnte es sehen, ohne in den Vollbildmodus zu wechseln. Man muss den Mann mit dem verzogenen Gesicht ansehen und auf den Rand des Hemds in der Nähe der Schulter achten.
      In dem Foto mit der schlechten Bildqualität gibt es um die Schulter herum eine Art Lichthof, fast wie Gegenlicht.
      In dem Foto mit der guten Qualität ist der Verlauf glatt. Es gibt um die Schulter keinen gegenlichtartigen Lichthof, es sieht einfach wie ein weicher Hintergrundverlauf aus.
      Nur um das klarzustellen: Ich bin kein Fotograf, sondern DevOps-Ingenieur. Das letzte Mal, dass ich JavaScript beruflich verwendet habe, ist mindestens 11 Jahre her.
      Es ist leicht genug zu erkennen.
    • Siehe die Diskussion hier [1]. Um den Unterschied zu erkennen, muss man es in Originalgröße ansehen.
      [1] https://news.ycombinator.com/item?id=38653224
    • Jeder, der schon einmal mit Codecs gearbeitet hat, weiß, dass man Codec-Vergleiche nicht anhand eines einzigen Bildes macht.
      Der ganze Grundansatz dieses Blogposts wirkt nicht so, als solle er als Vergleich zwischen Formaten auch nur eine grundlegende Prüfung bestehen, sondern eher, als wolle er mehr Beschwerden und Klicks erzeugen.

  • Als etwas Hintergrund: Aurelien Pierre ist als wichtiger Mitwirkender von Darktable bekannt. Darktable ist ein Open-Source-Tool für RAW-Entwicklung und Katalogisierung, also so etwas wie ein Open-Source-Adobe-Lightroom.
    Er ist dafür bekannt, starke Ansichten über den richtigen Weg zu haben, und manchmal sogar so schroff, dass er Darktable in sein eigenes Projekt Ansel geforkt hat. Dazu gab es früher auch eine HN-Diskussion: https://news.ycombinator.com/item?id=38390914

    • Ich sollte mir Ansel mal ansehen. Weiß jemand, ob es noch mit dem Darktable-Format kompatibel ist?

  • Wenn einem die Qualität von Archivbildern wichtig ist, sollte man ältere Bilder nicht erneut in ein neues Format komprimieren, sofern man das nicht vom unkomprimierten Original aus tun kann. Eine Neukodierung aus einer bereits verlustbehaftet komprimierten Quelle verschlechtert die Qualität. Speicher ist billig und wird immer billiger.
    Wirklich relevant ist, bei der Komprimierung neuer Fotos in ein neues Format sichere Einstellungen zu wählen.

    • Bei JPEG XL heißt es, dass sich bestehende JPEG-Dateien ohne Qualitätsverlust in um 20 % kleinere Dateien rekodieren lassen.
      In diesem Zusammenhang hat Google JPEG XL blockiert, indem es die Unterstützung in Chrome entfernte und auch eine Wiederherstellung ablehnte, mit der Begründung, es biete gegenüber bestehenden Formaten wie WebP keinen ausreichend „inkrementellen Nutzen“.
    • Stimmt, aber das ist nicht der Kernpunkt. Selbst wenn man von einer als PNG gespeicherten perfekten Verlaufsgrafik ausgeht, erzeugt WebP bei -q100 sichtbares Banding, während JPEG selbst bei -q90 visuell transparent ist.

  • Der Autor scheint sich auf den falschen Punkt konzentriert zu haben. Er fokussierte sich auf Formatunterschiede, obwohl es in Wirklichkeit um das Komprimierungsverfahren hätte gehen müssen. Je nach Bildbearbeitungsprogramm fällt das Komprimierungsergebnis selbst bei derselben Zahl, etwa „80“, unterschiedlich aus.
    Für einen wirklich aussagekräftigen Vergleich müsste man nicht nur Schwarzweiß-Studioporträts mit weichem Verlaufs-Hintergrund testen, sondern auch verschiedenste Bilder wie Vollfarb-Aufnahmen mit komplexem Hintergrund. Man müsste außerdem mehrere Programme einbeziehen, etwa imagemagik, graphicsMagick, sharp, photoshop und diverse Cloud-Dienste.
    Ein weiteres Problem ist der Anwendungsfall. Wenn ein professioneller Fotograf Fotos in voller Größe und höchster Qualität hochladen will, ist es womöglich besser, sie gar nicht zu komprimieren, damit das kreative beziehungsweise editorische Ergebnis vollständig erhalten bleibt. Das ist jedoch nicht der durchschnittliche Anwendungsfall einer Website, die Bilder in angemessener Größe und angemessener Qualität anzeigen möchte.
    In vielen Situationen lohnt sich ein deutlich kleineres Bild trotz stärkerer Komprimierung, und bei vielen Bildern werden Kompressionsartefakte weit weniger auffallen als bei professionellen Studiofotos in voller Auflösung mit großem Verlaufs-Hintergrund.

  • Ich persönlich kann keinen bedeutenden Unterschied erkennen, also habe ich offenbar eindeutig „Nicht-Profi-Augen“.

    • Das hängt stark vom Gerät ab. Auf dem Windows-Rechner im Büro ist etwas Banding zu sehen, auf dem Handy ist es schlimmer und auf dem MacBook furchtbar.
    • Wahrscheinlich hast du wie die meisten nur auf den Vordergrund geschaut. Selbst auf einem kleinen Android-12-Gerät ändern sich ohne Vollbildansicht die Farben des Hintergrunds um die Hemdkanten und an den Bildrändern von Bild zu Bild auffällig.
      Worüber sich der Autor beschwert, sind Artefakte im Bildhintergrund.
    • Meine Sehkraft ist nicht gut und ich bin darin nicht geschult, aber nachdem man mich auf die Fehler hingewiesen hatte und ich noch einmal hinsah, waren sie ziemlich deutlich.
    • Gut so. Sobald man das Banding-Problem einmal bemerkt hat, ist man mit dem Fluch geschlagen, es überall zu sehen.
    • Interessanterweise konnte ich den Unterschied schon vor dem Lesen klar erkennen. Das Gerät, das ich benutze, ist ein 9 Jahre altes MacBook Air mit 11 Zoll, also nicht schlecht, aber auch keine High-End-Hardware.
      Faszinierend, dass die Wahrnehmung von Mensch zu Mensch so unterschiedlich ist.

  • Die Verläufe in WebP wirken oft wie Standbilder aus einem Video. Chroma-Subsampling verringert die Dichte der verfügbaren Luminanz-Approximationen, und je stärker es angewendet wird, desto schlechter werden die Verläufe.
    Hoher Kontrast und hochfrequente Details sind davon nicht stark betroffen, aber Verläufe können massiv beschädigt werden.

    • Die Aussage „Chroma-Subsampling verringert die Dichte der Luminanz-Approximationen“ ist eher das Gegenteil der Realität.
      Chroma bedeutet Farbe, und Farb-Subsampling wird verwendet, damit dem wichtigeren Luminanzkanal keine Information entzogen wird.
    • Auch bei WebM/VP9 sieht man nicht selten ziemlich starkes Banding in dunklen Verläufen, daher ist diese Erklärung bis zu einem gewissen Grad plausibel.
    • WebP verwendet wie Video YCbCr mit begrenztem Bereich, JPEG dagegen YCbCr mit vollem Bereich. Deshalb sieht ein Graustufen-JPEG auf Monitoren, die den vollen RGB-Wertebereich nutzen, perfekt aus, während WebP bei der Darstellung von Graustufeninhalten leichtes Banding zeigen kann.