Pelle la tarte.
Archive for the ‘Summer of Code’ Category
Gimp warp tool: Midterm report
Already the midterm of the Google Summer of Code, and I didn’t post updates like I wanted. I guess thinking and hacking is still more easy and fun for me than writing. However, let’s correct that.
The least I can say is that the warp tool is in better shape than the cage tool the same time last year. The reason is simple, I learned a lot last year, and the warp tool need similar skills, and even reuse some part of the code.
That said, here is the report:
- All the tool’s infrastructure is here and functional.
- We can apply stroke and deform the canvas.
- 7 behaviors are supported for now:
- moving pixels
- growing an area
- shrinking an area
- swirl clockwise
- swirl counter-clockwise
- erasing a transformation
- local smooth of a transformation
- Actions on the canvas are done with a round brush, with a gaussian like influence curve.
- Tool’s options are strength, size and hardness.
A quick screencast:
Each actions on the canvas are implemented as a Gegl operation that produce a relative coordinate buffer, that is inserted in the render graph. The final image is computed with a map-relative render operation.
This is what still need to be handled:
- Performances need enhancement. For now, for each stroke on the canvas, each operation already computed are re-rendered (cache does not work correctly), and this for the complete surface of the selection (the legagy code wasn’t designed for that). Other areas for improvement exist, such as the implementation of copy on write (COW) for GeglBuffer. The ultimate goal is to perform actions interactively.
- A good tweaking is needed. For now, behaviors are not consistent.
- UI implementation, as specified by Peter Sikking and his team.
- Undo implementation.
As I’m more confident this year, I’m going a bit deeper and I work on related things, especially in Gegl. An interresting thing is that the warp tool is structurally close than a paint core, and is therefore a step closer to a paint core based on Gegl in Gimp.
On da road again !
That’s it ! This summer again, i will participate to the Summer of Code program !
My last year’s contribution was for me a huge challenge, a way to learn a LOT of things, to meet and work with some very interesting people, and a big source of pride (even for my family, here we can see how much Google’s name mean something for the society nowadays).
This year, I’ll use the knowledge I learned last year to rewrite the old plugin iWarp as a real internal Gimp tool. His pretty name will be the Gimp Warp Tool). That’s a feature that has been asked and waited for long. Here again, this tool will fit in the ‘big picture’, the future of Gimp (Gegl, live on-canvas preview, ..).
On a more personal note, it’s clear that my task this year is less challenging than last year (another deformation tool, structure relatively close..), and it’s kind of too bad. Nevertheless, it’s always great to work on a big project like Gimp, and users return it well most of the time. And hey, it’s cool to have his brain working during the summer =)
This time, I should be able to do the job right the first time (as opposition to the cage tool, that was kind of a prototype at the end of the summer), and avoid the 3 or 4 partial rewrite that was needed after the deadline. With a bit of luck, this tool can be included in Gimp 2.8. The start of the coding period is in fact not so far !
Expect news !
Some cage tool’s update
It’s been a while since i didn’t post update here. There even was months without any change, especially when I got the idea to write a small ERP suitable to a Junior-Enterprise. I spend somes hours on it today, and I feeled like it was time for a small changelog:
- as stated before, a rewrite of the UI management as a state machine, with a lot of cleaning (and some regression, I have to say ..)
- use of a custom data structure, that allow …
- the multi-selection of the cage’s handle, with a rubber band, to allow quicker editing of the cage, or simply moving the whole cage at once
- the possibility to go back to the edit mode, to tweak the source cage
- some optimisation in the Gegl operator that run the transformation
There is still some bugs to catch, the more obvious is that the image shift from the cage after a return in edit mode. But promess is made, it will be ready for the Gimp 2.8 release ! By the way, further work in the cage tool will be done in the master branch of Gimp, ne need to checkout a particilar branch.
To celebrate all this, I made a quick screencast with a lizard as the victim. Enjoy =)
Refactoring and evolution of the Cage tool
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… =)
Cage tool is on Master !
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.
Video showing the Gimp cage tool
Hello,
Somebody did a quick review of my cage-based deformation tool for The Gimp and published it in a Gimp community website. It’s on GimpUser.com !
A video of the tool in action is included !
It’s so cool to see that peoples like my work and find it usefull =)
Also, Devv, big thanks for the review and the video !
I really need to find some times to fine tune and clean all this (UI and optimization, mainly) …
Trick list
Memory allocation with Glib:
memory allocation for objects:
simple allocation:
Hacking Gimp
gobject and glib debug
GTK event debug
autogen.sh
compilation without optimisation
quick install of binaries only
Gobject
gobject is evil.
if you have a warning relative to glib or gobject, try make install
something wrong ? Try make install
Babl
setup a format
convert buffer with a Babl fish
Gegl
create a buffer
buffer leak
Git
push in a remote branch
keep branch up-to-date
Official end
- we set on the image a cage-sized grid
- we apply the deformation to the grid
- we split each grid case to two triangle
- for each pixel inside these triangle, we compute the source coordinates
- finally, we have for each pixel of the final, the coordinate from where to fetch color (sampling)
- Cage_coef_calc compute, for each pixel that need to be transformed, the coefficient series that the transform algorithm need.
- Cage_transform compute and inverse the transformation
- Render_mapping render the final image.
To stay in the present, here is the state of things. My tool is in majority done. I mean that the core works well, and it’s usable for a classic utilisation. There is still some teething problem to correct (for instance, it doesn’t works on mask), love to give to UI, and it will be ready for code review and inclusion in master branch of Gimp. At least I hope =)
Moving from prototype
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 !
Shazam
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”.