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