Weird matches on Click . . . the Found Image

I've been wanting to write about enhancing the performance of my Found Images. I turned on the "Display" option a while back. Many times my images are marked with less than 10%. But they were still found and working, so I haven't thought about it much.

Recently one of my macros stopped working because the image was no longer unique. I turned on the "Display" checkbox and was surprised. I see eleven Display matches – all with higher percentages than the image I want, in the bottom right corner at 1% (partial picture below). And none of those higher percentage matches look anything like the downward triangle in my macro image well (image ).

I use command-control-shift-4 on Macintosh to grab the image and then paste it in the Image well in Keyboard Maestro. I recently upgraded to Keyboard Maestro 9, but I don't know if that is a factor. I'd be willing to test with KM8 if not too hard.

My general interest in making better matches for images is much more specific now. How can I best make sure that an image matches just what I want?


I like to experiment and I'm starting to feel like I should have experimented more before posting. On the other hand, this macro has been working fine for over a year. So something has changed but I'm not sure what.

One thing that probably should change is how much I know about the Found Image feature. I changed the option of which image to select from Bottommost to Best. It still selects the bottom one, even though it is marked as 1%. (Note this test uses a different image well image than my previous post.) . //short break while I read forum postings about troubleshooting Found Image//

Aha the percentage is how much fuzz was needed, not how good the match is. I usually turn fuzz way up because it seemed to help before. I think I understand most of what is happening. Perhaps I accidentally nudged the fuzz setting on the macro step.


Yes, the percentage is the fuzz setting required. For this case, you want the “unique” setting, and you want a low fuzz (5% say), which will then only match the correct item, and will fail if for some reason another one appears.

In Keyboard Maestro 8, there was no option to select which kind of match, so it was always "unique, or near enough" - basically unique, but if one image was clearly better, that was ok.

In Keyboard Maestro 9, with the option to select which kind of match, this relaxation of the unique option no longer applies. You can use “best”, but better is to use “unique” and adjust the fuzz appropriately.

Thanks for the clarification. It all makes sense now! And it means I don't have to make my images "better" because they're already very matchy. I'm declaring success.

That may be Peter, but I have seen many reports by other users of the Found Image failing when upgraded to KM9, and IIRC the solution for all was to change from "Unique" to "Best". So you might look at your code to see why this is happening.

Folks solved their problems by switching to “best”, not because that was the right thing to do, but because that was the easiest thing to do. In every case, if “best” works, and if the best solution is significantly better than any other (which was required for it to work in version 8), then adjusting the fuzz and leaving it as “unique” is the correct solution.

There are usually multiple solutions for any given problem. I don't know that I would label one "right" or "wrong".

If switching to "best" always works for a given use case, then it is a "good enough" solution. Fiddling with the "fuzz factor" is a trial and error process, much more time consuming to do.

Perhaps my perception is wrong, but it seems like using "best" with KM9 is equivalent to using "unique" with KM8 in many cases.

So when I encountered this issue I just changed "unique" to "best". If that worked, fine, I moved on. If any of those did not work, then it would be worth the effort to leave as "unique" and fiddle with the "fuzz".

Just my approach. YMMV.

1 Like

Not really, no. Because “best” will always succeed if there is any match anywhere, it will always click on something, which can be bad (potentially very bad).

In version 8, it would only successfully match if the best match was clearly the uniquely the best match.

So I label the correct, right, behaviour if you want to match a single specific thing to use “unique” and an appropriate fuzz.

If you use “best” and a large fuzz, then you leave yourself open to a case where there is a second match unexpectedly on the screen somewhere and clicking in the wrong place, rather than the macro failing and dealing with the issue appropriately.

So IMO, it is better to take the time and ensure the macro is robustly working properly, and will properly fail in a case where it should fail, rather than apply a bandaid solution and hope you don't cut yourself further down the track.

1 Like

But doesn't the fuzz also affect the "best" found image selection? IOW, if the fuzz is very small, then no image would be found, whereas if it is large, then one or more images might be found. Don't all of the matches still have to meet the criteria set by the fuzz level?

I guess I'm still confused by the behavior of KM8. It sounds like "unique" might also result in a found image even though multiple images were found. This sounds like to me that KM8 was actually using a "best" method, provided that one image was matched much better than all others.

BTW, I agree that using the "unique" setting with a proper "fuzz" is a better solution than using the "best" setting with perhaps a larger "fuzz". The real danger is when the "fuzz" is set to a very large value where almost anything on the screen matches. Perhaps there should be a warning in the KM Wiki about this, and maybe also if the user sets a large fuzz, then a warning is displayed in the action.

All of this reaffirms my design methodology that using "Found Image" actions/conditions should be a choice of last resort. IOW, first look for solutions that are discrete, deterministic, like clicking on, or checking for, a button or menu item. Even using a UI script would be preferred.