| Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
* 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.
|
|
|
|
* Avoid decoding stacked row 1 of N independently
* Avoid decoding stacked row 1 of N independently
|
|
|
|
|
|
|
|
* Add ResultMetadataType.ERRORS_CORRECTED and ERASURES_CORRECTED (2D barcodes)
* Maintain existing constructor on AztecDetectorResult
* Maintain existing ReedSolomonDecoder.decode method
|
|
#1641) (#1642)
|
|
|
|
|
|
* rename metadata test files
* implement symbology identifier on ITFReader
* add metadata test
* remove unused code
|
|
|
|
* decoder support for symbology identifier metadata
Co-authored-by: Daniel Dehnhard <daniel@dehnhard.it>
|
|
* also decodes inverted barcode on hint
Co-authored-by: Daniel Dehnhard <daniel@dehnhard.it>
|
|
|
|
|
|
* decode Aztec FLG(n)
Per https://en.wikipedia.org/wiki/Aztec_Code#Character_set,
FLG(0) → FNC1, FLG(1-6) → ECI identifier
Decode FNC1 as 0x1d (ASCII escape character; same as Code128,
DataMatrix, others)
Not doing anything with ECI yet, but this at least fixes
the mis-synchronization of the bit stream that comes from
ignoring the bits that follow it.
* include ecLevel (percentage) in DecoderResult for Aztec
* Aztec decoder: follow character set indicated by ECI codes
Modeled on PDF417's DecodedBitStreamParser
* add testAztecResultECI and testHighLevelDecode to aztec.decoder.DecoderTest
The latter includes non-ECI, ECI, and mixed test cases.
|
|
* Improve support for Macro PDF417
* cleanup and move license to it's proper place
* add .editorconfig + proper indentation / add optionalFields array
* rename variables and use Arrays instead of System
* replaced length with to
* restore spaces & switch to package private
|
|
|
|
|
|
|
|
* Update Decoder.java
* Add files via upload
dlusbs.png and dlusbs.txt is a test case for the D/L [digit] U/S B/S sequence, which should end in Upper mode, not Digit mode
* Update number of test cases
* Comment logic of the fix
* Mention fixed issue #642
|
|
|
|
Some barcode generators (e.g. Okapi) seem to generate additional barcode
rows at the end of the barcode, which can be decoded as valid barcode
rows, but actually contain garbage. The barcode metadata states that
these additional rows are not part of the barcode. So we ignore those
addional rows when parsing the barcode. This could potentially also
happen (though quite unlikely) if data after the barcode looks like a
barcode row.
|
|
|
|
git-svn-id: https://zxing.googlecode.com/svn/trunk@2992 59b500cc-1b3d-0410-9834-0bbf25fbcc57
|
|
git-svn-id: https://zxing.googlecode.com/svn/trunk@2915 59b500cc-1b3d-0410-9834-0bbf25fbcc57
|