The most common failure case I see for broken QR codes is it scans fine but it was created using some commercial link-bouncer service and they stopped paying the subscription fees so the redirect is dead.
This infuriates me. You are using a QR exactly to easily share a (long) link, why the hell you need to use a link shortener? Why is the market for small shops, restaurants, bars, small museums, small towns etc so riddled with technically incompetent people?
> easily share a (long) link, why the hell you need to use a link shortener?
Because it makes the QR code simpler (less "pixels") and therefore more robust. Given the same physical size, scratches affect it less, and a phone can read it from further away. You want to avoid long links in QR codes whenever possible.
The other thing is analytics, of course. You can generate 10 different small QR codes that lead to the same long URL, to find out where they're getting scanned, so you know which locations are popular and worthwhile and which ones are not.
And maybe don't criticize restaurant owners for being technically incompetent? I'm sure they would find you just as incompetent at cooking at scale.
Sometimes, because the service sneakily shortens the link. I wanted to share a WIP whitelabel ticket sales platform ( https://pentas.id ) with a friend. I didn't have time to build the logic to generate QR code, so I just googled "online QR generator". I pasted my link, a QR code was generated. When I tried it using Pixel's Camera app, the preview is NOT my link. Although when I tap it, it eventually goes to my link.
Being able to change the destination URL is one reason to use a redirect. Many users do not control their tech infrastructure, or have the knowledge to create redirects. This allows them to update or change content without changing their QR codes.
because they want the analytics the eg bit.ly packages up nicely for them. The software that's missing (though tbh, I Haven looked) is the let's encrypt certbot for doing your own analytics that a link shortener would get you.
Related, https://qris.cool/ was posted here a few weeks ago and it's a really neat way to interactively explore the code itself, and see what any given pixel does.
There is a tool called qrazy box
https://merri.cx/qrazybox/
It allows you to essentially remake a damaged or partially hidden QR code pixel by pixel, but has some limitations.
A software tool should exist to repair QR codes. People could really benefit from it because QR codes are used everywhere.
I'd like to find a way to repair QR codes through software. However, that begins with collecting a bunch of broken and corrupted QR codes people stumble across and fixing them up by hand. This will help spot patterns in how they fail. So please help out by submitting your QR code that doesn't scan. Please don't create QR codes that don't scan just to submit them. Thank you! In the past I have fixed one QR code by hand and it is shown at the link.
> A software tool should exist to repair QR codes.
Seems that the solution is to add more redundancy (and stop covering the center pixels with an icon). The codes are designed to be self-correcting if the damage is slight enough or more redundancy is added.
The bulk of the QR code is about specifying, quite exhaustively, multiple means of error prevention, detection , and correction.
I guess some applications don’t use these features effectively, but compliant QR codes are really quite hard to corrupt.
> People could really benefit from it because QR codes are used everywhere.
I hear you, and at the same time we're solving the wrong end of that pipeline, in my opinion. Almost every QR code I have ever seen in my life either points to bit.ly or some other link-shortener or marketing tracker domain which I would put good money will be dead way before the QR code's ink deteriorates
I don't mean that QR is a terrible standard, but at least until we can get URL forms that are on the whole less than 128 characters, I wish they had met the world where it is. I believe the http2 compression scheme comes with dedicated dictionary slots for header strings that they know are going to appear, so QR would have benefited from the same (e.g. http/https taking less than 4/5 bytes, :// less than 3)
Then again, having thought further about this, I guess Marketing's Razor is the most likely explanation: it wasn't a technical reason they're using bit.ly, it's for those sweet engagement metrics
I imagine that a really useful piece of information is where the QR code was spotted. So that means treating the photo of the QR code and its exif data as part of the puzzle. No doubt some URLs are more common in some parts of the world than others in a kind of ode to geoguessing games.
QR codes already have built-in Reed-Solomon error correction at different levels (L:7%, M:15%, Q:25%, H:30%), which is why they can often be read despite partial damage or obstruction.
Reading the QR code spec (or even just the wikipedia page) could help a lot here. A lot of the room on the code is taken up by metadata, rather than output-data. The output data is repeated lots of times across the code (this is why you can have a brand logo right in the middle of the code).
Repairing the metadata parts & iterating over each of the version number should make the overwhelming majority of broken QR codes usable again.
A QR code dedicates around 30% to metadata (positioning, timing data, version numbers). There are very few metadata arrangements shared across all QR codes, so you can recover 30% of the code with almost no computation.
The other 70% is dedicated to "data", on which the Reed-Solomon-coding is applied. If your QR code is absolutely stuffed to its limit (about 2kb data), you can still destroy up to 51% of the image before the Reed-Solomon coding will start to fail at 30% redundancy.
Most codes only store a few hundred bytes of data, so you can afford to destroy a lot more before the payload is also destroyed.
I'd expect the minimal-viable QR code for a 100 character URI can be very degraded.
Qr codes have some redundancy but nowhere near "repeated lots of time". Not even twice. More realistically there is 5-30% of redundancy and some very clever math to allow any individual part of data (not neceserily any part of qr code)to be damaged up to certain percentage.
> Reading the QR code spec (or even just the wikipedia page) could help a lot here.
Comprehending what you read could help a lot, too.
The output data generally isn't repeated even a single time in full, let alone "lots of times". That's what error correction keys are for.
The fact that you can stick a logo in the middle doesn't have much to do with anything. I can (and many publishers have!) put a bunch of color pictures in the middle of a book, it doesn't mean the data in the book is repeated.
I'm less interested in the theory and am more interested in the practice. I own a printed copy of the 2015 version of the spec, but don't find the insights I get from it have much to do with its ability to scan as compared to taking my phone out and scanning a QR code does.
In practice, I mostly I find that the corners are the most finicky part. However, that is just my current opinion.
I think if the corners really are more sensitive, it’s because the reader can’t find the QR code and it’s orientation, not because the data is not recoverable. If you would manually enter the pixels into a decoder, the corners shouldn’t be more sensitive than other spaces of the code, I think.
it was extremely fun organizing that QR Show. it's actually very fun organizing events/jams in general (I'm also thinking of https://wambamjam.recurse.com/ ) -- you put out an invite, get it to interesting people, and then step back. (and, like, get snacks).
that QR Show was truly a success because of people like you who brought original works -- a lot of these pieces were made in the last weeks! and days! leading to it. it was just astonishing to see.
I've shared with some friends that I'd be afraid to repeat that show because it went so well (like - should there be a yearly? qr show??). I'm still mulling this over.
Readit News
Because it makes the QR code simpler (less "pixels") and therefore more robust. Given the same physical size, scratches affect it less, and a phone can read it from further away. You want to avoid long links in QR codes whenever possible.
The other thing is analytics, of course. You can generate 10 different small QR codes that lead to the same long URL, to find out where they're getting scanned, so you know which locations are popular and worthwhile and which ones are not.
And maybe don't criticize restaurant owners for being technically incompetent? I'm sure they would find you just as incompetent at cooking at scale.
Interestingly enough, printed QR codes physically degrading as described in the article is actual bit rot, albeit a form often overlooked.
[1] - https://en.wikipedia.org/wiki/Link_rot
Basically, we put data into QR codes the same as hard drives. Why then are there so few data recovery tools for QR codes?
I'd like to find a way to repair QR codes through software. However, that begins with collecting a bunch of broken and corrupted QR codes people stumble across and fixing them up by hand. This will help spot patterns in how they fail. So please help out by submitting your QR code that doesn't scan. Please don't create QR codes that don't scan just to submit them. Thank you! In the past I have fixed one QR code by hand and it is shown at the link.
Seems that the solution is to add more redundancy (and stop covering the center pixels with an icon). The codes are designed to be self-correcting if the damage is slight enough or more redundancy is added.
I hear you, and at the same time we're solving the wrong end of that pipeline, in my opinion. Almost every QR code I have ever seen in my life either points to bit.ly or some other link-shortener or marketing tracker domain which I would put good money will be dead way before the QR code's ink deteriorates
I don't mean that QR is a terrible standard, but at least until we can get URL forms that are on the whole less than 128 characters, I wish they had met the world where it is. I believe the http2 compression scheme comes with dedicated dictionary slots for header strings that they know are going to appear, so QR would have benefited from the same (e.g. http/https taking less than 4/5 bytes, :// less than 3)
Then again, having thought further about this, I guess Marketing's Razor is the most likely explanation: it wasn't a technical reason they're using bit.ly, it's for those sweet engagement metrics
Repairing the metadata parts & iterating over each of the version number should make the overwhelming majority of broken QR codes usable again.
https://en.wikipedia.org/wiki/QR_code#/media/File:QR_Code_St...
The other 70% is dedicated to "data", on which the Reed-Solomon-coding is applied. If your QR code is absolutely stuffed to its limit (about 2kb data), you can still destroy up to 51% of the image before the Reed-Solomon coding will start to fail at 30% redundancy.
Most codes only store a few hundred bytes of data, so you can afford to destroy a lot more before the payload is also destroyed.
I'd expect the minimal-viable QR code for a 100 character URI can be very degraded.
Comprehending what you read could help a lot, too.
The output data generally isn't repeated even a single time in full, let alone "lots of times". That's what error correction keys are for.
The fact that you can stick a logo in the middle doesn't have much to do with anything. I can (and many publishers have!) put a bunch of color pictures in the middle of a book, it doesn't mean the data in the book is repeated.
In practice, I mostly I find that the corners are the most finicky part. However, that is just my current opinion.
Show: https://qrshow.nyc/retrospective.html Related: https://bsky.app/profile/sri.xyz/post/3llnpa3tvqs2u
it was extremely fun organizing that QR Show. it's actually very fun organizing events/jams in general (I'm also thinking of https://wambamjam.recurse.com/ ) -- you put out an invite, get it to interesting people, and then step back. (and, like, get snacks).
that QR Show was truly a success because of people like you who brought original works -- a lot of these pieces were made in the last weeks! and days! leading to it. it was just astonishing to see.
I've shared with some friends that I'd be afraid to repeat that show because it went so well (like - should there be a yearly? qr show??). I'm still mulling this over.
thanks again!
Consider reading up on https://www.nayuki.io/page/creating-a-qr-code-step-by-step
And I highly recommend QRazyBox for manual painting with automatic decoding: https://merri.cx/qrazybox/ , https://github.com/Merricx/qrazybox
> that begins with collecting a bunch of broken and corrupted QR codes
Some ideas to consider: http://datagenetics.com/blog/november12013/index.html