31–40 of 43 posts
The examples look a lot better than what I'm seeing in my own attempts and on the "Wall of QRs", I wonder if it's just because we're not using "High Res" or if there's some fine-tuning of the source-image involved. In any case, this is massively cool. Did you see that little egg fella? He's got sunglasses and everything.
I've been writing about (and using) QR codes for a couple of decades. I love the innovation that happens within the bounds of the specification. One problem that I foresee with this is that they don't look like QR codes. People are now used to looking for a specific monochrome pattern to point their phone towards. There was a competitor to QR - MS Tag - which tried something similar. Their codes were able to be integ…
The irony is you can scan a URL with a phone camera and it's clickable, with the nice side-effect that the domain is human-inspectable. Just make the font a little bigger and it scans easily. QR codes are fascinating though, as they can encode more than mere URLs. But the vast majority in the consumer space are links. For that purpose, I'm rooting for OCR.
And they are human-inspectable. It is regrettable that iOS's camera app just prompts you to open a QR-encoded URL in a Web browser, but you can use a "passive" scanner that just reveals the payload without risk.
Over on Mastodon we've just recently been having some fun with these techniques: Dithering: https://mathstodon.xyz/@andrewt/115035614385265413 Mondrian: https://mathstodon.xyz/@OscarCunningham/115049490241833844 Hand Drawn: https://mathstodon.xyz/@andrewt/115056697540191327 Bad Apple: https://pony.social/@luna/115057532794342459 White Noise: https://pony.social/@luna/115058126613306302
You cannot intelligently merge anything with the data. Otherwise it would change the data. The data is firmly packed on the rightmost side of the code (in the usual orientation). There is no space to weave anything in there. The only way to have anywhere to weave anything in is to choose an oversized code, and then manipulate the padding in the free space after the data, if you go only slightly out of spec (it's supposed to be a specific pattern, but any qr code reader I found doesn't give a damn about what's after the data).
"We leverage the highest level of error correction (Level H), which allows up to 30% of the data to be "damaged" or altered while remaining perfectly scannable. By using this capacity for the image pattern, we create a code that is both visually striking and reliable."
This is a completely nonsensical statement. You can manipulate the padding, to get some control over the generated reed solomon blocks (using the fact that RS encoded data is closed under XOR), although you won't be able to fully control all of those bits. But you can fully control the padding bits. So what you want is to have more padding, and less error correction, so you have maximum control. In which case, using the highest error correction level is hugely detrimental to the aim of making a QR code contain a picture. You cannot use the "30% error correcting capacity" to store the image. Those bits depend solely on the data and padding. The only control you have is over the padding (although you can get some indirect control over some ECC bits, if you give up control of several padding bits).
As for the reliability claim: I tried scanning the codes on the top image of the article with 10 codes on it. I first tried https://zxing.org/w/decode.jspx and it identified exactly none of them. I then tried with an application called BinaryEye on android, and it managed to scan 3 of them, but failed to recognize 7 of them. Enough said.
What they did was shrink each module to allow some of the background to bleed through. Which also makes their other claim that they do some halftoning thing quite irrelevant, you can have any color palette you want in the background (even full-on rgb). They are NOT part of the QR code, you just have to ensure the overall contrast of the module is distinguishable between the two states, conveniently achieved by the "ugly" black and white boxes dotted around the code. What this does is only make the code partially readable, because the scanner has a hard time interpreting a lot of the modules, and relies on error correction to recover the damaged parts.
They are not making the image into a QR code. Not a valid one anyway. They claim the code itself becomes the image, but it's really just a different way of partially damaging a valid QR code (spread the error over the whole area, instead of concentrating it in the middle). If it were a valid QR code, then a perfect picture of one (directly out of the generator, not taken from a photo, so it's as clean and perfect as can be) would be scanned correctly (most didn't) and it also does so with ZERO errors on any of the reed solomon blocks in the code. This project achieves nothing particularly interesting.
Over on Mastodon we've just recently been having some fun with these techniques: Dithering: https://mathstodon.xyz/@andrewt/115035614385265413 Mondrian: https://mathstodon.xyz/@OscarCunningham/115049490241833844 Hand Drawn: https://mathstodon.xyz/@andrewt/115056697540191327 Bad Apple: https://pony.social/@luna/115057532794342459 White Noise: https://pony.social/@luna/115058126613306302
https://arstechnica.com/information-technology/2023/09/dream...
I wonder how well these scan under less-than-ideal lighting and focus conditions. The standard QR code would be a lot more robust...
It's a slight tradeoff. Digital works flawlessly though Still experimenting with how it works with print.