When converting 8-bit RGB channel values to floating-point numbers, should the values be divided by 255 so that 0 maps to 0.0 and 255 maps to 1.0, or divided by 256 using a different quantization convention? What are the practical trade-offs, especially when doing image processing, converting between sRGB and linear light, or saving the results back to 8-bit formats?
4 Answers
Dividing by 256 can make sense in a carefully controlled quantization pipeline, particularly if you treat the samples as bins or use a half-step bias. It may give slightly different error characteristics, but it also means black is no longer exactly zero unless you handle that separately. For images created elsewhere, that convention can introduce additional error, so it usually is not the right default.
The divisor is not the only issue. Mathematical image operations should generally be performed in linear-light space, not directly on gamma-encoded sRGB values. Convert sRGB to linear values, do the operation, convert back to sRGB, and then quantize to 8 bits. You still need a consistent endpoint convention, and 255 is normally the practical choice.
An 8-bit channel has 256 possible values: 0 through 255. The zero value is important because it represents no light, so reserving 0.0 for black is usually preferable. Using 256 as the divisor leaves the maximum value below 1.0 and can cause pure white to come back slightly gray unless the conversion is designed around that behavior.
For ordinary 8-bit images, divide by 255. That maps black exactly to 0.0 and white exactly to 1.0, which is the convention most image formats, APIs, and graphics hardware expect. When converting back, multiply by 255 and round or clamp to the valid 0–255 range.
So the 256 approach is mainly useful when you control both the encoding and decoding steps, rather than when loading arbitrary 8-bit images?