compare -subimage-search command hanging

[farzher]

Code: Select all

compare.exe -metric RMSE -subimage-search screenshot.png locator.png null

This command just hangs and runs my CPU at 13% until I press Ctrl + C

Other compare commands are working just fine!

[snibgo]

Perhaps it has problems writing to a file called "null". Try "null:" (with a colon) instead.

[farzher]

Good idea, I didn't realize there was supposed to be a : after null.
But that didn't work; I've also tried whatever.png

The command works if I just remove -subimage-search
Well, it complains about different image sizes, but when I use the same image twice it's all good.

[farzher]

If I flip the two images, instead of hanging it complains "image size differs"

[farzher]

Wow, so I let it run for a minute, and it actually finished successfully, and I think detected the subimage too (:

But, why is it taking so long!? Images are ~800 pixel resolutions.

[fmw42]

The subimage search is slow for any metric because it has to do a full pixel-by-pixel comparison for each pixel shift of the smaller image with the larger image. And yes the larger image must come first in the command line.

If the two images are the same size, then leave off the -subimage-search.

What are the exact sizes of your two images?

Best way to speed it up is to use more threads, if you have multicore processor. Compile IM so that it uses OpenMP.

The other alternative is to use my scripts, rmsecorr or normcrosscorr, if you are on Linux/Mac or Windows with Cygwin. It is orders of magnitude faster. But you need to install the FFTW delegate library, since my scripts process the images using Fourier Transforms and the IM FFT function.

[snibgo]

But, why is it taking so long!? Images are ~800 pixel resolutions.

Try doing it on 5000x7500! The time required is proportional to the fourth power of the linear dimension. The trick is to resize both images so the search is much faster but the result is approximate, then use this result to search a crop of the full image.

My current scheme (for photos and videos) is to resize both images the same such that the small image has the smaller dimension between 10 and 20 pixels.

[fmw42]

Snibgo is right. I forgot about multi-resolution processing. I have used that in the past as well.

[farzher]

Thank you for all the tips!
My resolutions are
850 x 590
67 x 57

But I'll need to use a 1080p base image (I'm looking for something on the desktop). Maybe I can shrink the sub image I'm looking for.
It doesn't make any sense how this is so slow though, because there's a thing I've used called Sikuli script, which allows you to automate stuff, and you can have it search for images and then click them or whatever and it's very fast.

Can I do some fuzziness or something to speed this up? How are they able to do it so quickly?

[fmw42]

Thank you for all the tips!
there's a thing I've used called Sikuli script, which allows you to automate stuff, and you can have it search for images and then click them or whatever and it's very fast.

There are speedups to running normalize cross correlation, but they usually involve FFT processing. Sikuli is based upon OpenCV, which has a faster normalized cross correlation algorithm, which is also based upon FFT processing. IM uses the more brute force spatial correlation techniques which are bound to be slower.

What platform are you on? If not Windows, you can try my scripts. They are orders of magnitude faster.

[farzher]

I'm on Windows /:
And I don't want to make things too complicated, because I want other people to be able to use this code on their computer.

[fmw42]

I'm on Windows /:
And I don't want to make things too complicated, because I want other people to be able to use this code on their computer.

Then your only option right now is to use IM's brute force method and try multi-scale processing as snibgo suggested. Scale down both images and do a full search. Then locate the region where you get the best score and crop out a subsection that is a bit larger than that in the full resolution large image and search that with the full resolution small image.

[snibgo]

I would shrink both images by a factor of 5 linear, so they become approx 170x118 and 13x11. This would speed it up by a factor of 5^4, or 625. A massive saving. The result is approximate, so you have do do another search, of 67x57 in 77x67.

I expect programs more sophisticated than IM use some variation of this techniqe.

[farzher]

Maybe this isn't the algorithm I want to be using?
Since in my case I'm looking for an image on the desktop, which is a screenshot, not a real life picture, and pixels will be the same exact colors as in my sub image; there's probably a way more efficient way of looking for it.
I think It'll be easier to just write my own loop, looking for an exact match. And I'll use IM for all the other things I'm currently using it for.