Hello, I see that there (on IRC) has been some queries on n-point deformation recently. I'll try to bring some transparency to it. I'm currently quite a lot busy, but in my free time I try to work on the deformation tool at least a bit. For example I've recently integrated a lattice cutting algorithm that I devised during GSOC. In a lot of situations it allows user to set a larger square size of lattice and still be able to manipulate with articulated parts of an image. The algorithm can be made even smarter, that's one of my plans for the future. GEGL part of n-point-deformation -------------------------------- I was creating the library in a way so that it was the most independent (especially on "display" library). I wanted to use it (and I use it) with Allegro library as well as with GEGL. If is that possible, I would like it to stay as independent as possible so that I can maintain and refine just one source code. The library is separated into computational part (deformation.[ch]), graphics part (graphics.[ch]), GEGL part (npd_gegl.[ch]) and other rutines. Graphics part contains graphics rutines that are not dependent on any graphics library. When somebody wants to use the library with some graphics library he is expected to implement some graphics functions (get_pixel, set_pixel, draw_line) and some structures (_NPDImage, _NPDDisplay). NPD operation does it this way. GEGL part should contain these implementations of majority of needed graphics functions and structures due to the fact that these implementations can be useful when somebody would like to use them from more then one place (for example in two partialy different GEGL operations). About NPD operation. It currently operates in 'RGBA u8' format which is suitable for a preview of the deformation. Generation of the preview should be as fast as possible - it currently uses graphics techniques implemented in graphics part of the library. I have partialy implemented a version of NPD operation that produces absolute coordinate buffer in floats. When we connect it to map-absolute operation we can get a better interpolated result and in 'RGBA float' format. GIMP part of n-point deformation -------------------------------- During GSOC I wanted to use mentioned GEGL operation for a preview of the deformation process in GIMP NPD tool and I also wanted to use some functions (e.g. to manipulate with points) and share some structures. I decided to make shared library and bundle it with GEGL because it showed up that it was an easy way - because GIMP uses GEGL (and 'seamless clone' does it similarly). At the beginning of implementation of NPD tool, the tool directly modified image's GEGL buffer and forced the image to redraw itself. That was just for testing reasons and, of course, it was slow. It showed up that it was needed to draw on canvas using Cairo - similarly as Transform Tools do it. I use GimpCanvasBufferPreview class for it. Things to do (among others) --------------------------- - Solve deformation of large images - The deformation is currently slow on large images. It's due to the fact that it's needed to render the deformation of such an image serveral times per second. That is impossible. The solution is to render only what is contained in viewport. - Implement depth of control points so that user can adjust which part of overlapping mesh/image is visible. I hope that my thoughts about n-point deformation during GSOC are now clearer and that it's not a total nonsense. Regards, Marek _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
