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

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