I feel like I might have posted about this issue before. I haven't experienced it in awhile, and thought it had somehow resolved itself, but now it's happening again.
When I use the "found image" action with the search area set to "the front window," particularly in Chrome though this might also be the case for other apps, the action and macro, which previously worked just fine, now fail.
However, if I switch the action's search area to "front window's screen" or "main screen" or "all screens," the action and macro work perfectly fine again.
It's bewildering. And while, yes, I could always go and tweak all my macros that have found image actions so that they're no longer using "the front window," I'd prefer not to do this if possible.
Is this a bug? Any help would be greatly appreciated.
Sorry, I indicated this in the post's title but should have made it clearer in the body of the post, as well. It's when the search area is set to "the front window."
I should have noticed that. Sometimes I overlook info that's only in the title. I'm pondering now.
I'm quite experience with the Find Image action but it can be hard to troubleshoot something when I can't see the code. I'm trying.
IDEA: Some windows change their "colour" or "brightness" when they are selected vs when they are not selected. Could that be the problem here? In other words, when it fails could it be due to colour changes because the window is not in focus? Parts of the window do change colour when they are not in focus, at least parts of macOS do, I'm not sure about Chrome.
IDEA: If you change the fuzziness to a larger value, is it able to find it then? The fuzziness bar is in the middle of the Find Image action. Try a much larger value.
IDEA: I'm not sure about KM 11, which has made some changes to the Find Image code, but sometimes I find the KM Engine (for v10) has to be restarted to wake up the Find Image code. When did you last restart the engine? Which version of KM are you using?
POSSIBLE IDEA: Is your flag set to "Unique" or "Best".
Thanks, Airy. These are all good ideas, but most if not all of them wouldn't explain why the action is still working just fine when the search area is set to "front window's screen" or "main screen" or "all screens." (Unless I'm missing something.)
It seems like the issue might be that KM is unable to identify the front window? Like, instead of searching the actual front window, it's searching something else.
Oh, and I did try to restart KM, but that made no difference.
Restarting KM (that's usually what people call the Editor) is definitely not the same thing as restarting the KM Engine.
Which version of KM are you using?
I think I mentioned that windows can change colour a bit if a different window is in focus. That can cause a Find Image to fail. You did not clearly say which window was in focus during your tests, so it could be you have a different window in focus causing this problem.
NEW IDEA: Turn the Fuzz factor to maximum and turn on the "Display Flag." See what happens.
The fact that you didn't see any green rectangles on your screen tells me a lot. I'm pondering. Or did you see green rectangles appear on the screen?
Yes, but you didn't assert that every window in all your spaces was identical to before. I was worried about Chrome windows being in your spaces.
NEW IDEA: If you can't show me your action, at least tell me if they image you are trying to search for has multiple colours and shapes in it, or is it mostly just a solid block of the same colour? Find Image is a spectacular action, but it does "miss" images inconsistently if the image is mostly a solid colour.
This started happening for me a while back with Brave Browser. I've discussed it with Peter, and it seems to be something to do with Chromium-based browser window reporting that changed/broke in an update.
Restricting the search to a manually calculated window frame seems to be the worakaround for Brave. See if the same holds true for Chrome.
It's quite perplexing, because if KM can can restrict the search area based on the front window dimensions, then you'd expect a Front Window search to work, but nope.
I agree. The speed at which KM image searches run baffles me, honestly. However, I see it less as a resources issue and more as an isolation issue. Sometimes you need to find an image in only the front window that appears onscreen in multiple windows, and that's where a full-screen search falls down.
Exactly. This is why I try to set the search area to "the front window" whenever possible.
With that said, I might have to switch to one of the other search areas, unless a fix for this is coming soon.
I like your solution, @noisneil, but I think I prefer the simplicity of the native action. But I'm grateful you shared it, as I otherwise wouldn't have been able to confirm that this is the issue.
That's 100% true, except that in my experience there usually aren't duplicate images outside the window.
I don't even know what kind of mathematical wizardry is used by KM to implement it. I suspect it's an API, and I suspect the API sends a request to a API that the GPU has in its firmware, and I suspect that that API uses some "discrete Fourier transforms" which is something I know very little about. But here's a video showing how Fourier Transforms can be used as an OCR algorithm! It's amazing!
