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.
Commentaires (106)
#1
Alors ça c’est du lourd pour de l’allègement !
Y’a pas photo, et je demande à voir.
#2
Et puis c’est le genre de traitement que tu peux faire la nuit en batch, pour ne pas perturber le traffic utilisateur
#3
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!
#4
#5
Avec les MEP alternées ta nuit tu peux l’avoir à 14h30 si tu veux. " />
#6
#7
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é ?
#8
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).
#9
#10
#11
“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.
#12
#13
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.
#14
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…. " />
#15
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é).
#16
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é…
#17
#18
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.
#19
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=…
#20
> Brotli (présent dans Chrome et Edge)
Brotli est aussi présent dans Firefox.
#21
Après le JPEG2000 et le BPG, enfin un truc qui va prendre ?
#22
#23
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.
#24
#25
mais on avait pas déjà le JPEG2000….??
#26
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 " />
#27
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
#28
#29
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 ?
#30
Je te renvoie au lien et au passage cité, dans mon commentaire juste au-dessus du tien.
#31
#32
Sûrement que ces algos sont développés à Google Zurich " />
#33
#34
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.
#35
le poids des pages web ne sont pas les images,mais la pub.
certains site avec 650 cookies bloqués…
#36
Dommage qu’il n’y ait pas la prise en compte de la transparence, histoire de définitivement enterrer le jpeg 2000 :-)
#37
#38
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 !
#39
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
#40
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.”
#41
Ca a mis 30 min pour compresser une image ? rly ?
#42
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.
#43
Oui…
Je vais le tester sur ma bête de course pour voir la différence avec le laptop
#44
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 ?
#45
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
#46
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
#47
#48
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.
#49
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é !
#50
C’est une catastrophe pour les fabricants de solution de stockage ! " /> " />
" />
#51
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 " />
#52
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.
#53
#54
#55
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.
#56
#57
FileOptimizer, qui maintenant en interne utilise justement guetzli pour la compression jpeg très poussée…
#58
#59
#60
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…
#61
Pas parce que certains sites font gâchent de la bande passante que les autres ne peuvent pas chercher à en économiser.
#62
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.
#63
je demande à voir car rien que sur l’exemple 16x16 la différence est flagrante.
pour un usage spécifique peur être ?
#64
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.
#65
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.
#66
#67
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….
#68
#69
#70
#71
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.
#72
#73
Guetzli is good.
#74
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
#75
Sisi, les images en JPEG “Guetzli” sont tout à fait lisibles par tous les navigateurs supportant déjà le JPEG " />
#76
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.
#77
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 !
#78
merci ça donne une idée
#79
my bad je croyais que du coup ce n’était pas supporté
#80
#81
[…] 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 …
#82
#83
#84
#85
#86
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.
#87
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.
#88
#89
#90
#91
#92
#93
#94
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…
#95
Ce n’est pas en partie le but du http2 ?
#96
#97
#98
#99
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 !
#100
#101
#102
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 !
#103
#104
L’output conserve les exif ?
#105
#106
Entre Brotli et Guetzli, les Suisse-Allemands doivent se sentir importants " />