Je fais depuis quelques jours des tests avec différents outils d’optimisation pour images PNG en vue de réimplémenter un smushit-like libre en ligne de commande. Je vous avais déjà parlé de pngcrush, mais sans plus de détails. Ce billet est là pour répondre à la question « dois-je utiliser les options pour pousser l’outil à bout ou dois-je utiliser les options par défaut ?« .
Pour y répondre j’utilise un répertoire de 7000 fichiers de 250 ko maximum avec une moyenne à 60 ko. En réalité il y a pour plus de moitié de fichiers inférieurs à 10 ko (pour ceux que ça intéresse, l’écart type est de 50 ko). Je n’ai aucune prétention sur la représentativité de ces images téléchargées de façon automatisée sur le web, mais cela donne au moins un ordre d’idée.
Sur des fichiers sortis sous Photoshop, de mon expérience et au jugé j’aurai tendance à dire qu’un passage par les outils type pngcrush font gagner entre 10 et 30 % sur le poids des images. Sachant que les images représentent généralement plus d’un tiers du poids global des pages, c’est non négligeable.
Donc ces 7000 et quelques fichiers prennent 450 Mo sur disque. Passés par pngcrush on arrive à 403 Mo. Un passage par l’outil nous fait gagner 10 % en moyenne. C’est moins que ce que je pensais (mais mon échantillon n’est pas forcément représentatif) mais notable tout de même.
J’ai tenté plusieurs solutions dans les options, en finissant avec un outrageux « -l 9 -brute -cc -rem alla -reduce -rem time -rem iTXt -rem tEXt -rem zTXt » qui n’est pertinent pour rien d’autre que pour ce test. Je suis tombé à un poids global de 399 Mo. On gagne 1,5 points par rapport aux options par défaut, à peine 1 % à partir du test précédent. Par contre pour gagner ce 1 %, pngcrush a pris 7 fois plus de temps (520 minutes au lieu de 70). Autant dire que votre processeur pourrait trouver de meilleures occupations.
Résultat : pngcrush, oui, mais gardez les options par défaut.
Justement j’avais envie de faire un outil de la sorte pour automatiser l’optimisation des images lors du déploiement.
Si tu veux un coup de main ou un testeur, contacte moi.
Vu que de plus en plus de personnes optimisent leurs PNG, est ce que ton échantillon non représentatif récupéré sur le web n’était pas déjà optimisé ? Cela pourrais fausser grandement tes résultats…
Bonjour,
Je suppose que c’est l’option « -l 9 » qui fait perdre beaucoup de temps. Vous avez essayé de mesurer le gain sans cette option ?
Cordialement,
david
@Martin: cela peut jouer, mais de mon expérience la proportion de gens passant par ces outils est extrêmement faible. Cela concerne peut être les sites les plus importants sur le web mais vu la manière donc j’ai récupéré mes fichiers, je doute que ça influe vraiment sur les résultats. C’est tout de même un biais possible, oui.
@David: J’ai testé sans aucune option, et avec toute la chaîne, je n’ai pas mesuré les performances en temps des options intermédiaires, je tenterai peut être mais si j’en crois la documentation c’est surtout le « -brute » qui fait exploser le temps de calcul.
Voir aussi: http://blog.virgule.info/post/2009/05/14/Optimisez-vos-images!
Et pensez à pngnq: la réduction est incroyable.
J’ai testé: 496 Mo de PNG réduits à 186 Mo, avec pour la majorité une diminution de qualité tout à fait acceptable.
Ah oui j’oubliais:
http://www.commentcamarche.net/faq/sujet-3770-optimiser-la-taille-des-images-png
Pngnq est bien différent, justement parce que c’est une recompression avec pertes, alors que pngcrush ou optipng sont sans pertes.
Pour les recompressions avec perte, j’encourage plutot à jouer avec photoshop, trouver la qualité qui vous va, puis passer le résultat par optipng. Un outil automatique ne sera jamais capable de faire les choix de compromis qui *vous* reviennent. Ou alors il faut faire une revue manuelle en sortie de l’outil.
Il y’a un outil pratique qui est pre parametre et qui fait tres bien le boulot :http://www.css-ig.net/scriptpng
Il est long sur certains PNGs, mais l’option 3 est parfaite sur la plupart de mes images
J’utlise optipng et en général c’est suffisant
Pour les Mac users, on m’a fourni quelques liens fantastiques dans une discussion sur un site américain.
Share the love <3
« c’est une recompression avec pertes »
Certes, mais dans la majorité des cas il n’y pas *visuellement* de perte.
Le gain est tellement énorme par rapport à optipng/pngcrush que ça serait dommage de ne pas en profiter.
@sebsauvage: je ne suis pas contre, mais peut être pas assez confiance pour un faire un process automatisé sans contrôle manuel. Mais surtout, on a déjà un mal incroyable à convaincre les intégrateurs et graphiste d’optimiser les images sans pertes, alors s’il y a des pertes on va faire face à un mur.
@Éric:
Ah oui, l’outils nécessite un contrôle manuel, je suis tout à fait d’accord. Mais le processus de réduction des couleurs est automatique.
Le contrôle se limite à accepter/rejeter.
Dans ce sans, on peut rapidement faire le tri et donc gagner pas mal de place.
(Hors sujet : je ne découvre votre site que maintenant, mais félicitations !)
Concernant PNG, le potentiel du format est très souvent largement sous-exploité ; puisque vous cherchez la performance, vous devriez vous orienter vers l’optimisation du stockage, des filtres, de la méthode d’encodage (etc.), plus que la compression à proprement parler. La compression n’est réellement efficace que sur un PNG filtré et préparé. Exemple concret :
http://www.css-ig.net/degrade-non-filtre.png (63687 octets)
http://www.css-ig.net/degrade-filtre.png (751 octets)
A qualité de restitution plus ou moins identiques, les deux images étant compressées en utilisant les mêmes méthodes de compression, avec les mêmes outils, l’une est néanmoins 80 fois moins lourde que l’autre.
Bref, avant de compresser, il faut optimiser 😉
css-ig: quels outils ? quels résultats ? quelle perte de qualité éventuelle ?
Si tu as plus d’informations sur ce qui est fait, comment, avec quoi, je suis plus que preneur.
Cet exemple est très significatif (rapport qualité/poids) puisqu’on y retrouve bon nombre des notions d’optimisation en une seule et même image.
Contrairement à la logique primaire, qui voudrait que dans le cas de l’image « plus léger = moins de qualité », l’image qui occupe moins d’espace est dans cet exemple de bien meilleure qualité que l’image qui en occupe plus.
L’image légère contient toutes les couleurs originelles de l’image brute (soit 68850 couleurs), tandis que celle plus lourde ne contient que 56326 couleurs ; l’une est tout simplement beaucoup plus simple à compresser, car les données sont organisées de manière continue (rbg,n,n,n)+/-x/y. L’autre dispose de variables de couleurs plus ou moins ressemblantes, mais n’ont aucun rapport entre elles.
En vulgarisant, c’est comme compresser 1 000 000 de zéros continus, et compresser 100 zéros séparés par des caractères aléatoires. Il n’y a pas d’outils de compression/conversion capables d’obtenir ce résultat depuis une image déjà encodée et « lourde ». Une image mal encodée restera malheureusement mal encodée à vie.
Les résultats sont très significatifs sur des images bien préparées ; beaucoup de points doivent être pris en compte, et ce, par un humain. Si vous voulez plus d’informations, j’ai tenté de synthétiser certaines notions sur les quelques pages disponibles sur le site cité plus haut 🙂
J’ai du mal à voir en quoi une image déjà encodée serait impossible à réencoder correctement. Le format PNG étant sans perte, avec une palette RVB complète, sauf à travailler dans un espace de couleur plus important que le RVB classique, l’image brute est bien celle qui est dans le PNG.
Je comprend bien le principe de la compression utilisée par PNG, ma question c’est plus : quel algorithme utilises tu pour corriger tes dégradés et améliorer leur compression (parce que dans ton exemple c’est surtout ça) et quel logiciel met en oeuvre cet algorithme ? (parce que le scriptpng de ton site propose d’un côté une recompression sans perte, qui n’est pas ce dont tu parles, et de l’autre une conversion de la palette, ce qui est déjà facile à faire partout, sans compter que le code source n’est pas dispo et qu’il s’agit d’un exécutable ms windows, ce qui est bloquant pour pas mal de gens).
Sauf si tu parles du travail réalisé par le graphiste quand il s’agit de dégrader certaines parties de l’image et pas d’autres, mais là on sort complètement d’un système automatisable ou même d’un système utilisable pour l’intégrateur.
> J’ai du mal à voir en quoi une image déjà encodée serait impossible à réencoder correctement
Exemple se rapprochant du principe : prenez un CD audio, faites une extraction en MP3 32 kbits/s, et tentez d’améliorer la qualité audio du MP3.
Le principe s’applique au PNG : une fois que la matrice de l’image est modifiée -par une conversion, pas par le PNG lui même- (les valeurs des pixels les uns par rapport aux autres n’ont plus aucune logique entre eux), la perte est « définitive », dans le sens où la réorganisation est surréaliste en terme de temps/gain. Il faut alors repartir d’une source non altérée.
> quel algorithme utilises tu pour corriger tes dégradés et améliorer leur compression (parce que dans ton exemple c’est surtout ça)
Il n’y a ni correction, ni amélioration ; il est impossible de passer de l’image lourde à l’image moins lourde de cet exemple, que ce soit par logiciel, ou autre. Pour l’éventuel faux espoir, je n’ai jamais affirmé être passé de « ça à ça » en appliquant un quelconque algorithme, et ce n’est bien sûr pas le cas ici.
Il ne s’agit pas que de dégradés d’ailleurs, ça s’applique à n’importe quelle image :
A: http://www.css-ig.net/capture-proprietes-bad.png (76146 octets)
B: http://www.css-ig.net/capture-proprietes.png (3451 octets)
Les deux images ont été compressées avec la suite de compresseurs / filtreurs à un même niveau de compression, qui fonctionnent bien avec la plupart des images, et qui sont extrêmement efficaces (ce n’est pas le script lui même qui réalise la prouesse, mais les logiciels) sur des images qui ont été préparées pour (pixels continus, peu de couleurs). Il est totalement incapable d’automatiser une différence de poids telle que je vous l’ai présentée plus haut. Il n’effectue aucun calcul lui même, et aucun algorithme ne peut passer de A vers B.
> Sauf si tu parles du travail réalisé par le graphiste quand il s’agit de dégrader certaines parties de l’image et pas d’autres
Encore une fois, il ne s’agit pas de convertir un TrueColor en Paletted, ou d’atténuer le nombre de couleurs.
Il s’agit de bien choisir le format et les variables de couleurs pour atténuer le poids d’une image. Exemple, l’image en arrière plan du titre de votre site (bannière défaut wordpress, bleue et cadre). Bien que le poids ne soit pas excessif, le format est mauvais.
Cette image en « PNG préparé » pourrait occuper un espace poids bien moindre (facilité et suivi des couleurs). La convertir en PNG serait néanmoins une erreur (surpoids). L’image telle quelle est irrécupérable, il faudrait la recréer.
Pour finir là dessus, mon intervention ciblait simplement que la compression n’est pas le facteur décisif du poids et qu’il est inutile de tester toutes les méthodes de compression possibles. Le vrai gain n’est pas dans la compression, mais dans l’optimisation de création.
Il est vrai qu’il faut absolument un système automatique. Je recompresse toujours les nouvelles images que j’obtiens ( find -type f -iname ‘*.png’ -exec optipng {} ; )
Merci de penser aux admin (même si c’est pas leurs boulot!)
Ok, je vois ce que tu veux dire, que les éventuels motifs peuvent être codées avant d’être passés dans une image point à point, sur un mode de type vectoriel ou similaire.
Par contre, pour parler concret, si je devais faire l’image exemple, comment devrais-je m’y prendre, avec quel logiciel et quelle(s) méthode(s) pour m’assurer que le codage est fait comme il faut au bon moment ? (bref, la différence entre savoir qu’il faut le faire et savoir comment le faire)
J’avoue que ça dépasse ma sphère d’intervention (je prend les images réalisées et je fais ce que je peux avec une fois qu’elles sont déjà réalisées, charge à celui qui les fait de les faire le plus correctement possible au départ) mais je suis sûr que ça en intéressera parmi ceux qui lisent.
@css-ig: merci beaucoup pour ces informations. Je vais dévorer votre site, qui me semble, après quelques détours, fort bien rempli et mis en page. Encore merci de partager ces connaissances avec nous 🙂
Côté potentiel de compression, on aurait pu imaginer un format image qui stocke le texte dans un chunk tEXt -entête de l’image-, et qui le restitue en le positionnant dans l’image :
http://www.css-ig.net/c-test/c-plein.html (4369 octets)
http://www.css-ig.net/c-test/c-vide.html (865 octets)
C’est grossièrement illustré ici avec du HTML, mais cela pourrait améliorer l’exploitation texte d’une image (accessibilité, bot, etc.) et bien sûr le potentiel de compression de l’image. Dommage qu’aucun format n’exploite cette méthode.
Pour répondre à la question, une image type dégradée est un bon exemple de départ.
rgb(50,60,70);rgb(50,60,71);rgb(50,60,72) etc.
ou
rgb(50,60,70);rgb(51,61,71);rgb(52,62,72) etc.
ou
rgb(50,60,70);rgb(51,60,70);rgb(51,61,70);rgb(51,61,71) etc.
N’importe quel logiciel d’édition (graphique ou non) peut réaliser ça. Enregistrez dans un format brut (BMP, PNG). Donnez l’image au script, et vous obtiendrez un PNG TrueColor potable 🙂
Une image bien encodée en suivant ce principe devrait voir son poids se multiplier si elle est convertie en PNG Paletted (effet inverse de la pensée première). Exemple :
Un PNG TrueColor à définition élevée (PNG24)
http://www.css-ig.net/test05.png (3495 octets)
… convertit en PNG Paletted (PNG8)
http://www.css-ig.net/test05b.png (44 703 octets)
@css-ig: Flash ? Je plaisante… juste un peu. A peine.
Flash est finalement un format vectoriel et bitmap qui reconstruit des bitmaps. Et il est _relativement_ efficace.
SVG serait peut-être un bon concurrent, s’il était moins verbeux (à mort l’XML !). Et associé à la compression Wavelet d’images, cela donnerait de bien meilleurs résultats que nos jpg actuels.
D’ailleurs tiens je me souviens du format LuraDocument: Vous scannez un document, puis le système sépare ce qu’il reconnaît comme « texte » en bitmap 1 bit/pixel (encodé en TIFF CCITT groupe 4, comme les faxes), et le reste de l’image est encodé en tant qu’image en tons continus en wavelets.
Les résultats étaient assez impressionnants question compression.
Le tout est d’utiliser des compressions adaptées, ou d’être capable de reconstruire l’image.
Nos formats habituels utilisent des compressions fourre-tout, et ça ne peut clairement pas être optimale dans tous les cas.
Le format idéal n’existe pas…
Je pencherais quand même bien pour des formats vectoriels (quitte à ce qu’il stock un peu de bitmap aussi), parce qu’ils seront les seuls à permettre le passage aux écrans haute résolution (>200dpi) avec une qualité acceptable.
(ça me ferait mal de payer un super-écran à 200dpi pour afficher des pages web avec des images « toute pourries » en 75 dpi).
Un format vectoriel assez évolué permettrait de reconstuire des images complexes, certes au prix d’une consommation CPU plus importante, mais c’est ce que nous faisons tous: nous échangeons du temps CPU contre de la place.
Pour apporter de l’eau à ton moulin, je viens d’optimiser les images de l’intranet sur lequel je travaille actuellement, sur une cinquantaine d’images j’ai gagné 22% avec Smushit, pas sur non plus que ce soit représentatif, mais ce qui est sur, c’est que cela aura un impact sur la rapidité d’affichage.
J’ai d’ailleurs gagné 3% sur le thème de JQuery
Et juste pour l’info, en faisant quelques tests j’ai remarqué que tu peux gagner 10% sur ton gravatar… 😉