sikuli-driver team mailing list archive

[RaiMan <question272495@xxxxxxxxxxxxxxxxxxxxx>]

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

    Status: Open => Answered

RaiMan proposed the following answer:
This are 2 different things:

-- high similarity
This can and will be solved with version 2.
As one requirement for a solution, the images must concentrate on the distinguishing contents (as little background as possible towards the edges (this will be better supported in version 2 at time of snapshotting the image and there will be a possibility to automatically recapture an image set).
Another problem currently is the fact, that the similarity is already internally rounded to the second decimal, but image differences of only some pixels (e.g. different rendering of edges of graphic elements) might only be reported at a decimal far beyond the third decimal. This will be changed in version 2 too.

Another challenge with similarity valid from the very beginning of
SikuliX is transparency. Since the images are rectangles, there might
always be parts towards the edges, that are not relevant. Or testing
people get images for testing from the development, that have
transparent parts. Or one wants to find a button with changing text
(e.g. localized). A transpareny channel in images currently is simply
ignored, with affects, that are not generally predictable. This will be
addressed in version 2 too (may be limited).

-- different resolution
Since SikuliX is based on matching the images by their pixel content, the image on the screen must have the same size (width and height) measured in pixels as reported by the underlying snapshot feature of Java Robot. If the image has a different size on the screen now, then SikuliX will not find it currently. You have to manually create a new image set for this environment.
For this situation there will be a solution in version 2, that allows to capture a new imageset on the fly by simply running a workflow that would fail with the original image set otherwise (this only works if the known positions of the images from a valid run are still the same may be evenly changed by a different resolution)
Another option, that already now works: If you know, how the images in the different resolution are shown, then you might on the fly resize your given images with this factor and might have success (if the rendering in the different resolution works such simple).
Features for that are available in version 1.1.0 in the class Image. Come back if interested.

-- SIFT
with version 2 I will again have a look at this complex but powerful feature and what it can help. 
If you want to start with some experiments: I started with SikuliX version 2. Here I use the Java API available with OpenCV, which is a bit easier to use in situations where you do not want to deal with C++ code.
Come back if interested.

You received this question notification because your team Sikuli Drivers
is an answer contact for Sikuli.