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