find() not successful with large regions (> 200 pixel)

[RaiMan]

This is somehow related to my bug report https://bugs.launchpad.net/sikuli/+bug/521370.
(Win 7 and OS X 10.6 with Sik 098)

Here I talk about my experience, that only images with at least one dimension less than 200 pixels are always found. If one dim is between 200 and 300 pixels, there is a chance, that find() is successful - but in most cases it is not. Above 300 pixels nearly always the image is not found.

The results vary to some extent depending on the screensize (the larger the screen, the higher the max pixel value, where an image is always found) and on the content of the image. I found situations, where an image of 400 x 400 was still found, but a little aside or increased a little, the find() failed.

Another experience is, that for the not-found situations trying with find(Pattern(<image>).similar(0.2).firstN(1) in many cases the find() now is successful, but the match is (sometimes significantly) displaced and shows a similarity below 0.5.

On top you will find, that in the not-found situations the screen is captured internally up to 4 times (leads to very bad performance!)

I made my test with the same iPhoto screen as in the bug report above mentioned. This time with the activities bound to the gray region with the fotos.

If you want to try this manually, just write down a one line script:
print find(capture()) # no parameters at all!

If you run this script, you will get into the capturing situation. You have to capture something. Find() will try to find this captured image. The print reports the Match in the massage area, which may be None (not found).

Run this script over and over again with varying shapes you capture and you will get an impression.

Similar to the script I used in the above mentioned bug report, I created a script, where you have to capture a region. when you run the script, you will be asked for an action, then everything works silently until a border is reached:

-- the question comes up: w/i x/y/a Width Height

w is walk: take one fixed shape (with Width and Height) and then go left to right (x) or top to bottom (y) stepping the pos with 100 pixel. at the current pos the image is captured and we try to find(). if not found, we try again with Pattern and step further.
we always start at relative [10, 10] to the upper left of the captured region (the test area).
-- valid actions:
w x 200 200: left to right with a shape [200 x 200]
w y 600 250: top to bottom with a shape [600 x 250]

i is increase: a shape at a fixed pos [now relativ [10,10] top left) is increased to the right and/or to the bottom stepping 50 pixel. rest same as with walk. the only valid input now: i a val1 val2, which starts with [val1 x val2] and increases in both directions.

the result is reported with 3 count values: (found, not found, found with Pattern). Some information on the steps in between are reported with print() into the message area.

If you click "Cancel" at the input() the script stops.

some results:

always found:
w x or y 200 200
w x 200 600
w y 600 200

sometimes found:
w x or y 250 250
w x or y 300 300 (on large screen)
and slices, that stay less then 300 in one dim

never found:
w x or y 350 350
and all other shapes/slices with one dim more than 350 pixels

the script is available at (sorry, but its quick and dirty, and may not work as you expect)
http://files.me.com/rhocke/v8unym

[RaiMan (raimund-hocke)]

I stated:

On top you will find, that in the not-found situations the screen is captured internally up to 4 times (leads to very bad performance!)

I found the reason for that myself:

A find() in the standard is waiting max 3 seconds for the pattern to come up on the screen. This is an implicit wait(). If you know what should be on the screen, it boosts performance if you use

setAutoWaitTimeout(1)

that hinders find() after a not-found to wait for some aliens to help the screen to come up with the image we are looking for.

Normally you would think, that setAutoWaitTimeout(0) would be the way to say "don't wait at all", but there seems to be a bug, because if you use 0, the <try: except:> does not work any longer.

[RaiMan (raimund-hocke)]

version 0.10: no problems anymore.