When converting 8-bit RGB channel values, ranging from 0 through 255, into floating-point values, should each channel be divided by 255 or 256? Dividing by 255 maps black to 0.0 and white to 1.0, while dividing by 256 keeps the maximum value just below 1.0. Which approach is technically correct, and are there situations where the alternative makes sense?
4 Answers
For ordinary 8-bit images, divide by 255. That maps 0 to exactly 0.0 and 255 to exactly 1.0, which is what most image formats, APIs, and GPU workflows expect. Dividing by 256 leaves white at about 0.9961 and shifts the interpretation of the range.
The bigger issue is the color space. If you are doing blending, lighting, filtering, or other calculations, convert sRGB values to a linear-light space first, perform the math there, then convert back and quantize. The 255-versus-256 choice still matters at the conversion boundaries, but it is not a substitute for working in the correct color space.
Remember that an 8-bit channel has 256 possible values: 0 through 255. Zero must represent no light, so using 255 as the maximum gives the intuitive normalized range from 0.0 to 1.0. If you need different quantization behavior or more precision, it is usually clearer to use a higher-precision format instead of silently treating white as less than one.
Dividing by 256 can be reasonable if you control the entire pipeline and deliberately treat the values as quantization bins. It can slightly reduce average quantization error, but black no longer maps to exactly zero unless you apply an offset. For images produced elsewhere, that tradeoff usually adds error rather than removing it.
That approach is mostly useful when you also control how floating-point values are converted back to 8-bit values. Otherwise, standard 0-to-255 scaling is safer and more interoperable.
Exactly. Most stored RGB values are not linear, so doing arithmetic directly on the encoded sRGB numbers can produce incorrect brightness and color results.