[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.

--Oliver
-----------------------------------------------------------
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: