I’m having trouble with finding black numbers on a gray background using text search. The gray is (192,192,192), or very close to the namedColor “Silver”. I’m searching for 3 numbers: “1.33”, “1.85” and “2.35”. The latter two work. 1.33 gets nothing, and false reads, 118 of them, when I up the tolarance to 70. Backing it down to 67, I still get 3 (the last one of the 3 is the one I want), and zero imagesFound at tolerance = 66.
Here’s some of my thoughts on how to fix this: I can’t reduce the rectangle search size to limit finds, so before I go crazy doing colorAtLocation() walks around the foundImageLocations to look for black pixels (0,0,0), anyone have any great ideas? A free beer to the best suggestion.
v
Some questions: Are you using the TIG, or are these images that you have captured from the SUT? What OS are you testing? Any chance of a screenshot (even if it’s just of the specific area of the screen that these numbers appear in)?
Your answers will help us focus our thinking so that we don’t suggest things that don’t apply to your process.
TIG on XP, numbers appear in a pane that’s 400x400ish pixels, and can be anywhere in the screen and last position remembered by the app
OK, if that’s still too vague, I’ll make it very specific:
- Open up Paint on XP.
- Draw a gray (192,192,192) rectangle.
- Choose Text. Select Microsoft Sans Serif, 8 pt. On 3 lines, with an extra line in between, enter
1.33
1.85
2.35
- Now run the following 3 lines:
put everyImageLocation(Text:“1.33”, TextFont:“Microsoft Sans Serif”)
put everyImageLocation(Text:“1.85”, TextFont:“Microsoft Sans Serif”)
put everyImageLocation(Text:“2.35”, TextFont:“Microsoft Sans Serif”)
As I mentioned earlier, the 1.33 is found (this will vary based on the size of your gray background rectangle) many times. My simple test this morning, it was 142 found. 1.85 and 2.35 are found only once.
I can find “1” and “1.1.1.” but anything with “…” or “.3.3.3” it finds everything.
And above all else, focus your thinking :-).
v
I could still use a screenshot, but I’ll throw out an idea. Let’s try to isolate the problem: Add a search for “.33” and a search for “1.3” and see if either of those work. If not, see if “1.” or “.3” come up with the right locations (“1.” is going to have two matches unless you hide the “1.85” number with another window or something, or you can use something like
put EveryImageLocation()
to determine if the right position is being found.)
I’m suspicious that this is a spacing issue – there may be an extra pixel of space being introduced between two of the characters, but if none of the above tests find the right position on the page then something else is amiss. This hypothesis is based on the assumption that the TIG is using the correct font, which it probably is because the other numbers are being found.
Got it myself: without a background color setting, 1.85 and 2.35 could be found, but 1.33 could not. Setting the exact background color (see below) found it.
One of the nice / not so nice things about Sensetalk is that when you enter a property into a property list that isn’t recognized, Sensetalk doesn’t by default warn or throw an exception, so for example, if one put “backgroundColor:(192,192,192)” instead of “textBackgroundColor”, the color is ignored. You can do this:
set the strictProperties to true
– but for some reason, if I do this and then run
put ImageLocation(Text:“1.33”, TextFont:“Microsoft Sans Serif”, bgColor:(192,192,192))
– where bgColor is NOT a property, I don’t get a warning or exception. Bug?
At any rate, I discovered the solution by opening all the text images I generated and I noticed a white background, even when I thought I was setting it to gray.
v
The strictProperties doesn’t apply in this case since you are declaring a new property list (Property Lists can use any keys you want).
However, I agree that it’s poor behavior that we don’t do something about a text property that has unused/unrecognized text attributes. We might add bgColor and backgroundColor as acceptable alternatives, but that won’t solve the case for backColour or any of the other variants we are likely to encounter.
We’ll try to at least provide a warning in such cases and we’re glad you were able to work it out.