[Public WebGL] WEBGL_compressed_texture_s3tc_srgb

Florian Bösch [email protected]
Tue Jun 14 03:08:44 PDT 2016


On Tue, Jun 14, 2016 at 11:20 AM, Kirill Dmitrenko <[email protected]>
wrote:
>
> If you're referring to WebGL (and WebGL 2 for that matter), is there any
> info backing this statement? Because it seems to be not specified in either
> spec, and, moreover, browsers seem to threat image data differently (both
> recieved from a server and rendered with WebGL). There was an endeavour to
> specify browsers behaviour regarding gamma correction on decoding images
> for textures and compositing WebGL content to a page. But as far as I can
> tell, it has never gotten anywhere.
>

Gamma exists for two related, but ultimately independent reasons.

   1. CRT display technology (which was mankind's first display technology)
   used phosphorescence to produce light. To produce a picture an electron
   beam emitted by what is known as electron gun, was electromagnetically
   guided over the display panel. The electron source was cathode ray tube,
   which is a form of amplifying vacuum tube. These tubes (also known as
   triodes) have a nonlinear relationship to the voltage applied and the
   electrons emitted.
   2. The human eye under normal lighting conditions has a response to
   light that is able to distinguish shades of dark easier than shades of
   bright.

These two facts combined in a lucky union to create what is known as "gamma
space". Lucky, because it allows a form of compression of the signal (be it
analog or digital) where a smaller portion of the signal is used to express
differences in higher luminances and more is used to express differences in
lower luminances, hence improving the quality of the display, while
simultaneously building the necessary "decoding" into the physics of the
display device at no additional cost.

Variance in gamma curves (and display gamut) became a problem however. And
by 1996 Microsoft and HP in collaboration with many other industry partners
introduced sRGB. A combined colorspace and gammaspace that was designed to
fit CRTs of the period. This became the de-facto standard for color
exchange between devices and CRTs.

Due to a complete lack of the management of colorspaces and gamma curves
between devices and displays, this later turned out to be a problem for
alternative displays such as TFTs, which did not share the CRT inherent
technical reasons for gamma and gamut, and did in fact physically surpass
CRTs in luminance response, luminance accuracy and gamut reproduction
considerably.

However due to the fact that TFTs entered a field that was dominated by
CRTs, which all serviced a de-facto standard that was below the technical
abilities of the TFTs, TFTs had no choice but to adopt an (electronic)
emulation of sRGB because that was the signal they got from devices.

To this day there does not exist any way for displays and devices to
inter-operate to discover gamma curves, gamut coverage and precision.
Consequently there does not exist any way for applications to communicate
those properties with the host operating system.

For this reason, graphics APIs leave this property wholly unspecified, and
it is implied that what you output has to be in gamma space, which most
probably means sRGB.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160614/43cc8ea0/attachment.html>


More information about the public_webgl mailing list