Je ne sais pas trop quoi penser de la méthodologie consistant à comparer le poids par exemple de fichiers JPEG 95% avec ceux de fichiers WebP 95% : qui dit que ces paramètres sont comparables au delà du nombre indiqué comme réglage pour différents encodeurs ?
Ou de partir d'un format particulier (utilisé pour les iPhone) pour réaliser ensuite des conversions en d'autres formats : qui dit que ces résultats sont extrapolables à partir d'autres formats ?
Et comme d'habitude, alors qu'il s'agit de trouver mieux que le JPEG, il n'est pas indiqué quel encodeur JPEG est utilisé (un optimisé ou non), rendant impossible de juger de la réalité des écarts avancés.
J'utilise tout le temps Mozjpeg. Avec des options "bien choisies", le poids des images descend au niveau d'une compression WebP. Kornelski, le mainteneur de Mozjpeg, a fait un utilitaire bien utile pour ceux qui ne veulent pas mettre la main dans le cambouis : ImageOptim qui existe en version online et en version Mac, livre directement l'image optimisée.
Avec un petit script Perl, on arrive à faire mieux qu'ImageOptim, en conservant la simplicité d'usage, mais au prix d'une appréciation "manuelle" de la qualité (avec l'habitude ça va vite).
Et à propos de la qualité, il faudrait que "les gens" remettent un peu les pieds sur terre : dans la plupart des pages web que je vois, on passe rapidement sur les images, rares sont celles qu'on regarde. De toute façon, les 3/4 des visiteurs sont sur mobile et consultent donc les pages dans de mauvaises conditions de lumière, et avec des reflets. Quant à ceux qui surfent sur grand écran, lequel a fait un calibrage ? Bref, rappelez vous les années modems, quand les images étaient petites et allégées au max. Une bonne pratique c'est d'alléger au max les premières images de la page, celles qui soutiennent le texte pour donner une vue d'ensemble. Et d'en mettre des belles, si besoin, un peu plus bas, pour ceux qui veulent des détail et s'intéressent au sujet. Ma copine le fait depuis 2 ans (elle vend des jouets), sa clientèle est ravie d'aller vite.
En faveur de JPEG, il ne faut pas oublier la relative rapidité de décompression sur nos CPUs.
Bon, c'est bien ça m'oblige à regarder les coulisses des outils que j'utilise.
En général je resize avec le plugin GIMP Save for Web (qui n’accepte pas cependant les trop grosses résolutions en entrée) puis je fais une optimisation lossless avec jpegoptim, mais je ne sais pas du tout sur quoi se base ledit plugin Save for Web ni ce qu'il vaut par rapport à Mozjpeg ?
Posté par orfenor .
Évalué à 3.
Dernière modification le 18 février 2023 à 15:44.
Oui j'avais proposé à Jehan de le payer pour une interface à Mozjpeg. Mais on avait peu de moyens. De fil en aiguille il a proposé à Kornelski des modifications, pour intégrer Mozjpeg à Gimp, mais ça stagne.
Save for the web fait du bon boulot à partir de la libjpeg. Mais ne peut pas faire plus que ce que la lib propose. Tandis que Mozjpeg est basé libjpegturbo, qui dispose d'options avancées — et en ajoute qq autres bien sûr.
Pour utiliser Libjpegturbo/Mozjpeg je prépare une image de la plus haute qualité possible, parce que JPEG est mauvais sur la recompression. Ensuite je passe les paramètres à cjpeg (l'utilitaire de compression JPEG standard). J'utilise le cjpeg de Mozjpeg si je l'ai compilé, sinon celui de libjpegturbo.
Voilà les paramètres de libjpegturbo
progressive: progressive jpeg (default)
optimize: libturbo optimizations (default)
smooth: smoothness to reduce jpeg artifacts
sample 1x1: allow to separate Luminance & Chrominance quality
quality: Luminance and Chrominance quality (JPEG compression)
5 Table from paper by Klein, Silversteien and Carney
6 Table from paper by Watson, Taylor and Borthwick
7 Table from paper by Ahumada, Watson, Peterson
8 Table from paper by Peterson, Ahumada and Watson
dc-scan-opt: DC scan optimization mode (default is 1)
notrellis Disable trellis optimization
trellis-dc Enable trellis optimization of DC coefficients (default)
notrellis-dc Disable trellis optimization of DC coefficients
tune-psnr Tune trellis optimization for PSNR
tune-hvs-psnr Tune trellis optimization for PSNR-HVS (default) mesure la distorsion de l'image
tune-ssim Tune trellis optimization for SSIM
tune-ms-ssim Tune trellis optimization for MS-SSIM
… et d'autres pour les "sorciers"
Et voici comment faire
Le paramètre qui a le plus d'effet est dans libjpegturbo, c'est la compression différente pour la Luminance et la Chrominance. On va vulgariser un peu et les appeler lumière et couleur (c'est moins long à taper). Pour la lumière on met le paramètre de compression JPEG habituel, pour la couleur on met 1/4 ou 1/3 en général. Attention c'est lumière d'abord, couleur ensuite.
Pour jouer sur les qualités de lumière et de couleur il faut impérativement le paramètre sample 1x1.
Le lissage (paramètre smooth) alourdit l'image et créé un peu de flou, auquel mon oeil est très sensible. L'utilisation des tables de quantisation permet de s'en passer avec Mozjpeg.
Les tables de quantisation, c'est le deuxième paramètre qui a beaucoup d'effet. Pour le web, c'est le plus souvent la table 3 qui fait gagner le plus de poids, ensuite ce sont les tables 2 et 5. Les tables 7 et 8 permettent d'archiver avec une excellente qualité (je ne retrouve pas la discussion dans les bugs et PR de mozjpeg, mais c'est dedans) ; il m'arrive de m'en servir pour améliorer le rendu d'une image bien compressée, le poids supplémentaire est alors acceptable.
La CLI de base est donc cjpeg -sample 1x1 -quality 65,21
ça marche avec libjpegturbo (on peut ajouter -smooth [un nombre] pour corriger les artefacts de compression JPEG.
Et si on compile Mozjpeg, la CLI de base est cjpeg -sample 1x1 -quality 65,21 -smooth 0 -quant-table 3
… à laquelle je rajoute souvent -dc-scan-opt 2
Les autres paramètres servant (si j'ai bien compris) pour faire des comparaisons automatiques de qualité d'image.
Mozjpeg utilisable dans Gimp c'est assez simple : il faut rendre Mozjpeg installable en parallèle de libjpeg (ou libjpegturbo). C'est un patch de Jehan qu'il faut revoir.
Mais pour avoir une interface graphique avec les options qui vont bien c'est autre chose. Jehan me l'a bien expliqué. Y'a du boulot et on voulait le payer pour ça. J'ai fait une interface en CLI qui masque la difficulté et nous permet (ma copine et moi) de l'utiliser en rafale sur un grand nombre d'images.
Effectivement ça vaudrait le coup de lancer un co-financement. Il suffit d'essayer Mozjpeg via ImageOptim online pour se rendre compte des bons résultats. Cela dit il y a des images pour lesquelles on ne fait pas aussi bien que WebP. L'image utilisée dans l'article en est un bon exemple.
Posté par orfenor .
Évalué à 2.
Dernière modification le 19 février 2023 à 14:14.
Non, tu n'as pas compris. Faut lire la discussion et les critiques sous la PR et les bugs en rapport : il y a des trucs à revoir, du code à faire. Les changement dans Mozjpeg permettront seulement de l'inclure dans les distros Linux et donc d'en faire une dépendance de Gimp. Tout restera à faire concernant un plugin de Gimp. Et accessoirement, Mozjpeg n'est plus maintenu par Mozilla, mais par Kornelski.
En fait il a trouvé ce qui fonctionne pour lui …utilisateur de aphone et certainement d'outils qui font des trucs automagiques sans qu'il ait plus de maitrise sur les paramètres d'une part, personne qui découvre d'autre part que la recherche de la résolution-définition ultime est inutile comme dit dans un autre commentaire.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Posté par mahikeulbody .
Évalué à 3.
Dernière modification le 19 février 2023 à 12:26.
C'est mal barré pour JPEG-XL, qui ne sera peut-être jamais ajouté aux navigateurs (cf journaux récents).
Parce que quand on fait de la photo, c'est seulement pour l'afficher sur un site web ?
Le jpeg-xl a le potentiel pour être le format idéal pour la majorité des applications (y compris dans les appareils photo car il ne demande pas d'accélération matérielle). Je ne vais pas reprendre la liste de ses avantages ici, ils sont très bien documentés sur le net. Il est déjà intégré à Gimp, Darktable, Digikam, Kritia, Telegram, etc… Il est supporté par Facebook, Nvidia, Intel, Adobe (Photoshop, Lightroom), et j'en passe.
On va baisser les bras et s'interdire de l'utiliser parce que Google fait son grognon (webp inside) et veut le retirer de Chrome (où il est pourtant déjà intégré) ?
NB. Google est un des premiers contributeurs importants à l'origine de jpeg-xl.
On ne parlait que du web dans cette discussion… Or, JPEG-XL n'est plus dans Chrome ni Chromium, Mozilla se déclare neutre sur le sujet (autrement dit ça va stagner) et Apple, 3ème poids lourd, n'a pas commencé. Et ce n'est que le dessus de l'iceberg ! Aucun navigateur mobile n'a commencé son intégration, or le web est majoritairement visité sur des mobiles. Voilà pourquoi je pense qu'aujourd'hui c'est mal barré pour JPEG-XL sur le web. Mais bien entendu ça peut changer.
Merci, je vais regarder cet outil
C'est volontaire ou non que tu mettes pas l'adresse de ton blogue dans ton profil LinuxFR ?
Pour ma part je mets une seule version, jpg ou png selon le type d'image, optimisée comme indiqué ici https://libre-ouvert.tuxfamily.org/?article2/mes-outils-pour-bloguer-gerer-les-fichiers-multimedias donc sans Mozjpeg actuellement (cf ce qui est dit plus haut à partir d'ici) faudrait que je teste voir les gains qu'il pourrait y avoir avec ma chaîne de production actuelle mais je ne pense pas le faire (rapport énergie dépensée / gain que j'anticipe faible) et plutôt attendre l'intégration de Mozjpeg dans Gimp l'an prochain peut-être
# Bref ?
Posté par antistress (site web personnel) . Évalué à 9. Dernière modification le 18 février 2023 à 03:46.
Je ne sais pas trop quoi penser de la méthodologie consistant à comparer le poids par exemple de fichiers JPEG 95% avec ceux de fichiers WebP 95% : qui dit que ces paramètres sont comparables au delà du nombre indiqué comme réglage pour différents encodeurs ?
Ou de partir d'un format particulier (utilisé pour les iPhone) pour réaliser ensuite des conversions en d'autres formats : qui dit que ces résultats sont extrapolables à partir d'autres formats ?
Et comme d'habitude, alors qu'il s'agit de trouver mieux que le JPEG, il n'est pas indiqué quel encodeur JPEG est utilisé (un optimisé ou non), rendant impossible de juger de la réalité des écarts avancés.
[^] # Re: Bref ?
Posté par antistress (site web personnel) . Évalué à 8.
Pour un billet en faveur de JPEG https://www.flother.is/til/mozjpeg/
Comme quoi…
[^] # Re: Bref ?
Posté par orfenor . Évalué à 4.
J'utilise tout le temps Mozjpeg. Avec des options "bien choisies", le poids des images descend au niveau d'une compression WebP. Kornelski, le mainteneur de Mozjpeg, a fait un utilitaire bien utile pour ceux qui ne veulent pas mettre la main dans le cambouis : ImageOptim qui existe en version online et en version Mac, livre directement l'image optimisée.
Avec un petit script Perl, on arrive à faire mieux qu'ImageOptim, en conservant la simplicité d'usage, mais au prix d'une appréciation "manuelle" de la qualité (avec l'habitude ça va vite).
Et à propos de la qualité, il faudrait que "les gens" remettent un peu les pieds sur terre : dans la plupart des pages web que je vois, on passe rapidement sur les images, rares sont celles qu'on regarde. De toute façon, les 3/4 des visiteurs sont sur mobile et consultent donc les pages dans de mauvaises conditions de lumière, et avec des reflets. Quant à ceux qui surfent sur grand écran, lequel a fait un calibrage ? Bref, rappelez vous les années modems, quand les images étaient petites et allégées au max. Une bonne pratique c'est d'alléger au max les premières images de la page, celles qui soutiennent le texte pour donner une vue d'ensemble. Et d'en mettre des belles, si besoin, un peu plus bas, pour ceux qui veulent des détail et s'intéressent au sujet. Ma copine le fait depuis 2 ans (elle vend des jouets), sa clientèle est ravie d'aller vite.
En faveur de JPEG, il ne faut pas oublier la relative rapidité de décompression sur nos CPUs.
[^] # Re: Bref ?
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 18 février 2023 à 11:15.
Bon, c'est bien ça m'oblige à regarder les coulisses des outils que j'utilise.
En général je resize avec le plugin GIMP Save for Web (qui n’accepte pas cependant les trop grosses résolutions en entrée) puis je fais une optimisation lossless avec jpegoptim, mais je ne sais pas du tout sur quoi se base ledit plugin Save for Web ni ce qu'il vaut par rapport à Mozjpeg ?
--
En tout cas il une demande de recours à Mozjpeg pour Gimp que Jehan a positionnée sur la version 3.2
https://gitlab.gnome.org/GNOME/gimp/-/issues/1039
[^] # Re: Bref ?
Posté par orfenor . Évalué à 3. Dernière modification le 18 février 2023 à 15:44.
Oui j'avais proposé à Jehan de le payer pour une interface à Mozjpeg. Mais on avait peu de moyens. De fil en aiguille il a proposé à Kornelski des modifications, pour intégrer Mozjpeg à Gimp, mais ça stagne.
Save for the web fait du bon boulot à partir de la libjpeg. Mais ne peut pas faire plus que ce que la lib propose. Tandis que Mozjpeg est basé libjpegturbo, qui dispose d'options avancées — et en ajoute qq autres bien sûr.
Pour utiliser Libjpegturbo/Mozjpeg je prépare une image de la plus haute qualité possible, parce que JPEG est mauvais sur la recompression. Ensuite je passe les paramètres à cjpeg (l'utilitaire de compression JPEG standard). J'utilise le cjpeg de Mozjpeg si je l'ai compilé, sinon celui de libjpegturbo.
Voilà les paramètres de libjpegturbo
et ceux rajoutés par Mozjpeg
Et voici comment faire
Le paramètre qui a le plus d'effet est dans libjpegturbo, c'est la compression différente pour la Luminance et la Chrominance. On va vulgariser un peu et les appeler lumière et couleur (c'est moins long à taper). Pour la lumière on met le paramètre de compression JPEG habituel, pour la couleur on met 1/4 ou 1/3 en général. Attention c'est lumière d'abord, couleur ensuite.
Pour jouer sur les qualités de lumière et de couleur il faut impérativement le paramètre
sample 1x1.Le lissage (paramètre
smooth) alourdit l'image et créé un peu de flou, auquel mon oeil est très sensible. L'utilisation des tables de quantisation permet de s'en passer avec Mozjpeg.Les tables de quantisation, c'est le deuxième paramètre qui a beaucoup d'effet. Pour le web, c'est le plus souvent la table 3 qui fait gagner le plus de poids, ensuite ce sont les tables 2 et 5. Les tables 7 et 8 permettent d'archiver avec une excellente qualité (je ne retrouve pas la discussion dans les bugs et PR de mozjpeg, mais c'est dedans) ; il m'arrive de m'en servir pour améliorer le rendu d'une image bien compressée, le poids supplémentaire est alors acceptable.
La CLI de base est donc
cjpeg -sample 1x1 -quality 65,21ça marche avec libjpegturbo (on peut ajouter -smooth [un nombre] pour corriger les artefacts de compression JPEG.
Et si on compile Mozjpeg, la CLI de base est
cjpeg -sample 1x1 -quality 65,21 -smooth 0 -quant-table 3… à laquelle je rajoute souvent
-dc-scan-opt 2Les autres paramètres servant (si j'ai bien compris) pour faire des comparaisons automatiques de qualité d'image.
[^] # Re: Bref ?
Posté par orfenor . Évalué à 2.
NB : Pour le web, on ne s'embête pas avec des valeurs précises de lumière et couleur , ça ne joue pas, aller de 5 en 5 est suffisant.
[^] # Re: Bref ?
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 18 février 2023 à 16:50.
D'après le site de ImageOptim :
ImageOptim for various platforms
The ImageOptim app only works on Macs (sorry!), but you can achieve similar compression with some other tools:
Linux
Trimage (GUI+CLI) — similar to ImageOptim and uses many of the same lossless tools under the hood.
Puis :
Command-line
With these tools and a bit of a glue code you can build your own image optimizer:
[^] # Re: Bref ?
Posté par orfenor . Évalué à 2.
Trimage ne fait que du Lossless.
Si tu regardes le code source d'ImageOptim tu vas voir qu'il y a pas mal de boulot sur le glue code ;-)
[^] # Re: Bref ?
Posté par antistress (site web personnel) . Évalué à 4.
OK merci
Bon, faut payer où pour contribuer à voir émerger mozjpeg dans GIMP ? ;)
Pourquoi pas un crowfunding de cette fonctionnalité (si un dev l'accepte) ?
[^] # Re: Bref ?
Posté par orfenor . Évalué à 3.
Mozjpeg utilisable dans Gimp c'est assez simple : il faut rendre Mozjpeg installable en parallèle de libjpeg (ou libjpegturbo). C'est un patch de Jehan qu'il faut revoir.
Mais pour avoir une interface graphique avec les options qui vont bien c'est autre chose. Jehan me l'a bien expliqué. Y'a du boulot et on voulait le payer pour ça. J'ai fait une interface en CLI qui masque la difficulté et nous permet (ma copine et moi) de l'utiliser en rafale sur un grand nombre d'images.
Effectivement ça vaudrait le coup de lancer un co-financement. Il suffit d'essayer Mozjpeg via ImageOptim online pour se rendre compte des bons résultats. Cela dit il y a des images pour lesquelles on ne fait pas aussi bien que WebP. L'image utilisée dans l'article en est un bon exemple.
[^] # Re: Bref ?
Posté par antistress (site web personnel) . Évalué à 3.
Pour l'interface graphique, le boulot qui a été fait pour générer des interfaces pour les greffons pourrait pas aider ?
[^] # Re: Bref ?
Posté par antistress (site web personnel) . Évalué à 4.
https://linuxfr.org/news/gimp-2-99-4-et-2-99-6-don-t-worry-be-h-api#toc-greffons-de-fichiers-mis-%C3%A0-jour-avec-interface-graphique-automatique-2994
[^] # Re: Bref ?
Posté par BAud (site web personnel) . Évalué à 2.
tu as https://www.patreon.com/zemarmot par exemple :-)
[^] # Re: Bref ?
Posté par antistress (site web personnel) . Évalué à 3.
Je donne déjà pour GIMP, ce n'est pas tout à fait ma question
[^] # Re: Bref ?
Posté par BAud (site web personnel) . Évalué à 2.
bin orfenor< t'a indiqué https://github.com/mozilla/mozjpeg/pull/383
faut tanner mozilla pour intégrer la pull request (tout le boulot est déjà fait)
[^] # Re: Bref ?
Posté par orfenor . Évalué à 2. Dernière modification le 19 février 2023 à 14:14.
Non, tu n'as pas compris. Faut lire la discussion et les critiques sous la PR et les bugs en rapport : il y a des trucs à revoir, du code à faire. Les changement dans Mozjpeg permettront seulement de l'inclure dans les distros Linux et donc d'en faire une dépendance de Gimp. Tout restera à faire concernant un plugin de Gimp. Et accessoirement, Mozjpeg n'est plus maintenu par Mozilla, mais par Kornelski.
[^] # Re: Bref ?
Posté par antistress (site web personnel) . Évalué à 4.
Merci tous deux pour les précisions.
Quelle frustration, Jehan doit être boudhiste c'est pas possible
[^] # Re: Bref ?
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
En fait il a trouvé ce qui fonctionne pour lui …utilisateur de aphone et certainement d'outils qui font des trucs automagiques sans qu'il ait plus de maitrise sur les paramètres d'une part, personne qui découvre d'autre part que la recherche de la résolution-définition ultime est inutile comme dit dans un autre commentaire.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# JPEG XL
Posté par Glandos . Évalué à 4.
https://jpegxl.info/why-jxl.html
C'est vrai qu'il a l'air de découvrir que ces formats sont révolutionnaires. Mais il ne peut pas ne pas être tombé sur JPEG-XL…
Bref, l'article est un peu trop manichéen :)
[^] # Re: JPEG XL
Posté par orfenor . Évalué à 3.
C'est mal barré pour JPEG-XL, qui ne sera peut-être jamais ajouté aux navigateurs (cf journaux récents).
[^] # Re: JPEG XL
Posté par mahikeulbody . Évalué à 3. Dernière modification le 19 février 2023 à 12:26.
Parce que quand on fait de la photo, c'est seulement pour l'afficher sur un site web ?
Le jpeg-xl a le potentiel pour être le format idéal pour la majorité des applications (y compris dans les appareils photo car il ne demande pas d'accélération matérielle). Je ne vais pas reprendre la liste de ses avantages ici, ils sont très bien documentés sur le net. Il est déjà intégré à Gimp, Darktable, Digikam, Kritia, Telegram, etc… Il est supporté par Facebook, Nvidia, Intel, Adobe (Photoshop, Lightroom), et j'en passe.
On va baisser les bras et s'interdire de l'utiliser parce que Google fait son grognon (webp inside) et veut le retirer de Chrome (où il est pourtant déjà intégré) ?
NB. Google est un des premiers contributeurs importants à l'origine de jpeg-xl.
[^] # Re: JPEG XL
Posté par orfenor . Évalué à 4.
On ne parlait que du web dans cette discussion… Or, JPEG-XL n'est plus dans Chrome ni Chromium, Mozilla se déclare neutre sur le sujet (autrement dit ça va stagner) et Apple, 3ème poids lourd, n'a pas commencé. Et ce n'est que le dessus de l'iceberg ! Aucun navigateur mobile n'a commencé son intégration, or le web est majoritairement visité sur des mobiles. Voilà pourquoi je pense qu'aujourd'hui c'est mal barré pour JPEG-XL sur le web. Mais bien entendu ça peut changer.
Pour les intégrations voir https://caniuse.com/?search=jpegxl
# Il y a aussi Imgp et...
Posté par arnauld . Évalué à 2.
Pour mon blog (presque pas visité) je mets pour chaque image une version en jpg ou png, une en webp et une en avif, par ordre où elles sont servies.
Pour optimiser et convertir mes images j'utilise Imgp https://github.com/jarun/imgp
arnauld
[^] # Re: Il y a aussi Imgp et...
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 19 février 2023 à 10:28.
Merci, je vais regarder cet outil
C'est volontaire ou non que tu mettes pas l'adresse de ton blogue dans ton profil LinuxFR ?
Pour ma part je mets une seule version, jpg ou png selon le type d'image, optimisée comme indiqué ici https://libre-ouvert.tuxfamily.org/?article2/mes-outils-pour-bloguer-gerer-les-fichiers-multimedias donc sans Mozjpeg actuellement (cf ce qui est dit plus haut à partir d'ici) faudrait que je teste voir les gains qu'il pourrait y avoir avec ma chaîne de production actuelle mais je ne pense pas le faire (rapport énergie dépensée / gain que j'anticipe faible) et plutôt attendre l'intégration de Mozjpeg dans Gimp l'an prochain peut-être
[^] # Re: Il y a aussi Imgp et...
Posté par orfenor . Évalué à 2.
Sauf erreur de ma part, cet outil (très intéressant par ailleurs, merci de l'info!) ne propose pas plus qu'une compression JPEG de base ?
# Puisqu'on parle d'optimisation des images
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 2.
Connaissez-vous Curtail ? Qu'en pensez-vous ? Est-ce adapté à l'optimisation pour le web ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.