Hello,

We somewhat assumed that you weren't here, because we couldn't easily get a hold of you. Apparently, we didn't try hard enough. Thanks for sticking around.

Anyway, I began reviewing your code. I made some changes to it to try and make it a bit cleaner, so we could merge it into the main gegl tree. You can see all of my changes here: https://git.gnome.org/browse/gegl/log/?h=npd-squashed

The main complaints we have about your code are:

* The GEGL operation shouldn't contain any Cairo code in it. UI stuff like that should only be in either your library or your GIMP tool. Of course, you have it set up so that this should be easy to change.

* Generally, when you write an API, you want to expose as little as possible. Only the bare minimum number of functions should be included in the public/installed header files, and typically no structures at all should appear there. I've begun fixing this by converting some of your functions to static functions where possible.

* Some of the functions like add_point_to_suitable_cluster do bizarre things like convert floats to strings just so they can be used as hash table keys. A lot of this code wasn't actually used, so I commented it out for now.

I would feel a lot better if the npd library didn't include its own interpolation code. You mentioned outputting float coordinates to an image and then using map-absolute, but I'd prefer if the gegl operation found the color values directly with a GeglSampler object. This gives you access to Gegl's built-in interpolation methods.

I'm not sure if you want me to continue working on npd (I can find other stuff to do, if you'd prefer to make these changes yourself.)

Anyway, these are the main things that are stopping us from merging the gegl npd branch right now. I haven't actually looked at the gimp npd branch, but mitch sounded generally happy with the code there.

If you want to talk to me on irc, my nick is "drawoc".

Anyway, thanks for the hard work!

Sure, starting from npd-squashed would be fine.

I suppose the gegl sampling functions might be a bit slow for the preview. On the other hand, they have had a fair amount of optimization work done on them, so you might find that they're actually faster. Actually trying them out is probably a good idea. If nothing else, we should use GeglSamplers for the final rendering of the mesh.

On Sun, Dec 1, 2013 at 7:07 PM, Marek Dvoroznak wrote:

Hello,

thanks for the hints and sorry for the late answer. I will try to fix what I'm able to and then ask you for review.

About the interpolation code - I was afraid that GEGL sampling functions could be slow for a preview of the deformation. I will try to use them and make some performance tests.

Do you prefer me to use your branch (npd-squashed) for that work?

Marek

Hello,

We somewhat assumed that you weren't here, because we couldn't easily get a hold of you. Apparently, we didn't try hard enough. Thanks for sticking around.

Anyway, I began reviewing your code. I made some changes to it to try and make it a bit cleaner, so we could merge it into the main gegl tree. You can see all of my changes here: https://git.gnome.org/browse/gegl/log/?h=npd-squashed

The main complaints we have about your code are:

* The GEGL operation shouldn't contain any Cairo code in it. UI stuff like that should only be in either your library or your GIMP tool. Of course, you have it set up so that this should be easy to change.

* Generally, when you write an API, you want to expose as little as possible. Only the bare minimum number of functions should be included in the public/installed header files, and typically no structures at all should appear there. I've begun fixing this by converting some of your functions to static functions where possible.

* Some of the functions like add_point_to_suitable_cluster do bizarre things like convert floats to strings just so they can be used as hash table keys. A lot of this code wasn't actually used, so I commented it out for now.

I would feel a lot better if the npd library didn't include its own interpolation code. You mentioned outputting float coordinates to an image and then using map-absolute, but I'd prefer if the gegl operation found the color values directly with a GeglSampler object. This gives you access to Gegl's built-in interpolation methods.

I'm not sure if you want me to continue working on npd (I can find other stuff to do, if you'd prefer to make these changes yourself.)

Anyway, these are the main things that are stopping us from merging the gegl npd branch right now. I haven't actually looked at the gimp npd branch, but mitch sounded generally happy with the code there.

If you want to talk to me on irc, my nick is "drawoc".

Anyway, thanks for the hard work!

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi Marek,

On Wed, Nov 20, 2013 at 12:32 AM, Marek Dvoroznak wrote:

Hello,

I see that there (on IRC) has been some queries on n-point deformation recently. I'll try to bring some transparency to it.

Thanks for all your great work. I was just wondering how it was getting along. :-)

This feature is really neat and each time I try the branch, I love it more and more.
Also a small stupid question: when I try the current version, the grid is "printed" onto the canvas after a deformation, which is likely not intended. Is there a reason for this? Testing maybe? I wanted to try and use the feature a little for experimentation but could not find how to disable this grid printing.

Anyway hope we'll get more news soon. :-)

Jehan

I'm currently quite a lot busy, but in my free time I try to work on the deformation tool at least a bit. For example I've recently integrated a lattice cutting algorithm that I devised during GSOC. In a lot of situations it allows user to set a larger square size of lattice and still be able to manipulate with articulated parts of an image. The algorithm can be made even smarter, that's one of my plans for the future.

GEGL part of n-point-deformation --------------------------------
I was creating the library in a way so that it was the most independent (especially on "display" library). I wanted to use it (and I use it) with Allegro library as well as with GEGL. If is that possible, I would like it to stay as independent as possible so that I can maintain and refine just one source code.

The library is separated into computational part (deformation.[ch]), graphics part (graphics.[ch]), GEGL part (npd_gegl.[ch]) and other rutines.

Graphics part contains graphics rutines that are not dependent on any graphics library. When somebody wants to use the library with some graphics library he is expected to implement some graphics functions (get_pixel, set_pixel, draw_line) and some structures (_NPDImage, _NPDDisplay). NPD operation does it this way.

GEGL part should contain these implementations of majority of needed graphics functions and structures due to the fact that these implementations can be useful when somebody would like to use them from more then one place (for example in two partialy different GEGL operations).

About NPD operation. It currently operates in 'RGBA u8' format which is suitable for a preview of the deformation. Generation of the preview should be as fast as possible - it currently uses graphics techniques implemented in graphics part of the library. I have partialy implemented a version of NPD operation that produces absolute coordinate buffer in floats. When we connect it to map-absolute operation we can get a better interpolated result and in 'RGBA float' format.

GIMP part of n-point deformation --------------------------------
During GSOC I wanted to use mentioned GEGL operation for a preview of the deformation process in GIMP NPD tool and I also wanted to use some functions (e.g. to manipulate with points) and share some structures. I decided to make shared library and bundle it with GEGL because it showed up that it was an easy way - because GIMP uses GEGL (and 'seamless clone' does it similarly).

At the beginning of implementation of NPD tool, the tool directly modified image's GEGL buffer and forced the image to redraw itself. That was just for testing reasons and, of course, it was slow. It showed up that it was needed to draw on canvas using Cairo - similarly as Transform Tools do it. I use GimpCanvasBufferPreview class for it.

Things to do (among others) ---------------------------
- Solve deformation of large images - The deformation is currently slow on large images. It's due to the fact that it's needed to render the deformation of such an image serveral times per second. That is impossible. The solution is to render only what is contained in viewport.
- Implement depth of control points so that user can adjust which part of overlapping mesh/image is visible.

I hope that my thoughts about n-point deformation during GSOC are now clearer and that it's not a total nonsense.

Regards, Marek

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi again,

On Mon, Feb 3, 2014 at 2:39 PM, Jehan Pagès wrote:

Hi Marek,

On Wed, Nov 20, 2013 at 12:32 AM, Marek Dvoroznak wrote:

Hello,

I see that there (on IRC) has been some queries on n-point deformation recently. I'll try to bring some transparency to it.

Thanks for all your great work. I was just wondering how it was getting along. :-)

This feature is really neat and each time I try the branch, I love it more and more.
Also a small stupid question: when I try the current version, the grid is "printed" onto the canvas after a deformation, which is likely not intended. Is there a reason for this? Testing maybe? I wanted to try and use the feature a little for experimentation but could not find how to disable this grid printing.

Drawoc told me to use the npd-squashed GEGL branch (and not outdated soc-2013-n-point-deformation), and it does not have the grid printing anymore. So forget the question. Apparently the tool is close to a mergeable state, at least on GEGL side, he also told, which is awesome. :-)

Hope to see the full feature on master soon!

Jehan

Anyway hope we'll get more news soon. :-)

Jehan

I'm currently quite a lot busy, but in my free time I try to work on the deformation tool at least a bit. For example I've recently integrated a lattice cutting algorithm that I devised during GSOC. In a lot of situations it allows user to set a larger square size of lattice and still be able to manipulate with articulated parts of an image. The algorithm can be made even smarter, that's one of my plans for the future.

GEGL part of n-point-deformation --------------------------------
I was creating the library in a way so that it was the most independent (especially on "display" library). I wanted to use it (and I use it) with Allegro library as well as with GEGL. If is that possible, I would like it to stay as independent as possible so that I can maintain and refine just one source code.

The library is separated into computational part (deformation.[ch]), graphics part (graphics.[ch]), GEGL part (npd_gegl.[ch]) and other rutines.

Graphics part contains graphics rutines that are not dependent on any graphics library. When somebody wants to use the library with some graphics library he is expected to implement some graphics functions (get_pixel, set_pixel, draw_line) and some structures (_NPDImage, _NPDDisplay). NPD operation does it this way.

GEGL part should contain these implementations of majority of needed graphics functions and structures due to the fact that these implementations can be useful when somebody would like to use them from more then one place (for example in two partialy different GEGL operations).

About NPD operation. It currently operates in 'RGBA u8' format which is suitable for a preview of the deformation. Generation of the preview should be as fast as possible - it currently uses graphics techniques implemented in graphics part of the library. I have partialy implemented a version of NPD operation that produces absolute coordinate buffer in floats. When we connect it to map-absolute operation we can get a better interpolated result and in 'RGBA float' format.

GIMP part of n-point deformation --------------------------------
During GSOC I wanted to use mentioned GEGL operation for a preview of the deformation process in GIMP NPD tool and I also wanted to use some functions (e.g. to manipulate with points) and share some structures. I decided to make shared library and bundle it with GEGL because it showed up that it was an easy way - because GIMP uses GEGL (and 'seamless clone' does it similarly).

At the beginning of implementation of NPD tool, the tool directly modified image's GEGL buffer and forced the image to redraw itself. That was just for testing reasons and, of course, it was slow. It showed up that it was needed to draw on canvas using Cairo - similarly as Transform Tools do it. I use GimpCanvasBufferPreview class for it.

Things to do (among others) ---------------------------
- Solve deformation of large images - The deformation is currently slow on large images. It's due to the fact that it's needed to render the deformation of such an image serveral times per second. That is impossible. The solution is to render only what is contained in viewport.
- Implement depth of control points so that user can adjust which part of overlapping mesh/image is visible.

I hope that my thoughts about n-point deformation during GSOC are now clearer and that it's not a total nonsense.

Regards, Marek

_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list