Hacker News Reader

I'm not sure this is a constructive comment, but I just wanted to say that you are completely correct, everyone else is crazy, and I am baffled at how much confusion there seems to be over this topic.

One thing to add: Wikipedia sayeth "the eye senses brightness approximately logarithmically over a moderate range". If we go with that, then you presumably want to encode brightness logarithmically, and the number of bits you have available will determine the ratio between your adjacent quantized levels. In that case I believe the ratio between adjacent levels would be exp(ln(max_range_ratio)/(2^bits)).

That's why even the good old 8 bits per channel images are encoded logarithmically. Enter the gamma curve: https://en.wikipedia.org/wiki/Gamma_correction

no - the REASON why we use gamma is deeply historical and has essentially to do with trying to build TV receivers with the minimum number of vacuum tubes

Is it just a coincidence that the gamma curve also corresponds roughly to our eyes response to light? Awfully lucky if it was.

You don't want to encode brightness perceptually until you're showing it to the user. You need a linear space to actually do lighting calculations, which means physical luminance values. Within that space, you can use whatever scale you wish, with consequences to banding and quantization artifacts for decimating the bit depth. Tone mapping includes conversion to a log space via the gamma curve.

I explained it in another comment but basically the "20 bit" value is based on an idealized digital image sensor rather than a game rendering pipeline (which operates in floating point). It has admittedly proven somewhat confusing.

It's worth noting explicitly that floating point numbers let you have a linear scale but logarithmic-ish storage at the same time. A 12-bit float could represent a 1:1000000 range, let you perform normal linear math, and also be just as banding-free as a 20 bit integer.

To be honest I think everyone else is crazy and/or doing a calculation without thinking about what it means.

All we know is that the range is N to 1000000N, but we do not know in and of itself that N is the smallest delta perceivable or possible.

Well since at least one person thinks I'm not crazy I'll stop trying to argue now - thanks!

I think you're making sense.

I don't know anything about games but at least in cameras the relation you want between the bit depth and dynamic range is determined by what you want to measure rather than a formula. An eye tracker I have is a 10-bit IR camera because a normal 8 bits are insufficient to both note that IR LED reflections are way brighter than everything else, while also having sufficient detail in the lower values that the edges of the pupil are easy to detect. At least, without having the scale be logarithmic or discontinuous or otherwise compressed.

You are correct. Luminance is a real number not integer so the more bits the better (unless you go all they way down to photons!). So, more bits allow us to increase the dynamic range and also allow more values in that dynamic range.

The real benefit of HDR is in the "more values" part since, as the author notes, our displays have a very limited dynamic range anyway.

Yes. I'm leaning towards a "didn't really think it through" oversight on the author's part, rather than fundamentally confusing signal-to-noise ratio (which is what more bits give you, if you treat em right) with numerical range.

Hell, I like to think I'm somewhat knowledgeable about these things and I read straight past that line thinking "that's a million, that's about twenty bits, okay".

But you are absolutely right, now that you pointed it out it's obvious.

And indeed you can get the same range using only one bit (per channel, that is) and if you had high enough (very high) resolution and proper dithering, you'd totally get away with it, too. In that case, the tonemapping goes just before the dithering.

The straight to the point answer is yes, you can use less bits to encode the same range, though for practical matters you'll get strong banding as a result. That is because the log curve applied to make the range viewable on a screen will stretch the lowest part of the range. Moreover, the multiple passes made in the linear (wide) range will produce artifacts viewable in screen space much more quickly.

The only negative result you're certain to get and can't avoid is a low signal-to-noise ratio. You only get banding (unwanted spatial artifacts) if you do it badly (without dither).

To express a ratio of 1000000:1, you need at least 20bits. I think that's all the article is saying, and that far more bits than the current contrast ratio that is supported--essentially show that we're far off from supporting actual contrast ratios.

I didn't interpret the articles premise that if you had 20 bits, you could 100% reproduce the light in a scene.

Sorry I still don't get it :)

> To express a ratio of 1000000:1, you need at least 20 bits.

You mean to express all the integer factors in the range 1000000:1, you need at least 20 bits. With 20 bits you can represent 1 times brighter, 2 times brighter ... 1000000 times brighter.

But there's nothing special about those coefficients. 20 bits does not allow you to represent 1.5 times brighter. That's still in the range 1000000:1 but 20 bits isn't enough to represent it.

If we're happy to skip 1.5 times brighter, why can't we skip all the even integer times brighter values, and use 19 bits?

> If we're happy to skip 1.5 times brighter, why can't we skip all the even integer times brighter values, and use 19 bits?

Things get wonky if you don't have a linear scale with a true zero; in such a scale the low end of your N:1 contrast ratio (in the smallest representation) has a value of 1, and the high end has a value of N.

Hmm… but the actual display’s representation of 0 cannot be darker than the minimum brightness value it supports. If 1 really is 1x the minimum, then 0 and 1 have to be displayed identically. But then your scale isn’t even linear, nor does it have a true zero. How does that help?

edit: And aren’t output color spaces already highly nonlinear due to gamma correction?

0 is the lowest and x-1 is the highest for a ratio of 1:x. It’s 1 all the way to x; You just subtract one because computers start counting from 0

But in that case, skipping "even integer times brighter values" wouldn't exclude 0 - because 0 is 1x brighter, an odd integer.

Is that the reason you can’t just chop off the two least significant bits when converting from 10-bit to 8-bit?

Good thing in real life there's no such thing as truly zero photons, then (which is a detail the article actually shortly touches upon).

Also, if that type of "wonky" throws off your rendering pipeline, you're bound to get something else wrong.

Such as ever having a linear scale with a small number of bits in your pipeline. The linear scaled brightness stays afloat all the way through (cause floats have this handy feature of being transparently sorta-logarithmic in the way they use their bits, even 16-bit floats beat 20-bit ints for that purpose), only at the very end you apply the tonemap+gamma function(s), then dither, then truncate to fixed (8) bit integer.

> To express a ratio of 1000000:1, you need at least 20bits.

You only need 1 bit if you declare an encoding scheme where 1 == 1 million. You need 20 bits to define 1 million DIFFERENT luminances. Their ratio is subject to an arbitrary scaling.