Welcome to the Power Users community on Codidact!
Power Users is a Q&A site for questions about the usage of computer software and hardware. We are still a small site and would like to grow, so please consider joining our community. We are looking forward to your questions and answers; they are the building blocks of a repository of knowledge we are building together.
Post History
I never heard of Anti-Twin. So I went to the web site and quickly found the answer: http://www.joerg-rosenthal.com/en/antitwin/similar.html As expected, "byte by byte" will look for an exact matc...
Answer
#1: Initial revision
I never heard of Anti-Twin. So I went to the web site and [quickly found the answer](https://en.wikipedia.org/wiki/RTFM): http://www.joerg-rosenthal.com/en/antitwin/similar.html As expected, "byte by byte" will look for an exact match. Change a single pixel and it fails. Change something in the header (e.g., strip EXIF details) and it fails. "Compare image (pixels)" gets more interesting. In addition to the compressed vs. uncompressed issue, there are apparently other potential pitfalls: > As a technical requirement, the image comparison had to be programmed with a detection of only a fuzzy similarity. Due to different image formats and compressions, pixels always differ slightly, even if this difference is not intended (e.g. by color reduction or compression artifacts). As a consequence, Anti-Twin is deliberately inaccurate and even color-blind when comparing pixels. In addition, Anti-Twin ignores the image files' file sizes as well as height and width in pixels. This unfortunately results in a certain lack of reliability of the results displayed. This can easily result in False Negatives - e.g., a resized or cropped image will always fail. It can also result in False Positives - an image that has been changed in some subtle but visible way, such as adjusting brightness uniformly across the entire image by a small amount, might show as a match due to each pixel being "close enough".