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

Re: [Public WebGL] Gamma correction and texImage2D/texSubImage2D

On Sep 3, 2010, at 5:54 PM, Steve Baker wrote:

> Oliver Hunt wrote:
>> The way browsers currently handle colour space is fairly simple, the
>> actual format does not matter:
>>  * The image includes a colour profile: then use that colour profile
>>  * The image does not include a colour profile: then assume the image
>> is in sRGB
>> This is the model that WebGL texture loading should follow in order to
>> be consistent with other web content.
>> Obviously WebGL will need an API to load raw (un "corrected") data
>> into a texture in order to handle a few use cases, but other than that
>> additional API there shouldn't be any other logic necessary.
>> Basically the complete (image to display) model is:
>>            Image                       WebGL Context                
>>      Display
>>  <arbitrary colour space>  -> match ->   Linear RGB   -> match ->  
>> <arbitrary colour space>
>> With an option to do
>>            Image                       WebGL Context                
>>      Display
>>  <arbitrary colour space>  ->  nop  ->   Linear RGB   -> match ->  
>> <arbitrary colour space>
>> The actual file formats, and the actual mechanism of matching isn't
>> relevant, all that we need to do is guarantee the colour space of the
>> GL context.
>> --Oliver
> Yes - that's workable.
> I'm a little concerned about the meaning of if the "image does not
> include a color profile: then assume the image is in sRGB"...that's
> going to cause a bunch of grief to people who don't have an advanced
> degree in specification-parsing.   But so long as we can override the
> Image=>WebGL conversion painlessly, I'll just do that unconditionally
> and all will be well.
> The critical parts are that we assume that the WebGL context is ALWAYS a
> linear color space (because that's all our hardware will ever be) - and
> that (as a consequence) something after that in the pipeline applies a
> decent gamma value...which would most efficiently be a GPU-based
> compositing step.

Gamma correction is (from the PoV of the GL context) simply an aspect of the display's colour profile so doesn't effect the WebGL spec.

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: