Unable to read QR cord.

[TP-Nishiyama]

The JAVA version of ZXing can read, but the C++ version of ZXing cannot read.
The error message was "versionNumber must be between 1 and 40".
The QR cord made following cords in some site, but the result was the same.

• version=1
• level=M
• data=RFHJ5FJSDZCNSESGE2WU

Does anyone know the solution ?

[axxel]

TLDR: replace

zxing-cpp/core/src/zxing/qrcode/detector/FinderPatternFinder.cpp

Lines 288 to 289 in 07e5600

	return (int)(abs(firstConfirmedCenter->getX() - center->getX()) - abs(firstConfirmedCenter->getY()
	- center->getY()))/2;

with return 0;

I started working on this new c++ port by @huycn and expected it to work fine here, since it is based on the up-to-date Java code. Interestingly, it failed to decode the QR-code just like you described. I debugged the code and found the problem. What I don't understand is, how the Java version would work here, since the problematic section is exactly the same code (as far as I can tell).

The issue is that a wrong finder pattern is detected, leading to the wrong dimension estimate, leading the invalid version number. That happens because the findRowSkip method, which is supposed to skip a few lines for detection speedup after two finder patterns have been found, results in a smaller count (here 2) for the two upper finder patterns compared to a wrongly detected pattern left of the image center (gets count 5). If the findRowSkip gets disabled (see above) the two upper patterns get a count of 12 which leads to the wrong one being removed instead of the correct upper-right one.

So no idea how the Java version deals with this but in my opinion, the findRowSkiprelated code is buggy (in upstream Java and both c++ ports).

[TP-Nishiyama]

Sorry about my late reply.

I intended to check the version data between JAVA version and C++ version.
But at first I check the logic searching finder patterns.

Thank you for an important information.

[axxel]

@huycn did have a look at how the JAVA version was able to detect the code and it turned out that you need to set the tryRotate flag. Then both upstream and his port successfully detect it. That fits with my above analysis, because then the 'wrong' pattern gets skipped at the same time as the two good ones are. I bet there is a good chance the C++ code in here behaves the same way if you set that flag. I'd still argue that the way this findRowSkip is used/implemented has room for improvement :).