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

Re: [Public WebGL] The Newly Expanded Color Space Issue



The historical background to the problem is that on X-windows
(Unix/Linux) machines there is a gamma setup command line tool that
affects the entire screen.

If you have a Linux box, open up a shell window and type:

   xgamma -gamma 3.0

...and you'll immediately see the difference...including in browser
windows and with WebGL.  Since OpenGL started life on SGI's Unix
workstations - it didn't have to be concerned with gamma correction at
all.  In theory one would set the xgamma to 2.2 (or whatever the correct
value was for the screen you're using) then every program would be
working in linear color space and the whole gamma correction issue would
go away.  You can even set the gamma separately for red, green and blue
(which is strictly necessary because older CRT's would have slightly
different gamma for each phosphor).

However, when early full-color graphics cards started to appear for the
PC, they didn't support that...so people started trying to fix gamma in
software or on the input to the pipeline...and chaos has reigned supreme
ever since.   Now I have to set the gamma on my Linux box to 1.0 because
the browser is also trying to do gamma - which opened up a whole new can
of worms.   On modern Windows machines (certainly on nVidia) you can
still set the gamma globally using the nVidia setup stuff - but again,
doing that only makes matters worse when the application is also trying
to fix it - so I doubt many people actually do that.

  -- Steve

Kenneth Russell wrote:
> I don't think that any of the proposed definitions for how WebGL's
> drawing buffer is presented to the screen are clear enough to both
> eliminate confusion on the part of the developer, and avoid locking
> the WebGL specification into a bad situation that will prevent a sound
> solution to the color space issue in the future.
>
> In particular, stating explicitly that WebGL's output is treated as
> sRGB may cause extreme confusion among developers. They may assume
> that this implies that the values in the drawing buffer have a gamma
> correction factor explicitly applied before drawing to the screen, and
> attempt to undo that in their shaders.
>
> Note that up until 2007/2008, OpenGL developers didn't even have
> access to sRGB texture formats and framebuffers, and plenty of
> progress in rendering algorithms was made to that point. It's only
> been in recent years as AAA game titles have tried to implement fully
> gamma correct HDR rendering pipelines that some of these issues have
> been discovered, and in fact are still being worked on.
>
> On Wed, Sep 8, 2010 at 8:48 AM, Chris Marrin <cmarrin@apple.com> wrote:
>   
>> It's time to bring this issue to a conclusion. We can't make WebGL programs correct, and we can't tell authors that we will only accept mathematically correct WebGL programs. What we CAN do is to give authors sufficient tools (given the current constraints) to give them the flexibility to do what they want with WebGL. As Adrienne and I have pointed out the only things we can do are:
>>
>> 1) Manipulate the color space of images being loaded with texImage2D. Choices are:
>>
>>        a) Convert all images to sRGB always
>>        b) Convert all images to Linear always
>>        c) Give a choice of which conversion to perform
>>
>> (with all choices, we also need a way to turn off all conversion and get raw pixels into the engine)
>>     
>
> I think that the only toggle that should be exposed at this time is
> whether the browser's default image conversion should be applied
> (whatever it is), or whether the "raw" pixel values in the image (for
> example, in a PNG with a gAMA block) are uploaded. I do not think that
> the sRGB color space should be mentioned at all in the WebGL 1.0
> specification. If it is, developers may assume that WebGL somehow
> incorporates the sRGB texture extensions, which is not the case. Also,
> even with normal HTML content, there are differences between browsers
> in handling of things like embedded color profiles in images. I think
> that overspecifying this behavior will provide false guarantees to
> developers and make it impossible for implementations to reach spec
> compliance.
>
> Note that the 2D Canvas context specification at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html
> does not mention the phrase sRGB at all.
>
>   
>> 2) Manipulate the color space of the drawing buffer as it is composited with the page. Choices are:
>>
>>        a) Always convert the drawing buffer as if it is sRGB into the device color space used by the compositor
>>        b) Always convert the drawing buffer as if it is Linear into the device color space used by the compositor
>>        c) Give a choice of which conversion to perform
>>
>> I can live with any combination of the above. Currently my first choice would be 1c and 2c, with the default being sRGB for both. Please don't criticize those choices as wrong, just make your own choice.
>>     
>
> I think that the only thing that should be said in the WebGL 1.0
> specification is that the color space of the drawing buffer is managed
> according to the rules in the OpenGL ES 2.0 specification. The OpenGL
> ES 2.0 spec does not mention sRGB at all.
>
> A future version of the WebGL spec could more clearly define the
> behavior. As I understand it, if OES_texture_float is available, then
> it might even be possible to emulate the semantics of EXT_texture_sRGB
> and EXT_framebuffer_sRGB behind the scenes by using higher-precision
> textures for the input and output. However, until that time, I think
> that we should add the minimal amount of wording to the WebGL spec.
>
> -Ken
>
> -----------------------------------------------------------
> You are currently subscribed to public_webgl@khronos.org.
> To unsubscribe, send an email to majordomo@khronos.org with
> the following command in the body of your email:
>
>   

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: