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