Live data from Hacker News

Should you normalize RGB values by 255 or 256?

30fps.net

101–110 of 156 posts

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

#101
Dammit, I have an 80%-written article covering the same issue but for ADCs, and had to put it aside for the past few months. There's historical precedent here from the 1960s and 1970s, and in large part it involves testing and definitions of gain and offset error in ADCs.

Someday I'll finish... :-(

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

#103
post #42
post #3

If 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.

I'm confused by that analogy. Is the “ruler” a 255-inch ruler with 256 points labeled 0–255, or is it a 256-inch ruler with 256 1-inch segments, making L = 256×1?

The analogy is pretty straightforward.

When you have a 12 inch ruler, you effectively have 13 numbers on the ruler. The fact that zero isn't marked is neither here nor there -- the numeral one is not at the far end of the ruler.

So if you extend the ruler to be as long as you can hold in eight bits, it will range from 0 to 255, and the total length will be 255.

The ruler analogy may seem overly simplistic, but then the real world is likewise fairly simplistic.

At the end of the day, the numbers presumably come from a sensor, or go to a display, and, often, in either case, zero represents as dark as you can get and 255 represents as light as you can get, so the physics dictate that the intervals associated with the 0 and 255 are half the size of the rest of the intervals.

Audio is more interesting than video, because in audio, you care deeply about not having an offset, and about having a balanced signal, so the question of whether the midpoint is actually on a number or not is pertinent.

In audio, it is often useful to simply discard a code so that 0 is the midpoint (e.g -65535 to +65535, discarding 0xFFFF). But this still gives you smaller intervals at both ends.

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

#105

Earlier quoted context omitted.

It's right up there with the confusion if 2000 was the new year of the 21st century or the last year of the 19th century.

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 of zero) made the even less venerable decision that the year right before 1 AD would be 1 BC.

We could just decide today that 0 came right before 1 AD and was the first year of the first century AD. Then we’d just have to shift all BC dates by 1 year in all our history books.

The upside would be that arithmetic on year labels starts working again. The downside is that there are way too many history books and no one will ever do this.

Of course, the easier way out is to just decide today that either 1) the first century began in 1 BC or 2) the first century had 1 fewer year than all the other centuries.

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

#108
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.

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

#109
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…

> That means you don't get to see any pure grays -- the closest ones will have bit of blue or yellow tint, depending on the direction of the difference. OMG I remember as a kid staring at static-y CRT displays, and seeing these faint blue and yellow lines at the borders of them. I’d always wondered why they appeared and why they were specifically blue and yellow. I finally know! (at least, assuming those specific art…

specifically on the edges? I would guess that is the phosphor layout, that the 'gray' beam is hitting a blue phosphor but not the red & green, or vice-versa.

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

#110
See: cbloom's rant on quantization for deeper investigation: https://cbloomrants.blogspot.com/2020/09/topics-in-quantizat...

"While in theory there are cases where you might want to use either type of quantization, if you are in games don't do that!

The reason is that the GPU standard for UNORM colors has chosen "centered" quantization, so you should do that too."

Post reply on HN