sikuli-driver team mailing list archive

[RaiMan <question154519@xxxxxxxxxxxxxxxxxxxxx>]

Question #154519 on Sikuli changed:
https://answers.launchpad.net/sikuli/+question/154519

    Status: Open => Answered

RaiMan proposed the following answer:
--1: clarification on score
The search concept (searching a visual sample in a specified screenarea (might be the whole screen)  or a given image (class Finder)) is based on the appropriate features of OpenCV. So it is not comparing images, it is finding a normally smaller image in some larger image (if sample and search area are the same size, you have the special case that can be called comparing).

Internally a few different approaches (e.g. downsampling, grey-scale)
are used to optimize speed (the slowest version is to go through the
search area pixel by pixel and compare the sample pixel by pixel with
the appropriate image area).

The minimum similarity given with a Pattern (standard value 0.7) tells
the search engine, that only matches with a minimum score of  the given
minimum similarity should be returned. This score is not an absolute
value, that tells about the pixel differences, it is only something like
a probability, that the returned match might be, what the scripter is
looking for. The higher the value, the higher the probability, that the
match is what you expected. But vice versa is not true: a match with a
score of 0.5 or lower might be the match, that the scripter expected.

The larger the difference in size between sample and search area, the
higher the probability, that even with scores of above 0.8 something is
found, that you did not expect.

Currently with grey-scaled images even a score of 1.0 does not assure,
that you found what you expected (see bug 768940).

--2. your case
So if your need is to compare images, the approach of capturing the samples (your "baseline pages") and then search for them on a screen that contains "the loaded new pages in the browser" will only work if you restrict the search area to the browser window content area, that is either same size or some pixels larger than the probe. Together with the fact, that some of your pages might be longer then the screen height, makes it very complex to arrange the browser window accordingly.

If interested, here (https://files.me.com/rhocke/fecehn) you can
download a zipped .sikuli, that runs in the IDE on Mac OS X 10.6 as is.
You only have to open Safari with a page, that can be scrolled down at
least half screen (e.g. this question ;-). It shows the influence of
restricting the area to search for a sample and prints out the results.
The IDE and Safari have to be on Screen(0), the default screen, if multi
monitor environment.

-- Conclusion: use the features of class Finder and capture both images
(you seem to have some tool for that, that is not Sikuli) (baseline and
new) in a way that they can be "compared". If you do that, you can say,
a score of 1.0 means (exception brightness/grey-sacale - see above) both
are identical pixel by pixel. But in your sense even 0.95 might mean
identical, depending on what you compare (e.g. a slightly different font
in one case).

-- Possible solution: (see the docs http://sikuli.org/docx/finder.html#finder)
- capture your both versions to a folder with a naming convention for the image pairs or another concept, that allows to loop through the images and get the pairs to compare

# a base script (supposing that the images can be found in image path)
img1 = "filename of a baseline image.png"
img2 = "filename of the corresponding new image.png"
minSim = 0.9

f = Finder(img1)
f.find(img2, minSim)

if f.hasNext():
    print img2, "found with score =>", minSim, f.next()
else:
    print img2 "not found with score =>", minSim
f.destroy()

pack this in a loop and arrange the image handling together with may be
image specific minSim e.g. coded in the filename and here you are.

You received this question notification because you are a member of
Sikuli Drivers, which is an answer contact for Sikuli.