I’ve been reading up on how to actually create physical QR Codes, complete with error correction. It’s been very enlightening, and has grown a deeper fascination on the symbology of barcodes in general for me. While I’m not in 100% agreement with how they are currently being used (marketing, mailing lists, coupons, etc.), I do believe there does exist a market for mobile barcodes. Heck, I’m using them on this site for each and every post!
Regardless, I started reading up on High Capacity Color Barcodes that was developed by Gavin Jancke at Microsoft. It’s important to separate HCCB codes from Microsoft Tag, which is a specific implementation of HCCB. There are some misconceptions about HCCB, and probably some things that you haven’t thought about. Further, there are technical advantages that usually aren’t mentioned. So, I’ll discuss that here.
Here are some advantages that I think HCCB Has over QR Codes, and I personally think they hold quite a bit of weight:
- Unlike Microsoft Tag, HCCB can store a lot of data offline. QR codes can do this as well.
- HCCB codes can be digitally signed with either Elliptic Curve Cryptography (ECC) or RSA, and the reader should verify the signature (while this is technically possible with any code, current readers in the “app store” markets don’t verify them).
- The HCCB specification was designed to take advantage of poor cellphone autofocus lenses.
- HCCB was also designed to take advantage of varying light conditions.
- Due to the triangle shapes of the HCCB symbols, a black-and-white HCCB code can fit the same amount of data in a smaller space.
- Due to the 4 and 8 color palette options, higher compression can be achieved with the same data in the physical HCCB code.
- HCCB codes can store multiple payloads, such as a URL, text and a vcard in a single code.
Now, don’t get me wrong. I’m not advocating HCCB codes by any stretch of the imagination. Here are a few major disadvantages:
- The license to print HCCB codes, or develop readers to decode the codes, is 100% proprietary, and requires a Microsoft account.
- Microsoft Tag, by far the most common HCCB implementation, requires a data connection to access the data in the code. Think of Microsoft Tags as a short URL redirector.
- There are currently no HCCB decoding apps in any “app store” for the common mobile devices outside of the Microsoft Tag implementation.
- HCCB code generation requires Microsoft libraries and software to create the codes. There are no 3rd party libraries, open source or otherwise.
- Large-scale printing is an issue, due to offsetting the colors, so they align perfectly. This is also expensive, compared to black-and-white printing (Microsoft has also released a black-and-white version of the HCCB spec).
- Due to 3rd party reliance on Microsoft software, most barcode decoding apps do not have the ability to decode HCCB codes, thus requiring multiple decoding apps to be installed on the device. This requires users to know the difference between barcodes, and which app to use for which code.
To me, a few of those disadvantages are heavy hitters. Now, Gavin has stated that they were not designed to replace, or even compete with QR code or other symbologies. Instead, it’s trying to fill a niche market. I don’t know if it’s succeeding in that niche, or not. However, I do believe that it won’t reach the general population on large scale terms, due to some of the disadvantages listed above. With that said, I am willing to give credit where credit is due, and recognize the technically superior specifications in the code. It was well researched, and well executed, and I’m bothered that there does not exist an “open source” specification that meets or exceeds these specs.
I have the Microsoft Tag reader installed on my phone to handle decoding them anyway.