[Gimp-developer] GSOC proposal: cage-based transform tool
Hello, I'm Michael Muré, a French student in computer science. I'd like to propose a GSOC about a new cage-based deformation tool. This tool wil be based on this paper: http://www.math.tau.ac.il/~lipmanya/GC/gc_techrep.pdfhttp://www.math.tau.ac.il/%7Elipmanya/GC/gc_techrep.pdf(Siggraph 2008) The basic behavior of this tool would be: - you put a closed polygon on the image (not limited to 4 handles) - you deform the cage, the image is deformed accordingly - user can choice if the pixels can go outside of the cage or not. In the normal behavior of the Green Coordinates, the pixels can overflow the cage, due to the shape preservation. Unlike the other classical method (mean value coordinates, harmonic coordinates, ..), the Green Coordinates allow high quality deformation by preserving the shape. That mean that you don't have side effect like shear. Example can be found in the paper. However, a restriction, the figure 14 show a deformation of the outside of the cage, that require a cutting of the outside. I think that's not relevant for a software like the Gimp. That was for the presentation. I would really like some advise or opinion of the community, to improve my proposal. For instance, I've some question: - Since the GC is affine-invariant, it can do rotation and translation as well. However, it is less efficient than this simple tools. Should this tools be merged in the same tool ? - Generally speaking, I'm not sure about the best UI solution - Concerning the code, I'm a bit rookie with the code base of the Gimp. I usually follow more the Blender's development. Any hint or advise or thing to know would be appreciated. Regards Michael Muré ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC proposal: cage-based transform tool
http://liquidrescale.wikidot.com/en:tutorial But the behavior and the goal of this tool is rather different from mine. 2010/3/25 Alexia Death alexiade...@gmail.com On Thu, Mar 25, 2010 at 6:12 PM, Joao S. O. Bueno gwid...@mpc.com.br wrote: On Wed, Mar 24, 2010 at 5:14 PM, Alexia Death alexiade...@gmail.com wrote: Haven't checked the references - but it sounds like the same UI could be used to perform the Liquid Resize magic, currently existing as a 3rd party plug-in - what do you say? Could you point me to the plug-in? I don't think Ive seen it before -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC proposal: cage-based transform tool
Hello, - Since the GC is affine-invariant, it can do rotation and translation as well. However, it is less efficient than this simple tools. Should this tools be merged in the same tool ? I just found a mistake, the green coordinates is not affine invariant, that's why the shape preservation can be achieve. However, it is invariant for rotation, translation and scale. Any other reaction, advise, opinion ? Regards Michael Muré ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC: cage based transform tool
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.pdfhttp://www.google.com/url?sa=Dq=https%3A%2F%2Fwww.mi.fu-berlin.de%2Fwiki%2Fpub%2FMain%2FTobiasPfeiffer%2Fgc-talk.pdf https://www.mi.fu-berlin.de/wiki/pub/Main/TobiasPfeiffer/gc-talk.pdf http://www.google.com/url?sa=Dq=https%3A%2F%2Fwww.mi.fu-berlin.de%2Fwiki%2Fpub%2FMain%2FTobiasPfeiffer%2Fgc-talk.pdf http://www.den.rcast.u-tokyo.ac.jp/~yu-ohtake/GeomPro/3/GreenCoordinates.ppthttp://www.google.com/url?sa=Dq=http%3A%2F%2Fwww.den.rcast.u-tokyo.ac.jp%2F%7Eyu-ohtake%2FGeomPro%2F3%2FGreenCoordinates.ppt http://www.den.rcast.u-tokyo.ac.jp/~yu-ohtake/GeomPro/3/GC2D.jarhttp://www.google.com/url?sa=Dq=http%3A%2F%2Fwww.den.rcast.u-tokyo.ac.jp%2F%7Eyu-ohtake%2FGeomPro%2F3%2FGC2D.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.movhttp://www.google.com/url?sa=Dq=http%3A%2F%2Fwww.cs.technion.ac.il%2F%7Eweber%2FPublications%2FComplex-Coordinates%2FComplex_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://http://www.google.com/url?sa=Dq=http%3A%2F%2Fbatmur.mine.nu%2Fdawa%2Fmockup.jpg batmurhttp://www.google.com/url?sa=Dq=http%3A%2F%2Fbatmur.mine.nu%2Fdawa%2Fmockup.jpg .mine.nu/http://www.google.com/url?sa=Dq=http%3A%2F%2Fbatmur.mine.nu%2Fdawa%2Fmockup.jpg dawahttp://www.google.com/url?sa=Dq=http%3A%2F%2Fbatmur.mine.nu%2Fdawa
[Gimp-developer] GSOC: Cage based transform tool
Hi everyone, A quick mail to let you know that I started a blog about my summer of code. You will find on it my progress about this tool, and some others things. Since I'm still in both school and exam, I didn't started to code, but stay tunned ! The blog is here: http://pellelatarte.fr/en/ (still very new) Sorry for minute of disturbing Michael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] donations for GIMP 2.8
Hi everyone, You may know me as the student who coded the cage tool during this summer. I'd like to add something about these bounty. For me, the key point for the health of the community dev of Gimp is the current difficulty to be used to the codebase. I myself had a hard time to understand how things works in the code, and how to do things. The main cause of these difficulty is the lack of technical documentation. We sometimes need to read hundred lines of code just to know what an objet actually do. The code architecture is obscur for most of the dev, and if we loose the key dev, we will have hard time. If i haven't the pressure of the GSOC program, I probably abandoned. I once asked why we don't have these documentation. The answer i had is that writing documentation is boring, that's like that in free software, you just have to deal with. That's a vicious circle. The less we have docs, the less we have dev. And so, and so ... My idea is to use this money to reverse the trend. Lets give bounty for these docs. Here is some example of documentation I think is needed: - How to write a cool GObject for Gimp - How to write a cool Gegl op - A summary of what do core object if it's not already documented Just have a look on what Blender's dev do to present their work, and compare Blender and Gimp activity. http://code.blender.org/index.php/2011/01/a-look-at-point-cache/ I hope this message will go somewhere ... -- Michael Muré ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] donations for GIMP 2.8
2011/1/10 Øyvind Kolås pip...@gimp.org Lets hope use of rewards wouldnt scare off people from contributing such work for free. It could be a one-time operation, with clearly defined goal and bounty. Just the time we need to have these needed documentation. -- Michael Muré ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp should be GIMP, but have no idea about GimpCageConfig (translation related)
Hi, Sorry for the late reply. 2011/7/29 Cristian Secară li...@secarica.ro First of all, I think that Gimp should be GIMP in these strings: #: ../app/gegl/gimpoperationcagecoefcalc.c:65 msgid Compute a set of coefficient buffer for the Gimp cage tool #: ../app/gegl/gimpoperationcagetransform.c:104 msgid Convert a set of coefficient buffer to a coordinate buffer for the Gimp cage tool Fixed in git master. Second, I don't know what to do with the GimpCageConfig; is this something that is supposed to be known by a normal user ? It should be not translated ? #: ../app/gegl/gimpoperationcagecoefcalc.c:82 #: ../app/gegl/gimpoperationcagetransform.c:118 msgid A GimpCageConfig object, that define the transformation For now, this string won't go to the UI, but it might happen in the future, when gegl will be integrated, so I keep it marked for translation. Thanks for the report ! -- Michael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp should be GIMP, but have no idea about GimpCageConfig (translation related)
I'm afraid I don't have a better answer than pippin told me this. If nobody object in the next few days, I will unmark them for translation. 2011/8/2 Martin Nordholts ense...@gmail.com 2011/8/2 Michael Muré batolet...@gmail.com: #: ../app/gegl/gimpoperationcagecoefcalc.c:82 #: ../app/gegl/gimpoperationcagetransform.c:118 msgid A GimpCageConfig object, that define the transformation For now, this string won't go to the UI, but it might happen in the future, when gegl will be integrated, so I keep it marked for translation. Hi Michael, I strongly doubt it would make sense to bother our users with names of GObject classes, could you elaborate on why we should do this? Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com -- Michael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
