Thanks, Peter.
Is there much of a performance hit between matching the first image (say, 100x200px) and matching the 10th image in an "If Any Are True" list?
That's the point of my wanting to add the newest option at the top, my presumption that it's the most likely match going forward, and wanting the macro to execute snapily.
Thanks for the idea of matching file images, Chris (cdthomer). I'm intrigued about how it could make things a little more organized.
Do you have any idea if the macros run faster or slower that way? Does it have to do multiple file accesses each time the macro is run, or does it load the whole set when KBM is loaded, or what? What are the symptoms of "plist bloat"?
As for the copy and paste cycle, that's what I'm already doing. I add a new option at the bottom and them copy and paste each "The Screen: ⇳ contains ⇳ Image:" items successively down the chain until I can paste the new entry at the top. Since the tiny thumbnails all look alike, I keep track of where I am with the Display checkboxes. In my imagination, I don't see copying and pasting pathnames as being substantially faster; I still have to copy and paste each item in the chain.
Thanks.
Thanks Chris (ccstone).
This whole approach looks intriguing, and not just for this problem. I think I want to try these macros out to get familiar with them (when I have some time to play...).
As for my current question, it looks like this can be handled by cutting the new item from the bottom of the list and inserting at the top of the list. That makes the update effort constant, no matter how many items are in the list. That makes it feasible to let the list grow; as long as the most likely item is first, it shouldn't have much performance hit, right?
So if there are only 3 or 4 items in the list, it may be faster to just move things one by one down the chain, but if there are 10 or more it would be much less mind-numbing to manipulate the text version, once I have going into the text in my toolkit.
Thanks!
P.S. Is there a versioning spit? Should the Big Sur version not be used on earlier OSes (I'm staying on Mojave as long as I can) or can the V1.1 version be used anywhere?
When you say:
[KMET Sub-Macro] Get Selected Objects as Text .I presume you mean the macro named [µKMET Sub-Macro] Get Selected Objects as Text, right?
Thanks.
I think the Big Sur version can be used on Mojave, but there's no reason to use it - nothing else has changed.
No. All matches will run simultaneously.
So unless you break them in to multiple actions, Keyboard Maestro will do all of the matches. The conditions will abort once the overall condition is met (eg “any of” will complete if any condition returns true), but the match will probably continue to completion before it figures out its decision is no longer required.
Thanks. Is there any performance hit (or advantage) in having the matching image in separate files, as Chris suggested?
This is just my personal experience, and no doubt @peternlewis can correct me and/or expound on it if I’m wrong. But the macros appear to execute slightly faster when using image files rather than using images embedded in the actions(s). Could just appear to be that way though.
But what has been stated here previously (and by people far more knowledgeable than myself) is that when you place an image directly into the image well, it copies that image into Keyboard Maestro’s file system. What this means is that if you have a lot of macros that use a lot of “find image” actions, your KM file (I think it’s the plist file, but again, not 100% certain on the file type) can become very large, causing a general slowdown, especially of the editor. This is because every time you make a change to one macro, the entire plist file has to be updated (since every single macro is stored in one master file).
I absolutely know this last point to be true! Because over the last few weeks, I did a LOT of housekeeping in my macros (I have nearly 1,000), and switched from embedded images to image files. I also deleted a lot of macros I no longer needed (like simple text expansion macros that I can accomplish the same thing with Typinator). This has resulted in the KM Editor running MUCH faster and smoother.
Again, perhaps Peter or somebody else who is very knowledgeable on the inner workings of KM can explain more about advantages/disadvantages of using image files instead of embedded images.
External image files wherever possible. Less steps this way. The only time I use clipboards for images is for specific actions that require it. For instance, to set a Stream Deck button to an image I have to set a clipboard to an image first, and then set the button to the clipboard. As of now, KM doesn’t allow me to set the SD button to an image file.
There should be no appreciable difference.
Either will remove the data from the Keyboard Maestro Macros.plist file, which is generally desirable.
As @cdthomer notes, if that file gets large, then that will slow the editor down - it wont have much affect on the engine.
I mostly store them as clipboards, good to know that is fine. Thanks!
Thanks @peternlewis, @cdthomer, @ccstone,
This has been a very enlightening thread. My initial question has been more than answered, and the original purpose, making sure that KBM runs efficiently, has definitely been addressed.
As for macro editing workflow, it has been very quick and easy for me to capture screen clips to the system clipboard using Ctrl+Cmd+Shift+4 and then paste them into the Image Well and I would previously have recommended it.
However, the methodology of saving them as files allows me to add a form of annotation to them. I can name the clip with its date, purpose, etc. in a way that I cannot within KBM proper. (I had been considering asking for a feature to add comments to images be able to tell multiple image match options apart, but that's not necessary now; file names work for that and if makes the editor run faster, that's a total win.)
Thanks for the help, everyone.
Based on this thread from last Summer, and the performance comments by @cdthomer and @peternlewis, while I was working on cleaning up one of my most-used macros, I decided to try moving the images from the various Image Wells inside the macro to external files.
The macro continues to work, but what is lost appears to be the Display option in the Find Image action. When I have the image pasted into the Image Well, I get a green highlight on the screen that shows what part of the screen is being matched by the action. But when I have the image in an external file, I don't get the display of where the match is.
Since I am often matching images in an attempt to distinguish one part of a display from another, not know exactly what region triggered the match is not as useful to me.
Is this the intended behavior? If so, maybe the Display checkbox should go away when the image is in a file. Or is it a Known Bug?
Hey August, that seems odd. Every one of my found image actions uses an image file and I can display them without any issue.
How did you move the image from the image well to an external file? I’m curious if I’m the process the resolution or something changed enough to where KM no longer finds that image on the screen. Do(es) the action(s) work still?
Hi Chris,
At first I tried displaying the Image Well image using the Spacebar and doing a screenshot of that. I didn't care if I lost a pixel or two at the edges. When that wasn't consistently showing up with the Display highlight, I tried doing a brand new capture from the screen and saving that new capture in the File.
The Action shows that the image is found because the Until action shows the annotation of "(currently true)" when I add the image to the "until any of the following are true:" section. So it's working to find the image and make the logic decision, it just isn't giving me the green Display highlight.
It does give me the display highlight when I have either the current or the former image in the Image Well.
And your question prompt me to agree that I think it would be really cool to be able to extract an image from the Image Well and save it in a file.
Thanks for chiming in,
August
The more I think about it, the more I would really like to be able to directly put the Image Well images into a file instead of having to recapture them.
I took a look at the XML version of the macro, just to see if there might be a clue there towards how to extract the image. What's in the XML is the encoded image, like this:
<key>Conditions</key>
<dict>
<key>ConditionList</key>
<array>
<dict>
<key>ConditionType</key>
<string>ScreenImage</string>
<key>DisplayMatches</key>
<false/>
<key>Fuzz</key>
<integer>15</integer>
<key>Image</key>
<data>
TU0AKgAAGkKAOl1u5/gCDQeEQmFQ
uGQ2HQ+IRGJROKRWLReMRmNRuOR2
PR+QSGRSOSSWTSeUSmVSuWS2NwKC
S6ZTOaTWbTecTmdTueT2fT+gUGTT
CC0KjUekUmlUumU2nU+oVGVUSpVW
rVesVmtVuuV2vSmqSd/2OE2Oi1+0
Wm1Wu2W23W+d2GRvp9AAHNdnAADt
1tAAAup0wZ+vu4YXDYfEYnFYun3K
M2YAAtwtsAAxdrSDPR5xKyP8AwoA
2cA5/GaXTaedWQAarUa2TgIBaXHR
TIZLKAxXKbHwd4vt+AABgHYgzg37
R67kcnlRzjgB+7/nP3l9OM6QAAQD
bKB2eKv58PgABhRpaDPN5Rl/AoFA
BcNBuAB6ALpFUTh+/P1/dT9fv+Pp
8oMDr7AADwQoM2CDNU5sEtI1iDwU
osHoNCLjQQ7kJQZCEMQvCsNtXC0K
Q9DsFw5EEGxFDMSQnCaERVDUSxRE
KExbFMXOafz8vg84AGwayDH86S/N
iuDZofG78geaRkgABJfl1EiLn6AT
Pl+dj/nKEkCi6BTPgEbi+r0BMOv5
McyMQeR4oMJAloMI4nwNIUyv2fsg
HMcaDE4SjVn2uoAgGArCyIhTIHzQ
gAA4WpUgAARxHBJ6LH+zQAHuFIWA
AfYpi2ux1nMvxaFcgxzHKgwGAdRy
oNVE04q85rm1UkEzoMJIm1iKM31c
/U5oMclGgATZJz0wk+gJQDtohI1J
Hue4ABC8aDHue1TIi1R8vBZYRIMM
Y2tWAYBoMZhjoMVZRSDboAAUBkfQ
. . .
I'm sure there are utilities that can make sense of that, but that would be research project for me.
It reminds me of the old ASCII email days when the UUENCODE utility was used to encode images to be sent as text. It probably is exactly that under the hood.
I'm still curious, but I'm not pursuing it right now.
August,
Sometimes back I asked Dan the same thing, and it turns out that Dan has already done the research and implemented the extraction in his utility. You can extract all macros and their action information from his utility in json object.
The file format according to the Peter is tiff
[Lag as my projects get bigger]
I have developed a macro to decode it using base64, unfortunately the decoded image does not open even though it seem to be decoded correctly because there is readable text like "Copyright Apple Inc"
[EXP] Decode XML Image Data.kmmacros (15.3 KB)
Here the macro:
Oddly enought,
if the plist image data is decoded using this online service https://api.products.aspose.app/ocr/en/base64-to-img, the image is shown, but when decode locally, it failed.
August,
I have confirmed that those image are encoded in base64, and image type is tiff. The custom prompt window supports tiff. You can try the macro in
Saving decoded base64 image to file has to be done in binary mode. I believe that base64 filter KM Action did not work because it is saving the image in text mode not binary mode in reference to my previous reply.