Il QR si legge bene.
Non è mai stato bello
Manifesti, confezioni, biglietti da visita — il QR è ovunque, e mettere un quadrato in bianco e nero sopra un progetto curato per settimane è sempre stato un dispiacere. Ma il QR ha quell'aspetto per un motivo: è ciò che si costruisce quando una fotocamera e un processore del 1994 devono riuscire a leggerlo.
Quei vincoli sono in gran parte caduti. Le fotocamere dei telefoni e la potenza di calcolo hanno margine. Così, invece di rincorrere solo il riconoscimento, quel margine è stato speso perché il codice valga la pena di essere guardato. Non è un sostituto del QR: è un posto accanto.
Perché proprio ora
Il QR era la risposta giusta per il suo tempo. Due valori, moduli quadrati, grandi pattern di ricerca — ognuna di quelle scelte serviva a far leggere il codice anche a una fotocamera debole. Con quei vincoli, rinunciare all'estetica era razionale.
Quella premessa è cambiata. Le fotocamere dei telefoni di oggi non hanno nulla a che vedere con quelle, e l'elaborazione video in tempo reale gira dentro un browser. Quel margine poteva andare alla densità — oppure a come appare. È per questo che il formato esiste.
In cambio si è rinunciato alla densità. Le celle romboidali sono meno efficienti in superficie dei moduli quadrati. Questo formato non compete sulla densità. Se serve trasportare molto, lo strumento giusto resta il QR.
Tre tipi
Scegli in base a dove verrà messo. Tutti e tre condividono lo stesso contratto dati e differiscono solo per la silhouette. Ogni codice qui sotto contiene https://tl.estre.so.
Type Y — cubo singolo
Tre facce n×n. Un segno compatto, adatto a insegne e gadget.
Type O — campo esagonale
La forma base. Le celle romboidali si dispongono attorno a un pattern di ricerca centrale.
Type A — silhouette triangolare
Un nucleo esagonale più le toppe d'angolo, che formano un triangolo equilatero.
Il payload netto è riferito a ECC-M. Tutti e tre i tipi possono portare accanto un QR di riserva, così resta una via anche dove il codice TL non è leggibile.
Come funziona
1. Cella = tre rombi
Una tassellatura rhombille divide ogni cella esagonale nelle facce T, L e R.
2. Ordine = simbolo
Ordinare le tre luminanze dà 3! = 6 esiti — una cifra in base 6.
3. 3 cifre = 1 simbolo
Un Reed–Solomon sul campo primo GF(211) corregge gli errori.
Che cosa si libera
Invariante rispetto alle trasformazioni monotone. Variazioni di luce globale, gamma e mappatura tonale della stampante sono monotone: non possono cambiare un ordinamento. Se l'ordine sopravvive, il valore sopravvive.
Il renderer resta libero. Il contratto dati è solo «l'ordine fra le facce, più una separazione minima». Dentro quel vincolo, colore, texture, gradienti per faccia e animazione sono tutti aperti. Quella libertà è il senso del formato.
Non rende però nulla bello da solo. Ciò che si apre è il contratto, non il risultato. Che cosa disegnare lì dentro resta lavoro di chi progetta.
Scanner — a che punto siamo
Il decoder funziona. Tutti e tre i tipi si leggono da foto scattate con dispositivi reali; resta da alzare precisione e velocità. Ogni tempo qui sotto è una decodifica di una singola foto statica scattata con un telefono reale, non il tempo del primo aggancio né un tasso di successo dal vivo.
| Tipo | Foto reali decodificate | Una decodifica su foto statica | Verifica dal vivo |
|---|---|---|---|
| Type Y — cubo singolo | 3 / 3 | ≈ 0.1 s | altre misure in corso |
| Type O — campo esagonale | 3 / 3 | ≈ 1.8 s | altre misure in corso |
| Type A — silhouette triangolare | 3 / 3 | ≈ 0.86 s | altre misure in corso |
| Variante con QR centrale (tutti e tre i tipi) | 8 / 9 | — | altre misure in corso |
Sul criterio di una decodifica di una foto statica, il Type Y è il più breve e O e A richiedono più tempo. La riprogettazione dei pattern di ricerca e i nuovi tentativi di formato hanno allargato l'insieme di foto reali che si decodificano, al costo di più lavoro su alcuni percorsi; Y prova prima un percorso economico e fa una scansione completa solo dopo un fallimento. Questi numeri non vanno letti come tempo del primo aggancio dal vivo.
Il tempo di una decodifica su foto statica non predice la sensazione della scansione dal vivo. Nelle prime misure su dispositivo reale, un fotogramma veloce poteva comunque portare a un primo aggancio lento quando servivano molti fotogrammi prima di uno riuscito, e la classifica dei tipi risultava diversa da questa tabella su foto statica. Quei rilievi riguardano un solo dispositivo e un campione piccolo, quindi non assegniamo ancora un giudizio d'uso dal vivo.
Contano molto anche le condizioni di ripresa. Alla misura, 9 pixel per cella era il limite inferiore di decodifica e, a parità di distanza, un obiettivo ultragrandangolare inquadra il codice più piccolo e scende sotto quella soglia (ultragrandangolare 7.6 px fallito / grandangolare 9.1 px riuscito). Per questo lo scanner offre la scelta dell'obiettivo.
Nella variante con QR centrale un blocco QR sostituisce il pattern di ricerca centrale. I suoi pattern forniscono il punto d'ingresso di posizione e orientamento con cui si decodifica il corpo TL circostante. Il generatore usa ora questo percorso verificato come impostazione predefinita per i tipi O e A. Per impostazione predefinita il QR resta una riserva che porta un link al lettore; il payload vero rimane nel corpo TL.
Misurato il 2026-08-13 · campione di 9 foto scattate con tre sensori di telefono (ultragrandangolare, grandangolare, teleobiettivo) · lato corto 1440 px. Il campione è piccolo: da leggere come stato attuale, non come tasso di successo.
Specifica e implementazione
La specifica del formato e l'implementazione di riferimento sono pubblicate con licenza Apache 2.0. JavaScript puro, nessuna toolchain di build, zero dipendenze a runtime — funziona come un singolo file HTML.
Implementare solo il decoder basta a essere un'implementazione conforme. La diffusione parte da chi legge.
| Sito | Ruolo | Stato |
|---|---|---|
| tlcube.estre.so | Generatore | attivo |
| tlscan.estre.so | Scanner | attivo — stato › |
| tl.estre.so | Sito di presentazione | sei qui |