Archive pour la catégorie ‘Summer of Code’

Et voilà, on est déjà à la mi-parcours pour le Google Summer of Code, et je n’ai pas posté de mise à jour comme je le voulais. Il faut croire que réflechir et coder reste plus amusant pour moi qu’écrire. Néamoins, corrigeons ça.

Le moins que l’on puisse dire, c’est que l’outil warp (il va falloir que je trouve une traduction française) est en bien meilleure forme que l’outil cage à la même époque l’an dernier. La raison est simple, j’ai appris énormement l’an passé, et il faut bien avouer que l’outil warp fait appel à des compétences similaires, voir reprend quelques portions de code.

Ceci étant dit, voilà le bilan:

• Toute l’infrastructure de l’outil est en place et fonctionnelle.
• On peut appliquer des déformations directement sur le canvas.
• 7 comportements sont supportés actuellement:
  • déplacement de pixels
  • grossissement d’une zone
  • rétrécissement d’une zone
  • spirale dans le sens horaire
  • spirale dans le sens anti-horaire
  • effacement local d’une transformation
  • lissage local d’une transformation
• Les actions sur le canvas se font grâce à un pinceau rond, avec une courbe d’influence gaussiene.
• Les réglages du pinceau sont la force, la taille et la dureté de la courbe d’influence (plus ou moins raide).

Une petite vidéo pour la forme:

Les différentes opérations effectuées sur le canvas sont implémentées comme des opérations Gegl qui produisent un buffer de coordonées relatives, que l’on insère dans le graph de rendu. L’image finale est calculée grace à une opération de rendu map-relative.

Et voilà ce qu’il reste à corriger:

• Les performances restent à améliorer. Actuellement, à chaque action sur l’image, chaque opérations déjà effectuées est recalculées (le cache ne fonctionne pas correctement), et ce pour toute la surface de l’image (un problème dans le code historique qui n’a pas été conçu pour ça). D’autres pistes d’amélioration existent, comme l’implémentation du Copy On Write (COW) pour les GeglBuffer. Le but final est d’effectuer les actions de manière interactive.
• Un bon réglage est nécessaire, les différents comportements ne sont pas cohérents actuellement.
• Implémenter l’interface selon les spécifications de Peter Sikking et de son équipe.
• Implémenter l’annulation des opérations.

Comme j’ai plus de facilités cette année, j’en profite pour aller un peu plus en profondeur et de travailler sur des choses annexes, en particulier dans Gegl. Une chose intéressante est de constater que l’outil warp est structurellement assez proche d’un moteur de dessin (dans le sens pinceau), et fait donc un pas de plus vers un moteur de dessin basé sur Gegl dans Gimp.

Et voilà. Cette année encore, je vais participer au programme Google Summer of Code !

Ma participation à l’édition de l’an dernier aura été pour moi un énorme défi, un moyen d’apprendre énormément de chose, de rencontrer et côtoyer des gens très intéressants, et une grande source de fierté (même pour ma famille, c’est dire si le nom de Google veut dire quelque chose pour la société d’aujourd’hui).

Cette année, je vais pouvoir mettre à profit toutes ces connaissances engrangés l’an dernier pour réécrire l’ancien plugin iWarp comme un véritable outil interne à Gimp (dont le petit nom sera le Gimp Warp tool). C’est un outil qui a longtemps été demandé par les utilisateurs de Gimp. Là encore, cet outil s’intégrera dans la « grande vision » du futur de Gimp (Gegl, prévisualisation directement sur l’image, ..).

D’un point de vue plus personnel, il est clair que ma tâche de cette année présente moins de défi que l’an dernier (un autre outil de déformation, structure relativement proche ..), et c’est presque dommage. Néanmoins, c’est toujours sympathique de travailler sur un projet comme Gimp, et les utilisateurs le rendent bien la plupart du temps. Et puis, il faut bien faire travailler son cerveau pendant l’été =)

Cette fois, je devrais être capable de faire cet outil de la bonne façon, dès la première fois (et donc éviter les 3 ou 4 réécritures partielles qui ont suivit la période officielle de développement du programme Summer of Code). Avec un peu de chance, cet outil pourrait être intégré à Gimp 2.8. Le début de la période de code est finalement pas si loin !

A bientôt !

Cela fait maintenant quelques temps que je n’ai pas posté de news a propos de de l’outil cage. Il est même resté quelques mois sans changements, quand je me suis mis en tête de coder un ERP adapté au Junior-Entreprise. J’y ai passé quelques heures aujourd’hui, et je me suis dit qu’il serait temps de faire un petit bilan des changements depuis ce temps:

• comme annoncé précédemment, une réécriture de la gestion de l’interface sous forme d’une machine à état, avec pas mal de nettoyage (et quelques régression également, il faut avouer)
• utilisation d’une structure de donnée spécifique, ce qui permet ..
• la sélection multiple des poignées, avec une sélection par ruban, pour pouvoir éditer une cage plus rapidement, ou simplement la bouger en entier d’un coup
• la possibilité de revenir dans dans le mode d’édition de la cage, et ajuster la cage de départ
• quelques optimisations dans l’opérateur Gegl qui effectue la transformation

Il reste des bugs à attraper, le plus évident étant que l’image se décale après un retour en mode d’édition. Mais promis, ça sera près pour la sortie de Gimp 2.8 ! D’ailleurs, les dernières corrections se feront a partir de maintenant dans la branche master de Gimp, donc ce n’est plus la peine de récupérer la branche de l’outil.

Pour fêter tout ça, j’ai fait un rapide screencast avec un lézard comme victime.

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

Ç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.

Hello,

Un internaute à fait une petite revue de mon outil de déformation par cage et l’a publié sur le site d’une communauté d’utilisateur de Gimp. C’est sur le site GimpUser.com !

L’article contient notamment une vidéo de l’outil en action !

En tout cas, ça fait vraiment plaisir de voir que la chose plait, et que c’est utile =)

Il faut vraiment que je trouve du temps pour fignoler tout ça (interface et optimisation surtout) …

Voici une liste d’astuces, de techniques que j’ai apprise durant mon Summer of Code. Elle est livré un peu en vrac, et peu, ou non, vous intéresser.

Allocation mémoire avec la Glib:

allocation mémoire pour des objets:

allocation simple:

Coder pour Gimp

debug des gobject et erreurs glib

debug des evenements GTK

autogen.sh

compiler sans optimisation

installation rapide des binaires uniquement

Gobject

les gobject, c’est mal.

si vous avec un warning relatif au gobject, essayer un make install

quelque chose cloche ? essayez un make install

Babl

déclarer un format

convertir des formats avec un Babl fish

Gegl

creer un buffer

buffer leak

Git

push dans une branche distante

garder la branche à jour

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 !

Ç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 ».