Écosystème Logiciel de GIMP

GIMP est un logiciel libre de traitement d'images matricielles. La dernière version mineure — GIMP 2.8.4 — est sortie en février 2013. Cette sortie s'accompagne principalement de corrections de bug et de divers changements mineurs.

Ce qu'il est intéressant de noter est qu'en plus d'être un logiciel phare du monde du libre, GIMP est très extensible. Ainsi de nombreux greffons y sont développés, dans des langages de programmation variés (C/C++, Scheme, Python ou Perl), et plusieurs outils gravitent autour de ce logiciel. Cette dépêche revient sur quelques-uns de ces outils qui furent récemment présentés par la communauté LinuxFr.org.

Pack My Sprites

Pack My Sprites est un outil qui génère des feuilles de sprites à partir d'une ou plusieurs images au format XCF. Il s'agit d'un outil développé au sein de Stuffomatic durant la production d'Andy's Super Great Park. Il est écrit en C++ et diffusé sous les termes de la GPL 3.

Xcftools

Xcftools est une suite d'outils en ligne de commandes pour extraire des informations de fichiers au format XCF. Ces commandes sont :

• xcf2pnm, pour convertir un fichier XCF en un fichier Portable_anymap ;
• xcf2png, pour convertir un fichier XCF en un fichier Portable_Network_Graphics ;
• xcfview, pour afficher un fichier XCF à l'écran ;
• xcfinfo, pour extraire des informations sur les calques d'un fichier XCF.

Les outils de conversion permettent de choisir les calques à utiliser et même de changer leur mode de composition.

xcf-utils

xcf-utils est une suite d'utilitaires similaire à xcftools, mais bien plus récente et basée sur la libgimp plutôt qu'une réimplémentation du format. Elle fut développée par le Studio Girin pour palier à un manque dans la gestion de fichiers XCF versionnés, et contient deux outils :

• xcf-info, similaire à xcfinfo des xcftools, mais plus complète ;
• xcf-diff pour comparer deux fichiers XCF.

Ces outils peuvent être avantageusement utilisés dans un flot de travail git comme outil de diff, ce que le Studio Girin utilise pour versionner des fichiers XCF lors de la production d'animation 2D. Une telle configuration de travail sera expliquée dans le cours de cet article.

Plus d'informations sur ces différents outils autour de GIMP en deuxième partie de dépêche. Merci à Julien Jorge et Jehan pour leur participation à cette dépêche.

Sommaire

• Pack My Sprites
  • Exemple d'utilisation
  • Obtenir l'outil
  • Améliorer l'outil
• Xcftools
  • Reprise du développement
  • T'es le bienvenu
• xcf-utils
  • Implémentation
  • Usage en Console
  • Usage dans votre Flot de Travail git
• Conclusion : GIMP, Couteau Suisse du Traitement d'Images, et le Futur

Pack My Sprites

L'idée au départ de Pack My Sprites était de réduire autant que possible le temps qui séparait la réalisation d'une image dans GIMP et sa visualisation dans le jeu. En effet, avec un outil classique de création de feuilles de sprites, il fallait répéter les étapes suivantes à chaque fois que l'on voulait voir l'image dans le jeu :

• Dimensionner l'image à sa taille finale ;
• Sélectionner les calques du sprite et masquer les autres ;
• Exporter l'image dans un fichier png ;
• Répéter les deux étapes précédentes pour chaque image ;
• Lancer le logiciel de création de feuille de sprite ;
• Sélectionner les images ;
• Générer la feuille.

Chacune de ces étapes est répétitive et inutile, et devrait donc être automatisée. Il fallait donc un logiciel de création de feuille de sprites qui fonctionne directement avec les images sources : les fichiers XCF créées avec GIMP.

Il existe de nombreux outils de créations de feuilles de sprites : Sprite Sheet Packer, Texture Packer, glue, darkFunction Editor, Nanimstudio… Pack My Sprites se distingue sur différents points :

• il travaille directement avec les fichiers XCF plutôt qu'avec des images intermédiaires ;
• il fonctionne sans interface graphique afin de faciliter l'automatisation de la génération des feuilles de sprites (glue est aussi un outil en ligne de commandes) ;
• il sait générer des fichiers Makefile qui recréent les feuilles de sprites quand les fichiers XCF sont modifiés.

Exemple d'utilisation

Voici une capture de la fenêtre de GIMP dans laquelle est dessinée une animation d'un oiseau qui vole :

Pour produire la feuille de sprites depuis cette image et une autre, on écrit le fichier suivant décrivant chaque sprite de l'animation :

/* file bird.spritedesc */
sprite_sheet "bird" 256 x 256 order "height"

/* The source images. */
fly "bird-fly.xcf.bz2"
afraid "bird-afraid.xcf.bz2"

/* The sprites. */
"afraid" autosize * 0.33 with afraid
  "eyes"
  "beak"
  "body"
  "tail"
;

"fly 1" autosize * 0.33 with fly
  "body"
  "eyes"
  "back wing 1"
  "wing 1"
;

"fly 2" autosize * 0.33 with fly
  "body"
  "eyes"
  "back wing 2"
  "wing 2"
;

"fly 3" autosize * 0.33 with fly
  "body"
  "eyes"
  "back wing 3"
  "wing 3"
;

/* etc. */

Puis on exécute la commande suivante pour générer la feuille de sprites :

pack-my-sprites bird.spritedesc

La commande produit deux fichiers. La feuille de sprites :

Et un fichier contenant la position et la taille des sprites dans la feuille :

fly 1: 0 0 75 84
fly 2: 76 0 75 84
fly 3: 152 0 75 84
fly 4: 0 85 75 84
fly 5: 76 85 75 84
fly 6: 152 85 75 84
fly 7: 0 170 75 84
fly 8: 76 170 75 84
afraid: 152 170 94 69

Obtenir l'outil

L'outil est disponible depuis son site Web ainsi que sur GitHub. Il n'y a pas de paquets pour les distributions pour l'instant. Son utilisation nécessite l'installation de xcfinfo et de gimp.

Améliorer l'outil

La version mise en ligne a été suffisante durant le développement de notre jeu, mais elle peut encore être améliorée. Par exemple, au niveau de la syntaxe du fichier de description des sprites, la liste des fichiers XCF utilisés est le résidu d'une contrainte obsolète de l'application et est pénible à maintenir. On gagnerait à supprimer cette liste et à les nommer directement lors de la déclaration d'un sprite.

L'algorithme de placement des sprites dans la feuille est assez rudimentaire. Plusieurs méthodes de calculs existent et mériteraient d'être explorées.

L'utilisation de xcfinfo et gimp se fait par un appel à popen(). Pour le premier, on lit le résultat de la commande pour récupérer les informations sur les calques, pour le second on passe un script Scheme qui génère l'image finale. Ce serait plus classe si on passait directement par une bibliothèque de manipulation des XCF.

Enfin, comme l'outil s'appuie sur xcfinfo, il ne pourra pas être disponible sous Windows tant que Xcftools ne l'est pas non plus.

Xcftools

Les outils de Xcftools ont soudainement prit un coup de vieux avec la sortie de GIMP 2.8 et ses groupes de calques. En effet, Xcftools a été écrite pour gérer les images de la version 2.6 de GIMP et même si elle arrive à extraire des informations des images au nouveau format, le résultat n'est pas toujours celui espéré.

Reprise du développement

Cette suite d'outils a initialement été développée par Henning Makholm. La dernière version est sortie en juillet 2009, sous licence GPL 2 d'après le site de l'auteur, ou dans le domaine public d'après les sources.

Stuffomatic était particulièrement intéressé par l'outil xcfinfo, notamment pour Pack My Sprites ; c'est pourquoi un patch a été envoyé à l'auteur pour y ajouter la gestion des groupes de calques. Comme nous n'avons pas reçu de réponse, le projet a été forké sur GitHub pour y ajouter ce patch et reprendre un peu le développement.

T'es le bienvenu

Les premières modifications faites ont été d'ajouter l'affichage de la hiérarchie des calques dans xcfinfo, puis d'entamer une migration du système de construction vers CMake afin de pouvoir compiler pour Windows (c'est la branche cmake sur GitHub). En effet, la suite utilisait un mélange d'autotools et de scripts divers qui, combinés avec quelques macros bien placées dans le code, permettaient d'obtenir un logiciel qui compile. Vous l'aurez compris, ces outils sont développés en C.

Les outils me conviennent très bien dans leur état actuel. Cependant il est clair qu'ils sont incomplets tant qu'ils ne gèrent pas correctement les groupes de calques ; c'est pourquoi il n'est pas évident de packager tout de suite une nouvelle version. De plus, aucune des améliorations entrevues ne motive les repreneurs ; c'est pourquoi une aide de la communauté ou l'utilisation d'un nouvel outil est espéré.

Idéalement il faudrait adapter le code d'aplatissement de l'image afin de prendre en compte le mode de composition des groupes de calques. Il faudrait aussi gérer les groupes quand les calques sont passés en paramètres au programme. Dans l'absolu on pourrait utiliser libgimp pour composer les images au lieu de refaire les algos en interne. Ça me semblerait bien plus simple mais on s'éloignerait de la philosophie initiale de l'outil.

xcf-utils

xcf-utils est une suite d'utilitaires très similaire à xcftools. Elle est née du besoin du Studio Girin de suivre les changements sur les images XCF versionnées dans un dépôt git. Comme beaucoup le savent en effet, gérer des fichiers binaires dans des systèmes de versionnement perd plusieurs avantages habituels du versionnement, en particulier il est impossible de comparer les fichiers de manière objective avec les outils de base. Il faut donc se limiter aux commentaires, parfois trop succincts, avec les limites que cela implique, notamment pour traquer un bug graphique involontaire.

Or git a cette fonctionnalité d'attributs qui permet de spécifier un outil pour comparer des fichiers binaires. Il ne me restait plus qu'à trouver un outil en ligne de commande pour « traduire » un XCF en texte.

Bien entendu les xcftools furent testés en premier, mais ils étaient non maintenus depuis des années, le développeur ne répondait pas à au patch qu'on lui avait envoyé depuis des semaines, et ils étaient bien trop basiques. En particulier xcfinfo ne donnait aucune information sur le contenu (le bitmap) des calques. En outre ils ré-implémentent le format XCF de GIMP, alors que les développeurs eux-même considèrent ce format comme une sorte de « dump mémoire » de la structure d'une image dans GIMP, avec une documentation quasi inexistante ou vieillotte. Il n'y a en effet aucune volonté de compatibilité avec des outils externes, uniquement dans le cadre d'une utilisation dans GIMP même.

Vouloir forker les xcftools est possible uniquement si on a le courage de suivre l'évolution d'un format non documenté pendant des années, ce qui n'était absolument pas le cas du Studio Girin, même si son développeur est aussi développeur GIMP.

Il fallait donc une solution plus pérenne.

Implémentation

C'est ainsi que furent démarrés les xcf-utils. Ils se reposent sur la libgimp, ce qui leur permet d'avoir à tout moment l'implémentation officielle du format, et ont été testés avec succès sur GIMP 2.8 et 2.9 (version de développement).

D'abord développés en python, ils ont été ré-implémentés en C en juste quelques heures, ce qui montre la petite taille du source code et la facilité de maintenance, malgré le nombre de fonctionnalités déjà bien supérieur aux xcftools.

Le code source est hébergé chez TuxFamily, disponible sur le web ou bien directement par git :

git clone git://git.tuxfamily.org/gitroot/xcfutils/xcfutils.git

La liste d'outils n'est qu'au nombre de deux à l'heure actuelle : xcf-info (pendant du xcfinfo des xcftools) pour lister le contenu d'un XCF, et xcf-diff pour comparer deux versions d'un même XCF.

Voici une liste des fonctionnalités supplémentaires que xcf-info des xcf-utils a déjà, comparé à xcfinfo des xcftools:

• Arborescence en arbre pour les groupes de calques (le fork de Xcftools a aussi la gestion des groupes) ;
• hash du bitmap de calque, pour vérifier si le dessin a changé ;
• tatouages de calques, ce qui permet de suivre un calque d'une version à l'autre, même après avoir changé nom et dessin ;
• liste les chemins ;
• hash des chemins, ce qui permet aussi de suivre leur édition ;
• mode de précision de l'image (utile seulement pour les versions à venir, puisque GIMP a maintenant la gestion des images 16 et 32-bit, entier et flottant, dans la version de développement).

Néanmoins les xcf-utils ont un désavantage majeur : ils sont bien plus lents que les xcftools. À titre d'exemple, là où un xcfinfo sur une image XCF peut prendre quelques centièmes de seconde, il prendra quelques secondes avec xcf-info.

La raison est double : premièrement les xcf-utils hashent le bitmap entier de chaque calque ; deuxièmement la libgimp nécessite GIMP, ainsi chaque fois que vous exécutez un utilitaire des xcf-utils, GIMP est lancé en mode console sans que vous ne vous en rendiez compte, ce qui a un temps d'initialisation et de finalisation bien trop grand.

La conclusion à cela est que si vous souhaitez un utilitaire rapide et basique pour simplement voir le nombre de calques, leur nom et dimension, les xcftools sont plus adaptés ; par contre, si vous souhaitez un outil avancé et à jour pour inspecter en détail un XCF et pouvoir même comparer le bitmap, seuls les xcf-utils peuvent vous être utiles.

Usage en Console

Les xcf-utils, tout comme xcftools sont faits pour être utilisés en console avant tout.
Voici la sortie de xcf-info sur un XCF de test:

jehan@DarkMarmot $ xcf-info test_1.xcf
32 bit integer RGB Image "test_1.xcf" 610x377
┎──────┒
┃LAYERS┃
┖──────┚
☑ Layer [8] "Calque #4" (Difference)
  610x377 with α — Hash: 415d7516f458b96148aea0501d935fc1
  Opacity: 29,4% — Has mask
☐ Layer [7] "Calque #3" (Normal)
  610x377 with α — Hash: e5a3c644962a7141077c5cebf1069ce9
☑ Layer Group [4] "Groupe de calques" (Normal)
  ☑ Layer [6] "Calque #2" (Multiply)
    610x377 with α — Hash: 9b760e039b86eef1e0a96c34da4e9c4f
    Opacity: 62,0%
  ☑ Layer [5] "Calque #1" (Normal)
    610x377 with α — Hash: f736844b2e08e5277358d2880884d156
☑ Layer [3] "Calque" (Overlay)
  610x377 with α — Hash: f736844b2e08e5277358d2880884d156
☑ Layer [2] "Arrière-plan" (Normal)
  610x377 — Hash: 6081ea405bd31c2ae6e8c6cde70bb8e9
┎─────┒
┃PATHS┃
┖─────┚
☐ Path [17] "Chemin"
  Hash: 3d2ac4ba3c67c72c257be53995681ac6
☐ Path [10] "Sans nom"
  Hash: f19eae1e61bb341ff2a429fd768f69eb

Pour comparer, voici la sortie de xcfinfo des xcftools sur le même fichier :

jehan@DarkMarmot $ xcfinfo test_1.xcf
Warning: XCF version 4 not supported (trying anyway...)
Version 4, 610x377 RGB color, 7 layers, compressed None
+ 610x377+0+0 RGB-alpha Difference/29%/mask Calque #4
- 610x377+0+0 RGB-alpha Normal Calque #3
+ 610x377+0+0 RGB-alpha Normal Groupe de calques
+ 610x377+0+0 RGB-alpha Multiply/61% Calque #2
+ 610x377+0+0 RGB-alpha Normal Calque #1
+ 610x377+0+0 RGB-alpha Overlay Calque
+ 610x377+0+0 RGB Normal Arrière-plan

Comme vous pouvez le constater, il manque les informations de chemin, les groupes, le tatouage des calques et leur hash.

Aussi ce XCF a été créé avec GIMP 2.9 comme image 32 bits, ce que xcfinfo ne voit pas.

Enfin, j'ai fais le choix d'être un peu plus verbeux sur le sens de chaque valeur et de mieux séparer les textes.

xcf-diff quant à lui n'a pas d'équivalent dans les xcftools et a pour but d'afficher uniquement les changements entre deux XCF. Cela le rend beaucoup plus rapide que xcf-info car des optimisations peuvent être faites.

jehan@DarkMarmot $ xcf-diff test_1.xcf test.xcf
Image renamed from "test_1.xcf" to "test.xcf"
Layer "Calque #3" [7]'s compositing mode changed from Normal to Dissolve.
Layer "Calque #1" [5] abandoned by parent "Groupe de calques" [4].
Layer "Groupe de calques" [4] renamed "Groupe".
Layer "Calque" [3] adopted by parent "Groupe" [4].
Layer "Arrière-plan" [2]'s offsets changed from (0, 0) to (22, 0)
Layer "Arrière-plan" [2]'s drawing changed.
Some Layer changed position.

Usage dans votre Flot de Travail git

Là où cela devient intéressant est d'intégrer ces outils dans votre système de versionnement préféré (s'il le permet. git le permet, svn non, et je ne sais pas pour les autres. À vos commentaires !).

Ainsi, créez ou ajoutez ces lignes à votre .gitattributes (note: GIMP permet d'ouvrir et sauver vos images compressées avec gzip, bzip2 et, bientôt, xz):

*.xcf diff=gimp
*.xcf.xz diff=gimp
*.xcf.gz diff=gimp
*.xcf.bz2 diff=gimp

Puis cela dans votre .git/config:

[diff "gimp"]
    textconv = xcf-info

Voici alors ce qu'un git show affichera quand vous modifierez votre image tel que plus haut :

commit c484d087b9beed17582be9c21bc88b52d28ec3f4
Author: Jehan <...girinstud.io>
Date:   Tue Feb 19 20:07:06 2013 +0900

    Bouge "Calque #1" hors du groupe.
    Bouge "Calque" dans le groupe.
    Renomme le groupe.
    Change le mode de "Calque #3".
    Change le dessin de "Arrière-plan".
    Bouge l'offset de "Arrière-plan".

diff --git a/test.xcf b/test.xcf
index f603581..90ed877 100644
--- a/test.xcf
+++ b/test.xcf
@@ -1,22 +1,23 @@
-32 bit integer RGB Image "Y2hbPJ_test.xcf" 610x377
+32 bit integer RGB Image "o086Lf_test.xcf" 610x377
 ┎──────┒
 ┃LAYERS┃
 ┖──────┚
☑ Layer [8] "Calque #4" (Difference)
   610x377 with α — Hash: 415d7516f458b96148aea0501d935fc1
   Opacity: 29,4% — Has mask
-☐ Layer [7] "Calque #3" (Normal)
+☐ Layer [7] "Calque #3" (Dissolve)
   610x377 with α — Hash: e5a3c644962a7141077c5cebf1069ce9
-☑ Layer Group [4] "Groupe de calques" (Normal)
+☑ Layer Group [4] "Groupe" (Normal)
+  ☑ Layer [3] "Calque" (Overlay)
+    610x377 with α — Hash: f736844b2e08e5277358d2880884d156
   ☑ Layer [6] "Calque #2" (Multiply)
     610x377 with α — Hash: 9b760e039b86eef1e0a96c34da4e9c4f
     Opacity: 62,0%
-  ☑ Layer [5] "Calque #1" (Normal)
-    610x377 with α — Hash: f736844b2e08e5277358d2880884d156
-☑ Layer [3] "Calque" (Overlay)
+☑ Layer [5] "Calque #1" (Normal)
   610x377 with α — Hash: f736844b2e08e5277358d2880884d156
 ☑ Layer [2] "Arrière-plan" (Normal)
-  610x377 — Hash: 6081ea405bd31c2ae6e8c6cde70bb8e9
+  610x377 — Hash: f39205c3df12040cc6b81b8ab1d4bf9d
+  Offsets: (22, 0)
 ┎─────┒
 ┃PATHS┃
 ┖─────┚

Ainsi je vois exactement ce que ce commit a modifié, en plus du commentaire. Notez par exemple ici qu'il y a eu beaucoup de déplacements de calque, des offsets, un renommage, mais que le seul et unique hash modifié est celui de l'arrière-plan. Cela signifie que c'est le seul dessin modifié, ce qui est une info primordiale en cas de traque de bug graphique ou de conflit de commit. Ainsi, pour la gestion de conflit, toutes les autres modifications sont « simples » et aisées à « merger » à la main avec un autre commit : un seul calque dans cet exemple aura à être scruté si et seulement si les deux commits en conflit ont modifié le dessin de ce calque.

Bien entendu, je préférerais utiliser xcf-diff dans mon flot git, car ses informations sont plus concises (comparé à ce diff sur deux xcf-info séparés), vont à l'essentiel, et surtout est énormément plus rapide. Malheureusement, je n'ai jamais trouvé comment faire cela parfaitement. J'ai joué avec la configuration d'un outil diff externe mais cela ne fonctionne pas par type de fichier. Le mieux que j'ai pu trouver est de passer par un script de « reroutage », et d'en faire mon outil diff externe générique. xcf-diff a une option --git-diff qui permet d'émuler ce système de routage.

Pour cela, au lieu de la configuration précédente, ajoutez ceci dans votre .git/config:

[diff]
    external = xcf-diff --git-diff

Cela permet d'adapter xcf-diff au format git-diff (avec 7 paramètres) et de rerouter vers git les fichiers non-XCF.
Votre prochain git diff utilisera alors xcf-diff. Par contre git show n'utilisera pas par défaut xcf-diff dans ce type de configuration. Vous devez explicitement appeler git show --ext-diff ou bien faire un alias quelconque.

Bien sûr, si quelqu'un a une solution plus élégante, je suis tout ouïe.

Conclusion : GIMP, Couteau Suisse du Traitement d'Images, et le Futur

GIMP est un de ces vieux dinosaures du Libre, qui a donc une place particulière dans nos cœurs malgré ses défauts. Né en 1996, il se veut un outil générique de manipulation d'image. D'ailleurs, fut un temps où le "G" initial signifiait "General", bien qu'il ait changé pour "GNU" depuis.

Notez qu'il existe de nombreux autres outils graphiques Libres, et certains sont meilleurs que GIMP dans des domaines précis. Par exemple MyPaint se spécialise dans le dessin numérique. Si vous voulez du dessin vectoriel, vous devriez regarder du côté d'Inkscape ; et ainsi de suite. Pour rencontrer les développeurs de ces outils ou connaître le futur des outils graphiques, je rappelle d'ailleurs que vous pouvez vous rendre au Libre Graphics Meeting très bientôt.

GIMP lui, se pose comme l'homme à tout faire de l'image raster, où nous voyons ainsi des gens y faire du pixel art, des sprites de jeu vidéo, du dessin, des animations, de la retouche photo… Ses possibilités avancées de scripting, permettant de faire par des scripts automatisés presque tout ce que vous pouvez faire dans son interface graphique, ou bien d'ajouter des fonctionnalités à la dite interface, y sont évidemment pour quelque chose. Il ne tient donc qu'à vous de spécialiser cet outil générique pour votre activité et d'automatiser vos tâches répétitives.

Et le futur réserve encore bien des surprises, avec l'arrivée des images 16 et 32-bits, d'outils repensés (par exemple un outil de transformation unifié bien plus pratique que plusieurs outils épars), mais surtout le développement d'une librairie indépendante de manipulation d'images, GEGL, qui devrait permettre à terme d'avoir une édition non destructive de vos images (vous pourrez ainsi notamment tester et appliquer des effets, en changer la configuration, puis revenir en arrière et retrouver votre image d'origine à tout moment), ou encore le port vers GTK3.

Le Libre a encore de beaux jours devant lui dans le monde de l'image !

Aller plus loin

• Pack My Sprites (44 clics)
• xcftools sur GitHub (28 clics)
• xcf-utils chez TuxFamily (50 clics)
• Release Notes de GIMP 2.8 (17 clics)