XL-Converter 1.0, billet d'humeur et plaidoyer

Posté par  . Édité par Julien Jorge, palm123 et ted. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
31
6
juin
2024
Internet

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.


  1. voir ce paragraphe dans la doc sur les Core Web Vitals de Google. 

  2. les paramètres sont dans la source, use the force luke, read the code 

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

  • # IHM pas très ergonomique

    Posté par  . É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  . Évalué à 3.

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

      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  . Évalué à 6. Dernière modification le 14 juin 2024 à 15:16.

      [..] par l'encoder jxl. -> le convertisseur jxl

      [..] plutôt un ré-encodage -> une reconversion

      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  (site web personnel) . Évalué à 4.

    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’affichage

    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  . É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  (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  (site web personnel) . Évalué à 2. Dernière modification le 17 juin 2024 à 11:14.

    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.

    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:

    ./example compress -quality 80 test-jpegturbo.jpg
    
    LD_LIBRARY_PATH=$MYPATH/libjpegli  ./example compress -quality 80 test-jpegli.jpg
    

    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  . É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  (site web personnel) . Évalué à 3.

        avec jpegli on baisse à 40 et la qualité est bien meilleure, pour nous le rendu équivaut à du 75 de TurboJpeg

        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  . É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  (site web personnel) . Évalué à 3.

            C'est très sensible dès lors que tu tripote des options avancées, comme les tables de quantization.

            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)

            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

            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  (site web personnel) . Évalué à 4.

        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.

        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  (site web personnel) . Évalué à 2.

          ces paramètres/ résultats

          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)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.