I tried reading them manually about ten years ago, but gave up because of the mask. The mask pattern needs to be applied (xor) before you can even tell as much as the data type...
Does anyone know how much it actually helps QR code readers to have this mask pattern applied?
Last month, I tried to find out what the optimal error correction setting is (answer: none, if the matrix isn't damaged, like in my use-case where it's shown on a screen), which wasn't easy to find. I didn't find anyone who actually went out into the real world and tried out different settings and different scanning implementations to see what the effect is of choosing a good mask or choosing a good error correction value. In the end, a theoretical answer was enough for my application because I can assume the QRs to be pristine, but in a perfect world we also wouldn't need a mask setting. I then tried to do some research of my own by reading a small QR off my screen with different error correction levels and an intentionally shaking camera to simulate read issues when someone points a smartphone, but found no significant difference between any of the settings. With there being at least four alignment markers, a huge quiet area, and a "timing pattern", does it really matter if there are white blobs due to not having a mask?
(The secondary reason why I gave up trying to read QRs visually is because I noticed they always have the URL written below as fallback anyway. Since then, I did see a few times where there was no fallback, but it's very rare)
The error correction is funny. If you don't use it, your message takes up less space, and the QR is smaller. If you have a fixed space to fit it in (e.g. printing to a sticker), that means your pixels can be physically bigger. For reliable reading, I found that physically bigger pixels helped more than the error correction itself.
Depending on the length of your message, sometimes you can turn up the error correction level without impacting the final QR dimensions, and in those cases it's a win/win.
The 'proper' fix is to either engineer cameras that can focus closer, or to engineer barcode scanning apps to be able to see a code which is small somewhere in the frame.
It doesn't matter how objectively good your camera/decoder is, in absolute terms. There will always be some minimum size or maximum distance, where the detail can no longer be resolved (or errors no longer corrected)
If we're talking theory, the pixel size doesn't matter - it's the amount of information encoded in the QR code that matters (ie. excluding ECC bits!). In turn, that means it is theoretically possible to decode a QR code where each 'pixel' of the code is smaller than the pixel of the camera sensor observing the code.
While it is theoretically possible, nobody has yet done so...
Physically bigger pixels help a lot indeed. The encoding mode also helps make pixels bigger.
This is very convenient when you control the QR reader and need to represent long numeric identifiers like UUIDs.
For example:
9728983f-7d7d-4189-b624-f92781e36650 (lowercase UUID):
=> length=36, 15 pixels between markers
JWM9GFVXFN0RKDH4Z4KR3RV6A0 (base32 UUID):
=> length=26, 11 pixels between markers
9728983F-7D7D-4189-B624-F92781E36650 (uppercase UUID):
=> length=36, 11 pixels between markers
200924207194334734815443970355691218512 (decimal UUID):
=> length=39, 7 pixels between markers
The uppercase UUID has bigger pixels because it used a different encoding, and gets the same results as the shorter base32 uuid.
The decimal UUID is a longer string, but results in much bigger pixels because it can use numeric encoding.
I have a QR code base attendance tracker [1], where attendees show the code [2] on their phones (glares, etc.), in bad lighting conditions, etc. Bigger pixels means scanning stays quick. Same with parcel tracking [3] where field agents might need to scan QR codes in barely-lit hallways, etc.
-4J5BJ+%F$C881NIMV-IG2.C (base45, 132 bits in QR)
JWM9GFVXFN0RKDH4Z4KR3RV6A0 (base32, 143 bits in QR)
200924207194334734815443970355691218512 (decimal, 130 bits in QR)
It will make use of all allowed characters in the alphanumeric mode, while being significantly shorter than base32 and as dense as decimal. And decimal encoding in general needs bignum, because there is no suitable 10^k which is only slightly larger than powers of two so no convenient binary-to-decimal encoding exists (conversely, QR code itself does make use of the fact 2^10 is only slightly larger than 10^3 for this mode). Base45 always works on three-byte groups and maintains the similar efficiency in comparison.
The error correction isn't meant for folks like us who think about things like "how can I make this message smaller to increase the readability of the QR code", it's for the people that take their entire tracking parameter-infected URL and dump it into a version 25 (117x117) code and plaster it onto a huge sign out front where a bird promptly shits on it and a teenager slaps a sticker on it and somehow the data remains.
I also have the impression that a common use of error correction is the "QR Code with a logo in the middle" style. With an appropriate level of error correction, you can carve an empty patch in the middle of the logo and slap a logo/icon there, and the QR code remains readable.
At least this is the way I did it years ago when I thought it would be fancy to have my contact data as a QR Code on my visit card.
Last year I did some experimentation along these lines and I also found that no error correction was best, at least when 3d printing QR codes. I was trying to find how small I could print it and still have it be detectable. Like the sibling comment, I suspect it is because of individually larger pixels.
The problem with that, as I understand it, is that your 3d print (or any print or screen) cannot get damaged at all. The pixels being bigger makes it easier to scan ...when it's fully in view and fully intact. Any pixel fails, and you can never recover the original data (besides some guesses, e.g. if the protocol identifier gets damaged a la htwps://)
Error correction doesn't seem to be for easier scanning, but for errors that might occur
(... and stupid logo overlays)
but this information is annoyingly hard to find. Hence my question about the mask xor overlay: does that actually help? Did anyone try it, or did it just sound like a good idea?
the idea that a single pixel of the design would get damaged absent the rest seems unlikely. What seems to be more common is that a direction of light/some flaw in the printing process causes many/all pixels to be flawed in the same way past some threshold.
Does anyone know how much it actually helps QR code readers to have this mask pattern applied?
Last month, I tried to find out what the optimal error correction setting is (answer: none, if the matrix isn't damaged, like in my use-case where it's shown on a screen), which wasn't easy to find. I didn't find anyone who actually went out into the real world and tried out different settings and different scanning implementations to see what the effect is of choosing a good mask or choosing a good error correction value. In the end, a theoretical answer was enough for my application because I can assume the QRs to be pristine, but in a perfect world we also wouldn't need a mask setting. I then tried to do some research of my own by reading a small QR off my screen with different error correction levels and an intentionally shaking camera to simulate read issues when someone points a smartphone, but found no significant difference between any of the settings. With there being at least four alignment markers, a huge quiet area, and a "timing pattern", does it really matter if there are white blobs due to not having a mask?
(The secondary reason why I gave up trying to read QRs visually is because I noticed they always have the URL written below as fallback anyway. Since then, I did see a few times where there was no fallback, but it's very rare)