sikuli-driver team mailing list archive

[RaiMan <rmhdevelop@xxxxxx>]

--- So I'd consider this a regression bug
You might get this impression based on your current situation. But the VisionEngine of X is much faster and much more precise and reliable, than the one from 10.2. 
And it might be, that this improvement has some impact on finding images having much background of a solid color like in your case, compared to the content, that makes it distinct. This is an aspect that should be evaluated.
... but the similarity is not a tweak, it is a feature, to tell Sikuli, what results you expect.

--- Does it make sense to restore 0.10.2 recognition in 1.0?
simply no, because this would really be a big regression. 

--- Much of the fun using Sikuli is gone if recognition becomes unreliable
No, this should not be. 
The difference between 10.2 and X might be, that the score of a match is higher in average, so using findAll() without a similarity value returns more (and not wanted) matches than in 10.2 using the default of 0.7.
This is worth an evaluation: Should the standard similarity be raised above 0.7 (e.g. 0.8)?

Sorry for not thinking about that possibility when answering your post:
Your script might run without modification if you just set the minimum
similarity to e.g. 0.8 (see:
http://sikuli.org/docx/globals.html#Settings.MinSimilarity)

--- conclusion
I think, in most cases we would expect from findAll, that it only returns the most probable matches (as in your case). This means, all matches with a score near the one of the best match. If you analyze your "wrong" result, you will find, that the wrong match's score is very different.

I will change this bug into a request bug, to get an improved findAll().

** Summary changed:

- findAll() with multiple matches returns invalid last match
+ [request] findAll() should only return the most probable matches

** Changed in: sikuli
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of Sikuli
Drivers, which is subscribed to Sikuli.
https://bugs.launchpad.net/bugs/880861

Title:
  [request] findAll() should only return the most probable matches

Status in Sikuli:
  New

Bug description:
  --- request (based on the primary bug situation)

  findAll(): "most probable" means, that only those matches are
  returned, whose score differ only slightly from that of the best match
  (e.g. max 0.5 or even less). This surely is the expectation of most
  people, when using findAll().

  Additionally it might make sense, to implement a findAny(), that
  returns ALL matches having a score above the given similarity, because
  this might be the expected result in some situations, when using
  findAll() in its current shape.

  -------------------------------------------------

  1. Sikuli 1.0 rc3
  2. Windows XP SP3 32-bit
  3. Enclosed code loops over all "Apply" boxes. Once apply has been clicked it wait for a confirmation box to appear, confirms, waits for the confirmation box to disappear. The final match does not point to the bitmap.
  4. Required bitmaps attached.

  # setFindFailedResponse(PROMPT)
  setROI(Screen(0))

  applies = findAll("Apply.png")

  for apply in applies:
      click(apply)
      confirm="Doyoureallyw-1.png"
      wait(confirm)
      click(Pattern("YesNo.png").targetOffset(-31,-1))
      waitVanish(confirm)

To manage notifications about this bug go to:
https://bugs.launchpad.net/sikuli/+bug/880861/+subscriptions