You should multiply by 255.0, optionally add a dither (triangular is okay), and then let the FPU round using its default IEEE 754 round-to-nearest-ties-to-nearest-even mode. None of this crazy 0.5 stuff. :-)
Should you normalize RGB values by 255 or 256?
21–30 of 156 posts
Re: Should you normalize RGB values by 255 or 256?
#22Both. 255 for each color and the last 1 as the alpha for each channel.
Why not??? Fight me
Re: Should you normalize RGB values by 255 or 256?
#23Interesting article. I tend to use
- i = min(floor(f * 256), 255) (from float to uint8)
- f = i / 255 (from uint8 to float)
Basically a mix of the 2 approaches mentioned in the article.
For all integers between [0,255], if I do uint8 -> float -> uint8 conversion, I will get the same result.
--
edit: I wondered what's the maximum jitter amount that I can introduce to the float and get the same uint8 value. And also these 0->0.0 and 255->1.0 should map properly.
With my approach at the top, the jitter margin that I can introduce is 1/65280.
But with the article's approach
- i = floor(f * 255 + 0.5)
- f = i / 255
maximum jitter margin is 1/510 (which is better).
Re: Should you normalize RGB values by 255 or 256?
#24Earlier quoted context omitted.
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.
> Also, you should use SIMD.
ironically no clang is better at auto vectorizing
Re: Should you normalize RGB values by 255 or 256?
#25Re: Should you normalize RGB values by 255 or 256?
#26I'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…
> In a sense our eyes experience contrast on a sliding scale
There's a whole visual center to check the amount of incoming light and adjust your pupils for you. It's intentionally reactive.
> and there is no absolute zero in the system.
There maybe is. I think we call that "blind."
> broadcast systems historically used 16-235 as their luminance range for SDR
Mostly because it was a fully analog system and these all translate down to signal voltage. Jokingly NTSC used to be referred to as "Never Twice the Same Color" due to being a compromise bolted onto the side of an already compromised system.
Re: Should you normalize RGB values by 255 or 256?
#27Re: Should you normalize RGB values by 255 or 256?
#28If you have a ruler and it goes to 12 inches, you should normalize by the length L and not by 13, the number of points on the ruler.
yes but >> 8 is so much faster
You don’t divide a float by 256 by shifting it right eight bits; that would yield complete garbage. You subtract 8 from the exponent, then check if you got an underflow.
Re: Should you normalize RGB values by 255 or 256?
#29Interesting article. I tend to use - i = min(floor(f * 256), 255) (from float to uint8) - f = i / 255 (from uint8 to float) Basically a mix of the 2 approaches mentioned in the article. For all integers between [0,255], if I do uint8 -> float -> uint8 conversion, I will get the same result. -- edit: I wondered what's the maximum jitter amount that I can introduce to the float and get the same uint8 value. And also th…
This is what I do for the former:
floor( nextafter( 256, 255 ) * value )Re: Should you normalize RGB values by 255 or 256?
#30"Let’s say you’re writing an image processing program. The program takes in an image, converts it to floating point, does some processing and finally saves the modified pixels to disk as 8-bit colors. "
excuse to argue about the best way aside, if this is the goal you should not be rolling your own image file reading. you should use openimageio. idk what approach it takes in its internal conversion to float, but that library is more likely to have the right answer than you trying to roll it yourself given its the library used internally by tons of professional image manipulation software...