Feature alternative data matrix detector on develop

[NilsEngelbach]

So i finished porting the alternative Data Matrix Detector from the zxing-cpp project (https://github.com/nu-book/zxing-cpp/blob/2ceda95cba943b3b2ab30af3c90150c97e84d416/core/src/datamatrix/DMDetector.cpp#L442-L1072).

The decoding results are quite similar to the old one:

	Old detector	New detector
datamatrix-1	Decoded 168 images out of 168	Decoded 166 images out of 168
datamatrix-2	Decoded 120 images out of 144	Decoded 122 images out of 144
	Total 188	Total 188

I will debug the 2 not detected codes from datamatrix-1 folder as soon as i find some time.
And i wanted to also do some real benchmarking, because the speed should also be considered. (Maybe this could be added to the tests in a generic way?)

I did not replace the old implementation, i would propose to use the new implementation as second detector when tryHarder is enabled and the first detector does not find a code. What are you toughts about this?

My plan is to adjust the Detector so it can be used to detect DataMatrix Codes with Dots instead of squares also called DPM Codes (https://en.wikipedia.org/wiki/Direct_part_marking).

Some questions i had along the way:

Debugging & testing

I modified the launch.json to use ts-mocha. This was working quite well expect the paths filter does not seem to work this way:

    {
      "type": "node",
      "request": "launch",
      "name": "Data Matrix Tests",
      "runtimeExecutable": "${workspaceFolder}/node_modules/.bin/ts-mocha",
      "args": [
        "-p",
        "tsconfig.test.json",
        "--paths",
        "./src/test/core/datamatrix/**/*.spec.ts"
      ]
    },

Therfore i also had to use describe.only(...) in the data matrix spec, to run only the datamatrix tests:

describe.only('DataMatrixBlackBox.1', () => {
  it('testBlackBox', async () => {
    const test = new DataMatrixBlackBox1Spec();
    await test.testBlackBox();
  });
});

I saw @odahcam posted an alternative setting 2 days ago with mocha but i could not get it to work properly.

I think it would also be helpful to specify a certain test file with rotation (e.g. 04.jpg at 90°), because the quick fix i did so far was removing all other files from the folder...

I was also wondering why only the test files in datamatrix-1 folder are included in the tests? Is there a reason for it?

Is there an prefered way to handle debugging code like logging? E.g. I added a function for myself to print the BitMatrix to a file (with + and . chars), so i could quickly double check the values while debugging in that file visually.

Common classes

I created a class called Point with some basic mathematical operations, i also saw that the Aztec Detector uses a quite similar class. Should every Detector have it's own implementations of such helper classes or would you prefer some common implementations?

Are there any other detectors and decoders you would like to get ported from other zxing implementations? I feel a bit motivated at the moment to contribute something useful :)

[odahcam]

That's a great contribution already. I just have to ask, is this the final version so we should review or do wanna make any changes before that? Also, about...

I did not replace the old implementation, i would propose to use the new implementation as second detector when tryHarder is enabled and the first detector does not find a code. What are you toughts about this?

Yeah, for we to integrate this in here faster a suggest adding this outside of the /core in a new ES module so we would have two DataMatrix readers and users would handle it's usage, but only for now. For the future we should introduce a new hint or something that tells weather to use or reader or the other or even both, but that's something we should further discuss. About the folder outside of the core module we don't have a name yet so ideas are very wel welcome.

Are there any other detectors and decoders you would like to get ported from other zxing implementations? I feel a bit motivated at the moment to contribute something useful :)

Literally anything here helps. You can choose from the PR or issues list or in the Projects tab something you'd like to work on. My personal preference would be to improve the PDF417 reader by finishing porting all it's tests and solve any issues while doing so. Meanwhile @Swiftwork is working on some readers to improve decoding efficiency, so that should be covered but he may like some help maybe.