Well done on Your Implementation. One Suggestion!

[dhruvaura]

Hi @tarukosu

Currently, your implementation reconstructs the QR code texture using the ZXing package. However, the generated texture differs from the original QR texture scanned by the user.

Would it be possible for you to generate a texture that closely matches the original QR code? This would help improve QR tracking performance, as providing an accurate texture to the AR image tracking system (in the Mutable library) enables faster and more consistent tracking.

[tarukosu]

Currently, this library reconstructs the QR code image from the decoded data using ZXing, and then uses that generated image as the tracking target.
Because of that, it cannot support QR codes that have custom / designed appearances (e.g. non-standard styling or decorations).

[dhruvaura]

@tarukosu Thanks for your reply.

Yes, I understand that styling or decoration cannot be added.

However, when scanning a simple standard QR code, it should ideally generate the same texture as the original QR texture being scanned.
Currently, the ZXing implementation reconstructs the QR code from the given content, but the generated texture looks visually different from the original QR texture.

If we can reconstruct the exact same texture, it would significantly improve tracking performance, as the image tracking system would receive an identical texture to the one being scanned, enabling faster and more reliable tracking.

If that achieve then you can able to sell this asset on Asset Store.

Since last week I am also trying to figure out how to reconstruct the exact same texture. I tried to construct using same configuration of created QR, but that not worked.

Thanks Again!

[tarukosu]

For simple standard QR codes, the reconstructed texture should match the original texture.

Could you share the QR codes that didn’t reconstruct correctly?
If you can provide them, I can also take a look on my side when I have time.

[dhruvaura]

@tarukosu

Here is QR code which not reconstruct correctly.

Here our test video: https://drive.google.com/file/d/1dRtI2yLbaJu7Qu12DSsR52thJIAzYf--/view?usp=sharing

[tarukosu]

You’re correct — the reconstructed QR code looks different from the original one.
It seems that the character count specified inside the QR code differs between them.
From what I’ve checked, ZXing doesn’t appear to provide access to the character count information, so it might be difficult to reconstruct the QR code exactly.

[tarukosu]

As a workaround, could you try using a different QR code generation tool?

[dhruvaura]

@tarukosu
I tried two packages which generate QR code at our backend system.
https://www.npmjs.com/package/qrcode
https://www.npmjs.com/package/@zxing/library | I was expecting that the ZXing Node package and our Unity implementation would generate visually identical QR codes since both use the ZXing library. However, that didn’t work as expected, even though both are based on ZXing, they produce visually different QR codes. I tried same parameter during generation at node and unity.

Creating QR from both library and tested but see that reconstructed QR is different looks different from the original one.

I have tried opencv to extract texture from camera feed, but during that implementation feel that it's need many days to implementation and later see that it is feasible or not.

Let me know if you have any other idea to reconstruct the QR code exactly.

[tarukosu]

When a text contains a mixture of numbers and lowercase letters, it can cause mixed encoding modes, which may result in different generated textures depending on the algorithm.
If possible, since uppercase letters allow the QR code to use the Alphanumeric mode, could you try converting the alphabetic characters in the text to uppercase?

[dhruvaura]

@tarukosu Thanks your idea worked in my initial tests. It generate reconstruct same visually.
I'll update how works on further detail test.
This will helpful to many dev.