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.
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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
