Note : cette dépêche est une traduction de l'annonce officielle de la sortie de GIMP 3.2 du 14 mars 2026 (en anglais).
Nous sommes heureux de vous présenter la première version de GIMP 3.2 ! (NdM: et même la 3.2.2 depuis)
Cette version est le fruit d'une année de conception, de développement et de tests réalisés par des bénévoles et la communauté, conformément à notre plan visant à simplifier le rythme des mises à jour après GIMP 3.0.
Nous avons hâte de vous faire découvrir les nouvelles fonctionnalités de la version 3.2 !
Image de démarrage de GIMP 3.2, par Mark McCaughrean (CC by-sa 4.0)
Changements majeurs
Voici quelques-unes des nombreuses nouveautés à découvrir lors de la première utilisation de GIMP 3.2 :
-
Nouveaux calques non destructifs !
- Vous pouvez désormais utiliser les calques liés pour intégrer des images externes à vos compositions. Redimensionnez, faites pivoter et transformez-les facilement sans perte de qualité ni de netteté. Le contenu du calque lié est mis à jour lorsque le fichier source est modifié.
- L'outil Tracé peut maintenant créer des calques vectoriels, vous permettant de dessiner des formes avec des paramètres de remplissage et de contour ajustables.
L'outil Pinceaux de MyPaint a été mis à jour : 20 nouveaux pinceaux sont disponibles et il s'adapte automatiquement au zoom et à la rotation de votre zone de travail pour une peinture plus dynamique.
Un nouveau mode de peinture « Écraser » vous permet de dessiner par-dessus les couleurs existantes sans mélanger leur transparence.
L'éditeur de texte intégré à la zone de travail bénéficie de plusieurs améliorations de flux de travail. Vous pouvez désormais déplacer l'élément à votre guise sur la zone de travail et utiliser de nombreux raccourcis courants, tels que
Ctrl+Bpour le texte en gras etMaj+Ctrl+Vpour coller du texte non formaté. La fonction Contour du texte inclut également davantage d'options pour contrôler la direction du contour.Prise en charge de nouveaux formats de fichiers et améliorations des formats existants, comme l'exportation DDS BC7 et l'importation de davantage de styles de calques pour les fichiers PSD. Grâce aux calques vectoriels, nous prenons désormais en charge l'exportation SVG et proposons des options vectorielles étendues pour l'exportation PDF.
-
Diverses améliorations de l'expérience utilisateur (UX) et de l'interface utilisateur (UI), basées sur vos commentaires et le travail de notre équipe de conception. En voici quelques exemples :
- Possibilité d'utiliser les couleurs du thème pour les vignettes des pinceaux lors des aperçus, pour une meilleure expérience avec les thèmes sombres.
- Possibilité de glisser-déposer des images sur l'onglet Image pour les ouvrir dans GIMP.
- Prise en charge des raccourcis clavier pour les outils Cisaillement et Retournement.
- Nouveau thème de couleurs « Système » qui adapte automatiquement les couleurs du thème de GIMP à celui défini pour votre système d'exploitation.
Le sélecteur de couleurs CMJN affiche désormais la « Couverture d'encre totale » de votre couleur, facilitant ainsi les ajustements lors de l'épreuvage écran, en fonction de la limite de couverture d'encre de votre imprimante.
- Pour les développeurs de scripts et de modules complémentaires, un nouveau explorateur de filtres GEGL a été ajouté afin de simplifier la recherche de filtres non destructifs.
En savoir plus
Nous avons préparé les notes de version qui détaillent toutes les modifications, améliorations, nouvelles fonctionnalités et bien plus encore. Pour encore plus d'informations, consultez le journal des modifications des versions de développement 3.1 et 3.2.
Mais pour le découvrir par vous-même, téléchargez GIMP 3.2 directement depuis notre page de téléchargements et testez-le !
Autres versions connexes
Pour accompagner la sortie de GIMP 3.2, les responsables de paquets doivent savoir que nous avons également publié :
Nous ne disposons pas encore d'une documentation prête à être diffusée pour cette version 3.2.
Nous vous recommandons de continuer à utiliser la documentation en ligne de la version 3.0 pour le moment.
Nos contributeurs travaillent activement à l'amélioration de la documentation.
Toute contribution est la bienvenue sur notre projet gimp-help afin d'accélérer le processus !
Profitez de GIMP 3.2 !
GIMP 3.2 s'appuie sur les bases posées par GIMP 3.0, offrant de nouvelles fonctionnalités exceptionnelles et préparant le terrain pour des nouveautés encore plus impressionnantes dans les versions futures !
Remarque : la livraison des paquets sur les plateformes de téléchargement peut prendre un peu plus de temps, car ils sont peut-être en cours de vérification.
Soutenez le développement de GIMP
N'oubliez pas que vous pouvez faire un don et soutenir financièrement les développeurs de GIMP, afin de
contribuer et d'accélérer le développement de GIMP. L'engagement de la communauté est essentiel à la réussite du projet !
Aller plus loin
- Annonce de sortie de GIMP 3.2 (79 clics)
- Notes de sortie de GIMP 3.2 (37 clics)
- Téléchargement de GIMP (41 clics)
- Donations pour soutenir le développement de GIMP (34 clics)
# typo: 2026 au lieu de 2025 dans la note d'entête
Posté par oliverpool (site web personnel) . Évalué à 5 (+4/-0).
L'annonce traduite arrive 15 jours après l'annonce officielle (et non pas 1 an et 15 jours :)
--
Merci pour tout le boulot technique et communautaire !
[^] # Re: typo: 2026 au lieu de 2025 dans la note d'entête
Posté par Benoît Sibaud (site web personnel) . Évalué à 8 (+5/-0).
Ce week-end on change d'année. Corrigé, merci.
# GIMP 3.2.2 est déjà là!
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+8/-0).
Entre le moment où cette dépêche fut commencée et maintenant, exactement 2 semaines se sont passées et on a déjà sorti la première version de correction de bug: GIMP 3.2.2.
Voili voilà. Il n'y a pas de nouveautés particulièrement époustouflantes pour GIMP 3.2.2, sinon de rendre GIMP plus stable (c'est le but d'une version micro). Donc une nouvelle dépêche n'est sûrement pas nécessaire (mais bon… sauf si quelqu'un veut en faire une, j'imagine…). Alors je donne l'info en commentaire à la place. :-)
Peut-être une note dans la dépêche de la version 3.2.0 pourrait être propice, ceci dit, puisqu'elle est encore en première page du site.
Merci à tous pour le travail de traduction, édition, publication, etc.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Benoît Sibaud (site web personnel) . Évalué à 4 (+1/-0).
Note ajoutée, merci.
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Maderios . Évalué à 6 (+4/-0).
Une nouveauté indispensable, qui ne serait en fait que la résolution d'une régression, serait de pouvoir afficher de nouveau les vignettes des fichiers XCF dans les gestionnaires d'images/fichiers. Ce n'est plus cas depuis que l'on peut utiliser les calques non destructifs, fonction formidable. Les photographes ont toujours utilisé des "vignettes" pour travailler. Dans le passé, c'était des diapositives que l'on disposait sur la table lumineuse; ou bien les planches-contact pour le N&B, images 24x36 que l'on scrutait avec une bonne loupe à poser, genre x10. Du coté des agences photographiques presse/illustration, on choisit les images sur des écrans remplis de vignettes. C'est comme ça que ça marche. Tant que cet affichage ne sera pas disponible, Gimp ne sera pas utilisable en photographie professionnelle (ou amateurisme "éclairé"). Je parle bien ici de photographie et non de graphisme où peut-être, les exigences sont différentes.
J'ai cru comprendre qu'il serait possible d'intégrer un png dans chaque XCF, c'est une bonne idée à condition que la définition de ce png/vignette soit d'une taille suffisante (1), je pense à 512x512 pixels, taille que je connais bien puisque je l'utilise dans Digikam. Elle permet de voir les détails de l'image sans avoir besoin d'ouvrir le fichier.
(1) Je ne pense pas que le poids d'un png 512x512 soit pénalisant dans le cadre de de fichiers XCF qui peuvent atteindre des dizaines de Mo ou même plus de 100 Mo
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Axelos (site web personnel) . Évalué à 1 (+0/-0).
C’est une question intéressante. Je me demande cependant si le problème ne devrait pas être pris à l’envers : Ne serait-ce pas aux explorateurs de fichiers de s’adapter pour générer une vignette d’un fichier XCF à la volée (en prenant en charge ces nouveaux calques) ?
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Maderios . Évalué à 2 (+0/-0).
Bonne question mais au vu de l'ancienneté du problème, des réponses négatives données lors des nombreux rapports de bugs envoyés aux dev concernés par le problème (dont kimageformats et imagemagick), ce n'est pas prêt de se faire.
Détails ici: https://bugs.kde.org/show_bug.cgi?id=491795
Pour info, Digikam utilise kimageformats, donc ne pas enquiquiner les devs (bien ennuyés ne pouvoir résoudre cette histoire). Ils ont également essayé d'utiliser imagemagicks, "but it's a mess".
Concernant imagemagick, les dev m'ont répondu que la prise en charge des XCF n'était pas à l'ordre du jour.
Coté GTK/Gnome, j'ignore ce qu'il se passe.
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Personnellement je pense que pour ce genre de fichier spécifique, c’est à l’éditeur de fournir un outil en ligne de commande qui prend en entrée un fichier et qui sort une image, afin d’être intégré au système de vignette.
Par exemple pour les fichiers raw j’ai scripté
darktable-cli:C’est atrocement lent mais au moins j’ai la garantie que la vignette correspond exactement à ce que Darktable va me présenter.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Sébastien Wilmet (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Il y a aussi une spécification freedesktop.org à ce sujet :
https://www.freedesktop.org/wiki/Specifications/thumbnails/
freedesktop.org - ou encore XDG pour Cross-Desktop Group - rassemble des spécifications et des composants logiciels communs entre les différents environnements de bureaux libres.
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Jehan (site web personnel, Mastodon) . Évalué à 3 (+0/-0).
GIMP prend en charge cette spec depuis toujours pour info, c'est à dire qu'il génère les vignettes des images et les installe aux emplacements adéquats. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Maderios . Évalué à 3 (+1/-0).
J'ai l'impression que l'on ne parle pas de la même chose. Je n'ai jamais vu de vignettes générées par Gimp, au moins depuis l'apparition des calques non destructifs. Si dans le meilleur des cas il y a des vignettes issues de fichiers XCF dans les gestionnaires d'images, elles sont générées par des logiciels extérieurs, dont kimageformats, par exemple, et ce à condition que ce soit des XCF simples, c'est à dire n'incluant pas des calques non destructifs. Dans le cas contraire, on a le droit à un carré noir en guise de vignette.
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Jehan (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Si, GIMP génère des vignettes pour toutes les images qu'il ouvre (XCF ou non d'ailleurs).
Une fois que tu as ouvert un XCF dans GIMP, alors tu en verras la vignette dans tout logiciel qui prend en charge cette même spécification "Thumbnail Managing Standard" de Freedesktop. Ça marche parfaitement chez moi avec GNOME Files , et je pense que ça marche avec la plupart des navigateurs de fichiers sous Linux/BSD et autre OS libres, puisque c'est une ancienne spéc qui est on-ne-peut-plus standard.
Ensuite je ne vais pas prétendre utiliser tous les navigateurs de fichiers sous Linux, donc si ça ne fonctionne pas pour celui que tu utilises, je conseillerais de faire une demande de fonctionnalités.
Par contre, ça ne crée pas de vignettes pour les XCFs ou autres images qui n'ont pas été au préalable ouvertes dans GIMP (par exemple, un XCF que quelqu'un t'a envoyé ou échangé entre machines), ou bien si tu as renommé ou déplacé le fichier (la spéc reconnaît les images par leur location absolue dans le système de fichier)…
Ton OS peut aussi avoir un système qui nettoie le cache régulièrement, par exemple en supprimant les vieilles vignettes de plus de X jours. Donc il se peut aussi que si tu recherches sur des XCFs qui datent d'il y a longtemps, il n'y ait plus de vignettes.
Ce qui pour moi est ton problème (tu navigues au hasard dans tes XCFs, et tu espères avoir des vignettes pour tous tes fichiers).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Bonjour Jehan, on parle bien du fait que lorsque tu ouvres un dossier dans un explorateur de fichier comme nautilus, thunar ou dolphin, l’explorateur de fichier puisse appeler GIMP sans interface pour générer les miniatures des fichiers du dossiers. Est-ce que GIMP propose une telle interface ?
Cette interface en ligne de commande n’a pas besoin d’être standardisée, on peut écrire un script autour comme j’ai fait avec Darktable.
De mon côté j’utilise mon propre fork de
gnome-xcf-thumbnaileravec des patchs perso:Mais ce projet ne fait pas partie de GIMP, donc quand GIMP fait évoluer le format (et c’est très bien et j’ai même des suggestions à apporter), bah
gnome-xcf-thumbnailerne suit pas et ne peut pas générer des miniatures pour les nouvelles itérations du format.Mon besoin est de pouvoir utiliser un outil genre
gimp-cliqui prendrait en entrée un fichier xcf et qui donnerait en sortie un png, compilé depuis la même base de code de GIMP (avec desifdefpar exemple), est-ce que ça existe ? Ça serait peut-être atrocement lent, mais ça marcherait. On pourrait même chaînergnome-xcf-thumbnaileret n’appeler cegimp-clique quand le premier échoue.Peut-être que tout est déjà là. Je sais qu’il existe
gimp-console, peut-être qu’on peut le scripter pour faire ça.Je n’ai pas du tout besoin que GIMP génère des vignettes et implémente la spécification "Thumbnail Managing Standard" de Freedesktop.
J’ai besoin que GIMP propose un outil en ligne de commande qui propose cette interface:
command -s SIZE INFILE OUTFILE.J’attends de mon explorateur de fichier (pas GIMP) d’implémenter la spécification "Thumbnail Managing Standard" de Freedesktop, et puisse appeler GIMP avec l’interface précitée. 🙂️
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Thomas Debesse (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Ça m’a motivé à ré-investiguer le problème, et voici donc
gimp-thumbnailer:Il sera toujours à jours des format XCF vu qu’il utilise GIMP directement pour produire la miniature.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Maderios . Évalué à 2 (+1/-1). Dernière modification le 31 mars 2026 à 11:46.
Cette solution semble intéressante si gimp-thumbnailer génère des vignettes pour les XCF qui incluent des calques non destructifs en respectant l'image intégralement. Une inconnue demeure, la taille des vignettes générées. Si la vignette est trop petite, elle sera inutilisable. L'idéal serait qu'elle fasse 512x512. C'est nécessaire quand on travaille sur plusieurs versions d'une image, versions impossibles à différencier si la vignette est trop petite.
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Jehan (site web personnel, Mastodon) . Évalué à 6 (+3/-0).
Je te suggèrerai de nous le soumettre en patch: https://gitlab.gnome.org/GNOME/gimp/
Mets le dans
app-tools/et rajoute une règle dans lemeson.buildde ce répertoire pour l'installer au bon endroit.Je suis sûr qu'il y a des choses améliorables, mais c'est un très bon point de départ. Par contre faudra mettre sous licence GPLv3 or later. 😉
Ensuite comme on disait tous les deux plus haut, ce n'est absolument pas un
thumbnaileridéal, loin de là. Mais bon c'est sûr que c'est mieux que rien. 🤷Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: GIMP 3.2.2 est déjà là!
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
C'était la question originelle oui. Ensuite ça a dévié sur la spéc Thumbnails de Freedesktop (que GIMP prend en charge donc).
Ceci dit, il y a une petite erreur à mon avis: le but n'est pas d'appeler GIMP! Comme tu le notes toi-même pour ton
thumbnailerdarktable:Et le second gros problème, c'est que cela dépend de GIMP (ou de darktable, je suppose, dans le cas de ton
thumbnailerdarktable). Les gens veulent avoir unthumbnailerXCF qui puisse être léger, rapide mais aussi indépendant, et par exemple pourraient être leur propre paquet dans les dépôts Linux (sans dépendance au paquet GIMP). De sorte qu'on pourrait avoir des vignettes de fichiers XCF qui traînent dans son système sans forcément avoir GIMP installé. :-)C'est ce que je dis, ce serait idéal. Un petit binaire indépendant qui ne contiendrait que le code nécessaire pour charger un XCF et en faire le rendu, et qui serait bien plus rapide à lancer.
Ensuite — et c'est là où l'idée de la vignette embarquée prend tout son sens — si le XCF contient déjà des vignettes, on pourrait avoir un binaire qui n'a même pas besoin de comprendre l'entièreté du format XCF, juste d'en savoir assez pour extraire la vignette de son choix. Et ça ferait un thumbnailer vraiment rapide. :-)
Mais bon, ça sera probablement juste pour la prochaine version de XCF (qui est mon gros projet de GIMP 3.4).
Par exemple, typiquement une des parties qui peut prendre du temps au lancement de GIMP, c'est le chargement des plug-ins (au premier lancement après une mise-à-jour par exemple). Or avec les nouveaux calques-liens, sans les plug-ins de formats de fichier (autre que XCF), on ne peut pas regénérer le rendu d'un calque lien. Maintenant ce n'est pas très grave à l'heure actuelle car ces derniers contiennent leur dernier rendu dans le XCF. Sauf que justement on a des demandes pour ne même pas embarquer ce rendu (typiquement on a quelqu'un qui nous a dit traiter des images de plusieurs GiBs en mémoire, toutes dans le même XCF, avec quelques filtres dessus, et cette personne espérait que le fichier XCF serait lui-même très petits puisque ce sont juste des liens).
Ben si on implémente cette option, alors il faudrait aussi que notre
thumbnailerpuisse charger les plug-ins de prise en charge de formats de fichier.Ils le font aussi mais juste avec une autre perspective. Quant aux
thumbnailers, c'est encore juste une autre pièce du même puzzle.Idéalement tous les logiciels dans la chaîne à la fois de création, rendu ou lecture de fichiers devraient implémenter cette spéc, mais simplement chacun le fait avec une perspective un peu différente. Et tout cela se complète alors.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# préférer l'algo jpegli à l'encodage jpeg classique
Posté par orfenor . Évalué à 3 (+1/-0).
Question pour Jehan
(ça serait mieux dans le suivi de bugs et améliorations de Gimp, mais je pense que ça y est déjà et je ne l'ai pas trouvé).
Tu as relancé le mainteneur de Mozjpeg. Mais pourquoi ne pas plutôt intégrer Jpegli dans Gimp ? Jpegli c'est le nouvel algo de compression JPEG issu du labo suisse de Google. Il n'a pas d'options supplémentaires par rapport à l'ancien algo, mais savoir qu'il est utilisé permet une meilleure compression : parmi les options faciles, le curseur de compression peut descendre plus bas et le choix du Chroma subsampling a pas mal d'influence (en tests à mon petit niveau).
[^] # Re: préférer l'algo jpegli à l'encodage jpeg classique
Posté par BAud (site web personnel) . Évalué à 1 (+0/-1).
rouvrir une entrée fera qu'elle remontera ou qu'un doublon sera trouvé :-)
c'est ballot de ne pas avoir mis le bon lien : https://linuxfr.org/news/xl-converter-1-0-billet-d-humeur-et-plaidoyer ni de citer spécifiquement le point que tu veux mettre en avant, j'imagine que c'est :
qui est un peu léger en terme de justification technique :-) i2bp faisait mieux, bien avant !
[^] # Re: préférer l'algo jpegli à l'encodage jpeg classique
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+7/-0). 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 ]
# Qu'est-ce qui manque ?
Posté par Shunesburg69 . Évalué à 4 (+3/-0).
Salut à tous,
Qu'est-ce qui manque par rapport à PhotoShop ?
J'entends toujours les gens dire que Gimp n'est pas à la hauteur, que c'est pour les amateurs, mais personnellement, je le trouve bien super avancé et Pro.
Y a-t-il des vraiment des fonctionnalités qui lui manquerait, ou c'est juste les gens qui cherchent des excuses ?
[^] # Re: Qu'est-ce qui manque ?
Posté par Lutin . Évalué à 5 (+3/-0).
Parmi les gens qui disent ça, il y en a 1% qui veulent dire qu'ils sont plus habitués à Photoshop, et les 99 autres pour cent tentent juste de se convaincre qu'ils ont absolument besoin de Photoshop pour redimensionner une image (ce qui arrive une où deux fois par an les années fastes).
[^] # Re: Qu'est-ce qui manque ?
Posté par Ysabeau 🧶 (courriel, site web personnel, Mastodon) . Évalué à 4 (+1/-0).
Y'a de ça en effet. Dans la plupart des cas, pour rogner, redimensionner et ajuster les couleurs d'une photo, Gwenview (sur Linux, mais il doit y avoir des équivalents ailleurs) est tout à fait suffisant.
Je n’ai aucun avis sur systemd
[^] # Re: Qu'est-ce qui manque ?
Posté par Shunesburg69 . Évalué à 1 (+0/-0).
Je parlais de fonctionnalités manquantes, pas de choses déjà présentes depuis le début. Par exemple, niveaux calques, gestions des couleurs… des choses qui ont été mises récemment ou grandement améliorés. Manquent-ils encore des choses par rapport à la concurrence ou les efforts récents les ont entièrement été comblés ?
[^] # Re: Qu'est-ce qui manque ?
Posté par Psychofox (Mastodon) . Évalué à 4 (+1/-0).
Ce qui compte c'est qu'il convienne à ses utilisateurs, pas comment il se compare à d'autres outils.
Ça n'a pas de sens de demander si telle ou telle appli remplace telle autre, la majorité des utilisateurs n'utilisent qu'un spectre finalement assez réduit de fonctionnalitées et les différents logiciels, qu'ils soient proprios ou libres couvrent différemment tout ou parties de ces fonctionalités. L'imporant c'est de demander quel est le besoin de l'utilisateur.
[^] # Re: Qu'est-ce qui manque ?
Posté par Maderios . Évalué à 3 (+1/-0). Dernière modification le 01 avril 2026 à 15:33.
Depuis le départ (1987), Photoshop est axé sur la photographie, il a été créé par des photographes. Ensuite, son développement s'est fait en y associant des photographes, en tenant compte de leurs usages/besoins.
Gimp est arrivé plus tardivement (1995), il a été créé par des informaticiens, c'est un éditeur d'images plus généraliste mais il a l'avantage d'être libre.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.