On 21 Feb, peter sikking wrote: >> 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 Yes, he's called Todor > the algorithm is. Yes, of course. But even tiny differences in lightening show up. If not, you're fine with the clone tool. There is no other magic to the healing tool than adapting 'lightening'. > >> 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. Probably my explanation wasn't clear here. Of course, the user can heal one defective are after another. But one single defective area, i.e. an area large enough so that it's boundary doesn't contain a defective point anymore, must be selected (by the brush) at once. snip > 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. I wouldn't be so optimistic. We have to solve a linear system with as many unknowns as there are pixels in the selected area. If that are more than 100,000 that will take a bit of time. If haven't implemented the algorithm, yet, so I don't have any timings now. But I'd like to use some sort of progress meter if such a thing is already there. (today we have about 10,000,000 pixels per image, tomorrow even more.) >> 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. Then we have two choices: Either force the user to not release the mouse button (or pen) until he's finished brushing one defective area completely. (For me that's too much stress since releasing the button/pen too early would initiate the postprocessing with undesirable results and force me to undo everything.) Or, don't do the postprocessing immediately but wait until a button or something else is clicked. In that case I have the problem to identify overlapping regions and to take the union of these. If someone has a simple and fast algorithm for that, OK. > > 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. No no, a completely wrong idea about a mathematician! I don't want any automatism, on the contrary I dislike an automatic postprocessing once I (happen to) release my mouse button or pen. > > 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... and we have just to find out how to come close to that! Helmut. -- Helmut Jarausch Lehrstuhl fuer Numerische Mathematik RWTH - Aachen University D 52056 Aachen, Germany _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
