Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should you normalize RGB values by 255 or 256?

30fps.net

Post reply on HN
Print view View original

151–156 of 156 posts

Re: Should you normalize RGB values by 255 or 256?

#151

Post by jason_s »

fps-hero wrote: post #90

This was a genuinely thought provoking article. I had to challenge some personal assumptions. Coming from an electrical engineering background, I disagree with how the author presented "Two types of quantizers". Mathematically rigorous, but not grounded in practical systems. In ADCs, there is always an inherent +-1/2 LSB of quantisation uncertainty. The transfer characteristic is always mid-tread sampling, or at leas…

The datasheet specifications are largely standardized across ADC manufacturers and do not represent the exact mathematical norm but rather the range of ADC performances. So it's not that "the transfer characteristic is always mid-tread sampling" but rather that "the ideal model of the transfer characteristic is always X".

I do have some historical examples where mid-riser was used, but in practice it doesn't matter when you consider ADC variations and the variation of gain and offset are multiple counts. (8-bit or more; this exact definition would have been important for ADCs less than 8 bits.)

Re: Should you normalize RGB values by 255 or 256?

#152

Post by jason_s »

kroeckx wrote: post #111
fps-hero wrote: post #90

This was a genuinely thought provoking article. I had to challenge some personal assumptions. Coming from an electrical engineering background, I disagree with how the author presented "Two types of quantizers". Mathematically rigorous, but not grounded in practical systems. In ADCs, there is always an inherent +-1/2 LSB of quantisation uncertainty. The transfer characteristic is always mid-tread sampling, or at leas…

All ADCs I have looked at document that they can't represent the positive full scale. For instance, for an 8 bit ±1 V ADC, -128 represents -1 V, +127 represents 127/128=0.99219 V. The transition from 126 to 127 happens at 1.5 LSB from the positive full range. 1 LSB difference represents 1/128 = 0.00781 V difference, and not 2 / 255 = 0.00784 V. But if you actually care about what the voltage (and uncertainty) is, mos…

Largely those datasheets are poorly written... but in practice it doesn't matter much because the manufacturing variations of offset and gain error are larger than the quantization level.

Re: Should you normalize RGB values by 255 or 256?

#153

Post by [deleted] »

pixelesque wrote: post #47
Tuna-Fish wrote: post #38

Earlier quoted context omitted.

FP Division by constant is optimized by a compiler into a multiply. Graphics processing typically happens on the GPU these days, and on all recent GPUs FPMUL belongs to the class of lowest-latency operations. That is, there are no other instructions that complete faster.

Only with things like -ffast-math enabled will compilers do the reciprocal. It can make a fair difference in some cases, but it's often better to selectively use it in code locations you know are acceptable by doing it manually in the code.

[deleted]

Re: Should you normalize RGB values by 255 or 256?

#155

Post by jessetemp »

alterom wrote: post #142
jessetemp wrote: post #96

Earlier quoted context omitted.

Thank you for the thoughtful reply. Maybe bins is the wrong word to use, so I'll try with intervals. Starting with 1 bit data, there are two numbers and one interval. I think where bins makes it confusing is that inside the interval there are two big rounding errors mapping everything to either 0 or 1 and many people seem to be considering those the bins. Taking a step back, remember we're ultimately mapping these di…

>Maybe bins is the wrong word to use, so I'll try with intervals Same thing, in both how you use it and how the author does. >Taking a step back, remember we're ultimately mapping these discrete numbers to some real world continuous variable I think this is where you have a misconception. There are two maps. The important one goes the other way : FROM a continuous variable TO a finite set. It's not 1-to-1: it maps en…

I get it now. Had to play around with the code a bit to see it. Very interesting and unintuitive problem. Thanks for the thorough replies

Re: Should you normalize RGB values by 255 or 256?

#156

Post by glkindlmann »

mark-r wrote: post #149
glkindlmann wrote: post #114

This is like a 1D version of what a scientific computing person might describe as the distinction between node-centered ("standard" or "mid-tread" in this post) vs cell-centered ("alternative", "mid-riser") samples: do consider values to be at the middles of bins (or middles of triangles, or middle of tetrahedra), or the boundaries between intervals (or vertices of triangles, or of tets). In a scientific computing se…

In 8-bit (per channel) color there is a standard for when the context is unspecified: sRGB. It was developed to match the characteristics of a "typical" display at the time of its creation. It won't be 100% accurate, but it represents the best you can assume. You're not forced to throw up your hands and give up.

I see that https://en.wikipedia.org/wiki/SRGB#Translation_to_integers implies what I would call node-centered sampling ("standard" or "mid-tread" in the post), but are you aware of sRGB documentation that precisely specifies the quantization semantics?

Most of what I've read about sRGB focuses on the semantics of continuous (floating-point) R,G,B channels.

Post reply on HN