Auteur Sujet: Guerre des codecs: qui va l'emporter entre AV1 vs HEVC/H.265 ? Probablement AV1 (Lu 154675 fois)

hwti · « **Réponse #312 le:** 01 novembre 2025 à 19:17:01 »

Citation de: MaxLebled le 01 novembre 2025 à 17:17:28

Ces SVG ne devraient pas, en soi, mettre le banding en évidence. C'est surtout le deuxième qui permettra de le distinguer. Mais in fine ça va dépendre du moteur de rendu et de l'affichage derrière. Je ne suis pas sur mon écran principal OLED qui sait afficher du 10-bit actuellement (je suis sur une tablette "normale") donc je vois un peu de banding. Mais ça va... un peu de dithering (diffusion d'erreur avec "bruit bleu" et ça serait très propre.

Je pense que Vivien parle de générer des AVIF 8/10 bits à partir des SVG, pour comparer les deux, avec le SVG en référence.
Mais effectivement le rendu du SVG peut être fait en 8 bits ou 10 bits selon l'application et l'écran, sans compter qu'un écran 8 bit peut être 6 bits + FRC, et un écran 10 bits peut être 8 bits + FRC.

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

Oui, il est plus simple de comparer l'encodage 8 bits vs 10 bits et 12 bits sur des images. On pourra le faire ensuite en vidéo, mais c'est plus compliqué.

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

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 #314 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 #315 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 #316 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 #317 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 #318 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 #319 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.

vivien · « **Réponse #320 le:** **Hier** à 22:27:43 »

Je découvre qu'en important un SVG dans GIMP, on reste à 8 bits / couleur :

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.