|
* Fix QR decode failure for small/native-size images (#1976)
QRCodeWriter.encode(..., 0, 0) produces a 33x33 native-size QR that
ZXing cannot decode. The CENTER_QUORUM filter in selectBestPatterns()
(added in 110ef9e to fix #1567) removes finder patterns with count < 2.
For small images, the row-skip interval (iSkip=3, MIN_SKIP) means the
scanner only crosses the top two finder pattern centers on a single row
each, giving them count=1. The bottom-left pattern gets count=2 because
it's scanned after iSkip drops to 2. The filter then removes the two
count=1 patterns, leaving 1 of the 3 needed, and throws
NotFoundException.
The fix: only apply the CENTER_QUORUM filter when either (a) at least 3
confirmed patterns would survive, or (b) the total candidate list
exceeds a size threshold. This preserves #1567 protection while
allowing small images through.
Why a size threshold: the filter was added to prevent O(n^3) blowup
in the triangle-selection loop when noisy images produce thousands of
spurious candidates. When the candidate list is small (<= 25 entries,
yielding <= ~2300 loop iterations), the cubic cost is negligible
regardless of whether the patterns are real or spurious. A clean
single-QR image produces ~3 candidates; even a noisy image below the
threshold is computationally trivial. Above the threshold, the filter
applies unconditionally, matching today's behavior.
Alternatives considered:
- Removing the filter entirely: all 561 existing tests pass, but
re-opens #1567 for pathological images with thousands of spurious
count=1 candidates.
- Reducing MIN_SKIP from 3 to 1 for small images: addresses the
symptom (more scan rows = higher counts) but doesn't fix the
fundamental interaction between iSkip and the quorum filter,
and changes scan behavior for all small images.
- Fallback (try with filter, retry without on failure): re-opens
#1567 whenever fewer than 3 confirmed patterns exist, which is
exactly the scenario that produces thousands of unconfirmed
candidates in noisy images.
* Increase noisy-image test timeout from 5s to 30s
GitHub shared runners timed out at 5s. Local measurement shows ~1.2s,
implying at least 4x slowdown on CI. 30s gives a comfortable margin
while still catching the O(n^3) regression from #1567.
|
