4 ms·

The larger the dynamic range, the more bits you need to represent the possible values in between. Imagine a gradient that smoothly transitions from black to wh

The larger the dynamic range, the more bits you need to represent the possible values in between. Imagine a gradient that smoothly transitions from black to white. 8 bit color means only 256 shades of luminance, which would quickly show banding artifacts. In fact, the entire reason we gamma encode images is because 256 is too small for even a low dynamic range monitor. Gamma encoding is a clever technique to give us more bits to represent shadows, which humans are more sensitive to than highlights.

ttoinou 9y ago
I think O.P. understand that since he wrote "You can encode a range using any number of bits you want, but if you use fewer bits the resolution within may be lower.", applying a curve solves high dynamic range but lowers the resolution
deleted 9y ago
[deleted]
chrisseaton 9y ago
Right, but the contrast range 1:1,000,000 - that's a real range isn't it? Not an integral one? So why does it ideally need to be represented with a particular quantisation of 1,000,000 different states? I mean there's not 1,000,000 different values between the real numbers 1 and 1,000,000 are there? There's an infinite number. There's only 1,000,000 values (20 bits) if you decide to quantise on each integer. Why do you need to do that? Why not more? Or less? What's special about the integral values on the number line?
- ttoinou 9y ago
  Because 1 defines the lowest value you want to see. 20 bit is the minimum number of bits you need (in linear light) if you don't want noise in the darkest parts of your image
  - chrisseaton 9y ago
    There are an infinite number of luminance levels between a contrast of 1 to 1,000,000, right? You will need 20 bits if a human can distinguish 1,000,000 levels between those two extremes. Is that the case? Maybe a human can distinguish 2,000,000 levels between 1 and 1,000,000, in which case you would need 21 bits. You can't take a real range and give a number of bits needed to represent it without also stating what resolution you need. And I think it's unlikely that the resolution that a human can perceive is coincidentally the same as the factor of one extreme to the other.
    - ttoinou 9y ago
      I think you are right about the "infinite scale" thing but also that the bit count is correct up to a multiplication coefficient, given a specific resolution you are trying to achieve. To put it in mathematical terms, there is no reason to use the log base 2, but the formulae is definitely a logarithm. So, again, 20 bits is a minimum bit count conveniently used to compare with others situation (e.g. "if you are shooting not in direct sunlight, you will only need 12 bit minimum, not 20 bit minimum so this method of shooting is OK") and make decision about your color pipeline You will need 20 bits if a human can distinguish 1,000,000 levels between those two extremes It's not about what we can perceive but how we store and manipulate amount of lights in our pipelines
    - Promit 9y ago
      This was certainly not meant to be a crucial piece of information, but sure, let's get into it. Much of the post comes from a general assumption that the goal of computer graphics is primarily to replicate how a camera sees the world around it. Thus I think it's easiest to start from the idea of real world light entering a digital image sensor. Light in this setting is not continuous! Each subpixel in an image sensor acts as a photon counter. One photon hits the sensor, the count ticks up by one. There's no question of being able to perceive the values between 1 and 2 because they don't even exist. Either the sensor counted one photon or two. If you were going to literally create a digital camera that can process the entire world, you need 20 bits to count up to a million photons without losing any along the way. So if you were to build the hypothetical rendering pipeline that works on "real world" data about the scene, that 20 bit value would be the input. As a practical matter, nearly all modern games store lighting levels internally in floating point, in arbitrary units chosen by the developers. Lighting pipelines are not integer based, but they're linear and not perceptual. The conversion to perceptual 8 bit (gamma curve) happens as part of the tone map stage. Doing things in floating point physical units is a better idea than the photon counter anyway, but the line you're confused about was really written with idealized cameras in mind. (Technically an image sensor is an analog device and the voltage increases with each photon detection by an increment that is subject to noise of all sorts and pre-amplification before hitting ADC. Don't jump me on the photon counter thing.)
tripzilch 9y ago
> Imagine a gradient that smoothly transitions from black to white. 8 bit color means only 256 shades of luminance, which would quickly show banding artifacts. Only if you don't dither. Which is like free bits of precision given today's monitors resolutions. I don't disagree with the rest of your point (although I do believe that just because there's a 20-bit dynamic range one should represent it by 20 bits of precision that's an arbitrary choice) (not even the best choice, IMO). Just want to emphasize that, a statement being made all over this thread, that "less bits = you gonna get banding", just means you're doing it wrong, thinking about it wrong, and might therefore even end up with banding if you had enough bits but wasted them at some point in the pipeline.

ttoinou 9y ago

I think O.P. understand that since he wrote "You can encode a range using any number of bits you want, but if you use fewer bits the resolution within may be lower.", applying a curve solves high dynamic range but lowers the resolution

deleted 9y ago

[deleted]

chrisseaton 9y ago

Right, but the contrast range 1:1,000,000 - that's a real range isn't it? Not an integral one? So why does it ideally need to be represented with a particular quantisation of 1,000,000 different states? I mean there's not 1,000,000 different values between the real numbers 1 and 1,000,000 are there? There's an infinite number. There's only 1,000,000 values (20 bits) if you decide to quantise on each integer. Why do you need to do that? Why not more? Or less? What's special about the integral values on the number line?

ttoinou 9y ago
Because 1 defines the lowest value you want to see. 20 bit is the minimum number of bits you need (in linear light) if you don't want noise in the darkest parts of your image
- chrisseaton 9y ago
  There are an infinite number of luminance levels between a contrast of 1 to 1,000,000, right? You will need 20 bits if a human can distinguish 1,000,000 levels between those two extremes. Is that the case? Maybe a human can distinguish 2,000,000 levels between 1 and 1,000,000, in which case you would need 21 bits. You can't take a real range and give a number of bits needed to represent it without also stating what resolution you need. And I think it's unlikely that the resolution that a human can perceive is coincidentally the same as the factor of one extreme to the other.
  - ttoinou 9y ago
    I think you are right about the "infinite scale" thing but also that the bit count is correct up to a multiplication coefficient, given a specific resolution you are trying to achieve. To put it in mathematical terms, there is no reason to use the log base 2, but the formulae is definitely a logarithm. So, again, 20 bits is a minimum bit count conveniently used to compare with others situation (e.g. "if you are shooting not in direct sunlight, you will only need 12 bit minimum, not 20 bit minimum so this method of shooting is OK") and make decision about your color pipeline You will need 20 bits if a human can distinguish 1,000,000 levels between those two extremes It's not about what we can perceive but how we store and manipulate amount of lights in our pipelines
  - Promit 9y ago
    This was certainly not meant to be a crucial piece of information, but sure, let's get into it. Much of the post comes from a general assumption that the goal of computer graphics is primarily to replicate how a camera sees the world around it. Thus I think it's easiest to start from the idea of real world light entering a digital image sensor. Light in this setting is not continuous! Each subpixel in an image sensor acts as a photon counter. One photon hits the sensor, the count ticks up by one. There's no question of being able to perceive the values between 1 and 2 because they don't even exist. Either the sensor counted one photon or two. If you were going to literally create a digital camera that can process the entire world, you need 20 bits to count up to a million photons without losing any along the way. So if you were to build the hypothetical rendering pipeline that works on "real world" data about the scene, that 20 bit value would be the input. As a practical matter, nearly all modern games store lighting levels internally in floating point, in arbitrary units chosen by the developers. Lighting pipelines are not integer based, but they're linear and not perceptual. The conversion to perceptual 8 bit (gamma curve) happens as part of the tone map stage. Doing things in floating point physical units is a better idea than the photon counter anyway, but the line you're confused about was really written with idealized cameras in mind. (Technically an image sensor is an analog device and the voltage increases with each photon detection by an increment that is subject to noise of all sorts and pre-amplification before hitting ADC. Don't jump me on the photon counter thing.)

tripzilch 9y ago

> Imagine a gradient that smoothly transitions from black to white. 8 bit color means only 256 shades of luminance, which would quickly show banding artifacts. Only if you don't dither. Which is like free bits of precision given today's monitors resolutions. I don't disagree with the rest of your point (although I do believe that just because there's a 20-bit dynamic range one should represent it by 20 bits of precision that's an arbitrary choice) (not even the best choice, IMO). Just want to emphasize that, a statement being made all over this thread, that "less bits = you gonna get banding", just means you're doing it wrong, thinking about it wrong, and might therefore even end up with banding if you had enough bits but wasted them at some point in the pipeline.