Pelle la tarte.

Posts Tagged ‘Gimp’

The development of a software like Gimp is done during long years, and by many peoples. To let you see this work, I made a video of the modification done on the code repository for 14 years.

A quick note however, the first 2 years of hacking is not on the video since the related logs are not available on git.

This video was made using Gource, pretty cool software =)

Clang, which use LLVM infrastructure, is a compiler for the C language family. His goal is to offer a moder alternative to GCC. With Clang come a pretty cool static analyser. Here is how to use it for Gimp.

A small disclaimer before, I shamefully copied and adapted the procedure given by Campbell Barton, form the Blender team. (http://wiki.blender.org/index.php/User:Ideasman42/BlenderClang).

Step 1: compile LLVM/Clang

I first tried the LLVM provided by ArchLinux, but the compilation ended with a fatal error. It goes flawlessly with the development version. To fetch it, Campbell Barton’s script works well.

Step 2: configure Gimp’s compilation

First, we need to add  LLVM’s binary to the PATH:

The only difference with a classic GCC compilation, is that we explicitly ask to use Clang’s compiler:

Step 3: compile

If you just want to compile, the procedure doesn’t change.

If you want to run a static analyse, you have to use scan-build:

Just be aware that a static analyse will take a lot of time (3h40 with my Core 2 Duo E4500).

Etape 4: profit !

The static analyzer of Clang will probably find a lot of bug in the code. Yes, there is false positive, but it’s globally remarkably well done ! You can find here the result of the analyse of master i did today: http://pellelatarte.fr/dawa/gimp-llvm/

Hi,

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

Hi,

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 !

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

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://git.gnome.org/gimp, 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:

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: http://git.gnome.org/browse/gimp/tree/themes/Default/images/tools

Here we go again !

No, I haven’t give up.

Until now, I spent much of my time (that I have left after working for my exams), in learning. Understand how a 4.5 millions line software work is not an easy task, you guessed it. This is what kept me quite busy:

• Git: the version control system used by Gimp. I’m quite used to Subversion, but switching to Git take some time, especially when you have your own branch.
• Gobect: it’s a library that allow to use object-oriented programming in C, which is used by a large portion of Gnome’s project, including Gimp. It changes so much the way you code in C that it’s almost a new language. To be honest, my reaction on seeing that was something like “is that possible ?”. Quite disturbing, but I’m starting to overcome.
• GEGL, BABL, and architecture in general: my tool will consist of a series of Gobject (Gegl operation, data structure, GUI, …), and creating this architecture assumes that you well understand how Gimp works internaly. I’m beginning to see the end as well.

This step is, I think, the most difficult, and takes times. But I will end it.