[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The Newly Expanded Color Space Issue
On 09/09/2010, at 1:18 AM, Chris Marrin wrote:
> (with all choices, we also need a way to turn off all conversion and get raw pixels into the engine)
+1 (default raw)
> c) Give a choice of which conversion to perform
+1 (default sRGB)
> 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.
The important part is getting the raw values. The sRGB vs linear argument is intricate but it is also a finer detail. Raw is more important than linear _or_ sGRB.
Drawing unlit images in OpenGL should result in the same appearance as the <img> tag, so in the absence of any mathematically valid options for strict GLES2.0, as covered by Adrienne Walker:
On 08/09/2010, at 7:50 AM, Adrienne Walker wrote:
> 1) Higher-precision linear input textures. (Not possible at this point.)
> 2) Store the framebuffer in sRGB. (No EXT_framebuffer_sRGB in GLES2.)
> 3) Convert textures to linear space at sample time. (No EXT_texture_sRGB either.)
> 4) Convert textures to linear space at upload time. (Loss of precision.)
> 5) Convert the linear framebuffer to sRGB before compositing.
and that OpenGL has an existing precedence in sRGB textures (fur future WebGL expansion), I think that having the schizophrenic raw import of data and sRGB composition is one of those mathematical hacks we still need to live with for now.
Right now, we don't have 12 bits... (point 1)
>From the perspective of code, I want two things... "leave my data alone" and "tell me what I'm writing to"... "Raw, sRGB". :)
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: