That is, this was split off from issue 143 (see above with typo).

(No comment was entered for this change.)

(No comment was entered for this change.)

Colour management is important but don't try and re-invent the wheel here. It's a 
simple process - check image for embedded profile, convert to monitor profile (read 
from the system). I don't think it's a problem that support is only available via the 
OS so Vista could use WCS whereas on XP it wouldn't be available. CM in plugins such 
as flash shouldn't be handled by the browser, it's up to the plugin to provide the 
support or you risk double modifications. At best plugins should be able to request 
CM from the browser and in doing so specify the working space (sRGB, AdobeRGB, etc.) 
being used.

In terms of user experience a couple of options would prevent the appearance that 
things are broken.

1) Make colour management an option (off by default).
2) Provide an option for what "profile" to assume for all images missing a profile, 
not this should include ALL graphics rendered, not just photos (solves the wide gamut 
issue for all content).

I really think this issue is more important than some users here appreciate and will be 
more and more serious as time goes on. The latest version of Firefox supports proper 
color management (on XP as well, not just Vista) and it works fine.

Not having color management in Chrome makes it unusable for a lot of people (those with high-gamut monitors, and those who do any design-related work or care about such 
things).

Bill, I have a profiled monitor and the profile affects all applications. In what cases 
do people have monitor profiles that aren't applied by Windows to all applications?

Brett: Are you on Vista, as perhaps the situation is different there.

I'm running XP Pro, and using Spyder3 to do proper ICM color calibration. As
mentioned, Firefox (and Photoshop, etc) handles this correctly, but Chrome does not.
In XP, the ICM profile is only used by applications that support it, not by all
Windows applications.

Yes, Vista has it built in.

Brett I think you're misunderstanding how Vista handles profiles. If you have a h/w 
calibrator then it's s/w will adjust the gamma LUT to correct the display but the 
profile also contains some changes that will be done in s/w - but only if the s/w is 
properly colour managed.

Secondly the s/w needs to read the profile from the images it is displaying and 
translate them to the display profile.

Vista doesn't actually do any colour management, it's not done by the OS as it's done 
to applications. So the Windows Gallery app is colour managed, IE7/8 are not. Safari 
and FF3 (if you set the option) are colour managed.

Have a look at this page:

http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html#

and the "Three Tagged Files" section at the top. If you see a colour shift when you 
mouse over or click the image your browser isn't colour managed. In FF3 or Safari 
there is no shift as the apps are managed - note this is true regardless of if you 
have calibrated your display using something like the spyder.

Browser colour management should simply be the reading the profile from the image and 
converting it to the display profile indicated by the system. Chrome doesn't do that 
no matter that flavour of windows you are running.

That makes sense. I see the gamma and white point change, but not the rest. Thanks for 
clarifying!

Handling tagged images is issue 143, which we're tracking separately.

The handling of untagged contents (e.g. images without color profile, HTML rendering) 
should be an user option:
1. Straight output to monitor, i.e. no conversion
2. Assume sRGB and convert to the monitor space
3. Assume other user-specified color space and convert to monitor space

It's debatable, though, whether the default should be (1) or (2). (1) is probably a 
better default for now but (2) is more future proof, as monitor gamuts are starting 
to grow beyond sRGB.

Color management for web is going to be problematic until there is a standard for web 
developers to specify the color space of all contents (not just images), e.g. using 
<meta> tag.

Since 99.999% of content on the web is currently in sRGB (whether tagged or not), I
don't think there's too much debate about what should be done. (2) is your answer.
(And of course if the image is tagged, use that for the conversion instead of
assuming sRGB..)

"Color management for web is going to be problematic until ..." all major browsers
implement a workable solution. The fact that both Firefox and Safari have already
done it should give you a clue as to where you need to go. Otherwise, Chrome is just
contributing to the "problematic" state of things.

Bill is right. Content produced by most devices is sRGB and assuming that (when no additional information exists) will make 
us show wrong colors (within the display's capability) the least amount of times.

At the same time, color-space conversions on most (99.999% ;) displays create visible artifacts which can be more 
disturbing than the wrong colors (banding, posterization, etc).

The final issue is that "convert to monitor color-space" is not unambiguous because there are different ways of doing the 
conversion which have different properties for the resulting image. For example, we can convert with greater color accuracy 
for in-gamut colors or better preserve relative color differences.

Without a common spec (e.g. HTML 5), it's difficult to expect browsers to move 
towards a common implementation. Safari and FF3.5 by default don't color manage 
untagged graphics (i.e. option 1). Chrome will then be at odds if it goes with (2).

The problem with 1 is that users of wide gamut monitors will see odd looking over-
saturated colors.

With 2, web colors will be reproduced in a somewhat more consistent manner across all 
output devices, with the problem of potential conversion artifacts.

So which one is the lesser evil?

In FF 3.5 advanced users can change fx.color_management.mode to switch between the 
two. Regardless of which way Chrome goes, I strongly recommend providing such option 
to advanced users.

I did a proof of concept using my 20% time, I'll add this under a command line switch.

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=18675 

------------------------------------------------------------------------
r18675 | brettw@chromium.org | 2009-06-17 17:38:06 -0700 (Wed, 17 Jun 2009) | 5 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/backing_store.h?r1=18675&r2=18674
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/backing_store_win.cc?r1=18675&r2=18674
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_win.cc?r1=18675&r2=18674
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=18675&r2=18674
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=18675&r2=18674

Enable off-by-default monitor color management on Windows. This is enabled via
a command-line switch.

BUG=4938
Review URL: http://codereview.chromium.org/131002
------------------------------------------------------------------------

Fixed in r18675. To enable, pass the command line flag --enable-monitor-profile (you can specify this in the 
shortcut you use to launch the browser).

I have not done performance tests. It appears to have some effect, at least when a profile is installed. As a 
result, I don't foresee turning this on by default. The performance impact will be difficult to measure since 
it doesn't block page layout, it may not be very visible in layout tests, but it can block the UI of the 
browser.

It would be great if somebody with an AdobeRGB monitor could try this out and let me know if it works. You'll 
have to be on the dev channel and wait for the next dev build in a week or two to get the feature.

The conversion uses Windows "images" intent since I presume if you profiled your 
monitor you're primarily looking at photos. This intent tries to maintain contrast.

 Issue 6808  has been merged into this issue.

>Not having color management in Chrome makes it unusable for a lot of people (those
with high-gamut monitors, and those who do any design-related work or care about such 
things).

On that note, several people have reported that Chrome unloads their monitor's color
profile (Issue 1673).

It's great that Chrome now uses the display profile for rendering. But what about 
reading the embedded profile and converting the image from imaage's color space to 
monitor's? Is there a switch for this yet?

	Chrome_embedded_profile.jpg
	108 KB Download

(No comment was entered for this change.)

(No comment was entered for this change.)

I have a high gamut monitor, properly set up with a display profile. Neither Chrome
2.x (stable) and 3.x (beta) seem to do anything when the --enable-monitor-profile
switch is passed on.

	chrome3-ff35-cms.jpg
	982 KB Download

This went into version 18675. If you check about:version, the number after "Official 
Build" needs to be higher than this for you to have this feature. I don't actually know 
if this is Chrome 3. It's definitely not in Chrome 2. Can you check this version for 
me?

My Chrome version is much later than that:
Google Chrome	3.0.195.10 (Official Build 24604)

In that case the feature implemented is not working.
Is there anything else to configure / turn on?

I just set my default display profile to wide gamut and Chrome (after restarting) now 
looks very desaturated, which is what I would expect (my "real" profile is pretty weak 
so it's hard to tell it was applied).

If you change your default profile to different things and restart Chrome, does it 
change anything at all?

Unfortunately, nothing happens. I tried to set several profiles to my monitor, even
reloaded the profile with a LUT utility, but Chrome is still showing a default,
highly saturated (non color-managed) rendering.

Is there any way to check if Chrome is honoring that command line option (if it's
indeed in effect or not) ?