Hacker News Reader

2D barcodes such as QR and datamatrix certainly have their place, but I wouldn't say they're "massively resilient" to failure.

The codes use reed-solomon ECC and the symbology spec has different levels of error tolerance ranging up to a max of ~30% errors. That's certainly robust but it still requires a controlled optical setup to avoid operator frustration. Sometimes, in some applications, a nice big 1D barcode is better. Your 150 meter postage stamp example is an extreme use case that requires a lot of setup to work properly.

This color barcode appears to be an effort from a respected institution to increase information density. It doesn't have to be immediately accepted by major manufacturers to succeed. It just has to solve some problems for some applications. I think it's a compelling new symbology.

I work in manufacturing too.

What if we add color or even UV/IR to an existing QR code just to increase data redundancy? Backward-compatibility FTW!

It is already in the works. In 3-5 years every big box store product will have UV QR codes on every side of external packaging that encode the existing product barcode plus a unique per item ID.

This is being done to improve self check out speed (no more having to find the bar code) and help with tracking receipt-less returns (this box of cereal was purchased at our store).

Do you have any hints as to what terms I should be googling for to find out more about this? I'm _very_ curious...

Not offhand, sorry. It came up with some engineers while I was doing a security audit on a self checkout machine.

> (this box of cereal was purchased at our store).

Think of the impact on forensics when every single article contains its source of origin.

Time to start a company selling an invisible privacy spray for your cereal box that coats it in UV ink and obscures the original invisible barcode...

There's already invisible barcode on some backaging. I had a UV light and used it over a Pringle can and there was a code there!

>it doesnt matter what your new standard claims to achieve, it is useless without industry adoption.

You have no idea what this person's intentions are, and calling their work useless because Toyota, Honda, Yamaha, Ford, and Dell don't use it is obnoxious.

> ... rely on near/far vision systems developed by Intermec and other companies to read a code the size of a postage stamp from up to 150 meters away.

Does anyone know of these super long range scanners (e.g, 150 m)?

Looking through Honeywell's products, the Granit 1280i [1] claims 16.5 m, which is impressive but not the 150 m mentioned above. I'm curious how aiming is even possible with what I would assume to be an incredibly narrow field of view.

[1]: https://www.honeywellaidc.com/products/barcode-scanners/indu...

Just remember there are sensors like the CMV12000 that spew out over 3 billion pixels per second @10bit/pixel and, sufficient light assumed, subpixel motion blur down to iirc about 50% linear overlap or so about. (i.e., only about 50% of the captured pixels have not been captured already.)

Assuming 32 by 32 pixels with a size of 1mm by 1mm, you get a field of view of about 2 by 3 meters or smaller if you want to skip exotic monolithic decoders that integrate de-aliasing into the error correction decoder. Below about 1.2 sensor pixel per code pixel it stops being fun and you try to find a way to get more magnification.

So, at 150 meters distance, assuming a cube for simplicity, and 5 square meters FOV. We have a cube of 300 m side length. That cube has a surface area of 540 000 m^2, which is just ~100k times the FOV. The 300 frames per second you could get out of the sensor would get this done in about 20 minutes, so yes, it's a lot, but you can reduce to 30% assuming the height difference is approximately known. Then you can probably get another 10x speed by restricting the angle in which anything interesting could happen, and you get 3% of 20 minutes/1000 seconds. That's half a minute, if you can only tell the scanner that it's about there, with a precision of "between one and two 'o clock, I'm sure".

And that's <10k$ hardware I'm speaking of (not including the cost to get a 2k$ FPGA to extract 2D-barcodes from it's video feed), in 3-digit quantities.

I deem the number plausible.

I suppose that color-based codes have more density per "pixel" (2-3 bits), so they can be used to encode relatively large amounts of information. Try encoding 1kb as a QR code; it will become pretty unwieldy, if it's possible at all. Think about the size of a reasonable cryptographic public key; would it be nice to have it optically readable sometimes?

Tagging things during manufacture is a different application area, with different constraints and requirements. Bar codes are not gone because QR codes are here, QR codes won't be gone because color codes appear.

A B/W randomart image which uses alphanumeric and special characters, like the one used in ssh-keygen itself when generating keys, would be enough. With current tech, Adding colors is just a recipe for disaster in environments which need maximum reliability.

Personally, I think QR codes are just fine for manufacturing but as for encodings meant for end-users, I think we should be focusing on making them more human-readable or at least visually comparable, without sacrificing bit-depth.

Still, this tech was really neat to play around with and I hope something good comes out of all the work put into it.

Some kind of symmetry would already really enhance how nice QR codes look to people.

> Try encoding 1kb as a QR code; it will become pretty unwieldy, if it's possible at all.

So for reference, QR codes are specified up to 177 pixels wide, and at that size they can hold around 2KB with medium error correction.

But for practical use you probably want half that width, so a 400 byte payload is fine but not much more.

Printing a 400 byte payload is pretty easy, but printing a 400 byte payload that's readable at high-speed(100 scans per second) is quite a different story. You'll find that in many usage scenarios the practical upper limit for a data payload is determined less by the symbology and more by the speed and reliability at which the symbology can be read by the equipment. Many thermal printers can do 200dpi or better which would allow you to print a QR code at maximum capacity into an area a little less than an inch, but you'll be hard-pressed to find a device which can scan those barcodes at a reasonable decoding speed and reliability.

You're much better off using the QR code to encode a unique key which points to a record of the desired size in some database in a networked system.

Edit: this is actually a discussion I've had in a professional context pretty recently.

> encode a unique key which points to a record of the desired size in some database

I'm sure you understand why this is not going to work the same way as reading the actual public key. Not only it needs a network, but it also is susceptible to stealing the values from the database by just generating the (short) unique keys.

I just made a short (2048 bit) key pair, and made the public key into a QR Code (as ascii armoured text, so it could have been more dense in straight binary)

https://flic.kr/p/2cYCwfG

I could only get it into a 141x141 by dropping error correction right down to 7%, but under ideal conditions (from my monitor to an iPhone) it reads reliably, as shown. I tried a 4096 bit key, but I couldn't (as text) get it into even a 171x171 QR Code at minimum error correction without truncating (and even in ideal conditions, my phone won't reliably read 171x171 resolution QR codes...)

RSA keys are significantly larger than elliptic curve keys, so for something like putting a pubkey in a QR code, you're much better off going with a 256 bit elliptic curve key than any other hacks to try shave bytes off encoding RSA keys.

Some friends and I experimented with this when running a CTF a few years back. We figured out that setting some of the Chinese Remainder Theorem values in the private key to zero, we could stuff it into a QR code and read it when printed using a receipt printer.

> it also is susceptible to stealing the values from the database by just generating the (short) unique keys

Even a very small QR code fits enough bits to prevent that.

> it needs a network

It depends on what the key is for. For many purposes a hash of the public key is sufficient.

I'm not talking about cryptographic keys, I'm talking about unique keys. Like a UUID or a serial number.

A barcode is not often used as the sole storage medium in an application. Typically it's used in conjunction with a piece of software that can connect to a database. In a manufacturing setting this could be a piece of shop floor control software. In that setting the barcode doesn't encode any information that could change in the database. It is instead used to encode a machine-readable identifier for the material that it is labeling.

> Think about the size of a reasonable cryptographic public key; would it be nice to have it optically readable sometimes?

An ECDSA key would be 256 bits or 32 bytes long. At low error correction, it can fit into QR Code version 2 (21×21 modules). Or if you're thinking of RSA, then a 2048-bit key would fit in version 10 (57×57).