URL: https://linuxfr.org/news/gimp-2-10-roule-au-gegl
Title: GIMP 2.10 roule au GEGL
Authors: Jehan
 Davy Defaud, antistress, BAud, ZeroHeure, teoB, bobble bubble, M5oul, jcr83, Nÿco, Yves Bourguignon, Anonyme, bubar🦥, palm123, Benoît Sibaud, Dareg, gusterhack, Nicolas Boulay, Frédéric Massot, Sylvhem, nizan666, daissi, n0wic, GSurrel, Ontologia, claudex, err404, patrick_g, reynum, Xavier Teyssier, fravashyo, Narann, esdeem, Lucas, guitou, Matthieu Moy, RyDroid, Stéphane Aulery, gabu, Thomas Debesse, olivierweb et Laurent Pointecouteau
Date: 2014年04月16日T13:18:17+02:00
License: CC By-SA
Tags: gimp, gegl, graphisme, gtk, sortie_version, debian et fedora
Score: 168
Après six années de développement, une nouvelle version stable de [GIMP](http://gimp.org) est sortie le 27 avril 2018 vers 17 h. C’est un jalon important dans l’évolution de cet outil de création d’images, à de nombreux égards...
![Wilber, la mascotte de GIMP](https://upload.wikimedia.org/wikipedia/commons/b/be/Wilber-gimp.png)
En particulier, cette sortie se démarque par une refonte totale du moteur de traitement d’image, basé désormais entièrement sur [[GEGL]], comme nous l’évoquerons dans la deuxième partie de la dépêche...
Citons aussi :
 
- l’amélioration des fonctions de peinture numérique, notamment avec la possibilité d’utiliser les brosses MyPaint, la peinture symétrique, la rotation et inversion du canevas, etc. ;
- la gestion des métadonnées ;
- de nouveaux thèmes, notamment un thème sombre par défaut, un nouvel ensemble d’icônes symboliques, ainsi qu’un ensemble d’icônes couleur vectorielles ;
- l’ajout de plusieurs nouveaux outils — notamment en résultat de trois années de [Google Summer of Code](https://fr.wikipedia.org/wiki/Google_Summer_of_Code) ;
- une palette des formats de fichiers pris en charge plus large et plus complète...
----
[Notes de version sur le site officiel de GIMP](http://www.gimp.org/release-notes/gimp-2.10.html)
[Téléchargement direct (flatpak)](https://flathub.org/apps/details/org.gimp.GIMP)
[Journal des modifications](https://git.gnome.org/browse/gimp/tree/NEWS.pre-2-10)
[En route vers GIMP 2.10 (nouveautés en développement, LinuxFr.org, décembre 2017)](http://linuxfr.org/news/en-route-vers-gimp-2-10)
[GIMP 2.8 est sorti : une fenêtre unique ! (dépêche de la version précédente, mai 2012)](http://linuxfr.org/news/gimp-2-8-est-sorti-une-fenetre-unique)
[GEGL 0.3.0 et babl 0.1.12 sont de sortie (LinuxFr.org, juin 2015)](https://linuxfr.org/news/gegl-0-3-0-et-babl-0-1-12-sont-de-sortie)
[Entretien avec Jehan, développeur GIMP LinuxFr.org, juin 2015)](https://linuxfr.org/news/entretien-avec-jehan-developpeur-gimp)
[Bilan des projets GIMP et GEGL en 2017](https://www.gimp.org/news/2017/12/31/gimp-and-gegl-in-2017/)
[Bilan des projets GIMP et GEGL en 2016](https://www.gimp.org/news/2017/01/15/2016-in-review/)
[Bilan des projets GIMP et GEGL en 2015](http://www.gimp.org/news/2015/12/31/2015-report/)
[Bilan des projets GIMP et GEGL en 2014](https://mail.gnome.org/archives/gimp-user-list/2015-January/msg00012.html)
----
# Conséquences directes de GEGL #
De loin, [GEGL](http://gegl.org) est **la** nouveauté majeure, qui explique [la longue attente](https://www.openhub.net/p/gimp/) depuis la sortie de GIMP 2.8. Cette bibliothèque, [en cours de développement depuis 2000](https://git.gnome.org/browse/gegl/commit/?id=11d77a8be7f620a5e77a648fa94f01259329a5ee), est née du projet GIMP dans l’optique de remplacer un jour son moteur. Malgré des débuts d’intégration dès GIMP 2.6 (outil GEGL expérimental), puis 2.8 (projection de calques utilisant GEGL), c’est seulement après la sortie de la version 2.8 que son intégration a été accélérée.
La majeure partie du code existant de traitement d’image a donc été retirée en faveur de l’usage de cette bibliothèque externe. Cette séparation signifie que GIMP est désormais davantage une interface graphique autour de GEGL. Une majeure partie des traitements sur les pixels est faite si possible à l’aide de cette bibliothèque (certaines fonctionnalités, telles que la peinture, sont encore implémentées directement dans GIMP pour des raisons de performance) et est donc utilisable par d’autres projets, ce qui est extrêmement intéressant pour tout le monde.
Plusieurs projets utilisant GEGL comme base sont ainsi déjà en cours de développement, fonctionnalité ou _[back‐end](https://fr.wikipedia.org/wiki/Backend)_ supplémentaire. Nous en avions parlé lors de [la sortie de GEGL 0.3.0](https://linuxfr.org/news/gegl-0-3-0-et-babl-0-1-12-sont-de-sortie) ou encore lors de la [sortie de la version 3.20 de l’environnement de bureau GNOME et de son application intégrée nommée Photos](https://linuxfr.org/news/parution-de-gnome-3-20-delhi#photos).
## Prévisualisation sur canevas ##
Désormais, le résultat d’un traitement (par exemple, un changement de luminosité, de contraste ou un filtre ; bref, presque tout traitement passant par une boîte de dialogue) est directement visible sur l’image avant de l’appliquer, ce qui rend la prévisualisation beaucoup plus pratique.
 
Il est aussi possible de scinder la vue horizontalement ou verticalement, avec une partie prévisualisant l’effet et une autre partie affichant le canevas original, comme un « rideau » de prévisualisation qui peut être déplacé à la souris.
 
![Rideau de prévisualisation](https://lut.im/9FmgaQCgt0/cQWyaiOpkV7TgpGf.png)
## Traitement de très grandes images ##
Un des points forts de GEGL est sa gestion intelligente des tampons, permettant à l’utilisateur d’allouer une partie seulement de sa mémoire à GIMP, mais également de travailler sur des images plus grandes que la mémoire disponible. Un tampon GEGL est une matrice de dalles, chacune pouvant avoir un stockage différent en arrière-plan.
## Haute précision des couleurs ##
Une autre fonctionnalité majeure apportée par GEGL est sa [prise en charge de diverses profondeurs de couleur](http://libregraphicsworld.org/blog/entry/gimp-2.8-released-next-version-to-get-high-bit-depth-precision) dont GIMP tire désormais profit. En particulier, cela signifie que GIMP n’est plus limité à travailler sur des images à 8 bits par composante couleur. GIMP peut désormais travailler sur des images 8, 16 ou 32 bits, en nombre entier ou flottant (le format natif de GEGL est maintenant en _32 bits flottants_), et avec codage linéaire ou correction gamma, au choix de l’utilisateur depuis le menu _Image_ → _Précision_.
## Accélération : OpenCL et multi‐thread ##
À travers l’usage de GEGL, GIMP sait désormais tirer parti d’[[OpenCL]], ce qui lui permet d’utiliser bien mieux les possibilités d’un ordinateur moderne et de ses multiples processeurs (processeur central, processeur graphique, [circuit logique programmable](https://fr.wikipedia.org/wiki/Circuit_logique_programmable), etc.).
 
Au fil des années cependant, nous avons pu rencontrer des plantages (venant de pilotes graphiques bogués), des « _[glitches](https://fr.wikipedia.org/wiki/Glitch)_ » graphiques (notamment avec les pilotes NVIDIA), ou des implémentations peu performantes (en particulier avec [Beignet](https://www.freedesktop.org/wiki/Software/Beignet/), pour les cartes Intel). Par conséquent, OpenCL est désactivé par défaut (l’option peut être activée dans les préférences).
 
En revanche, un important travail a été fait pour rendre les opérations GEGL multi‐tâches afin d’utiliser au mieux les processeurs modernes, comme les multi‐cœurs. Dernièrement, GIMP lui‐même est devenu multi‐tâches, ce qui a été utilisé notamment pour séparer le traitement de la peinture et l’affichage.
# Prise en charge améliorée de formats d’image #
Puisque la gestion des images passe désormais entièrement par GEGL, cela signifie aussi que GIMP peut profiter davantage de certaines fonctionnalités avancées, en particulier de la possibilité qu’ont certains formats de stocker aussi différentes profondeurs de couleur. Ainsi, GIMP peut désormais charger et sauvegarder des PNG 8 ou 16 bits, du TIFF ou du PSD jusqu’à 32 bits, et du FITS jusqu’à 64 bits par composante.
 
Les gestions des formats [[OpenEXR]], [RGBE](https://en.wikipedia.org/wiki/RGBE_image_format) (pour l’[[imagerie à grande gamme dynamique]] _(HDR)_), [WebP](https://fr.m.wikipedia.org/wiki/WebP) (notamment avec les fonctionnalités d’animation) et [HGT](https://fr.wikipedia.org/wiki/Shuttle_Radar_Topography_Mission#Format_des_fichiers) ont aussi été ajoutées.
 
De nombreux formats d’images ont également été améliorés. On peut citer le format PSD de Photoshop, dont la prise en charge est devenue bien meilleure (même si toujours incomplète).
# Prise en charge des métadonnées #
GIMP a amélioré sa [prise en charge des métadonnées](http://libregraphicsworld.org/blog/entry/gimp-gets-advanced-exif-xmp-iptc-metadata-support) qui n’étaient pas gérables dans la version précédente, en utilisant [gexiv2](https://wiki.gnome.org/Projects/gexiv2), une bibliothèque de liaison (_wrapper_) GObject autour de la bibliothèque de gestion des métadonnées [Exiv2](http://www.exiv2.org/). Les métadonnées prises en charge par Exiv2 sont à ce jour les standards [EXIF](https://fr.wikipedia.org/wiki/Exchangeable_image_file_format "Exchangeable image file format"), [IPTC](https://fr.wikipedia.org/wiki/IPTC_Information_Interchange_Model) et [XMP](https://fr.wikipedia.org/wiki/Extensible_Metadata_Platform "Extensible Metadata Platform") :
 
* les métadonnées au format EXIF contiennent notamment des données techniques sur les conditions de prise de vue : date, heure, coordonnées GPS, réglages de l’appareil (ouverture, temps de pose, etc.), mais aussi des informations sur le matériel utilisé ;
* les métadonnées au format IPTC ou à celui, plus récent, XMP, contiennent des informations plus génériques relatives à l’image en tant que médium d’information, comme une description, un titre, un lieu (sous forme compréhensible par l’humain, soit la ville, le pays...), une licence d’utilisation et un copyright, une citation de sources, etc.
 
_gexiv2_ est devenu un projet GNOME à l’occasion de son intégration dans GIMP, lui donnant une visibilité et une pérennité accrue (voir [ce billet retraçant l’histoire de cette bibliothèque](http://blogs.gnome.org/jnelson/2013/11/06/gimp-meets-gexiv2/)).
 
Puisque les métadonnées peuvent contenir des données privées parfois très sensibles (telles que nom, adresse de courriel et même coordonnées GPS !), il est possible de ne pas les exporter et un choix par défaut peut être configuré dans les préférences (lequel peut être outrepassé par format ou simplement par fichier).
# Accès aux fichiers par GIO #
Les accès aux fichiers ont été tous portés vers l’interface abstraite et de haut niveau [GIO](https://developer.gnome.org/gio/), plutôt que les interfaces bas niveau de traitement de fichier local.
 
Cela permet de ne plus considérer un fichier comme nécessairement local, surtout dans un monde dorénavant fortement connecté où il devient de plus en plus courant de vouloir travailler sur des fichiers distants. GIO permet ainsi, par exemple, d’ouvrir une image sur un serveur FTP distant ou sur votre _cloud_ (OwnCloud...) de manière transparente, sans avoir à transférer l’image au préalable (et même à la sauver si l’accès distant permet aussi l’écriture).
# Compatibilité descendante #
## Gestion de LZMA2 et compression interne DEFLATE ##
GIMP 2.8 proposait de compresser ses images sous les formats hybrides `.xcf.gz` (gzip) et `.xcf.bz2` (bzip2), deux des formats de compression les plus répandus du monde libre. La version 2.10 apporte la compression [LZMA2](http://fr.wikipedia.org/wiki/LZMA) (`.xcf.xz`), bien plus efficace, qui fait son chemin pour remplacer les deux précédents algorithmes un peu partout, et les dépendances de compression sont devenues obligatoires (tout utilisateur de GIMP 2.10 ou supérieur pourra désormais ouvrir vos fichiers `.xcf.(gz|bz2|xz)`). Il s’agit cependant seulement de compression du fichier complet comme un conteneur.
 
Il faut savoir que les données sont également compressées au niveau des dalles. Jusqu’à maintenant, l’algorithme basique [RLE](http://en.wikipedia.org/wiki/Run-length_encoding "Run‐length encoding") était utilisé, GIMP 2.10 peut le remplacer par DEFLATE de [zlib](http://en.wikipedia.org/wiki/Zlib), permettant des fichiers bien plus petits. Cette compression n’est cependant pas utilisée par défaut, car plus lente, mais reste sélectionnable au moment de sauvegarder son fichier.
 
Par ailleurs, la compression au niveau des dalles peut permettre d’outrepasser certaines limitations (liées au système d’exploitation ou au système de fichiers par exemple) dans le traitement de documents très volumineux.
## Interface applicative ##
GIMP n’est pas seulement un puissant logiciel de traitement et de création d’images. C’est aussi une plate‐forme évoluée pour les développeurs de greffons.
 
GIMP 2.10 continue dans la lignée de la version 2. Utilisant une API stable, tout greffon existant devrait donc continuer de fonctionner. Néanmoins, les interfaces historiques de traitement de pixels de l’API de GIMP seront déconseillées au profit du traitement par l’API GEGL. Les développeurs tiers de filtres sont ainsi encouragés à convertir leurs greffons sous la forme d’opérations GEGL, ce qui leur ouvrira également le monde de l’édition non destructrice, de la haute profondeur de couleur, de la prévisualisation instantanée, ainsi que de nombreux autres avantages inhérents à GEGL.
# Outils #
## Partage de brosses avec MyPaint ##
MyPaint a un système de brosses différent de celui de GIMP, avec ses avantages et inconvénients. Dans tous les cas, il est intéressant pour les utilisateurs de GIMP de pouvoir utiliser ce système de brosses alternatif. C’est pourquoi il a été décidé d’intégrer les brosses de MyPaint dans GIMP. C’est probablement un des changements majeurs pour de nombreux peintres qui préféraient MyPaint à GIMP.
![brosses MyPaint dans GIMP](https://lh3.googleusercontent.com/-jh_q8r5RMV4/VngDZltQFqI/AAAAAAAABeg/wxwxeeddmg0/w868-h557-no/GIMP-2.9-with-libmypaint-osx.png)
_MyPaint_ avait déjà sa bibliothèque [_libmypaint_](https://github.com/mypaint/libmypaint) et a clairement fait la [séparation avec son dépôt principal en avril 2014](https://github.com/mypaint/mypaint/commit/f8d48ad9b91866eab1fa5fe6946f0ae2354534fe) pour mettre en avant ce genre de possibilité avec son moteur de brosses.
## Outil de transformation unifié ##
Conséquence du Google Summer of Code 2012 ([wiki](http://wiki.gimp.org/index.php/Hacking:GSOC_Archive#Projects_in_GSoC_2012)), cet outil permet le redimensionnement, le déplacement, la rotation et la perspective, le tout dans un seul outil.
![Outil de transformation unifié](https://lh6.googleusercontent.com/tg-F48J3m4kO2PeLKpmlPukuoAo_fpx9EH0I-QDhVTQ=w912-h592)
 
Notez que les anciens outils de transformation, pour chacune de ces fonctionnalités séparées, n’ont pas été supprimés à cette occasion. En effet, le nouvel outil est basé sur un concept de transformation au jugé uniquement, et l’utilisation des outils dédiés est toujours nécessaire lorsque vous souhaitez effectuer une transformation précise, avec des chiffres (angle, nombre de pixels, etc.). Il s’agit d’un choix du concepteur Peter Sikking ([section GIMP de son journal Web](http://blog.mmiworks.net/search/label/GIMP)), qui a écrit la spécification de l’outil.
## Outil de transformation « Warp » ##
Un autre résultat du Google Summer of Code, 2011 cette fois ([wiki](http://wiki.gimp.org/index.php/Hacking:GSOC_Archive#Projects_in_GSoC_2011)), l’outil de « warp » ([démonstration en vidéo](http://www.youtube.com/watch?v=RakpVMxl2Hc), [billet du développeur](http://pellelatarte.fr/2011/07/gimp-warp-tool-cest-la-mi-parcours/)) permet de « tordre » l’image directement sur le canevas. Cette fonctionnalité existait en fait déjà sous la forme du greffon iWarp, qui a maintenant été rendu obsolète en faveur de cet outil. En effet, le greffon ne permettait pas de travailler aisément sur une image, contrairement à un outil qui donne la possibilité de voir directement un effet sur le canevas et d’éditer ou annuler à chaque étape.
 
Extrait d’une [vidéo de démo de peinture en miroir](https://youtu.be/osSiETyae5c) (vers 2 min 45) montrant une utilisation de l’outil Warp pour simuler l’eau (note : l’interface est désormais bien différente depuis cette vidéo) :
![Outil de transformation « Warp » de GIMP](https://lut.im/q9cOMj1Yd1/wCRM3HzFuVLN0zN9.gif)
## Outil de transformation par poignée ##
Un autre outil de transformation a été intégré : l’outil de transformation par poignée, qui permet de placer des poignées librement sur le canevas et de transformer l’image en fonction du nombre de poignées. Une poignée permet de déplacer l’image. Deux poignées permettent d’exécuter une rotation ou un redimensionnement en conservant les proportions. Trois poignées permettent un cisaillement ou un redimensionnement sans conserver les proportions. Enfin, quatre poignées permettent un changement de perspective. [Une vidéo de démonstration](https://vimeo.com/82585231) est disponible.
Les personnes habituées aux interfaces tactiles pourront se retrouver en terrain familier.
## Outil de sélection de premier plan ##
L’outil de **sélection de premier plan** manquait de précision et n’avait notamment pas de notion de sélection partielle d’un pixel, par exemple dans le cas de fibres (cheveux...) ou de textures semi‐transparentes, auquel cas un même pixel peut contenir partiellement du premier et de l’arrière‐plan.
 
Le nouvel outil est désormais basé sur des algorithmes de [_matting_](http://en.wikipedia.org/wiki/Compositing#Matting) théoriquement plus évolués, portés sur GEGL.
## Peinture en miroir, dalles et rotation ##
Il est désormais possible de peindre en miroir dans GIMP, relativement à un axe horizontal, vertical et à un point. Il est aussi possible de peindre en « dalles », copiant un trait en une série similaire à intervalles réguliers (translation) ou encore en rotations multiples autour d’un centre (style « mandalas »).
 
![Peinture en miroir](https://lut.im/KC5RvM3tSV/fqFjZjBJjiArnMfX.gif)
 
Cette fonctionnalité est disponible pour tous les outils de peinture de GIMP. Plus de détails et une vidéo disponible sur un [billet de journal de bord](http://girinstud.io/news/2015/03/peinture-symmetrique-dans-gimp-prete/). L’image animée au‐dessus est extraite de ladite vidéo, dessinée par l’artiste [Aryeom](http://girinstud.io).
## Outils encore dans le bac à sable ##
Deux outils résultant de *Google Summer of Code* (2011 et 2013) n’ont malheureusement pas pu faire partie de la version stable. Il s’agit de l’outil de clonage sans raccord ([démonstration en vidéo](http://www.youtube.com/watch?v=pqVMt-ReaDc), [section correspondante du journal du développeur](http://lightningismyname.blogspot.fr/search/label/seamless-clone)) et de l’outil de déformation N‐Point ([démonstration en vidéo](http://www.youtube.com/watch?v=OmOyQyuiO_E), [billet du développeur](http://korek.name/web/blog/n-point-image-deformation/299)). Ces deux outils sont en effet dans le bac à sable à cause de leur état non satisfaisant, soit extrêmement lent, voire bogué ou conduisant à des plantages. Les développeurs souhaitant contribuer pour finaliser ces outils sont les bienvenus !
 
Pour tester ces outils, lancez GIMP avec l’option `--show-playground`, puis cochez les options dans les préférences. Il convient de rappeler que ces outils ne sont pas conseillés pour de la production et peuvent même faire planter GIMP, vous faisant ainsi perdre des données non sauvegardées.
# Interface graphique #
## Tableau de bord
Un tableau de bord fait son apparition permettant de suivre l’évolution de l’utilisation du processeur, le cache et l’espace d’échange mémoire (_swap_) occupé.
## Mode fenêtre unique par défaut ##
Si GIMP 2.8 avait rajouté le mode fenêtre unique, celui‐ci restait une option à sélectionner, ce que beaucoup d’utilisateurs occasionnels ne savaient pas et n’utilisaient donc jamais. Ce mode étant finalement d’autant plus utile pour ces utilisateurs, afin de ne pas les perturber, il s’agit donc du nouveau mode de fenêtrage par défaut.
 
Le mode multi‐fenêtre existe toujours et est désormais activable comme l’était auparavant le mode fenêtre unique.
## Verrouillage des transformations ##
Les calques peuvent désormais être verrouillés pour être préservés contre toute transformation accidentelle (déplacement, rotation, etc.).
## Rotation et retournement du canevas ##
Il est désormais possible de [faire pivoter le canevas](http://libregraphicsworld.org/blog/entry/gimp-gets-canvas-rotation), ainsi que de le faire se retourner horizontalement ou verticalement. Il ne s’agit pas d’opérations sur les pixels (donc notamment pas d’une rotation d’image ni d’un miroir), mais uniquement d’une rotation d’affichage. Certains peintres utilisent en effet la rotation pour peindre avec leur tablette en diagonale (comme certains écrivent sur une feuille en diagonale) tout en orientant l’image sur l’écran à l’identique, ce qui permet d’atteindre plus aisément certaines zones du canevas.
 
Le retournement est également beaucoup utilisé par les peintres pour vérifier les problèmes de perspective, de symétrie et de proportions. Dessiner trop longtemps sur le même dessin entraîne en effet parfois une habitude de l’esprit, qui ne se rend plus compte de certaines erreurs autrement évidentes. Retourner régulièrement le canevas permet aux peintres numériques de « rafraîchir » leur cerveau en chamboulant son attente comme si une nouvelle image lui était soumise et, ainsi, de découvrir et corriger les erreurs.
## Thèmes d’icônes et nouveaux thèmes d’icônes symboliques ##
Les icônes ne sont désormais plus inclues dans les thèmes, mais sont fournies dans des thèmes d’icônes, indépendamment. GIMP sera désormais fourni avec des thèmes d’icônes symboliques et un thème d’icônes vectorielles couleur, en addition du thème couleur historique.
 
![Thème d’icônes symboliques de GIMP](https://bug759673.bugzilla-attachments.gnome.org/attachment.cgi?id=318260)
 
Cela fait suite aux efforts du projet GNOME pour proposer des [alternatives symboliques](https://wiki.gnome.org/Design/HIG/IconsAndArtwork) aux icônes couleur classiques.
## Tailles d’icônes ##
Les icônes des outils étaient de 16 <span class="naked_sign">×</span><span class="naked_aural">ばつ</span> 16 pixels et 22 <span class="naked_sign">×</span><span class="naked_aural">ばつ</span> 22 pixels. Nous utilisons seulement des multiples de 16 et 24 pour les nouvelles icônes, suivant ainsi l’[évolution de GNOME et GTK+](https://developer.gnome.org/gtk3/stable/gtk3-Themeable-Stock-Images.html#GtkIconSize).
 
En outre, plutôt que de proposer un thème particulier « petites icônes » (thème _Small_ qui disparaît), il devient désormais possible d’outrepasser les tailles des icônes de n’importe quel thème (officiel, comme personnalisé) dans les préférences, pour peu que le thème d’icônes propose une taille adéquate (ou une version vectorielle). Cela permettra notamment d’utiliser GIMP sur des écrans à haute densité de pixels (HiDPI).
 
![Redéfinir tailles d’icônes](https://lut.im/8vefASvhIV/cUA6R8Am0spq6sDw.png)
## Nouveaux thèmes ##
Trois nouveaux thèmes font leur apparition, dans diverses nuances de gris (un thème clair, un thème gris intermédiaire, et un thème sombre), en plus du thème _Système_.
![Nouveaux thèmes](https://www.gimp.org/news/2018/04/17/gimp-2-10-0-rc2-released/gimp-2-10-rc-2-themes.png)
## Recherches d’actions ##
GIMP possède désormais une recherche‐et‐activation des actions. Par défaut, l’entrée de recherche correspond à `/`. Cela permet, par exemple, de rechercher des filtres par mot‐clef présent dans le nom ou la description du filtre, plutôt que par les menus et sous‐menus. Mais cela ne se limite pas aux filtres, ni même aux menus. Toute action présente dans GIMP (c’est‐à‐dire une opération à laquelle on peut assigner un raccourci clavier) peut être recherchée et activée par cette nouvelle fonctionnalité.
![Recherche d’action](https://lut.im/fLrMsq8a/ajv7ksI6)
 
On peut ainsi rechercher des outils ou fonctions disponibles, mais présents dans aucun menu. Cela pondère notamment le fait qu’il y ait plus d’actions que de raccourcis techniquement possibles (sans compter la mémorisation quasi‐impossible si l’on devait se rappeler un raccourci par action !). Et puis, qui n’avait jamais cherché une fonctionnalité dans les menus qu’on avait déjà utilisé des semaines auparavant, mais qu’on est incapable de retrouver en moins de dix minutes de tripatouillage dans les menus et sous‐menus ?
 
Notons que l’outil prend en compte la localisation (on peut ainsi chercher dans la langue de l’interface, par exemple en français).
## Position des onglets modifiable ##
Il est désormais possible de placer la barre des onglets, dans le mode à fenêtre unique, de n’importe quel côté (haut, bas, gauche ou droite).
 
![Capture d’écran avec onglets à gauche](https://lut.im/3pqR3H2HXE/Sq4pe29uoBxTcyEZ.png)
# Traitement d’images en ligne de commande #
Tout d’abord, il est à noter que GIMP n’est pas forcément adapté à du traitement d’image en ligne de commande, en particulier sur de multiples images. Il existe des logiciels véritablement dédiés à ce type de traitement dit « _batch_ », comme [ImageMagick](http://www.imagemagick.org/script/index.php), lesquels pourraient être plus pratiques d’utilisation et aussi plus efficaces.
Plus proche de GIMP, [G’MIC](http://gmic.eu/) possède aussi une interface en ligne de commande, et l’on peut même utiliser tout simplement [GEGL](http://gegl.org), qui est doté d’un binaire capable d’enchaîner des opérations sur des images directement depuis la ligne de commande. Ainsi, inverser les couleurs d’une image PNG avec GEGL puis convertir en JPEG est aussi simple que :
 
 ```bash
 $ gegl source.png -o dest.jpg -- gegl:invert-gamma
 ```
Néanmoins, de nombreuses personnes continuent à utiliser GIMP pour du traitement d’image en ligne de commande, notamment par habitude ou par connaissance de l’API de GIMP (la même que pour les greffons). Donc, pour ne pas oublier ces personnes, deux fonctionnalités petites mais très attendues ont été ajoutées :
 
* lorsqu’une instance GIMP tourne déjà, les commandes _batch_ sont exécutées sur cette instance existante ;
* une nouvelle macro `with-files` permet désormais d’exécuter une même suite de commandes sur une liste d’images. Ainsi, voici comment inverser les couleurs de toutes les images PNG contenues dans un répertoire donné :
 
 ```bash
 $ gimp -i -b '(with-files "*.png" (gimp-invert layer) \
 (gimp-file-save 1 image layer \
 (string-append basename ".jpg") \
 (string-append basename ".jpg") ))'
 ```
# Peinture #
## Historique des couleurs utilisées ##
Il existe désormais une palette automatique des couleurs récemment utilisées. En outre, le dock des couleurs d’avant plan et d’arrière‐plan affiche les douze couleurs les plus récentes de ladite palette.
![Historique des couleurs](https://lut.im/j6EEjpWMNx/SnfYwvsIIQQaRxvk.gif)
## Nouveaux modes de fusion des calques ##
Historiquement, GIMP travaillait en espace de couleur perceptuel, ce qui est en train de changer grâce à la haute profondeur de couleur. Pour toute profondeur plus grande que 8 bits par canal, travailler en espace linéaire est bien plus efficace. Nous avons donc créé une nouvelle collection de modes en espace linéaire. De nombreux modes de calque ont ainsi été nouvellement implémentés.
 
Bien entendu, toute image XCF d’une version précédente sera parfaitement migrée. C’est‐à‐dire que tout ancien XCF aura le rendu attendu, une fois chargé dans une version de GIMP, et ce, à jamais (si un XCF à un rendu différent, alors cela est à considérer comme un bogue).
## Lier la taille de la brosse au zoom ##
Une nouvelle option est disponible pour tout outil utilisant le moteur de brosses de GIMP : il est désormais possible de lier la taille de la brosse au niveau de zoom (« _Lock brush size to zoom_ »), et pas uniquement à sa taille en pixels.
Ainsi, en zoomant davantage, votre brosse rapetissera d’autant, et inversement, de sorte qu’elle aura toujours la même taille sur l’écran (mais pas la même taille en pixel sur le canevas).
# Gestion des couleurs #
GIMP 2.10 apporte de nombreuses améliorations sur la gestion des couleurs. Notamment, GIMP est passé du moteur [LCMS](http://www.littlecms.com/) v1 à v2, ajoutant au passage la prise en charge de [ICC v4](http://www.color.org/icc_specs2.xalter), mais aussi une meilleure fidélité de conversion entre des profondeurs de couleur différentes. Nous avons en fait même déjà commencé le travail pour remplacer LCMS par _babl_, notamment pour la conversion entre profils de couleur quand cela est possible. La librairie _babl_ est en effet extrêmement plus rapide que LCMS.
 
GIMP gérait historiquement les profils de couleur à l’aide d’un module. Celui‐ci a été retiré en faveur d’une implémentation interne et complète, interagissant sur l’ensemble de l’interface. Par exemple, il y a maintenant une prise en charge de la copie d’une image sur une autre avec des profils différents, impliquant une conversion pour garder la fidélité des couleurs.
 
Les images en niveau de gris peuvent désormais aussi être munies d’un profil de couleur, et plus seulement les images RVB.
 
Enfin, l’interaction utilisateur avec les profils a été revue, rendant la gestion de profils sur les images (assignation, suppression, conversion...) plus simple et compréhensible.
![Métadonnées d’un profil de couleur visible dans le sélecteur de fichiers](http://www.gimp.org/news/images/gimp-2-9-2/2015-11-27-icc-metadata.png)
# Emplacement standardisé des fichiers de configuration #
Les fichiers de configuration ont été déplacés dans une arborescence plus appropriée sur chaque plate‐forme :
 
* Windows : `%APPDATA%/GIMP/{GIMP_APP_VERSION}` ;
* macOS : `NSApplicationSupportDirectory/GIMP/{GIMP_APP_VERSION}` ;
* tous les autres UNIX : `$XDG_CONFIG_HOME/GIMP/{GIMP_APP_VERSION}`.
 
Il est à noter sur nos systèmes d’exploitation libres en particulier, que GIMP adopte désormais la spécification [XDG](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html "X Desktop Group — freedesktop.org"). Cependant, seul `$XDG_CONFIG_HOME` est pris en charge pour le moment. En particulier, nous ne séparons pas avec `$XDG_CACHE_HOME` (en revanche, **GEGL** utilise ce dernier), ni `$XDG_DATA_HOME`.
 
Les anciens fichiers de configuration seront immédiatement migrés, et convertis si nécessaire (ce dernier point étant aussi une nouveauté), lors du premier lancement de GIMP 2.10.
# Multi‐plate‐forme #
GIMP est multi‐plate‐forme et, bien que l’on sache qu’il tourne aussi sous BSD ou Solaris, par exemple, les plates‐formes qui connaissent le plus de succès sont bien entendu GNU/Linux, Windows et macOS. GNU/Linux a le moins de problèmes, car quasiment tous les développeurs l’utilisent comme système d’exploitation principal.
 
macOS rencontre un peu d’amour de la la part contributeurs par intermittence. Cela fait déjà un moment que GIMP fonctionne avec une interface graphique native. Il faut pour cela compiler GTK+ avec le [quartz](http://www.gtk.org/download/macos.php) en arrière‐plan à la place de X11 (surtout que X11 n’est plus fourni par défaut avec macOS). L’intégration est désormais portée plus loin avec des migrations d’API [Carbon vers Cocoa](https://developer.apple.com/library/mac/documentation/porting/conceptual/portingunix/environments/environments.html), ainsi que des changements d’interface graphique pour suivre les règles de macOS (notamment au niveau menu, barre des tâches, etc.).
 
Windows est toujours le vilain petit canard malheureusement, bien qu’il s’agisse probablement de la masse la plus importante des utilisateurs. Un [appel à l’aide de développeurs Windows](http://www.gimp.org/news/2012/07/25/we-are-looking-for-windows-developers/) avait d’ailleurs été lancé, il y a quelques années, sans grand succès. L’appel tient toujours.
# Et après ? #
## GIMP 3.0 ##
GIMP 3.0, la version majeure qui succédera à 2.10, sera aussi la promesse d’un futur radieux. Il s’agira encore une fois d’une refonte en profondeur. Si GIMP 2.10 refondait le moteur avec GEGL, GIMP 3.0 refondra l’interface graphique avec GTK+ 3.0.
Notons que la migration directe à GTK+ 4 a aussi été évoquée, bien que rien n’ait été formellement décidé à ce sujet pour l’instant.
Qu’est‐ce qu’une migration à GTK+ 3.0 apporterait ?
### Meilleure prise en charge des dispositifs de pointage ###
Les utilisateurs avancés utilisent souvent des dispositifs de pointage particuliers, comme les tablettes graphiques. GTK+ 2 avait une prise en charge assez aléatoire, surtout sous Windows où beaucoup de cas de tablettes non fonctionnelles nous étaient rapportées. Cela devrait être beaucoup mieux avec GTK+ 3.
 
Le branchement à chaud de périphériques USB, parfois chaotique, a été amélioré avec XInput 2. Et, bien sûr, les fonctionnalités digitales devraient pouvoir être implémentées bien plus facilement (zoom ou rotation du canevas en glissant les doigts, etc.).
### Gestion des très hautes densités d’affichage ###
De plus en plus de gens, en particulier parmi les professionnels de l’image, travaillent avec des écrans à très haute résolution ou très haute densité de pixels (HiDPI, Retina display...). Un travail a été fait sur GIMP 2.10, notamment en auto‐détectant la densité de l’écran et en permettant de configurer des icônes de grande taille. Mais ces améliorations restent superficielles, tenant plus de la rustine que de la prise en charge en profondeur.
 
[GIMP 3.0](https://bugzilla.gnome.org/show_bug.cgi?id=725263) devrait bien mieux prendre en charge de tels écrans et permettre aux gens de travailler efficacement avec une telle configuration.
### Wayland ###
GDK a un _back‐end_ Wayland disponible pour GTK+ 3. GIMP pourra donc devenir une application native Wayland. Wayland pourrait d’ailleurs apporter de nouveaux usages, tels que le dessin multi‐pointeur, ainsi que le lancement d’actions par les boutons des tablettes graphiques.
### Thèmes améliorés ###
Les thèmes GTK+ 3 sont de type « CSS » et permettent notamment des variantes de thèmes (comme les variantes obscures). Cela sera beaucoup plus propre et standard que de créer de nouveaux thèmes à l’infini.
### Contributions accrues à GTK+ ###
L’un des principaux problèmes de l’utilisation de GTK+ 2 est que celui‐ci ne peut plus évoluer. GTK+ 2 accepte des corrections de bogues, mais pas de nouvelles fonctionnalités. C’est donc un blocage majeur pour l’évolution de GIMP dès que nous souhaitons une fonctionnalité qui touche la bibliothèque graphique (_toolkit_).
 
Le passage à GTK+ 3 signifie donc que les évolutions d’interface seront enfin libérées, puisqu’il sera désormais permis de contribuer des fonctionnalités de fond à GTK+ au besoin. Et réciproquement, cela signifie que GTK+ pourra à nouveau profiter du développement de GIMP, puisque nos contributions à GTK+ étaient forcément limitées.
## Traitement d’image non destructif ##
Nous expliquions déjà dans la [nouvelle sur GEGL](https://linuxfr.org/news/gegl-0-3-0-et-babl-0-1-12-sont-de-sortie) que le traitement en graphe signifie que le **traitement d’image non destructif** sera bientôt possible. Il ne sera plus question d’appliquer un effet, puis de voir, annuler, puis le refaire avec des paramètres différents, et ainsi de suite. Vous pourrez appliquer un effet, puis, plus tard, simplement en changer les paramètres. Vous pourrez même supprimer l’effet et retrouver l’image originelle.
 
Malheureusement, cela n’est pas présent dans GIMP 2.10 car l’interface graphique n’a pas encore été spécifiée. Le traitement d’image est donc de fait toujours destructif, pour le moment. C’est cependant une des futures étapes majeures de GIMP, actuellement prévu pour GIMP 3.2, bien que cela puisse arriver avant (ou après) en fonction des priorités des contributeurs.
## Amélioration globale de l’interface ##
J’ai récemment créé une [liste de discussion sur l’interface graphique](https://mail.gnome.org/mailman/listinfo/gimp-gui-list) de GIMP, et repris en main nos discussions et spécifications sur le sujet, notamment autour du [wiki associé](http://gui.gimp.org/index.php/GIMP_UI_Redesign). Mon but à terme est d’améliorer drastiquement l’expérience utilisateur, même si je ne me fais pas d’idées sur le fait que cela prendra plusieurs années. Travail en cours...
## Amélioration de la plate‐forme d’intégration ##
La plate‐forme d’intégration s’était améliorée, mais elle connaît beaucoup de problèmes ces dernières années (et malheureusement nous n’avons plus vraiment d’administrateur avec du temps libre parmi nous). Idéalement, à chaque _commit_, le code est compilé et testé (tests unitaires) et des messages d’erreur sont envoyés sur les canaux de communication (IRC notamment) pour avertir de tout problème. Mais notre plate‐forme n’est plus du tout fiable. À une époque, nous avions aussi des « _nightly builds_ » pour les utilisateurs friands de nouveautés et qui aiment le risque, mais cela n’existe plus depuis quelques années.
 
Nous aimerions ajouter aussi des constructions et tests pour macOS et Windows dans notre intégration. Ce qui est en discussion régulière, mais n’est toujours pas fait (et ne risque pas d’arriver de sitôt si l’on n’arrive même pas à stabiliser les constructions pour GNU/Linux), et ce, pour les mêmes raisons que pour le code : l’absence de contributeurs macOS et Windows.
 
En d’autres termes, les contributeurs qui s’intéressent à ces aspects du développement logiciel sont les bienvenus !
## Politique de publication ##
Je pense que peu de monde est vraiment satisfait de la politique de sortie de GIMP. Cela inclut aussi les développeurs, ne croyez pas le contraire. En effet, les versions majeures se font attendre des années et les corrections de bogues des mois, car on est coincé dans le système à l’ancienne de publications majeures et mineures où il faut attendre la stabilité de tout un tas de fonctionnalités. Or, certaines d’entre elles pourraient être prêtes et publiées depuis des années, mais doivent attendre la stabilité d’autres points.
![GIMP: It’s done when it’s done](http://www.gimpusers.com/system/tutorial_steps/3072/itsdonewhenitsdone-thumb.jpg)
C’est pourquoi j’ai lancé l’idée, lors du _Libre Graphics Meeting 2014_ à Leipzig, de changer notre politique de publication pour adopter le système plus récent, dit de « sorties rapides », qu’ont adopté par exemple les navigateurs ces dernières années. Bien sûr, outre l’aspect « commercial » de numérotation rapide que les gens pourraient reprocher (nous ne prévoyons pas de copier cela à ce jour), je pense bien voir là une solution à l’absence de visibilité sur les développements. Au lieu de voir une publication majeure comme un « gros » changement qui a beaucoup de fonctionnalités et une publication mineure comme seulement des corrections, on pourrait simplement voir une publication comme « quelque chose de prêt », sans discrimination. On devrait pouvoir être capable de sortir une version rapidement, même si c’est pour une ou deux corrections de bogue (que l’on juge suffisamment importantes pour ne pas faire patienter les gens), ni devoir attendre dix fonctionnalités quand une est déjà prête.
 
Après des années de pression interne, cette politique a été adoptée par étape. Nous avons ainsi [annoncé, il y a un an](https://www.gimp.org/news/2017/02/02/gimp-2-10-blockers/), que nous autoriserons de nouvelles fonctionnalités lors de publications mineures 2.10.x. Néanmoins, elles seront forcément limitées aux fonctionnalités peu « invasives » (au niveau du code).
# Sous GNU/Linux ! #
Sur nos systèmes GNU/Linux préférés, les logiciels sont historiquement empaquetés par les diverses distributions. Néanmoins, cela a quelques inconvénients, entre autres parce que les mises à jour sont souvent en retard. Et, pire, les distributions dites « stables » ne vont mettre à jour que les versions mineures. Comme nous avons déjà manqué quelques « gels » de distributions, on ne verra donc pas GIMP 2.10 sur Fedora avant au moins six mois, et vraisemblablement pas sur la dernière LTS d’Ubuntu (sortie la veille de la sortie de GIMP 2.10 et supportée jusqu’en 2023) ! Sans même parler de Debian stable... 
 
N. B. : C’est déjà [disponible dans _unstable_](https://packages.debian.org/sid/gimp).
Ce type de gestion de versions commence à changer dernièrement, avec les dépôts privés (PPA pour Ubuntu, Copr pour Fedora...) et aussi avec les paquets extra‐distributions (Flatpak, Snap, AppImage...).
GIMP est ainsi disponible dans un [paquet officiel Flatpak](https://flathub.org/repo/appstream/org.gimp.GIMP.flatpakref), hébergé sur Flathub. Cliquez le lien et, si votre distribution est suffisamment moderne, elle vous proposera d’installer GIMP.
C’est moi‐même qui maintient ce paquet, et il est officiellement pris en charge par le projet GIMP. Il fonctionne bien, malgré quelques limitations (et même quelques pertes de fonctionnalités à cause du modèle de sécurité et autres limitations actuelles du format). Ainsi, vous pouvez d’ores et déjà installer GIMP 2.10.0 en un clic, là, maintenant, tout de suite ! Et, bonus, vous bénéficierez directement de toute mise à jour future ! :-D
GIMP est aussi disponible dans des paquets tiers pour les divers autres systèmes. Je tiens cependant à rappeler que ces paquets ne sont pas créés par nous. Cela signifie qu’en cas de bogues, nous vous demandons de vous assurer que ceux‐ci ne proviennent pas du paquetage et de les rapporter d’abord à l’empaqueteur. En outre, on ne peut en assurer ni la qualité ni la conformité, et surtout la sécurité (c’est‐à‐dire si aucun code malveillant n’a pu être ajouté). C’est pour cette raison que je ne donne pas de liens mais ces paquets sont simples à trouver.
On nous a souvent accusé de privilégier Windows, car on ne proposait pas de binaires GNU/Linux (ce qui était simplement la norme jusqu’il y a peu : laisser les distributions s’en occuper). On notera que désormais, la version GNU/Linux est la première à sortir, presque immédiatement après l’annonce de la version stable (alors que l’installeur Windows a mis deux jours et le paquet macOS n’est pas sorti) ! Il ne s’agit d’ailleurs pas d’un coup de chance : cette situation est faite pour durer ! En tant que mainteneur du Flatpak, je prévois de ne jamais laisser passer plus de quelques heures avant la sortie du binaire (en fait, même pour cette sortie, le binaire n’a été retardé que parce que j’ai été forcé de lancer la compilation cinq fois d’affilée à cause de divers contretemps ; autrement, j’espérais pouvoir sortir le Flatpak en même temps que l’annonce).
# Liste non exhaustive #
Vous noterez que les [notes de sortie de GIMP 2.10.0](https://www.gimp.org/release-notes/gimp-2.10.html) ne listent pas exactement les mêmes changements que le présent article (alors même que j’ai contribué massivement à écrire les deux documents, ainsi qu’une majeure partie des implémentations de fonctionnalités). En fait, le nombre de nouvelles fonctionnalités ou de changements dans GIMP 2.10.0 est tellement énorme que personne n’a même essayé de les compter.
 
Le fichier [NEWS](https://git.gnome.org/browse/gimp/tree/NEWS.pre-2-10) est un peu plus complet, bien qu’il ne soit pas exhaustif non plus (je viens par exemple de me rendre compte qu’au moins une des fonctionnalités de cet article avait été oubliée dans `NEWS` et ce n’est probablement pas la seule).
 
Il fallait faire des choix de fonctionnalités à citer, qu’on espère pertinents, mais dans tous les cas, ce qualificatif dépendra fortement de chacun. Je vous laisse donc découvrir les autres nouveautés vous‐même en croisant les articles.
# GIMPez bien ! #
Le tour des fonctionnalités est terminé. Notons qu’il s’agit en fait d’un survol extrêmement succinct des nouveautés de GIMP 2.10.0 qui représentent véritablement un énorme bond en avant depuis la version 2.8.
Pour plus de détail de diverses fonctionnalités, je peux conseiller de lire les annonces (en anglais) des diverses versions de développement, ainsi que des candidates de sortie, donnant une vision plus incrémentale du développement :
 
* [GIMP 2.9.2 (27 novembre 2015)](https://www.gimp.org/news/2015/11/27/gimp-2-9-2-released/) ;
* [GIMP 2.9.4 (13 juillet 2016)](https://www.gimp.org/news/2016/07/13/gimp-2-9-4-released/) ;
* [GIMP 2.9.6 (24 août 2017)](https://www.gimp.org/news/2017/08/24/gimp-2-9-6-released/) ;
* [GIMP 2.9.8 (12 décembre 2017)](https://www.gimp.org/news/2017/12/12/gimp-2-9-8-released/) ;
* [GIMP 2.10.0 RC1 (26 mars 2018)](https://www.gimp.org/news/2018/03/26/gimp-2-10-0-rc1-released/) ;
* [GIMP 2.10.0 RC2 (17 avril 2018)](https://www.gimp.org/news/2018/04/17/gimp-2-10-0-rc2-released/) ;
* [GIMP 2.10.0 (27 avril 2018)](https://www.gimp.org/news/2018/04/27/gimp-2-10-0-released/).
 
Dans tous les cas, je vous souhaite beaucoup de plaisir à GIMPer toutes vos images, que ce soient des œuvres d’art originales ou de simples photos de vacances à retoucher. :-D
# Épilogue : *ZeMarmot* et le développement de GIMP #
Je souhaitais également rappeler que notre studio associatif, [LILA](https://libreart.info/), est un contributeur majeur de GIMP (je suis le [second plus gros contributeur de GIMP 2.10](https://www.openhub.net/p/gimp/contributors/summary), après le mainteneur ; et même plus gros contributeur des six derniers mois).
Notre but est de promouvoir l’art libre et les logiciels libres créatifs au niveau professionnel. Nos projets ont donc pour but à terme de rémunérer des créateurs qui utilisent des logiciels libres et partagent leurs créations. En particulier, nous produisons le film d’animation [*ZeMarmot*](https://film.zemarmot.net/).
 
Ma priorité dans la contribution de GIMP est donc d’en faire un outil de qualité professionnel (ce que j’estime qu’il est dorénavant, bien qu’il puisse encore être énormément amélioré). Cela signifie qu’il doit être fiable et stable (avant même de nous lancer dans *ZeMarmot*, mes contributions initiales étaient dues à l’existence de plantages trop fréquents de GIMP, que j’ai corrigés depuis), puis qu’il doit bénéficier de nouvelles fonctionnalités pour les usages avancés (ce que je fais aussi).
 
Si vous appréciez GIMP et notre travail pour l’améliorer, nous vous encourageons donc à contribuer financièrement. Vos dons rémunèreront aussi bien le développement de GIMP que la création du film (lequel peut servir de vitrine pour le logiciel libre, tout en étant une véritable œuvre et pas seulement une démo technique). Les donations sont possibles sur [Liberapay](https://liberapay.com/ZeMarmot), [Tipeee](https://www.tipeee.com/zemarmot), [Patreon](https://www.patreon.com/zemarmot) ou [autres](https://film.zemarmot.net/fr/donate) (que ce soit par virement, chèque, Paypal, bitcoin...).
C’est un moyen de contribuer à l’amélioration constante de ce fabuleux logiciel.
 
*Ze End*
---
_N. D. M. : Jehan est aussi un important contributeur à_ LinuxFr.org, _fournissant dépêches de qualité, journaux copieux et commentaires pertinents. Grâce à lui, nous sommes régulièrement informés, avec constance et précision, sur le développement de GIMP, les logiciels d’animation et le monde du traitement d’images. Quelques‐uns de ses articles sont mentionnés dans la dépêche, beaucoup manquent. Vous pouvez les retrouver en suivant [son pseudo](/users/jehan) ou l’étiquette [`gimp`](/tags/gimp/public). En voici un florilège pour découvrir certaines nouveautés oubliées dans la dépêche :_
 
- [_Wilber Week, GIMP, interviews des développeurs et sortie de la 2.10 à venir !_](/news/wilber-week-gimp-interviews-des-developpeurs-et-sortie-de-la-2-10-a-venir) (mars 2017) ;
- [_Entretien avec Michael Natterer, mainteneur de GIMP_](/news/entretien-avec-michael-natterer-mainteneur-de-gimp) (mars 2017) ;
- [_Nouvelles de ZeMarmot, GIMP et GIMP Motion (greffon d’animation dans GIMP)_](/news/nouvelles-de-zemarmot-gimp-et-gimp-motion-greffon-d-animation-dans-gimp) (août 2017) ;
- [_Les dernières nouvelles de ZeMarmot_](/news/les-dernieres-nouvelles-de-zemarmot) — sur le débogage dans GIMP (février 2018).
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/gimp-2-10-roule-au-gegl.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/gimp-2-10-roule-au-gegl.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>