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 des 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
-
Je vous propose ci-dessous un des meilleurs articles récapitulatifs des avantages du JPEG-XL, traduit en français. Il est écrit par Jon SNEYERS de Cloudinary, un des auteurs principaux de JPEG XL. Ce n'est donc pas l'article le plus impartial, mais il permet de bien lister les nombreux avantages de ce format.
L'article original, en anglais, est disponible sur The Case for JPEG XL (https://cloudinary.com/blog/the-case-for-jpeg-xl).
Le cas du JPEG XL
(https://lafibre.info/images/format/202210_cloudinary_le_cas_jpeg_xl_1.avif)
Récemment, les développeurs de Chrome ont annoncé leur décision de supprimer la prise en charge derrière un drapeau pour JPEG XL (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84). Les raisons suivantes sont invoquées pour cette décision :
- Les drapeaux et le code expérimentaux ne doivent pas rester indéfiniment
- Il n'y a pas assez d'intérêt de la part de l'ensemble de l'écosystème pour continuer à expérimenter avec JPEG XL
- Le nouveau format d'image n'apporte pas suffisamment d'avantages supplémentaires par rapport aux formats existants pour justifier son activation par défaut
- En supprimant le drapeau et le code dans M110, cela réduit la charge de maintenance et nous permet de nous concentrer sur l'amélioration des formats existants dans Chrome
La première déclaration a du sens, mais de nombreuses personnes s'attendaient à ce qu'elle soit résolue en activant la fonctionnalité par défaut, et non en la supprimant entièrement. Cela ne justifie en rien cette décision.
Quant au deuxième point : la question est de savoir si et comment l'intérêt de l'écosystème a été mesuré. Étant donné que la fonctionnalité a été verrouillée derrière un indicateur, il est évident que tout déploiement réel a été bloqué - les fonctionnalités désactivées par défaut peuvent être utilisées pour l'expérimentation, mais pas pour le déploiement réel car la plupart des utilisateurs finaux n'auront pas l'indicateur activé. Il n'y a donc pas de statistiques d'utilisation significatives à examiner.
La partie principale de la norme JPEG XL (ISO/IEC 18181-1) a été publiée en mars 2022, il y a environ six mois. La partie décrivant l'implémentation de référence (ISO/IEC 18181-4) a été publiée en août 2022, il y a environ trois mois. Il semble plutôt prématuré de tirer des conclusions sur « l'intérêt écosystémique » à ce stade précoce.
Cependant, si le soutien enthousiaste dans le bugtracker Chromium de Facebook (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c16), Adobe (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c61), Intel et VESA (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c64), Krita (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c66), The Guardian (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c67), libvips (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c69), Cloudinary (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c70) et Shopify (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c79) est une indication, il semble déconcertant de conclure qu'il y aurait un intérêt insuffisant pour l'écosystème.
Cela nous amène au troisième point, et peut-être le plus important : "Pas suffisamment d'avantages supplémentaires par rapport aux formats existants"
Bien sûr, « pas suffisant » est un critère assez vague, s'il n'est pas précisé quel est le seuil pour qu'un avantage soit considéré comme suffisant. Dans cet article de blog, nous examinerons de plus près quels sont les avantages, puis vous pourrez juger par vous-même s'ils sont "suffisants" ou non.
Concernant le quatrième point : oui, évidemment chaque ligne de code supplémentaire introduit une « charge de maintenance », mais c'est un argument assez générique qui s'applique à toute nouvelle fonctionnalité. Mais dans ce cas particulier, le fardeau est sans doute relativement modeste.
L'implémentation réelle de JPEG XL dans Chrome est basée sur une intégration de libjxl, qui n'est pas elle-même maintenue par Chrome, bien qu'ils doivent évaluer et peut-être même atténuer - si les développeurs de libjxl ne fournissent pas une réponse rapide - les bogues de sécurité potentiels qui pourrait y être découvert, comme avec n'importe quelle bibliothèque "tierce" intégrée à Chrome. Tout le travail d'intégration a déjà été fait, y compris ce qui est nécessaire pour que la transparence alpha, l'animation, la gestion des couleurs dont le HDR et le décodage progressif fonctionnent correctement. Le principal "fardeau" restant dont nous parlons encore à ce stade consiste essentiellement à augmenter occasionnellement un numéro de version dans un script de construction, au cas où une nouvelle version de libjxl apporterait des améliorations utiles pour Chrome.
-
1/ Recompression JPEG sans perte
Une caractéristique unique de JPEG XL est qu'il est possible de recompresser des images JPEG existantes (il y en a beaucoup !) en un fichier JPEG XL qui est en moyenne environ 20 % plus petit, sans introduire de perte. En fait, 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é, ce qui signifie qu'ils n'ont pas de solution satisfaisante pour effectuer la transition depuis JPEG : les fichiers JPEG existants peuvent être conservés au format JPEG — en utilisant le nouveau format uniquement pour les nouvelles images — ou elles peuvent être transcodées au nouveau format. Cependant, le transcodage est une opération quelque peu problématique. Dans tous les cas, il s'agit d'une opération avec perte, ajoutant plus d'artefacts de compression au-dessus du JPEG déjà avec perte. Mais cela peut aussi être contre-productif : si vous sélectionnez une qualité de transcodage élevée, la perte supplémentaire peut être minimisée, mais vous risquez de vous retrouver avec un fichier plus volumineux que le JPEG avec lequel vous avez commencé (similaire à ce qui se passe si vous convertissez une image JPEG en PNG). Si vous sélectionnez une qualité de transcodage suffisamment faible, vous pourrez réduire 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.
2/ Décodage progressif
L'ancien format JPEG prend en charge le décodage progressif : lorsque seulement 15 % des données d'image ont été transférées, un aperçu de qualité inférieure de l'image peut déjà être affiché, qui est ensuite affiné à mesure que davantage de données arrivent. Il s'agit d'une fonctionnalité issue de l'époque de l'accès commuté à Internet, mais elle est toujours très utile aujourd'hui dans un monde où les vitesses moyennes du réseau et les résolutions d'image ont toutes deux augmenté de manière significative, mais où la variation des conditions du réseau a également augmenté. Sur un câble rapide ou une connexion 5G, le décodage progressif rend simplement le chargement de la page un peu plus rapide, mais sur une connexion 3G fragile sur la route, cela fait la différence entre voir quelque chose et ne rien voir du tout.
Grâce en partie au fait que MozJPEG gagne du terrain en tant qu'encodeur JPEG, le JPEG progressif a été le format d'image Web à la croissance la plus rapide au cours de la dernière décennie, si vous le traitez comme un format distinct du mode JPEG séquentiel de base.
Aucun des formats d'image dérivés de la vidéo (WebP, HEIC, AVIF) ne prend en charge le décodage progressif au niveau du codec, car il s'agit d'une fonctionnalité très spécifique aux images fixes. Dans un format vidéo, il est peu utile de pouvoir afficher un aperçu d'une seule image - si vous n'avez pas assez de bande passante pour tamponner de nombreuses images de données vidéo, il est inutile d'essayer de lire la vidéo. Les formats vidéo ont leurs propres solutions pour faire face aux conditions de réseau variables (par exemple HLS).
Pour surmonter cette lacune des "nouveaux" formats d'image actuellement disponibles (WebP et AVIF), les développeurs Web ont eu recours à d'autres astuces pour créer une expérience de chargement progressif, par exemple en utilisant des espaces réservés avec des images de faible qualité (https://www.guypo.com/introducing-lqip-low-quality-image-placeholders).
En revanche, JPEG XL ne prend pas seulement en charge le décodage progressif, il s'étend également au-delà de ce qui est possible dans l'ancien JPEG, par exemple, la progression basée sur la saillance (https://opensource.googleblog.com/2021/09/using-saliency-in-progressive-jpeg-xl-images.html). C'est assez excitant et peut améliorer les choses à la fois pour le développeur Web (plus besoin de complications d'espace réservé) et pour l'expérience de l'utilisateur final.
3/ Performances de compression sans perte
JPEG XL peut effectuer une compression d'image sans perte d'une manière qui bat les formats existants (en particulier PNG) à tous égards : il peut être plus rapide à encoder, produit des fichiers plus petits et davantage de fonctionnalités sont disponibles (par exemple, CMJN, calques, flottant 32 bits, échantillons ponctuels). Comme cela est principalement pertinent pour les flux de travail de création, pas tellement pour le cas d'utilisation de la diffusion Web, je ne m'attarderai pas trop sur ce sujet, mais c'est certainement un "avantage" assez important de JPEG XL en tant que format en général.
Même pour le cas d'utilisation spécifique de la diffusion Web, la compression sans perte peut dans certains cas être souhaitable, car pour certains types de contenu d'image (par exemple, les captures d'écran ou le pixel art), la compression sans perte peut paradoxalement produire des fichiers plus petits que la compression avec perte. PNG et WebP sans perte ont leurs utilisations sur le Web - pas pour les images photographiques, mais pour certains types d'images non photographiques.
-
4/ Performances de compression avec perte
Il s'agit, bien sûr, d'un aspect essentiel de tout format d'image utilisé pour la diffusion sur le Web : comment se comprime-t-il ?
Ce n'est pas une question facile à répondre. Contrairement à la compression sans perte (où vous pouvez simplement regarder la taille des fichiers), la compression avec perte est toujours un compromis entre compression et qualité. Avec les codecs récents, plus compliqués et expressifs, il faut également ajouter la vitesse d'encodage à ce compromis - en passant plus de temps d'encodage, de meilleurs résultats peuvent être obtenus, mais le type de temps d'encodage acceptable dépend du cas d'utilisation : pour un seul image de héros sur une page de destination qui obtiendra des millions de visites, il pourrait être acceptable de passer quelques minutes à l'encoder, tandis que pour une image sur les réseaux sociaux, les exigences de latence et de coût CPU seront beaucoup plus strictes.
Mesurer la compression (bits par pixel) et la vitesse d'encodage (mégapixels par seconde) est assez simple : ce ne sont que des chiffres. Mesurer la qualité de l'image, cependant, est beaucoup plus difficile.
Il existe deux approches d'évaluation de la qualité d'image : les expériences subjectives et les mesures objectives. Les expériences subjectives, si elles sont effectuées correctement, restent le seul moyen fiable d'évaluer la qualité de l'image, mais elles nécessitent que des participants humains évaluent ou comparent les images. Ce n'est donc pas un moyen pratique ni bon marché d'évaluer les performances des encodeurs d'images. Pour cette raison, des métriques objectives sont souvent utilisées dans la pratique : ce sont des algorithmes qui prennent une image originale non compressée et une image avec une compression avec perte en entrée et calculent un score censé indiquer la qualité de l'image.
Les métriques objectives doivent toujours être prises avec un grain de sel, car leur corrélation avec les opinions humaines n'est pas parfaite et peut même être assez faible pour certaines des métriques les plus anciennes — l'utilité d'une métrique a tendance à diminuer avec le temps, car s'il s'agit d'un métrique largement utilisée, les encodeurs auront tendance à s'améliorer pour "tromper la métrique" sans réellement améliorer la qualité de l'image. Pour illustrer comment les métriques peuvent se tromper, j'ai créé une galerie d'images "Hall of shame" (https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMULACRA_2_modelD.html) montrant trois images par ligne (compressée A, originale, compressée B), où de nombreuses métriques (toutes les métriques sauf une que j'ai récemment développée (https://github.com/cloudinary/ssimulacra2)) disent cette image B à droite a une meilleure qualité que l'image A à gauche, même si les évaluateurs humains diront probablement le contraire.
Chez Cloudinary, nous avons récemment réalisé une expérience d'évaluation subjective de la qualité d'image à grande échelle, impliquant plus de 40 000 sujets de test et 1,4 million de scores. Nous préparons actuellement encore une publication de nos résultats détaillés, mais en synthèse générale : dans la gamme de qualité pertinente pour le web , JPEG XL peut obtenir une compression de 10 à 15 % supérieure à 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 lui-même a une compression 10 à 15% meilleure dans la gamme de qualité Web que les encodeurs JPEG typiques comme libjpeg- turbo ou les encodeurs utilisés par les caméras).
Dans le tableau suivant avec des résultats agrégés pour 250 images différentes, la note du 10ème centile la plus mauvaise est indiquée par paramètre d'encodage - il est plus logique d'évaluer en fonction des performances les plus défavorables que sur la base du cas moyen.
(https://lafibre.info/images/format/202210_cloudinary_le_cas_jpeg_xl_2.avif)
En regardant des types spécifiques de contenu d'image, comme les photos de portrait, l'écart entre JPEG XL et les formats existants peut être encore plus grand :
(https://lafibre.info/images/format/202210_cloudinary_le_cas_jpeg_xl_3.avif)
Au niveau des images individuelles, il existe des cas où l'écart entre JPEG XL et le meilleur format suivant atteint 30 %, voire plus :
(https://lafibre.info/images/format/202210_cloudinary_le_cas_jpeg_xl_4.avif)
Lors de l'évaluation de la qualité à l'aide de métriques objectives, le résultat dépendra fortement de la métrique utilisée, des paramètres de l'encodeur et de la manière dont les données sont agrégées sur plusieurs images. Les meilleures métriques perceptuelles actuellement disponibles - selon leur corrélation statistique avec les résultats subjectifs - sont Butteraugli (https://jon-cld.s3.amazonaws.com/test/atradeoff-relative-Butteraugli_3-norm.html), DSSIM (https://jon-cld.s3.amazonaws.com/test/atradeoff-relative-DSSIM.html) et SSIMULACRA 2 (https://jon-cld.s3.amazonaws.com/test/atradeoff-relative-SSIMULACRA_2_modelD.html). Ils sont pour la plupart en accord les uns avec les autres et avec nos résultats subjectifs : JPEG XL surclasse assez nettement les formats existants, avec une marge de 10 à 15 %. Les encodeurs AVIF ont besoin d'environ 100 fois plus de temps pour obtenir une compression comparable à JPEG XL ; à une vitesse d'encodage plus pratique (disons 2 à 3 fois plus lente que JPEG XL à l'effort par défaut), AVIF obtient une compression 10 à 15 % inférieure à JPEG XL ; à vitesse d'encodage identique, AVIF n'est pas meilleur voire un peu moins bon que MozJPEG alors que JPEG XL est 20 à 40% meilleur.
S'agit-il maintenant d'un « avantage supplémentaire suffisant » ? Cela peut être une question d'opinion : combien de pourcentage d'amélioration de la compression est suffisant pour justifier l'ajout d'un autre format à un navigateur ? À quel moment les économies de bande passante (et de stockage et de coût du processeur) justifient-elles la taille binaire supplémentaire, la sécurité supplémentaire, la surface de bogue et la charge de maintenance introduites par le code supplémentaire ? Ce n'est pas une décision anodine.
Dans tous les cas, il suffit de regarder l'amélioration de la compression elle-même : avec les encodeurs actuellement disponibles — dans le cas de JPEG XL et AVIF, les encodeurs s'améliorent encore, donc la situation peut changer — et à des vitesses d'encodage raisonnables et plus ou moins comparables, le l'amélioration globale allant de (Moz)JPEG à WebP est à peu près aussi importante que l'amélioration allant de WebP à AVIF, tandis que l'amélioration allant d'AVIF à JPEG XL est plus importante et à peu près comparable à l'amélioration allant de JPEG à AVIF.
-
5/ Encodeur déployable
L'implémentation de référence de JPEG XL, libjxl, inclut un encodeur qui peut être utilisé tel quel dans les environnements de production : il est relativement rapide et produit une qualité visuelle constante pour une cible de fidélité donnée. La vitesse d'encodage est relativement simple à comprendre et à mesurer, mais la cohérence est quelque chose qui nécessite quelques explications.
Les encodeurs d'image (et vidéo) peuvent généralement être configurés avec un paramètre de "qualité", disons sur une échelle de 0 à 100, qui contrôle la fidélité de l'encodage. Cependant, le même paramètre de qualité, appliqué à différentes images, ne se traduit pas nécessairement par la même qualité visuelle. Bien que l'algorithme de codec puisse effectuer des actions similaires, l'effet de cela sur la qualité d'image perçue réelle dépend du contenu spécifique de l'image. Ce phénomène - la cohérence imparfaite de l'encodeur - est la raison pour laquelle nous avons introduit une méthode de sélection automatique de la qualité dans Cloudinary (https://cloudinary.com/blog/introducing_smart_cropping_intelligent_quality_selection_and_automated_responsive_images) ("q_auto") en 2016.
Une façon de caractériser la cohérence d'un encodeur consiste à comparer le résultat visuel moyen d'un paramètre de qualité donné aux résultats les plus défavorables - disons le score au centile 1 ou 10. Dans notre expérience subjective, nous avons obtenu des scores d'opinion sur de nombreuses images différentes. (225 photographiques et 25 non photographiques), nous pouvons donc jeter un œil à l'écart entre le score le plus défavorable et le score moyen :
(https://lafibre.info/images/format/202210_cloudinary_le_cas_jpeg_xl_5.avif)
Par exemple, pour atteindre un score d'opinion moyen de 60 (« qualité moyenne-élevée ») dans 99 % des cas, en utilisant JPEG XL, vous devrez utiliser un paramètre qui vise un score d'un peu moins de 70 (« haute qualité » ) tout en utilisant les formats existants (JPEG, WebP, AVIF) il faudrait viser un score de 72 ou plus.
Dans les déploiements pratiques, cela signifie que les gains de compression réels pouvant être obtenus avec JPEG XL sont supérieurs à ce qui serait suggéré en considérant les performances moyennes. La raison en est que les paramètres de l'encodeur sont généralement choisis de manière à ce que 99 % (ou même 99,9 %) des images aient une qualité visuelle acceptable, et pas seulement 50 %. Une meilleure cohérence de l'encodeur implique des résultats plus prévisibles et fiables - il y a donc moins de raisons de « viser trop haut » pour tenir compte de la variation dépendante de l'image.
-
6/ Fonctionne sur l'ensemble du flux de travail
Un dernier avantage significatif de JPEG XL est qu'il a une large portée : bien qu'il s'agisse d'un excellent format pour la diffusion sur le Web, ce n'est pas le seul cas d'utilisation pour lequel il a été conçu. JPEG XL peut également être utilisé comme format de capture, où il peut jouer un rôle similaire aux formats Raw des appareils photos actuels : haute précision, plage dynamique élevée, compression sans perte ou avec perte minimale. Il peut par ailleurs être utilisé comme format de création, prenant en charge les calques nommés, les masques de sélection et plusieurs canaux alpha. Il peut être utilisé pour imprimer des cas d'utilisation, prenant en charge par exemple CMJN et les couleurs d'accompagnement. Il peut être utilisé pour des applications médicales ou scientifiques, prenant en charge une compression sans perte de haute précision et une imagerie multispectrale. Et ainsi de suite. Il s'agit d'un format à usage général qui couvre de nombreux cas d'utilisation différents pour l'imagerie numérique.
Bien sûr, la diffusion d'images Web a toujours été le cas d'utilisation le plus important que nous ayons eu à l'esprit lors de la conception de JPEG XL. Mais ce n'était pas le seul cas d'utilisation. Nous ne pensions pas qu'il serait utilisé uniquement sur le Web — contrairement par exemple à WebP qui, comme son nom l'indique déjà, a été conçu spécifiquement pour le Web et uniquement pour le Web. WebP a été conçu comme un format d'image à usage spécial spécifiquement pour le Web, il présente donc diverses limitations, par exemple en ce qui concerne la qualité (forçant le sous-échantillonnage de chrominance 4: 2: 0 de la gamme TV, qui ne permet pas une compression avec perte haute fidélité), la taille de l'image (maximum 16383 pixels dans les deux dimensions, ce qui est acceptable pour le Web mais pas pour de nombreux autres cas d'utilisation), la profondeur de bits (8 bits uniquement) et l'espace colorimétrique (RVB uniquement). Ces limitations sont toutes raisonnables pour le cas d'utilisation Web, mais pas pour un format d'image à usage général.
JPEG XL est le premier candidat sérieux à devenir un format d'image universel qui "fonctionne sur l'ensemble du flux de travail", en ce sens qu'il convient au cycle de vie d'une image numérique, de la capture et de la création à l'échange, l'archivage et la livraison. Pour les développeurs Web, cela présente l'avantage de réduire les problèmes d'interopérabilité et les processus de conversion nécessaires dans la gestion des actifs numériques ; pour les utilisateurs finaux, cela signifie qu'ils peuvent enregistrer des images à partir de pages Web et s'attendre à ce qu'elles "fonctionnent simplement" dans d'autres applications en dehors du navigateur. De toute évidence, JPEG XL n'en est pas encore là en termes d'adoption, mais au moins il est plausible qu'il puisse obtenir une adoption plus large que les formats qui limitent leur portée à la diffusion Web uniquement et n'apportent pas d'avantages significatifs à d'autres cas d'utilisation.
Conclusion
Dans le passé, de nouveaux formats d'image ont été introduits, apportant des améliorations dans certains domaines tout en introduisant des régressions dans d'autres. Par exemple, PNG était une grande amélioration par rapport au GIF, sauf qu'il ne supportait pas l'animation. WebP a apporté des améliorations de compression par rapport à JPEG dans la plage de fidélité faible à moyenne, mais au prix de la perte du décodage progressif et de l'encodage 4: 4: 4 haute fidélité. AVIF a encore amélioré la compression, mais au prix à la fois d'un décodage progressif et d'encodeurs déployables.
Nous avons examiné six aspects de JPEG XL où il apporte des avantages significatifs par rapport aux formats d'image existants :
1/ Recompression JPEG sans perte
2/ Décodage progressif
3/ Performances de compression sans perte
4/ Performances de compression avec perte
5/ Encodeur déployable
6/ Fonctionne sur l'ensemble du flux de travail
Le lecteur peut juger par lui-même s'il considère ces avantages suffisants. À mon avis, chacun de ces avantages est suffisant. Plus important encore, JPEG XL peut apporter ces avantages sans introduire de régression dans d'autres domaines, du moins en termes de points forts techniques. Évidemment, en termes d'interopérabilité et d'adoption, chaque nouveau format a un long chemin à parcourir pour rattraper les formats existants comme JPEG et PNG. Nous ne pouvons qu'espérer que les développeurs de Chrome reviendront sur leur décision et aideront JPEG XL à rattraper les anciens formats en termes de support logiciel, afin que nous puissions tous profiter des avantages qu'il apporte.
Source : Jon SNEYERS de Cloudinary (https://cloudinary.com/blog/the-case-for-jpeg-xl), le 2 novembre 2022
-
Un bug Chromium (https://issues.chromium.org/issues/40270698) 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 (https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes#Images)).
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 ?
-
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.
-
Les formats d'image sont-ils tous équivalents pour la sécurité ?
Non !
La complexité de TIFF en fait un format difficile à sécuriser.
On découvre encore tous les mois des failles sur les librairies qui permettent de lire ce vieux format de fichier.
Ce n'est pas juste des failles inexploitables. 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.
Vous comprenez pourquoi votre navigateur web ne sait pas lire de fichiers TIFF...
Voici une liste de failles découvertes ces derniers mois :
- CVE-2023-38289 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38289) (trop récent, l'info sur la faille n'est pas publique)
- CVE-2023-38288 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-38288) (trop récent, l'info sur la faille n'est pas publique)
- CVE-2023-26966 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-26966) libtiff 4.5.0 is vulnerable to Buffer Overflow in uv_encode() when libtiff reads a corrupted little-endian TIFF file and specifies the output to be big-endian.
- CVE-2023-26965 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-26965) loadImage() in tools/tiffcrop.c in LibTIFF through 4.5.0 has a heap-based use after free via a crafted TIFF image.
- CVE-2023-25433 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25433) libtiff 4.5.0 is vulnerable to Buffer Overflow via /libtiff/tools/tiffcrop.c:8499. Incorrect updating of buffer size after rotateImage() in tiffcrop cause heap-buffer-overflow and SEGV.
- CVE-2023-3618 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-3618) A flaw was found in libtiff. A specially crafted tiff file can lead to a segmentation fault due to a buffer overflow in the Fax3Encode function in libtiff/tif_fax3.c, resulting in a denial of service.
- CVE-2023-3316 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-3316) A NULL pointer dereference in TIFFClose() is caused by a failure to open an output file (non-existent path or a path that requires permissions like /dev/null) while specifying zones.
- CVE-2023-2908 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2908) A null pointer dereference issue was found in Libtiff's tif_dir.c file. This issue may allow an attacker to pass a crafted TIFF image file to the tiffcp utility which triggers a runtime error that causes undefined behavior. This will result in an application crash, eventually leading to a denial of service.
- CVE-2022-48281 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-48281) processCropSelections in tools/tiffcrop.c in LibTIFF through 4.5.0 has a heap-based buffer overflow (e.g., "WRITE of size 307203") via a crafted TIFF image.
Mise à jour TIFF pour Ubuntu :
(https://lafibre.info/testdebit/ubuntu/202308_tiff_mise_a_jour_de_securite.webp)
-
Je ne suis pas certain que la complexité de TIFF soit la vraie raison de la présence de nombreuses vulnérabilités.
L'ancienneté du format TIFF fait que tout le monde réutilise des libraires existantes, conçues à l'époque où la cybersécurité n'était pas un concept vraiment pris en compte (l'époque de "tout le monde il est beau tout le monde il est gentil" de l'informatique et des réseaux).
Pas certain que si on implémentait from scratch une librairie TIFF en appliquant les standards de cybersécurité actuels (et surtout en utilisant des langages plus modernes), on aurait encore ces mêmes problèmes.
-
Je ne suis pas certain que la complexité de TIFF soit la vraie raison de la présence de nombreuses vulnérabilités.
L'ancienneté du format TIFF fait que tout le monde réutilise des libraires existantes, conçues à l'époque où la cybersécurité n'était pas un concept vraiment pris en compte (l'époque de "tout le monde il est beau tout le monde il est gentil" de l'informatique et des réseaux).
Pas certain que si on implémentait from scratch une librairie TIFF en appliquant les standards de cybersécurité actuels (et surtout en utilisant des langages plus modernes), on aurait encore ces mêmes problèmes.
TIFF est intrinsèquement difficile à sécuriser.
Il supporte des dizaines de solutions pour compresser les images, des extensions à gogo, presque sans limite,...
D'autres formats sont eut très strictes et en même temps bien moins évolutif.
Si TIFF est toujours utilisé de nos jours, c'est qu'il a su régulièrement évoluer. On est loin du format noir et blanc de ses origines.
-
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 ;)
-
Le format JPEG XL n'est pris en charge que par iOS 17 et Safari sous macOS Sonoma. Ces versions ne sont pas encore disponibles en version stable, mais je profite zoc pour savoir si mon image est visible, car je l'ai enregistrée en JPEG XL, mais je n'ai pas pu tester que cela fonctionnait bien avec les prochaines versions des OS d'Apple.
-
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.
-
Je ne suis pas certain que la complexité de TIFF soit la vraie raison de la présence de nombreuses vulnérabilités.
L'ancienneté du format TIFF fait que tout le monde réutilise des libraires existantes, conçues à l'époque où la cybersécurité n'était pas un concept vraiment pris en compte (l'époque de "tout le monde il est beau tout le monde il est gentil" de l'informatique et des réseaux).
Pas certain que si on implémentait from scratch une librairie TIFF en appliquant les standards de cybersécurité actuels (et surtout en utilisant des langages plus modernes), on aurait encore ces mêmes problèmes.
TIFF est intrinsèquement difficile à sécuriser.
Il supporte des dizaines de solutions pour compresser les images, des extensions à gogo, presque sans limite,...
D'autres formats sont eut très strictes et en même temps bien moins évolutif.
Si TIFF est toujours utilisé de nos jours, c'est qu'il a su régulièrement évoluer. On est loin du format noir et blanc de ses origines.
Et encore une faille pour TIFF, c'est 3 fois par an minimum...
⇒ CVE-2023-1916 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1916)
(https://lafibre.info/images/format/202310_tiff_cve-2323-1916.webp)
-
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)
-
Je suis quand même surpris par toutes ces failles des librairies TIFF.
Le format est assez simple à coder et décoder, même s'il est très extensible. Quand je vois la page support (http://www.libtiff.org/support.html) de libTIFF, à part quelques formats de compression rarement inutilisés, il n'y a rien de très renversant... même certaines parties optionnelles de la spec ne sont pas prises en charge.
Il doit y avoir quelque chose qui m'échappe (et du coup le décodeur TIFF que j'ai écrit il y a longtemps doit être aussi très peu sécurisé !)
-
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.
-
Une chanson pour geeks : Elle parle de donner une chance au format d'image Jpeg XL
Google doit se sentir visé...
https://www.youtube.com/watch?v=VJaa1Le4W7c
-
Je ne suis pas certain que la complexité de TIFF soit la vraie raison de la présence de nombreuses vulnérabilités.
L'ancienneté du format TIFF fait que tout le monde réutilise des libraires existantes, conçues à l'époque où la cybersécurité n'était pas un concept vraiment pris en compte (l'époque de "tout le monde il est beau tout le monde il est gentil" de l'informatique et des réseaux).
Pas certain que si on implémentait from scratch une librairie TIFF en appliquant les standards de cybersécurité actuels (et surtout en utilisant des langages plus modernes), on aurait encore ces mêmes problèmes.
TIFF est intrinsèquement difficile à sécuriser.
Il supporte des dizaines de solutions pour compresser les images, des extensions à gogo, presque sans limite,...
D'autres formats sont eut très strictes et en même temps bien moins évolutif.
Si TIFF est toujours utilisé de nos jours, c'est qu'il a su régulièrement évoluer. On est loin du format noir et blanc de ses origines.
Et encore une faille pour TIFF, c'est 3 fois par an minimum...
⇒ CVE-2023-1916 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-1916)
(https://lafibre.info/images/format/202310_tiff_cve-2323-1916.webp)
Encore plusieurs failles de sécurité pour le format d'image TIFF.
C'est un puits sans fond de failles de sécurité.
Les dernières :
⇒ CVE-2023-52356 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-52356)
⇒ CVE-2023-6228 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6228)
⇒ CVE-2023-6277 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-6277)
(https://lafibre.info/images/format/202402_tiff_cve-2323-6228.webp)
-
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