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

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

On Mon, Sep 13, 2010 at 6:18 AM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
>  On 09/09/2010 03:56, stephen white wrote:
>> 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,
>> ...
>> 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.
> Do you see the contradiction between your two statements?
> In the pure 2D case, the browser is applying color correction from the
> color space of the <img> to the color space of the display. If you
> insist on passing only raw values to GL, then you can never get the same
> appearance as the <img> tag for an unlit image unless the application
> applies the same correction. Since the application has no way to query
> either the image color space or the display color space, this is
> currently impossible.

No, this backwards.  The application ordinarily is not doing any correction.

In the straightforward 2D case, webkit[*] takes raw rgb values from
the image file and passes them straight through, without any numerical
transformations, to the framebuffer.  Conventionally (and per the CSS
specs you cite), the framebuffer assumes sRGB values, and
conventionally, 99% of images are captured into an sRGB color space
and transmitted as sRGB.

Re WebGL, let's assume a fragment shader that copies the input
straight to the output.  If WebGL does anything other than take sRGB
image values and pass them straight through to an sRGB output buffer,
it will be behaving differently than the default 2D browser path.


[*] Firefox evidently does not take raw values unless gamma is
unspecified in the image file.  Instead it uses the image-specified
gamma to convert the image data into sRGB before further processing.
This is a corner case and the webkit behavior is probably a bug, but
it only affects a tiny fraction of images on the web, which probably
explains why no one has fixed it yet.

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: