Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Yikes! I beat my head against this one many years ago and never came up with a viable answer for my problem. I have had some thoughts since that I haven't tried to implement and I'll throw them out just in case they do you any good:</p> <p>I disagree with Al Crowley's statement about the average RGB values--the cropping could very well be the removal of an object that was quite different than the target.</p> <p>Furthermore, an observation: Reducing images to an 8x8 thumbnail (not that it's big enough for human eyes) and taking the square of the difference of each component does a pretty good job of picking out duplicates and often works even with small crops around the edge. Ideally contrast should be normalized before doing the thumbnail, I didn't do it and found it was declaring a bunch of low-contrast images to be dupes of each other when they had no similarity at all. This approach uses only 192 bytes per image and thus allows you to compare a large number of images in memory although it's still an O(n^2) algorithm. (I made it so you could close the program at any time, it would dump the state info and shut down, next time it would resume where it left off.)</p> <p>Given what you are describing as a problem I would be inclined to try taking a set of test crops of the image and running the comparison against each crop. When you find a likely candidate then start working with bigger images and try to narrow it down by jogging a few pixels and seeing if it gets better or worse. I can't imagine anything other than very slow performance from such a routine.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload