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 275 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

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

Issue description

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
Showing comments 75 - 174 of 174 Older

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 (was: Available)
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
Blockedon: 667411
Blockedon: -648707
Blockedon: -655247
Blockedon: -667411
Mergedinto: 667431
Status: Duplicate (was: Assigned)
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.

Comment 169 by tyl...@gmail.com, Sep 17 2017

Solution from #167 worked for me. I didn't have any new color profiles so not sure how to remove the "undesired" one. 
>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.

May I ask for clarification on this statement? I'm using a wide-gamut monitor that is calibrated with an external device, the resulting profile installed as the system display profile on OSX 10.12.6.  Previously, Chrome didn't handle this profile well and everything was over-saturated so I've been keeping an eye on this ticket. Since 61, things have gone the other way and everything is slightly dull. 

If I open the same sRGB JPEG in Chrome, Firefox, Safari, and Preview.app, it looks the same in everything except for Chrome, where it is slightly desaturated. CSS colors are similarly desaturated. Not sure if I am running into another issue that is only apparent now that Chrome has improved its color management.  Thanks!
Re #170, if an sRGB JPEG is looking between Chrome 61, Firefox, Safari, and Preview.app, then there is a bug -- it should look identical.

Could you file a new bug and include
- a screenshot of an sRGB JPEG comparing Chrome, Safari, and Preview.app?
- your monitor's ICC profile (should be in Library > Colorsync > Profiles)
Please find files attached. I’m using a calibrated Eizo monitor with a slightly modified sRGB ICC profile. Color seems OK now. No need to file a new bug because this one can be closed, I presume. Thank you for remedying. - Jos Gysenbergs
Preview Version 10.0 (944.1).png
78.3 KB View Download
Chrome Version 61.0.3163.100 (Official Build) (64-bit).png
209 KB View Download
Safari Version 11.0 (13604.1.38.1.6).png
254 KB View Download
The Preview image has a higher saturation and contrast but that's a 'feature' or should I say 'bug' in Preview. It's obvious when you compare the DNG or RAW with the Preview jpg.
Showing comments 75 - 174 of 174 Older

Sign in to add a comment