Should you normalize RGB values by 255 or 256?
Dividing RGB values by 255 vs. 256 reflects two quantizer types with different precision and convenience tradeoffs.
When converting 8-bit RGB integers to floating point, division by 255 (standard) maps 0→0.0 and 255→1.0, while division by 256 with a +0.5 bias maps 0→0.001953125. The standard approach is a mid-riser quantizer; the alternative is a mid-tread quantizer. The standard formula's extreme bins are half-width, making 0 and 255 half as likely in uniform random generation. Division by 255 produces inexact floats (128/255 ≈ 0.501961 vs. 128/256 = 0.5), though the error is negligible. The alternative maps each value between integers, potentially aiding dithering. Theoretically, division by 256 has lower reconstruction error (1/1024 vs. 1/1020 mean absolute error), but only when controlling both encoding and decoding. For processing images from others, division by 255 is standard and correct. Mixing encode/decode steps from both methods yields broken results.
What HN community is saying
Commenters prioritize practical context over theory. The dominant point: performance matters more than precision for many use cases. Right-shift by 8 bits (approximating division by 256) is dramatically faster than floating division by 255 in hot loops (1 cycle vs. 20+), making the alternative attractive for software renderers and real-time code. However, deeper concerns emerged: alpha blending and compositing workflows assume 0→0.0 and 255→1.0 for masking logic; shifting that breaks multiplicative identity and causes subtle artifacts. One commenter noted that colorspace conversion (sRGB linearization) happens after load, so dynamic range squishing from the +0.5 offset creates downstream problems. The broadcast standards debate (16-235 for SDR) appeared but was tangential.