Especificación del código HCC2D

Introducción

HCC2D es un formato de código de barras bidimensional a color. Reutiliza la estructura de matriz cuadrada del código QR Code mientras define sus propias reglas específicas de HCC2D para la codificación de color, el enmarcado de carga útil, la semántica del borde del símbolo, las capacidades de versión y la organización de codewords. En particular, HCC2D reutiliza el finder pattern, el alignment pattern, el timing pattern, la información de formato, la información de versión, las mask formulas y el comportamiento de corrección de errores Reed-Solomon compatible con QR Code / ISO/IEC 18004:2006, excepto donde esta especificación define explícitamente un comportamiento diferente.

QR Code es una marca registrada de DENSO WAVE INCORPORATED en Japón y en otros países. HCC2D no está patrocinado, respaldado ni afiliado a DENSO WAVE INCORPORATED. Los elementos estructurales definidos en QR Code / ISO/IEC 18004:2006 — incluidos los finder patterns, alignment patterns, timing patterns, format information, version information y masking — se utilizan aquí como elementos de un estándar técnico público. Este documento describe únicamente los elementos específicos de HCC2D del formato y deliberadamente no reitera esos elementos.

HCC2D no es una alternativa al código QR sino una extensión del mismo. Un decoder HCC2D también debe ser un lector de códigos QR. En términos prácticos, un decoder HCC2D es fundamentalmente un decoder estándar de códigos QR con funcionalidad adicional para reconocer y decodificar módulos de colores. Utiliza la fase estándar de detección de QR Code para detectar la estructura del símbolo. Después de la detección y antes de la decodificación del payload, el decoder determina si debe seguir la ruta estándar de decodificación de QR Code, en la que los módulos se interpretan como módulos en blanco y negro, o la ruta de decodificación HCC2D, en la que los módulos se interpretan como módulos de 4 colores o de 8 colores. Esta elección se realiza comprobando si los Color Palette Patterns de HCC2D están presentes en el perímetro del símbolo. Si los Color Palette Patterns no están presentes, el decoder decodifica el símbolo como un QR Code estándar. Si los Color Palette Patterns están presentes, el decoder decodifica el símbolo como un código HCC2D conforme a las reglas de color HCC2D aplicables. Un encoder HCC2D produce símbolos que comparten la misma base estructural que el código QR y debe ser capaz de codificar tanto códigos QR como códigos HCC2D.

Este documento especifica los formatos de código HCC2D de cuatro colores y HCC2D de ocho colores.

1. Alcance

Este documento cubre:

• hcc2d4: HCC2D de 4 colores
• hcc2d8: HCC2D de 8 colores

Esta especificación define:

• símbolos cuadrados únicamente
• versiones 1..40
• niveles de corrección de errores L, M, Q, H
• codificación de carga útil solo en modo byte

Esta especificación define el enmarcado de carga útil HCC2D usando un segmento BYTE.

1.1 Términos y acrónimos

• Color Palette Pattern: el borde exterior de un código HCC2D que contiene la secuencia cíclica de colores de la paleta y que sirve como leyenda de colores
• EC: corrección de errores
• EC level: nivel de corrección de errores
• ECPB: error-correction codewords per block
• MSB: bit más significativo
• LSB: bit menos significativo
• RS: Reed-Solomon
• RGB: rojo, verde, azul
• ISO/IEC: Organización Internacional de Normalización / Comisión Electrotécnica Internacional

Términos de matriz:

• module: una celda cuadrada lógica del símbolo
• inner grid o inner matrix: la matriz N×N reutilizada compatible con QR antes de añadir el borde HCC2D
• full symbol: el cuadrado N+2 producido tras añadir el borde HCC2D
• function module: un módulo que no es de datos perteneciente a las estructuras de buscador, alineación, temporización, formato o versión
• data module: un módulo cuyo estado está determinado por la carga útil codificada y el flujo de bits de corrección de errores
• plane: una matriz binaria extraída del flujo de bits interpolado final

1.2 Estructura de alto nivel

A alto nivel, la codificación HCC2D procede de la siguiente manera:

1. enmarcar la carga útil como un segmento en modo BYTE
2. elegir la versión y el nivel de corrección de errores
3. generar data codewords, error-correction codewords y el flujo de bits interpolado final
4. dividir ese flujo de bits final en dos o tres planos binarios
5. construir una matriz interna compatible con QR por plano usando un mask pattern compartido
6. combinar los bits de plano en índices de color para los módulos de datos
7. renderizar los módulos de función en blanco y negro
8. añadir el borde Color Palette Pattern de HCC2D

HCC2D no ejecuta un proceso de corrección de errores separado por plano. Primero se produce un flujo de bits combinado, y la extracción de planos ocurre solo después.

2. Base de conformidad

Una implementación conforme produce códigos decodificables por el HCC2D Decoder oficial, disponible en Google Play, Huawei AppGallery y la App Store.

Una implementación que declare conformidad con esta especificación deberá combinar:

1. una capa específica de HCC2D definida por este documento; y
2. una capa de codificación de matriz cuadrada reutilizada cuyo comportamiento sea compatible con QR Code / ISO/IEC 18004:2006 para todas las partes reutilizadas.

Para la interoperabilidad con los decodificadores HCC2D existentes, la capa reutilizada deberá proporcionar al menos:

• versiones cuadradas de tipo Model-2 1..40
• niveles de corrección de errores L, M, Q, H
• ubicación del finder pattern
• ubicación del alignment pattern a partir de las coordenadas indicadas en las tablas HCC2D
• ubicación del timing pattern
• generación y ubicación de la información de formato
• generación y ubicación de la información de versión donde corresponda
• orden de ubicación de datos en modo BYTE en la matriz interna
• mask formulas para los mask indices 0..7
• evaluación de mask penalty compatible con QR Code / ISO/IEC 18004:2006, excepto por la regla específica de HCC2D que usa solo el plano 0 invertido en la sección 10
• generación de paridad Reed-Solomon e intercalado de codewords compatible con QR Code / ISO/IEC 18004:2006, excepto por los recuentos totales de codewords y multiplicidades de bloques específicos de HCC2D definidos en las secciones 19 y 20

Por lo tanto:

• esta especificación no es completamente autónoma
• una implementación que ya tenga esos comportamientos reutilizados compatibles con QR Code / ISO/IEC 18004:2006 puede implementar la generación de símbolos HCC2D interoperables a partir de esta especificación
• una implementación que tenga esta especificación junto con la especificación QR Code para las partes reutilizadas tiene la información necesaria para implementar la generación de símbolos HCC2D interoperables

En términos prácticos, HCC2D no es un sustituto de la construcción de matrices cuadradas de estilo QR. Es una capa de capacidad de color y enmarcado construida sobre un símbolo interno reutilizado compatible con QR. Por lo tanto, las diferencias normativas de HCC2D se concentran en:

• enmarcado de carga útil
• capacidades totales de codewords y multiplicidades de bloques
• extracción de planos de bits e interpretación de color
• selección del input para el algoritmo de data masking: solo el plano 0 invertido
• regla de renderizado de módulos de función
• semántica del borde exterior de HCC2D

Un formato o símbolo solo puede denominarse HCC2D si cumple con esta especificación. El uso del nombre HCC2D para describir un formato o símbolo no conforme es engañoso y no está autorizado por esta especificación.

3. Parámetros de codificación

Un proceso de generación de símbolo HCC2D conforme está parametrizado por al menos estos valores lógicos:

• payload: obligatorio, arreglo de bytes no vacío
• mode: hcc2d4 o hcc2d8
• ec_level: uno de L, M, Q, H
• version: 0 significa selección automática; de lo contrario 1..40
• scale: píxeles por módulo para renderizado raster, si se produce salida raster
• quiet_zone: módulos de margen blanco alrededor del símbolo renderizado, si se produce salida raster
• palette_rgb: anulación RGB opcional

Los primeros cuatro parámetros afectan al símbolo HCC2D lógico. Los últimos tres afectan solo al renderizado visual.

Los valores predeterminados, el comportamiento de la interfaz de usuario y las convenciones de línea de comandos están fuera del alcance de esta especificación.

Notas adicionales sobre parámetros:

• payload se interpreta estrictamente como bytes crudos
• esta especificación no define transcodificación de texto, optimización multi-segmento, modo numérico ni modo alfanumérico
• mode determina el número de planos y la familia de paleta
• ec_level selecciona la fila de tabla normativa dentro de la versión elegida
• version controla la capacidad, la dimensión interior, las coordenadas de alineación y la estructura de bloques
• scale, quiet_zone y palette_rgb no cambian el flujo de bits lógico codificado

4. Geometría del símbolo

Para ambos modos HCC2D, la versión v utiliza una cuadrícula cuadrada interior de dimensión:

N = 17 + 4*v

Ejemplos:

• versión 1 → 21 × 21
• versión 10 → 57 × 57
• versión 40 → 177 × 177

La cuadrícula interior reutiliza las estructuras de finder pattern, alignment pattern, timing pattern, información de formato e información de versión que siguen reglas compatibles con QR Code / ISO/IEC 18004:2006.

HCC2D añade después su propio borde exterior de un módulo en los cuatro lados:

• dimensión interior = N
• dimensión completa = N + 2

Este borde exterior específico de HCC2D es el Color Palette Pattern.

La distinción entre cuadrícula interior y símbolo completo es normativa:

• toda la lógica de posicionamiento reutilizada compatible con QR opera sobre la matriz interior N × N
• el Color Palette Pattern de HCC2D se sitúa fuera de esa matriz interior
• el renderizado y la salida raster utilizan la dimensión completa N + 2

Por lo tanto, cuando este documento se refiere a patrones de función, posicionamiento de datos, masking o geometría de versión, esas reglas se aplican primero a la matriz interior, y solo después se añade el borde HCC2D.

5. Índices de color y paletas predeterminadas

Esta sección define el diseño de bits del índice de color para HCC2D4 y HCC2D8, los dos Modelos de Paleta de Colores estándar (Modelo 1 para visualización en pantalla y Modelo 2 para impresión), la clasificación de los modelos de paleta, y las reglas para la personalización de la paleta.

5.1 HCC2D4 — Paleta de Colores Modelo 1 — Definición

Los códigos HCC2D4 con Paleta de Colores Modelo 1 deberán usar los siguientes colores para los índices de paleta 0..3. La luminancia es aproximada, calculada como Y = 0.299R + 0.587G + 0.114B.

Disposición de bits del índice de color:

• bit 1 = plano MSB
• bit 0 = plano LSB

Por lo tanto:

• 00 → 0 → negro
• 01 → 1 → rojo
• 10 → 2 → cian
• 11 → 3 → blanco

El ordenamiento es lógico, no meramente visual. El índice 0 es el ancla oscura y el índice 3 es el ancla blanca de la familia de cuatro colores.

5.2 HCC2D8 — Paleta de Colores Modelo 1 — Definición

Los códigos HCC2D8 con Paleta de Colores Modelo 1 deberán usar los siguientes colores para los índices de paleta 0..7. La luminancia es aproximada, calculada como Y = 0.299R + 0.587G + 0.114B.

Disposición de bits del índice de color:

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

Por lo tanto, el índice de color es igual al valor de 3 bits formado por los tres bits de plano.

Nuevamente, el ordenamiento es lógico. El índice 0 es el ancla oscura y el índice 7 es el ancla blanca de la familia de ocho colores.

5.3 Paleta de Colores Modelo 1 — Justificación del diseño

Los valores RGB de la Paleta de Colores Modelo 1 (definida en las secciones 5.1 y 5.2) fueron elegidos deliberadamente para evitar los extremos del gamut sRGB, donde los perfiles de pantalla y los gamuts hardware divergen más. El decodificador muestrea el Color Palette Pattern en tiempo real sobre la pantalla real — que puede ser sRGB, de gama amplia, AMOLED o LCD, y casi con certeza no está calibrada. Los valores de canal próximos a los límites (cercanos a 0 o 255) se reproducen de forma diferente según el tipo de pantalla; al limitar los canales activos a 200–220 en lugar de 255, los colores de la paleta se sitúan en el interior del gamut sRGB, donde las diferentes pantallas coinciden de forma más fiable en el color percibido. Esto reduce la desviación de color entre pantallas y mejora la estabilidad del muestreo de colores durante la decodificación.

Esta elección de limitación de canales RGB también produce una distribución de luminancia coherente con el requisito de ordenamiento de la sección 5.9. Para HCC2D8 (sección 5.2), los índices 0–3 (negro, rojo oscuro, verde oscuro, azul marino oscuro) caen todos por debajo del punto medio de luminancia (Y < 128), mientras que los índices 4–7 (cian claro, amarillo claro, magenta claro, blanco) caen todos por encima (Y > 128). La diferencia entre el índice 3 (azul marino oscuro, Y ≈ 56) y el índice 4 (cian claro, Y ≈ 153) es de aproximadamente 97 unidades de luminancia.

La Paleta de Colores Modelo 1 es la línea de base validada para pantallas. No pretende ser óptima para impresión.

5.4 HCC2D4 — Paleta de Colores Modelo 2 — Definición

Para HCC2D4, todos los colores intermedios son de un solo canal. El amarillo se excluye por proporcionar contraste insuficiente con el papel blanco:

5.5 HCC2D8 — Paleta de Colores Modelo 2 — Definición

Para HCC2D8, la paleta cubre los tres primarios CMYK de canal único y sus tres combinaciones binarias a saturación completa. No se utiliza ninguna combinación de tres canales:

5.6 Paleta de Colores Modelo 2 — Justificación del diseño

La Paleta de Colores Modelo 2 es la paleta optimizada para impresión, definida para HCC2D4 y HCC2D8. Para la impresión, el problema es diferente al de las pantallas: el gamut de la tinta, el punto de blanco del papel y las condiciones de iluminación durante el escaneo introducen fuentes de variabilidad distintas. La Paleta de Colores Modelo 2 se basa en el principio de minimizar el número de canales de tinta por color de módulo. Los colores de un solo canal son los más estables entre impresoras; cada canal adicional introduce interacciones de ganancia de punto que varían según la impresora, el papel y la densidad de tinta.

Ambas paletas de la Paleta de Colores Modelo 2 cumplen el ordenamiento oscuro/claro de la sección 5.9. Para HCC2D8, la separación es especialmente clara: los índices 0–3 (negro, azul, rojo, magenta) caen todos por debajo del punto medio de luminancia (Y < 128), mientras que los índices 4–7 (verde, cian, amarillo, blanco) caen todos por encima (Y > 128), con una diferencia de aproximadamente 45 unidades de luminancia entre el índice 3 (magenta, Y ≈ 105) y el índice 4 (verde, Y ≈ 150).

5.7 Clasificación de Modelos de Paleta de Colores

Los códigos HCC2D se clasifican según su paleta de colores de la siguiente manera. El número de modelo es una propiedad de la paleta, no del formato del código; el decodificador es agnóstico a la paleta.

• Paleta de colores Modelo 1: códigos que usan la paleta predeterminada exacta definida en las secciones 5.1 y 5.2. Esta es la paleta estándar e interoperable. La Paleta de colores Modelo 1 ha sido validada para funcionar bien cuando los códigos se muestran en pantallas (monitores de ordenador, teléfonos inteligentes y dispositivos similares). Cualquier implementación que declare conformidad HCC2D sin más calificaciones implica la Paleta de colores Modelo 1.
• Paleta de Colores Modelo 2: códigos que utilizan la paleta optimizada para impresión definida en las secciones 5.4 y 5.5, disponible para HCC2D4 y HCC2D8. Diseñada para flujos de trabajo de impresión y escaneo.
• Paleta inválida: una paleta que no tiene negro en el índice 0 o blanco en el último índice. Los códigos que usan tal paleta no son códigos HCC2D válidos. Los codificadores conformes deberán rechazar estas configuraciones (ver sección 5.8).
• Paleta no estándar / experimental: una paleta que mantiene negro en el índice 0 y blanco en el último índice, pero usa colores intermedios diferentes. Los códigos producidos con tal paleta pueden o no ser decodificables, dependiendo de cuán cromáticamente distintos sean los colores elegidos. La implementación de codificación asume la responsabilidad exclusiva de cualquier código que no se pueda decodificar.

Los números de modelo de paleta de colores son asignados exclusivamente por esta especificación. En versiones futuras de esta especificación pueden definirse modelos de paleta de colores adicionales (Paleta de colores Modelo 3 y sucesivos) a medida que otras combinaciones de colores sean validadas experimentalmente para funcionar bien en casos de uso específicos, como la lectura de ordenador a teléfono o de teléfono a teléfono.

Las modificaciones de paleta deberían limitarse a uso experimental. Para uso en producción, la Paleta de colores Modelo 1 debería usarse cuando los códigos vayan a mostrarse en pantallas (monitores de ordenador, teléfonos inteligentes y dispositivos similares); la Paleta de colores Modelo 2 debería usarse cuando los códigos deban imprimirse.

Las implementaciones que produzcan códigos con una paleta no estándar deberán comunicarlo explícitamente a sus usuarios, indicando que los códigos usan una paleta no estándar y pueden no ser decodificables por todos los decodificadores HCC2D.

5.8 Anulación de paleta

La primera entrada de paleta y la última son anclas normativas y no deben modificarse:

• para hcc2d4, el índice 0 debe permanecer negro y el índice 3 debe permanecer blanco
• para hcc2d8, el índice 0 debe permanecer negro y el índice 7 debe permanecer blanco

Por lo tanto:

• en hcc2d4, solo los índices 1 y 2 pueden personalizarse
• en hcc2d8, solo los índices 1 a 6 pueden personalizarse

Cuando se proporciona una anulación de paleta:

• el modo de 4 colores requiere exactamente 12 bytes (4 * 3)
• el modo de 8 colores requiere exactamente 24 bytes (8 * 3)
• la disposición de bytes es la paleta completa en orden de índice de paleta, luego en orden de componente RGB
• sin embargo, los codificadores conformes deberán rechazar anulaciones cuya primera entrada no sea negro o cuya última entrada no sea blanco

El orden de bytes es por orden de entrada de paleta, luego por orden de componente RGB:

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

Valores de ancla normativos:

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

La lógica del símbolo usa solo índices. Los valores RGB personalizados no afectan las codewords, la construcción del flujo de bits, la selección de versión, la mask selection ni la disposición de la matriz, pero sí afectan la apariencia renderizada.

Equivalentemente, HCC2D determina primero un índice de color lógico para cada módulo y solo entonces asigna ese índice a una terna RGB para el renderizado.

5.9 Ordenamiento de luminancia recomendado para paletas personalizadas

Esta subsección es informativa.

Cuando se usa una paleta personalizada, las implementaciones deberían preservar una mitad inferior más oscura y una mitad superior más clara. Esta recomendación está motivada por la mask selection rule de HCC2D definida más adelante en esta especificación.

La mask selection de HCC2D no se realiza sobre el símbolo final renderizado en color completo. En cambio, se realiza sobre un proxy binario derivado de un solo plano de bits:

• solo el plano 0 participa en la mask selection
• para hcc2d4, el plano 0 es el bit más significativo del color
• para hcc2d8, el plano 0 es el bit más significativo del color (bit 2)
• ese plano se extrae del flujo de bits entrelazado final
• ese plano se invierte
• las QR-compatible mask penalty rules se evalúan sobre ese proxy invertido de un solo plano

Por lo tanto, solo un bit por módulo influye directamente en la mask choice.

Esto tiene una consecuencia práctica importante. La máscara se elige usando reglas de penalización binaria al estilo QR, pero el símbolo HCC2D final es un símbolo multicolor. Para que el proceso de mask selection al estilo QR siga siendo significativo para HCC2D, el proxy binario utilizado para la mask choice debería seguir correlacionando razonablemente bien con la estructura de oscuridad aparente del símbolo renderizado final.

Esa correlación mejora cuando los índices de paleta inferiores son más oscuros y los índices superiores son más claros. En esa disposición, el plano único utilizado para la mask selection aún actúa como una aproximación gruesa útil de cómo se distribuyen las regiones oscuras versus claras en el símbolo HCC2D final.

Por lo tanto, la personalización de paleta debería preservar un ordenamiento de luminancia renderizada en el que la mitad inferior permanezca más oscura en general y la mitad superior más clara en general, coherente con el ordenamiento de significado lógico de los índices de color.

En términos prácticos:

• los índices de paleta inferiores deberían corresponder a colores más oscuros
• los índices de paleta superiores deberían corresponder a colores más claros
• la primera entrada deberá permanecer negra
• la última entrada deberá permanecer blanca

Ordenamiento recomendado para hcc2d4:

• el índice 0 deberá ser negro
• el índice 1 debería ser visualmente más oscuro que el índice 2
• el índice 3 deberá ser blanco
• como pauta general de la familia de 4 colores, los índices 0 y 1 deberían formar la mitad más oscura de la paleta y los índices 2 y 3 la mitad más clara

Ordenamiento recomendado para hcc2d8:

• el índice 0 deberá ser negro
• el índice 7 deberá ser blanco
• los índices 1, 2 y 3 deberían permanecer en la mitad más oscura de la paleta
• los índices 4, 5 y 6 deberían permanecer en la mitad más clara de la paleta
• como pauta general de la familia de 8 colores, los índices 0 a 3 deberían ser más oscuros en general que los índices 4 a 7

Esta recomendación no cambia la lógica del símbolo, ya que HCC2D usa índices de paleta en lugar de valores de luminancia al construir el símbolo. Una paleta que viole el equilibrio recomendado oscuro-inferior / claro-superior puede seguir produciendo símbolos decodificables. Sin embargo, al hacerlo se debilita la relación prevista entre:

• el proxy utilizado durante la mask selection
• la distribución de oscuridad aparente del símbolo renderizado final
• la estabilidad visual de la paleta personalizada en diferentes condiciones de escaneo

Si se preserva ese equilibrio oscuro-versus-claro, las mask rules al estilo QR reutilizadas siguen siendo una heurística razonable y útil para HCC2D también.

Si ese equilibrio no se preserva:

• el codificador puede seguir generando símbolos válidos
• los decodificadores pueden seguir decodificando esos símbolos con éxito
• pero la máscara seleccionada queda entonces optimizada para el proxy binario al estilo QR en lugar de para una disposición de colores final cuya oscuridad percibida sigue la misma estructura

En ese caso, la mask selection aún funciona en el sentido estricto de que se elige una máscara y el símbolo resultante puede seguir siendo decodificable, pero el modelo de penalización al estilo QR se vuelve menos representativo de las propiedades visuales del símbolo HCC2D real.

Por esa razón, una paleta personalizada debería preservar colores más oscuros en los índices inferiores y colores más claros en los índices superiores.

6. Enmarcado de carga útil

El enmarcado de carga útil HCC2D usa un segmento BYTE.

• bits de marcador de segmento: 0100
• ancho del campo de conteo: 16 bits en ambos modos HCC2D, para todas las versiones
• valor de conteo: longitud de la carga útil en bytes
• bytes de carga útil: añadidos literalmente, 8 bits cada uno, bit más significativo primero

El flujo de bits de carga útil lógico antes de la terminación es:

0100 || byte_count_16 || payload_bytes

Los bits de terminación, la alineación de bytes, los bytes de relleno, la generación de paridad Reed-Solomon y el entrelazado final siguen reglas compatibles con QR Code / ISO/IEC 18004:2006, excepto donde esta especificación define explícitamente un comportamiento específico de HCC2D.

Consecuencias importantes de esta regla de enmarcado:

• el campo de conteo siempre tiene dieciséis bits para HCC2D, independientemente de la versión
• el valor de conteo es un recuento de bytes, no de bits ni de caracteres
• los bytes de carga útil se añaden literalmente en orden de bit más significativo primero
• esta especificación define exactamente un segmento BYTE por símbolo HCC2D

7. Selección de versión

Si se especifica explícitamente una versión, se usará solo si la carga útil cabe.

Si se usa la selección automática de versión, se seleccionará la versión más pequeña que quepa.

Para un modo, versión y nivel de corrección de errores HCC2D dados:

• total_codewords, data_codewords, ec_codewords y la distribución de bloques se obtienen de las tablas explícitas HCC2D en las secciones 19 y 20
• una carga útil cabe si y solo si su flujo de bits enmarcado puede terminarse y rellenarse hasta exactamente data_codewords bytes

Para este propósito, la longitud del flujo de bits enmarcado antes de la terminación es:

4 + 16 + 8 * payload_length

donde 4 es el indicador de modo BYTE y 16 es el ancho del campo de recuento de bytes HCC2D.

Una carga útil cabe cuando ese flujo de bits enmarcado puede:

1. terminarse opcionalmente con hasta cuatro bits cero
2. rellenarse con bits cero hasta el siguiente límite de byte
3. rellenarse con bytes de relleno alternos hasta alcanzar exactamente la capacidad de data codewords

sin superar el recuento de data codewords disponibles para el modo, versión y nivel de corrección de errores seleccionados.

8. Organización de codewords HCC2D

Las tablas de parámetros HCC2D en las secciones 19 y 20 son normativas.

La estructura de corrección de errores sigue reglas compatibles con ISO/IEC 18004:2006, excepto donde esta especificación define explícitamente un comportamiento específico de HCC2D.

Cada fila de la tabla proporciona:

• dim: dimensión interior
• align: coordenadas centrales del alignment pattern
• total: total codewords
• data: data codewords
• ec: error-correction codewords
• ecpb: error-correction codewords per block
• blocks: multiplicidades de bloques y data codewords por bloque

Esos valores determinan completamente la organización de codewords HCC2D para cada versión y nivel.

Para hcc2d4, el recuento total de codewords para cada versión y nivel es exactamente el doble de la estructura base compatible con QR Code / ISO/IEC 18004:2006 correspondiente.

Para hcc2d8, el recuento total de codewords para cada versión y nivel es exactamente el triple de la estructura base compatible con QR Code / ISO/IEC 18004:2006 correspondiente.

Más precisamente:

• hcc2d4 mantiene los valores de codewords per block compatibles con QR Code / ISO/IEC 18004:2006 reutilizados y duplica las multiplicidades de bloques
• hcc2d8 mantiene los valores de codewords per block compatibles con QR Code / ISO/IEC 18004:2006 reutilizados y triplica las multiplicidades de bloques

Este es el mecanismo por el cual HCC2D aumenta la capacidad total de bits mientras continúa usando los procedimientos Reed-Solomon compatibles con QR reutilizados.

9. Construcción de planos

Sea B el flujo de bits final de codewords entrelazadas.

La construcción de planos se realiza solo después de:

• haber formado las data codewords
• haber generado las error-correction codewords
• haber completado el entrelazado final

HCC2D no crea flujos de corrección de errores separados por plano. En cambio, primero se produce un flujo de bits combinado final y luego se divide por paso en planos.

9.1 HCC2D4 — Dos planos

hcc2d4 usa dos planos.

La extracción de planos se realiza por desentrelazado de bits del flujo de bits final:

• el plano 0 toma bits en las posiciones 0, 2, 4, ...
• el plano 1 toma bits en las posiciones 1, 3, 5, ...

El plano 0 es el plano MSB. El plano 1 es el plano LSB.

Índice de color del módulo de datos:

color = (plane0_bit << 1) | plane1_bit

Equivalentemente, si el flujo de bits final entrelazado es B[0], B[1], B[2], ..., los colores de los módulos del símbolo se determinan por pares de bits:

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

9.2 HCC2D8 — Tres planos

hcc2d8 usa tres planos.

La extracción de planos es:

• el plano 0 toma bits en las posiciones 0, 3, 6, ...
• el plano 1 toma bits en las posiciones 1, 4, 7, ...
• el plano 2 toma bits en las posiciones 2, 5, 8, ...

El plano 0 es el plano MSB. El plano 2 es el plano LSB.

Índice de color del módulo de datos:

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

Equivalentemente, si el flujo de bits final entrelazado es B[0], B[1], B[2], ..., los colores de los módulos del símbolo se determinan por tripletes de bits:

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

El orden de planos es normativo y no deberá permutarse. En hcc2d4, el plano 0 es el bit más significativo y el plano 1 es el bit menos significativo. En hcc2d8, el plano 0 es el bit 2, el plano 1 es el bit 1 y el plano 2 es el bit 0.

10. Mask selection

Se deberá usar un único mask pattern en 0..7 para todos los planos de un símbolo.

La mask selection sigue reglas compatibles con ISO/IEC 18004:2006, excepto donde esta especificación define explícitamente un comportamiento específico de HCC2D.

Comportamiento específico de HCC2D para la evaluación de candidatos:

• construir un flujo de bits proxy solo desde el plano 0
• invertir cada bit de ese flujo del plano 0
• usar ese flujo invertido para la evaluación de mask penalty

Procedimiento de mask selection:

1. para cada mask index candidato en 0..7, aplicar esa mask al flujo del plano 0 invertido y construir una matriz interior candidata a partir de él
2. calcular la mask penalty sobre esa matriz candidata
3. seleccionar el mask index con penalización mínima

La resolución de empates es por el primer mínimo encontrado, es decir, el mask index más bajo.

Una vez elegido el mask index ganador, ese único índice deberá reutilizarse para cada plano del símbolo. HCC2D no elige mask patterns diferentes para planos diferentes.

11. Construcción de la matriz interna

Cada plano se convierte en una matriz interna usando la versión elegida y el mask pattern común elegido.

Importante: todos los planos usan la misma geometría de patrón de función, la misma versión, los mismos bits de formato y el mismo mask index. Solo difieren en los bits de datos.

Este documento no vuelve a exponer en su totalidad las fórmulas reutilizadas de finder pattern, alignment pattern, timing pattern, información de formato, información de versión, Reed-Solomon ni las mask rules.

Así, la construcción de la matriz interior para HCC2D puede entenderse como una construcción de matriz compatible con QR repetida sobre la misma geometría, una vez por plano, con solo el flujo de bits de plano cambiando de una pasada a la siguiente.

12. Coloración de módulos de función

Para hcc2d4 y hcc2d8, los módulos de datos usan el mapeo de colores multiplano descrito anteriormente, pero los módulos de función se renderizan solo en blanco y negro:

• si el plano 0 en esa coordenada de módulo de función es 1, renderizar negro
• de lo contrario renderizar blanco

En la práctica esto es seguro porque los módulos de función son idénticos en todos los planos.

Esta regla se aplica a todos los módulos estructurales reutilizados en la matriz interior, incluidos los finder pattern, los alignment pattern, los timing pattern, la información de formato y la información de versión donde corresponda.

13. Color Palette Pattern

El Color Palette Pattern debe implementarse exactamente como se especifica: los decodificadores muestrean sus módulos para reconstruir la paleta de colores. El decodificador no conoce a priori los colores de la paleta, salvo que el primero es negro y el último es blanco. El Color Palette Pattern es por tanto necesario para la decodificación.

Sea la dimensión interior N.

El borde HCC2D se sitúa un módulo fuera de la cuadrícula interior:

• la fila de borde superior está en la fila lógica -1
• la fila de borde inferior está en la fila lógica N
• la columna de borde izquierda está en la columna lógica -1
• la columna de borde derecha está en la columna lógica N

El código HCC2D desplaza esas coordenadas lógicas en +1 en ambos ejes, produciendo una cuadrícula de (N+2) × (N+2).

El Color Palette Pattern es una parte estructural de HCC2D, no una decoración opcional. Su geometría y el orden de índices de color son parte de la definición del formato.

13.1 Período del Color Palette Pattern

• hcc2d4: período P = 4
• hcc2d8: período P = 8

Los tramos activos en cada borde recorren todos los índices de paleta P repetidamente. La fórmula exacta para cada borde, incluido el índice inicial y la dirección de ciclo, se da en la sección 13.2.

El ciclo se define en términos de índices de paleta lógicos, no de valores RGB literales.

13.2 Fórmulas exactas para los colores del Color Palette Pattern

Sean row y col coordenadas lógicas en el sistema de coordenadas de borde descrito anteriormente.

El borde Color Palette Pattern deberá usar estas reglas exactas:

1. Borde superior: si row == -1 y 8 ≤ col < N - 8, entonces color = (col - 8) mod P
2. Borde inferior: si row == N y 8 ≤ col < N, entonces color = (col - 8) mod P
3. Borde izquierdo: si col == -1, sea start = N - 9. Si 8 ≤ row ≤ start, entonces color = (start - row) mod P
4. Borde derecho: si col == N y 8 ≤ row < N, entonces color = (row - 8) mod P
5. Todas las celdas de borde restantes: color = P - 1

Esto significa que las celdas de borde no cíclicas, incluidas las esquinas y los tramos excluidos cerca de los finder pattern, son siempre el índice de paleta más alto:

• 3 para HCC2D4 → blanco
• 7 para HCC2D8 → blanco

13.3 Réplicas del Color Palette Pattern por modo

No todos los módulos del borde llevan los colores de paleta. Los módulos en las esquinas y cerca de los finder pattern son blancos fijos (color = P − 1, como se define en la sección 13.2). La longitud del segmento que replica cíclicamente los colores de paleta en cada lado es:

• lado superior: N − 16 módulos
• lado inferior: N − 8 módulos
• lado izquierdo: N − 16 módulos
• lado derecho: N − 8 módulos

Para HCC2D8 (P = 8), se aplican las mismas longitudes.

La secuencia exacta por lado —incluido el índice inicial y la dirección— está determinada por las fórmulas de la sección 13.2. Los lados superior, inferior y derecho se incrementan con su coordenada de barrido. En el lado izquierdo el índice de palette decrece con el aumento de la fila; el índice inicial exacto en cada versión viene dado por la fórmula de la sección 13.2.

13.4 Interpretación para el decodificador

El decodificador muestrea estas tiras para recuperar las estadísticas de paleta. Por lo tanto, el borde es parte del formato del símbolo, no meramente una decoración.

Cualquier implementación que cambie la geometría del tramo, la dirección de ciclo o las celdas blancas de reserva del Color Palette Pattern generaría un símbolo no conforme.

14. Coordenadas de salida renderizada

Esta sección define el renderizado raster de un símbolo HCC2D lógico. El símbolo lógico está completamente definido sin fijar ningún tamaño de píxel particular.

14.1 Coordenadas de módulo

Para los modos HCC2D:

• tamaño total de la cuadrícula de módulos = N + 2
• el módulo interior (x, y) se asigna al módulo renderizado (x + 1, y + 1)

14.2 Zona de silencio

La imagen rasterizada añade quiet_zone módulos de color de fondo en los cuatro lados.

Índice de color de fondo:

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

14.3 Tamaño de imagen en píxeles

Sea F la dimensión completa de módulos:

F = N + 2

Entonces:

• ancho de imagen = (F + 2 * quiet_zone) * scale
• alto de imagen = igual

Cada módulo lógico se rasteriza como un cuadrado de color sólido de scale × scale.

Para los símbolos HCC2D, la zona de silencio usa el índice de paleta más alto:

• 3 para hcc2d4
• 7 para hcc2d8

Con las paletas predeterminadas, esto corresponde a blanco.

15. Reglas estructurales relevantes para el decodificador

15.1 Campo de conteo HCC2D

El campo de conteo BYTE es de 16 bits en ambos modos HCC2D.

15.2 Orden de planos

Para HCC2D de 4 colores:

• el plano 0 es el MSB del color
• el plano 1 es el LSB del color

Para HCC2D de 8 colores:

• el plano 0 es el bit más significativo del color (bit 2)
• el plano 1 es el bit 1
• el plano 2 es el bit menos significativo del color (bit 0)

15.3 Máscara común

Todos los planos deben usar el mismo mask pattern.

Estas reglas son relevantes para el decodificador porque un decodificador que asuma anchos de campo de conteo BYTE variables al estilo QR, un orden de significancia de planos diferente o máscaras independientes por plano no interpretaría correctamente un símbolo HCC2D conforme.

16. Procedimiento de codificación

Un procedimiento de codificación HCC2D conforme deberá realizar los siguientes pasos:

1. Validar entradas.
2. Seleccionar familia de símbolos (hcc2d4 o hcc2d8).
3. Seleccionar nivel de corrección de errores (L/M/Q/H).
4. Elegir versión: usar la versión explícitamente especificada si cabe; de lo contrario, cuando se usa la selección automática, elegir la versión más pequeña que quepa.
5. Construir el flujo de bits de carga útil lógico: 0100 || byte_count_16 || payload_bytes
6. Determinar la capacidad específica de la familia y la distribución de bloques desde la tabla HCC2D explícita para el modo, versión y nivel elegidos.
7. Aplicar terminación y bytes de relleno.
8. Generar paridad e intercalar codewords usando la estructura de corrección de errores reutilizada.
9. Dividir el flujo de bits final en 2 o 3 planos por extracción escalonada.
10. Seleccionar un mask index común: para los modos HCC2D, evaluar penalizaciones usando solo el plano 0 invertido.
11. Construir una matriz interna por plano usando la versión común, el nivel EC y la máscara.
12. Renderizar módulos de datos:
    • HCC2D4: índice de color de 2 bits (un bit por plano)
    • HCC2D8: índice de color de 3 bits (un bit por plano)
13. Renderizar módulos de función como negro/blanco desde el plano 0.
14. Añadir el borde Color Palette Pattern exacto de un módulo usando las fórmulas de coordenadas de la sección 13.
15. Añadir zona de silencio blanca.
16. Rasterizar módulos en píxeles si se necesita salida de imagen raster.

El orden de las operaciones importa. En particular:

• la corrección de errores y el entrelazado ocurren antes de la extracción de planos
• la mask selection ocurre una vez y es compartida por todos los planos
• la construcción de la matriz interior ocurre antes de añadir el borde Color Palette Pattern
• la zona de silencio está fuera del símbolo HCC2D completo y no es parte de la estructura lógica de la carga útil

17. Envoltura de carga útil HCC2DF opcional

Esta sección no define el propio código HCC2D.

Define un formato de envoltura de carga útil opcional, HCC2DF, que puede usarse antes de la codificación del símbolo HCC2D cuando la aplicación quiere transportar un nombre de archivo junto con el contenido del archivo. Cuando se usa, el flujo de bytes HCC2DF se convierte en la carga útil definida en las secciones 3, 6 y 16 de esta especificación.

HCC2DF es una envoltura a nivel de aplicación superpuesta sobre los bytes de carga útil HCC2D. No forma parte de la geometría del símbolo HCC2D ni de la lógica de color.

17.1 Diseño de bytes HCC2DF

Los bytes de carga útil HCC2DF son:

1. magic ASCII: "HCC2DF" → 6 bytes
2. byte de versión de envoltura: 0x01
3. byte de indicador de compresión:
   • 0x00 = contenido sin comprimir
   • 0x01 = contenido comprimido con zlib
4. longitud del nombre de archivo: 1 byte
5. bytes del nombre de archivo: UTF-8, exactamente filename_length bytes
6. bytes de contenido: bytes de archivo crudos o bytes de archivo comprimidos

Esta envoltura no define ningún campo de suma de verificación, pie de página ni estructura de metadatos anidada.

17.2 Restricciones del nombre de archivo

• el nombre de archivo no debe estar vacío
• el nombre de archivo no debe superar los 127 bytes UTF-8
• el nombre de archivo no debe contener /
• el nombre de archivo no debe contener \

17.3 Regla de compresión

Si se intenta la compresión, el contenido se comprime usando zlib compress2(..., Z_DEFAULT_COMPRESSION).

La compresión debería usarse solo si se cumplen todas las condiciones siguientes:

• la compresión tiene éxito
• el tamaño del archivo original es de al menos 128 bytes
• el tamaño comprimido es estrictamente menor que el 90% del tamaño original

De lo contrario, deberían almacenarse los bytes del archivo crudos y el indicador de compresión debería ser 0x00.

El mínimo de 128 bytes refleja el overhead fijo que introduce siempre la compresión zlib. El wrapper zlib añade 6 bytes (2 de cabecera + 4 del checksum Adler-32). Además, los encabezados de bloque deflate añaden más overhead: un bloque almacenado añade 5 bytes, y un bloque Huffman dinámico añade la descripción de la tabla de códigos, que puede ser de 20 a 50 bytes para entradas pequeñas — dando un overhead total realista de unos 36 bytes. Para ver por qué 128 bytes es el umbral correcto, considérense estos dos casos:

• Entrada de 64 bytes: margen para superar el 90% = 64 × 0,9 − 36 = 21,6 bytes para los datos reales — el contenido debe comprimirse al ~34%, alcanzable solo para secuencias muy repetitivas.
• Entrada de 128 bytes: margen = 128 × 0,9 − 36 = 79 bytes para los datos reales — el contenido debe comprimirse al ~62%, lo cual es realista para texto, JSON o URLs típicos.

Por debajo de 128 bytes el overhead consume una parte tan grande del margen disponible que es improbable que la compresión produzca un resultado significativo para cualquier payload real.

Esta regla prefiere la compresión solo cuando proporciona un claro beneficio de tamaño. Las implementaciones pueden usar un umbral diferente (p. ej. 95%), pero no se recomienda: un umbral más alto implica comprimir datos que solo ahorran unos pocos puntos porcentuales de espacio, lo cual no supone un beneficio significativo: almacenar los bytes crudos es más simple y el resultado puede tener prácticamente casi el mismo tamaño. En cualquier caso, las implementaciones que se desvíen de esta recomendación seguirán produciendo códigos decodificables por el HCC2D Decoder oficial, siempre que el indicador de compresión y el contenido sean coherentes: si el indicador es 0x01 el contenido debe ser datos zlib válidos; si es 0x00 el contenido debe ser los bytes crudos.

17.4 Relación de alcance con HCC2D

HCC2DF es una envoltura opcional transportada dentro de los bytes de carga útil HCC2D. No forma parte de la estructura del código HCC2D, la codificación de color, la organización de codewords ni la geometría del símbolo.

18. Recomendaciones de implementación

Las siguientes son recomendaciones orientativas para los implementadores. No son requisitos normativos de esta especificación. Los requisitos normativos en el resto de esta especificación se expresan con los términos "deberá" y "no deberá"; esta sección usa "debería" y "no debería" para orientación orientativa.

Nivel de corrección de errores recomendado: Para los códigos HCC2D, deberían usarse los niveles Q o M. El nivel L no debería usarse para uso general. El nivel H ofrece la máxima robustez a costa de una capacidad de carga útil significativamente reducida.

Modo recomendado: Para uso en producción, debería usarse hcc2d4. hcc2d8 ofrece mayor capacidad de carga útil, pero requiere condiciones de visualización y escaneo cromáticamente más consistentes.

Calidad de impresión y producción: Para códigos impresos de uso en producción:

• Debería usarse un formato de salida sin pérdida (PNG, SVG o PDF). Los formatos con pérdida como JPEG introducen artefactos de compresión que corrompen los colores de los módulos.
• Cada módulo debería renderizarse como un bloque de color sólido; no debería usarse semitono (halftoning).
• La relación de aspecto no debería estirarse, comprimirse ni distorsionarse.
• No deberían aplicarse desenfoque, suavizado ni remuestreo después de la rasterización.
• El tamaño de módulo debería ser de al menos 0,5 mm (dimensión X objetivo de GS1 para QR Code), o preferiblemente alrededor de 1 mm para mayor fiabilidad. Los módulos más pequeños reducen la diferenciación de colores durante la decodificación.

19. Tabla de parámetros HCC2D4 explícita

Los siguientes valores son los parámetros de versión HCC2D4. Son los totales completos HCC2D4 y las distribuciones de bloques.

Significado de los campos de la tabla:

• Vn: número de versión HCC2D.
• dim: dimensión interior del símbolo en módulos, excluyendo el borde Color Palette Pattern de un módulo de HCC2D.
• align: coordenadas centrales del alignment pattern en la cuadrícula interior. Una lista vacía significa que no hay alignment pattern.
• L, M, Q, H: niveles de corrección de errores.
• total: número total de codewords en el símbolo para esa versión y nivel de corrección de errores.
• data: número total de data codewords en el símbolo para esa versión y nivel de corrección de errores.
• ec: número total de error-correction codewords en el símbolo para esa versión y nivel de corrección de errores.
• ecpb: error-correction codewords per block.
• blocks=a x b: a bloques Reed-Solomon, cada uno transportando b data codewords y ecpb error-correction codewords.
• blocks=a x b, c x d: dos grupos de bloques; el primero tiene a bloques de b data codewords cada uno, y el segundo tiene c bloques de d data codewords cada uno. Cada bloque de ambos grupos lleva las mismas ecpb error-correction codewords.

Ejemplo trabajado:

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

significa:

• versión 1
• cuadrícula interior 21 × 21
• sin alignment pattern
• en nivel de corrección de errores L
• 52 total codewords en el símbolo
• 38 data codewords
• 14 error-correction codewords
• 2 bloques Reed-Solomon
• cada bloque contiene 19 data codewords y 7 error-correction codewords

La tabla HCC2D8 a continuación usa exactamente los mismos significados de campo.

Parámetros derivados del código QR (ISO/IEC 18004:2006) mediante la aplicación del multiplicador de codificación de color HCC2D.

20. Tabla de parámetros HCC2D8 explícita

Los siguientes valores son los parámetros de versión HCC2D8. Son los totales completos HCC2D8 y las distribuciones de bloques.

Parámetros derivados del código QR (ISO/IEC 18004:2006) mediante la aplicación del multiplicador de codificación de color HCC2D.

21. Nota de publicación

Esta especificación intencionalmente no republica el contenido de finder pattern, alignment pattern, timing pattern, corrección de errores o mask rules asociados con QR Code. Para las partes reutilizadas, solo indica que siguen las mismas estructuras usadas por QR Code, o estructuras compatibles con ISO/IEC 18004:2006, y luego especifica completamente las partes específicas de HCC2D y las tablas de parámetros HCC2D.

En consecuencia, este documento debe leerse como:

• completo para el comportamiento específico de HCC2D
• intencionalmente no exhaustivo para evitar republicar información relativa a componentes de los códigos QR
• normativo junto con las especificaciones de los códigos QR, para la definición de los componentes de los códigos QR reutilizados por los códigos HCC2D

Anexo A — Ejemplos ilustrativos

Los siguientes símbolos son códigos de barras HCC2D conformes a esta especificación. Cada símbolo puede ser escaneado con la aplicación oficial HCC2D Decoder. Las figuras se han renderizado a 0,80 mm por módulo. Esto corresponde al tamaño físico en la página impresa cuando la versión PDF de esta especificación se imprime al 100% en papel.

Los siguientes símbolos codifican Tintern Abbey de William Wordsworth (6.900 bytes, contenedor HCC2DF con compresión zlib), demostrando la capacidad HCC2D para textos largos.

— Fin de la Especificación —