4 ms·

I don't really know intimately about this but it seems to me that the ever-problematic gamma is one of the problems whose solutions should lie in the realm of h

by yason 16y ago

I don't really know intimately about this but it seems to me that the ever-problematic gamma is one of the problems whose solutions should lie in the realm of hardware instead of software. Why couldn't we have graphics cards, monitors, printers, cameras, camcorders and other devices that perform mapping from linear values to exponential values (or vice versa)? Then linear scale would be the standard and all software could continue to live on the nice and comfortable illusion that 127 is half the brightness of 255 and everyone would be happy. It's just that when a pixel of value 127 was shown on the screen it would actually show up as what we currently get from 180 or so.

wmf 16y ago
An 8-bit linear value probably wouldn't give adequate dynamic range (this is the same reason 8-bit audio isn't linear AFAIK), so you'd have to use 16-bit linear which would make all images twice as large. It would probably be an acceptable solution today, but not back in 1995.
reitzensteinm 16y ago
Wouldn't that result in a loss of precision at the lower end?
- yason 16y ago
  Doesn't that happen anyway, no matter which way we're doing it? Currently, if 180 out of 256 is half then we have considerably fewer values representing the highest intensities than the darkest intensities. So, in effect we currently "waste" values by allocating lots of them for darker values that mostly seem all the same on the screen. If we could program on the linear scale, it would depend on the hardware that how accurately the linear scale would be mapped to the voltages that would give linear intensity levels in reality. You can add bits per channel if you want more precision, that's what we do already.
  - jacobolus 16y ago
    No. Intensity varies (roughly) proportionally with voltage, and where it doesn’t displays have built-in lookup tables which correct for any nonlinearity. Human lightness response though is a complex non-linear response that depends on the viewing conditions and the particular observer. There’s a not great description at http://en.wikipedia.org/wiki/Lightness_(color) http://en.wikipedia.org/wiki/Lightness_(color)
    - ssp 16y ago
      Human lightness response though is a complex non-linear response that depends on the viewing conditions and the particular observer. This is why I'm not convinced that the right solution is simply filtering in linear intensity. Consider a black and white checker board where the individual squares are big enough that you can easily see them. If you scale this image down such that the squares disappear, the resulting gray should be the one that minimizes the perceptual error. But since sRGB is roughly perceptually uniform and the squares are mostly low frequency information, that gray would be 0x80 and not the 0xba you would get from the supposedly correct algorithm.
jacobolus 16y ago
In the not impossibly distant future (that is, we could do it now, but it might be slow enough that a few people would complain) we’ll be able to do all intermediate processing with floating point, and it won’t be an issue. Using 127.5 to represent half and 255 to represent 1 is completely unintuitive.
- yason 16y ago
  How would using floating point avoid the conversion from linear to exponential range? You will still have to convert between brightness and voltage. And you would like to do gamma conversion in floating point anyway. For the second point, programmers are familiar with base-2. For decimal values, both end-users and programmers confuse 127/128 vs. 255/256 for being half the latter. Besides, end-users often see [0.0, 1.0] floating point range for color values already in graphics user interfaces, and would expect 0.5 to give half the intensity that does 1.0.
  - deleted 16y ago
    [deleted]
  - deleted 16y ago
    [deleted]
  - jacobolus 16y ago
    Obviously you take integer gamma-compressed values, convert to floats, and then un-gamma-compress those, doing intermediate math on the linearized floats, and then gamma compressing and converting back to integers when you need to save out a file of some sort. For showing the amount in each component to users, it's possible to use either linear or gamma-compressed values, depending on the goal, but either way showing a decimal makes it a lot easier to understand than showing a fraction of 255.
- ramchip 16y ago
  I think in the end cheap hardware will still win for a long time. Today's embedded CPUs aren't much more powerful than what was used in the 80's. Floating-point would be a lot of extra logic.

by yason 16y ago

wmf 16y ago

An 8-bit linear value probably wouldn't give adequate dynamic range (this is the same reason 8-bit audio isn't linear AFAIK), so you'd have to use 16-bit linear which would make all images twice as large. It would probably be an acceptable solution today, but not back in 1995.

reitzensteinm 16y ago

Wouldn't that result in a loss of precision at the lower end?

yason 16y ago
Doesn't that happen anyway, no matter which way we're doing it? Currently, if 180 out of 256 is half then we have considerably fewer values representing the highest intensities than the darkest intensities. So, in effect we currently "waste" values by allocating lots of them for darker values that mostly seem all the same on the screen. If we could program on the linear scale, it would depend on the hardware that how accurately the linear scale would be mapped to the voltages that would give linear intensity levels in reality. You can add bits per channel if you want more precision, that's what we do already.
- jacobolus 16y ago
  No. Intensity varies (roughly) proportionally with voltage, and where it doesn’t displays have built-in lookup tables which correct for any nonlinearity. Human lightness response though is a complex non-linear response that depends on the viewing conditions and the particular observer. There’s a not great description at http://en.wikipedia.org/wiki/Lightness_(color) http://en.wikipedia.org/wiki/Lightness_(color)
  - ssp 16y ago
    Human lightness response though is a complex non-linear response that depends on the viewing conditions and the particular observer. This is why I'm not convinced that the right solution is simply filtering in linear intensity. Consider a black and white checker board where the individual squares are big enough that you can easily see them. If you scale this image down such that the squares disappear, the resulting gray should be the one that minimizes the perceptual error. But since sRGB is roughly perceptually uniform and the squares are mostly low frequency information, that gray would be 0x80 and not the 0xba you would get from the supposedly correct algorithm.

jacobolus 16y ago

In the not impossibly distant future (that is, we could do it now, but it might be slow enough that a few people would complain) we’ll be able to do all intermediate processing with floating point, and it won’t be an issue. Using 127.5 to represent half and 255 to represent 1 is completely unintuitive.

yason 16y ago
How would using floating point avoid the conversion from linear to exponential range? You will still have to convert between brightness and voltage. And you would like to do gamma conversion in floating point anyway. For the second point, programmers are familiar with base-2. For decimal values, both end-users and programmers confuse 127/128 vs. 255/256 for being half the latter. Besides, end-users often see [0.0, 1.0] floating point range for color values already in graphics user interfaces, and would expect 0.5 to give half the intensity that does 1.0.
- deleted 16y ago
  [deleted]
- deleted 16y ago
  [deleted]
- jacobolus 16y ago
  Obviously you take integer gamma-compressed values, convert to floats, and then un-gamma-compress those, doing intermediate math on the linearized floats, and then gamma compressing and converting back to integers when you need to save out a file of some sort. For showing the amount in each component to users, it's possible to use either linear or gamma-compressed values, depending on the goal, but either way showing a decimal makes it a lot easier to understand than showing a fraction of 255.
ramchip 16y ago
I think in the end cheap hardware will still win for a long time. Today's embedded CPUs aren't much more powerful than what was used in the 80's. Floating-point would be a lot of extra logic.