Skip to content
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

Code39 barcodes #41

Closed
mzimmerman opened this issue Jun 6, 2015 · 14 comments
Closed

Code39 barcodes #41

mzimmerman opened this issue Jun 6, 2015 · 14 comments

Comments

@mzimmerman
Copy link

I have some Code39 barcodes (as seen on roadid race bibs (http://www.roadid.com/sponsorship/SampleBib.aspx)

Quagga will do a partial reading sometimes and return 345 as 34 or 45. I thought about enforcing 3 digits for the read, but RoadID doesn't always include 3 digits (e.g, 50 not 050).

Any advice? (new to barcodes) Looking to use this in github.com/mzimmerman/racergo

@madmanpierre
Copy link

I've used barcodes for years. Unless I am mistaken, Code39 requires a stop and start character of "" so the reader shouldn't accept a reading if it doesn't see *345 or 50 ... so, that sounds to me like a bug in quagga. Code39 is one of the ones I'm most interested in, and would be willing to help test as well (once I get quagga working in my application).

@serratus
Copy link
Owner

serratus commented Jun 7, 2015

@mzimmerman thanks for reporting back to me. I'm kinda short of real Code39 barcodes, that's why I'm forced to use generated codes which might not be an optimal solution. Do you have any sample images for me that I could use?

@madmanpierre do you need help setting up quagga?

@mzimmerman
Copy link
Author

Here are some real codes that I've been testing with. I believe code39 are supposed to start/end with * which seems to be the case here. I'm using quagga with getUserMedia and the onDetected API call.
(*Sorry, awful pictures before)

img_20150607_144357
img_20150607_144411
img_20150607_144425

@mzimmerman
Copy link
Author

Using the file input site these all detect properly. I guess you need/want an example that fails? I'll have to see how to do that; hopefully better than guess and check!

@serratus
Copy link
Owner

serratus commented Jun 7, 2015

@mzimmerman Thanks for the images. I'll simply print them and use my camera to detect the issues. Stay tuned!

@madmanpierre
Copy link

@serratus I am managing about 20 developers around the world along with support and sales staff. Getting quagga going in our main product is 'my' development project - as I have time :) I started on Thursday. The Typescript d.ts is tentatively done, and I'm now working on integrating it. Then I'll be having myself and one or two of my developers testing. If I have questions I'll ask. Thanks!

serratus added a commit that referenced this issue Jun 12, 2015
@serratus
Copy link
Owner

Thank you for pointing out the issues with Code 39 barcode reading. I've partially fixed the problem where only parts of the code are being returned. In addition, the result is only considered successful if there is content available.

Can you please give it another try and report back to me?

@mzimmerman
Copy link
Author

Initial testing shows perfect results and also seemingly must faster at detection! I've only tested it a little bit, but it seems great! Thank you so much!

@mzimmerman
Copy link
Author

Using version 0.8.0, I'm getting "truncated" results again. 212 rendering as 21 or 12. Usually it's 212 however. Using the code_39_reader with Live/LiveStream @ 1280x720 on chromium.

I can reproduce it with http://serratus.github.io/quaggaJS/examples/live_w_locator.html but when I save the images that the live locator said were "12" or "21" and input it to http://serratus.github.io/quaggaJS/examples/file_input.html 212 it always gets the correct result.

Any ideas?

@mzimmerman mzimmerman reopened this Nov 11, 2015
@mzimmerman
Copy link
Author

I feel like the decode() function should be changed slightly.
E.g., only when the decoded characters found start and end with * -- this way, you can never read a partial.

When I read the code though, it looks as if https://github.com/serratus/quaggaJS/blob/master/src/code_39_reader.js#L79 never lets the function return a result unless an asterisk was found, but in practice I'm not seeing that. I also can't find where or how the leading asterisk is thrown away.

I tried to modify the decode() function to only return true if result starts and ends with an asterisk, but the decode function never saw the leading asterisk. I guess _findStart() throws it away?
https://github.com/serratus/quaggaJS/blob/master/src/code_39_reader.js#L187

@mzimmerman
Copy link
Author

12fail212

@serratus
Copy link
Owner

Thanks again for reporting the issue with Code 39 decoding, and the example image. I was able to reproduce the error and tracked down the bug. The fix is now available in the newest version (0.8.1). Please give it another try and close the issue if it is resolved for you.

@mzimmerman
Copy link
Author

Yes, looking a lot better, no partials (12 or 21), but I'm still receiving results that aren't 212. What I am getting are symbols and letters - e.g., 2%. It usually does not trigger that way and instead returns the proper code of 212, but I can still reproduce it fairly easily. Maybe with the resolutions of the images I'm using this is to be expected? Again, not a barcode expert, there is supposed to be a check bit type piece of data with code39 too - does 2% pass that check bit?

@madmanpierre
Copy link

Unfortunately, there is no check digit on code39 unless ‘you’ build it in. Code39 has some ‘character by character’ protection that should make it ‘hard’ to get a bad character – if ONE of the bars or spaces is misread in a character – then it should fail. But if more than one are misread*, it is then possible to get a misread.

There are two patterns that characters can follow in bar39.

The 1st 39 consist of 2 wide bars and 1 wide space (all the rest of the bars and spaces MUST be ‘narrow’) (a-z and 1-9 are in this set of 39 along with 3 symbols and * - * is normally reserved as the start/stop characters.)

The 2nd 4 consist of no wide bars and 3 wide spaces. (% is in this second set of 4)

  • Because only these 2 patterns are allowed, if there are two misreads SIDE BY SIDE should be IMPOSSIBLE to be misread – it should be thrown as a no-read. Since this would mean that a space AND a bar were misread – and the two patterns cannot be created by changing just 1 bar and 1 space. It would require either 2 bars be misread (and all spaces CORRECTLY read) or 2 spaces misread (and all bars CORRECTLY read) – or it requires MORE than 2 mistakes that ‘happen’ to end up as one of the 2 patterns – a very unlikely situation.

So if a check is done to make sure it meets one of those patterns only – it should have an extremely low bad-read rate. Since you are saying you are getting the % character as a bad read – that means there were AT LEAST 4 Bars incorrectly read. To my mind this means you should be getting dozens or hundreds of no-reads for each failed read.

If you ARE getting dozens of no-reads for each failed read then it would seem to me that your hypothesis of resolution is a reasonable guess. If you are NOT getting dozens of no-reads for each failed read, then it would seem to me more likely that it is a failure in the quagga algorithm. It has been several months since I have run Quagga with the debugging options so I don’t remember the specifics – but can I suggest you figure it out (it wasn’t hard) and report back?

Adding a check digit: There is no ‘official’ way to do it, But there is one common checksum practice. The rule of 43 (sum up the data characters, then divide by 43 and put the result as the last character just before the terminal * character.) If you have control of both the production of the codes and the reading of them– then you can use the rule of 43.

It has been several months since my company has tested quaggaJS (we use it in our product but currently have a very small number of people using it and their use is ‘light’) we are coming up to another test cycle and I can join you in testing, because I have more that I expect will want to use 39. I’ll make sure I update to the most recent Quagga before we start our testing cycle.

peter

From: Matthew Zimmerman [mailto:notifications@github.com]
Sent: November 16, 2015 6:15 AM
To: serratus/quaggaJS quaggaJS@noreply.github.com
Cc: peter horwood aka Madman Pierre petere@madmanpierre.com
Subject: Re: [quaggaJS] Code39 barcodes (#41)

Yes, looking a lot better, no partials (12 or 21), but I'm still receiving results that aren't 212. What I am getting are symbols and letters - e.g., 2%. It usually does not trigger that way and instead returns the proper code of 212, but I can still reproduce it fairly easily. Maybe with the resolutions of the images I'm using this is to be expected? Again, not a barcode expert, there is supposed to be a check bit type piece of data with code39 too - does 2% pass that check bit?


Reply to this email directly or view it on GitHub #41 (comment) . https://github.com/notifications/beacon/AC7G01oNN640wA5J2cIF0Npx7GYhbf4Aks5pGc5TgaJpZM4E6Lg-.gif

@serratus serratus closed this as completed Apr 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants