Re: [Gimp-developer] N-Point Image Deformation queries

[Jehan Pagès <jehan marmottard gmail com>]

Hi again,

On Mon, Feb 3, 2014 at 2:39 PM, Jehan Pagès <jehan marmottard gmail com> wrote:
> Hi Marek,
>
> On Wed, Nov 20, 2013 at 12:32 AM, Marek Dvoroznak <dvoromar gmail com> 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 gnome org
> > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list