Added test cases containing a large in-the-wild image, and two rotated versions

[jjhbw]

One of the rotated versions fails (test_wild_rotated_1), likely because the QR code is too tilted.

We don't have to retain the other two tests, as these cases are pretty much already covered.

In debug-images mode, i found that test_wild_rotated_1 gives the following candidates.png:

My naive analysis would be that the top-right finder is a false positive.

[jjhbw]

Slightly decreasing the accepted variance of the finder pattern seemed to at least make the detection work, but now decoding fails. The error correction seems to have trouble, if i read the code correctly.

[piderman314]

Yeah you can see the debug image in the extract directory, it appears it can find the data quite accurately, but it's not 100% correct, causing it to have more errors than the correction can handle.

[piderman314]

Come to think of it, this also has to do with the fact that this is a version 1 QR Code which doesn't have an extra alignment pattern. Can you try this kind of rotation with a level 2+ QR Code?

[jjhbw]

Ah yeah i saw that second image too. It seems to miss a few of the black squares (duh ;)).
What would testing a v2 tell us? Or are v1 QR codes out of scope?

[piderman314]

A v2 (and up) code has an extra special square in the bottom right corner that helps adjusting the angle a bit better. In the end, we have to estimate the angle and skew of the image based on discrete data (pixels). This is always going to be wrong to a certain degree, resulting in missed squares.

I'm not sure it's possible to get the estimation any better for a v1 image that has been rotated quite this much.

I'm just curious if a v2 code that has been rotated in the same way would fare better because of the extra alignment pattern. (See the version3_example test case for an example that has that pattern in the bottom right).