Analyse des avantages et des limites de la technologie WebP (2021)
(eng.aurelienpierre.com)- Avec la prise en charge de WebP par WordPress et les principaux navigateurs, la migration d’une photothèque est devenue plus simple, mais sur de vraies photos les défauts comme la postérisation et le ringing ressortent davantage que le gain de taille de fichier
- Google et plusieurs plugins WordPress indiquent que WebP est plus léger que JPEG et que
lossy 80suffit, mais reconvertir un JPEG existant en WebP peut cumuler la compression avec pertes - Sur des images où des dégradés doux sont essentiels, comme les portraits de studio ou les scans de film, WebP 95–96 produit des résultats comparables à JPEG 85+bruit, voire plus lourds
- La comparaison de la SSIM moyenne et de la taille moyenne des fichiers ne garantit pas la gestion des pires cas nécessaire aux photographes, et sur des sites où il est difficile d’ajuster la qualité image par image, la stabilité compte davantage
- Pour les sites où la qualité d’image est cruciale, il est plus réaliste de conserver JPEG 85–90, d’ajouter du dithering ou un bruit fin, d’éviter le réencodage WebP de JPEG existants, et d’utiliser un CDN, des images responsives et le chargement différé
Attentes autour de WebP et problèmes constatés en pratique
- Depuis que WordPress accepte l’upload du type MIME
image/webpet que les principaux navigateurs affichent WebP depuis septembre 2020, il est devenu plus facile de migrer une photothèque vers WebP - WebP semble être une option séduisante en raison de comparaisons affirmant qu’il est 15 % plus léger que JPEG à qualité égale, ainsi que des chiffres de Google annonçant 25 à 34 % de gain
- WordPress propose de nombreux plugins qui convertissent la médiathèque existante en WebP, et une grande partie fonctionne selon un modèle SaaS avec conversion sur des serveurs externes
- Certains plugins et documents techniques indiquent qu’une qualité WebP de
lossy 80ou plus est inutile pour la plupart des photos, mais les exemples de logos ne représentent pas suffisamment les problèmes rencontrés sur de vraies photographies
Dégradation lors de la recompression d’un JPEG existant en WebP
- Après une conversion en masse des médias WordPress avec une qualité
lossy 80, des anneaux de postérisation sont apparus dans l’arrière-plan - L’image concernée était un scan moyen format 6×7 cm réalisé avec un Mamiya RB 67 sur pellicule Ilford Delta 400, à partir d’un scan 16 bits
- Le grain argentique de Delta 400 agit comme un dithering naturel, ce qui aide à éviter la postérisation dans les zones douces, mais après conversion WebP les dégradés se cassent en marches d’escalier
- Le JPEG source en qualité 85 n’était pas parfaitement propre non plus, mais il restait meilleur que la version convertie en WebP, l’effet venant largement de l’empilement d’une nouvelle compression avec pertes sur un JPEG déjà compressé avec pertes
- Google Page Speed Insights et plusieurs plugins recommandent ou facilitent ce flux de réencodage, mais en pratique cette perte de qualité n’est pas sûre
Comparaisons expérimentales sur de vraies photos
- Même dans des conditions où la photo RAW est encodée directement depuis darktable avec une seule compression, les faiblesses de WebP apparaissent
- L’image de test est un vrai portrait studio, où l’éclairage en dégradé et le fond progressif sont des éléments importants
- En enregistrant JPEG et WebP tous deux avec une qualité 90 et en appliquant un dithering Floyd-Steinberg en 8 bits :
- JPEG 85 et WebP 90 sont tous deux jugés insuffisants
- WebP présente des anneaux de postérisation plus contrastés et paraît donc pire
- WebP 90 conserve le problème malgré une qualité 10 points au-dessus de la valeur recommandée
lossy 80 - JPEG 90 paraît acceptable, mais avec un fichier plus lourd
- En enregistrant WebP en sans perte, la qualité devient propre mais la taille de fichier n’est pas satisfaisante ; JPEG 90 fait environ un tiers de cette taille pour une différence difficile à percevoir, et JPEG 95 paraît similaire pour un peu plus de la moitié de cette taille
- Même dans un test où l’on ajoute un bruit aléatoire à -48 dB PSNR au lieu du dithering Floyd-Steinberg, WebP reste plus vulnérable à la postérisation
- La qualité WebP nécessaire pour obtenir une douceur comparable à JPEG 85+bruit se situe entre 95 et 96
- Dans ces conditions, WebP est 39 % plus lourd que JPEG 85+bruit, et même 30 % plus lourd que JPEG 90+ dithering Floyd-Steinberg
- Le résultat WebP conserve encore un léger ringing
L’écart entre les métriques moyennes et la qualité photographique
- L’évaluation favorable de WebP repose largement sur la SSIM moyenne et la taille moyenne des fichiers sur des jeux d’images
- Ces moyennes ne garantissent pas la stabilité du rendu exigée par les photographes dans un portfolio web
- Un portfolio photo n’est pas un domaine où le backend de compression peut échouer de façon aléatoire
- Ajuster finement la qualité WebP image par image prend beaucoup de temps, et dans WordPress cela semble difficile à mettre en place
- La SSIM est un indicateur de similarité d’image fondé sur la moyenne, la variance et la covariance ; elle reste controversée car elle ne reflète pas suffisamment les métriques perceptuelles réelles
- En matière d’artefacts de compression, ce n’est pas seulement l’ampleur de l’écart numérique qui compte, mais aussi la nature des artefacts
- Un bruit aléatoire peut être acceptable jusqu’à un certain point
- Des taches structurées ou des dégradés en escaliers dégradent bien plus la photo
Les scènes où WebP est particulièrement faible
- Dans le travail photographique, les scènes les plus délicates ne sont souvent pas celles avec des détails nets, mais celles avec des dégradés doux
- Quand une lumière proche d’une source ponctuelle éclaire un mur pour créer un fond naturel, ce fond doit garder suffisamment de texture sans détourner le regard du sujet
- Les exemples de compression WebP montrent souvent des scènes nettes, avec une grande profondeur de champ et beaucoup de détails haute fréquence, mais ces scènes révèlent mal les faiblesses de l’algorithme car elles sont moins sujettes à la postérisation
- Un manque de netteté ne ruine pas forcément une photo, mais voir un vignettage doux se casser en marches d’escalier est une dégradation difficile à accepter
Conception du format et problèmes de couleur
- WebP utilise un format RGB ou RGBalpha, ce qui empêche de stocker une image en noir et blanc comme une image en niveaux de gris mono-canal
- Dans les tests, la postérisation observée était aggravée par des anneaux magenta et verts, interprétés comme un décalage chromatique dû au sous-échantillonnage de chrominance
- Si un format noir et blanc pur pouvait stocker le contenu sur un seul canal, il pourrait éviter ces décalages chromatiques supplémentaires
- AVIF a résolu ce point, mais il faudra selon l’auteur au moins 10 ans avant que cela devienne réellement répandu dans la pratique
Mesures à prendre pour préserver la qualité d’image
- Pour un site où l’image est essentielle, en particulier le portfolio d’un artiste visuel, il semble préférable de conserver une qualité JPEG de 90, ou au minimum 85
- Pour protéger les dégradés doux, il est recommandé d’ajouter systématiquement du dithering ou un bruit très léger aux images
- Il vaut mieux éviter de convertir des JPEG existants en WebP, sauf si l’on accepte une dégradation du niveau montré dans les exemples précédents
- Pour améliorer la vitesse de chargement et la réactivité perçue, il est plus sûr de miser sur un CDN, des tailles d’image responsives et le chargement différé des images plutôt que sur un changement de format
- Le modèle SaaS avec conversion sur serveur externe a un coût, ne révèle pas toujours le coefficient de qualité réel, et peut provoquer des erreurs de connexion HTTP dans des environnements WordPress renforcés par des plugins de sécurité
- Il est préférable d’exécuter directement ImageMagick ou GraphicsMagick sur le serveur, et d’utiliser les programmes serveur eux-mêmes plutôt qu’une interface PHP
- Quand des développeurs ou concepteurs d’algorithmes d’image imposent un choix de format à partir de seules métriques moyennes, ils peuvent faire perdre du temps et de l’argent aux artistes en situation réelle
1 commentaires
Avis sur Hacker News
J’ai constaté le même problème avec WebP, donc je suis majoritairement revenu au JPG/PNG : jpg pour les photos, png pour les images de type UI.
Le vrai problème me semble être que beaucoup de gens ne perçoivent pas la différence, sans doute parce que, ces dix dernières années, les moniteurs de bureau sont restés dans un angle mort sans innovation. La moitié des gens ici regardent probablement les images d’exemple sur un LCD 1920x1080 sorti vers 2012, et cela fait aussi partie du problème.
Curieusement, les petits écrans comme ceux des téléphones et les grands écrans comme les TV 4K ont atteint une excellente densité de pixels par rapport à la distance de visionnage, mais les dalles de 20 à 40 pouces sont restées coincées au niveau du milieu des années 2000.
Je pense aussi que cela aurait été mieux si l’auteur avait utilisé des photos d’exemple sur fond clair, ou avait passé l’arrière-plan de l’article en noir. Une image noire sur fond blanc rend l’adaptation de l’œil difficile et complique la perception du problème ; sur un fond sombre, la différence se voit beaucoup plus facilement.
Il est donc difficile de dire que la qualité de l’écran est le problème central. Cela pourrait venir des pilotes ou de filtres de post-traitement, ou tout simplement du fait que tout le monde n’a pas l’œil pour ce genre de choses.
Quand on s’intéresse au traitement d’image, on finit par repérer ce genre de détails par expérience. L’auteur a manifestement plus d’expérience que moi, et repérer ces détails fait peut-être partie de son travail. Il est très probable qu’il repère les problèmes même sur un mauvais moniteur, et qu’il puisse aussi expliquer en quoi ce moniteur est mauvais.
Les exemples ne sont pas très bons. Si l’on veut montrer quelque chose, il faut agrandir les captures d’écran pour faire apparaître les artefacts.
Quand on remplace un PNG par du WebP, le « lossless » de “lossless WebP” ne serait-il pas réellement sans perte ?
À titre de référence, si l’on convertit un PNG en WebP sans perte, puis qu’on le décompresse à nouveau en PNG, et qu’on reconvertit ce PNG en WebP, on obtient exactement le même fichier WebP sans perte. Que l’on encode directement depuis le PNG, ou depuis le même PNG “crushé” par un optimiseur PNG, on obtient le même WebP.
C’est bien qu’il y ait des gens qui se soucient vraiment du meilleur résultat possible, mais je pense que la plupart ne le remarqueront pas et ne s’en soucieront pas.
J’ai ouvert les deux premières photos chacune dans un onglet et basculé rapidement entre elles : aucune différence. J’ai essayé sur deux moniteurs différents, avec Chrome et Firefox, et c’était pareil pour les dernières photos de l’homme.
Modification : la dernière comparaison contenait deux fois le WebP et le lien était erroné. Le jpg est ici, mais je ne vois toujours pas de différence
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
Modification : pour voir la vérité, il faut réellement cliquer et afficher l’image en taille réelle. Les images intégrées dans l’article avaient des artefacts de compression assez prononcés, même celles indiquées comme sans perte.
Du coup, le WebP sans perte en taille réelle https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... semble correct, mais la version intégrée de la même image, https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20..., est affreuse.
Modification 2 : la différence entre les trois ci-dessous est assez évidente
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... lossy-noise.jpg (JPEG 216 kB)
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (WebP 150 kB)
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (WebP 301 kB)
Dans les deux exemples WebP, même la version à 301 kB, la postérisation est clairement visible.
Je me demande s’il n’y a pas un problème avec l’encodeur WebP utilisé ou avec ses réglages.
Modification 3 : le gamma du moniteur et le profil couleur peuvent influer sur la visibilité de la postérisation dans les dégradés.
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
Cela dit, si vous ne vous intéressez pas à la photo, vous n’y prêterez peut-être pas assez attention pour la voir.
Ce genre de différence n’est pas mineur. Les personnes qui ne la voient pas, ou seulement en regardant de près, devraient savoir que pour beaucoup de gens elle saute immédiatement aux yeux.
Pour la deuxième image, j’ai ouvert les versions jpeg 90 [1] et webp 90 [2], et en les comparant il y a un problème de banding net à droite du cou. La bande plus sombre qui fait le tour de toute l’image est aussi un peu moins visible, mais on la voit encore si l’on sait où regarder.
Si l’on compare le jpeg 90 avec l’un des webp lossless, jpeg 100 ou jpeg 95, on voit aussi un très léger banding du jpeg 90 à droite du cou. Mais sans zoomer, c’est très difficile à repérer.
[1] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
[2] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
À mon avis, le pire défaut de WebP, et le plus facile à repérer, c’est le sous-échantillonnage de chrominance 4:2:0 imposé. Sur beaucoup d’images avec des couleurs vives, la perte de couleur et de luminosité est évidente même sans œil expert.
Dans la comparaison [1], on voit nettement que le ballon en haut à droite a perdu son rouge éclatant, et dans la comparaison [2], l’art néon bleu vif au centre a perdu en luminosité.
[1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
[2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
Je me demande pourquoi cette commande produit un bleu pâle lors d’une conversion jpg > webp, alors que les autres couleurs s’en sortent à peu près correctement.
cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -oCet article ne traite pas du problème que je ressens le plus avec WebP. En dehors du navigateur, les désagréments de ce format l’emportent sur le léger gain de taille.
Il existe de meilleurs formats. Des formats inspirés des codecs vidéo comme HEIF, AVIF, ce qui pourrait venir de H.266, ou encore JPEG XL ; WebP ressemble à un compromis sans avantage suffisant.
Beaucoup de gens débattent pour savoir si du banding est visible ou non sur des images WEBP proches des meilleures conditions possibles, mais dans la vraie vie les images WEBP ont généralement un aspect atroce. Je n’ai commencé à vraiment m’en rendre compte que récemment.
Bien sûr, on peut maintenant « nettoyer » les images avec un processus d’upscaling génératif, mais c’est assez ironique de consommer autant d’électricité parce que quelqu’un voulait économiser 45 Ko.
Ça me rappelle aussi l’époque où des GIF étaient convertis en JPEG. Il y a environ 25 ans, il y avait beaucoup de captures d’écran GIF propres pour lesquelles 256 couleurs suffisaient, et le JPEG les a massacrées.
Google dit aux développeurs d’utiliser WEBP, mais n’a aucun problème à servir des publicités vidéo que personne ne veut voir à l’échelle du pétaoctet.
Si l’argument est « ça peut paraître correct à un œil non expert, mais pas à un photographe », il faudrait de meilleurs exemples pour montrer aux « non-experts » pourquoi WebP est mauvais et justifier le texte et son ton.
Peut-être parce que je regarde sur Android, mais toutes les photos me semblent de qualité identique.
Et si l’on produit des photos destinées à un « œil expert », il suffit de ne pas utiliser une technologie qui ne convient pas à cet œil expert, non ? Ou alors de ne pas laisser ce genre de décision à d’autres ?
À voir dans ce fil les commentaires de personnes qui racontent n’importe quoi et affirment avec assurance qu’il n’y a aucune différence, sa frustration paraît justifiée. Ne pas voir la différence sur les premières images, ce n’est pas grave ; mais il ne faut pas pour autant affirmer avec assurance qu’on en sait plus que l’auteur, ni concevoir des codecs d’image.
J’ai pu le voir même sans passer en plein écran. Il faut regarder l’homme qui grimace, puis le bord de sa chemise près de l’épaule.
Sur la photo de mauvaise qualité, il y a une diffusion lumineuse autour de l’épaule, comme un contre-jour.
Sur la photo de bonne qualité, le dégradé est fluide. Il n’y a pas cette diffusion lumineuse de contre-jour autour de l’épaule, ça ressemble simplement à un arrière-plan en dégradé doux.
Pour être clair, je ne suis pas photographe, mais ingénieur DevOps. La dernière fois que j’ai utilisé JavaScript professionnellement remonte aussi à au moins 11 ans.
C’est assez facile à voir.
[1] https://news.ycombinator.com/item?id=38653224
Toute l’idée de base de ce billet de blog semble ne pas chercher à passer une validation élémentaire en tant que comparaison entre formats, mais plutôt à générer des plaintes et des clics.
Pour donner un peu de contexte, Aurelien Pierre est connu comme l’un des principaux contributeurs de Darktable. Darktable est un outil open source de développement/catalogage RAW, en gros un Adobe Lightroom open source.
Il est connu pour avoir des opinions fortes sur la bonne manière de faire, parfois au point d’être abrupt, et il a fini par forker Darktable dans son propre projet appelé Ansel. Il y avait déjà eu une discussion HN à ce sujet : https://news.ycombinator.com/item?id=38390914
Si vous vous souciez de la qualité des images d’archive, vous ne recompresserez pas d’anciennes images dans un nouveau format, sauf si vous pouvez repartir des originaux non compressés. Réencoder à partir d’une source déjà compressée avec perte dégrade la qualité. Le stockage est bon marché et continue de l’être de plus en plus
Ce qui compte, c’est de choisir des réglages sûrs quand on compresse de nouvelles photos dans un nouveau format
Dans ce contexte, Google a bloqué JPEG XL en retirant sa prise en charge de Chrome et en refusant de la rétablir, en affirmant qu’il n’apportait pas assez de « bénéfices incrémentaux » par rapport aux formats existants comme WebP
-q100, alors que JPEG est visuellement transparent même à-q90L’auteur semble s’être focalisé sur la mauvaise chose. Il s’est concentré sur les différences de format, alors qu’il aurait dû se concentrer sur les méthodes de compression. D’un logiciel de traitement d’image à l’autre, un même nombre, par exemple « 80 », ne donne pas le même résultat de compression
Pour faire une comparaison vraiment pertinente, il faudrait tester des images variées : pas seulement des portraits de studio en noir et blanc avec un fond en dégradé doux, mais aussi des images en couleur avec des arrière-plans complexes. Il faudrait aussi examiner plusieurs programmes et services, comme imagemagik, graphicsMagick, sharp, photoshop et divers services cloud
Un autre problème est le cas d’usage. Si un photographe professionnel veut publier une photo en pleine taille et en qualité maximale, il vaut peut-être mieux ne tout simplement pas la compresser, afin de préserver complètement le résultat de la création et de la retouche. Mais ce cas d’usage n’est pas celui, moyen, d’un site web qui affiche des images de taille raisonnable et de qualité raisonnable
Dans beaucoup de situations, des images beaucoup plus petites valent largement une compression plus forte, et sur beaucoup d’images la compression ne sera pas aussi visible que sur une photo de studio professionnelle en pleine résolution avec un grand arrière-plan en dégradé
Personnellement, je ne vois pas de différence significative ; mes yeux sont donc clairement des « yeux de non-spécialiste »
Ce dont se plaint l’auteur, ce sont les artefacts dans l’arrière-plan de l’image
C’est fascinant de voir à quel point la perception varie d’une personne à l’autre
Les dégradés de WebP ressemblent souvent à des images fixes tirées d’une vidéo. Le sous-échantillonnage de la chrominance réduit la densité des approximations de luminance disponibles, et plus il est appliqué fortement, plus les dégradés se dégradent
Les détails à fort contraste et à haute fréquence ne sont pas beaucoup affectés, mais les dégradés peuvent être sévèrement abîmés
La chrominance désigne la couleur, et le sous-échantillonnage de la couleur sert justement à ne pas retirer d’informations du canal de luminance, plus important