Who wants to pay for Serratus continue with this project?

[dictosistemas]

Who would be willing to pay (in BTC) for Serratus to develop this project again?

It would be interesting if he resumed the project and added the parallel processing of the new Chrome API below:

https://web.dev/shape-detection/

@serratus what do you think in being payed to work again in QuaggaJs?

[ericblade]

Doesn't look like it'd be too hard to make a Shape Detection API reader, although it doesn't appear that it provides the full amount of information that is available in most of the decoders in Quagga. Difficulty level is increased, however, by that it apparently only works on Android or Mac chrome, and most devs use Windows or Linux... and it can be quite annoying to develop against an Android device. It's not impossible, but it's timeconsuming.

[dictosistemas]

My idea would be to embed this new API in parallel with the current QuaggaJs processing.
For example, firing a worker with each logic and the one that responds the fastest returns the result.
Of course, if this API is available in the browser's user.

[ericblade]

I think that depending on Workers, as they were constructed in the existing Quagga, isn't really a good idea -- in my fork, I've actually eliminated use of workers, and seen substantial benefit -- I believe the existing worker structure put a quite substantial load on each worker, by spawning a complete copy of the entire library in each thread, and all of them appear to be duplicating each other's work. Forcing numOfWorkers to 0 has shown significant gains in detection speed on my app that uses Quagga.

That said, I've been working on slowly rearchitecting pieces to be much more reusable, and I believe that with the fork that I have, or something very similar to it, it should be possible to create a wrapper that can better distribute work to multiple workers -- ie, have one copy working on each reader. That would probably show better results than the present way. Ultimately, if I were to re-implement the worker part inside the lib, I would probably want to try out having one thread that runs barcode detetction/location, and multiple workers that each have just a single reader running inside them. As I separate the pieces of Quagga to make them standalone units, that becomes more likely to happen in the future. What I'm really stuck on, oddly, is trying to figure out a way with modern tooling, to ship workers inside a browser, without shipping multiple JS files. Blobbing doesn't seem to be well supported by the current tooling system.