Re: Moche

Je suis un très fort soutien de WebP, en remplaçant du JPEG et du PNG 8-bit. Mais WebP n’est pas un concurrent qui peut se mesurer au Jpeg XL.

Pour remplacer du JPEG, le WebP avec perte gagne haut la main, en terme de taille, et en terme de qualité :

comparaison jpeg/webp

Pour remplacer le PNG 8-bit aussi. Par défaut le format PNG n’est pas mieux qu’un BMP dans un zip. C’est littéralement une matrice RGBA compressée avec zlib. Pour mieux compresser il faut utiliser des profils que quasiment aucun logiciel n’utilise, qui vont justement stocker l’image dans d’autres formats qu’une simple matrice RGBA avant de compresser. En utilisant un optimiseur on peut en général gagner entre 5 et 25% de taille. Il existe d’autres choses plus folles comme des optimiseurs qui après ça font des algorithmes génétiques pour tester des milliers de combinaisons pour trouver celle qui compresse le mieux. Après ça on peut encore utiliser zopfli qui est un algorithme de compression zlib très bourrin qui fait beaucoup de calculs pendant très longtemps pour gagner de la place. Quand on mélange tout ça, on obtient un outil qui peut passer des heures (littéralement) pour économiser 1 octet. Au début on gagne 5~25%, après on gagne des octets.

Eh bien en faisant tourner ce genre d’optimiseur PNG pendant des heures, on peut parfois approcher (mais seulement approcher) ce que fait WebP en quelques secondes. Attention cependant, pour avoir un WebP vraiment avec perte il faut non-seulement utiliser l’option -lossless mais aussi l’option -exact de l’outil cwebp, autrement le rendu final peut être sans perte mais pas les données (par exemple sans -exact un pixel rouge avec une transparence complète donc avec le rouge totalement invisible pourrait être mis dans une autre couleur pour optimiser).

Maintenant que j’ai vanté les louanges de WebP, comparons avec JPEG XL. Quand je dis « 8-bit » ou « 12-bit », c’est par canal. Un JPEG 8-bit par canal c’est 24-bit (trois canaux), un PNG transparent au format RGBA 8-bit c’est 32-bit (quatre canaux), mais dans tous les cas ont va appeler ça du « 8-bit ». C’est l’unité de base, indépendamment des formats internes.

Comparaison	JPEG XL	WebP	AVIF
Compresser depuis un format 8-bit avec ou sans perte vers JPEG XL? JPEG XL fait au moins aussi bien que WebP et AVIF.	✅️	✅️	✅️
Compresser depuis un format JPEG avec perte vers JPEG XL? JPEG XL le fait sans perte, WebP et AVIF le font avec perte.	✅️	❌️	❌️
Compresser depuis un format 12-bit avec ou sans perte vers JPEG XL? WebP ne fait pas, AVIF le fait.	✅️	❌️	✅️
Compresser depuis un format 14-bit avec ou sans perte vers JPEG XL? Ni WebP ni AVIF ne le font.	✅️	❌️	❌️
Compresser depuis un format 16-bit avec ou sans perte vers JPEG XL? Ni WebP ni AVIF ne le font.	✅️	❌️	❌️

Non-seulement JPEG-XL permet de recompresser sans perte les milliards de JPEG qui existent, JPEG étant le standard de fait pour les images compressées avec pertes en 8-bit, ce qu’aucun autre format ne fait.

Mais JPEG-XL gère les images en haute résolution, c’est donc un concurrent du PNG 16-bit et probablement de nombreux usages du TIFF (il y a peut-être des fonctionnalités que j’oublie là tout de suite).

Pour comprendre quel est l’impact de la taille des canaux dans la vie réelle, je donne un exemple très concret, avec deux appareils photos réflexe du marché (un peu anciens) que je connais, le Nikon D5100 et le Nikon D7000. Il est probable que Nikon fasse toujours ce que je vais dire sur ses modèles récents, mais je suis sûr pour ces modèles alors on va garder ceux-là pour l’exemple. Ces deux appareils photos ont exactement le même capteur et la même carte mère, et peut recevoir exactement les mêmes objecifs. Le D5100 est dans la gamme amateur, le D7000 est dans la gamme semi-professionnelle. La différence fondamentale ? Elle est logicielle, Nikon a bridé le D5100 à ne produire que des images 12-bit alors que le D7000 produit des images 14-bit. Ce bridage logiciel signifie que le photographe a moins de données au développement et est restreint dans sa capacité d’édition, il devient plus difficile de sauver des photos un sur-exposées ou sous-exposées, ou dont la balance des blanc est mauvaise.

Le marché des appareils photographiques est organisé comme ça : 8-bit pour le compact du tout-venant , 12-bit pour le reflex du photographe amateur, 14-bit pour le reflex du semi-professionnel et professionnel, je ne sais pas s’il existe des appareils photos 16-bit mais vous voyez l’idée.

Le gros avantage de AVIF comme de WebP et de HEIF c’est qu’ils sont dérivés de formats vidéos et qu’il est très probable que les téléphones auront des décodeurs matériels pour ça, même en entrée de gamme car l’industrie veut vendre de la vidéo à tout le monde, et probablement pour beaucoup, des encodeurs matériels (dès lors qu’ils filment dans les formats vidéos dont ces formats d’images sont dérivés).

Mais ils restent des formats soit d’entrée de gamme, soit « amateur éclairé », pas plus.

Il y a vraiment besoin de sortir du 8-bit par canal qui correspond aux usages d’il y a plusieurs décennies, AVIF a une carte a jour en proposant 12-bit, ce qui j’imagine est suffisant pour beaucoup d’usages (surtout quand on édite pas).

Mais JPEG-XL a deux atouts de choix: le premier c’est la compatibilité avec le jpeg, et là c’est certainement l’industrie du Web qui va pousser (sauf que le Web c’est beaucoup trop Google aujourd’hui), le second c’est la haute précision. Le seul format JPEG-XL est un concurrent de tous les formats d’images, en terme de taux de compression et de qualité de compression il n’y a aucun autre format qui puisse se vanter de faire mieux de manière significative, quand il ne les oblitère pas complètement, ou fait des choses que les autres ne font même pas. Ni WebP, ni AVIF, ne peuvent concurrencer JPEG-XL autrement que par de la politique.

JPEG-XL est l’équivalent pour les images de Opus, qui sur le plan de l’audio sans perte remplace dans les applications et sur le web tous les autres codecs, que ce soit les codecs téléphoniques que les codecs musicaux. Faire une plate-forme de conférence ? Opus. Faire une plate-forme de streaming de musique ? Opus. En fait JPEG-XL fait mieux que ça, il ne couvre pas seulement tous les besoins du web (compression 8-bit avec perte, canal alpha...), il couvre aussi les besoins sans perte. Pour conserver la comparaison c’est comme si Opus se mettait à aussi concurrencer FLAC sur son terrain...

Je ne sais pas ce qui pousse Google à pousser AVIF si fort et à mettre autant d’obstacles à JPEG XL. Ils ont connaissance de brevets dormant dans JPEG XL ? Ils se disent que ne payer la production et l’intégration d’une puce pour AV1/AVIF dans leurs milliers de machines sera moins cher que de devoir intégrer en plus une puce JPEG-XL?

L’opposition à JPEG-XL ne peut pas être technique, JPEG-XL est meilleur que les autres et de loin. Il ne reste donc que la politique et l’économie.

Bref, je suis un fort soutien du WebP, mais WebP ce n’était bien qu’avant que JPEG-XL n’existe. Si JPEG-XL est disponible dans un flux de travail, je ne ferai pas du tout de WebP. Je ne défendrai WebP que si JPEG-XL n’est pas disponible.

ce commentaire est sous licence cc by 4 et précédentes