Zxing Cannot Decode QR Codes It Creates

[Cali Ente]

So I have been using ZXing to decode and create barcodes. I have broken a text file into chunks and have been encoding these chunks into QR Codes. For some reason however, it cannot decode two of the chunks. I have tested the chunks separately and it can encode/decode them fine, but when running the whole file it breaks on these chunks. Oddly enough however a QR code app on my phone will read the chunks fine. Is there a reason for this? Just to recap, I have a file I split into chunks and then encode to QR codes. Some of the chunks can not be decoded by ZXing, but by other libraries. When I encode those same chunks separately they decode fine with ZXing, why is this?

[Sean Owen]

If you ask "why doesn't this decode" it would be much more useful to include an example of what you are encoding, or what the result is.

You haven't said how you decode it, or what the chunks are.

[Rogan Creswick]

I've also run into ZXing-generated QR codes that it can't parse.  I've attached one such code (this particular image is superimposed on a photo in the hopes that additional non-module context would make it easier for zxing to detect the code). This has come up for us because we want to run an end-to-end integration test where a binary blob is serialized to a bunch of QR codes, then those are read by our receiver and reconstituted.  However, the decoding process often fails.

To mitigate this, we're making multiple passes over the generated QR codes, using:

 - the raw, square QR codes

 - the QR codes placed in the center of a photo (as seen in the attachment)

 - the QR codes, rotated ~7 degrees, and placed in the center of the photo.

On the receiving side, we've tried using all variants of the TRY_HARDER and PURE_BARCODE hints, and various different versions of QR code.

At the moment, we're just accepting that about 30% of the time our test will fail (and thus the /actual/ test only fails if more than 30% of the sub-tests fail), but that's obviously sub-optimal.

The test can be found here: https://github.com/creswick/StreamingQR/blob/master/development/qrlib/src/test/java/com/galois/qrstream/qrpipe/SerializableRoundTripTest.java

And the decoding process is at:

https://github.com/creswick/StreamingQR/blob/master/development/qrlib/src/main/java/com/galois/qrstream/qrpipe/Receive.java#L109

--Rogan

On Wed, May 28, 2014 at 8:59 AM, Sean Owen <sro...@gmail.com> wrote:

If you ask "why doesn't this decode" it would be much more useful to include an example of what you are encoding, or what the result is.

You haven't said how you decode it, or what the chunks are.

--
You received this message because you are subscribed to the Google Groups "zxing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zxing+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sean Owen]

PURE_BARCODE mode will always work with generated images. Do you have
any example where this is not the case? that seems to be the OPs
question.

Adding background noise doesn't seem relevant.

Why are you constructing such a test though?

[Rogan Creswick]

On Wed, May 28, 2014 at 5:10 PM, Sean Owen <sro...@gmail.com> wrote:

PURE_BARCODE mode will always work with generated images. Do you have
any example where this is not the case? that seems to be the OPs
question.

I've attached one image, and here's a link to the property-based test I used to generate it:

 - https://gist.github.com/creswick/17808161de1f37a94415

The attached QR code does scan via the Android barcode scanner, but decoding with PURE_BARCODE results in a Not Found exception.

Adding background noise doesn't seem relevant.

It /seemed/ to help, at least in some cases, but I don't have hard data on that.

 

Why are you constructing such a test though?

I wasn't intending to test zxing's ability to round-trip; I'd just assumed it would work, and wrote the test as a simple way to see if our wrapper code for streaming multiple QR codes would round-trip also.  We (essentially) have a function from byte[] to List<Image> and another function from List<Image> to byte[], so it seemed useful to put random data in one end and make sure it came out the other.

The qr code density makes a large difference, but we've never been able to find one that works reliably in our test suite (hence the workaround I mentioned earlier).

[Sean Owen]

This is handy -- yes this uncovers a corner case in this mode when the density is high. I'll add a fix, which makes all the tests pass.

It may or may not help your real-life use case, but worth a fix.

[Rogan Creswick]

Thanks! I'm not sure when we'll be able to fold this in (it might have to wait until the next maven release of zxing) but if I can find the time to build a dev jar and try it out in our full test suite I'll let you know if any other issues arise.

--Rogan

On Sat, May 31, 2014 at 1:02 PM, Sean Owen <sro...@gmail.com> wrote:

This is handy -- yes this uncovers a corner case in this mode when the density is high. I'll add a fix, which makes all the tests pass.

It may or may not help your real-life use case, but worth a fix.

--

[Stanley Tso]

On Saturday, May 31, 2014 at 1:02:58 PM UTC-7, Sean Owen wrote:
> This is handy -- yes this uncovers a corner case in this mode when the density is high. I'll add a fix, which makes all the tests pass.
> It may or may not help your real-life use case, but worth a fix.

I found this code that Zxing generates can't be decoded: uNpsg6u2uMMVt1VJi0MYDaIpYsPNiiX66BW13bfI77j7AN1eQi for some reason.....