QR error correction helps and hinders scanning (2021)
huonw.github.io
huonw.github.io
It feels a bit like the error correction exists mainly so you can embed fancy logos in your QR code... Avoiding damage to some parts but not others seems unaligned with real world scenarios...
The camera app on your smartphone likely searches for them by default. That means feeding at least 1-2 frames a second through it.
Basic pattern matching for the position markers is a rounding error overhead vs processing a video feed. Fancy computer vision is not - on lower end devices you may not have enough resources to do both and on higher end devices it'll still impact power usage.
Detecting a QR code in real time should be possible on all devices by now...
Absolutely not the case. QR codes, like most 2D matrix codes were designed for logistics and supply chain, their leap into the consumer mobile phone arena was an interesting one, but not the original design intent at all (QR was developed at Denso, the automotive parts and logisitics arm of Toyota). The purpose for the error correction is so that the symbol can still be read on a label even if part of it is misprinted or obliterated, it works very well in practice. Industrial scanning software is mature technology, and more sophisticated than you imply (besides, segmenting and aligning barcodes, any barcode, in greyscale images is pretty simple). Position markers are easy to reconstruct and damage can be tolerated.
Still, it is possible the app has a legit reason like the OS wallet implementation is missing support for their region or OS wallet support is incomplete in some way and this bridges that gap.
18m does seems a tad steep though considering that RDW payed UDL to build a sample reference app for free and one would expect that to be the basis for any 3p implementation delivered. Like that would be 36 very highly paid engineers which is a lot for 2 apps. It’s possible the 18m was also for the backend changes to enable the app which would maybe be more legit and be required changes for the builtin integration. Are you sure it was 18m just for the app?
https://www.themandarin.com.au/233815-queensland-digital-lic...
That's probably total development and some operations costs
It’s a shame that there’s so many disparate motor vehicle agencies. They should standardize their IT solutions to amortize development costs as I fear the vendors they pay double dip with the pricing of solutions.
Why didn't they encrypt it with a random key and then put a QR code of the key on the inside of the passport? Or just use a magnetic stripe or similar instead of something that can be remotely accessed by an attacker?
See ICAO 9303 for details. (BAC specifically)
I'd rather use an RFID-safe pouch to store my passport and use the RFID-based automatic border control.
--
My fun, pre-RFID traveling days... always ended up with me in secondary screening. Millions of non-citizens, waived right-on-through... and then these two Texian gringoes... getting their beat-up, licensed & insured Z71 thermally scanned at every possible Rio Grande crossing.
--
Decades later, traveling insland (with gray hair and wiser comlexion) and I smoked a joint while a drug-sniffing dog walked by, unaware of his worthlessness (as intended).
--
It's all theater, welcome to Our Play.
You know what is a protip though? When applying for a US passport you can also choose to get a passport card. It's a plastic card that is the same dimensions as a driver's license and is valid for use in place of a passport when traveling between US-Canada-Mexico by land, and it's also an acceptable form of identification in general because it's a government-issued identification.
I grew up in Central Texas (HOURS to get out-of-state), and many drinking establishments would ONLY accept a Texas ID/Passport for alcohol purchases — this isn't "legal" but "how it was."
I'll take your ProTip, though, and get myself an ID Passport Card (I presume this is not scannable).
I found this surprising. I'll be displaying QR codes on a screen, so for me L easily makes the most sense in order to be able to make it larger with fewer squares inside of it.
This is essentially false. Plenty of industrial cameras are black and white because of their speed and light collecting advantages. This matters for high speed identification. Going to color would not be an upgrade.
"missed opportunity"
Limited information density just isn't nearly as big an issue as you seem to believe.
Colors work great until they don't, for non emissive sources they depend on ambient lighting. A black and white code can be read with under virtually any color lighting (it doesn't even have to be in the visible spectrum). And if you've seen anyone futzing getting a read of an eticket off an emissive device such as a screen, that is just much worse once color is brought in.
Most auto ID applications have limited keys and identifiers encoded in the symbol. Just as color cameras are ubiquitous, the same goes for network connectivity, you don't need to store massive amounts of data in the symbol. If color symbols were really that much of a win they would have been adopted in industry. Attempts by groups that don't understand the subject have been made over the years, this is not new:
https://en.wikipedia.org/wiki/High_Capacity_Color_Barcode
"Yes, it requires different printers"
This is quite an understatement. There's no cheap upgrade path from monochrome thermal printing technology (or laser engraving), that's why they have never been replaced all these years.
Color imagers were readily available long before 2005. Color printing has not changed much at all in the past 20 years. If color symbols made sense they would have been adopted a long time ago. They are almost always the wrong approach, too many problems for too little payoff, that's why they are uncommon.
Lighting. The Sun, incandescent, and halogen lights have pretty good color reproduction. But LED lights and fluorescent lights do not. LED lights and fluorescent lights are designed to look acceptable to human eyes. And they can be reasonably good at it. But cameras are not human eyes; color gets all fucky when you look at it through a camera.
Cameras. The tag you linked to uses the LAB color space; one channel is brightness, one channel is blue vs yellow, one channel is red vs green. Cameras almost always have BGGR arrays; on a 4 megapixel camera, you will have 1 million blue pixels, 2 million green pixels, and 1 million red pixels. So if you use a normal camera to read a tag in the LAB space, you have 4 million pixels reading the brightness channel, 3 million pixels reading the red-green channel, and 1 million pixels reading the blue-yellow channel.
If we make a QR code so dense that the scanner cannot make out any of the pixels, it becomes completely unreliable, even if 80% of it is error correction bits.
Basically, error correction defends against processes that cause random erasure or flipping of bits. Error correction is not meant to defend against fundamental channel bandwidth problems.