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

121–130 of 156 posts

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

#121

Post by account42 »

londons_explore wrote: post #108
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…

Dithering in time seems like the best solution to this problem. Delta sigma modulation per pixel can be done reasonably easily. Changing at 30Hz I doubt a human can tell the difference between slightly blue and slightly yellow.

This is called frame rate control (FRC) in display terminology, at least when used for LCD displays where the panel has fewer distinct levels than the manufacturer wants to advertise.

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

#122

Post by account42 »

yxhuvud wrote: post #8
herf wrote: post #4

I'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…

Both solutions add 0.5, the difference is where in the process it happens.

They don't - trunc(result * 255 + 0.5) is just round(result * 255), i.e. error is on average 0 whereas trunc(result * 256) has an average bias of -0.5.

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

#123

Post by account42 »

herf wrote: post #4

I'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…

> For example, broadcast systems historically used 16-235 as their luminance range for SDR.

Unfortunately "modern" HDMI is still plagued by this insanity so if your display and source don't agree you can either get washed out or crushed blacks.

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

#124

Post by account42 »

exyi wrote: post #40
lacedeconstruct wrote: post #27

Earlier quoted context omitted.

The difference between 20 cycles and 1 clock cycle in a hot loop is very noticeable

It's 3 cycles for float multiplication (and 1 for shift right): https://uops.info/table.html?search=mulss&cb_lat=on&cb_tp=on... https://uops.info/table.html?search=shr&cb_lat=on&cb_tp=on&c... In throughput it's even less of a difference: 2 per cycle vs 3 per cycle.

Shift right isn't even relevant here - if you shift before conversion to float all your values end up 0 and if you want to divide afterwards its no longer a simple shift.

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

#125

Post by account42 »

tshaddox wrote: post #105
simonask wrote: post #66

Earlier quoted context omitted.

For the record, the mathematically correct answer to this question is that the year 2000 was the last year of the 19th century. The reason is that year 0 never existed. The year 1 BCE was followed by the year 1 CE. Culturally, anthropologically, and psychologically it might be a different matter. But 2000 years had not passed before the end of that year.

What makes this argument less compelling is that “year 1 AD” also didn’t exist at the time , and this isn’t a great reason to abandon the arithmetically sane approach of zero-indexed year numbering. The calendar was back-dated 500 or so years after Jesus, by a European guy before Europe had the concept of zero, leaving us with 1-indexed years. Then, 200 or so years after that, another guy (still lacking the concept o…

We could also just define that 0 AD = 1 BC and don't have to rewrite any BC dates.

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

#126

Post by account42 »

MyMemoryfails wrote: post #94

As game dev, i never understood why floats are used to present colors? Isn't integers better? The issues which this article mentioned wouldn't exist. I can only think its due integers having undefined behavior what happens on overflow, usually its wrapping but not always.

The problem would still exist, for example when you want to multiply colors which is common in lighting calculations - with integers you would need to divide by either 255 or 256 after such an operation. Which floats you only need to make that decision when converting to/from float representation, which is part of what makes them convenient.

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

#127

Post by jyounker »

From an algebraic standpoint, the answer is clearly f(x) -> [0, 255].

If you don't have f(n * 0) == n * f(0), then all sorts of weird stuff happens, like:

For f(x) -> [0, 255] then f(0) + f(0) + f(0) = 0 + 0 + 0 = 0 = f(0)

For f(x) -> [0.5/8,7.5/8] then f(0) + f(0) + f(0) = 0.5/8 + 0.5/8 + 0.5/8 = 1.5/8 != f(0)

Choosing the latter means that if you do a calculation on the x side, then you can't expect it to match the calculation on the f(x) side.

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

#129

Post by jorvi »

account42 wrote: post #121
londons_explore wrote: post #108

Earlier quoted context omitted.

Dithering in time seems like the best solution to this problem. Delta sigma modulation per pixel can be done reasonably easily. Changing at 30Hz I doubt a human can tell the difference between slightly blue and slightly yellow.

This is called frame rate control (FRC) in display terminology, at least when used for LCD displays where the panel has fewer distinct levels than the manufacturer wants to advertise.

PWM and FRC aka headache generators deluxe
Post reply on HN