Guetzli, l'algorithme de Google pour réduire le poids des fichiers JPG de 35 %

Guetzli, l’algorithme de Google pour réduire le poids des fichiers JPG de 35 %

Et avec lui celui du web

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

17/03/2017 3 minutes
106

Guetzli, l'algorithme de Google pour réduire le poids des fichiers JPG de 35 %

Google a publié un rapport annonçant un nouvel algorithme de compression. Baptisé Guetzli, il est capable de réduire le poids des fichiers JPG de 35 % en moyenne. Avec à terme l’espoir d’avoir un impact significatif sur le poids des pages web.

Le JPG représente de loin le format d’image le plus courant sur le web. L’algorithme de compression, qui détermine le poids de ces fichiers en tenant compte du critère de la qualité, est donc un élément déterminant. Google a annoncé hier un nouvel algorithme justement : Guetzli. Open source (sous licence Apache 2.0), il est désormais disponible pour des tests dans un dépôt GitHub.

Il existe une grande différence entre Guetzli et certains précédents travaux réalisés par Google, notamment WebP. Certes WebP prend appui sur le PNG et propose donc des images de meilleure qualité, mais avec un inconvénient majeur : il faut que le client lisant le fichier soit compatible avec le format, sinon l’image ne s’affiche pas.

Une réduction de 35 % du poids des images

Guetzli – qui signifie « cookie » en suisse allemand – se base sur les travaux déjà effectués sur l’algorithme Zopfli, déjà utilisé pour réduire le poids des images PNG et des fichiers gzip, et dont Brotli (présent dans Chrome et Edge) est une évolution importante. Résultat, les fichiers JPG produits sont en moyenne 35 % plus petits que ceux générés par libjpg, avec un avantage conséquent : ils restent parfaitement lisibles par le client.

Guetzli opère ses opérations en trois étapes successives : la transformation de l’espace colorimétrique, la transformée discrète en cosinus et la quantification. C’est particulièrement au cours de cette dernière étape que l’algorithme fait la différence, au moment où les choix sont faits sur la perte de qualité visuelle. Le tout est de jouer sur la qualité perçue, le « modèle psychovisuel » de Guetzli opérant à un niveau plus détaillé.

guetzli
Image d'origine - Compression libjpg - Compression Gutzli

Un temps de traitement beaucoup plus long

Il y a cependant un inconvénient, comme on pouvait s’en douter. Puisque la compression effectuée s’appuie sur plusieurs étapes successives et un nombre nettement plus important de calculs, le temps de traitement d’une image est « significativement plus long » que pour une image codée par la classique bibliothèque libjpg.

Pour Google toutefois, le jeu en vaut clairement la chandelle. L’éditeur assure qu’au cours des tests réalisés, les observateurs ont indiqué préférer le plus souvent les images compressées avec Guetzli que les classiques. Par ailleurs, la société espère que le nouvel algorithme motivera les développeurs web et les graphistes, puisque ce changement pourrait entrainer une réduction significative du poids des pages web, et donc de la bande passante nécessaire. Tout le monde serait donc gagnant.

Et maintenant ?

Ne reste finalement plus qu’à voir dans quelle mesure Guetzli sera adoptée par les utilisateurs et autres développeurs. Son aspect open source devrait contribuer à son acceptation, mais une clé du succès sera son intégration éventuelle à l’ensemble des outils impliqués dans la chaine de traitement. La suite Adobe pourrait ainsi jouer un grand rôle si l'éditeur décidait de le proposer, de même que les environnements de développement et tout ce qui a trait à la manipulation des images.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une réduction de 35 % du poids des images

Un temps de traitement beaucoup plus long

Et maintenant ?

Commentaires (106)


Alors ça c’est du lourd pour de l’allègement !



Y’a pas photo, et je demande à voir.


Et puis c’est le genre de traitement que tu peux faire la nuit en batch, pour ne pas perturber le traffic utilisateur


Je croyais que le fléau de la bande passante était le SPAM. Et maintenant le streaming porno.

Faudrait voir ce qui est le plus écolo au niveau mondial entre JPG et Gutzli.

On ne va pas mettre notre invention française à la poubelle comme ça!








Lochnar a écrit :



Et puis c’est le genre de traitement que tu peux faire la nuit en batch, pour ne pas perturber le traffic utilisateur





Malheureusement de plus en plus de site sont “mondiaux” et n’ont plus de nuit. Les batchs ont la vie dur :/



Avec les MEP alternées ta nuit tu peux l’avoir à 14h30 si tu veux. <img data-src=" />








Crillus a écrit :



Avec les MEP alternées ta nuit tu peux l’avoir à 14h30 si tu veux. <img data-src=" />





Lapin compris.



Alors aucune idée de ce que peut donner l’algorithme sur une image, mais avec la vue zoomé ça n’à pas l’air si top que ça niveau respect des couleurs. J’ai l’impression que ça “ternit” l’image. &nbsp;L’image de libjpg à l’air de plus respecter l’image mais par contre les couleurs “sautent” d’un pixel à un autre ce qui donne l’aspect un aspect beaucoup trop pixelisé.



Après ça a toujours plus proche de l’original que l’image de libjpg pour la comparaison.



Il y à des comparaison de l’image à taille réel plutôt qu’une image zoomé ?


Et sinon, pour ceux qui veulent réduire la taille des fichiers de nombreux formats sans perte de qualité, il existe le méconnu mais très efficace FileOptimizer (libre et open source).








vampire7 a écrit :



Et sinon, pour ceux qui veulent réduire la taille des fichiers de nombreux formats sans perte de qualité, il existe le méconnu mais très efficace FileOptimizer (libre et open source).







C’est ce que tu as fait pour ton avatar ?









Bejarid a écrit :



Lapin compris.







Les MEP alternées ou Mise en Production alternées.



Disons qu’en gros sur ce genre de site mondial, tout est redondé et pas juste en cas de panne. Le principe c’est de mettre à jour une infra de réserve, cette infra de réserve devient l’infra de production, et l’infra de production devient l’infra de réserve.



La variante consiste à placer une infra de réserve en production, le temps de patcher la production, pour ensuite rebasculer la réserve et la production une fois que le patch a été passé. L’infra de réserve en ensuite patchée à son tour.



Donc théoriquement tu peux patcher à n’importe quelle heure, d’où mon commentaire sur le fait que en théorie tu peux donc “patcher de nuit, à 14h30”. Dans les faits on fait quand même ça de nuit parce qu’il y a toujours quelques minutes d’interruption.





EDIT : j’imagine que ça fonctionne aussi sur les bases de données et les post-traitement. Et sinon il y a des mécanismes.



“Par ailleurs, la société espère que le nouvel algorithme motivera les

développeurs web et les graphistes, puisque ce changement pourrait

entrainer une réduction significative du poids des pages web, et donc de

la bande passante nécessaire. Tout le monde serait donc gagnant.”



Un moyen simple de réduire le poids des pages web serait d’arrêter de nous gaver comme des pigeons avec des dizaines de pubs, pop-ups, bandeaux flashys clignotants dans tous les sens …

&nbsp;

Sur ordi fixe c’est encore supportable, mais sur mobile c’est catastrophique.








Paraplegix a écrit :



Alors aucune idée de ce que peut donner l’algorithme sur une image, mais avec la vue zoomé ça n’à pas l’air si top que ça niveau respect des couleurs. J’ai l’impression que ça “ternit” l’image.





Ça m’a sauté aux yeux, et en effet on peut gagner en compression en stockant moins la chrominance, ce que fait normalement le JPEG avec le codage 4:2:2 (un peu comme une matrice de Bayer). Là il y a aussi une forme de lissage supplémentaire, que tu as relevé.

Cela dit, il faut voir ça sur un ensemble d’images, et sans le zoom qui est artificiel.







Cashiderme a écrit :



C’est ce que tu as fait pour ton avatar ?





<img data-src=" />



Non, j’ai découvert ce logiciel plus tard.

Mais pour le tien, tu pourrais passer de 99720 octets à 78243 octets. Et il n’y a vraiment aucune altération des pixels.


Please note that JPEG images do not support alpha channel (transparency). If the input is a PNG with an alpha channel, it will be overlaid on black background before encoding.



Boarf….&nbsp;<img data-src=" />


Il disait qu’il voyait pas le rapport entre ton commentaire et la discussion que t’as cité. Pas qu’il savait pas ce qu’était une MEP. Sinon il aurait demandé ce que c’était. C’est con un lapin, mais pas à ce point.



PS: Pour les bases c’est assez chiant, faut les mettre en lecture seule le temps de la monté de version, pour certain service ça oblige a de drôle de contorsion avec un design spécifique. Pour le post traitement il est doit être facultatif normalement, tout doit pouvoir se faire à la volé (quitte à être dégradé).


Mouais, sauf qu’actuellement je dirais à vue de nez que 80% des sites se contentent d’encoder leur JPEG avec les paramètres par défaut de l’application, sans gérer aucun des paramètres de compression, et parfois même sans gérer la taille (genre du 800x600 pour un thumbnail affiché à l’arrivée en 80x60). Bref, hormis chez les vrais professionnels, j’ai peur que ça ne soit guère utilisé…








vampire7 a écrit :



Et sinon, pour ceux qui veulent réduire la taille des fichiers de nombreux formats sans perte de qualité, il existe le méconnu mais très efficace FileOptimizer (libre et open source).





Je ne vois pas bien comment il gagne de la place sur du JPEG sans altérer la qualité. L’algorithme de compression du JPEG est connu et si FileOptimizer a trouvé une meilleure méthode que la libjpeg, ça serait déjà dans la libjpeg depuis longtemps.







Poppu78 a écrit :



Mouais, sauf qu’actuellement je dirais à vue de nez que 80% des sites se contentent d’encoder de sauver leur JPEG avec les paramètres par défaut de l’application





<img data-src=" />

merci.



Pas forcément, Google peut, par son monopole, imposer ce traitement. Quand tu reçois un mail de Google te disant que ton référencement est dégradé car tu ne respecte par leurs règles de vitesse, ben tu clic là où ils te disent de le faire, tu regarde leur rapport, et t’applique leur recommandation.




 Qui d'ailleurs sont plutôt bonne, j'ai eu le cas récemment sur un site vitrine à la con, et en 2h de boulot j'avais divisé le temps d'affichage de la page d'accueil par 5, sans trop de perte (config serveur web, encodage/taille des image, organisation du CSS/JS, ils analysent tout et donne des pistes intéressantes pour corriger ça).

le BPG était aussi une alternative intéressante mais je ne sais pas trop ce que c’est devenu …http://xooyoozoo.github.io/yolo-octo-bugfixes/#moscow&jpg=s&bpg=…

&nbsp;


&gt; Brotli (présent dans Chrome et Edge)



Brotli est aussi présent dans Firefox.


Après le JPEG2000 et le BPG, enfin un truc qui va prendre ?








OlivierJ a écrit :



Je ne vois pas bien comment il gagne de la place sur du JPEG sans altérer la qualité. L’algorithme de compression du JPEG est connu et si FileOptimizer a trouvé une meilleure méthode que la libjpeg, ça serait déjà dans la libjpeg depuis longtemps.





Fais des tests toi-même si tu ne le crois pas.



Si les logiciels employaient directement les meilleures méthodes, Guetzli n’aurait pas vu le jour…



On a une liste des algorithme qui allègent JPEG??



Car de mémoire Mozilla avait des travaux dessus et c’est d’ailleurs pour cela qu’ils ont refusé de mettre WebP dans Firefox.








vampire7 a écrit :



Fais des tests toi-même si tu ne le crois pas.

Si les logiciels employaient directement les meilleures méthodes, Guetzli n’aurait pas vu le jour…





La méthode Guetzli ne garantit pas forcément la même qualité, en tous cas elle est documentée. Et celle de FileOptimizer ?







Soriatane a écrit :



On a une liste des algorithme qui allègent JPEG??





Le JPEG est déjà le fruit de pas mal de réflexions et de tests, en principe c’est peu probable, à qualité égale.



mais on avait pas déjà le JPEG2000….??


Guetzli, en suisse allemand, ça veut dire “biscuit”… Zopfli c’est “petite tresse” et Broetli “petit pain”… Je me demande de quelle nationalité est l’un des chercheurs. Et si il n’était pas boulanger avant <img data-src=" />


C’est aussi ce que fait ImageOptim (pour macOS, sinon il existe aussi un service web). C’est un GUI qui utilise MozJPEG, qui retire les métadata (qui des fois sont plus lourde que l’image), utilise le progressive scan et d’autres techniques








Mem’s a écrit :



C’est un GUI qui utilise MozJPEG, qui retire les métadata (qui des fois sont plus lourde que l’image), utilise le progressive scan et d’autres techniques





(en effet, retirer les méta-données, c’est une solution facile et non-technique, mais en général ce n’est pas ça qu’on cherche :-) ).

Merci pour ce dernier lien. Cela dit dans certains cas il abaisse le niveau de détail (il l’écrit lui-même).



La conclusion est intéressante :



Xiph.org’s researcher Tim Terriberry calls JPEG an “alien technology from the future”. JPEG, designed over 20 years ago, has got so many details right that it still remains competitive today, despite being much simpler and faster to decode than newer formats trying to dethrone it. And MozJPEG isn’t done yet!



Je n’arrive pas à comprendre pourquoi sur le web on est bloqué sur le JPEG.



JVeux dire, c’est un format de l’époque des 56k, le tout début du web, pourquoi on se tape encore cette merde 20 ans plus tard alors qu’en face en comparaison on a la compression vidéo qui a été exponentielle ?


Je te renvoie au lien et au passage cité, dans mon commentaire juste au-dessus du tien.








OlivierJ a écrit :



La méthode Guetzli ne garantit pas forcément la même qualité, en tous cas elle est documentée. Et celle de FileOptimizer ?





Je ne suis pas l’auteur du logiciel. Je sais seulement qu’il a étudié attentivement tous les formats pris en charge et qu’une bonne partie de son logiciel s’appuie sur les librairies faites par d’autres (par ex. PngOptimizer). Il y a de nombreux utilitaires en ligne de commande (appelés par le GUI), et chacun d’entre-eux a un fichier texte présentant les techniques utilisées.



L’ensemble du logiciel est d’ailleurs assez lourd (le dossier d’installation prend plus de 80 Mo), et il est terriblement lent sur certains formats (en particulier le png). Mais au moins, il fait ce qu’il prétend.



Sûrement que ces algos sont développés à Google Zurich <img data-src=" />








vampire7 a écrit :



Non, j’ai découvert ce logiciel plus tard.

Mais pour le tien, tu pourrais passer de 99720 octets à 78243 octets. Et il n’y a vraiment aucune altération des pixels.







Windows only apparement. Je touche pas à ces trucs là.

D’autant que ça interesse surtout les serveurs, en tant qu’utilisatrice je cours pas après le moindre octet, tant que ça loge sur une disquette <img data-src=" />



Le JPEG2000 sert au cinéma, chaque image est compressée avec.

Pour l’imagerie médicale aussi vus ses avantages de pouvoir avoir un ‘piqué’ plus ou moins précise selon les zones de l’image.

Mais c’est vrai que dans nos navigateurs internet, il ne sert pas.


le poids des pages web ne sont pas les images,mais la pub.

certains site avec 650 cookies bloqués…


Dommage qu’il n’y ait pas la prise en compte de la transparence, histoire de définitivement enterrer le jpeg 2000 :-)








legurt a écrit :



le poids des pages web ne sont pas les images,mais la pub.

certains site avec 650 cookies bloqués…





Je confirme les cookies, pub obèses qui font que les sites sont lents



Bon après un test rapide je te déconseille de lancer le script sur ton serveur de production, même si c’est un site relativement léger ! En effet pour tester je lui ai envoyé une image de 10 Mo il y a environ 30 min et il travaille toujours… (Je tourne sur un i5, 6Go RAM, Debian8) pas super puissant mais qui fait le travail pour le quotidien !

C’est assez gourmand en RAM et en CPU, niveau resultat bah je reviendrais poster !


C’est quoi la révolution ??? Google Photos a déjà un optimizer de ce type et surtout JPEGmini fait le même job pour des meilleurs perfs à priori depuis “seulement” &gt;3 ans… :o


Bon bah résultat mon image est passée de 9.3 Mo a 3.9 Mo ce qui est vraiment pas mal ! Niveau rendu je vois pas la différence donc bien mais a prévoir avant de convertir toutes les images, surtout pas sur le serveur ! A noter que les png transparents ne sont pas supportes et convertis avec un fond noir&nbsp;

&nbsp;

Source github : “Please note that JPEG images do not support alpha channel (transparency). If the input is a PNG with an alpha channel, it will be overlaid on black background before encoding.”


Ca a mis 30 min pour compresser une image ? rly ?


C’est super long.

Je lui ai fait manger un JPG 1920x1080 qui pèse 333 Ko, il faut bien 30 secondes de traitement, CPU à 100% (pas multi threadé au passage), processus à 300MB de RAM pour produire un fichier final de 284 Ko.

Y’a du potentiel, mais il n’est clairement pas possible de traiter les images à la volée.


Oui…

Je vais le tester sur ma bête de course pour voir la différence avec le laptop


A propos du JPEG200, il n’a jamais pris (en dehors de certaines niches) car il est bardé de brevets. Mais depuis le temps, les dits brevets ne sont pas encore tombés ?


Bon pour conclure, ça marche bien, mais qu’est ce que c’est leeeennnnt !

&nbsp;Sans commentaire :

&nbsp;

&nbsp;\(date vendredi 17 mars 2017, 21:04:35 (UTC+0100)

\)
./guetzli ~/Images/Day_Is_Done_3.jpg ~/Images/Day_Is_Done_03.jpg

\( date vendredi 17 mars 2017, 21:27:01 (UTC+0100)

\)
du -h Day_Is_Done_3.jpg&nbsp;

&nbsp;8,9MDay_Is_Done_3.jpg

&nbsp;$ du -h Day_Is_Done_03.jpg&nbsp;

&nbsp;3,8MDay_Is_Done_03.jpg&nbsp;

&nbsp;CPU :&nbsp;i7-6700K CPU @ 4.00GHz RAM 16Go



image source :&nbsp;http://www.dayisdone.ch/downloads/img/l/Day_Is_Done_3.jpg


Parce que ça fonctionne correctement, et que le débit mangé par la photo est fort inférieur à celui lié à la vidéo, qui est lui un vrai défi. Les autres formats photos ont longtemps été menacés niveau brevets, et comme jpeg fonctionne, « tant que ça marche, on touche pas » ©



C’est hélas je pense une explication des plus plausibles








Cashiderme a écrit :



C’est ce que tu as fait pour ton avatar ?



<img data-src=" />



Bon flute, je ne peux pas vérifier car il faut compiler le truc et je n’ai pas les outils.

Bon je vais surveiller ça de très prêt car ça m’intéresse beaucoup.


LOL,&nbsp; l’argument de la bande passante !

Non mais franchement, quelle foutage de “tronche”, surtout quand sur bien des sites, les “scripts inutiles et les pubs” font plus que doubler le poids des pages… il me semble qu’il y a des leviers plus intéressants à jouer si on veut réduire la bande passante, comme limiter les données “parasites” ! ! !



Mais bon, sinon, ca reste intéressant, c’est toujours ca de gagné !


C’est une catastrophe pour les fabricants de solution de stockage ! <img data-src=" /> <img data-src=" />



<img data-src=" />


C’est exactement ce que j’allais dire …<img data-src=" />



Le meilleur moyen de réduire la taille des pages que nous visitons n’est pas un meilleur algorithme de compression d’images, mais plutôt un meilleur bloqueur de Pub/Pop-Up/Scripts <img data-src=" />



Mais vu son fonds de commerce, Google ne travaillera jamais dessus <img data-src=" />


Un tel zoom au niveau des pixels ne permet pas de juger. En fait, le résultat est juste génial. Perso, J’ai fait des essais. Le résultat est juste bluffant. Ça apporte une diminution considérable des artefacts de compression et le résultat est très fidèle.



Quand on passe d’une version à l’autre à l’écran, il faut être attentif pour percevoir la différence entre un original non compressé et la version compressée avec guetzli tandis-que avec avec la même image compressée au même taux, mais avec algorithme de compression JPEG classique, les artefacts de compression se distinguent très nettement.



Mais qu’est ce c’est long. Sur des images de plusieurs mégas, le temps de compression se compte en minutes.








Trollalalala a écrit :



\(date vendredi 17 mars 2017, 21:04:35 (UTC+0100)

\)
./guetzli ~/Images/Day_Is_Done_3.jpg ~/Images/Day_Is_Done_03.jpg

$ date vendredi 17 mars 2017, 21:27:01 (UTC+0100)







Cadeau :https://linux.die.net/man/1/time <img data-src=" />







Krutors a écrit :



C’est une catastrophe pour les fabricants de solution de stockage ! <img data-src=" /> <img data-src=" />



<img data-src=" />







Mais non c’est un super argument pour ré-indexer la taxe copie privée sur les nouveaux taux de compression moyens observés <img data-src=" />









DayWalker a écrit :



LOL,&nbsp; l’argument de la bande passante !

Non mais franchement, quelle foutage de “tronche”, surtout quand sur bien des sites, les “scripts inutiles et les pubs” font plus que doubler le poids des pages… il me semble qu’il y a des leviers plus intéressants à jouer si on veut réduire la bande passante, comme limiter les données “parasites” ! ! !



Mais bon, sinon, ca reste intéressant, c’est toujours ca de gagné !







Quand tu t’appelle Google, ce n’est pas ton problème si le client met 10 secondes à exécuter un script de quelques ko.

En revanche, économiser des ko, voire des Mo sur les millions d’images que t’héberge, ça fait un paquet de frais en moins sur ta facture réseau.



Là, le résultat est bien supérieur à celui de JPEGmini. D’après mes quelques tests, avec un taux de compression de 85%, c’est environ 25% de moins en taille que via JPEGmini, et ce, avec un qualité supérieure (moins d d’artefacts de compression).



A un tel point que lorsque l’on passe une image compressée avec Gueztli comme source à JPEGmini, ce dernier ne donne aucun résultat et répond juste qu’il est désolé mais ne peut pas mieux faire.








kypd a écrit :



Mais non c’est un super argument pour ré-indexer la taxe copie privée sur les nouveaux taux de compression moyens observés <img data-src=" />







Genius !!! :)



FileOptimizer, qui maintenant en interne utilise justement guetzli pour la compression jpeg très poussée…








Trollalalala a écrit :



Bon pour conclure, ça marche bien, mais qu’est ce que c’est leeeennnnt !



&nbsp;Sans commentaire :      

&nbsp;

&nbsp;$date vendredi 17 mars 2017, 21:04:35 (UTC+0100)

$ ./guetzli ~/Images/Day\_Is\_Done\_3.jpg ~/Images/Day\_Is\_Done\_03.jpg

$ date vendredi 17 mars 2017, 21:27:01 (UTC+0100)

$ du -h Day\_Is\_Done\_3.jpg&nbsp;



&nbsp;8,9MDay_Is_Done_3.jpg

&nbsp;$ du -h Day_Is_Done_03.jpg&nbsp;

&nbsp;3,8MDay_Is_Done_03.jpg&nbsp;

&nbsp;CPU :&nbsp;i7-6700K CPU @ 4.00GHz RAM 16Go




image source :&nbsp;http://www.dayisdone.ch/downloads/img/l/Day\_Is\_Done\_3.jpg







Tu aurais le résultat avec passage à la moulinette ?









DayWalker a écrit :



LOL,&nbsp; l’argument de la bande passante !

Non mais franchement, quelle foutage de “tronche”, surtout quand sur bien des sites, les “scripts inutiles et les pubs” font plus que doubler le poids des pages… il me semble qu’il y a des leviers plus intéressants à jouer si on veut réduire la bande passante, comme limiter les données “parasites” ! ! !&nbsp;





Cet argument est pourtant parfaitement recevable. D’une part ce n’est pas parce que le site de NRJ12 est bardé de trackers que Google ne peut pas proposer aux webmasters de sites “raisonnables” une méthode pour réduire leur besoin en bande passante.



D’autre part il ne faudrait pas oublier que les clients des Google, ce sont les gens qui gèrent des serveurs, pas des gens qui possèdent un ordinateur à la maison. Il est donc logique que leur comm s’adresse prioritairement à ceux-là.



Je lis beaucoup de commentaire qui parle de batch où du traitement d’une image déjà en jpeg.

Cette lib il faut l’utiliser sur l’image source pas sur une image déjà compressée…


Pas parce que certains sites font gâchent de la bande passante que les autres ne peuvent pas chercher à en économiser.


Ok, c’est clairement super long quand on monte le réglage de “qualité” d’encodage: pour un jpg à qualité 95%, sur un png de 11 Mo, guetzli met 19 min, imagemagick 1s pour un résultat pesant respectivement 2.3 Mo et 3.3 Mo.

Le gain en taille est conséquent, le gain en qualité d’image est léger, la perte en temps est … conséquente.



Je vais comparer avec BPG et mozjpeg. Et faudrait voir avec lepton si on peut gagner plus. Ce gain en taille m’intéresse fortement.


je demande à voir car rien que sur l’exemple 16x16 la différence est flagrante.

pour un usage spécifique peur être ?


Pour ceux qui veulent comparer visuellement quelques formats d’images entre eux (le site ne supporte pas mozjpeg ni encore guetzli)

https://xooyoozoo.github.io/yolo-octo-bugfixes/



Sur la même image que précédemment, mozjpeg ne prend que 2s à encoder, la taille passe de 11Mo à 2.5 Mo, soit un tout petit peu moins bien que guetzli. Niveau qualitatif, en zoomant beaucoup, je trouve guetzli à peine mieux que mozjpeg (c’est très subjectif à ce niveau, ca se joue au niveau du niveau de flou des défauts et du crénelage des arêtes de la photo). Bref, le gain de guetzli est minime dans le cas de cette image. Les ~19 minutes d’encodage ne sont pas rentables.


Chuck Norris a développé un algorithme qui compresse un JPEG pour qu’il tienne sur un seul bit, et il l’a appelé Bruztli.

&nbsp;








stratic a écrit :



FileOptimizer, qui maintenant en interne utilise justement guetzli pour la compression jpeg très poussée…





Ah oui merci, je n’avais pas vu l’ajout qui date de début janvier. Il y a maintenant un exécutable nommé guetzli.exe.



Néanmoins, je ne trouve pas d’option à ce sujet dans le GUI. Guetzli suppose une compression avec perte, or la seule option à ce sujet est pour les png.



Faut arrêter de pleurer à propos de la pub et du fait que les gens s’en foute, je suis un pro du web et je vous garanti qu’ici la performance est une priorité. Ce genre de nouvelles est juste parfait pour notre business….








adesfire a écrit :



Faut arrêter de pleurer à propos de la pub et du fait que les gens s’en fouteNT, je suis un pro du web et je vous garantiS qu’ici la performance est une priorité. Ce genre de nouvelles est juste parfait pour notre business….





La performance est une priorité, mais pas la conjugaison apparemment….



<img data-src=" />









33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



Chuck Norris a développé un algorithme qui compresse un JPEG pour qu’il tienne sur un seul bit, et il l’a appelé Bruztli.







C’est raconté dans l’excellent biopic “La Fureur du Dragon”, où l’on voit le parcours semé d’embuches de Chuck Norris pour optimiser Bruztli.









kypd a écrit :



Cadeau :https://linux.die.net/man/1/time <img data-src=" />





&nbsp;Oui aussi j’aurais du y penser !

&nbsp;



wanou2 a écrit :



Tu aurais le résultat avec passage à la moulinette ?





C’est a dire ? Avec le mode verbose ?



merci pour le lien.

&nbsp;

&nbsp;l’un de vous qui a fait les essais aurait l’amabilité de nous poster l’image source et le résultat pour que nous puissions aussi comparer. Vu que les navigateurs ne supportent pas encore Guetzli j’imagine qu’il faut sauvegarder ensuite le résultat dans un format sans perte pour justement pouvoir voir l’image et comparer les différences.








Cashiderme a écrit :



C’est raconté dans l’excellent biopic “La Fureur du Dragon”, où l’on voit le parcours semé d’embuches de Chuck Norris pour optimiser Bruztli.







<img data-src=" />



Guetzli is good.


C’est con, ca avait l’air intéressant comme logiciel… sauf que je viens d’essayer avec un .pdf et c’est tout sauf lossless ! Il m’a compressé les images comme un porc style JPEG bien pourri


Sisi, les images en JPEG “Guetzli” sont tout à fait lisibles par tous les navigateurs supportant déjà le JPEG <img data-src=" />


Mes JPEG générés par mon appareil photo ne sont pas acceptés par le logiciel, j’ai donc pris une image au pif qui fonctionne. Ce n’est probablement pas la bonne image de test.

Image initiale 4,9 Mo

Image finale 3,6 Mo



17 minutes sur mon portable sous FreeBSD.


Baaahh on sait faire depuis longtemps plus efficace que le JPEG, mais à l’époque le temps de calcul était rédhibitoire.

Google ne fait que recompter de l’existant !


merci ça donne une idée


my bad je croyais que du coup ce n’était pas supporté








Cashiderme a écrit :



C’est ce que tu as fait pour ton avatar ?





<img data-src=" />





Cashiderme a écrit :



en tant qu’utilisatrice je cours pas après le moindre octet, tant que ça loge sur une disquette <img data-src=" />





Ah, tu as abandonné les cartes perforées ? <img data-src=" />



[…] une réduction significative du poids des pages web, et donc de la bande passante nécessaire. […]



Y’a bien plus efficace que Guetzli pour économiser de la bande passante sur les pages web, et ça s’appelle µBlock Origin.



Ok, je sors …








Trollalalala a écrit :



&nbsp; C’est a dire ? Avec le mode verbose ?





Il demande si tu peux partager l’image après traitement <img data-src=" />









Pyraah a écrit :



Il demande si tu peux partager l’image après traitement&nbsp;<img data-src=" />



&nbsp;Désolé la semaine a été difficile !







wanou2 a écrit :



Tu aurais le résultat avec passage à la moulinette ?





traitée :&nbsp;https://ibb.co/gWAETv



originale :&nbsp;http://www.dayisdone.ch/downloads/img/l/Day\_Is\_Done\_3.jpg








Trollalalala a écrit :



&nbsp;Désolé la semaine a été difficile !





traitée :&nbsp;https://ibb.co/gWAETv



 originale :&nbsp;http://www.dayisdone.ch/downloads/img/l/Day\_Is\_Done\_3.jpg







Merci l’ami ! :)



Et je suis surpris, impossible de voir la différence °-°.









Pyraah a écrit :



Merci l’ami ! :)



Et je suis surpris, impossible de voir la différence °-°.





D’un autre coté, les deux sont des jpg, non ?



Pour l’image de Trollalalala qui passe de 9 Mo à 3,9 Mp, il y a eu une énorme perte d’informations et pourtant on ne voit pas grande différence à l’œil.


L’image de départ est quasiment brute aussi.

Sur cette image, avec du jpg « normal », c’est possible d’obtenir un fichier de quelques centaines de ko sans que cela se voit à l’œil.








Trollalalala a écrit :



&nbsp;Désolé la semaine a été difficile !





traitée :&nbsp;https://ibb.co/gWAETv



 originale :&nbsp;http://www.dayisdone.ch/downloads/img/l/Day\_Is\_Done\_3.jpg







Merci beaucoup :)









Mihashi a écrit :



L’image de départ est quasiment brute aussi.

Sur cette image, avec du jpg « normal », c’est possible d’obtenir un fichier de quelques centaines de ko sans que cela se voit à l’œil.





Avec KolourPaint (un paint basique sur linux) :&nbsphttps://ibb.co/gWqgQa



Pour une image qui fait moins d’un méga… effectivement la différence n’est pas des plus criantes. Peut être à voir avec une image plus riche en détail :)









Faith a écrit :



D’un autre coté, les deux sont des jpg, non ?





Tout à fait, mais la version traitée a perdu 58% du poids initial. Plus de la moitié sans réel impact visuel.









yannickta a écrit :



A propos du JPEG200, il n’a jamais pris (en dehors de certaines niches) car il est bardé de brevets. Mais depuis le temps, les dits brevets ne sont pas encore tombés ?





Cela dit il s’agit de brevets américains, dans tout le reste du monde on devrait s’en fiche ; sauf que vu la place importante du marché US dans le monde, c’est difficile de l’ignorer :-( .









oliv5 a écrit :



quand on monte le réglage de “qualité” d’encodage de sauvegarde/de compression









oliv5 a écrit :



Sur la même image que précédemment, mozjpeg ne prend que 2s à encoder convertir,





<img data-src=" />

Pitié, déjà qu’on voit parfois cet affreux “encodage” à propos des vidéos, pas sur les images à présent. On sauve (ou on convertit) en PNG ou en JPG.







33A20158-2813-4F0D-9D4A-FD05E2C42E48 a écrit :



Chuck Norris a développé un algorithme qui compresse un JPEG pour qu’il tienne sur un seul bit, et il l’a appelé Bruztli.





<img data-src=" /> <img data-src=" />









Cashiderme a écrit :



C’est ce que tu as fait pour ton avatar ?





<img data-src=" /><img data-src=" />



C’est “mignon” de s’attaquer au poids des images.



Mais quand est-ce qu’on s’attaque à changer tous les protocoles “texte” (HTTP, FTP, SMTP, POP,…) pour passer à du binaire ?



Parce qu’avec le nombre de requêtes qu’il peut y avoir ça pourrait pourrait faire un gain non négligeable…


Ce n’est pas en partie le but du http2 ?








adrenalinedj a écrit :



C’est “mignon” de s’attaquer au poids des images.



Mais quand est-ce qu’on s’attaque à changer tous les protocoles “texte” (HTTP, FTP, SMTP, POP,…) pour passer à du binaire ?



Parce qu’avec le nombre de requêtes qu’il peut y avoir ça pourrait pourrait faire un gain non négligeable…





Heu ça passe déjà en binaire.



La seule exception ce sont les PJ des mail.



Et quand bien même c’est un soucis, la compression des protocoles est souvent suffisant pour masquer l’overhead de la conversion en base64.









Trollalalala a écrit :



&nbsp;Désolé la semaine a été difficile !





traitée :&nbsp;https://ibb.co/gWAETv



 originale :&nbsp;http://www.dayisdone.ch/downloads/img/l/Day\_Is\_Done\_3.jpg







2,9Mo en JPEGMin, traitié en genre 7-8 sec… mouai ça me laisse tjrs autant perplexe ce truc… juste parce que c’est Google c’est foufou… alors que des mecs font une techno pareil depuis ~5 ans, sachant qu’ils font ça aussi en video (et que Netflix s’en sert ;)).









tpeg5stan a écrit :



Parce que ça fonctionne correctement, et que le débit mangé par la photo est fort inférieur à celui lié à la vidéo, qui est lui un vrai défi. Les autres formats photos ont longtemps été menacés niveau brevets, et comme jpeg fonctionne, « tant que ça marche, on touche pas » ©



C’est hélas je pense une explication des plus plausibles





Une&nbsp;des grandes forces des codecs vidéos est aussi de se reposer sur les images précédentes et suivantes &nbsp;, et c’est dans ce domaine que les plus grosses avancées ont été faites … on comprend facilement pourquoi ça n’a pas profité à la compression photo …



Sauf que jpegmini est propriétaire, le client gratuit est indisponible sous linux (qui couvre une bonne partie des serveurs) et la version serveur et plutôt chère…!&nbsp;http://www.jpegmini.com/server&nbsp;donc c’est loin d’être la meilleure solution !








DayWalker a écrit :



LOL,  l’argument de la bande passante !

Non mais franchement, quelle foutage de “tronche”, surtout quand sur bien des sites, les “scripts inutiles et les pubs” font plus que doubler le poids des pages… il me semble qu’il y a des leviers plus intéressants à jouer si on veut réduire la bande passante, comme limiter les données “parasites” ! ! !



Mais bon, sinon, ca reste intéressant, c’est toujours ca de gagné !





Ouais, c’est un peu mon sentiment aussi.





  • Ouais, on gagne 35% sur la BP !

  • Excellent, on va utiliser cette BP supplémentaire pour coller une vidéo de pub sans ralentir la page !









Trollalalala a écrit :



Sauf que jpegmini est propriétaire, le client gratuit est indisponible sous linux (qui couvre une bonne partie des serveurs) et la version serveur et plutôt chère…!&nbsp;http://www.jpegmini.com/server&nbsp;donc c’est loin d’être la meilleure solution !





Pour un utilisateur lambda, qui l’utilise pour ses photos, 20€ c’est pas si foufou que ça vs. le prix du matos.



Pour les versions serveurs c’est un peu plus tendu, mais bon, si t’as le besoin et les moyens d’avoir un CDN, avoir JPEGMini est a considéré.



Parce que la vue les perfs de Guetzli, bon on va pas se mentir, tu va pas pouvoir optimiser en temps réel les nouveaux assets (genre sur un Flickr like par ex), du coup c’est conso de BP vs conso de CPU… :o



Pour l’instant, vouloir absolument ne pas rémunéré pour un tel travail c’est un peu crevard en fait. Et comme dit, on a jamais fait autant de battage pour JPEGMini alors que ça fait mieux en moins de temps… WTF… Google c’est le messie pour tout ou quoi ?



Pour un utilisateur lambda d’accord pour jpgmini mais dans un environnement pro c’est même pas la peine. Je pense que le fait qu’on en parle est aussi du a la différence du traitement, guetzli traite l’image en elle même, jpgmini je ne sais pas (peut-être une compression numerique).&nbsp;

Je ne remet pas en cause l’efficacité&nbsp;de jpgmini mais ce genre de solution propriétaire sur un serveur c’est pour moi inconcevable !








oliv5 a écrit :



Ok, c’est clairement super long quand on monte le réglage de “qualité” d’encodage: pour un jpg à qualité 95%, sur un png de 11 Mo, guetzli met 19 min, imagemagick 1s pour un résultat pesant respectivement 2.3 Mo et 3.3 Mo.





+1 pour Imagemagick. J’ai trouvé un jour une commande ultra-performante pour réduire en batch rapidement de grandes quantités de photos (prise au smartphone ou via un appareil) avec un gain impressionnant de taille - ça reste parfait pour une visualisation à la dimension finale réelle voulue à l’écran, pas pour grossir ou imprimer sur papier en vue d’utilisation top qualité (et encore), mais à l’œil nu, on ne voit pas du tout la différence entre les deux :



convert *.jpg -auto-orient -filter Triangle -define filter:support=2 -resize XX% -unsharp 0.25x0.25+8+0.065 -dither None -posterize 136 -quality 82 -define png:compression-filter=5 -define png:compression-level=9 -define png:compression-strategy=1 -define png:exclude-chunk=all -interlace none -colorspace sRGB -strip -scene 1 XX-%02d.jpg



Il faut remplacer les différents XX : pour la réduction de taille (souvent de l’ordre de 20% de la photo originelle), ça enlève aussi toutes les métadonnées (strip), et le dernier XX après -scene c’est le nom des nouveaux fichiers (cela n’écrase pas la source), le 1 étant le N° à partir duquel la numérotation commence.



Pour un envoi mail ou un site, le résultat est bluffant, et le gain en poids plus que significatif (récemment, sur 12 photos je suis passé de 41,4 à 2 Mo !).



L’output conserve les exif ?


&nbsp;


Entre Brotli et Guetzli, les Suisse-Allemands doivent se sentir importants <img data-src=" />