XL-Converter est un utilitaire graphique pour convertir vos images en formats utilisables sur Internet. Outre les classiques JPEG et PNG il y a donc AVIF, WEBP et JPEG-XL. L’outil se veut ergonomique avec un minimum d’options pratiques. Par exemple on peut indiquer une dimension ou un poids maximum pour les images. À mes yeux, l’intérêt d’XL-Converter c’est surtout le format Jpeg. Pourquoi ? parce que ce format est loin d’être mort : tout en travaillant sur Jpeg-XL, les chercheurs suisses de Google ont développé un nouvel algorithme d’encodage du Jpeg classique, et cet algo est très performant.
Jpegli, le nouvel algo, tire son nom du jargon suisse, tout comme guetzli, butteraugli, etc. par la même équipe. Il est inclus dans la version 0.10 de la libjxl, la bibliothèque de référence pour Jpeg-XL (c’est normal il en réutilise du code). Et par là, il se retrouve l’encodeur Jpeg de XL-Converter.
Jpeg est un format de compression qui date des années 80. C’est grâce à lui qu’on voit le web en couleur. On a souvent tenté de le remplacer, il résiste. C’est normal, non content d’offrir un bon rapport qualité/poids, il y a belle lurette que nos puces décodent les images Jpeg en un éclair. Jpeg est donc efficace et rapide, sa compression avec perte n’enlève que des détails invisibles à nos yeux. Enfin il a des défauts quand même : pour gagner encore plus de poids, il gomme encore plus de détails et nous laisse des artefacts bien visibles, qui ressemblent à des saletés dans l’œil, celles qu’on découvre en regardant un mur blanc. En principe je ne vous apprends rien, vous êtes habitués à optimiser le poids de vos images sur Internet et vous savez jouer du curseur pour obtenir le meilleur compromis pour la meilleure image Jpeg possible (© Voltaire).
Nos accès Internet deviennent sans cesse plus rapides, la puissance et la Ram sur nos ordis augmentent de même, les nuisances énergétiques itou. Ça m’importe. Et même si les nuisances vous indiffèrent, vous vous êtes peut-être déjà retrouvé pris au piège d’une zone blanche, ou bien sur une île surpeuplée de touristes en été, ou bien dans un pays lointain aux prises avec un vieil ordi malmené par les débits inconstants et la lourdeur de votre site web préféré, bref dans ma peau. La situation est tout de même assez commune pour qu'un des critères majeurs de bon référencement des pages web sur Google soit le temps de chargement et d’affichage1.
Normalement vous savez qu’il y a plusieurs facteurs là-dedans, matériels, logiciel et humain. Humain, voilà ce qui nous intéresse. C’est l’humain qui fait l’effort de soigner son code, d’utiliser un format qui décompresse vite, de redimensionner ses images et de compresser suffisamment, en acceptant des pertes que l’autre internaute ne verra jamais sur un écran non calibré, salis par les doigts, sous un éclairage douteux et le plus souvent coloré (dans les villes).
Il y a quelques mois, je pensais vous décrire les merveilles de Mozjpeg : les premières versions de Webp n’avaient pas convaincu Mozilla qui avait proposé un nouvel algo et un nouvel outil, plutôt efficace. En remplaçant purement et simplement la libjpeg, les gains en compression était du même niveau que Webp (à l’époque), mais pour ceux qui aimaient jongler avec les paramètres2, les gains étaient et sont toujours bien meilleurs. Tout le monde n’étant pas imageo-technophile, les feignants pouvaient se contenter d’utiliser ImageOptim pour un résultat équivalent.
Aujourd’hui, même les feignants n’ont pas d’excuses : Jpegli est super simple à utiliser3, plus rapide et meilleur que Webp ou Avif, produit beaucoup moins d’artefacts classiques du Jpeg et se décode à la vitesse de l’éclair puisque c’est du Jpeg normal. Et au sein d’XL-Converter c’est de la balle.
Je n’ai rien de plus à dire. En attendant Jpeg-XL dans tous nos navigateurs, Jpeg à la sauce Jpegli c’est trop bon, mangez-en.
En apéritif, goûtez donc cette petite note du divin Jon Sneyers :
More recently, the JPEG-XL team at Google has built yet another JPEG encoder, jpegli, which is both faster and better than even mozjpeg. It is based on lessons learned from guetzli and libjxl, and offers a very attractive trade-off: it is very fast, compresses better than WebP and even high-speed AVIF, while still producing good old JPEG files that are supported everywhere.
-
voir ce paragraphe dans la doc sur les Core Web Vitals de Google. ↩
-
les paramètres sont dans la source, use the force luke, read the code ↩
-
disons plutôt qu’il n’y a pas besoin d’autre paramètres que le niveau de compression pour être bien meilleur que Webp. ↩
Aller plus loin
- XL-Converter, sa doc et ses screenshots (370 clics)
- Les sources sur Github (75 clics)
- Jpegli pour les curieux (159 clics)
- Mozjpeg pour les pointilleux (42 clics)
- "JPEG XL and the Pareto Front" pour les soucieux (40 clics)
- Dis donc Orfenor t'as fini d'affirmer des trucs sans preuve (102 clics)
# IHM pas très ergonomique
Posté par cosmocat . Évalué à 3.
D'abord c'est cool un logiciel qui inclus jpegli.
Par contre je trouve que l'IHM n'est pas très claire (pour pas dire piégeuse) si on veut faire de la conversion jpeg<->jxl, si on tient compte de l'existence de la fonctionnalité de conversion sans perte permise par l'encoder jxl.
Dans ce cas là, on ne sait pas exactement quel est le sens de "Lossless". Le format "lossless" de jxl ou la fonctionnalité de conversion lossless particulière à jpg<->jxl?
Est-ce qu'il converti vers la version lossless de jxl. Ou est-ce qu'il convertit de jpeg vers jxl avec la fonctionnalité de conversion lossless?
Un test ne m'a pas permis d'être sûr même si je crois qu'il fait un conversion lossless (qui est peut-être la plus logique actuellement tant que jxl n'est pas utilisé dans le web mais qui peut-être changera 🤞)
Pareil pour l'inverse. Mais dans ce cas, il semble qu'il ne fasse pas de conversion lossless mais plutôt un ré-encodage (donc pas l’opération lossless inverse).
[^] # Re: IHM pas très ergonomique
Posté par cosmocat . Évalué à 3.
En parcourant les format, je viens de voir que la conversion lossless jxl->jpeg est disponible quand on sélectionne le format de sortie… png 😅 (mais c'est dispo \o/)
[^] # Re: IHM pas très ergonomique
Posté par cosmocat . Évalué à 2.
Du coup maintenant que j'ai trouvé l'option de conversion lossless jxl->jpeg, je peux être sûr que c'était bien une conversion lossless jpeg->jxl qu'il fait.
[^] # Re: IHM pas très ergonomique
Posté par CodePoems . Évalué à 10.
Hello,
I'm the author of XL Converter.
I've detailed the way this option works is the docs: https://xl-docs.codepoems.eu/jpg-reconstruction
If you feed the program a JPEG and check "Lossless" it will automatically use Lossless JPEG Recompression.
Future versions will feature dedicated options in the format selector to avoid confusion.
[^] # Re: IHM pas très ergonomique
Posté par cosmocat . Évalué à 7.
Woaw!! Finding this post and creating an account to provide feedback is really impressive! What a dedication!
Thanks a lot.
I was not aware of this necessity of reconstruction data.
I found this on the subject: https://github.com/libjxl/libjxl/blob/main/doc/format_overview.md#jpeg-bitstream-reconstruction-data
[^] # Re: IHM pas très ergonomique
Posté par Olivier Jeannet . Évalué à 6. Dernière modification le 14 juin 2024 à 15:16.
S'il vous plaît, parlez de convertisseur / compresseur ou de conversion / compression, car il ne s'agit pas d'un codage (pas une transformation bijective car avec perte), et encore moins d'un "en"codage qui est un anglicisme. Le JPEG est un algorithme de compression (tout comme l'est le MPEG), et j'ai presque toujours entendu parler de convertir en JPEG, pas de coder en JPEG.
Dans la même veine, jamais compris pourquoi on s'est mis à parler « d'encodage vidéo » alors que c'est de la compression ou conversion, indépendamment de l'anglicisme avec le préfixe "en".
Noter au passage que "codec" c'est (même en anglais) pour coder/decoder (codeur/décodeur) ; on ne parle pas de "encodec".
# Google is dying
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ca doit être le 42° critère alors, car les premières pages de résultats sont presque toujours des sites bloated.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Google is dying
Posté par orfenor . Évalué à 2.
Non, c'est un des tout premiers, si ce n'est le tout premier.
Je le vois très bien avec Amazon : c'est hyper lourd, mais le premier écran s'affiche vite. Pour simplifier je n'ai pas précisé que c'est la première partie de l'écran que Google prend en compte, c'est à dire ce qu'on voit avant de faire défiler.
[^] # Re: Google is dying
Posté par Zorro (site web personnel) . Évalué à 2.
La fameuse ligne de flottaison, dont on se demande bien comment elle est calculée, de nos jours, par rapport à quel type d'écran…
Il n'empêche, clairement depuis quelques mois, quoiqu'on cherche, on tombe soit sur des pages de vente de produits (et très souvent, plein de résultats sont la même page, ou des pages proches, du même site !), soit des faux-blogs pourris, qui parlent de strictement tout, et aux contenus visiblement écrits et traduits par des machines (à croire qu'ils sont générés à la volée en fonction de ta recherche Google, comme le font certains fabriquants de produits personnalisables sur Amazon, comme des coques de téléphones).
Il est devenu beaucoup plus difficiles qu'à une époque de trouver du contenu généré par des utilisateurs, des vrais avis, des actus.
À la décharge de Google, il faut admettre que beaucoup de contenu intéressant ne se fait plus sur le web (blog ou forums), et que beaucoup de sites d'actus ont mis en place des accès payants, ou refusent de se faire indexer - Google Actu est devenu quasiment inutilisable… Tout est en train de migrer sur des plate-formes beaucoup plus volatiles et impossible à indexer correctement (X, tik-tok, insta,…)
# Plus rapide (?), mais pas plus light
Posté par Tarnyko (site web personnel) . Évalué à 2. Dernière modification le 17 juin 2024 à 11:14.
Une note là-dessus.
Je viens d'essayer. Plus précisément:
- j'ai pris l'exemple C de JPEG-Turbo;
- j'ai appliqué ce patch (qui rend l'exemple "standard" en retirant le format 12-bits qui n'existe pas partout) et compilé ;
- j'ai executé 2 fois,
1x avec JPEG-Turbo, 1x avec JXL-jpegli:
Il en ressort que la 2ème image produite par jpegli est entre 3-5 Ko plus grosse.
C'est peut-être effectivement plus rapide sur des traitements de grosses images (ou des lots de grosses images) ; mais comme la taille était mon critère, je juge bon de l'indiquer.
[^] # Re: Plus rapide (?), mais pas plus light
Posté par orfenor . Évalué à 6.
C'est le taux de compression qui ne va pas. Il ne faut pas mettre le même taux vu que la qualité de compression est supérieure avec jpegli.
Par exemple, je travaille sur un tas d'images de jeux et jouets. En comprimant via TurboJpeg, on baisse la qualité jusqu'à 65 pour la première image chargée sur la page. Évidemment c'est pas très beau. Tandis qu'avec jpegli on baisse à 40 et la qualité est bien meilleure, pour nous le rendu équivaut à du 75 de TurboJpeg ; le poids est bien entendu nettement plus bas.
J'observe une grosse différence sur la présence et l'intensité des artéfacts habituels du Jpeg, un flou moindre et des couleurs moins dégradées.
Sur la vitesse, en principe TurboJpeg reste vainqueur.
[^] # Re: Plus rapide (?), mais pas plus light
Posté par BAud (site web personnel) . Évalué à 3.
comment juges-tu de la qualité ? (comparaison à la perte effective par rapport à l'image de départ ?)
un tableau d'équivalence serait intéressant selon la résolution / taille des images de départ et temps obtenus /
qualitéchoix de compression de chaque outil (entre effort / quality / lossy mode ça risque d'être un peu compliqué surtout si le paramètre quality n'est pas linéairement lié entre chaque outil :/)[^] # Re: Plus rapide (?), mais pas plus light
Posté par orfenor . Évalué à 4.
Jehan avait déjà expliqué que la valeur numérique "qualité" du jpeg n'était pas comparable d'un algo à l'autre, en particulier entre Photoshop et Gimp. C'est très sensible dès lors que tu tripote des options avancées, comme les tables de quantization.
Jon Sneyer dit qq mots de l'appréciation sur son blog : ni les algos, ni les règles de comparaison visuelles ne suffisent. La subjectivité en fait partie. Pour nous, subjectivement, le résultat est bien meilleur, la différence nous parait si grande qu'on ne voit pas l'intéret d'utiliser des règles de comparaison.
Cela étant, garde à l'esprit qu'il s'agit pour nous de pages web qui sont presque toujours consultées sur les petits écrans des smartphones, rayés, salis de traces de doigt, et sous un éclairage très variable.
[^] # Re: Plus rapide (?), mais pas plus light
Posté par BAud (site web personnel) . Évalué à 3.
moui, forcément, ça fout en l'air tout algo numérique de mesure d'écart en analyse d'image :/ et c'est tables de quantification en français ;-)
pour autant, vu qu'un algo de compression n'y touche pas dans le traitement d'image, selon certaines conditions faire ressortir une métrique (dans son domaine d'application) resterait intéressant :p quitte à ce que cela soit validé par une métrique subjective in fine
et je n'ai pas (encore) retrouvé les commentaires de Jehan< traitant du sujet (mais tu m'as donné de la lecture intéressante :p)
en tout cas, à voir https://github.com/libjxl/libjxl/pulse le sujet reste actif, inclure des métriques pour voir la « progression » permettrait de mieux comprendre les axes choisis… (même si je suis d'accord avec toi que toute métrique requière une analyse et se doit de rester dans un domaine d'interprétation compréhensible)
malencontreusement, les smartphones ont souvent plus de pixels que nos écrans 1080p o_O mais, oui, ce n'est pas ton cas d'usage, je veux bien l'entendre :D
[^] # Re: Plus rapide (?), mais pas plus light
Posté par Tarnyko (site web personnel) . Évalué à 4.
Effectivement 😲 !
Je viens de tester en double-aveugle avec Joritro (un camarade de code !) et ces paramètres/ résultats :
- JPEG : 80% (23,5 Ko)
- JPEG-LI : 60% (21,0 Ko)
Et là 2,5 Ko de moins pour la version JPEG-LI -c'était prévisible- mais oui elle est également plus jolie "à l'oeil" avec notamment moins de pâtés irréguliers dans l'espace central.
Je te remercie beaucoup, et vais du coup considérer cette lib pour mes traitements !
[^] # Re: Plus rapide (?), mais pas plus light
Posté par BAud (site web personnel) . Évalué à 2.
il manque le temps de traitement et les images avant / après (pour apprécier l'aspect subjectif)
dis-nous ce qu'il en est sur 1000 images, sans les images au pire ;-) (on ne peut pas tromper une personne mille fois… !lcdlp inside :p)
[^] # Re: Plus rapide (?), mais pas plus light
Posté par Tarnyko (site web personnel) . Évalué à 2.
Un tel batch est à faire oui !
Perso je ne saurai m'engager sur aucun délai ; sauf que je posterai le résultat ici pour sûr :-).
[^] # Re: Plus rapide (?), mais pas plus light
Posté par BAud (site web personnel) . Évalué à 3.
ça, ce n'est pas demandé :p
ça déjà, ce sera plus intéressant (avec les hypothèses / cas d'usage permettant de cibler le résultat _o/)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.