Skip QR Code version check for higher recall?

[duanqn]

Hi, I noticed that we perform a version check for QR Code model 2. link

This caused some recognition failures on some low quality QR code images. I found that those QR codes can be recognized successfully if we skip the check here.

Is there any side effects if we skip the version check? Should we consider removing this check or let the user choose whether to enable it?

[axxel]

Can you post an example of such a QRCode? The line you pointed to is a function definition, not a check. Can you point to the specific if() statement that you had to disable to make it work for you?

[duanqn]

@axxel This is the QR code I'm talking about:

When I use ZXingReader (latest commit 5214892) to read it, I get a FormatError because of invalid QR code version.
However, if I change this line to

    case Type::Model2: return Version::Model2(number);

then the QR code can be read successfully. In this ReadVersion function, we already have a way to get the version of a QR code, but it also performs a check when such version info is present in the code (i.e. QR code model 2 with version >= 7).

[duanqn]

By the way, I noticed that the QR code sample I provided has very uneven row/column widths. Some rows/columns have 2x to 3x the widths of others. Needless to say, this is nowhere near a standard QR code and such width variance will cause difficulties for recognition. Do you know what could cause this kind of noise? I have seen a few QR codes with this kind of noise recently.

[Sec-ant]

This distortion looks like the result of a naive downsampling / nearest neighbor zoom out of the original image.

[axxel]

@duanqn Thanks for the information. It is indeed questionable to read/check the version information at this point during the decoding. The version info has already been read during the detection part. In this particular case, it works there but then fails later due to a slight shift in the sampling points. I will simply remove the check.

@Sec-ant I agree with your analysis. This issue has also been discussed in #495.