Issue 1260 in zxing: Larger AZTEC 2D codes are not decoded

[zx...@googlecode.com]

Status: New
Owner: ----

New issue 1260 by gmarcel....@gmail.com: Larger AZTEC 2D codes are not
decoded
http://code.google.com/p/zxing/issues/detail?id=1260

When larger AZTEC barcodes are provided, for instance C95x95 in size, they
are not processed. Note this size is used in the UIC industry standard
Railroad e-tickets in Europe, for instance companies NS Hispeed or
Deutschen Bahn.

Up to now I have tried (via intent) the Barcode Scanner v4 as well as the
online scanner http://zxing.org/w/decode.jspx

Smaller AZTEC codes are ok.

Attached are examples which should all decode to "ABC 123456789"

OK: aztec c19x19 barcode-image
OK: aztec c75x75 barcode-image
NOK: aztec c95x95 barcode-image
NOK: aztec LARGE c95x95 barcode-image (same as previous, bigger 'pixels'
more space)





Attachments:
aztec c19x19 barcode-image.gif 1.6 KB
aztec c75x75 barcode-image.gif 10.0 KB
aztec c95x95 barcode-image.gif 15.2 KB
aztec LARGE c95x95 barcode-image.gif 41.6 KB

[zx...@googlecode.com]

Comment #1 on issue 1260 by srowen: Larger AZTEC 2D codes are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

Maybe so... but is there a specific issue you can identify? it's just
always generally true that bigger denser codes are harder to scan with a
phone, so I don't know if there is a specific problem here with aztec.

[zx...@googlecode.com]

Comment #2 on issue 1260 by gmarcel....@gmail.com: Larger AZTEC 2D codes

are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

Possibly related to my phone (a HTC Desire by the way). Up to now I did not
encounter any problems scanning other types of barcodes or smaller density
Aztecs.

I am capable to scan the barcodes using NeoReader which might give an
indication that at least my camera has sufficient reolution and quality. I
want to be able to process the scanned results (deflate them in case of
traintickets) for which I need to write some custom code.

Would it be possible to test the provided barcode in a unit test to exclude
an algorithmic error specific to this size of Aztecs?

[zx...@googlecode.com]

Comment #3 on issue 1260 by ch...@orr.me.uk: Larger AZTEC 2D codes are not
decoded
http://code.google.com/p/zxing/issues/detail?id=1260

For what it's worth, I got the first three attachments to scan with ZXing
on Android (svn 2295); I could only scan the first two with NeoReader.
However, the second and third threw an exception on decoding:

java.lang.NegativeArraySizeException
at
com.google.zxing.common.reedsolomon.ReedSolomonDecoder.decode(ReedSolomonDecoder.java:60)
at com.google.zxing.aztec.decoder.Decoder.correctBits(Decoder.java:320)
at com.google.zxing.aztec.decoder.Decoder.decode(Decoder.java:102)
at com.google.zxing.aztec.AztecReader.decode(AztecReader.java:72)
at
com.google.zxing.MultiFormatReader.decodeInternal(MultiFormatReader.java:170)
at
com.google.zxing.MultiFormatReader.decodeWithState(MultiFormatReader.java:85)
at
com.google.zxing.client.android.DecodeHandler.decode(DecodeHandler.java:79)


But I have managed to scan a number of different large Aztec barcodes (e.g.
~83x83 Deutsche Bahn tickets) with ZXing on Android (and online). However,
it always takes a while to recognise, and then the decoding is wrong.

In this example, ZXing seems to insert a lot of unwanted 0xc2 and 0xc3
bytes, when compared to the verified correct decoding:

$ hexdump -C aztec.correct | grep "c[23]"
00000090 82 d8 c6 b6 18 17 11 d4 c5 c1 1a 98 49 51 c2 13
|............IQ..|
00000100 4b 5a f8 91 54 ab 9c 47 d3 7d 3e 9c 2f c3 69 bf |
KZ..T..G.}>./.i.|

$ hexdump -C aztec.zxing | grep "c[23]"
00000010 02 14 28 c2 9a 5c c2 b1 c2 a8 3d 3f 2a 75 c2 93
|..(..\....=?*u..|
00000020 c2 9d 7b c2 b6 7a c2 ae c3 8a c3 a4 68 c3 89 2c
|..{..z......h..,|
00000030 02 14 29 c2 9f 14 75 c3 ae c3 a0 c3 81 c2 84 08
|..)...u.........|
00000040 c3 8f 18 c2 9b c3 b3 c2 88 c2 87 c3 8a c2 a9 05
|................|
00000050 c3 aa 09 00 00 00 00 30 32 33 31 78 c2 9c 6d c2
|.......0231x..m.|
00000060 8f 41 6b 02 31 10 c2 85 c3 bb 53 c2 84 5e c3 9a
|.Ak.1.....S..^..|
00000070 c2 80 c3 b4 4d c2 92 75 c2 93 c3 9e 36 66 51 c2
|....M..u....6fQ.|
00000080 b1 5d c3 81 c3 94 4a 4f c2 a5 50 41 c2 a1 c3 ae
|.]....JO..PA....|
00000090 4a c2 b4 c3 bf c2 bf 2f c3 b4 62 c2 a1 c2 93 43 |
J....../..b....C|
000000a0 c2 be c2 bc 79 33 c2 99 c3 99 c2 bc c3 8f c3 9b
|....y3..........|
000000b0 26 42 c2 80 c3 8a 00 0e c3 8f 53 c2 bb c3 9c c2 |
&B........S.....|
000000c0 be c2 8d c3 ad c3 8d 55 68 26 35 44 6b c3 91 c2
|.......Uh&5Dk...|
000000d0 82 c3 98 c3 86 c2 b6 18 17 11 c3 94 c3 85 c3 81
|................|
000000e0 1a c2 98 49 51 c3 82 13 15 5d 7b c3 90 07 57 75
|...IQ....]{...Wu|
000000f0 2f 5d 30 6e c3 bd 6f c2 9f c3 9f c2 bb 16 5e 16 |
/]0n..o.......^.|
00000100 5e 4c 42 c2 99 40 c2 a4 1b c3 b2 c3 b1 c3 a3 c3 |
^LB..@..........|
00000110 ab c2 94 77 c2 87 33 25 c3 ba c2 a9 11 4c c2 81
|...w..3%.....L..|
00000120 40 c3 b0 c2 84 c2 89 c2 8c 79 7c 62 c2 83 22 c2 |@........y|
b..".|
00000130 83 60 09 3a 69 52 45 72 71 c3 88 c2 97 c3 a3 77
|.`.:iRErq......w|
00000140 c3 bf c3 89 37 07 c2 83 0d 43 c3 9f 27 4e 45 53
|....7....C..'NES|
00000150 c3 bd c2 ba 68 1e 47 77 c3 b3 46 6d 55 c2 9a 3d
|....h.Gw..FmU..=|
00000160 c3 8c 5a c2 b5 0a 2a 6e 54 c2 bc 57 4b 5a c3 b8
|..Z...*nT..WKZ..|
00000170 c2 91 54 c2 ab c2 9c 47 c3 93 7d 3e c2 9c 2f c3
|..T....G..}>../.|
00000180 83 69 c2 bf c3 8b c2 94 4b 17 2e 45 c2 aa 69 c3
|.i......K..E..i.|
00000190 b0 c3 aa 6f c2 94 c3 bd c2 99 72 c2 a5 c3 b6 c2
|...o......r.....|
000001a0 aa c3 ae c2 96 7d 7e 00 c3 af c2 99 4f 65 0a
|.....}~.....Oe.|

[zx...@googlecode.com]

Comment #4 on issue 1260 by ch...@orr.me.uk: Larger AZTEC 2D codes are not
decoded
http://code.google.com/p/zxing/issues/detail?id=1260

Actually, looking more closely at the differences:

0xc2 is inserted by ZXing before any original byte >= 0x80 and <= 0xbf.
0xc3 is inserted by ZXing before any original byte >= 0xc0, while the
original byte has 0x40 subtracted from it.

e.g. the correct decoding (on the left) is output by ZXing (on the right)
as follows:

# Everything below 0x80: no replacements
33 7f -> 33 7f

# Bytes >= 0x80 prefixed
33 80 -> 33 c2 80

# Bytes >= 0xc0 prefixed and reduced
2f c3 69 -> 2f c3 83 69

# Both 0xc2 and 0xc3 inserted
7a ae ca -> 7a c2 ae c3 8a


Hopefully this information is meaningful to someone; I unfortunately am
unable to determine how this comes into effect in the decoder.

[zx...@googlecode.com]

Comment #5 on issue 1260 by srowen: Larger AZTEC 2D codes are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

That's good info -- I also know about nothing about Aztec, but maybe
someone who knows and is motivated can translate into a patch.

[zx...@googlecode.com]

Comment #6 on issue 1260 by jungni...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

I am trying to decode a 362 bit string in C67x67 Aztec format, the error
correction level is at 23%. The detector is working fine but when it comes
to the decoding part the following exception was thrown "Error locator
degree does not match number of roots" and after some research I found that
during the reedsolomon.findErrorLocations(GenericGFPoly errorLocator) the
vars numErrors and e get compared. In my case numErrors equals 62 and e=0
can anyone of you figure out what that Error is about or how to fix this
problem?

[zx...@googlecode.com]

Comment #7 on issue 1260 by jungni...@gmail.com: Larger AZTEC 2D codes are

not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

I am trying to decode a 362 bit string in C67x67 Aztec format, the error
correction level is at 23%. The detector is working fine but when it comes
to the decoding part the following exception was thrown "Error locator
degree does not match number of roots" and after some research I found that
during the reedsolomon.findErrorLocations(GenericGFPoly errorLocator) the

vars numErrors and e get compared. In my case numErrors equals 62 and e=1

[zx...@googlecode.com]

Comment #8 on issue 1260 by srowen: Larger AZTEC 2D codes are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

It means there are too many errors to correct. Detection may not have
worked correctly.

[zx...@googlecode.com]

Comment #9 on issue 1260 by franz...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

How can that be when using images with only the aztec code. They are
generated and then thrown into the CommandLineRunner. It works with C67x67
with lower RS-ErrorCorrection. The Detector works fine, but the decoder
doesn't. We can't find a starting point to fix this issue.

[zx...@googlecode.com]

Comment #10 on issue 1260 by srowen: Larger AZTEC 2D codes are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

How? because the corners aren't found correctly. If so then the sampled
barcode is mostly garbage noise.

Are you really saying it's the decoder not detector? like you are feeding
the pure BitMatrix into the Decoder?
I'm not sure if you've actually ruled out detection.

[zx...@googlecode.com]

Comment #11 on issue 1260 by franz...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

We ruled the detector out for two reasons:
First, it works with lower RS-Correction on the same size, so the Aztec
Code should be found and the eye in the middle, too.
Second, I checked the found coordinates with the image and it matches the
positions.
It could be possible that either the bull's eye can't be read correctly for
whatsoever reason or the decoder and the RS algorithm have issues with the
size.

[zx...@googlecode.com]

Comment #12 on issue 1260 by srowen: Larger AZTEC 2D codes are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

The real test is to see how the BitMatrix matches the original image. Does
it seem to have binarized and parsed it correctly?

Or, build a BitMatrix directly from your test harness if that is feasible.
Don't use images at all.

[zx...@googlecode.com]

Comment #13 on issue 1260 by franz...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

The problem is the bull's eye, afai can see. The bull's eye says how big
the actualy code is, doesn't it? But the program fails at decoding it
properly, due to the RS-Correction error (if I'm wrong here, please correct
me). So, the image itself is not even in a BitMatrix. I could check whether
the bull's eye is correct in the matrix. I will do so later this evening
and update you.

[zx...@googlecode.com]

Comment #14 on issue 1260 by franz...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

Okay. You were right. The detection is off! It actually works, but the
problem is, the outtest corners are a excatly one row and column to the
inside. I will attach an image to explain. Any ideas where the problem is
and how I could fix it? I'm not too familiar with your code. The arrow
shows the corner bit detected for TopLeft. Sorry for the "censoring", but
you can create your own aztec code with Data. It's C67x67 with 23%
RS-Correction

Attachments:
Barcode_1.png 14.2 KB

[zx...@googlecode.com]

Comment #15 on issue 1260 by franz...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

To clarify: The outest row is skipped.

[zx...@googlecode.com]

Comment #16 on issue 1260 by franz...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

Ah, here is a better image. I colored the CornerPoints red.

Attachments:
test.jpg 1.4 MB

[zx...@googlecode.com]

Comment #17 on issue 1260 by srowen: Larger AZTEC 2D codes are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

I would not be surprised if there's an off-by-one issue somewhere in the
detector. When the modules are relatively larger than a pixel it may not
matter, but at higher densities it does. You already know 10x more than I
know about this class. If you have a patch that seems to fix the logic that
would be great. I do imagine it's a simple change.

[zx...@googlecode.com]

Comment #18 on issue 1260 by Ala...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

Im interested to know if there was any follow-up? I've watched the
changelog and didn't see any commit related to this issue. How long do you
imagine it would take for a java dev to find and fix the issue?

[zx...@googlecode.com]

Comment #19 on issue 1260 by franz...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

I have not been working too much on it latetly. I now know the bug for sure
and made a tentative patch which works for some aztec images, but not for
all. It works for this which are detected wrong on both axis. If the
scanner is wrong in only one direction it doesn't work, as it only alters
the factor. I'm trying to figure if there's a way to solve this for all
directions without 16 times bitsize loops. That would be way to much for
mobile scanning.

[zx...@googlecode.com]

Comment #20 on issue 1260 by kam...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

To get more accurate corner points you may need to change implementation of
getMatrixCornerPoints method. You can take advantage of reference grids to
do that.

[zx...@googlecode.com]

Comment #21 on issue 1260 by chuyennv90: Larger AZTEC 2D codes are not
decoded
http://code.google.com/p/zxing/issues/detail?id=1260

I have error when encoding text to Aztec code. this is log

10-13 18:32:51.557: E/AndroidRuntime(706): FATAL EXCEPTION: main
10-13 18:32:51.557: E/AndroidRuntime(706): java.lang.RuntimeException:
Unable to resume activity
{com.google.zxing.client.android/com.google.zxing.client.android.encode.EncodeActivity}:
java.lang.IllegalArgumentException: No encoder available for format AZTEC
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.ActivityThread.performResumeActivity(ActivityThread.java:2120)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.ActivityThread.handleResumeActivity(ActivityThread.java:2135)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1668)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.ActivityThread.access$1500(ActivityThread.java:117)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.ActivityThread$H.handleMessage(ActivityThread.java:931)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.os.Handler.dispatchMessage(Handler.java:99)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.os.Looper.loop(Looper.java:123)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.ActivityThread.main(ActivityThread.java:3683)
10-13 18:32:51.557: E/AndroidRuntime(706): at
java.lang.reflect.Method.invokeNative(Native Method)
10-13 18:32:51.557: E/AndroidRuntime(706): at
java.lang.reflect.Method.invoke(Method.java:507)
10-13 18:32:51.557: E/AndroidRuntime(706): at
com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:839)
10-13 18:32:51.557: E/AndroidRuntime(706): at
com.android.internal.os.ZygoteInit.main(ZygoteInit.java:597)
10-13 18:32:51.557: E/AndroidRuntime(706): at
dalvik.system.NativeStart.main(Native Method)
10-13 18:32:51.557: E/AndroidRuntime(706): Caused by:
java.lang.IllegalArgumentException: No encoder available for format AZTEC
10-13 18:32:51.557: E/AndroidRuntime(706): at
com.google.zxing.MultiFormatWriter.encode(MultiFormatWriter.java:84)
10-13 18:32:51.557: E/AndroidRuntime(706): at
com.google.zxing.client.android.encode.QRCodeEncoder.encodeAsBitmap(QRCodeEncoder.java:316)
10-13 18:32:51.557: E/AndroidRuntime(706): at
com.google.zxing.client.android.encode.EncodeActivity.onResume(EncodeActivity.java:192)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.Instrumentation.callActivityOnResume(Instrumentation.java:1150)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.Activity.performResume(Activity.java:3832)
10-13 18:32:51.557: E/AndroidRuntime(706): at
android.app.ActivityThread.performResumeActivity(ActivityThread.java:2110)
10-13 18:32:51.557: E/AndroidRuntime(706): ... 12 more


please help me.

[zx...@googlecode.com]

Comment #22 on issue 1260 by ch...@orr.me.uk: Larger AZTEC 2D codes are not
decoded
http://code.google.com/p/zxing/issues/detail?id=1260

@chuyennv90: This bug is about decoding, not encoding.

As far as I know, ZXing doesn't support encoding Aztec barcodes -- you'll
need to find another project which does.

[zx...@googlecode.com]

Comment #23 on issue 1260 by chuyennv90: Larger AZTEC 2D codes are not
decoded
http://code.google.com/p/zxing/issues/detail?id=1260

thanks ch...@orr.me.uk

[zx...@googlecode.com]

Comment #24 on issue 1260 by st.jug...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

I have further investigated this issue:

I have changed the getMatrixCornerPoints-method (see attachment), as
proposed. But the issue with read-errors for the big Aztec-codes still
exists.
The BitMatrix represents perfect the original aztec-code and no discrepancy
betwee the Aztek-code as picture and the BitMatrix can be detected. It
seems that the ReedSolomonDecoder has some problems with the error
correction.

Attachments:
getMatrixCornerPoints.txt 1.6 KB

[zx...@googlecode.com]

Comment #25 on issue 1260 by ogetb...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

doesn't the Aztec spec describe bit configuration at the corners? (not
targets)

[zx...@googlecode.com]

Comment #26 on issue 1260 by srowen: Larger AZTEC 2D codes are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

This change reduces the number of test images that decode by about 50%, I
don't think it's quite a step forward. Try running the Aztec black-box
tests.

[zx...@googlecode.com]

Comment #27 on issue 1260 by rafalv...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

It is definitely problem with getMatrixCornerPoints.
Even small distortions (eg. Fish Eye) can cause error in recognition of
corners.
My temporary (very ugly) solution is to use part of WhiteRectangleDetector
(see atachment).

If I have time I'll try to write something better.

Attachments:
getMatrixCornerPoints.txt 2.1 KB

--
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 #28 on issue 1260 by fyel...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

I suspect 1260 and 1605 are really the same issue. The code miscalculates
the corners, and ends up passing garbage to the Aztec decoder.

The Aztec code tries to extrapolate the location of the corners from the
location of the bull's eye. I've haven't figured out what the current
code is doing, but it seems to be "good enough" for small Aztec codes.

[zx...@googlecode.com]

Comment #29 on issue 1260 by fyel...@gmail.com: Larger AZTEC 2D codes are
not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

Looking further. What did you use to construct the two 95x95 structures?
Neither of the two above actually seems to encode "ABC 123456789".

If you read down the first two columns (reading left and right of each
row), you can see that both start with
00000000000001000011
The first four bits are padding
0000000001 / 000011 ...
The first "1" is there because no data word is allowed to be all zeros or
all ones, so a 1 is inserted after nine zeros.
000000000000011 ...
And this decodes into
CNTRL_PS
FLG(n)
B
C
...
Given that this code is completely mis-using FLG(n), (it's supposed to be
followed by three bits of info, but it isn't), I just have no idea what's
going on.

Using my new decoder (see issue 1605), I'm able to read the bitmap
correctly. I can even verify that the reference grid is there and in the
right place, so I have strong reason to believe I've read it correctly.
The Reed Solomon encoding just looks totally off.


I'm n

[zx...@googlecode.com]

Updates:
Status: Duplicate
Mergedinto: 1605

Comment #30 on issue 1260 by srowen: Larger AZTEC 2D codes are not decoded
http://code.google.com/p/zxing/issues/detail?id=1260

(No comment was entered for this change.)