Guetzli, l’algorithme de Google pour réduire le poids des fichiers JPG de 35 %
Et avec lui celui du web
Le 17 mars 2017 à 16h10
3 min
Internet
Internet
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é.
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.
Guetzli, l’algorithme de Google pour réduire le poids des fichiers JPG de 35 %
-
Une réduction de 35 % du poids des images
-
Un temps de traitement beaucoup plus long
-
Et maintenant ?
Commentaires (106)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 18/03/2017 à 07h18
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.
Le 18/03/2017 à 07h31
Le 18/03/2017 à 07h33
FileOptimizer, qui maintenant en interne utilise justement guetzli pour la compression jpeg très poussée…
Le 18/03/2017 à 09h28
Le 18/03/2017 à 09h44
Le 18/03/2017 à 09h45
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…
Le 18/03/2017 à 10h35
Pas parce que certains sites font gâchent de la bande passante que les autres ne peuvent pas chercher à en économiser.
Le 18/03/2017 à 10h38
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.
Le 18/03/2017 à 11h02
je demande à voir car rien que sur l’exemple 16x16 la différence est flagrante.
pour un usage spécifique peur être ?
Le 18/03/2017 à 12h01
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.
Le 18/03/2017 à 12h27
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.
Le 18/03/2017 à 12h37
Le 18/03/2017 à 13h12
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….
Le 18/03/2017 à 15h12
Le 18/03/2017 à 15h22
Le 18/03/2017 à 15h44
Le 19/03/2017 à 09h45
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.
Le 19/03/2017 à 15h23
Le 19/03/2017 à 15h30
Le 19/03/2017 à 15h42
Le 19/03/2017 à 20h14
Le 19/03/2017 à 20h28
Le 20/03/2017 à 00h22
Le 20/03/2017 à 07h30
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…
Le 20/03/2017 à 07h37
Ce n’est pas en partie le but du http2 ?
Le 20/03/2017 à 08h31
Le 20/03/2017 à 08h37
Le 20/03/2017 à 08h56
Le 20/03/2017 à 09h02
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…! http://www.jpegmini.com/server donc c’est loin d’être la meilleure solution !
Le 20/03/2017 à 10h10
Le 20/03/2017 à 11h47
Le 20/03/2017 à 12h32
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).
Je ne remet pas en cause l’efficacité de jpgmini mais ce genre de solution propriétaire sur un serveur c’est pour moi inconcevable !
Le 17/03/2017 à 16h18
Alors ça c’est du lourd pour de l’allègement !
Y’a pas photo, et je demande à voir.
Le 17/03/2017 à 16h20
Et puis c’est le genre de traitement que tu peux faire la nuit en batch, pour ne pas perturber le traffic utilisateur
Le 17/03/2017 à 16h21
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!
Le 17/03/2017 à 16h22
Le 17/03/2017 à 16h27
Avec les MEP alternées ta nuit tu peux l’avoir à 14h30 si tu veux. " />
Le 17/03/2017 à 16h30
Le 18/03/2017 à 15h49
merci pour le lien.
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.
Le 18/03/2017 à 15h53
Le 18/03/2017 à 16h22
Guetzli is good.
Le 18/03/2017 à 16h39
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
Le 18/03/2017 à 17h14
Sisi, les images en JPEG “Guetzli” sont tout à fait lisibles par tous les navigateurs supportant déjà le JPEG " />
Le 18/03/2017 à 17h43
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.
Le 18/03/2017 à 18h11
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 !
Le 18/03/2017 à 18h26
merci ça donne une idée
Le 18/03/2017 à 18h42
my bad je croyais que du coup ce n’était pas supporté
Le 18/03/2017 à 19h32
Le 18/03/2017 à 22h03
[…] 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 …
Le 18/03/2017 à 22h04
Le 19/03/2017 à 00h44
Le 19/03/2017 à 03h38
Le 19/03/2017 à 08h38
Le 19/03/2017 à 09h38
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.
Le 17/03/2017 à 16h31
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. 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é ?
Le 17/03/2017 à 16h34
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).
Le 17/03/2017 à 16h36
Le 17/03/2017 à 16h38
Le 17/03/2017 à 16h39
“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 …
Sur ordi fixe c’est encore supportable, mais sur mobile c’est catastrophique.
Le 17/03/2017 à 16h40
Le 17/03/2017 à 16h43
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.
Le 17/03/2017 à 16h45
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…. " />
Le 17/03/2017 à 16h46
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é).
Le 17/03/2017 à 16h46
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é…
Le 17/03/2017 à 16h51
Le 17/03/2017 à 16h52
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.
Le 17/03/2017 à 16h57
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=…
Le 17/03/2017 à 17h00
> Brotli (présent dans Chrome et Edge)
Brotli est aussi présent dans Firefox.
Le 17/03/2017 à 17h09
Après le JPEG2000 et le BPG, enfin un truc qui va prendre ?
Le 17/03/2017 à 17h12
Le 17/03/2017 à 17h13
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.
Le 17/03/2017 à 17h25
Le 17/03/2017 à 17h26
mais on avait pas déjà le JPEG2000….??
Le 17/03/2017 à 17h30
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 " />
Le 17/03/2017 à 17h34
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
Le 17/03/2017 à 17h41
Le 17/03/2017 à 17h41
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 ?
Le 17/03/2017 à 17h51
Je te renvoie au lien et au passage cité, dans mon commentaire juste au-dessus du tien.
Le 17/03/2017 à 18h05
Le 17/03/2017 à 18h08
Sûrement que ces algos sont développés à Google Zurich " />
Le 17/03/2017 à 18h17
Le 17/03/2017 à 18h30
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 17/03/2017 à 18h53
le poids des pages web ne sont pas les images,mais la pub.
certains site avec 650 cookies bloqués…
Le 17/03/2017 à 18h58
Dommage qu’il n’y ait pas la prise en compte de la transparence, histoire de définitivement enterrer le jpeg 2000 :-)
Le 17/03/2017 à 19h14
Le 17/03/2017 à 19h28
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 !
Le 17/03/2017 à 19h30
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” >3 ans… :o
Le 17/03/2017 à 19h43
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
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.”
Le 17/03/2017 à 19h46
Ca a mis 30 min pour compresser une image ? rly ?
Le 17/03/2017 à 19h49
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.
Le 17/03/2017 à 19h57
Oui…
Je vais le tester sur ma bête de course pour voir la différence avec le laptop
Le 17/03/2017 à 20h14
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 ?
Le 17/03/2017 à 20h33
Bon pour conclure, ça marche bien, mais qu’est ce que c’est leeeennnnt !
Sans commentaire :
\(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
8,9MDay_Is_Done_3.jpg
$ du -h Day_Is_Done_03.jpg
3,8MDay_Is_Done_03.jpg
CPU : i7-6700K CPU @ 4.00GHz RAM 16Go
image source : http://www.dayisdone.ch/downloads/img/l/Day_Is_Done_3.jpg
Le 17/03/2017 à 20h41
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
Le 17/03/2017 à 20h42
Le 17/03/2017 à 21h26
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.
Le 17/03/2017 à 22h11
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é !
Le 18/03/2017 à 05h42
C’est une catastrophe pour les fabricants de solution de stockage ! " /> " />
" />
Le 18/03/2017 à 06h52
C’est exactement ce que j’allais dire …" />
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 " />
Mais vu son fonds de commerce, Google ne travaillera jamais dessus " />
Le 18/03/2017 à 06h56
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.
Le 18/03/2017 à 07h00
Le 18/03/2017 à 07h14
Le 20/03/2017 à 14h13
Le 20/03/2017 à 16h53
L’output conserve les exif ?
Le 20/03/2017 à 17h02
Le 21/03/2017 à 10h45
Entre Brotli et Guetzli, les Suisse-Allemands doivent se sentir importants " />