Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 272 users

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Duplicate
Merged: issue 667431
Owner:
Closed: Nov 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature
CSS

Blocked on:
issue 644545



Sign in to add a comment
Unmanaged CSS colors
Reported by ctrlfrea...@gmail.com, May 23 2010 Back to list
Chrome Version       : 5.0.375.55 (Official Build 47796) beta & 6.0.408.1 (Official Build 47574) dev
URLs (if applicable) : all
OS version               : 10.6.3 (64-bit kernel)
Behavior in Safari 3.x/4.x (if applicable): FAIL
Behavior in Firefox 3.x (if applicable): OK (requires gfx.color_management.mode setting set to 
non-default value "1")
Behavior in Chrome for Windows: unknown, likely FAIL

What steps will reproduce the problem?
1. Use a wide-gamut monitor (or monitor with non-sRGB color profile
2. View any webpage with CSS colors
3.

What is the expected result?
Correct, color-managed CSS colors displayed.

What happens instead?
Incorrect, over-saturated CSS colors displayed.

Please provide any additional information below. Attach a screenshot if
possible.
The following website shows CSS colors vs. ICC-tagged images of the same color and shows their 
differences: <http://www.libpng.org/pub/png/colorcube/colorcube-pngs-iCCP-CSS.html> 
Screenshots of this page in Chrome and Firefox when viewed on a profiled wide-gamut monitor 
are attached.

This behavior appears as if it may also be a violation of the CSS specification: 
<http://www.w3.org/TR/REC-CSS1-961217#color-units>
 
Firefox managed CSS colors.png
82.4 KB View Download
Chrome unmanaged CSS colors.png
65.7 KB View Download
Note that tested Safari version was 4.0.5 and tested Firefox version was 3.6.3
Labels: -Area-Undefined Area-WebKit
Labels: -Type-Bug Type-Feature
Status: Untriaged
Checked in 6.0.415.0 (Official Build 48118)
Comment 4 by karen@chromium.org, May 26 2010
Labels: CSS Mstone-X
Comment 5 by kerz@chromium.org, Jul 8 2010
Status: Available
Moving all bugs marked as untriaged and mstone X to be available rather than untriaged.  If you think this is in error, please feel free to set back to untriaged.
Was this issue resolved?  The last three comments (Untriaged, labels, etc.) make sno sense.

This is actually a W3 standard for CSS: http://www.w3.org/TR/2010/PR-css3-color-20101028/
Comment 8 Deleted
We must make sure this gets fixed alongside the issue for sRGB interpretation of untagged images:
http://code.google.com/p/chromium/issues/detail?id=37028

Both issues must get fixed in the same release so we're not left in a state where colors in untagged images no longer match colors in CSS (which is currently the only reliable way to ensure colors in images match colors in CSS at all).
Here's the most up-to-date recommendation from W3C:
http://www.w3.org/TR/css3-color/
Comment 11 Deleted
Comment 12 by Deleted ...@, Feb 11 2012
I see that this has been fixed in Chrome Canary version. Any word on when this be rolled into the public Chrome version?
This does *not* appear to be fixed in the current canary (19.0.1039.0) on Mac OS 10.7.3. The test page <http://www.libpng.org/pub/png/colorcube/colorcube-pngs-iCCP-CSS.html> still fails.
Comment 14 by Deleted ...@, Feb 12 2012
I see what you mean on the test page. I don't know the full scope of the issue. I am seeing a png without an ICC profile displaying correctly in Canary (19.0.1039.0) vs in the public version which immediately gave me hope that the issue was close to being resolved.
Comment 15 by Deleted ...@, Jun 28 2012
I got this issue in Version 20.0.1132.43

I switched from my laptop display to an external display and the colors are now crazy. Restarting fixed it.
Comment 16 by tszm...@gmail.com, Jul 7 2012
Still have this issue with 20.0.1132.47.

Btw, this is not a feature, this is a huge blocker if you are doing serious web development.

Cc: tpayne@chromium.org
Labels: Feature-Color-Management
Comment 19 by preby...@gmail.com, Aug 10 2012
WHAT THE FUCK!
Comment 20 by Deleted ...@, Sep 22 2012
Still happening in Chrome 21.0.1180.89 (Build oficial 154005), Win 7 x64, using a calibrated Dell u2711 using a ColorMunk Display. Colors appear OK in Firefox.
Comment 21 by white...@gmail.com, Oct 27 2012
This article provided a fix to this issue,
http://www.brilliantthinking.net/2012/08/06/how-to-fix-screen-colour-changes-in-mountain-lion-osx/
Comment 22 by Deleted ...@, Dec 27 2012
I get exactly the same issue with just my normal MBP display (i.e. no external monitor). The Brilliant Thinking article did nothing to help. This is really really annoying for web developers!
This appears to be happening in Chrome 24.0.1312.52 using an external monitor (an HP LP3065) under Mac OS 10.6.8 on a late 2007 MacBook Pro.

The colors reported by DigitalColor Meter do not match those specified using CSS or HTML. The reported colors change if you select a different color profile for the monitor. Also, the appearance of certain images, such as the Google logo, is degraded. The problem disappears if you drag the window onto the MBP's built-in display.

The problem vanishes if Flash starts up on the page. To demonstrate this, configure plugins to require a click to play. Then load a page that has Flash ads, such as http://www.w3schools.com/html/html_colors.asp. Observe that the colors are wrong, as reported by DigitalColor Meter. Then click one of the Flash ads, watch the muted colors instantly brighten, and use DigitalColor Meter to verify they are now correct.

Safari 5.1.7 (6534.57.2) also exhibits the problem.  Firefox 18.0 and Opera 12.11 do not.
Comment 24 by Deleted ...@, Feb 21 2013
This still happens on  Chrome 24.0.1312.57  on 

Built-in iMac Display  

27-inch (2560 x 1440)

AMD Radeon HD 6970M 2048 MB graphics

 Ironic that it  happens on a product from a company famous for testing 41 shades of blue.
Project Member Comment 25 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-WebKit Cr-Content
Project Member Comment 26 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Comment 27 by aime...@gmail.com, Jul 8 2013
As of 2013, this is still an issue. I have my Macbook connected to an external Dell monitor. Connecting the Macbook to a different monitor seems to reproduce this issue.

My info:

Google Chrome: 27.0.1453.116 (Official Build 206485) 
OS: Mac OS X 
WebKit: 537.36 (@152168)
Reproduced using Macbook 5,1 with iMac as primary display.

Google Chrome: 31.0.1613.0 canary
OS: OS X 10.8.4

I had the same thing here on a Dell U2711 via direct displayport on late 2011 MBP.

Repair permissions reported and repaired deviations on “System/Library/PreferencePanes/Displays.prefPane/Contents/Resources/French.lproj/DisplaysPref.nib”

After restarting Chrome the curtain of drabness disappeared.
Comment 30 by Deleted ...@, Oct 23 2013
Still having this issue in Chrome on Mac. Renders fine in other browsers and we can reproduce it with multiple computers using color code #e85959
Comment 31 by Deleted ...@, Oct 27 2013
I'm having this issue as well. Safari works fine, but Chrome displays the wrong colors. Looks like something with the color profile in OS X, because when I switch between those profiles then Safari displays instantly the new color but Chrome displays always the same wrong color.

Macbook Retina 2012 with Dell u2711 via DisplayPort.
I have this issue as well on MacBook Air (Mavericks). Chrome does not map the CSS color values to the native color profile unlike Safari. On a wide-gamut monitor, colors in Chrome look washed out. If I set my monitor's color profile to sRGB, the issue goes away. I would prefer Chrome map appropriately to the native color profile.
Issue still exists in current Version.

It would be nice if this could be done like described in the Standard (w3c)

untagged images -> assign sRGB Profile
CSS Colors -> consider them as being in sRGB and convert them. CSS Color values > 100% are possible and only displayed if the gamut allows it (output profile). Otherwise they are clipped at the max. possible value.

Implementing both at once ensures, there is no problem with images not looking like the css colored background around them (if they should represent the same color)
Comment 34 by pdknsk@gmail.com, Mar 6 2014
Chromium developers have previously stated this won't be supported for reasons mentioned in this old post.

https://www.webkit.org/blog/73/color-spaces/
In that article, the Flash argument is now somewhat obsolete; so is the performance issue. We should rethink about it.
Also, if you make this a feature that isn't enabled by default, the performance argument is moot.
Comment 37 by pdknsk@gmail.com, Mar 15 2014
It was a stupid argument to begin with.

And performance is a non-argument IMO. I did some benchmarks on qcms, the color management engine uses. It's very fast. Transforming a 4096 x 4096 image with all 256^3 RGB colors takes 0.18s on a not particularly fast i3 Haswell. Fast enough even for 4K displays.

I figured out it's so fast because it does precaching on the output profile, which is always the same. I'm not exactly sure how this works. The speed increase is significant for some reason.

This could be made even faster. Why? The input profile is always sRGB! The transform could just be stored in a LUT, which could be build on Chrome start in a fraction of a second. It'd take 256^3 * 2 bytes in memory though, I think. Still not so much, when Chrome uses many hundred MBs easily. This could be improved by filling it lazily, as only a low percentage of RGB colors are probably used practically.

The same LUT could be used for images without profile, as discussed in issue 37028.

So the only obstacle for this is really that someone from Google needs to do it.
Comment 38 by pdknsk@gmail.com, Mar 15 2014
PS. I meant the Flash argument is stupid.
On my mac, not in sRGB profile, the test page is now loading fine in Chrome. Has this been fixed?
More specifically, I think the test page was only measuring gamma correction. So it looks like the issue now is whether the sRGB color (in CSS values) is converted to the monitor's color profile. It doesn't appear to be.

This hasn't been fixed. Custom calibrated monitor profile, Mavericks, latest Chrome.
Safari renders the colors approximatively correct (there are few exceptions) but with Chrome, every single box is a miss...
Comment 42 by Deleted ...@, May 1 2014
I just noticed this is not fixed in Chrome Version 34.0.1847.131 m. IE looks natural and Chrome looks terrible.

mustangorange.JPG
121 KB View Download
Comment 43 by pdknsk@gmail.com, May 2 2014
#42: That's a different related bug.

https://code.google.com/p/chromium/issues/detail?id=37028
Comment 44 by pdknsk@gmail.com, May 2 2014
And some potentially very good news for this bug.

https://code.google.com/p/chromium/issues/detail?id=368694#c11
Seeing large color inaccuracy on a wide gamut display (Dell U2711), but also slight color differences on my regular display (Macbook Pro). Both Chrome and Firefox render the same, while Safari is in agreement with a sRGB photoshop document. I noticed the problem in the CSS colored logo on this site: http://mattbierner.github.io/nu/

First attachment is rendering on a wide gamut display. Safari (left) and Photoshop: sRGB(0.44, 0.7, 0.99).  Firefox (middle) and Chrome (right): sRGB(0.20, 0.71, 1.00)

Second attachment is rendering on my regular macbook display. Safari (left) and Photoshop: sRGB(0.18, 0.72, 0.98). Firefox (middle) and Chrome (right): sRGB(0.20, 0.71, 1.00).


Latest public releases of all three browsers. These are not subtle differences.
macbook-s-f-c.png
146 KB View Download
wide-s-f-c.png
116 KB View Download
Spring 2015 and still the same issue. Alas, Google's Chrome browser does not render colour correct. Colours are still hugely oversaturated. 
It happens in Linux too, only with some shades, but not as much as in OS X.

Almost 5 years, about 40 versions of Chrome later, this is still unresolved.
They are not just oversaturated, they are also undersaturated when it comes to flashy green colors…
Comment 49 by Deleted ...@, Mar 19 2015
I don't understand how this bug has remained open for so long! This is a pretty important issue for anyone in the design industry, ESPECIALLY when dealing with clients and brand specific colors.
Comment 50 by noel@chromium.org, Apr 8 2015
Cc: noel@chromium.org
Issue 324201 has been merged into this issue.
Comment 51 Deleted
Comment 52 by Deleted ...@, Apr 11 2015
I'm having the same problem. And this is evident in this video https://vimeo.com/122709284 when played in mac chrome and when played in any other brownser. In this attachment you can see a photo of a scene of this video. In the left side is safari in the right is chrome and in the bottom it is the original file.
Screen Shot 2015-04-11 at 3.20.48 AM.jpg
904 KB View Download
Comment 53 by b...@cleverbug.com, May 11 2015
I'm not a designer, but that bug cause annoying for me too :'(  Interesting that you can see proper colors if move another window over chrome window, looks as blending happens in another color space.
Comment 54 by Deleted ...@, May 14 2015
Confusing why this hasen't been fixed — I love chrome's tools for web development but can't use it in my colour managed environment.
Comment 55 by tri...@gmail.com, Aug 26 2015
For as much as google tries to enforce proper web coding, they really need to fix this issue. 

If using brand colors in a web design, the only way to get them to be at all close to accurate is to use a color managed png. You can see here how off some of these css colors are, especially in the oranges and purples: http://www.libpng.org/pub/png/colorcube/colorcube-pngs-iCCP-CSS.html

Another issue, on Mac, is that any time a window is above the chrome window, the area where the shadow is cast is the proper color. It makes the page look very broken.

It's astonishing that this has been open since 2010, is there some reason this has been ignored?



> It's astonishing that this has been open since 2010, is there some reason this has been ignored?

Because it's not clear how to fix it? :)
It’s not an issue in Safari. What are they doing differently in this regard?
Comment 58 by arn...@unraad.com, Aug 26 2015
The thing is that it's not just a Mac problem (despite being tagged as one).
The same problem is happening on Windows (except the odd thing with the shadows). And I'm pretty sure it's an issue on Linux too.
It’s not an issue in Safari. What are they doing differently in this regard?
Comment 60 by b...@cleverbug.com, Aug 26 2015
Chrome definitely not applying current display's color profile (ICC-profile) that's why it may look differently on different screens and that's very annoying :( Safari doing that, btw. Both based on WebKit (once), but that ICC stuff is probably separate to browser engine.
Same problem here :
displayed images in safari are fine
displayer images in chrome are over saturated

(mac osx 10.10.5)

While making my Finder to Cover Flow mode, it shows the same problem.
All the apps on macOSX (and Windows) are not working fine. 
Some of the boxes on that gamma test page definitely include smaller off color boxes in them on my Windows 7 system with Chrome, so the problem is not unique to Mac on that regard.
I'm posting here because this is a HUGE issue for me as my monitor is 99% Adobe RGB. I'm forced to leave Chrome only for this.
Comment 64 by Deleted ...@, Oct 26 2015
Having this issue with Chrome Version 46.0.2490.80 vs Safari 9.0.1. Seems less of a problem with tagged images than with CSS colors, etc. Attached is PNG of Google splash comparison.

Mac Pro (Late 2013)/ AMD FirePro D300/ Eizo ColorEdge CX240
Screen Shot 2015-10-26 at 11.00.42 AM.png
2.2 MB View Download
Having a bug that directly impacts the work of creative professionals open for over 5 years is surprising. I'm very much looking forward to a fix so I can once again trust the colors being displayed in Chrome.
I work for a Creative Agency and we are having problems with our final products because of this bug!
Comment 67 by Deleted ...@, Dec 9 2015
Do we have any temporary solution while chrome team is working on this issue ? It will really help to people who are having problem with their pending task because of this issue.I will really appreciate for your help if we can get the solution asap.
Comment 68 by Deleted ...@, Dec 11 2015
Experiencing this issue with Chrome on OS X as well. Wildly different CSS colors displaying in Chrome, sometimes making it impossible to match image colors with CSS colors.

Please fix!
Screen Shot 2015-12-10 at 17.08.37.png
109 KB View Download
Screen Shot 2015-12-10 at 17.10.51.png
22.8 KB View Download
Comment 69 by noel@chromium.org, Dec 11 2015
#68 > sometimes making it impossible to match image colors with CSS colors.

How difficult is it to convert your images to sRGB?
Comment 70 by chik...@gmail.com, Dec 11 2015
#69 Even if the images were tagged as sRGB they wouldn't match because CSS colors aren't color managed and so would look different than the colors in the images on any calibrated monitor that wasn't perfectly sRGB out of the box.
Comment 71 by njdo...@gmail.com, Dec 11 2015
The problem is it is today impossible to get universally accurate and consistent colours.

You can get consistency with CSS by having all of your images untagged. The problem with untagged images is that Chrome assumes they are in the colour profile of the display, not sRGB, which is a bug.

You can get colour accuracy in images if you attach a colour profile (at a non-trivial byte expense) but even if the images are tagged, the CSS colours are also assumed to be in the colour profile of the display, this leads to colour mismatches between images and CSS colours.

In all cases, it seems you can not get colour accuracy with CSS.

Unless otherwise specified (tagged), colours should be interpreted as sRGB. Chrome does the wrong thing and interprets the colours as being in the display's colour profile, not sRGB.
Comment 72 by noel@chromium.org, Dec 11 2015
Covert your images to sRGB.  Remove the sRGB "tags" from the image.
Comment 73 by chik...@gmail.com, Dec 11 2015
#72 Then they will display incorrectly because Chrome assumes untagged images to be in the display's color space which on any calibrated monitor will not be exactly sRGB.

Rather than ask everyone on the web to incorrectly tag their images it would be better to just fix this issue and issue 37028 which are both more than 5 years old so that Chrome follows the W3 spec for treating untagged CSS and images as if they were sRGB.
Comment 74 by njdo...@gmail.com, Dec 11 2015
#72 As I said, that will get you consistency with CSS colours at the expense of the colours not being actually correctly shown on the display. This is super obvious and problematic when using Chrome on any display that doesn't closely conform to sRGB. In my experience, even common displays like that in the MacBook Air are enough to get people to complain.
Comment 75 Deleted
Comment 76 by noel@chromium.org, Dec 11 2015
> #72 Then they will display incorrectly because Chrome assumes untagged images to be in the display's color space which on any calibrated monitor will not be exactly sRGB.

But they will match CSS color, right, and the images will be smaller and faster image to load for users.  That saves them time and money, particularly on low-bandwidth mobile connects where users pay-by-the-byte.  If you know what you are doing, you would not send tagged images to mobile users at this time.

For desktop users, sRGB is the default monitor profile on Windows, for example, and things work and color match and are accurate to the conditions ... right up until the user intentionally re-configures their monitor profile to something that is not sRGB.

Oversaturated color is a problem that can then result.  Oddly, some users like the effect (they feel their world is more colorful), but to me, overstaturation is color distortion.

How do web designers and web sites deal with that issue, since it not just Chrome where you'll see it btw (unmanaged CSS color, and the issue of users changing their default monitor profile, often to wide-gamut or LCD-like color space these days, etc).

Web designers tone their colors down to avoid the overstaturation effects that users with non-sRGB color profiles (wide, LCD) would otherwise see.  Not ideal, but that is what professional site designers currently do.
Comment 77 by njdo...@gmail.com, Dec 11 2015
#76

I understand very well that attaching colour profiles to images is very bad for performance. The problem is that because of this issue and issue 37028, it is absolutely necessary to attach colour profiles to get accurate colour. This /shouldn't/ be necessary and that's where the bug is here and with issue 37028.

I think you're misunderstanding how colour is defined and how profiles are supposed to work. Any colour on the web is to be assumed to be sRGB unless otherwise specified. Colour profiles allow you to convert from a colour defined in one profile to a colour in another profile.

The correct path is for untagged colours is:
1. Assume colour is defined sRGB.
2. Use display profile to convert sRGB colour for use on display.
3. Display colour

What is actually happening is this:
1. Assume colour is defined in the current user's display colour profile.
2. Display colour.

People often attach colour profiles to images (even the sRGB profile to sRGB images) to get this process:
1. Colour is defined in the attached colour profile.
2. Use display profile to convert attached colour profile colour for use on display.
3. Display colour.

If the first set of steps is followed you get smaller images because no attached profile is necessary and you get accurate colour for any display no matter it's profile.

Unfortunately, CSS colours always follow the second set of steps even though the W3 CSS specification says the first set of steps must be performed. That is this bug.

Desktop Safari does the right thing already. Firefox has a configuration flag to do the right thing (not optimal but at least it's there). Chrome just does the wrong thing all together.
Comment 78 by noel@chromium.org, Dec 11 2015
#76 > I understand very well that attaching colour profiles to images is very bad for performance.

It is, but yet you still advocate for the performance hit that results, saying that 

> it is absolutely necessary to attach colour profiles to get accurate colour

Is that true in all cases?  It seems to be the wrong advice if you mean do it always.  It's clearly the wrong for mobile users.  But let's talk desktop.

> What is actually happening is this:
> 1. Assume colour is defined in the current user's display colour profile.
> 2. Display colour.

Fine, so if the CCS colors of you web UI, and the images you want to match to them have no color "tags" as I suggested, then they are treated exactly the same way - their colors match, and cross-browser too.

[Optional]: tone down the UI colors a bit to avoid overstatuation effects, for the smaller percentage of users who have fiddled with their monitor profile. (The vast majority of users don't know what a color profile is or does or even how to change it).

> it is absolutely necessary to attach colour profiles to get accurate colour

With the example just given, it's clearly not "absolutely necessary" and would in fact cause CSS colors to no longer match your UI image colors across-browser if followed.

> People often attach colour profiles to images (even the sRGB profile to sRGB images) to get this process:
> 1. Colour is defined in the attached colour profile.
> 2. Use display profile to convert attached colour profile ...
> 3. Display colour.

Agree, but why?  You do that because the image is _not_ some part of your CSS web UI, right?

It is most often some stand-alone <img>, usually containing a wide-gamut photograph for example.  And in that case, sure, it makes sense to include a color profile in the image as you say.  Chrome will color manage it, so will Firefox and Safari.

So one can achieve color matching across-browser, and also show stand-alone content images in their full, photographic color glory on supporting browsers, by ignoring the "absolutely necessary" advice.  For mobile users, such advice should be completely ignored, unless you think it's a great idea to waste their battery and their money.

> Desktop Safari does the right thing already. Firefox has a configuration flag to do the right thing (not optimal but at least it's there).

Ever considered why it not on in Firefox by default?

> Chrome just does the wrong thing all together.

Sorry but, given all the above, I certainly don't think you're the one to tell us what the "the right thing" is, or what's "absolutely necessary".  No offense intended :) 
This issue is not about CSS and images matching, nor is it about how color in tagged or untagged images is interpreted; it’s about how CSS colors are not being interpreted as sRGB despite it being the color space the CSS spec specifies them to be in [1][2]. Tagged images not matching the CSS colors is simply a convenient way to test that behavior (given that the browser correctly handles tagged images). Thus the performance of profile-tagged images is not relevant here.

A website developer/designer “toning down” the actual CSS colors is not fixing the actual problem. The developer/designer did nothing wrong: they specified the colors they want as they exist in sRGB, as per the CSS spec. The browser user did nothing wrong: they specified to their OS a correct, accurate color profile for their display (not because “like the effect” of oversaturated color, as instead accurate color is the goal). Chrome is doing the wrong thing: it ignores that CSS colors are specified to be in sRGB, and also incorrectly assumes that every user’s display will be exactly sRGB. The result is that Chrome renders an undeniably incorrect color when the user’s display profile is not sRGB.

Note that while the current CSS3 Color spec states “User agents may vary in the fidelity with which they represent these colors” [1], the current CSS4 Color draft contains no such allowance for variance and instead states as a rule that CSS colors are in sRGB and shall be interpreted as such [2].


[1] https://drafts.csswg.org/css-color-3/#numerical
[2] https://drafts.csswg.org/css-color/#sRGB
Comment 80 by noel@chromium.org, Dec 11 2015
#73 chiklit > Rather than ask everyone on the web to incorrectly tag their images

Stripping color "tags" from images does not incorrectly tag them.  It makes them smaller, faster, and puts them in the assumed-to-be-sRGB bucket.

> it would be better to just fix this issue and issue 37028 which are both more than 5 years old so that Chrome follows the W3 spec for treating untagged CSS and images as if they were sRGB.

Why would it be better?  Treating untagged things as sRGB and managing them as such, is a performance hit (see #77) for all our users.  Most users don't care about color, have no clue what a color profile is or how to configure it, let alone how to fix it when color goes wrong.  Why would it be better for them?


> #77 njdoyle I think you're misunderstanding how colour is defined and how profiles are supposed to work.

If we can't understand it, what chance do our everyday users have in understanding it and fixing things when they go wrong?

> Colour profiles allow you to convert from a colour defined in one profile to a colour in another profile.

OIC, so you do this conversion I assume when the two profiles are different?  (If they were the same, there's no point I suppose).

If they are different, then I guess the conversion from one to the other might lose some information?  Could colors change, or be clipped?  And when you said ...

> it is absolutely necessary to attach colour profiles to get accurate colour

"accurate colour"?  Unsure what that is.  If colors can change, or are clipped in the process you describe, that sounds like it would introduce color inaccuracies, no?
To noel@chromium.org:

I think you misunderstood this problem here, let me try to clarify this for you as follows:

1. For most of the users with an sRGB monitor, Chrome behave correctly. And this issue is not about these users.
2. For the user using a monitor with a color profile other than sRGB (usually with a larger colorspace than sRGB), the chrome behaves incorrectly because:
 
  1. All CSS colors are oversaturated.
    Because all css colors are treated as sRGB but my monitor has a larger colorspace and the colors are treated as if they are in my monitor's colorspace

  2. Every image without a color profile, is oversaturated as well, for the same reason as above. And such images are exactly what you advocated.

It's generally not good for the web developers to attach a profile to the images displayed in webpages, because

1. it makes them larger;
2. for sRGB images it should not be necessary because W3 specification suggest that sRGB color profile is by default.

And web developers have nothing to do with the incorrectly displayed colors in current Chrome for the users using a monitor with a color profile different than sRGB.
Comment 82 by chik...@gmail.com, Dec 11 2015
#80 > Stripping color "tags" from images does not incorrectly tag them.  It makes them smaller, faster, and puts them in the assumed-to-be-sRGB bucket.

This is incorrect. In Chrome it does not put them in the assumed-to-be-sRGB bucket. It puts them in the assumed to be in monitor's native color space bucket. And so they are being displayed incorrectly because they aren't getting converted by the OS from sRGB to the monitor's color space. This is true even of monitors that aren't wide gamut but have merely been calibrated because no monitor is perfectly 100% sRGB out of the box.

> Why would it be better?  Treating untagged things as sRGB and managing them as such, is a performance hit (see #77) for all our users.  Most users don't care about color, have no clue what a color profile is or how to configure it, let alone how to fix it when color goes wrong.  Why would it be better for them?

Well for one because that's what the spec says browsers are supposed to do and because Firefox and Safari already handle this correctly on OS X at least, I can't speak for Windows. And "because some users don't care about it" isn't an excuse for doing it wrong. If Chrome treated color profiles the way it's supposed to then display colors would be correctly for everybody instead of only being "correct" for people who have their monitor color space set improperly.

> OIC, so you do this conversion I assume when the two profiles are different?  (If they were the same, there's no point I suppose).
>
>If they are different, then I guess the conversion from one to the other might lose some information?  Could colors change, or be clipped?  And when you said ...

Yes. The thing is though, on a calibrated monitor the monitor color space will always be at least slightly different than sRGB and on wide gamut monitors will be vastly different than sRGB. And so there will always be a conversion. But treating images and CSS as the correct color space, either what it's tagged as or as sRGB if untagged, means that the OS will be able to do the conversion between sRGB and the monitor's color space and will render the colors as close as possible to the intended color because it knows what RGB value it needs to send to the monitor to cause it to display a specific color. As it is currently Chrome is telling the OS that it doesn't need to do any conversion on untagged images and CSS. And so it just passes the RGB values to the monitor unchanged which means that the monitor will output the wrong color and that the same color in an untagged and a tagged sRGB image will not match because the OS is correcting one and not the other.

> "accurate colour"?  Unsure what that is.  If colors can change, or are clipped in the process you describe, that sounds like it would introduce color inaccuracies, no?

Accurate color means that the color the monitor outputs is as close as possible to the color that is intended. Color profiles are used to correct for the fact that if you send the exact same RGB values to 10 different monitors and then measure the color output with a colorimeter you will find that the monitors are displaying 10 different colors despite each being sent the same value. A color profile allows the OS to say "I know what color this is supposed to be displayed as, and I know how different the monitor's color is from the image, so I will adjust the values I'm sending to the monitor to make sure that the monitor is actually outputting the intended color."

For example, say you want to display what's considered 100% green in an sRGB image. If you do no conversion and just send (0, 255, 0) to an Adobe RGB monitor it will output a totally different color than what you want because it thinks you mean 100% green in Adobe RGB. By handling color profiles correctly the OS will be able to realize that you meant to display 100% green in sRGB and so it needs to convert the RGB value from (0, 255, 0) to (158, 229, 76) before sending it to the monitor so it actually outputs the right color.

There will be inaccuracies and clipping when converting from a larger colorspace like Adobe RGB to a smaller color space like sRGB simply because an sRGB monitor is physically incapable of displaying all of the colors in the Adobe RGB color space. But by handling color management correctly you can at least ensure that the colors being output by the monitor will be as close as physically possible to the intended colors instead of the way it currently is where image colors can be very far off from the intended colors because Chrome is telling the OS it doesn't need to do color correction on anything that isn't tagged.
Comment 83 by tara...@gmail.com, Dec 11 2015
#80
>Why would it be better?  Treating untagged things as sRGB and managing them as such, is a performance hit (see #77) for all our users.  Most users don't care about color, have no clue what a color profile is or how to configure it, let alone how to fix it when color goes wrong.  Why would it be better for them?

So, for now, if you're not in this "most users" you just should quit using Chrome, right? 
Just make it optional. Like Firefox did. I understand it may be hard to implement this feature, may be it's no time for this now and it'll be postponed for next 5 years. But implementing it will definitely make Chrome just better. Problems on wide-gamut monitors is the ONLY thing that forces me and number of other people to use Firefox instead. 
Comment 84 by b...@cleverbug.com, Dec 11 2015
I'm already thinking about filling a petition on change.org just to break the deadlock...
Comment 85 by noel@chromium.org, Dec 11 2015
#80 > Stripping color "tags" from images does not incorrectly tag them.  It makes them smaller, faster, and puts them in the assumed-to-be-sRGB bucket.

> This is incorrect. In Chrome it does not put them in the assumed-to-be-sRGB bucket. It puts them in the assumed to be in monitor's native color space bucket.

For now.  If we turned on CSS color correction, then they'd be in the right bucket and be small and fast.  My point is don't try to force them in the right bucket by adding profiles to them, for now.
Comment 86 by arn...@unraad.com, Dec 11 2015
The funny thing is, as designers I think it is our duty to work with accurate colours (some may disagree).
So most of us will work with calibrated monitors which, as has been said many times, will differ from the sRGB profile.
So do we assume that we then don't need to see these accurate colours in Chrome ?

#85 > "For now" and for the past 5 years this bug has been open.
And I wouldn't say that people who calibrate their monitor "fiddle" with their profile. They're just using their monitor the way it's supposed to be.

Anyway, as has been said many times, the main issue here is that W3C's recommendation states that CSS and untagged colours should be displayed in an sRGB profile and that's all we've been asking for these last few years.
Comment 87 by sean...@gmail.com, Dec 11 2015
Has Google ignored this problem for half a decade because its own staff is ignorant/unconvinced of the utility of color management and conforming to color rendering standards? Must the case be made here, in this space??

If you're worried about the performance hit to the average joe, make it optional. Color professionals and enthusiasts with non-sRGB-calibrated displays will know to look for it, just like we already look for the color management toggle in Firefox (and various other non-professional software which optionally provide color-management). This has likely been mentioned a thousand times already, but Chrome's color management is incomplete. This is why, in the link provided in the original 2010 issue report, there is a discrepancy between CSS color values & tagged sRGB JPEG color values on a non-sRGB display. It reveals that color management is arbitrarily half-implemented in Chrome. Why not render the whole web properly, rather than partially?
chrome_partial_color_management.jpg
191 KB View Download
Comment 88 by chik...@gmail.com, Dec 11 2015
#85 > For now.  If we turned on CSS color correction, then they'd be in the right bucket and be small and fast.  My point is don't try to force them in the right bucket by adding profiles to them, for now.

I don't think anybody is suggesting retagging everything anyway. As you said, for now the best solution is to leave them untagged because then at least untagged images and CSS will both display the same wrong colors in Chrome and the same correct colors everywhere else. Though personally I would probably tag photos and just not UI elements that need to match CSS so at least photos will display correctly everywhere.
Comment 89 by noel@chromium.org, Dec 11 2015
#88 chiklit

> I don't think anybody is suggesting retagging everything anyway.

Yeah, I hope not.  And the solution I gave is the best option for now, given the current browser landscape, not just Chrome mind.  And it is future proof, say if all browsers decided to manage sRGB content sometime. Tagging content photos is fine, all browsers support that, well most all.

> just not UI elements that need to match CSS

Precisely.  Matching UI elements with UI images (I'm not taking about content images like photos to be clear) is a important [1].  Flash seems to be less used these days maybe, but that actually helps your cause. <video> is CSS but has a separate color space, that has to be corrected at 60 frames per second to match CSS colors, and is also when watched full-screen.  Takes a bit of compute horse-power to do.

[1] https://webkit.org/blog/73/color-spaces
Comment 90 by noel@chromium.org, Dec 11 2015
Let me back up a bit, for Andrew #79 and #81 sirxenofex.
Comment 91 by njdo...@gmail.com, Dec 11 2015
I'd just like to clear up some terminology.

Colour Accuracy
Assuring that a colour is displayed correctly to the best of a medium's ability over all displays and mediums.

Colour Consistency
If I use a colour more than once that it appear the same (even if it's wrong, it's at least consistently wrong).

Chrome breaks colour accuracy for all untagged images and for all CSS colours. Chrome breaks consistency when you have a tagged colour (even tagged sRGB) next to an untagged colour (supposed to be assumed sRGB).

The only reason things seem to work okay for most people is because their monitors are not displaying accurate colour and things are accidentally consistent because the monitor is being sent sRGB colour across the board as a best effort.

Many displays today ship with a best effort calibration that is not exactly sRGB. Many laptops today are shipped with a best effort profile already assigned to their monitor which is not sRGB. This was observed specifically on the MacBook Air; a very common device.

Automated image optimizers have been forced to conditionally keep a colour profile attached to optimized images when users insist on colour consistency with the input image. Even if all input is converted to sRGB, an sRGB profile needs to be attached to the image at the great expense of ~4KiB (per image) just to ensure consistency that is supposed to already be ensured by the W3 specifications.

Already today we've come to a place where big players are attaching a colour profile to every single photo just to get around these bugs. Facebook has come up with a clever way to reduce the ~4KiB sRGB profile to ~0.5KiB. They attach it to every photo to account for these bugs. ~0.5KiB per image still sucks a lot though when the cost should be 0B.
https://www.facebook.com/notes/facebook-engineering/under-the-hood-improving-facebook-photos/10150630639853920/

This bug and issue 37028 are literally responsible for half a kibibyte of should-be-unnecessary bloat on every single image coming from Facebook and inhibits image optimizers that must maintain colour consistency. That is a ton of wasted bytes in the context of the internet.
Comment 92 by noel@chromium.org, Dec 11 2015
> #81 sirxenofex

> 1. For most of the users with an sRGB monitor, Chrome behaves correctly. This issue is not about these users.

Yes it does behave correctly, and they are the vast majority of our users, they're viewing conditions are sRGB and we do care about performance here for them. Chrome works for them as you say, and so if ain't broke ...

This problem is not about color per say.  I think part of the problem is normal users don't care about color (I'm sure you folks do).  It's not important to them because they don't have problems.  User happiness unlocked and best not to disturb them.

However, for people providing the content, it's not so easy because ...

> 2. For the user using a monitor with a color profile other than sRGB

The minority reports.  Yes as you noted these users can experience the problems of color overstaturation in their wide-gamut viewing conditions - assuming web site designers did not try to compensate their content for that fact of life /sadface

> It's generally not good for the web developers to attach a profile to the images displayed in webpages, because ...

Yes, and you listed good reasons why, and it also costs users real money sometimes (eg., due to poor process delivering image content to mobile users).

We should however qualify that "generally not good to" statement: for stand-alone content images in desktop browsers, photographs an such - being images that do not need to match CSS like UI images - then no problem, include the color profile. 


> #79 andrew@johnandrewmarshall.com

> A website developer/designer “toning down” the actual CSS colors is not fixing the actual problem.

And I agree Andrew, but it is the sad reality they face today. They can either cry or deal with it and the professionals do deal with it in the manner I described: they tone colors down, shift them s bit toward sRGB, so that those in the minority with wide-gamut viewing conditions see something reasonable and pleasing too.

Service providers might not like having to do it, but when they do make the effort, wide-gamut users are happier, they have less overstaturated color.  Folks with sRGB viewing conditions are fine too.  Not ideal: is the real-world ever ideal apart from hardly ever?

> Note that while the current CSS3 Color spec states “User agents may vary in the fidelity with which they represent these colors”

Noted, but not really the sort of spec text that browser vendors can conform to.  It does recognize that "accurate color" is hard to implement without some variance. The spec was sensible here, in that it allowed practical implementations some leeway.

> The current CSS4 Color draft contains no such allowance for variance and instead states as a rule that CSS colors are in sRGB and shall be interpreted as such [2]. https://drafts.csswg.org/css-color/#sRGB

Neither does CSS4 preclude variance, it just doesn't mention it anymore. Re: sRGB in the draft: three browser vendors ignore it, one implements, that means that the particular spec section might very likely be removed, and it happens [3].

[3] Spec-ed items with little cross-browser support, tend to wilt and be removed.
https://bug-147812-attachments.webkit.org/attachment.cgi?id=258581 gone from Webkit, same property was removed from Chrome also, and the related CSS spec text was deleted.
Comment 93 by mad...@tapil.com, Dec 11 2015
I really don't understand the resistance to fixing this.

- The code to transform the color space from sRGB to monitor space is already in the browser. We know this since tagged images work.

- Transforming a CSS color is trivial. It is a mapping of a single RGB value to another. This is simply not a performance problem.

- I suspect that if the browser were to assume images were sRGB and do the transformation there would be a net latency and power savings over transmitting the sRGB profile with each image.

- I believe all the other major browsers already do the transformation.

To noel:

When we were saying 'color accuracy', it is not that we see 'just little bit greener' (green for instance) than it should be. It's a HUGE difference that a wide gamut monitor user cannot stand with. It's not that a small portion of designer users that are sensitive to the colors. The difference is quite notable by literally everyone, though only most of the people don't own this type of monitors.

On OS X, I did exactly like everybody else here did - use Safari as our main browsers. However I do miss Chrome because it's superior in features. And it's is apparently something to fix from a wide gamut monitor user's view.
I agree with #94. I stopped using Chrome as my main browser because of this. The difference is huge on my MacBook Air (2013), but it was not just over-saturated colors, it was also really whased colors in some cases (a voluntary flashy green who looked like sad lighted khaki green on Chrome, but as wanted on Firefox (without any tuning) and Safari 8.
I've had this problem too for many many years. Completely unnatural colors on my wide-gamut monitor. Most 30 inch monitors on the market are wide gamut by the way. 
I ended up selling my monitor and getting an sRGB one just because of this bug in chrome.
Comment 97 by njdo...@gmail.com, Dec 11 2015
>> 2. For the user using a monitor with a color profile other than sRGB
>
> The minority reports.  Yes as you noted these users can experience the problems of color overstaturation
> in their wide-gamut viewing conditions - assuming web site designers did not try to compensate their
> content for that fact of life /sadface

No need to be juvenile here...

The reality of today is that fewer and fewer people are using sRGB displays.

To say the majority is using sRGB is completely analogous to saying the majority of users:
* Have a display of 1024x768
* Have a display of 72 PPI
* Have a display of 256 colours

All of these points were true in the past and a lot of software was written making incorrect assumptions around them. That software was wrong the same way Chrome is wrong today. The world moved on and our displays are a lot better... including in the range of colours displays can and do display.

Not a single Mac today ships with sRGB as it's colour profile. Not a single one. The MacBook Air specifically is different enough that even naïve users can easily see the colour problems with Chrome. I would make the same assumptions for other laptop manufacturers today too; as shipped, their displays are probably not calibrated to sRGB.

If the whole premise of not fixing this bug and issue 37028 is the assumption that everyone (who matters, at least) uses sRGB then I would very much reevaluate that assumption using real-world data.

All of this is ignoring that fixing these bugs today is /good/ for performance because optimized images will no longer need a 4KiB profile attached to them to be colour consistent with their unoptimized counterpart.
Comment 98 by arn...@unraad.com, Dec 11 2015
And even if "most people" have an sRGB monitor (which may change very soon), when should this problem be resolved?
I'm not sure waiting for the majority to have display problems is the best solution.
As #97 said, monitors are changing fast and many devices have more than an sRGB gamut.
Comment 99 by noel@chromium.org, Dec 11 2015
#97 njdoyle

> No need to be juvenile here...

Wasn't being that here. I was being serious, but then perhaps the juvenile is the one who make statements without fact or data to substantiate their claims.

> The reality of today is that fewer and fewer people are using sRGB displays.

That's just your opinion. There are lots of Windows users and they are sRGB profile by default.

> Not a single Mac today ships with sRGB as it's colour profile. Not a single one.

When my MacAir(2013) arrived from the factory, its had sRGB set as it's color profile.  Had to set the profile to the LCD's screen profile myself.

> I would make the same assumptions for other laptop manufacturers today too; as shipped, their displays are probably not calibrated to sRGB.

Assumptions don't help.  The actual state of display color profiles from some manufactures is not so great: issue 492379 for details.

> I'd just like to clear up some terminology.

Yes it would help if you didn't invert it. Perhaps read the spec, it has the right terminology.
http://www.color.org/icc_specs2.xalter

> Colour Accuracy
> Assuring that a colour is displayed correctly to the best of a medium's ability over all displays and mediums.

Source colors can be lost when it shown on different displays and mediums that are the not same color space as the source.  #82 chiklit provided examples.  It's hard to say it's accurate when colors are lost in the process.  The spec has the term you are looking for.

> This bug and issue 37028 are literally responsible for half a kibibyte of should-be-unnecessary bloat on every single image coming from Facebook ...

This bug is not responsible for what Facebook does.  Seems sensible to add a color profile to content images as discussed, and the C2 color profile you mentioned is ~0.5KiB and small.

The problem could be solved by improving JPEG standards, issue 443829, and it could be done in about 10 bytes if we try, https://codereview.chromium.org/811703002

> If the whole premise of not fixing this bug and issue 37028 is the assumption that everyone (who matters, at least) uses sRGB then I would very much reevaluate that assumption using real-world data.

Off you go then and get some data. Come back when you have decent data to share.
Comment 100 by arn...@unraad.com, Dec 11 2015
I'm sorry Noel, but if Chrome was focused only for the "majority", why then do we have things like the developer tools? Chrome was a browser mostly used by designers/developers but because of this bug, many of us are switching to firefox or safari.
It really seems to me, and I hope I'm wrong, that you're not even open to discussion about this bug that has been plaguing the design community for years. For all you've said, you've clearly shown that you're not interested in this bug being fixed.
It "is" a bug and not just a requested feature, I think it's only fair that it receives the same treatment as any other bug and not being put in a box and not discussed because you don't deem it important.
So please, keep in mind that we're not here to bother you but because we really need this thing sorted.
@noel, I'm not exactly sure why you're being rude to the people who are trying very hard to use your product when they could easily switch to the competition.

I also fail to understand your opposition to simply adding an *option* for users to force automatic sRGB -> monitor transformations for untagged CSS elements and images, as per the W3C standard. You can have this switched off by default, so naive users wouldn't be troubled by it.

Chromium already has the code for color space conversions, so this should be straightforward. Maybe a few hours of work for one engineer. So what exactly is the reason not to do this? You mentioned performance, but if the option is disabled by default, that's not an issue. You're worried that <video>s won't be rendered consistently unless you do an expensive color conversion for every frame -- fair enough; just don't convert videos, mention that in the description of this feature, and call it a 'beta' feature. We'll live with it.

By now I think most other browsers have switched either to having this behavior as the default, or to having an option for it. Why can't Chromium?
I'm not buying the performance argument, not with today's computers.

If the issue is solely with <video>, then leave video out of it and manage static elements only. A color mismatch between embedded video and the surrounding content would be small potatoes compared to having wrong colors all around.

Consumer-level displays are getting better and better all the time, perversely making the user experience on Chrome correspondingly worse and worse. So eventually even the average user is going to prefer color management to no color management.

Therefore, the necessity for color management is not a question of if but when. Given this, what's the obstacle to just implementing it already? The feature could go behind a config option until the time is ripe to enable it by default.

Comment 103 by noel@chromium.org, Dec 11 2015
#100 arnaud@unraad.com, if I wasn't interested, I probably wouldn't be here try to answer your questions.  I am interested in your thoughts, but I'd help if we try to to stick to facts. I'm just assessing if users understand color. [Congrats on #100, btw].

#101 ttesileanu I'm not here to be rude to anyone, your option idea seems fine to me, but chrome does not provide options as a rule, so I think the only option would be on-for-everyone. Interesting idea though, I'll keep it in mind.

My thanks to the others who provided good data, and my apologies for not being able to respond to you all.
Comment 104 by arn...@unraad.com, Dec 11 2015
Thanks Noel I wasn't trying to be rude, sorry if it seemed so.

There is one thing, you stated that on Windows, people use sRGB profile for their monitor. I use Windows and almost all of the monitors I owned, when first detected, installed their own monitor profile or came with a CD which installed a monitor profile (and many "common" users will install everything that is provided with a new device).
So maybe even without knowing it, a lot of Windows users have profiles that are not sRGB and have differences between CSS and tagged photo colours. Probably not strong enough to be perceived in many cases, but since monitors keep getting better, the problem will soon be noticeable for a lot of users.
> I believe all the other major browsers already do the transformation.

> By now I think most other browsers have switched either to having this behavior as the default, or to having an option for it.

AFAIK, only Firefox fully supports color management by setting a hidden option. But if more browsers were to support this feature, Chrome would surely try to catch up.

> but chrome does not provide options as a rule

I know that Chrome tries to minimize the number of user-configurable settings, but I see plenty of options under chrome://settings/. One more checkbox in the advanced settings surely wouldn't hurt. Most users would even be OK with the command-line switch that existed at one point in time.

Comment 106 by noel@chromium.org, Dec 11 2015
#104 arnaud@unraad.com  Thanks Arnuad and no worries, didn't see you as being rude at all. My apologies if it seemed that way.

Yes, interesting that your Windows system came almost pre-configured for color, using an install CD, or somehow auto-configured (maybe via EDID). And yes, some users might not be noticing that yet, and monitors improving... One thing we have noticed is that when things are all good, they're good.  But when they go bad, users struggle to fix it. See issue 492379.
Surely you would only need to do the conversion, and thus add this supposed performance hit, if the display is not currently set to sRGB? Therefore, this bug is not about those users.

It is broken though for a whole other set of users.

That’s an assumption.

Laptops and phones compete on the merits of their displays which suggests that users do value, on some level, good colour representation. Do they understand colour profiles and displays enough to give you direct feedback on this particular issue? No probably not. Does that mean that users don’t care about colour? No.

Sure that can happen, it’s a conversion. But the status quo is that colours look terrible on displays other than sRGB.

That’s a very good rule. Colour representation is something that should just work out of the box. The conversion does not seem necessary if the display is set to sRGB, however.
Hello! Any updates here?
are you f@@ing kidding me? How has this not beed addressed? My iMac 5k in chrome makes my sites colors look retarded... chrome is my every day browser.. and the blues and reds are just way to saturated... 

I looked everywhere, and tried everything to fix this.

How is there no fix? no pluggin? no hack? nothing?

I am able to change the color profile on my mac to rgb to match at least what I am seeing in chrome... ( the wrong colors )...

but then on every other browser/computer I will see something different.. this is not a good thing when you a developing websites all day.

FIX THIS PLEASE.. sadly I guess im going to have to move onto safari which seems to be the new go to browser.... sadly, I am super comfortable with chromes web inspector.... great now I have to learn safaris developers tools.... just great..

u suc@
How can this still not be fixed?!?!
FIX THIS FOR FUCK SAKE IM GOING CRAZY
Comment 112 by jatl...@gmail.com, Jan 21 2016
Waiting for a fix... :(
Hello,

I was having this problem since many, many months, and i'have done something that solved this issue.
I got an iMac and a Eizo screen. When displaying on my iMac : chrome is fin, and on Eizo : color problem etc.
But, i'have gone in the preference tab, and in the monitor tab, you can move the screens to switch the disposition of the screens, and one thing i just discovered, you can set your "main" monitor (normally the iMac), and you can do it by moving the white menubar in the other screen. Just after that i have restarded my computer, and chrome is now displaying the colors very nicely now.
I have encountered this issue in "coverflow" mode in Finder, and it disappear too.
I think that the MacOSX icc profil gesture is bad, but can't confirm anything.
Maybe someone could try like me and say if all is ok ? :)


Capture d’écran 2016-02-14 à 10.37.43.png
63.8 KB View Download
@noel, is there a chance you can summarize the state of affairs regarding CSS color display in Chrome? A lot of links for basically "my css colors look wrong in Chrome" end up at this ticket and it's not especially clear whether:

1. Current color display is working as intended and will not change.
2. Web developers/designers need to change how they choose colors.
3. Chrome is planning to change behavior in the future.

Would love some clarity on a frustrating topic!
Components: -Blink Blink>Paint
Cc: chrishtr@chromium.org ccameron@chromium.org junov@chromium.org enne@chromium.org
Components: Internals>GPU
Owner: vmi...@chromium.org
Paint and GPU teams are looking into this now! Assigning to Victor to send it to the right person.
I'm sorry but I keep getting these weird messages from you people I have no
idea what they mean or who they're from thank you
Status: Assigned
Cc: vmi...@chromium.org
Owner: ccameron@chromium.org
Glad to see that this issue has finally been assigned. Very annoying when developing. I can't even begin to tell you how many times I edited my code to make sure that it wasn't me.... (thousands)
Chrome is completely unusable on my new wide-gamut monitor so I'm having to switch to firefox. HDR displays are coming out this year and chrome still can't handle basic SRGB management
Labels: -css CSS
I wonder if this any progress on this issue. Can't believe that this is discussed for so long and nothing is happening. Chrome isn't really usable on a wide gammut display (Here: Dell U2715k) with a Mac. It's not only about Design - the colors are over saturated in a way that makes browsing the web already hurting your eyes.

Firefox got this managed for over 6 years now with just giving a path to the icc profile in the config and switching it on. Should be possible for chrome, too!?
Project Member Comment 124 by bugdroid1@chromium.org, Aug 5 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/453bdc54a3650850eb8f8c5b5ca58f5db48df73d

commit 453bdc54a3650850eb8f8c5b5ca58f5db48df73d
Author: ccameron <ccameron@chromium.org>
Date: Fri Aug 05 00:20:43 2016

Color: Read embedded ICC profiles regardless of QCMS

Move code to load embedded ICC profiles out from behind the QCMS guard.

Add plumbing for the ICC profile from ImageDecoder to ImageFrame, where
the relevant SkBitmap is loaded.

BUG=44872

Review-Url: https://codereview.chromium.org/2203903002
Cr-Commit-Position: refs/heads/master@{#409942}

[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/graphics/BitmapImageTest.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/graphics/test/MockImageDecoder.h
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.h
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/ImageFrame.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/ImageFrame.h
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/bmp/BMPImageReader.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/gif/GIFImageDecoder.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/ico/ICOImageDecoder.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/ico/ICOImageDecoder.h
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/jpeg/JPEGImageDecoder.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/png/PNGImageDecoder.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cpp
[modify] https://crrev.com/453bdc54a3650850eb8f8c5b5ca58f5db48df73d/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.h

Project Member Comment 125 by bugdroid1@chromium.org, Aug 5 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dde2b8cb74bec2c53017c0445e0696a458c81d78

commit dde2b8cb74bec2c53017c0445e0696a458c81d78
Author: ccameron <ccameron@chromium.org>
Date: Fri Aug 05 05:53:33 2016

Color profile layout test cleanup

Remove callers to setImageColorProfilesEnabled, since it no longer has
an effect.

Rename the "whacked" color profile to the more descriptive "colorSpin"
color profile.

BUG=44872

Review-Url: https://codereview.chromium.org/2217463003
Cr-Commit-Position: refs/heads/master@{#409999}

[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/content/test/layouttest_support.cc
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-animate-rotate.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-animate.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-background-clip-text.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-background-image-cover.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-background-image-cross-fade-png.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-background-image-cross-fade.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-background-image-repeat.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-background-image-space.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-border-fade.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-border-image-source.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-border-image.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-border-radius.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-clip.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-drag-image.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-filter.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-group.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-iframe.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-canvas-pattern.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-canvas-svg.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-canvas.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-filter-all.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-object-fit.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-profile-match.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-pseudo-content.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-shape.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image-svg-resource-url.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-image.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-layer-filter.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-layer.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-mask-image-svg.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-munsell-adobe-to-srgb.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-munsell-srgb-to-srgb.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-object.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-reflection.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-svg-fill-text.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-svg-foreign-object.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/fast/images/color-profile-svg.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/media/color-profile-munsell-bt601-smpte-to-srgb.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/media/color-profile-munsell-bt709-to-srgb.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/media/color-profile-video-poster-image.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/media/color-profile-video-seek-filter.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/media/color-profile-video-seek-object-fit.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/media/color-profile-video-seek.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/LayoutTests/media/color-profile-video.html
[modify] https://crrev.com/dde2b8cb74bec2c53017c0445e0696a458c81d78/third_party/WebKit/Source/platform/testing/ImageDecodeBench.cpp

Project Member Comment 126 by bugdroid1@chromium.org, Aug 10 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/024c8dbbb497a75c01abb813d61659663689ccaa

commit 024c8dbbb497a75c01abb813d61659663689ccaa
Author: ccameron <ccameron@chromium.org>
Date: Wed Aug 10 03:03:14 2016

Color: Add cc accessors and unit tests

Add the ability to look up the color space for a resource when it is
locked for GL read.

Add tests to ensure that color spaces are transferred correctly (they
weren't).

Add a test to ensure that overlay candidacy is transferred correctly
as well.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2228693002
Cr-Commit-Position: refs/heads/master@{#410934}

[modify] https://crrev.com/024c8dbbb497a75c01abb813d61659663689ccaa/cc/resources/resource_provider.cc
[modify] https://crrev.com/024c8dbbb497a75c01abb813d61659663689ccaa/cc/resources/resource_provider.h
[modify] https://crrev.com/024c8dbbb497a75c01abb813d61659663689ccaa/cc/resources/resource_provider_unittest.cc

Project Member Comment 127 by bugdroid1@chromium.org, Aug 11 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7c4df6c240fd6bbc5fbf622d503f470cd505c643

commit 7c4df6c240fd6bbc5fbf622d503f470cd505c643
Author: ccameron <ccameron@chromium.org>
Date: Thu Aug 11 03:03:15 2016

Color: Add ColorCorrectRendering flag

Re-use the ImageColorProfiles flag (except in the interface to testing
internals).

Hook this up to:
- Remove QCMS color profiles from being baked into decoded images.
- Tag decoded image SkBitmaps with their specified color profile.
- Set canvas elements to be sRGB.

Add support for enabling this feature in layout tests. Images with
color profiles often appear blank with this flag, so don't add layout
tests yet.

BUG=44872

Review-Url: https://codereview.chromium.org/2216073002
Cr-Commit-Position: refs/heads/master@{#411241}

[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/chrome/browser/chromeos/login/chrome_restart_request.cc
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/public/common/common_param_traits_macros.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/public/common/content_switches.cc
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/public/common/content_switches.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/public/common/web_preferences.cc
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/public/common/web_preferences.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/renderer/render_view_impl.cc
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/renderer/render_widget.cc
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/renderer/render_widget.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/content/test/layouttest_support.cc
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/core/page/Page.cpp
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/core/page/Page.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/core/testing/InternalSettings.cpp
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/core/testing/InternalSettings.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/core/testing/InternalSettings.idl
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.in
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/platform/image-decoders/ImageFrame.cpp
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/platform/image-decoders/ImageFrame.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/web/WebRuntimeFeatures.cpp
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/web/WebViewImpl.cpp
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/Source/web/WebViewImpl.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/public/web/WebRuntimeFeatures.h
[modify] https://crrev.com/7c4df6c240fd6bbc5fbf622d503f470cd505c643/third_party/WebKit/public/web/WebView.h

Project Member Comment 128 by bugdroid1@chromium.org, Aug 12 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca

commit b4d9236157069f52950e8f4d84cbc0f0df5cd9ca
Author: ccameron <ccameron@chromium.org>
Date: Fri Aug 12 07:33:26 2016

cc: Add gfx::ColorSpace to cc::ResourceProvider resource creation

Updated all callers to specify a color space. Almost all of these are
the default gfx::ColorSpace, but some of them in cc::DirectRenderer and
its subclasses use the cc::OutputSurface's color space, as appropriate.

Update tests for cc::ResourcePool to take color space into account for
resource recycling.

Add tests for plumbing through to queryable properts in locks.

The addition of this argument does not change any behaviors, and this
patch should have no observable effects.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2235623003
Cr-Commit-Position: refs/heads/master@{#411575}

[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/layers/heads_up_display_layer_impl.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/layers/texture_layer_impl.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/output/direct_renderer.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/output/gl_renderer.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/output/gl_renderer_unittest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/output/output_surface.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/output/output_surface.h
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/output/renderer_pixeltest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/output/software_renderer_unittest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/raster/raster_buffer_provider_perftest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/raster/raster_buffer_provider_unittest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/resource.h
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/resource_pool.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/resource_pool.h
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/resource_pool_unittest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/resource_provider.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/resource_provider.h
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/resource_provider_unittest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/scoped_resource.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/scoped_resource.h
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/scoped_resource_unittest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/video_resource_updater.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/resources/video_resource_updater.h
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/test/fake_ui_resource_layer_tree_host_impl.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/test/render_pass_test_utils.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/tiles/tile_manager.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/tiles/tile_manager.h
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/tiles/tile_manager_unittest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/trees/layer_tree_host_impl_unittest.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/cc/trees/layer_tree_host_unittest_context.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/ui/gfx/color_space.cc
[modify] https://crrev.com/b4d9236157069f52950e8f4d84cbc0f0df5cd9ca/ui/gfx/color_space.h

Project Member Comment 129 by bugdroid1@chromium.org, Aug 12 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/53d7727467e44f51ad9fe10e0f0d2a2ef2366a10

commit 53d7727467e44f51ad9fe10e0f0d2a2ef2366a10
Author: erikchen <erikchen@chromium.org>
Date: Fri Aug 12 23:15:32 2016

Fix a bug that prevents all reuse of ResourcePool resources.

The ColorSpace parameter was being lost when creating a ResourcePool resource.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2240873003
Cr-Commit-Position: refs/heads/master@{#411812}

[modify] https://crrev.com/53d7727467e44f51ad9fe10e0f0d2a2ef2366a10/cc/resources/resource.h
[modify] https://crrev.com/53d7727467e44f51ad9fe10e0f0d2a2ef2366a10/cc/resources/scoped_resource.cc

Project Member Comment 130 by bugdroid1@chromium.org, Aug 15 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0bada44ad4dc13728a59e89a596dacb763bbb268

commit 0bada44ad4dc13728a59e89a596dacb763bbb268
Author: erikchen <erikchen@chromium.org>
Date: Mon Aug 15 18:37:41 2016

Refactor ResourcePool::AcquireResource() and add test.

This CL has no intended functional effect.

Separate AcquireResource() into the functions ReuseResource() and
CreateResource() and write a test.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2243013002
Cr-Commit-Position: refs/heads/master@{#411998}

[modify] https://crrev.com/0bada44ad4dc13728a59e89a596dacb763bbb268/cc/resources/resource_pool.cc
[modify] https://crrev.com/0bada44ad4dc13728a59e89a596dacb763bbb268/cc/resources/resource_pool.h
[modify] https://crrev.com/0bada44ad4dc13728a59e89a596dacb763bbb268/cc/resources/resource_pool_unittest.cc

Project Member Comment 131 by bugdroid1@chromium.org, Sep 2 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/41495f2551c63bea769afd6cc70f1c3593f3537f

commit 41495f2551c63bea769afd6cc70f1c3593f3537f
Author: ccameron <ccameron@chromium.org>
Date: Fri Sep 02 02:37:32 2016

Color: Clean up color profile handling for layout tests

Allow layout tests to manually specify an output ICC profile
through the ContentRendererClient.

Match existing behavior on all platforms. This means:
- on Mac, using a generic RGB profile
- on Linux, not specifying a profile
- on Windows, leave this as TODO, since correct behavior is unclear

Remove layout_test_helper on Mac, since its only purpose was
to set the system color space to the now-specified color space.
Remove copyright exceptions for layout_test_helper as well.

BUG=44872

Review-Url: https://codereview.chromium.org/2226733003
Cr-Commit-Position: refs/heads/master@{#416170}

[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/BUILD.gn
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/build/all.gyp
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/components/test_runner/BUILD.gn
[delete] https://crrev.com/bc099185878fda1c06351f745e19aff4fe6fac64/components/test_runner/helper/layout_test_helper_mac.mm
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/content/public/renderer/content_renderer_client.cc
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/content/public/renderer/content_renderer_client.h
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/content/renderer/render_view_impl.cc
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/content/shell/renderer/layout_test/layout_test_content_renderer_client.cc
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/content/shell/renderer/layout_test/layout_test_content_renderer_client.h
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/third_party/WebKit/Tools/Scripts/webkitpy/layout_tests/port/mac.py
[modify] https://crrev.com/41495f2551c63bea769afd6cc70f1c3593f3537f/tools/copyright_scanner/third_party_files_whitelist.txt

Project Member Comment 132 by bugdroid1@chromium.org, Sep 6 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/27978e43e0901a0ecb13833f9987ae9522e94d24

commit 27978e43e0901a0ecb13833f9987ae9522e94d24
Author: ccameron <ccameron@chromium.org>
Date: Tue Sep 06 23:06:21 2016

Layout tests: Parameterize color space to use by default

Add an explicit sRGB ICC profile.

This is a step towards moving all layout tests to the same
sRGB color space. A follow-up patch delete the "generic RGB"
color space and the #if block specifying different color spaces.

BUG=44872

Review-Url: https://codereview.chromium.org/2299193005
Cr-Commit-Position: refs/heads/master@{#416752}

[modify] https://crrev.com/27978e43e0901a0ecb13833f9987ae9522e94d24/content/public/test/layouttest_support.h
[modify] https://crrev.com/27978e43e0901a0ecb13833f9987ae9522e94d24/content/shell/renderer/layout_test/blink_test_runner.cc
[modify] https://crrev.com/27978e43e0901a0ecb13833f9987ae9522e94d24/content/shell/renderer/layout_test/layout_test_content_renderer_client.cc
[modify] https://crrev.com/27978e43e0901a0ecb13833f9987ae9522e94d24/content/test/layouttest_support.cc
[modify] https://crrev.com/27978e43e0901a0ecb13833f9987ae9522e94d24/ui/gfx/icc_profile.h

Blockedon: 644545
Project Member Comment 134 by bugdroid1@chromium.org, Sep 12 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/23f6433cbb6eced66e2585c3c6af092776b93f5b

commit 23f6433cbb6eced66e2585c3c6af092776b93f5b
Author: ccameron <ccameron@chromium.org>
Date: Mon Sep 12 22:59:21 2016

Add cc::LayerTreeSettings for color correct rendering

Propagate the --enable-color-correct-rendering flag from the browser
to the renderer, and propagate it to the LayerTreeSettings of the
browser and the renderer.

Move the flag from content to cc, because it needs to be set from
content::RenderWidgetCompositor and ui::Compositor (oops).

BUG=44872
TBR=piman

Review-Url: https://codereview.chromium.org/2328133002
Cr-Commit-Position: refs/heads/master@{#418090}

[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/cc/base/switches.cc
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/cc/base/switches.h
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/cc/trees/layer_tree_settings.h
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/chrome/browser/chromeos/login/chrome_restart_request.cc
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/content/browser/renderer_host/render_process_host_impl.cc
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/content/browser/renderer_host/render_view_host_impl.cc
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/content/public/common/content_switches.cc
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/content/public/common/content_switches.h
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/23f6433cbb6eced66e2585c3c6af092776b93f5b/ui/compositor/compositor.cc

Project Member Comment 135 by bugdroid1@chromium.org, Sep 13 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9a20110f728dac9b1250aee3956ae388741f8905

commit 9a20110f728dac9b1250aee3956ae388741f8905
Author: ccameron <ccameron@chromium.org>
Date: Tue Sep 13 20:56:30 2016

cc: Populate SkColorSpace for raster from resource gfx::ColorSpace

Ensure that this does nothing when --enable-color-correct-rendering is
not specified.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2332143002
Cr-Commit-Position: refs/heads/master@{#418362}

[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/raster/bitmap_raster_buffer_provider.cc
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/raster/one_copy_raster_buffer_provider.cc
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/raster/one_copy_raster_buffer_provider.h
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/raster/raster_buffer_provider.cc
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/raster/raster_buffer_provider.h
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/raster/zero_copy_raster_buffer_provider.cc
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/resources/resource_provider.cc
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/resources/resource_provider.h
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/resources/resource_provider_unittest.cc
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/surfaces/display.cc
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/test/fake_resource_provider.h
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/test/pixel_test.cc
[modify] https://crrev.com/9a20110f728dac9b1250aee3956ae388741f8905/cc/trees/layer_tree_host_impl.cc

Cc: hubbe@chromium.org
Project Member Comment 137 by bugdroid1@chromium.org, Sep 14 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b

commit f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Author: ccameron <ccameron@chromium.org>
Date: Wed Sep 14 00:04:09 2016

cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2325773003
Cr-Commit-Position: refs/heads/master@{#418422}

[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/browser/web_contents/web_contents_view_android.cc
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/browser/web_contents/web_contents_view_aura.cc
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/browser/web_contents/web_contents_view_mac.mm
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/common/view_messages.h
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/public/common/screen_info.cc
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/public/common/screen_info.h
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/renderer/gpu/render_widget_compositor.h
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/content/renderer/render_widget.cc
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/ui/display/BUILD.gn
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/ui/display/android/screen_android.cc
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/ui/display/display.cc
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/ui/display/display.h
[modify] https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b/ui/display/mac/screen_mac.mm

Project Member Comment 138 by bugdroid1@chromium.org, Sep 14 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/72cc58add8718a0093e160aa96341ba887144cc3

commit 72cc58add8718a0093e160aa96341ba887144cc3
Author: yutak <yutak@chromium.org>
Date: Wed Sep 14 05:04:46 2016

Revert of cc: Plumb the monitor color profile to renderer for rasterization (patchset #6 id:100001 of https://codereview.chromium.org/2325773003/ )

Reason for revert:
Suspected cause of the following MSAN failure.

https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20MSAN/builds/12218

19:03:27.700 29717   ==4==WARNING: MemorySanitizer: use-of-uninitialized-value
19:03:27.700 29717       #0 0x7853dbe in computeTypeMask third_party/skia/src/core/SkMatrix44.cpp:59:23
19:03:27.700 29717       #1 0x7858825 in getType third_party/skia/include/core/SkMatrix44.h:208:31
19:03:27.700 29717       #2 0x7858825 in setConcat third_party/skia/src/core/SkMatrix44.cpp:378:0
19:03:27.700 29717       #3 0x76f8840 in operator*= ui/gfx/transform.h:253:5
19:03:27.700 29717       #4 0x76f8840 in ColorSpaceToColorSpaceTransform ui/gfx/color_transform.cc:563:0
19:03:27.700 29717       #5 0x76f78de in NewColorTransform ui/gfx/color_transform.cc:703:15
19:03:27.700 29717       #6 0x767f315 in GetColorSpace ui/gfx/icc_profile.cc:142:45
19:03:27.700 29717       #7 0xb2263ae in initializeLayerTreeView content/renderer/render_widget.cc:1141:61
19:03:27.700 29717       #8 0xb1e68fd in initializeLayerTreeView content/renderer/render_view_impl.cc:1956:17
19:03:27.700 29717       #9 0xc1c6b06 in initializeLayerTreeView third_party/WebKit/Source/web/WebViewImpl.cpp:4341:19
19:03:27.700 29717       #10 0xc1c57bf in WebViewImpl third_party/WebKit/Source/web/WebViewImpl.cpp:471:5
19:03:27.700 29717       #11 0xc1c29ff in create third_party/WebKit/Source/web/WebViewImpl.cpp:342:25
19:03:27.700 29717       #12 0xc1c29ff in create third_party/WebKit/Source/web/WebViewImpl.cpp:336:0
19:03:27.700 29717       #13 0xb19b457 in Initialize content/renderer/render_view_impl.cc:717:7
<snip>

Original issue's description:
> cc: Plumb the monitor color profile to renderer for rasterization
>
> This adds the output device color profile to display::Display, and
> populates it correctly on Mac. We will want to do this for all
> platforms.
>
> The color profile is then plumbed through the same IPCs that take
> the device scale factor, to get to the renderer process'
> RenderWidgetCompositor.
>
> Note that we are sending the full ICCProfile this far. This is
> important, because the renderer process will be setting the ICCProfile
> of its rasterized IOSurfaces, and there is a power impact of even slight
> differences between the monitor profile and the IOSurface profile.
>
> The ICCProfile is then sent as a gfx::ColorProfile (which internally
> references the ICCProfile, for the above purpose) to the
> RenderWidgetCompositor, from where it will be pushed to cc.
>
> In the next step, we will (under a flag) specify the color space
> for rasterization.
>
> BUG=44872
> CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
>
> Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
> Cr-Commit-Position: refs/heads/master@{#418422}

TBR=enne@chromium.org,clamy@chromium.org,dcheng@chromium.org,ellyjones@chromium.org,ccameron@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=44872

Review-Url: https://codereview.chromium.org/2336113003
Cr-Commit-Position: refs/heads/master@{#418490}

[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/browser/web_contents/web_contents_view_android.cc
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/browser/web_contents/web_contents_view_aura.cc
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/browser/web_contents/web_contents_view_mac.mm
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/common/view_messages.h
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/public/common/screen_info.cc
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/public/common/screen_info.h
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/renderer/gpu/render_widget_compositor.h
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/content/renderer/render_widget.cc
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/ui/display/BUILD.gn
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/ui/display/android/screen_android.cc
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/ui/display/display.cc
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/ui/display/display.h
[modify] https://crrev.com/72cc58add8718a0093e160aa96341ba887144cc3/ui/display/mac/screen_mac.mm

Project Member Comment 139 by bugdroid1@chromium.org, Sep 14 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f408cabe76348e2e5f207a633178fdf150e38aa4

commit f408cabe76348e2e5f207a633178fdf150e38aa4
Author: ccameron <ccameron@chromium.org>
Date: Wed Sep 14 16:54:42 2016

cc: Plumb the monitor color profile to renderer for rasterization

This adds the output device color profile to display::Display, and
populates it correctly on Mac. We will want to do this for all
platforms.

The color profile is then plumbed through the same IPCs that take
the device scale factor, to get to the renderer process'
RenderWidgetCompositor.

Note that we are sending the full ICCProfile this far. This is
important, because the renderer process will be setting the ICCProfile
of its rasterized IOSurfaces, and there is a power impact of even slight
differences between the monitor profile and the IOSurface profile.

The ICCProfile is then sent as a gfx::ColorProfile (which internally
references the ICCProfile, for the above purpose) to the
RenderWidgetCompositor, from where it will be pushed to cc.

In the next step, we will (under a flag) specify the color space
for rasterization.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/f1fef7489c29deeee2a29c41ce4851e9ad1bd67b
Review-Url: https://codereview.chromium.org/2325773003
Cr-Original-Commit-Position: refs/heads/master@{#418422}
Cr-Commit-Position: refs/heads/master@{#418591}

[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/browser/web_contents/web_contents_view_android.cc
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/browser/web_contents/web_contents_view_aura.cc
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/browser/web_contents/web_contents_view_mac.mm
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/common/view_messages.h
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/public/common/screen_info.cc
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/public/common/screen_info.h
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/renderer/gpu/render_widget_compositor.h
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/content/renderer/render_widget.cc
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/ui/display/BUILD.gn
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/ui/display/android/screen_android.cc
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/ui/display/display.cc
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/ui/display/display.h
[modify] https://crrev.com/f408cabe76348e2e5f207a633178fdf150e38aa4/ui/display/mac/screen_mac.mm

Project Member Comment 140 by bugdroid1@chromium.org, Sep 19 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/99961cb9d362a5499e3b7455d16c760db78c2108

commit 99961cb9d362a5499e3b7455d16c760db78c2108
Author: ccameron <ccameron@chromium.org>
Date: Mon Sep 19 19:15:19 2016

cc: Plumb device color space through to rasterization

Add plumbing from LayerTree to LayerTreeImpl. Grab the color space
from the LayerTreeImpl in raster task creation in the TileManager by
using the TileManagerClient interface.

Note that while this is plumbing a valid gfx::ColorSpace, this still
has no impact on behavior, because the gfx::ColorSpace to
SkColorSpace conversion isn't in place yet. Once that is in place,
tests to query the tile resources' color spaces can be added.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2336853002
Cr-Commit-Position: refs/heads/master@{#419525}

[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/test/fake_tile_manager_client.cc
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/test/fake_tile_manager_client.h
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/tiles/tile_manager.cc
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/tiles/tile_manager.h
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/trees/layer_tree.cc
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/trees/layer_tree.h
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/trees/layer_tree_host_impl.cc
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/trees/layer_tree_host_impl.h
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/trees/layer_tree_host_unittest.cc
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/trees/layer_tree_impl.cc
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/trees/layer_tree_impl.h
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/cc/trees/layer_tree_impl_unittest.cc
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/content/renderer/gpu/render_widget_compositor.cc
[modify] https://crrev.com/99961cb9d362a5499e3b7455d16c760db78c2108/ui/compositor/compositor.cc

Project Member Comment 141 by bugdroid1@chromium.org, Sep 20 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c37fc95428d69f46a528627fe3564cb53f8ce474

commit c37fc95428d69f46a528627fe3564cb53f8ce474
Author: ccameron <ccameron@chromium.org>
Date: Tue Sep 20 02:29:01 2016

cc: Add conversion between gfx::ColorSpace and SkColorSpace

Use the ICC profile to convert between the two for now. This is not
robust or efficient, but it is behind a development flag.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2351823002
Cr-Commit-Position: refs/heads/master@{#419653}

[modify] https://crrev.com/c37fc95428d69f46a528627fe3564cb53f8ce474/cc/resources/resource_provider.cc
[modify] https://crrev.com/c37fc95428d69f46a528627fe3564cb53f8ce474/ui/gfx/color_space.cc
[modify] https://crrev.com/c37fc95428d69f46a528627fe3564cb53f8ce474/ui/gfx/color_space.h

Blockedon: 648707
Cc: msarett@chromium.org
Project Member Comment 144 by bugdroid1@chromium.org, Sep 21 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1614d49c8ff84f43b6d5abdfa6e78beec18101c4

commit 1614d49c8ff84f43b6d5abdfa6e78beec18101c4
Author: ccameron <ccameron@chromium.org>
Date: Wed Sep 21 20:47:30 2016

color: Make images without embedded profiles sRGB by default

This is only under the --enable-color-correct-rendering flag.

BUG=44872

Review-Url: https://codereview.chromium.org/2359643002
Cr-Commit-Position: refs/heads/master@{#420157}

[modify] https://crrev.com/1614d49c8ff84f43b6d5abdfa6e78beec18101c4/third_party/WebKit/Source/platform/image-decoders/ImageFrame.cpp

Project Member Comment 145 by bugdroid1@chromium.org, Sep 21 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1614d49c8ff84f43b6d5abdfa6e78beec18101c4

commit 1614d49c8ff84f43b6d5abdfa6e78beec18101c4
Author: ccameron <ccameron@chromium.org>
Date: Wed Sep 21 20:47:30 2016

color: Make images without embedded profiles sRGB by default

This is only under the --enable-color-correct-rendering flag.

BUG=44872

Review-Url: https://codereview.chromium.org/2359643002
Cr-Commit-Position: refs/heads/master@{#420157}

[modify] https://crrev.com/1614d49c8ff84f43b6d5abdfa6e78beec18101c4/third_party/WebKit/Source/platform/image-decoders/ImageFrame.cpp

Project Member Comment 146 by bugdroid1@chromium.org, Oct 11 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e25efb436aa053fe04d12080b6e3341cecd28c6e

commit e25efb436aa053fe04d12080b6e3341cecd28c6e
Author: ccameron <ccameron@chromium.org>
Date: Tue Oct 11 17:03:38 2016

color: Read LayerTreeSettings.enable_color_correct_rendering

Send this to the ResourceProvider.

BUG=44872
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2409193002
Cr-Commit-Position: refs/heads/master@{#424460}

[modify] https://crrev.com/e25efb436aa053fe04d12080b6e3341cecd28c6e/cc/trees/layer_tree_host_impl.cc

Blockedon: 655247
Cc: rponnada@chromium.org
Issue 294598 has been merged into this issue.
Cc: caryclark@chromium.org reed@chromium.org brettw@chromium.org senorblanco@chromium.org a...@chromium.org
Issue 37028 has been merged into this issue.
Issue 651688 has been merged into this issue.
Comment 151 by kgb@chromium.org, Oct 29 2016
Labels: -OS-Mac OS-All
Project Member Comment 152 by bugdroid1@chromium.org, Oct 31 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/65402021deb370b590ec564d93f941733308f477

commit 65402021deb370b590ec564d93f941733308f477
Author: ccameron <ccameron@chromium.org>
Date: Mon Oct 31 23:30:23 2016

Plumb color space to DecodingImageGenerator and ImageFrameGenerator

Image creation was failing in ExternalMemoryAllocator::allocPixelRef
because the SkImageInfo specified to the ExternalMemoryAllocator via
the ImageFrameGenerator that creates it did not include the color space
of the image. Populate this information by querying it from the decoder
in DecodingImageGenerator::create.

Change ImageDecoder::colorSpace to be the single place for enforcing
the rule that images that do not have embedded color profiles should be
interpreted as sRGB.

Change all callers to ImageFrame::setSizeAndColorSpace to query the
ImageDecoder::colorSpace, and enforce that the color space specified be
non-null.

Rename ImageDecoder::hasColorSpace to hasEmbeddedColorSpace to make it
clear that this refers only to an embedded color space (all images
have an explicit or implicit color space).

Rename ImageDecoder::setColorSpaceAndComputeTransform's overload to
setColorProfileAndComputeTransform, when the argument is a full ICC
profile.

BUG=44872

Review-Url: https://codereview.chromium.org/2462803002
Cr-Commit-Position: refs/heads/master@{#428864}

[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/graphics/DecodingImageGenerator.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/graphics/DeferredImageDecoder.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/graphics/DeferredImageDecoder.h
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/graphics/ImageDecodingStoreTest.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/graphics/ImageFrameGenerator.h
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/graphics/ImageFrameGeneratorTest.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/graphics/ImageSource.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.h
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/ImageFrame.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/ImageFrame.h
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/bmp/BMPImageReader.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/gif/GIFImageDecoder.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/jpeg/JPEGImageDecoder.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/png/PNGImageDecoder.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoder.cpp
[modify] https://crrev.com/65402021deb370b590ec564d93f941733308f477/third_party/WebKit/Source/platform/image-decoders/webp/WEBPImageDecoderTest.cpp

Comment 153 by reed@google.com, Nov 1 2016
Cc: -reed@chromium.org -a...@chromium.org brianosman@chromium.org
Project Member Comment 154 by bugdroid1@chromium.org, Nov 2 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/14bf9e84af49ea02296fba3083f6e91db1def841

commit 14bf9e84af49ea02296fba3083f6e91db1def841
Author: ccameron <ccameron@chromium.org>
Date: Wed Nov 02 21:21:24 2016

Fix double-move of SkColorSpace

I allowed std::move(colorSpace) to be called twice, resulting in
in the second result being null.

TBR=junov
BUG=44872

Review-Url: https://codereview.chromium.org/2471193002
Cr-Commit-Position: refs/heads/master@{#429403}

[modify] https://crrev.com/14bf9e84af49ea02296fba3083f6e91db1def841/third_party/WebKit/Source/platform/image-decoders/ImageFrame.cpp

As the person who filed http://code.google.com/p/chromium/issues/detail?id=37028, I am glad to see this being fixed.

I was so frustrated I eventually switched to Windows for photo editing purposes.  I use nice wide gamut monitors for photo editing and Windows does a much better job managing wide gamut monitors than OSX does :(.  

Chrome fixing this would really help, but ideally we want Apple to fix it at OSX level as well.
Cc: pawli...@chromium.org hcm@chromium.org bsalo...@google.com reed@google.com andresantoso@chromium.org pinkerton@chromium.org shrike@chromium.org
Issue 318005 has been merged into this issue.
Issue 510945 has been merged into this issue.
Cc: -andresantoso@chromium.org -pawli...@chromium.org
Project Member Comment 159 by bugdroid1@chromium.org, Nov 16 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/54e9f5e214d9dbc57df09d2669ab2d1a9bb8a780

commit 54e9f5e214d9dbc57df09d2669ab2d1a9bb8a780
Author: ccameron <ccameron@chromium.org>
Date: Wed Nov 16 21:57:37 2016

Add image color space histograms

Use the same binning as output color spaces, merge them into a helper
function.

This should help inform strategies for image decoding.

BUG=44872

Review-Url: https://codereview.chromium.org/2503973002
Cr-Commit-Position: refs/heads/master@{#432636}

[modify] https://crrev.com/54e9f5e214d9dbc57df09d2669ab2d1a9bb8a780/third_party/WebKit/Source/platform/graphics/BitmapImageMetrics.cpp
[modify] https://crrev.com/54e9f5e214d9dbc57df09d2669ab2d1a9bb8a780/third_party/WebKit/Source/platform/graphics/BitmapImageMetrics.h
[modify] https://crrev.com/54e9f5e214d9dbc57df09d2669ab2d1a9bb8a780/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.cpp
[modify] https://crrev.com/54e9f5e214d9dbc57df09d2669ab2d1a9bb8a780/third_party/WebKit/Source/platform/image-decoders/ImageDecoder.h
[modify] https://crrev.com/54e9f5e214d9dbc57df09d2669ab2d1a9bb8a780/tools/metrics/histograms/histograms.xml

Blockedon: 667411
Blockedon: -648707
Blockedon: -655247
Blockedon: -667411
Mergedinto: 667431
Status: Duplicate
I've been using this as too broad of an umbrella bug. I've separated out the two targets for color correctness as
legacy color correct rendering: issue 667431
true color correct rendering: issue 667433

I've re-distributed the sub-bugs of this to the appropriate one of the above, and I'm duping this to the legacy color correct rendering bug.

The overall design doc for the two approaches is:
https://docs.google.com/document/d/1BMyXXTmiAragmt5ukVBIIOLDthd7JcJBgGMt-PwuTHY/edit#
Comment 165 by stu...@anchev.net, Nov 21 2016
What about multi-monitor configurations? How will Chrome handle moving the browser window from one monitor to another (considering both monitor may be different and with different profiles)? Also what will happen if the browser window is stretched to cover both monitors? Will it respect the primary one only or will it be able to handle intelligently each part of the window respecting which monitor it is on? That is not clear in the document.
Dear developers:

Thanks for implementing this feature. 

However for everyday use, the current stable Chrome (v58, mac for my case) still has a UX issue which makes your effort not visible to me:

When I start Chrome without the external wide gamut monitor, it works fine with the built-in. And When I plug the external wide gamut monitor to my MacBook Pro, the Chrome remains file on the external monitor, showing correct colors. But when I start Chrome with the external monitor connected, Chrome appears to treat all colors sRGB even on the external one. Therefore to let Chrome support the color profile of the external monitor, I have to disconnect the external  monitor, start Chrome, then connect the external monitor again.

Could you make a patch to address this issue, please?
I had this issue in Chromium build 61.0 , Os Ubutnu 16, i disabled Color correct rendering in chrome://flags and works fine for me.
Re #167, if you are seeing incorrect colors in Chrome 61, it is because you have a color profile installed that you don't like. We will use a different flag in Chrome 62 to override your color profile, but the best solution is to remove your undesired color profile.
Solution from #167 worked for me. I didn't have any new color profiles so not sure how to remove the "undesired" one. 
Sign in to add a comment