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

Re: [whatwg] WebGL and ImageBitmaps

From: Justin Novosad <junov@google.com>
Date: Fri, 16 May 2014 10:14:20 -0400
Message-ID: <CABpaAqRghqdfRFuwg17N-BYzb7e4UuQH7YvQx57R8TkR6jN5ng@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Katelyn Gadd <kg@luminance.org>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Glenn Maynard <glenn@zewt.org>, Ian Hickson <ian@hixie.ch>
On Thu, May 15, 2014 at 12:27 AM, Rik Cabanier <cabanier@gmail.com> wrote:

> On Wed, May 14, 2014 at 7:45 PM, Glenn Maynard <glenn@zewt.org> wrote:
>
>
> Yes, color correction from sRGB to your monitor should not affect drawing
> on canvas. (What if you had multiple monitors :-))
>

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. 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. 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.

Adding a colorspace option to createImageBitmap is not enough IMHO. I think
we need a more global color-management approach for canvas. I commented on
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25643
Received on Friday, 16 May 2014 14:24:42 UTC

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