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

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

On Wed, Sep 15, 2010 at 5:25 AM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
>  On 13/09/2010 20:05, Thatcher Ulrich wrote:
>> On Mon, Sep 13, 2010 at 6:18 AM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
>>>  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.
> No it is not backwards. What got this whole discussion started was the
> revelation that , when displaying an <img> tag, web browsers convert
> image data from the color space specified by the image file to the color
> space of the display. As a result it was suggested that WebGL
> applications needed a way to disable that conversion. You even agree
> with that (below) while noting that WebKit is not doing any conversions.
> So what I wrote is correct. If the browser *is* doing conversion then a
> WebGL application receiving raw image data (i.e. having disabled the
> conversion) needs to perform the disabled conversion, if the result is
> to match that of an img tag displayed by the browser. The fact that the
> conversion many times reduces to a NOP does not make my statement
> incorrect or backwards.
> I don't know about recent Mac's but in the past Macs did not have sRGB
> displays and JPEG and other near sRGB images definitely had to be
> converted for proper display.

I misunderstood what you meant by color conversion; I agree with what
you just said above.  I don't know the historical details of Mac
either.  My only point was that most of the time the conversion is
actually NOP.


> Regards
>    -Mark
>> 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.
>> -T
>> [*] 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: