This looks great!
I also gave it a try, uploaded a transparent png (which was converted to black, fair enough, guess there's no good default choice for all cases) and scanned the pretty QR code with my phone: Flawless.
Thanks for building and sharing this, I love to see QR codes become more readable
This is cool, but what's the use of error correction when you're deliberately introducing noise?
In my experience, these art-y qr codes are more challenging to scan than traditional plain variants, especially in real life scenarios where you don't always have a perfectly clear image
Modern iOS and Samsung devices have very good QR code libraries which work well even under challenging conditions. Other Android manufacturers (e.g. Xiaomi) and a lot of the "QR Scanner" apps on Google Play use a really old library that doesn't work well under perfect conditions.
Hei ! Just wanted to drop by to say that i tested this with a black and white logo that I had generated ; sounded like the worst case scenario ; it handled it flawlessly ; the picture didn't look the best - but the job was done and it worked. Bookmarked it will definitely use it if i need to !
It's a commercial project but I'm of course not planning to monetize the QR generation. That'll always remain free.
Currently adding more features that would appeal more to enterprises or businesses. Those will be the only paid features
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 integrated into designs without the "ugliness" of QR codes. The problem is, no one knew they were there!
The corner targets are still visible in Nitro's codes - so hopefully people will spot them. But I think it is OK to embrace the ugly. Not everything needs to be smothered in your corporate branding. Something which is standardised across multiple things is useful.
I wrote a blog post about QR codes with an overview of image techniques like this and a bunch of links to different implementations if anyone would like to see more things like this.
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.
"This halftone pattern is then intelligently merged with the QR code's essential data."
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.
Hi! These look fancy but there are obviously issues around scanability. At first glance, you can probably make them readable with libraries like ZXing and others by keeping the finder patterns intact, i.e. making sure there is always a bit of white space (ISO mandates a 1-module width white border) around them.
There is Russ Cox's QArt coder [1] that does actually make the code match an image by manipulating the padding (it works by adding a #<padding> on the end).
That is a fair bit closer to 'intelligently merged with the QR code's essential data'.
27 comments
[ 3.3 ms ] story [ 52.9 ms ] threadIn my experience, these art-y qr codes are more challenging to scan than traditional plain variants, especially in real life scenarios where you don't always have a perfectly clear image
Is this a commercial project or an open-source ?
Well done.
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 integrated into designs without the "ugliness" of QR codes. The problem is, no one knew they were there!
See https://shkspr.mobi/blog/2010/11/ms-tags-vs-qr-codes/#not-as...
The corner targets are still visible in Nitro's codes - so hopefully people will spot them. But I think it is OK to embrace the ugly. Not everything needs to be smothered in your corporate branding. Something which is standardised across multiple things is useful.
https://kylezhe.ng/posts/crafting_qr_codes#image-techniques links directly to that section and skips the fluff about how QR codes work
I highly recommend checking out https://cgv.cs.nthu.edu.tw/projects/Recreational_Graphics/MQ... which uses word clouds with QR codes and looks crazy cool
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
In any case, this is massively cool. Did you see that little egg fella? He's got sunglasses and everything.
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.
[1]: https://research.swtch.com/qr/draw/
https://arstechnica.com/information-technology/2023/09/dream...