Hi,

On Sat, 2006-09-02 at 20:58 +0200, Michael Natterer wrote:

I just merged the "Healing Brush" branch soc-2006-healing-brush to CVS HEAD (see the ChangeLog entry pasted below for details).

Cool!

I tried the new tool and I have a couple of comments:

(1) It would be nice if Jimmac could have a look at redoing the icon. I very much like the metaphor but the icon would benefit from some Tango love applied to it.

(2) IMO the tool should be moved next to the Clone tool in the toolbox.

(3) I frequently get error messages saying "Source and destination regions are not the same size.". That shouldn't happen.

(4) I don't really understand how to use the tool. I understand that I need to Ctrl-Click to select a source as with the Clone tool. But then, when I try to heal an area, I find the behaviour unpredictable and somehwat erratic. Can someone please explain how this tool is supposed to be used?

Sven

Hi!

I'm really glad the the Healing Brush has been merged into HEAD. That marks my first open-source contribution!

(1) It would be nice if Jimmac could have a look at redoing the icon. I

very much like the metaphor but the icon would benefit from some Tango love applied to it.

Yes. Please fix the icon. This was just something I did in a few spare minutes, and I am definitely not an icon expert.

(3) I frequently get error messages saying "Source and destination

regions are not the same size.". That shouldn't happen.

The source and destination region should be the same size, but I don't know how to ensure this for every click. Right now the best I could do is not report the error and just run the loop again. I'll look into it though

(4) I don't really understand how to use the tool. I understand that I

need to Ctrl-Click to select a source as with the Clone tool. But then, when I try to heal an area, I find the behaviour unpredictable and somehwat erratic. Can someone please explain how this tool is supposed to be used?

I created a tutorial about the tool. Is there any GIMP hosted site where I could post it to for everyone to look at. This should answer most of your questions.

Kevin

On 9/4/06, Kevin Sookocheff wrote:

I created a tutorial about the tool. Is there any GIMP hosted site where I could post it to for everyone to look at. This should answer most of your questions.

Theres is wiki.gimp.org, but I don't know if it allows uploading images

Alexandre

Hi,
-------- Original-Nachricht -------- Datum: Mon, 4 Sep 2006 10:41:20 -0400 Von: "Kevin Sookocheff"
An: "Sven Neumann"
Betreff: Re: [Gimp-developer] soc-2006-healing-brush branch merged and closed

I created a tutorial about the tool. Is there any GIMP hosted site where I
could post it to for everyone to look at. This should answer most of your questions.

Independent of the place you store the tutorial, it might be a good idea to send a copy to the documentation team, so we can incorporate your knowledge about the usage of the tool into the manual.

greetings, lexA

Kevin

Hi,

On Mon, 2006-09-04 at 10:41 -0400, Kevin Sookocheff wrote:

I created a tutorial about the tool. Is there any GIMP hosted site where I could post it to for everyone to look at. This should answer most of your questions.

I doubt that a tutorial will answer my main question, which is "why does the tool not do what I expect it to do?" ;-) My concern is that when I paint over a spot that needs healing and while the brush is over it, it looks fine but it reverts to almost the original when I leave the area or stop painting. It seems that I get better results if I only click without moving the mouse while healing.

Sven

Hey,
Just tried the healing brush for the first time, on an 8mp image with a 200px brush.
- Useually works ok for most tools.

With the healing brush it was very slow, thats ok too- I assume theres a lot of math to go for this tool

But after a click+drag it was so slow, it would not finish after about 2min... even worse, I could not move any windows or click anywhere while it was thinking.

Only quick way out was to kill X11 with a ctrl+alt+backspace. (or boot up another PC and kill the gimp via SSH)

it looks like this is more of a problem with the way gimp locks X11 then the healing tool its self.

- Cam

Hi Cam,

A bad point about the current implementation is that it is slow. The Laplacian solver is not optimized. There are also other ways to implement the Laplacian solver that may increase the speed.

You're correct in that the reason that X freezes is because GIMP locks X11.

Kevin

Kevin Sookocheff wrote:

Hi Cam,

A bad point about the current implementation is that it is slow. The Laplacian solver is not optimized. There are also other ways to implement the Laplacian solver that may increase the speed.
You're correct in that the reason that X freezes is because GIMP locks X11.

Kevin

Hey Kevin,
Is the tool freezing issue been discussed before? - seems like it should be changed to only freeze operations within the gimp?

Also, my mistake for also having the brush spacing on 1.0!

Because I use large images I need brushes up to about 400px so rather then using the selection of brushes I use 1 and resize it each time. This ok but keeps spacing unchanged. - Cam

Hi,

On Mon, 2006-09-04 at 20:45 -0400, Kevin Sookocheff wrote:

A bad point about the current implementation is that it is slow. The Laplacian solver is not optimized. There are also other ways to implement the Laplacian solver that may increase the speed.

As far as I know, the Heal tool in Photoshop solves this problem by only going through the math after you release the mouse button. While you are painting, the tool works just like the clone tool and just copies from the source location. Only after you release the mouse button the healing magic is performed.

I think that this would a good solution to our problem. It's unacceptable for GIMP to get stuck in a long-time calculation while the mouse is grabbed. And there's no way to not grab the mouse while the user is painting.

Sven

Hi,

On Mon, 2006-09-04 at 15:03 -0400, Kevin Sookocheff wrote:

That's because right now the Laplacian solver isn't optimized. If we used another algorithm, or optimized the current one it would be fine. The tool isn't "real-time" at the moment and clicking is the only way to use it for the moment.

I don't see how optimizing the algorithm would solve the usability problem. If we optimized the algorithm, we would spend less CPU cycles, but the tool would still not behave like a paint tool. I think we need to do something about the way the tool works. I have outlined a possible solution in another mail.

Of course optimizing the Laplacion solver is still desirable. Have you done any profiling on this yet? Is there a way to benchmark it? A regression test would also be nice to have for this purpose.

Sven

As far as I know, the Heal tool in Photoshop solves this problem by only

going through the math after you release the mouse button. While you are painting, the tool works just like the clone tool and just copies from the source location. Only after you release the mouse button the healing magic is performed.

OK. That seems logical. So during the mouse stroke a region is selected, and after the mouse stroke healing is done on the selected region. Are there any tools in GIMP right now that follow a similar sequence? The problem I have is that I'm not sure how to implement this, I just don't know enough GIMP yet :)

Kevin

Hi Kevin,

On Tue, 2006-09-05 at 09:15 -0400, Kevin Sookocheff wrote:

OK. That seems logical. So during the mouse stroke a region is selected, and after the mouse stroke healing is done on the selected region. Are there any tools in GIMP right now that follow a similar sequence? The problem I have is that I'm not sure how to implement this, I just don't know enough GIMP yet :)

I don't think there's a tool that does something similar. But then, it shouldn't be that hard. The heal tool would simply do what the clone tool is doing on motion. Or actually, it should share the code, either by delegation or perhaps we would derive GimpHeal from GimpClone.

As far as I can see, there is currently no way to override gimp_paint_core_finish(). That's probably where the heal tool would have to do its magic. So we would have to make this a virtual method of the GimpPaintCore class so the GimpHeal could override it.

Mitch knows this code a lot better, he should be able to help you with this.

Sven

Hey, is it ok to report bugs her? With Blender3D we sometimes report bugs on the ML if the features are in active development or just added.

The perspective clone tool crashes if you make the perspective square concave or a 'bow tie' where 2 of the lines intersect.

This also locked X11 after crashing, tho thats another issue,

- Cam

Sven Neumann wrote:

Hi,

On Sat, 2006-09-09 at 20:01 +1000, Campbell Barton wrote:

Hey, is it ok to report bugs her? With Blender3D we sometimes report bugs on the ML if the features are in active development or just added.

It is actually too early to report any bugs in the new tool. It has only just been merged into the HEAD branch and a lot will change before it starts to make sense to report bugs for it. Mentioning problems on the mailing-list is OK though as it doesn't create as much hassle as a bug report in the bug tracker does.

The perspective clone tool crashes if you make the perspective square concave or a 'bow tie' where 2 of the lines intersect.

This also locked X11 after crashing, tho thats another issue,

Why is that another issue? GIMP crashes while the pointer is grabbed and it needs to do that while you drag the perspective plane around.

Sven

On the last point,

previously I mentioned Gimp stealing the mouse focus, causing me to kill X even though other X application were responsive.

This happened again with the perspective tool, if it had crashed and closed it would have been ok, but in this case it gave the [segfault error, continue, exit... etc] in the command line prompting me for input, but the input being locked didnt let me enter in a value.

I mean to say that a tool crashing and the tools locking the input are seperate issues.- its not the perspective-clone tools fault X11 is locked. ;-)

- Cam

Hi,

On Sat, 2006-09-09 at 20:01 +1000, Campbell Barton wrote:

Hey, is it ok to report bugs her? With Blender3D we sometimes report bugs on the ML if the features are in active development or just added.

It is actually too early to report any bugs in the new tool. It has only just been merged into the HEAD branch and a lot will change before it starts to make sense to report bugs for it. Mentioning problems on the mailing-list is OK though as it doesn't create as much hassle as a bug report in the bug tracker does.

The perspective clone tool crashes if you make the perspective square concave or a 'bow tie' where 2 of the lines intersect.

This also locked X11 after crashing, tho thats another issue,

Why is that another issue? GIMP crashes while the pointer is grabbed and it needs to do that while you drag the perspective plane around.

Sven

Hi,

On Sat, 2006-09-09 at 23:52 +1000, Campbell Barton wrote:

This happened again with the perspective tool, if it had crashed and closed it would have been ok, but in this case it gave the [segfault error, continue, exit... etc] in the command line prompting me for input, but the input being locked didnt let me enter in a value.

Shouldn't happen any longer with current CVS. We now try to ungrab the pointer and keyboard before calling g_on_error_query().

Sven

Hi Kevin,

a while ago I wrote to the list with the following questions and I don't remember to have gotten answers to them. Will you please consider to answer these questions?

On Tue, 2006-09-05 at 07:55 +0200, Sven Neumann wrote:

Of course optimizing the Laplacion solver is still desirable. Have you done any profiling on this yet? Is there a way to benchmark it? A regression test would also be nice to have for this purpose.

Sven

Hi Kevin,

a while ago we discussed how to change the heal tool so that it doesn't do it's time-expensive calculations while the user is painting but to delay it until after the mouse has been released. Have you tried to change the code in this direction? Do you need more help with this?

Sven

In regard to: Re: [Gimp-developer] soc-2006-healing-brush branch merged and...:

Hi Kevin,

a while ago I wrote to the list with the following questions and I don't remember to have gotten answers to them. Will you please consider to answer these questions?

My guess is that Kevin isn't listening right now, because of the move and internship he mentioned at the bottom of this email:

https://lists.xcf.berkeley.edu/lists/gimp-developer/2006-August/016152.html

On Tue, 2006-09-05 at 07:55 +0200, Sven Neumann wrote:

Of course optimizing the Laplacion solver is still desirable. Have you done any profiling on this yet? Is there a way to benchmark it? A regression test would also be nice to have for this purpose.

Tim

Hi,

On Wed, 2006-09-13 at 10:52 -0500, Tim Mooney wrote:

My guess is that Kevin isn't listening right now, because of the move and internship he mentioned at the bottom of this email:

https://lists.xcf.berkeley.edu/lists/gimp-developer/2006-August/016152.html

Sorry, I missed that. Thanks for reminding me.

Sven

Hi Sven,

Regarding your questions:

Of course optimizing the Laplacion solver is still desirable. Have you done any profiling on this yet? Is there a way to benchmark it? A regression test would also be nice to have for this purpose.

At the moment I haven't done any profiling. I haven't thought of any benchmarking except for total time spent. The inner loop runs until convergence so we may have to change that to run for a specific number of times for profiling purposes.

Kevin

Hi Sven,

I haven't had any time to try this. I depart this Saturday and don't anticipate having more time to devote to the healing brush in the near future. Once I get settled I'll set up a work environment and try and work on the code some more.

Kevin

On 9/13/06, Sven Neumann wrote:

Hi Kevin,

a while ago we discussed how to change the heal tool so that it doesn't do it's time-expensive calculations while the user is painting but to delay it until after the mouse has been released. Have you tried to change the code in this direction? Do you need more help with this?

Sven