Example of Safari vs Chrome. This is extra pronounced when plugged into a Thunderbolt display that doesn't have the same color gamut.

Deleted: Screen Shot 2016-12-09 at 8.42.56 PM.png 85.0 KB

	Screen Shot 2016-12-09 at 8.42.56 PM.png 85.0 KB View Download

Thanks for the report. In your screenshot, Chrome is in the background, right? How does it looks side by side in an active state? Installing a darker theme could be a workaround.

Ah, sorry you mean the blue color of the "Inbox" area, right?

Yeh the blue header background color is what is being displayed incorrect.
It's pretty obvious across the every website though, especially big
background color fills, logos, favicon, etc.

It's hard to find info about it online since it's such a new computer.

Sketch app (a GUI design tool for Mac) is also effected by this too. I
think they use some color profiles and type rendering from chrome in their
app.

Okay, adding Needs-bisect label, since you say that it worked in Chrome 54. May be the bisecting team can find the regression range.

FWIW I updated Chrome to latest on my 2014 MacBook Air and the colors look normal there. Important to note that this issue is on new 2016 MacBook Pros only, not older displays.

Is this generally on Retina, e.g. also on MacBook Pro 2015 Retina or iMac Retina ? Any chance to test it?

I'll take a look on Monday at work.

Thanks. 

Maybe you can also check in the meantime, if this issue is still appearing in latest Chrome Canary 57. You can download it from here: https://www.google.de/chrome/browser/canary.html

Oh. probably things have changed regarding color management on MBP 2016. On my Mac with a wide gammut color screen this has always been a problem. Somehow it was closed to beeing fixed in the latest betas but now it reverted back to the usual problem. I don't know what happened but there are really old open bugs regarding missing/faulty color handling in Chrome.

sorry of missing links in the last post. Examples for these old tickets are #294598, #44872 and others. https://bugs.chromium.org/p/chromium/issues/detail?id=44872

Can confirm problem exists in Canary as well Version 57.0.2948.0

Adding Skia as a component, as color management is done there IIUC.
(correct me if I'm wrong.)

Its bit hard to differentiate the colours, can we have a minimal test case to triage it  further.Attached the screen shots of Macbook air 2014 and Macbook pro 2012 on stable 55.0.2883.87, Canary 57.0.2949.0.

Deleted: MacbookAir_2014.png 72.8 KB

	MacbookAir_2014.png 72.8 KB View Download

Deleted: MacBook Pro_2012.png 362 KB

	MacBook Pro_2012.png 362 KB View Download

MacBook Air 2014 screenshot -- colors look very different between Chrome and Safari.

MacBook Pro 2012 -- colors are negligible and probably fine.

My new 13" MacBook Pro late 2016 (sans touch bar edition) screenshot is attached with hex values, RGB and system info.

The hex values are wildly different with a lot more red in the safari version.

To be clear, Safari is rendering all colors really well. Chrome is the browser that looks off/over saturated.

Deleted: macbook-pro-late-2016.png 901 KB

	macbook-pro-late-2016.png 901 KB View Download

+ hcm@ as per comment #17.

Thanks for the feedback.
The rgb value is same :(66,133,244) since 37.0.1986.0 on Macbook Air 2014 but the color seems to more saturated compred to Safari.
Untriaged it to get address further.

Removed Needs-Bisect as could not get any regression range.

Note : rgb value is same for Win 10 and Ubuntu 14.04.

Deleted: Colorpicker_MacbookAir.mp4 2.7 MB

	Colorpicker_MacbookAir.mp4 2.7 MB View Download

Skia and Chrome are jointly responsible for managing the color data and values- I need to look into the code to see what's going on here but running short on time with the holiday.  Bringing in Skia color folks...

I suspect that the changes made for  issue #654488  have led to this. ccameron@ would need to confirm, but my theory:

1) Sierra modified how color correction was applied, so that it was doing sRGB -> Display profile conversion of Chrome's output. That resulted in double-conversion of images, making them very dark.

2) To fix that, we switched to tagging Chrome's output in the monitor's color profile, to suppress any OS color conversion.

3) ... but we're still not doing color management of CSS colors (yet), and the newer MBPs have wider gamut than the older models, so the difference is becoming more obvious.

The long term solution is the color management work that's underway, but won't be ready for some time. A shorter term solution (that has some other bad tradeoffs) is the alternate solution to the previous bug - explicitly tag our output surfaces as sRGB (and do our image conversion to sRGB). That unnecessarily clamps all content to the sRGB gamut, but will provide perfect color accuracy on these newer Macs for all content that fits in that gamut.

I also would put my money on  issue 654488 .

> A shorter term solution (that has some other bad tradeoffs) is the alternate solution to the previous bug - explicitly tag our output surfaces as sRGB (and do our image conversion to sRGB).

I wonder if we should just do that for now. It would be very unfortunate for people with wide gamut displays, but it would fix so many issues for other users.

> I wonder if we should just do that for now. It would be very unfortunate for people with wide gamut displays, but it would fix so many issues for other users.

Just wanted to say that this solution gets my vote. People with sRGB monitors won't see any difference at all. The only real difference is for people with wide-gamut displays, so do those people value accuracy of CSS colors and untagged images, or of tagged (wide-gamut) images? The former is much more common than the latter, so we ought to optimize for that.

There's a blog post by the Webkit team that talks about the decisions they made in this space:

https://webkit.org/blog/6682/improving-color-on-the-web/

As someone with a wide gamut display, I would rather have Chrome limited to sRGB than the current situation. (Obviously, proper support for tagged images and some theoretical future CSS syntax would be ideal).

Chrome Canary now has "enable color correct rendering" in its about:flags. This issue should be fixed if you enable that settings (feel free to file bugs with that flag on, since we're hoping to enable it across the board soon).