for those decrying the limited use of 2d barcodes in the US or in europe, you've never set foot in a manufacturing environment.
2d barcodes are used for cradle-to-grave inventory tracking by systems like Glovia and SAP. everything from transmission gears to soda pop are tagged during manufacture with numerous 2d barcodes that change at different stations, and at different times.
it doesnt matter what your new standard claims to achieve, it is useless without industry adoption. Toyota, Honda, Yamaha, Ford, Dell, and countless other manufacturing titans have invested collective billions into the QR implementations of their factories and arent going to re-tool just because your standard has colors.
QR is also massively resilient to failure. Try this experiment: cut a QR code in half, try to read it. It will succeed. This resilience is pivotal in harsh environments and especially during international/trans oceanic shipping.
black and white QR can be engraved on shipping containers and is resistant to corrosion, solvents, and the environment around it. QR codes are regularly burned at thousands of degrees as part of the heat treatment process for hardened steel, and still perform. Vision systems for forklifts and robotic cranes at shipping yards (most are robotic yards these days) 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.
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.
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).
>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.
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 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.
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)
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.
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).
2d barcodes are used for cradle-to-grave inventory tracking by systems like Glovia and SAP. everything from transmission gears to soda pop are tagged during manufacture with numerous 2d barcodes that change at different stations, and at different times.
it doesnt matter what your new standard claims to achieve, it is useless without industry adoption. Toyota, Honda, Yamaha, Ford, Dell, and countless other manufacturing titans have invested collective billions into the QR implementations of their factories and arent going to re-tool just because your standard has colors.
QR is also massively resilient to failure. Try this experiment: cut a QR code in half, try to read it. It will succeed. This resilience is pivotal in harsh environments and especially during international/trans oceanic shipping.
black and white QR can be engraved on shipping containers and is resistant to corrosion, solvents, and the environment around it. QR codes are regularly burned at thousands of degrees as part of the heat treatment process for hardened steel, and still perform. Vision systems for forklifts and robotic cranes at shipping yards (most are robotic yards these days) 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.