- From: Justin Novosad <junov@google.com>
- Date: Fri, 16 May 2014 10:14:20 -0400
- 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