Aztec barcode vs QR-Code

Question

I am trying to develop an application that will use tickets given the user the ability to validate them. I am wondering why I should choose Aztec barcode as many many companies have already chosen that instead of QR-Codes. What are the pros of the Aztec barcodes?

I good comparison I have found so far is: http://www.tec-it.com/en/support/knowbase/barcode-overview/2d-barcodes/Default.aspx

and here: http://en.wikipedia.org/wiki/Aztec_Code on Usage section you can see that is used quite often.

Answer 1

Although Aztec Codes are more compact and tunable, there is poor support for them among open, non-proprietary software. I would still use QR Codes for now, which have very mature software support on a wide variety of platforms.

If space is at a premium for you, and you do not care for users to be able to read or generate your codes with their own software or on a wide variety of devices, then Aztec would be a better choice. Aztec codes do not require a surrounding margin, allow for very finely tunable error correction level, and have a tighter encoding optimized for a wider range of message texts.

For example, the Aztec codec has a mode specialized for encoding lowercase letters, so it could encode most of this question answer with only 5 bits per character. The QR codec is only optimized for uppercase URLs, and must store lowercase letters as full 8-bit binary data. A QR code containing this text would have to encode about 160% as much data as an Aztec code -- and then it needs a margin space too.

QR codes require more space than Aztec codes but have freely available software supporting them.

Aztec codes can store more information, but there is poor free support for them. They can be harder to read and generate efficiently, right now.

On an Android phone, Google's "Barcode Scanner" application will scan an Aztec code after a longer delay than a QR code, and the user has to manually enable Aztec code scanning in the application preferences.

Similarly the free barcode generator package "zint" will produce Aztec codes, but has a handful of bugs, and does not make full use of the codec to optimize their size as small as possible. Its generation of QR codes, on the other hand, is bulletproof.

Answer 2

The biggest advantage I've seen with Aztec codes, in the past, is the distance you create read them from.

The testing I've seen showed that if the data density is low (6'ish bytes with approximately 1 3/4" square images) they're readable at twice the distance of QR codes (10 feet vs under 5 feet). This is with a modern, as of 2023, commercial scanning library.

If you scale up the data density (40-60 bytes) testing showed the distance gap getting larger, although the Aztec code distance also dropped by a foot to get a reliable read. Beyond 80 Aztec codes again appear to drop off but a bit more drastically (5 feet).

Testing showed QR codes also need better lighting conditions than Aztec codes appear to need to get repeatable reads. Off angle results were also better with Aztec as well.

Answer 3

I share the frustration with the comparative incompleteness of FLOSS support for encoding and decoding Aztec Code, expressed in @fuzzyTew's answer.

There is much more open-source code for encoding and decoding QR, compared to Aztec, and it is more feature-complete and thoroughly tested.

That's a shame, because Aztec Code is in several ways superior to QR. As described in @fuzzyTew's answer…

• Aztec doesn't require a “quiet zone” of white space around the symbol, while QR does.
• Aztec offers continuously-tunable error correction levels, whereas QR code offers only a few discrete levels.
• Aztec offers substantially higher density than QR, for typical applications consisting mostly-to-entirely of standard ASCII text.
  • Compared to Aztec, QR is particularly inefficient for encoding lowercase Latin letters (8 bits/char) compared to Aztec (5 bits/char).
  • The largest QR size, 177×177 blocks, can store 2953 bytes in binary mode with Low error correction (~7%), while the largest Aztec size, 151×151 blocks, can store 2318 bytes in binary mode with equivalent 7% error correction. At that size, Aztec requires ~9.83 blocks/byte, while QR requires ~10.61.

Much of the open-source support for Aztec is based on ZXing. That includes the Android Barcode Scanner app, and many online encoders and decoders.

Until recently, ZXing's Aztec Code implementation did not correctly support the encoding or decoding of non-Latin1 characters. (QR, Aztec, PDF417, and Data Matrix all use ECI to support other character encodings.)

Recently I've started doing something about it:

• I added support for correctly decoding non-Latin1 characters from Aztec in ZXing.
• I added support for correctly encoding non-Latin1 character sets to Aztec in ZXing.
• I also added support for encoding non-Latin1 character sets in the Python aztec_code_generator module.

The point of all this is: There's not actually a ton of work to be done to get open-source Aztec encoders/detectors/decoders of a high quality.