Jyrki Alakuijala, Ph.D., Google, Inc.
Vincent Rabaud, Ph.D., Google, Inc.
Dernière mise à jour: 01/08/2017
Résumé : nous comparons l'utilisation des ressources de l'encodeur/décodeur WebP à celle du format PNG en mode sans perte et avec pertes. Nous utilisons un corpus de 12 000 images PNG translucides choisies de manière aléatoire sur le Web, ainsi que des mesures plus simples pour montrer les variations de performances. Nous avons recompressé les fichiers PNG dans notre corpus pour comparer les images WebP aux fichiers PNG de taille optimisée. Nos résultats montrent que WebP est un bon remplacement du format PNG pour une utilisation sur le Web en termes de taille et de vitesse de traitement.
Introduction
WebP est compatible avec les images sans perte et translucides, ce qui en fait une alternative au format PNG. De nombreuses techniques fondamentales utilisées pour la compression PNG, telles que le codage par dictionnaire, le codage de Huffman et la transformation d'indexation des couleurs, sont également compatibles avec WebP, ce qui se traduit par une vitesse et une densité de compression similaires dans le pire des cas. En parallèle, un certain nombre de nouvelles caractéristiques, telles que des codes d'entropie distincts pour différents canaux de couleur, la localité en 2D des distances de référence arrière et un cache de couleurs des couleurs récemment utilisées, permettent d'améliorer la densité de compression pour la plupart des images.
Dans ce travail, nous comparons les performances de WebP à celles de fichiers PNG hautement compressés à l'aide de pngcrush et ZopfliPNG. Nous avons recompressé notre corpus d'images Web de référence en suivant les bonnes pratiques, et comparé la compression WebP avec et sans perte à ce corpus. En plus du corpus de référence, nous avons choisi deux images plus grandes, l'une photographique et l'autre graphique, pour une analyse comparative de la vitesse et de l'utilisation de la mémoire.
Il a été démontré que le décodage est plus rapide que le format PNG et qu'il offre une compression plus importante de 23 % par rapport au format PNG actuel. Nous concluons que WebP est un remplacement plus efficace du format d'image PNG actuel. De plus, la compression d'images avec pertes compatible avec la version alpha sans perte offre des possibilités supplémentaires pour accélérer les sites Web.
Méthodes
Outils de ligne de commande
Nous utilisons les outils de ligne de commande suivants pour mesurer les performances:
cwebp et dwebp. Ces outils, qui font partie de la bibliothèque libwebp (compilé à partir de l'en-tête),
effectuer des conversions. Cet outil de ligne de commande fait partie du logiciel ImageMagick (6.7.7-10 21/07/2017).
pngcrush 1.8.12 (30 juillet 2017)
ZopfliPNG (17 juillet 2017)
Nous utilisons les outils de ligne de commande avec leurs indicateurs de contrôle respectifs. Par exemple, si nous faisons référence à cwebp -q 1 -m 0, cela signifie que l'outil cwebp a été appelé avec les indicateurs -q 1 et -m 0.
Corpus d'images
Trois corpus ont été choisis:
Une seule image (Figure 1)
une seule image graphique translucide (Figure 2) ;
Un corpus Web: 12 000 images PNG choisies au hasard, avec ou sans transparence, explorées depuis Internet. Ces images PNG sont optimisées via convert, pngcrush, ZopfliPNG, et la plus petite version de chaque image est prise en compte pour l'étude.
Figure 1. Image photographique, 1 024 x 752 pixels. Respiration du feu "Jaipur Maharaja Brass Band" Chassepierre Belgique, Auteur: Luc Viatour, Photo sous licence Creative Commons Attribution - Partage dans les mêmes conditions 3.0 Unported. Cliquez ici pour accéder au site Web de l'auteur.
Figure 2 Image graphique, 1 024 x 752 pixels. Montages images issus des outils de graphique Google
Pour mesurer la capacité complète du format PNG existant, nous avons recompressé toutes ces images PNG d'origine à l'aide de plusieurs méthodes:
Pince à 8 bits par composant: conversion input.png -depth 8 output.png
ImageMagick(1) sans prédicteur: convertissent input.png -quality 90 output-candidate.png
ImageMagick avec des prédicteurs adaptatifs: convertissez input.png -quality 95 output-candidate.png
Pngcrush(2): pngcrush -brute -rem tEXt -rem tIME -rem iTXt -rem zTXt -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text input.png output-candidate.png
ZopfliPNG(3): zopflipng --lossy_transparent input.png output-candidate.png
ZopfliPNG avec tous les filtres: zopflipng --iterations=500 --filters=01234mepb --lossy_8bit --lossy_transparent input.png output-candidate.png
Résultats
Nous avons calculé la densité de compression pour chacune des images du corpus Web, par rapport à des tailles d'image PNG optimisées pour trois méthodes:
WebP sans perte (paramètres par défaut)
WebP sans perte avec la plus petite taille (-m 6 -q 100)
meilleur de WebP sans perte et avec perte de WebP avec la version alpha (paramètres par défaut).
Nous avons trié ces facteurs de compression et les avons représentés dans la figure 3.
Figure 3. La densité de compression au format PNG est utilisée comme référence, à 1,0. Les mêmes images sont compressées à l'aide de méthodes sans perte et avec pertes. Pour chaque image, le rapport entre la taille et le fichier PNG compressé est calculé, et les ratios de taille sont triés, et indiqués pour la compression avec et sans perte. Pour la courbe de compression avec pertes, la compression sans perte est choisie dans les cas où elle produit une image WebP plus petite.
WebP va au-delà de la densité de compression PNG pour les fichiers libpng en qualité maximale (convertir) et ZopfliPNG (Tableau 1), les vitesses d'encodage (Tableau 2) et de décodage (Tableau 3) étant à peu près comparables à celles de PNG.
Tableau 1. Nombre moyen de bits par pixel pour les trois corpus en utilisant les différentes méthodes de compression.
| Ensemble d'images | conversion -qualité 95 | ZopfliPNG | WebP sans perte -q 0 -m 1 | WebP sans perte (paramètres par défaut) | WebP sans perte -m 6 -q 100 | WebP avec pertes avec alpha |
|---|---|---|---|---|---|---|
| photo | 12.3 | 12.2 | 10.5 | 10.1 | 9.83 | 0.81 |
| explicite | 1.36 | 1,05 | 0.88 | 0.71 | 0.70 | 0,51 |
| Web | 6.85 | 5.05 | 4.42 | 4.04 | 3.96 | 1.92 |
Tableau 2 : Temps d'encodage moyen pour les corpus de compression et les différentes méthodes de compression.
| Ensemble d'images | conversion -qualité 95 | ZopfliPNG | WebP sans perte -q 0 -m 1 | WebP sans perte (paramètres par défaut) | WebP sans perte -m 6 -q 100 | WebP avec pertes avec alpha |
|---|---|---|---|---|---|---|
| photo | 0,500 s | 8,7 s | 0,293 s | 0,780 s | 8,440 s | 0,111 s |
| explicite | 0,179 s | 14 s | 0,065 s | 0,140 s | 3,510 s | 0,184 s |
| Web | 0,040 s | 1,55 s | 0,017 s | 0,072 s | 2,454 s | 0,020 s |
Tableau 3 : Temps de décodage moyen pour les trois corpors de fichiers image compressés avec différents paramètres et méthodes.
| Ensemble d'images | conversion -qualité 95 | ZopfliPNG | WebP sans perte -q 0 -m 1 | WebP sans perte (paramètres par défaut) | WebP sans perte -m 6 -q 100 | WebP avec pertes avec alpha |
|---|---|---|---|---|---|---|
| photo | 0,027 s | 0,026 s | 0,027 s | 0,026 s | 0,027 | 0,012 s |
| graphismes | 0,049 s | 0,015 s | 0,005 s | 0,005 s | 0.003 | 0,010 s |
| Web | 0,007 s | 0,005 s | 0,003 s | 0,003 s | 0.003 | 0,003 s |
Profilage de mémoire
Pour le profilage de la mémoire, nous avons enregistré la taille maximale de l'ensemble résident, comme indiqué par /usr/bin/time -v
Pour le corpus Web, la taille de l'image la plus grande définit à elle seule l'utilisation maximale de la mémoire. Pour mieux définir la mesure de la mémoire, nous utilisons une seule image (figure 1) pour donner un aperçu de l'utilisation de la mémoire. L'image graphique donne des résultats similaires.
Nous avons mesuré 10 à 19 Mio pour libpng et ZopfliPNG, et 25 Mio et 32 Mio pour l'encodage WebP sans perte aux paramètres -q 0 -m 1 et -q 95 (avec une valeur par défaut de -m).
Dans une expérience de décodage, la fonction de conversion de redimensionnement 1x1 utilise 10 Mio pour les fichiers PNG générés par libpng et ZopfliPNG. Avec cwebp, le décodage sans perte WebP utilise 7 Mio et 3 Mio.
Conclusions
Nous avons montré que les vitesses d'encodage et de décodage appartiennent au même domaine que celles du format PNG. L'utilisation de la mémoire augmente au cours de la phase d'encodage, mais la phase de décodage montre une diminution saine, du moins si l'on compare le comportement de cwebp à celui de la conversion d'ImageMagick.
La densité de compression est meilleure pour plus de 99% des images Web, ce qui suggère qu'il est relativement facile de passer du format PNG au format WebP.
Lorsque WebP est exécuté avec les paramètres par défaut, sa compression est améliorée de 42% par rapport à libpng et de 23% par rapport à ZopfliPNG. Cela suggère que WebP est prometteur pour accélérer les sites Web comportant beaucoup d'images.
Références
Associations externes
Les études suivantes ne sont pas sponsorisées par Google, et Google ne garantit pas l'exactitude de tous leurs contenus.