Auteur Sujet: Liste des formats d’image et de leurs fonctionnalités (Lu 42895 fois)

MaxLebled · « **Réponse #60 le:** 06 mai 2024 à 12:02:37 »

Il ne faut pas oublier que ça n'est pas qu'une histoire de couleurs, mais aussi de luminosité. Les gradations sont beaucoup plus susceptibles d'être visibles avec une précision de 8 bits par couleur (24 bits au total), surtout si un traitement est appliqué à l'image.

Jetez un coup d'œil à ces pages : http://www.lagom.nl/lcd-test/black.php & http://www.lagom.nl/lcd-test/gradient.php

Si vous faites un zoom sur le dégradé, je suis certain que vous arriverez à faire la distinction entre chaque bande.

On doit actuellement utiliser du dithering (diffusion d'erreur) pour pallier à ce manque de précision. Exemples visuels : https://en.wikipedia.org/wiki/Dither#Examples_2

vivien · « **Réponse #61 le:** 01 août 2024 à 08:56:40 »

Un an plus tard, toujours pas de changement de position de Google sur JPEG XL pour sa prise en charge dans Chrome / Chromium / Android : Google bloque la prise en charge de JPEG XL (aujourd'hui supporté uniquement par Safari ; Firefox a annoncé le prendre en charge si Google le prend en charge)

Citation de: vivien le 20 août 2023 à 14:28:24

Un bug Chromium a été ré-ouvert depuis quelques semaines pour demander à Google de revoir sa positon sur JPEG XL, avec un argument fort : Apple va prendre en jarge JPEG XL dans iOS 17 et la prochaine version de macOS. Pas avec un flag expérimental, mais activé par défaut (cf Safari 17 Beta Release Notes).

Il reste à observer la position de Firefox qui est aujourd'hui neutre sur le sujet.

Personnellement, je suis convaincu que JPEG XL a des atouts pour réussir la transition et remplacer complétement les vieux formats JPEG / PNG / GIF, tache que WebP ou AVIF ne pourront pas réussir, en tant que format uniquement Web.

Oui, les performances de compression de JPEG XL sont proches de AVIF, mais pour moi, il faut reconsidérer la question AVIF : Ce format (toujours pas pris en charge par Microsoft Edge) peut être sauté et les sites web passant alors directement de WebP à JPEG XL.

Je vois les choses de la sorte pour les formats d'image Web :
- 1ʳᵉ génération : JPEG, PNG, GIF
- 2ᵉ génération : WebP
- 3ᵉ génération : AVIF, JPEG XL

On a deux formats de 3ᵉ génération et JPEG XL est meilleur que AVIF, alors pourquoi ne pas partir sur lui ?

vivien · « **Réponse #62 le:** 03 août 2024 à 09:29:17 »

J'ai fait un test avec une série de 28 images représentatif du forum et le réglage qualité excellente du tableau ci-dessous :

Jpeg : 7,9 Mo (qualité paramétrée sur 80)
WebP : 4,7 Mo (qualité paramétrée sur 82)
AVIF : 3,6 Mo (qualité paramétrée sur 64)

Normalement, c'est censé produire des images de qualité très proche.

Si vous trouvez d'autres comparatifs sur les paramétrages à faire pour avoir une qualité d'image équivalente sur les formats Jpeg / WebP / AVIF, je suis preneur.

C'est une question que l'on se pose dès qu'on utilise un nouveau format : quel niveau de qualité paramétrer (sachant qu'un niveau 70 en Jpeg et un niveau 70 en AVIF ne donne pas du tout la même qualité d'image, le réglage est propre à chaque format d'image).

Citation de: vivien le 28 août 2023 à 20:44:52

Malte Ubl a réalisé une comparaison avec 3 images : Il a généré des images JPEG, AVIF et WebP de différentes tailles et avec une multitude de paramètres de qualité. Il a ensuite utilisé l'algorithme DSSIM pour calculer la différence visuelle entre chacune de ces images et les images source. Les scripts nécessaires sont sur ce projet GitHub.

Il a ensuite rapproché le paramètre de qualité qui permet d'avoir une même note DSSIM. Cela donne le tableau suivant :

Source : Industrial Empathy, le 20 février 2021

rooot · « **Réponse #63 le:** 05 août 2024 à 08:32:52 »

est-ce que dans les metadonnées de l'image on retrouve le parametre de compression qui a été appliqué à l'image ?

vivien · « **Réponse #64 le:** 05 août 2024 à 08:57:32 »

Non, ce n'est pas affiché.

Il est par contre possible de faire des tests pour tenter de retrouver le paramètre, si on a le fichier original.

Sur un site web qui diffuse des images AVIF, il y a également des images JPEG en fallback. Ce sont ces images qui sont utilisées en source : il est donc possible de vérifier avec quelques tests quel est le paramètre de compression.

Sur certains sites web, tu as une URL en .jpeg mais tu récupères un .webp ou un .avif car il a détecté un navigateur compatible.

Pour récupérer le JPEG 2 solutions :
- Utiliser une extension qui va retirer WebP / AVIF de la liste des formats acceptés mentionnés dans les requêtes GET
- Utiliser wget ou curl en ligne de commande pour récupérer le fichier.

fred_mgnt · « **Réponse #65 le:** 10 août 2024 à 03:55:20 »

pas certain que ce « taux de compression » ou « de qualité » soit vraiment fiable et identiques d’un encodeur/logiciel à un autre et donc que ça soit comparable.

vivien · « **Réponse #66 le:** 10 août 2024 à 08:05:28 »

Pour WebP, il me semble qu'il n'y a qu'un seul encodeur : libwebp
Pour JPEG et AVIF il y a plusieurs encodeurs disponibles, mais le paramètre de qualité ne serait pas comparable ?

Le tableau suivant a été réalisé par Malte Ubl par une comparaison avec des images JPEG, AVIF et WebP de différentes tailles et avec une multitude de paramètres de qualité. Il a ensuite utilisé l'algorithme DSSIM pour calculer la différence visuelle entre chacune de ces images et les images source.

Il a ensuite rapproché le paramètre de qualité qui permet d'avoir une même note DSSIM. Cela donne le tableau suivant :

Source : Industrial Empathy, le 20 février 2021

Malheureusement, j'ai testé sur des copies d'écran (avec du texte) et en utilisant GIMP pour compresser mes images. Je vois de nettes différences (je regarde en zoom 400% pour comparer les compressions).

En qualité JPEG 80, on voit de gros défauts autour de chaque lettre du texte.
En WebP 82, ces défauts existent à peine, c'est vraiment propre en WebP 82.
En AVIF 64, j'ai halluciné : C'est propre comme une compression sans perte. Il y a bien des différences de couleur entre certains pixels, mais les pixels blancs autour des lettres restes tous blancs. Je n'ai pas été en mesure de déterminer en comparaison à l'aveugle qu'est l'original et quelle est la compression AVIF.

De plus sur les copies d'écran, AVIF est très efficaces, Il divise par 3 la taille par rapport à du WebP, alors qu'habituellement sur des photos la différence WebP / AVIF est bien plus faible (toujours en prenant les paramètres de ce tableau, pour l'instant je n'ai pas d'autre référentiel)

L'algorithme DSSIM est donc insuffisant pour comparer la qualité, notamment sur du texte.

Ensuite, autre information de mes tests, la compression AVIF semble moins intéressante pour les images de toute petite taille (images de moins de 1 Ko que vous trouvez en nombre sur la page d'accueil de LaFibre.info)

vivien · « **Réponse #67 le:** 06 septembre 2024 à 08:40:51 »

Mozilla s'intéresse à un décodeur JPEG-XL Rust pour Firefox et Google pourrait le développer

Mozilla est intéressé par un décodeur d'image JPEG-XL écrit en Rust pour ses caractéristiques de sécurité mémoire par rapport au code C++ existant sur lequel ils s'appuient pour la prise en charge des images JPEG-XL dans Firefox. Alors que Google a précédemment supprimé la prise en charge JPEG-XL de Chrome/Chromium, il se peut que ce soit Google qui vienne à la rescousse et écrive un décodeur d'image JPEG-XL basé sur Rust qui peut ensuite être livré par Firefox.

Bobby Holley, le directeur technique de Firefox chez Mozilla, a exposé hier sa position en faveur d'un éventuel décodeur d'image JPEG-XL basé sur Rust pour Firefox. Au référentiel des positions standards de Mozilla, il a commenté dans une nouvelle demande d'extraction " Firefox envisagera une implémentation Rust de JPEG-XL " avec l'explication suivante :

« Au cours des derniers mois, nous avons eu des conversations productives avec l'équipe JPEG-XL de Google Research sur l'avenir du format dans Firefox. Notre principale préoccupation a longtemps été la surface d'attaque accrue du décodeur de référence (actuellement derrière un pref dans Firefox Nightly), qui pèse plus de 100 000 lignes de C++ multithread. Pour répondre à cette préoccupation, l'équipe de Google a accepté d'appliquer son expertise en la matière pour créer un décodeur JPEG-XL sûr, performant, compact et compatible dans Rust, et intégrer ce décodeur dans Firefox. S'ils parviennent à fournir une implémentation qui satisfait ces propriétés et répond à nos exigences de production normales, nous la livrerons.

Le temps nous dira si le format réussit à devenir un remplacement universel du JPEG comme certains l'espèrent. Dans le cas où il le ferait, il serait regrettable d'introduire potentiellement des vulnérabilités de sécurité de la mémoire dans la myriade d'applications qui auraient éventuellement besoin de le prendre en charge. Un décodeur Rust sûr, rapide et testé au combat de l'équipe d'origine pourrait rendre ce scénario beaucoup moins probable, et nous utilisons donc notre influence pour encourager les progrès sur ce front.

Très intéressant, surtout si l'on considère l'histoire passée de JPEG-XL et de Chrome. Mais si Google investit dans l'écriture d'un décodeur JPEG-XL basé sur Rust, il sera intéressant de voir s'ils vont de l'avant et reconsidérer leur prise en charge des images dans Chrome. Sinon, il serait plutôt ironique que Google développe ce décodeur JPEG-XL basé sur Rust uniquement pour être utilisé par Firefox et d'autres logiciels non Google.

Quoi qu'il en soit, nous verrons ce qui se passera sur ce front au cours des prochains mois.

Source : Phoronix, Écrit par Michael Larabel le 4 septembre 2024, traduit par Vivien

Cochonou · « **Réponse #68 le:** 10 octobre 2024 à 06:39:18 »

l'iPhone 16 Pro supporte désormais la prise de photos en format JPEG XL... mais juste pour les sauvegardes RAW (et encapsulées dans un container DNG).

vivien · « **Réponse #69 le:** 10 octobre 2024 à 08:46:38 »

C'est du JPEG-XL Lossless (sans perte) qui est utilisé, c'est bien ça ?

Cela remplace le format RAW propriétaire ?

Coté Google, la demande pour rajouter le support de JPEG-XL à Chrome n'avance pas : https://issues.chromium.org/issues/40270698

Cochonou · « **Réponse #70 le:** 10 octobre 2024 à 08:54:48 »

Visiblement il y a le choix entre lossy et lossless, ce qui est surprenant pour du RAW. La compression lossy doit avoir été paramétrée pour avoir très peu de perte de qualité.

vivien · « **Réponse #71 le:** 10 octobre 2024 à 09:20:51 »

Étonnant.

Je regrette également qu'Apple ne permette pas de sélectionner le codec vidéo séparément du format d'image pour les photos.

Ma femme reste en JPEG pour les photo pour des raisons de compatibilité (HEIC étant assez peu pris en charge), mais elle aimerait bien avoir HEVC pour les vidéos.