Compared to the other tool this is just "slow code, but now with threads."<p>This problem is perfect to exploit capabilities of modern CPUs, and neither of the projects does so. At least <i>this</i> one iterates over the <i>y</i> coordinates in the outer loop.<p>Nothing about what either tool does is noteworthy.
When making an <i>image</i> manipulation/creation/diff/etc tool I'd highly recommend showing at least a screenshot or two of the result in the Github itself.
I'm skeptical about it's high claims. Looking at the code its just using the Go standard library image package, looping over the bounds and calculating delta?<p>Doesn't seem like there's anything special here? It's roughly what any novice would build if asked to diff two images in Go?
Years ago I worked with image processing and thought of writing a CLI image diff tool. I then thought meh, anyone can quickly roll their own.<p>Turns out it seems to be something people care about.<p>I should just start writing the CLI tools I think of, without dismissing their utility.
A bit meta and very cruddy - a cheap and cheerful ruby tool I whipped up back in 2014 that would render two websites and then diff them.<p>It was achieved by looping over every RGB pixel from the PNG rendered image of each URL.<p><a href="https://github.com/sammcj/urldiff" rel="nofollow">https://github.com/sammcj/urldiff</a><p>Not exactly something I'm proud of, but the pixel loop solution did make me laugh at the time.
For those interested, I created a gem in Ruby for comparing the similarity of images by computing the dhash of an image and then calculating the Hamming distance between the hashes: <a href="https://github.com/rohanpatel2602/ruby-dhash" rel="nofollow">https://github.com/rohanpatel2602/ruby-dhash</a>
You should probably provide instructions as to how to build it. The <i>build.sh</i> script does not work for me because <i>cmd/main.go</i> is not in GOROOT. <i>go run main.go</i> and <i>go build</i> inside the <i>cmd/</i> directory works though.<p>I am really used to just being able to do <i>go build</i> from the root directory of the repository.
This can be done much faster. The problem is memory/disk bound.<p>Decoding the PNGs should be most of the work if written properly.<p>Edit: Yes, this is more reasonable: <a href="https://news.ycombinator.com/item?id=25405595" rel="nofollow">https://news.ycombinator.com/item?id=25405595</a>
Congratulations on writing a tool that has 3 times the performance of the most commonly used competitor. The fact that you exploited simply straightforward technique in terms using Go's multithreading is a plus in my book, no magic just simple engineering. Also, thanks for sharing it :)
I solved this problem for my use case by using an approximate diff.<p>Basically diffing took too long ( I was diffing to remove duplicate frames from a virtualized browser to browser screencast ), so after trying to various options (hashing, diffs, etc) I just went with a simple check of a basically random but fixed set of pixels, which worked really well. I don't have data on the actual false positives/ negatives but for the thing important in my case, perceptual difference and not sending the same frame twice (to save bandwidth and speed) it worked great, and was "constant time".<p>The "code" is here: <a href="https://github.com/c9fe/ViewFinder/blob/84620bd87abb32b2f2c3dc0b79a0be5212fa14ee/zombie-lord/screenShots.js#L9" rel="nofollow">https://github.com/c9fe/ViewFinder/blob/84620bd87abb32b2f2c3...</a><p>And a demo of the project is: <a href="https://demo.browsergap.dosyago.com" rel="nofollow">https://demo.browsergap.dosyago.com</a> (if you check it on Safari mobile you need to plant your clicks about half a finger under where you think they should go, some bug!)<p>I'd like to know some idea of how this posted fast diff works. I checked around the repo and couldn't figure it out, but it seems to be splitting across multiple cores, but still looping over each pixel (but divided by the number of cores). I thought it might be doing something like checking 64-bit blocks somehow, but seems not.