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

91–100 of 156 posts

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

#91

Post by klodolph »

dpark wrote: post #86
klodolph wrote: post #79

Earlier quoted context omitted.

> Why not scale to fill the available bins, though? i.e. trunc(result * 255.999)? That’s half of the mid-riser staircase quantizer discussed in the article. (The other half is coming up with the reverse.) (I would implement it as min(floor(x * 256), 255).)

Kind of. According to the article, the mid-riser vs mid-tread distinction correlates to where the 0.5 is applied in the transform. I’m proposing that there is no 0.5 applied at all. Instead of counteracting the compression of the truncation operation by adding a fixed offset, it multiplies by a scale factor. Possibly my proposal doesn’t hold up to repeated transforms and operations. It might skew toward 255 in real o…

The 0.5 comes from debiasing the round-trip.

If your conversion from high precision -> 8-bit is just multiplication by 256 and then truncation, then you’ve got the mid-riser quantizer. The +0.5 comes from interpreting a value of 0 as bucket from 0-1, just like the value of 255 is the bucket from 255-256. It’s introduced in the conversion back from 8-bit to high precision.

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

#92

Post by tdeck »

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…

> Notice how none of the blue voltages match any of the red/green ones (other than the extremes)? That means you don't get to see any pure grays

I assume this is why RGBI color was so common in the 80s.

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

#93

Post by userbinator »

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.

It's 3 cycles for float multiplication (and 1 for shift right):

3x faster

In throughput it's even less of a difference: 2 per cycle vs 3 per cycle.

50% faster

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

#94

Post by MyMemoryfails »

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.

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

#95

Post by dylan604 »

variaga wrote: post #72
dylan604 wrote: post #54

Earlier quoted context omitted.

> broadcast systems historically used 16-235 For 8-bit, 16 maps to 7.5IRE which is the well understood legal black. Mapping 235 means they mapped peak to 110IRE. This is based on a 0-120IRE scale. This gets weird as the broadcast limit for video was 100IRE allowing for the chroma to reach 110IRE. So if you're trying to limit your white values to 235, that'll be higher than is broadcast safe. Of course, nobody cares a…

Ugh. Sudden flashbacks to having to switch analog output between Japanese NTSC (no pedestal) and US NTSC (with pedestal) without getting weird noise in the black regions. But IIRC the MPEG-2 standard had luma==235 -> 100IRE for all of the analog formats (pal/ntsc-j/ntsc/secam) so I'm not sure why you say that would violate the broadcast limits?

Simply because the math works that 7.5IRE on a 120IRE scale maps to 16 8-bit that 110IRE maps itself to 235 8-bit on a simple scaling equation. To get 235 8-bit to match to 100IRE means some sort of exponential scaling. At that point, I stuck with the linear scale and moved on with the keep it simple stupid mindset

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

#96

Post by jessetemp »

alterom wrote: post #81
jessetemp wrote: post #48

The author is confusing bins with bin edges. In their first plot, the standard approach looks strange because 0-7 should be the bin edges, not the center points as shown in the plot. You can see this confusion again in the histogram example. There are only 255 bins, not 256. If you fix that mistake and remove the 0.5 offset, then the histogram is distributed correctly at both ends.

Sorry, you seem to be confused. >There are only 255 bins, not 256 There are 256 bins because there are 256 values. The questions are: 1. What are the boundaries of these bins? 2. Which sample represents a particular bin? With 1-bit color, we have sample values {0, 1}. What bins do they represent? Here's one choice: [0, 1), [1, 2) Two equally sized bins, spanning the interval [0, 2] of length 2, each defined by its sa…

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 discrete numbers to some real world continuous variable like the saturation of red, frequency, mass on a scale, whatever. And our digital device can only represent a finite amount of numbers. For 2 bit data, we can represent 0-3, and for 3 bit data we can represent 0-7.

The important part is that 0 represents the minimum and 1,3, and 7 all represent the same maximum real value, and everything that can be measured by the device will fall within those ranges. So comparing 1, 2 and 3 bit data on a linear number line looks like this:

  0                    1
  0      1      2      3
  0  1  2  3  4  5  6  7
You could assume that everything gets assigned to whatever number is nearest in the number scale or come up with another scheme, but that is ultimately defined by the ADC and likely nonlinear. All we know is that those are the numbers we have available to represent the real values we're measuring.

The question is about how to normalize the data. 1 bit data is already normalized. If you normalize 2 bit data by 3 you get [0, 1/3, 2/3, 1]. LGTM. If you normalize it by 4, you get [0, 1/4, 2/4, 3/4] and you're effectively throwing away some of the range of the ADC. You can try to get it back by offsetting by 0.5 then normalizing but now you get [1/8, 3/8, 5/8, 7/8]. And you could stretch that with some clever formula to fill from 0 to 1, but if you do it right then it's the equivalent to normalizing by 3, so why not normalize by 3?

So the answer is, if you have N bit data, you normalize by 2^N-1.

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

#97

Post by jessetemp »

pornel wrote: post #60
jessetemp wrote: post #48

The author is confusing bins with bin edges. In their first plot, the standard approach looks strange because 0-7 should be the bin edges, not the center points as shown in the plot. You can see this confusion again in the histogram example. There are only 255 bins, not 256. If you fix that mistake and remove the 0.5 offset, then the histogram is distributed correctly at both ends.

No, the author understands the problem way deeper than you do. You haven't grasped the fact that the choice isn't obvious, and has subtle trade-offs. If you don't believe the author, check the other posts he references.

Judging by your other comment in this thread, you might agree with my rational [1] more than you realize

[1] https://news.ycombinator.com/item?id=48365800

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

#98

Post by sheept »

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.

Floats are better for calculating lighting. I would think some GPUs are probably also more optimized for float processing than ints.

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

#99

Post by somat »

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.

It is because light(colors) is a fundamentally exponential process and floats are also a fundamentally exponential process and as such the two are a good match for one another.

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

#100

Post by yuriks »

pixelesque wrote: post #43
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…

As someone with a lot of experience in this area doing image processing and rendering for VFX (including writing image readers and writers for my own software and commercial VFX software), I think you might be forgetting that colourspace conversion (to sRGB 'linear' rec709 for old-school SDR, but other more wider gamuts for newer formats) would happen after this, so the 'squish' of the dynamic range would happen afte…

I think more to the point, if 0 doesn't represent 0.0, and 255 doesn't represent 1.0, congratulations you've just lost your additive and multiplicative identities and most of the math used in colors falls apart.

The argument for 0-256 feels compelling when thinking about the physical display, but it seems like a very poor fit for any digital image processing or rendering.

Post reply on HN