Helmut wrote: > Hal wrote: >> I wrote: >>> that means we can use exactly the same interaction as the clone >>> tool. >> >> 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 > http://www.tgeorgiev.net/Invariant.pdf 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 > pixels. 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 user. 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... --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
