IDE changes script - similar(1.0) to exact() --- this is by intention and ok

Asked by John Winning on 2017-02-10

If I save my script in the IDE (I rarely do this, I use an external editor), I found that the IDE changes similar(1.0) to exact() without saying anything. This caused an incorrect exact match with images of different shades of color - i.e. in shadow. Because the IDE changed my code silently, this was very difficult for me to find. Also, it took me some time to conclude that exact() isn't exact pixel-for-pixel.

I can avoid it by not saving with the IDE. However, I will not be able to use the export packed option. I just discovered this feature, and would like to use it to make sharing easier. I tried to work around the problem by using similar(0.99), but that value still results in an incorrect "exact" match.

Questions: Is there a way to prevent silent script changes during Save or Exports? What else does the IDE change in scripts? If there is a different approach I should use to find perfect matches, please let me know.


Question information

English Edit question
Sikuli Edit question
No assignee Edit question
Solved by:
John Winning
Last query:
Last reply:
John Winning (johnwinning) said : #1

I am using 1.1.1 nightly builds

RaiMan (raimund-hocke) said : #2

up to version 1.1.1 exact() means that the score should be greater than 0.99 ( > 0.9900000000.... )

... and the same goes for similar(1.0).

In fact a match giving a score of 1.0 is not possible, since internally the score value is a double real number between 0 and 1, that at the surface is always rounded at some place right of the decimal point.

You might check this using Match.getScore().

To understand better, read this:

In the versions of Sikuli before I took over with version 1.0.0, there were some inconsistencies in the handling of the wanted similarity score.
Especially the internal handling with only 2 decimals made it impossible to differentiate between 2 very similar matches (score diff < 0.009).

But with version 1.1.1 the most inconsistencies have been fixed (except the 2 decimals problem), so the symptom you have does not influence the internal search.

With version 2 it will be possible, to define, what exact() should mean in a special case and the number of decimals taken into account will be raised to 5 or even more (not yet decided).

John Winning (johnwinning) said : #3

Thank you for the reply. I switched my code to evaluate based on the match score rather than use similar or exact when dealing with very similar images. The score for a shaded button matching a non-shaded one was > 0.9996.