La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: 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)
(https://lafibre.info/images/format/image_test4_gimp3_444_png_sans_perte.png)
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é :
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
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 :
(https://lafibre.info/images/format/image_test4_gimp3_synthese.webp) (https://lafibre.info/images/format/image_test4_gimp3_synthese.webp)
-
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).
-
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 (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 (https://github.com/cloudinary/ssimulacra2)
-
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 (https://lafibre.info/images/format/202411_gimp_3.0_parametres_export_jpeg.webp) : 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 (https://lafibre.info/images/format/202411_gimp_3.0_parametres_export_webp.webp) : Ce sont les options par défaut.
Export AVIF (https://lafibre.info/images/format/202411_gimp_3.0_parametres_export_avif.webp) : J'ai mis "Encoder speed" sur "Lente" pour améliorer la qualité ou réduire le poids au prix d'un encodage plus long.
-
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 ?)
-
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 (https://www.industrialempathy.com/posts/avif-webp-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
(https://lafibre.info/images/format/synthese_compression_image.avif)
Le fichier zip comprenant les 648 images bitmap et l'image SVG source : lot_649_images_differents_formats.zip (https://lafibre.info/images/format/lot_649_images_differents_formats.zip).
Paramètres utilisés pour générer les images :
- Paramètres JPEG YUV420 (https://lafibre.info/images/format/parametres_jpeg_yuv420.webp)
- Paramètres JPEG YUV444 (https://lafibre.info/images/format/parametres_jpeg_yuv444.webp)
- Paramètres PNG RVB 8bits (https://lafibre.info/images/format/parametres_png_rvb_8bits.webp)
- Paramètres PNG RVB 16bits (https://lafibre.info/images/format/parametres_png_rvb_16bits.webp)
- Paramètres WebP RVB (https://lafibre.info/images/format/parametres_webp_rvb.webp)
- Paramètres WebP YUV420 (https://lafibre.info/images/format/parametres_webp_yuv420.webp)
- Paramètres HEIC RVB (https://lafibre.info/images/format/parametres_heic_rvb.webp)
- Paramètres HEIC YUV420 (https://lafibre.info/images/format/parametres_heic_yuv420.webp)
- Paramètres HEIC YUV444 (https://lafibre.info/images/format/parametres_heic_yuv444.webp)
- Paramètres AVIF RVB (https://lafibre.info/images/format/parametres_avif_rvb.webp)
- Paramètres AVIF YUV420 (https://lafibre.info/images/format/parametres_avif_yuv420.webp)
- Paramètres AVIF YUV444 (https://lafibre.info/images/format/parametres_avif_yuv444.webp)
- Paramètres JPEG XL XYB (https://lafibre.info/images/format/parametres_jpegxl_xyb.webp)
-
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
-
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).
-
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.
-
- 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...)
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
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 :)
-
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)
(https://lafibre.info/images/format/parametres_jpeg_yuv444.webp)
-
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.
-
Je découvre qu'en important un SVG dans GIMP, on reste à 8 bits / couleur :
(https://lafibre.info/images/format/parametres_importation_svg_dans_gimp3.webp)
La source de mes images est donc du 8 bits.
Si je compare le PNG16 bits avec le PNG8 bits, je n'obtiens pas l seuil de 100% :
$ ssimulacra2 png_rvb_8bits_sans_perte.png png_rvb_16bits_sans_perte.png
95.35676076
$ ssimulacra2 png_rvb_16bits_sans_perte.png png_rvb_8bits_sans_perte.png
95.35673729
Si je convertis le PNG 8 bits en PNG 16bits, quand je compare avec SSIMULACRA2 le même fichier, j'ai bien un seul de 100.000 (correspondance parfaite), ce qui est normal :
$ ssimulacra2 png_rvb_16bits_sans_perte.png png_rvb_8bits_sans_perte_converti_16bits.png
100.00000000
J'en conclus, qu'il ne peut donner 100% que si les deux fichiers ont le même nombre de bits.
Par mesure de précaution, je pense qu'il sera peut-être bon de convertir tous mes fichiers en PNG 16bits, même ceux comme le JPEG qu'il sait traiter directement.
-
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
Une autre possibilité : Butteraugli de Google
⇒ https://github.com/google/butteraugli
Il s'installe très simplement sous Linux : sudo apt install butteraugli
Ligne de commande : butteraugli image1.{png|jpg} image2.{png|jpg}
(il ne supporte que PNG et JPEG)
Il peut générer une heat map (carte de chaleur) qui montre où dans l'image il a trouvé des défauts perceptuels :
butteraugli image1.{png|jpg} image2.{png|jpg} heatmap.pnm
Voici la comparaison SSIMULACRA2 et Butteraugli par gemini (désolé Leon) :
Question : Quels sont les avantages et inconvénients de SSIMULACRA2 et Butteraugli pour mesurer la qualité visuelle d'une image compressée, par rapport à l'image originale ?
Réponse Gemini :
C'est une excellente question qui touche au cœur de l'évaluation moderne de la qualité d'image. SSIMULACRA2 et Butteraugli sont deux des métriques de qualité perceptuelle ("Full-Reference") les plus avancées, toutes deux conçues pour surpasser les anciennes métriques comme le PSNR ou le SSIM.
Elles partagent un objectif commun : prédire un score de qualité qui correspond à ce qu'un être humain percevrait. Cependant, elles ont des philosophies de conception et des spécialités différentes.
La principale différence est la suivante :
- Butteraugli (par Google) est un modèle psychophysique. Il tente de modéliser le fonctionnement du système visuel humain (en particulier la perception des couleurs) pour trouver le seuil où les différences deviennent perceptibles.
- SSIMULACRA2 (par Cloudinary) est une métrique d'ingénierie "feature-based". Elle a été spécifiquement conçue pour détecter et pénaliser les artefacts de compression que les codecs modernes (AVIF, JXL, WebP) introduisent et que les humains trouvent gênants.
🦋 Butteraugli
Développé par Google, Butteraugli est un outil fondamental utilisé dans le développement de leurs codecs, notamment Guetzli et JPEG XL.
Avantages
- Modélisation psychophysique : C'est sa plus grande force. Il modélise en profondeur la sensibilité humaine à la couleur.
- Impériale sur la couleur : Butteraugli est extrêmement sensible à la dégradation de la chrominance (couleur), comme le bruit de couleur ou les bavures, auxquels l'œil humain est très attentif.
- Modélisation du masquage : Il est très bon pour comprendre si un artefact de compression est "caché" (masqué) par une zone de texture élevée, le rendant ainsi moins visible.
- Sortie de carte de chaleur : Plus qu'un simple score, il génère une "carte de chaleur" (heat map) qui montre où dans l'image il a trouvé des défauts perceptuels.
Inconvénients
- "Pardon" pour certains artefacts modernes : C'est son principal défaut par rapport à SSIMULACRA2. Des études ont montré qu'il pouvait être trop indulgent envers des artefacts comme le "smoothing" (lissage excessif des textures, donnant un aspect "plastique") ou le "ringing" (halos près des bords), qui sont courants dans les codecs comme AVIF ou WebP.
- Vitesse de calcul : Il est assez lent. Il est plus rapide que les métriques de deep learning (comme DISTS), mais nettement plus lent que SSIMULACRA2.
- Conçu pour la haute qualité : Il a été principalement optimisé pour le seuil de "différence à peine perceptible" (JND - Just Noticeable Difference), ce qui le rend excellent pour le "visuellement sans perte", mais potentiellement moins précis pour des compressions de qualité moyenne ou basse.
🚀 SSIMULACRA2
Développé par Jon Sneyers (Cloudinary), SSIMULACRA2 est une évolution de métriques antérieures (MS-SSIM, SSIMULACRA) spécifiquement affinée en utilisant des tests subjectifs pour corriger les échecs des autres métriques.
Avantages
- Meilleure corrélation subjective (pour la compression) : C'est l'argument principal. Dans les benchmarks publics comparant les scores des métriques aux notes données par les humains, SSIMULACRA2 l'emporte très souvent.
- Spécialiste des artefacts modernes : Il est conçu pour "chasser" les défauts que Butteraugli et d'autres ignorent. Il est excellent pour pénaliser :
1/ Le "ringing" (halos).
2/ Le "smoothing" (perte de texture / aspect "plastique").
3/ Le "banding" (bandes dans les dégradés de couleur).
- Vitesse : Il est nettement plus rapide que Butteraugli, en particulier sur GPU, ce qui le rend plus pratique pour les tests à grande échelle.
- Bon équilibre : Il analyse la structure, les bords et les textures à plusieurs échelles (multi-scale) pour obtenir son score, ce qui le rend très robuste.
Inconvénients
- Moins "fondamental" : Il s'agit moins d'un modèle pur du système visuel humain que d'un outil d'ingénierie hautement optimisé. Il est "entraîné" sur ce qui déplaît aux humains dans la compression.
- Moins sensible à la couleur que Butteraugli : Bien que très compétent, il est généralement admis que Butteraugli reste le "gold standard" si votre préoccupation unique est la fidélité absolue des couleurs.
✅ Lequel choisir ?
- Utilisez SSIMULACRA2 si votre objectif principal est de comparer différents codecs (AVIF, JXL, WebP) ou différents réglages pour savoir lequel produit l'image perçue comme la meilleure par un humain. C'est actuellement la métrique de référence pour le benchmarking de compression.
- Utilisez Butteraugli si vous développez un nouveau codec et que vous avez besoin d'un modèle psychophysique robuste, ou si votre priorité absolue est de garantir la fidélité des couleurs et d'éviter les seuils de différence à peine perceptibles.