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

131–140 of 156 posts

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

#131

Post by jnovacho »

jrmg wrote: post #87
jessetemp wrote: post #58

Earlier quoted context omitted.

By counting the edges

I see what you’re saying - index 0 holds values from 0-1, index 2 from 1-2 etc, but then you have index 255 holding values between 255 and 256. So you’re sort of arguing that the 0-255 8-bit quantization is actually representing ‘real’ values of 0-256?… Edit: somehow missed alterom’s reply - they explain it much better than my question above does.

> index 0 holds values from 0-1, index 2 from 1-2 etc,

Well, now you are double counting the end values of the ranges. In your example 1 is included in both 0-1 and 1-2.

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

#132

Post by exyi »

account42 wrote: post #124
exyi wrote: post #40

Earlier quoted context omitted.

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.

Exactly. Although if you do >> 8 while working with uint8, it will be the fastest :)

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

#133

Post by dpark »

klodolph wrote: post #91
dpark wrote: post #86

Earlier quoted context omitted.

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.

You’re still misinterpreting what I proposed. I didn’t propose a +0.5 debias at all. I proposed that the bias is removed by scaling. In this case you divide by 255.0 but multiply by 256.

But again, the likely reason no one does this is because it introduces a bias in the other direction, toward 255.

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

#134

Post by davidkwast »

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…

Your comment remembered me of ESA normalization value for the Sentinel-2 level-2 satellite image quantization.

Something like this:

Digital Number DN=0 remains the “NO_DATA” value

For a given DN in [1; 1;215-1], the L2A SR reflectance value will be:

L2A_SRi = (L2A_DNi + BOA_ADD_OFFSETi) / QUANTIFICATION_VALUE

https://sentiwiki.copernicus.eu/web/s2-products

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

#135

Post by jessetemp »

jrmg wrote: post #87
jessetemp wrote: post #58

Earlier quoted context omitted.

By counting the edges

I see what you’re saying - index 0 holds values from 0-1, index 2 from 1-2 etc, but then you have index 255 holding values between 255 and 256. So you’re sort of arguing that the 0-255 8-bit quantization is actually representing ‘real’ values of 0-256?… Edit: somehow missed alterom’s reply - they explain it much better than my question above does.

Not quite. I'm saying there are 256 discrete numbers (0-255) and 255 intervals between those numbers. Most of the real values will fall into the intervals and get mapped to 0-255 somehow, maybe by nearest neighbor, but I'm not trying to define how they get mapped. The point is that 255 is the largest number that can be represented with 8 bits, so you should normalize by 255.

I wrote a longer replay to alterom but it looks buried for some reason.

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

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

#137

Post by HelloNurse »

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…

> Remember how the 0 and 255 bins poked slightly beyond the [0,1][0,1] range’s edges? In the standard approach, the range of representable values is actually [−0.5/255,255.5/255][−0.5/255,255.5/255], meaning the bins are spaced further apart than strictly needed for [0,1][0,1] inputs

This is of course silly: the "range of representable values" of floating point colour components is [0,1] independent of quantization and how an invalid input would be quantized is irrelevant.

Looking at the actual "big picture" there are 256 representable values and (taking into account gamma correction, arbitrary ranges other than [0,1], deliberately nonuniform quantization bins, and other plausible complications) their correspondence to 256 floating point values should be regarded as a generic lookup table, abandoning all hope of using elegant and cheap formulas and making it obvious than encoding and decoding differently is not an option.

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

#138

Post by 1xn »

smallstepforman wrote: post #119
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 …

I care! :-)

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

#139

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. Compare these two:

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

  For f(x) -> [0.5/8,7.5/8] then f(0) + f(0) + f(0) = 3 * 0.5/8 = 1.5/8
Choosing f(x) -> [0, 255] means that if you do a calculation on the x side and you do the same calculation on the f(x) side, then you'll get the same result when you convert from one to the other.

Choosing f(x) -> [0.5/8,7.5/8] breaks the algebraic correspondence.

Post reply on HN