« L'internet a changé notre façon de vivre, de travailler et de communiquer. Cependant, il peut devenir une source de frustration lorsque les pages se chargent lentement. Le codage des images est au cœur de ce problème », affirme Google.
Pour combattre ce phénomène, l’entreprise propose une nouvelle bibliothèque, Jpegli. Objectif : proposer un meilleur codage JPEG. Comme toujours, il s’agit de réduire le poids à qualité équivalente. Selon Google, le taux de compression est amélioré de 35 % avec des paramètres de compression de haute qualité.
La bibliothèque intègre le codeur et le décodeur, tous deux entièrement compatibles avec la norme JPEG originale. Une compatibilité API/ABI est également présente avec libjpeg-turbo et MozJPEG. Le code est open source, disponible sur GitHub et sous licence de type BSD.
Google assure qu’avec les opérations réalisées par Jpegli, « les images paraîtront plus claires et présenteront moins d'artefacts observables ». La vitesse opérationnelle serait comparable à libjpeg-turbo et MozJPEG, tout en améliorant le rapport qualité/compression.
Le codage des images peut en outre se faire sur plus de 10 bits. Cette opération « se fait dans le formalisme 8 bits original et les images résultantes sont entièrement interopérables avec les visionneuses 8 bits », indique Google. La dynamique sur 10 bits et plus est cependant dans une extension de l’API, donc optionnelle. Les applications devront être mises à jour pour tirer parti de ces capacités supplémentaires.
Tel qu’expliqué par Google, la compatibilité avec le JPEG 8 bits ordinaire était la priorité. Pour parvenir à une meilleure compression, elle s’est servie de techniques plus modernes, dont l’heuristique de quantification adaptative développée initialement pour JPEG XL. Jpegli peut d’ailleurs en reprendre optionnellement l’espace colorimétrique XYB pour pousser la qualité un cran plus loin.
« Jpegli est une nouvelle technologie prometteuse qui a le potentiel de rendre l'internet plus rapide et plus beau », n’hésite pas à conclure Google.
Commentaires (23)
#1
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#the_lossy_pareto_front
Extraits:
A specific method can be called Pareto-optimal if no other method can achieve the same (or better) compression density in less time. There might be other methods that compress better but take more time, or that compress faster but result in larger files. But a Pareto-optimal method delivers the smallest files for a given time budget, which is why it’s called “optimal.”
Medium Quality
More recently, the JPEG XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere.
High Quality
At this point, mozjpeg no longer beats WebP, though jpegli still does. The Pareto front is now mostly covered by JPEG XL, though for very fast encoding, good old JPEG is still best. At this quality point, AVIF is not on the Pareto front: at its slowest settings (at 0.5 Mpx/s or slower) it matches the compression density of the second-fastest libjxl setting, which is over 100 times as fast (52 Mpx/s).
Conclusion
Meanwhile, the old JPEG is still attractive thanks to better encoders. The new jpegli encoder brings a significant improvement over mozjpeg in terms of both speed and compression. Perhaps surprisingly, good old JPEG is still part of the Pareto front — when extremely fast encoding is needed, it can still be the best choice.
#2
J'ai l'impression de lire de la science fiction
#2.1
#2.2
#3
Parce que si c'est pour que les hébergeurs économisent sur le stockage et la bande passante mais que ça demande un effort supplémentaire à tous les clients pour afficher/décoder le fichier ce n'est peut-être pas un gain au final.
#4
Google et le taux de compression des images/vidéos. Episode 37.
Après l'échec de l'adoption de son format WebP, Google change de stratégie. Plutôt que de proposer un nouveau format, Google propose d'optimiser le taux de compression des formats existants. Mais au lieu de proposer un pull request sur le projet MozJPEG de Mozilla, Google présente sa propre bibliothèque...
Cast: Google (main), Mozilla (supporting).
#4.1
#4.3
Mais j'ai comme dans l'idée que Google ne cherche pas a réduire la taille des données transmises. A mon avis, Google cherche a envoyer davantage de pixels dans la même taille de données. La faute à la course au DPI.
C'est donc p-e pas aussi vertueux qu'on pourrait le penser.
#4.4
#4.5
Envoyer/afficher des images plus détaillées (dpi) au seul motif que les écrans ont une plus grande densité d'affichage de pixels (ppi), ne me semble pas pertinent.
Pour être vertueux, il faudrait m'envoyer une image avec une résolution adaptée aux dimensions observables sur mon écran, et pas me balancer la plus grosse image possible dans le cas improbable où j'aurais un téléviseur de 115".
#4.6
Je ne sais pas d’où vient cette supposition que Google souhaiterait gaspiller de la bande passante en envoyant des images inutilement grosses. Qu’y gagneraient-ils ?
Disclaimer : je travaille pour eux (mais j’écris en ma capacité personnelle).
Historique des modifications :
Posté le 08/04/2024 à 20h45
Que jpegli augmente la qualité perçue a bien été vérifié : https://github.com/google-research/google-research/tree/master/mucped23#results
Je ne sais pas d’où vient cette supposition que Google souhaiterait gaspiller de la bande passante en envoyant des images inutilement grosses. Qu’y gagneraient-ils ?
Disclaimer : je travaille pour eux.
#4.7
Aucune idée. Mais c'est probablement pour la même raison que les bannières sur youtube sont actuellement beaucoup plus grandes que ce qui est nécessaire pour la majorité des gens.
Ex: https://www.youtube.com/@joueurdugrenier
Dimension de mon écran:
- 1920x1080 (Dimension la plus répandue dans le monde d'après StatCounter)
Dimension du viewport (div) qui affiche la bannière avec chrome plein-écran (F11):
- 1284x207
Dimension de l'image envoyée par Youtube:
- 2120x352
Soit 746240 pixels envoyés alors que j'en affiche seulement 265788. Presque 3 fois moins.
.
Historique des modifications :
Posté le 09/04/2024 à 10h29
Aucune idée. Mais c'est probablement pour la même raison que les bannières sur youtube sont actuellement beaucoup plus grandes que ce qui est nécessaire pour la majorité des gens.
Ex: https://www.youtube.com/@joueurdugrenier
Dimension de mon écran:
- 1920x1080 (Dimension la plus répandue dans le monde d'après StatCounter)
Dimension du viewport (div) qui affiche la bannière avec chrome plein-écran (F11):
- 1284x207
Dimension de l'image envoyée par Youtube:
- 2120x352
Soit 746240 pixels envoyés que j'en affiche seulement 265788. Presque 3 fois moins.
.
Posté le 09/04/2024 à 10h30
Aucune idée. Mais c'est probablement pour la même raison que les bannières sur youtube sont actuellement beaucoup plus grandes que ce qui est nécessaire pour la majorité des gens.
Ex: https://www.youtube.com/@joueurdugrenier
Dimension de mon écran:
- 1920x1080 (Dimension la plus répandue dans le monde d'après StatCounter)
Dimension du viewport (div) qui affiche la bannière avec chrome plein-écran (F11):
- 1284x207
Dimension de l'image envoyée par Youtube:
- 2120x352
Soit 746240 pixels envoyés que j'en affiche seulement 265788. Presque 3 fois moins.
.
#4.2
À choisir, je préfère aussi un JPEG optimisé aux petits oignons, c'est plus simple à gérer, mais j'essaie de plus en plus d'avoir un WebP en alternative (quand le CMS le permet...).
#5
#6
Faut-il leur rappeler le pourcentage énorme et sans cesse croissant des contenu liés à la publicité (bannière, scripts JS, outils de tracking, etc.) pour une part de plus en plus faible de "vrai contenu" (textes, images, hors NEXT bien sûr)
Gagner 20% sur des images qui représentent 10% du poids total des pages à charger (au pif, je l'admet, mais j'ai la flemme de chercher les chiffres), c'est au mieux 2% de gagné au total.
Ublock + noScript font bien mieux...
#6.1
#6.3
En fait, ce sont des logos affichés en 200x200, mais les images PNG utilisées font 800x800 et pèsent plus de 2 Mo chacune... Déjà signalé, mais sans succès.
#6.4
On voit même souvent l'utilisation d'un format pas adapté (une photo en PNG par exemple).
Je t'invite à m'envoyer l'url du site via notre form de contact : https://www.lewebvert.fr/contact/
Je me ferais un plaisir de lancer un diagnostic et on tentera notre chance nous aussi
#6.5
Je suis d'une génération où on n'optimisait les images qu'après les voir réduites à la seule définition/taille nécessaire pour les écrans courants (de l'époque).
On n'utilisait que le JPEG pour les illustrations photographiques, et le PNG était utilisé pour la transparence sur des logos, et avec une palette (index de couleurs) pour limiter son poids...
Tout ça, c'était avant la mode "Rétina"
#6.2
#7
Quand ces cochonneries représentent 80% du poids d'une page téléchargée, il me semble que l'effort est d'abord à porter sur ces dernières. Vive miblock / Noscript et consorts.
#7.1
Après ce n’est peut-être pas exactement ce que tu voulais dire ?
#7.2