tag:linuxfr.org,2005:/tags/babl/publicLinuxFr.org : les contenus étiquetés avec « babl »2021-05-02T21:07:05+02:00/favicon.pngtag:linuxfr.org,2005:News/403712021-04-19T22:55:11+02:002021-05-20T15:11:25+02:00GIMP 2.10.24: version cartographeLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>GIMP 2.10.24 est principalement une version corrective qui une fois encore améliore beaucoup le support des formats de fichier.<br>
<strong>Nouveautés notables :</strong></p>
<ul>
<li>magnétisation hors-canevas ;</li>
<li>métadonnées <a href="https://fr.wikipedia.org/wiki/GeoTIFF" title="Définition Wikipédia">GeoTIFF</a> <em>(informations de géoréférencement utilisées par les cartographes, ajoutées dans les fichiers TIFF)</em> ;</li>
<li>beaucoup d’améliorations dans l’éditeur et afficheur de métadonnées ;</li>
<li>beaucoup de formats de fichiers mieux gérés : HEIF, PSP, TIFF, JPEG, PNG, PDF,
DDS, BMP, PSD ;</li>
<li>une nouvelle opération la « <em>Negative Darkroom</em> » pour simuler l’agrandisseur depuis des scans de films négatifs ;</li>
<li>l’importation d’image Raw peut se faire via darktable 3.6 et plus ;</li>
<li>nouvelle traduction en kabyle.</li>
</ul>
</div><ul><li>lien nᵒ 1 : <a title="https://www.gimp.org/donating/" hreflang="en" href="https://linuxfr.org/redirect/108182">Faire un don au projet GIMP</a></li><li>lien nᵒ 2 : <a title="https://www.gimp.org/news/2021/03/29/gimp-2-10-24-released/" hreflang="en" href="https://linuxfr.org/redirect/108183">GIMP 2.10.24 Released</a></li><li>lien nᵒ 3 : <a title="https://www.gimp.org/downloads/" hreflang="en" href="https://linuxfr.org/redirect/108184">Téléchargements</a></li><li>lien nᵒ 4 : <a title="https://linuxfr.org/news/gimp-2-10-22-consolidation-des-formats" hreflang="fr" href="https://linuxfr.org/redirect/108262">Dépêche sur la précédente version stable 2.10.22 sur Linuxfr.org</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li>
<a href="#toc-au-c%C5%93ur-du-code">Au cœur du code</a><ul>
<li><a href="#toc-magn%C3%A9tisation-hors-du-canevas">Magnétisation hors du canevas</a></li>
</ul>
</li>
<li><a href="#toc-gestion-des-m%C3%A9tadonn%C3%A9es">Gestion des métadonnées</a></li>
<li>
<a href="#toc-formats-de-fichiers">Formats de fichiers</a><ul>
<li><a href="#toc-geotiff">GeoTIFF</a></li>
<li><a href="#toc-am%C3%A9liorations-sur-plusieurs-formats-dimage">Améliorations sur plusieurs formats d’image</a></li>
</ul>
</li>
<li><a href="#toc-nouvelle-traduction">Nouvelle traduction</a></li>
<li>
<a href="#toc-gegl-et-babl">GEGL et babl</a><ul>
<li><a href="#toc-les-changements-en-bref">Les changements en bref</a></li>
<li><a href="#toc-chambre-noire-pour-n%C3%A9gatifs">Chambre noire pour négatifs</a></li>
<li><a href="#toc-version-minimum-de-babl-dans-gegl-et-gimp">Version minimum de babl dans GEGL et GIMP</a></li>
</ul>
</li>
<li><a href="#toc-t%C3%A9l%C3%A9charger-gimp-21024">Télécharger GIMP 2.10.24</a></li>
<li><a href="#toc-%C3%80-suivre">À suivre…</a></li>
<li>
<a href="#toc-%C3%89pilogue-je-deviens-co-mainteneur-de-gimp">Épilogue: je deviens co-mainteneur de GIMP</a><ul>
<li><a href="#toc-une-responsabilit%C3%A9">Une responsabilité</a></li>
<li><a href="#toc-comment-cela-a-t-il-commenc%C3%A9">Comment cela a-t-il commencé</a></li>
</ul>
</li>
</ul>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f7777772e67696d702e6f72672f6e6577732f323032312f30332f32392f67696d702d322d31302d32342d72656c65617365642f3230323130332d77696c6265722d616e642d636f2e6a7067/202103-wilber-and-co.jpg" alt="Wilber le cartographe — Wilber and co. comics strip" title="Source : https://www.gimp.org/news/2021/03/29/gimp-2-10-24-released/202103-wilber-and-co.jpg"><br>
<em>« Wilber le cartographe » par <a href="https://film.zemarmot.net">Aryeom</a>, Creative Commons by-sa 4.0 — GIMP 2.10.24 prend en charge GeoTIFF</em></p>
<h2 id="toc-au-cœur-du-code">Au cœur du code</h2>
<h3 id="toc-magnétisation-hors-du-canevas">Magnétisation hors du canevas</h3>
<p>C’est le changement le plus intéressant, bien qu’il y en ait d’autres dans le code central. Depuis GIMP 2.10.14, nous pouvons afficher <a href="https://www.gimp.org/news/2019/10/31/gimp-2-10-14-released/#out-of-canvas-viewing-and-editing">l’espace hors canevas</a>. Désormais, beaucoup de choses peuvent être effectuées hors du canevas, même si tout n’est pas encore possible. Ce changement est dans la continuité de ce travail initial, vous permettant de magnétiser plusieurs outils sur les guides, grilles et vecteurs en dehors du canevas.<br>
<img src="//img.linuxfr.org/img/68747470733a2f2f7777772e67696d702e6f72672f6e6577732f323032312f30332f32392f67696d702d322d31302d32342d72656c65617365642f67696d702d322e31302e32342d736e61702d6f66662d63616e7661732e676966/gimp-2.10.24-snap-off-canvas.gif" alt="Snapping to guide/grid/vectors off-canvas made possible - GIMP 2.10.24" title="Source : https://www.gimp.org/news/2021/03/29/gimp-2-10-24-released/gimp-2.10.24-snap-off-canvas.gif"></p>
<h2 id="toc-gestion-des-métadonnées">Gestion des métadonnées</h2>
<p>Beaucoup de travail a été fait sur les métadonnées, surtout pour en améliorer la prise en charge et corriger plein de bugs.<br>
L’éditeur et visualiseur de métadonnées a reçu beaucoup d’attention pour le rendre plus fiable, notamment sur des cas particuliers (comme la duplication de balises), mais aussi sur la correspondance entre balises similaires IPTC et XMP, sur une meilleure gestion de l’encodage, etc.<br>
Les données GPS sont gérées avec plus de précision, des bulles d’aide et un meilleur formatage.<br>
Beaucoup reste à faire pour améliorer les métadonnées bien que nous soyons en bonne voie. C’est une partie peu visible du développement, mais chronophage et donc ingrate, tout en étant indispensable pour ceux qui utilisent les métadonnées. On tient donc à remercier <a href="https://www.jacobboerema.nl/en/">Jacob Boerema</a> qui travaille inlassablement là-dessus depuis des mois.</p>
<h2 id="toc-formats-de-fichiers">Formats de fichiers</h2>
<h3 id="toc-geotiff">GeoTIFF</h3>
<p>Une histoire qui commence avec <a href="https://www.youtube.com/watch?v=N1G0qyETCow">une conférence d’Adam Cox de l’Université de l’État de Louisiane</a> sur l’utilisation de GIMP pour améliorer les cartes historiques — malgré la perte des métadonnées GeoTIFF qui rendait le processus un peu pénible. La conférence a déclenché un rapport de bug puis un patch de Ruthra Kumar (un contributeur occasionnel) et une relecture du code par l’équipe. Le tout en deux mois !<br>
Maintenant GIMP importe puis exporte en retour les balises GeoTIFF. Attention, aucune logique sémantique n’est implémentée, GIMP ne met pas de sens dans ces métadonnées : les métadonnées importées sont recopiées en sortie sans être corrigées par GIMP. Faites particulièrement attention si elles contiennent des références géographiques, parce que des transformations (géométrie ou résolution de l’image par exemple) pourraient les rendre obsolètes. C’est à vous de savoir ce que les données référencent et comment conserver leur signification. <br>
Dans la boite de dialogue, l’option d’export sera disponible seulement s’il y avait des métadonnées GeoTIFF à l’importation :<br>
<img src="//img.linuxfr.org/img/68747470733a2f2f7777772e67696d702e6f72672f6e6577732f323032312f30332f32392f67696d702d322d31302d32342d72656c65617365642f67696d702d322e31302e32342d736176652d67656f746966662e706e67/gimp-2.10.24-save-geotiff.png" alt="Save GeoTIFF metadata as imported - GIMP 2.10.24" title="Source : https://www.gimp.org/news/2021/03/29/gimp-2-10-24-released/gimp-2.10.24-save-geotiff.png"><br>
Cette jolie petite histoire montre une fois de plus le pouvoir du Logiciel Libre, qui est avant tout un logiciel fait par vous-même. Tout contributeur fait partie de l’équipe GIMP ! 🤗<br>
<em>NB : les plus attentifs auront noté que cette fonction était disponible dans la version de développement 2.99.4. On l’a décrite pour la 2.10.24 parce que c’est la première version stable avec le support de GeoTIFF.</em></p>
<h3 id="toc-améliorations-sur-plusieurs-formats-dimage">Améliorations sur plusieurs formats d’image</h3>
<p>Comme dans <a href="/news/gimp-2-10-22-consolidation-des-formats">notre version stable précédente</a>, on a poursuivi le travail sur les greffons de format de fichiers. </p>
<ul>
<li>
<strong>TIFF</strong> s’améliore dans la gestion du multi-page, et dans plein de cas particuliers comme les images TIFF 2 ou 4 bits ou l’ouverture de fichiers non conformes, etc.</li>
<li>
<strong>HEIF</strong> fait un export sans pertes visibles en utilisant libheif 1.10 ou plus récente. On détecte séparément à l’exécution le support d’HEIC et AVIF, ce qui permet de compiler le greffon avec seulement l’un des codages.</li>
<li>
<strong>PNG</strong> ignore maintenant un offset de calque à 0, métadonnée que certains logiciels enregistrent systématiquement, supprimant ainsi des dialogues inutiles.</li>
<li>
<strong>JPEG</strong> avertit plus clairement quand l’enregistrement de certaines métadonnées échoue.</li>
<li>
<strong>BMP</strong> charge maintenant les images avec une grande profondeur de couleur, notamment celles à 24 bits par pixel ; de plus, GIMP arrive à récupérer certains fichiers BMP non conformes ayant une valeur de compression invalide stockée dans l’en-tête.</li>
<li>
<strong>PDF</strong> propose en option d’inverser l’ordre des couches à l’import (c’était déjà le cas dans l’export) et permet l’importation des images avec une résolution décimale (DPI).</li>
<li>
<strong>DDS</strong> (<a href="https://en.wikipedia.org/wiki/DirectDraw_Surface">DirectDraw Surface</a>) a reçu plusieurs corrections pour la compression BC5. De plus, GIMP peut maintenant détecter des images qu’il a précédemment mal exportées et les corriger lors du chargement.</li>
<li>
<strong>Raw</strong> est toujours délégué à des <a href="https://www.gimp.org/release-notes/gimp-2.10.html#digital-photography-improvements">dématriceurs évolués</a> tels que <a href="https://www.darktable.org/">darktable</a> ou <a href="https://www.rawtherapee.com/">RawTherapee</a>. L’API du premier est en chantier, et bien que darktable 3.6 ne soit pas encore sorti, GIMP est déjà compatible avec cette version. C’est pourquoi GIMP 2.10.24 fonctionnera avec le futur darktable.</li>
</ul>
<h2 id="toc-nouvelle-traduction">Nouvelle traduction</h2>
<p>Une langue de plus est disponible dans GIMP : le <strong>kabyle</strong>. C’est un début de traduction puisque seulement <a href="https://l10n.gnome.org/languages/kab/gnome-gimp/ui/">18% de la branche stable est traduite</a> (et 32% de la branche de développement !), mais on peut déjà remercier les nouveaux traducteurs, pour fournir GIMP à encore plus de gens. Ça rend GIMP disponible dans 82 langues en plus de l’anglais ! Les traducteurs sont aussi des contributeurs dont le formidable travail n’obtient ni la visibilité ni les remerciements qu’ils méritent. Alors merci à eux !</p>
<h2 id="toc-gegl-et-babl">GEGL et babl</h2>
<p>Comme d’habitude, des nouvelles versions de <a href="https://gegl.org/babl/">babl</a> (0.18.6) et <a href="https://gegl.org/">GEGL</a> (0.4.30) accompagnent cette sortie.</p>
<h3 id="toc-les-changements-en-bref">Les changements en bref</h3>
<p>Notre moteur d’encodage de pixels et de conversion d’espace de couleurs, babl 0.1.86, permet maintenant la création d’espaces babl (représentation d’un espace de couleur dans babl) depuis les classes d’entrées de profils ICC et il améliore le multi-threads.<br>
De son côté, GEGL 0.4.30 améliore ses tests et les opérations suivantes : <code>jpg-load</code>, <code>png-load</code>, <code>tiff-load</code>, <code>rgbe-load</code>, <code>color-reduction</code>, <code>fattal02</code> et <code>paint-select</code>. Cette dernière opération a été introduite pour le nouvel <a href="https://www.gimp.org/news/2020/12/25/gimp-2-99-4-released/#new-experimental-paint-select-tool">outil Paint Select</a> dont on aura l’occasion de reparler à la prochaine version de développement.</p>
<h3 id="toc-chambre-noire-pour-négatifs">Chambre noire pour négatifs</h3>
<p>En plus des améliorations, une nouvelle opération très intéressante est apparue dans GEGL grâce à Jonny Robbie : <code>negative-darkroom</code>.<br>
C’est un outil pour les photographes qui utilisent une technique hybride de développement photo : après avoir scanné un film négatif, cette opération crée une image positive (inversée du scan) en simulant le développement via un agrandisseur en chambre noire avec différents paramètres d’exposition et plusieurs papiers photo.<br>
<img src="//img.linuxfr.org/img/68747470733a2f2f7777772e67696d702e6f72672f6e6577732f323032312f30332f32392f67696d702d322d31302d32342d72656c65617365642f67696d702d322e31302e32342d6e656761746976652d6461726b726f6f6d2e6a7067/gimp-2.10.24-negative-darkroom.jpg" alt="Negative Darkroom operation in GEGL 0.4.30 / GIMP 2.10.24" title="Source : https://www.gimp.org/news/2021/03/29/gimp-2-10-24-released/gimp-2.10.24-negative-darkroom.jpg"><br>
Comme GIMP détecte toutes les opérations GEGL, elles sont automatiquement disponibles dans le menu générique des outils GEGL. Vous trouverez celle-ci dans le menu <code>Outils > Opérations GEGL…</code> en choisissant « <em>Chambre noire négative (negative-darkroom)</em> » dans la liste.<br>
Aucune boite de dialogue spécifique n’a été créée pour l’instant, il faudra attendre une future version de GIMP pour améliorer l’utilisation de l’outil.</p>
<h3 id="toc-version-minimum-de-babl-dans-gegl-et-gimp">Version minimum de babl dans GEGL et GIMP</h3>
<p>La version minimum de babl pour GEGL a été rétrogradée à la 0.1.78 (comme déjà le cas dans GIMP) parce que les nouvelles versions ont besoin d’un <code>meson</code> plus récent pour être compilées, lequel n’est pas disponible dans plusieurs distributions. Pour que tout le monde bénéficie des nouvelles versions de GEGL et GIMP nous avons choisi de ne pas incrémenter la version minimum, mais nous insistons pour que les empaqueteurs utilisent la dernière version de babl si possible. Il y a plein de corrections et d’améliorations dans les versions récentes.</p>
<h2 id="toc-télécharger-gimp-21024">Télécharger GIMP 2.10.24</h2>
<p>Comme d’habitude, GIMP 2.10.24 est disponible sur <a href="https://www.gimp.org/downloads/">le site officiel de GIMP (gimp.org)</a>:</p>
<ul>
<li>Le flatpak Linux est déjà publié, ceux l’ayant précédemment installé devraient donc se voir proposer une mise à jour par leur gestionnaire de logiciels (ou depuis la console: <code>flatpak update org.gimp.GIMP</code>).
<em>NB : GIMP en format flatpak n’est disponible que pour <code>x86_64</code> et <code>AArch64</code> (versions 64 bits des architectures x86 et ARM). <code>i386</code> (x86 32 bits) a été sorti de l’environnement d’exécution Freedesktop il y a quelque temps déjà. C’est maintenant <code>ARM</code> (32 bits) qui est abandonné (bien que des matériels ARM 32 bits sortent encore, ou que des machines ARM 64 bits soient fréquemment livrées avec un OS 32 bits). Nous avons essayé de prolonger ces versions 32 bits le plus longtemps possible, mais le dernier runtime disponible étant en fin de vie, leur abandon était le seul choix raisonable.
Par conséquent, la dernière version du flatpak <code>i386</code> est 2.10.14, et celle du flatpak <code>ARM</code> est 2.10.22 (Elles ont été respectivement téléchargées quelques milliers de fois et un peu plus de 400 fois).</em>
</li>
<li>L’installeur Windows est disponible dès maintenant. La plupart des miroirs le proposent, mais pas encore tous. Si le téléchargement échoue, re-cliquez sur le bouton <code>Télécharger</code>.</li>
<li>Le paquet DMG pour macOS sera publié d’ici quelques jours, dès que son mainteneur aura trouvé le temps nécessaire.</li>
</ul>
<h2 id="toc-À-suivre">À suivre…</h2>
<p>Le développement continue de manière intensive et on voit bien le basculement vers GIMP 3 à mesure que les versions 2.10.x deviennent plus robustes et contiennent moins de nouveautés (même si on continue à rétroporter des nouveautés quand ça peut être fait sans trop de travail).<br>
On vous donnera plus de détail sur cet aspect du développement à la sortie de la prochaine version de développement 2.99.6.</p>
<p>Enfin, n’oubliez que vous pouvez <a href="https://www.gimp.org/donating/">faire un don au projet GIMP ou financer directement certains développeurs</a>, c’est un moyen d’aider en retour et d’accélérer le développement de GIMP.</p>
<p>En particulier nous rappelons que vous pouvez financer directement <a href="https://www.patreon.com/pippin">le mainteneur de GEGL sur Patreon</a> ainsi que le projet de film libre "<em>ZeMarmot</em>" sur <a href="https://www.patreon.com/zemarmot">Patreon</a>, <a href="https://en.tipeee.com/zemarmot/">Tipeee</a> ou <a href="https://liberapay.com/ZeMarmot/">Liberapay</a>, projet grâce auquel je développe GIMP depuis maintenant plusieurs années, et par lequel je suis même devenu depuis un an le plus gros contributeur.</p>
<h2 id="toc-Épilogue-je-deviens-co-mainteneur-de-gimp">Épilogue: je deviens co-mainteneur de GIMP</h2>
<p><em>Note: extrait de notre dernier article sur <a href="https://www.patreon.com/posts/sortie-de-gimp-2-49975752">Patreon</a> et <a href="https://en.tipeee.com/zemarmot/news/114878">Tipeee</a> pour le projet <a href="https://film.zemarmot.net/">ZeMarmot</a> — traduction ci-dessous par le contributeur <strong>gillux</strong> à partir de la version que j’avais écrite en anglais.</em></p>
<h3 id="toc-une-responsabilité">Une responsabilité</h3>
<p>La nouveauté, cela dit, c’est que <strong>j’ai (Jehan) été officiellement nommé co-mainteneur de GIMP</strong> par Mitch (notre super mainteneur) ! Comme dit dans un <a href="https://www.patreon.com/posts/45607895">article précédent</a>, j’avais déjà préparé intégralement la précédente version de développement (GIMP 2.99.4), mais cette fois, on m’a demandé de mettre mon nom dans le fichier me donnant le rôle de mainteneur du code source, pour que je puisse taguer cette nouvelle version. Une sorte de dernier coup de tampon pour dire « Je valide ! ».</p>
<p>C’est extrêmement touchant pour moi. Il y a près de neuf années, lorsque j’ai fait mon premier correctif pour GIMP, jamais je n’aurais imaginé que l’on m’en confierait un jour la maintenance. GIMP a toujours été une grande figure du logiciel libre. Mais j’ai surtout compris au fil des années que c’est bien plus que ça. C’est un véritable logiciel collaboratif. J’avais contribué à d’autres projets en soumettant des correctifs à droite à gauche, mais c’est la première fois que je me suis senti pleinement le bienvenu au sein d’un projet de logiciel libre (accueilli par des personnes bienveillantes qui ne m’ont pas considéré comme un oiseau de passage, mais qui souhaitaient me voir rester). On m’a très rapidement donné le droit de faire “push”, invité à des événements, tout ça dans une atmosphère très conviviale, très loin de tout baratin marketing. C’est aussi une des équipes les plus inclusives que j’ai jamais vues, avec toutes sortes de personnes qui s’acceptent simplement, telles qu’elles sont. De plus, toutes les grandes questions techniques sont débattues avec les autres contributeurs, même les nouveaux venus, et même les anciens qui ne contribuent plus tellement au code (mais qui sont toujours là), avec les développeurs comme les non-développeurs. Pas de hiérarchie, que des décisions horizontales dans le respect des contributeurs. Voilà pourquoi je considère GIMP comme un véritable <strong>logiciel libre collaboratif</strong>.</p>
<p>La seule chose que nous n’accepterons pas, c’est ceux qui sont méchants avec les autres. C’est la chose qui, par-dessus tout, m’importe le plus (oui, même plus que les compétences) et l’une des choses que je continuerai à défendre en tant que co-mainteneur.</p>
<h3 id="toc-comment-cela-a-t-il-commencé">Comment cela a-t-il commencé</h3>
<p>Pour l’anecdote, tout a commencé quand Aryeom et moi testions GIMP (à l’époque, en 2011-2012, Aryeom était en dernière année d’école des beaux-arts de l’animation, très habituée à utiliser certains logiciels propriétaires de graphisme) et rencontrions des problèmes avec. Nous avons commencé par envoyer quelques correctifs. Nous avons alors été si bien accueillis que nous en avons envoyé davantage, et avons même tenté de petits projets. En dehors de quelques illustrations et posters, le premier projet animé que nous avons tenté avec GIMP fut cette <a href="https://vimeo.com/62131490">petite interview animée de Firefox</a>, après avoir gagné un prix au concours vidéo de Mozilla (même si la vidéo du concours a été faite avec des logiciels propriétaires, l’« interview » elle-même fut intégralement dessinée et animée avec GIMP). Ensuite, Aryeom voulait essayer d’autres choses et elle a créé cette deuxième <a href="https://youtu.be/VdoreQ1_oJs">vidéo par rotoscopie</a>, intégralement dessinée avec GIMP. Tout cela s’est passé en 2013. Principalement des créations expérimentales, pour le plaisir, tandis que les productions payées d’Aryeom continuaient à être faites avec des logiciels propriétaires.</p>
<p>Passons directement à 2015, lorsque nous avons commencé à réfléchir à faire un truc plus conséquent avec GIMP. Soyons clairs d’entrée de jeu : nous l’avons regretté plus d’une fois. Nous savons mieux que personne que nous avons eu les yeux plus gros que le ventre. Nous le savons tous, car c’est toujours d’actualité (depuis beaucoup plus longtemps que prévu). Pendant cette période, Aryeom et moi sommes tous les deux passés par des phases d’extrême fatigue, de stress intense, parfois proches de la dépression, nous demandant où nous allions avec ce projet (presque pas rémunérés, nous devons souvent accepter d’autres boulots pendant de longues périodes, tout en travaillant sur ZeMarmot sur notre temps libre), gagnés parfois même par un sentiment d’échec. Malgré tout, nous n’avons jamais vraiment abandonné, car nous avions fait la promesse de sortir quelque chose. Nous savons maintenant que ce ne sera pas ce que nous espérions, mais nous tenons tout de même à arriver à un résultat. Cela vaut à la fois pour Aryeom et pour moi.</p>
<p>Pour Aryeom, c’est un travail extrêmement fatigant et éprouvant. Je sais qu’elle n’aime pas en parler, parce qu’elle est plutôt réservée et déteste donner l’impression de se chercher des excuses, alors je me permets de le faire pour elle. Le fait est que l’animation est déjà un travail lent et difficile lorsqu’il est effectué par toute une équipe de centaines de personnes avec des dizaines de millions d’euros. Là, elle n’a ni l’équipe ni le financement ; et elle travaille avec un logiciel qui n’a pas été conçu initialement pour l’animation, qu’en même temps nous améliorons et modifions (ce n’est pas un produit fini d’une grande entreprise dotée de dizaines de développeurs à plein temps), avec moi, développeur maladroit, aux prises avec le code. C’est d’autant plus difficile et on se sent seul. D’ailleurs, n’hésitez jamais à lui dire un petit mot gentil, car elle a souvent peur que les gens soient déçus d’elle.</p>
<p>Pour ma part, j’ai réécrit tant de fois mon code pour l’animation que je ne compte même plus les milliers de lignes de code et les semaines de travail que j’ai jetés à la poubelle. Et il n’est toujours pas dans le code de GIMP (oui, j’ai énormément de choses à montrer, mais pas ce gros morceau). Pas terrible ! Aryeom comme moi sommes assez perfectionnistes, ce qui est parfois problématique.</p>
<p>Bref, quand Mitch m’a dit que j’étais de toute façon mainteneur, et que nous l’avons officialisé en modifiant un fichier, c’était une excellente et requinquante nouvelle, après toutes les difficultés que nous avons traversées pendant lesquelles nous nous demandions parfois à quoi bon continuer. C’est notamment quand nos contributions sont appréciées et qu’une valeur leur est reconnue que parfois on se dit que ça vaut le coup de continuer. C’est là une de ces petites choses qui font que la vie vaut la peine d’être vécue. 💌</p>
<p>À propos, en ce qui me concerne, je considère Aryeom comme tout aussi responsable de la maintenance de plein de choses dans GIMP que moi. Évidemment, son nom n’apparaît pas tant dans les logs que le mien, mais la réalité est que tout a commencé avec elle et continue encore avec ses propositions et conseils réguliers pour GIMP. Jour après jour ! 😂 Alors qu’elle aurait pu mener une vie ordinaire, comme la plupart des animateurs de gros studios, utilisant seulement des logiciels onéreux et touchant de très hauts salaires, elle a choisi de m’accompagner pour faire de petits projets copyleft sur un logiciel collaboratif avec une poignée de développeurs sur leur temps libre, parce que nous souhaitions que tout le monde profite de nos productions artistiques et logicielles plutôt que de nous faire un max de pognon sur le dos de la société. Alors oui, elle mérite ce titre de co-mainteneuse pour toutes ces années passées à améliorer GIMP dans l’ombre avec un très maigre salaire. Et ce, sans l’ombre d’un doute ! 😃</p>
<p>Nous comptons faire bon usage du titre de co-mainteneurs de GIMP, pour de longues années, espérons-le ! (Pas pour toujours sur ZeMarmot bien sûr, nous ferons sûrement d’autres projets sympas plus tard, plus petits et moins stressants !)</p>
<p>Pardonnez-moi cette digression sur de vieilles histoires, tout cela m’a quelque peu ému et m’a donné envie de vous raconter comment nous avions commencé à travailler sur GIMP. Je voulais aussi vous remercier, vous tous, encore une fois ! 💕</p>
<p><strong>NdM. :</strong> toutes nos félicitations à vous, Aryeom & Jehan, de la part de la part de l'équipe LinuxFr.org (ce n'est même pas une figure de style, cela a été discuté lors de l'assemblée générale de l'association LinuxFr à laquelle toutes les équipes admin / modération / animation étaient conviées). Vos contributions sur GIMP, sur ZeMarmot, vos dépêches sur le site et le logo ZeMarmot (qu'arbore le site pour l'occasion) sont grandement appréciées. Et ceux qui vous ont croisé à l'occasion de stands et autres conférences apprécient aussi vos qualités humaines.</p>
</div><div><a href="https://linuxfr.org/news/gimp-2-10-24-version-cartographe.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/123723/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/gimp-2-10-24-version-cartographe#comments">ouvrir dans le navigateur</a>
</p>
JehanorfenorEmmanuelPBenoît SibaudFlorent ZaraAnonymeLtrlgLe PnumeYves BourguignonTBTBhttps://linuxfr.org/nodes/123723/comments.atomtag:linuxfr.org,2005:News/353342015-06-27T14:49:45+02:002015-06-27T14:49:45+02:00Entretien avec Jehan, développeur GIMPLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Nous avons la chance d’avoir quelques développeurs qui fréquentent LinuxFR.org, dont Jehan Pagès (<a href="//linuxfr.org/users/jehan">Jehan</a>) qui contribue à <a href="https://fr.wikipedia.org/wiki/GIMP" title="Définition Wikipédia">GIMP</a>, le logiciel de retouche d’images que l’on ne présente plus et qui est en train de se faire beau en vue de la sortie de la version 2.10 (je parle du logiciel, pas de Jehan — quoique je ne sache pas précisément ce qu’est en train de faire Jehan à l’heure où je couche ces quelques lignes).</p>
<p>Jehan a accepté de répondre à quelques questions pour LinuxFr.org ; nous le remercions chaleureusement à la fois pour le temps consacré à cet entretien et pour son implication dans GIMP !</p></div><ul><li>lien nᵒ 1 : <a title="http://girinstud.io" hreflang="fr" href="https://linuxfr.org/redirect/94448">Studio Girin</a></li><li>lien nᵒ 2 : <a title="http://gimp.org" hreflang="en" href="https://linuxfr.org/redirect/94449">GIMP</a></li><li>lien nᵒ 3 : <a title="https://www.openhub.net/accounts/Jehan/" hreflang="en" href="https://linuxfr.org/redirect/94450">Contributions (non-exhaustif) de Jehan à des projets Libres</a></li></ul><div><p><strong>Bonjour, peux-tu te présenter en quelques mots ?</strong></p>
<p>Je m’appelle Jehan. Ces dernières années, je me suis principalement défini comme un « vagabond » mais depuis environ un an, ce n’est plus vrai. Donc je ne sais plus trop comment me présenter autrement. Je suis un être humain. :-)<br><img src="//img.linuxfr.org/img/68747470733a2f2f6c75742e696d2f50546a4e336e41382f5748346659616374/WH4fYact" alt="Mongolie" title="Source : https://lut.im/PTjN3nA8/WH4fYact"></p>
<p><strong>Comment définirais-tu ton rapport au logiciel libre, et comment es-tu entré en contact avec lui ?</strong></p>
<p>J’étais dans une famille d’artistes, pour qui l’usage de l'ordinateur est très basique. À l’opposé donc du stéréotype du geek dont les parents sont eux-mêmes ingénieurs et qui a développé son premier logiciel à 7 ans en BASIC.<br>
Mon premier contact avec un ordinateur fut en squattant l'Amiga de mon grand frère qui nous servait essentiellement de console de jeu, jusqu’à ce que l’alimentation crame (facilement réparable, mais on n’y connaissait rien, le vendeur de grande surface non plus et c’en est resté là : l’horreur de la société de consommation dans toute sa splendeur).</p>
<p>J’ai eu mon premier ordi au milieu du lycée, avec Windows, des logiciels crackés, et des jeux vidéos. En prépa j’ai rencontré un gars qui a contribué à changer ma vision de l’informatique. Il s’appelle Samuel (et fréquente LinuxFr.org sans commenter beaucoup, je crois qu’il en a marre des trolls !). Il me bassinait avec ce truc : « Linux ». Je pense que c’est la première fois que j’en entendais parler. Je ne devais même pas avoir idée qu’il existait autre chose que Windows sur PC (et Mac était juste une « autre sorte » d'ordi). Pendant un an, il m’a fait chier, mais j’ai tenu et lui disais d’arrêter de m’emmerder avec ça.<br>
Plus tard, en fac d’info, tout était sous Linux. J’appelle Sam, je lui demande donc « un Linux ». Il me file un CD de Mandrake. J’avais le même vieil ordi depuis le lycée avec un petit disque, donc je vire Win et mets Mandrake en simple démarrage. Depuis je n’en suis pas revenu (enfin de GNU/Linux, pas de Mandrake bien sûr !). Et franchement je ne souhaite revenir à Windows comme OS principal pour rien au monde.<br>
Avec le temps, j’ai découvert la philosophie derrière les Logiciels Libres. Et je pense que c’est ce qui m’a réellement conquis.</p>
<p>Au début, j’ai essayé de participer à quelques projets, avec plus ou moins de succès.</p>
<p>De nos jours mon rapport au LL est : si quelque chose ne me plaît pas ou est buggué, je fais un rapport de bug ; si mon rapport de bug n’a pas assez de priorité pour les développeurs, mais qu’il en a pour moi, je n’attends plus que quelqu’un le corrige. Je corrige moi-même et envoie <em>upstream</em>.</p>
<p><strong>Quelles sont tes contributions à la future version 2.10 de GIMP ?</strong></p>
<p>Déjà des contributions tierces, c’est-à-dire sur d'autres projets utilisés par GIMP (dépendances), qui ne sont pas aussi visibles, mais tout aussi importantes. En effet, des fois, les bugs qui sont rapportés viennent d’une bibliothèque tierce. Donc, on ouvre un rapport de bug sur l’autre projet. Or, suivant ma philosophie "je corrige quand j’en ai assez d’attendre les autres", il m’est régulièrement arrivé de faire un patch par-ci, par-là. J’ai ainsi contribué sur glib, GTK+, Pango, Exiv2, GExiv2, poppler, libmypaint, gettext, fontconfig, même autoconf et, bien sûr, à babl et GEGL. Et pour tous ces projets, mes patchs sont dûs au fait que je développe sur GIMP.</p>
<p>Pas forcément grand-chose, des fois juste des améliorations sur leurs systèmes de <em>build</em>. Par exemple, quand nous avons intégré <a href="https://wiki.gnome.org/Projects/gexiv2">GExiv2</a> dans GIMP, ce dernier avait un <code>Makefile</code> fait main et un <code>pkg-config</code> cassé. Je leur ai donc proposé un système de compilation à base d'<code>autotools</code>, ce qui a notamment permis de compiler GExiv2 pour Windows, sans même toucher à une seule ligne de code (un des développeurs m'a dit avoir été étonné, car il n’avait jamais vraiment pensé à Windows en développant jusque-là et n’avait pas la moindre idée que ce serait aussi simple de <em>cross-compiler</em> leur code).</p>
<p>Et puis l'une des corrections tierces dont je suis le plus content est dans <a href="http://www.gtk.org/">GTK+</a>. Jusqu'en 2013, quand on déconnectait sa tablette graphique, GIMP plantait. C'est tout con, mais c'est horripilant. La tablette est branchée en USB, et on sait tous qu'avec le câble qui se balade, ou un coup de main malencontreux, déconnecter un périphérique USB (même une micro-coupure pour un centième de seconde) n'est pas rare. Cela faisait planter tout logiciel qui gérait des tablettes sous GTK+ 2.0, car la prise en charge du branchement à chaud de périphérique n'est disponible qu'a partir de la version 3.0 de GTK+. Or, avec GIMP ou <a href="http://mypaint.intilinux.com/">MyPaint</a> (tous deux logiciels de dessin en GTK+2) les gens qui utilisent une tablette sont légions. Et je vous parle pas de l'horreur de perte de travail pour un peintre numérique qui ne pense pas à sauver régulièrement !</p>
<p>Je n'ai pas ajouté la prise en charge du branchement à chaud sous GTK+ 2 (qui n'accepte pas de nouvelles fonctionnalités, juste des correctifs), mais j'ai au moins permis de contourner le problème. Maintenant ça ne plante plus !</p>
<p>Ensuite GIMP à proprement parler, ce serait assez dur de lister toutes mes contributions. L'une d'elle est que je suis désormais le mainteneur du greffon de prévisualisation d'animation. Mon but est d'en faire un greffon et une UI bien plus élaborée qui permettra de faire autre chose que des <code>GIF</code> de chatons, mais même aussi d'utiliser GIMP pour faire de la vraie animation professionnelle. C'est un travail en cours que j'espère pouvoir présenter bientôt.</p>
<p>Sinon j'ai aussi fait passer GIMP aux normes des <a href="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">répertoires XDG</a>, j'ai amélioré le système de migration d'une version de GIMP à l'autre, ainsi que plusieurs problèmes de localisation (l'ordre des menus pour suivre les normes d'un langage RTL, la détection du langage sous Windows, la localisation des noms de langage dans leur propre langage…), des améliorations des onglets (leur permettre d'être réordonnés, de les avoir à gauche, droite, en bas…), j'ai intégré le code d'un contributeur externe permettant d'avoir une boîte de recherche contextuelle d'action (similaire au « menu-espace » de Blender), aidé à l'intégration des brosses <a href="http://mypaint.intilinux.com/">MyPaint</a> comme outil GIMP, ajouté une compression zlib (plutôt que RLE jusque-là) interne dans le format XCF, etc.<br><img src="//img.linuxfr.org/img/68747470733a2f2f6c75742e696d2f664c724d737138612f616a76376b734936/ajv7ksI6" alt="Recherche d'action" title="Source : https://lut.im/fLrMsq8a/ajv7ksI6"></p>
<p>Je suis aussi l'un des rares développeurs qui va parfois corriger des bugs pour Windows (j'utilise ma licence en vente-liée essentiellement pour GIMP, avec un Windows en VM). Donc j'ai corrigé plusieurs bugs spécifiques à GIMP sous win.</p>
<p>Et puis, bien sûr, pas mal de corrections de bugs, dont des <em>crashs</em>/plantages. C'est pour moi un des points les plus importants et pourtant des plus ingrats. Ingrat, car tout le monde se plaint des bugs, mais personne ne remercie jamais un développeur pour une correction de bug. Combien d'utilisateurs m'ont félicité pour la fonctionnalité de <a href="https://www.youtube.com/watch?v=NwPY0sTiVPk">peinture en miroir</a> ! Par contre, très peu pour la correction des <em>crashs</em> lors du débranchement de tablette. :/</p>
<p>Et pourtant, je pense que j'ai contribué à améliorer la vie de bien plus d'utilisateurs par cette correction que je ne le ferai jamais par la peinture en miroir !</p>
<p>Un logiciel instable (c'est-à-dire qui <em>plante</em> très souvent. Tout logiciel peut avoir des plantages inattendus tant qu'ils sont rares), aussi bien soit-il au niveau fonctionnalités, est mauvais. Aussi simple que ça.</p>
<p><strong>Comment es-tu devenu développeur sur ce projet ?</strong></p>
<p>Je suis arrivé en cours de 2.8. La première fois que j'ai montré GIMP à <a href="http://girinstud.io/news/2015/03/about-the-authors-of-zemarmot/">Aryeom</a>, qui l'utilise maintenant quotidiennement, il n'était pas rare du tout de le voir se planter lamentablement. Donc j'ai décidé de corriger. Ce que j'ai fait.</p>
<p>Assez rapidement on m'a donné les droits en écriture car j'ai fourni plusieurs correctifs que Mitch, le mainteneur, a estimé de bonne qualité. Un jour, en juste 1 ou 2 mois, il m'a dit en substance : "tu me donnes trop de boulot, je te donne les droits sur le dépôt". Et c'est ainsi que je suis devenu un développeur GIMP.</p>
<p><strong>Tu as fait une demande de financement par les utilisateurs pour développer la fonctionnalité « Peinture en miroir », quelle a été ta démarche ?</strong></p>
<p>J'aimerais pouvoir développer plus de Logiciel Libre, c'est-à-dire être payé pour cela. Au <a href="http://fr.wikipedia.org/wiki/Libre_Graphics_Meeting">LGM</a> à Madrid, j'ai vu la fonctionnalité "peinture en miroir" sur Krita, et me suis dit que ce ne devait pas être trop compliqué. J'ai fait un prototype vite fait, puis un peu plus tard j'ai fait une vidéo, me disant que cela me motiverait pour la développer vraiment. En vrai je crois avoir choisi la mauvaise fonctionnalité (elle ne m'intéresse pas tant que ça. Je l'avais juste sous la main), et surtout ne pas avoir visé assez haut pour me donner envie de la faire rapidement.<br>
Au final j'ai pris plusieurs jours sur 2/3 semaines vers mars pour l'implémenter. J'aime vraiment faire du beau code, le plus générique possible, avec une architecture solide. J'ai donc transformé le cœur logique pour la peinture dans GIMP pour qu'il soit "multi-point". Bien que par défaut, il n'y ait qu'un seul point (sous le pointeur), il est maintenant possible de peindre plusieurs points simultanément, selon toute transformation mathématique qui passe par la tête (permettant de transformer les coordonnées, mais aussi la brosse). Sur la base de ce nouveau cœur, j'ai ajouté un module de peinture en mirroir (par rapport à des axes), ainsi qu'une peinture en rotation (par rapport à un point), et une peinture en tuiles (par translations multiples).</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f6c75742e696d2f63645133304b51592f7a5a445a5133774b/zZDZQ3wK" alt="Image mirroir" title="Source : https://lut.im/cdQ30KQY/zZDZQ3wK"></p>
<p><strong>Quelles sont les autres personnes derrière GIMP ?</strong></p>
<p>GIMP est un des fanions du Libre, à n'en pas douter. Néanmoins contrairement (quoique…) à d'autres gros projets Libres, le projet GIMP a un problème de sous-effectif et une organisation bien plus informelle. Ainsi, là où beaucoup de projets se regroupent sous une fondation, une association, voire une société, GIMP n'a aucune entité officielle. Il n'y a pas non plus de marque GIMP. C'est un projet à la structure totalement informelle, comme le sont en général les projets libres de petite taille.</p>
<p>Pour tout ce qui nécessite un nom plus officiel, par exemple afin de recevoir des dons aisément, le projet GIMP est sous le parapluie de la fondation <a href="http://gnome.org">GNOME</a>. Ainsi GNOME gère les finances de GIMP et héberge plusieurs de ses serveurs, ainsi que ses sources et son suivi de bugs. Néanmoins, le projet GIMP ne peut pas vraiment être considéré comme un projet GNOME. Il s'agit davantage d'une relation symbiotique où GNOME fait une faveur à un plus petit projet frère qui partage de nombreuses briques de base. Notamment, il est à rappeler que GTK+, le <em>toolkit</em> graphique à la base de GNOME, vient originellement du projet GIMP (GTK+ signifie « GIMP ToolKit »). Bien sûr, avec tant en commun, le projet GIMP suit de près les recommandations et évolutions GNOME, si possible, et les standards des bureaux Libres, tout en restant séparé. Ainsi GIMP n'a aucune dépendance à l'infrastructure GNOME (installer GIMP ne requiert pas l'environnement et le bureau GNOME) et est considéré comme indépendant.</p>
<p>GIMP a extrêmement peu de contributeurs actifs, en particulier pour un projet de cette taille. Ainsi, si on regarde les <a href="https://www.ohloh.net/p/gimp/contributors/summary">statistiques de contributions</a>, on se rend compte qu'un unique contributeur, Michael Natterer (Mitch), a fait plus de 60 % des commits sur la dernière année, suivi de quelques contributeurs actifs mais bien moins productifs (comme moi, avec pourtant seulement 4% des commits, je suis le second développeur C si on regarde sur un an!) et enfin énormément de contributeurs avec des patchs uniques. Mitch est bien entendu le mainteneur du projet GIMP.<br>
Néanmoins quand on considère GIMP, il faut dorénavant aussi prendre en compte <a href="https://www.ohloh.net/p/gegl/contributors/summary">GEGL</a> et <a href="https://www.ohloh.net/p/babl/contributors/summary">babl</a>, <a href="//linuxfr.org/news/gegl-0-3-0-et-babl-0-1-12-sont-de-sortie">briques désormais essentielles</a>, dont Øyvind Kolås (Pippin) et Daniel Sabo sont les mainteneurs. Les trois projets ont bien entendu beaucoup de développeurs en commun, bien que certains se concentrent clairement plus d'un côté ou l'autre.</p>
<p>Beaucoup de contributeurs beaucoup moins actifs dorénavant au niveau du code restent impliqués pour les décisions ou communautairement. Michael Schumacher par exemple est clairement l'administrateur de GIMP, s'occupant de toute tâche administrative (comme la gestion financière, les relations publiques ou notre relation avec GNOME).</p>
<p>Il est aussi à noter qu'à l'heure actuelle, aucun développeur n'est payé pour améliorer GIMP, à notre connaissance, pas même indirectement (je ne parle pas de mini-financements ponctuels, mais de développeurs à temps plein ou partiel sur du long terme).</p>
<p>Les développeurs GIMP ont très peu de rencontres physiques (le principal point de rencontre est le canal irc <code>#gimp</code> sur <code>irc.gimp.org</code>). Néanmoins, l'un des évènements désormais phare du projet est le <a href="http://libregraphicsmeeting.org">Libre Graphics Meeting</a>, chaque année, pour lequel GIMP est un sponsor majeur (sponsoriser l'évènement et défrayer les contributeurs est quasiment la seule grande dépense annuelle du projet). C'est l'occasion pour les contributeurs principaux de GIMP de pouvoir se rencontrer chaque année, et discuter du projet de vive voix. GIMP fait venir des contributeurs du monde entier, pour certains depuis des zones aussi lointaines que le Brésil, Israël et la Nouvelle-Zélande.<br>
Ci-dessous un aperçu d'une réunion de développeurs à l'université de Leipzig, en Allemagne, en mars 2014, lors de LGM 2014.</p>
<p><img src="//img.linuxfr.org/img/68747470733a2f2f636c6f75642e676e6f6d652e6f72672f7075626c69632e7068703f736572766963653d66696c657326743d386337353165303762373037646533336435343836616135656466616532623926646f776e6c6f6164/public.php?service=files&t=8c751e07b707de33d5486aa5edfae2b9&download" alt="Réunion de développeurs GIMP, à l'université de Leipzig, mars 2014, lors du Libre Graphics Meeting 2014" title="Source : https://cloud.gnome.org/public.php?service=files&t=8c751e07b707de33d5486aa5edfae2b9&download"><br>
Puis à Montréal à l'université de Toronto, au Canada, pour LGM 2015:<br><img src="//img.linuxfr.org/img/68747470733a2f2f6c75742e696d2f31787573655359722f4e32364c46466a69/N26LFFji" alt="GIMP BOF LGM 2015" title="Source : https://lut.im/1xuseSYr/N26LFFji"></p>
<p><strong>Comment GIMP tire-t-il parti du Google Summer of Code ?</strong></p>
<p>GIMP a été régulièrement un projet mentor du <a href="https://fr.wikipedia.org/wiki/Google%20Summer%20of%20Code" title="Définition Wikipédia">Google Summer of Code</a>, mais l'an dernier, le projet n'a pas été accepté et cette année, je crois qu'on n'a même pas essayé (sauf erreur, puisque je n'ai pas suivi).</p>
<p>Je pense que GSoC est une contribution intéressante et, en même temps, il faut relativiser l'apport. En général les résultats ne sont pas de qualité adéquate pour finir immédiatement dans l'arbre de développement de GIMP et ce même si le projet étudiant est qualifié de « succès » (l'étudiant a bien travaillé et il serait injuste de le faire échouer, mais le résultat final n'est pas pour autant d'une qualité suffisante pour intégration immédiate). Dans tous les cas, il reste beaucoup de travail d'intégration, de revue et d'assurance qualité une fois les projets achevés, ce qui est surtout un problème quand les étudiants disparaissent une fois la récompense empochée, ce qui n'est pas si rare (ce n'est pas non plus un reproche. Les étudiants ne promettent pas de rester, même si c'est bien sûr le secret espoir d'un projet Libre).<br>
Ainsi même les projets GSoC les plus éblouissants en démo vont prendre des mois, voire des années à être intégrés, pour atteindre le seuil de qualité adéquate.<br>
Ensuite cela serait moins un problème s'il y avait beaucoup de développeurs permanents, ce qui permettrait de faire beaucoup plus de revues de code, mais comme je le disais, on est au final très peu sur GIMP.</p>
<p>Néanmoins, le Google Summer of Code reste un apport intéressant pour les projets. Cela apporte du sang frais et des fonctionnalités inédites. J'espère personnellement que nous serons de nouveau dans la liste des organisations mentor un jour.</p>
<p><strong>GIMP n’a pas été retenu parmi les projets participants au GSoC cette année : sait-on comment s’opère la sélection ?</strong></p>
<p>J'ai demandé aux autres développeurs, un jour, et ils savaient pas non plus a priori. Les critères de sélection sont non divulgués par Google, il me semble. Donc non, je sais pas. Si je devais m'aventurer à deviner, je dirais que GIMP perd un peu de son aura ces dernières années car on n'a pas assez de sorties (trop espacées). Donc de l'extérieur, le projet peut avoir l'air mort, ce qui n'est pas du tout le cas. Une autre raison possible serait que notre propre intérêt pour le GSoC s'est affaibli. Comme je disais plus haut, plusieurs développeurs ont vu les limites du programme Google, et aussi ont peut-être estimé que leur temps pouvait être mieux utilisé plutôt qu'encadrer des étudiants pour du code qu'on n'est pas sûr d'utiliser. En tous les cas, au final, on n'avait que deux mentors intéressés l'an dernier (moi notamment car je n'y avais jamais participé et que ça m'intéressait de voir l'envers du décor) et — sauf erreur — seulement un cette année (pas moi cette fois, je n'avais pas le temps).<br>
Peut-être que Google a vu cela (nos listes de diffusion et discussions étant publiques), et a préféré donner du financement pour des projets plus à fond sur le programme ?</p>
<p><strong>Depuis des années, GIMP possède un système de greffons (<em>plug-ins</em>) ayant permis de nombreuses contributions extérieures au projet. Avec l’arrivée de GEGL, comment vois-tu ce système de greffon évoluer ? Risque-t-on de perdre l’immense base de greffons existants ?</strong></p>
<p>Dans GIMP 2.10, tout greffon qui marche en 2.8 est censé continuer à marcher. On reste dans la lignée de GIMP 2, donc la compatibilité est assurée. Si ce n'est pas le cas, alors il y a un bug, et dans ce cas faites-vous plaisir : remplissez des rapports de bug !</p>
<p>GIMP 3 par contre (future version majeure de GIMP qui suivra 2.10) pourra entraîner des changements d'<a href="http://fr.wikipedia.org/wiki/Interface_de_programmation">API</a>. Je ne suis pas certain lesquels, mais globalement je pense que les fonctions “dépréciées” à l'heure actuelle pourraient alors être retirées.</p>
<p>GEGL deviendra alors le moteur de GIMP pour tout ce qui touche aux données bitmap. Il est donc possible que certaines fonctions qui donnaient accès aux données bitmap à un autre niveau disparaissent dans GIMP 3.0. Mais ça ne voudra absolument pas dire que le développeur de greffons devra absolument passer par des nœuds GEGL pour modifier les images. Développer une opération GEGL est la voie préférée et conseillée dans lequel le projet GIMP se dirige à la place de greffons de type "filtres", mais les buffers GEGL ne sont pas des structures opaques, et sont accessibles aux greffons. Un développeur de greffons pourra tout à fait récupérer les données bitmap bruts, les modifier comme il faisait avant, puis les remettre dans le buffer. Il pourrait donc y avoir un peu de réécriture de code, mais rien d'insurmontable, et rien d'anormal pour un passage de version 2 à 3 ! Simplement ils ne pourront alors pas profiter de toutes les supers fonctionnalités permises par GEGL (visualisation directe sur le canvas, même partielle, édition non destructrice, création de graphes d'effets qui pourraient être réutilisés sur de multiples d'images sources, etc.).</p>
<p>Ensuite je ne suis pas le plus grand expert de GEGL chez GIMP (donc je peux dire des erreurs aussi), mais c'est ce qui ressort de ma petite expérience à manipuler l'API GEGL et parce que ce sont des choses que j'ai aussi demandées au mainteneur.</p>
<p>Par contre les thèmes qui utilisent des icônes fait-maison directement risquent d'être cassés car on utilise maintenant le <a href="http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html">standard des thèmes d’icônes</a>. Mais bon ce n'est pas le pire des cassages.</p>
<p>Personnellement ce qui m'intéresse bien plus serait d'avoir une vraie plateforme de diffusion et de gestion des greffons. À l'heure actuelle, installer un greffon est manuel : on trouve un bout de code ou une archive sur le net, on l'installe dans le bon répertoire, éventuellement on se heurte à des problèmes de droit, etc. Sans compter que l'on ne sait en général pas quelle version on a installée, donc les mises à jour sont inexistantes. Au final, comme tu dis, on a une immense base de greffons, mais les gens en utilisent très peu. Il y en a quelques uns qui sont très connus comme <a href="http://gmic.eu/">G'MIC</a>, grâce à une équipe de développement active, aussi bien pour le développement que la communication du projet.<br>
Mais tous ces petits greffons de quelques lignes, adaptés à certains cas d'usage très particuliers et qui pourraient vraiment sauver la vie (du moins la simplifier grandement) à certaines catégories d'utilisateurs ? Ceux-là sont perdus dans le grand internet, quelque part sur un serveur qui peut disparaître demain sans que personne s'en rende compte.<br>
Le projet GIMP a <a href="http://registry.gimp.org/">un dépôt où les gens peuvent déposer des plugins</a>, mais totalement envahi par le spam et le flood, donc l'enregistrement de nouveaux comptes est fermé depuis plus d'un an, sans compter que l'UI générale laisse clairement à désirer. J'aimerais qu'on ait une vraie plateforme de greffons, avec laquelle les utilisateurs pourraient installer, retirer et mettre à jour un greffon depuis GIMP même, avec de la sécurité (vérifications de code automatique et par des humains si nécessaire), un système de versionnement et de mise à jour des greffons, une spécification, etc.<br>
De mon expérience en tant qu'utilisateur, Firefox et WordPress sont de très bons exemples avec une vraie plateforme de gestion et téléchargement des greffons, et j'aimerais qu'on y pioche des idées.</p>
<p>J'ai en fait le projet de travailler sur une telle plateforme (et ai même déjà des bouts de code "stashed" quelque part sur mon ordi) et ça pourrait être mon prochain gros projet. Mais j'attends déjà de voir comment mon projet actuel (film d'animation 2D libre "ZeMarmot") se passe. Si ça ne marche pas bien, je ne sais pas si je continuerai longtemps. Si <a href="http://film.zemarmot.net">ZeMarmot</a> marche par contre, on pourrait voir une nouvelle proposition de financement pour cette plateforme dans quelques mois.</p>
<p><strong>Comment vois-tu les interactions entre GIMP et les autres projets libres ?</strong></p>
<p>Je pense personnellement que GIMP est un projet moteur du mouvement Libre, dont le but n'est pas uniquement de créer un logiciel, mais a suscité de nombreux autres projets. Il est ainsi à l'origine de briques essentielles comme GTK+ (qui est la base de nombreux programmes, que l'on aime ou non ce <em>toolkit</em> et son état actuel), et maintenant babl et GEGL, qui eux-mêmes seront à l'avenir — je pense — des briques majeures de nombreux autres projets. GIMP aussi participe activement aux discussions avec d'autres projets, et tente de suivre les standards pour un bureau de travail sain. Plutôt que de bosser dans son coin, la collaboration est clairement un créneau majeur, comme le montre l'intégration des brosses MyPaint, qui inaugure une ère nouvelle où les divers projets majeurs de l'image <em>raster</em> souhaitent collaborer et créer ensemble un <a href="http://libregraphicsworld.org/blog/entry/gimp-krita-mypaint-teams-discuss-common-brushpack-format">format de partage des brosses entre applications</a>.</p>
<p>Ceci sans parler du format <a href="http://freedesktop.org/wiki/Specifications/OpenRaster/">OpenRaster</a>, encore balbutiant et dont le développement est peu actif, mais qui pourrait être très important s'il va au bout des espérances, et dont GIMP est aussi un contributeur majeur pour la spécification.</p>
<p>C'est pourquoi, si vous avez le moindre problème avec GIMP, je conseillerai de faire un pas en avant et d'aider le projet, avec du code, du design ou de l'aide communautaire. Nous manquons de mains !</p>
<p><strong>À ce propos, quel est ton avis sur GTK+ comme boite à outils pour interface graphique et ses évolutions ?</strong></p>
<p>Personnellement je suis très peu intéressé par les guerres et trolls, etc. En fait je suis anti-spécialisé. Je m'intéresse à un peu tout, et le fait que je fais plus souvent du GTK+ dernièrement est essentiellement dû au fait que le hasard a voulu que les logiciels auxquels je me suis intéressé étaient en GTK+.<br>
Hors cela, je n'aurais aucun problème à développer en Qt demain si le prochain programme qui me faisait de l'œil devait être en Qt, ou en quoi que ce soit d'autre.<br>
Au final je fais avec ce que j'ai. Ce qui m'intéresse, c'est de faire quelque chose de bien. Le reste, c'est de la perte de temps.</p>
<p>Ensuite oui c'est pas parfait, et je m'y connais pas assez pour savoir comment c'est à côté, mais je doute qu'on change le <em>toolkit</em> de GIMP (surtout qu'il <em>vient</em> de GIMP !), donc bon. Plutôt que brasser du vent à rouspéter contre quelque chose qui ne changera pas, je fais avec; et franchement ce <em>toolkit</em> n'est pas si mal. :-)</p>
<p>Tout ça pour dire : GTK+, je m'en balance. C'est ce que je fais avec qui m'intéresse.</p>
<p><strong>Qu'est-ce que tu aimerais (voir) changer/améliorer dans GIMP ou son développement, quels sont les prochains sujets et même les futurs enjeux pour GIMP ?</strong></p>
<p>Au niveau fonctionnalité, mon gros chantier à l'heure actuelle, c'est l'animation, la peinture numérique et la consolidation de GIMP.<br>
Mon prochain gros projet, c'est les plugins. Je l'ai déjà dit plus haut. Je pense que c'est vraiment important qu'on ait une plateforme saine et cela devrait vraiment apporter un renouveau.</p>
<p>Ensuite il y a toute la partie "édition non destructrice" qui sera un bond majeur dans la manière dont les gens travaillent l'image avec les logiciels Libres.</p>
<p>Un autre point majeur est le design et l'interface utilisateur de GIMP qui souffre de sa vieillesse. GIMP se traîne des casseroles dues essentiellement à son âge (20 ans cette année !) et ce serait vraiment un projet très important, non seulement pour l'image du logiciel, mais surtout pour améliorer la simplicité d'utilisation. À vrai dire on a un tel projet avec Aryeom, et elle pense démarrer un groupe de design et UI pour GIMP dans l'année à venir.</p>
<p>Enfin un dernier gros point qui me chagrine est le cycle de sortie du projet : il est trop long. Ceci est aussi dû à l'âge du projet, d'une époque où on laissait les choses mûrir des années et où les utilisateurs compilaient eux-mêmes quand ils souhaitaient le logiciel plus vite. Mais de nos jours, il faut sortir plus vite, et passer à un cycle de sortie rapide. On devrait être capable de faire une sortie rapidement pour juste quelques corrections de bug, mais aussi pour des fonctionnalités. C'est quand même triste qu'on doive attendre des années pour utiliser des fonctionnalités qui sont déjà implémentées dans l'arbre de développement.</p>
<p><strong>Comment s'établit la feuille de route ?</strong></p>
<p>La feuille de route s'établit essentiellement par discussion. Les divers développeurs discutent, que ce soit sur IRC ou physiquement (sans sortir les poings !) lors de rencontres telles que Libre Graphics Meeting, et choisissent de ce qui est prioritaire ou non.<br>
Ensuite le reste, c'est aussi l'intérêt personnel. Si quelque chose est prioritaire pour moi, je le développe, le soumet à revue et c'est intégré même si c'était une basse priorité dans notre feuille de route.</p>
<p><strong>Contribues-tu également à d'autres logiciels ? As-tu des projets en rapport avec le logiciel libre dans un futur proche ?</strong></p>
<p>Oui, comme j'expliquais, quand je rencontre un problème ou un manque, mon premier réflexe est de chercher s'il n'existe déjà pas une solution, puis d'ouvrir un rapport de bug (ou demande de fonctionnalité) et enfin de corriger/implémenter moi-même s'il le faut (en estimant bien entendu le temps que j'y passerai comparativement avec mon désir d'avoir le bug corrigé ou la fonctionnalité disponible).<br>
Donc j'ai déjà des patchs dans une <a href="https://www.openhub.net/accounts/Jehan/positions">trentaine de projets d'après OpenHub</a>, et encore ce site ne compte pas tous les projets auxquels j'ai contribué sans le nom en auteur, notamment parce qu'ils utilisaient un dépôt de source qui n'a pas de concept d'auteur vs. committer, comme le vieillissant SVN. Ainsi j'ai par exemple <a href="https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/e6cdee370e74ef3e48051ad95a4bc3eba5f804c4">deux</a> <a href="https://git.blender.org/gitweb/gitweb.cgi/blender.git/commit/1ba194aeddef7a4d2859d7587b60c70c03387b1c">patchs</a> dans Blender (qui utilise <code>git</code> maintenant mais utilisait <code>svn</code> à l'époque où j'ai fourni ces patchs) et dans de nombreux autres logiciels dont je ne me souviens probablement même plus avoir fourni un patch.</p>
<p>Sinon j'ai créé l'outil <a href="//linuxfr.org/news/a-la-croisee-des-chemins-crossroad-environnement-de-cross-compilation">crossroad</a>, initialement justement pour cross-compiler GIMP pour Windows depuis GNU/Linux (c'est tellement horrible d'essayer de compiler des logiciels sous environnement Windows alors que c'est si simple sous GNU/Linux !).</p>
<p>Enfin, je pense que vous avez tous entendu parler ici de <a href="//linuxfr.org/news/financement-collaboratif-du-film-d-animation-libre-zemarmot">ZeMarmot</a>, un film d'animation Libre (Creative Commons BY-SA) en 2D, dessiné avec GIMP, édité avec Blender et Ardour. Dans ce contexte, je vais continuer à développer pour GIMP, mais aussi je vais travailler sur un nouveau logiciel pour la gestion d'un projet de film d'animation. Et ce sera cool. :-)<br>
D'ailleurs notre financement n'est pas terminé puisqu'on a eu droit à une prolongation de la plateforme. Donc si quelqu'un lit cet entretien, et souhaiterait contribuer, ce qui aidera à améliorer GIMP et d'autres logiciels Libres, <a href="https://www.indiegogo.com/projects/zemarmot-libre-movie-made-with-free-software/">vous êtes les bienvenus!</a>.<br><a href="https://www.indiegogo.com/projects/zemarmot-libre-movie-made-with-free-software/"><img src="//img.linuxfr.org/img/687474703a2f2f66696c6d2e7a656d61726d6f742e6e65742f696d616765732f737570706f72742d627574746f6e2d66722e706e67/support-button-fr.png" alt="Contribue à ZeMarmot" title="Source : http://film.zemarmot.net/images/support-button-fr.png"></a></p>
<p><strong>Pour ZeMarmot justement, tu utiliseras certainement beaucoup GIMP. GIMP est souvent vu comme un logiciel de retouche alors que Krita est présenté comme adapté à la peinture numérique… Quelle est ton opinion au sujet de ces deux logiciels et des outils de travail proposés ?</strong></p>
<p>Oui c'est une image de GIMP qui est selon moi totalement erronée. GIMP est très générique (le 'G' signifiait d'ailleurs <a href="http://www.gimp.org/about/ancient_history.html">"General" avant d'être renommé pour signifier "GNU"</a> à la place) et est fait notamment pour de la retouche photographique en effet, aussi bien que pour de la composition d'image, et de la création d'image, c'est-à-dire dessin, peinture… Cf. la description officielle:</p>
<blockquote>
<p>GIMP is the GNU Image Manipulation Program. It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring.</p>
</blockquote>
<p>Bien sûr, d'autres logiciels ont décidé de se spécialiser dans le dessin numérique, comme Krita ou MyPaint, tous deux de très bons logiciels d'ailleurs. C'est un choix totalement valide, mais au final on voit que ces derniers se mettent à recouper des utilisations de retouche photo et autre, avec des filtres, etc. Comme quoi tout est lié dans l'image et vouloir être <em>mono-utilisation</em> seulement a peut-être ses limites ?</p>
<p>Pour moi, aussi bien MyPaint, que Krita ou GIMP sont valables pour la peinture numérique. D'ailleurs je pense que les dessins d'Aryeom en sont la preuve, non ? Et elle n'est pas seule. Sur le web, on trouve de nombreuses perles, des dessins sous GIMP vraiment superbes techniquement. Maintenant c'est sûr que GIMP est 1000 fois moins fort en marketing que Krita, surtout ces dernières années où son mainteneur a décidé d'en vivre et fait donc très fort pour promouvoir ce dernier (ce qui lui a valu une bonne accélération, et c'est vraiment cool). Clairement GIMP a des progrès à faire du côté "marketing".<br>
Au final il est juste dommage que certaines personnes veuillent absolument reléguer GIMP à une partie seulement de ces capacités, et certains exprès, j'ai l'impression malheureusement. Des fois j'ai l'impression de voir les fans de Krita cracher sur GIMP et je ne comprends vraiment pas le but. Deux logiciels Libres ne peuvent-ils pas vivre en paix côte à côte?</p>
<p>En conclusion: GIMP est un très bon logiciel de dessin/peinture numérique, qu'on se le dise!</p>
<p>Je conclus donc avec l'affiche de notre film ci-dessous (que vous connaissez déjà ici) comme exemple, dessinée entièrement avec GIMP; désolé si vous vous dites que j'en fais trop! :p<br><img src="//img.linuxfr.org/img/687474703a2f2f66696c6d2e7a656d61726d6f742e6e65742f696d616765732f4d61726d6f745f41645f31303030783536332e6a7067/Marmot_Ad_1000x563.jpg" alt="Affiche de ZeMarmot" title="Source : http://film.zemarmot.net/images/Marmot_Ad_1000x563.jpg"></p>
<p><strong>Quels distribution et environnement graphique utilises‐tu ?</strong></p>
<p>J'ai été longtemps utilisateur Mandrake, puis Mandriva, puis Mageia. J'ai abandonné Mageia car j'avais trop de <em>petits</em> problèmes (petits, mais à force, ça devient majeur) qui rendaient mon utilisation quotidienne de plus en plus désagréable et malheureusement mes rapports de bug n'étaient quasiment jamais traités et simplement fermés lors d'une montée de version (j'aurais pu chercher pour corriger moi-même mais comme je disais plus haut, il faut quand même estimer le temps qu'on y passera et la priorité. Or là, c'était beaucoup plus simple de passer sur une autre distribution, donc priorité basse. Désolé aux contributeurs de Mageia du coin !). Dernièrement j'ai surtout utilisé Linux Mint (depuis plus d'un an), et globalement cela se passe bien. C'est tout de même une distribution bien maintenue et ficelée. Je n'ai plus aucun des problèmes que j'avais sous Mageia notamment. Ensuite elle manque de trucs excitants à mon goût. Je voudrais au moins tester GNOME 3 (et sous Mint, installer GNOME 3 tient du parcours du combattant à priori), donc je suis en train de considérer le passage à Fedora pour la première fois. Aucune idée si j'y resterai.</p>
<p>Sinon j'ai testé un peu Ubuntu à une époque, pas accroché du tout. Mon grand amour au niveau stabilité et fonctionnalité fut Gentoo. La seule raison pour laquelle je n'y reviens pas est le temps que cela prend à mettre en place, à compiler chaque paquet, à peaufiner les détails, etc. En même temps, c'est peut-être grâce à cela que c'est une si bonne distribution. Mais je n'ai plus le courage de passer des heures juste pour avoir mon environnement (même s'il est super). Maintenant je préfère que tout marche direct, même si c'est moins marrant et avec moins de fonctionnalités dernier cri.</p>
<p>Environnement graphique : j'ai pas mal testé, du KDE, du GNOME (2), WindowMaker, ion3 pendant un bon moment aussi. Mon environnement graphique préféré fut Openbox, puis Openbox+Cairo-dock. Malheureusement là aussi je n'y suis pas resté à cause de détails ici ou là. C'est vraiment dommage, je pense que ce sont vraiment les détails qui changent tout dans l'utilisabilité d'une solution informatique.<br>
À l'heure actuelle, je suis sur le Cinnammon par défaut de ma Linux Mint. Je n'y ai pas grand chose à redire, mais je n'en suis pas non plus fou et n'aurai pas de regret à le quitter.</p>
<p><strong>Merci pour l’entretien et pour ta contribution à GIMP !</strong></p>
<p>Et merci à vous pour les questions ! :-)</p></div><div><a href="https://linuxfr.org/news/entretien-avec-jehan-developpeur-gimp.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/102070/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/entretien-avec-jehan-developpeur-gimp#comments">ouvrir dans le navigateur</a>
</p>
antistressJehanBenoît SibaudJulien.DM5oulBAudpalm123Stéphane AuleryolivierwebDavid TschumperléEdBAnonymeesdeemhttps://linuxfr.org/nodes/102070/comments.atomtag:linuxfr.org,2005:News/365142015-06-16T10:30:23+02:002015-06-17T07:06:02+02:00GEGL 0.3.0 et babl 0.1.12 sont de sortieLicence CC By‑SA http://creativecommons.org/licenses/by-sa/4.0/deed.fr<div><p>Babl est une bibliothèque de conversion de formats de pixels. GEGL est un moteur de traitement d'images en graphe, construit autour de babl.</p>
<p>Ce sont deux bibliothèques nées du projet GIMP, qui constitueront son nouveau moteur interne d'édition d'image dès la version majeure suivante (GIMP 2.10, date de sortie non connue). Mais ce sont aussi bien plus que les moteurs de GIMP, ce sont surtout des projets indépendants qui commencent à être utilisés par d'autres projets, que ce soient des logiciels Libres, comme des services propriétaires.</p>
<p>De nouvelles versions viennent de sortir (GEGL 0.3.0 et babl 0.1.12), et je profite donc de l'occasion pour présenter ces logiciels, leurs spécificités, leurs historiques et leurs utilisations dans la seconde partie de la dépêche.</p></div><ul><li>lien nᵒ 1 : <a title="https://mail.gnome.org/archives/gegl-developer-list/2015-June/msg00000.html" hreflang="en" href="https://linuxfr.org/redirect/94361">Note de sortie sur la liste de diffusion</a></li><li>lien nᵒ 2 : <a title="http://gegl.org/babl/" hreflang="en" href="https://linuxfr.org/redirect/94386">babl</a></li><li>lien nᵒ 3 : <a title="http://gegl.org/" hreflang="en" href="https://linuxfr.org/redirect/94387">GEGL</a></li><li>lien nᵒ 4 : <a title="http://gimp.org" hreflang="en" href="https://linuxfr.org/redirect/94388">GIMP</a></li></ul><div><h2 class="sommaire">Sommaire</h2>
<ul class="toc">
<li><a href="#babl">babl</a></li>
<li>
<a href="#gegl">GEGL</a><ul>
<li><a href="#formats-dimages">Formats d'images</a></li>
<li><a href="#traitement-dimage-en-graphe">Traitement d'image en graphe</a></li>
<li><a href="#d%C3%A9veloppement-dop%C3%A9rations-maison">Développement d'opérations maison</a></li>
<li><a href="#scriptable">Scriptable</a></li>
<li><a href="#performance--opencl-et-multi-threading">Performance : OpenCL et multi-threading</a></li>
<li><a href="#traitement-de-tr%C3%A8s-grandes-images">Traitement de très grandes images</a></li>
</ul>
</li>
<li>
<a href="#utilisation-actuelle-de-gegl">Utilisation actuelle de GEGL</a><ul>
<li>
<a href="#historique-et-relation-%C3%A0-gimp">Historique et relation à GIMP</a><ul>
<li><a href="#un-avant-go%C3%BBt-de-gimp-210">Un avant-goût de GIMP 2.10</a></li>
</ul>
</li>
<li><a href="#int%C3%A9gration-dans-les-biblioth%C3%A8qes-graphiques">Intégration dans les bibliothèqes graphiques</a></li>
<li><a href="#autres-projets">Autres projets</a></li>
</ul>
</li>
<li><a href="#note-de-sortie">Note de sortie</a></li>
</ul><h2 id="babl">babl</h2>
<p><img src="//img.linuxfr.org/img/687474703a2f2f6765676c2e6f72672f6261626c2f67726170686963732f6261626c2d6134706f737465722e706e67/babl-a4poster.png" alt="babl" title="Source : http://gegl.org/babl/graphics/babl-a4poster.png"></p>
<p>Babl est une bibliothèque de conversion de formats de pixels. Quand on parle de formats de pixels, on entend la représentation du pixel en mémoire comme par exemple l'espace de couleur (RVB, CIE Lab…), une profondeur de couleur (nombre de bits utilisés par canal…) ou le type de données (entiers, flottants…), utilisés pour la représentation et non un format de fichier d'image pour enregistrer sur un espace de stockage.</p>
<p>Ainsi, cela permet par exemple de traduire des représentations de pixels RVB, RVBA, CMJN, CIE Lab, etc. Babl ne fait pas de traitement d'image dans le but de la modifier, mais uniquement des conversions (les seules modifications étant par exemple de la perte éventuelle de données si on passe à un format moins précis, ou de l'approximation entre deux formats qui ne sont pas parfaitement équivalents bijectivement).</p>
<p>Cette bibliothèque fournit une API extrêmement petite (le dépôt de source fait 4 Mo en tout, pour moins de 900 ko de code), simple et stable par conception.</p>
<h2 id="gegl">GEGL</h2>
<p><img src="//img.linuxfr.org/img/687474703a2f2f6765676c2e6f72672f696d616765732f4745474c2e706e67/GEGL.png" alt="GEGL logo" title="Source : http://gegl.org/images/GEGL.png"></p>
<p>GEGL est une bibliothèque permettant de traiter des images sous la formes de graphes de nœuds, chaque nœud pouvant avoir des entrées, sorties et une configuration.</p>
<p>Un nœud représente ce qu'on appelle une "opération". Typiquement, il y a des opérations servant principalement d'entrée à partir d'image stockées en mémoire ou sur disque, des opérations servant de sortie pour enregistrer ou afficher de nouvelles images, et des opérations intermédiaires servant de filtres mathématiques pour modifier l'image entre le nœud d'entrée et de sortie. Ces opérations intermédiaires sont par exemple:</p>
<ul>
<li>les filtres classiques que l'on aurait dans le menu "Filtres" de GIMP (flou, netteté, filtres artistiques, etc.);</li>
<li>des modifications des couleurs (balance, saturation, etc.);</li>
<li>de la composition (avec 2 images en entrée pour 1 en sortie, ce qui correspond notamment aux modes de composition des calques de GIMP : <em>normal, multiply, add, substract</em>, etc.):</li>
<li>des traitements plus utilitaires (découpe, redimensionnement, rotation, etc.):</li>
<li>…</li>
</ul><h3 id="formats-dimages">Formats d'images</h3>
<p>GEGL sait de base ouvrir et sauver de nombreux formats d'images, des plus classiques (PNG, JPEG, BMP, tiff…) aux formats plus spécialisés (RAW, OpenEXR…), et même des formats vectoriels (SVG…). En outre, il sait tirer profit d'autres sources, comme des fichiers vidéos (avec ffmpeg) ou de l'acquisition vidéo directe (v4l).</p>
<p>GEGL sait aussi tirer profit de très hautes précisions de couleur (<em>high bit precision depth</em>), permettant par là de travailler sur des images à 8, 16, 32 ou même 64 bits par canal (et en nombre entier ou flottant, avec codage linéaire ou correction gamma), ainsi que de charger et sauver les données en haute précision lorsqu'on utilise un format l'autorisant (comme ce sera le cas des <a href="http://libregraphicsworld.org/blog/entry/gimp-2.8-released-next-version-to-get-high-bit-depth-precision">fichiers d'image de GIMP, XCF, à la sortie de GIMP 2.10</a>).<br>
Cela permet des traitements intermédiaires complexes avec beaucoup moins de perte de données et de qualité.</p>
<h3 id="traitement-dimage-en-graphe">Traitement d'image en graphe</h3>
<p>Si un traitement simple (toute action basique sur une image) peut être représenté en un nœud unique avec l'image en entrée et le résultat en sortie, un traitement complexe est un graphe liant de multiples nœuds.</p>
<p>Schématiquement, travailler sur une image ressemble à l'éditeur de nœuds de Blender.<br><img src="//img.linuxfr.org/img/687474703a2f2f6d616e676f2e626c656e6465722e6f72672f77702d636f6e74656e742f75706c6f6164732f323031322f30342f73706c617368626f745f6e6f6465732d353430783233342e706e67/splashbot_nodes-540x234.png" alt="Éditeur de Nœuds de Blender" title="Source : http://mango.blender.org/wp-content/uploads/2012/04/splashbot_nodes-540x234.png"></p>
<p>Le traitement par graphe a deux intérêts principaux:</p>
<ol>
<li>Du <strong>traitement "non destructif"</strong> si l'interface logicielle le permet.
Cela implique un flot de travail où on ne touche jamais l'image originelle. Elle est en entrée, et toute modification du graphe influe sur les pixels dans le nœud de sortie (qui peut être théoriquement le même fichier que celui chargé en entrée, mais alors cela rend le concept moins intéressant).
On peut à tout moment supprimer ou modifier les paramètres d'une opération sans craindre pour l'image de base (plutôt qu'appliquer, voir, annuler, refaire avec d'autres paramètres, revoir, et ainsi de suite). Le concept de traitement non destructif rend donc presque caduque le concept d'historique et d'annulation des opérations.</li>
<li>La <strong>limitation de la dégradation d'une image</strong> qui se produit lors de l'application de filtres.
Un exemple explicite: une simple rotation d'image à 45° dégrade une image. Si on se rend compte qu'on préfère une rotation à 90° et qu'on applique donc une nouvelle rotation à 45° : on a alors dégradé 2 fois l'image et on se retrouve avec une qualité très amoindrie par rapport à l'original. Or une rotation à 90° directement se fait entièrement sans perte (puisqu'on travaille dans des matrices de pixels). Si on avait sauvé un graphe et qu'au lieu d'appliquer 2 rotations successives, on modifiait seulement les paramètres de la première rotation, on se retrouve avec un traitement sans perte. Bien sûr dans le cas général, on aura de la dégradation, mais celle-ci peut être limitée par la création d'un graphe optimal qui ne sera appliqué qu'une seule fois.</li>
</ol><h3 id="développement-dopérations-maison">Développement d'opérations maison</h3>
<p>GEGL est livré avec de nombreuses opérations par défaut, mais cela ne le rend pas exhaustif pour autant. La bibliothèque est conçue pour être étendue à volonté par les développeurs. </p>
<p>Vous avez besoin d'ajouter la prise en charge d'un format d'image maison ou peu répandu ? Vous avez besoin d'un filtre qui n'a pas été déjà développé, ou vous avez développé une version algorithmique bien plus efficace ? Vous avez besoin de traitements un peu particuliers qui servent spécifiquement à votre application et n'auraient aucun sens en <em>upstream</em> ? Il n'y a pas besoin d'attendre que vos opérations soient intégrées dans GEGL ou de le patcher. Vous pouvez créer et étendre GEGL à l'infini. </p>
<p>En ce sens, GEGL est un "cadriciel" (<em>framework</em>) pour la création d'opérations de traitement d'image.</p>
<h3 id="scriptable">Scriptable</h3>
<p>Grâce à l'<a href="https://wiki.gnome.org/action/show/Projects/GObjectIntrospection">introspection GObject</a>, cette bibliothèque est accessible à de nombreux langages tiers, notamment des langages de scripts (Python, Ruby, JavaScript, PHP…). Cela signifie notamment qu'il est possible de l'utiliser pour des petits scripts rapides ou en ligne de commande, et en augmente considérablement l'accès.</p>
<p>Bien sûr, certains <em>wrappers</em> existent déjà, permettant une encore meilleure intégration aux spécificités d'un langage. Le <a href="https://github.com/jsbueno/python-gegl">wrapper Python</a> est un bon exemple de bibliothèque maintenue.</p>
<p>Voici par exemple un court script Python pour inverser une image avec GEGL :</p>
<pre><code class="python"><span class="kn">import</span> <span class="nn">gegl</span>
<span class="n">x</span> <span class="o">=</span> <span class="n">gegl</span><span class="o">.</span><span class="n">Graph</span><span class="p">(</span><span class="s">"png-load"</span><span class="p">,</span> <span class="s">"invert"</span><span class="p">,</span> <span class="s">"png-save"</span><span class="p">)</span>
<span class="n">x</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span><span class="o">.</span><span class="n">path</span> <span class="o">=</span> <span class="s">"/home/user/input.png"</span>
<span class="n">x</span><span class="p">[</span><span class="mi">2</span><span class="p">]</span><span class="o">.</span><span class="n">path</span> <span class="o">=</span> <span class="s">"/home/user/output.png"</span>
<span class="n">x</span><span class="p">()</span></code></pre>
<p>Enfin, il est possible, avec l'outil console <code>gegl</code> fourni par défaut de lui passer des graphes d'opérations GEGL en XML, pour un traitement d'image scripté.</p>
<h3 id="performance--opencl-et-multi-threading">Performance : OpenCL et multi-threading</h3>
<p>GEGL prend en charge <a href="https://www.khronos.org/opencl/">OpenCL</a>, langage de programmation et bibliothèque « <em>conçu pour programmer des systèmes parallèles hétérogènes comprenant par exemple à la fois un CPU multi-cœur et un GPU</em> » (cf. <a href="http://fr.wikipedia.org/wiki/OpenCL">OpenCL sur Wikipédia</a>). En d'autres termes, cela permet de faire travailler votre carte graphique, en plus de votre processeur, en parallèle, pour accélérer les calculs.<br>
Cela couplé avec du traitement "<em>thread-safe</em>" (pour vous autoriser à utiliser du <em>multi-thread</em> dans votre propre code), et un début de <em>multi-thread</em> dans GEGL même, nous essayons d'obtenir une utilisation aussi performante que possible.</p>
<h3 id="traitement-de-très-grandes-images">Traitement de très grandes images</h3>
<p>Un des points forts de GEGL est sa gestion intelligente des <em>buffers</em> (objet gérant les données bitmap à l'aide des formats de pixel babl), permettant à l'utilisateur d'allouer une partie seulement de sa mémoire, mais également de travailler sur des images plus grandes que la mémoire disponible. Un <em>buffer</em> GEGL est une matrice de dalles, chacune pouvant avoir un <em>backend</em> de stockage différent, en particulier en mémoire RAM, ou en swap lorsque l'on dépasse la mémoire allouée.<br>
Dans l'avenir, on pourrait avoir un backend en mémoire GPU, en réseau, etc.</p>
<p>Cela permet ainsi d'avoir une majeure partie d'une image en mémoire, ainsi qu'une autre partie en swap disque, lors du travail sur de très grandes images. Le travail en dalle autorise aussi un travail plus efficace lorsqu'il s'applique sur de petites parties d'une image.</p>
<h2 id="utilisation-actuelle-de-gegl">Utilisation actuelle de GEGL</h2>
<h3 id="historique-et-relation-à-gimp">Historique et relation à GIMP</h3>
<p>GEGL est un projet très ancien avec pour raison initiale son intégration dans GIMP. Les plus anciennes annonces officielles de GIMP datent de <a href="http://www.gimp.org/about/prehistory.html">1995</a>, et le plus vieux commit daté du dépôt de source est du 1<sup>er</sup> janvier 1997. De son côté, le plus vieux commit daté du dépôt de source de GEGL est du… 2 janvier 1997, avec comme auteur "<em>People doing a 16 bpc version of gimp</em>" (traduisible en « personnes faisant une version de gimp à 16 bits par canal »). À un jour près, les dépôts de source des deux projets ont donc été créés quasiment en même temps. GEGL n'est donc pas seulement né de GIMP, c'est presque son frère ! Certains n'ont cependant pas cru en GEGL (du moins pas suffisamment pour y consacrer du temps, ce qui a même engendré un fork célèbre de GIMP), et il faut avouer que cela a pris son temps (presque 20 ans !).<br>
La <a href="http://www.gimp.org/release-notes/gimp-2.6.html">première tentative d'intégration n'est apparue qu'en 2008 dans GIMP 2.6</a>, soit 11 ans après la naissance du projet GEGL. Cette version comprenait seulement un port des opérations de couleur sur GEGL, optionnel (par défaut les opérations de couleur utilisaient toujours le code non GEGL) et un outil « GEGL » expérimental (donc non disponible par défaut dans la boîte à outils). Ainsi, cela initia un balbutiement du port où rien n'était activé par défaut, mais pouvait l'être par l'utilisateur aventureux.</p>
<p><a href="http://www.gimp.org/release-notes/gimp-2.8.html">GIMP 2.8 a vu plusieurs autres ports de fonctionnalités sur GEGL</a>, notamment la projection des calques, les modes de calques, les sélections flottantes et le redimensionnement des calques. Néanmoins là encore, tous ces ports restaient désactivés par défaut dans la version stable.</p>
<p>Ainsi, bien que GEGL soit présent dans GIMP depuis 7 ans, cette partie du code est techniquement inexistante pour les utilisateurs, du code mort, inutilisé, dans le reste du programme. Dans les faits, GIMP ne contient donc pas encore de code GEGL du point de vue de l'utilisateur de base. C'est en 2012 que, finalement, deux contributeurs majeurs de GIMP (Mitch, mainteneur de GIMP et Pippin, mainteneur de GEGL) se sont un jour enfermés chez Mitch sans vraiment le planifier, et ne sont ressortis à la lumière du jour que 3 semaines plus tard, <a href="http://gimpfoo.de/2012/04/17/goat-invasion-in-gimp/">après avoir porté 90 % du cœur applicatif de GIMP vers GEGL</a>.<br><img src="//img.linuxfr.org/img/68747470733a2f2f6769742e676e6f6d652e6f72672f62726f7773652f67696d702f706c61696e2f646174612f696d616765732f67696d702d73706c6173682e706e673f69643d31303731353032346262633132336539313566316333326662363533366538653565373439333235/gimp-splash.png?id=10715024bbc123e915f1c32fb6536e8e5e749325" alt="Invasion des chèvres" title="Source : https://git.gnome.org/browse/gimp/plain/data/images/gimp-splash.png?id=10715024bbc123e915f1c32fb6536e8e5e749325"></p>
<p>Ces 90 % n'étaient en fait que le début. Car en plus du cœur, il restait toute la plateforme applicative de GIMP (les greffons, filtres, etc.) à porter, l'interface graphique à mettre à jour pour profiter du nouveau cœur, les détails à fignoler et la bibliothèque à optimiser. </p>
<p>D'ailleurs, c'est seulement quelques mois après cet évènement que je suis arrivé moi-même dans ce projet : un peu par hasard aussi et sans le vouloir, un jour j'ai donné un patch. À l'époque, je n'avais même jamais entendu parler de GEGL. Eh bien, laissez-moi vous dire que la version de développement de GIMP, à ce moment là, était totalement inutilisable, et ce, encore jusqu'à il y a à peine deux ans, car si lente que l'on pouvait donner un coup de pinceau puis aller préparer un café en regardant le trait s'afficher (ou presque !). C'est seulement très récemment que la bibliothèque a été massivement optimisée et commence à peine à atteindre la vitesse de la version précédente du cœur de GIMP pour les opérations de base (voire est plus rapide, dans pas mal de cas).</p>
<h4 id="un-avant-goût-de-gimp-210">Un avant-goût de GIMP 2.10</h4>
<p>GIMP 2.10 sera donc la première version où GEGL sera utilisée, remplaçant le code originel de traitement d'image, ce qui est une étape majeure de l'histoire de GIMP. En fait, ce ne sera même pas une alternative. Tout traitement d'image utilisera désormais GEGL.</p>
<p>Cela donnera à GIMP la prise en charge de nombreux nouveaux formats de fichiers, de la haute précision de couleur, une prévisualisation (partielle ou totale) des effets directement dans le canvas pour peaufiner les paramètres, et surtout à terme du traitement d'image non destructif. Mais… ceci est une histoire pour une prochaine news… :-)</p>
<h3 id="intégration-dans-les-bibliothèqes-graphiques">Intégration dans les bibliothèqes graphiques</h3>
<p>Il existe plusieurs bibliothèques intermédiaires pour simplifier l'utilisation de GEGL :</p>
<ul>
<li>GTK+: <a href="https://git.gnome.org/browse/gegl-gtk/">GEGL-GTK</a>;</li>
<li>Qt: <a href="https://git.gnome.org/browse/gegl-qt/">gegl-qt</a>;</li>
<li>Clutter: <a href="https://git.gnome.org/browse/gegl-clutter">gegl-clutter</a>;</li>
<li>…</li>
</ul><h3 id="autres-projets">Autres projets</h3>
<p>Bien que GEGL soit né de GIMP, c'est avant tout dorénavant un projet à considérer comme une bibliothèque indépendante. Et nous espérons que de plus en plus de projets l'intégreront dans leur code.</p>
<p><a href="http://www.jonnor.com/">Jon Nordby</a> est l'un des grands implémenteurs de GEGL. Il a ainsi intégré GEGL comme <a href="http://www.jonnor.com/2012/05/mypaint-and-goats-at-lgm2012/">backend supplémentaire</a> dans <a href="http://mypaint.intilinux.com/">MyPaint</a>.<br>
Il a également expérimenté le traitement vidéo par GEGL en implémentant un <a href="http://www.jonnor.com/2011/05/geglfilter-gstreamer-element-for-manipulating-video-using-gegl/">filtre GEGL pour GStreamer permettant d'intégrer un graphe GEGL dans son traitement vidéo</a>, bien que celui-ci n'ait finalement pas été intégré <em>upstream</em>, non par intérêt des développeurs GStreamer, mais simplement par <a href="https://bugzilla.gnome.org/show_bug.cgi?id=650750">manque de temps pour le porter sur l'interface changeante du projet</a> (laissant ouverte la possibilité).<br>
Son dernier gros projet, <a href="https://github.com/jonnor/imgflo">imgflo</a>, est un <a href="http://www.jonnor.com/2014/04/imgflo-0-1-an-image-processing-server-and-flowhub-runtime/">serveur web pour le traitement d'image</a>, avec une interface graphique orientée graphes.<br><img src="//img.linuxfr.org/img/68747470733a2f2f7062732e7477696d672e636f6d2f6d656469612f426c434e484e3943414141463956682e706e67/BlCNHN9CAAAF9Vh.png" alt="imgflo" title="Source : https://pbs.twimg.com/media/BlCNHN9CAAAF9Vh.png"><br>
Jon Nordby étant désormais employé par <a href="https://thegrid.io/">The Grid</a>, plateforme commerciale de création de sites web générés par une intelligence artificielle, <strong>imgflo</strong>, et par conséquent <strong>GEGL</strong> est utilisé comme composant majeur pour toute l'automatisation des traitements d'image (ajustements de couleurs pour que les images utilisateurs s'adaptent au jeu de couleur du site, par exemple). Ce traitement passe par <a href="http://libregraphicsworld.org/blog/entry/artificial-intelligence-designs-websites-uses-open-technology-stack">imgflo-server</a>.<br>
Enfin le travail de Jon Nordby sur imgflo montre un des grands intérêts de GEGL : Jon a développé un format JSON pour déclarer des graphes GEGL qui peuvent alors être <a href="http://www.jonnor.com/2015/01/imgflo-0-3/">sauvés dans imgflo puis chargés dans GIMP</a>, par exemple. Il est ainsi très simple de partager des processus de travail complets entre applications pour automatiser des traitements sur de multiples images.<br>
Bien entendu, cela a permis plusieurs améliorations de GEGL, sponsorisées par <em>The Grid</em>.</p>
<p>En dehors de ce développeur très prolifique, <a href="https://wiki.gnome.org/Apps/Photos">GNOME-photos</a> dépend désormais de <a href="http://www.gegl.org/gegl-gtk/">GEGL-gtk</a>.<br>
Certains autres projets bien établis ont aussi montré leur intérêt pour GEGL. <a href="http://darktable.org">Darktable</a> par exemple avait <a href="http://www.darktable.org/2011/03/why-gimp-doesn%E2%80%99t-play-well-with-darktable/">entamé un port GEGL</a>, en 2011 déjà, et annoncé qu'ils le termineraient quand GIMP prendrait en charge la haute précision des couleurs <em>et</em> l'édition non destructrice, ceci afin de pouvoir partager une image entre les deux applications. On est donc à la moitié du chemin.<br><a href="http://blender.org">Blender</a> a aussi montré son intérêt pour GEGL, dans le but de mettre au niveau leur compositeur (« node editor », ou éditeur de nœuds en français), vieux et souffrant d'un design inadéquat pour de la composition efficace, comme le montre cette <a href="http://wiki.blender.org/index.php/Dev:Source/Node_Editor/Composite/Refactor">page de wiki</a> proposant l'usage de GEGL comme alternative à une ré-implémentation maison. Bien sûr, rien ne dit s'ils agiront dans ce sens au final, mais ce serait une très bonne nouvelle, bénéfique pour tous les projets.</p>
<p>Nous découvrons aussi des plus petits projets qui utilisent GEGL. Par exemple lors des <a href="http://libregraphicsmeeting.org/2014/">Libre Graphics Meeting 2014</a>, Manuel Quiñones a annoncé son début d'implémentation d'un logiciel d'animation 2D, <a href="https://github.com/manuq/xsheet">xsheet</a>. On ne sait pas vraiment ce que cela va donner, mais il est toujours intéressant de voir apparaître des développeurs extérieurs qui commencent à utiliser GEGL.</p>
<p>Ces divers exemples montrent bien que le projet atteint une certaine maturité, et il faut maintenant continuer dans cette voie.</p>
<h2 id="note-de-sortie">Note de sortie</h2>
<p>Nous terminerons par un survol de la liste des nouveautés dans GEGL 0.3.0 et babl 0.1.12, qui comptent 92 contributeurs.</p>
<ul>
<li>Amélioration du parallélisme et de la sécurité du multi-tâche.</li>
<li>OpenCL est désormais activé par défaut si détecté.</li>
<li>Multi-tâche expérimental, activé avec la variable d'environnement <code>GEGL_THREADS=<nombre de tâches></code>.</li>
<li>Rendu <em>mipmap</em> expérimental permettant la prévisualisation sur des versions de petite taille de manière transparente, avec la variable d'environnement <code>GEGL_MIPMAP_RENDERING=true</code>.</li>
<li>Nouveau site web, <a href="http://gegl.org/operations.html#GEGL%20operations">galerie d'opérations</a> et <a href="http://gegl.org/operations.html#Gegl">navigateur d'API</a>.</li>
<li>Découverte et documentation des opérations en ligne de commande, avec les options suivantes sur la commande <code>gegl</code>: <code>--list-all</code> (liste de toutes les opérations disponibles), <code>--properties</code> (imprime les détails d'une opération) et <code>--exists</code> (teste l'existence d'une opération).</li>
<li>Prise en charge des <em>URI</em> pour le chargement d'image.</li>
<li>Chargement de meta-opérations en format JSON.</li>
<li>Nouvelles opérations: alien-map, antialias, apply-lens, bilateral-filter, bump.map, cartoon, channel-mixer, color-enhance, color-exchange, color-reduction, color-rotate, convolution-matrix, copy-buffer, cubism, deinterlace, diffraction-patterns, distance-transform, displace, edge, emboss, engrave, exposure, fractal-trace, high-pass, image-compare, illusion, invert-gamma, lens-flare, linear, linear-gradient, mosaic, motion-blur-circular, motion-blur-zoom, noise-cell noise-cie-lch, noise-hsv, noise-hurl, noise-pick, noise-rgb, noise-simplex, noise-spread, n-point deformation ops, oilify, panorama-projection, photocopy, plasma, radial-gradient, red-eye-removal, scale-size-keep-aspect, softglow, stretch-contrast, texturize-canvas, tile-glass, tile-seamless, tile-paper, tile, warp, whirl-pinch, wind, cache, cast-format, lcms-from-profile, npy-save, webp-load, webp-save, scale-ratio, scale-size, seamless-clone, sinus, supernova, value-propagate, video-degradation</li>
<li>Réimplémentation de gaussian-blur (plus rapide et précis).</li>
<li>Nouveau backend de tuiles par défaut, écrivant sur le disque en tâche séparée.</li>
</ul></div><div><a href="https://linuxfr.org/news/gegl-0-3-0-et-babl-0-1-12-sont-de-sortie.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/106037/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/gegl-0-3-0-et-babl-0-1-12-sont-de-sortie#comments">ouvrir dans le navigateur</a>
</p>
JehanBAudbubar🦥palm123Benoît Sibaudpatrick_gRyDroidhttps://linuxfr.org/nodes/106037/comments.atom