Prioritize reader types

[danikaze]

I enabled all readers:

decoder: {
  readers: [
    'code_128_reader',
    'ean_reader',
    'ean_8_reader',
    'code_39_reader',
    'code_39_vin_reader',
    'codabar_reader',
    'upc_reader',
    'upc_e_reader',
    'i2of5_reader',
    '2of5_reader',
    'code_93_reader',
  ],
},

and tried decoding an image with 4 901777 300446. It detected 02017273 which is upc_e type.

If I disable the upc_* readers, then it detects the code properly as ean_13.

It would be nice to specify an order (or more properly, to follow the specified order of the readers array) so, if a type of barcode is found, don't use the following one.

This could be useful, if we know the scope of the application (and which kind of barcodes will be used), to reduce the number of false positives.

[ericblade]

Yep, enabling too many readers does cause definite problems. I don't know right off hand what would cause it to not follow the order of the array, especially with worker threads explicitly disabled. Something I can look into, though.

[danikaze]

Having parallel calculation will actually make things harder, if we want an order... but a way could be to calculate everything in parallel, and when everything is done, then apply the order and search for the first found. This would be an easy way to apply priorities... (with the side effect of having to wait for everything to be calculated vs stop at the first one -- maybe a flag in the configuration to do this?)

[ericblade]

I think before workers were disabled, whichever one responded first with a positive identification would cause the trigger. However, one of the big problems that I noted with Workers, is that it was shipping the entire library to each worker thread, and they were all working on the exact same problem in the same way, which seemed completely useless, and really just slowed down the process with little to no benefit. Since disabling that, my EAN and UPC scanner has improved drastically in speed, although that speed has come with a downside -- i get a ton of false readings when my phone camera's auto-focus is adjusting.

Most of that's an aside to the problem though -- when just working on a single thread, what is the order that it goes through the readers? I don't know the answer to that, and I suspect it'll take a little bit of time to trace it out. It definitely should be predictable, and sensible.

[ericblade]

I think first step of investigation should be to do something along the lines of logging the readers list passed in, and then logging from each reader's decode functions, which one is being triggered, and see if that order is consistent with each other.

If it is, then there's not really much of anything to do here (unless this would also be a feature request to add a way to prioritize them, outside of the order passed in). If it is not in a consistent order, then we should make it that way.

I think I might ultimately just consider dropping multi-threading as an idea completely -- with the ability to load multiple instances, it should be theoretically possible to write a wrapper around Quagga that handles pushing a differently configured instance with the same incoming data, to several worker threads. It feels like it's a problem that should be tackled outside of the library, now.