Google a-t-il relancé la prise en charge de JPEG XL ?

 (tonisagrista.com)
5 points par GN⁺ 2025-12-03 | 2 commentaires | Partager sur WhatsApp
  • Le moteur Chromium rétablit la prise en charge de JPEG XL et un format d’image autrefois abandonné revient sous le feu des projecteurs
  • En 2022, Google avait retiré JPEG XL au motif d’un « manque d’intérêt de l’écosystème », mais la pression continue de la communauté et des grandes entreprises a perduré
  • Plusieurs organisations, dont Meta, Intel, Adobe, Cloudinary et Krita, ont publiquement soutenu le maintien du format
  • Récemment, l’annonce de la PDF Association d’adopter JPEG XL comme format de base pour les contenus HDR a renforcé cette dynamique
  • La décision de réintroduire Chrome est considérée comme un tournant augmentant la possibilité de standardisation grand public de JPEG XL

Contexte de la résurrection de JPEG XL

  • En 2022, l’équipe Chromium a supprimé le code et les flags de JPEG XL, invoquant un « manque d’intérêt suffisant de l’écosystème » et un « manque d’avantages par rapport aux formats existants »
    • À l’époque, la communauté s’était déjà prononcée en faveur du format, notamment via des soutiens de Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips et Krita
    • Des réactions ont ensuite suivi via des blogs, vidéos et réseaux sociaux pour souligner l’iniquité de cette décision de suppression
  • À la fin de 2025, l’équipe Chromium a changé l’état du ticket JPEG XL, anciennement Obsolete, en Assigned, lançant officiellement le processus de réintégration
    • Au sein du groupe de développement Blink, Rick Byers a salué l’idée d’un décodeur JPEG XL performant et sûr au niveau mémoire
    • Cette décision s’est appuyée sur des signaux positifs comme le support de Safari, l’évolution de la position de Firefox et l’impulsion de la PDF Association

Firefox et le développement d’un décodeur en Rust

  • L’équipe Firefox a insisté sur la nécessité d’une version Rust, considérée comme « mémoire-sûre », en raison des risques de sécurité du décodeur libjxl basé sur le C++
    • De ce fait, Google Research a commencé à développer l’implémentation Rust jxl-rs
    • Ce projet a été un catalyseur pour renforcer la faisabilité d’une intégration sûre de JPEG XL dans les navigateurs

Mouvement d’adoption de la PDF Association

  • Le CTO de la PDF Association, Peter Wyatt, a annoncé son intention d’inclure JPEG XL comme format d’image HDR par défaut dans la spécification PDF
    • Cela agit comme un facteur de renforcement du potentiel de standardisation de JPEG XL dans les secteurs de la documentation et de l’édition

Principales caractéristiques techniques de JPEG XL

  • Grâce à la recompression sans perte du JPEG d’origine, JPEG XL permet une réduction d’environ 30 % de la taille sans perte de qualité
  • Prise en charge de la large gamme de couleurs et du HDR, avec prise en charge de canaux allant jusqu’à 32 bits et jusqu’à 4 099 canaux
  • Prise en charge d’une taille d’image maximale de 1,073,741,823×1,073,741,824, permettant le traitement d’images ultra-étendues
  • La prise en charge du décodage progressif (progressive decoding) améliore l’efficacité du transfert web
  • Fonctions d’animation, de transparence alpha et de depth map incluses
  • Une structure robuste face à la perte générationnelle réduit au minimum la dégradation de la qualité lors des réencodages successifs

Conclusion

  • JPEG XL répond aux critères d’un format image de nouvelle génération, et le retour de Chrome constitue un moment décisif pour une diffusion à grande échelle
  • Résultat de la pression communautaire de long terme, cette réintégration hisse JPEG XL au rang de nouveau candidat au statut de standard dans l’écosystème de l’imagerie web
  • L’auteur accueille favorablement la réévaluation de Chromium, tout en soulignant que cette décision a été prise avec beaucoup de retard.

À lire aussi

2 commentaires

 
GN⁺ 2025-12-03
Avis Hacker News

  • L’une des fonctionnalités intéressantes mais peu connues de JPEG XL est un mode permettant un transcodage sans perte depuis JPEG tout en réduisant l’espace de stockage d’environ 20 %
    Comme le bitstream d’entropie d’origine est conservé tel quel, c’est entièrement réversible
    GCP applique cela à son DICOM Store API, ce qui permet de profiter des gains d’espace de JXL tout en servant à la volée une conversion en JPEG
    Notre entreprise stocke des dizaines de PB de données dans GCP DICOM Store, donc nous espérons que cette fonctionnalité réduira fortement nos coûts annuels
    Nous espérons aussi un support natif dans les navigateurs, et j’ai entendu dire que l’équipe Chrome finirait par l’adopter

    • Je me demande quelle est la différence par rapport à un encodeur JPEG moyen ou à mozjpeg
    • Je n’ai jamais eu le temps de tester GCP DICOM Store auparavant, donc je serais curieux de savoir ce que ça donne en pratique
      Je voudrais savoir si c’est un PACS complet, une implémentation de WADO, ou simplement une API custom
    • Si c’est réversible, ne suffit-il pas de stocker en JPEG XL puis de reconvertir au moment du service ?
      Je me demande si le traitement est particulièrement coûteux
    • S’il faut de toute façon stocker le DICOM d’origine, je me demande quel est l’intérêt du transcodage
      J’imagine que l’essentiel du coût de stockage vient du DICOM lui-même
    • Au final, comme les gros clients de GCP profitent beaucoup de cette fonctionnalité, j’ai l’impression que la raison de pousser JXL dans Chrome vient de clients internes

  • Le concurrent de JPEG XL n’est pas AVIF
    AVIF est déjà devenu un standard de fait, pris en charge par presque tous les navigateurs, et utilisé aussi comme format d’image par défaut chez Apple
    JXL reste encore peu pris en charge par les navigateurs, mais se fait une place dans des niches comme l’archivage, la photo professionnelle et le médical
    Dans une dizaine d’années, il pourrait devenir assez courant pour que les gens l’appellent simplement « JPEG »
    AVIF est un standard ouvert et sans redevance, bien plus efficace que JPEG/WebP en compression, et d’un niveau comparable à JXL
    La taille maximale des images JXL est plus grande, mais en adoption réelle AVIF est très largement devant
    Quand AV2 arrivera, l’écart de qualité disparaîtra presque, et les deux formats devraient continuer à évoluer en conservant un niveau de qualité similaire

    • Il est évident qu’AVIF compresse mieux que JPEG ou WebP, mais face à JXL, il ne rivalise pas
      Avec des réglages de qualité réalistes, JXL offre un meilleur taux de compression ainsi qu’un encodage et un décodage plus rapides
      En plus, il prend en charge le progressive decoding
      AV2 pourra peut-être le rattraper, mais pour l’instant je pense que JXL est très largement devant
    • L’une des raisons pour lesquelles l’équipe Chrome avait abandonné le support de JXL était qu’AVIF était déjà jugé suffisamment bon
      Ce réexamen semble lié à cette décision de l’époque
    • Dire que « le format d’image par défaut d’Apple est AVIF » me semble faux
      L’iPhone utilise HEIF
    • J’ai utilisé libjxl directement, et j’ai trouvé que la consommation mémoire était élevée et instable
      Encoder des images en haute résolution semblait nécessiter jusqu’à une RAM de niveau téraoctet
      J’ai été surpris par l’état du codebase, et beaucoup d’options ne fonctionnaient pas correctement
      Le fait de réessayer avec jxl-rs est positif, mais comme ce sont les mêmes développeurs qui y participent, je reste prudent

  • Il est probable que Chromium utilise le crate jxl-rs pour la fonctionnalité JPEG XL
    Ils semblent sans doute attendre qu’il soit suffisamment stabilisé avant de l’intégrer
    L’issue correspondante est consultable ici

    • Mozilla avait une position similaire, mais Google a longtemps affiché une attitude hostile
      Ils avaient fermé l’issue malgré l’opposition des utilisateurs, et ne l’ont rouverte que récemment
      C’est peut-être lié à des problèmes de relations publiques ou à des frustrations internes
    • jxl-rs a connu une période de plus d’un an et demi sans commit
      Si ça avance bien aujourd’hui, c’est peut-être aussi un coup de chance

  • J’ai regardé l’implémentation de référence (C++) de JPEG XL, et il y a encore deux ans la qualité du code n’était pas bonne
    Cela donnait l’impression qu’il pouvait y avoir des problèmes de sécurité

    • C’est pourquoi Mozilla et Google envisagent tous deux le support de JXL à condition d’avoir une implémentation memory-safe
      Une version Rust est en cours de développement, et Google prévoit aussi de remplacer progressivement tous les décodeurs de Chromium par des implémentations Rust
    • En réalité, en 2025, tout gros code de traitement d’image écrit en C++ constitue en soi un risque de sécurité
      Ce n’est pas un problème propre à JPEG XL

  • La résolution maximale de JPEG XL est de 1,073,741,823 × 1,073,741,824, ce qui permet de représenter des images ultra-haute résolution atteignant des centaines de pétaoctets
    En pratique, même après compression, on reste à des dizaines à des centaines de PB

    • À 600 DPI, un côté correspondrait à une distance de marathon
      Si l’on peut définir une image aussi gigantesque dans un petit nombre d’octets, cela pourrait aussi devenir un vecteur d’attaque DOS
      J’ai essayé de convertir ça en feuilles A4, mais le calculateur Gemini a confondu les unités et a donné un résultat absurde
    • Pour de telles images géantes, la seule méthode réellement pratique est de les gérer avec du tiling et une structure pyramidale
    • Cela correspondrait à peu près à une image de toute la Terre avec une résolution d’environ 4 cm
    • À cette résolution, un selfie ressemblerait à de la microscopie super-résolue
    • Contrairement à AVIF, JPEG XL prend en charge un progressive decoding efficace, ce qui permet d’afficher rapidement un aperçu de basse qualité pendant le téléchargement

  • Recueil d’anciennes discussions HN
    Chromium Team Re-Opens JPEG XL Feature Ticket
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • J’utilise .avif depuis plusieurs années
    Ce n’est pas parfait, mais je le trouve bien meilleur que .jpg ou .png
    J’ai aussi envisagé .webp et jpeg-xl, mais au final je suis satisfait de .avif
    En revanche, je n’aime pas que Google dicte de fait les standards du Web
    Il n’est pas souhaitable qu’une entreprise commerciale contrôle l’écosystème numérique

    • Dans la phrase « .avif est meilleur que .jpg », le fait de répéter .avif deux fois prête à confusion
    • Si vous voulez réduire la taille d’un JPEG de haute qualité, je recommande d’essayer jpegli
      jpegli GitHub
      Avec de bons réglages de quasi-sans-perte visuelle, AVIF peut parfois être plus petit que jpegli, mais en moyenne jpegli est plus efficace
    • À titre de remarque, en anglais, « for several years » est plus naturel que « since some years »
    • JPEG XL perd moins en qualité après plusieurs réenregistrements, ce qui est un avantage pour le Web
      Vidéo liée : lien YouTube

  • Ce n’est pas « Google dans son ensemble » qui a supprimé JXL, mais l’équipe Chrome
    JXL a été conçu par Jyrki Alakuijala du laboratoire Google Zurich, qui ne fait pas partie de l’équipe Chrome mais de Google Research
    L’équipe Chrome a une culture fermée centrée sur Mountain View

    • Jyrki est un excellent ingénieur, à l’origine aussi de Brotli, WebP lossless, WOFF2, jpegli, entre autres
      Le fait qu’il ait créé jpegli après l’abandon de JpegXL relevait aussi d’une forme de réaction
    • On peut probablement expliquer cette situation par la loi de Conway

  • Il semble que JXL ait été retardé parce que sa dépendance à de nombreux composants multithreadés en C++ pouvait élargir la surface d’attaque de sécurité
    Mozilla comme Google préfèrent une implémentation Rust pour éviter cela
    Le standard lui-même est clairement une amélioration par rapport aux formats existants

    • Parler de 100 millions de lignes semble très exagéré
    • En réalité, on est plutôt autour de 30 000 lignes, et la version mono-thread tourne autour de 10 000 lignes
      Le binaire est aussi bien plus petit qu’AVIF, et la spécification est beaucoup plus concise
    • Puisque Google a participé au développement de JXL, le fait de ne pas avoir produit plus tôt un décodeur memory-safe relève de sa propre responsabilité
    • Vous vouliez peut-être parler de 100 000 lignes ? Une bonne partie serait sans doute du code de test
    • En réalité, libjxl représente environ 112 000 lignes, soit trois ordres de grandeur de moins que l’affirmation des 100 millions

  • Les fichiers RAW de l’iPhone 17 Pro seraient compressés en JPEG XL