[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The Newly Expanded Color Space Issue
On Wed, Sep 8, 2010 at 11:17 PM, Chris Marrin <firstname.lastname@example.org> wrote:
> On Sep 8, 2010, at 11:56 AM, stephen white wrote:
>> ...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.
> I agree with your points, but I am confused. Web browsers (WebKit at least) convert all images to sRGB, regardless of what their original color space was. So to get the same appearance as the <img> tag you would either need to import images as sRGB and consider the drawing buffer to be sRGB, or import images as Linear and consider the drawing buffer to be Linear. Having Raw as the default won't give you that consistent behavior. Or am I misunderstanding you?
FYI when I tried this on WebKit on Mac, both Chrome and Safari ignored
the gAMA tags in some PNG test images. Firefox observed it. This
looks like a good test page:
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: