differentiate text color?

Asked by Chris Kiick

Here's the problem: region.text() is not working for me. This is a known problem with the OCR engine, I know. It's probably due to the small font size that I have to deal with, the text color and the noisy background. Whatever the reason, text() either gives nothing at all or semi-random characters, and it's not at all consistent.

However, I can do something based on the color of the text (white, yellow, red). But how do I get sikuli to recognize/know the color of the text? I can't use exact matches (even if that worked) because the text changes.

I thought of two ways to do this but don't know how to implement them.

One is to scan the entire region for a particular color. Except how do I capture the font color in question? What if it's not a single, simple color but has shading? Also, there would have to be some kind of threshold count so that random background pixels would't give a false positive. I'm sure I'm not the first person to have this problem, so are there any scripts out there that do this?

The other thing is to get a snapshot of each character (it's a number, so only 10 characters) and try to do matches on each digit, in each position, for each color. For a 5 digit number that's 5 * 10 * 3 = 1500 matches. Doesn't sound feasible. Plus all the coding to handle shorter numbers. Unless there's a trick I'm missing?

Any suggestions on how to handle this?

Question information

Language:
English Edit question
Status:
Answered
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:
Revision history for this message
RaiMan (raimund-hocke) said :
#1

There are no possibilities in the current version, that make really sense.

Starting with the next version 1.1 we will try to improve the text features.

--- ...try to do matches on each digit, in each position, for each color
Since each comparison for one digit is in a very small region, the comparison itself should be very fast (range of milliseconds). This could be optimized, by taking the captured screenimage of the first check and do the other 29 checks with a Finder().find().
and if the numbers are spread even, then it is only 750 searches on average ;-)
So if you get it optimized, you might get an average of 1-2 sec for a 5 digit number.

Interesting problem, but I do not think it is really worth the effort :-((

Can you help with this problem?

Provide an answer of your own, or ask Chris Kiick for more information if necessary.

To post a message you must log in.