Auteur Sujet: JPEG XL arrive en 2026 dans les navigateurs web (Lu 112 fois)

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

kgersen · « **Réponse #1 le:** 16 juin 2023 à 00:28:27 »

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

vivien · « **Réponse #2 le:** 16 juin 2023 à 07:33:25 »

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.

vivien · « **Réponse #3 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 #4 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 #5 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 #6 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 #7 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 #8 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 #9 le:** 27 août 2023 à 08:47:21 »

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.

vivien · « **Réponse #10 le:** 10 décembre 2023 à 22:21:13 »

Une chanson pour geeks : Elle parle de donner une chance au format d'image Jpeg XL

Google doit se sentir visé...

fred_mgnt · « **Réponse #11 le:** 11 décembre 2023 à 14:40:39 »

Citation de: vivien le 16 juin 2023 à 07:33:25

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

Citation de: vivien le 16 juin 2023 à 07:33:25

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