Tested the issue using #61.0.3163.39 on Linux Ubuntu 14.04 and Win 10 and was unable to reprodcue the issue as per seps mentioned in comment #0. Did not observe any color swatch from blue to purple.

@averstak: Could you please find the attached screencast and let us know if we missed any steps from our end. That would help us in further triaging of the issue.

Thanks

I think "broken" may not be the right word to use here.

Chrome pays attention to the color profile as specified by the _ICC_PROFILE atom. You can modify your installed profile using xicc.

Chrome will convert all colors (note that CSS colors and most images are specified as sRGB) to the output device color space.

If you have installed a color profile that you did not mean to install, you can reset your machine back to using sRGB as its color profile by running
  xicc /usr/share/color/icc/colord/sRGB.icc

> Monitor is Samsung 210T; it has a so-titled ICC profile
> in system settings (I'm guessing it's vendor's default
> profile for this model).

Can you clarify which "system settings" this refers to? I'm getting several reports of having the _ICC_PROFILE atom set to random values that were not intended. It may be that the state of color management on Linux is less coherent than we may have thought.

Yes, changing system ICC profile to sRGB fixes it.  Thanks!

"System settings" is /usr/bin/unity-control-center; my guess is it changes _ICC_PROFILE just like xicc.

Bogus ICC profile was the default, not a custom setting.  Not sure what fraction of Linux users this affects, or if there's a way to automatically detect problem cases.  Mine is a recent standard issue Goobuntu desktop with an old monitor.

Linux <snip> 4.4.0-72-generic #93~14.04.1-Ubuntu SMP Fri Mar 31 15:05:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Monitor = Samsung SyncMaster 210T

If the plan is to enable color management by default on Linux, it may be appropriate to uplift the color management flag from about:flags to regular settings.  Or show color swatches in settings and explain how to reset the system ICC profile if they don't look right.  This is technically a system setting rather than a Chrome setting, but in practice it looks like Chrome is showing wrong colors and all other apps are fine.

Thank you for providing more feedback. Adding requester "sandeepkumars@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

 Issue 758208  has been merged into this issue.

+hubbe, marcheu, piman

I just merged in another instance of someone having an ICC profile installed that they weren't aware of.

This is getting to be a pretty pervasive problem. Almost all Linux applications completely ignore the system display configuration -- even image viewers.

I checked gimp, and that ignores the system color profile by default, but you can tell it to pay attention to the display profile in preferences... see the attached screenshot.

I'm wondering if we should force all Linux displays to be sRGB for Chrome 61, and maybe migrate the "color correct rendering flag" to a "force sRGB profile" flag, and do that by default on Linux.

Deleted: gimp-color.png 84.2 KB

	gimp-color.png 84.2 KB View Download

questions:

1. These people who have ICC profiles they are not aware of, is the ICC profile correct for their actual monitor?

2. Are these people googlers? (goobuntu does a bunch of extra stuff to set up displays that ubunutu doesn't do.)

3. If they have incorrect ICC profiles, how did they get them? Did they run or install a program? Is it their linux distribution? 

Forcing sRGB for linux does not sound like the correct solution to me. My expectation is that people fall into three buckets:

a) no icc profile (vast majority)
b) system installed ICC profile, which is in fact the right one for the monitor
c) user fiddled with ICC profiles at some point (knowingly or unknowingly)

My expectation is that (c) is a very small minority.

The only reason for chrome to completely ignore ICC profiles would be if major linux systems routinely configured and installed ICC profiles which are incorrect for the monitor they have IMHO.

Feel free to assign bugs like this to me if you get tired of them.

Also, in this particular case: Do we know that the ICC profile is bogus, or is it our interpretation of the ICC profile that is off?

> Also, in this particular case: Do we know that the ICC profile
> is bogus, or is it our interpretation of the ICC profile that is off?

Good question. I suspect we're doing all the right math, but we should double-check.

averstak@, could you attach your original ICC profile to the bug?

Attached ICC profile for comment 12.

Re comment 10 and 11, keep in mind the ICC profile is not the only color adjustment.  It's combined with: (1) the monitor's hardware controls, (2) the calibration table in the graphics card, and (3) the ambient light.  See:

https://displaycal.net/#concept

I played a bit with a colorimeter on two different Linux machines; all three factors seem to make a visible difference.

A. Home machine - Ubuntu XFCE, nVidia, smaller Samsung monitor.  First attempt at calibration produced a moderate purple cast.  Changed cheap green CFLs to daylight-balanced CFLs and redone calibration - no color cast.

I'm not entirely sure the ambient was the only factor, though.  Second time around I didn't completely trust the colorimeter when adjusting the whitepoint with monitor's controls (1).  It was measuring an awfully light patch where I couldn't tell by sight if there was a color cast or not; so I also looked at a gray patch where the color cast was more visible.

B. Work machine - Goobuntu, nVidia, larger Samsung monitor.  This is the one with the attached allegedly bogus ICC profile.  Monitor's own color controls (1) are disabled (possibly because it's a DVI connection?).  Color tone can be adjusted in nVidia's software settings, which, presumably, changes (2).  Alas, the calibration process also changes (2), which leaves no obvious way to manually calibrate the whitepoint.  Auto calibration did fine on the color cast but ended up with rather dull colors, so I reverted it to defaults for now.

Moral of the story is that the allegedly bogus ICC profile may not be plain wrong, but rather may work in a different environment.

Since it creates a strong purple cast, one possibility is that this ICC profile was made under very green fluorescent ambient lights.  If that's the case, tough luck telling if it was intentional or not.

Another possibility is that it somehow disagrees with the calibration table in the graphics card.  From my limited understanding of the displaycal's docs, this table is also supposed to be embedded in the ICC file, and supposed to be loaded into the graphics card from there (where it affects all applications, just like monitor's hardware controls).  Maybe it's not embedded, or maybe it's embedded but nVidia loads some other table, or maybe it's embedded and then both loaded into the graphics card and also applied in software by Chrome (which would probably be a bug in Chrome).

It could also be a bogus ICC file, of course.

Anyhow, I'm just a clueless end user, and my understanding of color management may be completely wrong. :-)  If it isn't practical to fix the underlying issue, it would help to make it more obvious to users how to work around it.

Deleted: edid-5079b85a28414afdc4d8ef5a3acde478.icc 1.9 KB

edid-5079b85a28414afdc4d8ef5a3acde478.icc 1.9 KB Download

Graphics-card-based calibration should only be used for analog monitors.
Nvidia cards seem to ignore the gpu calibration tables when the output is digital. This is a good thing since 8-bit-to-8-bit mappings tends to cause a lot of banding. (Some monitors support digitial outputs with more than 10 bits, not sure if graphics cards will use LUTs for those or not.)

Ambient light does play a factor, but when preparing an ICC profile for an unknown environment, it should always be done with a D65 whitepoint. If something installed an ICC profile for you automatically and it's not using a D65 whitepoint, that's a bug.

Personally I don't generally trust colorimiter-generated profiles, as they seem to mess things up more than they fix things. I usually stick with factory ICC profiles, even if they aren't always 100% accurate.

Heh: https://xkcd.com/1882/

That xkcd exactly mirrors my journey through the magical world of color.
Except, at the end of the day, it's not someone else's problem.

PS: Make sure to read the hover text...

Hover text is why I thought it's particularly relevant :)

That said, it got me thinking. It's possible that (some) compositing managers try to apply color correction for the display - it's their role after all - and by Chrome doing so we might get things wrong. Obviously if there's no compositing manager (or if it doesn't do color correction), Chrome would still need to be the one doing it.

I've never seen a spec that actually clarifies who's role it is to do what when it comes to color management on linux, or any X11-based platform.
However, there seems to be at least one window manager that does this, through a plugin called CompICC. In the description, it says that color-aware applications can disable this behavior, but it doesn't say how.

@13: how did you create your .icc file? And in particular, how did you name it? 

If you didn't name it, then the name implies that the icc file was created based on EDID data, which is often broken. If that is the case, I would be interested in seeing your edid (which you can grab by pasting the output of xrandr --verbose here).

I suspect that it wasn't created from the EDID data (is that even possible?) but associated with a hash of the EDID in some database somewhere.

I didn't create or name that .icc file; it came that way with Goobuntu.

$ xrandr --verbose
Screen 0: minimum 8 x 8, current 1600 x 1200, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x2dc
	Timestamp:  222711
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	CscMatrix: 65536 0 0 0 0 0 0 0 0 0 65536 0 
	BorderDimensions: 4 
		supported: 4
	Border: 0 0 0 0 
		range: (0, 65535)
	SignalFormat: VGA 
		supported: VGA
	ConnectorType: DVI-I 
	ConnectorNumber: 0 
	_ConnectorLocation: 0 
DVI-I-1 connected primary 1600x1200+0+0 (0x2de) normal (normal left inverted right x axis y axis) 518mm x 324mm
	Identifier: 0x2dd
	Timestamp:  222711
	Subpixel:   unknown
	Gamma:      1.0:1.0:1.0
	Brightness: 1.0
	Clones:    
	CRTC:       0
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	_ICC_PROFILE: 0 11 62 76 0 0 0 0 2 64 0 0 109 110 116 114 
		82 71 66 32 88 89 90 32 7 225 0 8 0 23 0 16 
		0 8 0 12 97 99 115 112 0 0 0 0 0 0 0 0 
		0 0 45 76 0 0 66 82 0 0 0 0 0 0 0 0 
		0 0 0 0 0 0 246 214 0 1 0 0 0 0 211 45 
		0 0 0 0 27 168 220 10 170 244 252 30 201 251 197 206 
		124 237 194 31 0 0 0 0 0 0 0 0 0 0 0 0 
		0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
		0 0 0 22 100 101 115 99 0 0 1 140 0 0 0 140 
		99 112 114 116 0 0 2 24 0 0 0 74 108 117 109 105 
		0 0 2 100 0 0 0 20 119 116 112 116 0 0 2 120 
		0 0 0 20 98 107 112 116 0 0 2 140 0 0 0 20 
		118 99 103 116 0 0 2 160 0 0 6 18 65 50 66 48 
		0 0 8 180 0 3 122 140 114 88 89 90 0 3 131 64 
		0 0 0 20 103 88 89 90 0 3 131 84 0 0 0 20 
		98 88 89 90 0 3 131 104 0 0 0 20 114 84 82 67 
		0 3 131 124 0 0 2 12 103 84 82 67 0 3 133 136 
		0 0 2 12 98 84 82 67 0 3 135 148 0 0 2 12 
		65 50 66 49 0 0 8 180 0 3 122 140 66 50 65 49 
		0 3 137 160 0 3 176 122 66 50 65 48 0 7 58 28 
		0 3 176 122 116 97 114 103 0 10 234 152 0 0 74 25 
		68 101 118 68 0 10 234 152 0 0 74 25 67 73 69 68 
		0 10 234 152 0 0 74 25 99 104 114 109 0 11 52 180 
		0 0 0 36 109 109 111 100 0 11 52 216 0 0 0 40 
		109 101 116 97 0 11 53 0 0 0 9 76 100 101 115 99 
	CscMatrix: 65536 0 0 0 0 0 0 0 0 0 65536 0 
	EDID: 
		00ffffffffffff004c2d524231324350
		2b0c0103803320a22a564e9c5b509526
		235059bfef8081806159455931593140
		0101010101018c3240a060b019401e32
		130006442100001e000000fd0038551e
		510f000a202020202020000000fc0032
		313054204469676974616c0a000000ff
		0048344b544130303832380a202000f8
	BorderDimensions: 4 
		supported: 4
	Border: 0 0 0 0 
		range: (0, 65535)
	SignalFormat: TMDS 
		supported: TMDS
	ConnectorType: DVI-I 
	ConnectorNumber: 0 
	_ConnectorLocation: 0 
  1600x1200 (0x2de)  129.4MHz +HSync +VSync *current +preferred
        h: width  1600 start 1630 end 1680 total 1760 skew    0 clock   73.5KHz
        v: height 1200 start 1201 end 1204 total 1225           clock   60.0Hz
  1280x1024 (0x2df)  135.0MHz +HSync +VSync
        h: width  1280 start 1296 end 1440 total 1688 skew    0 clock   80.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   75.0Hz
  1280x1024 (0x2e0)  108.0MHz +HSync +VSync
        h: width  1280 start 1328 end 1440 total 1688 skew    0 clock   64.0KHz
        v: height 1024 start 1025 end 1028 total 1066           clock   60.0Hz
  1024x768 (0x2e1)   94.5MHz +HSync +VSync
        h: width  1024 start 1072 end 1168 total 1376 skew    0 clock   68.7KHz
        v: height  768 start  769 end  772 total  808           clock   85.0Hz
  1024x768 (0x2e2)   78.8MHz +HSync +VSync
        h: width  1024 start 1040 end 1136 total 1312 skew    0 clock   60.0KHz
        v: height  768 start  769 end  772 total  800           clock   75.0Hz
  1024x768 (0x2e3)   75.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1328 skew    0 clock   56.5KHz
        v: height  768 start  771 end  777 total  806           clock   70.1Hz
  1024x768 (0x2e4)   65.0MHz -HSync -VSync
        h: width  1024 start 1048 end 1184 total 1344 skew    0 clock   48.4KHz
        v: height  768 start  771 end  777 total  806           clock   60.0Hz
  800x600 (0x2e5)   56.2MHz +HSync +VSync
        h: width   800 start  832 end  896 total 1048 skew    0 clock   53.7KHz
        v: height  600 start  601 end  604 total  631           clock   85.1Hz
  800x600 (0x2e6)   49.5MHz +HSync +VSync
        h: width   800 start  816 end  896 total 1056 skew    0 clock   46.9KHz
        v: height  600 start  601 end  604 total  625           clock   75.0Hz
  800x600 (0x2e7)   50.0MHz +HSync +VSync
        h: width   800 start  856 end  976 total 1040 skew    0 clock   48.1KHz
        v: height  600 start  637 end  643 total  666           clock   72.2Hz
  800x600 (0x2e8)   40.0MHz +HSync +VSync
        h: width   800 start  840 end  968 total 1056 skew    0 clock   37.9KHz
        v: height  600 start  601 end  605 total  628           clock   60.3Hz
  800x600 (0x2e9)   36.0MHz +HSync +VSync
        h: width   800 start  824 end  896 total 1024 skew    0 clock   35.2KHz
        v: height  600 start  601 end  603 total  625           clock   56.2Hz
  640x480 (0x2ea)   36.0MHz -HSync -VSync
        h: width   640 start  696 end  752 total  832 skew    0 clock   43.3KHz
        v: height  480 start  481 end  484 total  509           clock   85.0Hz
  640x480 (0x2eb)   31.5MHz -HSync -VSync
        h: width   640 start  656 end  720 total  840 skew    0 clock   37.5KHz
        v: height  480 start  481 end  484 total  500           clock   75.0Hz
  640x480 (0x2ec)   31.5MHz -HSync -VSync
        h: width   640 start  656 end  696 total  832 skew    0 clock   37.9KHz
        v: height  480 start  481 end  484 total  520           clock   72.8Hz
  640x480 (0x2ed)   25.2MHz -HSync -VSync
        h: width   640 start  648 end  744 total  800 skew    0 clock   31.5KHz
        v: height  480 start  482 end  484 total  525           clock   60.0Hz
  640x480 (0x2ee)   25.2MHz -HSync -VSync
        h: width   640 start  656 end  752 total  800 skew    0 clock   31.5KHz
        v: height  480 start  490 end  492 total  525           clock   59.9Hz
DP-0 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x2ef
	Timestamp:  222711
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	CscMatrix: 65536 0 0 0 0 0 0 0 0 0 65536 0 
	BorderDimensions: 4 
		supported: 4
	Border: 0 0 0 0 
		range: (0, 65535)
	SignalFormat: TMDS 
		supported: TMDS
	ConnectorType: DisplayPort 
	ConnectorNumber: 1 
	_ConnectorLocation: 1 
DP-1 disconnected (normal left inverted right x axis y axis)
	Identifier: 0x2f0
	Timestamp:  222711
	Subpixel:   unknown
	Clones:    
	CRTCs:      0 1
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
	CscMatrix: 65536 0 0 0 0 0 0 0 0 0 65536 0 
	BorderDimensions: 4 
		supported: 4
	Border: 0 0 0 0 
		range: (0, 65535)
	SignalFormat: DisplayPort 
		supported: DisplayPort
	ConnectorType: DisplayPort 
	ConnectorNumber: 1 
	_ConnectorLocation: 1 

The raw chroma info block from the EDID is:

56 4e 9c 5b 50 95 26 23 50 59


Split it in bytes, it is:

25: 0x56 01 (red x lo2) 01 (red y lo2) 01 (green x lo2) 10 (green y lo2)
26: 0x4e 01 (blue x lo2) 00 (blue y lo2) 11 (white x lo2) 10 (white y lo2)
27: 0x9c (red x hi8)
28: 0x5b (red y hi8)
29: 0x50 (green x hi8)
30: 0x95 (green y hi8)
31: 0x26 (blue x hi8)
32: 0x23 (blue y hi8)
33: 0x50 (white point x hi8)
34: 0x59 (white point y hi8)


In XYZ, that is:

red x = 625 / 1024
red y = 365 / 1024
green x = 321 / 1024
green y = 598 / 1024
blue x = 153 / 1024
blue y = 140 / 1024
white point x = 323 / 1024
white point y = 358 / 1024


In RGB, that is:

red is (0.200816, 0.0356904, 0.00571729)
green is (0.0307525, 0.123337, 0.0175238)
blue is (-0.0187389, 0.0328739, 0.130341)
white point is (0.0499531, 0.0663102, 0.0606444)

(Used this for conversion
https://www.wolframalpha.com/input/?i=%5B%5B0.41847,+-0.15866,+-0.082835%5D,%5B-0.091169,0.25243,0.015708%5D,%5B0.00092090,-0.0025498,0.17860%5D%5D+*+%5B%5B0.323%5D,%5B0.358%5D,+%5B0.343%5D%5D )


So overall, the info from the EDID makes sense. It is probably broken somewhere along the way. Next thing to check is _ICC_PROFILE.

Oh actually, I notice blue here is negative. While that is correct color-wise, it could be that we hit an underflow somewhere, either in the code converting the EDID to _ICC_PROFILE, or later in Chrome? That theory would work very well with the observation that blue turns purple since because of the underflow we would be adding a huge amount of red to the blue.

Here is what we have in the .icc file, it seems correct as well:

EDID_red_x0.610352
EDID_red_y0.355469
EDID_green_x0.313477
EDID_green_y0.583984
EDID_blue_x0.149414
EDID_blue_y0.136719

averstak@ do you have an icm file in the same directory as the icc file by any chance? I'd be curious to see of that one is valid.

I don't see any .icm files there:

$ ls -l $HOME/.local/share/icc/
-rw-r----- 1 averstak eng 736844 Aug 23 16:15 210T #1 2017-08-23 15-42 D6500 2.2 F-S XYZLUT+MTX.icc
-rw-r----- 1 averstak eng   1956 Oct 22  2014 edid-5079b85a28414afdc4d8ef5a3acde478.icc
-rw-r--r-- 1 averstak eng   2428 Jan 16  2014 sRGB.icc

First file is from my later attempt to calibrate with a colorimeter - please ignore it, it was made after I filed this bug.

(BTW, if you'd like an hour of quality time with this workstation, it's a short walk and a shorter gbike ride.)

 Issue 762491  has been merged into this issue.

 Issue 762222  has been merged into this issue.

 Issue 762710  has been merged into this issue.

@averstak: Sadly xrandr truncates properties past 400 bytes (yeah I just found out too), so the _ICC_PROFILE from comment #21 is unusable.

Can you get the xrandr source from https://cgit.freedesktop.org/xorg/app/xrandr/, apply this patch, build it, and past the output of xrandr --verbose again?

diff --git a/xrandr.c b/xrandr.c
index 2d4cb72..b802abf 100644
--- a/xrandr.c
+++ b/xrandr.c
@@ -3855,7 +3855,7 @@ main (int argc, char **argv)
                    int k;
 
                    XRRGetOutputProperty (dpy, output->output.xid, props[j],
-                                         0, 100, False, False,
+                                         0, 4000, False, False,
                                          AnyPropertyType,
                                          &actual_type, &actual_format,
                                          &nitems, &bytes_after, &prop);


I think 4000 should be enough, but feel free to bump it if it isn't.

ICC file is in comment #13.

I'm not sure what xrandr's _ICC_PROFILE corresponds to - changing between sRGB and 210T in unity control center doesn't seem to change xrandr's output.  But attached it anyway.

Also attached the output of xprop -root | grep ICC - this one does change when I change the profile in unity control center.

Deleted: xrandr.txt 63.1 KB

xrandr.txt 63.1 KB View Download

Deleted: xprop_srgb.txt 9.0 KB

xprop_srgb.txt 9.0 KB View Download

Deleted: xprop_210t.txt 7.0 KB

xprop_210t.txt 7.0 KB View Download

#20 > I suspect that it wasn't created from the EDID data (is that even possible?)

It's possible, yes.
https://dxr.mozilla.org/mozilla-beta/source/gfx/thebes/gfxPlatformGtk.cpp#455

  edidAtom = XInternAtom(dpy, EDID1_ATOM_NAME, TRUE);
  if (edidAtom) { /* create color profile */ ... }

@31: sadly 4000 isn't enough. Can you just put an arbitrarily large number there and retry? Sorry about that...

Attached.

Deleted: xrandr2.txt 2.5 MB

xrandr2.txt 2.5 MB View Download

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

commit ceb8727d80e9ddd671577494ddeb1c182645833e
Author: Christopher Cameron <ccameron@chromium.org>
Date: Thu Sep 07 23:53:16 2017

Add about:flags to force color profile

Add an about:flag to force a specific color profile, and add some common
options to this flag. In particular:
  * sRGB, since it's the standard color space
  * Display P3, since it is a common wide gamut profile
  * scRGB Linear, since that will force HDR mode on Windows 10
  * A color spin non-standard gamma space, for testing

Some users who have wide color gamut monitors want the over-saturated
that non-color-correct rendering provided. For these users, on Chrome
61, they must either disable the color correct rendering feature, or
remove their system-installed color profile.

These users who want oversaturated colors on Windows and Linux will have
the option of forcing sRGB as their color profile in about:flags in
Chrome 62 and beyond.

R=hubbe
TBR=holte

Bug:  755747 
Change-Id: I80b37432ca42bd0500b443b892bc754727c3f7b7
Reviewed-on: https://chromium-review.googlesource.com/655802
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#500439}
[modify] https://crrev.com/ceb8727d80e9ddd671577494ddeb1c182645833e/chrome/browser/about_flags.cc
[modify] https://crrev.com/ceb8727d80e9ddd671577494ddeb1c182645833e/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/ceb8727d80e9ddd671577494ddeb1c182645833e/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/ceb8727d80e9ddd671577494ddeb1c182645833e/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/ceb8727d80e9ddd671577494ddeb1c182645833e/ui/display/display.cc

Requesting merge to M62

Attached is the icc profile binary from _ICC_PROFILE. It looks correct at first blush, but I didn't dig too much, there's a lot of stuff in there.

It could also be used to repro locally by setting the _ICC_PROFILE prop with a small piece of X code.

Deleted: icc4.bin 719 KB

icc4.bin 719 KB Download

 Issue 762776  has been merged into this issue.

Is there a reason that this is Restrict-View-Google? I'm duping lots of bugs here, and I'd like for the parent bug to be public.

Ping on M62 merge.

I installed the color profile that averstak has on their machine (from #38) on my Mac, and it turns my screen really blue.

So, yeah, that profile is probably not the one that you wanted installed on your machine.

As discussed, approving merge to M62. 

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

commit cb0f371788eb16f7ad8a6c8d75a3d669938464a2
Author: Christopher Cameron <ccameron@chromium.org>
Date: Fri Sep 08 19:57:53 2017

Add about:flags to force color profile

Add an about:flag to force a specific color profile, and add some common
options to this flag. In particular:
  * sRGB, since it's the standard color space
  * Display P3, since it is a common wide gamut profile
  * scRGB Linear, since that will force HDR mode on Windows 10
  * A color spin non-standard gamma space, for testing

Some users who have wide color gamut monitors want the over-saturated
that non-color-correct rendering provided. For these users, on Chrome
61, they must either disable the color correct rendering feature, or
remove their system-installed color profile.

These users who want oversaturated colors on Windows and Linux will have
the option of forcing sRGB as their color profile in about:flags in
Chrome 62 and beyond.

R=hubbe
TBR=ccameron@chromium.org, holte

(cherry picked from commit ceb8727d80e9ddd671577494ddeb1c182645833e)

Bug:  755747 
Change-Id: I80b37432ca42bd0500b443b892bc754727c3f7b7
Reviewed-on: https://chromium-review.googlesource.com/655802
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#500439}
Reviewed-on: https://chromium-review.googlesource.com/657809
Cr-Commit-Position: refs/branch-heads/3202@{#93}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/cb0f371788eb16f7ad8a6c8d75a3d669938464a2/chrome/browser/about_flags.cc
[modify] https://crrev.com/cb0f371788eb16f7ad8a6c8d75a3d669938464a2/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/cb0f371788eb16f7ad8a6c8d75a3d669938464a2/chrome/browser/flag_descriptions.h
[modify] https://crrev.com/cb0f371788eb16f7ad8a6c8d75a3d669938464a2/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/cb0f371788eb16f7ad8a6c8d75a3d669938464a2/ui/display/display.cc

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

commit dbd2cb5bd65838fea5b1075755d94f876439b702
Author: Christopher Cameron <ccameron@chromium.org>
Date: Thu Sep 21 02:42:01 2017

Remove color correct rendering from about:flags

From Chrome 62 and on users who want to avoid color correct rendering
should use the "force color profile" option in about:flags.

Bug:  755747 
Change-Id: Ic4e600d2f2277b7cd0b36260b69e7296a7ff4fad
Reviewed-on: https://chromium-review.googlesource.com/673371
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503337}
[modify] https://crrev.com/dbd2cb5bd65838fea5b1075755d94f876439b702/chrome/browser/about_flags.cc
[modify] https://crrev.com/dbd2cb5bd65838fea5b1075755d94f876439b702/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/dbd2cb5bd65838fea5b1075755d94f876439b702/chrome/browser/flag_descriptions.h

Tested the issue on ubuntu 14.04 using chrome M63 #63.0.3222.0 and followed steps mentioned in comment #0 and enabled the flag "force color profile" from chrome://flags as per comment #46 and observed that blue color is displayed.

Attached screencast for reference.

@ccameron-- Could you please check attached screencast and confirm us if this is fine/expected and let us know if anything else to be verified. 

Thanks!

Deleted: 755747.ogv 2.4 MB

	755747.ogv 2.4 MB View Download

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

commit a9f586c32a973a3a25bf60a1b8cd355dd6ad4ec2
Author: Christopher Cameron <ccameron@chromium.org>
Date: Fri Sep 22 18:29:39 2017

Remove color correct rendering from about:flags

From Chrome 62 and on users who want to avoid color correct rendering
should use the "force color profile" option in about:flags.

TBR=ccameron@chromium.org

(cherry picked from commit dbd2cb5bd65838fea5b1075755d94f876439b702)

Bug:  755747 
Change-Id: Ic4e600d2f2277b7cd0b36260b69e7296a7ff4fad
Reviewed-on: https://chromium-review.googlesource.com/673371
Reviewed-by: Fredrik Hubinette <hubbe@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#503337}
Reviewed-on: https://chromium-review.googlesource.com/678125
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#401}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/a9f586c32a973a3a25bf60a1b8cd355dd6ad4ec2/chrome/browser/about_flags.cc
[modify] https://crrev.com/a9f586c32a973a3a25bf60a1b8cd355dd6ad4ec2/chrome/browser/flag_descriptions.cc
[modify] https://crrev.com/a9f586c32a973a3a25bf60a1b8cd355dd6ad4ec2/chrome/browser/flag_descriptions.h

Closing this as fixed.

If colors look wrong on Chrome, you should
- install a color profile that you prefer
- set "force color profile" to "sRGB" in about:flags
  - this option will stay forever
  - the "disable color correct rendering" flag is gone in M62
- if you believe that your color profile is not interpreted by Chrome correctly
  - file a bug attaching an image and the ICC profile

 Issue 768352  has been merged into this issue.

 Issue 767935  has been merged into this issue.

Can we remove the Restrict-View-Google label here? I've duped lots of community bugs in here.

Re comment 52 - totally agree that it should be public.  Not sure who has access to change it; it doesn't seem to let me do that.

 Issue 771181  has been merged into this issue.

 Issue 765628  has been merged into this issue.

I've been pointing many of the sub-bugs at the following document which describes how to reset your system color profile on Windows and Linux:
https://docs.google.com/document/d/1jMokB_OBkZVELu22li8vnHxAUoL1eGnLedP-1Gttv40/edit?usp=sharing

Hello

Using Google Chrome 63.0.3239.84 I found the option chrome://flags/#force-color-profile
Nice to see that color management is being worked on.

1. How do I add a custom ICC to the list of forced color profiles?
2. How do I find out which color profile "as specified by the operating system" was detected? How do I see its filename?
3. Which rendering intent is used?
4. Is black point compensation enabled?

inb4, there is a common misconception that there is only one correct profile for a monitor, or that the monitor profile "installed system-wide" (a very vague term, especially on a cross-platform program) is the one which should be used. This page explains the situation very well:
https://ninedegreesbelow.com/photography/monitor-profile-calibrate-confuse.html#choice

1. That list is hard-coded and will not include custom profiles
2. See the document in #58 for where there "as specified by the operating system" comes from. All platforms except Linux support per-monitor profiles at the moment.
2a. You can see the parametric approximation we are using in about:gpu (see "Color space information").
3. Perceptual
4. I'm going to have to plead ignorance on that one.

Thank you for the reply ccameron.

1. Why does Chromium not let the user specify a custom profile?

2. The document is for Windows. What about Linux, where does it come from - the X11 _ICC_PROFILE atom, a color management service (which means the user would have to have one installed, which is not a good design choice considering how poor all Linux CMS track record has been), or other?

Re #61:

2. There is a "For Linux Users" section of https://docs.google.com/document/d/1jMokB_OBkZVELu22li8vnHxAUoL1eGnLedP-1Gttv40/edit?usp=sharing -- we get the color profile on Linux from the _ICC_PROFILE atom.
2a. FYI, Linux still doesn't support multiple distinct monitor color profiles yet.

1. File a bug with what you'd like such a feature to look like.

The response to comment #62 seems to be https://bugs.chromium.org/p/chromium/issues/detail?id=800019

 Issue 804287  has been merged into this issue.