Working With Found Images Questions

I picked one at random. Notice that in your 3 examples only one adds any meaningful information in the description -- that pictures will be downloaded from a camera. The really useful info is in the specification which, for KM, is much more completely documented on each action's Wiki page.

No. An image on the screen is not an object -- it's an ordered collection of pixels, each having particular characteristics. The action works best when comparing a screenshot of some or all of a screen to the current screen.

Ah -- now, perhaps, we've found out what your problem is.

The "screen" is what (probably -- other output methods are available) you are looking at this post on. It's that thing you take a "screenshot" of, the thing you really shouldn't use a "screen cleaner" on (they can ruin the coating), that you might use a "screen reader" to interpret... You might, incorrectly, call it the "display" or "monitor" or "magic moving picture".

That is not only colloquially correct -- since KM runs on Apple devices it is also technically correct. Now that you know what a screen is, perhaps you'll understand what the action does.

Here's the default action, as freshly added (it autofills a recently-used variable, so yours will be different in that respect):

Find Image Default

So, by default, it will look for an image that you paste into the image well in "all screens". That's something anyone who knows what a screen is can understand without having to go and look up "viewport" -- probably 99.999% of users, plus you now. And now you know what a screen is you'll also understand "main screen" and possibly "screen with index". The "Window" variations should be self-explanatory, as should "area".

The number of users who won't understand the above terms but will understand "viewport" is vanishingly small -- and has probably vanished altogether now you know what a screen is.

Yes, I'd like to see that as well. But that's me being a nerd -- if you can paste it into the image well, you can use it. If you can pick it with the file picker, you can use it. If the OS puts a bitmap version on the clipboard when you copy it, you can use it. If it's an area of the screen, you can use it. So while it would be nice have an explicit note as to what formats can or can't be used, it doesn't really matter in day-to-day use.

1 Like

The definition that you offered (i.e., "an ordered collection of pixels") fits an object more. Furthermore, in the books on computer graphics I read, I never came across a stern definition of a graphical object you insist upon. The meaning is derivative and is used most commonly in the appropriate context as in

Although images on the computer screen are represented using pixels, specifying individual pixel colors is not always the best way to create an image. Another way is to specify the basic geometric objects that it contains, shapes such as lines, circles, triangles, and rectangles

(Introduction to Computer Graphics, David J. Eck). That's one.

An image consists of pixels but it's not an ordered collection of these. It's just a representation «using pixels». What's more, it's not a definition but merely an ad hoc observation. The usage of the term has solidified in due course (similar to the saying "the grass is green and the sky is blue") just like "a graphical object" has. You may want to use "Find a graphical shape" instead of "find a graphical object". That wouldn't change a thing, That's two.

You're right when you draw a line between an object and an image. You claiming KM detects an image is where you slip. I'm sure the developer knows all of that, but his choice of action's title was injudicious. That's three.

Based on my knowledge corroborated by input from people in this thread, I assume that the action looks for matching pixels. I don't know the mechanics of how it identifies and compares pixels in the case of KM, nor do I have to. However, calling the lookup target "image" is ambiguous because it's inaccurate. What I meant in my previous post was that action looks not for an image but for a graphical object, or, even better now, a matching group of pixels. That's four.

Considering that, I have yet another candidate for the descriptive name of this action: Identify matching pixel area. It scours for an identical group of pixels to match, it scans for a matching graphical object but it doesn't look for an image.

How did you determine that only one adds any meaningful information? Just because you decided so? I think otherwise.
A user doesn't need all or nothing. More often than not, a concise note regarding the purpose and intent of the function will do.

I don't take a screenshot of a computer display, meaning the physical surface with the coating on it that's warned against using a cleaner by that. I take a screenshot of a visible graphic area that is dangerously close to the meaning of the term "viewport". Is this where the clownery comes from?

You don't know the number of users who do understand or do not, and you're delegating yourself additional powers on behalf of those whose opinion you didn't ask. So, appealing to the unknown is a weak argument.

So, because you have asserted that it doesn't matter for you, you inferred it doesn't matter at all? Well, if I asked then it does. And where is one there are two. This position breathes arrogance which is not good. Not good at all.

Again, I still haven't gotten the answers to the two very important questions: what file types are valid, and what is the scope that the action searches within?

It is better to start a new topic when you have a question rather than reviving one that is 6 years old.

Everyone who uses Keyboard Maestro knows what an image is and what a screen is. Only a tiny fraction of those users would know what a “viewport” is and few would get any help from the term “graphic element” whatever that is supposed to mean.

In any event, this thread about the details of the naming of the action is far off track of the topic of finding images on the screen so I am closing the topic.

3 Likes