Looks like a for loop iterating over each pixel one row at a time. What makes this fast?
It does at least parallelize the work across available cores.
Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
31–40 of 66 posts
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#32Years 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. Turns out it seems to be something people care about. I should just start writing the CLI tools I think of, without dismissing their utility.
[deleted]
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#33Compared to the other tool this is just "slow code, but now with threads."
This problem is perfect to exploit capabilities of modern CPUs, and neither of the projects does so. At least this one iterates over the y coordinates in the outer loop.
Nothing about what either tool does is noteworthy.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#34I solved this problem for my use case by using an approximate diff.
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".
The "code" is here: https://github.com/c9fe/ViewFinder/blob/84620bd87abb32b2f2c3...
And a demo of the project is: https://demo.browsergap.dosyago.com (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!)
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.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#35Years 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. Turns out it seems to be something people care about. I should just start writing the CLI tools I think of, without dismissing their utility.
Did you know that ImageMagick includes an image diffing tool? https://imagemagick.org/script/compare.php
...plus ImageMagick has a myriad of options.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#36This feels like an application where an APL one-liner would just be the fastest thing that there is.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#37Worth noting it's ~100-lines of Go code that's quite readable:
https://github.com/n7olkachev/imgdiff/blob/master/pkg/imgdif...
https://github.com/n7olkachev/imgdiff/blob/master/pkg/yiq/de...
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#38Worth noting it's ~100-lines of Go code that's quite readable: https://github.com/n7olkachev/imgdiff/blob/master/pkg/imgdif... https://github.com/n7olkachev/imgdiff/blob/master/pkg/yiq/de...
This is a go question but I thought go funcs took less than a thread. This assigns one go func per cpu. Can it be faster with more go funcs per cpu?
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#39Worth noting it's ~100-lines of Go code that's quite readable: https://github.com/n7olkachev/imgdiff/blob/master/pkg/imgdif... https://github.com/n7olkachev/imgdiff/blob/master/pkg/yiq/de...
This is a go question but I thought go funcs took less than a thread. This assigns one go func per cpu. Can it be faster with more go funcs per cpu?
Likely not. Green threads concept (goroutines) makes a lot of sense if you block on I/O (such as reading DB, making RPCs), you can multiplex a thread. However, in this case, there is not a lot of I/O involved so regular CPU-bound parallel programming practices apply.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#40Why not use the GPU? This is exactly the kind of tasks GPUs were designed for. Gimp can do this in real time using the difference layer mode.
Does using the GPU pay off for one-off diffing? It's "obvious" that it makes sense for Gimp, but does it for this?
Compared to a threaded CPU implementation, it only pays off if your image is already sitting in VRAM. This kind of operation should be primarily limited by memory bandwidth, so you're just making it take longer by copying the image to VRAM and copying the diff back.