What Quagga may look like in the Future

[ericblade]

While I've been doing this massive undertaking of both modernizing all of Quagga's dependencies, and reworking much of it into TypeScript, I've had a lot of ideas about some ways to re-organize things behind the scenes, and I'd like to express how I'd like to perhaps structure this lib in the future.

One of the things that has been a bit of a thorny problem, is how tightly integrated all the pieces are -- there's a lot of clear places where there could be completely separate, compact modules involved, but right now, the entire thing is quite tightly integrated. There's the basic barcode decoding pieces, the barcode locating pieces, code that is different in node vs browser, on top of that is a layer that handles obtaining images from various sources, including image files and from a browser camera. There are people who's applications use the camera capability, but never use the locator, or people who depend on the locator capability, but never use it in a browser, or with the camera. There's a lot of different pieces that are all included in a giant bundle. That's not even accounting for the dozen or so different readers, when most people only need 1 for most of their purposes.

And on top of that, nothing addresses the potential elephant in the room that is the former multi-threaded WebWorker code. In the versions of Quagga prior to forking, and shortly after forking this repo, as well as in code still hanging out but unused, there was support for using WebWorkers to multi-thread location/decoding. A big problem with that fairly sizeable chunk of code, was that it depended on sending the entire library to every thread, and running the entire library code on each thread, exactly like it was running on the main thread. Disabling the entire multi-threading capability was key to several enhancements and fixes that have been implemented in the current version in this repo, and further de-coupling of the individual pieces and parts can lead to an implementation that significantly improves upon the former multithreaded implementation.

So, the proposal that I'm working up here, is an attempt to build out a more modular quagga, that retains all of it's original functionality, but allows you to only import the pieces that you need. Ultimately, there would be a "front-end" module that would supply an interface kind of similar to what we have right now, at least, it might be recognizeable as derived from the current interface :-)

I'm imagining a possible use-case of being something like

import Quagga from 'quagga'; // the front-end
import quaggaDecoderUPC from 'quagga-decoder-upc'; // the decoder
import quaggaLocator from 'quagga-locator'; // the locator
import quaggaCameraSource from 'quagga-source-usermedia'; // provider of images


const quagga = await Quagga.init({
    source: quaggaCameraSource,
    locator: quaggaLocator,
    decoders: quaggaDecoderUPC,
    worker: (...somehow define code to ship to a WebWorker, or some thread lib that is compatible with both Node and Browser threads...),
    numWorkers: 4
});

quagga.on('detected', (codes) => { .... });

Modules:

1- quagga-core -- a module which containers just the basic decoder functionality. Most/all of the existing barcode decoders would extend the Decoder that this exports, as most of the decoders internal to Quagga right now extend BarcodeDecoder.

2- quagga-decoder-* -- modules for each of the types of barcodes that Quagga currently can decode. Each decoder, if passed an image that contains a complete barcode, and very little else, should be able to return the barcode data.

3- quagga-locator -- Frankly, Quagga's best feature -- the barcode locator. This would be a separate module, that would I think if given an input image, it would return an image that contains just the barcode as much as possible, in a way that is readable by the decoders. There could be a separate decoder that would be analogous to the current "locator: false, area: { ... }" methods. There could also be a separate decoder that detects entirely different types of codes, such as "3d" barcodes, or QR codes.

4- quagga-source-* -- modules for various ways of obtaining images. Obvious would be the existing source types -- LiveStream, ImageStream, VideoStream. These would emit image data, which would then be intended for consumption by the locator (if provided), then the decoder.

... i think that is a pretty accurate description of what i'm thinking of, and it would allow several things that i think would greatly improve on the structure, as well as allow users to ship much less complex libs into their apps. Not only that, but it would allow for a lot more extensibility. One of my goals for adding external reader functionality into Quagga in the first place, was to allow for non-2D-barcode like items -- it's my goal to be able to use a relatively simple interface, to not only scan barcodes, but also pick up numbers and words via text recognition.

... this is getting really long, i'll pick up more later

[oppsDayly]

Hello, your plan is excellent. However, I have a project where I need to identify all barcodes on an image. I plan to use OpenCV.js to locate the barcodes and then use Quagga for decoding. Is this feasible? Can Quagga directly accomplish this?

[ericblade]

Hello, your plan is excellent. However, I have a project where I need to identify all barcodes on an image. I plan to use OpenCV.js to locate the barcodes and then use Quagga for decoding. Is this feasible? Can Quagga directly accomplish this?

You can set "multiple" to true in your Quagga configuration and it should return several different barcodes.

Internally, the locator uses things that closely resemble some OpenCV operations, and may possibly have been sourced from OpenCV. I don't really understand how much of that works, but I have done some reorganization in that area.