> Hal wrote:
>> I wrote:
>>> that means we can use exactly the same interaction as the clone
>> This is exactly the way this works in photoshop and I can't think
>> of any
>> reason to do it differently. In fact this is exactly what I would
>> expect as a user.
> Let me explain the difference between the clone tool and the healing
> tool in more detail.
[snip] I get the picture, smart blending clone tool on steroids...
> Therefore one does need an area D which includes the defective
> parts but whose boundary must not contain any defective pixels.
> Please have a look at the example given on page 3 of
can we first of all agree that no photographer would put the source
cursor in a highlight area when repairing a shadow area? I am sure
that T. (doesn't he have a first name?) did that to show off how cool
the algorithm is.
> If the healing tool were to applied on the fly while the brush is
> over a
> defective part, its boundary will most probably contain defective
Let the computer do the work. Add just one pixel around the user brushed
area, and bingo! condition met.
> So, if the 'brush style' of the healing tool is a must, I'd suggest to
> do away with the healing tool altogether - as a separate tool. Instead
> one could add a post-processing option to the clone tool which
> tries to
> call for the chameleon described above.
now there is an idea: healing as a clone option, one tool less. cool.
Of course the post-processing part is should be unnoticeable by the
I can live with a bit of cheating where the user sees an immediate
feedback that is just cloning++, and within 0,5 seconds the real
healing algorithm catches up.
> For that to implement, one would need to gather the (set-)union of all
> the regions having been touched by the brush in the source as well
> as in
> the destination area.
no. a photographer will be concerned with image fidelity and be
moving the source cursor all the time. you will get many tiny
disjunct and fundamentally different (different source offset)
healed areas. which can be calculated individually, which will
be temporised by the speed the user works.
In case of your long scratch: even in the unlikely case of the
user not using several source cursors along its path, the
actual brushing of the scratch will be a painstaking affair
meaning relatively slow S and D area growth.
Use these assumptions for your optimisation.
Forget rectangles, the brushed user selections are it.
looks ideal that the user is specifying which pixels belong
to S and D.
Remember that for the high-end photo manipulation tasks
we are designing for here, the users are so discriminating
that in principle no computer algorithm is good enough to
do things automatic. However that must be painful to a
mathematician, we saw this during the user observations.
So the healed area will be the absolute minimum, to
not destroy photo-realism. Transparency will be used
at the edges of the brush to blend the healing,
guided by the eye of the user.
which is all that counts at the end...
principal user interaction architect
man + machine interface works
http://mmiworks.net/blog : on interaction architecture
Gimp-developer mailing list