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

111–120 of 156 posts

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

#111

Post by kroeckx »

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, most of this is difference is mostly pointless, you're reference will have a bias, there are linearity errors and so on. 1 LSB will not match either the 1/128 or 2/255, you will need parameters to compensate for it.

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

#113

Post by virtualritz »

lacedeconstruct wrote: post #19
dist-epoch wrote: post #15

Earlier 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,…

And both are wrong since the values would have to be in a linear color space for for the compositing math to make sense. But in some non-linear space to be useful when mapped to 0..255 (e.g non-linear sRGB).

Which happens right after the Porter-Duff Over operator above -- a smoking gun. Which one is it gonna be?

I.e. the display transform is omitted from this and the math involved with the latter makes your whole argument moot.

It can't be expressed well enough with bitshifts to keep your purported 10x speedup anyway (and which I strongly doubt btw).

And lastly: in a software renderer that stuff is usually P.S.: I'm speaking from 30 years of experience with software rendering in the context of VFX.

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

#114

Post by glkindlmann »

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 setting it would be insane to start doing data processing without knowing how to interpret the values. In the context of audio signal processing, if you just get a stream of integers, you'd have to know the representational intent of those integers (mu-law encoding or linear?) if you're going to compute anything about the underlying signal. The meta-data accompanying the values would hopefully provide the answer.

But with 8-bit pixel values, absent any meta-data from a competent file format that can communicate the representational intent, we're adrift and there's no right answer (like the author says). Certainly no one can fault you for picking whichever one seems to be give better results for your application, but you can raise awareness that bits without context have had their meaning undermined.

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

#115

Post by virtualritz »

255.0. Everything else makes no sense and is actually dangerous when working with colors. Trust me. :)

And when you go from float to 8bit you should dither to avoid banding.

If in doubt, error diffusion with a random number between -0.5..=0.5 is fine. 0.5 here is dither_amplitude:

round(255 * input_value + dither_amplitude * random(-1, 1))

See e.g. my dithereens crate: https://crates.io/crates/dithereens

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

#117

Post by spider-mario »

chongli wrote: post #83
moefh wrote: post #65

This problem of what exactly a color value means is mostly inconsequential when you have 8 bits per component, the difference in the denominator being either 255 or 256 makes the errors tiny, you must have really good color perception and get really close to the screen to see any difference at all, and your monitor/phone screen is probably not calibrated anyway, so who cares. It becomes a pain in the ass when you're…

You forgot about gamma correction. Before converting a value in the range of 0-255 into a voltage, PCs typically raise that value to the power of 2.2. This makes the difference between small values and large values far more apparent: 2^2.2 = 4.595, 255^2.2 = 196,964.699

Differences between small and large values are irrelevant to the point being made here, though. Much more relevant is the difference between nearby values, and the gamma just gets that closer to logarithmic perception, instead of perceptual steps being disproportionately large for small values.

(This may be more apparent when you frame gamma as being applied in the 0-1 range, so it doesn’t really turn 2 into 4.595 and 255 into ~200k; it turns (2/255)≈0.00784 into (2/255)^2.2 ≈ 0.0000233, and leaves (255/255)=1 as is.)

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

#118

Post by spider-mario »

lacedeconstruct wrote: post #24
dist-epoch wrote: post #20

Earlier quoted context omitted.

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

Better than what? And do you use `-mavx2` or do you let it target baseline x86_64 and miss out on 8-float vectors? How do you make sure its autovectorisation is successful?

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

#119

Post by smallstepforman »

BearOso wrote: post #80

There is a fallacy here in assuming there's 256 steps from 0 to 255. That's not true, there's 256 values that can be represented in 8 bits, and 255 steps (spaces between those values) from 0 (black) to (255) pure white. Thus, the division by 255 isn't problematic. Of course, 128 isn't half grey, it isn't in 0-255 and quantized 8-bit values are almost always in sRGB, not linear perceptive space. This is the same kind…

BeOS API is based on pixel centers, not that anyone cares anymore …

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

#120

Post by imtringued »

lacedeconstruct wrote: post #19
dist-epoch wrote: post #15

Earlier 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,…

How is this supposed to be 10x faster if all you did was drop one out of three multiplications?
Post reply on HN