Datamatrix detection is sensitive to symbol position

[urishab]

I have a simple and clear datamatrix that fails to be read by the library:
The image is 200x200 pixels:

When studying the problem it seems the library is very sensitive to the size of the image.

Simply cropping 15 pixels from the bottom of the image (so it's 200x185 pixels) allows the library to detect the DM:

Also extending the image from the top by 15 pixels allows detection (now it's 200x215 pixels)

In all cases the DM is located on the right side of the image.

What is the reason for this and is there a way to fix these problems without cropping images in many ways to successfully detect the DM?

[axxel]

The problem is that it currently only detects the symbol if it is intersected by either the horizontal or vertical center line of the image. If you can compile the library, you can fix that yourself as mentioned in #146. Simply comment out this line and it will work (but be considerably slower).

[urishab]

First here's an example where I crop the image in X and it still fails to detect even though I'm sure the vertical line is going through the DM:

After I additionally crop it in Y so it's more centered in Y then it detects it correctly:

So I'm not sure about your explanation. Maybe it works with the horizontal line but not with the vertical one.

[urishab]

Second, I saw your fix for #146 but unfortunately I cannot try it.
I'm using zxing-cpp with the Python wrapper and release 1.1.1.
When I update the code to the latest branch I can't get it to compile anymore.
Should I open a new issue for that or is it still work in progress?

I will try to update only the relevant DMDetector and see if it works on its own.

[axxel]

I'll try to reproduce your findings that do in fact contradict my earlier claim. As for the Python wrapper: that should definitively work (and gets tested by the CI). If you have an issue, please open another issue.

[axxel]

I checked your sample and can confirm your finding. It is indeed not sufficient for the symbol to be intersecting with any of the center lines, it is the vertical/left line of the 'L'-shaped finder pattern that needs to intersect with a center line. In your first counter example only the horizontal/bottom line does this.

[urishab]

Ok thanks. That's useful information.
It means I should be able to run multiple windows over my image that are all wide but not tall and should be able to find any DM that is not rotated in the image.

I've opened a new issue #190 for the problem I'm having compiling the latest code.

[axxel]

But if you can now compile the latest version, that should be easier and also more efficient than your suggested approach. Sooner or later, I'll have to decide on whether the currently implemented (but disabled because it is slow) approach is a cost that has to be payed...

Interestingly, I recently came across the fact that the Google MLKit for android, that does all sorts of barcode detection, has indeed the same limitation for DataMatrix symbols. That tells me that even they don't have a magic AI wand to quickly detect DM symbols anywhere in the image.

[urishab]

I did manage to compile the latest version after commenting out the tryharder=False line. Now I'm getting readout of the DM with all those cases.
IMO there has to be a hint from the user saying whether to search the whole image or just the center of the image.
Generally though, submitting a whole image to the read_barcode function should search the whole image, otherwise I would have submitted just a crop of the image.
Alternatively it would make sense to have a ROI hint of where to search for images.

I recently came across this very high end barcode scanner and this has tons of hints for the algorithm (the process of defining the hints is called 'tuning'). Which codes to search, which orientation, where to search (different for each code type), maximum number of codes to detect, invert code and many others. This makes sense because there are a lot of assumptions when reading barcodes and these assumptions should both help the reading process, speed it up and be configurable in the form of 'hints'.

[axxel]

Sort of fixed here: d6dc409 (needs c++-20).

[axxel]

This is as fixed as it gets... -> closing.