Color management

[Yoav Weiss]

(chromium-dev in bcc)

I went down the rabbit hole of several color management related issues, and came out believing there's a lot of confusion and misunderstandings in those (very long) threads, which IMO need sorting out.

So, I'll try to sum up the state of affairs here:

1) CSS Color management

CSS colors are sRGB, and in order to be accurately displayed on screen with non-sRGB color profile, need to be color corrected before sent to screen. 

Currently in Chrome and Firefox* that is not the case, but it is the case in Safari. There have been past claims that color managing CSS will break content, but from Safari supporting it, one can assume that it is fairly safe to do so.

2) Image color management

Images that contain an ICC profile seem to be properly handled on desktop Chrome, but not so on Android.

Otherwise, images that do not contain an ICC profile are considered to be in the display color profile space rather than in the sRGB space. This is again similar to Firefox, but contrary to Safari. 

One can also argue that it is also important for color consistency to make sure that images and CSS colors are in the same color space, even if means that the colors are not accurate. Taking this approach means sending sRGB color profiles along with all images (even ones that are using the sRGB color space), which is extremely wasteful. Facebook seems to be taking this approach.

OTOH, for images, there probably would be some perf costs when color space conversions are required.

3) Video color management

More or less the same as images, but performance impact may be more significant.

All in all, it seems like everyone would be better off if in the case of non-sRGB display, CSS colors, as well as images and video with no color profile would all be assumed sRGB and color corrected to the display's color space rather than sent to it as is, leading to color inconsistency between devices. Also, fixes for all these issues have to be shipped at the same time, to avoid color inconsistency between images and CSS colors.

The downsides of fixing these issues are a potential compatibility risk (which the Safari experience may suggest is a non-issue) and a potential performance hit for the users that need this color correction (assuming we can avoid color correcting for sRGB display users).

What do you folks think? Did I cover the full breadth of these color management issues correctly?

If so, should we try and fix these issues despite the perceived risks? 

Cheers,

Yoav

* Firefox enables users to turn on color management using a flag. However that flag is off by default.

[Ruud van Asseldonk]

On Monday, January 4, 2016 at 10:53:28 PM UTC, Yoav Weiss wrote:

Otherwise, images that do not contain an ICC profile are considered to be in the display color profile space rather than in the sRGB space. This is again similar to Firefox, but contrary to Safari. 

+1 for assuming sRGB if the color space was not specified, the meaning of the pixels in the image cannot possibly depend on the user’s configuration.

More food for thought: is it Chrome’s responsibility to output anything different than sRGB? There are programs that apply a color profile screen-wide (e.g. xcalib on Windows, software that comes with the Spyder, GNOME’s built-in color management). I’ve seen a few programs that try to be color space-aware and actually make things worse. I suspect (but I didn’t actually verify) that this is what happens: they read an sRGB image (or other color space image) and see that the monitor profile is not sRGB, so they convert to the monitor profile before displaying the image. Then the screen-wide correction assumes the program output is sRGB and applies the correction again, leading to the wrong output.

One more thing: some png images contain gamma metadata but not a full color profile. How this value is interpreted handled across different browsers is a mess, see this arthis articleticle. I don’t know what the right thing to do is here. I expect that for the majority of png images that contain a gamma chunk, it ended up there because the authoring software wrote it by default, and the author doesn’t even know what a color space is. In that case it would be best to just ignore the value and assume sRGB. On the other hand, that defeats the purpose for authors who actually know what they are doing.

[Mike Pinkerton]

+noel@ and kbr@ who have been looking at this, noel for a long time.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--

Mike Pinkerton
Mac Weenie
pink...@google.com

[Yoav Weiss]

Just had a long off-list discussion with Noel. I'll do my best to summarize it here:

* In order to maintain color consistency between the page elements, we would need to correct CSS (including gradients), images, videos, canvas (and perhaps plugins) at the same time.

* Since drawing is not necessarily centralized, making sure that no piece of code is drawing before correcting is not trivial.

* The Skia team will also have to implement color correction.

* Gradients may pose an issue since in sRGB=>wide gamut conversions they can create banding artifacts. Can be overcome for CSS gradients but not necessarily for image gradients.

* The use-case of not having to send sRGB profiles for sRGB images can be resolved by adding a low overhead sRGB profile to the standard, regardless of automatically converting no-profile images from sRGB to the display color space.

* We need to gather data on which color profiles we see in the wild. UMA is being added. I'll try to gather some data as well.

* In general color correction in not a panacea, as it has performance costs, but most importantly, can result in its own color distortions.

* Some of the impact of sending sRGB to wider gamut screens can be minimized by users adjusting their screen settings, or sites picking "toned down" colors.

* On mobile, no browser seems to be doing color correction, even for profiled images. Also, the screen gamuts there do not exceed that of sRGB. Therefore, it makes sense to send only no-profile sRGB images to mobile.

* Perf concerns can be somewhat alleviated by applying color correction only when needed, offloading to GPU, etc. Distortion can also be reduced in some scenarios.

* A "display profile" client hint could make sense here, and help developers send sRGB images to sRGB screens while sending wider gamut images to wider gamut displays.

[Daniel Bratell]

On Tue, 05 Jan 2016 11:11:50 +0100, 'Ruud van Asseldonk' via blink-dev <blin...@chromium.org> wrote:

On Monday, January 4, 2016 at 10:53:28 PM UTC, Yoav Weiss wrote:

Otherwise, images that do not contain an ICC profile are considered to be in the display color profile space rather than in the sRGB space. This is again similar to Firefox, but contrary to Safari. 

+1 for assuming sRGB if the color space was not specified, the meaning of the pixels in the image cannot possibly depend on the user’s configuration.

More food for thought: is it Chrome’s responsibility to output anything different than sRGB?

I think this was a very good question. Is it really every program's responsibility to adapt to the screen currently connected? What if there are more than one with different color profiles? What if half of the browser is on one screen and half on another?

I understand that it's currently broken, at least in Linux and Windows, but it seems like the responsibility of the operating system to get right, not every application.

/Daniel

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Heather Miller]

On Tue, Jan 5, 2016 at 8:58 AM, Yoav Weiss <yo...@yoav.ws> wrote:

Just had a long off-list discussion with Noel. I'll do my best to summarize it here:

* In order to maintain color consistency between the page elements, we would need to correct CSS (including gradients), images, videos, canvas (and perhaps plugins) at the same time.

* Since drawing is not necessarily centralized, making sure that no piece of code is drawing before correcting is not trivial.

* The Skia team will also have to implement color correction.

Skia is getting serious about this starting 1Q/2Q this year.  Plumbing was done last year to support sRGB data being attached to Sk images/surfaces, and sRGB texture support was added on the GPU side.  There is a ton of work left to carry the support through the pipeline, and many performance considerations to weigh.  Support will likely come first to Ganesh, then software.  These discussions and additional test data will be helpful for us to understand who/how it will be implemented in Chrome.

* Gradients may pose an issue since in sRGB=>wide gamut conversions they can create banding artifacts. Can be overcome for CSS gradients but not necessarily for image gradients.

* The use-case of not having to send sRGB profiles for sRGB images can be resolved by adding a low overhead sRGB profile to the standard, regardless of automatically converting no-profile images from sRGB to the display color space.

* We need to gather data on which color profiles we see in the wild. UMA is being added. I'll try to gather some data as well.

* In general color correction in not a panacea, as it has performance costs, but most importantly, can result in its own color distortions.

* Some of the impact of sending sRGB to wider gamut screens can be minimized by users adjusting their screen settings, or sites picking "toned down" colors.

* On mobile, no browser seems to be doing color correction, even for profiled images. Also, the screen gamuts there do not exceed that of sRGB. Therefore, it makes sense to send only no-profile sRGB images to mobile.

* Perf concerns can be somewhat alleviated by applying color correction only when needed, offloading to GPU, etc. Distortion can also be reduced in some scenarios.

* A "display profile" client hint could make sense here, and help developers send sRGB images to sRGB screens while sending wider gamut images to wider gamut displays.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Torne (Richard Coles)]

On Tue, 5 Jan 2016 at 15:17 Daniel Bratell <bra...@opera.com> wrote:

On Tue, 05 Jan 2016 11:11:50 +0100, 'Ruud van Asseldonk' via blink-dev <blin...@chromium.org> wrote:

On Monday, January 4, 2016 at 10:53:28 PM UTC, Yoav Weiss wrote:

Otherwise, images that do not contain an ICC profile are considered to be in the display color profile space rather than in the sRGB space. This is again similar to Firefox, but contrary to Safari. 

+1 for assuming sRGB if the color space was not specified, the meaning of the pixels in the image cannot possibly depend on the user’s configuration.

More food for thought: is it Chrome’s responsibility to output anything different than sRGB?

I think this was a very good question. Is it really every program's responsibility to adapt to the screen currently connected? What if there are more than one with different color profiles? What if half of the browser is on one screen and half on another?

It seems like one issue is that if Chrome just outputs sRGB all the time and relies on the OS to correct it again, then any images that aren't in sRGB will get converted twice, which may lose information.

[Daniel Bratell]

On Tue, 05 Jan 2016 16:35:23 +0100, Torne (Richard Coles) <to...@chromium.org> wrote:

On Tue, 5 Jan 2016 at 15:17 Daniel Bratell <bra...@opera.com> wrote:

On Tue, 05 Jan 2016 11:11:50 +0100, 'Ruud van Asseldonk' via blink-dev <blin...@chromium.org> wrote:

On Monday, January 4, 2016 at 10:53:28 PM UTC, Yoav Weiss wrote:

Otherwise, images that do not contain an ICC profile are considered to be in the display color profile space rather than in the sRGB space. This is again similar to Firefox, but contrary to Safari. 

+1 for assuming sRGB if the color space was not specified, the meaning of the pixels in the image cannot possibly depend on the user’s configuration.

More food for thought: is it Chrome’s responsibility to output anything different than sRGB?

I think this was a very good question. Is it really every program's responsibility to adapt to the screen currently connected? What if there are more than one with different color profiles? What if half of the browser is on one screen and half on another?

It seems like one issue is that if Chrome just outputs sRGB all the time and relies on the OS to correct it again, then any images that aren't in sRGB will get converted twice, which may lose information.

Now this seems very hypothetical but I would add some APIs that could transfer image data lossless (or nearly lossless) for applications that really care. Most applications would not care.

But apparently hypothectical. I guess this is just something where operating systems have screwed up and noel and yoaw and others try to do the best of things.