Improve ImageSearch 2

[iseahound]

This is the second attempt at improving ImageSearch.

The following fixes a bug where the last row of images is not searched.

https://godbolt.org/z/oEoMW7zEK

[iseahound]

Use -O3 for the above script. For some reason it wasn't allocating variables correctly into registers and instead using the stack which is slower.

[iseahound]

https://godbolt.org/z/WPWjf8c96

[martona]

I don't know if you'd be interested in an external contribution. I'm working on an imagesearch replacement with more features (tolerance and % of pixels matched). I'm getting close to finishing it but I'm not dead set on releasing it as standalone.

I have 512 and 128-bit SIMD working, and also have the pedestrian base code that doesn't use vectors, even though that's not a strict necessity because every 64-bit CPU should have at least SSE2. Pretty happy with what I've got so far, at least with the speed.

I still need to write the 256-bit part but that should be easy with how modular the thing ended up being. The unknown is the CPUID stuff and sorting the computers into v4/v3/v2/v1, which largely describes the vectorization tier but also the gcc -march option used.

Anyway, lmk if there's any interest.

[iseahound]

Sure thing! As many approaches as possible are the best possible solution. I'm still working on optimizing the basic ImageSearch functionality by avoiding the O(n²) subimage matching loop as much as possible.

[iseahound]

Saved work (notes to self):

• https://godbolt.org/z/j6bvo1YPd 1
• https://godbolt.org/z/qqPd3W7qs 2
• https://godbolt.org/z/3vTeT3E6e all2

[iseahound]

@martona There is a requirement for a "focused pixel" (an additional pixel in the center of the image or to be determined by some algorithm). See: https://godbolt.org/z/j6bvo1YPd

An explanation: Doing 2 pixel searches in parallel reduces the need to enter the subimage matching loop (for lack of a better term). Also, if the top-left pixel is transparent, it's necessary to have a visible pixel somewhere as a backup.

[iseahound]

Notes:
#33 - Completed optimizations using parallel PixelSearch before ImageSearch.
#36 - Adding variation to ImageSearch (wind0204)

[martona]

I'll tidy things up and give you access to a repo later today (i'm in the US, East), you can check it out for yourself.

My take on the C stuff stuff you're doing... don't sweat optimizing it. I mean you can, it's fun, but vectors are so much faster. I don't have recent SSE2 numbers at hand but AVX512 is an order of magnitude faster than what you can achieve with wrangling standard C code. SSE would be slower, probably half the speed of AVX (much of it because it's missing integer cmple/cmpge for some reason). 256-bit SIMD should be the sweet spot.

Just to give you a rough idea, my test haystack is 822x987, needle (75x51) is found at 680x430 or so, and avx512 can do it in 2ms with the benchmark written in AHK and using ImagePutBuffers for both haystack and needle, so there's some overhead. If i'm not forcing a topleft pixel match (which is an option), and it means entering the subimage search for every haystack pixel, it's still just 10ms.

But, to be fair, I ignore he A channel completely. I suppose handling it in a non-fancy way wouldn't slow things down much. I just never had the need for it. It's usually about finding stuff that came from the screen, on the screen.

[martona]

Great work on the ImagePutBuffer project btw, it's immensely useful and a joy to use.

[iseahound]

Thanks! I personally have zero use for ImageSearch/PixelSearch myself, so any work on it is purely for learning, academic, or for fun. With that said, one common use case is when the target image is a sprite (meaning there is a character surrounded by transparent pixels). By ignoring those regions, one can search for a non-square collection of pixels. (You can do: ImagePutBuffer({sprite: "cat.png"}) or buf.TransColor()).

SIMD intrinsics are best for when repetitive data can be streamed, such as in a loop. There's some outer logic which controls how often the subimage loop is entered / exited which can be highly optimized by the CPU. For example, if one branch is 90% vs 95%, the 95% approach can be over 2x faster because it can anticipate it twice as much. To me, optimization is like a layer cake. Each level of complexity has different things that should be optimized. For example, the current ImageSearch + variation is unoptimized, because preprocessing can be done to split the target image into high and low variation images instead of encoding a SIMD instruction to do color + variation and color - variation.

My testing showed 3.4-3.8x speedup for 128-bit registers, and maybe a 50% increase over that for 256 and maybe 20% for 512. It's wildly CPU dependent, with better results nearing the theoretical 2x for better hardware.

[wind0204]

Awesome, I can't wait to see which SIMD instructions are being used. :D

[martona]

I see. Well, transparency can be handled trivially in the lo/hi mask precalculation phase where you can just set 0/0xffffffff for the masks in the locations that you want to ignore.

I sent you an invite to the repo with imagesearch. I just extracted it from the project I made it for, so it's pretty barebones re. tests and stuff.

[iseahound]

@martona It seems we have the exact same approach: https://github.com/iseahound/ImagePut/blob/master/source/pixelsearch2x.c
which is fantastic.

From my understanding, you're currently searching for one image correct? The approach with popcount/BitScanForward required a lot of extra C code on my end, so I simply allowed it to fall back to the "v1" approach when the mask returned positive.

__m128i vmask = _mm_set1_epi32(0xFFFFFFFF);

should this be -1 in my code?

[iseahound]

@wind0204

Some additional results:

• Replacing div with cmov didn't produce a speedup that was significant. In addition, it's the 3rd check after the focused pixel and the top-left pixel, so the additional code for left wasn't worth it.
• I also tried removing the line if (trans || c1 == *(current)) because it seemed redundant, but there was no difference in speed.

https://godbolt.org/z/M6nofK9hs