W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] WebGL and ImageBitmaps

From: Kenneth Russell <kbr@google.com>
Date: Fri, 16 May 2014 11:08:26 -0700
Message-ID: <CAMYvS2duR=pn3p46hLZiF3=8-XkS7_TJNqXFNp93SvHgsBia1g@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Justin Novosad <junov@google.com>, noel.gordon@gmail.com, Glenn Maynard <glenn@zewt.org>, Katelyn Gadd <kg@luminance.org>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Rik Cabanier <cabanier@gmail.com>
On Fri, May 16, 2014 at 9:27 AM, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 16 May 2014, Justin Novosad wrote:
>>
>> This is a longstanding issue with 2D canvas that several developers have
>> complained about over the years.  The color space of the canvas backing
>> store is currently unspecified.
>
> It's defined that the colour space must be the same as used for CSS and
> <img>, but yeah the final colour space is left up to the UA:
>
>    http://whatwg.org/html#color-spaces-and-color-correction
>
>
>> Blink/WebKit uses output-referred color space, which is bad for some
>> inter-op cases, but good for performance. Calling drawImage will produce
>> inter-operable behavior as far as visual output is concerned, but
>> getImageData will yield values that have the display color profile baked
>> in.
>
> I'm not quite sure what you mean here. If you mean that you can set
> 'fillStyle' to a colour, fillRect the canvas, and the get the data for
> that pixel and find that it's a different colour, then that's
> non-conforming. If you mean that you can take a bitmap image without
> colour-profile information and draw it on a canvas and then getImageData()
> will return different results, then again, that's non-conforming.
>
> If you mean that drawing an image with a color profile will result in
> getImageData() returning different colour pixels on different systems,
> then that's allowed, because the colour space of the canvas (and the rest
> of the Web platform, which must be the same colour space) is not defined.
>
>
>> Some web developers have worked around this by reverse-engineering the
>> client-specific canvas to sRGB colorspace transform by running a test
>> pattern through drawImage+getImageData.  It is horrible that we are
>> making devs resort to this.
>
> I'm not really sure what this work around achieves. Can you elaborate?
>
> If you just want to do everything in sRGB, then putting all your images in
> sRGB but without giving color space information (or setting the option to
> 'strip', if we add these createImageBitmap() options) would result in what
> you want, no?
>
> You'd have to manually (or on the server) convert images that were in
> other colour spaces, though.
>
>
>> Adding a colorspace option to createImageBitmap is not enough IMHO. I
>> think we need a more global color-management approach for canvas.
>
> If we need colour management, we need it for the Web as a whole, not just
> for canvas. So far, though, implementations have not been implementing the
> features that have been proposed, so...:
>
>    http://www.w3.org/TR/css3-color/#dropped

Recently there has been activity in some implementations to finally
solve the color management problem. I can't speak for Safari, but have
heard that as of Mac OS X 10.9, that implementation is rendering web
pages into the sRGB color space per the CSS spec, and converting to
the display's color profile on the way to the screen. I was told that
there was a concern there would be a compatibility impact with web
apps implicitly expecting to work in the display's color space, but
surprisingly, everything seemed to work during this transition.

In Chrome there is also work ongoing to handle multiple monitors with
different display color profiles. Noel Gordon (CC'd) is driving this
and the list of active issues can be seen at
https://code.google.com/p/chromium/issues/list?q=owner%3Anoel%40chromium.org
. It's likely the implementation will be done in stages: first
rendering images correctly when dragging windows from monitor to
monitor, and then rendering all web page content correctly.

In sum, while it has taken a while for implementations to finally
start tackling the color management problem, it's happening now.

-Ken
Received on Friday, 16 May 2014 18:10:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC