Hi again, On Mon, Feb 3, 2014 at 2:39 PM, Jehan Pagès <jehan.marmottard@xxxxxxxxx> wrote: > 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. Drawoc told me to use the npd-squashed GEGL branch (and not outdated soc-2013-n-point-deformation), and it does not have the grid printing anymore. So forget the question. Apparently the tool is close to a mergeable state, at least on GEGL side, he also told, which is awesome. :-) Hope to see the full feature on master soon! Jehan > > 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
