Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Code 128 Barcode Accuracy #104
I've been testing out this project for using to read barcodes on USPS shipping labels, but I've noticed that the results are sometimes very, very wrong and sometimes are only slightly wrong. Since the result is a 30 character string, it's hard to spot the subtle incorrect ones without going through the entire string, which defeats the purpose of scanning the barcodes.
I dug into the code and found that it is correctly using the checksum (yay) on the Code 128 barcodes, but is still coming up with the wrong result because there are multiple ways to get to the same checksum value.
I've gotten more accurate results by adding a few checks to
With those tighter checks the incidence rate for incorrect values goes down. The tradeoff is it takes longer to scan the barcode because the correct spot must be found to get it to read. However, it is basically rejecting incorrect values until it ends up with the correct one, which is what I want. Using a higher resolution (and closer focus) webcam yields better results.
Is it possible to make these configurable into quaggaJS so that they can be tweaked via the config and not need a custom version? I see some hint of configs being supported for readers but no way to provide one when configuring quaggaJS.
Thanks for reporting on that issue. I've also had some troubles with false positives on Code 128 barcodes. Those bugs are usually hard to track, that's why I haven't really had the time to dig deeper.
As soon as I can find myself some free-time, I'll look into that. Do you have a few samples where these problems can be reproduced?
I'm continuing to play with ways to get better accuracy when reading, and have abandoned the original technique mentioned because it was preventing matches from occurring at all.
So far I'm having good results with only accepting a match if it is read 3 times. It seems most extraneous results are unlikely to occur twice, let alone three times, so if it read the same result 3 times then it is likely the correct result. This leads to a high accuracy, but it may not detect at all.
Here's some output from logging which logs the possible results (that got all the way past the checksum check) and how many times they occur:
Another possible technique (but more complex) would be to keep track of the 'best match' for each individual code and weight it by the number of times it has appeared. So if a code is read as 98 with a 0.15 error twice, and read once as 42 with a 0.10 error once, the algorithm would choose the 98 (weighted error of 0.075). However, that's more complex because you need to recheck the checksum, and you may end up with a case where the best candidate codes do not create a result which passes the checksum.
added a commit
Apr 17, 2016
In the past few days I've been busy testing the robustness of the Code 128 reader and making some adjustments to the parameters as well as other corrections to reduce the occurrence of false positives. Could you please try again and close this ticket in case it solves your issue?
@serratus, sorry, I didn't see your response until just now. Assuming the live demo is running this latest version, I still get a lot of false positives from it. Holding up a sheet of paper with the sample image I provided will run through a dozen or so different false positive results.