JPEG XL et le front de Pareto
(cloudinary.com)- Le goulot d’étranglement de l’encodage JPEG XL, qui traitait auparavant les grandes images en une seule fois, est réduit par libjxl 0.10 grâce à une API d’encodage en streaming, avec de fortes améliorations de l’usage mémoire et de la vitesse en compression sans perte
- L’encodage sans perte de l’image nocturne de la Terre de la NASA en 13500×6750 passe d’environ 8 Go de RAM et plus de 2 minutes avec libjxl 0.9 à 0,7 Go de RAM, 30 secondes sur un seul thread et 5 secondes sur 8 threads avec libjxl 0.10
- Comparer les méthodes de compression par la seule taille de fichier ne suffit pas : le front de Pareto, qui considère ensemble la vitesse d’encodage et la densité de compression, devient le critère qui détermine les meilleurs réglages selon le budget temps
- Pour la compression avec perte, il faut examiner en même temps le taux de compression, la vitesse et la qualité d’image ; dans la plage SSIMULACRA2 60 à 90, JPEG XL se montre particulièrement solide dans la zone haute qualité à quasi sans perte visuelle
- De nouveaux encodeurs JPEG comme jpegli restent compétitifs dans les plages d’encodage très rapides, mais JPEG XL s’impose comme un choix majeur pour la compression sans perte comme avec perte sur une large plage de vitesses
Principaux changements de libjxl 0.10
- libjxl 0.10 est une nouvelle version de l’implémentation de référence de JPEG XL, et son plus grand changement est l’implémentation complète de l’API d’encodage en streaming
- Cette API encode les grandes images par chunks au lieu de les traiter d’un seul bloc
- elle réduit la pression sur la RAM liée au chargement de l’image entière en mémoire
- elle améliore aussi la vitesse d’encodage
- l’effet est particulièrement marqué pour la compression sans perte des grandes images
Mémoire et temps réduits en compression sans perte
- Avant libjxl 0.10, l’encodage JPEG XL sans perte pouvait poser problème à cause d’une forte consommation mémoire et de temps de traitement élevés
- L’image d’exemple est l’image nocturne de la Terre de la NASA en 13500×6750
- le fichier TIFF fait 64 Mo
- sa taille avant compression est de 273 Mo
- Résultat de la compression de cette image avec le réglage effort par défaut e7 :
- libjxl 0.9 utilisait environ 8 Go de RAM, prenait plus de 2 minutes, et produisait un fichier de 33,7 Mo
- sur un seul thread, il fallait 2 min 40 s ; sur 8 threads, 2 min 6 s, donc le gain lié à l’augmentation du nombre de threads était limité
- l’environnement de mesure était un MacBook Pro de novembre 2023 équipé d’un CPU Apple M3 Pro 12 cœurs et de 36 Go de RAM
- Avec libjxl 0.10, la compression de la même image ne demande plus que 0,7 Go de RAM
- 30 secondes sur un seul thread
- 5 secondes sur 8 threads
- le fichier obtenu fait 33,2 Mo
- Quand on augmente la valeur effort, le taux de compression s’améliore, mais le gain diminue progressivement au regard du temps CPU supplémentaire
- en passant de e1 à e2, utiliser 1 seconde au lieu de 0,1 seconde permettait de gagner 22 Mo
- en passant de e2 à e7, utiliser 5 secondes au lieu de 1 seconde permettait de gagner encore 11 Mo
- en passant de e7 à e9, il fallait attendre presque 2 minutes pour ne gagner qu’1 Mo supplémentaire
Compromis pratique des réglages effort
- Les réglages de compression relèvent d’un compromis entre temps et taille de fichier
- Dans un workflow de création où l’on enregistre localement pendant l’édition d’image, une compression forte n’est pas forcément nécessaire, et un encodage avec un effort faible peut être rationnel
- Dans des scénarios de diffusion un-à-plusieurs ou d’archivage de long terme, il peut être intéressant de dépenser davantage de temps CPU pour économiser quelques Mo
Comparer les méthodes de compression avec le front de Pareto
- Si l’on compare les techniques de compression uniquement par la taille de fichier, on risque de manquer des informations importantes pour un choix réel
-
Axes de comparaison et lecture du graphique
- les axes clés sont la densité de compression et la vitesse d’encodage
- dire qu’une méthode est Pareto-optimale signifie qu’il n’existe pas d’autre méthode offrant une densité de compression équivalente ou meilleure en moins de temps
- l’ensemble de ces méthodes Pareto-optimales forme le front de Pareto
- dans le graphique, l’axe vertical représente la vitesse d’encodage et l’axe horizontal la moyenne des bits par pixel de l’image compressée
- l’axe vertical est exprimé en mégapixels par seconde et utilise une échelle logarithmique afin de couvrir une large plage de vitesses
- avant compression, une image RGB 8 bits est à 24bpp
- plus on est haut, plus c’est rapide ; plus on est à gauche, meilleur est le taux de compression
Résultats comparatifs en compression sans perte
- Les versions précédentes de libjxl produisaient déjà des résultats Pareto-optimaux sur toute la plage de vitesses, avec des fichiers plus petits que PNG, AVIF sans perte et WebP sans perte
- libjxl 0.10 montre des résultats nettement meilleurs que les versions précédentes
- QOI n’apparaît pas sur le graphique, mais atteint 17bpp à 154Mpx/s
- le réglage effort le plus bas de libjxl compresse jusqu’à 11,5bpp à 427Mpx/s
- libjxl était donc 2,7 fois plus rapide, avec un fichier 32,5 % plus petit
Compression sans perte sur les images non photographiques
- Les photos sont difficiles à compresser sans perte à cause de leur bruit naturel, et les résultats diffèrent sur les images non photographiques
- Un test réalisé sur 41 images de mangas de styles variés, d’une taille moyenne de 7,3 mégapixels, l’a montré
- Ce type d’image se compresse jusqu’à environ 4bpp, bien mieux que les images photographiques autour de 10bpp
- L’AVIF sans perte n’était pas utile sur ce type d’image
- il compressait moins bien que PNG
- il atteignait une densité comparable à QOI, mais beaucoup plus lentement
- WebP sans perte affiche un très bon taux de compression sur ce type d’image
- QOI reste correct si l’on privilégie la vitesse et la simplicité, mais il est loin d’être Pareto-optimal
- un encodage JPEG XL à faible effort était 2 fois plus rapide que QOI, avec un fichier 31 % plus petit
- libjxl 0.10 s’améliore fortement par rapport à 0.9 aussi sur les images non photographiques
- effort par défaut de WebP : 4,30bpp, 2,3Mpx/s
- libjxl 0.9 effort 5 : 4,27bpp, 2,6Mpx/s
- libjxl 0.10 effort 5 : 4,25bpp, 12,2Mpx/s
- libjxl 0.10 effort 7 : 4,04bpp, 5,9Mpx/s
La compression avec perte ajoute l’axe de la qualité
- Pour la compression sans perte, il suffit d’examiner la taille compressée et la vitesse, mais la compression avec perte ajoute la qualité d’image
- Les codecs et encodeurs d’image avec perte peuvent avoir des performances différentes selon le niveau de qualité visé
- un encodeur performant en haute qualité ne l’est pas forcément en basse qualité
- l’inverse est également vrai
- Les graphiques bitrate-distortion, qui ne regardent que le taux de compression et la qualité, rendent difficile l’évaluation du compromis entre effort d’encodage et performance de compression
- Pour observer le front de Pareto en compression avec perte, il faut découper l’espace en trois dimensions compression-vitesse-qualité à plusieurs points de qualité
Mesure de la qualité et méthode d’agrégation
- La qualité d’image est subjective et peut varier d’une personne à l’autre
- La meilleure méthode de mesure consiste à faire comparer ou noter les images par des dizaines de personnes ou plus, selon un protocole de test rigoureux
- Comme ce type d’expérience coûte cher et prend du temps, il est difficile de tester tous les réglages d’encodeur, d’où l’usage d’indicateurs objectifs
- Parmi les bons indicateurs publics figurent SSIMULACRA2, Butteraugli, DSSIM
- ils cherchent à modéliser le système visuel humain et corrèlent bien avec les évaluations subjectives
- des indicateurs plus anciens et plus simples comme PSNR ou SSIM correspondent mal au jugement humain sur la qualité
- Si l’on évalue un encodeur avec l’indicateur qu’il optimise en interne, les résultats peuvent être biaisés en sa faveur
- libjxl à effort élevé optimise Butteraugli
- libavif peut optimiser PSNR ou SSIM
- SSIMULACRA2 est considéré comme un indicateur sûr, car aucun des encodeurs testés ne l’utilise pour son optimisation interne
- Dans le test, les réglages d’encodeur ont été choisis pour que, appliqués à l’ensemble du jeu d’images, le score moyen SSIMULACRA2 soit proche d’une valeur donnée
- Le classement par score moyen favorise WebP et AVIF
- des travaux précédents ont montré qu’AVIF et WebP étaient moins réguliers que JPEG et HEIC, tandis que JPEG XL était l’encodeur le plus constant
- en pratique, on peut préférer viser le pire score ou la pire qualité visuelle réelle
Une plage de qualité proche des usages réels
- La compression avec perte permet des taux très élevés, comme 50:1 ou 200:1, mais au prix d’artefacts de compression
- La plage la plus pertinente en pratique se situe entre 60 et 90 sur SSIMULACRA2
- Caractéristiques selon les niveaux de qualité :
- SSIMULACRA2 90 : qualité visuellement sans perte ; des codecs modernes comme AVIF et JPEG XL peuvent l’atteindre avec un taux d’environ 8:1, soit 3bpp
- SSIMULACRA2 80 : haute qualité ; atteignable à environ 16:1, soit 1,5bpp
- SSIMULACRA2 70 : qualité intermédiaire-haute ; atteignable à environ 30:1, soit 0,8bpp
- SSIMULACRA2 60 : qualité intermédiaire ; atteignable à environ 40:1, soit 0,6bpp
- En dessous de SSIMULACRA2 60, on peut encore réduire la bande passante, mais avec un risque de dégrader fortement l’image
- Sur le web en 2024, la plage de qualité intermédiaire à haute est la plus pertinente
- selon HTTP Archive, la médiane AVIF du web est à 1bpp, ce qui correspond à une qualité intermédiaire-haute
- la médiane JPEG est à 2,1bpp, ce qui correspond à une haute qualité
- Dans des cas d’usage non web comme l’appareil photo, la plage haute qualité à quasi sans perte visuelle est encore plus pertinente
Résultats du front de Pareto en compression avec perte
- Les tests de compression avec perte ont été réalisés avec les dernières versions de chaque encodeur disponibles fin février 2024
- La vitesse d’encodage a été mesurée sur un MacBook Pro de novembre 2023 basé sur Apple M3 Pro, avec 8 threads
- Pour AVIF, des réglages avec et sans tuiles ont été testés
- les réglages en tuiles exploitent mieux le multithreading et sont donc plus rapides
- en contrepartie, ils perdent en densité de compression
Qualité intermédiaire : SSIMULACRA2 60
- Même à l’intérieur d’un même format, les résultats variaient fortement selon l’encodeur et le réglage effort
- Le réglage par défaut de libjpeg-turbo, encodeur JPEG historiquement très répandu, est le plus rapide du graphique, mais se situe du côté d’une faible densité de compression
- WebP offrait une meilleure densité de compression que libjpeg-turbo
- mozjpeg est plus lent que libjpeg-turbo, mais fournit une meilleure compression et, sur ce jeu d’images et à ce niveau de qualité, était plus efficace selon Pareto que WebP
- jpegli, créé par l’équipe JPEG XL de Google, était plus rapide que mozjpeg et compressait mieux
- il s’appuie sur les enseignements tirés de guetzli et de libjxl
- il compresse mieux que WebP et les AVIF rapides tout en produisant des fichiers JPEG classiques
- AVIF et HEIC peuvent atteindre une meilleure densité de compression que JPEG et WebP, mais avec un encodage plus lent
- JPEG XL atteignait une densité de compression similaire tout en encodant beaucoup plus vite
- À ce niveau de qualité, le front de Pareto se compose de JPEG XL et de plusieurs encodeurs JPEG dans les plages de vitesse raisonnables, et d’AVIF dans les plages plus lentes
Résultats en qualité intermédiaire-haute et haute
- À SSIMULACRA2 70, donc en qualité intermédiaire-haute, les résultats globaux étaient similaires à ceux de la qualité intermédiaire
- Le point de qualité le plus élevé pertinent pour le web a été fixé à une moyenne SSIMULACRA2 de 85, avec l’objectif que la plupart des images atteignent au moins 80
- À ce niveau de haute qualité, les écarts deviennent plus nets
- mozjpeg ne battait plus WebP
- jpegli battait toujours WebP
- le front de Pareto était majoritairement occupé par JPEG XL
- pour les encodages très rapides, le JPEG classique restait encore bon
- À ce niveau de qualité, AVIF n’était pas sur le front de Pareto
- dans son réglage le plus lent, il atteignait la même densité de compression que le deuxième réglage libjxl le plus rapide, à moins de 0,5Mpx/s
- ce réglage libjxl atteignait 52Mpx/s, soit plus de 100 fois plus rapide
Vitesse de décodage
- Jusqu’ici, les comparaisons portaient surtout sur la densité de compression et la vitesse d’encodage
- Sur les ordinateurs modernes, la vitesse de décodage n’est pas un problème majeur, mais les mesures ont tout de même été comparées
- Le JPEG séquentiel reste le plus fort en vitesse de décodage
- Les JPEG progressifs produits par mozjpeg et le réglage par défaut de jpegli sont plus lents, mais restent largement assez rapides pour charger très vite des images de taille raisonnable
- JPEG XL se situe entre le JPEG séquentiel et le JPEG progressif
- La vitesse de décodage d’AVIF varie selon la méthode d’encodage
- un encodage multi-tuile, plus rapide mais légèrement moins bon, se décode aussi plus vite
- l’encodage par défaut en tuile unique est plus lent
- Même la vitesse de décodage la plus lente mesurée reste suffisamment rapide comparée à la vitesse d’encodage
Quasi sans perte visuelle et grandes images
- Le graphique de qualité visuellement sans perte n’incluait pas WebP
- il n’atteignait pas ce niveau de qualité en mode avec perte
- WebP impose en effet un sous-échantillonnage chroma 4:2:0
- mozjpeg n’est pas non plus conçu pour ce niveau de qualité, et faisait moins bien que libjpeg-turbo à la fois en compression et en vitesse
- Avec son réglage de vitesse par défaut, libavif produisait des fichiers 20 % plus petits que libjpeg-turbo, mais demandait un temps d’encodage d’un ordre de grandeur supérieur
- Au même niveau de qualité, libjxl produisait des fichiers 20 % plus petits que libavif tout en étant 2,5 fois plus rapide
- Le front de Pareto à qualité visuellement sans perte était majoritairement occupé par JPEG XL, avec encore du JPEG dans la plage de vitesse la plus rapide
- Contrairement aux tests autour de 1 mégapixel, représentatifs d’images de taille web, les résultats changent fortement sur des images plus grandes
- à haut niveau de qualité, WebP, mozjpeg et AVIF faisaient moins bien que libjpeg-turbo
- HEIC apportait un gain notable face à libjpeg-turbo
- jpegli apportait lui aussi un gain notable avec une meilleure vitesse
- JPEG XL compressait l’image sous 1,3bpp, alors qu’AVIF, libjpeg-turbo et WebP demandaient plus de 2bpp
Position finale de libjxl 0.10
- libjxl 0.10 réduit l’usage mémoire d’un ordre de grandeur en compression sans perte comme avec perte
- La vitesse progresse aussi, notamment en encodage sans perte multithread au réglage effort par défaut, avec un gain d’un ordre de grandeur
- JPEG XL s’affirme comme un codec d’image très solide en compression sans perte comme avec perte, en particulier dans la plage haute qualité à quasi sans perte visuelle
- Sur une large plage de réglages de vitesse, JPEG XL reste un choix proche de l’optimum de Pareto
- Le JPEG classique reste lui aussi attractif grâce aux nouveaux encodeurs
- jpegli améliore fortement à la fois la vitesse et la compression par rapport à mozjpeg
- quand un encodage extrêmement rapide est nécessaire, le JPEG classique peut encore être le meilleur choix
2 commentaires
L’encodeur jpegli prolonge encore une fois la durée de vie du jpg après mozjpeg...
Créé par le camp JXL, mais ironiquement, il pourrait aussi freiner la diffusion de JXL...
Commentaires sur Hacker News
Il faut aussi noter à quel point le WebP sans perte est bon
Cet aspect est souvent éclipsé par les discussions disant que WebP n’apporte pas d’avantage clair, voire est pire, que l’encodage MozJPEG, mais le WebP sans perte est vraiment excellent en termes de performances et de vitesse
Il est bien meilleur que PNG ou OptiPNG, le support en ligne est désormais suffisant, et il surpasse évidemment de loin le médiocre AVIF sans perte
C’est acceptable pour les images SDR, mais pour le HDR c’est une limite aussi fondamentale que celle du GIF limité à 256 couleurs
Si l’on compresse une BD entière, PNG reste le bon choix, et dans ce cas mieux vaut utiliser oxipng que optipng, désormais pratiquement abandonné
Autre point absent ici : le JPEG2000 sans perte peut être étonnamment bon et rapide sur du contenu photographique
Il est préférable au vrai sans perte dans la plupart des usages, et réduit souvent la taille de moitié sans perte visible supplémentaire
À des réglages de qualité très bas, il est surprenant de voir que le JPEG conserve une approximation nette des détails qui préserve mieux la qualité globale de l’image, même si, vue de près, elle ressemble à un tableau cubiste à cause d’artefacts flagrants
En pratique, cela revient à transformer l’image dans un style d’art abstrait, alors que JXL et AVIF deviennent simplement flous
Ces images ne visent pas le même taux de compression, mais le même niveau de distorsion, et le nombre de bits par pixel est indiqué à côté des images
Sur le vrai web, l’usage de la qualité 65 est rare et se limite aux sites de très basse qualité ; la qualité 75 est un bas de gamme courant, et la qualité 85 est plus proche de la moyenne
Quand la compression est nécessaire, on utilise une qualité 94 yuv444 ou plus
Le débit binaire est indiqué dans la colonne de gauche, et le JPG basse qualité a la même taille que le JXL/AVIF à 0,4 bpp, soit une qualité intermédiaire basse, donc il faut comparer l’image en bas à gauche avec celles du haut au centre et à droite
Il ne faut pas se laisser emporter par une comparaison erronée, et JXL comme AVIF auraient aussi bien meilleure allure si on leur donnait des fichiers deux fois plus gros
SSIMULACRA2 semble sanctionner fortement les artefacts de bloc mais peu se soucier du flou, et je suis d’accord pour dire qu’à score SSIMULACRA2 égal, la version JPEG paraît meilleure
Je ne comprends pas pourquoi cet article se concentre autant sur la vitesse d’encodage, tout en traitant à la légère le décodage, qui représenterait 99 % de l’usage en environnement web
Cela se résume à quelque chose comme : « la vitesse de décodage n’est pas un gros problème sur les ordinateurs modernes, mais les chiffres sont intéressants à voir rapidement »
À partir de là, le goulot d’étranglement n’est plus le décodage
La plupart des algorithmes de compression modernes sont asymétriques : on peut consacrer beaucoup plus de temps à la compression sans que cela n’affecte fortement les performances de décompression ; une fois les performances de base atteintes, cela devient moins important
Si c’est possible, ce serait une raison forte de les préférer au JPEG XL, qui doit aujourd’hui être décodé entièrement en logiciel sur le matériel actuel
Le décodage H264 est partout, et celui d’AV1 devient progressivement une fonctionnalité standard
Il suffit que le client puisse décoder les quelques images d’une page assez vite pour que l’humain ne le remarque pas ; à l’inverse, même un gain de quelques pourcents à l’encodage peut réduire des coûts réels
Ils dépensent réellement des millions de dollars pour l’encodage d’images
Voir QOI apparaître dans un benchmark sans perte m’a fait rire
C’est intéressant qu’un format essentiellement hors sujet, non pris en charge nativement par les logiciels grand public et visant surtout à être simplement correct plutôt qu’excellent, occupe une place dans le graphique d’encodage non photographique
Donc GameMaker Studio et les jeux créés ces deux dernières années environ utilisent effectivement QOI en interne
Le consommateur ne l’utilise pas consciemment, mais on ne peut pas non plus dire que ce soit totalement hors sujet
Avec le recul, c’est logique : le décodage de QOI est intrinsèquement séquentiel et ne se parallélise pas facilement
Je me demande si l’excellence de JXL vient du format lui-même ou de l’encodeur
La capacité à produire de petites images de haute qualité avec seulement
-d 1.0est presque étrange, alors qu’avec d’autres codecs il fallait ajuster différemment les réglages de qualité selon le type d’image pour obtenir des résultats comparablesÀ ce rythme de développement, il ne serait pas surprenant que libjxl devienne le x264 des encodeurs d’image
À l’inverse, libvpx a toujours été un encodeur assez quelconque, et je pense que cela peut expliquer les performances décevantes de vp8/vp9, non seulement en vitesse mais aussi de façon plus générale
Cela a inévitablement eu un impact sur les performances de WebP avec pertes, et Dark Shikari a déjà comparé les performances sur images fixes de x264 et vp8 [0]
[0] https://web.archive.org/web/20150419071902/http://x264dev.mu...
L’accent a été fortement mis sur le quasi sans perte visuel, et on ne voulait pas ajouter de fonctionnalités de format qui n’aident pas aux réglages de haute qualité tout en augmentant seulement la complexité
Au-delà des fonctions de modélisation, la modélisation du contexte et l’efficacité du codage entropique sont très importantes à haute qualité
Je pense que le codage entropique d’AVIF n’est pas bien adapté aux photos de haute qualité ou sans perte
-d 1.0Il vaut aussi la peine de signaler qu’un excellent nouveau framework de parallélisation appelé Highway est sorti des travaux sur JPEG XL
Cette bibliothèque est utilisée non seulement pour JPEG XL, mais aussi pour les récents modèles d’IA Gemma de Google
C’est aussi abordé dans [1], qui commence ainsi : « Aujourd’hui, nous partageons du code open source qui trie des tableaux de nombres environ 10 fois plus vite que le
std::sortde C++, tout en restant portable sur toutes les architectures CPU modernes et en étant plus rapide que les algorithmes spécifiques les plus récents pour chaque architecture. Nous expliquons ci-dessous comment nous y sommes parvenus. »[0] https://github.com/google/highway
[1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., l’article scientifique associé est https://arxiv.org/pdf/2205.05982.pdf
Cela semble être la meilleure façon d’obtenir du SIMD portable en C++
Indépendamment de l’éclat propre à JPEG XL, c’est déjà clairement impressionnant rien que parce qu’il peut faire ceci
a.jpgfait 615504 octets et son SHA-1 est716744d950ecf9e5757c565041143775a810e10fExécuter
cjxl a.jpg a.jxllit un JPEG de 615504 octets et le compresse à 537339 octets, conteneur inclusMais exécuter
djxl a.jxl b.jpglit les 537339 octets de données compressées, les reconstruit en JPEG, etb.jpgfait aussi 615504 octets avec exactement le même SHA-1Quand on pense aux milliards de fichiers JPEG qu’on peut vouloir préserver, recompresser un JPEG existant dans un format avec pertes en dégrade la qualité
Mais JPEG XL permet d’économiser 15 à 30 % tout en pouvant, si on le souhaite, restaurer le JPG d’origine de manière 100 % identique bit à bit
C’est vraiment génial
Malheureusement, j’utilise Debian stable 12 Bookworm avec ImageMagick 6.9, et il me semble qu’Emacs s’appuie probablement sur ImageMagick pour afficher les images
La prise en charge de JPEG XL n’a été ajoutée qu’à ImageMagick 7, et je n’ai pas encore creusé davantage
Je pense que cela aidera à préserver pleinement le patrimoine numérique sans réencodage avec pertes
Il est très impressionnant de voir que la nouvelle version de libjxl a réduit l’utilisation mémoire d’un ordre de grandeur à un seul chiffre en compression avec et sans perte, tout en améliorant la vitesse
J’apprécie particulièrement le fait que le réglage d’effort par défaut pour l’encodage sans perte multithread soit désormais plus rapide d’un ordre de grandeur à un seul chiffre, et l’article est bien écrit
Je me demande s’il existe un site web qui explique en détail chaque étape du format JPEG XL
Contrairement au JPEG traditionnel, il est difficile de trouver une documentation qui guide clairement à travers les étapes concernées, ce qui est dommage car il est évident que ce format rassemble de nombreuses innovations intéressantes
Les composants individuels sembleraient aussi utiles en eux-mêmes
L’essentiel, ce sont des DCT à taille variable jusqu’à 128x128, la prédiction entropique ANS et la prédiction de chrominance basée sur la luminance
https://github.com/libjxl/libjxl/blob/main/doc/encode_effort... montre aussi bien la répartition des fonctionnalités selon les niveaux d’effort
Il manque dans l’article rav1e, qui encode AV1, et donc AVIF
rav1e est bien plus rapide que l’implémentation de référence aom, et il y a eu des cas où aom n’avait pas fini de convertir l’image après une minute d’attente alors que rav1e prenait moins de 10 secondes
Je me demande aussi si rav1e rapide semble meilleur que jpegli à des vitesses d’encodage élevées
À vitesse comparable, je n’ai pas vu de grande différence de performances de compression entre les deux