Speed of barcode detection, relevant flags and allowing diagonal scans?

Skip to first unread message


Nov 16, 2016, 3:35:47 PM11/16/16
to zxing

I just started an Android project and I'm importing com.google.zxing.integration.android.IntentIntegrator

Doing tests, I noticed it's sometimes pretty hard to have the scanner find the barcode, I have to make sure it's aligned well, and move the phone back and forth several times before it find it.

(In case it matter, the targets are 52x52 ECC200 codes generated using iec16022 on linux)

I know it can be caused by the phone's camera or a lot of other things, but I have a couple of questions to make sure :

- I notice I need to have the phone oriented perfectly right (the line of the scanner must line up with the middle line of my code).
If I try to hold the phone diagonally, the scan almost never happens.
But I see some other scanner apps allow it, so I'm wondering if it's an option ? A flag to tell the scanner not to check the orientation?

- Is there some flags or intents I can use to speed up the detection, or make it less strict? I tried using initiateScan(DATA_MATRIX_TYPES) so it doesn't have to look for other codes, I think it helped a bit, any other similar hint?

Maybe telling the scanner the size to look for would help? (Since I only generate 52x52 codes)

Thanks, and sorry for the beginners questions!

PS. Here's an example : http://i.imgur.com/bYOEM33.png

Lachezar Dobrev

Nov 17, 2016, 10:25:39 AM11/17/16
to Dino, zxing
  These are Data-Matrix bar-codes.
  The reader for Data Matrix has some quirks, the most significant one is that the detector expects that the bar-code will be in the middle of the screen, and will have a white rectangle (upright!) around it. This does impose some limitations that are not there with let's say QR Code for instance. The centre point of the screen must be inside the Data Matrix boundaries, and you must be able to draw an upright (not tilted, skewed or rotated) rectangle that is all white around the Data Matrix. To help with the second issue I've been known to put additional white space around the Data Matrix that is beyond the minimum required 1 module, for instance putting the Data Matrix in a white circle with diameter more than twice the width of the Data Matrix (example attached).

  You can enhance the performance by specifying that the only format you're looking for is Data Matrix, and supply the TRY_HARDER decoding hint, but the effect may be marginal:

  // Create integrator
  IntentIntegrator integrator = ...;

  // Specify the TRY_HARDER hint
  integrator.addExtra("TRY_HARDER", Boolean.TRUE);

  // Request only Data Matrix


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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



Nov 17, 2016, 10:35:17 AM11/17/16
to zxing
Thanks for the answer!

Indeed, I noticed I couldn't scan the code at all earlier when it was next to a black border. That's a pretty big circle in the example, lot of wasted space...

But it should be easy to change to QR codes since I'm so early in the project, and I don't have any big reason to use Data Matrix specifically, I'll just switch, thanks for the info.

Sean Owen

Nov 17, 2016, 3:16:02 PM11/17/16
to zxing
Yes, it depends so much on the barcode, its quality, and the device hardware. You should find run of the mill QR codes scan in hundreds of milliseconds, but some will never scan.

You do not need perfect orientation, no, but, it's also not valid to scan some barcodes in some orientations. Obviously, you can't read UPC at a 90 degree angle; that's not valid. But +/- 20, or 180 +/- 20, should be fine. QR codes can be read in any orientation, though they're a little harder at 45, 135, 225 rotation. Diagonally would be invalid for UPC, PDF417, etc. DataMatrix should be fine in any orientation.

For UPC et al it wouldn't be hard to scan in several orientations, but, those are CPU cycles that aren't spent just trying to look again at the next frame which might decode. So it costs something for the normal case of scanning in its natural orientation and that's why I don't do it.

It's not that the detection is slow. Even on a phone each full parsing of an image for all barcodes is <100ms. It's that almost none of the frames you present can be decoded as valid barcodes. It "takes a while" to wait for a frame that happens to work. 

If you're writing your own code yes restricting to an area you know contains the barcode is of course helpful. Try various binarizers too.
Reply all
Reply to author
0 new messages