Subversion Repositories SmartDukaan

Last modification

• Rev 37450 2026-08-29 07:17:00
• Author: amit

• Log message:

  Oppo: find only the hole, and let a low-contrast hole be found at all
  
  60% of oppo attempts never got past detection -- getMatCircles2 returned null and
  the attempt was wasted before any aiming happened. That is a bigger loss than
  everything the scheduling work addressed put together.
  
  Two causes, both visible once real puzzles are captured and looked at.
  
  1. param1 is the Canny HIGH threshold, and it was 100. Edges weaker than that are
  discarded before circle finding begins. Measured hole-vs-background contrast on
  four live puzzles: 98, 103, 28, 117. The 28 -- a pale lilac background -- cannot
  produce an edge at 100, so no circle exists to find. Dropped to 50.
  
  2. It insisted on TWO circles whose radii matched within 3px, and returned null
  otherwise. So a puzzle where the hole was located perfectly still failed if the
  ring was missed, or if the two radii differed by 4px.
  
  The second is the sillier one: the ring is a DOM element,
  dx_captcha_basic_sub-slider_, whose exact position aim() already reads via
  pieceCentreX(). Detection was re-finding something known exactly, and then
  throwing away a good hole because it could not confirm it. Now the ring position
  is passed in and hough only has to find one thing.
  
  Lowering param1 without the pairing check would let textured backgrounds (the
  sand images especially) supply spurious circles with nothing to reject them, so
  the candidate is verified as an actual hole: its core must be at least 15
  luminance below the frame mean. Real holes measure 28-117 below, so 15 rejects
  noise with margin.
  
  Validated against live puzzles before committing:
  ring is at rel 42px on every sample; hole lands at 113-194px, separation
  71-152px -- so RING_EXCLUSION_PX = 30 never rejects a real hole
  hole contrast 28-117 against MIN_HOLE_DARKNESS = 15
  
  Not validated locally: the hough call itself. opencv 3.4.2-0 ships no osx/arm64
  native and every JDK on this machine is arm64, so the detection path cannot run
  here. param1 = 50 is reasoned from the measured contrasts, not measured. If the
  detection rate does not move, 40 is the next value to try -- the darkness check is
  what makes going lower safe.
  
  Watch "Detected N circle(s) but all sat on the ring" and "Rejecting circle at Npx"
  in the log: the first means hough found nothing but the ring, the second means the
  darkness check is doing its job.