Re: Issue 1605 in zxing: Aztec decoding

[zx...@googlecode.com]

Comment #2 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

Do you have a patch? I'm afraid I probably have little idea how to debug
the RS part there.
and have you verified it is correctly encoded?

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[zx...@googlecode.com]

Comment #3 on issue 1605 by serj...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

I am debugging the code, and I see that in ReedSolomonDecoder class in the
findErrorLocations method gives numErrors = 51, while e = 0

if (e != numErrors) {
throw new ReedSolomonException("Error locator degree does not match
number of roots");
}

The initial Aztec code was taken from the US airways ticket generator:
http://www.usairwaysmobile.com/mobiqa/c/session/Nd_W5XZ6X36o1VdrdzokGsN3aqM./16f876d/53bc00c4/

[zx...@googlecode.com]

Comment #4 on issue 1605 by serj...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

Seems like the problem in Full range Aztec codes decoding, there is no such
problem with Compact ones

[zx...@googlecode.com]

Comment #5 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

Yes this just means "too many errors" by itself. What happens if you scan
with PURE_BARCODE mode? It could be a mis-read, which means garbage goes in
and the ultimate failure is in EC even though EC itself works fine. I doubt
it, but maybe.

[zx...@googlecode.com]

Comment #6 on issue 1605 by serj...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

PURE_BARCODE mode still produces the same issue. :(

[zx...@googlecode.com]

Comment #7 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

Are you using the latest in SVN? While there are not likely to be many
relevant changes since the last release, there have been a few. I wasn't
clear which version this was.

I think you'd have to debug it yourself though if it is still a problem.

[zx...@googlecode.com]

Comment #8 on issue 1605 by mike...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

I'm not sure if it really helps but if the rectangle of the BitMatrix is
slightly increased within the detector, the image can be decoded
successfully. So I think the error is not located in the RS decoder. I
think the detector has to be adjusted.
I increased the rectangle while debugging.
Btw. in my opinion and how I understand the sources Aztec reader doesn't
support PURE_BARCODE.

[zx...@googlecode.com]

Comment #9 on issue 1605 by fyel...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

There is clearly a problem early on the Aztec Decoder when it is decoding
the above qr.png

When I add a statement
System.out.println(matrix);
at line 95 of aztec/decoder/Decoder.java, the result is not what I expect.
The first row and column are duplicated twice. It appears (but I'm not as
certain) that the final row and column are deleted. Everything goes
downhill quickly from there.

The error message from RS is simply that there are too many messages for it
to recover.

Here is the output of the print statement.

X X X X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X X X
X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X
X X X X X X X X X X X X X X
X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X
X X X X X X X X X X X X X X X X X
X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X X X
X X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X
X X X X X X X X X
X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X X
X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X X X
X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X
X X X X X X X X X
X X X X X X X X X X X X X X X X X
X X X X X
X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X
X X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X
X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X X X
X X X X X
X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X X
X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X X
X X X X X X X X X
X X X X X X X X X X X X X X X X X X X X X
X X X X X X X
X X X X X X X X X X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X X X X X X X X X X X X X
X X X X X X X X
X X X X X X
X X X
X X X X X X X X X X X X X
X X X X X X

[zx...@googlecode.com]

Comment #10 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

Yes it looks like the boundaries are not being found correctly, by just a
little bit, but it's corrupting a lot of the pixels. Yes, the R-S error is
then just a symptom and not the real issue.

[zx...@googlecode.com]

Comment #11 on issue 1605 by fyel...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

It seems that there are two bugs in aztec.detector.Detector.

#1) the denominator for "ratio" in getMatrixCornerPoints() needs to be
(2.0f * nbCenterLayers - 1). This will cause this method to return the
points just outside the Aztec code matrix

#2) the arguments to sampler.samplerGrid in the method sampleGrid() appear
to be incorrect.

Setting the arguments to below will allow the Aztec code above to be
decoded. But it still won't decode a similar code I have from United
Airlines. And I need to understand GridSampler better to understand what
the arguments are actually supposed to be.

Test suite has not yet been run, so more tweaking of arguments to
GridSampler may still be necessary.

return sampler.sampleGrid(image,
dimension,
dimension,
0f,
0f,
dimension - 0f,
0f,
dimension - 0f,
dimension - 0f,
0f,
dimension - 0f,
topLeft.getX() + 1,
topLeft.getY() + 1,
topRight.getX() - 1,
topRight.getY() + 1,
bottomRight.getX() - 1,
bottomRight.getY() - 1,
bottomLeft.getX() + 1,
bottomLeft.getY() - 1);

[zx...@googlecode.com]

Comment #12 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

The "0.5" in the second part is not a bug and should be left in. The middle
of pixels are sampled instead of the edges. If there is a problem it is
probably in a mismatch with the bounds that are passed. It is supposed to
get the x/y coordinates of the top/left pixel inclusive and the
bottom/right pixel exclusive. This ends up telling you the exact position
of the boundary since the integer coordinates are like the location of the
very top-left of a pixel.

Variations on these changes that I tried all resulted in test failures. It
may be that something happens to compensate for a problem in one image, but
could be the wrong change overall.

I think the interesting thing is to double-check point #1 -- what's the
logic for why it should be one smaller? -- and then see whether the
sampleGrid method is actually getting the top/left pixel from inside the
image and bottom/right from outside the image. If that doesn't hold
consistently, that's the problem.

[zx...@googlecode.com]

Comment #13 on issue 1605 by fyel...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

I've got a rewrite of Detector.java that passes the Test Suite, and fixes
the bug in this problem. I've got to clean it up a little bit, but I
should be sending it here as a diff in the next day or so.

As a bonus, the code is also a bit smaller and simpler.

[zx...@googlecode.com]

Comment #14 on issue 1605 by fyel...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

Here is a diff file to fix this problem. Note that this new detector
reads 18 more Aztec codes in AztecBlackBox2TestCase than is required to
pass the test suite. The old detector barely scraped by.

This code has several major differences with the previous code.
1) After finding the limits of the outer white part of the bull's eye, all
subsequent math is done is floating point rather than int. The rounding
was causing multiple errors.
2) The code makes us of the fact that the Sampler Grid doesn't need to be
passed the outer corners of the grid: it just needs four points. We can
use the four points of the bull's eye.

As a minor issue, I changed all occurrences of "bull eye" to "bull's eye".
Sorry, I typed copy editing in a former life.

Attachments:
Detector.diff 14.0 KB

[zx...@googlecode.com]

Updates:
Status: Fixed
Labels: Type-Defect Priority-Medium

Comment #15 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

Nice one, this improves several test images. I've committed it as it also
makes this one decode.

[zx...@googlecode.com]

Updates:
Owner: fyel...@gmail.com

Comment #16 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

(No comment was entered for this change.)

[zx...@googlecode.com]

Comment #17 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

Issue 1260 has been merged into this issue.

[zx...@googlecode.com]

Comment #18 on issue 1605 by manie...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

First of all, sorry for my english :)

ZXing still can't correctly decode big aztec codes.

Perspective Transformation is based on bulls eyes corners and is not
working properly with big aztec codes. It's because bulls eyes corners are
only approximate values. And in big images this approximation couse errors
in perspective transformations.

I attach an example. Red dots are points founded by perspective
transformations - the farther from the center, they are less accurate or
even completely wrong.

Nevertheless it works for small codes

Attachments:
Screenshot_2014-04-15-17-05-21.png 505 KB
Screenshot_2014-04-15-17-17-10.png 603 KB

[zx...@googlecode.com]

Comment #19 on issue 1605 by manie...@gmail.com: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

If I found a solution I post it here.

[zx...@googlecode.com]

Updates:
Owner: ---

Comment #20 on issue 1605 by srowen: Aztec decoding
http://code.google.com/p/zxing/issues/detail?id=1605

(This is not the active project site anymore. Use github.com/zxing/zxing)

This can probably be improved, but you would have to supply a patch.

[Mariusz Dąbrowski]

I change Aztec Detector.java file and i wrote simple CornersDetector class (based on WhiteRectangleDetector).

I made some tests and now Barcode Scaner recognize Aztec codes up to format C83X83. Ther is still problem with bigger codes but it can be problem with max camera resolution in my phone.

[Sean Owen]

At least, a patch is needed, not .java files. Better still is a pull request to github.com/zxing/zxing

It would be nice to briefly explain the change, and verify that all existing unit tests still pass.

[zx...@googlecode.com]

Comment #21 on issue 1605 by ksiazczy...@gmail.com: Aztec decoding
https://code.google.com/p/zxing/issues/detail?id=1605

Hi

is this problem solved? is there any patch for this problem on github?

problem still exist with objective-c version of codes but iphone module is
not active currently, maybe it was fixed in java version?