Re: [Gimp-developer] GSOC 2013 - n-point image deformation

[Michael Muré <batolettre gmail com>]

The reason the cage tool is slow is that a set of coefficient is
computed and used to deform every single pixel inside the cage. The
plan was indeed to use the poly2tri-C to mesh the cage and move that
instead of each pixels.

There is not that much work to do that, as most of the code can be
reused, and this library is already used in the seamless clone tool.

Another thing to look at is the new Free Transform Tool of Krita, wich
looks quite awesome: http://krita.org/item/131-free-transform-tool

It's based on this paper: http://faculty.cs.tamu.edu/schaefer/research/mls.pdf

2013/3/11 Alexandre Prokoudine <alexandre prokoudine gmail com>
> Well, I'm not really trained to talk of such things, but one thing
> worth thinking of is how precise your method is trying to be.
>
> One of the reasons why Cage Transform is so slow is that it's trying
> to be too smart and does too much computation.
>
> The plan was to eventually start using poly2tri-C library that
> implements Delaunay triangulations. Does it ring a bell?
>
> I'm sure, Michael Muré can provide much more useful info :)
>
> Alexandre
>
> On Tue, Mar 12, 2013 at 1:36 AM, Marek Dvoroznak <dvoromar gmail com> wrote:
> > I have it currently written in Java and performance on fairly large
> > images isn't so good. I suppose that in C and with more optimizations it
> > will be much better. Performance and behavior of the algorithm very
> > depends on a size of mesh's squares (or triangles). I'll try to do some
> > performance tests.
> >
> > Marek
> >
> > On Mon, 11 Mar 2013 18:03:11 +0400, Alexandre Prokoudine wrote:
> > > So this is more like Puppet Warp really :) And it does look very impressive!
> > >
> > > IMHO, it would be a great GSoC project.
> > >
> > > How is it performance-wise? How well does it work on fairly large images?




--
Michael