Incorrect barcode scanned

[JonasPrap]

We have a serious production issue regarding pdf417 scanning library. In some situations an incorrect barcode is scanned. This should never happen, it creates a huge issue for us.

For example if we have a simple code-128 barcode with text "004XYZ1" it is sometimes incorrectly scanned as a UPCE, ITF or EAN barcode giving wrong results like 25818192 or something similar. On production this happens when barcodes are small with poor light conditions and a shaky hand. Maybe people fail to center barcode in screen and only half of it gets scanned producing wrong results.

For development this can be reproduced by covering a part of barcode and holding at an angle.

I captured this image by placing a breakpoint at when scanning results are returned. In this case it gave the wrong result.

This happens on multiple Android devices, with library versions 4.1.0 and 4.5.1. It can also be reproduced on iOS version of library.

We use this:

        BarDecoderRecognizerSettings barDecoderSettings = new BarDecoderRecognizerSettings();

        barDecoderSettings.setScanCode39(true);
        barDecoderSettings.setScanCode128(true);
        barDecoderSettings.setTryHarder(true);//Does not make a difference if on or off, still wrong result.

        // enable ZXing scanner for other barcode types not having custom implementation
        // in pdf417.mobi lib.
        ZXingRecognizerSettings zxingSettings =  new ZXingRecognizerSettings();
        zxingSettings.setScanQRCode(true);
        zxingSettings.setScanAztecCode(true);
        zxingSettings.setScanDataMatrixCode(true);
        zxingSettings.setScanEAN13Code(true);
        zxingSettings.setScanEAN8Code(true);
        zxingSettings.setScanITFCode(true);
        zxingSettings.setScanUPCACode(true);
        zxingSettings.setScanUPCECode(true);
        zxingSettings.setSlowThoroughScan(true);//Does not make a difference if on or off, still wrong result.

        RecognizerSettings[] settings = {barDecoderSettings, zxingSettings};

        Intent intent = new Intent(context, Pdf417ScanActivity.class);
        intent.putExtra(Pdf417ScanActivity.EXTRAS_LICENSE_KEY, LICENSE_KEY);
        intent.putExtra(Pdf417ScanActivity.EXTRAS_RECOGNIZER_SETTINGS_ARRAY, settings);
        intent.putExtra(Pdf417ScanActivity.EXTRAS_SHOW_DIALOG_AFTER_SCAN, false);

Please provide suggestions how can this be fixed. We need to be able to scan most barcode types. But we also need to be sure the returned results are accurate even if it makes scanning slower.

[DoDoENT]

Hi,

enabling all barcode types will definitely lower the quality of scanning performance because similar barcodes can be misinterpreted (for example, UPCA, UPCE, EAN8 and EAN13 are different just in several bars and if those bars are not clearly visible, mismatch may occur).

If you know the type of barcode you are scanning, enable only those types (for example, do not enable ITF if you definitely do not need scanning ITF).

The other approach would be to perform advanced integration with embedding Recognizer view directly into your activity. Thus, you can obtain scan results with ScanResultListener and you can continue scanning as soon as you receive result with resumeScanning. With this approach you can implement counting of barcode types and if you receive multiple times same result (same barcode content and same barcode type), then you can be confident that the scan was performed correctly. If you in multiple scans receive different barcode results, then you can instruct user to better position the device over barcode. You can check Pdf417MobiDemoCustomUI for example of how to perform multiple scans within single camera session.

The same approach can also be used in iOS library.

[JonasPrap]

It would be good to have a setting in library that would improve accuracy. Currently if we enable only Code39, Code128, QR, DataMatrix and Aztec there are still cases where we get a bad reading. It's much more harder to reproduce, but it still happens.

[DoDoENT]

You already have such settings for PDF417 barcode recognizer, for Code39 and Code128 barcode recognizer and for ZXing recognizer.

If you need perfect accuracy at additional time cost, you can implement custom UI and count scan results as described in earlier post.

[JonasPrap]

Those settings only reduce accuracy, we already have them set for maximum accuracy.

Counting results is not an option either, because it again can produce incorrect results. For example have only Code39 enabled. Take a Code39 barcode with contents 5352 and cover a couple of bars on it. The scanning library will produce results as "53" Code39 for this barcode for a couple of times, thus counting is not an option. This is just one example of many why counting would not guarantee correct results...

[DoDoENT]

Jonas,

if part of Code39 barcode is not visible, it is not possible to read parts that are not visible. Unlike some other barcode symbologies, Code39 does not have "start" and "stop" patterns. It is more like alphabet, so if some parts are missing, these parts will not be read.

It is the same as if you are trying to read text "5352", while having "52" part covered - you can only read "53".

If your use case requires scanning partial barcodes, then you should consider using barcode symbology that support data correction (for example PDF417 barcode). If you are scanning third party barcodes (i.e. barcodes are not printed by you), then you must design an UI such that will inform the user that not all barcodes can be scanned correctly if only part of the barcode is visible.

[JonasPrap]

My use case requires not to scan incorrect barcodes. If it's only "53" scanned then it should not be scanned at all, because that scan is incorrect. If it's not possible to scan full barcode (in case its damaged or covered) then it should not be scanned at all.

[DoDoENT]

In you use case you should consider using barcodes that support error detection and correction (for example Code128 or PDF417). Code39 barcode does not support error detection so if partial barcode is visible, partial barcode is read. This is not case for Code128 and PDF417.

Please check this article for more information.

[DoDoENT]

Hi Jonas,

can this issue be closed?

[JonasPrap]

Thanks for all the info. We eded up scanning 2D barcodes 3 times. This solves most of the issues, like pointing at a carpet no longer produces some random result. We can't have clients changing their existing barcodes, and they appear to be using Code39 a lot. We can suggest to change them, but that is as far as we can go. So this is not perfect, but will have to do...