On Fri, May 16, 2014 at 9:27 AM, Ian Hickson <i...@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