veilletech.fr
14 sept. Feed du jour
#05 WEB Article

JPEG XL : les chiffres refroidissent la fête

Un format d'image se choisit sur vos images, pas sur celles de la démo.

Alors que le décodeur Rust jxl-rs entre dans Chrome et Firefox, une analyse chiffrée détaille quatre faiblesses structurelles du codec JPEG XL : pas de prédiction directionnelle, aucun filtre de déblocage, un espace XYB qui quantifie trop le canal bleu, des patches moins efficaces que l'Intra Block Copy d'AV1. L'auteur montre aussi qu'un fichier de 1 918 octets peut monopoliser 17 secondes de CPU au décodage.

3 min de lectureintermédiaire
Partager
Sommaire5 sections
  1. Ce qui se passe
  2. Ce que disent les chiffres
  3. Le point qui dépasse le débat de codecs
  4. Ce que ça change
  5. À retenir

Ce qui se passe

JPEG XL avait été rejeté de Chrome en 2023. Depuis peu, un décodeur écrit en Rust, jxl-rs, se fraie un chemin dans Firefox et Chrome — la mémoire de la faille WebP de 2023 (CVE-2023-4863) n'y est pas étrangère. Safari, lui, supporte le format nativement depuis longtemps.

Gianni Rosato, qui travaille sur la compression d'images, publie l'argumentaire inverse. Sa thèse n'est pas que JPEG XL est mauvais — il le décrit comme « a definitive upgrade over JPEG » — mais qu'il n'est pas le bon codec pour le Web.

Ce que disent les chiffres

Quatre reproches structurels au codec :

  1. Pas de modes de prédiction directionnelle. Les blocs VarDCT (de 2×2 à 256×256) passent directement en fréquentiel, sans prédiction soustraite au préalable comme le font WebP et AV1. Conséquence : une préservation des contours plus faible.
  2. Aucun filtre de déblocage. gaborish et l'EPF (filtre préservant les bords) sont proposés comme équivalents partiels — ils correspondent plutôt au loop restoration et au CDEF d'AV1, et ne remplacent pas un vrai DLF. Le bruit de moustique subsiste.
  3. L'espace perceptuel XYB déçoit. libjxl quantifie agressivement le canal B, ce qui dégrade la préservation des couleurs ; les nouveaux encodeurs doivent explicitement défaire ce choix.
  4. Les images non photographiques sont mal servies : les patches sont plus difficiles à exploiter que l'Intra Block Copy d'AV1.

Sur des encodages calibrés à taille égale depuis la même source :

Format Taille
JPEG 2 478 828 octets
JPEG XL 2 599 428 octets
AVIF 2 649 949 octets
WebP 2 693 794 octets

WebP pèse plus de 90 ko de plus que JPEG XL et décode pourtant plus de 10 fois plus vite que jxl-rs (mesuré avec wpd). Sur le décodage progressif, la démo officielle du format montre AVIF affichant une image utilisable dès 2 à 3 % du fichier, bien avant JXL. Quant à la recompression JPEG — les fameux 20 % gagnés sans perte —, elle coûte environ 33 % de temps de décodage en plus.

Le point qui dépasse le débat de codecs

L'expressivité du format permet de fabriquer des images pathologiques. L'auteur publie un fichier de 1 918 octets qui calcule les nombres premiers jusqu'à 33 599 et consomme 17,43 secondes de temps utilisateur à décoder sur un M5 Pro, avec le décodeur Rust — celui qui arrive dans les navigateurs.

Autrement dit : quelques dizaines de ces fichiers sur une page suffisent à faire ramer un appareil modeste, et Safari les décode déjà nativement. Si vous acceptez des images téléversées par vos utilisateurs, c'est un vecteur de déni de service à considérer avant d'activer le format.

Ce que ça change

L'avantage réel de JPEG XL reste le sans perte, à environ 11,9 % sous le WebP sans perte — mais mesuré sur un corpus peu représentatif du Web (photos de 157 MP, illustrations de 10 MP, livres de 27 MP), pour un usage marginal en volume.

À retenir

Le support navigateur qui arrive n'est pas un verdict de qualité. Avant de migrer un pipeline AVIF ou WebP qui fonctionne, encodez vos images et mesurez. Et posez une limite de temps de décodage si vous acceptez du JXL venu de l'extérieur.