Intent to implement: Color correct rendering

929 views
Skip to first unread message

Christopher Cameron

unread,
Apr 14, 2017, 3:30:39 PM4/14/17
to blink-dev
Contact

Spec Changes

This brings Chrome's behavior in line with existing specifications.

Summary & Motivation
The goal of this work is to eliminate the following bugs
  1. Images that do not have a specified color space are currently stretched to the monitor's gamut, despite specification saying that they should be treated as sRGB. This will make them be treated as sRGB (and transformed to the appropriate space for the monitor they are on).
  2. Images that do specify a color space are converted to the color space of "a" monitor, not necessarily the monitor that they are on. This will transform them to the appropriate space for whichever monitor they are on.
  3. It is currently not possible to deterministically match CSS colors (which are sRGB per spec) with images that have a specified color space (even if the specified color space is sRGB). This will make this deterministic (modulo blending).
  4. When writing and then reading back an image that specifies a color space to a canvas element, the image has a transform to the color space "a" monitor on the system applied to it, which results in unpredictably different behavior on different systems and is also a fingerprinting vector. This will change the behavior to always transform canvas images to sRGB.
This also puts down the foundation for the following features
  • High bit depth buffer support for WCG displays
  • HDR monitor support for video and WebGL
  • Canvases in non-sRGB color spaces (e.g, BT2020 floating point for a WCG working space)
  • Linear space rendering ("true color mode") for consistent appearance across all devices.
Privacy

This will eliminate a fingerprinting vector.

Performance Risk

A more detailed summary with power impact will come later. The following are areas of potential concern.
  • Many sRGB images that previously had no color transforms applied to them will now have color transforms applied to them (Bullet [1] in motivation). Efforts will be made to minimize this.
  • Many layers will have color transforms applied to them at compositing time. The cost of color transformation at compositing time is minimal (see doc).
Interoperability and Compatibility Risk

This change will eliminate sources of inconsistency across machines, and bring Chrome more in line with other browsers.

Acknowledging that often "the implementation is the spec", the implementation will change in the following noticeable way:
  • Canvases will operate in sRGB color space, as opposed to an undefined and inconsistent space. This means that WCG images will have their gamut shrunk when they are drawn to a canvas.This is the same behavior as exists on sRGB gamut monitors today (~90% of monitors).
  • Manipulating WCG images in a canvas will require using new canvas extensions in development elsewhere (as it has already on most displays).
Testing and Shipping

This feature is currently available (with many bugs) behind the flag --enable-color-correct-rendering. I will circulate a document discussing implementation details and power impact before shipping.

Rick Byers

unread,
Apr 22, 2017, 2:15:45 PM4/22/17
to Christopher Cameron, blink-dev
Sounds great.  I know Apple (dino@ in particular) has been doing a lot of color space work in Safari, and getting CSS specs updated for it (there was a long discussion at the Tokyo meeting this week which I must confess I didn't follow).

rj.amd...@gmail.com

unread,
Oct 9, 2017, 10:35:42 PM10/9/17
to blink-dev, ccam...@google.com
I'm excited to see that this is a consideration for future Chrome releases. I hope Google intends to integrate Chrome into the Windows WIC framework, instead of using the Firefox workaround, which involves linking Firefox settings directly to the monitor color profile.

Reply all
Reply to author
Forward
0 new messages