New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code 128 Barcode Accuracy #104

Open
dsanders11 opened this Issue Apr 14, 2016 · 8 comments

Comments

Projects
None yet
4 participants
@dsanders11
Copy link

dsanders11 commented Apr 14, 2016

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 Code128Reader: I added a final check that no individual code has an error above X, and a check that the checksum code has an error below Y. The rationale behind that is if the checksum is not trustworthy (high error) then it will end up OKing an incorrect value for the barcode.

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.

@serratus

This comment has been minimized.

Copy link
Owner

serratus commented Apr 14, 2016

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?

@dsanders11

This comment has been minimized.

Copy link

dsanders11 commented Apr 14, 2016

Here is a sample label that produces bad results. When printed so the barcode is around 4 inches wide it will result in about 30% bad results using the live demo and the webcam on a Macbook Pro,

@dsanders11

This comment has been minimized.

Copy link

dsanders11 commented Apr 15, 2016

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:

Object {)(~,zg7M]8Mc3: 1, 420957479499907123456123456781: 3}
Object {630957479499907120456120066781: 1, 420957479499907123456123456781: 3, 25420957479499907123456124457819: 1}
Object {420957479499907123456123456781: 3, 420957479499907123696123450580: 1, 25420957479499907123456120456781: 1, 420957479499907123696123456781: 1}
Object {630357089412177102456120060542: 1, 420957479499907123456123456781: 3}

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.

@serratus

This comment has been minimized.

Copy link
Owner

serratus commented Apr 19, 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?

@dsanders11

This comment has been minimized.

Copy link

dsanders11 commented Apr 28, 2016

@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.

@serratus

This comment has been minimized.

Copy link
Owner

serratus commented May 3, 2016

Alright, thanks for the feedback. I'll give it another try in the next few days.

@bchr02

This comment has been minimized.

Copy link

bchr02 commented Jan 31, 2017

I occasionally get false positives with code128 as well. Usually this happens when the barcode is not lined up properly or if the whole barcode is not visible within the camera.

@dustinfl

This comment has been minimized.

Copy link

dustinfl commented May 2, 2017

I like your approach @dsanders11, I'll implement that as I'm experiencing the same issues when playing around with the live demo and I was wondering what approach could be made to make sure we've got the right data to check against.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment