| Age | Commit message (Collapse) | Author | Files | Lines |
|
Port of https://github.com/zxing-cpp/zxing-cpp/pull/320
|
|
|
|
|
|
|
|
the crop constructors in PlanarYUVLuminanceSource and GrayscaleLuminanceSource did not reject negative offsets or sizes and overflowed when checking left+width and top+height, letting an out-of-bounds crop reach getRow and getMatrix; validate the rectangle the same way as BufferedImageLuminanceSource.
|
|
|
|
|
|
BitMatrix.flip() inverted every int in bits[], including the unused padding bits
beyond the logical width in each rows last int. Methods that scan the raw bits
(getTopLeftOnBit/getBottomRightOnBit/getEnclosingRectangle/equals) then treated
those stray bits as part of the matrix, e.g. getBottomRightOnBit() returning
(31,4) instead of (4,4) on a 5x5 matrix. Mask off the padding after flipping.
Adds a regression test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* avoid out-of-bounds read in pdf417 decodeMacroBlock
* use maxLength local for codewords[0] in decodeMacroBlock
|
|
|
|
* Avoid charset provider lookups for UTF-8 QR encoding
* Simplify charset lookup handling
|
|
|
|
|
|
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
test case for regression (#1961)
|
|
* Fix distortion calculation for isosceles right triangles
* Revert "Fix distortion calculation for isosceles right triangles"
This reverts commit 4a8ad9a5bea9d0be251450f9e0db15b16e85e1ac.
* Add comment to distortion calculation
The formula for calculating the distortion seems wrong but practically it seems to work slightly better
|
|
* Add hint to correct wrong dimension
Fix issue #1900
* Revert "Add hint to correct wrong dimension"
This reverts commit 16723b3434a78ab49894f611cfb57c3e712b9b97.
* Correct wrong dimension to lower value
Fix issue #1900
* Cleanup code
---------
Co-authored-by: Matthias Agethle <matthias.agethle@elca.ch>
|
|
* throw a more explicit exception when trying to PDF417/TEXT encode something outside of 0...255
* refactor PDF417HighLevelEncoder to avoid code duplication
extend UT to new method PDF417HighLevelEncoder#checkCharset
* fix javadoc typo
make UT more stringent on PDF417HighLevelEncoder#checkCharset
* restrict TEXT to 0...127
test with CP437 and Greek chars
* reinstate testEncodeAuto UT
* refactor testEncodeAuto UT
* address codacy findings
* formatting
* fix issue #1831
make PDF417#determineDimensions to enable finer UT
add UT coverage to validate fix for #1831
* fix javadoc for PDF417#determineDimensions
remove stacktrace when UT fails
* make UT Java 8 compliant
|
|
Compaction.TEXT, throw an explicit exception if not the case (#1878)
* throw a more explicit exception when trying to PDF417/TEXT encode something outside of 0...255
* refactor PDF417HighLevelEncoder to avoid code duplication
extend UT to new method PDF417HighLevelEncoder#checkCharset
* fix javadoc typo
make UT more stringent on PDF417HighLevelEncoder#checkCharset
* restrict TEXT to 0...127
test with CP437 and Greek chars
* reinstate testEncodeAuto UT
* refactor testEncodeAuto UT
* address codacy findings
* formatting
|
|
* be more stringent on email validation rules
add UT to validate various email formats
* fix indentation
* fix failing UT case
* refine regex for email's domain:
* only letters in the last part
* no part starting or ending with a - (- allowed inside the part)
add UT to cover such cases
|
|
|
|
This small commit makes public the "renderResult" method of the
"QRCodeWriter" class.
The reason to promote this method as public is that I'm facing
Business Case where, besides of generating the QR code as a PNG image,
I also need to print information about the QR code itself (specifically,
the QR version). Navigating through the code of zxing library, I noticed
that the com.google.zxing.qrcode.encoder.Encoder allows me to have that
(the QR metadata); however, by invoking that class I only have part of
the equation (the QRCode DTO) ... I'm still needing to generate the
BitMatrix in order to produce the QR image.
Here, I have two alternatives: either I invoke the Encoder.encode
class by myself and repeat the same logic when invoking the
QRCodeWriter.encode method; or I make the renderResult Public, call the
Encoder.encode and then I proceed to call the QRCodeWriter.renderResult
method with the previous result.
|