Integer Color Format Conversion Relations

01The Canonical Model

uint8 and uint16 are the canonical integer representations. They are mutually coherent: bit replication and truncation between them is lossless, and their float conversions agree:

02Bitwise Conversions

Bit replication and truncation are the convention in hardware and in software rendering engines: they are how a uint5 or uint3 asset yields its canonical uint8 values. Formats that specify a conversion of their own are listed in Appendix A.

uint8 → uint3: value >> 5
uint8 → uint4: value >> 4
uint16 → uint8: value >> 8

uint3 → float: extend to uint8, then /255
uint8 → float: /255
uint16 → float: /65535

float → uint8: round(clamp(f * 255, 0, 255)) — or dither; truncate bits if needed

03Exact Rounding

When the content is genuinely higher-precision — not a replicated code — reduction is quantization: read the source by its own divisor and round to the destination's, the exact v / (2^n - 1) model in both directions. Between coherent depths that is the nearest code on the replication lattice, and it has a closed form:

Extension is still replication. Quantized or not, uint8 → uint16 is v * 0x101, never the mid-cell padding (v << 8) | 0x80. Mid padding cannot reach either endpoint (0 becomes 0x0080 and 255 becomes 0xFF80 — full scale is lost), pulls every value toward mid gray by up to half a low code (+128/65535 at 0, −127/65535 at 255, nothing at 128), and puts every value but 128 off-lattice, so it is not a fixed point of the conversions: reducing and re-extending yields v * 0x101, not the value it came from.

v * 0x101
  0 → 0x0000
  1 → 0x0101
128 → 0x8080
255 → 0xFFFF

(v << 8) | 0x80
  0 → 0x0080
  1 → 0x0180
128 → 0x8080
255 → 0xFF80

04Coherent Bit Depths

Bit depths that divide evenly into a larger depth are fully coherent: bit replication, truncation, and float conversion all align perfectly.

For these, bit replication to the larger depth followed by division yields identical float values to direct division by (2^n - 1).

05Non-Divisor Bit Depths

Bit depths that don't divide evenly into 8:

For these depths:

• Bit replication is the definition. This is what the format means, unless the format specifies otherwise (Appendix A).
• Bit truncation is lossless. It is the inverse of replication.
• Float conversion via /255 is the definition. The value extend_to_uint8(v) / 255.0 is the correct float representation.

Replication is not exact rounding up. Extending by the exact model, round(v * 255 / max), gives the same uint8 codes as replication for uint2 and uint3, so for RGB332 the two agree on every code; for uint5 they differ on 4 codes of 32 and for uint6 on 10 codes of 64, always by one:

The differing codes are those whose exact value lies within a quarter code of a halfway point, with the replicated low bits landing on the other side of it. RGB565 content extended by replication and by exact rounding are therefore different uint8 images; the format defines the first.

06Incorrect Conversions

Dividing by (2^n - 1) directly

// WRONG: uint3 → float as v/7
float f = uint3_value / 7.0;

// CORRECT: extend first
float f = replicate_to_uint8(uint3_value) / 255.0;

The exact interpretation, each bit depth with its own divisor, skips the canonical form: the divisor belongs to the uint8 value the format defines, not to the low-depth code. Formats that define the float at their own depth are the exception: Direct3D's UNORM textures read B5G6R5_UNORM's red as v/31 (Appendix A).

Rounding during truncation

// WRONG: rounding during truncation
uint3 = (uint8 + 16) >> 5;

// CORRECT: truncation
uint3 = uint8 >> 5;

Rounding during truncation targets a lattice that doesn't exist: 0xFE80 is nearest 0xFE (extension 0xFEFE), yet (0xFE80 + 128) >> 8 gives 0xFF, and 0xFFFF overflows. Exact rounding, nearest on the true lattice, is round(v * 255 / 65535) — for quantizing genuine 16-bit content, never for reinterpreting codes. Plain truncation is always more correct than rounding during truncation; where precision matters, exact rounding is the correct way; both keep the round-trip guarantee.

Mixing divisors across bit depths

// WRONG: comparing values by their exact divisors
float a = uint3_value / 7.0;
float b = uint5_value / 31.0;

// CORRECT: extend both to canonical depth
float a = replicate_3_to_8(uint3_value) / 255.0;
float b = replicate_5_to_8(uint5_value) / 255.0;

07Why This Works: The Infinite Bit Replication Model

A uint_n value represents an infinitely repeating binary fraction:

This infinite series sums to exactly v / (2^n - 1), which is why the endpoints work:

0.111111... (binary) = 1.0 (exactly, like 0.999... = 1 in decimal)

Bit extension reveals more digits of this infinite pattern. Bit truncation recovers the original pattern. These operations are inverses by construction.

When extending to a non-multiple bit depth (e.g., 3→8), the pattern truncates at a non-aligned boundary. The subsequent /255 then interprets an 8-bit repeating pattern rather than the original 3-bit repeating pattern. This is not an error; it is the definition. The uint8 form is canonical.

08Summary

AAppendix A: Canonical Forms by Format

Some formats, DXT and BC7 among them, specify their own conversion for obtaining the uint8 value. Where a format does, that specification is authoritative: the uint8 value it produces is the canonical value, and everything in this article applies from that value onward. Bit replication is what hardware does for low bit depth formats, so outside those specified behaviors it is the correct option. The table lists what each format defines as its canonical value and the operation its specification names for getting there; where a row quotes a specification, the wording is the specification's own, and the sources follow the table.

Read down the third column, every integer color format that specifies its own expansion specifies bit replication, and the two that do not are the two whose codes do not mean fractions of full scale: limited-range video, where the scale is defined by the shift, and ASTC's trit and quint endpoints, which are not binary fractions at all. PNG is the one specification that ranks the methods, and it ranks them as this article does: linear scaling for precision, replication within one code of it, zero fill wrong at white. UNORM stands apart by defining a float, not an integer.

Sources: PNG Specification 1.2, sections 9.1 "Sample depth scaling" and 10.4 "Sample depth rescaling" (encoders, decoders); Direct3D 11.3 Functional Specification, 3.2.3 "Integer Conversion" and 19.5.2 to 19.5.6 (block compression error tolerance, promotion, BC1); BC7 Format, "Decoding the BC7 Format"; OES_compressed_ETC1_RGB8_texture and the Khronos Data Format Specification, ETC2 and ASTC chapters ("Endpoint Unquantization"); ITU-R BT.709 and BT.2100, digital representation tables.