3 ms·

Our software uses QR codes for inventory tracking. They're absolutely wonderful - you can store loads of data in a format that's very easily parsed by handheld

by oobey 9y ago

Our software uses QR codes for inventory tracking. They're absolutely wonderful - you can store loads of data in a format that's very easily parsed by handheld scanning devices. So much data that you can completely do away with having to call out to a central database for item information, as you do with bar codes. QR codes are great, and I never understood why they're treated as such a joke.

monocasa 9y ago
We were just in the the trough of disillusionment. https://en.wikipedia.org/wiki/Hype_cycle https://en.wikipedia.org/wiki/Hype_cycle
crispyambulance 9y ago
I think they're great too, but they don't hold more info (per unit area) than other types of symbology like, for example, datamatrix. If you really want to stuff tons of data in the symbol itself, you need PDF417. That can be scanned by a specialized line scanner (admittedly not convenient for phone cameras) QR codes often encode URL's/URI's and the application typically hits up a database upon scanning them just like any other inventory barcode.
- nayuki 9y ago
  It is not clear whether these statements are true. * QR codes mandate a minimum of 15% area used for error correction and a maximum of 60%. * Data Matrix codes mandate a minimum of 0% area used for error correction and a maximum of 50%. * The amount of overhead in QR codes (finders, timing, alignment) is probably in the same ballpark as Data Matrix codes (black lines, checkered lines). * PDF417 codes demand low vertical resolution (e.g. 15 thick steps) but high horizontal resolution (e.g. 200 thin steps). They are hard to scan on a phone camera. Although this thick-thin design is appropriate for line scanners, the asymmetry in horizontal-vertical information density leads to poor information density overall and higher susceptibility to damage and unreadable barcodes. Square primitive blocks make sense because they are more spatially balanced.
  - crispyambulance 9y ago
    Datamatrix uses ECC200 almost always. In practice, especially for phone-reader applications, the limiting factor for data transmission is not the symbology choice (datamatrix/QR) but limitations from the camera. That said dense 2D barcodes read by dedicated imagers in controlled lighting scenarios, as far as I've seen, are always datamatrix. Not sure if that's merely historical or if there's a technical reason for that.

by oobey 9y ago

monocasa 9y ago

We were just in the the trough of disillusionment. https://en.wikipedia.org/wiki/Hype_cycle https://en.wikipedia.org/wiki/Hype_cycle

crispyambulance 9y ago

I think they're great too, but they don't hold more info (per unit area) than other types of symbology like, for example, datamatrix. If you really want to stuff tons of data in the symbol itself, you need PDF417. That can be scanned by a specialized line scanner (admittedly not convenient for phone cameras) QR codes often encode URL's/URI's and the application typically hits up a database upon scanning them just like any other inventory barcode.

nayuki 9y ago
It is not clear whether these statements are true. * QR codes mandate a minimum of 15% area used for error correction and a maximum of 60%. * Data Matrix codes mandate a minimum of 0% area used for error correction and a maximum of 50%. * The amount of overhead in QR codes (finders, timing, alignment) is probably in the same ballpark as Data Matrix codes (black lines, checkered lines). * PDF417 codes demand low vertical resolution (e.g. 15 thick steps) but high horizontal resolution (e.g. 200 thin steps). They are hard to scan on a phone camera. Although this thick-thin design is appropriate for line scanners, the asymmetry in horizontal-vertical information density leads to poor information density overall and higher susceptibility to damage and unreadable barcodes. Square primitive blocks make sense because they are more spatially balanced.
- crispyambulance 9y ago
  Datamatrix uses ECC200 almost always. In practice, especially for phone-reader applications, the limiting factor for data transmission is not the symbology choice (datamatrix/QR) but limitations from the camera. That said dense 2D barcodes read by dedicated imagers in controlled lighting scenarios, as far as I've seen, are always datamatrix. Not sure if that's merely historical or if there's a technical reason for that.