QR codes are big ugly squares, so I can understand why some popular apps decide to roll their own.
But it certainly makes them way less convenient and universal. Can’t just open your camera app.
It took me maybe 45 seconds just now to find the scanning feature in Spotify, in a real world situation I probably would have given up and just used search after about 10 seconds.
The do have to be big, they do have to be squares (in terms of general shape), but ugly? Actually no! Check this out: https://qr-code-styling.com/
I've used this for a project where we wanted QR codes that fit a particular color theme. As long as you maintain a certain amount of contrast between the code and the background (and test your work, this is very much "you break it you fix it" territory) you can have rounded dots, rounded corner dots, colors (even gradients!) and an arbitrary image in the center.
Again, you need to try out this library with whatever design you're intending, and if you push some of the parameters too far you'll lose certain QR scanners, but the spec is way more flexible than most people know.
Beauty is subjective, of course, but for me at least, these stylized QRs don't look _much_ better than regular ones. And may make it harder for recognition too, for customers used to the big ugly squares-on-squares format
I wish QR codes were just 3-point simplices with barycentric triangle pixels. That ought to be enough. You could even shape the QR triangle any way (affine transform) you like, at the risk of readability of course.
Moreover, QR Codes can convey full URLs and text payloads, whereas proprietary app codes (Spotify / Snapchat / Facebook Messenger (retired?) / etc.) can only hold maybe 100 bits, which is only enough to have a unique ID that you must query the server to be useful in any way.
The code has a CRC code embedded. Why is it that every article mentioning CRC codes brings up that you can write them as polynomials? AFAICT it never makes a difference in implementation. What am I missing?
That bitwise XOR is polynomial addition (and subtraction) in F_2[x] (polynomials with coefficients mod 2)?
More immediately, it’s about the only way to unambiguously write which polynomial you mean, independent of endianness and similar notational issues. (The error correction properties don’t care about the way you arranged the bitstream into bytes or words.)
But I find the knowledge that I am just implementing long division helpful, too. I did transcribe the beast mindlessly from a reference book a couple of times before I got it, but debugging it that way is pure hell.
I think it is easier to extend a polynomial multiplication (known concept) with a finite field than to directly introduce a carryless multiplication. Also there are multiple different bitwise representations for the same polynomial, so separating them might avoid some confusion.
Apple's code is a simple circular barcode, essentially. I worked in one such format long time ago (ShotCode) - they have some benefits like resistance to motion blur and being easy to parse in low res cameras (compared to qr codes, for instance), but can't encode a lot of data (main drawback). ShotCode's reading algo is proprietary, like Apple's, but they're rather simple to implement.
Great closure from Peter, wish he'd take on Apple's App Clip codes as well. They look like those absolute quadrature encoders with rounded edges.
Even making QR codes fill up a circular shape with noise & rotating it by 45 degrees[for those 3 smaller square markers to line up well] would make it more appealing.
