Google présente Jpegli, sa nouvelle bibliothèque de codage JPEG
Le 08 avril à 06h59
2 min
Internet
Internet
« 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.
Le 08 avril à 06h59
Commentaires (23)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 08/04/2024 à 08h14
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.
Le 08/04/2024 à 08h38
J'ai l'impression de lire de la science fiction
Le 08/04/2024 à 09h12
Le 08/04/2024 à 11h45
Le 08/04/2024 à 09h51
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.
Le 08/04/2024 à 09h55
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).
Le 08/04/2024 à 12h28
Le 08/04/2024 à 14h34
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.
Le 08/04/2024 à 16h58
Le 08/04/2024 à 17h50
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".
Modifié le 08/04/2024 à 20h45
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).
Modifié le 09/04/2024 à 10h31
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.
.
Le 08/04/2024 à 14h25
À 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...).
Le 08/04/2024 à 10h02
Le 08/04/2024 à 10h28
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...
Le 08/04/2024 à 10h45
Le 08/04/2024 à 14h23
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.
Le 08/04/2024 à 15h00
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
Le 08/04/2024 à 16h37
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"
Le 08/04/2024 à 10h51
Le 08/04/2024 à 10h50
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.
Le 08/04/2024 à 14h48
Après ce n’est peut-être pas exactement ce que tu voulais dire ?
Le 08/04/2024 à 15h18