Articles avec le tag ‘png’

Pngrewrite sous linux

Lundi 7 septembre 2009

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.

Punypng, un smushit-like

Lundi 3 août 2009

Smushit a disparu, ou presque. On nous parlait d’ouvrir le code source. Il y avait une API pour faire des tests automatisés. Il était possible d’optimiser tout un site web. Le site a été repris sur un hébergement interne à Yahoo! et depuis il y a eu des indisponibilités et plus de régressions que d’améliorations. Le concept est toujours très intéressant mais finalement très limité.

J’ai annoncé il y a quelques temps que je comptais développer un outil similaire avec un code source ouvert et au moins une version en ligne de commande pour être intégré dans des mécanismes automatisés de publication (plutôt que d’attendre publication pour ensuite corriger image par image). Ca viendra, mais ça prend du temps parce que je veux faire les choses bien. Je compare donc tous les outils que j’ai pu voir pour comparer leurs résultats, avec différentes options. Il faut tenter de prendre un échantillon d’images représentatif, repérer les avantages et les défauts de chaque outil suivant le format mais aussi le type d’image (taille, transparence, nombre de couleurs, etc.) puis faire un choix en fonction du temps de traitement (prendre le plus efficace sur la taille finale n’est pas forcément la meilleure idée). Bref, ça viendra mais ce n’est pas pour demain.

Par contre vous avez désormais punypng. Je n’ai pas vu de code source, il n’y a pas de version en ligne de commande, ça n’accepte pas une URL de page HTML pour en extraire toutes les images (quoi qu’il doit être assez simple d’adapter l’ancienne extension smushit pour cela) mais ils innovent. Ils ont repris l’idée d’optimiser les images contenant des pixels avec une information RGB mais totalement transparents, ils font plus de travail sur les jpeg, et ils tentent d’avoir une interface plus efficace que smushit. C’est déjà ça et c’est bien.

Astuce EzPublish pour optimiser les images

Jeudi 23 juillet 2009

Je vous avais parlé de plugins pour wordpress et symfony en janvier, puis de nouveau en mars. Ces plugins ne sont généralement pas parfaits. Ils ajoutent un filtre PHP au téléchargement des ressources statiques, ou utilisent des conversions avec perte sur les images (si je soutiens l’idée de dégrader un peu les images, le faire automatiquement sans contrôle humain derrière est assez risqué).

Par contre j’apprécie beaucoup l’arrivée de ces plugins pour deux raisons. D’abord ils montrent une prise de conscience globale de la problématique des performance, et surtout ils posent les premières briques d’une démarche performance intégrée aux outils de publication. Si pour l’instant rien ne remplace l’expert et le consultant sur ces sujets, rien ne me ferait plus plaisir que de savoir qu’on puisse s’en passer à l’avenir. Il est finalement anormal que quelqu’un qui met juste en place un blog ou un CMS ne puisse pas avoir quelque chose de performant par défaut. (Lire la suite…)

Optimisation JPEG (encore)

Vendredi 19 juin 2009

je vous ai parlé plus d’une fois de recompression des images PNG. Mais … et les jpeg ?

Les jpeg ont aussi des métadonnées importantes et des informations inutiles dans un contexte web. Vous y trouverez plusieurs version de l’image à différentes résolutions pour gérer des miniatures, ou même des pistes audio. Stoyan Stefanov a trouvé un gain moyen de 12 % avec des transformations sans pertes sur l’image elle-même, loin d’être négligeable.

C’est Jpegtran dont j’avais parlé la dernière fois, l’outil utilisé par smushit. En plus de retirer les blocs de méta données (moins précisément que JHead), il permet de retoucher un peu la compression sans toucher à la qualité de l’image ni subir de pertes par rapport à l’image originale.

Jpegtran permet aussi de créer des images jpeg progressives, ce qui parfois est légèrement plus petit en taille (mais pas tout le temps, et en particulier pas pour les petites images).

Attention toutefois, cela retirera aussi les mentions de copyright éventuelles. Ne le faites que sur vos images ou prévoyez d’extraire d’abord cette information pour la réinjecter dans l’image finale ensuite.

JHead manipule lui aussi les entêtes et les métadonnées EXIF, IPTC et XMP. Je peux vous proposer les options -du -dc -de -di -dx. Jpegoptim propose aussi une optimisation sans perte et la possibilité de supprimer les entêtes EXIF et commentaires. Je n’ai pas de retour sur la performance de l’outil. Pour ceux que ça intéresse il y a une option pour diminuer la qualité de l’image (non activée par défaut).

Maintenant, comme on me le faisait remarquer il y a peu à propos des PNG, la meilleure compression s’obtient toujours en travaillant l’image avant de la fixer dans un format particulier. En particulier il est généralement appréciable de gérer la qualité par zones, pour avoir les détails là où c’est utile.

Pngcrush ou Optipng ?

Vendredi 12 juin 2009

Je reprend mon test précédent, plus de 7000 images PNG de taille diverses, beaucoup de 1 à 5 ko, d’autres jusqu’à 250 ko pour un total de 450 Mo. Faut-il utiliser pngcrush ou optipng pour recompresser ses images png ?

PNGcrush me donnait 403 Mo (10% de gain) pour 75 minutes avec les options par défaut, et 399 Mo (11% de gain) en le poussant à fond mais en prenant alors entre 8 et 9 heures.

Optipng, avec les options par défaut, arrive à 392 Mo (13% de gain, donc mieux que le maximum de pngcrush) pour deux heures et demie. C’est long, mais on gagne deux points. À noter tout de même que 10% des fichiers sont légèrement plus gros avec optipng qu’avec pngcrush, mais en moyenne quand optipng est plus gros c’est de moins de 1%, alors que quand il est plus petit c’est plus significatif (et il plus petit dans 90% des cas).

Si il est franchement inacceptable d’imaginer mettre huit heures pour quelques points, le compromis résultat/temps d’optipng peut avoir du sens. Si vous n’êtes pas trop pressés, c’est l’outil qu’il vous faut.

Malgré le mauvais retour des options « brutes»  avec pngcrush, j’ai tenté la même chose avec optipng (option -o7). On gagne au plus 2 Mo sur l’échantillon global, et le temps de calcul dépasse la journée. Autant dire que là aussi, sauf si vous avez une bonne raison, restez avec les options par défaut.