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 !

    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.


    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

    Here is a list of trick, technic, tips, that I learned during my Summer of Code. It’s published here as it is, and my or may not interrest you.

    Memory allocation with Glib:

    memory allocation for objects:

    – g_new (struct_type, number)
    – g_renew (struct_type, old_allocation, number)
    – g_unref_object (object)

    simple allocation:

    – g_malloc (byte_number)
    – g_realloc (old_allocation, byte_number)
    – g_free (allocation)
    Allocation with g_malloc are expensive, use gslice instead if the memory needed is length fixed.

    Hacking Gimp

    gobject and glib debug

    Run Gimp with –g-fatal-warnings

    GTK event debug

    When GTK send an event  (key press, mouse clic, ..), Gimp grabs the event manager. If you set a breackpoint in an event handler, this manager isn’t given back to GTK when the debugger freeze Gimp. Result, you cannot use your keyboard or mouse anymore. Not especially handy. Solution is to compile you own GTK with –enable-debug=yes, compile Gimp with this GTK, and run Gimp with –gtk-no-grabs.

    autogen.sh

    Compilation options are available with ./configure –help

    compilation without optimisation

    CFLAGS=-O0 ./autogen.sh –prefix=….

    quick install of binaries only

    cd app/ && sudo make install-binPROGRAMS

    Gobject

    gobject is evil.

    if you have a warning relative to glib or gobject, try make install

    something wrong ? Try make install

    Babl

    Babl is a library used to abstract different pixel formal and color space (RVB, CMJN, …)

    setup a format

    babl_type (“float”)
    babl_type (“u8″)
    babl_format_n (babl_type (“float”), nombre_element)
    Look in the doc http://www.gegl.org/babl/#Vocabulary to see format available. A small precision:
    – R': gamma adjusted
    – Ra: pre-multiplied alpha
    <http://www.gimp.org/docs/plugin_in/appendix-alpha.html>

    convert buffer with a Babl fish

    babl_process (babl_fish, buffer_source, buffer_destination, nombre_d’element)

    Gegl

    create a buffer

    GeglBuffer *bfr = gegl_buffer_new (gegl_rectangle, babl_format)

    buffer leak

    In gegl/buffer/gegl_buffer.c, uncomment #define GEGL_BUFFER_DEBUG_ALLOCATION. When closing Gimp, you will have an allocation trace. You can convert adress in the binary in position in the source code with addr2line -e app/.libs/gimp-2.7 adress.

    Git

    push in a remote branch

    git push origin soc-2010-cage

    keep branch up-to-date

    git fetch origin && git rebase origin

    Official end

    That’s it, Summer of Code is over, at least officially.
    I finally updated this blog less than I expected. I have to say that after 2 month banging my head to the code, motivation is less than before. So, here is the news:
    As announced in my last entry, I worked on a process to invert the computing of the transformation (ie know from where come pixels instead of where they go), to have a good image quality and avoiding aliasing. Here is how it works:
    • 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)
    My first approach for iterating in a triangle was first, re-order it (find the top-high vertice, then left and right vertices), and then iterate it with straight equation. That’s not a great idea. There is a lot of special case, it’s complex and inefficient. Finally, a friend suggested me to proceed recursively, by splitting the triangle in 4, until it include only one pixel. Then, interpolation is done with a barycentric system. Tadaaa, it works every time, and that’s even efficient ! Thanks Théophile (yes, you now have contributed in free software with more than a libcaca patch =) ).
    In fact, it’s so efficient that i will probably replace the “forward” method which is currently used for interactive preview (which is also quite ugly).
    These is how the tool core looks like. Each circle is a Gegl operation.
    • 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.
    This architecture allow, with Gegl, easy reussing of this operation. In that case, my tool’s code can be easily reused and adapted to create an iWarp like tool.

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

    Here is some deform example:
    It ain’t over, but it never was so close to be.

    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

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