Joyn: wrong QR-code

[on4aut]

I scanned a card with a QR-code in the app Catima. When I view the QR-code in the app for this card, the QR-code is different from the original. What is wrong ?

[TheLastProject]

There is not necessarily anything wrong. The important part is that the content of both codes are the same.

The reason there can be differences are because there are multiple different ways to encode the same text and Catima works as follows:

1. Read the QR code to get the value in it (in this case, https://scan.joyn.be/qr/5F8E3196-E078-4A1E-A0CB-EB2A8CCCB27F is the text actually scored in the QR code)
2. Store the value in the database
3. When you open the loyalty card in Catima, a QR code image is generated with the text value in it based on the screen size to make sure it fits well

The part that is most confusing is that your joyn loyalty card says CW5DS3QGHA967ZUM below the QR code, but the text actually stored in the QR code is https://scan.joyn.be/qr/5F8E3196-E078-4A1E-A0CB-EB2A8CCCB27F.

I would think this should still work fine in stores (please tell me if it does or doesn't!).

There are however a few things that can be done to make the user experience better:

1. Make it possible to change the Card ID of a loyalty card in Catima without overwriting the barcode value too (because in your case, it would be useful to set the Card ID to CW5DS3QGHA967ZUM but keep the QR code on https://scan.joyn.be/qr/5F8E3196-E078-4A1E-A0CB-EB2A8CCCB27F but right now if you would edit the Card ID you would have to go to the barcode tab and choose Set barcode value and put the URL there again).
2. Detect joyn loyalty cards and explain the user they do a few weird things and guide them through setup to make things less confusing.
3. See if there is some way to try to generate a QR code in the same exact format as the scanned QR code (this is probably very hard to code though)

I'll work on 1 and possibly 2. Would be great if the community could help with some things too.

Thanks for your report, it helps me improve the app!

[TheLastProject]

Okay, I have implemented the first of this in 929633e4dda0382a93bf10a82a5d9414f3627c47.

[ILoveFOSS]

Reading this report rang a bell as I have seen this behaviour (whole URL encoded, QR code on card and encoded by Catima look differently) before but didn't mind. Also, my cards from:

1. Depot Austria (furniture store)
2. Flying Blue (AF & KLM frequent flyer program) behave this way.

Testing all three (incl. on4aut's Joyn card) with Stocard, encodes the same QR codes as Catima does. Therefore, I believe it's due to an unusual error correcting level those shops use encoding their codes on the cards. It would require some time playing around with a barcode encoder to figure out the exact error correction level these shops use. I don't think its required though as long as the differently looking codes work.

I have tested https://github.com/TheLastProject/Catima/commit/929633e4dda0382a93bf10a82a5d9414f3627c47 with my two cards, and it works fine! Thank you! However, I discovered a bug when exporting and importing cards with different Card IDs and barcode value. I created a separate issue for it https://github.com/TheLastProject/Catima/issues/235.

[on4aut]

Today I went back to the shop, and I used the QR-code as generated by Catima - and it worked ! That's good enough for me :)

[chilledfrogs]

I noticed a similar phenomenon with Monoprix loyalty card barcodes ("card number" under the barcode doesn't correspond at all with the barcode itself), if we are going to start maintaining a whole list of services with these kinds of annoying quirks 😅

[JohnDoe-JohnDoe]

I have been looking for an app to store exact copies of QR codes (other than a photo or scan) but so far have not found one. May I ask why "See if there is some way to try to generate a QR code in the same exact format as the scanned QR code" would be hard to code? Surely the scanner/reader has to identify the pattern before it decodes it, why can't it just store the result rather than decoding it? Then recreate it block for block. Once the size has been determined, it appears to be a simple grid of squares which are either filled or empty so simple binary would result in 11011100110001100 for the 1st line of the example in the photo, excluding the corner locators, or 111111101101110011000110001111111 including the corners. Thanks JD

[TheLastProject]

@JohnDoe-JohnDoe I think you're looking for #506 and #244 instead, as that issue is about generated barcodes differing from the scanned barcodes in minor ways. This issue is about how the value displayed below the physical Joyn loyalty card isn't actually the same as the value stored in the QR code.

[JohnDoe-JohnDoe]

@TheLastProject Not really, the original post states "I scanned a card with a QR-code in the app Catima. When I view the QR-code in the app for this card, the QR-code is different from the original" And the picture shows 2 different QR codes. Later in the thread the fact that the "values" are different but that's not the original question or what I am asking.

244 is about EAN barcodes and #506 is about re-encoding the data to produce the same QR code, which is similar, but not what I am asking.

Why can't the scanner read the pattern WITHOUT decoding it and just store the position of the blocks which make up the QR code (it's a very simple block pattern) so it can be recreated exactly the same. As I said, the scanner must have picked up the position of the blocks in order to decode the information. It would be very simple to store the information in binary as I showed. The stored QR code would then definitely work as well as the original. What am I missing which makes this had to code?

[TheLastProject]

Okay, I hadn't read the original report clearly then. However, the part you are talking about is described in more details in #506 so I still believe that is a better issue for this.

The simple answer to "Why can't the data be stored without decoding" is because that's not how it correctly works and, if zxing (the library that Catima uses to detect and read the barcode) supports exposing that info (I haven't checked), would require a complete rewrite of many core parts of the app. It would also require complete new code to show barcodes and a second codepath for the case of users manually entering a barcode instead of scanning it with their camera (while this is currently one shared codepath). It also requires a big change to the database format, requiring a migration path for all existing barcodes. So, while it sounds simpler, it is actually the more difficult path to walk given the current codebase.

[Korb]

The same situation:

(on the left is the original QR code from another application for storing loyalty cards, on the right is a screenshot of Catima scanning this code). It can be seen that the QR codes are different. A QR code is a text string, a web link to a description of the store's loyalty program. I have not yet checked whether the new QR code works, but it confuses me when the “copied” QR code differs from the appearance of the QR code on the plastic card.

[TheLastProject]

It's indeed the same "issue": Catima just asks zxing to generate a QR code of a certain size and it auto-picks a reasonable error correction level which might not be the same as the original so the code may differ (even if the content is the same). I'm putting "issue" between quotation marks as it is very very rare to cause any actual scanning issues, it just causes confusion.

I will, however, close this issue because the OP reported the card did work at the store and I think the existing #939 describes the issue more clearly and is thus easier to track.

[TheLastProject]

Actually wait, I wanted to keep this open not for the QR code thing but for the fact that Catima puts https://scan.joyn.be/... at the start of the barcode while that's not on the actual card.

It's correct behaviour on Catima's side, but I want to track the stores that put another code on the card than actually in the image for if we ever start building some kind of database of stores.

The QR code thing though is more relevant to issue #939 :)