QR encodes data in black-and-white squares — right for a 1994 camera. Cameras changed; the squares didn't. So we spent the slack on looks. TLcube splits a hexagonal cell into three rhombic faces and encodes data in the rank order of their brightness, not in absolute values — shift exposure, gamma or contrast and the answer survives. Four silhouettes, an optional fallback QR, browser generator and scanner. Free to use, like QR. No licence fee, no per-scan cost. Apache-2.0.
Hi Product Hunt 👋
This started as an itch rather than a plan. I kept designing posters and packaging where the last thing to go on was a black-and-white square, and it always felt like an apology. But QR looks the way it does for a reason — it had to be readable by a 1994 camera with almost no compute. Two levels, hard edges, a big finder. Under those constraints, giving up on looks was the rational call.
That constraint is gone. So instead of spending the extra headroom on more density, I spent it on how the thing looks.
TLcube splits a hexagonal cell into three rhombic faces and reads the ORDER of their brightness — 3! = 6 orderings, one base-6 symbol per cell. The nice consequence is that it doesn't care about absolute brightness. I have test frames where the whole code is crushed into a 40-step luminance range out of 255 — barely visible to the eye — and the reference decoder still returns the URL.
The honest trade: it is less dense than QR. The rhombic cell is worse than a square by area. This isn't trying to replace QR; it's trying to earn a seat next to it. Every type can carry a fallback QR in the same print, so there's never a dead end.
Both the generator and the scanner run entirely in the browser, and the stable scanner processes frames on-device. Spec and reference implementation are Apache-2.0 — the format is meant to be free to use.
Still very much in the "improving recognition" phase, and the numbers on the site are the real ones, footnotes and all. Would genuinely like to hear where it breaks for you.