[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] The Newly Expanded Color Space Issue
On 13/09/2010 20:05, Thatcher Ulrich wrote:
> On Mon, Sep 13, 2010 at 6:18 AM, Mark Callow <email@example.com> 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.
> 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.
org:HI Corporation;Graphics Lab, Research & Development
adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan
tel;work:+81 3 3710 9367 x228
tel;fax:+81 3 5773 8660