(Avertissement habituel: Mozilla est mon employeur. Cependant je n'exprime que mes opinions personnelles et je ne travaille pas dans le domaine des formats d'images.)
Ce n'est pas un mystère: il existe une forte pression sur Mozilla pour adopter le format d'images WebP.
Une étude publiée par Google affirme que ce format produit, à qualité égale, des images 30% plus petites que JPEG.
La difficulté se trouve dans la définition du mot «qualité». Il existe un certain nombre de métriques concurrentes pour définir la qualité, qui conduisent à des conclusions très différentes. L'étude publiée par Google utilise une métrique appelée SSIM. Il existe plusieurs variantes de SSIM, et celle utilisée par Google consiste à appliquer SSIM aux canaux rouge, vert, bleu (RGB) de l'image pris séparément, puis à prendre la moyenne des trois résultats obtenus.
Mozilla vient de publier sa propre étude sur ce sujet. Cette étude reprend la variante de SSIM utilisée dans l'étude de Google (cette variante est nommée RGB-SSIM dans l'étude de Mozilla) et y adjoint trois autres métriques qui sont bien établies puisqu'elles ont fait l'objet de publications dans des journaux scientifiques à comité de lecture. Ce sont donc quatre métriques différentes qui sont utilisées dans l'étude de Mozilla, et les résultats sont très différents d'une métrique à l'autre.
NdM : merci à Benoit Jacob pour son journal.
Dans le cas de la métrique RGB-SSIM que Google avait utilisée, l'étude de Mozilla confirme les résultats de Google sur la supériorité de WebP sur JPEG. Mais les trois autres métriques donnent des résultats différents. Si l'on accorde une importance égale aux quatre métriques utilisées, alors WebP et JPEG sont à égalité. Il semble en tout cas impossible d'affirmer que l'un est supérieur à l'autre en taux de compression, sauf à accorder une très grande importance à une métrique au détriment de toutes les autres.
Alors est-ce que WebP donne des fichiers plus petits que JPEG à qualité égale? Tout dépend de ce qu'on entend par qualité, donc.
Bien entendu, WebP a d'autres avantages sur JPEG. En particulier, WebP offre le support d'un canal alpha, peut aussi servir de format sans perte (comme PNG) et peut contenir une image animée (comme GIF). Ce dernier point cependant est assez controversé : Mozilla considère généralement que les formats d'images animées sont devenus inutiles étant donné que les formats de vidéo sont capables de faire exactement la même chose (on peut faire du «GIF animé» avec WebM!), et il n'existe pas de façon raisonnable de supporter WebP pour les images fixes sans supporter aussi les animations (il n'y aurait pas de moyen raisonnable de détecter le support des WebP animés).
Aller plus loin
- Journal à l'origine de la dépêche (225 clics)
- L'étude de Google sur WebP (171 clics)
- L'étude de Mozilla sur des formats de compression d'image avec perte (670 clics)
# site de comparaison ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Si mozilla veut aller plus loin, il faut monter un site qui présente 2 image parmi l'original et les 2 types de compression, et faire des statistiques sur les utilisateurs.
"La première sécurité est la liberté"
[^] # Re: site de comparaison ?
Posté par Stéphane Péchard (site web personnel) . Évalué à 5.
Comme je l'ai déjà dit dans le fil de discussion sur le sujet [1], ce n'est pas forcément si simple, en tout cas pour avoir des résultats exploitables. Pour que les notes de deux utilisateurs soient comparables, il faut qu'ils soient dans les mêmes conditions d'expérimentation, notamment en termes d'affichage et d'éclairage ambiant. Sans parler du fait que les utilisateurs sont normalement testés pour écarter les cas de daltonisme et d'acuité faible (les bons vieux tests avec des lettres à lire au fond de la salle :-) ). C'est pour ça que ce genre de test se fait dans des salles dédiées, normalisées et que ça prend du temps et de l'argent.
Alors maintenant, oui, on peut s'affranchir de ces contraintes et faire un test via une interface web bien foutue (c'est pas à Mozilla qu'on va apprendre ça), mais rien ne garantira que les écarts de notes, semble-t-il minimes, entre les différents systèmes de codage provienne des différences de codage ou de la méthodologie.
Ceci dit, des sessions de tests subjectifs bien faits me semblent plus pertinentes que d'utiliser des métriques type SSIM. Elles ont certes l'avantage d'avoir du code disponible, d'être rapides à mettre en place et d'être relativement simples à comprendre, mais aucune d'elles n'est suffisament précise (corrélation de l'ordre de 0.91) pour déclarer un vainqueur clair dans ce type de comparaison. Il existe d'autres métriques plus proches du système visuel humain, mais c'est pas la même complexité…
[1] https://groups.google.com/forum/#!topic/mozilla.dev.platform/9NKc7OeEFLM
[^] # Re: site de comparaison ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est l'avantage de faire des statiques sur des comparaisons A/B/x, plein de biais peuvent être filtré.
"La première sécurité est la liberté"
[^] # Re: site de comparaison ?
Posté par Stéphane Péchard (site web personnel) . Évalué à 1.
Sauf que si je ne trompe pas (je ne suis pas un spécialiste des comparaisons A/B/x), un biais ne peut être filtré que si il est constant sur l'ensemble des échantillons, non ? Ce qui ne serait pas le cas ici.
[^] # Re: site de comparaison ?
Posté par rogo . Évalué à 2.
Pour ce genre de test, pourquoi faudrait-il éliminer du panel les utilisateurs "déficients" ?
Si l'objectif est de mesurer la qualité ressentie des encodages auprès d'un échantillon représentatif de la population, alors les daltoniens ont leur mot à dire. Peut-être que leurs avis minorerait les différences, mais ce n'est pas certain. Et même si c'était le cas, il serait utile de savoir pour quelle proportion d'un échantillon la différence de qualité ressentie est perceptible.
Ceci dit, je suis d'accord sur le constat, il sera difficile d'avoir des conditions expérimentales assez robustes pour ne pas fragiliser des écarts probablement faibles.
[^] # Re: site de comparaison ?
Posté par Stéphane Péchard (site web personnel) . Évalué à 3.
Ben justement, on ne cherche pas à avoir un échantillon représentatif de la population. On cherche à savoir, le plus précisément possible, quel est l'impact sur le système visuel humain, de tel ou tel système dégradant. Or le SVH en question n'est pas une "moyenne" ou une "représentation" de tous les SVH existants mais plutôt un modèle, une espèce de concept médico-psychologique représentant le cas nominal, parce que les déviances sont souvent trop importantes et auraient un impact trop important dans une moyenne. Oui, il y a des cas déviants, mais les codeurs ne peuvent pas en tenir compte dans leur manière de fonctionner, donc ça n'aurait pas de sens de les prendre en compte dans des tests subjectifs qui leur seraient dédiés.
# Fonctionnalités décisives
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
Pour moi, le taux de compression n'est qu'un simple avantage concurrentiel de WebP pour des usages déjà pris en charge par JPEG et PNG, alors qu'il surtout l'énorme avantage de venir combler un manque pour lequel il n'a aucun concurrent : la compression avec pertes avec canal alpha. Et de façon intelligente, avec notamment la possibilité d'avoir une compression avec pertes pour les couleurs, et sans perte pour l'alpha, qui est généralement caractérisé par de grands aplats de transparence ou d'opacité totale.
Cas d'usage : photos détourées et dessins sans aplats. Exemples : photos à réutiliser pour des montages, hackergotchis. Aujourd'hui on stocke tout ça en PNG, qui est lamentable pour compresser ce genre de chose, puisque pas fait pour, et on ne peut pas envisager d'utiliser JPEG, qui n'a pas d'alpha.
[^] # Re: Fonctionnalités décisives
Posté par Jean Roc Morreale . Évalué à 3.
Je me répète par rapport au journal d'origine : la compression avec perte et canal alpha est présente dans le jpeg2000
[^] # Re: Fonctionnalités décisives
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Qui est pourri de brevet donc inutilisable.
[^] # Re: Fonctionnalités décisives
Posté par Jean Roc Morreale . Évalué à 6.
Document datant de 2002 sur le sujet :
http://www.jpeg.org/newsrel1.html
Si le fait que quelqu'un puisse avoir des brevets sous-marins prêt à attaquer le format jp2k te préoccupe, tu lui préférais le WebP qui a également connu exactement le même type d'accusation banano-juridique ?
[^] # Re: Fonctionnalités décisives
Posté par Troy McClure (site web personnel) . Évalué à 2.
Et concernant la qualité, ça depend sans doute pas mal du type d'image considéré, mais quand j'ai fait des comparaisons webp / jpeg pour compresser des images bitmap contenant pas mal de textes et de détails assez fins, webp était largement supérieur à jpeg dans le sens où il avait beaucoup moins tendance à faire ces artefacts moches (les espèces de petites ondulations) autour des détails
[^] # Re: Fonctionnalités décisives
Posté par deasy . Évalué à 0.
J'ai laissé un commentaire plus bas à propos de l'apparence visuelle des images avec webp.
Et ton commentaire me fera ajouter ceci : si il lisse les fonds uniforme, comme je le pense, il a plus d'octets a dédié au reste donc ça doit être un test où webp est supérieur au jpeg mais ce n'est pas généralisé, sur une photo il perdra plus de détails par endroit qu'une image jpeg.
Pour moi visuellement webp = jpeg + filtrage ===> perte de certains détails.
# Autres formats
Posté par rogo . Évalué à 4.
En plus de JPEG et WebP, l'étude compare deux autres formats.
L'un est clairement défait par la concurrence dans tous les cas, c'est JPEG XR, un format développé par Microsoft, adoubé par le comité JPEG en 2007 et devenu norme ISO en 2009.
L'autre est HEVC-MSP qui est vainqueur, souvent largement, dans tous les cas. Je n'en avais jamais entendu parler. C'est la partie "image fixe" (Motion Still Picture) du codec HEVC prévu pour succéder à h264. Existe-t-il un conteneur pour cet algorithme, avec canal alpha ? J'ai rapidement cherché sans trouver la réponse, ni d'exemple d'intégration dans une application. Pas eu non plus le courage de défricher le bazar de l'article WP sur HEVC pour savoir quelle était la licence.
[^] # Déjà Vu
Posté par Arthur Accroc . Évalué à 3.
Un autre format, qui n’a pas été pris en compte, c’est le DjVu.
Même s’il est destiné en priorité aux documents scannés, d’après son site, il serait très supérieur au JPEG, même pour les photos.
Par contre, d’après le Wikipédia anglais, même s’il y a une implémentation open source, il y a des brevets dessus.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# Bis repetita placent
Posté par Alex_Parker . Évalué à -2. Dernière modification le 26 octobre 2013 à 16:04.
Ce qui m'agace le plus encore une fois, c'est que de nos jours, il suffit que quelqu'un d'un peu influent réinvente la roue et comme par hasard, toute les solutions qui étaient jusqu'à présent parfaitement adaptées et suffisantes sont tout à coups dénigrées et dévalorisées et le pire c'est que beaucoup trop de gens/d'organisations qui ont un minimum d'influence tentent par tout les moyens de l'imposer comme un standard de facto, on le voit notamment avec c++, avec python, avec html5 et toutes ses extensions propriétaires et ses drm, avec wayland, avec qt, avec net framework, avec c#, avec tout les runtimes microsoft qui viennent s'intercaler comme autant de potentielles attaques mitm alors que jusqu'à présent un éxecutable était autonome, mais aussi bien d'autre encore et là maintenant comme par hasard webp poussé par gogole qui s'est métamorphosé d'un moteur de recherche efficace et adapté aux besoins des utilisateurs en un vulgaire site de pub puritain, inutilisable et insipide .
Pourtant, avec toute cette propagande pour le réchauffement climatique, l'écologie et le recyclage on peut légitimement s'étonner qu'on continue mordicus dans ce genre de fuite en avant.
Mais bon, on en est plus à une contradiction près hein!?!
[^] # Re: Bis repetita placent
Posté par xcomcmdr . Évalué à 5.
What is this, I don't even ??
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Erreur
Posté par yvand . Évalué à 2.
En lisant j'ai vu une erreur : "L'étude publiée publiée par Google …" (mot en double) que je me permet de signaler.
[^] # Re: Erreur
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# webp vs jpeg
Posté par deasy . Évalué à 1. Dernière modification le 30 octobre 2013 à 22:49.
Alors pour avoir pas mal passé de temps à faire du filtrage et de la compression j'ai jeté un oeil à webp il y a pas mal de temps quand on en avait parlé ici ou ailleurs…
Je ne suis pas dev je n'ai pas fouiné dans le code mais webp semble appliquer un filtrage de bruit avant compression :
Ce que je veux dire c'est qu'on obtient le même genre de résultat via un filtre de bruit et du jpeg.
Le webp lissant pas mal les détails via…ce qui me semble être un filtre de bruit.
Tout ceci n'est qu'un jugé à l'oeil des sorties de webp.
Après peut-être que quelqu'un pourra confirmer ça ou bien expliqué ce que webp utilise pour perdre des détails comme il le fait/lisser.
à tester : compression de dégradé…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.