URL: https://linuxfr.org/news/etude-de-mozilla-comparant-les-taux-de-compression-de-differents-formats-d-images Title: Étude de Mozilla comparant les taux de compression de différents formats d'images Authors: Benoit Jacob Florent Zara, Benoît Sibaud et Xavier Teyssier Date: 2013年10月24日T16:18:58+02:00 License: CC By-SA Tags: Score: 31 _(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](https://bugzilla.mozilla.org/show_bug.cgi?id=600919) [pression](https://bugzilla.mozilla.org/show_bug.cgi?id=856375) sur Mozilla pour adopter le format d'images [WebP](http://en.wikipedia.org/wiki/WebP). ![Logo WebP](http://upload.wikimedia.org/wikipedia/commons/thumb/0/06/WebPLogo.svg/200px-WebPLogo.svg.png) Une [étude](https://developers.google.com/speed/webp/docs/webp_study) 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](http://en.wikipedia.org/wiki/Structural_similarity). 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](https://blog.mozilla.org/research/2013/10/17/studying-lossy-image-compression-efficiency/) sa propre [étude](http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/) 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._ ---- [Journal à l'origine de la dépêche](http://linuxfr.org/users/bjacob/journaux/etude-de-mozilla-comparant-les-taux-de-compression-de-differents-formats-d-images) [L'étude de Google sur WebP](https://developers.google.com/speed/webp/docs/webp_study) [L'étude de Mozilla sur des formats de compression d'image avec perte](http://people.mozilla.org/~josh/lossy_compressed_image_study_october_2013/) ---- 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). ![Qui veut la mort du JPEG ?](http://upload.wikimedia.org/wikipedia/commons/e/e0/JPEG_example_JPG_RIP_050.jpg)

AltStyle によって変換されたページ (->オリジナル) /