La Fibre
Télécom => Télécom => 
TV et codecs => Discussion démarrée par: vivien le 15 juin 2023 à 17:44:31
-
Le 31 octobre 2022, Google annonçait le retrait du support expérimental de JPEG XL dans Chrome : https://issues.chromium.org/issues/40168998#comment85
(JPEG XL devait être activé avec le drapeau enable-jxl, il n'était pas activé par défaut)
Traduction en français de l'annonce :
Nous supprimerons le code et l'indicateur JPEG XL de Chromium pour les raisons suivantes :
- 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 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.
Pour WebP 2, il n'est pas encore disponible avec un support expérimental, mais Google annonce que WebP 2 ne sera pas publié en tant que format d'image, mais est utilisé comme terrain de jeu pour les expériences de compression d'image.
Bref, il n'y aura probablement pas de WebP 2 ou JPEG XL disponible rapidement, ce qui va laisser le champ libre à AVIF dont la prise en charge est presque complète (il manque Edge).
JPEG XL sera supporté par Apple dans iOS 17 et macOS 14
Après l'abandon par Google de l'expérimentation JPEG XL, aujourd'hui supporté par aucun navigateur, Apple annonce un support complet avec la prochaine version d'iOS et de macOS.
Apple serait en avance sur le reste de l'écosystème ?
- 2020 : Apple ajoute, 8 ans après Google, le support du format d'image WebP dans iOS 14 et macOS 11
- 2022 : Apple ajoute, 2 ans après Google, le support du format d'image AVIF dans iOS 16 et macOS 13
- 2023 : Apple ajoute, avant tous les autres navigateurs, le support du format d'image JPEG XL dans iOS 17 et macOS 14.
Si Apple se rattrape bien coté image, coté vidéo et audio, c'est toujours la catastrophe (VP9, AV1 et Opus ne sont pas supportés dans iOS 17).
-
peut-etre a cause de leur future casque VR qu'ils ont annoncé récemment ou si j'ai bien compris la qualité d'image / conso cpu / taille stockage sera un critère important pour cet appareil.
Apple fait toujours des choses si ca sert les intérêts d'Apple ;)
-
JPEG XL est un format intéressant qui pourrait remplacer le JPEG dans les appareils photos, contrairement à AVIF est un surtout fait pour internet.
Apple pourrait peut-être l'utiliser pour les photos de l'iPhone.
Depuis iOS 11 le format d'image par défaut pour les photos est HEIF, un format pris en charge par aucun navigateurs web
=> https://support.apple.com/fr-fr/HT207022
HEIF ne permet pas des trop grandes photos, la réalité virtuelle demanderait des photos plus grandes ?
JPEG XL est bien meilleur que HEIF, en termes de performances ou caractéristiques.
-
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 ?
-
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.
-
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
-
JPEG XL est un format intéressant qui pourrait remplacer le JPEG dans les appareils photos, contrairement à AVIF est un surtout fait pour internet.
Dans l'absolu, pourquoi pas, le JPEG XL remplacera peut-être à terme le JPG dans les APN, mais je ne vois pas les APN ouvrir le bal là-dessus, à part peut-être une ou deux marques ou quelques modèles anecdotiques en terme de PdM. En effet, le JPG aujourd'hui sur les APN est plutôt un héritage de compatibilité lié au passé, à l'habitude (les premiers APN un peu corrects il y a 20 ans faisaient du JPG en éventuellement du TIFF). Il a donc pour lui son historique et sa compatibilité universelle. Les gens qui ont un APN peuvent être catégorisées en 2 groupes principaux (qui feront que les formats disponibles au niveau des APN suivront une logique identique):
- soit les gens qui se contentent de l'image faite par le boitier, pour l'avoir immédiatement, avec une compatibilité universelle, tant sur les ordis, tablettes, smartphones que sur les plateformes en ligne, ne nécessitant aucune conversion et avec un choix de qualité suffisant (LOW/MED/HIGH comme souvent sur les boitiers) ; pour ces gens le JPEG est le format parfait
- soit les gens qui veulent faire de la retouche photo, exploiter leur APN au mieux, développer les fichiers brut et dont la compatibilité universelle n'est pas dans un premier temps essentielle ; pour ces gens c'est les fichiers RAW qui doivent être post-traités
Le JPEG XL ne rentre dans aucune de ces catégories, du moins pour le moment : il n'a ni la compatibilité universelle du JPEG, ni les possibilités de post-traitement du RAW. Dans le monde la photographie, il sera sûrement d'abord utilisé comme format d'export des RAW, car il permet de stocker sans perte les photos retouchées dans une taille de fichier moindre que les RAW ou TIFF... Mais on garde finalement toujours les RAW car l'amélioration constante des dématriceurs et des algo notamment de débruitage par IA permet parfois de développer de manière très qualitative des RAW difficilement récupérables il y a 2, 3, 5 ans.
Donc pour un fabriquant d'APN, se fatiguer à ajouter le support du JPEG XL, ça n'apporte rien directement aux clientèles cibles (du moins ce qu'il en reste) des APN... Peut-être, comme je le disais plus haut, que certains boitiers les géreront rapidement, mais je crois guère à l'intérêt (coût, développement, puissance nécessaire pour gérer la compression/décompression et donc impact sur l'autonomie, etc. pour peu de plus-value directe pour l'utilisateur final).
Apple pourrait peut-être l'utiliser pour les photos de l'iPhone.
Depuis iOS 11 le format d'image par défaut pour les photos est HEIF, un format pris en charge par aucun navigateurs web
=> https://support.apple.com/fr-fr/HT207022
Apple peut effectivement avoir une force de frappe large pour imposer le JPEG XL vu la base d'appareils iOS/iPadOS, mais faudrait pour cela se dépêcher de le faire, voire (mais on peut toujours rever) ajouter le support aux anciennes version d'iOS... Néanmoins, le JPEG XL n'a pas non plus un support très large des navigateurs (depuis le retrait de Chrome), et Apple n'a pas réussi à faire changer les choses en 10 ans avec le HEIF...
Mais je suis d'accord pour dire que le JPEG XL aurait bien sa place dans ces boitiers/photo-phones au côté du JPEG (toujours la nécessité de compatibilité universelle), mais faut que le support des plateformes en ligne suivent aussi sur le JPEG XL (vu que ça passe par des applications, la compatibilité peut être améliorée directement via ces applications).
-
Apple n'a pas réussi à faire changer les choses en 10 ans avec le HEIF...
Un format d'image avec des brevets royalties, c'était perdu d'avance.
-
Avec des brevets ou avec des royalties ? Désolé de pinailler, mais comme je sais que c'est un de tes sujets de prédilection, je crois que la précision a de l'importance...
Par exemple AVIF est bardé de brevets, mais avec des accords de licence sans royalties qui lient tous les membres de l'alliance AOM, et qui sont censés couvrir l'intégralité des brevets en question.
-
Pour moi, HEIF demander de payer des royalties :
Ozer : Y a-t-il une redevance sur HEIF ? Si tel est le cas, savons-nous de quoi il s’agit ou s’agira-t-il d’un cauchemar comme HEVC ?
Gill : HEIF est un sous-ensemble de HEVC, car il contient une seule « image clé » ou « image I » HEVC. Il s'agit d'images qui sont codées dans leur ensemble et non prédites à partir d'autres images. Par conséquent, seuls les brevets HEVC qui couvrent le codage d'images fixes sont pertinents pour HEIF, et non les brevets qui traitent des prédictions d'images, de l'estimation et de la compensation de mouvement, des modes temporels, etc.
Les pools de brevets actuels ne font pas de distinction entre les brevets « images fixes » et le reste des brevets HEVC, il n’est donc pas clair comment obtenir une licence HEIF, autre que le paiement de l’intégralité des redevances HEVC. Il est logique que si le format d'image devient populaire, les pools de brevets offriraient des frais de licence réduits « HEIF only ».
Cela dit, je ne vois pas beaucoup d’entreprises qui utiliseront uniquement HEIF et non HEVC, car aujourd’hui les flux de travail d’image et de vidéo sont étroitement liés. Les fournisseurs d'appareils photo tels que Canon, Nikon et Sony fabriquent tous des appareils photo qui prennent à la fois des images fixes et des vidéos, les fournisseurs de logiciels tels qu'Adobe créent des logiciels d'image et de vidéo, et la plupart des services photo en ligne tels que Flickr, Snapfish, Shutterfly, etc. prennent en charge à la fois la photo et la vidéo. Dans tous ces exemples, les fournisseurs qui autorisent HEVC pour leur flux vidéo obtiendront la licence HEIF « gratuitement ».
Source : Apple Endorses New Image Format, HEIF (https://www.linkedin.com/pulse/apple-endorses-new-image-format-heif-jan-ozer/), le 12 juin 2017 par Jan Ozer - traduit de l'anglais.
Dans Windows 10, le support des images HEIF a comme pré-requis l'achat d'une licence HEVC (soit fourni par le matériel, soit acheté à 1€ sur le microsoft Store) :
(https://lafibre.info/images/format/202312_microsoft_extension_image_heif.webp)
-
Un format d'image avec des brevets, c'était perdu d'avance.
Le public s'en fiche pas mal des brevets (ou des royalties), ce qu'il veut c'est un format universel, un format suffisamment qualitatif (le JPEG convient à la plupart des gens) qui permet d'envoyer sa photo à quiconque sans se poser de question, et dont on est sûr que le destinataire l'ouvrira sans problème... 'it just works!'
Nombreux ont été les formats meilleurs que le JPEG de base et qui ont fait un flop. Donc cette caractéristique d'universalité est indispensable pour remplacer JPEG... Les gens n'ont pas envie de gérer les conversions, les 'c'est quoi ton fichier? J'arrive pas à l'ouvrir!', etc. (cf. les HEIF qui, dès qu'on sort de l'environnement Apple et des logiciels Apple, sont galère à gérer/ouvrir/convertir)
Alors oui les brevets et royalties ça peut faire suer les éditeurs (voire simplement pour des raisons politiques, ne pas trop soutenir/payer pour un format d'un concurrent féroce sur un autre marché), mais si on veut imposer un format tel que le JPEG XL, l'absence de déploiement massif ET rétroactif (ce que peu feront, mais il me paraît indispensable qu'Apple, Google et Microsoft rajoutent la compatibilité JPEG XL sur leurs systèmes antérieurs respectifs histoire d'élargir d'un coup la base d'utilisateurs et ne pas devoir attendre qu'elle se développe lentement de presque rien) est un sérieux frein ; le même type de frein qui ont tué les formats précédents... Et tant que ça sera comme ça, JPEG aura encore de beaux jours devant lui, et c'est dommage quand on voit les qualités du JPEG XL...
-
On parle du format d'image qui sera utilisé dans 10 ans, sachant qu'il y a forcément 10 ans entre la création et la mise en ouvre à grande échelle.
Les formats WebP ou AVIF ont des limitations qui font qu'ils resteront principalement des formats liés au web (même s'il WebP est pris en charge par la plupart des logiciels, même Microsoft Paint de Windows).
Jpeg a aussi des lacunes : Pas de HDR, limitation à 8 bits par couleur, pas de gestion de la transparence, pas de compression sans perte, pas possible d'avoir des images animées...
Bref, Jpeg doit être remplacé à moyen terme et Jpeg XL semble une piste qui coche toutes les cases.
-
Par rapport au royalties de HEIF... que penses-tu de la page Wikipedia (https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format) du format ?
HEIC: HEVC in HEIF
High Efficiency Video Coding (HEVC, ITU-T H.265)[13] is an encoding format for graphic data, first standardized in 2013. It is the primarily used and implied default codec for HEIF as specified in the normative Annex B to ISO/IEC 23008-12 HEVC Image File Format.
While not introduced formally in the standard, the acronym HEIC (High-Efficiency Image Codec) is used as a brand and in the MIME subtypes image/heic and image/heic-sequence. If the content conforms to certain HEVC profiles, more specific brands can be used: HEIX for Main 10 of HEVC, HEIM for (Multiview) Main profile and HEIS for (Scalable) Main (10) profile of L-HEVC.
A HEIC photo takes up about half the space of an equivalent quality JPEG file.[14] The initial HEIF specification already defined the means of storing HEVC-encoded intra images (i-frames) and HEVC-encoded image sequences in which inter prediction is applied in a constrained manner.
HEVC image players are required to support rectangular cropping and rotation by one, two and three quarter-turns. The primary use case for the mandatory support for rotation by 90 degrees is for images where the camera orientation is incorrectly detected or inferred. The rotation requirement makes it possible to manually adjust the orientation of a still image or an image sequence without needing to re-encode it. Cropping enables the image to be re-framed without re-encoding. The HEVC file format also includes the option to store pre-derived images.[15]
Samples in image sequence tracks must be either intra-coded images or inter-picture predicted images with reference to only intra-coded images. These constraints of inter-picture prediction reduce the decoding latency for accessing any particular image within a HEVC image sequence track.
The .heic and .heics file name extensions are conventionally used for HEVC-coded HEIF files.[16] Apple products, for instance,[17] will only produce files with these extensions, which indicate clearly that the data went through HEVC encoding.[2]
AVIF: AV1 in HEIF
This section is about AV1 and AVIF. For AVI, see Audio Video Interleave.
Main article: AVIF
AV1 is a video encoding format that is intended to be royalty free developed by the Alliance for Open Media (AOMedia). AV1 Image File Format (AVIF) is an image format based on this codec.[18]
The registered MIME type is image/avif for both still images and image sequences, and .avif is the file name extension.[19]
Il semblerait que strictement le container HEIF soit sans royalties, puisque même AVIF l'utilise. Par contre ce n'est pas du tout le cas de HEIC puisqu'il s'agit de l'HEVC.
-
Techniquement je ne dis pas le contraire, je l’ai déjà souligné. Je souhaiterais même que le JPEG XL soit déjà à la place du JPEG. Mais il n’est pas du tout certain que le JPEG XL soit autre chose qu’un format de niche comme le fut le JPEG 2000 il y a 20 ans et qui était aussi une tentative de correction des défauts du JPEG. A l’époque les besoins d’universalité et la dépendance au JPEG était moins grande qu’ajd (réseaux sociaux, messageries, APN, photo phone…) et pourtant le JPEG2000 a raté son coup.
Plus on laisse le JPEG hégémonique et s’incruster plus ses potentiels successeurs auront du mal à passer, à mon avis le retard est déjà trop grand il ne fait pas penser à 10 ans dans le futur mais dans le passé. Si on veut que le JPEG XL passe faut que les GAFAM le supportent tous et partout, et qu’ils ajoutent son support dans les versions de leur OS et logiciels des 3 voire 5 dernières années et qu’il soit mis comme format par defaut a la place du JPEG.
-
Oui, le conteneur HEIF est sans royalties et est utilisé par de nombreux formats d'image :
- JPEG 2000
- JPEG XR
- JPEG XS
- WXAM
- SharpP
- AVCI (Codec AVC dans HEIF)
- HEIC (Codec HEVC dans HEIF)
- AVIF (Codec AV1 dans HEIF)
...
Ce qui demande de payer des royalties, c'est le codec HEVC utilisé avec HEIF. Normalement son nom est HEIC, mais comme Apple l'a appelé HEIF, aujourd'hui quand on parle de HEIF, c'est avec le codec HEVC et il est nécessaire de payer les royalties pour HEVC.
-
En effet Apple ne semble pas très constant sur le label de ce format... sur une photo prise par un iPhone, extension HEIC mais description HEIF.
-
J'ai trouvé une source intéressante pour comparer les formats d'image sans perte
La différence de compression entre les formats me semble faible.
(cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/format/202106_comparison_of_lossless_image_formats.webp) (https://lafibre.info/images/format/202106_comparison_of_lossless_image_formats.pdf)
J'ai mis leurs données dans un tableau pour faire une moyenne des 3 types d'images analysés et classer les formats d'image en fonction de leur efficacité en mode compression sans perte de qualité.
AVIF et HEIC, les deux formats basés sur des codecs vidéos s'en sortent très mal.
(https://lafibre.info/images/format/202106_comparaison_des_formats_image_sans_perte.webp)
Note pour WebP : Si la compression avec perte de WebP est bien issue du codage des images clé des flux vidéos VP8, la compression sans perte est complétement indépendante, qui est intégré dans le même format. On a en fait un format d'image qui embarque deux technologies : la compassion du codec vidéo VP8 pour la compression avec perte et un autre, qui est performant pour la compression sans perte. Pour AVIF et HEIC, c'est respectivement AV1 et HEVC qui est utilisé aussi bien pour la compression avec perte et sans perte.
-
Je remets ici les résultats de mes tests fait ici avec Lightroom à partir d'un RAW de 20,4 MPix: https://lafibre.info/tv-numerique-hd-3d/liste-formats-image/msg1039076/#msg1039076
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.
et je rajoute que l'AVIF SDR génère des fichiers environ 30% plus gros que le JPEG XL (avec perte, même réglage). À noter que JPEG XL sans perte vs. AVIF qualité 100 en SDR donnent des fichiers légèrement plus gros pour JPEG XL, mais je pense que AVIF qualité 100 n'est pas réellement du sans perte dans ce cas, que c'est plutôt (comme pour le JPEG) la compression minimale.
-
Un an plus tard, toujours pas de changement de position de Google sur JPEG XL pour sa prise en charge dans Chrome / Chromium / Android : Google bloque la prise en charge de JPEG XL (aujourd'hui supporté uniquement par Safari ; Firefox a annoncé le prendre en charge si Google le prend en charge)
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 ?
-
Mozilla s'intéresse à un décodeur JPEG-XL Rust pour Firefox et Google pourrait le développer
Mozilla est intéressé par un décodeur d'image JPEG-XL écrit en Rust pour ses caractéristiques de sécurité mémoire par rapport au code C++ existant sur lequel ils s'appuient pour la prise en charge des images JPEG-XL dans Firefox. Alors que Google a précédemment supprimé la prise en charge JPEG-XL de Chrome/Chromium (https://www.phoronix.com/news/Chrome-Drops-JPEG-XL), il se peut que ce soit Google qui vienne à la rescousse et écrive un décodeur d'image JPEG-XL basé sur Rust qui peut ensuite être livré par Firefox.
Bobby Holley, le directeur technique de Firefox chez Mozilla, a exposé hier sa position en faveur d'un éventuel décodeur d'image JPEG-XL basé sur Rust pour Firefox. Au référentiel des positions standards de Mozilla (https://github.com/mozilla/standards-positions/pull/1064), il a commenté dans une nouvelle demande d'extraction " Firefox envisagera une implémentation Rust de JPEG-XL " avec l'explication suivante :
« Au cours des derniers mois, nous avons eu des conversations productives avec l'équipe JPEG-XL de Google Research sur l'avenir du format dans Firefox. Notre principale préoccupation a longtemps été la surface d'attaque accrue du décodeur de référence (actuellement derrière un pref dans Firefox Nightly), qui pèse plus de 100 000 lignes de C++ multithread. Pour répondre à cette préoccupation, l'équipe de Google a accepté d'appliquer son expertise en la matière pour créer un décodeur JPEG-XL sûr, performant, compact et compatible dans Rust, et intégrer ce décodeur dans Firefox. S'ils parviennent à fournir une implémentation qui satisfait ces propriétés et répond à nos exigences de production normales, nous la livrerons.
Le temps nous dira si le format réussit à devenir un remplacement universel du JPEG comme certains l'espèrent. Dans le cas où il le ferait, il serait regrettable d'introduire potentiellement des vulnérabilités de sécurité de la mémoire dans la myriade d'applications qui auraient éventuellement besoin de le prendre en charge. Un décodeur Rust sûr, rapide et testé au combat de l'équipe d'origine pourrait rendre ce scénario beaucoup moins probable, et nous utilisons donc notre influence pour encourager les progrès sur ce front.
Très intéressant, surtout si l'on considère l'histoire passée de JPEG-XL et de Chrome. Mais si Google investit dans l'écriture d'un décodeur JPEG-XL basé sur Rust, il sera intéressant de voir s'ils vont de l'avant et reconsidérer leur prise en charge des images dans Chrome (https://www.phoronix.com/news/Chrome-JPEG-XL-Seconds). Sinon, il serait plutôt ironique que Google développe ce décodeur JPEG-XL basé sur Rust uniquement pour être utilisé par Firefox et d'autres logiciels non Google.
Quoi qu'il en soit, nous verrons ce qui se passera sur ce front au cours des prochains mois.
Source : Phoronix (https://www.phoronix.com/news/Mozilla-Interest-JPEG-XL-Rust), Écrit par Michael Larabel le 4 septembre 2024, traduit par Vivien
-
l'iPhone 16 Pro supporte désormais la prise de photos en format JPEG XL... mais juste pour les sauvegardes RAW (et encapsulées dans un container DNG).
-
C'est du JPEG-XL Lossless (sans perte) qui est utilisé, c'est bien ça ?
Cela remplace le format RAW propriétaire ?
Coté Google, la demande pour rajouter le support de JPEG-XL à Chrome n'avance pas : https://issues.chromium.org/issues/40270698
-
Visiblement il y a le choix entre lossy et lossless, ce qui est surprenant pour du RAW. La compression lossy doit avoir été paramétrée pour avoir très peu de perte de qualité.
(https://lafibre.info/images/format/202410_iPhone16_pro_jpeg-xl.avif)
-
Étonnant.
Je regrette également qu'Apple ne permette pas de sélectionner le codec vidéo séparément du format d'image pour les photos.
Ma femme reste en JPEG pour les photo pour des raisons de compatibilité (HEIC étant assez peu pris en charge), mais elle aimerait bien avoir HEVC pour les vidéos.
-
Apparemment c’est une pratique qui commence à se répandre…
https://gregbenzphotography.com/lightroom-acr/shrink-your-raw-files-with-compressed-dng/
Lightroom Classic (and ACR) recently added support for a new DNG format which enables the ability to create RAW files which are 92% smaller with no visible loss of quality! This is made possible by using a new “lossy” image format based on the new JPEG XL (aka JXL) file format in DNG v1.7. Lossy means that the new DNG is not 100% identical to your original RAW file. However, in my testing, the results are extremely good and would be indistinguishable from the original in nearly any real scenario. The loss of quality is nearly undetectable for the vast majority of RAW files. Even the most discerning photographer would be hard pressed to see a difference in any realistic scenario (you’ll find a difference if you enlarge well beyond reasonable limits).
-
J'ai fait un nouveau commentaire cet après-midi sur le bug Chromium qui demande sa prise en charge : https://issues.chromium.org/issues/40270698
J'espère que Google va changer d'avis.
-
Dans les réponses qui sont arrivées juste après, ça parle de surface d'attaque. Le non-support de JPEG XL viendrait de la volonté de limiter les surfaces d'attaque. C'est vrai que plus il y a de codec, plus il y a de potentielles failles dans l'implémentation.
On l'a vu avec webp qui a deux implémentations, une avec perte et une sans perte, les algo étant complètement différents, cela fait deux surfaces d'attaques sur un seul format d'image...
Maintenant on a aussi des solutions pour limiter ces risques, les outils d'analyses de code sont de plus en plus poussé et on a des langages qui permettent d'écrire du code performant et sécurisé comme le Rust. La solution pourrait venir de ce dernier, dans les commentaires ils parlent du projet jxl-rs, un décodeur JPEG XL implémenté en Rust.
Good news! The jxl-rs project (a safe and fast JPEG XL decoder implementation in Rust) is progressing well. We are currently on track to deliver the following milestones:
End of February 2025: Initial decoding capabilities and a preliminary API.
April 2025: Aiming for a conforming decoder implementation, fully compliant with the JPEG XL specification.
July 2025: Critical code paths fully SIMDified and with a finalized API. This anticipated timeline should allow jxl-rs to be ready for browser integration in alignment with Interop 2025 goals.
Les choses vont peut-être bouger d'ici à cet été.
-
Réduire la surface d'attaque, c'est une réponse que tu peux utiliser pour tout ce que tu refuses d'implémenter.
Il y a pas mal de code peu utilisé.
Tu prends par exemple Safari, le navigateur prend en charge les images TIFF ! C'est un format qui n'est pas utilisé sur internet (pourquoi l'accepter dans Safari ?) et en plus c'est un format à tiroir, avec des choix infinis dans ses options (choix de l'algorithme de compression) qui fait que c'est un format impossible à sécuriser et qui a encore plusieurs fois par année des CVE.
JPEG-XL est un format qui semble avoir une surface d'attaque plus importante que AVIF (relativement simple), mais bien plus faible que TIFF.
Personnellement, j'aurais préféré, à l'époque où il était encore temps, que AVIF soit retiré des premiers navigateurs compatibles pour mettre à la place JPEG XL. Aujourd'hui c'est trop tard pour retirer AVIF.
-
Tu prends par exemple Safari, le navigateur prend en charge les images TIFF ! C'est un format qui n'est pas utilisé sur internet (pourquoi l'accepter dans Safari ?) et en plus c'est un format à tiroir, avec des choix infinis dans ses options (choix de l'algorithme de compression) qui fait que c'est un format impossible à sécuriser et qui a encore plusieurs fois par année des CVE.
A noter que le TIFF peut contenir des images compressées en JPEG XL... :)
-
Tous les navigateurs web devraient prendre en charge JPEG-XL en 2026 avec l'implémentation en Rust.
La question que je me demande : Est-ce que cela met en danger AVIF et qu'il pourrait être retiré des navigateurs ou c'est trop tard et les navigateurs auront AVIF et JPEG-XL ?
-
Tous les navigateurs web devraient prendre en charge JPEG-XL en 2026 avec l'implémentation en Rust.
En tout cas Chrome semble avoir révisé sa position sur le sujet:
https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKcBw219k/m/tdJGfuLQAAAJ?utm_medium=email&utm_source=footer
-
En tout cas Chrome semble avoir révisé sa position sur le sujet:
Oui, cela a été annoncé le 19 décembre 2024 : le support de JPEG XL sur tous les navigateurs web arrive pour 2026.
Google dévelope un décodeur JPEG XL en Rust qui sera implémenté dans tous les navigateurs web sauf Safari qui a son propre décodeur JPEG XL.
Dans les réponses qui sont arrivées juste après, ça parle de surface d'attaque. Le non-support de JPEG XL viendrait de la volonté de limiter les surfaces d'attaque. C'est vrai que plus il y a de codec, plus il y a de potentielles failles dans l'implémentation.
On l'a vu avec webp qui a deux implémentations, une avec perte et une sans perte, les algo étant complètement différents, cela fait deux surfaces d'attaques sur un seul format d'image...
Maintenant on a aussi des solutions pour limiter ces risques, les outils d'analyses de code sont de plus en plus poussé et on a des langages qui permettent d'écrire du code performant et sécurisé comme le Rust. La solution pourrait venir de ce dernier, dans les commentaires ils parlent du projet jxl-rs, un décodeur JPEG XL implémenté en Rust.
Good news! The jxl-rs project (a safe and fast JPEG XL decoder implementation in Rust) is progressing well. We are currently on track to deliver the following milestones:
End of February 2025: Initial decoding capabilities and a preliminary API.
April 2025: Aiming for a conforming decoder implementation, fully compliant with the JPEG XL specification.
July 2025: Critical code paths fully SIMDified and with a finalized API. This anticipated timeline should allow jxl-rs to be ready for browser integration in alignment with Interop 2025 goals.
Les choses vont peut-être bouger d'ici à cet été.
J'ai fusionné tous les messages lié à JPEG XL dans un même sujet (c'était un peu éparpillé avant)
-
Démo de JPEG-XL en 2025 dans Chromium avec la page https://jpegxl.info/resources/jpeg-xl-test-page.html :
Le format JPEG XL animé, aujourd'hui rarement supporté, serait de la partie...
https://lafibre.info/videos/logiciels/202511_demo_jpeg-xl_dans_chromium.webm