HCC2D Code Specification

Introduction

HCC2D is a color two-dimensional barcode format. It reuses the square-matrix structure of QR Code while defining its own HCC2D-specific rules for color encoding, payload framing, symbol border semantics, version capacities, and codeword organization. In particular, HCC2D reuses finder-pattern, alignment-pattern, timing-pattern, format-information, version-information, mask formulas, and Reed-Solomon error-correction behavior that is compatible with QR Code / ISO/IEC 18004:2006, except where this specification explicitly defines different behavior.

QR Code is a registered trademark of DENSO WAVE INCORPORATED in Japan and in other countries. HCC2D is not sponsored, endorsed, or affiliated with DENSO WAVE INCORPORATED. The structural elements defined in QR Code / ISO/IEC 18004:2006 — including finder patterns, alignment patterns, timing patterns, format information, version information, and masking — are used herein as elements of a public technical standard. This document describes only the HCC2D-specific elements of the format and intentionally does not restate those elements.

HCC2D is not an alternative to QR Code but an extension of it. An HCC2D decoder must also be a QR Code reader. In practical terms, an HCC2D decoder is fundamentally a standard QR Code decoder with additional functionality for recognizing and decoding colored modules. It uses the standard QR Code detection phase to detect the symbol structure. After detection and before payload decoding, the decoder determines whether to follow the standard QR Code decoding path, in which modules are interpreted as black-and-white modules, or the HCC2D decoding path, in which modules are interpreted as 4-color or 8-color modules. This choice is made by checking whether the HCC2D Color Palette Patterns are present on the perimeter of the symbol. If the Color Palette Patterns are not present, the decoder decodes the symbol as a standard QR Code. If the Color Palette Patterns are present, the decoder decodes the symbol as an HCC2D code according to the applicable HCC2D color rules. An HCC2D encoder produces symbols that share the same structural foundation as QR Code and must be able to encode both QR Code and HCC2D code.

This document specifies the HCC2D four-color and HCC2D eight-color code formats.

1. Scope

This document covers:

• hcc2d4: 4-color HCC2D
• hcc2d8: 8-color HCC2D

This specification defines:

• square symbols only
• versions 1..40
• error-correction levels L, M, Q, H
• byte-mode payload encoding only

This specification defines HCC2D payload framing using one BYTE segment.

1.1 Terms and Acronyms

• Color Palette Pattern: the outer border of an HCC2D code containing the cyclic sequence of palette colors, serving as a color legend
• EC: error correction
• EC level: error-correction level
• ECPB: error-correction codewords per block
• MSB: most significant bit
• LSB: least significant bit
• RS: Reed-Solomon
• RGB: red, green, blue
• ISO/IEC: International Organization for Standardization / International Electrotechnical Commission

Matrix terms:

• module: one logical square cell of the symbol
• inner grid or inner matrix: the reused QR-compatible N×N matrix before the HCC2D border is added
• full symbol: the N+2 square produced after adding the HCC2D border
• function module: a non-data module belonging to finder, alignment, timing, format, or version structures
• data module: a module whose state is determined by the encoded payload and error-correction bitstream
• plane: one binary matrix extracted from the final interleaved bitstream

1.2 High-Level Structure

At a high level, HCC2D encoding proceeds as follows:

1. frame the payload as one BYTE-mode segment
2. choose the version and error-correction level
3. generate data codewords, error-correction codewords, and the final interleaved bitstream
4. split that final bitstream into two or three binary planes
5. build one QR-compatible inner matrix per plane using one shared mask pattern
6. combine plane bits into color indices for data modules
7. render function modules in black and white
8. add the HCC2D Color Palette Pattern border

HCC2D does not run a separate error-correction process per plane. One combined bitstream is produced first, and plane extraction happens only afterward.

2. Conformance Basis

A conforming implementation produces codes decodable by the official HCC2D Decoder, available on Google Play, Huawei AppGallery, and the App Store.

An implementation that claims conformance to this specification shall combine:

1. an HCC2D-specific layer defined by this document; and
2. a reused square-matrix coding layer whose behavior is compatible with QR Code / ISO/IEC 18004:2006 for all reused parts.

For interoperability with existing HCC2D decoders, the reused layer shall provide at least:

• Model-2-style square versions 1..40
• error-correction levels L, M, Q, H
• finder-pattern placement
• alignment-pattern placement from the coordinates listed in the HCC2D tables
• timing-pattern placement
• format-information generation and placement
• version-information generation and placement where applicable
• BYTE-mode data placement order in the inner matrix
• mask formulas for mask indices 0..7
• mask-penalty evaluation compatible with QR Code / ISO/IEC 18004:2006, except for the HCC2D-specific rule using the inverted plane 0 only in section 10
• Reed-Solomon parity generation and codeword interleaving compatible with QR Code / ISO/IEC 18004:2006, except for the HCC2D-specific total codeword counts and block multiplicities defined in sections 19 and 20

Therefore:

• this specification is not fully standalone
• an implementation that already has those reused QR Code / ISO/IEC 18004:2006-compatible behaviors can implement interoperable HCC2D symbol generation from this specification
• an implementation that has this specification together with the QR Code specification for the reused parts has the information needed to implement interoperable HCC2D symbol generation

In practical terms, HCC2D is not a replacement for QR-style square-matrix construction. It is a color-capacity and framing layer built on top of a reused QR-compatible inner symbol. Therefore the normative HCC2D differences are concentrated in:

• payload framing
• total codeword capacities and block multiplicities
• bit-plane extraction and color interpretation
• input selection for the data masking algorithm: inverted plane 0 only
• function-module rendering rule
• HCC2D outer border semantics

A format or symbol may be referred to as HCC2D only if it conforms to this specification. Use of the name HCC2D to describe a non-conformant format or symbol is misleading and not sanctioned by this specification.

3. Encoding Parameters

A conforming HCC2D symbol-generation process is parameterized by at least these logical values:

• payload: required, non-empty byte array
• mode: hcc2d4 or hcc2d8
• ec_level: one of L, M, Q, H
• version: 0 means auto-select; otherwise 1..40
• scale: pixels per module for raster rendering, if raster output is produced
• quiet_zone: modules of white margin around the rendered symbol, if raster output is produced
• palette_rgb: optional RGB override

The first four parameters affect the logical HCC2D symbol. The last three affect visual rendering only.

Default values, user-interface behavior, and command-line conventions are outside the scope of this specification.

Additional parameter notes:

• payload is interpreted strictly as raw bytes
• this specification does not define text transcoding, multi-segment optimization, numeric mode, or alphanumeric mode
• mode determines the number of planes and the palette family
• ec_level selects the normative table row within the chosen version
• version controls capacity, inner dimension, alignment coordinates, and block structure
• scale, quiet_zone, and palette_rgb do not change the encoded logical bitstream

4. Symbol Geometry

For both HCC2D modes, version v uses an inner square grid of dimension:

N = 17 + 4*v

Examples:

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

The inner grid reuses finder-pattern, alignment-pattern, timing-pattern, format-information, and version-information structures that follow QR Code / ISO/IEC 18004:2006-compatible rules.

HCC2D then adds its own one-module outer border on all four sides:

• inner dimension = N
• full dimension = N + 2

This HCC2D-specific outer border is the Color Palette Pattern.

The distinction between inner grid and full symbol is normative:

• all reused QR-compatible placement logic operates on the inner N × N matrix
• the HCC2D Color Palette Pattern sits outside that inner matrix
• rendering and raster output use the full N + 2 dimension

Therefore, whenever this document refers to function patterns, data placement, masking, or version geometry, those rules apply first to the inner matrix, and only afterward is the HCC2D border added.

5. Color Indices and Default Palettes

This section defines the color index bit layout for HCC2D4 and HCC2D8, the two standard Color Palette Models (Model 1 for screen display and Model 2 for print), the classification of palette models, and the rules for palette customization.

5.1 HCC2D4 — Color Palette Model 1 — Definition

HCC2D4 codes with Color Palette Model 1 shall use the following colors for palette indices 0..3. Luminance is approximate, computed as Y = 0.299R + 0.587G + 0.114B.

Color index bit layout:

• bit 1 = MSB plane
• bit 0 = LSB plane

Therefore:

• 00 → 0 → black
• 01 → 1 → red
• 10 → 2 → cyan
• 11 → 3 → white

The ordering is logical, not merely visual. Index 0 is the dark anchor and index 3 is the white anchor of the four-color family.

5.2 HCC2D8 — Color Palette Model 1 — Definition

HCC2D8 codes with Color Palette Model 1 shall use the following colors for palette indices 0..7. Luminance is approximate, computed as Y = 0.299R + 0.587G + 0.114B.

Color index bit layout:

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

Therefore the color index equals the 3-bit value formed from the three plane bits.

Again, the ordering is logical. Index 0 is the dark anchor and index 7 is the white anchor of the eight-color family.

5.3 Color Palette Model 1 — Design Rationale

The RGB values of Color Palette Model 1 (defined in sections 5.1 and 5.2) were deliberately chosen to avoid the extremes of the sRGB gamut, where different display profiles and hardware color gamuts diverge most. The decoder samples the Color Palette Pattern at runtime on the actual display screen — which may be sRGB, wide-gamut, AMOLED, or LCD, and is almost certainly uncalibrated. Near-boundary channel values (close to 0 or 255) are rendered differently across display types; by capping active channels at 200–220 rather than 255, the palette colors land in the interior of the sRGB gamut where different screens agree more reliably on the perceived color. This reduces cross-display color drift and improves the stability of color sampling during decoding.

This RGB capping choice also produces a luminance distribution consistent with the ordering requirement of section 5.9. For HCC2D8 (section 5.2), indices 0–3 (black, dark red, dark green, dark navy) all fall below the luminance midpoint (Y < 128), while indices 4–7 (light cyan, light yellow, light magenta, white) all fall above it (Y > 128). The gap between index 3 (dark navy, Y ≈ 56) and index 4 (light cyan, Y ≈ 153) is approximately 97 luminance units.

Color Palette Model 1 is the screen-validated baseline. It makes no claim to being optimal for print.

5.4 HCC2D4 — Color Palette Model 2 — Definition

For HCC2D4, all intermediate colors are single-ink. Yellow is excluded because it provides insufficient contrast with white paper:

5.5 HCC2D8 — Color Palette Model 2 — Definition

For HCC2D8, the palette exhausts all three single-ink CMYK primaries and their three binary full-saturation combinations. No three-ink combination is used:

5.6 Color Palette Model 2 — Design Rationale

Color Palette Model 2 is the print-optimized palette, defined for both HCC2D4 and HCC2D8. For print, the problem differs from screens: ink gamut, paper white point, and lighting conditions during scanning introduce different sources of variability. Color Palette Model 2 is built on the principle of minimizing the number of ink channels per module color. Single-ink colors are maximally stable across printers; each additional ink channel introduces dot gain interactions that vary with printer, paper, and ink density.

Both Color Palette Model 2 palettes satisfy the dark/light ordering of section 5.9. For HCC2D8, the split is particularly clear: indices 0–3 (black, blue, red, magenta) all fall below the luminance midpoint (Y < 128), while indices 4–7 (green, cyan, yellow, white) all fall above it (Y > 128), with a gap of approximately 45 luminance units between index 3 (magenta, Y ≈ 105) and index 4 (green, Y ≈ 150).

5.7 Color Palette Model Classification

HCC2D codes are classified by their color palette as follows. The model number is a property of the palette, not of the code format; the decoder is palette-agnostic.

• Color Palette Model 1: codes that use the exact default palette defined in sections 5.1 and 5.2. This is the standard, fully interoperable palette. Color Palette Model 1 has been validated to work well when codes are displayed on screens (computer monitors, smartphones, and similar devices). Any implementation that claims HCC2D conformance without further qualification implies Color Palette Model 1.
• Color Palette Model 2: codes that use the print-optimized palette defined in sections 5.4 and 5.5, covering both HCC2D4 and HCC2D8. Designed for print-and-scan workflows.
• Invalid palette: a palette that does not have black at index 0 or white at the last index. Codes using such a palette are not valid HCC2D codes. Conforming encoders shall reject such configurations (see section 5.8).
• Non-standard / experimental palette: a palette that keeps black at index 0 and white at the last index but uses different intermediate colors. Codes produced with such a palette may or may not be decodable, depending on how chromatically distinct the chosen colors are. The encoding implementation bears sole responsibility for any codes that fail to decode.

Color palette model numbers are assigned exclusively by this specification. Additional color palette models (Color Palette Model 3 and so on) may be defined in future versions of this specification as other color combinations are experimentally validated to perform well in specific use cases, such as computer-to-phone scanning or phone-to-phone scanning.

Palette modifications should be limited to experimental use. For production use, Color Palette Model 1 should be used when codes are to be displayed on screens (computer monitors, smartphones, and similar devices); Color Palette Model 2 should be used when codes must be printed.

Implementations that produce codes with a non-standard palette shall explicitly disclose this to their users, stating that the codes use a non-standard palette and may not be decodable by all HCC2D decoders.

5.8 Palette Override

The first palette entry and the last palette entry are normative anchors and shall not be changed:

• for hcc2d4, index 0 shall remain black and index 3 shall remain white
• for hcc2d8, index 0 shall remain black and index 7 shall remain white

Therefore:

• in hcc2d4, only indices 1 and 2 may be customized
• in hcc2d8, only indices 1 through 6 may be customized

When a palette override is provided:

• 4-color mode requires exactly 12 bytes (4 * 3)
• 8-color mode requires exactly 24 bytes (8 * 3)
• the byte layout is still the full palette in palette-index order, then RGB component order
• however, conforming encoders shall reject overrides whose first entry is not black or whose last entry is not white

Byte order is palette-entry order, then RGB component order:

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

Normative anchor values:

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

The symbol logic uses indices only. Custom RGB values do not affect codewords, bitstream construction, version selection, mask selection, or matrix layout, but they do affect rendered appearance.

Equivalently, HCC2D first determines a logical color index for each module and only then maps that index to an RGB triple for rendering.

5.9 Recommended Luminance Ordering for Customized Palettes

This subsection is advisory.

When a customized palette is used, implementations should preserve a darker lower half and a lighter upper half. This recommendation is motivated by the HCC2D mask-selection rule defined later in this specification.

HCC2D mask selection is not performed on the final full-color rendered symbol. Instead, mask selection is performed on a binary proxy derived from one bit-plane only:

• only plane 0 participates in mask selection
• for hcc2d4, plane 0 is the color most-significant bit
• for hcc2d8, plane 0 is the color most-significant bit (bit 2)
• that one plane is extracted from the final interleaved bitstream
• that plane is then inverted
• the reused QR-compatible mask penalty rules are evaluated on that inverted single-plane proxy

Therefore, only one bit per module directly influences mask choice.

This has an important practical consequence. The mask is chosen using QR-style binary penalty rules, but the final HCC2D symbol is a multi-color symbol. For the QR-style mask-selection process to remain meaningful for HCC2D, the binary proxy used for mask choice should still correlate reasonably well with the apparent darkness structure of the final rendered symbol.

That correlation is improved when lower palette indices are darker and higher palette indices are lighter. In that arrangement, the single plane used for mask selection still acts as a useful coarse approximation of how dark-versus-light regions are distributed in the final HCC2D symbol.

Therefore, palette customization should preserve a rendered luminance ordering in which the lower half is darker overall and the upper half is lighter overall, consistent with the logical significance ordering of the color indices.

In practical terms:

• lower palette indices should correspond to darker colors
• higher palette indices should correspond to lighter colors
• the first entry shall remain black
• the last entry shall remain white

Recommended ordering for hcc2d4:

• index 0 shall be black
• index 1 should be visually darker than index 2
• index 3 shall be white
• as a 4-color family-level guideline, indices 0 and 1 should form the darker half of the palette and indices 2 and 3 should form the lighter half

Recommended ordering for hcc2d8:

• index 0 shall be black
• index 7 shall be white
• indices 1, 2, and 3 should fall in the darker half of the palette
• indices 4, 5, and 6 should fall in the lighter half of the palette
• as an 8-color family-level guideline, indices 0 through 3 should be darker overall than indices 4 through 7

This recommendation does not change symbol logic, because HCC2D uses palette indices rather than luminance values when constructing the symbol. A palette that violates the recommended darker-lower / lighter-upper balance may still produce decodable symbols. However, doing so weakens the intended relationship between:

• the proxy used during mask selection
• the apparent darkness distribution of the final rendered symbol
• the visual stability of the customized palette across different scanning conditions

If that dark-versus-light balance is preserved, the reused QR-style mask rules remain a reasonable and useful heuristic for HCC2D as well.

If that balance is not preserved:

• the encoder may still generate valid symbols
• decoders may still successfully decode those symbols
• but the selected mask is then optimized for the binary QR-style proxy rather than for a final color arrangement whose perceived darkness follows the same structure

In that case, mask selection still works in the narrow sense that a mask is chosen and the resulting symbol may remain decodable, but the QR-style penalty model becomes less representative of the visual properties of the actual HCC2D symbol.

For that reason, a customized palette should preserve darker colors in the lower indices and lighter colors in the higher indices.

6. Payload Framing

HCC2D payload framing uses one BYTE segment.

• segment marker bits: 0100
• count field width: 16 bits in both HCC2D modes, for all versions
• count value: payload length in bytes
• payload bytes: appended verbatim, 8 bits each, most-significant bit first

The logical payload bitstream before termination is:

0100 || byte_count_16 || payload_bytes

Termination bits, byte alignment, pad bytes, Reed-Solomon parity generation, and final interleaving follow QR Code / ISO/IEC 18004:2006-compatible rules, except where this specification explicitly defines HCC2D-specific behavior.

Important consequences of this framing rule:

• the count field is always sixteen bits for HCC2D, regardless of version
• the count value is a byte count, not a bit count and not a character count
• the payload bytes are appended verbatim in most-significant-bit-first order
• this specification defines exactly one BYTE segment per HCC2D symbol

7. Version Selection

If a version is explicitly specified, it shall be used only if the payload fits.

If automatic version selection is used, the smallest fitting version shall be selected.

For a given HCC2D mode, version, and error-correction level:

• total_codewords, data_codewords, ec_codewords, and block layout are given by the explicit HCC2D tables in sections 19 and 20
• a payload fits iff its framed bitstream can be terminated and padded into exactly data_codewords bytes

For this purpose, the framed bitstream length before termination is:

4 + 16 + 8 * payload_length

where 4 is the BYTE mode indicator and 16 is the HCC2D byte-count field width.

A payload fits when that framed bitstream can be:

1. optionally terminated by up to four zero bits
2. padded with zero bits to the next byte boundary
3. padded with alternating pad bytes until the exact data-codeword capacity is reached

without exceeding the available data-codeword count for the selected mode, version, and error-correction level.

8. HCC2D Codeword Organization

The HCC2D parameter tables in sections 19 and 20 are normative.

Error-correction structure follows ISO/IEC 18004:2006-compatible rules, except where this specification explicitly defines HCC2D-specific behavior.

Each table row gives:

• dim: inner dimension
• align: alignment-pattern center coordinates
• total: total codewords
• data: data codewords
• ec: error-correction codewords
• ecpb: error-correction codewords per block
• blocks: block multiplicities and data codewords per block

Those values fully determine the HCC2D codeword organization for each version and level.

For hcc2d4, the total codeword count for each version and level is exactly twice the corresponding reused QR Code / ISO/IEC 18004:2006-compatible base structure.

For hcc2d8, the total codeword count for each version and level is exactly three times the corresponding reused QR Code / ISO/IEC 18004:2006-compatible base structure.

More precisely:

• hcc2d4 keeps the reused QR Code / ISO/IEC 18004:2006-compatible codewords-per-block values and doubles the block multiplicities
• hcc2d8 keeps the reused QR Code / ISO/IEC 18004:2006-compatible codewords-per-block values and triples the block multiplicities

This is the mechanism by which HCC2D increases total bit capacity while continuing to use reused QR-compatible Reed-Solomon procedures.

9. Plane Construction

Let the final interleaved codeword bitstream be B.

Plane construction is performed only after:

• data codewords have been formed
• error-correction codewords have been generated
• final interleaving has been completed

HCC2D does not create separate error-correction streams per plane. Instead, one combined final bitstream is produced first and then split by stride into planes.

9.1 HCC2D4 — Two planes

hcc2d4 uses two planes.

Plane extraction is by bit deinterleaving from the final bitstream:

• plane 0 takes bits at positions 0, 2, 4, ...
• plane 1 takes bits at positions 1, 3, 5, ...

Plane 0 is the MSB plane. Plane 1 is the LSB plane.

Data module color index:

color = (plane0_bit << 1) | plane1_bit

Equivalently, if the final interleaved bitstream is B[0], B[1], B[2], ..., then symbol module colors are driven by bit pairs:

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

9.2 HCC2D8 — Three planes

hcc2d8 uses three planes.

Plane extraction is:

• plane 0 takes bits at positions 0, 3, 6, ...
• plane 1 takes bits at positions 1, 4, 7, ...
• plane 2 takes bits at positions 2, 5, 8, ...

Plane 0 is the MSB plane. Plane 2 is the LSB plane.

Data module color index:

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

Equivalently, if the final interleaved bitstream is B[0], B[1], B[2], ..., then symbol module colors are driven by bit triples:

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

The plane order is normative and shall not be permuted. In hcc2d4, plane 0 is the most-significant bit and plane 1 is the least-significant bit. In hcc2d8, plane 0 is bit 2, plane 1 is bit 1, and plane 2 is bit 0.

10. Mask Selection

A single mask pattern in 0..7 shall be used for all planes of a symbol.

Mask selection follows ISO/IEC 18004:2006-compatible rules, except where this specification explicitly defines HCC2D-specific behavior.

HCC2D-specific behavior for candidate evaluation:

• build a proxy bitstream from plane 0 only
• invert every bit of that plane-0 stream
• use that inverted stream for mask-penalty evaluation

Mask selection procedure:

1. for each candidate mask index in 0..7, apply that mask to the inverted plane-0 bitstream and build a candidate inner matrix from it
2. compute the mask penalty on that candidate matrix
3. select the mask index with minimum penalty

Tie-breaking is by first minimum encountered, i.e. lowest mask index.

Once the winning mask index is chosen, that one index shall be reused for every plane of the symbol. HCC2D does not choose different mask patterns for different planes.

11. Inner-Matrix Construction

Each plane is converted into an inner matrix using the chosen version and the chosen common mask pattern.

Important: all planes use the same function pattern geometry, the same version, the same format bits, and the same mask index. They differ only in data bits.

This document does not restate the reused finder-pattern, alignment-pattern, timing-pattern, format-information, version-information, Reed-Solomon, or mask formulas in full.

Thus, inner-matrix construction for HCC2D can be understood as repeated QR-compatible matrix construction over the same geometry, once per plane, with only the plane bitstream changing from one pass to the next.

12. Function Module Coloring

For hcc2d4 and hcc2d8, data modules use the multi-plane color mapping described above, but function modules are rendered only in black and white:

• if plane 0 at that function-module coordinate is 1, render black
• otherwise render white

In practice this is safe because function modules are identical across all planes.

This rule applies to all reused structural modules in the inner matrix, including finder patterns, alignment patterns, timing patterns, format information, and version information where applicable.

13. Color Palette Pattern

The Color Palette Pattern must be implemented exactly as specified: decoders sample its modules to reconstruct the color palette. A decoder has no prior knowledge of the palette colors, except that the first entry is black and the last is white. The Color Palette Pattern is therefore necessary for decoding.

Let the inner dimension be N.

The HCC2D border sits one module outside the inner grid:

• top border row is at logical row -1
• bottom border row is at logical row N
• left border column is at logical column -1
• right border column is at logical column N

The HCC2D code shifts those logical coordinates by +1 in both axes, producing a (N+2) × (N+2) grid.

The Color Palette Pattern is a structural part of HCC2D, not optional ornamentation. Its geometry and color-index order are part of the format definition.

13.1 Color Palette Pattern period

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

The active spans on each edge cycle through all P palette indices repeatedly. The exact formula for each edge, including the starting index and cycling direction, is given in section 13.2.

The cycle is defined in terms of logical palette indices, not literal RGB values.

13.2 Exact Color Palette Pattern color formulas

Let row and col be logical coordinates in the border coordinate system described above.

The Color Palette Pattern border shall use these exact rules:

1. Top edge: if row == -1 and 8 ≤ col < N - 8, then color = (col - 8) mod P
2. Bottom edge: if row == N and 8 ≤ col < N, then color = (col - 8) mod P
3. Left edge: if col == -1, let start = N - 9. If 8 ≤ row ≤ start, then color = (start - row) mod P
4. Right edge: if col == N and 8 ≤ row < N, then color = (row - 8) mod P
5. All remaining border cells: color = P - 1

This means the non-cycling border cells, including corners and excluded spans near the finder patterns, are always the highest palette index:

• 3 for HCC2D4 → white
• 7 for HCC2D8 → white

13.3 Color Palette Pattern replicas by mode

Not all border modules carry palette colors. Modules at the corners and near the finder patterns are fixed white (color = P − 1, as defined in section 13.2). The length of the segment that cyclically replicates the palette colors on each edge is:

• top edge: N − 16 modules
• bottom edge: N − 8 modules
• left edge: N − 16 modules
• right edge: N − 8 modules

For HCC2D8 (P = 8), the same lengths apply.

The exact sequence per edge — including starting index and direction — is determined by the formulas in section 13.2. The top, bottom, and right edges increment with their scan coordinate. On the left edge the palette index decreases with increasing row; the exact starting index at each version is given by the formula in section 13.2.

13.4 Decoder-facing interpretation

The decoder samples these strips to recover palette statistics. Therefore the border is part of the symbol format, not merely a decoration.

Any implementation that changes the span geometry, cycling direction, or fallback white cells of the Color Palette Pattern would generate a non-conformant symbol.

14. Rendered Output Coordinates

This section defines raster rendering of a logical HCC2D symbol. The logical symbol is fully defined without fixing any particular pixel size.

14.1 Module coordinates

For HCC2D modes:

• full module grid size = N + 2
• inner module (x, y) maps to rendered module (x + 1, y + 1)

14.2 Quiet zone

The rasterized image adds quiet_zone modules of background color on all four sides.

Background color index:

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

14.3 Image size in pixels

Let F be the full module dimension:

F = N + 2

Then:

• image width = (F + 2 * quiet_zone) * scale
• image height = same

Each logical module is rasterized as a scale × scale solid-color square.

For HCC2D symbols, the quiet zone uses the highest palette index:

• 3 for hcc2d4
• 7 for hcc2d8

Under the default palettes, this corresponds to white.

15. Decoder-Relevant Structural Rules

15.1 HCC2D count field

The BYTE count field is 16 bits in both HCC2D modes.

15.2 Plane order

For 4-color HCC2D:

• plane 0 is the color MSB
• plane 1 is the color LSB

For 8-color HCC2D:

• plane 0 is the color MSB (bit 2)
• plane 1 is bit 1
• plane 2 is the color LSB (bit 0)

15.3 Common mask

All planes must use the same mask pattern.

These rules are decoder-relevant because a decoder that assumes QR-style variable BYTE count-field widths, a different plane significance order, or independent per-plane masks would not correctly interpret a conforming HCC2D symbol.

16. Encoding Procedure

A conforming HCC2D encoding procedure shall perform the following steps:

1. Validate inputs.
2. Select symbol family (hcc2d4 or hcc2d8).
3. Select error-correction level (L/M/Q/H).
4. Choose version: use the explicitly specified version if it fits; otherwise, when automatic selection is used, choose the smallest fitting version.
5. Build logical payload bitstream: 0100 || byte_count_16 || payload_bytes
6. Determine family-specific capacity and block layout from the explicit HCC2D table for the chosen mode, version, and level.
7. Apply termination and pad bytes.
8. Generate parity and interleave codewords using the reused error-correction structure.
9. Split the final bitstream into 2 or 3 planes by strided extraction.
10. Select one common mask index: for HCC2D modes, evaluate penalties using inverted plane 0 only.
11. Build one inner matrix per plane using the common version, EC level, and mask.
12. Render data modules:
    • HCC2D4: color index from 2 plane bits
    • HCC2D8: color index from 3 plane bits
13. Render function modules as black/white from plane 0.
14. Add the exact one-module Color Palette Pattern border using the coordinate formulas in section 13.
15. Add white quiet zone.
16. Rasterize modules into pixels if a raster image output is needed.

The order of operations matters. In particular:

• error correction and interleaving occur before plane extraction
• mask selection occurs once and is shared by all planes
• inner-matrix construction occurs before the Color Palette Pattern border is added
• the quiet zone is outside the full HCC2D symbol and is not part of the logical payload structure

17. Optional HCC2DF Payload Wrapper

This section does not define the HCC2D code itself.

It defines an optional payload-wrapper format, HCC2DF, that may be used before HCC2D symbol encoding when the application wants to carry a filename together with file content. When used, the HCC2DF byte stream becomes the payload defined in sections 3, 6, and 16 of this specification.

HCC2DF is an application-level wrapper layered on top of HCC2D payload bytes. It is not part of the HCC2D symbol geometry or color logic.

17.1 HCC2DF byte layout

The HCC2DF payload bytes are:

1. ASCII magic: "HCC2DF" → 6 bytes
2. wrapper version byte: 0x01
3. compression flag byte:
   • 0x00 = raw content
   • 0x01 = zlib-compressed content
4. filename length: 1 byte
5. filename bytes: UTF-8, exactly filename_length bytes
6. content bytes: raw file bytes or compressed file bytes

No checksum field, footer, or nested metadata structure is defined by this wrapper.

17.2 Filename constraints

• filename must be non-empty
• filename must be at most 127 UTF-8 bytes
• filename must not contain /
• filename must not contain \

17.3 Compression rule

If compression is attempted, the content is compressed using zlib compress2(..., Z_DEFAULT_COMPRESSION).

Compression should be used only if all of the following are true:

• compression succeeds
• original file size is at least 128 bytes
• compressed size is strictly less than 90% of original size

Otherwise raw file bytes should be stored and the compression flag should be 0x00.

The 128-byte minimum reflects the fixed overhead that zlib compression always introduces. The zlib wrapper alone adds 6 bytes (2-byte header + 4-byte Adler-32 checksum). On top of that, deflate block headers add further overhead: a stored block adds 5 bytes, and a dynamic Huffman block adds the code table description, which can be 20–50 bytes for small inputs — giving a realistic total overhead of around 36 bytes. To see why 128 bytes is the right threshold, consider the two cases:

• 64-byte input: budget to pass 90% rule = 64 × 0.9 − 36 = 21.6 bytes left for actual data — the content must compress to ~34%, achievable only for highly repetitive sequences.
• 128-byte input: budget = 128 × 0.9 − 36 = 79 bytes left for actual data — the content must compress to ~62%, which is realistic for typical text, JSON, or URLs.

Below 128 bytes the overhead consumes so much of the available budget that compression is unlikely to produce a meaningful result for any real-world payload.

This rule prefers compression only when it gives a clear size benefit. Implementations may use a different threshold (e.g. 95%) but this is not recommended: a higher threshold means compressing data that saves only a few percent of space, which is not a meaningful benefit — storing the raw bytes is simpler and the result may be practically almost the same size. In any case, implementations that deviate from this recommendation will still produce codes decodable by the official HCC2D Decoder, as long as the compression flag and the content remain coherent: if the flag is 0x01 the content must be valid zlib-compressed data; if the flag is 0x00 the content must be the raw bytes.

17.4 Scope relationship to HCC2D

HCC2DF is an optional wrapper carried inside HCC2D payload bytes. It is not part of the HCC2D code structure, color encoding, codeword organization, or symbol geometry.

18. Implementation Recommendations

The following are advisory recommendations for implementors. They are not normative requirements of this specification. Normative requirements elsewhere in this specification are expressed using the terms "shall" and "shall not"; this section uses "should" and "should not" for advisory guidance.

Recommended error-correction level: For HCC2D codes, levels Q or M should be used. Level L should not be used for general use. Level H provides maximum robustness at the cost of significantly reduced payload capacity.

Recommended mode: For production use, hcc2d4 should be used. hcc2d8 offers greater payload capacity but requires more chromatically consistent display and scanning conditions.

Print and production quality: For printed production-use codes:

• A lossless output format (PNG, SVG, or PDF) should be used. Lossy formats such as JPEG introduce compression artifacts that corrupt module colors.
• Each module should be rendered as a solid color block; halftoning should not be used.
• The aspect ratio should not be stretched, squeezed, or distorted.
• Blur, antialiasing, and resampling should not be applied after rasterization.
• The module size should be at least 0.5 mm (GS1 target X-dimension for QR Code), or preferably around 1 mm for improved reliability. Smaller modules reduce color differentiation during decoding.

19. Explicit HCC2D4 Parameter Table

The following values are the HCC2D4 version parameters. They are the complete HCC2D4 totals and block layouts.

Table field meanings:

• Vn: HCC2D version number.
• dim: inner symbol dimension in modules, excluding the one-module HCC2D Color Palette Pattern border.
• align: alignment-pattern center coordinates on the inner grid. An empty list means that no alignment patterns are present.
• L, M, Q, H: error-correction levels.
• total: total number of codewords in the symbol for that version and error-correction level.
• data: total number of data codewords in the symbol for that version and error-correction level.
• ec: total number of error-correction codewords in the symbol for that version and error-correction level.
• ecpb: error-correction codewords per block.
• blocks=a x b: a Reed-Solomon blocks, each carrying b data codewords and ecpb error-correction codewords.
• blocks=a x b, c x d: two block groups; the first has a blocks of b data codewords each, and the second has c blocks of d data codewords each. Every block in both groups carries the same ecpb error-correction codewords.

Worked example:

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

means:

• version 1
• inner grid 21 × 21
• no alignment patterns
• at error-correction level L
• 52 total codewords in the symbol
• 38 data codewords
• 14 error-correction codewords
• 2 Reed-Solomon blocks
• each block contains 19 data codewords and 7 error-correction codewords

The HCC2D8 table below uses exactly the same field meanings.

Parameters derived from QR Code (ISO/IEC 18004:2006) by applying the HCC2D color encoding multiplier.

20. Explicit HCC2D8 Parameter Table

The following values are the HCC2D8 version parameters. They are the complete HCC2D8 totals and block layouts.

Parameters derived from QR Code (ISO/IEC 18004:2006) by applying the HCC2D color encoding multiplier.

21. Publishing Note

This specification intentionally does not republish finder-pattern, alignment-pattern, timing-pattern, error-correction, or mask-rule content associated with QR Code. For reused parts, it states only that they follow the same structures used by QR Code, or ISO/IEC 18004:2006-compatible structures, and then fully specifies the HCC2D-specific parts and HCC2D parameter tables.

Accordingly, this document should be read as:

• complete for HCC2D-specific behavior
• intentionally non-exhaustive to avoid republishing QR Code component information
• normative together with the QR Code specification, for the definition of the QR Code components reused by HCC2D

Annex A — Illustrative Examples

The following symbols are HCC2D-compliant barcodes generated according to this specification. Each symbol is scannable with the official HCC2D Decoder app. The figures are rendered at 0.80 mm per module. This corresponds to the physical size on the printed page when the PDF version of this specification is printed at 100% scale on paper.

The following symbols encode Tintern Abbey by William Wordsworth (6,900 bytes, zlib-compressed HCC2DF container), demonstrating HCC2D capacity for long-form text.

— End of Specification —