Comparaison de codecs d'images

Cet article est une traduction d'un article de Gianni Rosato dont l'original est ici

Pourquoi?

Pour commencer, je suis un fan du format d'image AVIF depuis que j'en ai entendu parler, peu de temps après avoir commencé à me renseigner sur le codec vidéo AV1 en 2020. J'ai pensé que le fait qu'il soit soutenu par l'Alliance for Open Media, qu'il soit le successeur naturel de WebP et qu'il soit basé sur un codec vidéo assez puissant qui gagnait rapidement en popularité était idéal pour que les utilisateurs et les organisations comprennent facilement ce que la technologie représentait, d'où elle venait et quels avantages elle offrait par rapport au roi de l'image avec perte existant, JPEG. Les bons codecs sont des codecs à code source ouvert, et le fait qu'AVIF soit à code source ouvert m'a semblé très important. En outre, il est déjà largement pris en charge au moment de la rédaction du présent document. Lorsque j'en ai entendu parler pour la première fois, j'ai pensé sans équivoque qu'AVIF serait l'avenir des images sur le web. Je ne pense pas que j'avais tout à fait tort, mais je n'avais pas encore entendu parler de JPEG-XL.

JPEG-XL (JXL en abrégé) est un codec d'image créé par le comité JPEG (oui, le comité JPEG). Au départ, je n'avais pas pensé à ce codec parce que l'efficacité de la compression était "la même que celle d'AVIF", et je l'ai donc en quelque sorte ignoré, comme l'ont fait et continuent de le faire, j'en suis sûr, de nombreuses personnes mal informées. En faisant des recherches plus approfondies, j'ai changé d'avis et je me suis retrouvé profondément investi dans l'avenir du JXL.

Les caractéristiques fascinantes de JXL comprennent la transformée en cosinus discrète à taille de bloc variable très efficace (qui est supérieure à la DCT de JPEG), l'utilisation de l'espace colorimétrique XYB qui représente plus précisément la réponse des cônes de nos yeux aux différentes longueurs d'onde de la lumière, et un mode "modulaire" pour un codage efficace sans perte ou presque sans perte. Il est également utilisé lors du codage d'images JPEG-XL avec perte, mais je ne connais pas grand-chose à ce sujet et je ne prétendrai pas le savoir. Actuellement, le codeur de référence prend également en charge la détection de patchs, la synthèse de bruit et, à terme, il prendra probablement en charge la détection de splines, étant donné qu'elle est présente dans la spécification du codec. JPEG-XL prend également en charge le transcodage JPEG sans perte qui réduit la taille des fichiers JPEG, ce qui, à mon avis, change la donne. À elle seule, elle pourrait constituer un codec révolutionnaire. Le décodage progressif est également une caractéristique remarquable de JPEG-XL, et j'ai trouvé cet article très intéressant à ce sujet.

D'autres articles et ressources JXL intéressants :

https://www.roboleary.net/webdev/2023/03/06/next-web-image-format-not-jpegxl.html

https://tonisagrista.com/blog/2023/jpegxl-vs-avif

https://cloudfour.com/thinks/on-container-queries-responsive-images-and-jpeg-xl

https://motionmill.com/2023/02/google-stopt-jpex-xl-gebruiken

https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

https://cloudinary.com/blog/the-case-for-jpeg-xl

Il convient également de noter Jon Sneyers(co-auteur de la spécification JPEG XL) et d'autres développeurs remarquables qui sont extrêmement actifs au sein de la communauté et apprécient les commentaires des personnes passionnées par leur travail. Cela ne devrait pas être aussi unique que cela l'est, mais il est incroyablement précieux de se faire entendre aussi facilement et fréquemment par des développeurs qui s'intéressent vraiment à la question.Je félicite Sneyers et les autres développeurs de JXL pour cela.

Bref, TL;DR : JXL a beaucoup plus à offrir qu'une bonne compression. Mais j'aimerais toujours savoir comment il se situe par rapport aux autres formats d'image en ce qui concerne la compression avec et sans perte.

Méthodologie (corpus photographique)

Afin de produire un test impartial pour déterminer la qualité de JPEG-XL par rapport à mes besoins, j'ai pris 27 photos (principalement des paysages/architectures) autour de ma ville natale au bord de la mer en utilisant mon Sony a5000 à 20. 1mp, je les ai éditées dans Darktable, je les ai exportées en PNG sRGB 16 bits (AdobeRGB a eu quelques problèmes), et enfin j'ai exécuté un script écrit par mon ami RootAtCali (jetez un coup d'oeil à son site) pour déterminer les scores SSIMULACRA2 de chaque format d'image pour chaque niveau de qualité disponible via l'option de codage avec perte du format.

Je ne manquerai pas de mettre à disposition mes sources lossy via un edit de ce post, et elles seront liées en haut de page. En attendant, voici une autre page avec des photos JXL en pleine résolution encodées à -d 1.0. Les images sont sous CC-BY-SA 4.0.

Ces tests ont été effectués en utilisant la métrique de qualité visuelle SSIMULACRA2 via ssimulacra2_rs. Cette métrique est conçue pour modéliser la vision humaine bien mieux que VMAF, SSIM, PSNR, et d'autres alternatives moins efficaces.

Voir le readme sur Github :

Returns a score in range -inf..100, which correlates to subjective visual quality scores as follows:

   30 = low quality. This corresponds to the p10 worst output of mozjpeg -quality 30.
   50 = medium quality. This corresponds to the average output of cjxl -q 40 or mozjpeg -quality 40, or the p10 output of cjxl -q 50 or mozjpeg -quality 60.
   70 = high quality. This corresponds to the average output of cjxl -q 65 or mozjpeg -quality 70, p10 output of cjxl -q 75 or mozjpeg -quality 80.
   90 = very high quality. Likely impossible to distinguish from the original when viewed at 1:1 from a normal viewing distance. This corresponds to the average output of mozjpeg -quality 95 or the p10 output of cjxl -q 95.

En raison du manque de pertinence des résultats négatifs de SSIMULACRA2, j'ai arrêté l'axe vertical du ou des graphiques à 0.

Pour le contexte, voici un aperçu des formats d'image testés :

JPEG, le champion en titre, est utilisé depuis des décennies. Prise en charge du décodage progressif
WebP, basé sur VP8, un codec vidéo open-source.
JPEG-XL, le successeur désigné de JPEG. Conçu par le comité JPEG.
AVIF, basé sur AV1, un codec vidéo open-source moderne.

Voici un tableau utile fourni par Cloudinary.

Les codecs JPEG 2000 (J2K) et HEIC sont notablement absents. Étant donné que JXL est le successeur de J2K et que J2K n'a jamais été adopté à grande échelle, je ne suis pas sûr qu'il soit utile à qui que ce soit de l'inclure. HEIC est exclu parce qu'il est nul, et aussi parce qu'il n'est pas libre de droits.

Voici les encodeurs testés pour chaque format :

JPEG via l'encodeur mozjpeg
JPEG via l'encodeur mozjpeg, réglé pour MS-SSIM, en utilisant la table de quantification et le codage arithmétique 'réglé pour MS-SSIM sur l'ensemble d'images Kodak'.
JPEG via l'insaisissable et mystérieux encodeur jpegli (plus d'informations à ce sujet ultérieurement)
WebP via cwebp
JPEG-XL via l'implémentation de l'encodeur de référence libjxl, cjxl
AVIF via aom-av1-lavish, adapté à SSIM

Voici les paramètres de l'encodeur que j'ai utilisés, ainsi que la version de l'encodeur (dans le même ordre que ci-dessus)

cjpeg -q [quality] "input" > "output.jpg" | mozjpeg version 4.1.1 (build 20230217)

cjpeg -q [quality] -quant-table 2 -tune-ms-ssim -arithmetic "input" > "output.jpg" | mozjpeg version 4.1.1 (build 20230217)

benchmark_xl --input=[input] --codec=jpeg:enc-jpegli:rgb:q[quality] --save_compressed --output_dir=[outdir] | cjxl v0.9.0 c4927fbf

cwebp -m 6 -q [quality] "input" -o [output.webp] | 1.3.0 libsharpyuv: 0.2.0

cjxl "input" "output.jxl" -q [quality] -e 7 --brotli_effort 11 | cjxl v0.9.0 c4927fbf

avifenc -c aom -s 6 -j 16 -d 10 -y 444 --min 1 --max 63 -a end-usage=q -a cq-level=[quality] -a tune=ssim "input" "output.avif" | AOMedia Project AV1 Encoder Psy v3.6.0 (default)

WebP est à l'effort maximum et les encodeurs JPEG ont été laissés de côté en termes d'effort. cjxl est à l'effort 7 (le défaut interne, donc je n'ai pas vraiment eu besoin de le spécifier, et brotli_effort est seulement pour le lossless iirc), et nous encodons avif à la vitesse 6 parce que c'est la meilleure corrélation avec la vitesse par défaut de JXL (et c'est aussi la vitesse par défaut de rav1e en interne, bien que nous n'utilisions pas rav1e). Aviator, basé sur SVT-AV1, utilise consciemment par défaut la vitesse 6 pour l'encodage vidéo AV1, tout comme rAV1ator basé sur rav1e.

L'analyse comparative avec cet ensemble de données d'images nous a donné un total d'un peu moins de 18 000 points de données avant le calcul de la moyenne. Pour le graphique, j'ai calculé la moyenne arithmétique des scores bpp et SSIMULACRA2 pour chaque étape de qualité et pour chaque encodeur.

Voici les résultats : résutats

Maintenant, retenez votre souffle, les conclusions viennent à la fin !

Méthodologie (non photographique)

Il s'agit d'un test plus court avec moins de choses à faire, mais toujours intéressant et qui mérite d'être évoqué. J'utilise cette image pour tester l'encodage non photographique en utilisant les mêmes paramètres que ci-dessus. Voici les résultats: résutats

Bien qu'il ne s'agisse que d'une seule image, j'ai constaté qu'AVIF prenait une avance considérable sur toutes les images non photographiques que j'ai testées.

Sans perte ? Animation ?

Restez à l'écoute ! AVIF et JXL (ainsi que WebP) prennent en charge l'animation, mais j'aimerais aborder ce sujet dans un autre article. J'aimerais en savoir plus sur le fonctionnement d'AVIF et de JXL en ce qui concerne le codage d'images sans perte avant de m'attaquer à un test de ce type.

Conclusion

Où JPEG-XL gagne-t-il ?

Il est clair pour moi que JPEG-XL sera mon choix pour l'exportation de mes photos d'amateur. Il est exceptionnellement performant à un niveau de qualité plus élevé, surpassant AVIF et les autres par une marge significative. AVIF est plus fort lorsque la qualité diminue, mais AVIF est encore plus affaibli par le fait que l'encodage utilisant plus de threads nuit généralement à l'efficacité et que l'encodage d'une image AVIF est généralement plus lent que l'encodage d'une image JXL. Quant à la pléthore d'autres fonctionnalités offertes par JXL, AVIF peut à peine rivaliser. AVIF est également handicapé par ses dimensions maximales d'image inférieures à celles des codecs concurrents.

Où AVIF gagne-t-il ?

AVIF gagne en qualité faible à moyenne (voire faible-moyenne). C'est une bonne chose pour la publication de contenu sur le web, car les images n'ont pas toujours besoin d'être de haute fidélité ou de conserver un grand nombre de détails à haute fréquence pour rester attrayantes ; il peut être plus souhaitable d'avoir un aspect agréable et de ressembler à la source. Bien qu'AVIF ne dispose pas du décodage progressif, son efficacité de codage supérieure à une qualité inférieure compense quelque peu cette lacune à mon avis. AVIF est également le vainqueur pour notre image non photographique, et si vous pensez que cette image n'est pas un cas particulier, elle ouvre des perspectives intéressantes pour le partage de l'art numérique, car JXL n'a pas d'encodeur disponible avec la détection de spline pour rivaliser avec lui à l'heure actuelle. Basé sur le codec vidéo AV1, AVIF serait également plus facile à mettre en œuvre; l'adoption généralisée de ce codec lui vaut déjà un certain succès sur le Web.

Qu'en est-il des autres ?

WebP n'est pas très bon à mon avis, il s'effondre à plus haute qualité et est battu à plate couture par AVIF à plus basse qualité. JPEG a clairement encore du potentiel même des années plus tard, et le réglage MS-SSIM semble faire quelques faveurs à l'encodeur avec l'ensemble de données photographiques. L'encodeur jpegli emprunte certaines des techniques de codage sophistiquées de JXL pour améliorer encore la qualité JPEG, en particulier à une qualité supérieure. Je n'ai même pas testé jpegli avec l'espace colorimétrique supérieur XYB (car cela s'est avéré difficile à faire), ce qui, à mes yeux, apporte à jpegli une amélioration de qualité encore plus importante par rapport aux encodeurs jpeg standard. Il y a un fil de discussion sympa sur Twitter à ce sujet. Selon Jyrki Alakuijala,

"jpegli prend en charge plus de 8 bits par canal (environ 10,5 bits) et peut codifier la dynamique HDR (HLG/PQ/XYB/etc.) dans l'ancien format '8 bits'".

Cela semble extrêmement prometteur.

À retenir

Je veux un web où les deux formats AVIF et JPEG-XL peuvent exister, et où les développeurs décident quel format utiliser en fonction de ses mérites. L'équipe Chromium de Google a rejeté le support JXL pour Chrome, et Mozilla reste "neutre" sur JXL, gardant un drapeau dans Firefox Nightly pour permettre un support partiel.

L'équipe Chromium ne devrait pas avoir l'autorité absolue de rejeter des normes potentielles comme celle-ci, car il semble qu'elle soit le seul décideur dans ce domaine et que tous les autres doivent suivre son exemple. À mon avis, JPEG-XL et AVIF ont des atouts fondamentalement différents qui les destinent à des cas d'utilisation différents. Si l'on considère que JXL a été approuvé par Facebook, Adobe, Intel et la Video Electronics Standards Association, The Guardian, Flickr et SmugMug, Shopify, la Krita Foundation, Serif Ltd, Gaia Sky, et bien d'autres encore, le marché est certainement intéressé. Mon optimiste actuel est que JXL décolle en dehors du web parmi les professionnels travaillant avec des outils comme la suite Adobe ou des alternatives, et que

les fabricants d'appareils photo,
les équipementiers de smartphones,
et d'autres,

le remarquent et commencent à penser à JXL plus sérieusement. Les avantages ne peuvent être ignorés, et c'est (à mon avis) le seul format d'image qui est en tous points supérieur au JPEG et qui offre un avenir concret aux nombreux JPEG existants sur le Web et au-delà.

Bien qu'il s'agisse d'un test non scientifique, n'hésitez pas à partager cet article si vous souhaitez que JPEG-XL reçoive plus d'attention pour ses mérites. AVIF est déjà largement soutenu, je n'ai pas besoin de me battre pour lui ; JPEG-XL a encore une guerre à gagner, et j'aimerais que tous ceux qui veulent de meilleures images et un meilleur Web soient du côté de JXL et d'AVIF, et comprennent que JPEG-XL a besoin de notre aide en tant qu'utilisateurs pour être adopté à grande échelle. Voici ce que je recommande de faire dès maintenant :

Vous utilisez Chrome ou un autre navigateur basé sur Chromium ?

Pensez à passer à Thorium. Il est disponible sur presque toutes les plateformes, y compris Windows, Linux, macOS et Android, et prend entièrement en charge JXL. Il se synchronise avec votre compte Google, tout comme Chrome. Il est également plus rapide.

Vous utilisez Firefox ?

Ce n'est pas un mauvais choix. Si votre flux de travail le permet, passer à Firefox Nightly pour une navigation occasionnelle et activer le drapeau JXL pour un support partiel de JXL en recherchant 'jxl' dans about:config n'est pas une mauvaise option. Je suis moi-même attaché à Firefox, et l'utilisation du drapeau sur mon téléphone fonctionne très bien pour toutes les images qui n'utilisent pas de canal alpha ou de HDR.

Si vous souhaitez jeter un coup d'œil à quelques belles images JXL, vous pouvez vous rendre ici. Vous pouvez tester la prise en charge de JXL par votre navigateur ici.

N'oubliez pas que le web est peut-être la dernière plateforme sans propriétaire, et nous devons faire en sorte qu'il en soit ainsi.

Joindre l'auteur de l'article.

Gianni Rosato

Dernière mise à jour: May 11, 2023
Créé: April 26, 2023