Et juste pour l’info, en faisant quelques tests j’ai remarqué que tu peux gagner 10% sur ton gravatar… 😉

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.

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)

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.

Merci de penser aux admin (même si c’est pas leurs boulot!)

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.

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.

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 🙂

Si tu as plus d’informations sur ce qui est fait, comment, avec quoi, je suis plus que preneur.

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 😉

Dans ce sans, on peut rapidement faire le tri et donc gagner pas mal de place.

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.

Share the love <3

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.

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.

@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.

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

Si tu veux un coup de main ou un testeur, contacte moi.