I am not able to reproduce this on a Linux ChromeOS build (66.0.3345.0).

We're starting to get reports from users about color issues on M66 Beta.

See these reports on 66.0.3359.67 beta, with logs:
https://listnr.corp.google.com/report/85244600927
https://listnr.corp.google.com/report/85249205321
https://listnr.corp.google.com/report/85248656438
https://listnr.corp.google.com/report/85248620242
https://listnr.corp.google.com/report/85244595823

Per this post on the Community Forum, it may just be affecting the external display

https://productforums.google.com/forum/#!msg/chromebook-central/mRhgT2BuPCo/4lJkgxtMAgAJ

Per the forum link above, the flags in the screenshot are related to the issue. cc'ing some more people. 

Deleted: Screenshot 2018-03-29 at 20.35.36.png 22.5 KB

	Screenshot 2018-03-29 at 20.35.36.png 22.5 KB View Download

+more graphics folks

I am wondering if this might be related to NV12 support?

afakrhy, doubt the NL has anything to do with it, but let's verify.

trumbull@ can we get more dets on what steps users took when they were able to resolve the issue?

#6: NV12 has landed recently, don't think it's in beta already?

66 has color space correction taken from the monitor EDID blob:
 r534422 --> initially landed in 66.0.3341.0

There should be a flag chrome://flags#use-monitor-color-space
enabled by default, could we try disabling it to see if it's the
culprit?

Does this happen on external monitors only? If so that's the color space changes. Similar issues have been reported on the Chrome side before, with the same functionality. It sounds like we will need to start adding more workarounds.

I doubt this is related to NV12 since I don't see any video in those reports.

Night Light is most probably not related, we haven't enabled it yet and is still behind a flag. Also NL makes the entire screen more red. From the screenshots in the feedback reports, this issue seems to affect only the blues.

+mcasas@ Any color correction issues?

+danakj@ in case there's something in the compositor. 

This sounds like the CrOS instance of  issue 755747  -- some users don't expect the color profile of their monitor to be applied.

@12: In this case I think the profiles are flat out incorrect. Definitely the one in 755747 turned out to be (I followed all the conversion steps, but assumed the initial profile was good, so disregard my early comments in this bug).

IMO the question is what can we do to detect profiles that steer away too far from "normal" colors. I'll let Miguel figure something out :)

 rkalavakuntla@, trumbull@, do we have a clear view of on which platforms
these bugs are popping up?  I see Peppy,Candy,Celes from the description,
but does it happen on panels? External monitors only? Mix...?

marcheu@ had the insight that blues should never look purple or
actually change very much; indeed to the best of my knowledge 
most of the color spaces' blue primarie tends to be around 
the 0.15-0.06 -- see the attached diagrams, but also numerically:

sRGB    0.15    0.06
BT.709  0.15	0.06
Adobe   0.1500	0.0600
DCI-P3  0.150	0.060   (D65)
BT.2020 0.131	0.046

So let's add a heuristic to filter out strange blue chromaticities.

Ideally, it'd be great to find the EDID of one of the reports
(can be found inside chrome:system-->modetest), to add a test case
for these situations. 

Deleted: cie_diagram.png 378 KB

	cie_diagram.png 378 KB View Download

Deleted: video-gamuts.png 187 KB

	video-gamuts.png 187 KB View Download

You can probably look at https://bugs.chromium.org/p/chromium/issues/detail?id=755747#c21 which has the ascii EDID for one such display (that's the bug where I checked that the EDID color points were properly converted at each step in the whole chain, but forgot to check that the initial values were sane, which they weren't...)

Release Boards reporting this issue include: Reks, Gnawty, Lulu, Peppy, and Gandof. 

A Googler submitted one of the feedback reports, I can reach out and confirm whether it's only the external monitor.

#18: yeah, that EDID (see below) corresponds to 
  Blue chromaticity........ Bx 0.149 - By 0.137

the second value is toast. Working on a CL to filter those out.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f8a9599429528169837d0b6c981c0b4a04a5660f

commit f8a9599429528169837d0b6c981c0b4a04a5660f
Author: Miguel Casas <mcasas@chromium.org>
Date: Wed Apr 04 18:39:19 2018

display: ignore EDID-provided colorspace if blue is broken

Some EDID-provided chromaticity coordinates for the blue colour are
too far from the expected ones, causing blue to be rendered as purple
(or cyan, in some cases). This is due to broken primaries, as all the
standard colorspaces' blues are clustered nearby.

This CL adds a sanity check for the blue coordinates (need to be to
the left and below of a given point) and adds a unit test for it. If
the condition doesn't verify, we just ignore this ColorSpace -- which
means we'll treat the monitor as sRGB.

Bug:  809909 ,  771345 
Change-Id: I4555625928f883825a3b315abdaaa379eb26a415
Reviewed-on: https://chromium-review.googlesource.com/993513
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Reviewed-by: Daniele Castagna <dcastagna@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548138}
[modify] https://crrev.com/f8a9599429528169837d0b6c981c0b4a04a5660f/ui/ozone/platform/drm/common/drm_util.cc
[modify] https://crrev.com/f8a9599429528169837d0b6c981c0b4a04a5660f/ui/ozone/platform/drm/common/drm_util_unittest.cc

Requestin merging #21 (r548138) to betas...

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), josafat@(ChromeOS), abdulsyed@(Desktop)

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

 Issue 827764  has been merged into this issue.

An alternative to merging #21 to Beta is to revert 
https://chromium.googlesource.com/chromium/src.git/+/4420416ee2078ea69f781d41397417e969e82df1  
(reviewed on crrev.com/c/899470), which made the flag enabled by default.

Can we verify this on canary before merging back?

Do we have a monitor that exhibits this?

#26: Dev/Canary have been stuck on 67.0.3383.0 since 03/29, so no Canary has
seen the fix. We have identified at least a given Chromebook with the issue,
but haven't been able to verify the fix -- the unittest addition in #21 is
actually based on its EDID blob.

What do you guys rather do, #25 == mark flag as disabled by default or land
the fix #21 ? (josafat@, bhthompson@)

The device showing the issue is a lulu , btw

Canary is now revved, pls confirm this is  working as expected 

ping?

We haven't been able to verify any Dev build because I haven't got my
hands on hardware presenting the problem. OTOH there haven't been many
bug reports/use feedbacks mentioning this issue.

Anyway, re. #30, the easiest option would be to disable the flag on 66 
branch and we try again on 67 -- this is nearly trivial, just flipping 
the line in [1] to FEATURE_DISABLED_BY_DEFAULT.

josafat@ WDYT?

[1] https://cs.chromium.org/chromium/src/ui/display/display_switches.cc?type=cs&q=display/display_switches.cc&sq=package:chromium&l=71

agreed, considering we are very close to stable disabling sounds like the right call here 

josafat@, target branch is 3359, correct?

Put up crrev.com/c/1012305 with the idea of cherry-picking to the
appropriate branch when known. (3359 wasn't known :?)

Merge-Request-67  -- on #34 that is in flight.

Can you test and advise when verified?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/51b5b7bc4217c7c430ce3453c9fd8360e7274f24

commit 51b5b7bc4217c7c430ce3453c9fd8360e7274f24
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Mon Apr 16 22:36:25 2018

kUseMonitorColorSpace: mark DISABLED_BY_DEFAULT

Mark kUseMonitorColorSpace disabled by default to avoid
the blue-color-looks-purple problems detailed in the bug.
This is just a temporary CL to allow cherry-picking it
into the beta branch.

TBR=dcastagna@chromium.org

Bug:  809909 
Change-Id: I35bb8cc48c26091cb1752d3d7709a48d23fb4c6e
Reviewed-on: https://chromium-review.googlesource.com/1012305
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551152}
[modify] https://crrev.com/51b5b7bc4217c7c430ce3453c9fd8360e7274f24/ui/display/display_switches.cc

#36: #37 disables the feature, so it solves the problem. Verified
locally that ToT ignores the feature :-)

ok, approved for M66

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bfa8b7e1e8c3eb175c7ac82b6713e7b9867a65be

commit bfa8b7e1e8c3eb175c7ac82b6713e7b9867a65be
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Tue Apr 17 14:49:29 2018

kUseMonitorColorSpace: mark DISABLED_BY_DEFAULT

Mark kUseMonitorColorSpace disabled by default to avoid
the blue-color-looks-purple problems detailed in the bug.
This is just a temporary CL to allow cherry-picking it
into the beta branch.

TBR=dcastagna@chromium.org

Bug:  809909 
Change-Id: I35bb8cc48c26091cb1752d3d7709a48d23fb4c6e
Reviewed-on: https://chromium-review.googlesource.com/1012305
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#551152}(cherry picked from commit 51b5b7bc4217c7c430ce3453c9fd8360e7274f24)
Reviewed-on: https://chromium-review.googlesource.com/1013755
Cr-Commit-Position: refs/branch-heads/3359@{#728}
Cr-Branched-From: 66afc5e5d10127546cc4b98b9117aff588b5e66b-refs/heads/master@{#540276}
[modify] https://crrev.com/bfa8b7e1e8c3eb175c7ac82b6713e7b9867a65be/ui/display/display_switches.cc

Marking as Fixed per c40 to unblock.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/51b5b7bc4217c7c430ce3453c9fd8360e7274f24

commit 51b5b7bc4217c7c430ce3453c9fd8360e7274f24
Author: Miguel Casas-Sanchez <mcasas@chromium.org>
Date: Mon Apr 16 22:36:25 2018

kUseMonitorColorSpace: mark DISABLED_BY_DEFAULT

Mark kUseMonitorColorSpace disabled by default to avoid
the blue-color-looks-purple problems detailed in the bug.
This is just a temporary CL to allow cherry-picking it
into the beta branch.

TBR=dcastagna@chromium.org

Bug:  809909 
Change-Id: I35bb8cc48c26091cb1752d3d7709a48d23fb4c6e
Reviewed-on: https://chromium-review.googlesource.com/1012305
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551152}
[modify] https://crrev.com/51b5b7bc4217c7c430ce3453c9fd8360e7274f24/ui/display/display_switches.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d526111ea8b0da1e0666c93888490780d26f9135

commit d526111ea8b0da1e0666c93888490780d26f9135
Author: Miguel Casas <mcasas@chromium.org>
Date: Tue Apr 17 18:47:20 2018

Revert "kUseMonitorColorSpace: mark DISABLED_BY_DEFAULT"

This reverts commit 51b5b7bc4217c7c430ce3453c9fd8360e7274f24.

Reason for revert: This CL landed on master so that it could be 
cherry-picked on M66 branch, which it did on crrev.com/c/1013755,
so it can be reverted now.

Original change's description:
> kUseMonitorColorSpace: mark DISABLED_BY_DEFAULT
> 
> Mark kUseMonitorColorSpace disabled by default to avoid
> the blue-color-looks-purple problems detailed in the bug.
> This is just a temporary CL to allow cherry-picking it
> into the beta branch.
> 
> TBR=dcastagna@chromium.org
> 
> Bug:  809909 
> Change-Id: I35bb8cc48c26091cb1752d3d7709a48d23fb4c6e
> Reviewed-on: https://chromium-review.googlesource.com/1012305
> Reviewed-by: Miguel Casas <mcasas@chromium.org>
> Commit-Queue: Miguel Casas <mcasas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#551152}

TBR=mcasas@chromium.org

Change-Id: Ie1f6d2eae27e1332374f696a5d17a8dacebac3e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  809909 
Reviewed-on: https://chromium-review.googlesource.com/1015142
Reviewed-by: Miguel Casas <mcasas@chromium.org>
Commit-Queue: Miguel Casas <mcasas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551406}
[modify] https://crrev.com/d526111ea8b0da1e0666c93888490780d26f9135/ui/display/display_switches.cc

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Using chromium 69 on ubuntu 18.10, I got this problem too. I don't knwo if it could be qualified as the problem or not.

I already had the problem on chroomium 68 and ubuntu 18.04

Take a look at that https://imgur.com/a/wXo89Fy
The color is fine in eog, but wrong in chromium

And don't look at this image in chromium.

Deleted: Capture d’écran du 2018-10-22 10-22-29.png 109 KB

	Capture d’écran du 2018-10-22 10-22-29.png 109 KB View Download

Ok.
So @fsod told me on IRC to force using the sRGB color profile in chrome settings. It fixed the problem.

So somehow, the color profile of the monitor was wrong. Even though I tried with the one provided by the manufacturer.