Je fais encore le tour des outils de compression d’image pour faire la comparaison et trouver le bon compromis entre ressources consommées et efficacité. Un de mes problème c’est punypng qui annonce des performances exceptionnelles mais qui ne détaille pas son fonctionnement et ne propose même pas d’API. Je vérifierai leurs affirmations et tenterai de m’en approcher mais en attendant je fouille.
Un des outils que je regarde c’est pngrewrite. La rumeur voudrait qu’il ne gagne pas grand chose mais qu’il est capable de le faire même après un passage par optipng ou pngcrush. Bref, un petit ajout rapide, juste pour grappiller un peu plus.
Je vais vérifier tout ça là aussi, mais en attendant le code proposé sur le site officiel ne compile pas sur mon linux récent. Pour ceux qui ont le même problème, la distribution gentoo a un patch disponible. Il suffit de le télécharger là où vous aurez décompacté le code source de pngrewrite et de lancer patch -p0 < pngrewrite-1.3.0-gcc44.patch puis de taper l’habituel make.
Voilà, maintenant vous savez.
J’aurai bien fait des paquets Ubuntu pour pngrewrite et pngout mais je ne trouve pas la licence du premier et le second interdit explicitement de reditribuer l’exécutable résultat. Si j’ai le courage je tenterai peut être des paquets « tricheur » qui téléchargent sur Internet lors de leur installation mais ça perd un des intérêts.
pngrewrite réécrit un PNG si celui-ci est encodé en TrueColor / GrayScale pour le « convertir sans pertes » en Paletted. Il tronque la palette au nombre de couleurs compté, et modifie la profondeur en conséquence. Il réorganise la palette afin de placer les alpha aux premières entrées, et peut convertir un TrueColor+alpha en Paletted avec « opacités variables ».
Ces fonctionnalités « anciennes » n’ont qu’un intérêt limité ; PNGOUT par exemple inclut ces techniques depuis quelques temps déjà. De plus, le compresseur utilisé est moins puissant.
Peut être que ce document qui parle d’optimisation des images Web vous sera utile : http://www.css-ig.net/optimiser-images-web.pdf
Merci pour ton document, il est très complet.
—
Je suis potentiellement d’accord avec toi sur le fond, en fait je n’en sais rien, je prend la chose par l’autre bout. J’ai des sources discordantes, chacune avec des arguments, et pas le temps d’aller regarder les codes sources pour comprendre ce que ça fait. Le C, les algos de traitement d’image ou de compression ne sont pas mon domaine à la base.
Du coup je fais l’inverse : je teste le résultat. S’il s’avère que passer par pngrewrite n’a aucune utilité par rapport à pngout, alors ça se verra sur les chiffres. Pour l’instant c’est trop tôt. Le principe même c’est de tout tester, au cas où j’ai une surprise. En attendant un optipng est un choix assez sûr.
Une fois que j’aurai des stats sur les outils, et éventuellement une chaine d’outil qui obtient les meilleurs rapports gain/temps je regarderai en détail ce que ces outils font et pourquoi éventuellement ceux dont on me parle tout le temps ne sont pas aussi intéressants.
Il y a aussi AdvanceCOMP qui peut recompresser (entre autre) les PNG. Peut-être en as-tu déjà parlé ici (j’ai fait une recherche mais WordPress plantoie).
http://en.wikipedia.org/wiki/AdvanceCOMP
Bonsoir,
Il faut surtout faire la différence entre les compresseurs et les logiciels qui tentent des conversions plus ou moins sans pertes. pngcrush avec les options telles que vous les utilisez dans vos tests ne fait office que de compresseur ; il compresse, point. pngrewrite lui optimise le PNG avant de le compresser. Il peut tronquer une palette, réorganiser les alpha, etc. Il peut donc y’avoir un gain, non pas sur la compression, mais sur l’organisation d’origine du PNG (organisation qui se compresse généralement mieux d’ailleurs).
Exemple, je donne une image de 16 couleurs à pngcrush. L’image est mal encodée en 24 bits/pixels. Il ne tentera aucune recherche : il va compresser, et mal, puisque l’encodage est mauvais. pngrewrite lui va réécrire le PNG selon le contenu : 16 couleurs, 4 bits/pixels, et recompresser le tout. Le gain est donc net dans certains cas.
A ce titre, certains utilitaires annoncent des résultats sans pertes. Exemple, la conversion d’un Truecolor+alpha (PNG32) en Paletted tRNS (PNG8). Le résultat peut être jugé sans pertes, car la restitution graphique est identique au pixel près, mais le support navigateur peut être différent.
Un autre exemple plus rare est la conversion d’un Paletted tRNS (compatible IE4 et supérieur) qui peut être convertit en GrayScale tRNS. Résultat graphique, identique. On gagne en poids, mais on perd en support, ce dernier étant pris en charge que depuis IE7.
Bon je vais être un peu hors-sujet (je vais essayer de pas trop déborder quand même ;-)).
J’ai récemment voulu optimiser une image sur un site, à la base en JPEG, la première chose que j’ai faite : la convertir en PNG. Surprise : le poids du fichier a littéralement doublé (même après optimisation).
Donc ma question est simple : quel format utiliser pour le web finalement ? La profusion d’outil d’optimisation PNG m’a fait pensé (à tort ?) qu’il s’agissait du format le plus pertinent pour les web.
Dans le cas d’un PNG, ne vaut-il alors mieux pas le convertir en JPEG d’abord ?
@css-ig:
Je prend en compte la différence de support navigateur, mais le reste ne m’intéresse pas forcément.
Ou plutot ça m’intéresse mais ce qui est le but final c’est uniquement le fichier final. Si certains font des opérations différentes, tant mieux, ça ne m’empêchera pas de comparer le résultat final au niveau de la taille et du support navigateur. Et s’ils font des travaux différents, alors ça vaudra peut être le cout de les faire travailler l’un après l’autre, ce que je vérifierai aussi.
Connaitre le fonctionnement est intéressant pour ma curiosité et pour ne pas faire n’importe quoi, mais mon but est bien d’avoir une vision naive et de bêtement m’intéresser au résultat final avec différentes combinaisons.
Sinon pour la taille de la palette, je la change de toutes façons quand elle n’est pas adaptée. Vu que je cherche à tirer des statistiques détaillées, toutes les images passent par image magick avant, et si le nombre couleurs utilisées n’est pas en adéquation avec la taille de la palette, c’est détecté et corrigé via pngcrush (qui sait réadapter la palette si on lui demande) ou image magick avant l’exécution (suivant les outils que je teste)
@thierry : Toujours utiliser une format adapté à ce que tu manipules. C’est seulement une fois que tu as le bon format que tu peux éventuellement parler d’optimisation.
– C’est une photo, une image avec beaucoup de couleurs en nuances : jpeg
– C’est un dessin, un logo, peu de couleurs ou dégradés très clean, des arrêtes ou des détails qui ne doivent pas être dégagés, tu peux utiliser png
– c’est juste quelques figures géométriques : clairement c’est du svg
Cette répartition est faite en trois lignes, c’est un peu plus complexe que ça, mais le plus simple et d’aller te renseigner sur les trois formats, leurs avantages et défauts. Les seules images qui sont « entre deux » sont éventuellement les captures d’écran, suivant ce qu’elles contiennent.
Bonjour Éric,
Petite question : il y a beaucoup d’utilitaires pour optimiser les PNG…
Quant aux JPEG ? Peut-on les optimiser sans dénaturer l’image ?
Cordialement,
Sébastien
PunyPng ne dévoile rien effectivement, niveau rapidité de calcul il est impossible de se faire un idée sans connaitre les serveurs qui tournent derrière. La seule vérification c’est le gain, enfin le rapport entre les images en entrées et les images en sorties. En utilisant la plupart des outils cités ici et leurs options , j’obtiens à 99% le même résultat que PunyPng. Donc rien d’inconnu, tu le savais déjà certainement PunyPng assemble habilement des softs déjà connus, rien de plus. http://fr.twitter.com/martinsam/status/6676776978
@Sébastien, tu as jpegtran pour les jpeg, mais le résultat est bien plus limité.