On Mon, Mar 11, 2013 at 5:40 PM, Marek Dvoroznak wrote:

Hello,

I would like to participate in this year's GSOC. As a school project, I implemented as-rigid-as-possible (and as-similar-as-possible) n-point image deformation. I've thought it would be useful to have a tool implementing this in GIMP. I know that at the moment similar effect can be achieved with Cage Transform tool, but with n-point image deformation it's much easier.

I planned to make a plugin implementing this type of deformation as a part of my thesis, but unfortunately I had to change my thesis' topic.

Could this be a suitable project for GSOC under GIMP?

I'm attaching a link to a video clip showing a character deformed using Cage Transform tool and also using as-rigid-as-possible deformation: http://youtu.be/ieaHvHAcNRE

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?

Alexandre Prokoudine http://libregraphicsworld.org

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 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?

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

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 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

Put the titles in ACM digital library and click on "Cited by" and you may find interesting articles that are newer.

On Tue, Mar 12, 2013 at 2:48 PM, Michael Mur wrote:

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

On Tue, Mar 12, 2013 at 9:01 PM, Marek Dvoroznak wrote:

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

My proposed implementation is also based on this paper but with some differences. I should make a proposal with more details but it'll take some time.

In the mean time please try to find some time and compile GIMP from source code in Git master branch. We'd like our students to have a working build environment prior to starting actual development :)

Most development discussions happen on IRC (#gimp on GIMPnet). We don't demand participation there (after all, not everybody likes IRC), it's just the easiest way to stay connected.

Alexandre Prokoudine http://libregraphicsworld.org