Specifiche del codice HCC2D

Introduzione

HCC2D è un formato di codice a barre bidimensionale a colori. Riutilizza la struttura a matrice quadrata del QR Code definendo al contempo le proprie regole specifiche per la codifica a colori, il framing del payload, la semantica del bordo del simbolo, le capacità di versione e l'organizzazione delle codewords. In particolare, HCC2D riutilizza il finder pattern, l'alignment pattern, il timing pattern, le informazioni di formato, le informazioni di versione, le formule di data masking e il codice a correzione di errori di Reed-Solomon compatibile con QR Code / ISO/IEC 18004:2006, eccetto dove questa specifica definisce esplicitamente un comportamento diverso.

QR Code è un marchio registrato di DENSO WAVE INCORPORATED in Giappone e in altri paesi. HCC2D non è sponsorizzato, approvato né affiliato a DENSO WAVE INCORPORATED. Gli elementi strutturali definiti in QR Code / ISO/IEC 18004:2006 — inclusi finder patterns, alignment patterns, timing patterns, format information, version information e masking — sono qui utilizzati come elementi di uno standard tecnico pubblico. Questo documento descrive solo gli elementi specifici di HCC2D del formato e intenzionalmente non ripubblica tali elementi.

HCC2D non è un'alternativa al codice QR ma un'estensione di esso. Un decoder HCC2D deve essere anche un lettore di codici QR. In termini pratici, un decoder HCC2D è fondamentalmente un decoder standard di codici QR con funzionalità aggiuntive per riconoscere e decodificare moduli colorati. Utilizza la fase standard di rilevamento del QR Code per rilevare la struttura del simbolo. Dopo il rilevamento e prima della decodifica del payload, il decoder determina se seguire il percorso standard di decodifica del QR Code, nel quale i moduli sono interpretati come moduli in bianco e nero, oppure il percorso di decodifica HCC2D, nel quale i moduli sono interpretati come moduli a 4 colori o a 8 colori. Questa scelta viene effettuata verificando se i Color Palette Patterns di HCC2D sono presenti sul perimetro del simbolo. Se i Color Palette Patterns non sono presenti, il decoder decodifica il simbolo come un QR Code standard. Se i Color Palette Patterns sono presenti, il decoder decodifica il simbolo come un codice HCC2D secondo le regole di colore HCC2D applicabili. Un encoder HCC2D produce simboli che condividono la stessa base strutturale del codice QR e deve essere in grado di codificare sia codici QR sia codici HCC2D.

Questo documento specifica i formati di codice HCC2D a quattro colori e HCC2D a otto colori.

1. Ambito

Questo documento copre:

• hcc2d4: HCC2D a 4 colori
• hcc2d8: HCC2D a 8 colori

Questa specifica definisce:

• solo simboli quadrati
• versioni 1..40
• livelli di correzione degli errori L, M, Q, H
• solo codifica del payload in modalità byte

Questa specifica definisce il framing del payload HCC2D usando un segmento BYTE.

1.1 Termini e acronimi

• Color Palette Pattern: il bordo esterno di un codice HCC2D che contiene la sequenza ciclica dei colori della palette e che funge da legenda
• EC: correzione degli errori
• EC level: livello di correzione degli errori
• ECPB: error-correction codewords per block
• MSB: bit più significativo
• LSB: bit meno significativo
• RS: Reed-Solomon
• RGB: rosso, verde, blu
• ISO/IEC: Organizzazione Internazionale per la Normazione / Commissione Elettrotecnica Internazionale

Termini della matrice:

• module: una cella quadrata logica del simbolo
• inner grid o inner matrix: la matrice N×N riutilizzata compatibile con QR prima dell'aggiunta del bordo HCC2D
• full symbol: il quadrato N+2 prodotto dopo l'aggiunta del bordo HCC2D
• function module: un modulo non dati appartenente alle strutture finder, alignment, timing, formato o versione
• data module: un modulo il cui stato è determinato dal payload codificato e dal flusso di bit di correzione degli errori
• plane: una matrice binaria estratta dal flusso di bit interlacciato finale

1.2 Struttura ad alto livello

Ad alto livello, la codifica HCC2D procede come segue:

1. inquadrare il payload come un segmento in modalità BYTE
2. scegliere la versione e il livello di correzione degli errori
3. generare le codewords dei dati, le error-correction codewords e il flusso di bit interlacciato finale
4. dividere quel flusso di bit finale in due o tre piani binari
5. costruire una matrice interna compatibile con QR per piano usando un mask pattern condiviso
6. combinare i bit dei piani negli indici di colore per i moduli dati
7. renderizzare i moduli di funzione in bianco e nero
8. aggiungere il bordo Color Palette Pattern di HCC2D

HCC2D non esegue un processo di correzione degli errori separato per piano. Prima viene prodotto un flusso di bit combinato, e l'estrazione dei piani avviene solo dopo.

2. Base di conformità

Un'implementazione conforme produce codici decodificabili dall'HCC2D Decoder ufficiale, disponibile su Google Play, Huawei AppGallery e App Store.

Un'implementazione che dichiara la conformità a questa specifica deve combinare:

1. un livello specifico di HCC2D definito da questo documento; e
2. un livello di codifica a matrice quadrata riutilizzato il cui comportamento sia compatibile con QR Code / ISO/IEC 18004:2006 per tutte le parti riutilizzate.

Per l'interoperabilità con i decoder HCC2D esistenti, il livello riutilizzato deve fornire almeno:

• versioni quadrate di tipo Model-2 1..40
• livelli di correzione degli errori L, M, Q, H
• posizionamento del finder pattern
• posizionamento dell'alignment pattern in base alle coordinate indicate nelle tabelle HCC2D
• posizionamento del timing pattern
• generazione e posizionamento delle informazioni di formato
• generazione e posizionamento delle informazioni di versione dove applicabile
• ordine di posizionamento dei dati in modalità BYTE nella matrice interna
• formule di data masking per i mask indices 0..7
• mask penalty evaluation compatibile con QR Code / ISO/IEC 18004:2006, eccetto per la regola specifica di HCC2D che usa solo il piano 0 invertito nella sezione 10
• generazione della parità Reed-Solomon e interleaving delle codewords compatibile con QR Code / ISO/IEC 18004:2006, eccetto per i conteggi totali delle codewords e le molteplicità dei blocchi specifici di HCC2D definiti nelle sezioni 19 e 20

Pertanto:

• questa specifica non è completamente autonoma
• un'implementazione che abbia già quei comportamenti riutilizzati compatibili con QR Code / ISO/IEC 18004:2006 può implementare la generazione di simboli HCC2D interoperabili a partire da questa specifica
• un'implementazione che abbia questa specifica insieme alla specifica QR Code per le parti riutilizzate dispone delle informazioni necessarie per implementare la generazione di simboli HCC2D interoperabili

In termini pratici, HCC2D non è un sostituto della costruzione di matrici quadrate in stile QR. È un livello di capacità cromatica e framing costruito sopra un simbolo interno riutilizzato compatibile con QR. Pertanto, le differenze normative di HCC2D sono concentrate in:

• framing del payload
• capacità totali delle codewords e molteplicità dei blocchi
• estrazione dei piani di bit e interpretazione del colore
• selezione dell'input per l'algoritmo di data masking: solo il piano 0 invertito
• regola di rendering dei moduli di funzione
• semantica del bordo esterno di HCC2D

Un formato o simbolo può essere denominato HCC2D solo se è conforme a questa specifica. L'uso del nome HCC2D per descrivere un formato o simbolo non conforme è fuorviante e non è autorizzato da questa specifica.

3. Parametri di codifica

Un processo di generazione di simboli HCC2D conforme è parametrizzato da almeno questi valori logici:

• payload: obbligatorio, array di byte non vuoto
• mode: hcc2d4 o hcc2d8
• ec_level: uno tra L, M, Q, H
• version: 0 significa selezione automatica; altrimenti 1..40
• scale: pixel per modulo per il rendering raster, se viene prodotto output raster
• quiet_zone: moduli di margine bianco attorno al simbolo renderizzato, se viene prodotto output raster
• palette_rgb: sostituzione RGB opzionale

I primi quattro parametri influenzano il simbolo HCC2D logico. Gli ultimi tre influenzano solo il rendering visivo.

I valori predefiniti, il comportamento dell'interfaccia utente e le convenzioni della riga di comando esulano dall'ambito di questa specifica.

Note aggiuntive sui parametri:

• payload viene interpretato strettamente come byte grezzi
• questa specifica non definisce la transcodifica del testo, l'ottimizzazione multi-segmento, la modalità numerica o la modalità alfanumerica
• mode determina il numero di piani e la famiglia di palette
• ec_level seleziona la riga della tabella normativa all'interno della versione scelta
• version controlla la capacità, la dimensione interna, le coordinate di allineamento e la struttura dei blocchi
• scale, quiet_zone e palette_rgb non modificano il flusso di bit logico codificato

4. Geometria del simbolo

Per entrambe le modalità HCC2D, la versione v usa una griglia quadrata interna di dimensione:

N = 17 + 4*v

Esempi:

• versione 1 → 21 × 21
• versione 10 → 57 × 57
• versione 40 → 177 × 177

La griglia interna riutilizza le strutture di finder pattern, alignment pattern, timing pattern, informazioni di formato e informazioni di versione che seguono regole compatibili con QR Code / ISO/IEC 18004:2006.

HCC2D aggiunge quindi il proprio bordo esterno di un modulo su tutti e quattro i lati:

• dimensione interna = N
• dimensione completa = N + 2

Questo bordo esterno specifico di HCC2D è il Color Palette Pattern.

La distinzione tra griglia interna e simbolo completo è normativa:

• tutta la logica di posizionamento riutilizzata compatibile con QR opera sulla matrice interna N × N
• il Color Palette Pattern di HCC2D si trova al di fuori di quella matrice interna
• il rendering e l'output raster utilizzano la dimensione completa N + 2

Pertanto, ogni volta che questo documento fa riferimento a pattern di funzione, posizionamento dei dati, masking o geometria di versione, tali regole si applicano prima alla matrice interna e solo successivamente viene aggiunto il bordo HCC2D.

5. Indici di colore e palette predefinite

Questa sezione definisce il layout dei bit dell'indice di colore per HCC2D4 e HCC2D8, i due Modelli di Palette di Colori standard (Modello 1 per la visualizzazione su schermo e Modello 2 per la stampa), la classificazione dei modelli di palette, e le regole per la personalizzazione della palette.

5.1 HCC2D4 — Palette di Colori Modello 1 — Definizione

I codici HCC2D4 con Palette di Colori Modello 1 dovranno usare i seguenti colori per gli indici di palette 0..3. La luminanza è approssimativa, calcolata come Y = 0.299R + 0.587G + 0.114B.

Layout dei bit dell'indice di colore:

• bit 1 = piano MSB
• bit 0 = piano LSB

Pertanto:

• 00 → 0 → nero
• 01 → 1 → rosso
• 10 → 2 → ciano
• 11 → 3 → bianco

L'ordinamento è logico, non meramente visivo. L'indice 0 è l'ancora scura e l'indice 3 è l'ancora bianca della famiglia a quattro colori.

5.2 HCC2D8 — Palette di Colori Modello 1 — Definizione

I codici HCC2D8 con Palette di Colori Modello 1 dovranno usare i seguenti colori per gli indici di palette 0..7. La luminanza è approssimativa, calcolata come Y = 0.299R + 0.587G + 0.114B.

Layout dei bit dell'indice di colore:

• bit 2 = piano 0 / piano MSB
• bit 1 = piano 1
• bit 0 = piano 2 / piano LSB

Pertanto l'indice di colore è uguale al valore a 3 bit formato dai tre bit di piano.

Ancora una volta, l'ordinamento è logico. L'indice 0 è l'ancora scura e l'indice 7 è l'ancora bianca della famiglia a otto colori.

5.3 Palette di Colori Modello 1 — Motivazione del design

I valori RGB della Palette di Colori Modello 1 (definita nelle sezioni 5.1 e 5.2) sono stati deliberatamente scelti per evitare gli estremi del gamut sRGB, dove i profili di schermo e i gamut hardware divergono maggiormente. Il decoder campiona il Color Palette Pattern in fase di esecuzione sullo schermo reale — che può essere sRGB, wide-gamut, AMOLED o LCD, e quasi certamente non calibrato. I valori di canale prossimi ai limiti (vicini a 0 o 255) vengono riprodotti in modo diverso a seconda del tipo di schermo; limitando i canali attivi a 200–220 anziché 255, i colori della palette si collocano all'interno del gamut sRGB, dove i diversi schermi concordano in modo più affidabile sul colore percepito. Questo riduce la deriva cromatica tra schermi e migliora la stabilità del campionamento dei colori durante la decodifica.

Questa scelta di limitazione dei canali RGB produce anche una distribuzione di luminanza coerente con il requisito di ordinamento della sezione 5.9. Per HCC2D8 (sezione 5.2), gli indici 0–3 (nero, rosso scuro, verde scuro, blu navy scuro) rientrano tutti al di sotto del punto medio di luminanza (Y < 128), mentre gli indici 4–7 (ciano chiaro, giallo chiaro, magenta chiaro, bianco) rientrano tutti al di sopra (Y > 128). Il divario tra l'indice 3 (blu navy scuro, Y ≈ 56) e l'indice 4 (ciano chiaro, Y ≈ 153) è di circa 97 unità di luminanza.

La Palette di Colori Modello 1 è la baseline validata per gli schermi. Non ha la pretesa di essere ottimale per la stampa.

5.4 HCC2D4 — Palette di Colori Modello 2 — Definizione

Per HCC2D4, tutti i colori intermedi sono a singolo canale. Il giallo è escluso perché offre contrasto insufficiente con la carta bianca:

5.5 HCC2D8 — Palette di Colori Modello 2 — Definizione

Per HCC2D8, la palette copre tutti e tre i primari CMYK a singolo canale e le loro tre combinazioni binarie a saturazione completa. Non viene usata alcuna combinazione a tre canali:

5.6 Palette di Colori Modello 2 — Motivazione del design

La Palette di Colori Modello 2 è la palette ottimizzata per la stampa, definita per HCC2D4 e HCC2D8. Per la stampa, il problema è diverso rispetto agli schermi: il gamut dell'inchiostro, il punto di bianco della carta e le condizioni di illuminazione durante la scansione introducono fonti di variabilità differenti. La Palette di Colori Modello 2 si basa sul principio di minimizzare il numero di canali di inchiostro per colore di modulo. I colori a singolo canale sono i più stabili tra le stampanti; ogni canale aggiuntivo introduce interazioni di dot gain che variano in funzione della stampante, della carta e della densità dell'inchiostro.

Entrambe le palette della Palette di Colori Modello 2 soddisfano l'ordinamento scuro/chiaro della sezione 5.9. Per HCC2D8, la suddivisione è particolarmente netta: gli indici 0–3 (nero, blu, rosso, magenta) rientrano tutti al di sotto del punto medio di luminanza (Y < 128), mentre gli indici 4–7 (verde, ciano, giallo, bianco) rientrano tutti al di sopra (Y > 128), con un divario di circa 45 unità di luminanza tra l'indice 3 (magenta, Y ≈ 105) e l'indice 4 (verde, Y ≈ 150).

5.7 Classificazione dei Modelli di Palette di Colori

I codici HCC2D sono classificati in base alla palette di colori utilizzata. Il numero di modello è una proprietà della palette, non del formato del codice; il decoder è agnostico rispetto alla palette.

• Palette di colori Modello 1: codici che utilizzano la palette predefinita esatta definita nelle sezioni 5.1 e 5.2. Questa è la palette standard e completamente interoperabile. La Palette di colori Modello 1 è stata validata per funzionare bene quando i codici sono visualizzati su schermi (monitor di computer, smartphone e dispositivi simili). Qualsiasi implementazione che dichiari conformità HCC2D senza ulteriori qualifiche implica la Palette di colori Modello 1.
• Palette di Colori Modello 2: codici che utilizzano la palette ottimizzata per la stampa definita nelle sezioni 5.4 e 5.5, disponibile per HCC2D4 e HCC2D8. Progettata per flussi di lavoro di stampa e scansione.
• Palette non valida: una palette priva di nero all'indice 0 o di bianco all'ultimo indice. I codici prodotti con tale palette non sono codici HCC2D validi. I codificatori conformi dovranno rifiutare tali configurazioni (vedi sezione 5.8).
• Palette non standard / sperimentale: una palette che mantiene il nero all'indice 0 e il bianco all'ultimo indice ma usa colori intermedi diversi. I codici prodotti con tale palette possono o non possono essere decodificabili, a seconda di quanto siano cromaticamente distinti i colori scelti. L'implementazione di codifica si assume la piena responsabilità per eventuali codici che non riescono a essere decodificati.

I numeri di modello della palette di colori sono assegnati esclusivamente da questa specifica. Versioni future di questa specifica potranno definire modelli di palette di colori aggiuntivi (Palette di colori Modello 3 e successivi) man mano che altre combinazioni di colori vengano validate sperimentalmente per funzionare bene in casi d'uso specifici, come la lettura da computer a telefono o da telefono a telefono.

Le modifiche alla palette dovrebbero essere limitate a uso sperimentale. Per l'uso in produzione, la Palette di colori Modello 1 dovrebbe essere usata quando i codici devono essere visualizzati su schermi (monitor di computer, smartphone e dispositivi simili); la Palette di colori Modello 2 dovrebbe essere usata quando i codici devono essere stampati.

Le implementazioni che producono codici con una palette non standard dovranno comunicarlo esplicitamente agli utenti, indicando che i codici utilizzano una palette non standard e potrebbero non essere decodificabili da tutti i decoder HCC2D.

5.8 Sostituzione della palette

La prima voce della palette e l'ultima sono ancoraggi normativi e non devono essere modificati:

• per hcc2d4, l'indice 0 deve rimanere nero e l'indice 3 deve rimanere bianco
• per hcc2d8, l'indice 0 deve rimanere nero e l'indice 7 deve rimanere bianco

Pertanto:

• in hcc2d4, solo gli indici 1 e 2 possono essere personalizzati
• in hcc2d8, solo gli indici da 1 a 6 possono essere personalizzati

Quando viene fornita una sostituzione della palette:

• la modalità a 4 colori richiede esattamente 12 byte (4 * 3)
• la modalità a 8 colori richiede esattamente 24 byte (8 * 3)
• il layout dei byte è ancora la palette completa in ordine di indice di palette, poi in ordine di componente RGB
• tuttavia, i codificatori conformi devono rifiutare le sostituzioni la cui prima voce non è nero o la cui ultima voce non è bianco

L'ordine dei byte è per ordine di voce della palette, poi per ordine di componente RGB:

• HCC2D4: R0 G0 B0 R1 G1 B1 R2 G2 B2 R3 G3 B3
• HCC2D8: R0 G0 B0 ... R7 G7 B7

Valori di ancoraggio normativi:

• hcc2d4: R0 G0 B0 = 0 0 0 e R3 G3 B3 = 255 255 255
• hcc2d8: R0 G0 B0 = 0 0 0 e R7 G7 B7 = 255 255 255

La logica del simbolo usa solo gli indici. I valori RGB personalizzati non influenzano le codewords, la costruzione del flusso di bit, la selezione della versione, la mask selection o il layout della matrice, ma influenzano l'aspetto renderizzato.

In modo equivalente, HCC2D determina prima un indice di colore logico per ogni modulo e solo poi associa quell'indice a una terna RGB per il rendering.

5.9 Ordinamento di luminanza consigliato per palette personalizzate

Questa sottosezione è informativa.

Quando viene utilizzata una palette personalizzata, le implementazioni dovrebbero preservare una metà inferiore più scura e una metà superiore più chiara. Questa raccomandazione è motivata dalla mask selection rule di HCC2D definita più avanti in questa specifica.

La mask selection di HCC2D non viene eseguita sul simbolo finale renderizzato a piena risoluzione cromatica. Viene invece eseguita su un proxy binario derivato da un solo piano di bit:

• solo il piano 0 partecipa alla mask selection
• per hcc2d4, il piano 0 è il bit più significativo del colore
• per hcc2d8, il piano 0 è il bit più significativo del colore (bit 2)
• quel piano viene estratto dal flusso di bit interlacciato finale
• quel piano viene poi invertito
• le QR-compatible mask penalty rules vengono valutate su quel proxy invertito a piano singolo

Pertanto, solo un bit per modulo influenza direttamente la mask choice.

Questo ha un'importante conseguenza pratica. La maschera viene scelta usando le regole di penalità binaria in stile QR, ma il simbolo HCC2D finale è un simbolo multicolore. Perché il processo di mask selection in stile QR rimanga significativo per HCC2D, il proxy binario utilizzato per la mask choice dovrebbe ancora correlare ragionevolmente bene con la struttura di oscurità apparente del simbolo renderizzato finale.

Quella correlazione migliora quando gli indici di palette inferiori sono più scuri e gli indici superiori sono più chiari. In tale disposizione, il piano singolo utilizzato per la mask selection funge ancora da utile approssimazione grossolana di come sono distribuite le regioni scure rispetto a quelle chiare nel simbolo HCC2D finale.

Pertanto, la personalizzazione della palette dovrebbe preservare un ordinamento di luminanza renderizzata in cui la metà inferiore rimanga più scura in generale e la metà superiore più chiara in generale, coerente con l'ordinamento di significato logico degli indici di colore.

In termini pratici:

• gli indici di palette inferiori dovrebbero corrispondere a colori più scuri
• gli indici di palette superiori dovrebbero corrispondere a colori più chiari
• la prima voce deve rimanere nera
• l'ultima voce deve rimanere bianca

Ordinamento consigliato per hcc2d4:

• l'indice 0 deve essere nero
• l'indice 1 dovrebbe essere visivamente più scuro dell'indice 2
• l'indice 3 deve essere bianco
• come linea guida a livello della famiglia a 4 colori, gli indici 0 e 1 dovrebbero formare la metà più scura della palette e gli indici 2 e 3 la metà più chiara

Ordinamento consigliato per hcc2d8:

• l'indice 0 deve essere nero
• l'indice 7 deve essere bianco
• gli indici 1, 2 e 3 dovrebbero rimanere nella metà più scura della palette
• gli indici 4, 5 e 6 dovrebbero rimanere nella metà più chiara della palette
• come linea guida a livello della famiglia a 8 colori, gli indici da 0 a 3 dovrebbero essere più scuri in generale degli indici da 4 a 7

Questa raccomandazione non modifica la logica del simbolo, poiché HCC2D usa gli indici di palette piuttosto che i valori di luminanza quando costruisce il simbolo. Una palette che viola il bilanciamento raccomandato più scuro in basso / più chiaro in alto può ancora produrre simboli decodificabili. Tuttavia, facendo così si indebolisce la relazione intesa tra:

• il proxy utilizzato durante la mask selection
• la distribuzione di oscurità apparente del simbolo renderizzato finale
• la stabilità visiva della palette personalizzata in diverse condizioni di scansione

Se quel bilanciamento scuro-verso-chiaro viene preservato, le mask rules in stile QR riutilizzate rimangono un'euristica ragionevole e utile anche per HCC2D.

Se quel bilanciamento non viene preservato:

• il codificatore può ancora generare simboli validi
• i decoder possono ancora decodificare con successo quei simboli
• ma la maschera selezionata viene quindi ottimizzata per il proxy binario in stile QR piuttosto che per una disposizione cromatica finale la cui oscurità percepita segue la stessa struttura

In tal caso, la mask selection funziona ancora nel senso stretto che una mask viene scelta e il simbolo risultante può rimanere decodificabile, ma il modello di penalità in stile QR diventa meno rappresentativo delle proprietà visive del simbolo HCC2D reale.

Per tale motivo, una palette personalizzata dovrebbe preservare colori più scuri negli indici inferiori e colori più chiari negli indici superiori.

6. Framing del payload

Il framing del payload HCC2D usa un segmento BYTE.

• bit del marcatore di segmento: 0100
• larghezza del campo di conteggio: 16 bit in entrambe le modalità HCC2D, per tutte le versioni
• valore di conteggio: lunghezza del payload in byte
• byte del payload: aggiunti verbatim, 8 bit ciascuno, bit più significativo prima

Il flusso di bit del payload logico prima della terminazione è:

0100 || byte_count_16 || payload_bytes

I bit di terminazione, l'allineamento dei byte, i byte di padding, la generazione della parità Reed-Solomon e l'interleaving finale seguono regole compatibili con QR Code / ISO/IEC 18004:2006, eccetto dove questa specifica definisce esplicitamente un comportamento HCC2D diverso.

Conseguenze importanti di questa regola di framing:

• il campo di conteggio è sempre di sedici bit per HCC2D, indipendentemente dalla versione
• il valore di conteggio è un conteggio di byte, non di bit né di caratteri
• i byte del payload vengono aggiunti verbatim in ordine di bit più significativo prima
• questa specifica definisce esattamente un segmento BYTE per simbolo HCC2D

7. Selezione della versione

Se viene specificata esplicitamente una versione, sarà usata solo se il payload vi rientra.

Se viene utilizzata la selezione automatica della versione, verrà selezionata la versione minima compatibile col payload.

Per una data modalità, versione e livello di correzione degli errori HCC2D:

• total_codewords, data_codewords, ec_codewords e il layout dei blocchi sono forniti dalle tabelle esplicite HCC2D nelle sezioni 19 e 20
• un payload è compatibile se e solo se il suo flusso di bit inquadrato può essere terminato e riempito fino a esattamente data_codewords byte

A tal fine, la lunghezza del flusso di bit inquadrato prima della terminazione è:

4 + 16 + 8 * payload_length

dove 4 è l'indicatore di modalità BYTE e 16 è la larghezza del campo di conteggio byte HCC2D.

Un payload rientra nella capacità quando quel flusso di bit inquadrato può essere:

1. facoltativamente terminato con fino a quattro bit zero
2. riempito con bit zero fino al successivo limite di byte
3. riempito con byte di padding alternati fino a raggiungere esattamente la capacità di data codewords

senza superare il conteggio di data codewords disponibili per la modalità, versione e livello di correzione degli errori selezionati.

8. Organizzazione delle codewords HCC2D

Le tabelle dei parametri HCC2D nelle sezioni 19 e 20 sono normative.

La struttura di correzione degli errori segue regole compatibili con ISO/IEC 18004:2006, eccetto dove questa specifica definisce esplicitamente un comportamento specifico di HCC2D.

Ogni riga della tabella fornisce:

• dim: dimensione interna
• align: coordinate centrali dell'alignment pattern
• total: total codewords
• data: data codewords
• ec: error-correction codewords
• ecpb: error-correction codewords per block
• blocks: molteplicità dei blocchi e data codewords per blocco

Quei valori determinano completamente l'organizzazione delle codewords HCC2D per ogni versione e livello.

Per hcc2d4, il conteggio totale delle codewords per ogni versione e livello è esattamente il doppio della struttura base compatibile con QR Code / ISO/IEC 18004:2006 corrispondente.

Per hcc2d8, il conteggio totale delle codewords per ogni versione e livello è esattamente il triplo della struttura base compatibile con QR Code / ISO/IEC 18004:2006 corrispondente.

Più precisamente:

• hcc2d4 mantiene i valori di codewords per block compatibili con QR Code / ISO/IEC 18004:2006 riutilizzati e raddoppia le molteplicità dei blocchi
• hcc2d8 mantiene i valori di codewords per block compatibili con QR Code / ISO/IEC 18004:2006 riutilizzati e triplica le molteplicità dei blocchi

Questo è il meccanismo con cui HCC2D aumenta la capacità totale di bit continuando a usare le procedure Reed-Solomon compatibili con QR riutilizzate.

9. Costruzione dei piani

Sia B il flusso di bit finale delle codewords interlacciate.

La costruzione dei piani viene eseguita solo dopo:

• la formazione delle data codewords
• la generazione delle error-correction codewords
• il completamento dell'interleaving finale

HCC2D non crea flussi di correzione degli errori separati per piano. Viene invece prodotto prima un flusso di bit combinato finale e poi diviso per passo in piani.

9.1 HCC2D4 — Due piani

hcc2d4 usa due piani.

L'estrazione dei piani avviene per de-interleaving dei bit dal flusso di bit finale:

• il piano 0 prende i bit alle posizioni 0, 2, 4, ...
• il piano 1 prende i bit alle posizioni 1, 3, 5, ...

Il piano 0 è il piano MSB. Il piano 1 è il piano LSB.

Indice di colore del modulo dati:

color = (plane0_bit << 1) | plane1_bit

In modo equivalente, se il flusso di bit interlacciato finale è B[0], B[1], B[2], ..., i colori dei moduli del simbolo sono determinati da coppie di bit:

(B[0], B[1]), (B[2], B[3]), (B[4], B[5]), ...

9.2 HCC2D8 — Tre piani

hcc2d8 usa tre piani.

L'estrazione dei piani è:

• il piano 0 prende i bit alle posizioni 0, 3, 6, ...
• il piano 1 prende i bit alle posizioni 1, 4, 7, ...
• il piano 2 prende i bit alle posizioni 2, 5, 8, ...

Il piano 0 è il piano MSB. Il piano 2 è il piano LSB.

Indice di colore del modulo dati:

color = (plane0_bit << 2) | (plane1_bit << 1) | plane2_bit

In modo equivalente, se il flusso di bit interlacciato finale è B[0], B[1], B[2], ..., i colori dei moduli del simbolo sono determinati da triple di bit:

(B[0], B[1], B[2]), (B[3], B[4], B[5]), (B[6], B[7], B[8]), ...

L'ordine dei piani è normativo e non deve essere permutato. In hcc2d4, il piano 0 è il bit più significativo e il piano 1 è il bit meno significativo. In hcc2d8, il piano 0 è il bit 2, il piano 1 è il bit 1 e il piano 2 è il bit 0.

10. Mask selection

Deve essere utilizzato un unico mask pattern in 0..7 per tutti i piani di un simbolo.

La mask selection segue regole compatibili con ISO/IEC 18004:2006, eccetto dove questa specifica definisce esplicitamente un comportamento specifico di HCC2D.

Comportamento specifico di HCC2D per la valutazione dei candidati:

• costruire un flusso di bit proxy solo dal piano 0
• invertire ogni bit di quel flusso del piano 0
• usare quel flusso invertito per la mask penalty evaluation

Mask selection procedure:

1. per ogni mask index candidato in 0..7, applicare quella mask al flusso del piano 0 invertito e costruire una matrice interna candidata da esso
2. calcolare la mask penalty su quella matrice candidata
3. selezionare il mask index con penalità minima

Il pareggio viene risolto dal primo minimo incontrato, cioè il mask index più basso.

Una volta scelto il mask index vincitore, quell'unico indice deve essere riutilizzato per ogni piano del simbolo. HCC2D non sceglie mask pattern diversi per piani diversi.

11. Costruzione della matrice interna

Ogni piano viene convertito in una matrice interna usando la versione scelta e il mask pattern comune scelto.

Importante: tutti i piani usano la stessa geometria del pattern di funzione, la stessa versione, gli stessi bit di formato e lo stesso mask index. Differiscono solo nei bit di dati.

Questo documento non riporta nella sua interezza le formule riutilizzate di finder pattern, alignment pattern, timing pattern, informazioni di formato, informazioni di versione, Reed-Solomon o formule di data masking.

Pertanto, la costruzione della matrice interna per HCC2D può essere intesa come una costruzione di matrice compatibile con QR ripetuta sulla stessa geometria, una volta per piano, con solo il flusso di bit del piano che cambia da un passaggio all'altro.

12. Colorazione dei moduli di funzione

Per hcc2d4 e hcc2d8, i moduli dati usano la mappatura dei colori multi-piano descritta sopra, ma i moduli di funzione sono renderizzati solo in bianco e nero:

• se il piano 0 a quella coordinata del modulo di funzione è 1, renderizzare nero
• altrimenti renderizzare bianco

In pratica questo è sicuro perché i moduli di funzione sono identici in tutti i piani.

Questa regola si applica a tutti i moduli strutturali riutilizzati nella matrice interna, inclusi finder pattern, alignment pattern, timing pattern, informazioni di formato e informazioni di versione dove applicabile.

13. Color Palette Pattern

Il Color Palette Pattern deve essere implementato esattamente come specificato: i decoder ne campionano i moduli per ricostruire la palette di colori. Il decoder non conosce a priori i colori della palette, ad eccezione del fatto che il primo è nero e l'ultimo è bianco. Il Color Palette Pattern è quindi necessario per la decodifica.

Sia N la dimensione interna.

Il bordo HCC2D si trova un modulo all'esterno della griglia interna:

• la riga del bordo superiore si trova alla riga logica -1
• la riga del bordo inferiore si trova alla riga logica N
• la colonna del bordo sinistro si trova alla colonna logica -1
• la colonna del bordo destro si trova alla colonna logica N

Il codice HCC2D sposta quelle coordinate logiche di +1 in entrambi gli assi, producendo una griglia (N+2) × (N+2).

Il Color Palette Pattern è una parte strutturale di HCC2D, non un ornamento opzionale. La sua geometria e l'ordine degli indici di colore fanno parte della definizione del formato.

13.1 Periodo del Color Palette Pattern

• hcc2d4: periodo P = 4
• hcc2d8: periodo P = 8

I segmenti attivi su ogni bordo scorrono ripetutamente attraverso tutti gli indici di palette P. La formula esatta per ogni bordo, incluso l'indice iniziale e la direzione del ciclo, è fornita nella sezione 13.2.

Il ciclo è definito in termini di indici di palette logici, non di valori RGB letterali.

13.2 Formule esatte per i colori del Color Palette Pattern

Siano row e col coordinate logiche nel sistema di coordinate del bordo descritto sopra.

Il bordo Color Palette Pattern deve utilizzare queste regole esatte:

1. Bordo superiore: se row == -1 e 8 ≤ col < N - 8, allora color = (col - 8) mod P
2. Bordo inferiore: se row == N e 8 ≤ col < N, allora color = (col - 8) mod P
3. Bordo sinistro: se col == -1, sia start = N - 9. Se 8 ≤ row ≤ start, allora color = (start - row) mod P
4. Bordo destro: se col == N e 8 ≤ row < N, allora color = (row - 8) mod P
5. Tutte le celle di bordo rimanenti: color = P - 1

Ciò significa che le celle di bordo non ciclanti, inclusi gli angoli e i segmenti esclusi vicino ai finder pattern, sono sempre l'indice di palette più alto:

• 3 per HCC2D4 → bianco
• 7 per HCC2D8 → bianco

13.3 Repliche del Color Palette Pattern per modalità

Non tutti i moduli del bordo portano i colori della palette. I moduli agli angoli e vicino ai finder pattern sono bianchi fissi (colore = P − 1, come definito nella sezione 13.2). La lunghezza del segmento che replica ciclicamente i colori della palette su ciascun lato è:

• lato superiore: N − 16 moduli
• lato inferiore: N − 8 moduli
• lato sinistro: N − 16 moduli
• lato destro: N − 8 moduli

Per HCC2D8 (P = 8), si applicano le stesse lunghezze.

La sequenza esatta per lato — incluso l'indice iniziale e la direzione — è determinata dalle formule nella sezione 13.2. I lati superiore, inferiore e destro si incrementano con la loro coordinata di scansione. Sul lato sinistro l'indice di palette decresce all'aumentare della riga; l'indice iniziale esatto per ciascuna versione è dato dalla formula nella sezione 13.2.

13.4 Interpretazione per il decoder

Il decoder campiona queste strisce per recuperare le statistiche della palette. Pertanto il bordo fa parte del formato del simbolo, non è semplicemente una decorazione.

Qualsiasi implementazione che modifichi la geometria del segmento, la direzione del ciclo o le celle bianche di riserva del Color Palette Pattern genererebbe un simbolo non conforme.

14. Coordinate di output renderizzato

Questa sezione definisce il rendering raster di un simbolo HCC2D logico. Il simbolo logico è completamente definito senza fissare alcuna dimensione di pixel particolare.

14.1 Coordinate del modulo

Per le modalità HCC2D:

• dimensione totale della griglia di moduli = N + 2
• il modulo interno (x, y) si mappa sul modulo renderizzato (x + 1, y + 1)

14.2 Quiet zone

L'immagine rasterizzata aggiunge quiet_zone moduli di colore di sfondo su tutti e quattro i lati.

Indice del colore di sfondo:

• HCC2D4: 3 (bianco)
• HCC2D8: 7 (bianco)

14.3 Dimensione dell'immagine in pixel

Sia F la dimensione completa del modulo:

F = N + 2

Allora:

• larghezza immagine = (F + 2 * quiet_zone) * scale
• altezza immagine = uguale

Ogni modulo logico viene rasterizzato come un quadrato a colore pieno scale × scale.

Per i simboli HCC2D, la quiet zone usa l'indice di palette più alto:

• 3 per hcc2d4
• 7 per hcc2d8

Con le palette predefinite, questo corrisponde al bianco.

15. Regole strutturali rilevanti per il decoder

15.1 Campo di conteggio HCC2D

Il campo di conteggio BYTE è di 16 bit in entrambe le modalità HCC2D.

15.2 Ordine dei piani

Per HCC2D a 4 colori:

• il piano 0 è il color MSB
• il piano 1 è il color LSB

Per HCC2D a 8 colori:

• il piano 0 è il bit più significativo del colore (bit 2)
• il piano 1 è il bit 1
• il piano 2 è il bit meno significativo del colore (bit 0)

15.3 Maschera comune

Tutti i piani devono usare lo stesso mask pattern.

Queste regole sono rilevanti per il decoder perché un decoder che assuma larghezze del campo di conteggio BYTE variabili in stile QR, un ordine di significatività dei piani diverso, o maschere indipendenti per piano non interpreterebbe correttamente un simbolo HCC2D conforme.

16. Procedura di codifica

Una procedura di codifica HCC2D conforme deve eseguire i seguenti passaggi:

1. Validare gli input.
2. Selezionare la famiglia di simboli (hcc2d4 o hcc2d8).
3. Selezionare il livello di correzione degli errori (L/M/Q/H).
4. Scegliere la versione: usare la versione specificata esplicitamente se il payload vi rientra; altrimenti, quando si usa la selezione automatica, scegliere la versione minima compatibile col payload.
5. Costruire il flusso di bit del payload logico: 0100 || byte_count_16 || payload_bytes
6. Determinare la capacità specifica della famiglia e il layout dei blocchi dalla tabella HCC2D esplicita per la modalità, versione e livello scelti.
7. Applicare la terminazione e i byte di padding.
8. Generare la parità e interlacciare le codewords usando la struttura di correzione degli errori riutilizzata.
9. Dividere il flusso di bit finale in 2 o 3 piani per estrazione a passo.
10. Selezionare un mask index comune: per le modalità HCC2D, valutare le penalità usando solo il piano 0 invertito.
11. Costruire una matrice interna per piano usando la versione comune, il livello EC e la maschera.
12. Renderizzare i moduli dati:
    • HCC2D4: indice di colore da 2 bit (un bit per piano)
    • HCC2D8: indice di colore da 3 bit (un bit per piano)
13. Renderizzare i moduli di funzione come nero/bianco dal piano 0.
14. Aggiungere l'esatto bordo Color Palette Pattern di un modulo usando le formule di coordinate della sezione 13.
15. Aggiungere la quiet zone bianca.
16. Rasterizzare i moduli in pixel se è necessario un output di immagine raster.

L'ordine delle operazioni è importante. In particolare:

• la correzione degli errori e l'interleaving avvengono prima dell'estrazione dei piani
• la mask selection avviene una volta ed è condivisa da tutti i piani
• la costruzione della matrice interna avviene prima dell'aggiunta del bordo Color Palette Pattern
• la quiet zone è al di fuori del simbolo HCC2D completo e non fa parte della struttura logica del payload

17. Wrapper opzionale del payload HCC2DF

Questa sezione non definisce il codice HCC2D stesso.

Definisce un formato wrapper del payload opzionale, HCC2DF, che può essere utilizzato prima della codifica del simbolo HCC2D quando l'applicazione vuole trasportare un nome file insieme al contenuto del file. Quando viene utilizzato, il flusso di byte HCC2DF diventa il payload definito nelle sezioni 3, 6 e 16 di questa specifica.

HCC2DF è un wrapper a livello applicativo sovrapposto ai byte del payload HCC2D. Non fa parte della geometria del simbolo HCC2D o della logica del colore.

17.1 Layout dei byte HCC2DF

I byte del payload HCC2DF sono:

1. magic ASCII: "HCC2DF" → 6 byte
2. byte della versione wrapper: 0x01
3. byte del flag di compressione:
   • 0x00 = contenuto non compresso
   • 0x01 = contenuto compresso con zlib
4. lunghezza del nome file: 1 byte
5. byte del nome file: UTF-8, esattamente filename_length byte
6. byte di contenuto: byte del file grezzi o byte del file compressi

Questo wrapper non definisce campi di checksum, footer né strutture di metadati annidate.

17.2 Vincoli del nome file

• il nome file non deve essere vuoto
• il nome file non deve superare i 127 byte UTF-8
• il nome file non deve contenere /
• il nome file non deve contenere \

17.3 Regola di compressione

Se viene tentata la compressione, il contenuto viene compresso usando zlib compress2(..., Z_DEFAULT_COMPRESSION).

La compressione dovrebbe essere usata solo se tutte le seguenti condizioni sono vere:

• la compressione ha successo
• la dimensione del file originale è di almeno 128 byte
• la dimensione compressa è strettamente inferiore al 90% della dimensione originale

Altrimenti i byte del file grezzo dovrebbero essere memorizzati e il flag di compressione dovrebbe essere 0x00.

Il minimo di 128 byte riflette l'overhead fisso che la compressione zlib introduce sempre. Il wrapper zlib aggiunge 6 byte (2 di intestazione + 4 di checksum Adler-32). Le intestazioni dei blocchi deflate aggiungono ulteriore overhead: un blocco memorizzato aggiunge 5 byte, e un blocco Huffman dinamico aggiunge la descrizione della tabella dei codici, che può essere di 20–50 byte per input piccoli — per un overhead totale realistico di circa 36 byte. Per capire perché 128 byte è la soglia giusta, si considerino i due casi:

• Input di 64 byte: margine per superare il 90% = 64 × 0,9 − 36 = 21,6 byte per i dati effettivi — il contenuto deve comprimersi al ~34%, raggiungibile solo per sequenze molto ripetitive.
• Input di 128 byte: margine = 128 × 0,9 − 36 = 79 byte per i dati effettivi — il contenuto deve comprimersi al ~62%, realistico per testo, JSON o URL tipici.

Al di sotto di 128 byte, l'overhead consuma una parte così grande del margine disponibile che la compressione difficilmente produce un risultato significativo per qualsiasi payload reale.

Questa regola preferisce la compressione solo quando fornisce un chiaro beneficio in termini di dimensione. Le implementazioni possono usare una soglia diversa (es. 95%), ma non è raccomandato: una soglia più alta significa comprimere dati che risparmiano solo pochi punti percentuali di spazio, il che non costituisce un beneficio significativo: memorizzare i byte grezzi è più semplice e il risultato può avere praticamente quasi la stessa dimensione. In ogni caso, le implementazioni che si discostano da questa raccomandazione produrranno comunque codici decodificabili dall'HCC2D Decoder ufficiale, purché il flag di compressione e il contenuto rimangano coerenti: se il flag è 0x01 il contenuto deve essere dati zlib validi; se è 0x00 il contenuto deve essere i byte grezzi.

17.4 Relazione di ambito con HCC2D

HCC2DF è un wrapper opzionale trasportato all'interno dei byte del payload HCC2D. Non fa parte della struttura del codice HCC2D, della codifica del colore, dell'organizzazione dei codewords o della geometria del simbolo.

18. Raccomandazioni di implementazione

Le seguenti sono raccomandazioni orientative per i realizzatori. Non sono requisiti normativi della presente specifica. I requisiti normativi nel resto di questa specifica sono espressi con i termini "dovrà" e "non dovrà"; questa sezione usa "dovrebbe" e "non dovrebbe" per la guida orientativa.

Livello di correzione degli errori raccomandato: Per i codici HCC2D dovrebbero essere usati i livelli Q o M. Il livello L non dovrebbe essere usato per uso generale. Il livello H offre la massima robustezza a scapito di una capacità del payload significativamente ridotta.

Modalità raccomandata: Per l'uso in produzione dovrebbe essere usato hcc2d4. hcc2d8 offre una maggiore capacità del payload ma richiede condizioni di visualizzazione e scansione cromaticamente più coerenti.

Qualità di stampa e produzione: Per i codici stampati destinati all'uso in produzione:

• Dovrebbe essere usato un formato di output senza perdita (PNG, SVG o PDF). I formati con perdita come JPEG introducono artefatti di compressione che alterano i colori dei moduli.
• Ogni modulo dovrebbe essere reso come un blocco di colore solido; la retinatura (halftoning) non dovrebbe essere usata.
• Le proporzioni non dovrebbero essere stirate, compresse né distorte.
• Sfocatura, antialiasing e ricampionamento non dovrebbero essere applicati dopo la rasterizzazione.
• La dimensione del modulo dovrebbe essere di almeno 0,5 mm (dimensione X obiettivo GS1 per QR Code), o preferibilmente intorno a 1 mm per una maggiore affidabilità. I moduli più piccoli riducono la differenziazione dei colori durante la fase di decodifica.

19. Tabella dei parametri HCC2D4 esplicita

I seguenti valori sono i parametri di versione HCC2D4. Sono i totali completi HCC2D4 e i layout dei blocchi.

Significato dei campi della tabella:

• Vn: numero di versione HCC2D.
• dim: dimensione interna del simbolo in moduli, escludendo il bordo Color Palette Pattern di un modulo di HCC2D.
• align: coordinate centrali dell'alignment pattern sulla griglia interna. Una lista vuota significa che non sono presenti alignment pattern.
• L, M, Q, H: livelli di correzione degli errori.
• total: numero totale di codewords nel simbolo per quella versione e livello di correzione degli errori.
• data: numero totale di data codewords nel simbolo per quella versione e livello di correzione degli errori.
• ec: numero totale di error-correction codewords nel simbolo per quella versione e livello di correzione degli errori.
• ecpb: error-correction codewords per block.
• blocks=a x b: a blocchi Reed-Solomon, ciascuno contenente b data codewords e ecpb error-correction codewords.
• blocks=a x b, c x d: due gruppi di blocchi; il primo ha a blocchi di b data codewords ciascuno, e il secondo ha c blocchi di d data codewords ciascuno. Ogni blocco in entrambi i gruppi porta le stesse ecpb error-correction codewords.

Esempio pratico:

V1 dim=21 align=[]
  L: total=52 data=38 ec=14 ecpb=7 blocks=2 x 19

significa:

• versione 1
• griglia interna 21 × 21
• nessun alignment pattern
• al livello di correzione degli errori L
• 52 codewords totali nel simbolo
• 38 data codewords
• 14 error-correction codewords
• 2 blocchi Reed-Solomon
• ogni blocco contiene 19 data codewords e 7 error-correction codewords

La tabella HCC2D8 seguente usa esattamente gli stessi significati dei campi.

Parametri derivati dal QR Code (ISO/IEC 18004:2006) tramite l'applicazione del moltiplicatore di codifica colore HCC2D.

20. Tabella dei parametri HCC2D8 esplicita

I seguenti valori sono i parametri di versione HCC2D8. Sono i totali completi HCC2D8 e i layout dei blocchi.

Parametri derivati dal QR Code (ISO/IEC 18004:2006) tramite l'applicazione del moltiplicatore di codifica colore HCC2D.

21. Nota di pubblicazione

Questa specifica non ripubblica intenzionalmente il contenuto del finder pattern, alignment pattern, timing pattern, correzione degli errori o mask rules associati al QR Code. Per le parti riutilizzate, indica solo che seguono le stesse strutture usate dal QR Code, o strutture compatibili con ISO/IEC 18004:2006, e poi specifica completamente le parti specifiche di HCC2D e le tabelle dei parametri HCC2D.

Di conseguenza, questo documento deve essere letto come:

• completo per il comportamento specifico di HCC2D
• intenzionalmente non esaustivo per evitare di ripubblicare informazioni relative a componenti dei codici QR
• normativo insieme alle specifiche dei codici QR, per la definizione di quei componenti dei codici QR che vengono riutilizzati dai codici HCC2D

Allegato A — Esempi illustrativi

I seguenti simboli sono codici a barre HCC2D conformi a questa specifica. Ogni simbolo è scansionabile con l'app ufficiale HCC2D Decoder. Le figure sono renderizzate a 0,80 mm per modulo. Questo corrisponde alla dimensione fisica sulla pagina stampata quando la versione PDF di questa specifica viene stampata al 100% su carta.

I seguenti simboli codificano Tintern Abbey di William Wordsworth (6.900 byte, contenitore HCC2DF con compressione zlib), dimostrando la capacità HCC2D per testi lunghi.

— Fine della Specifica —