@Paille Hello !
Je suis très intéressé et curieux de tester YOGA.

L'install via PyPi à merdé sur ma Debian old-stable, je vais tester ce soir sur une station avec une Debian plus récente, si j'ai encore un soucis je te dirai.

Et si non, est ce que tu connais, est ce que tu as comparé les performances avec le script Trimage ? (seul la perf de compression m'intéresse, le temps de traitement est accessoire pour moi)
pip install trimage ça devrait marcher si tu ne l'a pas encore testé.

Merci !

@Brunus @Paille Le temps de compression des jpeg est effectivement très lent (sur mon core i7 qui a 10 ans), mais c'est efficace. Sur les png c'est très rapide et c'est la solution la plus efficace que j'ai trouvé. Je ne connaissais pas trimage, je vais tester aussi. Pas testé WebP et je sais pas si il y a les avif, je testerais dans ce cas plutôt ça, même si il faudra du temps avant d'avoir une bonne proportions d'utilisateurs d'Android pouvant le lire.
@Brunus @Paille j'ai essayé sur 2 ou 3 images et ai trouvé un cas ou yoga recompressait mieux du png que trimage (et en plus rapide). trimage est plus long sur les png, mais semble rapide sur les jpeg j'ai l'impression, j'essairais de faire des tests plus poussés.
@Brunus @Paille C'est pour quelle version de debian, pour voir si je peux faire un paquet basique simplement. Est-ce qu'il y a python 3 dessus ?

@popolon @Paille Non mais attends, je vais d'abord tester avant de te faire faire un paquet ...
Trimage c'est vieux, c'est un ensemble de libs et binaire : optipng, pngcrush, jhead etc.
YOGA utilise des libs plus modernes, je ne doute pas trop qu'il soit plus performant autant en compression qu'en temps d'exécution.
Après les réglages de Trimages sur les PNGs peuvent êtres excellents, mais le temps de travail monstrueux (les options passées à pngcrush plus précisément)

@popolon @Paille La je viens de tester sur une Debian Stable (Buster), et même erreur de PiPy que sur la Old-Stable (Stretch) : error: [Errno 2] No such file or directory: 'cmake': 'cmake'

Désolé j'ai plus de compte Github pour poster l'issue :/

@Brunus @Paille ah dépendance, il suffit d'installer cmake à priori non ? Je peux tester ça sur une vm deban bulleye en archi risc-v ^^.
@Brunus @Paille trinage a été plus efficace sur un jpg repassage derrière yoda :). Je pense que ça vaut le coup de passer aux 2 l'un après l'autre.

@popolon @Paille C'est pas un peu overkill ? 😂
Mais je notes ! Merci !
Comme je peux pas encore tester YODA, est ce qu'il y a une option pour traiter tout un répertoire, genre le -d de trimage, ou faut faire un script bash avec du for i in *.jpg; do ...
Trimage permet de traiter toutes les PNG et les JPEGS d'un répertoire.

@Brunus @Paille via l'interface c'est possible avec yoga, pas vu en ligne de commande. C'est pas le manque du paquet cmake tout simplement pour le problème ? Il n'est pas dans le build-essential bizarrement. Ça met 3 plombes pour compiler sur mon risc-v émulé, mais ça a l'air de rouler pour le moment.

@popolon @Paille je check demain le prob de cmake ... j'ai un gamin mort de rire à coucher... ça ma me prendre plus de temps que de stabiliser mon env de compile ! 😂

@Brunus @Paille J'en suis à ça dans la compilation depuis au moins 1h sur le Bullseye RISC-V64 émulé. J'aurais du mettre 2 proc: Building wheels for collected packages: yoga, pillow, pyguetzli, zopflipy Building wheel for yoga (PEP 517) ... /

@Brunus Moi aussi suis intéressé et curieux de tester YOGA. Mais je l'ai juste mis sur mon shaarli (et partagé)... Pas encore eu le temps..

@Paille @popolon
Sur Debian il manque cmake dans les paquets à installer avant de tenter la compilation de YOGA avec PiPy.
Sur Debian Stretch ça se termine mal, par un

fatal error: assimp/config.h: Aucun fichier ou dossier de ce type

Sur Debian Buster ça se termine bien et je peux enfin tester ! \o/

@popolon @Paille ok ! Je vais tester ça merci !
Mais en attendant j'ai pu tester sur Buster.
C'est hyper long le temps de traitement sur le jpeg ! 😭
Par contre les résultats sont impressionnants ! J'ai lancé un test sans mettre de niveau de compression : source 831.1 ko - dest 86.7 ko ! 🤪
Je suppose qu'il y a un niveau de compression par défaut mais je ne sais pas combien, va falloir que je cherche.

@popolon @Paille Alors si on ne passe pas de paramètre de compression YOGA fait par défaut une compression jpeg 95% et... ça se passe bien.

#>identify -format '%Q' tonimage.jpg
...pour avoir l'info

Mais si tu forces la compression avec --jpeg-quality=95 , YOGA part en vrille et je kill le process après qu'il ait passé 3 fois plus de temps à tourner que lorsqu'on passe pas le paramètre !
Ya un problème ! 😎

De plus je suis tombé sur cette page : github.com/wanadev/yoga/

Je test cette version.

@brunus @Paille Ahah :), j'ai tendance à compresser en 80 à 82% en jpeg, il y a encore de quoi gagner alors. Merci pour cette info, je vais regarder/tester ça.

@popolon @Paille En fait les deux dépôts Github sont liés : un contient yoga en ligne de commande, l'autre la GUI. Celui que j'ai installé avec PiPy fait tomber la version CLI.
Bon donc en fait vu que c'est bugué et que c'est juste un script qui appelle Guetzli, Zopflipng, libwebp ... je vais m'y intéresser à nouveau (j'avais un peu laissé de coté ces libs, pour utiliser celles compilés par Trimage)

@brunus @Paille Oui, j'ai vu ça en faisant les paquets arch. Je ne connaissais pas ces outils, j'utilisais optipng et pngquant. Ils gagnent pas mal par rapport à ça. J'ai de la chance visiblement d'avoir obtenu un outil qui fonctionne, mais qu'avec l'utilisateur principal, je ne sais pas pourquoi. J'ai recompilé avec un utilisateur secondaire, me disant que le processus installait d'autres choses à côté, mais ça marche pas non plus ^^. Comme je suis une quiche sur tout ce qui concerne python, je ne sais pas d'où ça vient. Le développeur de Yoga m'a dit qu'il se penchera de nouveau dessus ce w.e. Ça m'interesse de le compiler sur un serveur (ubuntu) en plus pour tester des automatisations de compression. Je me dis que ça vaut toujours le coup de perdre un peu de cpu une fois, pour économiser du HDD/bande passante/cpu à décoder chez les utilisateurs pendant potentiellement des années.

@popolon @Paille
Je suis débutant en Python mais j'ai codé ce genre de script qui appellent des libs. Première chose que je vais faire c'est justement un script Python qui va appeler Guetzli, pour voir les perfs, reproduire celle de yoga et voir si ça part en vrille en passant la compression en paramètre. Pour moi c'est vraiment un bug étrange et tellement idiot ça !

@popolon @Paille

Je laisse tomber, c'est inutilisable la lib Guetzli (appelée par YOGA)
J'ai fait script Python de moins de 10 lignes, qui ouvre une image, l'optimise avec Guetzli et la sauvegarde.
Essai 1 : "ValueError, this is not a jpeg or is corrupted."
C'est un jpeg ! Y'a juste que l'entête a été nettoyé ! 😜

Essai 2 pour faire un jpg 95% de qualité :
- Guetzli 5 min : 557.8 ko
- Image Magick 1 s : 507.0 ko
- Trimage 3 s : 439.4 ko (en lui passant l'image IM)

Je vais tester le PNG.

@brunus @Paille Et la même image sans forcée la qualité à la valeur trop élevée de 95% par curiosité ? Si il y a une comparaison de la qualité du résultat dans l'optimisation (d'où le temps de calcul), cela peut être intéressant. Personnellement, j'utilise les optimiseurs pour du web.

Mettre 95% me paraît pas du tout pertinent pour ça. Peut être pour une image de texture dans un jeu, qui sera zoomé, mais png ou avif/av1 serait sans doute plus pertinent puisque dans le développement on peut maîtriser les outils de lecture. Après effectivement, j'ai eu un jpeg plus gros dans mes quelques tests, par contre pour les png, ça reste le mieux que j'ai trouvé.

Le format webp est maintenant beaucoup utilisé (le format av1 pose encore des problèmes avec les téléphones d'il y a 5 ans). Ça peut être intéressant aussi de comparé. Je m'était amusé sur mon blog à mettre du webm d'une image il y a quelques années. Firefox supportait les vidéos webm, mais refusait de supporter celui des images webp à cette époque où il avait encore des grosses part de marché. On gagnait beaucoup en taille sans perdre en qualité. Comme c'était un SVG, j'ai finalement mis du SVGz qui restait plus efficace.

Ce refus du webp, c'est comme le refus du standard mng (png animé) qui aurait pu remplacer efficacement le GIF (16m de couleurs en plus, canal alpha 8 bits, déplacement d'éléments dans l'image et compression PNG bien meilleure que GIF,etc),il y a une quinzaine d'année. Ça a été refusé pour d'assez mauvaises raisons à mon sens, c'était pourtant un beau standard. D'abord au prétexte que le lecteur était trop gros (plus de 5k, les auteurs l'ont optimisé en dessous de cette taille, ça a été refusé tout de même, plus tard Firefox à sorti ANG, qui était beaucoup plus limité qui n'aura pas été utilisé vu le peu d'avantage apporté (série de png compressées indépendament, comme MJPEG.

J'attends les retours avec curiosité :).

@popolon @Paille

Perso j'utilise JPEG pour la photo, PNG pour les dessins, illustrations etc.
J'ai voulu tester le 95% pour être dans les mêmes condition que les test de l'auteur de YOGA.
Mais ça m'arrive de choisir une compression plus forte.
Le webp, j'attends encore un peu pour l'utiliser.

J'ai testé Zopfli et c'est peut être intéressant ! (je fais encore quelques tests avant de poster les résultats)
Il faut cloner le dépot et make :
github.com/google/zopfli

@brunus @Paille Sur webp, je crois aussi que ça dépend des images, dans certains cas, c'est plus dégradé que jpeg, mais ça se joue à pas grand chose visuellement à mon sens et en général la compression est meilleure. AV1F gagne par contre énormément sur tous les plans, ça peut diviser par 2 la taille à qualité égale, est c'est un standard supporté par tous les navigateurs, mais pas pas les vieux mobiles avec leurs navigateurs de base. J'ai vu que ça posait aussi des problèmes avec Telegram par exemple sur mobile (pas sur desktop) qui doit se baser exclusivement sur les biblio du système pour les images et vidéos.

@popolon @Paille

Résultats à peu près identiques pour de l'optimisation de PNG en couleurs indéxées.

Je vais peut être adopter Zopfli pour optimiser les PNGs.

Pour Webp je ne sais pas, je ne suis pas assez documenté sur ce format, va falloir que je corrige ça ! 😅

@brunus @Paille Effectivement c'est pas un gain énorme sur les gros png, je ne sais pas ce que contiennent ces png non plus, PNG est fatalement moins efficace/pertinent pour des photos que pour des captures d'écran ou plus généralement des images géométriques avec des grands aplats.

@popolon @Paille Sur Stretch c'est mort de toutes façons ! Je n'avais pas vu la sortie : CMake 3.10 or higher is required. You are running version 3.7.2

Inscrivez-vous pour prendre part à la conversation
Framapiaf

Le réseau social de l'avenir : Pas d'annonces, pas de surveillance institutionnelle, conception éthique et décentralisation ! Possédez vos données avec Mastodon !