Helmut wrote:
>> Painting with a brush is just a way to select an area. And a very
>> nice
>> and intuitive one also. The problem with the current
>> implementation is
>> however that it tries to heal while you are painting. This doesn't
>> quite
>> work. I think it would be better if, while you are painting, the tool
>> would work like the clone tool. Then, when the mouse is released, the
>> healing algorithm should be applied on the area selected by the paint
>> stroke.
>
> This has two disadvantages. First, you won't see the real effect until
> you're finished anyway.
this I can agree with.
> Second, this might give many disjoint sets of points,
> which is difficult to handle in the algorithm.
whenever I have to choose between the user sweating a bit or
the developer, it will be the one that starts with a d...
let's have our priorities screwed in the right way around.
> There are a bunch of selection tools including the quick mask. Using
> these it's much easier and quicker to select a region than painting it
> with a brush.
boy, am I glad we went out and did workplace observation as part
of the project I am running. that means I can say with confidence
that the brush is the way to go. actually healing is applied
extremely local, with the tiniest brush, to take out only the
irregularity, and not to destroy the all important texture around
this spot.
> In most cases the lasso tool would do.
> Since the healing tool is of more 'global' nature, being forced to
> use a local tool like a brush seems misleading.
> What could make sense would be to use a selection (one in the
> destination area and a translated one in the source area) first,
> compute the 'healed' area without pasting it into the destination
> area, yet. Now the brush could be optionally used to copy parts
> of the healed area into the destination area.
now that we got the brush part nailed, we need to find something for
the user to set the source area. To me as an interaction architect
the healing brush looks like a smart clone tool on steroids.
that means we can use exactly the same interaction as the clone tool.
both tools need a bit of cleaning up in the tool options I think.
set a source location, heal a tiny bit of the photo.
set a new source location, heal a tiny bit of the photo.
set a new source location, heal a tiny bit of the photo.
set a new source location, heal a tiny bit of the photo.
set a new source location, heal a tiny bit of the photo.
set a new source location, heal a tiny bit of the photo.
set a new source location, heal a tiny bit of the photo.
set a new source location, heal a tiny bit of the photo.
looks as straightforward as it gets to me.
>>> A bug has been reported when source and destination areas are of
>>> different depth. Since, IHMO, the healing tool doesn't make sense
>>> in that case, I'd suggest to simply abort with an informative
>>> error message.
>>
>> Why does it not make sense to heal a region in an image using a
>> texture
>> from another image, or from another layer in the same image? The
>> clone
>> tool supports this nicely, so it seems to make some sense that the
>> heal
>> tool supports it as well.
>
> The main difference between the cloning tool and the healing tool
> relies
> on first computing the quotient of the pixel values in the destination
> area by those in the source area. Then, these factors are 'smoothed
> out'
> by solving a Poisson equation. Finally the source pixel values are
> multiplied by these factors before they are put into the destination
> area. Currently the R,G,B values of the destination and source area
> are divided by each other. How can this be done if there are, say 3
> values in the destination area but only 1 value in the source area.
"the healing brush looks like a smart clone brush on steroids."
the solution is already there in the clone tool...
--ps
principal user interaction architect
man + machine interface works
http://mmiworks.net/blog : on interaction architecture
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
