Should always be 0-255 as that fits an unsigned byte.
> assume that in both cases the output values are clamped before the final typecast
Should you normalize RGB values by 255 or 256?
11–20 of 156 posts
Re: Should you normalize RGB values by 255 or 256?
#12Should always be 0-255 as that fits an unsigned byte.
That's not what the article is about.
Re: Should you normalize RGB values by 255 or 256?
#13255 gives 0-255, which gives you a zero value. 256 is 1-256, you lose the option of setting 0.
That's not what the article is about.
Re: Should you normalize RGB values by 255 or 256?
#14A similar issue exists in the audio world, for example 16-bit integer audio is between [-32768, 32767] (non-symmetric), but floating point audio is [-1.0, 1.0].
Re: Should you normalize RGB values by 255 or 256?
#15Re: Should you normalize RGB values by 255 or 256?
#16Re: Should you normalize RGB values by 255 or 256?
#17A similar issue exists in the audio world, for example 16-bit integer audio is between [-32768, 32767] (non-symmetric), but floating point audio is [-1.0, 1.0].
note that floating point audio very often exceeds [-1.0, 1.0] within the pipeline, just to be tamed at the very end of the mix to fit within those bounds. this is pretty much why every modern DAW uses floating point these days.
Re: Should you normalize RGB values by 255 or 256?
#18I'll argue for the +0.5 solution. First, I don't like half-sized intervals at the edges, and second, a 255-based representation is typically a SDR (not HDR) image. RGB values represent luminances against some adapted state, and a "zero" in a daylit scene is not "zero luminance" - it's just about 0.001x as bright as the brightest point - it's millions of photons, way more than zero. In a sense our eyes experience cont…
I agree. Additionally, both 0.0 and 1.0 don't really exist for dithered signals, so a byte should map to [0.5, 255.5] before division by 256. This also solves the signed integer asymmetry, as a signed byte maps to [-127.5, 127.5] before division by 128. I wonder if audio DSP folks have done this already.
Re: Should you normalize RGB values by 255 or 256?
#19Earlier quoted context omitted.
yes but >> 8 is so much faster
Only in micro-benchmarks. For real usage, today's CPUs are limited by memory bandwidth.
What are you talking about in a hot loop in my software renderer this is like 10x faster
// color4_t result = {
// .r = (src.r * src.a + dst.r * inv_alpha) * INV_255,
// .g = (src.g * src.a + dst.g * inv_alpha) * INV_255,
// .b = (src.b * src.a + dst.b * inv_alpha) * INV_255,
// .a = src.a + (dst.a * inv_alpha) * INV_255
// };
// 1/256 but much faster
color4_t result = {
.r = (src.r * src.a + dst.r * inv_alpha) >> 8,
.g = (src.g * src.a + dst.g * inv_alpha) >> 8,
.b = (src.b * src.a + dst.b * inv_alpha) >> 8,
.a = src.a + ((dst.a * inv_alpha) >> 8)
};Re: Should you normalize RGB values by 255 or 256?
#20Earlier quoted context omitted.
Only in micro-benchmarks. For real usage, today's CPUs are limited by memory bandwidth.
What are you talking about in a hot loop in my software renderer this is like 10x faster // color4_t result = { // .r = (src.r * src.a + dst.r * inv_alpha) * INV_255, // .g = (src.g * src.a + dst.g * inv_alpha) * INV_255, // .b = (src.b * src.a + dst.b * inv_alpha) * INV_255, // .a = src.a + (dst.a * inv_alpha) * INV_255 // }; // 1/256 but much faster color4_t result = { .r = (src.r * src.a + dst.r * inv_alpha) >> 8,…
Because you are working in the cache.
Also, you should use SIMD.