cc'ing Tom and Ken for further triage. 

ccameron@: is this related to  http://crbug.com/713889 

I suspect that this is yet another instance of  issue 755747 .

+hubbe for Linux color oddness.

Chrome pays attention to the color profile as specified by the _ICC_PROFILE atom. We've seen a lot of people who have this set to something that they didn't expect. Do you know if dispcalGUI sets this? Or does it set something else?

If you want to reset this, you can run
  xicc /usr/share/color/icc/colord/sRGB.icc

I'm not too familiar with dispcal's working. There's this line on arch's wiki: "Before using a particular ICC loader, you should understand that some tools set only the calibration curves (e.g. xcalib), other tools set only the display profile to X.org _ICC_PROFILE atom (e.g. xicc) and other tools do both tasks at once (e.g. dispwin, dispcalGUI-apply-profiles)."

When I call displaycal-apply-profiles, it does the following:

/home/user/Downloads/Argyll_V1.9.2/bin
ArgyllCMS 1.9.2
...ok.
--------------------------------------------------------------------------------
Working directory:
  /
   home/
    user/
     .local/
      share/
       icc/

Command line:
  dispwin
    -v
    -d1
    'B156HW01 #1 2017-08-07 23-19 2.2 F-S XYZLUT+MTX.icc'

About to open dispwin object on the display
About to set display to given calibration
Calibration set
About to destroy dispwin object

Coming back to the _ICC_PROFILE atom, it looks like this is indeed affecting how chrome (61), and incidentally EOG, behave. I found this post (https://codeyarns.com/tag/icc-profile/), which suggests "xprop -root -remove _ICC_PROFILE" to solve the washed out colours problem in EOG. This also fixes it for chrome. If I set it to my actual icc profile with xicc, the colours become washed out again. Does this have to do with the fact that dispcal has already modified the GPU's LUT, and chrome/EOG aren't accounting for that ?

Thank you for providing more feedback. Adding requester "ccameron@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I confimed that dispcal does indeed set _ICC_PROFILE atom during the installation phase. i.e., it is a one time thing. After calibrating, if you choose to install the profile, it sets it. It doesn't set it when you call 'displaycal-apply-profiles', which is called on startup.

It sounds to me that this calibration scheme is causing the color space to be applied twice.

This is unique to version 61 though. I have chromium 60.x from the ubuntu repos, and chrome 61 on the same system. If there's some A/B testing that helps in narrowing it down, I can do that.

So far, we've been assuming that _ICC_PROFILE describes the frame buffer color profile. This means that when chrome loads web content and color-manages it, it adjusts it according to the color profile and outputs those colors to the frame buffer.

If the color management happens after we output data to the framebuffer, what's the point of setting _ICC_PROFILE ?

Also, since most monitors today have an 8-bit-per-channel data connection to the frame buffer, doing color management with a GPU LUT will usually lead to color banding.

I'm not exactly sure to what extent dispcal modifies the GPU LUT. In the menu, it is labelled as "GPU gamma table". This also seems to concur with the previous comment from arch's wiki, in that it seems to combine the functions of xcalib and xicc. I did try resetting the gamma table, which takes my monitor back to stock settings. This doesn't seem to solve the original problem though. i.e., 60 and 61 show different colours, with 61's colours still off (irrespective of GPU gamma settings or the icc profile returned by xprop -display :0.0 -len 14 -root _ICC_PROFILE). 

Chrome 60 ignores the ICC profile by default.
Chrome 61 reads it and tries to adjust everything based on it, so it's natural for them to behave differently in this case.

If chrome 60 seems more correct than 61, that means that either chrome, your ICC profile or your expectations are broken, now we just have to figure out which. :)

You can make chrome 61 behave like chrome 60 by unsetting your icc profile or setting it to an sRGB ICC profile.

Yes, that is a correct assessment. 60 seems correct, which is the same as 61 after resetting the _ICC_PROFILE or setting it to srgb. I can attach my icc profile if it helps.

Attaching icc profile generated with dispcal

Deleted: B156HW01 #1 2017-08-07 23-19 2.2 F-S XYZLUT+MTX.icc 723 KB

B156HW01 #1 2017-08-07 23-19 2.2 F-S XYZLUT+MTX.icc 723 KB Download

Looks like a parallel issue on dispcal's forum has also been opened. Here's the link for reference: https://hub.displaycal.net/forums/topic/chrome-61-washed-out-colors-and-banding/

Updating the bug title to reflect this.

I see banding in dark colors in images/video using DisplayCAL on Windows 10 under 61 but not 60. Is this likely to be the same issue?

> I confimed that dispcal does indeed set _ICC_PROFILE atom during the installation phase. i.e., it is a one time thing. After calibrating, if you choose to install the profile, it sets it. It doesn't set it when you call 'displaycal-apply-profiles', which is called on startup.

DisplayCAL-apply-profiles does set the _ICC_PROFILe atom -if required- (on a modern system, a colord-aware session daemon will do this work instead, although colord AFAIK expects you to preferably use its native API).

> It sounds to me that this calibration scheme is causing the color space to be applied twice.

Don't quickly jump to wrong conclusions. Consult the DisplayCAL and ArgyllCMS documentation for the difference of calibration vs characterization and how they (usually) go hand in hand.

> So far, we've been assuming that _ICC_PROFILE describes the frame buffer color profile. This means that when chrome loads web content and color-manages it, it adjusts it according to the color profile and outputs those colors to the frame buffer.

Correct, and this is all you need to do and care about.

The original reporters bug report is wrong. As his display is wide-gamut, the color managed result of displaying sRGB imagery is (of course!) correctly less saturated than just displaying the sRGB data as-is (i.e. incorrectly oversaturated).

>DisplayCAL-apply-profiles does set the _ICC_PROFILe atom -if required- (on a modern system, a colord-aware session daemon will do this work instead, although colord AFAIK expects you to preferably use its native API).

My test was to set the profile using xicc, or reset it with xprot, and calling displaycal-apply-profiles after that. It doesn't seem to set it. If I go to the GUI and click on install profile, that sets it. This is unrelated to this bug though.

Re #16, please file a separate bug for Windows.

>The original reporters bug report is wrong. As his display is wide-gamut, the color managed result of displaying sRGB imagery is (of course!) correctly less saturated than just displaying the sRGB data as-is (i.e. incorrectly oversaturated).

Do you mean that chrome 61, and EOG are displaying the right thing ? Note that EOG and gimp have different behaviour. If I open images in GIMP, they "look" correct, whereas EOG again shows, what appears to me, washed out images. I'm also attaching a screenshot of what I see in 60 v/s 61. The one on the left is 60 and the one on the right is 61.

Deleted: Screenshot from 2017-09-06 17-20-30.png 128 KB

	Screenshot from 2017-09-06 17-20-30.png 128 KB View Download

> Do you mean that chrome 61, and EOG are displaying the right thing ?

Correct

> Note that EOG and gimp have different behaviour. 

gimp requires that you opt-in to respecting the system color calibration.

You can do that in preferences -- see attached screenshot. With that setting enabled, it will match EOG and Chrome 61.

Marking this as a dupe.

Thanks, Florian, for pointing out that I was jumping the gun in assuming that this was a double-conversion and not just the usual sRGB on WCG monitor.

Deleted: gimp-color.png 84.2 KB

	gimp-color.png 84.2 KB View Download

Yes, changing that setting in GIMP makes it similar to EOG. There's another puzzling thing though. If I take a screenshot of my screen (including chrome 61), and open it in any of these apps, it looks different (even duller than before). So here's what's happening: 1) Open something on chrome 61 2) Press print-screen 3) Open the image in chrome 61. 1 and 3 are different. 

Re #24:

I'd suspect that that is because the image captured by pressing print-screen isn't specifying a color space correctly. The image *should* have an embedded color profile that specifies that it is in the output monitor's color space.

You can correct this by (in gimp) doing "Image -> Mode -> Assign Color Profile", and specify the monitor's color profile.

Thanks. Yes, print-screen issue is fixed after "assign color profile". So what is chrome 61 supposed to show for colours that are outside srgb ? For eg., on this page, https://webkit.org/blog-files/color-gamut/, for the first two samples (shoes and webkit logo), I can't see any difference between the srgb and adobe rgb images on chr 61 (i.e., no logo), whereas I can on chr 60. Is that expected ? Or is the icc profile limiting everything to srgb ? The webkit logo is also the one with the most stark difference in colour and saturation. Intuitively, it feels like I should be able to see those colours since the monitor can display them.

Yes that (and the related https://webkit.org/blog-files/color-gamut/comparison.html) are excellent test pages for WCG support.

If you've removed your _ICC_PROFILE atom (or set it to sRGB), then Chrome 61 will crush everything down to sRGB.

Note that Chrome doesn't re-read the _ICC_PROFILE setting whenever it changes -- you may need to restart Chrome to see the change.

I haven't removed the  _ICC_PROFILE atom. It is set to the same as the previous linked icc profile created by dispcal. For the logo test case, I see a divergence between chr61 and EOG. No visible logo with the former, whereas logo with the latter. 

Thanks for uploading your profile in #13 -- that was critical in debugging this. 

There is a Chrome bug here -- you're being crushed to sRGB unnecessarily.

The sequence of events is as follows:

The profile attached in #13 uses a table based transfer function. We can't rasterize (like, draw text, images, etc) using table based transfer functions, so we do an analytic approximation. This works most of the time, but in your profile's case, the numerical approximation has an error of ~2.5/255, which we consider to not be high enough fidelity.

This gets on to a very rare path where we rasterize to one space, then do LUT-based GPU conversion at composting time.

The problem is that if our approximation isn't precise, we accidentally destroy the ability to get it back when we IPC it over to the renderer process. The result is that the renderer says "whoops, we don't know what this space should be, let's just use sRGB".

This crush-to-sRGB bug will be fixed in Chrome 62.

Thanks for persisting. Quite a few interesting things came out of this exercise. Btw, another quirk that I've noticed on windows 10 (same machine & profile) is that this new feature isn't being activated consistently. If I open chrome from the default launcher, it uses the same behaviour as 60 (i.e. no profile awareness). However, if I restart chrome from the session with chrome://restart, it changes to colour correct rendering (as on linux). I suspected the flags playing a role, but all flags are default. Even explicitly enabling "Color correct rendering" in flags doesn't change this quirk. The only thing that works is relaunching chrome from within chrome.

> [...] calling displaycal-apply-profiles after that. It doesn't seem to set it

The output of displaycal-apply-profiles above clearly seems to indicate otherwise ("About to set display to given calibration ... Calibration set"). Note that dispwin *always* sets the _ICC_PROFILE atom when loading calibration from an ICC profile (and not a .cal file).

> There is a Chrome bug here -- you're being crushed to sRGB unnecessarily.

Alright, but this then only happens if the source is not (assumed) sRGB. Still nice to have it fixed of course.

> The profile attached in #13 uses a table based transfer function. We can't rasterize (like, draw text, images, etc) using table based transfer functions, so we do an analytic approximation.

Hmm. That seems like a kludge to me. Why not composite in an intermediate space and apply the output transform from that to display as the last step? I see no reason why you would want to use the display space as compositing space (other than maybe performance?) and quite some potential drawbacks.

> this then only happens if the source is not (assumed) sRGB

True -- any content in the sRGB gamut will appear correct. Content outside will be crushed.

> Why not composite in an intermediate space and apply the output transform from that to display as the last step?

Oh, this is a terminology difference. We do things like draw text, colors, images, etc, in the intermediate space (which has the same primaries, but a different transfer function), and then when we draw to the screen we convert to the actual display space.

Just another interesting data point. It looks like color management isn't applied to PDFs opened in chrome. It is applied to videos though.

Re #33, please file a bug against the PDF issues that you're seeing, including:
- what extensions, if any, you're using to view PDFs
- an example PDF that isn't having color management applied

I got the chrome 62 update today, and the issue with wide gamut images is still present. It is not getting crushed to srgb anymore, but it also not being colour managed. For the webkit logo case on https://webkit.org/blog-files/color-gamut/, the P3 image shows saturated reds, and different from eog. In eog, both the srgb and p3 images look similar except for the logo in the center. In chrome 62, the p3 image looks like it is not being colour managed. The logo in the center is visible.

(changing description back)

Re #35 ... please attach a screenshot. Also please "Reset all to default" your settings in about:flags.

Also, in Chrome Canary, if you go to about:gpu, it will print a short description of your output color space.

left is chromium 64.0.3244.0, right is eog. I had to assign the profile in gimp and save again as discussed earlier in the thread since the print screen key doesn't embed the profile. Also attached gpu.html.

Deleted: Screenshot from 2017-10-19 07-31-00.png 833 KB

	Screenshot from 2017-10-19 07-31-00.png 833 KB View Download

Deleted: gpu.html 61.8 KB

gpu.html 61.8 KB View Download

Re-opening to take a look with 64

This is also present when running Chrome with the headless flag, e.g via puppeteer. Using '--force-color-profile' or other options does not seem to have any effect.

Are there any workarounds we can use for headless while this is being investigated?

Re #39, please file a separate bug for headless issues.

Just checking in since I got a notification. Was the issue in 37 reproduced ? Btw, I saw the same behaviour in windows as well as linux. So it seems to be independent of the OS.

This still happens on Chrome version 64 on Windows 10 x64 using display profiles generated from DisplayCal.

Is there an issue for this bug and related problems on Windows? I've been having problems in Chrome for months and thought it was the AMD drivers but found a post on the DisplayCAL forum that pointed here: https://hub.displaycal.net/forums/topic/chrome-61-washed-out-colors-and-banding/

The problems I'm seeing:

1) Bad greys with opacity in Chrome on my primary monitor. I think it might be using the ICC profile from my second monitor as dragging the Chrome window to the other monitor fixes it.

2) Weird transparent layers similar to this screenshot from the DisplayCAL forum: https://i.imgur.com/vk1hFSi.png Resizing the window makes these go away.

3) Green grids like shown here: https://www.reddit.com/r/Amd/comments/7jm6u8/this_ongoing_issue_has_become_worse_with_the/

4) WebGL randomly crashing on Twitch.

5) Chrome's chrome becoming corrupt when moving tabs between monitors.

All of these seem to be fixed or reduced by setting "force colour profile" in chrome://flags to "sRGB".

Attached my profile for my monitor calibration generated by Displaycal that is causing issues (Chrome version 64 on Windows 10 x64).

Forcing sRGB "force color profile" is a valid workaround, but other apps like Spotify and other apps built on the chromium engine still suffer from this issue (since you can't force sRGB color profile).

Deleted: ASUS MG279 #1 2018-02-01 18-57 2.2 F-S XYZLUT+MTX.icm 723 KB

ASUS MG279 #1 2018-02-01 18-57 2.2 F-S XYZLUT+MTX.icm 723 KB Download

Here is a screenshot of the issue in the latest Spotify (since you can't force sRGB color mode).

Deleted: Spotify_2018-03-05_02-16-32.png 61.3 KB

	Spotify_2018-03-05_02-16-32.png 61.3 KB View Download

Just to confirm I've seen this with Spotify too.

Is everyone with these problems running AMD + DisplayCAL profiles?

It seems to be an issue when hardware acceleration is enabled with DisplayCal profiles. I have a 1080 ti so it's not just an AMD issue.

You can turn off hardware acceleration in Spotify as a temporary workaround.

There are too many different issues polluting this bug. Closing this instance.

I've filed a new bug, issue 820233 with the color profile from #13, because Chrome is producing different results, and that needs to be understood.

If anyone has a distinct issue, please file a separate bug, and attach your ICC profiles to it.