Première sortie du décodeur JPEG-XL en Rust

Posté par  . Édité par palm123 et Ysabeau 🧶. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
31
23
sept.
2025
Internet

En 2022, le format JPEG-XL (JXL) a fait naitre beaucoup d’espoirs sur Internet : un taux de compression et une qualité très supérieurs à tout ce qui existe dans nos navigateurs web, plus une rétro-compatibilité avec JPEG. Les décodeurs sont arrivés dans Chromium, Firefox et Safari, on était tout excité, et puis… Google supprime le décodeur. Mozilla le cantonne à la version développeurs, derrière une option. Apple le… tiens non, Apple le garde et le porte même sur iOS.
Pendant que ça hurle et tempête Mozilla s’explique : l’implémentation actuelle c’est 100 000 lignes de C++ probablement dangereuses, tandis que du Rust plus compact serait avantageux.
Célébrons la rentrée 2025, les développeurs du labo Google (principal sponsor de JXL) nous proposent de tester une première version habillée de rouille ! Ne déshabillez pas la source trop vite, appréciez les préliminaires lents, c’est une fragile version 0.1.1.

Aller plus loin

  • # Google ?

    Posté par  . Évalué à 3 (+1/-0). Dernière modification le 23 septembre 2025 à 16:31.

    Je ne suis pas sûr d'avoir bien compris : c'est Google qui propose cette pré-version en Rust ? Du coup, est-ce que ça veut dire que le jpeg-xl revient dans la danse ou bien c'est juste une initiative d'un labo qui ne prouve rien quant à aucun changement de politique de Google pour la prise en charge dans Chrome ?

    • [^] # Re: Google ?

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

      coquille : quant à aucun quant à un

    • [^] # Re: Google ?

      Posté par  . Évalué à 8 (+8/-0). Dernière modification le 23 septembre 2025 à 16:59.

      Il s'avère que le labo de recherche Google de Zurich est co-auteur (majoritaire) de la spec et de la librairie de référence en C++.
      Mais ça ne veut pas dire qu'ils s'entendent bien avec la team Chrome (euphémisme)

      La team Zurich maintient des patchs prêts à l'emploi pour la team Chrome depuis des lustres, mais elle refuse de les prendre.
      Et là, ils ont lancé le chantier de refaire un décodeur en rust pour Firefox qui a promis de l'intégrer dès qu'il aura atteint une certaine maturité.

      D'une pierre deux coups, vous pouvez glaner qq infos ici, et voter pour que le JPEG xl soit considéré à la prochaine session de l'interop https://github.com/web-platform-tests/interop/issues/994#issuecomment-3318764978

    • [^] # Re: Google ?

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

      C'est le labo de recherche sur les images en Suisse qui fait ce code. Le labo est indépendant de Chrome (qui n'est pas un projet de recherche), m'enfin la politique de Google c'est quand même d'utiliser ce que ses ingénieurs produisent.

  • # Dubitatif par rapport à avif

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

    Bonjour,

    Je ne suis pas un expert en la matière, mais l’année dernière j’avais testé différent formats d’images modernes, comparaison sur quelques types d’images et photos, et globalement j’ai trouvé le format avif plus performant que jxl.

    Alors peut-être que mes librairies dispo sur Debian 12 étaient mieux optimisé avec avif qui est légèrement antérieur, mais le doute s’installe.

    Axel.

    • [^] # Re: Dubitatif par rapport à avif

      Posté par  . Évalué à 2 (+0/-0). Dernière modification le 27 septembre 2025 à 11:38.

      Sur les quelques gros tests que j'ai vu JXL compresse 25% plus qu'Avif à qualité égale. Bien sur ça varie selon les images. Ces tests utilisent un panel d'images représentatives pour obtenir une note fiable. Mais sur des images particulières Avif peut être meilleur.
      Il faut voir aussi comment tu utilises Jxl : il n'y a pas de degré de compression comme dans Jpeg, mais une échelle de distance à la source. Il faut s'y habituer pour bien l'utiliser (des fois on peut descendre très très bas)

      Si j'ai bonne mémoire, l'article de Jon Sneyers (premier lien) indique les différences Avif/Jxl.

    • [^] # Re: Dubitatif par rapport à avif

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

      Sur le lossy, ça peut se valoir. On va dire qu'aux hautes et très hautes qualités, jpegxl est plus fidèle, aux moyennes et basses qualités, l'avif est plus flatteur 😅
      Sur le lossless, le jpegxl gagne à tous les coups (il perd seulement sur certaines images "synthétiques" face au webp, pour le moment)

      Mais le gros avantage ultime du jpegxl, c'est de pouvoir traduire sans dégradation un JPEG existant (et gagner 20% au passage !)

      Bref, le jpegxl, si supporté. Pourrait remplacer demain tous les jpg et tous les png existants (via la conversion sans perte)

      • [^] # Re: Dubitatif par rapport à avif

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

        Je ne pense pas que JpegXL puisse remplacer PNG. Typiquement, tu peux stocker des images en 8bits (+ palette) en PNG ce que tu ne peux pas faire en JpegXL. Tu as une certaine liberté sur ce que tu peux mettre dans un PNG (tu mets les chunks que tu veux, ils sont ignorés par les clients), ce que, à ma connaissance, n'est pas possible en JpegXL.

        Bref, le JPEGXL n'inclus pas la totalité du featureset du PNG (par choix, la majorité des fonctions sont là).

        Il est aussi, beaucoup, beaucoup plus gros que le PNG (qui est plus gros que le JPEG) à implémenter. Donc plus difficile à mettre sur un système embarqué (IoT).

        À voir donc dans le temps, il y a bien un développeur fou qui va faire une implémentation en 1000 lignes de code.

        • [^] # Re: Dubitatif par rapport à avif

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

          Y a totalement des palettes en JPEG XL lossless.
          Après, pour les chunks supplémentaires, le format utilise le ISO BMFF comme container, il offre donc toute latitude pour les embarquer.

          • [^] # Re: Dubitatif par rapport à avif

            Posté par  . Évalué à 7 (+6/-0). Dernière modification le 25 septembre 2025 à 10:05.

            Non, pas comme PNG. Il y a une transformation en palette (en interne) dans l'encodeur, c'est à dire que s'il voit que l'image en entrée n'utilise qu'une quantité limité de combinaison, il peut choisir de coder en palette, mais ce n'est qu'un encodage, ce n'est pas décrit dans le fichier généré et tu ne peux pas définir cette palette (vu que c'est interne à l'encodeur). Il n'y a rien qui te garantisse un 1:1 de la palette PNG vers la table de composantes internes à JPEGXL.

            Tu peux avoir 256 couleurs dans ta palette PNG dont seulement 4 utilisées dans l'image. Après conversion JXL, tu n'auras que 4 "couleurs" dans ta palette, les autres couleurs seront perdues (et l'ordre sera aléatoire de toute façon).

            Cela peut paraître être du détail, mais lorsque tu fais du pixel art, typiquement pour un jeu, tu veux que l'ensemble des ressources utilisent quasiment tous la même palette.

            Ou, si tu enregistres des images thermiques 16 bits, la palette indique la température des pixels observés ou pas, ce qui n'est pas linéaire avec la valeur du pixel, tu ne veux donc pas la perdre.
            etc…

            Bref, JXL n'est pas LE format qui les remplace tous, peut être pour la grosse majorité des applications, mais pas toutes.

        • [^] # Re: Dubitatif par rapport à avif

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

          Je ne pense pas que JpegXL puisse remplacer PNG. Typiquement, tu peux stocker des images en 8bits (+ palette) en PNG ce que tu ne peux pas faire en JpegXL.

          Même si ce n'était pas possible en JXL, quel intérêt ? Je veux dire, une image contenant des couleurs représentables sur 8 bits peut sans problème être codée sur 24 bits, puis compressée en JXL. Si le résultat prend plus de place que le PNG, je comprends que ce soit un inconvénient, mais si JXL compresse cela avec une efficacité au moins égale à celle de PNG, aucun problème.

          • [^] # Re: Dubitatif par rapport à avif

            Posté par  (site web personnel, Mastodon) . Évalué à 6 (+5/-0).

            Même si ce n'était pas possible en JXL, quel intérêt ? Je veux dire, une image contenant des couleurs représentables sur 8 bits peut sans problème être codée sur 24 bits, puis compressée en JXL.

            En procédant de cette manière, tu peux certes retrouver l'image d'origine, mais tu perds l'indépendance valeur/couleur, donc tu perds de l'information.

            Certaines images à palette ne contiennent que des valeurs numériques, et c'est le changement de palette qui permet tel ou tel type de visualisation, par exemple sur les images d'IRM ou de météo.

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.