Inspired by a recent HN article on QR codes [0], I decided to finally publish [1] and open-source [2] a service I created 7 years ago. I got pulled away from it by projects with higher priority and it has been catching dust and been bitrot eroding since. Now reconstructed the basics and hosted on an AWS instance I would like to share so it might inspire.
Creating a photo realistic QR requires two steps. The first is to create a 93x93 dithered monochrome image. The dithering is calculated to preserve the mandatory QR framework/timing bits and keep the data/crc bits conforming. Trying to maximize the crc bits to match the original image.
The second step is adding colour information as a 186x186 dithered layer. The colour palette is created using Spacial Colour Quantification which uses the 93x93 QR image as constraints on the available colour range.
SCQ also stabilises palettes used for animations (a service not made available through the site yet).
Slightly OT, but when migrating data between iPhones, the old iPhone displays an animated point cloud that appears to function like a QR code. You scan it with the new phone, and your data starts to migrate locally through Bluetooth.
Other than aesthetics, what are the advantages of the point cloud? Higher bandwidth?
Also, if you were to transfer 100s of megabytes of data from device A to B, using A's display and B's camera, what tech would you look into?
> Other than aesthetics, what are the advantages of the point cloud? Higher bandwidth?
Higher information density, in that it can pass ad-hoc wifi network info and cryptographic keys. The animated "QR code" also contains a unique code in each frame that is then sent back during the pairing process. This allows them to measure the round trip time from display to camera to wifi back to the original device, preventing relay and replay attacks.
(This is based on my attempting to reverse engineer watch pairing for a few days)
We use a similar method for offline wallet transfers of private crypto keys. I’ll note a couple things. Keep the frame simple and not too dense. Be careful on ecc settings. Higher res camera androids to be slower in our testing. Be ready to loop the series to catch missed frames. Gives your frames and order context. If it’s really sensitive dat, encrypt it before encoding you QR. assume the video can be stolen from a camera. Inject noisy frames To help obfuscate.
I want to use a one-time pad with a friend. That requires generating a fully random file that I then need to send to my friend (physically).
I don't have an Ethernet port on my machine to send the file on the wire, and I don't want to rely on weaker cryptography (WiFI, aes) to send this file (basically, everything is weaker than a one-time pad).
I also don't want to leave undeletable traces of my one-time pad on a flash drive.
So what's left is the actual screen of the device, provided I don't have any hidden cameras where I live.
I could use a hard drive and then shred the secrets, but nothing is proven regarding the actual deletion of the files, and QR codes are much cooler!
Did you consider using the front camera for bidirectional phone-to-phone communication? That could allow frame re-transmits which would increase the data rate a lot.
I've been wondering how one could efficiently and reliably pack arbitrary data into YouTube videos, a hacky way to get free and obfuscated data storage. Streaming QR codes has been the most promising way I can think of, particularly since they offer resilience against YouTube's video re-encoding process and are standardized for far larger codes, which could be easily fit in a video for later parsing out by a tool. You could probably embed even greater data densities with a color QR solution too.
If I had to guess, the animated point cloud isn't tasked with transferring lots of (megabytes) data, but is probably a proprietary version of a QR code, both for aesthetics and security through obscurity. Its format may also have higher information density than a QR code, which would work well for encrypted data.
I imagine the heavy lifting is done on Apple's server. The data being transferred locally is likely a GUID/IMEI/etc + a nonce.
I just transferred a friend's iphone the other day and noticed this animated pattern. I presumed the QR-like code was just to transfer authentication so that the two phones could establish a secure wifi connection, since the QR recognition is fairly instantaneous and you don't have to keep the camera on the animation for long. (the process does ask you to keep the phones close, so the later transfer is probably by bluetooth, as you say)
One (possible) advantage could be that the animated nature means that someone taking a photograph of the animation won't capture enough data to steal the whole payload? And the use of tiny pixels might mean that even a video capture from anywhere but up-close might not have enough fidelity (after compression) to read the encoding either?
I bet its about the “opportunity cost aesthetics”—-Apple thinks QR codes are butt ugly. See also the round App Clips codes recently introduced, and the very late (I bet teeth-grittingly reluctant) introduction of QR scanning in the first-party iOS Camera app.
I could be completely off the mark, but would an animation make it difficult to spoof. I can't now just use a photo of the cloud? Of course it could be that it just looks cool :D
Not quite sure I understand what the question is. Calculating the QR is really CPU intensive and the settings on the site are for lowest quality. ANd even now its overloading.
Somehow, I think these kinds of "clever" QR codes would be less used. Most people aren't going to even notice that they are legit QR codes. QR codes are already underutilized enough, at least in western countries. Cool idea, though!
It’s my opinion that underutilization is because of application rather than any more ephemeral thing like appearance. QR codes haven’t had a killer app yet, and they tend to be used for marketing rather than any critical tasks that rely on the qualities that make it a useful technology. My guess is this will change as it’s become more or less a requirement to have a cell phone to function in western society.
Since the virus hit, where I live restaurants are prohibited by law from having reusable menus. Instead, nearly all of them have a QR code at the able that you scan to see the menu on your phone.
When I lived in China, scanning QR codes was how we initiated payments for restaurants, groceries, couriers and other offline goods/services. It was also how we added people to WeChat.
I would guess at least 20 million QR codes are scanned per day in Beijing.
I think they’d need some hardware to verify that the transaction happened. A small business owner can use their own phone, but other businesses need a smartphone per point of sale, which might be more expensive than a card reader (that one likely has to have anyway)
You can use a phone (or whatever) to verify the transaction, but in practice I've never seen anyone do that. It probably helps that crime is pretty low in this part of Asia.
As an European I’d say over half of my mobile payments are already via a QR code (it triggers a direct debit from my bank app). It’s infinitely faster than going through online checkout forms.
I am French, use mobile payments and would be interested to see a payment qrcode (never seen one)
Also, when you mention Direct Debit, is this the mechanism which allows a merchant to draw on your bank account? There need to be confirmed with the bank before (though maybe it is possible now to have that in one step, which also has your consentement)
Also 1) only works up to a daily limit which you can configure 2) it’s a SEPA transfer, goes straight to another local, very traceable account and not a random bitcoin wallet in case you try to pull that off :)
Look at just any thing you’ve purchased and you’ll find a QR code on it somewhere (or the box it came in). They have massive uptake in warehousing and manufacturing.
They are also very popular in China, the dang things are on just about every surface.
The big problem is that any random QR code could be malware or the like (not a big problem for the tech-savvy, but worrying for those who are not) and few urls are so unwieldy that QR codes work better.
I can see it being useful for stealth links to .onion sites which are generally impossible to remember and a pain to type out.
> it's become more or less a requirement to have a cell phone to function in western society
Owning a cell phone doesn't mean everyone keeps it with him at all times, and this will limit potential uses. Hopefully people don't become tied to it that badly.
I'm a bit curious… how much traffic is the front page of HN?
(I was thinking of posting a "Show HN" at some point, but I just do everything on my own machines. Not sure how much traffic my desktop would handle before figuratively melting. The nice thing about my Show HN is that it would be a static HTML page, so that's at least easier; yours is necessarily dynamic.)
Ultimately it should be made possible to do it locally. Current setting is low-quality and takes about 1-2 seconds. Mid-setting about 20 seconds and high about 20 minutes.
Using the 4 example images at the top, the first (color) and last (B&W) work flawlessly on my iPhone.
But the two animated ones in the middle will work for a second, and then the phone loses it. Animated seems like "too much" for a phone to lock on to -- perhaps just stick to static? That's cool enough.
Really sorry to hear that. I do not have such a device and without. If I knew which engine was being used I might have a starting point to figure out what might be happening.
edit: I noticed that the QR needs to contain a message or it will not scan.
I do wonder what the practical use is, though, aside from just being pretty cool. In a real world situation I think the recognizability of a QR code as something you can scan with your phone is an important part of the value.
It uses dithering by Spacial Colour Quantification to get the best photorealistic 93x93/186x186 colour image. The title plays on that the QR can be near photo and not some pixelated icon.
Thanks for the example. It's the colour threshold. But with the brief number samples already posted I'm going to replace that that and generate two QR's. A low and high colour contrast.
I have a pet project, "Oh By"[1] that is a replacement for QR codes that does not require an app to create, or consume, and you can just chalk them up anywhere.
The downside is that it is a centralized service. Further, you would need to trust that this centralized service would continue operating into the indeterminate future. Luckily I have a strong track record there.
From a practical perspective, the larger problem with this implementation is that unless you happen to have heard of your service (unlikely), it's not obvious what to do with the code, or even how to find out what it is. You need a distinctive, unique string format that yields to googling. Overloading the hexadecimal notation was a poor choice, in my opinion.
The default Camera App in Google Pixel can auto-recognize QR codes, but unfortunately it doesnt work with these. Meanwhile, a dedicated QR scanner (such as built-in in iPhne) works.
I've long wondered whether you can make a photo that gets recognized as a QR code by computers. This is very cool! Is there any way you can smooth out the calibration squares?
QR should look MORE like QR, and always include an URL next to it.
If you display a QR Code with some url, and fail to show a shortened url next to it for people to type instead of scanning, you either fail basic common sense tests, or are intentionally being an asshat.
... or the QR code isn't meant exclusively for direct human consumption?
A QR code is quite information-dense. With even the highest error-correction rates, a 53x53 QR code will store 100 bytes of information (https://www.qrcode.com/en/about/version.html). That's more than you can replicate in a URL intended for typing.
For the case of the 'Show HN' here, think of semi-automatic uses of the QR code that still use the provided aesthetic potential, such as inventory-control stickers that look like the owning organization's logo.
Inspired by a recent HN article on QR codes [0], I decided to finally publish [1] and open-source [2] a service I created 7 years ago. I got pulled away from it by projects with higher priority and it has been catching dust and been bitrot eroding since. Now reconstructed the basics and hosted on an AWS instance I would like to share so it might inspire.
Creating a photo realistic QR requires two steps. The first is to create a 93x93 dithered monochrome image. The dithering is calculated to preserve the mandatory QR framework/timing bits and keep the data/crc bits conforming. Trying to maximize the crc bits to match the original image.
The second step is adding colour information as a 186x186 dithered layer. The colour palette is created using Spacial Colour Quantification which uses the 93x93 QR image as constraints on the available colour range.
SCQ also stabilises palettes used for animations (a service not made available through the site yet).