Contrary to popular belief, this wasn’t made by making a very error-resistant code and sticking an image on top, as most “Logo-QR” codes are made today. AFAIK, the code is not only error-free but also up to spec*, unlike this Bad Apple one that, while also impressive, uses non-standard padding bytes after the actual data.
* Except the XOR mask pattern is not chosen to minimize problematic patterns like solid color areas in the result, obviously – but I’m not buying a $270 standard just to see if it says “should” or “must”.
The URL is very interesting. I’m trying to reverse-engineer the creation process of this code.
The version (size) is 6 (41×41), just small enough to not have alignment patterns (extra squares).
The masking pattern is 2, probably since that encodes as 3 black pixels as part of the picture.
The error correction is set to the minimum or L, allowing the maximum possible number of bytes to be user-controlled. The number of content bits is 1088. Since one byte is used for length, the longest string that can be encoded is 134 bytes.
Here it is “unmasked”:
There can be multiple data types in a QR code. This one first has a bytes section, which readers interpret as text, and then a numeric section.
Blue is the text part of the URL, red-orange is the numeric part, and green is error correction.
The raw data in the QR code is:
Note that the numeric encoding uses 10 bits for each group of 3 digits. Let’s call it triplet-BCD.
The last two bits are only to round up the data section to a whole number of bytes, specifically these 88 bytes:
41 B6 87 47 47 07 33 A2
F2 F6 16 E6 16 C6 F6 76
E6 F7 76 86 57 26 52 E6
36 F6 D2 F2 31 3F 32 FE
F0 00 EE D5 53 12 72 51
20 D5 E1 AA 7F 02 C0 2F
1F 81 02 AA 55 53 81 AA
EA 95 6C 82 3A 3E E1 00
EE B5 59 0A 0B 02 0A 3D
FB BD F7 CB 4D 55 0C 8E
AA AA 0F BF DF ED A9 D0
A2 AA AA AA 55 FA 94 55
57 DD 7F F9 60 5E AA 55
5B AB 8A 75 45 0F AA AB
56 00 00 FB 7F 12 2C AD
53 54 D4 AA 0A 55 55 33
DF F9 80 07 AA 55 5B 80
What follows in the QR code is error correction bytes, 36 of them. The numbers in the right and mid-upper section of the image must have been chosen so that the error correction bytes end up forming the left half of the face, presumably via lots of trial-and-error. However, what I find very odd is that the decimal number the numeric section encodes, which you see at the end of the URL, translates to this in hex:
This is not a floating point error, the triplet-BCD-encoded data really produces 501222037467851 × 2788, a very round number in binary!! I have no idea how that coincides with so many digits being used as part of the face in the weird triplet-BCD encoding.
Also, I haven’t been able to replicate the error correction algorithm: I think it’s the same as reedsolo in Python but
Contrary to popular belief, this wasn’t made by making a very error-resistant code and sticking an image on top, as most “Logo-QR” codes are made today. AFAIK, the code is not only error-free but also up to spec*, unlike this Bad Apple one that, while also impressive, uses non-standard padding bytes after the actual data.
* Except the XOR mask pattern is not chosen to minimize problematic patterns like solid color areas in the result, obviously – but I’m not buying a $270 standard just to see if it says “should” or “must”.
https://analognowhere.com/#815956000955341196626324525376426508044011799516042661339518686677364520931952256954853578523008163894957991180853268570682643959895730628162682682661506593341503383997517938597366696669325062682725512003951964556693309309170041341332991998000490597366
The URL is very interesting. I’m trying to reverse-engineer the creation process of this code.
Here it is “unmasked”:
There can be multiple data types in a QR code. This one first has a bytes section, which readers interpret as text, and then a numeric section. Blue is the text part of the URL, red-orange is the numeric part, and green is error correction.
The raw data in the QR code is:
Note that the numeric encoding uses 10 bits for each group of 3 digits. Let’s call it triplet-BCD. The last two bits are only to round up the data section to a whole number of bytes, specifically these 88 bytes:
What follows in the QR code is error correction bytes, 36 of them. The numbers in the right and mid-upper section of the image must have been chosen so that the error correction bytes end up forming the left half of the face, presumably via lots of trial-and-error. However, what I find very odd is that the decimal number the numeric section encodes, which you see at the end of the URL, translates to this in hex:
This is not a floating point error, the triplet-BCD-encoded data really produces 501222037467851 × 2788, a very round number in binary!! I have no idea how that coincides with so many digits being used as part of the face in the weird triplet-BCD encoding.
Also, I haven’t been able to replicate the error correction algorithm: I think it’s the same as
reedsoloin Python butdoes not yield the expected error correction bytes I can see in the unmasked code (green)…