Work on 2.0.0 underway - feedback, suggestions, help, etc, welcome!

[ericblade]

As I've had some time to sit down this holiday weekend and do some continuation work on some of the things started a couple of years ago when I forked this project, I've decided to go ahead and open a 2.0 branch. There will be breaking changes on this branch, starting with the first 3 commits, which remove the numOfWorkers parameter, and change the patchSize parameter to an enum type (it's likely this will change again, but it made more sense as an enum in the places where it's actually used in the code right now, than as a string that gets mapped to a number...).

The first thing I've done, is broken out cvutils.js into separate files -- as a single large module, it was very daunting to convert to typescript, in the earlier conversion process. As single modules, however, it is extremely easy to peel it down and streamline it. I am considering making it available as a separate module, as several of it's functions look like they might be useful to other sorts of image processing projects. I'm not especially well versed on the mathematics or the purpose of the mathematics involved, so if anyone who is versed in these things wants to write some documentation/comments on the files in src/common/cvutils, that'd be super handy!

Some of the refactorings that I've started to perform I actually expected to increase the amount of time it takes to complete some operations, in favor of making the code more readable. Much to my surprise, however, tests are running noticeably faster (probably around about 10-15% faster). I'm hoping that's not due to new bugs being introduced :D but all the tests that were already existing are passing exactly as they were before.

My overall intent is to restructure Quagga2 so that each stage of the image acquisition, location, decoding, and reading process are all clearly separated and are changeable/extendable. And I want as much automated testing as we can possibly get.

Conceptually, I want to break it down to where the process is easily understandable:

1- Acquire an image
2- Locate a barcode
3- Decode (i'm a little unclear myself on this process, but there is currently a separate process in Quagga between Location and Reading, called Decoding)
4- Read the barcode
5- Return the results

Step 1 would be covered by a "front end" module -- possibly a separate module for using a live camera or a file input. At the very least, Quagga should accept input as raw image data and/or dataURIs, and be able to pass that to...
Step 2 (optional) barcode_locator
Step 3 - decode (is this a necessary step? or is it part of the reading process?)
Step 4 - read

I also want to provide a system for providing different filters -- i'm not sure if this should go before the locate or after, or both? but when the entire process fails, there should be a way to pipe the image data through a filter and re-try it, As is, the current system has a very rudimentary implementation that I found, and it should be extended -- as users we can't do anything with it right now, but it does automatically try to flip an image 180deg if it fails to read in the manner it comes in. I want to be able to pass in a set of filters, so that we can rotate it, flip it, colorize it, decolorize it, invert it, etc, etc. Whatever needs to be done to improve a user's input into a way that it works better.

The location step as-is right now is already optional, but the filters would also be optional (although flipping would probably become a 'default' filter). I also want users to be able to extend the Locator function, and hopefully we can incrementally improve on that, moreso than just improving the input data.