Chromium fusionne JpegXL

 (chromium-review.googlesource.com)
2 points par GN⁺ 2026-01-14 | 1 commentaires | Partager sur WhatsApp
  • Le décodeur JpegXL a été intégré à la base de code de Chromium, permettant au navigateur de traiter les images au format JXL
  • La modification peut être consultée sur la page de revue de code Gerrit sous le titre « Wire up JXL decoder »
  • Cette fusion constitue une étape clé pour la prise en charge du format JpegXL, incluant le raccordement du décodeur
  • La revue de code est enregistrée comme une modification dans le dépôt src de Chromium (7184969)
  • Cela est significatif dans le cadre de l’élargissement de la prise en charge des formats d’image de nouvelle génération par les navigateurs web

Intégration du décodeur JpegXL dans Chromium

  • L’élément de revue de code Gerrit « Wire up JXL decoder (7184969) » correspond à une modification qui relie le décodeur JpegXL au projet Chromium
    • Cette modification est effectuée dans le dépôt src de Chromium
    • La plateforme de revue de code utilisée est chromium-review.googlesource.com
  • Comme l’indique le titre, il s’agit du travail consistant à raccorder (wire up) le décodeur JXL (JpegXL) à l’intérieur du navigateur
  • La page n’affiche ni explication supplémentaire ni détails du code ; seul le titre de la modification est visible
Publicité

Contexte technique

  • JpegXL est un format de compression d’image de nouvelle génération, visant à améliorer l’efficacité par rapport au JPEG existant (pas de mention directe dans le texte source, seul le nom technique apparaît)
  • Avec l’intégration du décodeur dans Chromium, les bases nécessaires à l’activation du traitement des images JXL au niveau du code sont désormais en place
  • Cette modification constitue une avancée technique liée à l’extension du système de décodage multimédia du moteur de navigateur

État du document

  • La page est présentée comme un instantané mis en cache d’une revue de code Gerrit
  • Un avertissement indique que le shadow DOM est masqué, mais le contenu réel du code n’est pas affiché
  • Par conséquent, les seules informations vérifiables dans ce document sont le titre de la modification et l’identifiant de revue (7184969)

À lire aussi

1 commentaires

 
GN⁺ 2026-01-14
Commentaires Hacker News

  • J’ai regardé l’article de blog de Cloudinary, un ancien article de référence qui compare webp, jpegxl, avif, jpeg, etc.
    Les graphiques sont bien présentés, et AVIF est très lent.

    • Quand JPEG est réglé sur la qualité la plus basse, il paraissait ici bien meilleur visuellement.
      Lien vers la section concernée
    • Je ne comprends pas exactement ce que ce site essaie de faire.
      Voir la capture d’écran
    • Si, comme le dit la citation, JPEG XL a désormais consolidé sa position de meilleur codec, avec pertes comme sans pertes, c’est une avancée majeure capable de remplacer à la fois JPEG et PNG.
    • Cela dit, ce test n’utilise pas d’encodeur/décodeur avec accélération matérielle.

  • La bibliothèque jxl-rs est une implémentation Rust de JPEG XL.
    C’est un projet relativement récent, mais grâce à Rust, cela semble rassurant du point de vue de la sûreté de sécurité.
    Cette bibliothèque n’existait pas lors des anciennes discussions autour de Chromium.

    • Si je me souviens bien, Google avait rejeté JPEG XL à cause d’un « manque d’intérêt ». Il me semble que ce n’était pas pour des raisons de sécurité.
    • Je ne suis pas d’accord avec l’idée que « Rust réduit les inquiétudes de sécurité ». La sûreté mémoire n’est pas la sécurité en soi.
      Rust peut inspirer un excès de confiance, et conduire à omettre la modélisation des menaces.
      Au contraire, un programmeur C prudent peut parfois être plus sûr.
    • J’ai vérifié combien de code unsafe il y a réellement.
      Lien vers les résultats de recherche

  • J’ai récemment comparé WebP et AVIF, et WebP s’encode quasiment instantanément, tandis qu’AVIF met plus de 20 secondes pour une image de 1 MP.
    JXL n’est pas encore assez pris en charge pour être utilisable en pratique, mais j’espère une vitesse au niveau de WebP avec une meilleure qualité.

    • On dit que rav1e est à l’arrêt depuis des années côté mises à jour, donc il vaut mieux utiliser des encodeurs comme aom ou svt-av1.
    • Avec AVIF, il faut ajuster les paramètres d’utilisation CPU. La configuration par défaut emploie un niveau CPU trop élevé, d’où la lenteur.
      Dans mon environnement, je génère un AVIF de 2 MP en environ 100 ms.

  • Il est regrettable que la spécification publique (spec) de JPEG XL ne soit pas librement accessible.

    • Je trouve honteux de maintenir des standards non publics.
    • Le vrai problème, c’est que tant de documents d’organismes comme l’ISO ou l’IEC sont derrière un paywall.

  • On a encore droit à un nouveau format d’image, et j’ai peur qu’on se retrouve une fois de plus dans une situation où il reste inutilisable sans conversion.

    • Malgré tout, même Microsoft a publié un module complémentaire JPEG XL, et maintenant que Google recule, je pense qu’il y a une vraie opportunité.
      Lien Microsoft Store
    • En pratique, beaucoup d’applications le prennent déjà en charge — Affinity, Photoshop, Microsoft Photos, Gimp, ainsi que le support système global sur iOS 17+ / macOS 12+.
      Chromium est plutôt en retard sur ce point.
    • Bien sûr, un nouveau format a toujours besoin d’environ 10 ans d’adoption.

  • En lisant la liste des fonctionnalités de JPEG XL sur Wikipédia, j’ai vu des fonctions intéressantes comme les images multicanales ou les documents multipages.
    Il y a de bons côtés, mais cela donne de plus en plus l’impression de devenir aussi complexe que TIFF.

  • Il reste encore beaucoup de points communs entre JPEG et JPEG-XL.
    Je me demande si une nouvelle implémentation qui intégrerait aussi la prise en charge du JPEG classique permettrait de réduire la taille du code.

    • En fait, une issue a déjà été ouverte dans le dépôt Rust de JPEG-XL pour cette fonctionnalité.
      Lien vers l’issue #513

  • Personnellement, comme avec WEBP, je préfère continuer à utiliser le JPEG existant plutôt qu’un nouveau format.
    La plupart des programmes le prennent en charge, et pour l’utilisateur moyen, JPEG + PNG suffisent largement.
    Pour les animations simples, GIF suffit, et pour les contenus complexes, on peut utiliser de la vidéo.

    • Contrairement à ce que son nom laisse penser, « JPEG XL » n’est pas simplement une extension de JPEG.
      Il permet un encodage sans perte avec des fichiers plus petits que PNG, et prend aussi en charge un transcodage réversible en compressant les JPEG existants 20 % de plus.
      HDR, gamme étendue, chargement progressif et bien d’autres fonctions en font un format idéal pour le web.
      Voir jpegxl.info
    • WebP peut désormais être considéré comme un format standard de fait.
      Tous les principaux navigateurs le prennent en charge depuis Safari 14, et il est intégré par défaut depuis Windows 10 et macOS Big Sur.
      Voir l’état du support et la liste des logiciels.
    • GIF est désormais inefficace. Le remplacer par de la vidéo est 5 à 10 fois plus efficace.
      Article connexe

  • Cela fait longtemps que j’entends parler du débat JPEG XL, WebP et AVIF, mais je connaissais mal le sujet.
    Les benchmarks montrent que JpegXL est supérieur à WebP à la fois en vitesse de compression et en taille de fichier ; je me demande donc pourquoi Chromium hésitait à l’adopter.

    • WebP et AVIF partagent du code avec VP8/AV1, ce qui facilite leur intégration dans le navigateur, alors que JPEG-XL repose sur une base de code distincte, ce qui augmente la charge d’implémentation.
      De plus, libjxl représente plus de 100 000 lignes de C++, avec donc un risque de vulnérabilités de sécurité.
      À mesure que l’implémentation Rust mûrit, Chrome semble réévaluer la question.
    • JPEG XL prend en charge le décodage progressif.
      Vidéo de démonstration
    • Google soutenait qu’avoir plusieurs formats similaires n’augmente que le risque de sécurité, et qu’AVIF seul suffisait.
    • AVIF est bon à faible bpp (basse qualité), mais faible en sans perte, tandis que JXL est performant en haute qualité et en sans perte.
    • Par le passé, la bibliothèque C++ de JPEGXL était dans un état de maintenance interrompue, mais avec l’arrivée de la version Rust, son adoption par les navigateurs est redevenue possible.

  • Je me demandais si JPEG XL prend en charge l’animation.

    • Oui, mais comme il n’y a pas de compression inter-image, c’est inefficace et les fichiers sont plus volumineux qu’une vidéo classique.
    • D’après la page Chrome Platform Status, l’animation, le HDR et le décodage progressif sont tous pris en charge.
      Lien détaillé
    • Je l’ai effectivement testé dans le navigateur Canary, et l’animation fonctionnait bien.
    • Quelqu’un l’a résumé en plaisantant : WebP est en quelque sorte une « image au format vidéo », tandis que JPEG XL est une « vidéo au format image », ce qui crée une symétrie paradoxale 😄