Issue 56 in zxing: Broken QR Pattern Detection causes ReaderException
codesite...@google.com
http://code.google.com/p/zxing/issues/detail?id=56
New issue report by p...@foreach.be:
Create a QRCode image encoding the string "12328" (just the number, not
the quotes) with EC Level L and data mask 011.
When trying to decode this image, a
ReaderException: versionNumber must be between 1 and 40
will be thrown, because the topleft pattern will be misplaced, causing the
dimension to be estimated at 17, smaller than the minimum 21.
Using ZXing 0.7 on XP
Attachments:
enc17724.png 235 bytes
Issue attributes:
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
codesite...@google.com
http://code.google.com/p/zxing/issues/detail?id=56
Comment #1 by srowen:
Sounds like a good bug report, I'll take a look at why it is
misidentified today.
Issue attribute updates:
Status: Accepted
Owner: srowen
codesite...@google.com
http://code.google.com/p/zxing/issues/detail?id=56
Comment #2 by srowen:
Interesting, good bug. It was picking up (43,58) as a finder pattern.
If you look at
the pixels above/below and left/right of it, indeed they match the
finder pattern
profile. Since this is the third finder pattern found, and it can be
confirmed with a
second check on the next row, the detector stops and does not find the
third one.
Here, we know the third "finder pattern" is bogus since it is bigger
than the others
by a noticeable margin. I basically added a heuristic to check this,
and if the
confirmed finder patterns are too different in size, it keeps looking.
Then it finds the real third finder pattern. Later when it has to pick
which 3 of 4
are the real ones, it does get it right.
The fix makes this image work. Of course, if we misidentified a finder
pattern that
matched real ones in size, we would still have a decode problem. This
is a weakness
in the current FinderPatternFinder -- it's trying to be fast but will
miss tricky
corner cases like this.
At least, it is less easily fooled now. This image now decodes.
The fix is checked into Subversion. The change is just to
FinderPatternFinder, so you
could just pick up that change, recompile.
Issue attribute updates:
Status: Fixed
p...@foreach.be
Wouldn't a better heuristic be to count how many white pixels are
contained in the white outline you would expect from the white pixels
found?
Say you have found white pixels from (x1,y0) to (x2,y0), (x3,y0) to
(x4,y0), (x0,y1) to (x0,y2) and (x0,y3) to (x0,y4).
In a perfect situation, you would expect every pixel (x,y) with
(x1 <= x <= x4) and (y1 <= y <= y4) and not((x2 < x < x3) and (y2 < y
< y3))
to be white.
Calculating the percentage white pixels in that region would be a good
measure for how good a pattern candidate we have
(and also the percentage of black pixels (x,y) in the rectangle (x2 <
x < x3) and (y2 < y < y3))
On May 8, 5:17 pm, codesite-nore...@google.com wrote:
> Issue 56: Broken QR Pattern Detection causes ReaderExceptionhttp://code.google.com/p/zxing/issues/detail?id=56
srowen
I think the hard part is knowing where to look for said white pixels.
In a perfectly upright image like this, it's obvious. But if the image
were rotated 30 degrees?
You could say, well, you could also double-check that black/white/
black pattern looks like a finder pattern a module to the right and
left of center. Again the problem is how far is that? until you know
where the finder patterns are you don't know much about orientation
and size.
It's a good idea, just hard and adds complexity -- and some nontrivial
risk of false negatives. So far I've put off making that part better.
I mean if it causes a glitch even 1 out of every 1000 images, no big
deal -- decoders will be continuous-scan soon (the Android one is) so
it just means every 1000 times you wait an extra second to decode, as
the first fails and the second slightly different image succeeds.
p...@foreach.be
OK, I haven't read all the code yet, so I wasn't sure if the image was
somehow aligned.
In that case, maybe a better solution to decode generated images would
be to provide a public method allowing for the caller to provide the
coordinates of the centers of the finderpatterns:
public Result decode(MonochromeBitmapSource image,float top, float
left, float right)
This method assumes a erfectly aligned image, so bottom = top+(right-
left).
srowen
The Detector finds the barcode; the Decoder decodes it. So if you
already know where to barcode is and where the "bits" are in the
image, you could feed those straight into the decoder as a BitMatrix.
If you had some other process that detects and extracts the bits, you
can still reuse the Decoder part.
There is also a "PURE_BARCODE" DecodeHintType which tells the detector
that the image is pure black-and-white, perfectly aligned, just like
the image you sent in. In that case it can operate much faster and can
quickly find the finder patterns for you.
If we knew the image was perfectly aligned, I suppose it is much more
feasible to cross-check in the way you suggest. It doesn't help the
"real" case.