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.
_______________________________________________
Mailing list: https://launchpad.net/~sikuli-driver
Post to : [email protected]
Unsubscribe : https://launchpad.net/~sikuli-driver
More help : https://help.launchpad.net/ListHelp
