Sent: 2010-05-09 14:55:26 UTC (almost 2 years ago)

From: Michael Muré

GSOC: cage based transform tool

permalink

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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-05-09 17:47:36 UTC (almost 2 years ago)

From: gg@catking.net

GSOC: cage based transform tool

permalink

On 05/09/10 14:55, Michael Muré wrote:
> * 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

I suggest you look at the catmull-romm code used in GIMP image scaling
functions. It is a spline fit to four points that is probably better
than "averaging" . It is pretty light on computation time so achieves
good results with minimum overhead.

It allows interpolation anywhere between two points so does not
introduce extra pixelisation artifacts.

The only downside I'm aware of is it tends to overshoot near abrupt
changes since the mathematical definition of the spline does not
constrain it to the region of the points which define it but does
dictate that it pass through each one.

Near a step change it will exactly fit each point either side of the
step but over shoot around those points.

HTH.

/gg

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer