QR Code images are large, unnecessarily complex, and not well detected

[dgmltn]

I'm not sure this is a bug, but I've noticed that the QR codes generated by this library are more complex than the ones generated by zxing. They're also not easily detected. As an example, the top image here is generated by the qrcode-kotlin, and the bottom generated by zxing.

1. What's the reason for all the extra bits?
2. The qrcode-kotlin image is not as easily detected. My phone's camera app doesn't seem to ever detect the qr code. The qr code scanner app will detect, but only if I carefully move around a bit. The zxing qr code, on the other hand, is always detected instantly, and also detected quickly by the camera app.

[slaha]

I don't know if this is related to the issue but this look suspiciously to me:

    val qrCodeProcessor: QRCodeProcessor =
        QRCodeProcessor(data, ErrorCorrectionLevel.VERY_HIGH, graphicsFactory = graphicsFactory)

    /** Computed type number for the given [data] parameter */
    val typeNum = QRCodeProcessor.typeForDataAndECL(data, errorCorrectionLevel).coerceAtLeast(minTypeNum)

Why the qrCodeProcessor does not use errorCorrectionLevel and forces ErrorCorrectionLevel.VERY_HIGH?

[thecoden]

Hi there. I believe @slaha is onto something and the library does not autodetect the density based on data type and error correction well (or at all in terms of the data type). You can manually set it with the following methods withErrorCorrectionLevel and withMinimumInformationDensity. Technically if your code is a url with URL chars only around 25 chars or less, in all uppercase, you can acheive the smallest types/information density. My guess is you could lower the EC to low and get the information density to a type 6 likely.

QRCode
  .ofRoundedSquares()
  .withErrorCorrectionLevel(ErrorCorrectionLevel.LOW)
  .withMinimumInformationDensity(6)
  .withRadius(12)

We have a table of all the information that should be possible somewhere and I'll try to post that so we can measure against it and dig in to fix them at some point. We will pull request if @g0dkar is still accepting. They've done a great job on this library and a little attention would make it exceptional. Support from us as users with pull requests and fixes is definitely warranted to do that.

[g0dkar]

Heya, sorry for the long, LONG delay. Life got in the way quite a lot.

I noticed some mistakes on the code that handles the Error Correction parameter (it was being ignored pretty much)

As for the information density and other parameters, I'll try and add them :D

Thanks for all the contributions and for the patience, if anyone is still following :'(

[g0dkar]

Oh yeah, btw, gorgeous QR Code on the original ticket <3

[g0dkar]

As for some answers:

What's the reason for all the extra bits?

Basically because of the Error Correction Level being set to VERY_HIGH and being ignored if you set it manually

My phone's camera app doesn't seem to ever detect the qr code.

That is due to a misalignment around those 3 large outer squares. I'll to reproduce it so I can tune it better. I spent ages trying to get that correctly hahaha, it is possible that there is a situation where it isn't perfect.

As for the 2nd QRCode, if your phone can't read it its possibly because the outer squares are made of smaller ones hahaha - should be all good tho :(

[thecoden]

Thanks for jumping in @g0dkar. Hope life is going well 👍 You open sourced this. We're grateful for it and happy to help.

If there is an area where I can help in particular or at least support, we'd be happy to check it out. I dug in with a teammate a bit and we were starting to sort things out, but your context would probably make it much easier to produce a meaningful pull request for you to merge.

So far our biggest issue has been the higher density codes for ec levels and densities that we would expect a lower density to work, but it seems you know the cause for that. One thing we would be willing to chip in is something that allows for auto scaling the density to match the content type (at least for strings). We use all uppercase urls quite often to allow for the lowest density codes and that's what originally caused us to look into it further.

[g0dkar]

Hey everyone, first part of the fixes and improvements (basically the ECL issue) have just been released on version 4.2.1 😁

Next days I'll try and tackle some issues with quality, alignment and encoding of large payloads :)

[g0dkar]

Heya @dgmltn, @thecoden and @slaha!

I just released v4.3.0 with some improvements to the information density parameter. Now you can:

1. Set the parameter yourself and most important...
2. Force the library to use it, instead of computing a value and using yours as a minimum.

Let me know if these changes makes things better or working as you expect 😀

If not, also let me know so we can improve the library further <3

Thanks for your patience and kindness, it really means a lot to me!

[Edit: it also have some fixes you guys suggested, they were part of the v4.2.1 released earlier]

[dgmltn]

Hey @g0dkar, thanks for your work on this. That helps a bit but I'm not sure how to manually calculate the information density. When I made the string a bit longer (than just "hello, world"), the app crashed like:

java.lang.IllegalArgumentException: Code length overflow (116 > 72)

I made a simple app (here), that I've used to compare different qr code libs.

The output even with a manually specified information density is still not quite the same as (e.g. QRose). For one thing, on very short strings, other libs don't seem to put the square in the bottom right corner either.

[g0dkar]

Heya @dgmltn, I'll have a good look at it later today! From browsing QRose source, it uses a bunch of classes from this project, which is great :D (and I'm quite happy and humbled to know hahaha)

I'll see how some stuff is being done and, if the author allows it, maybe even incorporate some stuff on the library 😀 - One thing QRose is doing which we're not is automatically setting an ECL value 🥇 (I'll definitely add this hahaha)

As for the difference, the information density parameter is a weird one. That extra square is because of the ECL (try setting it to LOW, for example, and that square won't show up)

---

Let me try and explain it a bit:

TL;DR Information Density is a mix of how much data is being encoded and how much Error Correction data needs to be added - Try changing it to a lower ECL ;)

First and most important: QRCodes are a visual representation of an array of bytes.

Each byte needs 4 squares to be represented. The Information Density parameter is important when decoding the QRCode. Encoding is just a matter of building the array of bytes and rendering them. This library doesn't decode QRCodes, but the purpose of a QRCode is to be decoded :P - this library tries to encode data in a way decoders will have an easy way of decoding them ^^

Now, lets go about decoding QRCodes: Again, decoding is just a matter of rebuilding the original array of bytes and then making it back into a String or other data type.

QRCodes were designed to be read by any camera. That means that the input for a decoder is an image (a JPEG, or PNG for example). So they might be crumpled, the camera just sort of suck, blurry images, printer was almost out of ink, they're laminated so there's a lot of glare on them, etc.

The 3 large squares on the outside are used to find where is up/down when a camera reads a QRCode because a decoder needs to go over the squares in a particular way.

The other extra feature is quite hidden but it is the Error Correction. In order to make sure QRCodes can almost always be read, a bunch of the squares on it build what is known colloquially as "Error Correction".

Its an algorithm that can check if the decoded data is the same as the original AND in some cases correct the data to make sure it IS the same as the original.

To do that, it needs to add extra information embedded into the QRCode data.

Having said all that context, now we can go on to the questions:

1. Why is it breaking? Here's where the "trickyness" of the Information Density comes into play. It needs to encompass the data being encoded AND the extra data needed by the error correction.
2. Why are the QRCodes so different? From reading QRose's code, it seems to boil down to basically the fact that it computes an ECL for the data being encoded instead of going with VERY_HIGH as a default.
3. And those extra squares? Those come from the Error Correction extra data! To be extra safe and sure that the QRCode is being read correctly, it might add extra squares to tell the algorithm reading the camera input "hey, you're on the right track, keep it up!" 😛
4. Why is the default ECL VERY_HIGH? No particular reason other than to make sure the QRCodes will be easily readable by pretty much any camera ^^

Suggestions (fixes?)

Knowing all that, what we can do is:

• Try out the same data but with lower error correction levels: I took the liberty of doing that for the sake of explanation 😉 (check the images below)
• Find a way to automatically set a sensible ECL (action item for me): Right now this is a bit tricky as I myself don't know how hahaha, but I'll check how QRose does its auto-selection of ECL and implement something like it!

---

QRCodes

Here are two QRCodes generated with this code (new example)

First: using LOW for ECL makes it the same as QRose's

Data: "Hello, world.", ECL: LOW, Information Density: 1

Second: going higher than MEDIUM it looks closer to yours (with the extra square)

Data: "Hello, world.", ECL: HIGH, Information Density: 2

[g0dkar]

Also, a question to everyone following the thread: how easy was to use the library? Is there anything I can do to make it easier to use?

I'd really like this to be a powerful yet easy-to-use library ^^

[dgmltn]

Thanks for the detailed explanation! As far as "is it easy to use", I think it is! And it's flexible. It would be cool if there was a way to draw to a canvas directly instead of forcing it to go through a bitmap, though. (Although, I still figured out how to do that as you can see in my app). If that's what you intended, cool! But writing that loop made me feel a bit like I was looking into internals a bit too much.

[g0dkar]

It would be cool if there was a way to draw to a canvas directly ...

I could swear that was available. If I'm not mistaken, there's that option on the JVM version.

It's a great suggestion and point.

I'll see how I can implement/expose that somehow 😄

The annoying part might be adding the offset from where the QRCode would start to be drawn.