YOGA Image Optimizer v1.1 : résultats des travaux de l'été

Posté par  (site web personnel) . Édité par Benoît Sibaud, Ysabeau 🧶, bobble bubble et patrick_g. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
67
12
sept.
2021
Graphisme/photo

Je vous avais présenté la toute première version de YOGA Image Optimizer (sous licence GPLv3) juste avant les vacances d’été, et je reviens aujourd’hui avec une nouvelle version pleine d’améliorations !

Si vous découvrez YOGA Image Optimizer avec cet article, sachez qu’il s’agit d’une interface graphique pour la bibliothèque YOGA qui permet de convertir et d’optimiser (réduire le poids) des images. Elle accepte la plupart des formats courants en entrées, et supporte les formats JPEG, PNG et WebP en sortie.

Sommaire

Capture d’écran de YOGA Image Optimizer v1.1

Pour commencer, MERCI !

Avant de vous présenter les principales nouveautés du logiciel, je tenais à vous remercier. J’ai reçu énormément de messages et de retours suite à ma précédente publication, que ce soit en commentaire sous l’article publié ici, sur LinuxFr.org, ou via d’autres moyens (Mastodon, Reddit, Discord, e-mail…).

Outre les messages d’encouragement, j’ai reçu énormément de conseils et d’astuces sur l’optimisation des différents formats d’images ; et on m’a également envoyé pléthore d’outils et de bibliothèques « concurrents » dont je ne soupçonnais pas toujours l’existence. Tout ça m’a déjà permis d’apporter des améliorations à YOGA, et ça ne fait que commencer !

On m’a également suggéré pas mal de fonctionnalités qui manquaient cruellement à la première version (qui était assez minimale), et certaines d’entre elles sont à présent implémentées. 😀️

On arrête là le teasing et on passe aux choses sérieuses ! 😉️

Améliorations de l’optimisation des images

Cette nouvelle version de YOGA Image Optimizer s’accompagne d’une mise à jour de la bibliothèque YOGA sur laquelle je travaille en parallèle. Et cette mise à jour apporte quelques améliorations sur l’optimisation des images.

Pour commencer, cette nouvelle version réduit le poids des JPEG de 2.4 % à 7.3 % supplémentaires par rapport à la version précédente de YOGA. Ceci a été rendu possible grâce à MozJPEG dont on utilise à présent une partie des optimisations en complément de Guetzli, et ceci se fait sans perte de qualité supplémentaire : on applique uniquement les optimisations sans perte de MozJPEG (passage d’un encodage séquentiel à un encodage progressif, et optimisation de la table de Huffman) une fois l’encodage effectué par Guetzli.

D’ailleurs cet ajout de MozJPEG dans YOGA a donné naissance à une nouvelle bibliothèque, mozjpeg-lossless-optimization, qui permet d’accéder aux optimisations de MozJPEG depuis le langage de programmation Python.

Et tant qu’on parle du format JPEG, YOGA prend maintenant en charge la métadonnée EXIF d’orientation ce qui lui permet de toujours sortir les images dans le bon sens.

L’autre amélioration de YOGA porte sur le format PNG. Dans de rares cas, la première version de la bibliothèque pouvait sortir des PNG légèrement plus gros en sortie qu’en entrée. C’était notamment possible lorsque l’image avait déjà été (particulièrement bien) optimisée par un autre logiciel. Le problème se produisait d’ailleurs sur l’avatar de l’un des membres de LinuxFr.org.

Quoi qu’il en soit ceci ne peut plus se produire : dans le pire des cas l’image de sortie fera le même poids que celle d’entrée (et, en général, YOGA arrivera quand même à gratter quelques octets).

Pour arriver à ce résultat, lors d’une optimisation PNG vers PNG, YOGA compare la taille du fichier de sortie et celui d’entrée, et s’il s’avère que le résultat est moins optimal, il sort alors son scalpel et commence à opérer lui-même. Pour résumer l’opération, il va aller récupérer les morceaux (chunks) essentiels dans l’image d’entrée, il va concaténer les chunks IDAT qui contiennent les données de l’image, puis il va recompresser le tout avec Zopfli et enfin recoller tout ça pour former un nouveau fichier PNG.

Nouveautés de l’interface graphique

Passons à présent aux nouveautés de l’interface graphique.

Pour commencer, YOGA Image Optimizer est maintenant configurable. Une toute nouvelle fenêtre de configuration a donc fait son apparition. Cette dernière permet actuellement :

  • de choisir combien de threads seront utilisés pour l’optimisation des images (donc combien d’images seront optimisées en parallèle),

  • de sélectionner le thème GTK à utiliser et de choisir s’il faut utiliser de préférence la variante sombre (lorsque celle-ci est disponible),

  • et enfin, il est à présent possible de choisir comment sera formé le nom et l’emplacement des fichiers de sorties parmi trois possibilités :

    • « À côté du fichier original » : le fichier de sortie se retrouvera dans le même dossier que celui d’entrée, mais il sera suffixé avec .opti. Il s’agit du comportement déjà présent dans la première version.
    • « Dans un sous dossier » : un dossier nommé « optimized/ » est créé à côté du fichier d’entrée et l’image optimisée sortira dans celui-ci en conservant le nom de l’image d’entrée.
    • « Motif personnalisé » : permet de choisir finement le résultat désiré.

Capture d’écran de la fenêtre de configuration

Ensuite, l’une des fonctionnalités qui m’a été énormément demandée était de pouvoir sélectionner plusieurs images à la fois, afin de permettre l’édition de leurs paramètres d’un seul coup. Cette fonctionnalité avait été écartée de la première version par souci de simplicité (il s’agissait à ce moment-là de réussir à sortir une base que l’on pourrait améliorer par la suite). Je suis donc heureux de vous annoncer que c’est maintenant possible, comme vous pourrez le constater dans la petite vidéo ci-dessous :

Vidéo : démonstration de la multi sélection

Une autre fonctionnalité qui était elle aussi très attendue, était la possibilité de redimensionner les images. En fait, YOGA (la bibliothèque), permettait déjà de le faire, mais cette fonctionnalité n’était pas exposée dans la première version de l’interface graphique. YOGA Image Optimizer v1.1 corrige ce manque et permet donc de redimensionner les images. Il est toutefois important de noter que YOGA permet uniquement de réduire la taille d’une image et conservera toujours les proportions.

Capture d’écran de la fonctionnalité de redimensionnement

Enfin, dernière amélioration majeure : le bouton « Arrêter ». Dans la première version de YOGA Image Optimizer, ce bouton ne permettait que d’annuler l’optimisation des images en attente. Celles déjà en cours continuaient à s’optimiser en arrière-plan, consommant donc inutilement les ressources de la machine.

Ce « problème » était dû à une limitation de l’API Python utilisée, et un gros travail a été effectué dans cette version afin que le bouton puisse effectivement arrêter les optimisations déjà en cours. Maintenant quand on dit « Stop », c’est stop ! 😤️

Capture d’écran du bouton « Arrêter »

Et ensuite ?

Je ne compte pas m’arrêter en si bon chemin, et je vais continuer à améliorer le logiciel.

L’interface graphique dispose de toutes les fonctionnalités dont j’ai besoin, elle évoluera donc probablement assez peu dans les prochains mois (mais n’hésitez pas si vous avez des idées !). Par contre j’ai encore de nombreux projets pour YOGA, la bibliothèque qui effectue les optimisations sous le capot.

Je compte notamment étudier l’inclusion de pngquant afin de proposer des optimisations PNG à perte mais encore plus efficace (ce sera évidemment optionnel, hein 😜️). Je voudrais également me pencher davantage sur le WebP pour produire des images encore plus petites dans ce format. Enfin je souhaiterais intégrer davantage de formats de sortie, et je m’intéresse notamment à AVIF et à JPEG XL.

Quoi qu’il en soit, j’espère que YOGA pourra vous être utile, et je reste à l’écoute de toute suggestion, idée ou astuce pour pousser ce projet toujours plus loin ! 😁️

Aller plus loin

  • # encore des compléments et des compliments

    Posté par  . Évalué à 8.

    Je ne me souviens pas si on en a déjà parlé :

    • As-tu regardé les optimisations de jpeg-recompress ? et aussi on l'utilise en définissant un écart à l'image originale et non pas une qualité de compression jpeg, c'est astucieux.
    • Kornelsky, le mainteneur de Mozjpeg, a écrit ImageOptim, un logiciel semblable au tien, pour Mac. Le code source est disponible ainsi qu'une version en ligne très efficace.

    Sinon bravo pour le boulot, quels progrès depuis la dernière fois ! et puis je vois que tu soignes l'interface, c'est top.

    De mon côté j'ai fait un petit script Perl qui optimise la compression pour le web avec Mozjpeg de façon très simple : avec des plus et des moins on augmente ou baisse la qualité du résultat, tout le reste est automatique. J'enregistre le niveau de compression dans le fichier résultat comme ça si on relance le script on a le niveau de compression utilisé précédemment.

    • [^] # Re: encore des compléments et des compliments

      Posté par  (site web personnel) . Évalué à 7.

      Pour ce qui est de jpeg-recomrpess et de imageOtpim, il faut encore que je me penche un peu dessus pour voir ce que je pourrais en tirer.

      Du côté des JPEGs je pense pas être tellement en mesure de gagner quelque chose (mais ça vaut toujours le coup de se renseigner et de tester des trucs).

      Pour les PNGs par contre je pense qu'il y a encore une petite marge d'évolution pour la compression sans perte, et une grosse avec la compression à perte (réduction de couleurs). Je suis d'ailleurs en ce moment en train de travailler sur des bindings Python pour libimagequant (la bibliothèque utilisée derrière pngquant). :)

      Sinon bravo pour le boulot, quels progrès depuis la dernière fois ! et puis je vois que tu soignes l'interface, c'est top.

      Merci ! Effectivement je souhaite que l'interface reste agréable et simple à utiliser malgré le nombre d'options qui va forcément un peu augmenter.

      Je pense encore rajouter 2 ou 3 trucs dedans pour la prochaine version, mais je vais surtout me concentrer sur la compression maintenant. :)

      • [^] # Re: encore des compléments et des compliments

        Posté par  . Évalué à 2.

        Petite note :

        • mozjpeg permet d'utiliser 6 tables de quantifications pré-définies, selon la table choisie on gagne pas mal — chez moi ce sont souvent les tables 2 et 3 (curieusement la table 2, pas faite pour le web, donne des bons résultats)
        • en compressant séparément luminance et chrominance on gagne beaucoup, la chrominance étant mal perçue par l'oeil, on peut descendre a 10 ou 20 sur 100.

        • [^] # Re: encore des compléments et des compliments

          Posté par  (site web personnel) . Évalué à 1.

          Oui, mais la « principale » lib sur laquelle je m'appuie pour l'optimisation des JPEGs, c'est Guetzli. MozJPEG est utilisée en complément pour gratter quelques % supplémentaires. C'est pour ça que je n'utilise qu'une partie des optimisations de MozJPEG (celles sans pertes).

          Il faudrait trouver le temps de faire un véritable benchmark de MozJPEG vs Guetzli. En comparant la qualité perçu des images (le problème c'est qu'il existe plusieurs modèles de comparaison).

          • [^] # Re: encore des compléments et des compliments

            Posté par  . Évalué à 2.

            Sans oublier qu'il existe aussi plusieurs mauvaises qualités d'écran et plusieurs mauvaise conditions de vision. Entre le quai de métro sur un téléphone portable ordinaire et le graphiste dans une salle à éclairage constant sur un écran calibré… Le web n'est pas fait pour les images trop belles (à moins de savoir quel est son public).

    • [^] # Re: encore des compléments et des compliments

      Posté par  . Évalué à 3.

      Bravo pour ce gros travail, un outil bien pratique.

      J'avancerais une suggestion : nettoyage des métadonnées. On peut des fois peut gagner plusieurs kb en retirant des tas de trucs inintéressants dans les commentaires emboutis, dans les IPTC ou autres XMP.

      Je verrais bien une option cochable "Effacer métadonnées", avec peut-être une sous-option "Effacer EXIF", les données exif ne prennent pas de place mais ça peut être sympa pour anonymiser une photo avant de la balancer sur le net (il faudrait peut-être garder quand même dans ce cas les données exif sur l'orientation de l'image, puisque tu t'en sers pour afficher l'image correctement)

      • [^] # Re: encore des compléments et des compliments

        Posté par  (Mastodon) . Évalué à 2.

        J'avancerais une suggestion : nettoyage des métadonnées. On peut des fois peut gagner plusieurs kb en retirant des tas de trucs inintéressants dans les commentaires emboutis, dans les IPTC ou autres XMP.

        J'avancerais une suggestion : se relire. On peut des fois peut gagner plusieurs caractères ;-)

        Surtout, ne pas tout prendre au sérieux !

      • [^] # Re: encore des compléments et des compliments

        Posté par  (site web personnel) . Évalué à 6.

        J'avancerais une suggestion : nettoyage des métadonnées.

        En fait c'est déjà le cas, YOGA supprime toutes les métadonnées des fichiers. Dans les faits, il serait même plus compliqué de les conserver que de les enlever. :)

        il faudrait peut-être garder quand même dans ce cas les données exif sur l'orientation de l'image, puisque tu t'en sers pour afficher l'image correctement

        En fait, même celle-là est supprimée : lorsque YOGA rencontre cette métadonnée en entrée, il applique directement la transformation, comme ça l'image reste droite, malgré la suppression des métadonnées.

  • # Leanify

    Posté par  . Évalué à 4.

    Je place un nouvel outil là : https://github.com/JayXon/Leanify

    Je m'étais fait une fonction fish pour compresser en pagaille avec mozjpeg, et puis je suis tombé sur ça, qui fait exactement ce que je cherchais, avec des fonctionnalités en plus : je garde.

    Et puis, pour ceux qui veulent, il va même chercher dans les archives, fichiers compressés, etc, pour extraire les images et les optimiser.

    Mais YOGA Image Optimizer a un (très) gros intérêt : il est graphique. Moi, la ligne de commande ça me va, mais honnêtement, je suis (comme beaucoup d'autres ici), un peu spécial.

    • [^] # Re: Leanify

      Posté par  . Évalué à 3.

      Tu parles du shell fish ?

      • [^] # Re: Leanify

        Posté par  . Évalué à 3.

        Oui, j'avais ça :

        function mozjpeg --description 'Re-encode multiple images using mozjpeg'
    printf "%s\x00" $argv | xargs --null --max-args=1 --max-procs=3 -I'{}' /home/user/Téléchargements/mozjpeg/build/jpegtran-static -copy none -outfile 'moz-{}' '{}'
end

        Attention, c'est plus trop valide entre --max-args et -I mais j'ai pas eu le temps de vérifier.

        • [^] # Re: Leanify

          Posté par  . Évalué à 2.

          Pourquoi faire de la recompression sans perte (tu utilises jpegtran) ? la plupart des jpeg que je trouve sur le web sont tellement peu optimisés qu'ils supportent très bien une recompression avec perte.

          • [^] # Re: Leanify

            Posté par  . Évalué à 3.

            Mon objectif est de recompresser sans perte les sorties d'appareils photo / smartphone. Je veux garder toutes les métadonnées, et je ne veux pas que les pixels changent.
            C'est pour de l'archivage sur mon NAS, pas pour de la diffusion Web.

            • [^] # Re: Leanify

              Posté par  . Évalué à 2.

              Pour du sans perte de pixels JPEG ne convient pas vraiment, mais ça tu le sais. Normalement avec un taux de compression entre 85 et 90 tu n'auras jamais de perte perceptible, évidemment «ça dépend». Et en compressant séparément la chrominance tu peux beaucoup baisser le poids très vite (sur le web je mets la chrominance entre 10 et 20, pour conserver une source elle est entre 30 et 40 (sur 100).

              Si c'est pour de l'archivage, jpeg-recompress est notablement efficace et les nouveaux formats JPEG sont bien meilleurs, notamment sur la recompression.

    • [^] # Re: Leanify

      Posté par  (site web personnel) . Évalué à 5.

      Mais YOGA Image Optimizer a un (très) gros intérêt : il est graphique. Moi, la ligne de commande ça me va

      Après, si tu préfères la ligne de commande ou que tu as besoin de scripter, YOGA dispose également d'une CLI complète :

      :)

  • # Bravo !

    Posté par  . Évalué à 2.

    Je n'avais pas encore pris le temps d'essayer, c'est fou le gain que tu arrive à produire. La majorité des png que j'ai son des captures d'écran faite avec firefox ou scrot. yoga gagne systématiquement et c'est régulièrement 2 à 3 fois plus petits et ça sans chercher à comprendre juste avec une commande du genre :

    yoga image input.png output.png

    Je pense que je ais lui faire scruter mon dossier de téléchargement et lui faire retravailler automatiquement tout png.

    Par contre je ne le trouve pas très rapide. Les traitement sur les png sont coûteux ou tu n'a pas encore pris le temps de regarder ce coté là ?

    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

    • [^] # Re: Bravo !

      Posté par  (site web personnel) . Évalué à 2.

      La majorité des png que j'ai son des captures d'écran

      Actuellement je travaille à ajouter une optimisation à perte pour les PNGs (réduction du nombre de couleurs) → il se peut que ça soit une option très efficace pour les captures d'écran (si on accepte de perde un peu en qualité lorsque des dégradés sont présents).

      Par contre je ne le trouve pas très rapide. Les traitement sur les png sont coûteux ou tu n'a pas encore pris le temps de regarder ce coté là ?

      Effectivement, le but premier de YOGA est de réduire au maximum le poids des images, et le coût pour y parvenir peut être élevé. Et encore pour les PNGs ça reste raisonnable, le traitement des JPEGs est bien plus lourd.

      Si tu veux en savoir plus à ce sujet, j'avais écrit un passage sur les coûts d'optimisation dans un précédent article :

      • [^] # Re: Bravo !

        Posté par  . Évalué à 2.

        Actuellement je travaille à ajouter une optimisation à perte pour les PNGs (réduction du nombre de couleurs) → il se peut que ça soit une option très efficace pour les captures d'écran (si on accepte de perde un peu en qualité lorsque des dégradés sont présents).

        En soit je n'ai pas besoin d'une grande qualité, mais pour faire un traitement automatique comme je pense le mettre en place, il faut que le résultat soit convainquant (pour du sans perte, je peux me permettre de systématiquement remplacer l'image sans crainte). Mais je n'ai pas non plus un grand besoin de réduire la place, c'est plus un truc que je compte ajouter parce que ça me coûte pas grand chose et que ça m'amuse.

        https://blog.flozz.fr/2021/06/14/optimisez-vos-images-avec-yoga-image-optimizer/#une-optimisation-mais-a-quel-prix

        Intéressant, faut que je le prenne en compte dans ma mise en place (probable que je tue la tâche si elle met plus de quelques secondes ou dizaines de secondes). Je partagerais ici probablement, ma manière de faire ça te montrera un cas d'usage de yoga (même en manuel j'utiliserais pas l'UI).

        Encore merci pour ton travail :)

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

      • [^] # Re: Bravo !

        Posté par  (site web personnel) . Évalué à 3.

        Mes captures d'écran font qq dizaines de ko en png, j'ai déjà vu un truc énorme, c'était à cause de l'image de fond d'écran.

        "La première sécurité est la liberté"

  • # Petite remarque sur l'UI

    Posté par  (site web personnel) . Évalué à 3.

    Bravo pour ton logiciel.

    Une petite critique en passant, je ne vois pas l'intérêt du sélecteur de thème GTK dans l'application.

    • [^] # Re: Petite remarque sur l'UI

      Posté par  (site web personnel) . Évalué à 1. Dernière modification le 13 septembre 2021 à 11:43.

      Si tu utilises YOGA Image Optimizer sous Linux, effectivement, cette option est très peu utile puisqu'on peut déjà choisir son thème globalement et il n'y a pas grand intérêt à avoir un thème différent pour une application spécifique.

      J'ai surtout ajouté cette option pour le portage Windows du logiciel (oui, j'ai été assez fou pour porter une application Python/GTK sur cet OS… ^^'). Sous Windows ils n'ont pas la possibilité de sélectionner globalement un thème GTK… puis comme tout est compilé et distribué statiquement, les options de thème d'une application ne seraient de toute façon pas prises en compte par une autre…

      • [^] # Re: Petite remarque sur l'UI

        Posté par  (site web personnel) . Évalué à 2.

        platform.system() te permet de détecter l'OS.

        • [^] # Re: Petite remarque sur l'UI

          Posté par  (site web personnel) . Évalué à 2.

          Oui je sais, mais je n'ai aucun intérêt à ajouter du code pour masquer une partie de l'UI dans le but de rendre une fonctionnalité inaccessible à certains système.

          Je préfère que le logiciel soit identique pour tout le monde, sinon un jour je vais avoir une issue du style « je trouve pas l'option pour mettre le thème sombre ». :)

          • [^] # Re: Petite remarque sur l'UI

            Posté par  . Évalué à 2.

            J'utilise une toute autre techno pour faire une application multiplateforme, qui s'apelle AvaloniaUI.

            Dans celle-ci, je détecte sous Windows si on a le thème Light ou Dark, et je change 'en live' si ça change durant l'usage de l'appli.

            Y'a pas moyen de le faire en Python ?

            "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

            • [^] # Re: Petite remarque sur l'UI

              Posté par  (site web personnel) . Évalué à 5.

              Pour commencer, je n'ai pas envie de rajouter encore des développements spécifiques pour cette plateforme (le portage Windows m'a déjà demandé un bon mois de travail pour contourner tous les problèmes de conception de cet OS).

              Ensuite, la sélection automatique d'un thème sombre ou clair n'est pas vraiment le problème. L'application n'a actuellement pas une apparence « native » sur cet OS, et je préfère laisser le choix à l'utilisateur du thème qui lui convient le mieux, que ce soit pour des raisons esthétiques ou d'accessibilité (sélection d'un thème à haut contraste par exemple).

              J'ai incorporé dans la version Windows un thème « Windows10 » permettant de donner une apparence plus proche d'une application native de l'OS, mais je ne l'ai pas activé par défaut dans YOGA Image Optimizer v1.1 car je ne suis pas satisfait de sa qualité (il y a quelques « bugs » visuels et je ne veux donc pas mettre ce thème par défaut sans les avoir corrigés, si un jour j'en ai le temps et la motivation).

              :)

  • # Un grand merci et un OS de plus

    Posté par  . Évalué à 6.

    Un grand merci pour ce travail et pour la mise en avant de cet outil.
    Utilisateur pour la photo de Mac OS (je n'arrive pas à remplacer Capture One par Darktable), j'ai essayé cet outil en faisant tout simplement un

    pip3 install yoga-image-optimizer
    dans un iterm, et hop, ça marche, l'outil est disponible et pleinement fonctionnel

    Il manque clairement des fonctionnalités de lien avec l'OS, mais rien de grave en tout cas.

    Un OS de plus et des féliciations largement méritées

    • [^] # Re: Un grand merci et un OS de plus

      Posté par  (site web personnel) . Évalué à 4.

      Tu veux dire que l'interface graphique en GTK fonctionne « out-of-the-box » sous MacOS ? 🤯️

      • [^] # Re: Un grand merci et un OS de plus

        Posté par  . Évalué à 5. Dernière modification le 14 septembre 2021 à 09:02.

        Oui, tout à fait.

        Comme c'est du python, à partir du moment ou une version récente de Python est installée (de mon côté, c'est Anaconda), un pip3 install va amener les dépendances avec le module python gtk, et comme j'avais déjà gtk d'installé pour d'autres raisons, ça marche tout seul.

        Une expérience de python qui est réellement portable à travers les OS.

  • # Optimisation présentations et fichiers textes

    Posté par  . Évalué à 2.

    Salut,

    un truc qui pourrait être super utile, serait de pouvoir prendre un fichier odf, le décompresser, récupérer les images et les réduire dans Yoga avant de les remplacer par celles optimisées et refaire l'archive !

    Il y a un outil de redimensionnement dans libreoffice, mais il n'est pas forcément hyper intéressant, dans le sens ou son principal intérêt est de réduire la résolution de l'image par rapport à sa taille dans la présentation ou dans le fichier texte.

    • [^] # Re: Optimisation présentations et fichiers textes

      Posté par  (site web personnel) . Évalué à 1.

      Bonjour,

      Il s'agit d'une fonctionnalité qui dépasse le scope de YOGA, je ne pense donc pas l'implémenter.

      Ceci dit, étant donné que YOGA est aussi un outil en CLI et une bibliothèque Python, il est tout à fait possible d'écrire un script ou un outil qui s’appuierait sur YOGA pour effectuer ce genre d'opération.

      Aussi, comme l'a mentionné @Glandos dans un commentaire un peu plus haut, il existe un outil nommé Leanify qui semble faire exactement ce que vous souhaitez. :)

      • [^] # Re: Optimisation présentations et fichiers textes

        Posté par  . Évalué à 3.

        Ceci dit, étant donné que YOGA est aussi un outil en CLI et une bibliothèque Python, il est tout à fait possible d'écrire un script ou un outil qui s’appuierait sur YOGA pour effectuer ce genre d'opération.

        Tout à fait juste. C'est dommage que la dépêche soit si orientée interface graphique.

        Peut être qu'illustrer les nouveautés avec des insertions de codes aurait été plus parlant !

        Avez vous pensé à faire une galerie de type matplotlib, avec des exemples de codes et les résultats. Ça pourrait être assez simple à faire et rendre une image dans le navigateur est assez simple !

        • [^] # Re: Optimisation présentations et fichiers textes

          Posté par  . Évalué à 5.

          Alors… La doc est là : https://wanadev.github.io/yoga/python/image.html#usage

          Donc

          import yoga.image
yoga.image.optimize("./input.png", "./output.png", options={
    "output_format": "orig",         # "orig"|"auto"|"jpeg"|"png"|"webp"|"webpl"
    "resize": "orig",                # "orig"|[width,height]
    "jpeg_quality": 0.84,            # 0.00-1.0
    "webp_quality": 0.90,            # 0.00-1.0
    "opacity_threshold": 254,        # 0-255
    "png_slow_optimization": False,  # True|False
})

          C'est tellement simple qu'en faire une dépêche parait pas pertinent.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Optimisation présentations et fichiers textes

            Posté par  . Évalué à 2.

            Merci, mais je l'avais trouvée !

            C'est tellement simple qu'en faire une dépêche parait pas pertinent.

            C'est tout aussi vrai pour la GUI, non ?

            Je trouve au contraire, que le fait que cela soit simple justifie que ça apparaisse dans la dépêche ! Après, c'est vous qui l'écrivez, donc c'est vous qui décidez !

            Merci pour le soft, j'essayerais de voir ce que j'arrive à faire sur un document un de ces jours !

  • # SVG ?

    Posté par  . Évalué à 4.

    Si vous êtes intéressé a intégrer le format SVG, comme Yoga est en python, il est possible d'intégrer facilement scour (il peut aussi s'appeler en ligne de commande). C'est lui qui est chargé de la sortie optimisée d'inkscape :

    https://github.com/scour-project/scour

    • [^] # Re: SVG ?

      Posté par  (site web personnel) . Évalué à 2.

      Je connais scour, ça marche vachement bien ! :D

      Mais pour YOGA je vais rester sur des formats matriciels : étant donné que YOGA peut effectuer des conversions entre les formats, ça va beaucoup compliquer les choses si on ne peux pas convertir n'importe quel format en n'importe quel autre :)

      • [^] # Re: SVG ?

        Posté par  . Évalué à 3.

        Je trouve pertinent d'inclure le SVG, vu les formats "web" que tu supportes. Avec comme limite de ne pas convertir de matriciel en SVG (mais du SVG en matriciel, oui).

        • [^] # Re: SVG ?

          Posté par  . Évalué à 3.

          Avec comme limite de ne pas convertir de matriciel en SVG (mais du SVG en matriciel, oui).

          Quand j'utilise la découpe laser, je pars souvent de PNG N&B et je dois les vectoriser. Je trouve que ce processus est assez marrant, mais pour l'instant les meilleurs outils sont ceux du web !

          Après, c'est clairement un sujet trop éloigné de Yoga.

        • [^] # Re: SVG ?

          Posté par  (site web personnel) . Évalué à 3.

          Les problèmes avec les SVG sont les suivants :

          • À la base YOGA optimise des modèles 3D…. Et des images (comme elles sont utilisées pour les textures desdits modèles). Donc le support du SVG n'est pas une priorité dans YOGA (il y a actuellement encore énormément de travail à faire sur les formats matriciels).

          • Les optimisations des SVGs proposées par scour sont très performantes, mais clairement il y a beaucoup de paramètres en fonction de ce qu'on s'autorise à perdre comme précision / les contournements pour certains cas d'usages ou bibliothèques spécifiques, etc. → Bref, il faut une GUI très complète (comme celle que propose Inkscape) pour vraiment tirer parti de tout le potentiel de scour, là où YOGA veut rester relativement simple (pas plus d'une ou 2 options par format).

          • Comme je l'ai dit, yoga image permet de convertir d'un format vers n'importe quel autre, et je n'ai pas vraiment envie de complexifier ceci en rajoutant des restrictions. :)

          Au final:

          • scour propose déjà une CLI et une API Python tout à fait complète : donc peu d'intérêt de réintégrer la même chose dans YOGA lui-même (je parle ici de la lib dernière YOGA Image Optimizer).

          • La seule chose qu'il manque peut-être, c'est une bonne GUI pour scour dans laquelle on pourrait optimiser en masse des SVG. Il serait peut-être intéressant de s'y pencher en tant que projet à part entière. :)

          PS: désolé pour le temps de réponse, j'avais raté le message ^^'

          • [^] # Re: SVG ?

            Posté par  . Évalué à 2.

            désolé pour le temps de réponse, j'avais raté le message

            c'est vraiment pas grave, je t'absous :-)

  • # OxiPNG ? MozJPEG vanille?

    Posté par  . Évalué à 3.

    Bonjour, avez-vous regardé pour l'utilisation de OxiPNG? C'est ce que Squoosh utilise pour les PNGs avec ou sans pertes, et comme c'est la seule option là-bas, j'ai comme l'impression que la question a déjà été étudiée par les auteurs de Squoosh et OxiPNG déterminé le grand vainqueur. Cet article aussi semblait dire que ça écrasait, au moins, pngcrush. Mais j'émets cette supposition sans m'y connaître dans les codecs d'images, tout comme j'aurais cru que "juste MozJPEG" aurait été l'optimum pour l'encodage JPEG traditionnel (je n'ai pas vraiment trouvé de comparaisons récentes, seulement un banc d'essai de 2017 qui trouvait que Guetzli était plusieurs centaines de fois plus lent que MozJPEG pour le même résultat), d'ici à ce qu'on puisse utiliser JPEG XL sur le web…

    • [^] # Re: OxiPNG ? MozJPEG vanille?

      Posté par  . Évalué à 3.

      Par curiosité, je viens de faire le test, avec une image JPEG 900x725 156 kB, et l'article de 2017 semble possiblement encore d'actualité: Yoga utilisant Guetzli en qualité 90% (par défaut) prend environ une minute et demie à encoder l'image en JPEG optimisé à 108 kB, alors que Squoosh avec MozJPEG à qualité 75 (par défaut) sort une image de 77 kB en une fraction de seconde (trop rapide pour que je puisse chronométrer), ou une image très peu optimisée (152 kB) si on lui spécifie "qualité 90" (mais bon, les paramètres de qualité d'un encodeur à l'autre sont difficilement comparables; dans tous les cas j'ai du mal à percevoir une différence visuelle dans les résultats).

      Je suppose que Guetzli+MozJPEG donne le résultat optimal absolu (?) au coût des ressources pour l'encoder. C'est peut-être souhaitable en théorie, mais je me pose la question… faire chauffer les CPUs pendant plusieurs minutes pour chaque image (au lieu d'une fraction de seconde) me semble tout de même un coût assez prohibitif à mes yeux, surtout quand on voit venir JPEG XL qui encode aussi rapidement que l'ancien libJPEG-turbo ;)

Suivre le flux des commentaires

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