Posts Tagged ‘summer of code’

Refactoring and evolution of the Cage tool


A quick post to let you know that i started a refactoring of the Gimp cage tool. It’s a mandatory step to achieve a good quality and a solid basis to implement new things. It happens here by rewriting the frontend code as a state machine (as described here a few days ago), change on the data structure, documentation, and a lot of small fixes and simplifications.

In the future, a multi-points selection should come in a few days in the soc-2010-cage-2 branch. This editing mode will work in a similar way as in the path tool.

A proportional editing mode, similar to what you can find in Blender should come too.

Maybe i’ll start to getting satisfied of my work someday… =)

Cage tool is on Master !

Gimp Cage Tool Splash

That’s it ! For now 48h, the new Cage tool in on master branch of Gimp ! It will be, unless big surprise, in the next release, the 2.8 !

A big thanks to my mentor, Alexia Death, and Michael Natterer (Mitch) to take care of this merge, and for the cleaning step that come with.

Moving from prototype


Some news here. In recent days, I talked a lot with my mentor and the others Gimp’dev. In my projet, I’m now in a state where a good part of things works. The idea is now to move from a prototype to a more cleaner and efficient form. In my case, since I’ve done a lot of experiment and workaround, it mean almost a full rewrite. The background is good, but the form isn’t. However, this work is quite fast and already well advanced.

Along with that, I started a algorithm that will compute the inverse transformation. Let me explain. In the majority of processing is the inverse transformation is used (we run over the target image, and we fetch pixel that should be there). It allow to achieve good image quality, in particular by avoiding aliasing. The problem in my case, is that the Green Coordinates, which form the basis for my transformation, only describe the forward transform. We therefore obtain images like that of my last post. Cheating is possible, but it’s still not ideal. The idea here is to calculate the direct transformation, to see where it goes, and interpolate for each target pixel the position in the source. It sounds easy, but in fact, no. But things are moving !


une cage déformée

Finally, I managed to do a cage transformation !

It’s still ugly and non-usable (cages are defined directly inside the code), but it works ! Improvements should arrive soon (mainly basic interface).

As someone said, “we are going somewhere”.

User interaction

Cage Tool UI

Even if it’s not in my todo-list for midterm evaluation, I did a good progress on the interface part. It’s now possible to setup a cage, add point, remove the last (backspace key), and close the cage.

The reason why I did that is because I was really stuck in the project, and I needed to code a part a bit less difficult. It allows me as well to approach the core of the algorithm without worrying of the Gegl part, which was especially unclear to me at this time.

The target is now to tackle the exact opposite of the chain, ie the Gegl operator. This part is in progress. I will be able to test this part by using the menu ‘Tools/Gegl Operation’, with some cage defined directly on the code. The link with the interface will come later.

If you want to test that, even if there is not much to see, you could fetch and compile my branch (git://, branch soc-2010-cage).

I’ll probably do compiled version when there will be much to test.

Subtlety, however, I had to make a small change in GEGL, but not yet integrated into the official Git repository. You will have to apply the following patch to Gegl in order to compile my branch:

diff --git a/gegl/ b/gegl/
index 155758f..69a1916 100644
--- a/gegl/
+++ b/gegl/
@@ -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         \

First commits

I did yesterday few commits in my branch (it was about time !). Concretely, there is not much to see, it’s just a completely stupid tool which display a square on the image when he is activated, but it mean that things are progressing. The code behind that is ready to receive something more useful.

I’m getting more familiar with the Gimp’s code base, thanks to the patience of the dev’ (special thanks to Mitch !).

As you can see on the screenshot, I made a nice ugly icon. If you feel able to do better, don’t hold back ! I need a 22 pixels square icon and another of 16 pixels. You can have a look on the icons of the other tools, for inspiration:

Here we go again !

Libre Graphics Meeting

Libre Graphics Meeting

This weekend, I went to the Libre Graphics Meeting, in Brussels, where I met my mentor. Program of the weekend, conference on the FLOSS graphism of course, but also some workshop, and for me, one of the rare meeting in real life of the Gimp Team.

When I came to this event, I was a bit suprised to see that peoples here was quite normal. One might think that there will be only old geeky nerd, but actually, not at all. They were very different people, old, young, man, woman. Of course they were more hair than usual, but still.

In any case, it was for me an impressive experience. Besides the relative language barrier, I faced some people that I saw earlier with projects rather crazy. I refer in particular to the Blender team who was present,  who presented the progress of Sintel.

Even if this weekend wasn’t especially productive for my project, it was very interesting to put some face on names or nickname, to see how the things works. It allow also to see that they are people behind, in case of trouble. And that’s really cool. Hey Alexia =)

Summer of Code’s story

Summer of Code 2010For those who don’t know yet, here is summarized what is a Google Summer of Code. Google propose, each year since 2005, to student from all over the world to work during their vacation on Free Software. This program know a huge success, both on the student and software side.

As you probably understood, I will soon realize a Summer of Code. Why ? Because in addition to what a gsoc bring to the student (huge experience, contact, huge entry on the resume, cash, …)  I wanted to make one’s contribution to the free sofware world. It’s also for me a sort of ordeal by fire. If I can do this project, I will know I can do a lot of things in computer science. It’s a huge project for me, and nothing prove that I’ll be able to complete it. Anyway, I’m going to do it :p

La mascotte de Gimp

The projet I proposed is to code a new tool for the 2D drawing software The Gimp.

Better than rewrite what will be my tool, I will copy here an extract from my gsoc proposal:

Green Coordinates is a cage-based deformation method that allow, unlike the other method, shape-preserving mapping and usage of partial cage. The research paper was published in Siggraph 2008

Unlike the other classical method (mean value coordinates, harmonic coordinates, ..), the Green Coordinates allow high quality deformation by preserving the shape. That mean that you don’t have side effect like shear. Example can be found in the paper. However, a restriction, the figure 14 show a deformation of the outside of the cage, that requires a cutting of the outside. Since this cutting will result in difficult usage, difficult implementation and anyway, not so good result, I wont do that part. However, I can extend smoothly the deformation trough only one edge of the cage, what will cover in my sens, most of the needs.

Two examples of what my tool can do, that the Gimp cannot do easily right now:

  • Narrow morphing : you have an image with a character. You put a cage around his arm and fold it smoothly, with keeping the detail of the picture.
  • Partial growing : same image as before. You want to grow some part of his body. You cut-out the body or the part needed, you put a cage around and grow it as you like.

Un exemple de déformation par cage

The basic behavior of this tool would be:

  • you “put” a closed polygon on the image (not limited to 4 handles)
  • you deform the cage, the image is deformed accordingly
  • user can choice if the pixels can go outside of the cage or not. In the normal behavior of the Green Coordinates, the pixels can overflow the cage due to the shape preservation.

I also have a video of a such a cage deform tool. But keep in mind that my tool will use a different technique that those used on this video, so it will be slightly different.

I end this article with the document that I used as a support for the technical meeting with The Gimp’s dev. It describe a bit more what i’ve explained here, especially on the algorithm part.

You probably saw that my english is not perfect. If anyone want to correct this, let me know, I’ll be very happy =)