If the image will always show up in a certain area of the screen, we can also limit the search area. I did not notice that until now. I could limit some of my found image action to a 40*35px area.
Yup, you can even save a found image to a variable, and reuse it later:
7 Likes
wow.This is amazing! Thanks for showing it!
2 Likes
Fair enough, and 100%... I'm going to revamp my macros with KC's method. If it solves the issue (which it sounds like it will) than absolutely, I'll update and acknowledge that the issue was me not understanding KM well enough yet.
And I don't disagree, I've put a month of hard labor into automating what I can. While it's been frustrating watching KM come to a grinding halt, I'm sure I projected some of that frustration toward Peter without understanding that there are multiple ways to use the found image action...
Appreciate everyone's suggestions so far as well. If things go as scheduled I'll be updating this thread some time over the weekend once I've had time to tear through a good 1/3 of the macros I've created. Considerings things only got really rough in the last week/week and a half, it seems like I should see a big drop in the plist size, and some recovered snappiness by then...
Thanks again @kcwhat. Really appreciate you setting things straight. As I've said this seems to explain the enormous plist size. Cheers!
3 Likes
Thanks as well cc... I'll definitely give this a look. One of the more challenging issues I've had to work with so far is plugin windows being at different locations. Appreciate the tip. Best...
@peternlewis: enhancement request
IMO, it would be best if KM would do this automatically, and cache each found image image in a file instead of storing it in the master monolith file of all macros.
4 Likes
There are many ways Keyboard Maestro could work such that a larger database of macros could be supported. It could be an actual database instead of a plist for example.
But there are also consequences of these changes, and not just in my development time. Cache coherency is one of the hardest problems in computing. In fact there is a standard software developer quote “It’s often said that only two things are hard in computer science: cache coherency, naming things, and off by one errors.”
If the images are stored separately, then that will have a flow on effect on how syncing works. And what happens when the image goes missing, or is changed underneath Keyboard Maestro, and so on.
Yes, the monolithic plist has draw backs when folks start pushing Keyboard Maestro well past what it was designed for, but it also has advantages in other directions.
4 Likes
No problem @jackrabbitslim. Another move, that I made, was to use the built-in KM Icon Chooser, for my Macros bin icons, instead of trying to be so customized (aka cute) with my own pngs. At first, I just wanted to customize everything because I could. After you learn that speed wins, the behavior is modified. The good thing is you are learning early, in your Keyboard Maestro journey, so you won’t make those decisions. YMMV.
Good luck.
KC
4 Likes
Take a look at these.
-Chris
Definitely agree with that, that was the assumption I made... I can see it being useful for self containing a macro, but if the risk is creating a plist so big that the editor eventually has difficulty parsing it than seems like that would be the most headache free default....
That seems easy enough to solve: Add a folder "Image Sync" in the same folder where the main KM sync file is stored.
You do the same thing now if the user delete/changes the image file on the Mac where the file option is used in the Action. Doesn't the current Action fail when synced to another Mac which does NOT have the file?
To be clear, this request is NOT asking for you to change any other KM design other than how found images are stored.
FYI I followed KC's method and scaled every macro back by using the file option instead of embedding images within each macro. My plist went from just over 200 MB to 6.5 MB. KM is not longer laggy, in fact I forgot how snappy it was!
So far all the macros are working consistently, and they run faster...
I also wouldn't say I was trying to push KM to its limits, I just had a lot of redundant screenshots... For example if I have 50 macros that do the same thing, (load an instrument), however the specific instrument is unique in each macro, I wasn't just using the data required to store the screen shots required to run 1 version of the routine 50 slightly different ways; because I assumed KM was linking to the image I wound up eating 50x the data needed because I wasn't doing things properly.
Having very little programming background I didn't use subroutines/execute a macro like I should have initially... Now every macro references a subroutine wherever possible, and all images are linked instead of embedded. One folder of macros alone shaved off somewhere between 40-50 MB.
Anyway, my apologies to @peternlewis for being a jerk. I had no idea that KM converted each pixel of the image to code by default... Either way everything's running like a well oiled machine and I'm glad I got the growing pains out of the way early on....
8 Likes
That’s great to hear 
, and I’m sure this thread has been useful for those of us who only occasionally use found image and didn’t know about its performance impact implications.
Everybody: Is there something we could add to the wiki perhaps so that this kind of situation is something that fewer people might run into?
2 Likes
@peternlewis, I hope you will find this strong motivation to give serious consideration to my request:
Thanks.
1 Like
I would suggest that Peter has given it strong consideration already.
I for one don’t want to see this kind of feature. I don’t think making software accommodate unusual use cases is the best way to spend Peter’s time.
I'd suggest displaying a warning if/when the plist file gets larger than, say, 100mb, and point toward a Wiki entry with steps to reduce it to a more manageable state.
3 Likes
I would submit that this is NOT an unusual use case. From what I can tell in the Forum, many users use the various Found Image actions. AFAIK, KM is the only Mac automation tool that does this. So, when users discover how great it is, they tend to make great use of it. I know this is true for myself, even though I try to make found image the solution of last resort.
2 Likes
This is the sole feature that lead me to KM. I'm not being even slightly hyperbolic by saying this either...
KM was the only application that would solve the issue of automating repetitive tasks in an application (Logic), that has various parts of the UI where shortcuts aren't available, and the state of the UI element you want to change is variable -- meaning coordinates do not work. (For example - a Slider, a Knob, a view that may not always be in display, or a view or object can be 'floated' and may not always exist in the same location, etc).
TLDR: KM is the only thing that allows me to automate repetitive UI-based tasks in an application where many repetitive actions require a ton of unnecessary mouse clicks, dragging, etc, because the application does not have a shortcut for various common functions.
Not to mention this has lead to a huge improvement regarding carpel tunnel. So much so that it's more or less not an issue anymore...
Basically image recognition is what appealed to me, and I can pretty much guarantee it's the same missing link that has attracted thousands of other media composers, dialogue and post-production editors, etc to KM. Unfortunately editing programs typically have many limitations that require clicking and dragging on various UI elements.
2 Likes
I am so glad I found this thread. I've built huge drag-and-drop Found Image macros to automate bulk element creation in mouse-heavy web apps Airtable and FillOut. I've done it exclusively with drag and drop of screenshots, and I had been erring towards larger screenshots to ensure uniqueness. Hopefully I'll have the same success you did when I implement similar changes to yours.
Welcome! The found image is a great KM feature. If you haven’t seen this tutorial I wrote sometime back, it might be helpful. Basically it talks about using found image actions in conjunction with image files instead of images embedded directly into the action itself.
1 Like