Hello,Since my gsoc proposal was accepted, I described in more details the behavior and the technical part of my tool.

I'd like to have opinion and advise from competent people on the different part (UI, reconstruction step ...).

You could find the detail, either in a public wave or in the following of this mail.

http://wave.google.com/wave/waveref/googlewave.com/w%2BvsoJ9FmFH

Thanks

Michael Muré

Green coordinates

http://www.math.tau.ac.il/~lipmanya/GC/gc_techrep.pdf

https://www.mi.fu-berlin.de/wiki/pub/Main/TobiasPfeiffer/gc-talk.pdf

http://www.den.rcast.u-tokyo.ac.jp/~yu-ohtake/GeomPro/3/GreenCoordinates.ppt

http://www.den.rcast.u-tokyo.ac.jp/~yu-ohtake/GeomPro/3/GC2D.jar

Preparation step

- Tool activation - Creation of the cage and setup of the tool (UI) - the user draws a closed cage in the image - the user can change the setup of the tool, if parameters available (not sure yet)
- Intersection of the selection and the cage to obtain the pixels to be processed (my gsoc is for interior of the cage only, see my proposal)

Binding step

- For each pixel processed, the green coordinates need a set of coefficient (one per vertice of the cage, one per edge of the cage) - the number of coefficients is: Pixel_number x (Cage_vertice_number + Cage_edge_number)
- in 2D, Cage_vertice_number = Cage_edge_number - the computation of this coefficients is described at the end of the paper

Real time deformation step

- For each user action, processing + treatment - pixels processed are transformed by the green coordinates - discretization : The result of the transformation is not exact pixel, not integer. I could have also more "information" for one target pixel, or no information at all.
- I need a way to handle this problem, see below - It could be needed to compute only a part of the pixels to achieve real time

Final action

- maybe some filtering and post-process - end of the tool

Image reconstruction

I see 2 ways to handle the problem

Solution 1:

- each source pixels are sent to the target pixels. - For pixels with more than one information the value is computed as an average of the color, weighted by the distance to the pixel - For pixels with no information, the value is computed as a weighted average of the closer neighbour

Solution 2:

- when the pixel is sent to the target pixels, they not only affect one pixel, but an area of pixel (3x3, or 4x4 pixels) with a gaussian weight or similar
- For pixels with no information (which should be rare), the value is computed as a weighted average of the closer neighbour

idea:

- compute the transformation for all the pixels, store them in a huge table, with their color, and perform a sampling on it to compute the final pixels

Data structure

for the coefficients, 2 big table should be enough since they are computed during the bind, and don't change after

Reverse transform is mathematically too difficult ?

I'm not sure yet, but I think the transformation is not bijective, so reverse transformation cannot be achieved

Ways of improving

- multithread - computing of only a part of the pixels during real time (1/9, 1/16, ..) - automatic adaptation of the proportion of the pixels computed (based on computing time)
- automatic creation of the cage, based on the shape of the selection (no idea how to do that)

UI

- the following url shows an interesting UI for cage-based deformation tool:

http://www.cs.technion.ac.il/~weber/Publications/Complex-Coordinates/Complex_bary_coords.mov

idea:

- the handles can be moved by group (selection with a rectangle or other) - the handles or group of handle can be moved with hotkey, in a similar way than within blender (R to rotate, M to move, S to scale) - the handles can be moved by clicking in any part of the image that is not a handle, the influence on the handle is computed in function of the distance to the cursor. See
http://
batmur
.mine.nu/
dawa
/mockup.jpg