Idea: Generate a score for a barcode that tells you how 'scannable' it is.

[NigelThorne]

With the ArtQRCodes I frequently find I want to remove a few dots just to make the image a little nicer. When I do that manually I end up with a qr code that seems to scan fine... but it would be ace to score a qr code to say how redundant it is now.. or how well it will scan at different sizes... maybe.

[codebude]

Hi @NigelThorne ,

calculating such score at runtime does not make so much sense, if you later remove single dots/pixels. Latest if you remove the first pixel, the score wouldn't be accurate any longer.

Calculating such score for a given QR code would mean that QRCoder must be able to read/analyze QR codes. But since QRCoder is a generator only and since there are currently no plans/capacity to make it a reader, too, I can't fulfill this request.

I'm not sure in how far you are familiar with the QR code standard at all, but maybe the following information already helps you:

The amount of "redundancy"/error correction data depends on the so called ECC level (=error correction level). You can pass/define the ECC level, when creating the QRCodeData. The levels are defined as follows (source):

• Level L (Low) 7% of data bytes can be restored.
• Level M (Medium) 15% of data bytes can be restored.
• Level Q (Quartile) 25% of data bytes can be restored.
• Level H (High) 30% of data bytes can be restored.

So if you set ECCLevel.H in QRCoder you might remove up to 30% of the data modules, before the code becomes unreadable. If you render a logo onto the QR code with QRCoder you have to define how much percent of the QR code the logo should cover.
So if you for example render a logo with 15% coverage and choose ecc level Q like so...

var gen = new QRCodeGenerator();
var data = gen.CreateQrCode("This is a quick test! 123#?", QRCodeGenerator.ECCLevel.Q);
var bmp = new QRCode(data).GetGraphic(5, Color.Black, Color.White, icon: (Bitmap)Image.FromFile("C:\\mylogo.png"), iconSizePercent: 15);

...then ~15% of the 25% recoverable data may already be gone. Or in other words: you can remove at maximum 10% more, until the code definitely gets unreadable.

So far, so good. Let me give you one more hint. The ECC level defines only how much of the payload data can be removed, to keep still maintain readability. The key here are the words "payload data". If you remove the format/versionen data or finder patterns, the code might break, even if you change only some bits of the code. So keep in mind to only remove/change the payload data, but never the functional modules as shown below:

(image source)

That said, let me answer your last question ("[...] or how well it will scan at different sizes [...]"). The size of the graphic in theory doesn't matter (as long as you don't shrink it so far that a black/white module becomes smaller than a pixel and thus wouldn't be rendered/shown on screen). As long as each data module is represented as at least one pixel, the code is formally correct and theoretically readable. Practically it might become unreadable, because the reader's/scanner's camera isn't sensible enough to clearly read each pixel. But this heavily depends on the camera of the device. Maybe an iPhone 13 with it's good camera can scan QR codes with a pixelsPerModule=2 where in opposite an iPhone 3GS would totally fail. So from my point of view it doesn't make sende to calculate a readability score that relates to the size of the codes, because the readability heavily depends on the reading hardware...

[NigelThorne]

That makes sense. I guess the score I'm thinking of is "how good would your hardware have to be". As you say.. sounds like this is out of scope for a QR Code generator :) Maybe a sister project that knows all the phones and what their capabilities are, and let you know what phones at what distances would be able to read the code and different sizes. Then people can decide who their audience is and make educated guesses.