3 ms·

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. printi

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.

londons_explore 3y ago
This is actually "cameras can't focus close, and QR scanners aren't good at seeing a code which is tiny in the frame". By making the pixels of the code bigger, the camera can be a bit blurry to get the code big enough, and then it'll read.
- deleted 3y ago
  [deleted]
- Retr0id 3y ago
  I mean, that's kinda the whole point? The precise details of the optic path don't really matter, bigger pixels will always be easier to resolve. One might reasonably expect error correction to help with the decode of blurry inputs, but that wasn't really the case in my experiments.
  - londons_explore 3y ago
    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. I think people are working on both as we speak.
    - deleted 3y ago
      [deleted]
    - Retr0id 3y ago
      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)
      - subtra3t 3y ago
        Why? Is this something that's a side effect of some irrefutable physics law or a limitation of the current technology?
        Retr0id 3y ago
        Both. You can't have a measurable feature smaller than the Planck length, but that's not relevant to QR decoding in any practical sense. As for the practical limits, try using your phone to take a picture of something very far away, or very tiny, and see what happens.
      - londons_explore 3y ago
        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...
komlan 3y ago
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. [1] https://workspace.google.com/marketplace/app/qr_code_pass_for_attendance/1028329904752 https://workspace.google.com/marketplace/app/qr_code_pass_fo... [2] https://share.darkaa.com/!qntvtzNPWJ https://share.darkaa.com/!qntvtzNPWJ [3] https://admin.trak.codes/ https://admin.trak.codes/
- lifthrasiir 3y ago
  You can also use base45 [1]: -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. [1] https://datatracker.ietf.org/doc/html/rfc9285 https://datatracker.ietf.org/doc/html/rfc9285
  - komlan 3y ago
    That's neat, especially for arbitrary binary data!

londons_explore 3y ago

This is actually "cameras can't focus close, and QR scanners aren't good at seeing a code which is tiny in the frame". By making the pixels of the code bigger, the camera can be a bit blurry to get the code big enough, and then it'll read.

deleted 3y ago
[deleted]
Retr0id 3y ago
I mean, that's kinda the whole point? The precise details of the optic path don't really matter, bigger pixels will always be easier to resolve. One might reasonably expect error correction to help with the decode of blurry inputs, but that wasn't really the case in my experiments.
- londons_explore 3y ago
  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. I think people are working on both as we speak.
  - deleted 3y ago
    [deleted]
  - Retr0id 3y ago
    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)
    - subtra3t 3y ago
      Why? Is this something that's a side effect of some irrefutable physics law or a limitation of the current technology?
      - Retr0id 3y ago
        Both. You can't have a measurable feature smaller than the Planck length, but that's not relevant to QR decoding in any practical sense. As for the practical limits, try using your phone to take a picture of something very far away, or very tiny, and see what happens.
    - londons_explore 3y ago
      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...

komlan 3y ago

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. [1] https://workspace.google.com/marketplace/app/qr_code_pass_for_attendance/1028329904752 https://workspace.google.com/marketplace/app/qr_code_pass_fo... [2] https://share.darkaa.com/!qntvtzNPWJ https://share.darkaa.com/!qntvtzNPWJ [3] https://admin.trak.codes/ https://admin.trak.codes/

lifthrasiir 3y ago
You can also use base45 [1]: -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. [1] https://datatracker.ietf.org/doc/html/rfc9285 https://datatracker.ietf.org/doc/html/rfc9285
- komlan 3y ago
  That's neat, especially for arbitrary binary data!