Show HN: An interactive demo of QR codes' error correction | Hacker News Reader

Show HN: An interactive demo of QR codes' error correction

qris.cool

109 pointsXiione11 comments

Hi HN! This is a hobby project of mine that recently landed me my first interview and helped me get my first internship offers.

Draw on a QR code, and the health bars will accurately display how close the QR code is to being unscannable. How few errors does it take to break a QR code? How many errors can a QR code handle? Counters at the bottom track your record minimum and maximum damage. (Can you figure out how to break a QR code with 0.0% damage to the actual data region?)

Also, click on the magnifying glass button to toggle between "draw mode" and "inspect mode". I encourage you to use your phone's camera to scan the code as you draw and undo/redo to verify that the code really does break when the app says it does.

I wrote the underlying decoder in C++, and it's compiled to WebAssembly for the website.

I hope you find it interesting.

Open articleView on HN

Super cool interface to explore. It took a bit of playing around with the UI to understand all the features. My only feedback would be to try to make the "Continue" part of the flow to get to the sandbox easier to discover.

Thanks! The "continue" was one of those things that started off as a placeholder and didn't change much, I'll definitely be adjusting it.

Oh, this is cool. My favorite part is being able to mouse over the health bars at the right, and see exactly which bits they draw from in the code itself.

Very cool work! I really like being able to see the blocks and directly interact with them. It's nice to feel out how the ECC works. I can see myself using this to draw custom QR codes in the future!

This is really cool! Thanks for sharing!

Is there a way to get it to compute and visualize the MAXIMUM possible error rate for any given QR code? Like what is the greatest number and arrangement of pixels that could be altered before the QR code is no longer readable?

(Bonus: Is this a setting that can be controlled during QR code generation, based on version number or error correction level, etc.? Can you make some sort of huge and very complex QR code with a lot more redundancy than a smaller one?)

Thanks for checking it out! Essentially, for any given QR code the maximum error rate is reached when you deplete every block's health bar to 1 remaining slice, making sure to invert every pixel in each codeword you've touched (the individual tetris-piece shaped chunks), and then introduce one more single pixel error in any block. This is actually independent of the arrangement of corrupted codewords within each block.

The amount of redundancy is determined solely by the specific version-ecLevel pair a code has. So, the code with the largest amount of redundancy (in bytes) is one that has version 40 and EC level H - a staggering 2.43kB of redundancy vs. 1.28kB of data! See this particular sample: https://qris.cool/decode?sample=135

Awesome! I love seeing how the blocks are affected by twiddling bits.

It's surprising how much data you need to corrupt while still being able to read the QR code, that's what I'd take out from this. The demo is interesting in that respect, but I do think it's somewhat incomplete.

It seems to be missing some explanations regarding how the code is structured and how it performs error correction. I feel like there's little point in interacting with a system you don't understand or not trying to understand. And I also think there are cool ways to make those things interactive as well. Pick an image, then explain what the little squares in the corners are for and provide little interactivity to see how they affect the decoding. Then move on to the error correction. This step-by-step style of interactivity may be better, I'd think about that.

As for what is there, the first thing I don't like here is icons. The four icons in the lower-right corner (result data, format info, ..) are hard to distinguish, and are hard to correlate with the "history" tab. I'd probably either make them slightly different color, or actually simplifying these icons further might be a better option, just because they're so small.

But yeah it is pretty hard to tell what I'm interacting with, unfortunately. I don't know pretty much nothing about QR codes, and I don't know what the different kinds of errors are, what "EC" stands for etc.

UI should probably be rethought as well, because before I was writing the comment I had no idea I could switch a brush. Hell, I had no idea I was changing colors (the cursor covered half the space of the pixels, so I couldn't tell)

The idea's cool though, good work

Thank you so much for the honest feedback. One of the reasons I tried to not get into the math details is because the preliminaries would be somewhat lengthy, some people would not be familiar with what a finite field is so explaining even that succinctly would be its own challenge for me. But for those that the concepts are within reach for (like the folks here on HN), you are right that I ought to make some effort to explain what is going on, at least intuitively. As for the UI considerations, great feedback, I'll definitely take it all into account when re-designing. I'm open to additional suggestions from everybody.

Ultimately I'm glad that I was able to get the main point across. That is, that QR codes can take a lot more abuse than one might assume. Thanks for checking my work out!

How can you say that you 'don't know pretty much nothing about QR codes' and that you 'feel like there's little point in interacting with a system you don't understand or not trying to understand', while feeling qualified enough to write a critique claiming a demo of said thing you know pretty much nothing about is incomplete?

You don't know what EC stands for but you have an opinion on when the error correction should be demoed? And the first thing you don't like are the icons?

OP, if I were you I would ignore this critique entirely. This is a fantastic demo. The usability was spot on (I learned a lot in a very short amount of time) and your /repos readme is _exactly_ what I wanted to read. It is perfectly executed.

I'm gonna dig into your code a bit more tomorrow, but you should be very proud of this. You have a bright future ahead of you.

Thanks so much for your kind words! As a principle I try to at least listen to what everyone has to say, I wish I could make everybody happy but in the end I incorporate the feedback I'm convinced of/already agree with. Let me know if you have any thoughts on my code, and thank you for the github follow :)

Reply on news.ycombinator.com