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.

[Peter Kasting]

On Mon, Jan 4, 2016 at 2:52 PM, Yoav Weiss <yo...@yoav.ws> wrote:

2) Image color management

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

Only for certain image types.  I don't believe we respect the color profile for GIFs, for example.

I would like to see us address color management shortfalls.  We've had many complaints for years from graphic designers, photographers, website designers, and others about problems in this area.

PK

[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

[Nico Weber]

This only makes sense if you have a color profile of the display device, right? Else you don't know what space to convert to. Is having the right monitor color profile common on Windows / Android?

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

[kar...@gmail.com]

Hello, All!

I’m just a Photoshop guy, but very much interested in this and some movement in Chrome/Blink would be much appreciated! Currently, Chrome is the worst when it comes to colour (more apparent the more one’s monitor strays from sRGB). I think it would be great if Chrome considered adding (in order of importance):

1. a default assumption of sRGB of anything without the embedded colour information (Yoaw summed them all up well in 1st point of a summary from a conversation with Noel). I do not think that we will be better waiting for all these elements to be ready as there are already inconsistencies and getting images and CSS ready would cover most cases anyway.

2. a conversion from that assumed sRGB (and all other defined profiles) to the display profile (or profiles in case there are more monitors).

3. an implementation of a long-awaited http://www.w3.org/TR/2001/PR-SVG-20010719/color.html for all CSS. This would alleviate the “wastefulness” of sending colour profiles with every image. It would be good if that allowed for defining a default colour profile of all elements on a page that DO NOT already contain colour profiles.

I would also like to relate to some statements in this thread to the best of my knowledge (which may be wrong/outdated :):

 CSS colors are sRGB

They aren’t. They are just colours without meaning. Even though the spec says they should be assumed to be sRGB, Chrome does not treat them as such (Safari does, Firefox with a setting does too).

color managing CSS will break content

It’s all broken to one extent or another already, so that making it better (let alone perfect in one go) couldn’t hurt.

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.

Only for these instances when the colours from images must match with CSS elements (more important in SVG and PNG, I would say). If that’s what’s needed, then these (and only these) images should be send/defined as having the same colour space as CSS (sRGB most likely, but with option 3 implemented - any, really). But when the colour management works correctly, even if different elements do NOT share the same colour space - they can match visually! They just have to be prepared with correct conversions up front and have different RGB numbers that will translate to the same colour on output.

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

I wouldn’t know, but most probably: maybe. Ideally, though, this would work like with recent switch to better font rendering path in Chrome - more robust, more correct and faster ;-)

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

If that’s for real (I can’t believe Spyder software does what’s suggested!), then I would say: because somebody is gravely mistaken, this does not mean we should not try to be right.

 This only makes sense if you have a color profile of the display device, right? Else you don't know what space to convert to.

Every display has some colour profile (either explicit - is profiled - or assumed). This has nothing to do with the actual calibration of the display. I wouldn’t know but I would think applications should look to OS to provide that info.

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.

Explicitly embedding in images something like TinysRGB? Yeah, but it won’t solve zylions of images without profiles already in the wild not displaying correctly...

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

I know of only one said “distortion”. That’s when a user has a broken display profile. Although very rare, it was more common some time ago (I have no data, though - that data would be nice to see!). That is why, I believe, IE is or used to, incorrectly!, convert to sRGB on output instead of to display profile. My personal opinion is that this rare situation and is better handled by the OS (I think my Win10 does not allow some whacky profiles I used to have to test that situation in the past...). Better colour for the majority should win here. And IE should change policy, too.

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.

Err, the first option may work on some high-end displays (an “sRGB” mode), but doesn’t on most. And it just hides the errors, not fixes them. As for the second one... it makes no sense whatsoever, sorry.

Also, the screen gamuts there [on mobile] do not exceed that of sRGB. Therefore, it makes sense to send only no-profile sRGB images to mobile.

That’s wrong. I would say we can thank proliferation of mobile devices for faster developments in display tech. And they were the first (and still are) to have ever wider gamuts. This has nothing to do with the mobile OSes actually providing any useful info/control over them - I would have no idea here. And while it may look like it makes sense to send unprofiled sRGB images to non-colour managed systems, I think that’s a dangerous and short-sighted policy for which we are already suffering on desktops. Unless http://www.w3.org/TR/2001/PR-SVG-20010719/color.html for all CSS gets implemented quickly ;-)

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.

Hmm, that’s an interesting idea, but unnecessary with working colour management (unless: we would like to off-load conversions to the server solely for performance reasons). I could think of many more important client hints useful for imagery than this one (e.g. network conditions sniffing!). And instead of waiting (and people spending time) for this implemented, I would much rather wait less for the proper colour management.

 

Sorry for the lengthy post, I hope it isn’t wortless. I am super-excited to finally see some movement from Chrome here. Maybe one day I may even consider using Chrome on a wide gamut display? ;-) Big thanks for everybody here! And there.

Regards

m.

[kar...@gmail.com]

Sorry, just noticed that in my post above http://www.w3.org/TR/2001/PR-SVG-20010719/color.html should read http://www.w3.org/TR/css3-iccprof#icc-color.

Thinking about that spec (if I understand it correctly, that is)... Auto is what browsers should do without the spec being implemented at all. There may be some uses for sRGB and <uri>, but I can’t think of one, really, because they both override profiles already embedded.

In my humblest of opinions it should just have sRGB and <uri> and and override switch. With override switch switched on they would both behave as they already do in the spec (not that useful). With the override switch switched off (default), all elements without a profile would be assumed to be either sRGB or <uri>, BUT, crucially, elements that do have an embedded profile (either inside or by local application of a color-profile CSS property) would be treated as such.

Also browsers would be required to provide images on save to local devices to inherit the profiles based the above. Then the only weak link would be linking images without profiles (maybe a link could contain colour info?).

That would allow for not having to embedd profiles in images while at the same time to be able to override that flexibly whenever needed. The completely crazy ideas would be to be able to specify different policies and assumptions for different colour models (like CMYK) or for different types of elements (e.g. gradients).

Regards

m.

[Justin Novosad]

On Tue, Jan 5, 2016 at 2:32 PM, <kar...@gmail.com> wrote:

color managing CSS will break content

It’s all broken to one extent or another already, so that making it better (let alone perfect in one go) couldn’t hurt.

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.

Exactly. I think that is the main thing that breaks by switching CSS to sRGB, but if we do it at the same time as we change profile-less images to be interpreted as sRGB, we may be in the clear.

Only for these instances when the colours from images must match with CSS elements (more important in SVG and PNG, I would say). If that’s what’s needed, then these (and only these) images should be send/defined as having the same colour space as CSS (sRGB most likely, but with option 3 implemented - any, really). But when the colour management works correctly, even if different elements do NOT share the same colour space - they can match visually! They just have to be prepared with correct conversions up front and have different RGB numbers that will translate to the same colour on output.

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

I wouldn’t know, but most probably: maybe. Ideally, though, this would work like with recent switch to better font rendering path in Chrome - more robust, more correct and faster ;-)

I would imagine the transition to having a color managed pipeline would happen in stages, with the end goal being a correctly color managed pipeline with device-independent rendering, and with no loss of gamut or precision. To achieve that end goal, we would need content rendering and compositing to happen in some reasonable linearized profile connection space.  That will have costs in terms of processing and memory consumption, and perhaps this should only ever be enabled on devices with high capabilities.

A reasonable compromise, which is low hanging fruit in terms of implementation and in terms of resource consumption is to render and composite content in output referred color space (after the display or printer's profile has been applied). To achieve this, the current rendering pipeline does not need to be touched. We just need to apply sRGB->output space conversions upfront to CSS and profile-less image media, and continue we we are already doing for color-managed media. The upfront conversion of media from input to output referred color spaces allows us to avoid gammut clamping and color banding without increasing the bit-depth of the intermediate render buffers.  Image color correction can continue to be baked-in to the image decode cache, like we do today for images with color profiles, this avoids having to color correct the content repeatedly at each frame. The cons of this compromise are that compositing, filtering (CSS/SVG) and interpolation (images stretching, gradients) would happen in output referred color space (as opposed to a device-independent linear space), so the results would not be totally device independent, but we'd still be in much better shape than today with no extra RAM or VRAM consumption and very little extra processing.

What we must *not* do is use sRGB as an intermediate space for content rendering. Doing so will regress gamut and precision. Right now, images with embedded profiles are unclamped in Chrome, and we need avoid regressing that. In Chrome today, for example, if you observe a wide-gammut image on a wide-gammut display you get the right thing (correct colors, no banding, and no color space clamping). This is because we convert directly from input to output spaces in a single step during image decode.  

To use a device-independent linear intermediate color space without any rendering quality regressions, we will have to transition to higher bit depth render buffers.  I don't see any way around this.

Every display has some colour profile (either explicit - is profiled - or assumed). This has nothing to do with the actual calibration of the display. I wouldn’t know but I would think applications should look to OS to provide that info.

Correct. Chrome does this today.

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

I know of only one said “distortion”. That’s when a user has a broken display profile. Although very rare, it was more common some time ago (I have no data, though - that data would be nice to see!). That is why, I believe, IE is or used to, incorrectly!, convert to sRGB on output instead of to display profile. My personal opinion is that this rare situation and is better handled by the OS (I think my Win10 does not allow some whacky profiles I used to have to test that situation in the past...). Better colour for the majority should win here. And IE should change policy, too.

Anecdote: This problem actually just happened to us with the 2015 iMac lineup (the ones with P3 displays) see crbug.com/562951, comment #4

    -Justin

[linhng...@gmail.com]

Is this the correct issue that would be related to this https://bugs.chromium.org/p/chromium/issues/detail?id=294598 ?

Would staring that issue bring more attention to it possible?  This has been a long going issue for me in Chrome. I know there used to be a very long issue on this that was starred to death, but I can't find it anymore.

[Stephen Chenney]

Color management is enabled by default in Chrome 61. If it is not behaving as expected, file a bug at crbug.com and include your color profile. There are some known issues that are being worked on, and you can always disable color management in chrome://flags.

Stephen.

On Tue, Oct 3, 2017 at 4:21 PM, <nathanie...@gmail.com> wrote:

I'm comparing my website (photography) in both edge and chrome, Chrome colours are sickly and for the life of me I have not been able to find a solution or rational explanation. Gobsmacked at how bad this is. Has a solution been arrived at? I'm using a wide gaumut 99% Adobe rgb profiled monitor

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/076086a1-583d-494d-b1b3-3ab0245eb492%40chromium.org.