QR liest sich gut.
Es war nur nie schön
Plakate, Verpackungen, Visitenkarten — QR ist überall, und ein Schwarz-Weiß-Quadrat auf ein wochenlang gestaltetes Layout zu setzen, hat immer wehgetan. Doch QR sieht so aus, weil es so aussehen musste: So baut man einen Code, wenn eine Kamera und ein Prozessor von 1994 ihn überhaupt lesen sollen.
Diese Beschränkungen sind weitgehend gefallen. Handykameras und Rechenleistung haben Luft. Statt allein der Erkennung nachzujagen, ist diese Luft hier darin gelandet, dass der Code sehenswert ist. Das ist kein Ersatz für QR — es ist ein Platz daneben. Das Ergebnis ist ein 3D-Barcode — flach gedruckt, aber räumlich gelesen.
Typen
Wählen Sie danach, wo der Code sitzen soll. Die flachen Typen teilen denselben Datenvertrag und unterscheiden sich nur in der Silhouette; True 3D H ist die echte Würfelerweiterung der Y-Gruppe mit eigenem Format. Jeder Code unten enthält https://tl.estre.so.
Type Y — einzelner Würfel
Drei n×n-Flächen. Ein geschlossenes Zeichen, gut für Beschilderung und Merchandise.
True 3D H — echte Würfelerweiterung der Y-Gruppe
Ein eigenes Format für einen echten Würfel, mit unterschiedlichen Daten auf 1…6 Flächen. Der Generator exportiert auch ein Rotationsvideo (MP4), Papiervorlagen und 3D-Druckdateien.
Type O — Sechseckfeld
Die Grundform. Rautenzellen legen sich um ein zentrales Suchmuster nach außen.
Type C — ultrahohe Kapazität mit Kerbe
Die Kerbe auf 3 Uhr legt Ausrichtung und Typ schon in der Silhouette fest. C0–C3 sind für Scans im Nahbereich gedacht; ab C1 holen Sie den Code näher heran oder vergrößern ihn.
Type A — dreieckige Silhouette
Ein sechseckiger Kern plus Eckflächen ergibt ein gleichseitiges Dreieck.
Type K — Hexagramm
Ein Dreieck vereinigt mit seinem 180°-Bild. Größte Nutzlast bei gleichem k.
Die Netto-Nutzdaten gelten für ECC-M. Alle Typen, auch H, können einen Ersatz-QR danebentragen, sodass ein Weg bleibt, wo ein TL-Code nicht gelesen werden kann. Bei H sitzt er standardmäßig in der linken oberen Ecke.
Warum jetzt
QR war die richtige Antwort seiner Zeit. Zwei Werte, quadratische Module, große Suchmuster — jede dieser Entscheidungen gab es, damit auch eine schwache Kamera lesen konnte. Unter diesen Bedingungen war der Verzicht auf Ästhetik vernünftig.
Diese Voraussetzung hat sich geändert. Heutige Handykameras sind damit nicht zu vergleichen, und Echtzeit-Videoverarbeitung läuft im Browser. Der gewonnene Spielraum konnte in Dichte fließen — oder in das Aussehen. Deshalb gibt es dieses Format.
Dafür wurde die Dichte aufgegeben. Rautenzellen nutzen die Fläche schlechter als quadratische Module. Dieses Format tritt nicht im Wettbewerb um Dichte an. Wer viel unterbringen muss, ist mit QR richtig.
Funktionsweise
1. Zelle = drei Rauten
Eine Rhombille-Parkettierung teilt jede sechseckige Zelle in die Flächen T, L und R.
2. Reihenfolge = Symbol
Das Ordnen der drei Luminanzen ergibt 3! = 6 Fälle — eine Ziffer zur Basis 6.
3. 3 Ziffern = 1 Symbol
Reed–Solomon über dem Primkörper GF(211) korrigiert Fehler.
Was dadurch frei wird
Invariant gegenüber monotonen Transformationen. Globale Lichtwechsel, Gamma und die Tonwertabbildung eines Druckers sind monoton — sie können eine Reihenfolge nicht umstellen. Überlebt die Reihenfolge, überlebt der Wert.
Das Rendering bleibt frei. Der Datenvertrag lautet nur „die Reihenfolge zwischen den Flächen plus ein Mindestabstand“. Darin sind Farbe, Textur, Verläufe je Fläche und Animation offen. Genau diese Freiheit ist der Sinn des Formats.
Schön wird davon aber nichts von allein. Frei wird der Vertrag, nicht das Ergebnis. Was Sie darin zeichnen, bleibt Ihre Arbeit.
Scanner — Stand der Dinge
Der Decoder funktioniert. Alle vier Typen werden auf Fotos echter Geräte gelesen; offen sind Genauigkeit und Tempo. Jede Zeit unten ist eine Dekodierung eines Standfotos von einem echten Telefon — weder die Zeit bis zum ersten Treffer noch eine Erfolgsquote im Livebetrieb.
| Typ | Echte Fotos dekodiert | Eine Dekodierung, Standfoto | Live-Prüfung |
|---|---|---|---|
| Type Y — einzelner Würfel | 9 / 16 | ≈ 1.8 s | weitere Messungen nötig |
| Type O — Sechseckfeld | 29 / 48 | ≈ 1.9 s | weitere Messungen nötig |
| Type A — dreieckige Silhouette | 18 / 19 | ≈ 2.4 s | weitere Messungen nötig |
| Type K — Hexagramm | 18 / 27 | ≈ 3.1 s | weitere Messungen nötig |
| Zentrale-QR-Variante (alle vier Typen) · 2026-08-13 | 8 / 9 | — | weitere Messungen nötig |
Eine Dekodierung eines Standbilds. Type O ist jetzt am schnellsten; A, K und Y liegen dicht dahinter. ⚠ Eine frühere Fassung dieser Seite nannte Type Y als schnellsten — das war eine Stichprobe von 9 Fotos, und bei größerer Stichprobe hat sich die Reihenfolge umgedreht. Lesen Sie das nicht als Live-Zeit bis zum ersten Treffer.
Die Zeit einer Dekodierung auf einem Standfoto sagt nichts darüber, wie sich Live-Scannen anfühlt. In der ersten Messreihe auf einem echten Gerät konnte ein schnelles Einzelbild trotzdem zu einem späten ersten Treffer führen, wenn viele Bilder nötig waren, und die Reihenfolge der Typen wich von dieser Standfoto-Tabelle ab. Diese Reihe umfasst ein Gerät und eine kleine Stichprobe — deshalb vergeben wir noch keine Live-Bewertung.
Auch die Aufnahmebedingungen wirken stark. Gemessen war 9 Pixel je Zelle die Untergrenze der Dekodierung, und bei gleichem Abstand fasst ein Ultraweitwinkel den Code kleiner und fällt unter diese Linie (Ultraweitwinkel 7.6 px gescheitert / Weitwinkel 9.1 px erfolgreich). Deshalb bietet der Scanner eine Objektivwahl an.
In der Variante mit zentralem QR ersetzt ein QR-Block das zentrale Suchmuster. Dessen Suchmuster liefern den Einstieg für Position und Ausrichtung, mit dem der umgebende TL-Körper dekodiert wird. Standardmäßig bleibt der QR ein Ersatz mit einem Leser-Link; die Nutzdaten selbst bleiben im TL-Körper. Seit dem 2026-08-28 nutzt der Generator für die Typen O, C, A und K standardmäßig das Suchmuster Zentraler TL mit einem äußeren Ersatz-QR in der linken oberen Ecke; der zentrale QR bleibt eine der wählbaren Varianten. Die Zentral-QR-Zeile der Tabelle oben misst diese Variante (Runde vom 2026-08-13).
Type C und True 3D H sind nicht in der Tabelle oben enthalten; für H sind Erkennungsraten und FPS mit realen Kameras nicht garantiert. Der Scanner hat zwei Engines: R1 liest flache TL-Typen Bild für Bild, und R2, die Standard-Engine, sammelt Type Y und H über mehrere Frames. Bei H erscheint ein Ergebnis erst, wenn die nötigen Flächen die RS/CRC-Prüfung bestanden haben. In Browsern mit BarcodeDetector liest R2 auch gewöhnliche QR-Codes; ein Link aus einem QR-Code wird nie automatisch geöffnet — prüfen Sie die Adresse und tippen Sie dann darauf.
Gemessen am 2026-08-27 · Stichprobe von 110 Fotos (jedes bei 960 · 1440 px kurzer Seite versucht). ⚠ Der Großteil der Stichprobe ist vom Monitor abfotografiert — das sind keine Druck- oder Vor-Ort-Werte. Und 123 der 233 Korpusbilder sind Grenz- und Versuchsaufnahmen, die gerade deshalb aufbewahrt werden, weil sie noch nicht dekodieren — sie sind hier ausgeschlossen. Nur die Zentral-QR-Zeile stammt aus der älteren Runde vom 2026-08-13.
Spezifikation und Implementierung
Formatspezifikation und Referenzimplementierung sind unter der Apache License 2.0 veröffentlicht. Reines JavaScript, Node.js-Buildskripte im Repository, null Laufzeitabhängigkeiten — es läuft als einzelne HTML-Datei.
Nur den Decoder zu implementieren gilt bereits als konforme Implementierung. Verbreitung beginnt auf der Leseseite.
| Site | Rolle | Status |
|---|---|---|
| tlcube.estre.so | Generator | aktiv |
| tlscan.estre.so | Scanner | aktiv — Stand › |
| tl.estre.so | Übersichtsseite | Sie sind hier |