There is currently an ongoing discussion with the Khronos Web3D group to develop a proposal that solves these problems in canvas, over the past few weeks we have converged on a solution that I think is pretty solid. I am in the process of writing-up the HTML (non-WebGL) part of the proposal and I intend to post it to the WICG shortly so that we can incubate it further, with a broader audience. When that happens, I will update this thread.
On Sat, Apr 30, 2016 at 2:07 PM, Rik Cabanier <caban...@gmail.com> wrote: > [Sorry to revive this old thread] > All, > > with the advent of DCI-P3 compliant monitors and Apple's Safari doing > color managing to the device, we're seeing some issues in this area. > > - Currently, WebKit sets the profile of the canvas backing store to sRGB > regardless of the output device. Because of this, high gamut images are > always clipped to sRGB. [1] > It would be ideal if we can specify that the canvas backing store is in > the device profile. > Alternatively, we could add an API to attach a color profile to the canvas. > - The spec currently states that toDataURL should not include a profile. > However, if the backing store is in device pixels, the generated image > should include the correct profile. Otherwise if you draw the bitmap in a > compliant browser (ie Safari), the colors will look too saturated. > > If we agree that canvas is in the device space, I'd like to see the spec > [2] clarified to state that compositing on the canvas should match > compositing on the HTML surface. > Specifically: > > The canvas > <https://html.spec.whatwg.org/multipage/scripting.html#the-canvas-element> > APIs > must perform colour correction at only two points: when rendering images > with their own gamma correction and colour space information onto a bitmap, > to convert the image to the colour space used by the bitmaps (e.g. using > the 2D Context's drawImage() > <https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-drawimage> > method > with an HTMLOrSVGImageElement > <https://html.spec.whatwg.org/multipage/scripting.html#htmlorsvgimageelement> > object), > and when rendering the actual canvas bitmap to the output device. > > Becomes: > > The canvas > <https://html.spec.whatwg.org/multipage/scripting.html#the-canvas-element> > APIs > must perform colour correction at only one point: when rendering content > with its own gamma correction and colour space information onto a bitmap to > the colour space used by the bitmaps (e.g. using the 2D Context's > drawImage() > <https://html.spec.whatwg.org/multipage/scripting.html#dom-context-2d-drawimage> > method > with an HTMLOrSVGImageElement > <https://html.spec.whatwg.org/multipage/scripting.html#htmlorsvgimageelement> > object). > > > ToDataURL and ToBlob [3] should also be enhanced so they include the > device profile if it is different from sRGB. > > It would also be great if the browser could let us know what profile (if > any) it was using. > > 1: > https://github.com/WebKit/webkit/blob/112c663463807e8676765cb7a006d415c372f447/Source/WebCore/platform/graphics/ImageBuffer.h#L73 > 2: > https://html.spec.whatwg.org/multipage/scripting.html#colour-spaces-and-colour-correction > 3: > https://html.spec.whatwg.org/multipage/scripting.html#dom-canvas-todataurl > > > > On Thu, May 22, 2014 at 12:21 PM, Justin Novosad <ju...@google.com> wrote: > >> tl;dr: The color space of canvas backing stores is undefined, which >> causes problems for many web devs, but also has non-negligible advantages. >> So be careful what you wish for. >> >> I saw some confusion and questions needing answers in the "WebGL and >> ImageBitmaps" thread regarding color management. I will attempt to clarify >> to the best of my abilities. Though I am knowledgeable on the subject, I am >> not an absolute authority, so others are welcome to correct me if I am >> wrong about anything. >> >> Color management... To make a long story short, there are two types of >> color profiles : input profiles and output profiles for characterizing >> input devices (cameras, scanners) and output devices (displays, printers) >> respectively. >> Image files will usually encode their color information in a standard >> color space or in a an input device dependent space. If colors are encoded >> in a color space that is different from the format's default, then a color >> profile or a color space identifier must be encoded into the image >> resource's metadata. >> >> To present color-managed image content on screen, the image needs to be >> converted from whatever color space the image was encoded into into a >> standard "connection space" using the color profile or color space metadata >> from the image resource. Then the colors need to be converted from the >> profile connection space to the output space, which is provided by the >> OS/display driver. Depending on the OS and hardware configuration, the >> output space may be a standard color space (like sRGB), or a >> device-specific color profile. >> >> Currently, many color-managed software applications rely on the codec to >> take care of the entire color-management process for image and video >> content, meaning that the decoded image data is in output-referred color >> space (i.e. the display's profile was applied). There are practical >> reasons for this, the most important ones being color fidelity and memory >> consumption. Let me explain. The profile connection space is typically CIE >> XYZ or CIE L*a*b. I wont get into the technical details of how these work >> except to say that they are device independent and allow for an accurate >> representation of the whole spectrum of human-visible colors. This makes it >> possible to map colors from a wide gamut camera to a wide gamut display >> with high color fidelity for all the colors that are located in the >> intersection of the color gamuts of both the input and output devices. If >> we were forced to convert the image to an intermediate sRGB representation, >> the colors in the image would be clamped to the sRGB gamut (which is >> narrower than the gamuts of many devices). Currently, most browsers avoid >> doing that for <img>, and therefore provide (more or less) optimal image >> and video color fidelity for users of wide gamut devices. Also, an >> intermediate representation in 8-bit sRGB means loss of precision due to >> rounding errors, as opposed to the profile connection space which uses >> higher precision registers for intermediate color values to avoid precision >> issues caused by rounding. To avoid perceptible precision issues in an >> intermediate sRGB representation, we'd have to increase the bit depth and >> therefore use more RAM for storing decoded image data. >> >> All of this is to say that there are good reasons for the current >> situation where we deal with decoded images that have the output device's >> color profile pre-applied: color fidelity and memory consumption. >> >> In the case of 2D canvas, the color space for the backing store is >> unspecified, and many implementations have chosen to use the output >> device's color space, which has many advantages: >> * images and videos are already decoded directly into that space >> * no color conversion is necessary when presenting the canvas on screen >> (good for performance) >> * there is no loss of precision due the use of a limited-precision >> intermediate color space. >> * the color gamut is not constrained by an intermediate color space (like >> sRGB). >> And disadvantages: >> * Compositing operations produce incorrect results because most of them >> (including source-over) are affected by the color space. >> * direct pixel manipulation using put/getImageData exposes data in a >> color space that is undefined, making it extremely challenging to perform >> many types of image processing and image generation tasks in a >> device-independent way. >> * The device-dependent behavior of a drawImage/getImageData round trip is >> a known fingerprinting vector. >> >> Right now, I am hearing a lot of complaints regarding the lack of a >> standardized color space for canvases, and in particular the impact this >> has on applications that try to do cool things with put/getImageData, or >> generate images procedurally. I want to make sure everyone understands >> there is a trade-off to fixing this, so be careful what you wish for. >> >> I am especially concerned about the issue of color gamut clamping, which >> will increase in relevance as wide gamut devices become more widespread. >> If we were to decide that canvas backing stores had to be in sRGB, that >> would mean that a wide gamut image viewed on a wide gamut display would >> look best when displayed in an <img> and would be duller when drawn through >> a <canvas>, whether it be 2D or WebGL. Is that something we are willing to >> live with in the name of standardizing the color space of ImageData? I >> must admit I was in favor of moving canvases to sRGB until I reviewed some >> of Noel Gordon's recent work which brought the gamut and precision issues >> to my attention. >> >> Rik: to answer your question about your experiment: there is no issue >> with a put/getImageData round trip. You will get back the same color you >> put in (at least for opaque colors, but that is another story). The issue >> is with a drawImage/getImageData round trip. For the same source image, >> getImageData will return different values depending on the display profile >> of the system you are running on. >> >> Ken: You mentioned to me off thread that built-in support for sRGB render >> buffers in OpenGL ES 3 may make it easier to move rendering to sRGB on next >> gen devices. I tend to agree, and I think it will also mitigate the loss of >> precision issue, but it still implies clamping wide gammut media to the >> sRGB range. >> >> -Justin >> >> >> >
