Il me semble que tu as déjà demandé et que j'ai déjà répondu à tout ça.
préférer l'algo jpegli à l'encodage jpeg classique
Ces libs alternatives font des fichiers plus petits pour une même qualité visuelle. C'est génial. Mais cela se fait au prix d'un temps de codage extrêmement rallongé.
Comme je l'explique dans mon message de commit du MR où j'ajoute la prise en charge de Mozjpeg, pour une image (de taille tout à fait raisonnable), qui met 3,9 seconds à s'exporter en JPEG sur ma machine, avec jpeg-turbo (la libjpeg la plus standard sous Linux), cette même image s'exportait en plus de 30 seconds avec Mozjpeg.
Ce n'est pas acceptable comme régression. C'est tout à fait OK pour une nouvelle option cela dit (pour un choix taille du fichier vs. temps d'export) mais pas pour un remplacement de lib.
Ensuite je comprends que jpegli est plus rapide que Mozjpeg, en plus de faire des images plus petites. C'est cool. Je suppose que ce n'est toujours pas au niveau de jpeg-turbo ceci dit, sinon les dévs en auraient fait la pub à fond. Mais bon j'ai pas testé. Si quelqu'un fait un patch, et fait des tests extensifs et reproductibles prouvant que cela produit à la fois des fichiers de même qualité visuelle, plus petits, et tout cela en étant au moins aussi rapide, alors on en reparlera.
En attendant: c'est OK comme une option, mais non on ne va pas "préférer" jpegli à jpeg-turbo. Le format JPEG est un des formats les plus utilisés au monde, et je peux t'assurer que le jour où on sort une version qui multiplie le temps d'export par ×ばつ8, on sera inondé de rapports de bugs (et les rapporteurs auront raison de considérer cela comme un bug).
Tu as relancé le mainteneur de Mozjpeg. Mais pourquoi ne pas plutôt intégrer Jpegli dans Gimp ?
L'un n'invalide pas l'autre. J'ai déjà fait tout le boulot pour mozjpeg et finaliser le truc prendra 20 minutes (inclus le temps de vérification que tout marche encore) si jamais son mainteneur se réveille.
Quant à jpegli, je n'ai fait aucune recherche, j'ai pas compilé le code, j'ai pas testé dans GIMP... j'en ai pour des heures de travail, que je ferai peut-être un jour. Ou pas. Ou qu'un autre fera. Je sais pas. Je ne cherche pas la primauté sur toutes le nouveautés. 😅
Plutôt que d'hypothétiques, j'aime me nourrir de choses certaines.
Ce ne sont pas des choix inter-échangeables, ce sont des développements additifs. Chacun me prend du temps en plus.
Il n'a pas d'options supplémentaires par rapport à l'ancien algo, mais savoir qu'il est utilisé permet une meilleure compression
Rien de tout cela n'est suffisant pour mettre ça facilement dans GIMP. En fait même la seule fonctionnalité dont on a besoin n'y est pas! Parce que les autres options, etc. ben on pourrait tout à fait faire avec. Je vois pas pourquoi ce serait un problème si jpegli avait même une API propre.
De ce que je comprends, le problème est le même qu'avec mozjpeg (et c'est la raison pour laquelle ce dernier n'est pas non plus dans GIMP même, et ce alors que j'ai un patch près depuis 2023, lequel dépend d'un patch sur Mozjpeg que j'ai contribué en 2020, puis réimplémenté en 2023!). Ces gens, que ce soit Mozilla ou Google, ne semblent avoir aucune idée des bonnes pratiques de développement que les gens sur les OS libres ont progressivement peaufinées au cours des dernières décennies. Ils font des logiciels qui sont fait pour être embarqués dans un paquet unique, "drop-in" comme ils aiment bien dire, ce qui est surtout un autre joli mot pour dire qu'ils se fichent de l'existant, et de casser tout ce qui existe, sans donner un espace de nom dédié à leurs fichiers.
Bon je dis ça, je m'avance peut-être pour jpegli, puisque je n'ai pas testé. Mais c'est aussi ce qu'il me semble comprendre que ces derniers font. Et cela explique d'ailleurs pourquoi on ne voit ni de mozjpeg ni de jpegli dans les distribs classiques. Parce qu'il n'est acceptable pour personne d'avoir une telle régression et aussi qu'on ne va pas s'amuser à jarter des dépôts un projet historique (jpeg-turbo) qui a été un bon joueur du libre à chaque fois qu'un nouveau venu de la Silicon Valley arrive avec ses grandes annonces tonitruantes (surtout quand on sait comme ces gens aiment créer et tuer des projets d'un coup; Mozjpeg est encore un bon exemple puisque clairement Mozilla le délaisse maintenant). Et ce d'autant plus quand les dits projets se reposent en fait sur jpeg-turbo comme leur propre upstream (c'est en tous cas le cas de Mozjpeg, qui le dit clairement; je suis moins sûr pour jpegli), donc bon... en essayant de tuer leur upstream en utilisant le même espace de nom, c'est un peu des projets qui scient la branche sur laquelle ils sont assis. Et aussi qui sont vraiment peu reconnaissants de leurs prédécesseurs qui leur a mâché le travail.
Note que je ne dis pas que ces projets ne doivent pas aussi proposer une option drop-in, mais seulement s'ils ont aussi l'option de s'installer dans un espace de nom propre. Ou alors ils doivent être à la mesure de leur ambition et d'une part ne pas dépendre du tout du projet qu'ils essaient de remplacer, d'autre part d'être mieux en tous points.
Enfin bon, comme tu le sais (puisque je suis persuadé qu'on en a déjà parlé), je n'ai absolument rien contre une option jpegli, bien au contraire. J'adorerais une option pour avoir des JPEG plus petits (une option "export web" en gros). Et j'intégrerai un patch fait par quelqu'un avec plaisir. Ce n'est pas forcément à faire par moi! Sinon, je n'ai plus le temps si je dois tout faire sur tout.
En plus, j'ai aucune idée si un patch que je pourrais faire pour jpegli (dans leur propre intérêt! Je comprends pas pourquoi ces gens ne voient pas comme il serait intéressant d'être dans les paquets de toutes les distributions Linux! Même le mainteneur de Mozjpeg, j'ai eu du mal à le persuader qu'il y avait un intérêt et au final... il a juste disparu). Comme on l'a vu avec Mozjpeg, ce n'est pas une évidence. Et de mémoire, j'ai déjà eu d'autres patchs dans des projets Google qui ont été rejetés sans être lus après être restés des années sans réponse. Alors bon... je dis pas que j'essaierais pas un jour (j'aimerais beaucoup, aussi), mais je suis pas non plus pressé.
Ensuite, comme ces gens aiment bien le dire, c'est juste du "drop-in", donc quiconque a le droit de prendre un de nos paquets et de juste échanger la libjpeg. Ça marche aussi. Et pis c'est censé être "facile" (si on vous le dit! C'est écrit dans le discours marketing!). 🙄
P.S.: je comprends bien que vous avez tous votre option "killer feature" (que ce soit jpegli pour l'un ou les vignettes pour l'autre) mais bon le principe, c'est que si on dépend de bénévoles, alors faut juste être patient. Personne n'est contre une meilleure prise en charge de vignettes, ni contre une super option pour exporter de plus petits JPEGs. Mais bon, c'est la vie.
En plus, nous même dépendons de projets upstream et on ne peut pas (ni ne voulons!) faire n'importe quoi. GIMP est un projet qui a historiquement "fait les choses bien", et en conséquence, cela a créé des projets comme GTK, ou GLib. GNOME est donc aussi une conséquence de GIMP. Même le fait que Qt et donc KDE sont maintenant entièrement libres vient partiellement de notre projet en fait (puisque cela s'est produit en réaction notamment au succès de GTK et GNOME). Un autre projet que je maintiens est aussi utilisé massivement, comme uchardet (également sauvé historiquement du cimetière Mozilla!), ou même un petit project comme crossroad, je découvre à l'instant en regardant leur dépôt que même jpegli l'utilise. C'est ça le pouvoir de faire les choses dans les règles de l'art et c'est grâce à ce genre de détails que le libre a évolué positivement. Et nous poussons aussi nos dépendances à faire de même. On ne s'aligne pas sur les mauvaises pratiques (sinon au final, ce sont elles qui gagnent et je peux assurer que ce ne sera pas au bénéfice des gens dans leur ensemble en conclusion!).
Et si quelqu'un ne peut pas vivre sans une fonctionnalité, alors engager quelqu'un est aussi une option à propos! Cela s'est déjà vu dans GIMP. En fait, c'est même l'entièreté de la raison de mon implication dans ce projet. Je travaille sur GIMP pour un projet professionnel. Si certains ont un besoin absolu de pousser certains usages, soit vous attendez en espérant que la chance vienne (tout à fait possible), soit vous prenez les devants. 🙂
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: préférer l'algo jpegli à l'encodage jpeg classique
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche GIMP 3.2.0 est sorti. Évalué à 10. Dernière modification le 30 mars 2026 à 22:26.
Il me semble que tu as déjà demandé et que j'ai déjà répondu à tout ça.
Ces libs alternatives font des fichiers plus petits pour une même qualité visuelle. C'est génial. Mais cela se fait au prix d'un temps de codage extrêmement rallongé.
Comme je l'explique dans mon message de commit du MR où j'ajoute la prise en charge de Mozjpeg, pour une image (de taille tout à fait raisonnable), qui met 3,9 seconds à s'exporter en JPEG sur ma machine, avec jpeg-turbo (la libjpeg la plus standard sous Linux), cette même image s'exportait en plus de 30 seconds avec Mozjpeg.
Ce n'est pas acceptable comme régression. C'est tout à fait OK pour une nouvelle option cela dit (pour un choix taille du fichier vs. temps d'export) mais pas pour un remplacement de lib.
Ensuite je comprends que jpegli est plus rapide que Mozjpeg, en plus de faire des images plus petites. C'est cool. Je suppose que ce n'est toujours pas au niveau de jpeg-turbo ceci dit, sinon les dévs en auraient fait la pub à fond. Mais bon j'ai pas testé. Si quelqu'un fait un patch, et fait des tests extensifs et reproductibles prouvant que cela produit à la fois des fichiers de même qualité visuelle, plus petits, et tout cela en étant au moins aussi rapide, alors on en reparlera.
En attendant: c'est OK comme une option, mais non on ne va pas "préférer" jpegli à jpeg-turbo. Le format JPEG est un des formats les plus utilisés au monde, et je peux t'assurer que le jour où on sort une version qui multiplie le temps d'export par ×ばつ8, on sera inondé de rapports de bugs (et les rapporteurs auront raison de considérer cela comme un bug).
L'un n'invalide pas l'autre. J'ai déjà fait tout le boulot pour mozjpeg et finaliser le truc prendra 20 minutes (inclus le temps de vérification que tout marche encore) si jamais son mainteneur se réveille.
Quant à jpegli, je n'ai fait aucune recherche, j'ai pas compilé le code, j'ai pas testé dans GIMP... j'en ai pour des heures de travail, que je ferai peut-être un jour. Ou pas. Ou qu'un autre fera. Je sais pas. Je ne cherche pas la primauté sur toutes le nouveautés. 😅
Plutôt que d'hypothétiques, j'aime me nourrir de choses certaines.
Ce ne sont pas des choix inter-échangeables, ce sont des développements additifs. Chacun me prend du temps en plus.
Rien de tout cela n'est suffisant pour mettre ça facilement dans GIMP. En fait même la seule fonctionnalité dont on a besoin n'y est pas! Parce que les autres options, etc. ben on pourrait tout à fait faire avec. Je vois pas pourquoi ce serait un problème si jpegli avait même une API propre.
De ce que je comprends, le problème est le même qu'avec mozjpeg (et c'est la raison pour laquelle ce dernier n'est pas non plus dans GIMP même, et ce alors que j'ai un patch près depuis 2023, lequel dépend d'un patch sur Mozjpeg que j'ai contribué en 2020, puis réimplémenté en 2023!). Ces gens, que ce soit Mozilla ou Google, ne semblent avoir aucune idée des bonnes pratiques de développement que les gens sur les OS libres ont progressivement peaufinées au cours des dernières décennies. Ils font des logiciels qui sont fait pour être embarqués dans un paquet unique, "drop-in" comme ils aiment bien dire, ce qui est surtout un autre joli mot pour dire qu'ils se fichent de l'existant, et de casser tout ce qui existe, sans donner un espace de nom dédié à leurs fichiers.
Bon je dis ça, je m'avance peut-être pour
jpegli, puisque je n'ai pas testé. Mais c'est aussi ce qu'il me semble comprendre que ces derniers font. Et cela explique d'ailleurs pourquoi on ne voit ni de mozjpeg ni de jpegli dans les distribs classiques. Parce qu'il n'est acceptable pour personne d'avoir une telle régression et aussi qu'on ne va pas s'amuser à jarter des dépôts un projet historique (jpeg-turbo) qui a été un bon joueur du libre à chaque fois qu'un nouveau venu de la Silicon Valley arrive avec ses grandes annonces tonitruantes (surtout quand on sait comme ces gens aiment créer et tuer des projets d'un coup; Mozjpeg est encore un bon exemple puisque clairement Mozilla le délaisse maintenant). Et ce d'autant plus quand les dits projets se reposent en fait sur jpeg-turbo comme leur propre upstream (c'est en tous cas le cas de Mozjpeg, qui le dit clairement; je suis moins sûr pour jpegli), donc bon... en essayant de tuer leur upstream en utilisant le même espace de nom, c'est un peu des projets qui scient la branche sur laquelle ils sont assis. Et aussi qui sont vraiment peu reconnaissants de leurs prédécesseurs qui leur a mâché le travail.Note que je ne dis pas que ces projets ne doivent pas aussi proposer une option drop-in, mais seulement s'ils ont aussi l'option de s'installer dans un espace de nom propre. Ou alors ils doivent être à la mesure de leur ambition et d'une part ne pas dépendre du tout du projet qu'ils essaient de remplacer, d'autre part d'être mieux en tous points.
Enfin bon, comme tu le sais (puisque je suis persuadé qu'on en a déjà parlé), je n'ai absolument rien contre une option jpegli, bien au contraire. J'adorerais une option pour avoir des JPEG plus petits (une option "export web" en gros). Et j'intégrerai un patch fait par quelqu'un avec plaisir. Ce n'est pas forcément à faire par moi! Sinon, je n'ai plus le temps si je dois tout faire sur tout.
En plus, j'ai aucune idée si un patch que je pourrais faire pour jpegli (dans leur propre intérêt! Je comprends pas pourquoi ces gens ne voient pas comme il serait intéressant d'être dans les paquets de toutes les distributions Linux! Même le mainteneur de Mozjpeg, j'ai eu du mal à le persuader qu'il y avait un intérêt et au final... il a juste disparu). Comme on l'a vu avec Mozjpeg, ce n'est pas une évidence. Et de mémoire, j'ai déjà eu d'autres patchs dans des projets Google qui ont été rejetés sans être lus après être restés des années sans réponse. Alors bon... je dis pas que j'essaierais pas un jour (j'aimerais beaucoup, aussi), mais je suis pas non plus pressé.
Ensuite, comme ces gens aiment bien le dire, c'est juste du "drop-in", donc quiconque a le droit de prendre un de nos paquets et de juste échanger la libjpeg. Ça marche aussi. Et pis c'est censé être "facile" (si on vous le dit! C'est écrit dans le discours marketing!). 🙄
P.S.: je comprends bien que vous avez tous votre option "killer feature" (que ce soit jpegli pour l'un ou les vignettes pour l'autre) mais bon le principe, c'est que si on dépend de bénévoles, alors faut juste être patient. Personne n'est contre une meilleure prise en charge de vignettes, ni contre une super option pour exporter de plus petits JPEGs. Mais bon, c'est la vie.
En plus, nous même dépendons de projets upstream et on ne peut pas (ni ne voulons!) faire n'importe quoi. GIMP est un projet qui a historiquement "fait les choses bien", et en conséquence, cela a créé des projets comme GTK, ou GLib. GNOME est donc aussi une conséquence de GIMP. Même le fait que Qt et donc KDE sont maintenant entièrement libres vient partiellement de notre projet en fait (puisque cela s'est produit en réaction notamment au succès de GTK et GNOME). Un autre projet que je maintiens est aussi utilisé massivement, comme uchardet (également sauvé historiquement du cimetière Mozilla!), ou même un petit project comme crossroad, je découvre à l'instant en regardant leur dépôt que même jpegli l'utilise. C'est ça le pouvoir de faire les choses dans les règles de l'art et c'est grâce à ce genre de détails que le libre a évolué positivement. Et nous poussons aussi nos dépendances à faire de même. On ne s'aligne pas sur les mauvaises pratiques (sinon au final, ce sont elles qui gagnent et je peux assurer que ce ne sera pas au bénéfice des gens dans leur ensemble en conclusion!).
Et si quelqu'un ne peut pas vivre sans une fonctionnalité, alors engager quelqu'un est aussi une option à propos! Cela s'est déjà vu dans GIMP. En fait, c'est même l'entièreté de la raison de mon implication dans ce projet. Je travaille sur GIMP pour un projet professionnel. Si certains ont un besoin absolu de pousser certains usages, soit vous attendez en espérant que la chance vienne (tout à fait possible), soit vous prenez les devants. 🙂
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]