Journal JPEG-XL est finalement intégré dans Chromium (et donc Google Chrome)

Posté par  . Licence CC By‑SA.
Étiquettes :
12
14
jan.
2026

Phoronix (https://www.phoronix.com/news/JPEG-XL-Returns-Chrome-Chromium) relate donc l'événement mentionné dans le titre.

C'est l'implémentation en Rust (mentionnée dans https://linuxfr.org/news/premiere-sortie-du-decodeur-jpeg-xl-en-rust et disponible sur https://github.com/libjxl/jxl-rs) qui a été utilisée.

Les commits ont été faits dès le 10 décembre pour l'inclusion du codec (https://github.com/chromium/chromium/commit/740e9bb6eda1faec82bb17e11f87b7313b46a137), mais son branchement avec le moteur de rendu et l'interface du navigateur a été fait hier (https://github.com/chromium/chromium/commit/8215ebd5eb9d45b42bbc68e1ceff039a319b35d6)

On est bon pour le futur ?

  • # Fonctionnalités intéressantes ?

    Posté par  . Évalué à 4 (+3/-0).

    En regardant la page Wikipedia, les fonctionnalités qui attirent mon attention sont les espaces de couleurs HDR et la compression efficace des images synthétiques (screenshots). Ce qui est certes utile, mais déjà supporté par AVIF.

    Est-ce qu'un spécialiste pourrait nous expliquer ce que JPEG-XL apporte par rapport aux formats déjà supportés ?

    • [^] # Re: Fonctionnalités intéressantes ?

      Posté par  . Évalué à 6 (+4/-0).

      Y a tous les articles de Cloudinary sur https://cloudinary.com/blog/tag/jpeg-xl

      La page actuelle https://jpegxl.info/ est un peu bling-bling, l'ancienne est sur https://jpegxl.info/old/

      TL;DR JPEG-XL est beaucoup plus rapide que AVIF. AVIF garde une avance sur les toutes petites images. Les grosses images (> 9 MPixels) sont mal gérées par AVIF (https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs#:~:text=HEIC%20and%20AVIF%20can%20handle%20larger%20images%20but%20not%20directly%20in%20a%20single%20code%20stream%2E)

      • [^] # Re: Fonctionnalités intéressantes ?

        Posté par  . Évalué à 9 (+7/-0).

        De ce que j'ai pu lire, la conversion jpeg --> jpeg-xl se fait sans perte de qualité et est, de surcroît, réversible (i.e. jpeg-xl --> jpeg permet de retrouver le jpeg d'origine binairement identique). C'est un avantage par rapport à Avif.

        • [^] # Re: Fonctionnalités intéressantes ?

          Posté par  . Évalué à 3 (+1/-0).

          C'est vraiment utile ?

          • [^] # Re: Fonctionnalités intéressantes ?

            Posté par  . Évalué à 6 (+3/-0). Dernière modification le 15 janvier 2026 à 10:44.

            Il y a probablement des cas d'usages … Je pense à Internet Archive par exemple https://linuxfr.org/users/thoasm/liens/new-story-the-long-now-of-the-web-inside-the-internet-archive-s-fight-against-forgetting qui stocke des vieilles images à foison …

            Ils ne le feront sans doute pas si ils privilégient la fidélité des données stockées "bit pour bit" (pour le rendu global c'est plus compliqué de contrôler si la page est rendue comme à l'époque) et ça ne vaut pas forcément le coup, mais peut être qu'ils examineraient l'option pour gagner un peu d'espace à pas trop cher.

            Ils ne le feront sans doute pas aussi si on pense à certains cas d'usage d'archivage, comme utiliser une machine d'époque avec du logiciel d'époque (ou du logiciel d'époque dans une machine virtuelle sur une machine moderne), utiliser des formats trop récents rendrait ça impossible.

            • [^] # Re: Fonctionnalités intéressantes ?

              Posté par  . Évalué à 6 (+4/-0). Dernière modification le 15 janvier 2026 à 12:08.

              Ils ne le feront sans doute pas si ils privilégient la fidélité des données stockées "bit pour bit"

              Sachant que la conversion inverse (jpeg-xl --> jpeg) peut restituer un fichier jpeg identique binairement au fichier d'origine, stocker en jpeg-xl, c'est la même chose que stocker en jpeg… avec un gain de place non négligeable.

              (pour le rendu global c'est plus compliqué de contrôler si la page est rendue comme à l'époque)

              C'est un point pertinent : la conversion jpeg --> jpeg-xl (avec les paramètres qui permettent de faire la conversion inverse à l'identique binairement) est présumée fournir un jpeg-xl avec un rendu "quasi identique" à celui du jpeg mais le "quasi" me paraît difficile à quantifier. Cependant, au pire il suffit de reconvertir en jpeg mais si c'est le service qui le fait à la volée, ça peut représenter une charge non négligeable (à moins de ne le faire qu'à la demande).

    • [^] # Re: Fonctionnalités intéressantes ?

      Posté par  (site web personnel) . Évalué à 10 (+11/-0).

      Alors, la fonctionnalité qui tue, c'est la possibilité de recoder des images JPEG existantes en JPEG-XL sans pertes additionnelles, avec un gain de place.

      Ensuite, c'est conçu comme un format d'image beaucoup plus complet qu'AVIF. J'avais présenté tout ça dans un journal précédent.

      Mon impression, c'est qu'AVIF, comme WebP précédemment, était une solution transitoire, un truc bricolé à partir d'un format de vidéos pour répondre rapidement à un besoin. JPEG-XL pour le coup, ça a visiblement été conçu avec plus de soin pour répondre aux besoins attendus pour un successeur de JPEG à long terme.

      Bref, si JPEG-XL commence à être bien pris en charge, aucune raison de s'attarder sur AVIF.

      • [^] # Re: Fonctionnalités intéressantes ?

        Posté par  . Évalué à 4 (+3/-0).

        JPEG-XL pour le coup, ça a visiblement été conçu avec plus de soin

        Tu pourrais donner un exemple concret de fonctionnalité qui est hackée dans AVIF mais faite proprement dans JPEG-XL?

        Je n'y connais rien en formats d'image, j'ai plus d'expérience avec les formats vidéo. J'ai entendu ce genre d'affirmations à propos de VP9 (qui serait « hacké ») vis-à-vis de H.264 (qui serait plus professionnel), mais mon opinion personnelle est que H.264 inclut des fonctionnalités qui n'ont rien à faire à cette couche là (fragmentation, agrégation) et qui ne sont utiles que lorsque le transport est déficient, alors que VP9 est un format plus parsimonieux, qui délègue aux autres couches les fonctionnalités que celles-ci font déjà bien. D'où mon scepticisme.

        • [^] # Re: Fonctionnalités intéressantes ?

          Posté par  (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 15 janvier 2026 à 14:06.

          Tu pourrais donner un exemple concret de fonctionnalité qui est hackée dans AVIF mais faite proprement dans JPEG-XL?

          C'est plus un ressenti, pas un jugement sur des fonctionnalités précises. AVIF, c'est à peu de chose près le format d'image clef d'AV1. Un format vidéo, ça inclut un format d'image évidemment, mais :

          • le gros de l'effort sur le format vidéo ne porte pas uniquement sur la performance de ces images clefs ;
          • on peut s'attendre à ce qu'il manque pas mal de fonctionnalités : alpha, HDR…

          Ces fonctionnalités ont été ajoutées bien sûr, mais comme démarche, ça me donne l'impression d'une conception à l'envers.

          Après, AVIF, honnêtement, c'est très bien. Tant que JPEG-XL n'est pas pris en charge sur les appareils qu'on a l'habitude d'utiliser. Mais dès qu'on a accès à JPEG-XL, autant l'utiliser, c'est juste mieux.

    • [^] # Re: Fonctionnalités intéressantes ?

      Posté par  . Évalué à 4 (+2/-0).

      Y'a un très bon tableau récapitulatif ici: https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg#hopes_and_strategies

      • [^] # Re: Fonctionnalités intéressantes ?

        Posté par  . Évalué à 3 (+1/-0).

        En effet, même si attention : Cloudinary emploie (employait ?) Jon Sneyers, qui est un co-créateur de JPEG-XL.

        Il faut toujours lire avec ça en tête. Ceci étant dit, des employés de Google ont également travaillé sur JPEG-XL.

  • # Bench rapide

    Posté par  . Évalué à 0 (+1/-2).

    J'ai testé rapidement sur un lot d'une dizaine d'image avec 5 répétitions (pour les timings)

    J'ai choisis arbitrairement 80% (pas de lossless).

    Format     Size (KB) Time Mean (ms) Time SD (ms)

    WebP         668,24         788,39        11,7
JPEG XL      849,19        1137,00        47,8
AVIF         853,96        1331,03         7,8
JPEG        1313,43         224,67         4,3
JPEG 2000   9082,30        1547,75        13,7
PNG        12059,78        8194,72        39,1
TIFF (LZW) 13315,44         424,72         9,9

    En terme de temps de compression, le JPEG XL n'est pas beaucoup meilleur que AVIF (mais dispose d'autres avantages). On reste loin du jpeg. Le grand perdant est le PNG, et pour moi, le gagnant est le WebP sur mon expérimentation rapide.

    Quality Tier Format         Size (KB) Time (ms) Space Saved % Comp. Ratio

    Low          AVIF              446,06      1719 92.74%        1 : 13.77
Low          JPEG XL           554,41      3367 90.98%        1 : 11.08
Low          WebP              580,37      1111 90.55%        1 : 10.59
Medium       WebP              778,97      1180 87.32%        1 : 7.89
Medium       JPEG XL           940,17      1897 84.7%         1 : 6.54
Medium       AVIF             1007,51      1755 83.6%         1 : 6.1
Low          JPEG (Legacy)    1026,71       334 83.29%        1 : 5.98
Low          HEIC             1026,71       360 83.29%        1 : 5.98
Medium       HEIC             1582,46       350 74.24%        1 : 3.88
Medium       JPEG (Legacy)    1582,46       343 74.24%        1 : 3.88
High         WebP              1772,9      1348 71.14%        1 : 3.47
High         JPEG XL          1977,49      1950 67.81%        1 : 3.11
High         AVIF             2535,81      2165 58.73%        1 : 2.42
High         HEIC             2916,23       375 52.54%        1 : 2.11
High         JPEG (Legacy)    2916,23       359 52.54%        1 : 2.11
Low          JPEG 2000         5812,4      2408 5.4%          1 : 1.06
High         TIFF (LZW)      20478,13       660 -233.3%       1 : 0.3
Medium       TIFF (LZW)      20478,13       663 -233.3%       1 : 0.3
Low          TIFF (LZW)      20478,13       658 -233.3%       1 : 0.3
Low          PNG (Lossless)  19195,24      3178 -212.42%      1 : 0.32
Medium       PNG (Lossless)  18764,05      6755 -205.4%       1 : 0.33
High         PNG (Lossless)   18418,3     20255 -199.78%      1 : 0.33
High         JPEG 2000       13960,85      2423 -127.23%      1 : 0.44
Medium       JPEG 2000       13808,84      2416 -124.75%      1 : 0.44

    Ici, j'ai High:90%, Medium:75% et Low:50%.

    • [^] # Re: Bench rapide

      Posté par  . Évalué à 2 (+0/-0). Dernière modification le 16 janvier 2026 à 11:54.

      message supprimé

    • [^] # Re: Bench rapide

      Posté par  . Évalué à 3 (+1/-0).

      Une version plus complète : https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

      Attention, encore une fois, c'est fait par les promoteurs de JPEG-XL. Mais j'ai pas mieux à proposer.

      • [^] # Re: Bench rapide

        Posté par  . Évalué à 1 (+0/-0).

        Le site proposé donne des résultats de 2024. J'ai voulu refaire mes propres mesures pour mesurer l'évolution, et vous la partager.

        Je ne comprend pas vraiment mon -1, sans doute un manque d'explication du protocole, qui se fait sur des images plus grande (20mpx), ou/et une version de librairie plus récente (libjxl 0.11.1).

        De mon coté, c'était plus une indication (pour donner une information qui m'a surpris, je pensais qu'il y avait un vrai gaps entre avif et jpegXl en terme de rapidité, et que webp ne jouait pas dans la même catégorie alors que si).

        J'éviterais à l'avenir, en effet, le post parlait de l'intégration du format, pas du format lui même. Mea culpa.

        • [^] # Re: Bench rapide

          Posté par  (site web personnel) . Évalué à 2 (+0/-0).

          sans doute un manque d'explication du protocole, qui se fait sur des images plus grande (20mpx), ou/et une version de librairie plus récente (libjxl 0.11.1).

          la non reproductibilité surtout…
          on n'a ni tes images, ni le script (avec les options) de fournis, donc bon un tableau comme le tien ne donne que peu d'indications et tes conclusions sont peu explicites sur ce que tu cherchais à montrer :/

          Note : ne commence pas à te poser des questions au bout de moins d'une 1/2 heure d'un seul -1, sinon t'es pas sorti des ronces…

        • [^] # Re: Bench rapide

          Posté par  . Évalué à 4 (+1/-0).

          j'ai pas pertinenté ni inutilé, mais sans images, c'est un peu léger, que veut dire 80% de qualité? à quel point les dégradations sont elle visible ou pas?

          est ce que 80% en jpg-XL c'est la même qualité que 80% webP? quid des autres formats? Ils ont tous généralement leur propre façon de compresser et donc les résultats finaux sont différents, juste une vue sur les perfs taille/temps processeur, c'est un peu léger comme comparaison.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Bench rapide

            Posté par  . Évalué à 4 (+2/-0). Dernière modification le 19 janvier 2026 à 10:56.

            Le niveau de compression qu'on utilise en Jpeg ou Png n'est pas vraiment pertinent en Jpeg-XL :
            En Jpeg-XL on indique une distance par rapport à l'image originale ; ça ressemble, disons intuitivement, au niveau de pertes du Jpeg (devenu niveau de compression en langage courant). Mais dans pas mal de cas on peut descendre le curseur très bas en Jpeg-XL sans altérations perceptible (jusqu'à 30 dans mon cas). Autrement dit, alors que le curseur Jpeg est très uniforme (les pertes se voient en dessous de 70-75), il ne l'est pas en Jpeg-XL.
            D'autre part ces niveaux ne sont pas comparables : 80% en Jpeg n'est pas 80 en Jpeg-XL.

            Donc pour comparer les formats au même niveau (de "compression") il faut utiliser des outils d'analyse d'image et des vrais yeux humains. C'est ce qu'a fait Jon Sneyer dans son article cité plus haut.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.