La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: vivien le 19 août 2023 à 16:03:28
-
Vous êtes plutôt JPEG XL, AVIF, HEIC ou WebP ? Je vous explique les nouveaux formats d'image et leurs enjeux
(https://lafibre.info/images/logo/logo_format_images.webp)
Cela va choquer les plus jeunes, mais le format Jpeg n'a pas toujours existé.
De nombreux formats d'image numérique ont été développés. Ils n'avaient pas tous de la compression et quand ils avaient de la compression, elle était peu efficace, pourtant, on avait à l'époque des petits disques dur et pour transférer des documents, la disquette se limitait à 1,44 Mo. C'est pour cela que la limitation du GIF à 256 couleurs n'était problématique : même si les autres formats proposaient plus de couleurs, il était rare que cela soit utilisé.
Pour les photos, le JPEG règne encore aujourd'hui en maitre, mais il est maintenant obsolète et plusieurs formats veulent prendre sa succession, dont JPEG XL qui cumule les avantages avec peu d'inconvénients, à part sa prise en charge par les navigateurs qui se fait attendre.
J'ai mentionné la taille maximum de l'image en pixel, car c'est un point problématique pour plusieurs formats récents comme le WebP, HEIC ou l'AVIF : Ce sont des formats conçus pur internet, mais leur limitation en termes de taille qui vient des codecs vidéo dont ils sont issus pose un problème pour remplacer définitivement sur les appareils photo numériques.
Liste des formats d’image populaires et leurs fonctionnalités
Cliquer sur l'image pour zoomer :
(https://lafibre.info/images/format/format_image_populaire.webp) (https://lafibre.info/images/format/format_image.pdf#page=2)
Liste de presque tous les formats d’image et leurs fonctionnalités
Cliquer sur l'image pour zoomer :
(https://lafibre.info/images/format/format_image.webp) (https://lafibre.info/images/format/format_image.pdf)
Note : Pour la prise en charge par les navigateurs web, j'ai intégré les 3 annonces suivantes :
- Support du format HEIC par Safari 17 (sorti en septembre 2023)
- Support du format JPEG-XL par Safari 17 (sorti en septembre 2023)
- Support du format AVIF par Microsoft Edge 121 (sorti en janvier 2024)
-
Quelques détails sur les principaux formats d'image :
(https://lafibre.info/images/format/logo_jpeg_xl.svg)
JPEG XL est un format ouvert et libre de droits qui permet la compression d’images fixes avec ou sans perte de qualité. JPEG XL n'est pas basé sur un codec vidéo comme AVIF (AV1), HEIC (HEVC), BPG (HEVC), Webp (VP8) ou AVCI (H.264). JPEG XL est une combinaison de deux formats d'images récents : Pik et FUIF (ne les cherchez pas dans le tableau, ils n'ont pas été publiés, ils ne sont donc pas présents). FUIF intègre lui-même les travaux de FLIF qui est lui dans mon tableau.
Compression : JPEG XL compresse de 10 à 15 % de plus que AVIF, à des réglages de vitesse d'encodeur où l'encodage JPEG XL est d'environ trois fois plus rapide qu'AVIF. Les gains de compression sont bien sûr plus élevés par rapport à WebP (environ 20 à 25%) et MozJPEG (environ 30 à 35% - notez que MozJPEG étant lui-même 10 à 15% meilleur que les encodeurs JPEG typiques comme libjpeg- turbo). Source (https://cloudinary.com/blog/the-case-for-jpeg-xl)
JPEG XL est conçu pour être plus efficace que les formats existants et il intègre toutes les fonctionnalités de l'AVIF. JPEG XL vise à remplacer les formats existants pour tous les usages courants (et pas uniquement pour le web). Ci-dessous, je vais comparer JPEG XL à son plus proche concurrent AVIF.
Dimension maximale : JPEG XL a une dimension maximale de 1 152 921 502 459 mégapixels ou plus de 1 milliard de pixels de chaque côté d'une image. AVIF a une résolution maximale de 8192 x 4352 pixels. En tant que format d'image basé sur une image vidéo, la limite de résolution est parfaitement logique. Il est possible de dépasser cette limite grâce au carrelage : les tuiles codées indépendamment peuvent ensuite être placées sur une grille pour créer une résolution maximale théorique de 2 147 483 647 x 2 147 483 647 pixels ou 2 500 mégapixels. Cependant, lorsque vous utilisez cette méthode, vous obtenez des artefacts sur les bords de chaque mosaïque encodée, ce qui rend AVIF globalement inadapté aux images à ultra-haute résolution.
Profondeur des couleurs : La profondeur de bits maximale de JPEG XL peut pousser jusqu'à 24 bits entiers ou couleurs vraies, ou 32 bits flottants. AVIF a une profondeur de couleur maximale de 12 bits, mais en réalité, pour les images, la précision des couleurs sur 12 bits est suffisante (JPEG ou WebP, c'est 8 bits par couleur). Il est peu probable la prise en charge de la profondeur de bits élevée de JPEG XL soit utilisée, l’œil humain ne pouvant pas différencier ces couleurs supplémentaires.
Nombre de canaux : JPEG XL supporte jusqu'à 4 099 canaux : trois canaux pour le RVB ou quatre canaux pour le CMJN (autre façon de coder la couleur, plutôt utilisés par les graphistes). Le reste des canaux en tant que canaux supplémentaires peuvent être utilisés pour la transparence (canal alpha), coder la profondeur de l'image ou des données thermiques. AVIF a un nombre maximal de canaux de trois + transparence. JPEG XL permet donc des usages avancés que AVIF ne permet pas.
Une caractéristique unique de JPEG XL est qu'il est possible de recompresser des images JPEG existantes en un fichier JPEG XL qui est en moyenne environ 20 % plus petit, sans introduire de perte de qualité. Le même fichier JPEG au bit près peut être reconstruit à partir du fichier JPEG XL. Aucun autre format d'image n'a cette fonctionnalité. De nombreux sites web proposent des formats d'image évolués, en effectuant un transcodage vers le nouveau format (AVIF / WebP). Le transcodage est une opération quelque peu problématique, car dans tous les cas, il s'agit d'une opération avec perte de qualité, ajoutant plus d'artefacts de compression au-dessus du JPEG déjà avec perte de qualité. Le transcodage peut aussi être contre-productif : si vous sélectionnez une qualité de transcodage élevée, vous risquez de vous retrouver avec un fichier AVIF / WebP plus volumineux que le JPEG avec lequel vous avez commencé ! Si la qualité de transcodage est suffisamment faible, vous réduisez la taille du fichier, mais cela se fera au prix d'artefacts de compression supplémentaires. Il est difficile d'automatiser un tel processus de transition de manière à éviter ces problèmes. Sur LaFibre.info, la qualité de compression des fichiers WebP varie selon le type (s'il y a du texte sur l'image, j'augmente la qualité, car c'est là que c'est le plus visible) et de la source (une image JPEG recompressée par twitter est fortement compressée, si je l'enregistre en WebP avec mon paramétrage habituel de qualité, elle augmente de taille. Je laisse donc le JPEG d'origine ou je mets une qualité plus basse.
Le support préliminaire de JPEG XL est introduit dans GIMP 2.10.32 en juin 2022 (compression uniquement avec perte de qualité, sans possibilité de régler la qualité de l'image).
(https://lafibre.info/images/format/logo_avif.svg)
AVIF (AV1 Image File Format) est un format d'image ouvert et libre de droits qui utilise l'algorithme de compression pour les images clés de l'AV1. Il est supporté par tous les navigateurs (sauf Edge, mais AVIF devrait arriver dans Edge à la fin 2023). Il est pris en charge également par les systèmes d’exploitation récents (par exemple à partir d'Android 12, macOS 13).
AVIF supporte :
- Des espaces de couleur multiples HDR, SDR ou avec l'indication de l'espace de couleur par des profils CICP ou ICC ;
- La compression avec ou sans perte de qualité ;
- Le canal alpha qui indique le degré de transparence de chaque pixel de l'image ;
- Des animations (il remplace donc le GIF) ;
- Une profondeur de couleur de 8, 10 ou 12 bits par couleur primaire (le Jpeg et WebP sont à 8 bits) ;
- Les couleurs monochromes ;
- Le sous-échantillonnage de la chrominance 4:2:0, 4:2:2, 4:4:4 qu'il manque à WebP et le RGB ;
- Compatible avec la granularité des films photo.
(https://lafibre.info/images/format/logo_heic.webp)
HEIC (High Efficiency Image File Format) est un format d'image qui utilise l'algorithme de compression pour les images clés de l'HEVC, il a été développé par le Moving Picture Experts Group. HEVC et donc HEIC dépend de plusieurs brevets et est donc soumis à des royalties, ce qui l’exclut de fait des logiciels libres. Il n'est supporté que par Safari, pour les versions sorties fin 2023. Apple l'a déployé en 2017 comme format par défaut pour les photos avec iOS 11, et le présente comme deux fois plus petit qu'une image équivalente en JPEG. HEIC est peu utilisé hors de l'écosystème Apple. Certains appareils photo de chez Canon et Sony proposent l'enregistrement en HEIC, en plus du JPEG et du RAW.
(https://lafibre.info/images/logo/logo_webp.svg)
WebP est un format d'image ouvert et libre de droits qui utilise l'algorithme de compression pour les images clés du VP8 pour la compression avec perte de qualité, il a été développé par Google. Il permet la compression avec perte ou sans perte de qualité et gère les animations. WebP prend également en charge les métadonnées EXIF et XMP, les profils de couleur ICC et la transparence alpha. Le support de WebP par les navigateurs s'est généralisé en 2021 (pour Safari, macOS Big Sur est un prérequis). C'est le format d'image le plus efficace supporté par l'ensemble des navigateurs. WebP vise à remplacer sur internet les formats JPEG, PNG et GIF. WebP ne vise pas à remplacer le Jpeg sur l'ensemble de la chaine de photographie du fait de limites :
- Le nombre de pixels d'un côté de l'image qui ne peut dépasser 16 383 pixels, ce qui est relativement peu (le vieux JPEG permet un maximum de 65 536 pixels par côté)
- WebP ne prend en charge que le sous-échantillonnage des couleurs 420. WebP ne permet pas le du sous-échantillonnage des couleurs 444 pour avoir des images de haute qualité avec un encodage avec perte de qualité. Le choix du sous-échantillonnage 420, par rapport au format 444 original, réduit de moitié le nombre d'échantillons (en comptant sur les 3 plans de couleur) qui doivent être encodés tout en s'appuyant sur le fait que le système visuel humain est plus sensible à la luminance qu'à la chrominance. Dans la grande majorité des images, la perte due au sous-échantillonnage 420 n'est pas évidente à la perception humaine, cependant, le sous-échantillonnage 420 peut introduire des saignements de couleur et des irrégularités dans les emplacements avec des transitions de couleur. Une photo avec du texte rajouté dessus peut avoir intérêt à être en encodée en sous-échantillonnage des couleurs 444. Idéalement, un format d'image devrait pouvoir prendre en charge les deux sous-échantillonnages (le choix se ferait manuellement au moment de l'encodage afin d'optimiser la qualité par rapport à la taille du fichier). Le vieux JPEG permet 420, 422 et 444 et certains logiciels comme GIMP permettent au client de sélectionner le sous-échantillonnage des couleurs.
On note toutefois que le support de WebP va au-delà du web : WebP est pris en charge par Office 365 depuis fin 2021 et depuis LibreOffice 7.4 (sorite en 2022). La plupart des logiciels de retouche d'image (même le Paint livré avec Windows) savent lire WebP. Les incompatibilités WebP sont uniquement avec les logiciels anciens (dont la version majeure est sortie avant les années 2020, date de la généralisation de WebP).
Comparaison du support par navigateur de WebP et AVIF :
(https://lafibre.info/images/format/webp_avif_support.webp)
-
On continue avec les formats plus anciens :
(https://lafibre.info/images/format/logo_svg.svg)
SVG (Scalable Vector Graphics) est le principal format d’image vectoriel utilisé sur internet. SVG est développé par le World Wide Web Consortium et il est pris en charge par tous les navigateurs web. Les coordonnées, dimensions et structures des objets vectoriels sont indiquées sous forme numérique dans le document XML.
Les images SVG sont nettes, y compris si elles sont imprimées sur de grands supports. C’est un atout important face aux formats matriciels. Les images simples à représenter sous forme de vecteur sont également plus légers qu’un format matriciel, bien que la comparaison ne soit pas simple : lors d’une conversion en matriciel, il faut spécifier les dimensions de l’image, qui vont caractériser sont poids.
Si du texte est intégré dans une image vectorielle, il fait généralement appels aux polices de caractères. Contrairement au format PDF qui intègre habituellement les polices de caractères nécessaires, SVG va faire appel aux polices système et les polices de caractères intégrées dans un système d’exploitation ne sont pas les mêmes d’un terminal à un autre.
Exemple concret : Une même image vectorielle voit son texte changer selon le terminal : (Ce sont deux copies d'écran assemblées d'une image vectorielle, comme toute copie d'écran, c'est donc une image matricielle, au format WebP animé, qui est représentée ci-dessous)
(https://lafibre.info/images/doc/202107_arcep_rapport_etat_internet_2021_4_neutralite_4.webp)
Afin d’éviter ces problèmes, il est conseillé de convertir les objets texte en chemin : Les caractères seront alors définis par des vecteurs, comme le reste de l’image.
(https://lafibre.info/images/doc/202302_svg_inkscape_objet_en_chemin.webp)
Le format SVG permet également d’intégrer dans une image vectorielle des images matricielles : C’est utile pour intégrer une partie complexe à représenter sous forme de vecteur ou tout simplement un logo ou une image disponible uniquement au format matriciel. Cette intégration du matriciel dans du vectoriel génère également des incompatibilités.
Le format SVG peut héberger des scripts ou des CSS. Outre des problèmes de compatibilité, cela peut entrainer des risques de sécurité, avec un fichier SVG piégé et qui contient du contenu malveillant.
Différentes versions : Contrairement aux formats matriciels qui sont figés, SVG évolue. La version 1.1 actuelle va évoluer vers une version 2. Il est possible que des problèmes de compatibilité puissent apparaitre quand un terminal qui ne prend en charge que la version 1.1 doit afficher une image de la version 2.
(https://lafibre.info/images/format/logo_jpeg_xr.svg)
JPEG XR est un format d'image ouvert et libre de droits développé par Microsoft (Microsoft ne touche pas de redevances). Il permet la compression avec perte ou sans perte de qualité. Il a été examiné et adopté comme standard en novembre 2007 par le Joint Photographic Expert Group (JPEG), sous le nom de JPEG XR. Il est supporté par Internet Explorer 9 à 11 et Edge 12 à 18. Les autres navigateurs ne prennent pas en charge ce format qui n'est pas utilisé sur Internet.
(https://lafibre.info/images/format/logo_jpeg_2000.svg)
JPEG 2000, fichiers en .jp2 (part1) ou .jpx (part2 datant de 2004) est reconnu par l'ISO / CEI et l'UIT-T sous le code ISO/IEC CD 15444 en 2015. Le JPEG 2000 permet une légère augmentation des performances de compression par rapport à JPEG (+20%, il est clairement moins bon que WebP, HEIF et AVIF). Le principal avantage offert par JPEG 2000 est le fait que le flux codé après compression est de nature évolutive, ce qui signifie qu'il peut être décodé de plusieurs façons. En tronquant le flux codé en tout point, on peut obtenir une représentation de l'image à une résolution inférieure, sans avoir à le recompresser. Cependant, en raison de cette flexibilité, JPEG 2000 nécessite des codecs qui sont complexes et exigeants en termes de calcul. JPEG 2000 fournit à la fois une compression sans perte de qualité (comme le PNG) et avec perte de qualité (comme le JPEG). JPEG 2000 n'est pas pris en charge par les navigateurs, sauf Safari.
(https://lafibre.info/images/format/logo_png.svg)
PNG (Portable Network Graphics) propose une compression non destructive. PNG est donc complémentaire des formats d'image JPEG : Il vise à améliorer le GIF et prendre bien moins de place que le BMP. Il gère également la transparence, comme le GIF. Par contre, la transparence a mis du temps à être intégré dans certains navigateurs : Internet Explorer 6, sorti le 27 août 2001, gère le format PNG, mais la transparence n'est pas complètement implémentée. Contrairement au GIF, le PNG ne gère pas les animations, le format GIF n'est pas par totalement remplacé : Le GIF restera utilisé pour les animations.
(https://lafibre.info/images/format/logo_jpeg.svg)
JPEG (acronyme de Joint Photographic Experts Group) est une révolution : il permet d'avoir des photos avec de nombreuses couleurs et un poids raisonnable. Les brevets de son algorithme de codage arithmétique sont détenus par IBM et Mitsubishi électrique. Le premier navigateur web à avoir supporté le JPEG est Netscape Navigator en 1994. Le JPEG s'est imposé en remplaçant les autres formats, pour tout ce qui est photographies.
XBM (X BitMap) : Format ouvert et libre de droits d'image monochrome en texte brut conçu pour les icônes et pointeur du système X Window. Les données d'image sont codées sous la forme d'une liste de valeurs d'octets séparées par des virgules, chacune écrite dans la notation hexadécimale, les fichiers sont donc plus volumineux que le format BMP, mais les données XBM peuvent être intégrées directement dans les fichiers sources d'une application écrit en C sans aucune étape de prétraitement. Ce format (non propriétaire) a été utilisé sur les premières pages web avec le GIF qui est propriétaire. Le support de XBM a été enlevé avec Internet Explorer 6 et Mozilla Firefox 3.6.
GIF (Graphics Interchange Format) : Format soumis à un brevet à l'époque est mis au point en 1987 par le groupe CompuServe, pour permettre le téléchargement d'images en couleur sur internet. Il est limité à une palette de 256 couleurs, qui convenait à l'époque aux débits de quelques kilobits par seconde de l'internet de l'époque. Le GIF a la particularité de gérer la transparence et d'être resté pendant de multiples années comme le seul format à prendre en charge les animations (il faut attendre 2022 pour qu'un autre format propose des animations sur tous les navigateurs : le format WebP). À noter que certaines petites vidéos appelées 'GIF' dans les années 2020 sont en réalité des vidéos H.264 ou VP9 afin de limiter la taille et améliorer la qualité (+ de 256 couleurs).
Exemple de GIF sur twitter : Ce fichier de 85 Ko est en réalité une vidéo encodée en H.264 avec 3,8 images par seconde sans aucun flux audio.
https://lafibre.info/videos/datacenter/201807_netalis_visite_interxion_par5_1.mp4
(https://lafibre.info/images/format/logo_tiff.svg)
TIFF Le format TIFF est un format de compression avec ou sans perte de qualité, largement pris en charge par les applications de numérisation, de télécopie, de traitement de texte, de reconnaissance optique de caractères, de manipulation d'images, de publication assistée par ordinateur et de mise en page. Le format a été créé par Aldus Corporation pour être utilisé dans la publication assistée par ordinateur. TIFF est un format complexe, définissant de nombreuses balises dont seules quelques-unes sont généralement utilisées dans chaque fichier. il permet d'utiliser de nombreux types de compression, avec ou sans perte de données : brut, PackBits, LZW, CCITT Fax 3 et 4, JPEG. Il accepte de nombreux codages des pixels, de 1 à 64 bits par pixel, signé ou non, ainsi que les formats en virgule flottante 32 et 64 bits définis par l'IEEE. Cela a conduit à des implémentations prenant en charge de nombreux sous-ensembles différents du format, une situation qui a donné lieu à la plaisanterie selon laquelle TIFF signifie des milliers de formats de fichiers incompatibles. La complexité de TIFF en fait un format difficile à sécuriser. C'est en exploitant des failles de TIFF qu'il est possible de débloquer des équipements tels que les PSP de Sony et des iPhone d'Apple afin de lancer du code non officiel qui permet de "rooter" l'équipement. TIFF n'est bien sûr disponible sur aucun navigateur web.
PCX (PiCture eXchange). Le format PCX était très populaire sur les premiers systèmes DOS et Windows. Contrairement à BMP, il permet une petite compression, à une époque où chaque Ko comptait. Toutefois, la compression est très rapide, peu exigeant en mémoire et peu efficace. Il n'est plus utilisé depuis de nombreuses années, mais j'ai encore sur mon disque de veilles images PCX. Gimp sait encore lire et même créer des images PCX. PCX n'a jamais été proposé sur les navigateurs web.
BMP (Windows bitmap) format ouvert développé par Microsoft et IBM. Aucune compression, les fichiers en couleur sont d'une taille énorme. Cela a été longtemps l'unique format de Paint, outil permettant de créer des images livré avec Windows. Les premières versions de Windows demandaient un fichier BMP pour faire une mosaïque en fond d'écran. Sa popularité est également liée à sa simplicité d'implémentation.
-
Certains formats n'apparaissent pas dans le tableau.
1/ Les formats de fichiers qui ne sont pas finalisés et probablement abandonnés :
WebP 2 est un format d'image développé par Google pour succéder à WebP, qui devait sortir en 2023, mais qui a été abandonné, car il n’apporte pas suffisamment d’avantages supplémentaires par rapport au format AVIF déjà pris en charge par presque tous les navigateurs web. WebP 2 permet une compression avec perte de qualité plus efficace ~ 30% meilleure que WebP, aussi proche que possible d'AVIF. L'objectif principal de ce nouveau format est d'atteindre des taux de compression similaires à AVIF, tout en restant plus rapide à encoder et à décoder. WebP 2 supporte le HDR avec représentation des couleurs 10 bits, il propose une compression plus efficace des informations de transparence que WebP, la prise en charge complète de l'animation, le décodage incrémental (couche par couche avec plus de détails à chaque étape, permettant de générer très rapidement une vignette pour l'aperçu), encodage / décodage multithreads, minimisation de la dégradation visuelle à de faibles débits de bits et un mode de compression sans perte de qualité amélioré par apport à WebP.
HiFiC (High-Fidelity Generative Image Compression) : Recherche sur les formats d'image. Deux des 4 principaux auteurs sont de Google. Il est probable que ce format sera abandonné et le travail intégré dans un autre format.
La démonstration sur le site https://hific.github.io/ est assez bluffante, je vous invite à aller voir (il n'est pas nécessaire que votre navigateur sache lire le HiFiC).
FUIF (Free Universal Image Format) de Cloudinary. C'est un format d'image avec et sans perte complet et trés efficace. FUIF intègre les travaux du format Free Lossless Image Format (FLIF), un format de compression sans perte qui est lui dans mon tableau. Le développement de FUIF s'est arrêté depuis que FUIF est inclus dans JPEG XL, qui est basé sur une combinaison de Pik et FUIF. Source du projet : https://github.com/cloudinary/fuif
PIK de Google. Le développement de PIK s'est arrêté depuis que PIK est inclus dans JPEG XL. Source du projet : https://github.com/google/pik
2/ Les formats de fichiers pour la gestion par un éditeur d'image
Ce sont tous les formats d'image en haut de cette illustration, qui montre bien les différents périmètres des formats d'images populaires :
(https://lafibre.info/images/format/formats_images_par_perimetre.webp)
Source de l'illustration : Jon Sneyers, octobre 2022
RAW : Un fichier Raw contient les données brutes du capteur d'un appareil photo et les paramètres nécessaires à la transformation en fichier image. Le fichier RAW n'inclus pas les corrections des distorsions de l'objectif et tous les traitements réalisés par le processeur de l'appareil photo. Chaque marque et génération d'appareil photo a son propre format Raw propriétaire qui lui est spécifique. Un logiciel de lecture des fichiers Raw est compatible avec un nombre fini d'appareils photo et doit être mis à jour pour supporter de nouveaux modèles.
OpenEXR Format d'image libre destiné à stocker des images de haute qualité. Son créateur est la société d'effets spéciaux ILM qui l'utilise en interne pour stocker les films.
XCF (eXperimental Computing Facility) est un format d'image libre utilisé par GIMP. Il permet de sauvegarder un projet avec les informations cachées derrière un calque.
PSD (Photoshop Document) est un format propriétaire du logiciel Adobe Photoshop. Il permet de sauvegarder un projet. La popularité de Photoshop fait que d'autres outils peuvent lire les PSD, mais il y a souvent des pertes d'informations.
-
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
Source : Industrial Empathy (https://www.industrialempathy.com/posts/avif-webp-quality-settings/), le 20 février 2021
(https://lafibre.info/images/format/202308_compresssion_image_jpge_webp_avif_gimp.webp)
-
Les autres sujets en lien sur le forum :
- WebP, le nouveau format d'image qui devrait remplacer le Jpeg sur le web (https://lafibre.info/tv-numerique-hd-3d/webp-le-nouveau-format-dimage-qui-devrait-remplacer-le-jpeg/)
- AVIF, le format de fichier qui est plus efficace que WebP et JPEG (https://lafibre.info/tv-numerique-hd-3d/avif/)
Si la voiture ci-dessous s'affiche, votre navigateur sait lire les images AVIF (https://lafibre.info/images/format/202102_image_test.avif) :
(https://lafibre.info/images/format/202102_image_test.avif)
Si la voiture ci-dessous s'affiche, votre navigateur sait lire les images JPEG XL (https://lafibre.info/images/format/202102_image_test.jxl) :
(https://lafibre.info/images/format/202102_image_test.jxl)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en 16 couleurs (https://lafibre.info/images/format/image_test_bmp_16_couleurs.bmp) :
(https://lafibre.info/images/format/image_test_bmp_16_couleurs.bmp)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en couleurs 24 bits (https://lafibre.info/images/format/image_test_bmp_24bits_couleurs.bmp) :
(https://lafibre.info/images/format/image_test_bmp_24bits_couleurs.bmp)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en couleurs 32 bits avec transparence (https://lafibre.info/images/format/image_test_bmp_32bits_couleurs_transparence.bmp) :
(https://lafibre.info/images/format/image_test_bmp_32bits_couleurs_transparence.bmp)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, sans compression (https://lafibre.info/images/format/image_test_tiff_avec_transparence_sans_compression.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_sans_compression.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression LZW (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_lzw.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_lzw.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression Pack Bits (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_pack_bits.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_pack_bits.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression déflation (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_deflation.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_deflation.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression JPEG (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_jpeg.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_jpeg.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images XBM (https://lafibre.info/images/format/image_test_xbm.xbm) :
(https://lafibre.info/images/format/image_test_xbm.xbm)
-
En pratique, cela donne quoi ?
Sur le site HiFiC (High-Fidelity Generative Image Compression) (https://hific.github.io/) un format d'image qui n'est pas terminé (il n'apparait donc pas sur le tableau), on trouve des comparaisons.
J'ai repris une de leurs images de test et je l'ai compressé dans de nombreux codecs, avec Gimp.
C'est une compression un peu extrême (l'image compressée fait 8 Ko quel que soit le format utilisé), pour montrer graphiquement les différences entre format.
Les images JPEG, WebP et AVIF sont affichés directement dans ce format (les images font environ 8 Ko chacune).
Les images HEIC et HiFiC sont converties dans un format WebP sans perte, afin d'afficher le rendu exact de l'image d'origine qui fait entre 7 Ko et 8 Ko.
Image originale :
(https://lafibre.info/images/format/image_test_originale.webp)
Image compression JPEG de 8 Ko non optimisée :
(https://lafibre.info/images/format/image_test_jpeg_non_optimisee.jpg)
Image compression JPEG de 8 Ko : (c'est de meilleure qualité que celle proposée sur https://hific.github.io/, car j'ai utilisé les nombreux paramètres de GIMP pour optimiser la qualité du Jpeg, tout en restant à 8 Ko)
(https://lafibre.info/images/format/image_test_jpeg.jpg)
-
Image compression WebP de 8 Ko :
(https://lafibre.info/images/format/image_test_webp.webp)
Image compression HEIC de 8 Ko : (Si vous regardez la partie rouge du pull, on voit une nette différence par rapport à WebP)
(https://lafibre.info/images/format/image_test_heic.webp)
Image compression AVIF de 8 Ko : (on voit des défauts en bas de l'image, l'encodeur AVIF de GIMP n'est pas optimal et va être changé dans la prochaine version)
(https://lafibre.info/images/format/image_test_avif.avif)
Image compression HiFiC de 8 Ko : C'est clairement la meilleure qualité, observez le grain sur la peau
(https://lafibre.info/images/format/image_test_hific.webp)
Les compressions sont réalisées avec GIMP 2.10.34, sauf pour l'image HiFiC et l'image JPEG non optimisée, qui sont toutes les deux fournies par HiFiC.
Je referai des tests avec GIMP 3 qui il sera en release candidate, le format JPEG XL sera disponible et le format AVIF est grandement amélioré (la problématique de ces jeunes formats, ce que toutes les optimisations ne sont pas encore en place, alors que Jpeg et WebP sont matures aujourd'hui).
-
Chez moi la HiFiC ne fait pas 8Ko mais 436Ko (sur disque) quand l'original WebP en fait 428Ko.
L'image en HiFiC perd même en qualité.
-
Chez moi la HiFiC ne fait pas 8Ko mais 436Ko (sur disque) quand l'original WebP en fait 428Ko.
Toi tu n'as pas lu correctement :)
Les images HEIC et HiFiC sont converties dans un format WebP sans perte, afin d'afficher le rendu exact de l'image d'origine qui fait entre 7 Ko et 8 Ko.
-
Chez moi la HiFiC ne fait pas 8Ko mais 436Ko (sur disque) quand l'original WebP en fait 428Ko.
Aucun navigateur ne proposant HiFiC ou HEVC, après avoir créé les images HiFiC et HEVC, ces images ont été converties en WebP (mode compression sans perte) pour un affichage dans les navigateurs.
-
C'est noté :D
-
Vous exploitez un serveur web ?
N'oubliez pas de rajouter les nouveaux types MIME !
Si Ubuntu server 22.04 intègre déjà JPEG XL et AVIF, il lui manque WebP et les images AVIF animées.
Avec Ubuntu server 18.04 ou 20.04, il y a plus de lignes à rajouter sur votre serveur :
3/ Rajouter les types MIME (Multipurpose Internet Mail Extensions) pour les nouveaux formats d'images :
Nécessaire pour que les images (WebP et autres nouveaux formats d'images) s’affichent correctement, quand on fait "ouvrir l'image dans un nouvel onglet"). Sans cela, soit il affiche des hiéroglyphes (données brutes), soit il télécharge l'image (et affiche le file:// avec le lien vers l'image en local sur le PC).
Ubuntu 18.04 LTS et 20.04 LTS :
nano /etc/mime.types
copier / coller les lignes suivantes à la fin du fichier
image/webp webp
image/heif heif
image/heif-sequence heifs
image/avif avif hif
image/avif-sequence avifs
image/jxl jxl
Ubuntu 22.04 LTS :
nano /etc/mime.types
copier / coller les lignes suivantes à la fin du fichier
image/webp webp
image/avif-sequence avifs
Vérification : cat /etc/mime.types | grep -e "webp" -e "heif" -e "avif" -e "jxl" : Chaque type doit n'être listé qu'une seule fois.
-
Utilisateurs de Safari, il y a bien 3 images BMP qui sont visibles ?
Avec la dernière, il y a bien de la transparence ? Si oui, l'encadrement "avec transparence ici" doit être de la même couleur que le fond de la page (ce n'est pas du blanc, mais du bleu très doux)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en 16 couleurs (https://lafibre.info/images/format/image_test_bmp_16_couleurs.bmp) :
(https://lafibre.info/images/format/image_test_bmp_16_couleurs.bmp)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en couleurs 24 bits (https://lafibre.info/images/format/image_test_bmp_24bits_couleurs.bmp) :
(https://lafibre.info/images/format/image_test_bmp_24bits_couleurs.bmp)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en couleurs 32 bits avec transparence (https://lafibre.info/images/format/image_test_bmp_32bits_couleurs_transparence.bmp) :
(https://lafibre.info/images/format/image_test_bmp_32bits_couleurs_transparence.bmp)
-
Sur iPhone et Safari, oui les 3 images sont visibles, transparence OK.
-
Désolé, a priori Safari à un support de TIFF au moins partiel, cela serait possible de me dire si les 5 images TIFF suivantes s'affichent, elles ont chacune une méthode de compression différente :
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, sans compression (https://lafibre.info/images/format/image_test_tiff_avec_transparence_sans_compression.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_sans_compression.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression LZW (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_lzw.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_lzw.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression Pack Bits (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_pack_bits.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_pack_bits.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression déflation (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_deflation.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_deflation.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression JPEG (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_jpeg.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_jpeg.tiff)
-
J'ai aucune image sur firefox 118 ^^
-
Désolé, a priori Safari à un support de TIFF au moins partiel, cela serait possible de me dire si les 5 images TIFF suivantes s'affichent, elles ont chacune une méthode de compression différente :
Oui, elles s'affichent toutes sur Safari.
-
Toutes les images Ok (avec transparence) sur Safari macOS Sonoma beta.
-
Merci.
Un résumé de ce que j'ai compris :
Format BMP : Compatible avec tous les navigateurs, y compris Edge, sauf Internet Explorer
Format TIFF : Compatible avec aucun navigateurs sauf :
- Internet Explorer (mais pas Microsoft Edge)
- Safari sous macOS
- Tous les navigateurs sur iPhone / iPad
Su Safari macOS Sonoma bêta, cette image WebP s'affiche bien ?
Si la voiture ci-dessous s'affiche, votre navigateur sait lire les images JPEG XL (https://lafibre.info/images/format/202102_image_test.jxl) :
(https://lafibre.info/images/format/202102_image_test.jxl)
-
Chrome Android n'affiche pas la voiture :(
-
Safari iOS non plus ;)
-
Si la voiture ci-dessous s'affiche, votre navigateur sait lire les images JPEG XL (https://lafibre.info/images/format/202102_image_test.jxl) :
(https://lafibre.info/images/format/202102_image_test.jxl)
OK sous macOS Sonoma
-
Merci pour vos retours, j'ai corrigé le tableau récapitulatif. Le nom du fichier n'ayant pas changé, il est peut-être nécessaire de vider le cache de votre navigateur.
Je suis impressionné par le nombre de formats d'image supporté par Safari : 12 formats différents (pour Safari sous macOS Sonoma ou iOS 17) dont la majorité ne sont pas utilisés en pratique sur Internet (Safari étant le seul à supporter ces formats d'images). Cela contraste avec les codecs vidéos, où Safari est très limité, surtout sur iOS (H.264 et HEVC uniquement).
Cliquer sur l'image pour zoomer :
(https://lafibre.info/images/format/format_image.webp) (https://lafibre.info/images/format/format_image.pdf#page=2)
-
je profite zoc pour savoir si mon image est visible, car je l'ai enregistrée en JPEG XL
Désolé je viens juste de voir ton message (et je suis au bureau avec Edge...). Mais @Hugues à répondu du coup ;D
-
Quand on souhaite mettre en place WebP ou AVIF sur un site web, tout de suite se pose la question du paramétrage de la qualité pour convertir les images Jpeg en WebP et/ou AVIF.
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 (https://github.com/cramforce/avif-webp-quality-setting).
Il a ensuite rapproché le paramètre de qualité qui permet d'avoir une même note DSSIM. Cela donne le tableau suivant :
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
Source : Industrial Empathy (https://www.industrialempathy.com/posts/avif-webp-quality-settings/), le 20 février 2021
C'est bien, mais je ne trouve pas d'autres sources, si possible avec d'autres algorithmes et réalisé sur plus d'image pour confirmer les tests de Malte Ubl.
Si vous trouvez d'autres comparatif sur l'encodage des images JPEG, WebP et AVIF, je suis preneur.
-
Si vous trouvez d'autres comparatif sur l'encodage des images JPEG, WebP et AVIF, je suis preneur.
Il y a une comparison entre AVIF et WebP ici : https://www.ctrl.blog/entry/webp-avif-comparison.html
Et une autre entre WebP et JPEG/PNG avec des compresseurs les plus efficaces possibles (mais très lents) : https://www.ctrl.blog/entry/webp-vs-guetzli-zopfli.html (https://www.ctrl.blog/entry/webp-vs-guetzli-zopfli.html)
L'auteur était originellement assez critique envers WebP, mais il s'avère qu'activer une option de l'encodeur WebP donne de bien meilleurs résultats avec une taille de fichier à peine plus élevée : https://www.ctrl.blog/entry/webp-sharp-yuv.html (https://www.ctrl.blog/entry/webp-sharp-yuv.html)
-
Ce que je cherche, ce n'est pas trop un comparatif des formats abstrait, mais un comparatif du niveau de qualité : Si on souhaite avoir une image équivalent à la qualité JPEG 80, quel est le paramètre de qualité pour WebP et AVIF ?
J'ai trouvé que Malte Ubl qui a fait des tests que j'ai mis dans ce tableau, mais il doit y avoir d'autres tests, j'imagine, c'est une question importante pour ceux qui connaissent bien le paramétrage Jpeg.
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
-
Je suis impressionné par le nombre de formats d'image supporté par Safari : 12 formats différents (pour Safari sous macOS Sonoma ou iOS 17) dont la majorité ne sont pas utilisés en pratique sur Internet (Safari étant le seul à supporter ces formats d'images). Cela contraste avec les codecs vidéos, où Safari est très limité, surtout sur iOS (H.264 et HEVC uniquement).
La problématique de prendre en charge de nombreux formats d'image, c'est d'étendre la surface d'attaque.
Un bon exemple avec la faille WebP : Faille WebP CVE-2023-4863 exploitée par le logiciel espion Pegasus via iMessage (https://lafibre.info/attaques/webp-cve-2023-4863/)
-
Exemple de site web qui fait de l'AVIF avec un fallback JPEG :
- https://www.news18.com/
-
Exemple de site web qui fait de l'AVIF avec un fallback JPEG :
- https://www.news18.com/
Mais du coup ça demande de stocker sur les serveurs JPG + AVIF ! N’est-ce pas moi s energivore d’être en WebP only ?
-
Vaste question. Le problème se pose de façon bien plus compliquée pour la vidéo où on n'a aucun des formats récents pris en charge sur l'ensemble des terminaux.
- H.264 ⇒ pris en charge par l'ensemble des terminaux, mais H.264 a plus de 20 ans et n'est pas super efficace
- WebP ⇒ boycotté par Apple (aprés la prise en charge sur macOS, je pensais que cela arriverait sur iPhone, mais je me trompais)
- HEVC ⇒ problèmes de redevance qui bloque son implémentation, HEVC est par contre bien pris en charge coté Apple et TV
- AV1 ⇒ devait être le sauveur pris en charge par tout le monde, mais Apple a décidé de ne pas le décoder logiciellement, donc seul l'iPhone 15 est compatible.
Pour revenir sur les images, il y a des dizaines de milliers de sites web avec des images WebP avec un fallback JPEG : Il y a encore quelques années, WebP n'était pas pris en charge par l'écosystème Apple.
Sur le forum, je n'ai pas la possibilité de faire un fallback, donc je suis passé au WebP 2 ans après la prise en charge par Apple, c'est un peu rapide pour beaucoup de sites qui préfèrent attendre plus. Aujourd'hui cela fait 3 ans qu'Apple a pris en charge WebP et on commence à avoir des sites WebP only.
Aujourd'hui, fin 2023, un site web a donc deux possibilités :
- Partir uniquement sur du WebP
- Partir sûr de l'AVIF, plus efficace, mais avec un fallback JPEG (pour les sites non compatibles)
Pas simple de savoir lequel est le moins énergivore.
À noter Paulo, présent sur ce forum, qui site qui doit être une des rares site web (https://paulo-sc.com/) qui utilise de l'AVIF avec un fallback WebP :
(https://lafibre.info/images/format/202308_paulo_avif_fallback_webp.webp)
-
Le format JPEG XL n'est pris en charge que par iOS 17 et Safari sous macOS Sonoma.
Non l'image JPEG XL est visible chez moi (macOS Monterey 12.7 et Safari 17)...
Le gros clou dans le pied du JPEG XL c'est l'arrêt de son support aussi brutal qu'inexpliqué par Google pour se rabattre sur ses formats habituels bien moins performants tant en capacités qu'en qualité (et surtout rapport taille/qualité)... Moi ça m'aurait bien arrangé que le JPEG XL se déploie rapidement et en masse dans les logiciels qui manipulent des images. J'aimerais bien pouvoir exporter mes RAW corrigés sans perte (ou perte très minimale)... Aujourd'hui l'export que me propose Lightroom Classic (12.4 ou 12.5) ou DxO PhotoLab (version 6.10.x) c'est du DNG, du TIFF, du PNG ou du JPEG classique.
Si je veux faire du sans perte, je suis obligé de faire :
- soit du DNG dématricé (qui respecte bien l'espace colorimétrique, le HDR et la dynamique/profondeur de couleurs (notamment les valeurs intermédiaires entre 8 et 16 bits), mais tout de suite ça va à entre 70-80 Mo/fichier de 20 ou 24 MPix
- soit du TIFF, qui permet une profondeur de couleurs de 8-bits ou 16-bits, et ne gère pas tous les espaces colorimétriques ni, je crois, le HDR, mais si on veut conserver toutes la dynamique du capteur qui sort des RAW de 10, 12 ou 14 bits, si on ne veut pas la tronquer à 8 bits, faut passer à 16 bits et donc coder 2, 4 ou 6 bits pour rien, d'où une taille de fichier qui fleurte avec les 100 Mo/fichier voire la dépasse un peu
- soit du PNG mais je m'en sert jamais, je crois que sa dynamique est aussi limitée avec certains logiciel, sinon c'est du 16 bits (même problème que le TIFF) et la taille des fichiers n'est pas folle... Et je ne sait pas ce que ça donne dans la gestion des espaces colorimétriques en photographie
Sinon le JPEG, même en qualité excellente (entre 80 et 100), il y a une perte non négligeable de données : profondeur limitée à 8 bits, pas de HDR, pas de gestion de tous les espaces colorimétriques, etc.
Les autres formats (HEIC/HEIF, WebP, AVIF) dont certains commencent à être gérés parfois en import mais pas en export (HEIF) comportent tous des limites parfois rédhibitoires quand on veut pas de pertes (mais sans compression, même en loseless) : limités en taille (HEIC et AVIF se font déjà dépasser par pas mal de boitiers récents et même un peu ancien, même entrée de gamme qui font des photos dont l'un des côtés approchent ou dépassent leurs limites (il est fréquent d'avoir des boitiers qui sortent des fichiers avec 4 500, 5 000, 6 000 ou 7 000 pix de large, voire bien plus quand on fait des panoramiques qu'on assemble dans LrC, on atteint des largeurs de 10 000, 15 000, 20 000 voire 25 000 pixels sur 3 500, 4 000 ou plus pixels de hauteur)), limités en profondeur de couleur (10, ou 12 bits, alors que les capteurs désormais approchent les 14 bits), etc...
Il paraît que sur Mac Camera Raw gère désormais l'export du JPEG XL (j'ai pas essayé encore, j'utilise rarement Photoshop/Camera RAW pour mes photos, sauf correction d'un défaut bien particulier que des dématriceurs tels que Lightroom Classic ou PhotoLab ne font pas), d'abord dans une version preview/béta avancée il y a quelques mois, et maintenant paraît-il en production... Ce qui m'étonne car CameraRAW est surtout fait pour l'import et le dématriçage des fichiers RAW pour les travailler dans Photoshop... Comme je l'ai dit, je n'ai pas investigué ceci, je l'ai lu sur Reddit et/ou les forums Adobe (ou un autre) et il paraît que ça pourrait venir un jour sur Lightroom Classic. En tout cas l'export JPEG XL est très demandé sur les forums Adobe et DXO...[/list]
-
En cherchant un peu j'ai trouvé ce lien dans les préférences de Photoshop2024 > Camera RAW, c'est donc une fonction "aperçu de fonctionnalité" : https://helpx.adobe.com/fr/camera-raw/using/hdr-output.html
Je viens de regarder avec Photoshop 2024 : j'ai importé un de mes RAW, activé le HDR et j'ai pu effectivement enregistrer en JPEG XL (mais Camera RAW ne permet pas l'export en lot comme LrC et PL). Sur le bureau seul Safari est listé comme application capable de le lire, mais il ne l'affiche pas il le "télécharge" quand je le glisse sur un onglet. En le glissant sur Photoshop l'import n'est pas direct mais via Camera RAW, et donc logiquement (mais un peu étonné quand même car rien dans LrC ne fait mention au JPEG XL) LrC l'importe aussi car il utilise le moteur de Camera RAW mais sans passer par son interface comme dans Photoshop... Il reste bien au format JXL dans LrC, pas de conversion. On peut l'exporter aux classique formats JPEG, PNG, DNG, PSD, TIFF ou au format original...
-
Non l'image JPEG XL est visible chez moi (macOS Monterey 12.7 et Safari 17)...
Pour moi JPEG XL fonctionne bien avec Safari sur iOS 17 :
Copie d'écran :
(https://lafibre.info/images/format/202310_jpeg-xl_ios17.webp)
Test en réel :
Si la voiture ci-dessous s'affiche, votre navigateur sait lire les images AVIF (https://lafibre.info/images/format/202102_image_test.avif) :[/size]
(https://lafibre.info/images/format/202102_image_test.avif)
Si la voiture ci-dessous s'affiche, votre navigateur sait lire les images JPEG XL (https://lafibre.info/images/format/202102_image_test.jxl) :
(https://lafibre.info/images/format/202102_image_test.jxl)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en 16 couleurs (https://lafibre.info/images/format/image_test_bmp_16_couleurs.bmp) :
(https://lafibre.info/images/format/image_test_bmp_16_couleurs.bmp)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en couleurs 24 bits (https://lafibre.info/images/format/image_test_bmp_24bits_couleurs.bmp) :
(https://lafibre.info/images/format/image_test_bmp_24bits_couleurs.bmp)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en couleurs 32 bits avec transparence (https://lafibre.info/images/format/image_test_bmp_32bits_couleurs_transparence.bmp) :
(https://lafibre.info/images/format/image_test_bmp_32bits_couleurs_transparence.bmp)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, sans compression (https://lafibre.info/images/format/image_test_tiff_avec_transparence_sans_compression.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_sans_compression.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression LZW (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_lzw.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_lzw.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression Pack Bits (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_pack_bits.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_pack_bits.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression déflation (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_deflation.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_deflation.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images TIFF avec transparence, avec compression JPEG (https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_jpeg.tiff) :
(https://lafibre.info/images/format/image_test_tiff_avec_transparence_avec_compression_jpeg.tiff)
Si le texte ci-dessous s'affiche, votre navigateur sait lire les images XBM (https://lafibre.info/images/format/image_test_xbm.xbm) :
(https://lafibre.info/images/format/image_test_xbm.xbm)
-
Si je veux faire du sans perte, je suis obligé de faire :
[...]
soit du PNG mais je m'en sert jamais, je crois que sa dynamique est aussi limitée avec certains logiciel, sinon c'est du 16 bits (même problème que le TIFF) et la taille des fichiers n'est pas folle... Et je ne sait pas ce que ça donne dans la gestion des espaces colorimétriques en photographie
Pourtant, PNG gère bien le 32 bits par pixel :
- 8 bits par couleur + 8 bits alpha (transparence)
- il est possible de lui mettre des espaces colorimétriques
La compression n'est pas top, mais c'est le format de référence pour de la compression sans perte avec 32 bits par pixels.
À noter que WebP permet également de faire tout ce que fait PNG.
-
Pour moi JPEG XL fonctionne bien avec Safari sur iOS 17 :
Mais pas sous iOS 16.
-
Effectivement. Sous iOS17 il ne manque plus que le format XBM ! (iPhone 12 pro ici)
-
Pour moi JPEG XL fonctionne bien avec Safari sur iOS 17 :
Je parle de macOS pas d'iOS : il est noté dans le message que je citais qu'il faut Sonoma pour décoder le JPEG XL (en tout cas sur le Web), or c'est faux, sur Monterey (macOS 12.7) et Safari 17, le JPEG XL est décodé sans problème.
-
Pourtant, PNG gère bien le 32 bits par pixel :
- 8 bits par couleur + 8 bits alpha (transparence)
- il est possible de lui mettre des espaces colorimétriques
La compression n'est pas top, mais c'est le format de référence pour de la compression sans perte avec 32 bits par pixels.
À noter que WebP permet également de faire tout ce que fait PNG.
Oui, c'est ce que je dis 8 bits par couleurs, soit 24 bits en tout pour l'espace colorimétrique (le canal alpha n'a aucun intérêt en photographie et n'est pas exploité par les APN et logiciels de retouches photos). Là on parle de formats d'images qui gèrent plus de 8 bits/couleurs. La dynamique et les couleurs sont captées sur 10, 12 voire 14 bits/couleurs sur les APN, soit 30, 36 ou 42 bits en tout. Le PNG est largué en plus d'avoir une compression moyenne
EDIT : Je précise que je viens de découvrir que le PNG fait aussi du 48 bits après avoir vu cette config dans LrC 13 (ce n'était pas le cas avant)
-
Moi ça m'aurait bien arrangé que le JPEG XL se déploie rapidement et en masse dans les logiciels qui manipulent des images. J'aimerais bien pouvoir exporter mes RAW corrigés sans perte (ou perte très minimale)... Aujourd'hui l'export que me propose Lightroom Classic (12.4 ou 12.5) ou DxO PhotoLab (version 6.10.x) c'est du DNG, du TIFF, du PNG ou du JPEG classique.
Il a suffit d'en parler pour que les choses évolues : la mise à jour 13 de Lightroom gère désormais le HDR à l'import et à l'export et permet donc aussi (comme Camera Raw dans son "aperçu de technologie") de générer du JPEG XL mais aussi de l'AVIF.
J'ai fait un petit comparatif entre JPEG (qualité 80 et 100, avec et sans HDR), JPEG XL (qualité 80 et Sans perte, avec et sans HDR), AVIF (qualité 80 et 100, avec et sans HDR), DNG non dématricé (sans aperçu JPEG, sans données de chargement rapide, avec et sans perte), DNG dématricé, TIFF (8 et 16 bits/ composante) et PNG (8 et HDR 16 bits/composante) d'une photo.
Résultats :
• JPEG XL
- HDR sans perte : 41,8 Mo
- SDR sans perte : 13,8 Mo
- HDR qualité 80 : 3,4 Mo
- SDR qualité 80 : 3,1 Mo
• JPEG
- HDR qualité 100 : 21,2 Mo
- SDR qualité 100 : 9,9 Mo
- HDR qualité 80 : 6,5 Mo
- SDR qualité 80 : 4,8 Mo
• AVIF
- HDR qualité 100 : 11,8 Mo
- SDR qualité 100 : 12,2 Mo (étonnant)
- HDR qualité 80 : 4,6 Mo
- SDR qualité 80 : 4,5 Mo
• PNG
- PNG 8-bits/couleur : 20,6 Mo
- PNG 16 bits/couleur HDR : 59,4 Mo (je découvre, PNG fait du 48-bits)
• DNG
- DNG sans perte : 17,4 Mo
- DNG avec perte : 5,7 Mo
- DNG dématricé (sans perte) : 35,7 Mo
• TIFF
- TIFF 8-bits/couleur : 60,5 Mo
- TIFF 8 bits/couleur avec compression ZIP : 40 Mo
- TIFF 16 bits/couleurs HDR : 121 Mo
- TIFF 16 bits/couleurs HDR avec compression ZIP : 105,7 Mo
- TIFF 32 bits/couleurs HDR (pour le fun) : 241,9 Mo! (je découvre aussi que le TIFF fait du 96 bits!
Le JPEG XL avec perte (qualité 80) fait mieux de 35% (SDR) à 47% (HDR) que le JPEG à qualité identique. Le sans perte n'existe pas sur le JPEG (même à qualité 100).
Sur le sans perte, JPEG XL fait mieux de 33% que le PNG en 8 bits/coul et de 29% que le PNG en 16 bits/coul.
Je ne parle même pas du TIFF zippé ou sans compression.
-
Je parle de macOS pas d'iOS : il est noté dans le message que je citais qu'il faut Sonoma pour décoder le JPEG XL (en tout cas sur le Web), or c'est faux, sur Monterey (macOS 12.7) et Safari 17, le JPEG XL est décodé sans problème.
Merci, j'ai corrigé (il faut peut-être vider le cache de ton navigateur web).
Pou d'autres formats d'image comme WebP, c'est la version de MacOS qui compte et non la version de Safari.
-
bonjour, il y a du nouveau avec le jpegli :
To improve on this, we are introducing Jpegli, an advanced JPEG coding library that maintains high backward compatibility while offering enhanced capabilities and a 35% compression ratio improvement at high quality compression settings.
https://www.generation-nt.com/actualites/google-souhaite-oublier-format-image-jpeg-2046094
la source chez google : https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html
-
Oui, je n'ai trouvé aucune comparaison avec WebP et AVIF.
Google se limite à comparer à d'autres encodeurs Jpeg.
Il me semble comprendre que cela reste moins efficace que AVIF et même peut-être WebP (par contre cela permet de faire des choses que WebP ne permet pas, comme l'encodage des couleurs sur 10 bits et le sous-échantillonnage 4:4:4).
(https://lafibre.info/images/format/202304_google_encodeur_image_jpegli.webp)
-
C'est surtout pas nouveau du tout comme approche, non ?
https://github.com/google/guetzli/
Guetzli is a JPEG encoder that aims for excellent compression density at high visual quality. Guetzli-generated images are typically 20-30% smaller than images of equivalent quality generated by libjpeg. Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer.
Edit: ah bien j'aurais du mieux lire la source...
Adaptive quantization heuristics
Jpegli uses adaptive quantization to reduce noise and improve image quality. This is done by spatially modulating the dead zone in quantization based on psychovisual modeling. Using adaptive quantization heuristics that we originally developed for JPEG XL, the result is improved image quality and reduced file size. These heuristics are much faster than a similar approach originally used in guetzli.
La différence, c'est le "much faster".
-
...Là on parle de formats d'images qui gèrent plus de 8 bits/couleurs. La dynamique et les couleurs sont captées sur 10, 12 voire 14 bits/couleurs sur les APN, soit 30, 36 ou 42 bits en tout.
...
Quel est l'intérêt ? Peut-on réellement voir une amélioration à l'oeil ?
Il me semble que la limitation vient moins de la finesse des niveaux que du fait qu'on n'utilise que trois couleurs fondamentales, ce qui rend impossible par principe l'accès à certaines couleurs.
-
Quel est l'intérêt ? Peut-on réellement voir l'amélioration à l'oeil ?
Il me semble que la limitation vient moins de la finesse des niveaux que du fait qu'on n'utilise que trois couleurs fondamentales, ce qui rend impossible par principe l'accès à certaines couleurs.
On ne stocke pas de la couleur justement, mais d'autres informations, comme l'intensité de la lumière. En gros, si tu veux faire une scène bien éclairée, bah tu dois modifier les couleurs en 8bits, ou inversement, une scène sombre, tes couleurs tirent vers le noir, alors que c'est contre-nature : ta voiture ne change pas de peinture quand il fait nuit.
Oui, ça se voit à l'oeil, notamment quand on a diffusé Roland-Garros en 4K les années précédentes, à la fois en SDR et en HDR.
On a reçu qq remarques sur la version HDR, car la couleur du court de tennis était brun. Désolé mais la terre du court est bien brune, et non orange fluo quand le soleil tape dessus :)
-
La différence, c'est le "much faster".
En effet, Guetzli a pu proposer des grosses améliorations par rapport aux encodeurs JPEG « classiques », mais le prix à payer, c'était une utilisation de mémoire vive faramineuse (des centaines et des centaines de Mo), ainsi que des temps de compressions excessivement longs (plusieurs dizaines de secondes pour une photo de taille typique, genre 12 MP).
Même si je préfererais que nous passions à autre chose que JPEG, c'est bien de voir qu'ils arrivent à continuer d'en sortir des améliorations, 30 ans après
-
Quel est l'intérêt ? Peut-on réellement voir une amélioration à l'oeil ?
Il me semble que la limitation vient moins de la finesse des niveaux que du fait qu'on n'utilise que trois couleurs fondamentales, ce qui rend impossible par principe l'accès à certaines couleurs.
Il me semble qu’il y a une confusion dans les notions évoquées. Si ça se voit à l’oeil? Bien sûr, notamment sur des zones dans une même gamme de couleurs, comme un ciel bleu. Il y a moins d’effet de bandes dans les dégradés, effets accentués par un spectre RVB plus limité (8 bits par couleur contre 10, 12 ou 14 bits) et les effets de la compression (qui diminue la dynamique aussi). Je l’expérimente souvent (fais pas mal de photos) et je ne suis pas le seul à le remarquer.
Le système RVB est le même que celui de la rétine donc permet d’établir tout le spectre visible selon l’intensité de chaque composante même si on perd en chrominance par rapport aux couleurs primaires.
C’est pas pour rien que c’est un système universel et que les fabricants améliore la dynamique des capteurs et des écrans pour mieux restituer toutes les nuances.
-
Même si je préfererais que nous passions à autre chose que JPEG, c'est bien de voir qu'ils arrivent à continuer d'en sortir des améliorations, 30 ans après
Mouais sauf que là on bricole une vieille guimbarde qui ne répond plus aux besoins actuels. Et c’est bien pour ça qu’on n’arrive plus à se débarrasser de JPEG malgré ses limitations alors qu’il existe des formats bien meilleurs que lui comme JPEG XL. À ce rythme dans 10 ans on sera au même point.
-
Le format d'image HEIC, utilisé par Apple depuis 2017 (depuis iOS 11 et macOS High Sierra) était incompatible avec Windows 10 et les distributions Linux.
Windows 11 intègre maintenant HEIC et Ubuntu 24.04 LTS sera l'un des premières distributions Linux à proposer par défaut la compatibilité avec HEIC, via libheif.
HEIC nécessite toujours l'achat d'une licence pour le codec HEVC (1 €) pour ouvrir les images avec le lecteur de Microsoft sous Windows 10 et par ailleurs coté navigateur web, seul Safari 17 (lancé en octobre 2023) le prend en charge. On n'est donc pas sur un format d'image universel, mais cela sera plus simple pour ceux qui ont des photos.
L'iPhone de ma femme est configuré pour enregistrer les photos / vidéos en mode compatibilité, je vais peut-être changer le réglage (dommage de ne pas pouvoir régler indépendamment photos de vidéos, car HEVC pour les vidéos est moins exotique que HEIC pour les photos).
-
...
Le système RVB est le même que celui de la rétine donc permet d’établir tout le spectre visible selon l’intensité de chaque composante même si on perd en chrominance par rapport aux couleurs primaires.
...
C'est toute la question. Je lis ici https://www.guide-gestion-des-couleurs.com/oeil-perception-couleurs.html :
"Les êtres humains qui ont l'acuité visuelle la plus fine sont capables de distinguer jusqu'à 200 nuances par couleurs,... mais
jamais dans les trois couleurs primaires !
[...]
Si un œil très performant est effectivement capable de distinguer jusqu'à 200 nuances d'une même couleur primaire, ce même œil n'atteint qu'exceptionnellement cette prouesse dans les deux autres couleurs primaires."
Donc 8 bits/couleur seraient suffisants, et la différence avec plus de 8 bits, imperceptible.
-
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
-
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).
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 (https://github.com/cramforce/avif-webp-quality-setting).
Il a ensuite rapproché le paramètre de qualité qui permet d'avoir une même note DSSIM. Cela donne le tableau suivant :
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
Source : Industrial Empathy (https://www.industrialempathy.com/posts/avif-webp-quality-settings/), le 20 février 2021
-
est-ce que dans les metadonnées de l'image on retrouve le parametre de compression qui a été appliqué à l'image ?
-
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.
-
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.
-
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 :
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
Source : Industrial Empathy (https://www.industrialempathy.com/posts/avif-webp-quality-settings/), 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)
-
Oui... par exemple, les fichiers RAW en DNG produits par les téléphones Samsung ne sont plus aussi bons qu'avant, car ils sont désormais en JPEG XL lossy.
https://www.reddit.com/r/GalaxyS23Ultra/comments/1ang39u/samsung_yet_again_downgraded_the_quality_of/
Il n'y a plus la matrice bayer en brut, donc certaines fonctionnalités avancées de Lightroom ne fonctionnent plus :(
Selon moi, ça n'est pas du tout une avancée... en tout cas pour ces usages-là.
-
Comparatif d'une même image encodée dans des formats d'image différents :
Compression sans perte de qualité et sous-échantillonnage 4:4:4
Compression sans perte PNG : 75 450 octets
(https://lafibre.info/images/format/image_test_gimp3_444_png_sans_perte.png)
Compression sans perte WebP : 38 058 octets
(https://lafibre.info/images/format/image_test_gimp3_444_webp_sans_perte.webp)
Compression sans perte AVIF : 53 192 octets (comme je le dis régulièrement, AVIF n'est pas pertinent pour une compression sans perte de qualité)
(https://lafibre.info/images/format/image_test_gimp3_444_avif_sans_perte.avif)
-
(https://lafibre.info/images/format/parametrage_qualite_format_image.webp)
Compression en qualité excellente - (qualité 80 du JPEG)
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0 afin de comparer ce qui est comparable.
Observez la dégradation en JPEG, visible avec même ce niveau de compression de haute qualité :
- quand la ligne bleue croise la ligne rouge.
- autour des lettres de texte, la couleur change, ce n'est plus du vrai blanc
(https://lafibre.info/images/format/image_test_gimp3_420_jpeg80_zoomx2.webp)
(https://lafibre.info/images/format/image_test_gimp3_420_jpeg80_zoomx4.webp)
Compression JPEG qualité 80 : 34 540 octets
(https://lafibre.info/images/format/image_test_gimp3_420_jpeg80.jpg)
Compression WebP qualité 82 : 16 332 octets
(https://lafibre.info/images/format/image_test_gimp3_420_webp82.webp)
Compression AVIF qualité 64 : 9 031 octets
(https://lafibre.info/images/format/image_test_gimp3_420_avif64.avif)
WebP et surtout AVIF permettent d'avoir une qualité visuelle supérieure pour une taille largement inférieure.
-
Compression en qualité haute - (qualité 70 du JPEG)
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0. Les dégradations de la compression JPEG sont encore plus visibles.
Compression JPEG qualité 70 : 28 712 octets
(https://lafibre.info/images/format/image_test_gimp3_420_jpeg70.jpg)
Compression WebP qualité 72 : 12 824 octets
(https://lafibre.info/images/format/image_test_gimp3_420_webp72.webp)
Compression AVIF qualité 56 : 7 646 octets
(https://lafibre.info/images/format/image_test_gimp3_420_avif56.avif)
-
Compression en qualité moyenne - (qualité 60 du JPEG)
Compression JPEG qualité 60 : 25 174 octets
(https://lafibre.info/images/format/image_test_gimp3_420_jpeg60.jpg)
Compression WebP qualité 64 : 11 888 octets
(https://lafibre.info/images/format/image_test_gimp3_420_webp64.webp)
Compression AVIF qualité 51 : 6 861 octets
(https://lafibre.info/images/format/image_test_gimp3_420_avif51.avif)
-
Compression en qualité dégradée - (qualité 50 du JPEG)
Compression JPEG qualité 50 : 22 840 octets
(https://lafibre.info/images/format/image_test_gimp3_420_jpeg50.jpg)
Compression WebP qualité 55 : 10 966 octets
(https://lafibre.info/images/format/image_test_gimp3_420_webp55.webp)
Compression AVIF qualité 48 : 6 377 octets
(https://lafibre.info/images/format/image_test_gimp3_420_avif48.avif)
-
Seconde image pour comparer les formats d'image :
Compression sans perte de qualité et sous-échantillonnage 4:4:4
Compression sans perte PNG : 33 066 octets
(https://lafibre.info/images/format/image_test2_gimp3_444_png_sans_perte.png)
Compression sans perte WebP : 18 554 octets
(https://lafibre.info/images/format/image_test2_gimp3_444_webp_sans_perte.webp)
Compression sans perte AVIF : 28 530 octets (comme je le dis régulièrement, AVIF n'est pas pertinent pour une compression sans perte de qualité)
(https://lafibre.info/images/format/image_test2_gimp3_444_avif_sans_perte.avif)
-
Compression en qualité excellente - (qualité 80 du JPEG)
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0 afin de comparer ce qui est comparable.
Compression JPEG qualité 80 : 24 827 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_jpeg80.jpg)
Compression WebP qualité 82 : 13 170 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_webp82.webp)
Compression AVIF qualité 64 : 6 806 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_avif64.avif)
WebP et surtout AVIF permettent d'avoir une qualité visuelle supérieure pour une taille largement inférieure.
-
Compression en qualité haute - (qualité 70 du JPEG)
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0. Les dégradations de la compression JPEG sont encore plus visibles.
Compression JPEG qualité 70 : 21 411 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_jpeg70.jpg)
Compression WebP qualité 72 : 11 122 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_webp72.webp)
Compression AVIF qualité 56 : 5 948 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_avif56.avif)
-
Compression en qualité moyenne - (qualité 60 du JPEG)
Compression JPEG qualité 60 : 19 106 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_jpeg60.jpg)
Compression WebP qualité 64 : 10 488 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_webp64.webp)
Compression AVIF qualité 51 : 5 338 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_avif51.avif)
-
Compression en qualité dégradée - (qualité 50 du JPEG)
Compression JPEG qualité 50 : 17 563 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_jpeg50.jpg)
Compression WebP qualité 55 : 9 972 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_webp55.webp)
Compression AVIF qualité 48 : 4 890 octets
(https://lafibre.info/images/format/image_test2_gimp3_420_avif48.avif)
-
Troisième image pour comparer les formats d'image : Dégradé du noir au blanc (en diagonale)
Compression sans perte de qualité et sous-échantillonnage 4:4:4
Compression sans perte PNG : 88 148 octets
(https://lafibre.info/images/format/image_test3_gimp3_444_png_sans_perte.png)
Compression sans perte WebP : 65 258 octets
(https://lafibre.info/images/format/image_test3_gimp3_444_webp_sans_perte.webp)
Compression sans perte AVIF : 67 363 octets (comme je le dis régulièrement, AVIF n'est pas pertinent pour une compression sans perte de qualité)
(https://lafibre.info/images/format/image_test3_gimp3_444_avif_sans_perte.avif)
-
Compression en qualité excellente - (qualité 80 du JPEG)
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0 afin de comparer ce qui est comparable.
Compression JPEG qualité 80 : 10 487 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_jpeg80.jpg)
Compression WebP qualité 82 : 1 614 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_webp82.webp)
Compression AVIF qualité 64 : 571 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_avif64.avif)
WebP et surtout AVIF permettent d'avoir une qualité visuelle supérieure pour une taille largement inférieure.
-
Compression en qualité haute - (qualité 70 du JPEG)
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0.
Compression JPEG qualité 70 : 9 192 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_jpeg70.jpg)
Compression WebP qualité 72 : 1 312 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_webp72.webp)
Compression AVIF qualité 56 : 563 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_avif56.avif)
-
Compression en qualité moyenne - (qualité 60 du JPEG)
Compression JPEG qualité 60 : 7 632 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_jpeg60.jpg)
Compression WebP qualité 64 : 1 258 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_webp64.webp)
Compression AVIF qualité 51 : 496 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_avif51.avif)
-
Compression en qualité dégradée - (qualité 50 du JPEG)
Compression JPEG qualité 50 : 7 325 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_jpeg50.jpg)
Compression WebP qualité 55 : 1 248 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_webp55.webp)
Compression AVIF qualité 48 : 467 octets
(https://lafibre.info/images/format/image_test3_gimp3_420_avif48.avif)
-
Quatrième image pour comparer les formats d'image : Photo
Compression sans perte de qualité et sous-échantillonnage 4:4:4
Compression sans perte PNG : 529 616 octets
(https://lafibre.info/images/format/image_test4_gimp3_444_png_sans_perte.png)
Compression sans perte WebP : 402 012 octets
(https://lafibre.info/images/format/image_test4_gimp3_444_webp_sans_perte.webp)
Compression sans perte AVIF : 347 917 octets (oh, AVIF meilleur que WebP en compression sans perte, c'est rare !)
(https://lafibre.info/images/format/image_test4_gimp3_444_avif_sans_perte.avif)
-
Compression en qualité excellente - (qualité 80 du JPEG)
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0 afin de comparer ce qui est comparable.
Compression JPEG qualité 80 : 66 980 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_jpeg80.jpg)
Compression WebP qualité 82 : 46 538 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_webp82.webp)
Compression AVIF qualité 64 : 37 565 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_avif64.avif)
WebP et surtout AVIF permettent d'avoir une qualité visuelle supérieure pour une taille largement inférieure.
-
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0 afin de comparer ce qui est comparable.
Dans les 3 cas tu restes un beau gosse 8)
Bref, oui, j'ai déjà passé toutes les pièces jointes d'un forum et chat en WebP, j'ai gagné pas mal de Go
(bon le CPU a beaucoup souffert durant l'opération, mais ça en vaut la peine !)
-
Compression en qualité haute - (qualité 70 du JPEG)
Dans les 3 cas, c'est du sous-échantillonnage 4:2:0.
Compression JPEG qualité 70 : 53 815 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_jpeg70.jpg)
Compression WebP qualité 72 : 33 882 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_webp72.webp)
Compression AVIF qualité 56 : 28 568 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_avif56.avif)
-
Compression en qualité moyenne - (qualité 60 du JPEG)
Compression JPEG qualité 60 : 45 456 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_jpeg60.jpg)
Compression WebP qualité 64 : 30 656 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_webp64.webp)
Compression AVIF qualité 51 : 24 268 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_avif51.avif)
-
Compression en qualité dégradée - (qualité 50 du JPEG)
Compression JPEG qualité 50 : 39 834 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_jpeg50.jpg)
Compression WebP qualité 55 : 27 258 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_webp55.webp)
Compression AVIF qualité 48 : 21 401 octets
(https://lafibre.info/images/format/image_test4_gimp3_420_avif48.avif)
-
Bref, oui, j'ai déjà passé toutes les pièces jointes d'un forum et chat en WebP, j'ai gagné pas mal de Go
Tu as choisi quel paramétrage de qualité ?
-
Tu as choisi quel paramétrage de qualité ?
70, suffit large.
C'est vraiment efficace pour des captures d'écran ou des JPEG qui font 3 mégas pour montrer un poteau.
Donc même un "lafibre.info", on passe toutes les pièces jointes dans une moulinette, je doute que les gens voient quoi que ce soit.
Édit Vivien : La suite a été déplacée dans un sujet à part : Comparer la qualité des différents formats d'image (JPEG, WebP, AVIF, JPEG XL) (https://lafibre.info/tv-numerique-hd-3d/comparer-la-qualite-des-differents-formats-dimage/)