Code39 barcodes about quaggajs HOT 14 CLOSED

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

from quaggajs.

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

from quaggajs.

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)

from quaggajs.

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!

from quaggajs.

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

from quaggajs.

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

from quaggajs.

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?

from quaggajs.

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!

from quaggajs.

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?

from quaggajs.

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

from quaggajs.

from quaggajs.

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.

from quaggajs.

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?

from quaggajs.

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:[email protected]]
Sent: November 16, 2015 6:15 AM
To: serratus/quaggaJS [email protected]
Cc: peter horwood aka Madman Pierre [email protected]
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

from quaggajs.