Réfléchir soigneusement aux comparaisons de codecs

Lorsque Chrome a annoncé l’arrêt de l’expérimentation de JPEG XL (https://fr.news.hada.io/topic?id=7709), le suivi d’incidents a été inondé de questions demandant pourquoi cela était supprimé. En réponse, le camp d’AVIF avait déjà publié des benchmarks comparatifs pour défendre sa position (https://storage.googleapis.com/avif-comparison/index.html). Cet article propose une analyse de ces données ainsi qu’une réfutation du côté de JPEG XL.

Au-delà d’un simple soutien ou rejet de JPEG XL, il vaut la peine d’être lu car il met en lumière des points importants dans la comparaison des formats d’image. En résumant quelques points clés :

• Les mesures de vitesse de décodage du côté d’AVIF reposaient sur d’anciennes versions de Chrome et de libjxl, et sont donc exagérées. Avec les versions récentes, on obtient plutôt JPEG XL (paramètres par défaut) ~= AVIF 12 bits < JPEG XL (réglage de décodage rapide) ~= AVIF 8 bits < JPEG XL recompressé à partir de JPEG, chaque inégalité ne représentant qu’environ 10 % d’écart.

• Plus que la vitesse totale de décodage, le moment où une image exploitable apparaît est plus important, et JPEG XL dispose ici d’un gros avantage grâce au décodage progressif (progressive). (C’est le même type d’enjeu que lorsqu’on parle de Largest Contentful Paint sur le web.)

• Les comparaisons distinguent séparément les performances d’encodage et la qualité des images encodées, mais si libjxl permet d’ajuster totalement indépendamment ces deux aspects, ce n’est pas le cas de la plupart des autres encodeurs, dont AVIF, ce qui rend ce type de comparaison impossible pour eux.

• La plage de qualité cible proposée pour l’encodage est beaucoup trop large et ne tient pas compte de la distribution de probabilité. La qualité la plus basse, désignée comme "On the fly", est si faible que personne ne pourrait l’utiliser pour quelque usage que ce soit. De plus, AVIF est en moyenne avantagé sur les images de faible qualité, mais dès que la taille du fichier augmente un peu, JPEG XL prend souvent nettement l’avantage ; en faisant la moyenne d’une manière inadaptée, on aboutit à un résultat qui dilue les points forts de JPEG XL.

• Le jeu de données utilisé pour les tests est inadapté. Pour la compression sans perte, il utilise l’ensemble Kodak constitué de scans d’images de magazines, et pour la compression avec perte il inclut l’ensemble Noto Emoji, qui relève généralement plutôt du graphisme vectoriel ou de la compression sans perte ; dans les deux cas, ce ne sont pas des usages représentatifs de la compression sans perte ou avec perte.

• Si les performances de compression d’image relèvent d’un débat sur le présent, les fonctionnalités prises en charge par un format d’image concernent l’avenir. Si un format d’image intégré à un navigateur ne peut plus ensuite être retiré, alors il faut d’autant plus l’évaluer en mettant l’accent sur ses fonctionnalités.

[lifthrasiir]

Comme j’ai écrit ça à la va-vite avant de partir au travail, il y a quelques petites erreurs (...). Par ailleurs, on the fly, à strictement parler, ne signifie pas la qualité la plus basse mais la vitesse la plus élevée (même si, à l’exception de JPEG XL, cela a une corrélation inverse avec la qualité dans la plupart des encodeurs). De plus, pour l’ensemble de données Kodak, je ne sais pas ce que j’avais en tête en écrivant qu’il s’agissait d’un magazine, alors qu’en réalité il a été numérisé à partir d’un film.

[xguru]

Les avantages de JPEG XL