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.
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.
Drei Typen
Wählen Sie danach, wo der Code sitzen soll. Alle drei teilen denselben Datenvertrag und unterscheiden sich nur in der Silhouette. 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.
Type O — Sechseckfeld
Die Grundform. Rautenzellen legen sich um ein zentrales Suchmuster nach außen.
Type A — dreieckige Silhouette
Ein sechseckiger Kern plus Eckflächen ergibt ein gleichseitiges Dreieck.
Die Netto-Nutzdaten gelten für ECC-M. Alle drei Typen können einen Ersatz-QR danebentragen, sodass ein Weg bleibt, wo ein TL-Code nicht gelesen werden kann.
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 drei 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 | 3 / 3 | ≈ 0.1 s | weitere Messungen nötig |
| Type O — Sechseckfeld | 3 / 3 | ≈ 1.8 s | weitere Messungen nötig |
| Type A — dreieckige Silhouette | 3 / 3 | ≈ 0.86 s | weitere Messungen nötig |
| Variante mit zentralem QR (alle drei Typen) | 8 / 9 | — | weitere Messungen nötig |
Für eine Dekodierung eines Standfotos ist Type Y am kürzesten, O und A brauchen länger. Der Umbau der Suchmuster und die Format-Wiederholversuche haben die Menge lesbarer echter Fotos vergrößert, um den Preis von mehr Arbeit auf einzelnen Pfaden; Y versucht jetzt zuerst einen billigen Pfad und durchsucht erst nach einem Fehlschlag einmal vollständig. Diese Werte dürfen nicht als Live-Zeit bis zum ersten Treffer gelesen werden.
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. Der Generator nutzt diesen geprüften Weg jetzt standardmäßig für die Typen O und A. Standardmäßig bleibt der QR ein Ersatz mit einem Leser-Link; die Nutzdaten selbst bleiben im TL-Körper.
Gemessen am 2026-08-13 · Stichprobe von 9 Fotos aus drei Telefonsensoren (Ultraweitwinkel, Weitwinkel, Tele) · kurze Seite 1440 px. Die Stichprobe ist klein — lesen Sie das als aktuellen Stand, nicht als Erfolgsquote.
Spezifikation und Implementierung
Formatspezifikation und Referenzimplementierung sind unter der Apache License 2.0 veröffentlicht. Reines JavaScript, keine Build-Toolchain, 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 |