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

vivien · « **Réponse #12 le:** 20 août 2023 à 14:12:33 »

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.

Le cas du JPEG XL

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. 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, Adobe, Intel et VESA, Krita, The Guardian, libvips, Cloudinary et Shopify 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.

vivien · « **Réponse #13 le:** 20 août 2023 à 14:12:47 »

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é.

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. 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.

vivien · « **Réponse #14 le:** 20 août 2023 à 14:13:06 »

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" 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) 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.

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 :

Au niveau des images individuelles, il existe des cas où l'écart entre JPEG XL et le meilleur format suivant atteint 30 %, voire plus :

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, DSSIM et SSIMULACRA 2. 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.

vivien · « **Réponse #15 le:** 20 août 2023 à 14:13:25 »

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 ("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 :

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.

vivien · « **Réponse #16 le:** 20 août 2023 à 14:13:30 »

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, le 2 novembre 2022

vivien · « **Réponse #17 le:** 20 août 2023 à 14:28:24 »

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

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

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

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

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

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

vivien · « **Réponse #18 le:** 20 août 2023 à 15:22:52 »

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 :

Citation de: vivien le 14 octobre 2021 à 09:18:23

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
Code: [Sélectionner]
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
Code: [Sélectionner]
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.

vivien · « **Réponse #19 le:** 24 août 2023 à 07:44:00 »

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 (trop récent, l'info sur la faille n'est pas publique)
- CVE-2023-38288 (trop récent, l'info sur la faille n'est pas publique)
- 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 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 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 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 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 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 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 :

zoc · « **Réponse #20 le:** 24 août 2023 à 09:22:43 »

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.

vivien · « **Réponse #21 le:** 25 août 2023 à 13:41:02 »

Citation de: zoc le 24 août 2023 à 09:22:43

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.

vivien · « **Réponse #22 le:** 26 août 2023 à 10:43:05 »

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 :

Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en couleurs 24 bits :

Si le texte ci-dessous s'affiche, votre navigateur sait lire les images BMP en couleurs 32 bits avec transparence :

Optix · « **Réponse #23 le:** 26 août 2023 à 11:15:59 »

Sur iPhone et Safari, oui les 3 images sont visibles, transparence OK.