Hi Marek, On Wed, Nov 20, 2013 at 12:32 AM, Marek Dvoroznak <dvoromar@xxxxxxxxx> wrote: > 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. Thanks for all your great work. I was just wondering how it was getting along. :-) This feature is really neat and each time I try the branch, I love it more and more. Also a small stupid question: when I try the current version, the grid is "printed" onto the canvas after a deformation, which is likely not intended. Is there a reason for this? Testing maybe? I wanted to try and use the feature a little for experimentation but could not find how to disable this grid printing. Anyway hope we'll get more news soon. :-) Jehan > 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 _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
