Recomendation for best working readers

[kevinpapst]

I wonder if there are any recommendations that can be shared about which readers have the best results?

Use-case: a new app that generates barcodes with some js lib and allows to read those with quagga2. Similar to the thread about "best working hardware" I'd like to hear some recommendations about the readers.
My users are free to configure the barcode type they want to use, as this app is not required to follow any specific industry standard.

Now I would like to avoid those readers that have a lower positive matching rate (or higher false rate), as those will lead to less support requests 😁

From my naive point of view I imagine that not only the hardware, but also the lighting and the print quality have an impact on the results.
Maybe also the size of the barcode and amount of data (eg a short "UPC-E" is easier to identify than a large "Code 39 Extended")?

Can you share some of your experiences @ericblade ?

Edit ... and before I forget that: THANKS FOR YOUR WORK you are doing with quagga!

[ericblade]

Well my experience with a lot of the variables is pretty limited. I use upc exclusively in my app, and I've tuned my app pretty specifically to work decently with my personal lg G6 .

What I do know is that my girlfriend's phone, a LG Stylo 3 or 4 I think, has significantly worse results with the same settings. I also know that patchsize can have a significant effect on the auto locate mode being successful or not.

I hope other people can offer more experiences, and we could make some datasets, maybe come up with some ways to increase accuracy. I've recently noticed that holding my finger directly above or below a barcode not only allows my cameras autofocus to work better, it seems to make auto locate and reading more successful.

[WardLootens]

Lately I have been testing mostly with code 128, with almost flawless results.
I noticed that results with i2of5 are way less accurate. (gut feeling 30% error rate)

I also experienced that results on 'better' phones (e.g. iPhone) are better (and faster!) than on 'cheaper' phones, (e.g. my Moto 5G plus)

[RNCTX]

Hello everyone, I just found this lib today and am using it in Node. I am doing some work for a non-profit and they'd like to build an app that can scan UPCs of donation items to keep inventory with, hopefully without having to buy UPC scanning equipment.

Here are some (intentionally bad) samples...

https://imgur.com/a/r05utMQ

I took a video walking around my kitchen with an Iphone 5SE, recording at 4k/30, then loaded up the video and screenshot the above UPC frames from the video on my laptop, and passed the raw PNGs from the screenshot to the above imgur album.

My flow into Quagga:

1. I used headless Puppeteer+Chrome to load the imgur image with the viewport set at Iphone 5SE resolution (1136 x 640)
2. I passed base64 screenshot output from puppeteer into Quagga with both UPC types enabled
3. return ???

Here are the results...

Number 1 I'm guessing struck out due to having an entire bar in the code obscured by glare. Number 3 had the worst focus of the bunch and was in a blue color, not sure which to investigate there? I'm gonna pass these through a greyscale filter as well as deskew/flatten and see if that makes any difference. Unfortunately the image processor I'm using is crashing node with its greyscale option so I'm gonna have to figure that out first.

[RNCTX]

Update: greyscale didn't help on the two that failed. I took a second, much higher res pic of the green one (added to same album linked above) and the container curvature seems to be the culprit, didn't make any difference.

[ericblade]

Hi @RNCTX .. thanks for some real life samples! UPC reader doesn't seem to be the most accurate of the readers, but in this case, at least it's working between a good result and a no-result-at-all, which is a lot better than "really inaccurate result" :)

I have a suspicion that number 1 is failing because of the glare making it look like a much larger whitespace than should be there. Maybe some time spent poking around with Gimp or Photoshop, and Quagga together could find some ways to make image adjustments that make it possible to more reliably read images like that. Of course, that doesn't help automated reading, but if it gives us an idea of some ways to process the image before making the decode pass on it, something could be implemented to add that as an image post-process / pre-decode process step.

I can't check it out right now, but my thought on #3 is that there may not be enough whitespace around the barcode. Cutting the barcode, and putting a good 25 px whitespace on each side of it would tell us if that is the case or not. I have proposed an idea that maybe when the Locator code finds what it thinks is a barcode, it could try to surround that area with whitespace, before passing to the Decoder.

I've noticed that placing a finger above or below a UPC barcode while holding the item can greatly increase the accuracy of the scan from the LiveStream.

I think there's a lot of improvement that can be done on these types of images, I'm just not sure entirely where to start. I've been really wrapped up in bringing the code base up to date, too, which will hopefully help future enhancements.

[RNCTX]

Thanks for the hints!

I tried de-warping (flattening the container curve) on the original two failures with Scantailor and it didn't have any effect, these both still failed...

I re-took pics of the two items in question without the glare, and that DID work... (original album updated with the two new pics as well)

So it seems that it handles the curvature of the images okay after all.

[ericblade]

yeah, you might be surprised at the sorts of barcodes that it does read when you're doing a lot of UPCs. I have a surprising amount of success with barcodes that have large marks through them, but usually in red or black. Since a barcode is defined by the whitespace, moreso than the black space, having the blackspace become whitespace can be a bit of a problem. I'm surprised that on the blue one, that the glare was so much of a problem, though.

On the first one, it's really obviously not going to scan, since to our eyes, it's not readable as a valid code .. but the second one, the glare is mostly out of the area being scanned. I wonder if some sort of messing with the Contrast/Brightness/Color on that could get it into a working state -- and if so, is that some sort of a function that would be good to apply in general, or only in specific situations?

Here is where I wish I knew how Serratus originally built and debugged these decoder modules :-)

[RNCTX]

That was my million dollar question: what sort of automated filters can be added to the incoming image to help the scanner along?

FWIW here's our use case:

Imagine a place in the immediate days after a hurricane. Roads are flooded and/or obstructed, but people still need things that are generally only in 3 day supply locally. We've got small airplanes and their owners volunteering to deliver stuff to such places by air, but the stuff has to be sorted and inventoried as it comes in, it's all random donations.

Here's what that looks like, it's semi-controlled chaos, lol...

So volunteers who may or may not have any retail or warehouse experience have to sort and stock all of this stuff. Maybe in the parking lot as they unload from trailers and SUVs (in the sun, more glare), maybe in a poorly lit airplane hangar, maybe in a well-lit office lobby like the one in the pic. Can't really control the conditions because we don't know where it will be. It'll be wherever we get the biggest building donated to us to use on or around the airport property.

It's not really preferable to buy handheld scanners when everyone has got one in their pocket in the form of a phone. I understand that both phone platforms have UPC scanning implementations in their SDKs, but maintaining two complex phone apps in perpetuity will cost more than just buying the scanners, so I'm mocking up the idea of setting up all of the business logic of this as a web app, and then we could hypothetically just browser-wrap it on a phone.

[ericblade]

Well, I'm pretty sure that there are situations where some additional processing besides just using the "singleChannel" option would improve the image read capability. I also know there are javascript libraries in existence for modifying and filtering image data. I don't think it would be particularly difficult to implement a capability in Quagga to pass image data to an external processor function, and then run the decoder on the results of that. I think that we'd have a lot of manual work to do to find things that legitimately improve the situation.

FWIW, for your use case, handheld scanners are most definitely a better option functionally, but of course, you're going to have a fair amount of expense involved that i'm sure you would prefer to spend on better things if possible. And even if you have a quantity of laser scanners, if you have more people, you can process more things even if you don't have a laser scanner available. The application I'm working on is for resellers, and can work with any laser scanner that connects to a phone (i use a USB model, but there are bluetooth and others) as well as having an option to use Quagga to scan things.

I was not aware that mobile platforms have any built in scanning implementations? if they do, that's something i'd love to be able to connect to in places where it's available, if it can somehow be connected to via web code, perhaps via PhoneGap or whatever it's called these days.

So, anyway, while filtering is not a current capability in Quagga, it sounds like it's something that could be quite useful. ... might want to do it in a few stages.. like have a pre-locate filter, and a post-locate filter.. pre-locate would attempt to just clean up the image in some ways, while post-locate would be given the image data and the box area that the locator thinks has the barcode and could adjust the image further so that the decode step may be more successful.

I think we'd need to find an example that we can manually fix, first, and proceed from there to design a proper implementation that does it automatically, then try it on other real life images, and see how it goes?

[RNCTX]

And even if you have a quantity of laser scanners, if you have more people, you can process more things even if you don't have a laser scanner available.

That's the kicker. We had around a thousand ground volunteers over the span of a week in Raleigh, NC after hurricane Florence in 2018. If all of them can scan, sort, and dispatch stuff that comes in the door, that's more stuff getting done in a day. If we wanted to buy a thousand handheld scanners it's not just the cost, but now we have to bring a bunch of handheld scanners on the road with us (we're all from Texas).

People have phones already.

I was not aware that mobile platforms have any built in scanning implementations? if they do, that's something i'd love to be able to connect to in places where it's available, if it can somehow be connected to via web code, perhaps via PhoneGap or whatever it's called these days.

Here are the iOS docs and the Google docs.

Seems worth noting that the Google implementation works on both platforms and thus could be used for "all" devices, but only mobile ones in a closed ecosystem. It goes without saying that these are walled gardens.

Google's machine vision API can only be used on Firebase or on a Node application that lives on the Google Cloud service. iOS's is not open source either but it could at least be built into an OSX app, I presume.

So they haven't made this library you're working on obsolete yet. If you want to do this locally (no internet) outside of a closed-source phone SDK, then you can't use Google's solution. At best you could use Apple's solution on a Mac on the local network.

It still baffles me that Apple and Facebook managed to convince the whole world to do most of their internet activity on a phone, but here we are, lol.

[ericblade]

a thousand handheld scanners it's not just the cost, but now we have to bring a bunch of handheld scanners on the road with us

Yep. I can't recommend enough having at least some scanners available for heavy scanning jobs -- when I'm about to scan a lot of items, I go find my USB laser scanner and the USB A To C adapter. But I don't carry those with me everywhere I go that I need to scan things, because it's bulky and annoying to deal with. Even micro Bluetooth laser scanners are still annoying to carry around. But they are far more accurate and faster than visual scanners. If I were doing what you're doing, i'd probably consider using at least a small number of laser scanners, just because it'll get the job done a lot faster. But to keep costs and logistics in check, and to be able to support any number of users, even if it's well beyond the hardware availability, definitely have a cam scanner.

Anyway, that's all a bit off topic to the actual library itself -- I think we've got a couple of different asks here -- if you've got some time to spend figuring out some filters / adjustments that can be made to images that fail, i'd be more than happy to architect / code / help code the improvements necessary to make automatic adjustments happen. I think this is quite important stuff to do, but it's very outside where my current focus is.

[RNCTX]

Thanks, will keep in touch and let you know what way they decide to go. Board of the charity will have to have a sit down with a slow explanation of what it costs for phone apps, what it costs for scanners, and what it costs for open source development and weigh them all to figure it out.

Meantime I have a spiffy back-end mockup made up for them to see that it can be done for very little money if they go the open source route, so thanks for keeping this library alive for that!

[ericblade]

Excellent. I should probably mention that I am presently not employed in a programming career, so if someone wants me to change my current focus from where it is, to improving the UPC scanner ability, that would be one way to very quickly do so :-D In any case, I'd love to see where your project goes.

[RNCTX]

That may be a possibility too! I'll send you an email with more specifics of what they (+me) have got in mind.

[ericblade]

Moving to Discussion, as we don't really have anything to implement from this discussion at the moment