FLOZz a écrit 112 commentaires

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.

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

J'ai terminé cette après-midi d'implémenter le redimensionnement des images. C'est dispo sur la branche master et ça sortira dans la prochaine version :)

Si vous voulez un petit aperçu, c'est par là :

• https://mastodon.social/@FLOZz/106579177662484265

Ah oui j'avais pas fait gaffe au -m… mais ça ne change rien dans le cas présent…

Je viens de tester, et même sans le -m ZopfliPNG me sort une image plus petite…

-rw-rw-r--  1 fabien fabien   7907 juil. 13 10:40 avatar.png
-rw-rw-r--  1 fabien fabien   7728 juil. 13 10:41 avatar.yoga.png
-rw-rw-r--  1 fabien fabien   7728 juil. 13 10:41 avatar.yoga-slow.png
-rw-rw-r--  1 fabien fabien   7550 juil. 13 10:45 avatar.zopfli.png

Je considère donc ça comme un bug et je vais creuser pour trouver pourquoi ça fait ça. Merci beaucoup pour le retour du coup ! :)

Archivage d'images

Yoga est plutôt prévu pour l'optimisation d'images destinées à être publiées sur le web ou utilisées comme textures dans des modèles 3D.

Je ne pense pas que YOGA soit une bonne solution pour l'archivage : même si on s'efforce de ne pas dégrader la photo de manière perceptible, le JPEG est bel et bien réencodé et donc de pertes sont inévitables.

S'il on veut rester sur du JPEG, le mieux pour l'archivage serait d'utiliser l'utilitaire jpegtran (de préférence la version patchée par MozJPEG), qui va permettre d'optimiser l'image sans perte de qualité supplémentaire (mais forcément la réduction du poids de l'image sera moins spectaculaire).

Sinon, comme l'a indiqué @orfenor, il y a le format JpegXL qui semble prometteur et qui peut réencoder sans perte supplémentaire une image précédemment encodée au format JPEG (si j'ai bien lu la description du format).

Métadonnées

YOGA ne conserve actuellement pas les métadonnées des images.

J'ai ouvert un ticket à ce sujet comme ça m'a été demandé à plusieurs reprises, mais conserver les métadonnées pose plusieurs problèmes, notamment lors de la conversion d'une image entre les différents formats supportés…

En bref ça demande beaucoup de travail, et la conservation des métadonnées ne fait pas partie des besoin des principaux cas d'usage que YOGA essaye de couvrir :)

Bah c'est pas grave, grâce à toi on a gagné des explications super intéressantes de @Jehan. C'est toujours positif de discuter :)

Merci pour cette explication très claire et complète ! :D

Seul les dimensions en pixel de l'image sont systématiquement disponibles dans les fichiers.

Les autres informations peuvent éventuellement, parfois être présente sous forme de métadonnées dans certains formats de fichiers comme le JPEG, mais c'est pas du tout obligatoire (et bien souvent les informations stockées sont des valeurs par défaut exportées par un logiciel et pas forcément les bonnes).

Et pour certains formats comme le PNG cette information n'est pas présente et ne fait pas du tout partie de la norme.

c'est pour ça qu'il faudrait une saisie manuelle de l'utilisateur si on voulait faire ça :)

Ok je vois. Le souci avec cette méthode, c'est qu'avant de renseigner le nombre de DPI souhaiter, il faut

• soit indiquer à YOGA les dimensions de l'image en cm (ou en pouce en fonction des pays)
• soit lui indiquer la définition d'origine

Ça me parait être assez peu pratique au final, et étant donné que l'objectif de YOGA est surtout d'optimiser pour le web, donner des dimensions en pixels me semble plus approprié.

Généralement quand on commence à vouloir parler en unités physiques (cm / pouce) c'est qu'on veut faire du print et YOGA perd de son intérêt sur ce terrain-là (pas vraiment besoin d'optimiser une image que l'on veut imprimer).

En tout cas merci pour les explications plus précises :)

lorsqu'on ajoute une longue liste d'images, et qu'on veut leur appliquer les mêmes réglages (par exemple du PNG vers WEBP 75%), faut se taper toutes les lignes une par une. C'est dommage qu'on ne puisse pas sélectionner plusieurs lignes et appliquer les mêmes réglages pour ces images sélectionnées, ça serait plus pratique pour du traitement en masse (ou alors il y a un autre moyen que je n'ai pas trouvé)

Ça y est, je viens tout juste d'implémenter la multisélection sur master :D

Vidéo de démo par là : https://mastodon.social/web/statuses/106550416876265712

Changer les DPI ça revient à changer les dimensions de l'image (en pixel) au final non ? Je ne vois pas trop la différence avec un redimensionnement du coup… Est-ce que tu peux m'expliquer quel est le besoin exact ? :)

(meilleur que yoga en général)

C'est étrange, par ce que YOGA utilise ZopfliPNG pour optimiser les PNGs donc les résultats devraient être assez similaires… :(

Tu pourrais me passer une image où cela se produit pour que je puisse reproduire et essayer de corriger ça ?

Pour mozjpeg, j'ai compilé la dernière version disponible sur leur dépôt (https://github.com/mozilla/mozjpeg) et, étant donné que c'est un fork de libjpeg-turbo, ça fournit les mêmes outils.

Du coup j'ai utilisé le jpegtran compilé pour améliorer l'optimisation de mes images de test après les avoir compressées avec Guetzli (l'avantage étant qu'il s'agit ici d'une transformation sans perte de qualité supplémentaire).

J'ai essayé Guetzli en CLI, c'était affreusement lent, beaucoup plus que Yoga. Il y a un truc pour l'accélérer ?

Ça m'étonne beaucoup que ça soit plus lent que YOGA étant donné que j'utilise directement Guetzli comme bibliothèque derrière (via le binding Python PyGuetzli).

J'ai déjà fait quelques testes avec libjpegturbo et mozjpeg, clairement mozjpeg est plus intéressant : il me permet de gratter entre 2% et 7% supplémentaires sur l'encodage fait par Gueutzli (avec les options -optimize et -progressive qui sont sans perte) :)

L'option de redimensionnement existe déjà dans YOGA mais n'est pour le moment accessible qu'en ligne de commande. Je vais rajouter cette option dans la prochaine version de l'interface graphique, je me suis juste concentré sur l'essentiel pour la v1.0 :)

Salut,

Au vu de ce que ces deux logiciels intègrent comme bibliothèques, je pense qu'ils peuvent fournir le même taux de compression que YOGA pour les JPEG et pour les PNG (à condition de rester sur de l'encodage sans perte pour ce dernier).

Globalement les outils comme ImageOptim s'appuient à peu près tous sur les mêmes bibliothèques, et les petites différences qu'il peut y avoir viennent surtout des réglages utilisés sur chacun des encodeurs…

---

D'ailleurs je profite de ce commentaire pour apporter quelques news sur YOGA… :)

Pour les JPEGs,

• YOGA tient maintenant compte de l'orientation de l'image (pour ne plus la sortir de travers)

• et je suis en train de regarder pour améliorer encore un peu la compression (en utilisant Guetzli puis en faisant un encodage progressif du résultat).

Pour les PNG

• j'ai déjà apporté une petite amélioration récemment (dans certains cas rares YOGA pouvait générer des images peu plus grosses en sortie qu'en entrée, mais ce n'est plus possible, et il fera maintenant quasi systématiquement mieux d'au moins quelques octets ou au pire l'image fera le même poids)

• et je regarde aussi la possibilité de rajouter une option de compression PNG à perte (en utilisant pngquant pour réduire le nombre de couleurs puis en filtrant le résultat avec ZopfliPNG puis en compressant avec Zopfli).

J'ai des trucs à regarder du côté du WebP aussi mais pas sûr que j'ai le temps de m'en occuper pour la prochaine version :)

Ça fait des années que je « traîne » ici en « lecture seule » et depuis quelque temps j'ai activé le mode « lecture écriture » (j'ai enfin créé un compte quoi :p).

Merci à tout ceux qui lisent, à ceux qui commentent, à ceux écrivent des dépêches ou des journaux, aux modérateurs et autres administrateurs… Bref à tout ceux qui permettent à ce site d'exister :)

Pour ce qui est de la conservation des métadonnées, on me l'a déjà demandé sur Mastodon, j'ai donc ouvert une issue sur le sujet. Mais c'est clairement pas la priorité et c'est beaucoup moins simple qu'il n'y parait. :)

Et pour le redimensionnement des images, l'option existe en ligne de commande mais elle n'a pas encore été implémentée dans l'interface graphique. Je compte bien l'ajouter à terme. ;)

Je pense que le problème doit être réglé dans la version actuelle du paquet (je n'ai par contre pas encore eu le temps de tester car il fait trop chaud pour que j'allume mon PC ce weekend, mais je regarderais ça lundi)

Merci pour vos retours !

Étant donné qu'il s'agit de la toute première version, il y a effectivement certaines limitations (volontaires) dans les fonctionnalités afin de se concentrer sur le principal et être en mesure de sortir quelque chose de minimal mais de fonctionnel. Je compte bien travailler à améliorer pas mal des points évoqués par la suite.

le thème ne s'intègre pas avec le thème de l'OS (couleur de la fenêtre, icônes de gestion de la fenêtre…), ce n'est pas problématique, mais ça peut faire un peu bizarre sur certains environnements. Par exemple mon gestionnaire de fenêtre est réglé pour mettre les icônes en haut à gauche, du coup j'ai dans l'ordre : "croix" pour fermer la fenêtre, "moins" pour la réduire, "plus" pour l'agrandir, "plus" pour ajouter une image dans la liste, "moins" pour enlever une image de la liste. Ca me semblerait plus logique de mettre les boutons de gestion des images ("plus", "moins", "corbeille", "optimize" et "reglages") dans une barre d'outils sous la barre de titre de la fenêtre, quitte à perdre 20 ou 30 pixels en hauteur.

Pour ce qui est d'ajuster le thème de l'application (couleurs / icônes) :

• Sous Linux, le thème GTK par défaut est utilisé (mais il reste possible d'en forcer un autre via la configuration de GTK ou via une variable d’environnement).

• Sous Windows j'ai ajouté un thème qui s'intègre mieux à la plateforme (même si ce n'est pas parfait).

Quoi qu'il en soit, je pense rendre le thème GTK configurable via les options de l'application, mais ce n'est pas la priorité.

Pour les boutons de la fenêtre / la possibilité d'utiliser la barre de titre du gestionnaire de fenêtre plutôt que les décorations côté client, je verrais ce que je peux faire à ce sujet ultérieurement. C'est typiquement le genre d'options qui sont compliquées à maintenir sur le long terme (des cas supplémentaires à tester et donc des sources de bugs).

lorsqu'on ajoute une longue liste d'images, et qu'on veut leur appliquer les mêmes réglages (par exemple du PNG vers WEBP 75%), faut se taper toutes les lignes une par une. C'est dommage qu'on ne puisse pas sélectionner plusieurs lignes et appliquer les mêmes réglages pour ces images sélectionnées, ça serait plus pratique pour du traitement en masse (ou alors il y a un autre moyen que je n'ai pas trouvé)

Il s'agit d'un fonctionnalité qu'il me parait impensable de ne pas ajouter à terme.

Je me suis limité volontairement à une sélection unique pour ne pas compliquer cette première version avec une multi-sélection qui aurait été implémenté trop rapidement. Il faut encore que je réfléchisse à la meilleur manière de le faire d'un point de vue ergonomique. Mais je vais y travailler. :)

Ajouter une option "Ecraser le fichier d'origine" pour ne pas avoir à renommer les fichiers optimisés (au risque et péril de l'utilisateur). Le fait que le logiciel ajoute automatiquement ".opti" avec l'extension n'est pas toujours pratique, par exemple si un script repasse derrière pour renommer les fichiers, c'est moins facile à détecter que s'il préfixe le nom. Donc donner la possibilité de mettre autre chose que "opti" et son emplacement serait sympa.

Là encore il s'agit d'un point sur lequel j'ai fait l'impasse pour cette première version. Je réfléchis à plusieurs options pour la suite :

• Pouvoir définir un pattern de nom pour les fichiers de sortir,
• Stocker les images de sortie sous le même nom dans un sous dossier,
• Écraser le fichier d'entrée,
• …
• Écrire les fichiers de sortie dans un dossier temporaire et ouvrir l'explorateur de fichier dans ce dossier m'a également été suggéré…

Il faut encore que je réfléchisse quelles options je souhaite proposer et sous quelles formes :)

---

Il me reste pas mal de choses à explorer aussi bien au niveau de l'interface graphique que de la bibliothèque/CLI, et les améliorations arriverons au fil des versions. Le plus important pour moi était déjà d'être en mesure de sortir cette toute première version qui me servira de base pour les évolutions futures. :)

Lepton a l'air d'être très intéressant pour faire de l'archivage d'images JPEG, mais je ne pense pas qu'il soit pertinent de l'intégrer à YOGA : le but premier de YOGA est d'optimiser les images pour le Web, et Lepton n'est pas une technologie supportée par les navigateurs. :)

Dans notre cas on utilise ces modèles 3D pour des applications WebGL, ce qui nous donne des contraintes spécifiques :

• utiliser les formats d'images supportés par les navigateurs permet de garantir une compatibilité la plus large possible sur toutes les plateformes,

• le formats d'image comme le JPEG et surtout le WebP sont plus performants en terme de compression, et étant donné qu'il s'agit d'application web, les temps de transfère via le réseau sont à prendre en compte,

• suivant les projets on peut avoir des besoins spécifiques liés à la chaîne de production.

Dans tous les cas, on garde ça sous le coude et peut être que sur un projet il sera plus pertinent d'utiliser ces formats là :)

Quand t'as un problème avec un paquet spécifique à une distribution, il vaut généralement mieux le remonter au maintainer, qui le fera remonter "upstream" si nécessaire.

Dans le cas du paquet AUR de YOGA, le problème est connu et on est en train de travailler dessus avec le maintainer : https://github.com/wanadev/yoga/issues/35

:)

Je me demande ce que fait imageOptim pour réduire autant le PNG (je sais qu'il est possible de réduire très légèrement les couleurs pour améliorer la compression sans que ça ne soit perceptible, peut être qu'il joue là dessus ?)

Pour ce qui est de Guetzli, il est à noter qu'il ne faut normalement pas descendre en dessous de 84% (la version originale de la bibliothèque bloque d'ailleurs toute valeur inférieure).

En tout cas j'ai encore des pistes à explorer pour améliorer toujours plus l'optimisation :D

Guetzli sort uniquement des JPEG baseline et effectivement, utiliser un encodage progressif (comme le fait MozJPEG) permettrait de gratter encore quelques pourcents. C'est une suggestion qui m'a été faite sur Reddit et je compte bien creuser le sujet !

Pour ce qui est des PNG, tout comme toi, j'utilisais optipng avant… Mais il n'y a clairement pas photo, Zopfli fait mieux ! :)