Articles avec le tag ‘summer of code’

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 !

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 =)

Histoire d’un Summer of Code

Summer of Code 2010
Pour ceux qui ne le savent pas, voici en résumé ce qu’est un Summer of Code. Google propose, depuis 2005, à des étudiants du monde entier (sauf pays sous embargo), de travailler pendant les grandes vacances sur des logiciels libres. Ce programme connait un grand succès, autant du coté étudiant que du coté des différents logiciels.

Pour l’étudiant, l’intérêt de la chose est multiple. Le programme met le pied à l’étrier dans le monde du logiciel libre, rapporte une grosse expérience, de grosses compétences, des contacts, et accessoirement un petit paquet de cash.

Pour les différents logiciels (des organisations dans le langage Google), le Summer of Code apporte du sang frais, des nouvelles idées, et un gros morceau de code pour le logiciel.

Je vais donc, vous l’avez compris, réaliser bientôt un Summer of Code. Pourquoi ? Et bien, outre les éléments que j’ai mentionné au dessus, j’avais envie d’apporter ma pierre à l’édifice du logiciel libre. C’est également pour moi une sorte d’épreuve du feu pour mes compétences en informatique. Si j’arrive jusqu’au bout, je sais que je serai capable de beaucoup de chose en programmation. Car il ne faut pas se leurrer, un SOC, c’est un très gros projet. À l’heure actuelle, rien ne me prouve que j’y arriverai. Mais j’y vais quand même :p

La mascotte de Gimp

Le projet que j’ai proposé est de créer un nouvel outil de déformation d’image pour le logiciel de dessin 2D The Gimp. C’est un des logiciels phare du monde du libre et il est utilisé par un bon paquet de personnes.

Mon outil sera basé sur une publication de l’université de Tel-Aviv publié au Siggraph 2008. L’article se nomme « Green Coordinates », et décrit un nouveau système de coordonnées qui permet de réaliser des déformations grâce a des cages, dans un espace à N dimensions. La méthode à ceci d’intéressant quelle permet de préserver au maximum les formes des objets déformés.

La publication est très technique, c’est des maths qui tachent. Je remercie au passage les enseignants chercheurs qui m’ont aidé à la compréhension de la chose et à la conversion en une méthode applicable à la 2D.

Un exemple de déformation par cage

Mon outil aura plus ou moins le comportement suivant:

  1. l’utilisateur a une image complète ou une sélection à déformer
  2. l’utilisateur trace une cage autour de la zone a déformer (un polygone fermé)
  3. l’utilisateur déforme la cage, l’image est déformé au mieux

Alors comme ça, ça peut paraitre un poil abstrait, mais j’ai sous la main une vidéo qui devrait être plus explicite. Cette vidéo présente des déformations par cage, mais elles ont sous le capot des méthodes différentes de la mienne. Les déformations seront donc un peu différentes, mais le principe reste similaire.

Voilà, je termine cet article avec le document qui ma servi de support pour la réunion technique avec les développeurs de Gimp. Il reprend ce que je viens de décrire, mais en allant bien plus dans les détails du fonctionnement de l’algorithme. Par contre, il est en anglais  (haha).