Looks like a for loop iterating over each pixel one row at a time. What makes this fast?
It's fastest because others are slower. It doesn't necessarily mean it's fast :)
Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
21–30 of 66 posts
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#22Earlier quoted context omitted.
Were you comparing two identical image? Could you try two different image?
To really see how these algorithms perform, you should compare the worst case for the algorithm. In order to see if a picture is identical, you’d have to loop through every single pixel, which is the worst case. But you can shortcut on the first pixel which is different, which I imagine happens pretty quickly on many generic pictures. So testing performance with two different images is probably not best for compariso…
You can only short-circuit if you’re returning a Boolean. If you need to do what these tools and return some metric for the degree of difference you still have to process both images in entirety.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#23Earlier quoted context omitted.
Considering the source material is a file, that needs to be loaded up by the CPU first, and the operation itself is dead simple, the real constraint is RAM bandwidth. I would guess that the time of getting the data out to the GPU and back, is about the same as just calculating the difference on the CPU. So, the quickest solution is probably to use the CPUs vector operations, and read ahead into the registers so you c…
I recently tried this with a 19 megabyte .tiff file in PyTorch. Uploading the tensor took (i think) around 1 or 2 seconds, wall-clock time. So I quickly dismissed the GPU solution to my problem. But I'm still wondering... is this normal?
You've got your GPU program that needs to be compiled to actual GPU code at startup as well. That takes a bit.
The actual file transfer is comparable to the GPU doing a memcpy. (You could also use pinned host memory if the GPU program is just doing a one-off read.)
GPU processing for simple operations really shines if your data is already on the GPU and your code is hot. Otherwise, it's more useful if the process is significantly complex enough to make the overhead of a cold startup insignificant.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#24What are some of the common applications for diffing an image?
I’ve used them for regression testing web apps:
https://github.com/python-needle/needle
Depending on your needs, detecting duplicates can also be useful – especially if you’re using some kind of CV tool which quickly assesses similarity and you want a second check to confirm that the highly similarity matches aren’t hitting some edge case failure mode.
One challenge is that you sometimes want to allow minor differences - think things like text aliasing or slight differences in the pixel values produced by different compression/color handling/etc. implementations - so there are some neat tools like pdiff which try to emphasize differences which the human visual system is sensitive to:
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#25What are some of the common applications for diffing an image?
Visual regression testing is a common example, especially with websites.
I've put a few simple examples in Node.js here: https://github.com/umaar/learn-browser-testing/tree/master/3... (just as learning material)
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#26I'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? 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?
I just skimmed through the code, but as far as I can tell, the main point is that this code is multi-threaded. Which, sure, gets the job done faster than the single-thread `odiff` on a single image, but is quite irrelevant for a tool marketed for tests/CI where many images are likely to be compared in parallel already (and maybe a single core is even available).
https://github.com/n7olkachev/imgdiff/blob/9b2a87e1b729c70b5...
Yep, uses as many goroutines as the number of CPUs, that's about it. Saying it's 3x faster or whatever in "benchmarks" without even saying what CPU is used in the benchmarks is just sketchy.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#27Years 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?
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#28When making an image manipulation/creation/diff/etc tool I'd highly recommend showing at least a screenshot or two of the result in the Github itself.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#29Why 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.
Considering the source material is a file, that needs to be loaded up by the CPU first, and the operation itself is dead simple, the real constraint is RAM bandwidth. I would guess that the time of getting the data out to the GPU and back, is about the same as just calculating the difference on the CPU. So, the quickest solution is probably to use the CPUs vector operations, and read ahead into the registers so you c…
GPU can now directly read the file on the SSD.
Re: Imgdiff: Faster than the fastest pixel-by-pixel image difference tool
#30You should probably provide instructions as to how to build it. The build.sh script does not work for me because cmd/main.go is not in GOROOT. go run main.go and go build inside the cmd/ directory works though.
I am really used to just being able to do go build from the root directory of the repository.