Auteur Sujet: Comparer la qualité des différents formats d'image (JPEG, WebP, AVIF, JPEG XL) (Lu 96 fois)

vivien · « **le:** 11 novembre 2024 à 21:56:05 »

Comparatif d'une même image encodée dans des formats d'image différents

Image source : (PNG - Compression sans perte : 529 616 octets)

J'ai fait un zoom sur un livre derrière moi.

Je vais écrire à https://www.industrialempathy.com/posts/avif-webp-quality-settings/ car il y a un vrai problème dans leur équivalence de qualité :

Les lignes du tableau d'image ci-dessous sont censées avoir la même qualité. On voit bien qu'AVIF se comporte très bien et que JPEG dégrade fortement l'image.

Cliquer pour afficher l'image seule :

hwti · « **Réponse #1 le:** 12 novembre 2024 à 02:19:14 »

Citation de: vivien le 11 novembre 2024 à 21:56:05

Je vais écrire à https://www.industrialempathy.com/posts/avif-webp-quality-settings/ car il y a un vrai problème dans leur équivalence de qualité fortement l'image.

La page indique :
Images were encoded using the sharp image processing library. Results with different encoders may vary.
https://sharp.pixelplumbing.com/ mentionne mozjpeg, qui optimise la taille des fichiers générés, et pourrait aussi générer un résultat différent de libjpeg(-turbo) non patchée.
D'ailleurs l'auteur utilise https://github.com/kornelski/dssim pour mesurer la différence de qualité, le projet a un lien vers https://kornel.ski/en/faircomparison

mozjpeg's fast profile gives almost 20% larger files at the same quality setting (5% at the same SSIM)
Donc même avec mozjpeg, le profil "fast" augmente plus la taille du fichier si on garde le réglage de qualité identique, que si on l'ajuste pour avoir le même SSIM.
Ca veut dire qu'il produit des images plus grosses, mais aussi de meilleure qualité à réglage identique.

The underlying data was generated from only 4 images
C'est effectivement un peu léger, même si ce sont 4 photos.

Il y a également un point qui n'est pas mentionné : les images source sont en JPEG !
Certes elles sont assez grandes (4032x2268, 3040x4561, 2080x3120, 5304x7952) et redimensionnées en 160, 320, 640, 1280, 1920 pixels de large pour les tests.
Mais il pourrait rester quelques traces d'artéfacts JPEG ou du redimensionnement (en fonction de l'algo) qui pourraient avoir un effet (en fonction des encodeurs qui essayeraient plus ou moins de les reproduire).

Xantoom · « **Réponse #2 le:** 12 novembre 2024 à 11:57:39 »

Perso j'utilise du JPEG pour toutes mes images avec la nouvelle librairie de Google qui est sorti plus tôt dans l'année : JPEGLI
https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html

Avec un logiciel comme XL Converter et je mets la qualité à 67% en partant des images de base en PNG si possible (ou la plus haut qualité possible en tout cas).

Et pour comparer j'utilise SSIMULACRA 2 qui génère un score qui va jusqu'à 100 :
https://github.com/cloudinary/ssimulacra2

vivien · « **Réponse #3 le:** 12 novembre 2024 à 12:26:26 »

GIMP 3 RC ne semble pas proposer la nouvelle librairie de Google...

Voici les options utilisées pour mes tests plus haut (compression avec perte en sous-échantillonnage 4:2:0, avec la RC 1 de Gimp 3.0.0).
J'ai décoché la sauvegarde du profil colorimétrique et des données Exif / XMP pour tous les formats d'image.

Export JPEG : J'ai mis "Virgule flottante" pour la méthode DCT. D'après ce que j'ai compris, cela améliore l'image au prix d'un encodage plus long.

Export WebP : Ce sont les options par défaut.

Export AVIF : J'ai mis "Encoder speed" sur "Lente" pour améliorer la qualité ou réduire le poids au prix d'un encodage plus long.

MaxLebled · « **Réponse #4 le:** 12 novembre 2024 à 15:41:29 »

Regarde le poids des fichiers en 10-bit, il y a moyen pour que ça soit un meilleur rapport qualité-taille (ça peut paraître paradoxal mais ça fonctionne comme ça pour x264 & AV1 10-bit)

Et sinon oui, il vaudrait mieux comparer avec les vitesses d'encodage les plus lentes, et avec le meilleur encodeur JPEG (qui doit donc être MozJPEG, même plus Guetzli ?)

vivien · « **Réponse #5 le:** 02 novembre 2025 à 13:31:14 »

J'ai généré 648 images avec différents types d'encodages depuis le fichier vectoriel SVG proposé.

Je ne vais pas utiliser DSSIM (comme c'est le cas du comparatif AVIF and WebP encoding quality settings) car il est notoirement mauvais pour évaluer les codecs modernes. DSSIM se "bloque" à haute qualité, il peut donner un score très élevé à une image qui présente des artefacts de "ringing" subtils, mais très gênants pour un humain. Il ne pénalise pas assez le lissage des textures (il peut même le récompenser) et ne détecte pas bien le "ringing".

Tu as une idée de l'outil à utiliser pour qualifier la qualité de ces 648 images ?

La qualité dans le tableau est la qualité demandée à GIMP. Il faudrait maintenant avoir la qualité réelle de l'encodage pour pouvoir voir ce qui est le plus efficace, en effet, la taille de l'image varie, mais également sa qualité.

Comparaison d'un encodage 8 bits, 10 bits et 12 bits (taille exprimée en octets)

Compression d'une même image matricielle dans de nombreux formats : JPEG, PNG, WebP, HEIC, AVIF, JPEG XL

Le fichier zip comprenant les 648 images bitmap et l'image SVG source : lot_649_images_differents_formats.zip.

Paramètres utilisés pour générer les images :
- Paramètres JPEG YUV420
- Paramètres JPEG YUV444
- Paramètres PNG RVB 8bits
- Paramètres PNG RVB 16bits
- Paramètres WebP RVB
- Paramètres WebP YUV420
- Paramètres HEIC RVB
- Paramètres HEIC YUV420
- Paramètres HEIC YUV444
- Paramètres AVIF RVB
- Paramètres AVIF YUV420
- Paramètres AVIF YUV444
- Paramètres JPEG XL XYB

MaxLebled · « **Réponse #6 le:** **Hier** à 12:34:58 »

Citation de: vivien le 02 novembre 2025 à 13:31:14

Tu as une idée de l'outil à utiliser pour qualifier la qualité de ces 648 images ?

PSNR et SSIM sont les 2 grands classiques mais de moins en moins pertinents. VMAF : non, seulement utile pour la vidéo et ne prend pas en compte tout un tas de défauts perceptuels, dont le banding.

Donc... peut-être SSIMULACRA2 ? https://github.com/cloudinary/ssimulacra2

Ou alors une des nouvelles variantes de SSIM...

Ou alors DISTS (se repose sur de l'apprentissage machine) : https://github.com/dingkeyan93/DISTS

vivien · « **Réponse #7 le:** **Hier** à 14:39:30 »

Merci de m'avoir fait découvrir SSIMULACRA2.

Il est installable très facilement sur debian / ubuntu : sudo apt install libjxl-devtools (c'est dans les dépôts)

Il prend en charge les format d'images PNG, JPEG et JPEG XL. Pour WebP, HEIC et AVIF, il faut au préalable faire une conversion en PNG (en PNG 16 bits, j'imagine pour ne pas dégrader la qualité dans la conversion. Toutefois, je me demande si la conversion YUV ⇒ RVB du PNG n'entraine pas une perte).

Exemple :
$ ssimulacra2 png_rvb_8bits_sans_perte.png jxl_xyb_8bits_q100.jxl
90.00333001

SSIMULACRA2 semble très bon pour détecter les artefacts, notamment :
- Le "ringing" (halos ou "fantômes" près des contours nets).
- Le "smoothing" (lissage excessif qui efface les textures fines).
- Le "blockiness" (effets de blocs, bien qu'elle soit plus subtile que les anciennes métriques sur ce point).

DISTS est intéressant (plus généraliste que SSIMULACRA2, DISTS permet notamment de faire des analyses sur une large gamme de distorsions), mais est extrêmement lent, car nécessite l'exécution d'un réseau de neurones (VGG16) pour chaque comparaison. Une accélération GPU est pratiquement indispensable pour une utilisation en dehors de tests sur quelques images. Comme la plupart des modèles de deep learning, il est difficile de savoir exactement pourquoi elle attribue un score spécifique. DISTS est plus compliqué à installer, il lui faut un environnement python virtualisé (un simple pip install dists-pytorch ne fonctionne pas).

hwti · « **Réponse #8 le:** **Hier** à 17:12:27 »

Citation de: vivien le Hier à 14:39:30

Pour WebP, HEIC et AVIF, il faut au préalable faire une conversion en PNG (en PNG 16 bits, j'imagine pour ne pas dégrader la qualité dans la conversion. Toutefois, je me demande si la conversion YUV ⇒ RVB du PNG n'entraine pas une perte)

Il y a aussi une interpolation, quand on repasse du YUV 4:2:0 ou 4:2:2 au RGB qui est 4:4:4.
En 8 bits, on pourrait convertir en JPEG lossless.
Mais en 10 / 12 bits, la seule option serait JPEG-XL lossless, mais l'outil cjxl est limité dans les formats aussi.

ssimulacra2 parle de "XYB color space (rescaled to a 0..1 range and with B-Y)" donc il fait aussi des conversions, mais si c'est vers un flottant il n'y a pas d'arrondi.
En revanche rien n'est dit sur le downsampling.

MaxLebled · « **Réponse #9 le:** **Hier** à 17:32:52 »

Citation de: vivien le Hier à 14:39:30

- Le "blockiness" (effets de blocs, bien qu'elle soit plus subtile que les anciennes métriques sur ce point).

(Attention aux faux amis ! On dit « indicateurs » ou « mesures » en français ! Désolé, ça me fait vraiment tiquer...)

Citation de: vivien le Hier à 14:39:30

Toutefois, je me demande si la conversion YUV ⇒ RVB du PNG n'entraine pas une perte).

Normalement non... c'est vrai qu'il peut exister plusieurs façons de le faire, mais tant que c'est réalisé en 16-bits et pas 8-bits ↔ 8-bits, ça devrait aller

Citation de: hwti le Hier à 17:12:27

Il y a aussi une interpolation, quand on repasse du YUV 4:2:0 ou 4:2:2 au RGB qui est 4:4:4.

Oui, bien sûr ; mais attention, YUV ne veut pas forcément dire qu'il y a sous-échantillonage de la chrominance (on peut très bien avoir du YUV 4:4:4 même si c'est très peu répandu).

De même, oui, il y a certains algorithmes employés par certains lecteurs qui tentent de mieux « restaurer » la chrominance sous-échantillonnée lorsqu'elle est remise à l'échelle, pour mieux la faire correspondre avec la luminance. Pas sûr que ça doit souhaitable de tenter de faire autre chose que du bicubique normal dans toutes ces comparaisons, cela dit

vivien · « **Réponse #10 le:** **Hier** à 18:21:33 »

Pour les images, sur ce forum toutes les images sont en 4:4:4 : C'est soit du WebP RVB (compression sans perte) soit de l'AVIF YUV444 pour la compression avec perte.

Quand on a du texte sur une image (typiquement une capture d'écran), le 4:2:0 (imposé par exemple par la compression WebP avec pertes) dégrade bien l'image.

J'ai arrêté d'utiliser le JPEG et le WebP (compression avec perte).

À noter que le JPEG propose de nombreuses options (le YUV444 fait partie des options proposées)

hwti · « **Réponse #11 le:** **Hier** à 19:08:31 »

Pour le 4:2:0 / 4:2:2, j'en parlais parce que le tableau qui compare les tailles encodées a des données pour JPEG / WebP / AVIF / HEIC en 4:2:0.

Pour la conversion YUV 4:4:4 => RGB avant comparaison, ça peut faire quelques erreurs d'arrondis en 8 bits, l'effet sur la mesure sera probablement limité mais tout dépend quelle est la qualité cible.