HEX V8 — Preprint (português Brasil)

v1.5.4Satinus E.I.R.L. · 2026 · Relatório técnico [18]

HEX V8: um símbolo 2D ternário hexagonal com capacidade escalável e leitura móvel sob condições de impressão controladas

Autor: Jorge Figueroa
Afiliação: Pesquisador independente, Satinus E.I.R.L., Chile
Contato: jorgefigueroacifuentes@gmail.com, satinuseirl@gmail.com
Data: 2026-07-23 (preprint PT-BR, revisão editorial a partir do manuscrito ES)

Resumo

Os códigos bidimensionais dominantes — QR Code, Data Matrix e Aztec — codificam o payload em módulos binários sobre uma grade retangular. Esse design favorece o ecossistema e a leitura integrada em smartphone, mas impõe um teto prático de bytes recuperáveis quando o símbolo deve permanecer legível com óptica móvel, distância típica de escaneamento e impressão monocromática.

Este trabalho formula uma pergunta delimitada: sob regras explícitas de escala em milímetros e com um leitor dedicado, um símbolo monocromático com geometria distinta da grade e mais de dois estados por elemento físico pode transportar mais bytes úteis do que um QR de referência com legibilidade comparável? A resposta avaliada é HEX V8: malha triangular ternária empacotada em losangos S2-octal; cabeçalho autodescritivo de 8 bytes; Reed–Solomon em GF(256) com apagamentos nativos do par (1,1); ring interleave; padding determinístico; e camada visual checkerboard (spec v1.1), decodificada por um pipeline móvel alinhado ao anel hexagonal e ao parâmetro N.

Sob um protocolo declarado (RS-M, 300 DPI a 100%, captura a 25–35 cm, tri_mm (aresta média do triângulo impresso, em mm) ≈ 5 mm, sessão Auto N8→N15), um modelo fechado de capacidade, uma regressão sintética 15/15 e testes de campo em papel com o leitor Android 0.4.7 — instalado como APK de distribuição livre — em um Redmi Note 9 Pro documentado produzem 137 B de payload útil em HEX N15 (impresso ≈ 85 mm) frente a ~37 B de um QR de referência a ~25 mm na mesma legibilidade de aresta. Isso não é uma afirmação de mesma área impressa: com $\mathrm{tri_mm}$ fixo, aumentar $N$ aumenta $\mathrm{code_mm}$ (p. ex. N10 a 58 mm transporta 35 B; N15 a 85 mm transporta 137 B). HEX V8 não substitui a universalidade do QR nem reduz a área impressa de um QR pequeno: é um canal monocromático especializado que exige aplicativo dedicado, impressão controlada e enquadramento angular estrito em N altos.

Palavras-chave: código 2D; código de barras 2D; codificação ternária; malha hexagonal; Reed–Solomon; visão computacional móvel; capacidade de payload; QR Code; Data Matrix; Aztec; simbologia monocromática

1. Contexto: códigos bidimensionais e capacidade sob limites de legibilidade

Os códigos de barras bidimensionais atuam como um canal físico: convertem um payload de dados — sequência de bytes com significado para o aplicativo — em um padrão imprimível ou exibível, e um leitor com câmera tenta recuperar esses bytes. Na prática, o payload viaja em claro no símbolo; a correção de erros protege contra danos de impressão e captura, e não substitui a criptografia.

O modelo dominante — QR Code [1,7], Data Matrix [2], Aztec [3] — empacota a informação em módulos binários (dois estados por célula: claro ou escuro) sobre uma grade retangular. Após detectar marcadores de sincronização (finders, bullseye, perímetro), o leitor amostra cada módulo e reconstrói bits; a camada lógica aplica Reed–Solomon [5] em GF(256) sobre blocos de bytes. A versão ou o tamanho do módulo escala a capacidade: quanto maior a versão, mais linhas de módulos e mais bytes possíveis, ao custo de um símbolo fisicamente maior ou de células menores e mais difíceis de ler.

Esse design prioriza ecossistema: padronização (p. ex. ISO/IEC 18004 [1]), leitores integrados em smartphones e fluxos de impressão conhecidos. O custo estrutural é um teto de capacidade útil sob legibilidade móvel: quantos bytes recuperáveis restam disponíveis quando o elemento mínimo impresso deve permanecer legível com ópticas móveis, distância típica de ~25–35 cm e impressão monocromática cotidiana [6,17]. Reduzir o módulo aumenta os bits/mm² nominais, mas reduz a margem ante desfoque, curvatura do suporte e resolução efetiva da câmera — assim, “maior densidade” e “mais payload útil sob leitura de campo” não são o mesmo objetivo.

Outras simbologias abordam o mesmo problema com compromissos distintos. DotCode [16] visa impressão industrial de alta velocidade e permanece binário por ponto. Os códigos multicanal em cor [13,14] multiplicam estados por célula, mas exigem reprodução fiel de cor e calibração de câmera — condições mais frágeis do que o monocromático em campo. MaxiCode [15] emprega células hexagonais em um formato fechado de mensagens, não um codec aberto de bytes arbitrários. Em conjunto, a família ISO mais difundida compartilha um pressuposto: um módulo ≈ um bit, amostragem sobre grade (ou equivalente retangular) e pipelines de leitura projetados para esse pressuposto [8–10,17].

A leitura com câmera móvel está bem documentada: detecção, correção de perspectiva (homografia), binarização e decodificação RS. Essas técnicas não se transferem automaticamente a um símbolo com outra geometria ou mais de dois estados por elemento sem redesenhar detecção, amostragem e camada lógica. Permanece aberta, como pergunta de design, a exploração de formatos monocromáticos, com leitor dedicado e regras de impressão explícitas, quando o objetivo é priorizar capacidade de payload diante da universalidade de leitura.

2. Pergunta de pesquisa

Diante do panorama de §1, este trabalho parte de uma pergunta aberta e delimitada:

É possível projetar um símbolo 2D monocromático, com geometria distinta da grade binária e mais de dois estados por elemento físico, que transporte mais bytes úteis de payload do que os códigos de referência (p. ex. QR) com legibilidade móvel comparável, sendo legível com um leitor dedicado sob condições explícitas de impressão?

Não se pergunta se buscamos um substituto do QR em ecossistema, norma ISO ou confidencialidade. Não se pergunta se o HEX empacota mais bits em uma caixa impressa menor do que um QR compacto. Pergunta-se se existe uma alternativa mensurável em payload útil quando o símbolo é impresso e lido sob regras declaradas: tamanho em milímetros, resolução de impressão, distância de captura e limiar de legibilidade do elemento mínimo (tri_mm) — quantificados em §4 e §6. Sob essas regras, aumentar $N$ troca uma área impressa maior por mais bytes, mantendo a legibilidade de aresta aproximadamente fixa.

O restante do artigo relata como essa alternativa foi buscada: o que foi testado, quais camadas foram adicionadas até convergir para a versão avaliada, quais dados foram obtidos e o que se entrega como evidência. O nome HEX e o protocolo V8 designam essa convergência; o significado da sigla será explicitado em §3.7.

Organização. §3 traça a evolução do design até HEX V8 (camada lógica em §3.5; Tabela 1). §4 quantifica capacidade e escala de impressão (Tabela 2). §5 descreve o leitor móvel dedicado (perfis, estágios e resolução de N; Tabela 7). §6 declara o protocolo de avaliação (Tabela 6), reporta evidência sintética e de campo e oferece uma comparação delimitada com QR (Tabelas 4–5b). As contribuições numeradas aparecem em §8.2, após a evidência. §7–§9 cobrem limitações, conclusões e disponibilidade de materiais. Os apêndices indexam termos e floats.

3. Construção do formato: evolução do design

A partir da pergunta de §2, abriu-se uma linha de design que mais tarde se denominou HEX. O formato não foi definido de uma só vez: esta seção segue a ordem em que as ideias foram testadas e se adicionaram camadas, cada uma em resposta ao limite da anterior, até a versão V8 avaliada em §6.

Figura 7. Sequência de decisões de design (§3.1–3.7).

3.1 Ponto de partida: favo de mel hexagonal binário

A primeira proposta concreta foi deliberadamente modesta: um símbolo com silhueta hexagonal formado por módulos hexagonais binários (branco/preto), inspirado na tesselação do favo de mel, mas conservando o bit por célula do QR. O payload concentrava-se em uma borda codificada com Reed–Solomon; o interior cumpria principalmente uma função estrutural. Foi um banco de provas teórico: verificar se a geometria hexagonal merecia exploração antes de investir em um alfabeto mais rico.

Paralelamente, foram definidas restrições alinhadas com §2: sem canal RGB [13,14]; sem assumir o leitor QR do telefone; sim aceitar um leitor dedicado e regras de impressão explícitas (DPI, tamanho em mm) em troca de buscar mais bytes úteis em um limiar de aresta declarado, não uma área impressa menor do que um QR compacto.

3.2 Primeira linha: borda binária (insuficiente)

A implementação agrupou triângulos em módulos hexagonais de primeiro nível e codificou dados no perímetro. As capacidades medidas foram da ordem de 18 B (N8) a 64 B (N20) — muito abaixo de um QR comparável (p. ex. versão 10 nível M ≈ 652 B na referência usual).

O hexágono grosso como unidade e um canal binário perimetral desperdiçavam a área interior e não competiam em densidade com a grade QR madura. Era necessário mudar alfabeto e empacotamento, não apenas a silhueta exterior.

3.3 Malha triangular e trit

A silhueta foi fragmentada em uma malha triangular hexagonal — tesselação bariocêntrica de triângulos equiláteros alternados upright e inverted. Cada triângulo codificável leva um trit, dígito ternário $\in{0,1,2}$. Nominalmente cada trit aporta $\log_2 3\approx 1{,}58$ bit de informação por célula, frente a 1 bit do módulo QR.

Os trits isolados, contudo, não formam bytes estáveis nem resistem ao ruído de captura sem uma camada lógica adicional.

3.4 Losango, S2-octal e parâmetro N

Os trits são empacotados em losangos: cada losango une um triângulo upright com um inverted adjacente (aresta compartilhada). Dois trits admitem nove combinações; oito mapeiam-se a um símbolo de dados S2-octal de 3 bits e o par (1, 1) é reservado como apagamento nativo (§3.5.1) — essa é a ponte das células ternárias para o alfabeto octal de computação, não a afirmação de que um trit valha três bits.

O número inteiro N é o número de divisões radiais da malha triangular do favo de mel (quão finamente o hexágono é subdividido em coroas concêntricas de triângulos). Não é um “número de versão” estilo QR desenhado como hexágonos aninhados. A maior $N$, mais triângulos codificáveis e, portanto, mais losangos de payload (§4); com $\mathrm{tri_mm}$ fixo, também aumenta a largura flat-to-flat impressa $\mathrm{code_mm}$. A unidade de codificação atômica é o losango, não o triângulo isolado ou o hexágono grosso do §3.2.

Figura 4d. Escalonamento da área impressa e payload útil (RS-M) com parâmetro $N$ (subconjunto N8/N12/N15; valores na Tabela 2). Com legibilidade de aresta comparável, aumentar $N$ aumenta $\mathrm{code_mm}$ e a capacidade.

Sob as alternativas exploradas nesta linha — trit isolado, hexágono binário grosso (§3.2) e empacotamento experimental por células de três losangos - S2-octal oferece o melhor equilíbrio até a data entre capacidade, alinhamento a bytes/RS e rastreabilidade óptica (§3.5.1, §7). O agrupamento de três losangos por hexágono foi avaliado apenas como hipótese de packing e não entra no codec V8; é mencionado aqui por completude do design.

Figura 4b. Atlas de losangos: oito símbolos de dados (3 bits) e o par (1,1) reservado como apagamento. Aresta compartilhada entre upright e inverted.

3.5 Camada lógica: S2-octal, header, interleave e Reed–Solomon

A captura não retorna trits perfeitos: manchas, compressão JPEG, desfoque e ambiguidade de classificação transformam o símbolo impresso em um canal ruidoso. A camada lógica V8 responde com três decisões acopladas: um alfabeto físico com sinal de apagamento, uma ordem de escrita resistente a dano local e um bloco de metadados autocontido.

3.5.1 S2-octal e símbolos de apagamento nativos

Cada losango aporta dois trits $(t_a, t_b)$. Nove combinações são possíveis; oito mapeiam-se para símbolos de dados ${0,\ldots,7}$ (3 bits cada) e o par (1, 1) é excluído da tabela de codificação. Se o leitor classifica um losango como (1, 1) — uma ambiguidade típica do checkerboard sob ruído – o decodificador não o interpreta como dados: registra-o como apagamento (erasure) em uma posição conhecida. Em Reed–Solomon, corrigir um apagamento consome metade da paridade de corrigir um erro em uma posição desconhecida; o design alinha o alfabeto físico com o tipo de falha mais comum na captura móvel.

Os símbolos são empacotados em bytes (MSB-first, três símbolos por byte com um bit de padding) antes de aplicar RS em GF(256), o mesmo que em QR, mas a unidade de correção visual ainda é o losango, não o byte isolado.

3.5.2 Cabeçalho V8 (8 bytes)

O cabeçalho é um bloco fixo de 8 bytes serializado em big-endian. Viaja no início do fluxo lógico e é replicado nos primeiros losangos da malha. Sua integridade protege-se com CRC-8/MAXIM sobre os sete primeiros bytes; o decodificador rejeita cabeçalhos corrompidos antes de tentar RS (fail-fast).

Tabela 1. Layout do cabeçalho V8

Os 22 losangos reservados em §4.1 correspondem às posições $\lceil 64/3 \rceil$ necessárias para empacotar esses 8 bytes como símbolos S2-octal na malha.

3.5.3 Ring interleave

Sem interleave, um arranhão ou mancha local destruiria bytes contíguos do payload. No V8 o codificador ordena os losangos de dados por coroa hexagonal da malha de dados (interior → exterior) e, dentro de cada coroa, distribui em round-robin setorial (seis setores do favo de mel). Essa ordem lógica de escrita é diferente do anel visual de §3.6 (o perímetro preto grosso usado para pose/detecção $N$). Os bytes codificados são escritos em ordem de interleave; o decodificador reconstrói o fluxo lógico invertendo a permutação (deinterleave).

Efeito prático: a corrupção local da imagem resulta em erros dispersos no bloco RS, e não em um segmento contíguo da mensagem. O sinalizador ring_interleave no cabeçalho documenta que o símbolo usa esta ordem; no V8 canônico está sempre ativo.

3.5.4 Reed–Solomon (nível M)

Todos os experimentos neste artigo usam RS nível M (~20% de paridade sobre o bloco de dados). O codificador calcula o layout do bloco (dados + paridade) dentro do espaço disponível em losangos após reservar cabeçalho e âncoras; o valor rs_nsym resultante é gravado no cabeçalho para que o decodificador aplique a mesma configuração sem parâmetros externos.

O nível M equilibra capacidade e espaço em face de JPEG, leve desfoque e erros de classificação trit - condições típicas para o corpus sintético (§6.1) e o campo de papel (§6.2).

3.5.5 Padding determinístico

Losangos não ocupados por cabeçalho, payload RS e paridade preenchem-se com símbolos pseudo-aleatórios, mas reproduzíveis S2-octal. A semente é derivada de BLAKE2b-64("HEXV8_PAD" ‖ header ‖ data ‖ N) e um gerador xorshift64* produz a sequência trit. O codificador e o decodificador geram o mesmo padding no mesmo contexto, sem armazená-lo explicitamente no símbolo. Após a decodificação do RS, o payload é truncado para data_length do cabeçalho; o padding nunca é confundido com dados válidos.

Tomados em conjunto, a contribuição de §3.5 não é Reed–Solomon em abstrato, mas o alfabeto de co-design com apagamento nativo + ordem entre anéis + cabeçalho independente + padding verificável.

3.6 Materialização de tinta: especificação visual v1.1

Três estados ternários devem sobreviver à impressão monocromática sem depender do cinza plano – a tinta geralmente funde os tons de cinza médios. Convenção de implementação (alinhada ao codificador/decodificador de referência):

Figura 4. Três estados ternários em orientação vertical e invertida (atlas didático). Trit 1 é discriminado pela textura, não pelo tom contínuo.

Figura 4c. Recorte de um símbolo impresso: o checkerboard sob captura real.

Um anel visual hexagonal no perímetro sincroniza a orientação e permite que N seja estimado antes da leitura do núcleo. Fora do ringue, uma quiet zone (margem branca) cumpre a mesma função que a quiet zone QR. Dentro desta margem, próximo à borda interna do anel, o codificador de referência pode desenhar um padrão de temporização de quiet zone opcional: seis segmentos retangulares brancos/pretos alternados por face do hexágono. É uma banda de calibração binária entre a malha de dados ternária e o anel visual - útil como uma dica auxiliar de alinhamento - enquanto a pose, escala e estimativa de $N$ ainda são governadas pelo anel visual e pela proporção do anel (§5.2). A geração de imagens usa 300 DPI, escala 100% e superamostra raster (detalhes em [18]).

A camada visual não é decoração: o trit 1 deve ser legível pela imagem integral na câmera, e não apenas pela inspeção humana.

3.7 Convergência: Protocolo HEX V8

As camadas anteriores convergem em HEX V8 (Hexagonal Encoding eXtended), um codec visual bidirecional: converte payload de bytes e valor N em imagem (PNG/PDF) e recupera bytes de uma fotografia.

Codificar: cabeçalho → RS sobre o espaço disponível → bytes para S2-octal → ring interleave → preenchimento → mapa de triângulo + anel + margem → rasterização.

Decodificação: escala de cinza e recorte → anel visual → pose e N → homografia → amostragem de trits → losangos → deinterleave → RS com apagamentos (erasures) → validação de cabeçalho → truncamento para data_length.

Invariantes: dentro da capacidade do §4, ida e volta (decode(encode(data)) = data); após corrupção irrecuperável, fail-fast (erro explícito, sem decodificação silenciosa incorreta).

Figura 1. Pipeline lógico: codificação (esquerda), canal físico (centro) e decodificação (direita).

Figura 2. Renderização de referência (N=10, RS-M): anel visual, quiet zone (com segmentos de temporização opcionais na borda interna do anel) e malha triangular.

4. Capacidade e escala física

Com o formato definido (§3), a questão do §2 torna-se quantitativa: quantos bytes cabem por N e em que tamanho imprimir?

4.1 Capacidade geométrica

A geometria depende do parâmetro N (divisões radiais da malha hexagonal). Dois anéis externos são reservados para a cronometragem anel visual; o núcleo interno é deixado para os dados. Definimos o kernel de dados:

$$K = N - 3$$

equivalente a anéis codificáveis $L = N - 2_{\text{visual}} - 1$ na malha bariocêntrica.

Etapa 1 — triângulos codificáveis. Por setor (seis setores no favo de mel), o mosaico fornece triângulos de dados $K^2$; no total:

$$T_{\text{dados}} = 6K^2$$

Etapa 2 — losangos. Cada losango consome dois triângulos (adjacente na vertical + invertido). Os losangos de dados são agrupados em três bandas concêntricas de posições $K$, com sobreposição de bordas entre as bandas:

$$\text{rombos}_{\text{bruto}} = 3K(K-1)$$

Etapa 3 — sobrecarga fixa (em losangos, não em bytes):

Etapa 4 — bytes geométricos. Cada losango de payload contribui com 3 bits:

$$\text{pay_rombos} = 3K(K-1) - 25$$

$$\text{payload_bytes_geom} = \left\lfloor \frac{\text{pay_rombos} \times 3}{8} \right\rfloor$$

Esta expressão é a capacidade geométrica: limite superior do espaço disponível para o bloco lógico (cabeçalho + payload RS + preenchimento) antes de considerar a eficiência do empacotamento.

Exemplo ($N=15$). $K=12 \Rightarrow \text{rombos}_{\text{bruto}} = 396$; menos 25 losangos de payload $\Rightarrow 371$ geométricos $\Rightarrow \lfloor 371 \times 3 / 8 \rfloor = 139$ B (Tabela 2).

Exemplo ($N=10$). $K=7 \Rightarrow 101$ losangos de payload $\Rightarrow 37$ B geométrico; com RS-M o payload máximo medida é 35 B (Tabela 2).

4.2 Escala em milímetros

A borda central do triângulo impresso (tri_mm) é dimensionada com a largura plana a plana do hexágono (code_mm) e com N:

$$\text{tri_mm} \approx \frac{\text{code_mm} \times 0{,}86}{N}$$

O fator 0,86 relaciona a largura do hexágono à borda do triângulo na malha bariocêntrica. Este ligeiro desvio do ideal geométrico ($\approx 0{,}866$) deve-se estritamente à compensação da tolerância de impressão (sangria ou inserção visual dourada) na geração do raster.

Invertendo a fórmula, dado um alvo tri_mm e um N desejado, o tamanho de impressão se torna:

$$\text{code_mm} \approx \frac{\text{tri_mm} \times N}{0{,}86}$$

Limiar de campo. Leitura móvel confiável necessária empiricamente tri_mm ≳ 5 mm em alto N. Abaixo, a classificação de trit 1 (checkerboard) e a estimativa de N degradam. O protocolo de avaliação (§6) define tamanhos de impressão por N (Tabela 2) para manter esse limite: N8/N10 em 58 mm (tri ≈ 6,2 / 5,0 mm), N12 em 70 mm e N15 em 85 mm (tri ≈ 5,0 / 4,9 mm).

Regra de leitura (anti-confusão). Não leia a Tabela 2 como “N15 embala 137 B na mesma caixa de 58 mm que N10”. No $\mathrm{tri_mm}$ emparelhado, $\mathrm{code_mm}$ cresce aproximadamente com $N$ (fórmula §4.2). N10@58 mm ≈ 35 B e N15@85 mm ≈ 137 B são pontos de mesma legibilidade, não da mesma área. A referência QR ~37 B em ~25 mm (§6.4) é ainda menor; HEX altera o espaço ocupado para payload abaixo do limite declarado.

Figura 5. Tamanhos em milímetros validados em campo; impressão em 300 DPI, escala 100%. Cap. é a capacidade geométrica (Tabela 2); Payload é a cadeia de demonstração desta planilha, não o RS-M máximo.

4.3 Capacidade útil com RS (nível M)

A capacidade geométrica é um limite do espaço em losangos; a payload clara máxima é menor porque o bloco RS ocupa paridade dentro do mesmo espaço. Para cada N, o codificador de referência procura o maior data_length admissível com RS-M através de pesquisa binária no espaço disponível (junho de 2026); Os resultados estão na coluna Max Data da Tabela 2.

A coluna Utilização mede qual fração dos trits codificáveis da malha é ocupada pela saturação do símbolo (dados + paridade RS + cabeçalho compactado), não a simples proporção dados/geom. Com N mais alto, a utilização aumenta (~83% em N8 → ~90% em N15) porque a sobrecarga fixa de 25 losangos é diluída.

Relação geométrica → útil. Aproximadamente, RS-M reserva ~20% do bloco para paridade; a diferença entre Cap. geom. e Max.Data na Tabela 2 são pequenos em bytes porque o cabeçalho já está descontado na fórmula em §4.1 e a paridade se ajusta ao espaço restante. Detalhe do layout por N no relatório técnico [18].

Tabela 2. Capacidade por nível N (RS-M)

Figura 3. Crescimento da capacidade útil com N (valores da Tabela 2).

5. Leitor móvel: da foto ao payload

Um símbolo de maior capacidade sob o protocolo §4–§6 não é lido pelo scanner QR integrado do telefone. É necessário um pipeline de decodificação móvel alinhado com trits, anel hexadecimal e variável N. Esta seção descreve a arquitetura do leitor utilizado na avaliação de campo (versão 0.4.7, julho de 2026)—a linha de base do §5.6—, complementar ao codec do §3.7.

5.1 Por que um aplicativo dedicado é necessário

A decodificação móvel reutiliza componentes padrão [8–12] - escala de cinza, homografia, Reed–Solomon - mas o suposto QR (módulo binário na grade, localizadores retangulares, versão discreta) não se traduz diretamente em HEX. O leitor dedicado adiciona cinco recursos que um pipeline QR não possui:

1. Detecção de anel visual hexagonal e estimativa de escala antes da leitura dos dados.
2. Resolução N —o símbolo pode ser N8, N10, N12 ou N15 na mesma sessão.
3. Classificação ternária por triângulo, incluindo a textura xadrez do trit 1 (§3.6).
4. Deinterleave por coroas de acordo com a ordem de escrita V8 (§3.5.3).
5. Adaptação de cena — papel, monitor moiré, N15 denso — sem baixar a bateria em uma única digitalização cara.

Sem essas peças não é possível recuperar o payload mesmo com o mecanismo de decodificação correto: o gargalo no campo não é a camada RS, mas sim geometria + classificação + política de novas tentativas.

5.2 Captura e região de interesse

A IU define uma caixa de enquadramento; Ao capturar, uma região de interesse (ROI) é cortada do quadro com correção de polarização vertical empírica (monitor: o símbolo geralmente cai ligeiramente abaixo do centro óptico se não for compensado). Antes da decodificação, as métricas de cena são calculadas – contraste local, variação, dispersão de intensidade – usadas pelo roteador na Seção 5.4.

Cada tentativa começa com uma imagem em tons de cinza. O primeiro passo geométrico é detectar o anel visual: varredura radial a partir do centro estimado em busca da faixa escura do perímetro hexagonal. A partir do anel, obtém-se o centro refinado, a orientação e a razão do anel (quociente entre os raios externo e interno), que se correlaciona com N (por exemplo, N10 ≈ 0,874, N15 ≈ 0,887). Se a proporção for ambígua, o leitor mantém vários candidatos de N em vez de corrigir o candidato errado. Quando o padrão de temporização da quiet zone de §3.6 estiver presente, o gasoduto pode pontuar a concordância do segmento como uma verificação auxiliar opcional do alinhamento radial; Não substitui a detecção do anel nem condiciona o sucesso da descodificação.

5.3 Kernel geométrico por tentativa

Após detectar o anel, o pipeline executa o núcleo compartilhado com §3.7:

1. Homografia — retifica o plano do símbolo em direção a uma malha canônica, corrigindo perspectiva e rotação (âncoras nos setores 0, 2, 4).
2. Pré-processado — contraste, desfocado (desfocado) e variantes de escala de acordo com o estágio S0/S1/S2 (§5.4).
3. Amostragem Trits — integral por triângulo retificado; trit 1 por tabuleiro de damas (§3.6).
4. Losangos e deinterleave — símbolos octais S2; inversão do ring interleave (§3.5.3).
5. RS + cabeçalho — GF(256) com apagamentos em (1,1); validação do cabeçalho V8 (Tabela 1) e truncado para data_length.

A latência adiciona captura (~1,4–2,0 s) e decodificação (dezenas de ms a ~3,5 s em N alto, §6.2). As novas tentativas multiplicam a decodificação, não a captura.

5.4 Roteador de perfil e estágios S0 → S1 → S2

Antes de dimensionar o custo, o leitor 0.4.7 classifica a cena (ProfileRouter). Em caso de dúvida no papel, o caminho conservador é perfil de papel (mais rápido).

Tabela 7. Comportamento por perfil e estágio (resumo)

Os estágios S0–S2 são políticas de custo: mais combinações de pré-processamento e mais tentativas por N candidato. No papel, a maioria dos acertos ocorre em S0; no monitor N15, S1 limitado a duas variantes evitou varreduras de 12–23 s de versões anteriores. Muitos hatch_fail devido ao baixo enquadramento não esgotam S2: o operador reformula (centerDy ≈ −14 px em ocorrências N15, §6.2).

Resolução de 5,5 N e rastreamento de sessão

No modo Auto, a resolução de N segue esta ordem:

1. Pill N — Corrigido N na UI → um único candidato.
2. sessionNHint — último N hit; sequência 8 → 10 → 12 → 15; após N12, N15 é testado primeiro.
3. Proporção do anel — estimativa do anel; até quatro candidatos se houver ambiguidade.
4. Expansão por etapa — mais candidatos em S1/S2 se S0 falhar.

Com sessionNHint ≥ 12 no display, o leitor pode definir N da sessão e desabilitar autoScan para N15 —validado em monitor 4/4 (§6.3).

5.6 Linha de base avaliada

A campanha de campo de julho de 2026 usou o leitor Android (versão 0.4.7), instalado como APK de distribuição livre no dispositivo de referência: ProfileRouter ativo, resolução de $N$ antes da varredura, sessionNHint persistente, S1 limitado no monitor N15 e warp canônico experimental desativado. As métricas §6 (centerDy, decodeMs, perfil, estágio, candidatos $N$ e motivo da falha) foram registradas nessa construção durante as sessões de protocolo.

Figura 6. Pipeline de decodificação da linha de base avaliada (ROI → perfil → resolução de $N$ → estágios S0→S2 → núcleo geométrico → payload).

6. Avaliação experimental

Esta seção responde à pergunta em §2 sobre o artefato construído em §3–§5. Os experimentos compartilham um protocolo comum (§6.0); Em seguida, são relatados três eixos: regressão sintética (§6.1), campo no papel (§6.2) e campo no monitor (§6.3), fechando com a comparação limitada contra QR (§6.4). Salvo indicação em contrário, as métricas de campo móvel (centerDy, decodeMs, perfil/estágio) vêm da linha de base 0.4.7 de §5.6.

Protocolo de avaliação 6.0

Tabela 6. Parâmetros de protocolo fixos

Procedimento de campo (papel). (1) Imprima a folha de referência (Fig. 5). (2) Instale o APK 0.4.7 usado neste estudo. (3) Abra o modo Auto; Após cada leitura correta, avance para o próximo N sem reiniciar a sessão. (4) Enquadre o símbolo ativo dentro da caixa; em N15, centralize o código ligeiramente acima do centro óptico (centerDy ≈ −14 px em acessos).

Critérios de falha aceitáveis versus bloqueio. Uma falha devido a hatch_fail ou cabeçalho inválido com centerDy positivo é classificada como erro de enquadramento, não como regressão de codec. Uma falha RS com símbolo bem centrado e perfil correto seria bloqueio; Não foi observado nas sessões de julho de 2026.

Resolução angular (paraxial). A discriminação do checkerboard trit (§3.6) e o limiar tri_mm ≈ 5 mm (§4.2) dependem da distância de captura $D$ e da resolução angular óptica - distância focal efetiva $f$ e densidade de pixels do sensor $p$ (Tabela 6). Sob um modelo pinhole em regime paraxial (distorção desprezível próximo ao eixo óptico), a borda do triângulo projetado no sensor ocupa

$$p_{\text{tri,sensor}} \approx \frac{\text{tri_mm}}{D} \cdot \frac{f}{p}$$

(com comprimentos em mm). Os termos de tambor/almofada são omitidos: dentro do ROI do visualizador, o deslocamento radial é pequeno versus $D$, e polinômios móveis de grande angular típicos são de segunda ordem quando $|r|\lesssim 0{,}3\,D$.

Do quadro completo ao buffer de decodificação. Com tri_mm ≈ 4,9 mm, $D\approx 30$ cm, $f\approx 5{,}6$ mm (equivalente a 26 mm no sensor 1/1,72″) e $p\approx 1{,}6$ µm (binning 4:1 comum nesta classe de sensor), a ordem de grandeza no quadro completo é ~50 px/aresta antes do recorte. O pipeline corta o ROI e o redimensiona para aproximadamente 560 px de largura; em ocorrências N15, são relatados raios de anel de 126–164 px, ou seja, ~10–12 px/aresta no buffer – margem estreita para a textura de trit 1, alinhada com o limite operacional. A degradação periférica em N15 é tratada como um limite de campo (§7.1), não como uma correção dentro desta estimativa. Dispositivos com $f/p$ diferente ou faixa dinâmica podem cair abaixo dessa margem sem alterar o símbolo impresso, o que motiva a matriz multi-dispositivo (§7.1, §8.4).

6.1 Corpus sintético

O corpus de regressão do laboratório consiste em 15 imagens PNG geradas a partir de um símbolo base (N=8, payload Hola HEX) com deficiências controladas:

Resultado: os mecanismos de decodificação em Python e TypeScript recuperam 15/15 cargas úteis esperadas (npm run benchmark:matrix, junho de 2026). A latência p95 do mecanismo Python é ≈ 898 ms por imagem no hardware do laboratório. Este corpus valida o codec antes do ruído específico da impressão e da interface de captura.

6.2 Campo em papel

Sessões de julho de 2026 com APK 0.4.7 —Android, distribuição gratuita de APK— na planilha da Fig. 5, capturada com o Redmi Note 9 Pro da Tabela 6.

Tabela 3. Resultados do artigo

Telemetria da sessão confirmatória (04-07-2026). Quatro leituras corretas sequenciais N8→N15; cinco erros adicionais, todos ao tentar N15 com o símbolo abaixo do centro da caixa (centerDy +11…+26 px): três garbage_header, um crc_fail e um hatch_fail. N15 bem-sucedido: decodeMs 2.955 ms, centerDy −14 px, estágio S0, perfil função. Faixa decodeMs em acertos: 116–3524 ms (p95 marginal 3524 ms em N12, acima do limite de regressão de 3 s, mas sem falha funcional).

Interpretação. O formato V8 é estável no papel; o gargalo operacional é o enquadramento em N15, consistente com a maior densidade visual e área ativa do símbolo. Figura 9 (coluna esquerda) documenta leituras N8→N15 bem-sucedidas sob condições de folha impressa.

6.3 Campo no monitor (secundário)

O canal monitor é secundário: ele valida o perfil de exibição do leitor (§5.4) sob moiré e reflexos, mas o papel continua sendo o principal substrato de demonstração. A Figura 9 (coluna da direita) mostra leituras bem-sucedidas no monitor para os mesmos níveis de N do papel.

Moiré (por que é menos reproduzível que o papel). O moiré digital é uma mistura entre a frequência espacial do painel $f_{\text{display}}=1/d_{\text{display}}$ e a densidade de amostragem do pipeline $f_{\text{cam}}=p_{\text{tri,decode}}/\mathrm{tri_mm}$ após redimensionar o ROI (§6.0). No painel ThinkPad L14 WUXGA documentado [20], $d_{\text{display}}\approx 0{,}157$ mm e $f_{\text{display}}\approx 6{,}4$ ciclos/mm. Mostrado nos mesmos milímetros físicos da Fig. 5 (zoom de 100%), N15 fornece $p_{\text{tri,display}}\approx 31$ px/aresta no painel e, após pipeline, $p_{\text{tri,decode}}\approx 11$ px/aresta ($f_{\text{cam}}\approx 2{,}2$ ciclos/mm). Quando os harmônicos de malha ou checkerboard se aproximam do limite de Nyquist $f_{\text{cam}}/2$, o tremor altera a textura trit 1 e aumenta hatch_fail – distinto de uma falha de RS. Painéis com outro $d_{\text{display}}$ alteram esse acoplamento; é por isso que o monitor não é intercambiável com o papel.

As sessões douradas 2026-07-03 e 2026-07-04 usaram este L14 como a única tela de teste. N8/N10 no monitor exigiu ~6–7 s de decodificação (tela, S1 com moiré) antes de definir sessionNHint; O N12/N15 bem-sucedido caiu para 136–1333 ms com enquadramento fino. Sessão 03/07/2026: 4/4 OK, N15 em 1333 ms (desfocado, duas variantes, apenas S1). Confirmação 04/07/2026: 4/4 OK após oito falhas de enquadramento; N15 em 458 ms com centerDy ≈ −15 px. As falhas novamente seguem deslocamento vertical positivo (+1…+16 px). Com sessionNHint ≥ 12, S1 é limitado a duas variantes e as varreduras de 12–23 s das versões anteriores são evitadas.

Figura 9. Capturas de tela do aplicativo leitor Android (APK 0.4.7, distribuição gratuita; Redmi Note 9 Pro, julho de 2026): por linha, papel (esquerda, folha Fig. 5) e monitor (direita, ThinkPad L14 WUXGA, perfil tela) para N8, N10, N12 e N15. Cada painel mostra uma decodificação bem-sucedida sob o protocolo de §6.0. Os banners na tela informam bytes de capacidade geométrica (Tabela 2); O RS-M máximo útil é 11/35/69/137 B.

6.4 Comparação limitada com QR

Narrativa que esta seção rejeita. O HEX V8 não é apresentado aqui como “a evolução hexagonal do QR”, como um sucessor drop-in, nem como um formato simplesmente “3,7× mais denso”. A razão $137/37$ que aparece ao colocar N15 próximo ao QR de referência ~25 mm é uma razão de payload sob protocolo (mesma banda de $\mathrm{tri_mm}$ / RS-M declarado), não uma disputa de densidade por tamanho igual. O eixo decisivo são bytes úteis com legibilidade móvel comparável; a área impressa total em bits/mm² e a universalidade do ecossistema são deliberadamente deixadas em segundo plano (§7.3, Tabela 5b).

Tabela 4 contrasta o modelo de canal de simbologias binárias §1 típicas com HEX V8 (Figura 8d). Tabela 5 resume cargas úteis de referência no protocolo de campo (Figura 8). Tabela 5b adiciona área hexagonal impressa e densidade útil em bits/mm² (Figura 8c).

Tabela 4. Modelo qualitativo: simbologias típicas ISO vs HEX V8

Tabela 5. Carga útil de referência (protocolo de campo, tamanhos de folhas de referência)

Tabela 5b. Densidade e área útil (HEX V8 RS-M vs Referência QR §6.4)

Área do hexágono com largura flat-to-flat (W): (A = \frac{\sqrt{3}}{2} W^2). Densidade: (8 \times \text{payload (B)} / A). O QR de referência usa uma caixa quadrada (W\times W) como limite de área (não é um hexágono).

Como não ler as Tabelas 5–5b. Uma razão como $137/37\approx 3{,}7$ é uma taxa de payload sob o protocolo declarado, não evidência de que o HEX N15 ocupa os mesmos milímetros que o QR de referência, nem que o HEX ganha em bits/mm² de área total (a Tabela 5b mostra o oposto para a área do hexágono completo). Não há “equivalente a QR N15” neste manuscrito: o ponto QR é uma demonstração de campo em ~25 mm, enquanto HEX N15 é um símbolo de 85 mm em $\mathrm{tri_mm}\approx 5\,\mathrm{mm}$.

A comparação justa não é apenas “mais bytes em menos milímetros”, mas mais bytes mantendo a legibilidade móvel. O indicador operacional adotado é a aresta do triângulo impresso (tri_mm ≈ 5 mm, §4.2). Sob essa restrição, um QR de referência impresso a ~25mm na mesma banda de distância de captura (§6.0) carrega ~37B de payload em folhas de comparação de campo (ponto de demonstração limitado, não uma afirmação sobre todas as versões ou níveis ECC do QR). HEX N10 em tri ≈ 5 mm (~58 mm de largura plana a plana) atinge 35 B útil (RS-M) —mesma ordem de grandeza—; HEX N15 em tri ≈ 5 mm (~87 mm teórico; 85 mm em campo) atinge 137 B (Figura 8b). A Tabela 5 mostra os tamanhos validados em campo (Fig. 5): no N15 o protocolo utiliza 85 mm (tri ≈ 4,9 mm), um pouco abaixo do limite nominal, mas dentro da faixa observada (§6.2). HEX não reduz a área ocupada em mm em comparação com um QR pequeno: ele troca um hexágono impresso maior por mais payload ao dimensionar $N$, mantendo a legibilidade da aresta próxima ao limite declarado. Frases como “maior capacidade” ou “maior densidade” são, portanto, inseguras se essa compensação não for dita na mesma frase.

Leitura da Tabela 5b. Duas leituras de densidade devem ser distinguidas. (i) Densidade total da área ocupada usa a área hexagonal impressa $A(W)$ e fornece ≈0,175 bits/mm² para HEX N15 a 85 mm – inferior ao QR de referência em ~25 mm (≈0,47 bits/mm²), porque a área ocupada HEX inclui anel e quiet zone. (ii) A densidade do núcleo de trits restringe a área a (W_K=W\cdot K/N) (somente malha codificável) e aumenta N15 para ≈0,27 bits/mm²; esse número é uma métrica auxiliar do alfabeto, não uma afirmação de marketing de rótulo. De acordo com o protocolo declarado, a comparação decisiva é não “mais bits por mm² em qualquer escala”, mas mais bytes úteis com legibilidade comparável (tri_mm ≈ 5 mm), com uma densidade HEX de área total ainda crescendo com N em tri quase fixo (≈0,030 → ≈0,175 bits/mm² de N8 a N15; Figura 3, Figura 8b). Data Matrix [2] compartilha o alfabeto binário por módulo da Tabela 4; um ponto ISO específico não é tabulado aqui no mesmo protocolo de campo, para não misturar as capacidades nominais da versão com a referência QR já limitada no §6.4.

Figura 8d. Contraste qualitativo do modelo de canal (Tabela 4): QR / Data Matrix / Aztec compartilham alfabeto binário e topologia de grade; HEX V8 muda alfabeto, malha e leitor.

Figura 8. Carga útil (RS-M) sob o protocolo de campo (Tabela 5): Referência QR ~25 mm versus HEX N10 e N15.

Figura 8a. Relação entre bytes úteis (RS-M) e tamanho do símbolo (Tabela 2); Ponto QR de referência incluído.

Figura 8b. Comparação com legibilidade comparável (mesma aresta do triângulo impresso $\approx 5\,\mathrm{mm}$)—não com largura total igual.

Figura 8c. Densidade de área total útil (bits/mm²; Tabela 5b). O QR de referência em ~25 mm é mais denso por área; HEX ganha em bytes a tri comparável ao escalar $N$.

7. Limitações

A evidência no §6 apoia a questão no §2 sob regras explícitas; Fora desse quadro, o formato e o leitor não devem ser extrapolados sem novas medições.

7.1 Escopo experimental

A avaliação de campo documenta um único dispositivo (Redmi Note 9 Pro, Tabela 6) e uma versão do leitor Android (APK 0.4.7, §5.6), instalado por meio de distribuição gratuita de APK. Não há matriz de hardware entre OEMs, nenhum segundo sistema operacional, nenhuma varredura de iluminação controlada. O corpus sintético 15/15 (§6.1) valida o codec contra degradações de imagem, mas não substitui a variabilidade de impressão, enquadramento e latência da IU móvel (§6.2–6.3). Os resultados de campo são, portanto, uma prova de conceito nessa linha de base: sensores com menor faixa dinâmica, diferentes pipelines ISP ou maior distorção de grande angular podem deslocar a detecção de anel, a hatch e o decodeMs. A generalização requer a matriz multi-dispositivos priorizada em §8.4.

Teto empírico versus hardware moderno e industrial. As métricas de §6.2–6.3 delimitam a linha de base do Redmi Note 9 Pro; Eles não esgotam o teto teórico do formato ou do pipeline. Estimativas e validações de leitura e velocidade em hardware moderno (sensores de maior resolução, óptica dedicada, iluminação controlada) e em ambientes industriais (câmeras fixas, distância e ângulo nominalizados, substratos padronizados) são deixadas em aberto - como trabalho futuro ou via de colaboração em pesquisa - onde o modelo paraxial de §6.0 sugere margens de resolução angular e latências potencialmente superiores às observadas aqui, sem modificação do codec.

Modelo paraxial versus óptica periférica. Duas camadas não devem ser confundidas. (1) ROI paraxial/central. O modelo de projeção de §6.0 (pinhole, deslocamento radial pequeno) relaciona a borda do triângulo, distância $D$, focal $f$ e etapa $p$ dentro da caixa do visualizador onde o símbolo deve ser colocado. Explica a ordem de ~10–12 px/aresta no buffer de decodificação e permite estimar $p_{\text{tri,sensor}}$ em outros dispositivos. (2) Degradação periférica/fora do eixo. Quando o anel N15 de 85 mm se move em direção à periferia da lente, a aberração radial e a curvatura do campo aumentam; esse regime está fora do ponto ideal paraxial e é tratado como limite óptico de hardware/campo, não como evidência de fragilidade do codec.

Tolerância angular do quadro. A telemetria centerDy (deslocamento vertical do centro do anel detectado em relação ao centro do buffer de decodificação, em px) é traduzida para as mesmas unidades angulares. Com altura útil do sensor $h_{\text{sensor}}$ (≈ 7,2 mm em 1/1,72″), distância focal f, distância de captura D e altura do buffer $H_{\text{decode}}$ (≈ 560 px, Tabela 6),

$$\delta\theta_y \approx \frac{\text{centerDy}}{H_{\text{decode}}} \cdot 2\arctan\frac{h_{\text{sensor}}}{2f}$$

(equivalentemente, $\delta y \approx D \tan\delta\theta_y$ no plano de símbolo). Com f ≈ 5,6 mm, D ≈ 30 cm e a linha de base do Redmi Note 9 Pro, cada pixel de centerDy tem ≈ 0,7 mm e ≈ 0,12° na cena. Na sessão confirmatória de §6.2, os acertos N15 estão concentrados perto de −14 px (≈ −1,7°, símbolo ligeiramente acima do centro óptico); as cinco falhas em N15 estão em +11…+26 px (≈ +1,3°…+3,1°, símbolo abaixo da caixa). A janela empírica em elevação é da ordem de ±2° - coerente com a camada (2) acima (óptica periférica) - e não com falha Reed–Solomon ou S2-octal sob um símbolo bem centrado.

A métrica decodeMs em §6.2–6.3 não é generalizável sem uma matriz de vários monitores/vários dispositivos (§8.4). O modelo paraxial de §6.0 ainda permite estimar $p_{\text{tri,sensor}}$ em outros dispositivos antes de medir a latência de campo.

7.2 Escopo de formato e operação

Os níveis N8–N15 são validados em dispositivos móveis sob o protocolo §6.0. A cadeia Auto 8 → 10 → 12 → 15 omite a ímpar intermediária N (9, 11, 13) apesar de ser codificável (Tabela 2): não é uma limitação do codec, mas uma decisão de protocolo de campo e de geometria angular.

Geometria e incompatibilidade de fase. O favo de mel possui seis setores com triângulos $K^2$ cada ($K=N-3$, §4.1). O leitor estima N girando uma grade de amostragem angular com passo $\Delta\theta = 360°/N$ na malha bariocêntrica, enquanto as âncoras de temporização do formato - anel visual e setores 0, 2, 4 (§3.4) - são fixadas nas fases $0°$, $120°$ e $240°$. Um N é harmônico quando $\Delta\theta$ distribui essas fases uniformemente; equivalentemente, $360° \bmod N = 0$. N11 e N13 violam essa coerência de fase: a varredura rotacional não alinha exclusivamente a grade de estimativa com as âncoras de símbolo, o que aumenta a ambiguidade ao resolver N - elas são classificadas como dissonantes na heurística de design [18], e não como uma falha de codec. N9 é harmônico, mas fornece um passo de densidade quase iso-capaz para N10 sob o mesmo tri_mm (Tabela 2) sem benefício operacional; incluí-lo fragmentaria a varredura N e o espaço candidato ProfileRouter (§5.4–5.5). A progressão +2 até N12 mantém etapas de capacidade espaçadas com setores simétricos; N15 fecha a cadeia como um final denso validado (ímpar, mas harmônico: $\Delta\theta = 24°$).

Com N ≥ 18 e borda do triângulo abaixo de ~5 mm, a leitura não é mais confiável nos testes realizados.

O gargalo operacional em N alto é o frame, não o codec (um fenômeno diretamente correlacionado com a aberração óptica periférica prevista em §7.1): no papel, as faltas de sessão de confirmação (§6.2) são explicadas por centerDy positivo ao colocar N15 abaixo do centro do quadro. O canal do monitor (ThinkPad L14, $d_{\text{display}} \approx 0{,}157$ mm, §6.3) é secundário e menos estável que o papel devido ao moiré —sensível ao acoplamento $f_{\text{display}} \times f_{\text{cam}}$— e aos reflexos, embora confirme o perfil da tela do leitor.

HEX V8 não fornece confidencialidade intrínseca: o payload permanece clara no símbolo; a correção de erros protege a integridade contra danos físicos e não substitui a criptografia ou a autenticação de aplicativos. Empacotamentos alternativos na mesma malha (por exemplo, agrupamento de três losangos por hexágono) foram explorados fora do codec canônico e não melhoraram a capacidade ou o alinhamento de bytes (§3.4).

7.3 Comparação, ecossistema e status do documento

A comparação com QR (§6.4, Tabelas 4–5) é limitada ao protocolo declarado - RS-M, tri_mm ≈ 5 mm, um QR de referência em ~25 mm - e não se destina a cobrir todo o ecossistema ISO ou todos os níveis de correção QR.

HEX requer leitor dedicado e regras de impressão explícitas; não compete em universalidade de leitura com câmeras QR integradas. Este manuscrito é um preprint sem revisão por pares. A reprodutibilidade expandida – especificações detalhadas, tabelas, telemetria de campo e procedimentos de regressão – está documentada no relatório técnico [18].

8. Conclusões e resultados

8.1 Resposta à pergunta em §2

A pergunta do §2 permite uma resposta afirmativa e limitada. Sob as condições do protocolo (§6.0, Tabela 6) - impressão monocromática controlada, tri_mm ≳ 5 mm como critério de legibilidade, leitor dedicado com perfis e resolução de N (§5) - o artefato HEX V8 avaliado carrega mais bytes úteis do que referências QR declaradas com legibilidade comparável: até 137 B em N15 / ≈85 mm com RS-M (Tabela 2, Figura 8b) versus em ~37 B de um QR de referência em ~25 mm. A resposta afirmativa é não “HEX substitui QR” nem “137 B cabe em uma etiqueta de 25–58 mm”; é "mais bytes úteis quando a legibilidade da aresta é mantida próxima a 5 mm." Nenhuma validade é reivindicada fora desse quadro (§7).

A evidência é complementar, não intercambiável:

1. Codec — regressão sintética 15/15 (§6.1): teste necessário do mecanismo lógico em relação a JPEG, desfoque, deslocamento e perspectiva; não substitui impressão ou captura de UI.
2. Campo — 4/4 OK N8→N15 sequencial no papel com APK 0.4.7 no Android (APK de distribuição livre; §6.2, Figura 9), em um Redmi Note 9 Pro documentado. As cinco falhas da sessão confirmatória em N15 carregam centerDy +11…+26 px (≈ +1,3°…+3,1°, fora do ponto ideal paraxial de §7.1); o acerto correspondente usa o padrão centerDy −14 px (≈ −1,7°)—peripheral framing, não o erro RS. Em alto N, o pescoço operacional é enquadramento/óptica, não Reed–Solomon.
3. Comparação — critério operacional tri_mm ≈ 5 mm (§6.4), não densidade nominal em mm² ou embalagem com área igual; Para igual legibilidade, o N15 supera o QR de referência em payload, não em tamanho mínimo impresso.

O que não afirmamos (já excluído no §2 e detalhado no §7): substituição do QR em ecossistema ou padrão ISO; um “próximo QR” evolutivo; confidencialidade intrínseca; leitura universal sem aplicativo dedicado; generalização para outro hardware sem novas medições; uma afirmação de rótulo “3,7 × mais denso” no mesmo tamanho. HEX altera a área impressa pelo payload escalonando $N$, com leitor dedicado e sensibilidade ao enquadramento em N15 - consistente com o arco de design de §3 (a borda binária de §3.2 não atingiu essa banda de payload; V8 atingiu, sob as regras anteriores).

8.2 Contribuições

O seguinte resume o que é suportado nos §3–§6, alinhado com o não escopo do §2 e as limitações do §7:

1. Especificação convergente HEX V8 com evolução de design documentada (§3).
2. Modelo de capacidade geométrica fechada e tabela empírica N8–N15 com RS-M (§4, Tabela 2).
3. Co-design de canal: ring interleave, apagamentos nativos (1,1), cabeçalho V8 de 8 bytes (Tabela 1) e padding determinístico (§3.5).
4. Camada visual v1.1 (checkerboard) para impressão monocromática a 300 DPI (§3.6).
5. Leitor móvel com ProfileRouter, estágios S0–S2 e resolução de $N$ (§5, Tabela 7), avaliado sob o protocolo declarado com build 0.4.7 (§5.6, §6.0).

8.3 Entregáveis

Evidências e materiais reproduzíveis associados ao estudo (não comercialização do formato):

8.4 Trabalho futuro

Prioridades, ordenadas por impacto probatório:

1. Matriz Multi-dispositivo/multi-ISP — repita o protocolo de papel de §6.0 em pelo menos dois telefones Android adicionais (diferentes formatos de sensor e distorção grande angular), mantendo a distribuição livre de APK. Relate janelas centerDy, taxa de acerto N15 e distribuições decodeMs por dispositivo, para que a linha de base do Redmi Note 9 Pro não seja mais a única âncora de campo.
2. Validação de vários monitores — painéis com $d_{\text{display}}$ diferente do ThinkPad L14 em §6.3, separando o acoplamento moiré do comportamento do codec.
3. Extensões de protocolo — N ímpar e $N\geq 18$ com tri_mm medido; comparação formal entre BER e QR sob as mesmas regras de impressão/captura.
4. Operações — conjunto público de capturas de campo com telemetria; auxílios de enquadramento em N15 (guia ou ROI adaptativo); especificação pública 1.0.
5. Métricas teóricas e industrialização — complemento à linha de base móvel do §6: modelar e medir leitura e velocidade em hardware moderno e em ambientes industriais (câmeras fixas, iluminação controlada e geometria de captura), como linha de pesquisa colaborativa; o modelo paraxial §6.0 antecipa margens mais altas do que o Redmi, mas esses números não são extrapolados como evidência neste preprint.

Além da medição, o HEX V8 se posiciona como um canal especializado com leitor dedicado (§5.1, §7.3), e não como um substituto da câmera do sistema operacional na frente do QR. Os usos industriais potenciais – rotulagem de peças densas, rastreabilidade de fábrica, embalagem técnica – aceitam essa compensação quando o payload em tri_mm ≈ 5 mm é mais importante do que a área impressa de marketing mínima; eles não são validados no §6 e motivam o caminho de colaboração do §9. Um codificador/decodificador no navegador (§9) oferece suporte a roundtrips didáticos e exploração de capacidade; ele não substitui o campo de linha de base do Android.

9. Disponibilidade de documentação e materiais

A documentação técnica estendida é publicada como relatório técnico da Satinus E.I.R.L. [18]:
https://satinus-eirl.github.io/docs/informes/hex-v8-informe-tecnico.html.

Materiais online (centro de documentação):

• HTML preprint (espanhol)
• Relatório técnico [18]
• Folha de tamanhos (PDF) e Capacidade máxima RS-M (PDF)
• codificador/decodificador HEX (navegador) — ferramenta TypeScript de ida e volta (15/15 vs Python em §6.1); apenas educacional, não um substituto para APK 0.4.7

Leitor de campo. A linha Android usada no §6 é publicada via GitHub (hex-scanner): APK assinado, notas de lançamento e canal de atualização no aplicativo. Ele não está listado nas lojas de aplicativos durante a fase de preprint.

Reutilização e contato. Os resultados do §8.3 e os materiais públicos anteriores são gratuitos para uso educacional, avaliação do formato e reprodução parcial do protocolo do §6.0. O núcleo algorítmico de referência e a exploração comercial permanecem na Satinus E.I.R.L. (Lei de PI chilena nº 17.336). Colaboração, licenciamento e suporte para desenvolvimento adicional do formato/leitor estão disponíveis mediante acordo.

Contato: jorgefigueroacifuentes@gmail.com, satinuseirl@gmail.com (Satinus E.I.R.L., Chile).

Referências

1. ISO/IEC 18004:2015 — QR Code. iso.org/standard/62021
2. ISO/IEC 16022:2006 — Matriz de Dados.
3. ISO/IEC 24778:2024 — Código Asteca. iso.org/standard/82441
4. ISO/IEC 15438:2015 — PDF417. iso.org/standard/65502
5. IS Reed e G. Solomon, J. SIAM, 8(2):300–304, 1960. DOI: 10.1137/0108018
6. ISO/IEC 15415:2011 — Qualidade de impressão para símbolos 2D.
7. DENSO WAVE — histórico de desenvolvimento do QR. denso-wave.com
8. E. Ohbuchi et al., Proc. Mundos Cibernéticos, IEEE, 2004. DOI: 10.1109/CYBER.2004.144
9. J.-A. Lin e C.-S. Uau, Matemática. Provavelmente. Eng., 2013. DOI: 10.1155/2013/848276
10. LFF Belussi e NST Hirata, Proc. SIBGRAPI, IEEE, 2011.
11. K. Zuiderveld, Gemas Gráficas IV, 1994.
12. G. Bradski e A. Kaehler, Aprendendo OpenCV, O'Reilly, 2008.
13. D. Parikh e G. Jancke, IEEE WACV, 2008.
14. OI Bulan et al., Color Imaging Conf., 2011.
15. ISO/IEC 16023:2000 – MaxiCode.
16. AIM, Inc., Especificação de Simbologia DotCode 4.0, 2019.
17. H. Kato et al., IEEE Pervasive Computing, 6(4):76–85, 2007.
18. Satinus E.I.R.L., HEX V8 — Especificação técnica, tabelas de capacidade e protocolo de avaliação, relatório técnico (online), 2026. satinus-eirl.github.io/docs/informes/hex-v8-informe-tecnico.html
19. Xiaomi Redmi Note 9 Pro — especificações da câmera (variante global). gsmarena.com/xiaomi_redmi_note_9_pro-10217
20. Lenovo ThinkPad L14 — especificações do painel (14″ WUXGA 1920×1200 IPS). psref.lenovo.com — ThinkPad L14

Apêndice A — Índice de Termos

Referência rápida. As definições completas aparecem na primeira menção no corpo.

Apêndice B — Índice de tabelas e figuras

Os carros alegóricos são numerados automaticamente no PDF; o corpo usa referências cruzadas. Este índice lista os títulos por seção narrativa.