Code39 Decoding does not always work

[OphiCA]

Consider the following images:

1)

2)

3)

1 works without issues, but 2 and 3 do not. I'm guessing the decoder is unable to cope with the additional image details surrounding the barcode. Is that something that can be fixed in the algorithm or is there a recommended work around?

[EddieLa]

Well yes this will happen, it's actually not so certain that it's the fault of the search algorithm that locates the barcode. The decoding algorithm for code 39 however is a bit crappy, I actually think that's the cause since I tested it with a new search algorithm I've been working on. Didn't work there either so the probable cause us the actual decoding algorithm which means as of this date there is no workaround

[OphiCA]

Hmmm, well, I think a potential workaround would be to try and preprocess the captured image and try to cut away the surrounding area using a "targeting helper" of sorts. I haven't quite thought it through yet...

Oh, one other thing. The demo page isn't working in Chrome. The URL created by createObjectURL() 404s and so it fails. In my tests I just removed it altogether and fell right into FileReader().

[EddieLa]

Weird about chrome I use chrome and have had no problems, what version is it? As for the targeting helper idea that is actually something that is done in the image processing part of the code and is already implemented. It could however be better as I said but I'm still leaning towards the decoding algorithm.

Code 39 is difficult to decode because this code was originally written to only decode code 128 which is a lot less prone to false positives. So the decoding is done by trying a large amount of variation of the binary thresholds on the areas picked out from the image. This while working great for code 128 works less great for code 39.

I don't know how much of the code you've read so don't take it as a lecture, just trying to explain my reasoning.

[OphiCA]

I've only glanced at the code and my understanding of it is very near non-existent, so no worries.

I'm using Chrome 38.0.2125.104.

As far as my idea for the targeting, I mean something more along the lines of how RedLaser has the "targeting reticle" when "scanning". This way, anything outside of the boundaries of the reticle can be cropped to reduce the image data being parsed by the decoder. Perhaps that may give it a helping hand in finding and decoding the bar code easier? At the very least it may help in performance by not having to parse a higher resolution image, especially on a mobile device.

In the application I'm developing I'd like to use the scanner to track inventory our employees use either iPhone or iPads so the image resolution is high with most of it being pointless as far as the decoder would be concerned.

[EddieLa]

Interesting, I'm using version 37 so I guess they changed something.

As for the targeting idea it would probably help in decoding, I actually wanted to that when I first developed this as a demonstration project but I dismissed it. The reason why is because I originally wanted to use a getUserMedia implementation with a video feed but since it wasn't supported by most mobile browsers I had to settle for decoding just one image. So yeah an implementation with targeting would most likely help.

One interesting side note is that the decoding usually works better on lower quality images than on high resolution ones. Don't really know why but I suspect it may have something to with the fact that most digital cameras apply a bunch of sharpening filters to enhance the images, might mess up the dimensions of the barcode.