[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] gamma/color profile and sRGB



Florian missed one important factor in scenes looking different on different displays: the viewing conditions. Some high-end displays have sensors they use to account for this. For this and other reasons, I do not think application developers should be trying to second guess the display calibration. If the factory can’t get it right (as Florian postulates), how on earth can you expect a developer, who has never even seen the display in question, to get it right. BTW, display response curves in this age of LCD and LED displays are largely artificial so variations are either small or deliberate. The latter would be accounted for in the color profiles.

GLFW does not support every platform. I suspect there will be some platforms where WebGL is supported that do not have an equivalent to getGammaRamp in the underlying OS. In that case, what to do, return a standard sRGB response curve?

I think the solution to this is to be able to create sRGB back-buffers and let the rest of the system’s color management do its stuff to map that standard sRGB data to the actual display. Yes, this can’t be done for WebGL 1.0 but once WebGL 2 is out, WebGL 1.0 will only linger on older mobile devices that cannot be updated.

I suggested in another e-mail thread that WebGL 2 should support only sRGB back-buffers. I can’t see any reason to support physically linear back-buffers as all OpenGL ES 3 hardware supports sRGB rendering and textures and most displays are close to sRGB. All you succeed in doing when rendering to a linear back-buffer is waste bits on data people can’t see and introduce banding. It is better to let OpenGL {,ES} perform the linear calculations in higher precision and compress the result to sRGB when storing in the frame buffer.

Regards

    -Mark


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail