-
Notifications
You must be signed in to change notification settings - Fork 980
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
Comments
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). |
@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? |
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! |
@mzimmerman Thanks for the images. I'll simply print them and use my camera to detect the issues. Stay tuned! |
@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! |
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? |
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! |
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? |
I feel like the decode() function should be changed slightly. 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? |
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. |
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? |
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)
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] 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? — |
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
The text was updated successfully, but these errors were encountered: