The OCR action isn't atomic and related OCR feedback

Questions & Suggestions
#1

I've just discovered that the OCR action isn't atomic. That is, if I have two separate macros running simultaneously and each macro performs an OCR action, the variables in the other macros can end up storing the text from the other macro! I don't think this is desired behaviour. Probably a bug. It has taken me days to figure out that this is the probable cause of my problems (if I was smarter I would have realized it faster.) It's difficult so submit code that will illustrate this, I'll just leave it to Peter to opine on whether my theory could possibly be correct. If this is not fixable then at least the OCR action documentation should explain the issue and advise on reliable workarounds (semaphores might work, but I didn't test that yet.)

On a related matter, it would be really nice if I could lower the priority of the OCR action. That action bogs down the responsiveness of the system. I can use the macOS "nice" command to lower the priority of my command-line-based OCR software, but I can't do it with the built-in KM OCR action. To me that's a missing feature. In general when I use OCR I'm not in a rush and I would like to lower the priority of the OCR action. (In fact a similar feature might be handy on any other actions that require heavy CPU processing, perhaps the Find Image action.)

Also I've noticed that when I try to use the OCR action on a blank area, I tend to get this error: "Warning: Invalid resolution 0 dpi. Using 70 instead." (I'm using a 5K iMac monitor.) What is the recommended way to deal with this error? This probably should also be in the OCR action documentation.

But I must say I love the new OCR action. It's pretty fast (though not as fast as the miraculous Find Image action) and usually pretty accurate. It does however glitch badly on about 0.1% of the words that I scan. And when I say glitch I mean totally bungle the word even when it gets the words around it 100% correct. For example, if I was trying to read a sentence, I occasionally get a glitch like this: "Humpty Dumpty sat on a wall, Humpty Dumpty had a great fall, all the King's eaieoaeiaoaei and all the King's men couldn't put Humpty together again." Repeated calls to the OCR action result in the same error. But if I move the image to another part of the screen there's a chance that the OCR action will return the correct words, but generally that trick doesn't help.

I have other things to say about the nice new OCR action, but I'll save them for another time. I decided to post this now because I think this information may help users to use the new OCR action.

#2

This seems highly improbable, so without a working example, I can't suggest anything.

Obviously, if you use the same (non-local/non-instance) variables in each macro, then they will each mess each other up.

And yes, the action is non-atomic - most every action that takes time in Keyboard Maestro is non-atomic.

This is unlikely to happen. The OCR, like the screen search, is a CPU intensive action - if you want to reduce your CPU usage, don't use the action, or don't use the action continuously - put pauses in your macros if you want to use less CPU.

Yes, this is an error Tesseract reports (more or less all the time), and Keyboard Maestro hides the error from you normally. However, if nothing is returned as matched text, then Keyboard Maestro returns the error response, which includes this message.

Cleaning up the image, in particular thresholding it, seems to improve Tesseract’s accuracy (unfortunately, Keyboard Maestro has no thresholding or other image processing actions, so you'll have to use something else for that).

Triggering Stream Deck profiles for Logic Pro plugins
#3

Understood. I'm just glad you heard me out. Providing a working example would be impossible because I have no way of forcing two OCR actions in two asynchronous KM Engine processes to execute at the exact same time. All I can say is that I have several processes triggering (with the periodic trigger) simultaneously each and every second, running briefly then stopping quickly. These breaks constitute the pauses that you suggested in another paragraph. They are not running continually. I do not use the OCR condition in a Pause statement because that would be continual execution.

My realization occurred when I said to myself "How did text from the upper right hand corner of my screen get inserted into a variable that is only created by an OCR action that examines the lower left corner of the screen? That's impossible!" So I checked my code and when I saw it was literally impossible I realized that there must be a simultaneous execution conflict.

The KM engine has a propensity to synchronize periodic triggers. For example if I have two macros that trigger "every 10 seconds" they will both trigger at the exact same points in time even though nothing in the trigger is indicating that they should do this. This increases the chance of two macros (and their respective OCR actions) running at the exact same time. Hmm, perhaps if I put a PAUSE(RANDOM(0.5)) statement at the start of each periodic macro I might be able to ensure that macros' OCR actions don't run at the exact same time. But I've already swept through my code putting Semaphores before and after each OCR action and I think that has resolved the issue. But the Pause approach may also work in many cases.

#4

As long as the results of the OCR go in to different variables, this should be irrelevant.

Only if you use the same variables in the different macros would it be a problem.

#5

I'll have to take your word for it, but as I said above, "I checked my code and when I saw it was literally impossible". And I meant I checked my variables to make sure I didn't use the same one in two places.

This is something that would be extremely difficult for me to send you working code for, so we'll just have to leave it at this.