Articles avec le tag ‘Gimp’

14 années de développement de Gimp

Le développement d’un logiciel tel que Gimp se fait sur de longues années, et par un nombre conséquent de personne. Pour vous donner une idée de la chose, j’ai fais une vidéo des changements intervenu sur le dépôt de code depuis 14 ans.

Une précision cependant, les 2 premières années du développement ne sont pas sur la vidéo car les logs ne sont pas disponible dans Git.

Cette vidéo a été faite avec le logiciel Gource, très sympathique au demeurant =)

Compiler Gimp avec LLVM/Clang et analyse statique

Clang, qui utilise l’infrastructure de LLVM, est un compilateur pour la famille de langage du C. Son but est d’offrir une alternative moderne à GCC. Avec Clang arrive notamment un très sympathique analyseur statique du code source. Nous allons appliquer ça à Gimp.

Pour ça, j’ai lâchement copié et adapté la procédure donné par Campbell Barton, de la team Blender. (http://wiki.blender.org/index.php/User:Ideasman42/BlenderClang).

Voici ce que ça donne à la sauce Gimp:

Etape 1: compiler LLVM/Clang

J’ai d’abord essayé avec la version fournis dans ArchLinux, mais Clang s’arrêtait avec une fatal error. Ça se passe bien mieux avec la version de développement. Pour la récupérer, le script de Campbell Barton fonctionne très bien.

Etape 2: configurer la compilation de Gimp

Déjà, il faut ajouter les binaires de LLVM dans le PATH:

export PATH=$PATH:/opt/llvm/bin

La seule différence avec une compilation classique, c’est qu’on demande explicitement le compilateur de CLang:

CC=ccc-analyzer ./autogen.sh --prefix=/opt/gimp/

Etape 3: compiler

Si vous voulez juste compiler, la procédure ne change pas.

make -j3

Si vous voulez lancer en même temps une analyse statique, il faut utiliser scan-build:

scan-build -o clang make -j3

Attention, une compilation avec analyse statique prend pas mal de temps (3h40 avec mon Core 2 Duo E4500).

Etape 4: profit !

L’analyseur statique de LLVM va probablement trouver tout un tas de bug dans le code. Il y a bien sûr des faux positifs, mais c’est dans l’ensemble remarquablement bien fait ! Vous trouverez le résultat de l’analyse de master que j’ai fait aujourd’hui ici: http://pellelatarte.fr/dawa/gimp-llvm/

Refactorisation et évolution de l’outil Cage

Hello,

Un article rapide pour vous dire que j’ai commencé un refactoring du code de l’outil cage de Gimp. C’est une étape nécessaire pour atteindre une bonne qualité de fonctionnement et une bonne base pour implémenter de nouvelle choses. Cela passe ici par une réécriture de la gestion de l’interface avec une machine à états (comme décrit ici il y a quelques jours),  des changements dans les structures de données, de la documentation, et pas mal de petites simplifications et corrections.

Pour l’avenir, une sélection multiple des points de la cage devrait arriver rapidement dans la branche soc-2010-cage-2. Ce mode d’édition fonctionnera de manière similaire à celui de l’outil chemin.

Un mode d’édition proportionnelle similaire à ce qu’on peut trouver dans Blender devrait voir le jour également.

Si ça se trouve, je vais finir par être satisfait de mon boulot un jour … =)

L’outil cage est dans la branche principale !

Gimp Cage Tool Splash

Ça y est ! Depuis 48h maintenant, le code de l’outil de déformation par cage est dans la branche principale de Gimp ! Il sera donc, sauf surprise, inclus dans la prochaine release, la 2.8 !

Un grand merci à mon mentor, Alexia Death et à Michael Natterer (Mitch) de s’occuper de cette fusion et du nettoyage qui l’accompagne.

Sortir du prototype

Hello,

Un peu de nouvelle par ici. Depuis quelques jours, j’ai pas mal discuté avec mon mentor et les développeurs de Gimp. Je suis arrivé à une étape de mon projet où une bonne partie des choses marche. L’idée est maintenant de passer du prototype à une version plus propre et efficace. Dans mon cas, comme j’ai beaucoup bricolé, ça veut dire quasiment une réécriture. Le fond est bon, mais la forme beaucoup moins. Cependant, ce travail est assez rapide et a déjà bien avancé.

Parallèlement à ça, j’ai commencé un algorithme qui permettra de calculer la transformation inverse. Je m’explique. Dans la majorité des opérations de transformation, c’est la transformation inverse qui est utilisée (on parcourt l’image cible, et on va chercher les pixels qui doivent être à cet endroit). Ça permet d’obtenir une bonne qualité d’image, en évitant notamment l’aliasing. Le problème dans mon cas, est que les coordonnées de Green, qui servent de base à ma transformation, ne décrivent qu’une transformation dans le sens direct. On obtient donc des images comme celle de mon dernier post. Il est possible de tricher, mais ça reste pas l’idéal. L’idée ici, c’est de calculer la transformation directe, de voir où ça va, et d’interpoler pour chaque pixel cible la position dans la source. Ça peut paraitre simple, mais en fait, pas vraiment. Mais ça progresse !

Shazam

une cage déformée

Ça y est, j’ai réussi une transformation par cage !

Bien sûr, ça reste assez moche et non-utilisable (les cages sont définis directement dans le code), mais ça marche ! Des améliorations devraient arriver bientôt (interface basique principalement).

Comme dirait quelqu’un, « on va quelque part finalement ».

Interactions

Cage Tool UIBien que ça ne soit pas prévu dans mes objectifs pour l’évaluation de mi-parcours, j’ai fait une bonne avancé sur la partie interface. Il est maintenant possible de créer une cage, d’y ajouter des points, d’enlever le dernier (touche backspace), et de fermer la cage.

La raison qui m’a poussé à faire ça est que je me suis trouvé réellement bloqué dans le projet, et j’avais besoin d’une partie un peu plus facile à coder. Ça m’a également permis d’aborder le cœur de l’algorithme sans me préoccuper de la partie Gegl, qui me paraissait très obscure à ce moment.

L’objectif maintenant est de traiter l’exact opposé de la chaine, c’est à dire le Gegl operator, ce que j’ai déjà commencé à faire. Je pourrais tester cette partie en utilisant le menu ‘Outils/Actions Gegl’ avec des cages prédéfinies dans le code. La liaison avec l’interface se fera plus tard.

Si vous voulez tester tout ça, bien qu’il n’y ai toujours pas grand chose à voir, vous pouvez récupérer et compiler ma branche (git://git.gnome.org/gimp, branche soc-2010-cage).
Je ferai probablement des versions prêtes à l’emploi quand il y aura plus de choses à tester.

Petite subtilité cependant, j’ai du faire une petite modification dans Gegl, mais qui n’est pas encore intégré dans le dépôt Git officiel. Il vous faudra donc appliquer le petit patch que voici à Gegl pour compiler ma branche:

diff --git a/gegl/Makefile.am b/gegl/Makefile.am
index 155758f..69a1916 100644
--- a/gegl/Makefile.am
+++ b/gegl/Makefile.am
@@ -36,6 +36,7 @@ GEGL_public_HEADERS = \
gegl-plugin.h                      \
gegl-version.h                     \
buffer/gegl-buffer.h               \
+    buffer/gegl-buffer-iterator.h              \
property-types/gegl-paramspecs.h   \
property-types/gegl-color.h                \
property-types/gegl-path.h         \

Commit du soir, espoir

J’ai fait hier soir mes premiers commit dans ma branche (il était temps !). Concrètement, il n’y a pas grand chose à voir, c’est simplement un outil complètement stupide qui affiche un carré sur l’image quand il est activé, mais ça veut dire que les choses avancent. Le code derrière tout ça est près à recevoir des choses plus concrètes.

Je commence à être plus à l’aise dans le code source, grâce à la patience des développeurs de Gimp (merci à Mitch en particulier !).

Comme vous pouvez le voir sur la capture, j’ai fait une icône correctement moche. Si vous vous sentez près à faire mieux, n’hésitez pas ! Il faut créer deux versions de l’icone, une de 22 pixels de large et une autre de 16. Les icones des autres outils sont là, pour références: http://git.gnome.org/browse/gimp/tree/themes/Default/images/tools

C’est reparti !

L’évolution de mon SoC

Et non, je n’ai pas encore abandonné.

Jusqu’à maintenant, j’ai passé une bonne partie de mon temps (celui qu’il me restait en enlevant les examens), à apprendre. Comprendre comment fonctionne un logiciel de 4,5 millions de ligne n’est pas une chose facile, vous l’aurez deviné. Voilà ce qui m’a pas mal occupé:

  • Git: le gestionnaire de version utilisé par Gimp. Je suis assez familié de Subversion, mais le passage à Git prend un peu de temps, surtout si on a une branche à soi.
  • Les Gobject: c’est une librairie qui permet de faire de la programmation orienté objet (POO) en C, qui est utilisée dans une bonne partie des projets Gnome, Gimp compris.  Ça change tellement la façon de coder en C que c’est quasiment un nouveau langage. Pour tout dire, ma réaction en voyant ça a été un truc du genre « c’est possible ça ? ». Assez perturbant, mais je commence à en venir à bout.
  • GEGL, BABL, et l’architecture en général: mon outil sera composé d’une série d’objet (opération Gegl, structure de donnée, interface, …), et créer cette architecture présuppose d’avoir bien compris comment fonctionne Gimp en interne. Je commence à en voir le bout également.

Cette étape est, je pense, la plus difficile et prend un temps certain. Mais j’en verrai le bout !

Libre Graphics Meeting

Libre Graphics Meeting

Ce week-end, je suis allé au Libre Graphics Meeting, à Bruxelles, où j’ai pu rencontrer mon mentor. Au programme du week-end, des conférences sur le graphisme libre bien sûr, mais aussi des workshops et pour moi, une des rares réunion « en vrai » de l’équipe Gimp.

Ce qui m’a un peu surpris au premier abord, c’est que les gens présent sont très normaux. On pourrait penser qu’il n’y a que des vieux geek barbu, mais en fait pas du tout. Il y a des gens très différents, des jeunes, des vieux, des hommes, des femmes. Bien sûr, il y a plus de barbu et de cheveulu que dans la moyenne de la population, mais quand même.

En tout cas, pour un bleu comme moi, c’est une expérience très impressionnante. En plus de la barrière relative du langage, on se retrouve devant des gens qu’on voyait auparavant associé à des projets assez dingues. Je pense en particulier à la team Blender qui était présente, et qui a présenté l’évolution du projet Sintel.

Même si ce week-end n’a pas été spécialement utile dans le cadre strict de mon projet, c’est très intéressant de mettre des visages sur des noms ou des pseudos, de voir comment tout ça fonctionne. Ça permet également de voir qu’il y a des gens derrière en cas de soucis, et c’est très appréciable. Coucou Alexia =)