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 but>>> from reedsolo import RSCodec >>> rawbytes=b"\x41\xB6\x87\x47\x47\x07\x33\xA2\xF2\xF6\x16\xE6\x16\xC6\xF6\x76\xE6\xF7\x76\x86\x57\x26\x52\xE6\x36\xF6\xD2\xF2\x31\x3F\x32\xFE\xF0\x00\xEE\xD5\x53\x12\x72\x51\x20\xD5\xE1\xAA\x7F\x02\xC0\x2F\x1F\x81\x02\xAA\x55\x53\x81\xAA\xEA\x95\x6C\x82\x3A\x3E\xE1\x00\xEE\xB5\x59\x0A\x0B\x02\x0A\x3D\xFB\xBD\xF7\xCB\x4D\x55\x0C\x8E\xAA\xAA\x0F\xBF\xDF\xED\xA9\xD0\xA2\xAA\xAA\xAA\x55\xFA\x94\x55\x57\xDD\x7F\xF9\x60\x5E\xAA\x55\x5B\xAB\x8A\x75\x45\x0F\xAA\xAB\x56\x00\x00\xFB\x7F\x12\x2C\xAD\x53\x54\xD4\xAA\x0A\x55\x55\x33\xDF\xF9\x80\x07\xAA\x55\x5B\x80" >>> rsc = RSCodec(36); print(rsc.encode(rawbytes).hex()) 41b68747470733a2f2f616e616c6f676e6f77686572652e636f6d2f2313f32fef000eed55312725120d5e1aa7f02c02f1f8102aa555381aaea956c823a3ee100eeb5590a0b020a3dfbbdf7cb4d550c8eaaaa0fbfdfeda9d0a2aaaaaa55fa945557dd7ff9605eaa555bab8a75450faaab560000fb7f122cad5354d4aa0a555533dff98007aa555b80662d719c3ef320500601c1e3f6fd3b517a3e1f06c9a7d4140c7c78af219b3b39f5dd2053does not yield the expected error correction bytes I can see in the unmasked code (green)…