PNG Taille optimisée - Page 1

placer plein de petites images en une seule comme ça:


de manière à ce que:

1) l'aire de l'image finale soit la plus petite possible (relativement facile, P non linéaire)
2) le contour de l'image finale soit la plus petite possible (facile, PL linéaire)

MAIS

3) la taille (en octet) de l'image finale au format PNG soit la plus petite possible... c'est ce que je me demande.

En gros je voudrais savoir s'il y a des cas connus où un png prend moins de place? Ca dépend fortement de l'image mais y a t-il des caractéristiques des images au meilleur taux de compression?

Autre possibilité: énumérer toutes les solutions possibles et générer le PNG final et regarder sa taille. Dans ce cas, j'aimerais pouvoir faire un Branch & Bound. Donc meme genre de question: à une étape d'énumération peut-on borner la taille de l'image finale sachant qu'on a placé n petites images parmi les N?... etc.

y a tant de variation que ça ?

Non pas trop.
A cause de:

PNG uses a non-patented lossless data compression method known as DEFLATE, which is the same algorithm used in the zlib compression library.

On le voit bien:
Fichier joint : (5,41KB)

et:

Fichier joint : (7,15KB)

et tu veux faire tout ca pour quoi ?

permettre de réduire encore plus la taille des images ?

(et faut pas toujours chercher des raisons )

Ben tu pourrais peut être réduire le nombre de couleurs de la palette jusqu'à un seuil acceptable comme cette version en 128 couleurs:

a mon avis découper en morceaux est pas intéressant car tu te taperas les headers du fichier PNG qui sont de taille incompressible. ou alors j'ai pas compris ce que tu veux

Ben il veut plutôt recoller que découper justement
Mais bon j'avoue que pour le coup de la taille je vois pas vraiment de moyen d'optimiser, à moins de regarder comment fonctionne l'algorithme utilisé (je veux dire, ça utilise deflate mais ça doit pas être aussi simple derrière, ceci dit j'ai jamais regardé donc j'en sais rien) et de trouver l'organisation des pixels qui donnera le plus de redondance "positive" ^^

je connais pas la spec png par coeur mais ça m'étonnerait pas qu'il deflate le framebuffer directement. Donc a mon avis c'est une histoire d'aire.

C'est bien beau de faire une seule image qu'on place comme on veux apres, mais c'est generalement mal supporté par certain navigateurs

Ensuite

onur (./1) :
En gros je voudrais savoir s'il y a des cas connus où un png prend moins de place?

Oui plus il y a d'aplat de couleurs, meilleurs est la compression...

Mais bon

Oui je veux recoller parce que:

* faire une requete HTTP pour 1 gros truc plutot que 5 requetes pour de petites choses c'est bien mieux
* c'est pas "mal" supporté par les navigateurs (sauf safari je crois qu'il y a un souci quand on met des background position trop "négatives")

La preuve, Google le fait, et tout le monde s'y met maintenant.
Le but est d'optimiser sans perdre d'info donc pas de "réduction de palette".

C'est quoi les aplat de couleur?

D'après ./3 il faut réduire l'aire de l'espace blanche, donc l'aire totale... Donc ca revient une optimisation non-linéaire.

aplat = grande zone de même couleur

en gros tu veux faire quoi? mettre toutes tes images dans la même et trifouiller du CSS pour en afficher une partie?

oui. Ca s'appelle le "css sprite". Y a meme des outils qui font ca maintenant, mais ils font plutot le gros truc bien étalé qu'essayer de tout remettre dans une image de plus petite aire possible

(en plus c'est completement stupide de faire ce genre de choses, c'est casse gueule sur des navigateur pas trop recent (ou mobiles), ça reduit pas tant que ça la BP demandé, ca empeche les navigateur de faire du // fetch (et oui vu que c'est plus qu'une seule image on a que 2 fichier a telecharger plutot que X qu'on peut recuperer en meme temps) etc... enfin bref, je n'ai jamais trouvé cette option très intéressante..

idem pour ma part.

bon, apres, utiliser les CSS pour que les images restent en cache, je suis pour. (du style utiliser une div avec un background plutot qu'une balise img, quand on doit l'afficher pleins de fois dans la page)

mais en voulant trop optimiser, ca nuit plus qu'autre chose, surtout pour la reprise du site, si on doit faire une modification sur une image ou autre

Tout a fait pour le bg plutot qu'un <img> (quoique si tu as plusieurs <img> pointant sur la même URL le navigateur si il est pas trop con doit utiliser le cache...

(et utilise le bg des CSS à d'autres avantages par contre ^^ (repeat, resize & co))

Je post ce topic dans "algorithmique" et pas dans "css/html", c'est pas pour discuter de l'utilité.

en plus c'est completement stupide de faire ce genre de choses

bah écoute tous les grands sites font cette chose "stupide" maintenant. Le résultat est visible avec un site amateur (encore faut-il avoir plus de 5 lignes de HTML)

surtout pour la reprise du site, si on doit faire une modification sur une image ou autre

C'est pour ca qu'on fait plutot des outils qui font ca automatiquement plutot que de se taper ça à la main.

Anyway, je suis meme pas là pour vous convaincre que c'est bien ou pas, vous avez qu'à essayer de vous meme.

J'espère que tu es au courant que la taille d'un PNG dépend aussi énormément du compresseur ? Parce que ça sert à rien d'essayer de gagner 100 octets avec le placement si c'est pour prendre un compresseur qui fait des PNG 3 ko plus gros

Pour les algos, je sais pas si t'arriveras à faire un truc exact qui reste efficace avec beaucoup de sprites... (par contre si un truc approché te convient, http://www.csc.liv.ac.uk/~epa/ )

(en plus ça bouffe la RAM du client à mon avis, vu que toute l'image est chargée n fois...)

Non en *théorie* elle ne devrais l'etre qu'une fois...

Tu crois que le navigateur découpe l'image d'origine ?
Quand je vois la RAM qu'ils consomment tous, j'ai des doutes quant à ce genre d'optimisations (en plus, on peut déplacer les images en changeant les propriétés en dynamique. Tu crois que le navigateur redécoupe vraiment à chaque fois ?

moi non y'aura un download + plusieurs pixmap buffers

Pen^2 (./21) :
Tu crois que le navigateur découpe l'image d'origine ?
Quand je vois la RAM qu'ils consomment tous, j'ai des doutes quant à ce genre d'optimisations (en plus, on peut déplacer les images en changeant les propriétés en dynamique. Tu crois que le navigateur redécoupe vraiment à chaque fois ?

Il découpe pas, mais il charge l'image complete qu'une seule fois, et quand il viens pour "blitter" l'image sur la page, il le fait de maniere clipé (c'est + ou - comme ça que marche WebKit)

onur (./11) :
Le but est d'optimiser sans perdre d'info donc pas de "réduction de palette".

Mais faut pas rajouter des règles en cours de jeu aussi !
L'optimisation passe toujours par de la triche en exploitant des faiblesses, quelles soient matérielles ou humaines.

Il ne rajoute pas des règles... le "jeu" est clairement défini au post ./1 comme étant la réduction de la taille du png en réarrangeant les images;
Ça ne sert à rien de parler d'autres techniques qui certes peuvent réduire la taille du png, mais n'ont rien à voir.

Pollux > Oui c'est bien du bin packing 2D qu'il faut.

ZikZak > dsl si c'était pas clair dès le départ. Ta remarque est néanmoins intéressante parce que la réduction de couleur dans la palette peut être plus efficace lorsqu'on assemble les images en une comme ça.

Oui si elle sont toutes 'approchante' dans leurs couleurs, de façon a vraiment réduire la palette.
Mais au final ce que tu gagnera en octets sur une image tu le perdra en octets dans la CSS et dans le code de la page (découpage de la spritesheet).

Je viens de mater http://www.csc.liv.ac.uk/~epa/surveyhtml.html en détail et ça ne correspond pas exactement au problème. Ici on cherche plutôt à minimiser l'espace non-utilisé. Certains algos cités sont de très bonne heuristiques pour les problèmes citées mais ne sont pas bons du tout pour ce problème là.

Tu sais que ce que tu cherche a faire est NP-Complet ?

onur (./28) :
Ici on cherche plutôt à minimiser l'espace non-utilisé.

Là aussi, la seule différence c'est qu'ils s'intéressent au cas où la largeur est fixe par exemple. Si tu veux une solution bête et méchante tu parcours toutes les largeurs possibles... (et sachant que t'es pas à un pixel près t'es pas obligé de toutes les parcourir)
Plus précisément tu as juste un surcoût de l'ordre de log w / epsilon si tu veux une aire à un facteur 1+epsilon de l'aire optimale, rien de très grave.