>I'd really prefer the simplicity of applications using scRGB(16) or other such linear-light colorspace
Would an eight bit linear, standard gamut colorspace be enough of an improvement to be worth implementing? Or does that cause too much loss of color precision relative to 8 bit sRGB?
The main reason of course for supporting 8 bit is the extra resource requirements of 16 bit components, especially in a remoting protocol. Much more extensive and possibly lossy compression would have to be applied to keep up.
Posted Jun 25, 2012 17:34 UTC (Mon) by alankila (subscriber, #47141)
[Link]
It will not have high enough quality, I'm sad to say.
If you keep the sRGB gamut, it takes about 12 bits of linear precision per component to still generate every 8-bit sRGB value. Of course, the problem is most severe at the darkest of shades, but it doesn't really change things too much to just go full 3x16 or 4x16 bits compared to some more limited solution.
For the remoting protocol, it is thinkable that the fidelity of the rendering would be reduced during the process, but the focus should be very strongly on getting good local behavior and treating the remote behavior as afterthought. It's probably not so hard as people think, and in any case we must not cripple local features for sake of preserving remoting, imho.
St. Pierre: The Linux Graphics Stack
Posted Jun 27, 2012 4:37 UTC (Wed) by butlerm (subscriber, #13312)
[Link]
16 bit linear ARGB sounds like it ought to become the new standard buffer format. I sure hope the GPU vendors adopt a different representation than standard scRGB(16) however, because storing reference black with a large positive bias is going to complicate processing enormously. http://en.wikipedia.org/wiki/ScRGB