Bonjour tout le monde,
Oui j'insiste un peu, parce que je suis comme beaucoup de gens : je ne comprends pas. Il y a un refus d'intégrer JPEG XL dans les navigateurs qui n'est pas du tout argumenté.
Dernière en date : Interop 2024. L'intégration de JPEG XL est la fonctionnalité la plus plébiscitée. Elle a pourtant été écartée :
We wanted to let you know that this proposal was not selected to be part of Interop this year.
We did not have consensus to include this proposal. This should not be taken as a comment on the technology as a whole
Et c'est tout. Ce sont les seuls arguments. Tout le monde pointe du doigt Google dans l'histoire, comme le relate Techspot.
Beaucoup d'entreprises ont montré leur intérêt manifeste pour ce format. Google semble complètement contre, mais sans vouloir le dire. Mozilla traîne la patte, sans argumenter non plus. Safari et Edge l'intègrent.
Je n'ai pas de conclusion :(
# Moche
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6 (+3/-0).
C'est vraiment moche comme position. Mais je pense qu'ils finiront par s'y mettre, JPEG-XL intéresse trop d'acteurs pour qu'ils puissent se permettre de l'ignorer longtemps.
Par exemple, je ne serais pas surpris qu'on ait dans quelques années des appareils photos et des téléphones qui commencent à stocker nativement les photos en JPEG-XL. A un moment, ça finira peut-être par gonfler Google, de devoir les convertir dans tous les sens.*
Accessoirement, est-ce qu'il n'existe pas déjà des bibliothèques JavaScript permettant une prise en charge externe de JPEG-XL par les navigateurs déficients ?
[^] # Re: Moche
Posté par Psychofox (Mastodon) . Évalué à 5 (+2/-0).
https://addons.mozilla.org/en-GB/firefox/addon/jxl/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search
[^] # Re: Moche
Posté par Glandos . Évalué à 5 (+3/-0).
Il y a l'extension de navigateur qui va bien : https://github.com/zamfofex/jxl-crx
[^] # Re: Moche
Posté par BAud (site web personnel) . Évalué à 4 (+2/-0).
ça s'appelle du contournement :-) (et c'est déjà bien : cela montre que c'est faisable)
la bonne pratique est d'argumenter sur la demande d'évolution (sur le bugzilla) — statistiques d'utilisation à l'appui — ou mieux, proposer un patch permettant de l'intégrer upstream ; au final, c'est moins de boulot de part et d'autre que d'argumenter ad nauseam :D
[^] # Re: Moche
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4 (+2/-0).
Il me semble me rappeler que le code a été retiré de Chromium. Le récrire n'apporterait probablement pas grand chose.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Moche
Posté par Psychofox (Mastodon) . Évalué à 4 (+3/-2).
C'est triste à dire mais ça ne viendra que si les iphones prennent des photos en jpeg-xl nativement.
Les cameras sont devenus des appareils trop confidentiels et souvent utilisées par des gens qui font de toute façon du post-processing donc il n'y a pas forcément corrélation entre format source et cible.
[^] # Re: Moche
Posté par nud . Évalué à 9 (+7/-0).
Le format d'image de l'iPhone est HEIC depuis un certain temps et ça n'a pas l'air d'avoir beaucoup motivé les navigateurs…
[^] # Re: Moche
Posté par Psychofox (Mastodon) . Évalué à 6 (+3/-0). Dernière modification le 06 février 2024 à 12:51.
Mais HEIC n'est pas royalty free.
[^] # Re: Moche
Posté par Nicolas Boulay (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 06 février 2024 à 14:02.
Et jpeg-XL ?
"La première sécurité est la liberté"
[^] # Re: Moche
Posté par Mimoza . Évalué à 6 (+5/-1).
Pas le moins du monde : JPEG_XL
Bref, comme dirais certain, il « […] a tout pour plaire … pas assez cher[…])
Étrangement Google a pas mal participé a sa conception … mais maintenant fait tout pour le ralentir
[^] # Re: Moche
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 9 (+6/-0).
Parce que Google a aussi conçu le format webp et qu'il veut le voir s'imposer à la place ? (je ne sais pas si pertinent comme remarque).
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Moche
Posté par cosmocat . Évalué à 10 (+9/-0).
En terme de temps à investir pour migrer loin de l'utilisation de leur format webp, oui, ça peut être pertinent comme remarque.
En terme purement de technologie, non, ça n'a pas de sens. Avif et Jpeg Xl sont autrement meilleur que webp (conçu il y a plus de 10 ans).
Cf l'infographie "Battle of the codecs" en bas de cette page:
https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg
[^] # Re: Moche
Posté par Mimoza . Évalué à 8 (+6/-0).
Attention cloudinary est le plus gros promoteur de JXL, vu qu’il en est le co-auteur. Comparatif a prendre avec les précautions d’usage.
[^] # Re: Moche
Posté par Thomas Debesse (site web personnel) . Évalué à 10 (+21/-1). Dernière modification le 08 février 2024 à 08:30.
Je suis un très fort soutien de WebP, en remplaçant du JPEG et du PNG 8-bit. Mais WebP n’est pas un concurrent qui peut se mesurer au Jpeg XL.
Pour remplacer du JPEG, le WebP avec perte gagne haut la main, en terme de taille, et en terme de qualité :
Pour remplacer le PNG 8-bit aussi. Par défaut le format PNG n’est pas mieux qu’un BMP dans un zip. C’est littéralement une matrice RGBA compressée avec zlib. Pour mieux compresser il faut utiliser des profils que quasiment aucun logiciel n’utilise, qui vont justement stocker l’image dans d’autres formats qu’une simple matrice RGBA avant de compresser. En utilisant un optimiseur on peut en général gagner entre 5 et 25% de taille. Il existe d’autres choses plus folles comme des optimiseurs qui après ça font des algorithmes génétiques pour tester des milliers de combinaisons pour trouver celle qui compresse le mieux. Après ça on peut encore utiliser zopfli qui est un algorithme de compression zlib très bourrin qui fait beaucoup de calculs pendant très longtemps pour gagner de la place. Quand on mélange tout ça, on obtient un outil qui peut passer des heures (littéralement) pour économiser 1 octet. Au début on gagne 5~25%, après on gagne des octets.
Eh bien en faisant tourner ce genre d’optimiseur PNG pendant des heures, on peut parfois approcher (mais seulement approcher) ce que fait WebP en quelques secondes. Attention cependant, pour avoir un WebP vraiment avec perte il faut non-seulement utiliser l’option
-losslessmais aussi l’option-exactde l’outilcwebp, autrement le rendu final peut être sans perte mais pas les données (par exemple sans-exactun pixel rouge avec une transparence complète donc avec le rouge totalement invisible pourrait être mis dans une autre couleur pour optimiser).Maintenant que j’ai vanté les louanges de WebP, comparons avec JPEG XL. Quand je dis « 8-bit » ou « 12-bit », c’est par canal. Un JPEG 8-bit par canal c’est 24-bit (trois canaux), un PNG transparent au format RGBA 8-bit c’est 32-bit (quatre canaux), mais dans tous les cas ont va appeler ça du « 8-bit ». C’est l’unité de base, indépendamment des formats internes.
Non-seulement JPEG-XL permet de recompresser sans perte les milliards de JPEG qui existent, JPEG étant le standard de fait pour les images compressées avec pertes en 8-bit, ce qu’aucun autre format ne fait.
Mais JPEG-XL gère les images en haute résolution, c’est donc un concurrent du PNG 16-bit et probablement de nombreux usages du TIFF (il y a peut-être des fonctionnalités que j’oublie là tout de suite).
Pour comprendre quel est l’impact de la taille des canaux dans la vie réelle, je donne un exemple très concret, avec deux appareils photos réflexe du marché (un peu anciens) que je connais, le Nikon D5100 et le Nikon D7000. Il est probable que Nikon fasse toujours ce que je vais dire sur ses modèles récents, mais je suis sûr pour ces modèles alors on va garder ceux-là pour l’exemple. Ces deux appareils photos ont exactement le même capteur et la même carte mère, et peut recevoir exactement les mêmes objecifs. Le D5100 est dans la gamme amateur, le D7000 est dans la gamme semi-professionnelle. La différence fondamentale ? Elle est logicielle, Nikon a bridé le D5100 à ne produire que des images 12-bit alors que le D7000 produit des images 14-bit. Ce bridage logiciel signifie que le photographe a moins de données au développement et est restreint dans sa capacité d’édition, il devient plus difficile de sauver des photos un sur-exposées ou sous-exposées, ou dont la balance des blanc est mauvaise.
Le marché des appareils photographiques est organisé comme ça : 8-bit pour le compact du tout-venant , 12-bit pour le reflex du photographe amateur, 14-bit pour le reflex du semi-professionnel et professionnel, je ne sais pas s’il existe des appareils photos 16-bit mais vous voyez l’idée.
Le gros avantage de AVIF comme de WebP et de HEIF c’est qu’ils sont dérivés de formats vidéos et qu’il est très probable que les téléphones auront des décodeurs matériels pour ça, même en entrée de gamme car l’industrie veut vendre de la vidéo à tout le monde, et probablement pour beaucoup, des encodeurs matériels (dès lors qu’ils filment dans les formats vidéos dont ces formats d’images sont dérivés).
Mais ils restent des formats soit d’entrée de gamme, soit « amateur éclairé », pas plus.
Il y a vraiment besoin de sortir du 8-bit par canal qui correspond aux usages d’il y a plusieurs décennies, AVIF a une carte a jour en proposant 12-bit, ce qui j’imagine est suffisant pour beaucoup d’usages (surtout quand on édite pas).
Mais JPEG-XL a deux atouts de choix: le premier c’est la compatibilité avec le jpeg, et là c’est certainement l’industrie du Web qui va pousser (sauf que le Web c’est beaucoup trop Google aujourd’hui), le second c’est la haute précision. Le seul format JPEG-XL est un concurrent de tous les formats d’images, en terme de taux de compression et de qualité de compression il n’y a aucun autre format qui puisse se vanter de faire mieux de manière significative, quand il ne les oblitère pas complètement, ou fait des choses que les autres ne font même pas. Ni WebP, ni AVIF, ne peuvent concurrencer JPEG-XL autrement que par de la politique.
JPEG-XL est l’équivalent pour les images de Opus, qui sur le plan de l’audio sans perte remplace dans les applications et sur le web tous les autres codecs, que ce soit les codecs téléphoniques que les codecs musicaux. Faire une plate-forme de conférence ? Opus. Faire une plate-forme de streaming de musique ? Opus. En fait JPEG-XL fait mieux que ça, il ne couvre pas seulement tous les besoins du web (compression 8-bit avec perte, canal alpha…), il couvre aussi les besoins sans perte. Pour conserver la comparaison c’est comme si Opus se mettait à aussi concurrencer FLAC sur son terrain…
Je ne sais pas ce qui pousse Google à pousser AVIF si fort et à mettre autant d’obstacles à JPEG XL. Ils ont connaissance de brevets dormant dans JPEG XL ? Ils se disent que ne payer la production et l’intégration d’une puce pour AV1/AVIF dans leurs milliers de machines sera moins cher que de devoir intégrer en plus une puce JPEG-XL?
L’opposition à JPEG-XL ne peut pas être technique, JPEG-XL est meilleur que les autres et de loin. Il ne reste donc que la politique et l’économie.
Bref, je suis un fort soutien du WebP, mais WebP ce n’était bien qu’avant que JPEG-XL n’existe. Si JPEG-XL est disponible dans un flux de travail, je ne ferai pas du tout de WebP. Je ne défendrai WebP que si JPEG-XL n’est pas disponible.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Moche
Posté par Thomas Debesse (site web personnel) . Évalué à 6 (+3/-0).
Je me demande d’ailleurs si on ne pourrait pas ajouter JPEG-XL à des formats de stockages divers, que ce soit par exemple le format interne des dépôts Git, ou même un système de fichier… Et qu’à chaque fois qu’un JPEG est enregistré, la couche inférieure le convertit en JPEG-XL pour le stockage et le reconvertir vers JPEG à la lecture.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Moche
Posté par Thomas Debesse (site web personnel) . Évalué à 3 (+1/-1).
Je voulais dire HEIC (le format d’Apple). HEIF est un conteneur pour plusieurs codecs. HEIC est un format HEIF basé sur HEVC (H.265), AVIF est un format HEIF basé sur AV1, donc « AVIF et HEIF » ne veut rien dire. 🤓️
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Moche
Posté par Funix (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Non, HEIC n'est pas un format d'apple, il faut arrêter avec cette légende tenace qui attribue à Apple toutes les inventions technologiques. Il a été développé en parallèle du format HEVC pour la vidéo par le même groupe de travail ISO Moving Picture Experts Group (MPEG).
HEIC est un format qui s'impose dans le monde de la photo avec Apple certes, mais également Sony et Canon, excusez du peu, mais il est considéré ici malgré ses qualités comme le mal absolu car il intègre des brevets logiciels mais au même titre que jpeg-xl !
https://www.funix.org mettez un manchot dans votre PC
[^] # Re: Moche
Posté par Thomas Debesse (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 11 février 2024 à 15:40.
Oui, disons que c’est un format poussé par Apple, ma remarque portait sur la différence HEIF/HEIC.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Moche
Posté par cosmocat . Évalué à 4 (+3/-1).
Merci pour ces longues et détaillées explications pour des informations que j'essayais de donner succinctement.
J'aime beaucoup ce résumé:
[^] # Re: Moche
Posté par orfenor . Évalué à 4 (+2/-0).
Ta comparaison entre JPEG et WEBP est critiquable. Mais tu ne connais probablement pas ces gory details :
Au niveau du JPEG, les niveaux de qualité ne veulent pas dire grand chose parce qu'ils ne sont pas standardisés. Ils diffèrent d'un logiciel à l'autre. Par conséquent comparer avec le même niveau de qualité en WEBP n'a pas de sens. On compare la qualité du rendu à la fois en l'appréciant de façon subjective (par exemple on compte les défauts, les mauvaises couleurs, les artefacts, …) et de façon quantifiée avec MSSIM.
L'algo de compression JPEG utilisé est très important. Lui aussi diffère d'un logiciel à l'autre. Celui de libjpeg-turbo est le plus rapide, tout en proposant un excellent rapport poids/qualité. Celui de Mozjpeg dérive de libjpeg-turbo et c'est de loin le plus avancé pour le rapport poids/qualité, au point d'égaler fréquemment WEBP sur ce point,tout en étant beaucoup plus rapide.
Je te renvoies aux comparaisons citées plus haut : l'équipe WEBP et celle de Cloudinary (dirigée par Jon Sneyer) utilise systématiquement libturbo et Mozjpeg.
[^] # Re: Moche
Posté par Thomas Debesse (site web personnel) . Évalué à 5 (+2/-0).
Peut-être, mais j’ai aussi mentionné la taille des fichiers. Et pour un paramètre de départ équivalent (dont le sens est certes variable selon les outil), le webp montre moins de dégradations visuelles, mais sa taille est divisée de moitié. Et ça c’est sans appel, quelque soit la qualité utilisée.
J’ai mentionné l’option de qualité pour simplement expliciter que la comparaison n’est pas biaisée de ma part, que je n’ai pas utilisé des options qui arrangeaient le résultat. Utiliser une qualité de 92 dans un outil de compression est sensé ne pas être une option qui donne des résultats volontairement mauvais. C’est ça que la mention de qualité signifie dans ma comparaison.
Ce que j’aime bien avec le webp produit dans cette comparaison, c’est qu’il y a clairement des artefacts, mais peut-être que 95% d’entre eux ne sont identifiables que si on ne compare pas avec l’original côte à côte. Par exemple certaines couleurs (étoiles bleues) ne sont pas respectées (désaturées), mais la géométrie est conservée. Si on n’a jamais vu l’original, on ne peut pas savoir que l’information est perdue. Il y a aussi un peu de « color banding », et si ceci peut être repéré sans voir l’original, il est possible de douter que ces bandes soient d’origine si on ne voit pas l’original.
Alors qu’en comparaison, en observant le jpeg, même sans connaître l’original, on peut pointer du doigt les artefacts sans aucun doute.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Moche
Posté par orfenor . Évalué à 4 (+2/-0). Dernière modification le 12 février 2024 à 15:14.
Je n'y avais pas pensé, c'est très pertinent. À mon avis, ça vaut le coup de transmettre cette remarque à Jon Sneyer et aux autres, vu qu'on n'en parle jamais et qu'il est couramment admis (au vu des tests) que l'algo de Mozjpeg est aussi performant que WEBP.
[^] # Re: Moche
Posté par Libb . Évalué à 2 (+2/-0).
Merci beaucoup pour cette explication qui a permis à l'ignare que je suis de mieux comprendre ce dont il est question ici.
[^] # Re: Moche
Posté par Mimoza . Évalué à 6 (+4/-0). Dernière modification le 06 février 2024 à 14:37.
Je me répond car j’avais du mal a voir ce qu’ils entendaient par «rétrocompatible».
Il semble que l’on puisse convertir du JPEG en XL avec tout les gains que ça apporte, AINSI que le processus inverse aussi (XL -> JPG) et retrouver le fichier original au pixel près.
[^] # Re: Moche
Posté par cosmocat . Évalué à 6 (+4/-0).
Oui, il y a une conversion lossless (donc bijective) du Jpeg vers le Jxl qui apport une gain de 15 à 20% environ.
Aussi, l'algo the decompression du jxl est capable de décompresser le jpeg donc il n'y aurait pas 2 algos à maintenir, celui du jxl remplaçant celui du jpeg.
Je me demande même si, une fois le support dans les navigateurs ajouté, il n'y aurait pas moyen de renvoyer automatiquement du jxl là où du jpeg est demandé pour économiser de la bande passante sans avoir à adapter les sites webs ("migration" sans avoir à rien faire…)
[^] # Re: Moche
Posté par cg . Évalué à 4 (+2/-0).
Les CDNs le font déjà avec les GIF et les PNG, qui sont convertis en Webp à la volée, ça me semble tout à fait réaliste pour JPEG.
# Je ne comprends pas...
Posté par ff9097 . Évalué à 9 (+7/-0).
…l'engouement de JPEG-XL. On a déjà pas mal de formats d'images modernes. Qu'apporte-t-il ?
[^] # Re: Je ne comprends pas...
Posté par Mimoza . Évalué à -2 (+3/-7).
JPEG_XL
[^] # Re: Je ne comprends pas...
Posté par Marotte ⛧ . Évalué à 9 (+7/-1). Dernière modification le 06 février 2024 à 19:56.
Je suis un peu surpris que la page française Wikipédia explique que le JPEG XL est amené a remplacer un tas d’autres formats, notamment le PNG et le GIF
Je suis p-e à côté de la plaque mais pour moi PNG et JPEG ne sont pas performant sur le même type d’image. Pour certaines images, avec des à-plats de couleur, par exemple l’image « parfaite » (ie : pas une photo) d’un drapeau de n’importe quel pays, sera mieux compressées par un format utilisant l’indexation des couleurs, comme PNG. Au contraire, JPEG est beaucoup plus efficace sur une photo « normale ».
Personnellement je grince des dents à chaque fois que je vois une image qui aurait dû être compressée en PNG mais l’a été en JPEG. Je ne sais pas si je suis particulièrement sensible, et les dégâts de la compression JPEG dépendent du niveau de compression, mais des gens me disent souvent : « bah elle a quoi comme problème l’image ? ». Quand je peux leur montrer la différence sur une même image, typiquement un logo, leur mettre côté à côte un JPEG et un PNG, même si le JPEG est pas particulièrement dégueux il font « Haaa ! Oui en effet :\ ». Parce qu’on les voit souvent bien les « vaguelettes » du JPEG sur ce type d’image. Fort heureusement ça a tendance à disparaître ce genre d’horreur, m’enfin c’est quand même toujours bien trop répandu je trouve.
Est-ce que JPEG LX (JPLX de son petit nom si je comprends bien) possède un mode de compression avec couleur indexée qui lui permet de concurrencer voir dépasser PNG sur le type d’image dont je viens de parler ? Est-ce que c’est ça que signifie "il peut stocker les informations d’espace colorimétrique" ? Cela lui permet donc, avec un espace colorimétrique ayant très peu de couleur, (genre 3 ou 4 par exemple), de faire exactement ce que fait PNG ou GIF ? (GIF étant totalement à la ramasse niveau performance comparé à PNG me semble--t-il, mais, ayant une killer feature que PNG ne fait pas : l’image animée (cet incontournable du Web 1.0 des années 1990 !), il n’a pas disparu encore de nos jours sûrement pour ça (en Web 2023.11-efc66de4 !)
[^] # Re: Je ne comprends pas...
Posté par freem . Évalué à 5 (+3/-0).
J'ai envie de dire, prends donc un fichier avec plein de contrastes abruptes et d'autres nuancés, prends le raw, convertis le dans les divers fichiers et testes.
A la fois webp, qui me scotche déjà, et à priori JXL ont un mode de compaction lossless, avec, justement, 0 perte de donnée. Dans ce mode, ils marchent mieux en moyenne que le traditionnel jpeg, déjà.
[^] # Re: Je ne comprends pas...
Posté par Gof (site web personnel) . Évalué à 10 (+9/-0).
JPEG-XL supporte la compression sans perte tout comme le PNG. Sauf que c'est un meilleur algo de compression plus rapide et qui compresse mieux.
Donc oui, JPEG-XL remplace le PNG.
[^] # Re: Je ne comprends pas...
Posté par cosmocat . Évalué à 8 (+6/-0).
Jpeg XL possède 2 modes de compression: sans perte (comme png) et avec pertes (comme Jpeg).
Et on dit que jxl est à même de remplacer les 2 car dans les 2 cas, la compression est meilleure. Sans compter les autres fonctionnalités permises.
Pour les autres formats, il y a toujours des cas particuliers/de niche où png ou Jpeg est meilleur pour une raison ou une autre alors que jxl, quel que soit le critère est meilleur que ces 2 anciens formats.
Donc oui, jxl est à même de remplacer les 2 pour un usage photo ou dessin.
Je te conseille de lire le comparatif que j'ai donné dans un autre commentaire…
Par contre, autant avant avec l'extension tu pouvais savoir si c'était avec ou sans perte et beaucoup ne maîtrisent pas la notion comme tu viens de l'indiquer donc avec un seul format qui fait les 2, il va y avoir des erreurs humaines… (mais en même temps ça a aussi un côté pratique).
[^] # Re: Je ne comprends pas...
Posté par Marotte ⛧ . Évalué à 7 (+4/-0).
OK je vois, merci à vous trois.
Mais PNG peut aussi faire de la compression avec perte à priori. Ceci dit je veux bien croire que JPLX soit plus avantageux dans 99% des cas, ou même 100%.
Mais alors quel est le prix à payer ? Est-ce qu’il n’y en a aucun et que se sont juste les progrès en mathématiques, en algorithmie ou encore en électronique qui on permis cette amélioration ? De nouveaux algorithmes et/ou de nouveaux jeux d’instructions des processeurs modernes ?
[^] # Re: Je ne comprends pas...
Posté par cosmocat . Évalué à 4 (+2/-0). Dernière modification le 08 février 2024 à 10:16.
De ce que je comprend, non PNG ne fait pas de la compression avec perte mais c'est plutôt qu'on applique des filtres qui "dégradent" l'image (donc comme avec perte) avant compression pour exploiter les spécificités de l'algo de compression de png et donc obtenir des meilleurs résultats. Le but étant, comme les algo de compression avec perte de trouver les bons filtres qui dégradent visuellement l'image le moins possible.
Pour moi, oui, ce sont des avancées algorithmiques/mathématiques qui permettent l'amélioration. Il ont trouvé un manière plus futée d'encoder les données (ou de dégrader l'image pour que l'algo l'encode mieux).
[^] # Re: Je ne comprends pas...
Posté par nud . Évalué à 5 (+3/-0). Dernière modification le 06 février 2024 à 21:56.
D'après https://jpegxl.info/ le format (JPEG XL, pas LX) supporte la compression sans perte.
Par ailleurs il existe une version "animée" du JPEG (MJPEG) et du PNG (APNG), relativement bien supportés par les navigateurs. Et certains formats récents d'image sont en fait une seule frame d'un format vidéo (webp, HEIC, AVIF)
(bon y'a eu trois réponses avant, ça m'apprendra à mettre 1h avant d'appuyer sur "Envoyer")
[^] # Re: Je ne comprends pas...
Posté par freem . Évalué à 4 (+2/-0).
Il apporte une meilleure volumétrie, ce qui veut dire dire moins de données à transférer via le réseau ou a stocker sur disque.
Ainsi qu'une meilleure parallélisation, ce qui veut dire que tu peux charger ou compresser plus vite. C'est utile pour un jeu par exemple, dont chaque texture est souvent un assemblage de plusieurs images, mais pour faire du montage photo, ça doit être agréable aussi d'aller plus vite.
Sans avoir de pertes supplémentaires, voire en en ayant moins.
Récemment, j'ai recompacté la totalité des cartes portées (par quelqu'un d'autre, et dont je dispose) de tremulous vers unvanquished (des jeux libres) pour l'expérience, et le gain de volume en convertissant des images vers webp, une fois tout recompacté, à été de l'ordre de 20%.
Les cartes en question on été portées à la main, sans chercher a les optimiser (ce n'est pas moi, mais je connais la personne), du coup les images originelles ont été conservée dans leur format initial, et compresser juste les tga, utilisés pour les textures, m'a fait gagner 10% de place, une fois repackagé.
Les 10% restants sont des fichiers qui ne sont plus nécessaires au fonctionnement des serveurs d'unv, qui devaient auparavant être fournis au client malgré tout.
A l'heure actuelle, mon dossier "pakpath" qui stocke les données venue du net pèse 3 giga. 20% de 3 gigs, c'est pas rien, c'est un quasi-CD-rom, et je parle de webp, à priori JXL fait mieux que webp)
Alors, je comprend que, du point de vue de l'utilisateur qui a 3 ou 4 milliers de photos, on s'en fout. Mais du point de vue de ceux qui bossent avec l'outil informatique ou l'utilise pour autre chose que les photos de vacance, ça peut vite être significatif. Je veux dire zut, le gain de compression entre png "naïf" et webp est, en pratique, d'environ 10% sur mon cas d'usage, et JXL ferais mieux en moyenne?
[^] # Re: Je ne comprends pas...
Posté par alkino . Évalué à 2 (+0/-0).
Bon, j'ai voulu voir par moi-même. Vous savez les % de vitesses et tout ça des fois c'est un peu mensonger. Du coup j'ai pris un sample de vacances à moi avec 120 photos.
de JPEG à JPEG-XL avec l'option sans aucune perte.
J'ai donc compilé libjxl (c'est assez facile).
326Mo => 246Mo : 25% !
Bon ensuite pour les visionner, j'ai du installer le plugin firefox. Lancer un server http python (ouais l'extension a refus de toucher aux fichiers dans
file://.Et ça semble vraiment être sans perte !
[^] # Re: Je ne comprends pas...
Posté par cosmocat . Évalué à 3 (+1/-0). Dernière modification le 08 février 2024 à 13:48.
Mes tests avec un pool de photo nettement plus important me donnais un chiffre plutôt entre 16 et 18%.
Mais ça dépend peut-être du niveau de compression initial des photos et ma mémoire me fait peut-être également défaut…
Cependant, c'est une excellente fonctionnalité très appréciable !
[^] # Re: Je ne comprends pas...
Posté par cosmocat . Évalué à 4 (+2/-0).
J'avais utilisé ce script (je crois) pour faire mes tests qui donne le pourcentage à la fin:
https://codeberg.org/kylxbn/jxl-migrate
# L'avis de Google...
Posté par Meap . Évalué à 9 (+9/-0).
Ce serait officiellement à cause de tests de performances non concluants.
Voir discussion complète ici.
Officieusement ce pourrait être tout autre chose…
[^] # Re: L'avis de Google...
Posté par cosmocat . Évalué à 3 (+2/-1).
Ça on sait que c'est un peu du foutage de gueule car le format qui est en train de se répandre dans les navigateur est avif et même si la compression est plutôt bonne, on sait que les perfs sont moins bon tout particulièrement comparé au jxl…
[^] # Re: L'avis de Google...
Posté par orfenor . Évalué à 5 (+4/-1).
Les graphiques des test de performance montrent au contraire que JPG-XL est de loin le plus lent des formats à décoder.
Vu ces graphiques je trouve que ça fait sens de ne pas adopter JXL tout de suite. Grâce à Chrome, Google a d'excellentes statistiques sur les mobiles utilisés dans le monde. Beaucoup sont anciens à mon avis (sinon pourquoi inclure un Pixel3 dans les tests?), leur batterie l'est donc tout autant. Or plus c'est lent à décoder, plus ça bouffe du CPU et de la RAM, plus le niveau de la batterie baisse vite. Sur une batterie déjà usée, ça doit être catastrophique.
Finalement, Apple qui a aussi d'excellente statitiques et qui connaît à fond son matériel, l'implémente peut-être parce que sur les iPhones ça passe. En plus Apple connait bien ses acheteurs qui vont se ruer vers des iPhones plus puissant avec les nouvelles puces M1/M2 pour décoder le nouveau format qu'il est hype.
[^] # Re: L'avis de Google...
Posté par orfenor . Évalué à 4 (+2/-0).
Ah zut, je voulais dire que si l'on en croit les graphiques ça fait sens, etc. Pas que ça faisait sens tout court.
[^] # Re: L'avis de Google...
Posté par cosmocat . Évalué à 5 (+3/-0).
Ce n'est ni l'avis de Cloudflare, ni celui de Facebook ( https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c18 ).
[^] # Re: L'avis de Google...
Posté par abriotde . Évalué à 1 (+1/-1).
Je pense que Google veut pousser WebP et donc qu'un concurrent de plus ne l'arrange pas
[^] # Re: L'avis de Google...
Posté par Psychofox (Mastodon) . Évalué à 7 (+4/-0).
Je ne crois pas parce que Google ne gagne rien avec webp commercialement. Et ils n'auraient pas ajouté le support expérimentalement. À mon avis ça vient surtout d'une tentative de réduire les coûts. Plus ils réduisent les formats supportés plus ils réduisent les librairies externes à utiliser et à auditer, les risques de CVE, etc. Je n'ai jamais vu de JPEG-XL sur le web. Des webp, oui en pagaille. C'est un format qui est peut-être arrivé un poil trop tard dans la bataille.
[^] # Re: L'avis de Google...
Posté par raphj . Évalué à 4 (+2/-0).
J'imagine aussi que ça peut être des questions de coûts de maintenance.
Peut-être parce que ça n'est pas pris en charge sur Chrome et Firefox justement, parce que sinon, vu de loin avec un œil distrait, c'est plutôt séduisant, je me pencherais probablement sur la question perso.
[^] # Re: L'avis de Google...
Posté par Psychofox (Mastodon) . Évalué à 4 (+2/-1).
Justement il était pris en charge par chromium jusqu'à ce que le support soit retiré.
[^] # Re: L'avis de Google...
Posté par raphj . Évalué à 6 (+4/-0). Dernière modification le 07 février 2024 à 12:30.
Ouais, mais derrière un drapeau expérimental (pas activé par défaut). Ça n'encourage pas l'adoption. C'est presque comme si l'accès au pont était barré, pour reprendre la comparaison évoquée par un autre commentaire.
[^] # Re: L'avis de Google...
Posté par cosmocat . Évalué à 10 (+9/-0).
Y'a une expression que j'aime bien pour illustrer cela: "On ne décide pas de construire un pont en comptant le nombre de personnes qui traversent à la nage…"
Donc t'en a pas vu pas parce que le format n'a pas d’intérêt mais plutôt car personne n'a d’intérêt à servir des jxl tant que ce n'est pas supporté par les navigateurs.
Y'en a effectivement mais c'est tellement specifique au web qu'il y a pleins de logiciels qui ne le supporte pas contrairement au jxl qui est un format qui couvre tous les usages et donc qui pourrait être utiliser par tout les logiciels.
[^] # Re: L'avis de Google...
Posté par Psychofox (Mastodon) . Évalué à 1 (+1/-3). Dernière modification le 07 février 2024 à 10:43.
Jpeg-XL a justement été supporté par chromium. Ce support a été retiré par manque d'adoption. Alors peut-être que Google a manqué de patience, mais bon il n'y a pas de standard qui dit combien de temps on doit attendre avant de déclarer un format adopté ou non.
[^] # Re: L'avis de Google...
Posté par raphj . Évalué à 3 (+1/-0).
https://linuxfr.org/users/glandos/journaux/jpeg-xl-ne-fait-pas-consensus-au-sein-de-l-union-des-vendeurs-de-navigateurs#comment-1950239
[^] # Re: L'avis de Google...
Posté par orfenor . Évalué à 3 (+2/-1).
Non c'est faux : le code était expérimental et pas activé.
[^] # Re: L'avis de Google...
Posté par cosmocat . Évalué à 5 (+3/-0).
Heu… Un support derrière un flag, c'est juste pour faire des tests, jamais pour que ce soit adopté. Donc c'est normal que t'en ai jamais croisé.
[^] # Re: L'avis de Google...
Posté par freem . Évalué à 3 (+1/-0).
La question de la capacité des dev a faire la maintenance se pose, alors, parce que bon… soit on intègre tous les formats un par un, à la main, et la ça pique le coût de maintenance, forcément.
Ou alors on réfléchit 2s, et on utilise une lib dont c'est le job. Il y en existe quelques unes, moi j'en connais 2:
Je ne sais pas si le format JXL est supporté par elles, mais ça semblerait un bon point de pénétration, d'autant que FreeImage2 supporte un mécanisme de plugins.
En fait, webp n'est spécifique au web que dans les esprits, pour moi.
Quelle serait la raison pour que ça soit spécifique?
Qu'on me dise que DDS est spécifique aux jeux vidéo, ça, ok, c'est littéralement conçu de manière a ce que ça soit sous-optimal pour des applications graphiques qui n'ont pas autant de besoins d'upload vers la mémoire graphique (ça serait trop gros, c'est optimisé non pas pour l'espace mais pour être géré par les GPU a un coût minimal).
De fait, il y la même chose supposée ici. Enfin, on y pose la question, on n'y affirme rien, ce qui est légèrement différent du cas auquel ce message répond.
[^] # Re: L'avis de Google...
Posté par cg . Évalué à 5 (+3/-0).
Probablement ! D'ailleurs on voit régulièrement que ce n'est pas forcément le "meilleur format technique" qui reste ou est utilisé. Le Vorbis ne s'est jamais vraiment imposé face au MP3/MP4, ni le PNG face au GIF (ça a fini par venir, mais ça a été long), ou encore le GIF animé face à MNG.
Ou encore Minix dans le domaine des noyaux :D.
[^] # Re: L'avis de Google...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2 (+0/-1).
Oui, mais non en fait. On a vu arriver WebM, qui a mis quelques années à s'imposer. Puis AVIF, qui a mis encore moins de temps à être largement supporté. Maintenant, c'est JPEG-XL, et je ne vois pas en quoi sa situation chronologique est différente de cette d'AVIF justement.
[^] # Re: L'avis de Google...
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 07 février 2024 à 10:56.
Si, il arrive après AVIF et WebM/WebP qui sont déjà là.
Pour qu'il y ait bascule et adoption, il faut qu'il y ait une différence significative. Entre jpeg et jpeg-xl, elle est réelle. Entre WebP ou AVIF et Jpeg-XL, elle est beaucoup moins flagrante.
Exemple entre gérer à la fois des png et des jpeg, au final je préfère ne gérer que des WebP qui fonctionne tant en compression avec que sans perte. WebP apporte de plus un gain d'espace significatif par rapport à jpeg en terme d'espace à qualité égales. Gain de place de 25% par rapport au png, et entre 25 et 35% par rapport à du jpeg avec des artefacts moins désagreables à regarder.
Jpeg-XL fait encore un peu mieux en terme de pods/qualité et offre d'autres avantages (taille maximum, bit-depth) mais qui ne sont pas forcément pertinents dans un usage web actuel. Et le pas en avant qu'il offre en terme de qualité et practicité par rapport à webp est beaucoup plus petit qu'entre jpeg original et webp.
[^] # Re: L'avis de Google...
Posté par orfenor . Évalué à 5 (+3/-0). Dernière modification le 07 février 2024 à 13:07.
C'est d'ailleurs l'argument de Mozilla (lien cité plus haut).
C'est son universalité qui rend JPEG-XL intéressant. On voit bien pourquoi les photographes vont l'utiliser par exemple, d'autres secteurs vont aussi l'adopter (comme les nouveaux tel Samsung pour les photos). Ce qui pourrait alors se passer c'est une adoption plus tardive sur le web, vu que
Donc dans quelques années, les circuits spécialisés, la puissance disponible et la taille des images pourrait faire que le gain relativement faible de JXL sur AVIF ou WEBP représente un important gain absolu.
[^] # Re: L'avis de Google...
Posté par cosmocat . Évalué à 4 (+2/-0).
+100!
Et je peux ajouter que jxl, en terme de fonctionnalités, capacités (je me permet de remettre ce bon résumé https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg ) et cas d'usage est meilleur dans tous les cas que tous les formats pre-existants. Donc pour la facilité d'usage, y'a pas photo (un seul format pour tout la chaîne, tous les logiciels,…). Y'a que avif qui peut avoir un avantage dans les très fortes compressions mais ça en devient peut-être même un cas d'usage de niche. Pour tout le reste, il y a jxl 😜
[^] # Re: L'avis de Google...
Posté par orfenor . Évalué à 3 (+1/-0).
AVIF est limité dans la taille des images (9 Mo), le nombre de bits (12) et le nombre de canaux (3).
[^] # Re: L'avis de Google...
Posté par cosmocat . Évalué à 5 (+4/-1). Dernière modification le 07 février 2024 à 13:48.
Ouais, on a la chance d'avoir un format ayant des avantages sur les autres (support du décodage progressif, précision suffisante pour le support HDR,…), intérêt par de nombreux acteurs (cloudflare, Facebook, Adobe,…) et tout cela bloqué par un seul acteur.
Je suis presque enclin à penser que c'est un abus de position dominante…
[^] # Re: L'avis de Google...
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 07 février 2024 à 15:01.
3 en fait.
Google, Microsoft (même s'ils réusent blink, ils pourraient très bien maintenir jpeg-xl dans leurs branches locales) et Mozilla (jpeg-xl supporté uniquement sur les nightly).
[^] # Re: L'avis de Google...
Posté par orfenor . Évalué à 5 (+3/-0).
Même si Jon Sneyers espère qu'on aura des circuits spécialisés pour JXL, il souligne que JXL se décode facilement en "pur logiciel" contrairement à AV1 et HEVC sur lesquels se basent AVIF et WEBP.
[^] # Re: L'avis de Google...
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+8/-0).
La puissance du nouveau matériel, mais mon PC ne compte pas devenir plus puissant avec le temps et je compte bien le faire durer le plus longtemps possible :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: L'avis de Google...
Posté par Strash . Évalué à 5 (+3/-0).
C'est pas comme si ton ordinateur actuel était à genou lorsqu'il décode une image JXL. Je serais surpris si tu faisait la différence dans une expérience en double aveugle…
[^] # Re: L'avis de Google...
Posté par tisaac (Mastodon) . Évalué à 10 (+25/-1). Dernière modification le 07 février 2024 à 14:41.
C'est certain, faire des tests en aveugles avec des images, au final, on ne voit pas la différence ;-)
Surtout, ne pas tout prendre au sérieux !
[^] # Re: L'avis de Google...
Posté par aiolos . Évalué à 5 (+3/-0).
Ben le mien, il a vu sa RAM tripler au cours de sa vie…
[^] # Re: L'avis de Google...
Posté par cg . Évalué à 6 (+6/-2).
De quoi tu te mêle, vil prolétaire ? Cette conversation est entre riches qui regardent des images 12K sur des écrans 5' polis comme des miroirs.
(ça va, mon CPU de 2015 supporte SSE4.2 et AVX2, ça devrait bien se passer pour moi)
[^] # Re: L'avis de Google...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5 (+2/-0).
Il faut demander à l'équipe de VLC d'écrire un décodeur JPEG-XL :)
"La première sécurité est la liberté"
# Problème de licence, as usual
Posté par Da Scritch (site web personnel, Mastodon) . Évalué à 3 (+2/-1).
Sauf erreur de ma part, JPEG-XL est d'un usage gratuit, pas libre : y'a des licences toujours actives, non sécurisées (elles peuvent redevenir payantes), et l'algo repose toujours sur des brevets logiciels toujours actifs (le format de fichier JPEG est lui heureusement devenu domaine public depuis un bail).
[^] # Re: Problème de licence, as usual
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
Le format mais pas l’algorithme il me semble. Ce qui, pour moi, en fait un format pas vraiment ouvert.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Mon expérience
Posté par Maderios . Évalué à 3 (+1/-0).
J'ai testé webp et jxl en convertissant des fichiers tiff définition 10.000 x 7500 pixels vers webp et jxl.
La conversion tiff -> webp demande un temps acceptable mais concernant jxl, c'est une autre affaire. La conversion tiff -> jxl demande tellement de temps que ce format est inutilisable pour moi. Je n'ai même pas eu la patience d'attendre la fin de la conversion. Outils utilisés: BQM dans Digikam et Gimp
A qualité égale, quand on travaille, le facteur temps est déterminant et non les quelques Mo économisés, ce qui pour moi rend webp beaucoup plus intéressant que jxl/JPEG XL
[^] # Re: Mon expérience
Posté par cosmocat . Évalué à 2 (+0/-0).
Ce retour d'expérience ne permet pas de conclure grand chose. Lossless ou lossy? Quel niveau de compression pour jxl ?
Car si c'est trop long, il faut essayer de compresser avec le niveau le plus faible pour gagner en temps et voir si la taille est satisfaisante par rapport à webp…
[^] # Re: Mon expérience
Posté par Maderios . Évalué à 2 (+0/-0).
Toujours sans pertes pour tiff, webp. jxl, etc…Quant au webp, vu la différence énorme de taille entre un tiff et un webp, je m'en fiche un peu. Pour le moment, je teste, sans plus.
[^] # Re: Mon expérience
Posté par Glandos . Évalué à 2 (+0/-0).
À vue de nez, je dirais que pour ce genre de cas, c'est QOI qu'il faut tester.
[^] # Re: Mon expérience
Posté par Maderios . Évalué à 2 (+1/-1).
Le format .quoi ne semble pas supporter les images 16 bit.
Concernant le webp, il ne s'agit pas réellement d'un format sans perte. Il suffit d'agrandir une image, genre x1600, pour le constater. Cela se voit dans les teintes de certains pixels quand on part d'un fichier .nef 6000x400 pour le convertir au .tif puis le .tif au .webp. Les nuances du fichier .tif ne sont pas complètement respectées. Mais là, on est hors-sujet parce que les utilisateurs de navigateurs web se fichent complètement de ce genre de problème.
[^] # Re: Mon expérience
Posté par Maderios . Évalué à 2 (+0/-0).
Rectification de ma faute de frappe, il s'agit d'un fichier 6000 x 4000 (plus précisément 6032 x 4032 issu d'un capteur 24x36)
[^] # Re: Mon expérience
Posté par cosmocat . Évalué à 4 (+2/-0).
Le version 0.10 juste sortie est donc pour to:
https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.