New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 37028 link

Starred by 170 users

Issue metadata

Status: Duplicate
Merged: issue 44872
Owner: ----
Closed: Oct 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Attach sRGB to untagged images instead of monitor profile (wide gamut monitor problems with Mac OSX)

Reported by anand.sa...@gmail.com, Feb 28 2010

Issue description

Chrome Version       : 5.0.307.11 beta
URLs (if applicable) : http://www.gballard.net/photoshop/srgb_wide_gamut.html
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: FAIL
  Firefox 3.x: OK
         IE 7: Unknown
         IE 8: OK

What steps will reproduce the problem?
1. Connect a mac to a wide gamut monitor such as the Dell 2408 WFP (also
known as AdobeRGB monitors).
2. Visit the gballard.net page using Chrome and mouse over the image on
top, notice the colors change.
3. Visit the gballard.net page using Firefox 3.5 with color management
enabled.  See the colors DO NOT change.
4. Check that IE8 on Windows 7, colors do not change.
5. Visit any site such as www.ebay.com on the mac hooked to a wide gamut
monitor that has untagged images (ebay logo is untagged).  See the red "e"
is over saturated.  Compare it to the color red in Firefox.  Firefox is
closer to the correct color.  Compare the result of Chrome on Windows to
Chrome on Mac (with the wide gamut monitor).  Chrome on Windows looks
correct.  Chrome on Mac doesn't.

The root cause of this problem, as explained by the gballard.net page is this:

When Chrome on Mac OSX encounters an untagged image, it assigns the monitor
profile to it.  While this works for normal monitors which are close to the
sRGB color profile, it is broken with wide gamut monitors.  Due to the
color space problems, all colors (particularly reds) are oversaturated on
the Mac version of Chrome.

The problem with this is since 99% of the images on the internet are
untagged, Chrome is useless when used on the Mac platform with a wide gamut
monitor.  The colors are not just accurate, but they hurt your eyes.

Firefox 3.x handles this accurately.  It applies sRGB color profile to
untagged images, which is the correct intent.  Right now Chrome on mac
assumes that all monitors are sRGB monitors and this assumption fails for
wide gamut monitors (monitors that are closer to aRGB color space).

Please fix this.

What is the expected result?


What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.

 
Sorry, forgot to add the other 3 questions:

- What is the expected result?

In the gballard test at http://www.gballard.net/photoshop/srgb_wide_gamut.html, the
colors should NOT change when you mouse over.

- What happens instead?

The colors shift on wide gamut monitor when used with Mac OSX.  This is wrong.

- Please provide any additional information below. Attach a screenshot if
possible.

See attached image for the eBay color change.  Note that the developer can't see the
color shift unless they are using Mac and hooked to a wide gamut monitor.



Screen shot 2010-02-28 at 12.15.02 PM.png
73.6 KB View Download

Comment 2 by thakis@chromium.org, Feb 28 2010

Labels: -Area-Undefined Area-UI OS-All
Status: Untriaged
Is this a cross-platform thing, or is this specific to CG on OS X?

(who's our CG expert these days?)
Hi

Not sure if this question was intended to me.  No, this doesn't happen in Windows. 
Windows Vista and Windows 7, at the OS level assign sRGB profile to untagged images
found on the internet.  I am not sure if it is the OS that handles it right or Chrome
on windows that handles it correctly, this is not a problem in Windows.  Not sure
about linux.

I have attached another file to further illustrate this.

See the same same image saved in sRGB profile, but untagged (the profile is not saved
with the image).  Open side by side in Chrome, Firefox and Adode Photoshop CS3.

See how cartnooish the reds show up in Chrome.  Pretty much every red goes that way
for untagged images.
Screen shot 2010-02-28 at 6.18.51 PM.png
896 KB View Download

Comment 4 by liebl...@gmail.com, Mar 16 2010

I am also experiencing this issue. Right now I have to use Firefox 3.6 when I'm doing 
color critical work while working on web design.


Labels: Area-Internals
Labels: -Area-UI
Labels: Mstone-X HelpWanted
Status: Available

Comment 8 by goo...@vanbragt.com, May 10 2010

This seems to be closely related to  issue 143 .

Comment 9 by liebl...@gmail.com, May 17 2010

For people with wide gamut displays this problem occurs not only with untagged sRGB images but with colors set 
in HTML and CSS. Simply applying color management to Photographs will not solve the overall problem.

Firefox handles this issue very well when the Color Management add-on is installed: 
https://addons.mozilla.org/en-US/firefox/addon/6891/

This add-on allows a user to define the path to their monitor's color profile.

Comment 10 by Deleted ...@, May 20 2010

I've been seeing this too. One thing I've noticed. If I hook my Mac up to my Dell monitor when chrome is running, 
Chrome's colors are over saturated like described. If I then quit Chrome and start it back up, the colors display 
correctly. This doesn't work every time, but more often than not

Not a fix, but maybe helpful?
@Lemagicbullet - not really.  It doesn't do anything for me.

In any case, this was eating my head so much, I sold the monitor and bought a 27" iMac with sRGB color 
response.  Quite a shame that I had to do it for this sake.  At least now I can use chrome instead of firefox.
I'd like to see color management in Linux versions too. As others have noted, this is
becoming more important as wide-gamut monitors become popular. Firefox on Linux has
color management, as do many of the popular image editing and display programs. While
Firefox requires you to specify the monitor profile filename, there is a standard way
to set and retrieve monitor profiles in X without the user having to specify a
profile in applications:
http://www.burtonini.com/computing/x-icc-profiles-spec-0.2.html
I think Wine uses this method (Photoshop under Wine uses my installed monitor profile
without further ado), as can gimp ("use system profile" checkbox in prefs) and
probably others.

I am still surprised to see this issue.  I just retested with Version 8.  Untagged images are still not being handled right.  As a photographer I still can't use Chrome for my daily work - and I would LOVE to. Why can't Chrome get this right?  btw, I am using Chrome on OSX with color mgt enabled.  It doesn't seem to be a monitor profile issue.  It looks to me like untagged images are just not being handled right - I noticed this when many of the social net images I shared on FB and Flickr just didn't display right on Chrome but looked perfect on Safari, Firefox, and IE.  I don't get why Chrome can't get this right.  It has been a know problem for SOOOO long.  Geeze.

Comment 14 by mal@google.com, Feb 14 2011

Labels: -HelpWanted GoodFirstBug
Labels: -GoodFirstBug bulkmove Hotlist-GoodFirstBug
Chrome Version       : 5.0.307.11 beta
URLs (if applicable) : http://www.gballard.net/photoshop/srgb_wide_gamut.html
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: FAIL
  Firefox 3.x: OK
         IE 7: Unknown
         IE 8: OK

What steps will reproduce the problem?
1. Connect a mac to a wide gamut monitor such as the Dell 2408 WFP (also
known as AdobeRGB monitors).
2. Visit the gballard.net page using Chrome and mouse over the image on
top, notice the colors change.
3. Visit the gballard.net page using Firefox 3.5 with color management
enabled.  See the colors DO NOT change.
4. Check that IE8 on Windows 7, colors do not change.
5. Visit any site such as www.ebay.com on the mac hooked to a wide gamut
monitor that has untagged images (ebay logo is untagged).  See the red "e"
is over saturated.  Compare it to the color red in Firefox.  Firefox is
closer to the correct color.  Compare the result of Chrome on Windows to
Chrome on Mac (with the wide gamut monitor).  Chrome on Windows looks
correct.  Chrome on Mac doesn't.

The root cause of this problem, as explained by the gballard.net page is this:

When Chrome on Mac OSX encounters an untagged image, it assigns the monitor
profile to it.  While this works for normal monitors which are close to the
sRGB color profile, it is broken with wide gamut monitors.  Due to the
color space problems, all colors (particularly reds) are oversaturated on
the Mac version of Chrome.

The problem with this is since 99% of the images on the internet are
untagged, Chrome is useless when used on the Mac platform with a wide gamut
monitor.  The colors are not just accurate, but they hurt your eyes.

Firefox 3.x handles this accurately.  It applies sRGB color profile to
untagged images, which is the correct intent.  Right now Chrome on mac
assumes that all monitors are sRGB monitors and this assumption fails for
wide gamut monitors (monitors that are closer to aRGB color space).

Please fix this.

What is the expected result?


What happens instead?


Please provide any additional information below. Attach a screenshot if
possible.
Just to add to this.. I have had customer queries because they have moved to Chrome and are noticing the difference (worried that their images have been changed).  Usually it's because they are viewing them on sites that strip the tag.. Please assign the SRGB tag to untagged images so that Chrome reacts like the other browsers.
Cc: caryclark@chromium.org
Yes, this needs to happen. Even if it's added to about:flags as a super hidden option. I cannot use Chrome anymore as it incorrectly handles color tags and will have to fall back on Firefox which correctly handles this problem.  
I just got a wide gamut monitor and everything looks horrible in Chrome 12.0.742.122. If I switch my monitor to sRGB mode then things look as expected. I have been using Chrome since 0.x and so now it seems I must switch to Firefox. It is ridiculous to have to switch my monitor to sRGB just to browse. Especially my photo website.

Comment 20 by Deleted ...@, Aug 1 2011

I just switched to Chrome from Safari because of memory fragmentation issues in Safari that Chrome doesn't show.  But I immediately noticed the change in colors (and, in fact, have a Dell 2408 WFP, color calibrated with an Eye-One).  It is obvious it is Chrome.  Safari colors on uploaded images to SmugMug (which doesn't process image colors) match Adobe Lightroom (the reference) very well, but Chrome pushes every image to the red.  It is very problematic.  I have no control over tagging images since they are uploaded to web sites by many different means.  The browser needs fixing.

Comment 21 by rom1...@gmail.com, Aug 1 2011

Just for information, firefox handles icc v4 since yesterday's nightly build...
rom1dep, can you provide some more information about that? I tried Firefox Nightly today (Aug-1-2011) and this website: http://www.color.org/version4html.xalter and it did not pass the ICC V 4 test shown there. (It did show proper V 2 support.)

Comment 23 by rom1...@gmail.com, Aug 1 2011

Yeah, sorry, I forgot to talk about... This is a feature you need to manually enable for now : type about:config into your url bar and navigate to the gfx.color_management.enablev4 ; you just have to make it tell you true :)

Comment 24 Deleted

Comment 25 by scoo...@gmail.com, Aug 15 2011

If someone points me to where in the code the image handling happens, I'd be happy to take a look at it. This is an important issue to me, so I'd like to get it resolved.
- update qcms
The qcms code is checked into the Chromium tree from the Firefox tree, but it is not the latest. It supports V2, but not V4 (Firefox Nightly supports V4). See src/third_party/qcms

- enable profiles
platform/image-decoders/jpeg/JPEGImageDecoder.cpp disables color profile for JCS_YCbCr. See around lines 209 - 219

- call qcms
That code might look like the following:
In platform/image-decoders/skia/ImageDecoderSkia.cpp
  ColorSpaceQCMS cs(m_colorProfile.data(), m_colorProfile.size());
  cs.convertToSRGB(m_bitmap);

Where ColorSpaceQMS is declared as:

class ColorSpaceQCMS {
public:
    ColorSpaceQCMS(const char* data, size_t size);
    virtual ~ColorSpaceQCMS();
    void convertToSRGB(const SkBitmap&);
private:
    char* m_data;
    size_t m_size;
    _qcms_profile* m_profile;
};

And ColorSpaceQCMS is defined as:


#include "config.h"
#include "ColorSpaceSkia.h"

#include "SkBitmap.h"
#include "third_party/qcms/qcms.h"

ColorSpaceQCMS::ColorSpaceQCMS(const char* data, size_t size) 
    : m_size(size)
    , m_profile(NULL)
{
    m_data = (char*)sk_malloc_throw(size);
    memcpy(m_data, data, size);
    qcms_profile* profile = qcms_profile_from_memory(data, size);
    if (NULL == profile)
        return;
    if (qcms_profile_is_bogus(profile)) {
        qcms_profile_release(profile);
        return;
    }
    m_profile = profile;
}

ColorSpaceQCMS::~ColorSpaceQCMS()
{
    sk_free(m_data);
    if (NULL == m_profile)
        return;
    qcms_profile_release(m_profile);
}

static void flip(char* pixels, int width)
{
    for (int index = 0; index < width; index++) {
        char c1 = pixels[2];
        char c2 = pixels[1];
        char c3 = pixels[0];
        char c4 = pixels[3];
        *pixels++ = c1;
        *pixels++ = c2;
        *pixels++ = c3;
        *pixels++ = c4;
    }
}

void ColorSpaceQCMS::convertToSRGB(const SkBitmap& bitmap)
{
    if (NULL == m_profile)
        return;
    if (bitmap.config() != SkBitmap::kARGB_8888_Config)
        return; 
    qcms_profile* sRGB = qcms_profile_sRGB();
    qcms_profile_precache_output_transform(sRGB);
    qcms_transform* hTransform = qcms_transform_create(m_profile,
        QCMS_DATA_RGBA_8, sRGB, QCMS_DATA_RGBA_8, QCMS_INTENT_DEFAULT);
    bitmap.lockPixels();
    char* pixels = (char*)bitmap.getPixels();
    int rowBytes = bitmap.rowBytes();
    int height = bitmap.height();
    int width = bitmap.width();
    for (int index = 0; index < height; ++index) {
        // TODO: qmcs supports RGBA.
        // Once qcms supports BGRA, this rearrangement can be removed.
        flip(pixels, width);
        qcms_transform_data(hTransform, pixels, pixels, width);
        flip(pixels, width);
        pixels += rowBytes;
    }
    bitmap.unlockPixels();
    qcms_transform_release(hTransform);
    qcms_profile_release(sRGB);
}

While this provides a start, there's plenty to do to make this real code.

Comment 27 Deleted

Please stop me-too-ing this bug; that's what the star is for.

Comment 29 Deleted

Comment 30 Deleted

Comment 31 Deleted

Comment 32 Deleted

Comment 33 Deleted

Comment 34 Deleted

This proposed webkit change fixes this bug on the Skia-on-Mac platform in my testing:
https://bugs.webkit.org/show_bug.cgi?id=69622
Status: Fixed
I'm still seeing this problem in the latest Chrome Canary build - 17.0.926.0. Is this fix already committed to this version?

Here is the behavior I'm seeing:

Mac: ICC v2 and V4 support ok, but all untagged images and page elements are still rendered on the full display gamut, leading to oversaturated color for wide gamut display users. The --enable-monitor-profile doesn't work.

Windows: ICC v2 and V4 are not supported. Untagged elements are also rendered on the full display gamut. The --enable-monitor-profile works.

Test URL:
http://gearoracle.com/tools/web-browser-color-management-test/

How to reproduce the bug: Access the URL above with a wide gamut display that has near AdobeRGB coverage.

Firefox is the only browser that passes this test. Firefox 8 adds support for ICC v4 profiles and keeps the configuration option to treat untagged images and elements as sRGB.
Status: Available
Cc: -stuartmorgan@chromium.org
Please remember to also render CSS RGB colors in sRGB as well. Otherwise, there would be no way to guarantee color matching between colors in images and colors specified by CSS.

Reference:
http://www.w3.org/TR/2010/PR-css3-color-20101028/
There's actually a separate issue that goes with my comment above:
http://code.google.com/p/chromium/issues/detail?id=44872

Both issues must get fixed in the same release so we're not left in a state where colors in untagged images no longer match colors in CSS (which is currently the only reliable way to ensure colors in images match colors in CSS at all).
Cc: tpayne@chromium.org
Labels: Feature-Color-Management
The seems to be no progress with the color management issue.
Chrome Beta 21.0.1180.83 still doesn't display the images correctly.
See the example there:
http://gearoracle.com/tools/web-browser-color-management-test/
Okay, chrome22 just hit the beta channel.  UNTAGGED images are still not assumed to be sRGB (which they probably should.)

If an image is tagged, then the color management does appear to work now (ICC2 profiles only).

Comment 46 by glenjeh@gmail.com, Sep 1 2012

On sites like cnn.com, the page's colors are correct (assume sRGB) initially and then change to incorrect (assume monitor profile) as the page finishes loading.

I'm guessing Chrome is now assuming sRGB for HTML but not CSS. (!)

Switching to Firefox, which handles all color issues correctly.

Project Member

Comment 47 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals Cr-Internals

Comment 48 by Deleted ...@, Apr 15 2013

Left: Preview on Mac
Center: Safari
Right: Google Chrome

Color on Google Chrome still over saturated and incorrect.
This is Version 27.0.1453.47 beta with a Dell U3011 Display (wide gamut).
Screen Shot 2013-04-14 at 3.29.26 PM.jpg
988 KB View Download
Embedded profiles seems to work in stable now. 
However Chrome does not seem to respect the Exif.Photo.ColorSpace attribute when set to 1. (sRGB). 
Hence embedding a full profile seems necessary. Facebook has done a minimal profile for sRGB but even then it feels bad to add those extra bytes. 

http://www.facebook.com/note.php?note_id=10150630639853920

Comment 50 by ma...@mavos.net, Apr 30 2013

Sorry about hijacking this issue for a question, but it's a related issue and I really don't know how else to find the answer. Feel free to berate me for inappropriate use of this bug report.

Does Chromium/Chrome color manage CSS colors as well? Image rendering respecting embedded profile and monitor profile is one thing, but any solid/gradient/semi-transparent color applied via a CSS value such as rgb(r, g, b) or #rrggbb should ideally also be transformed from sRGB to the monitor profile before displayed on screen. (I seem to remember the CSS specification defining rgb colors as being in the sRGB color space.)

Is this being done at this time, a feature being worked on, or not yet considered? Firefox handles this neatly but at least on my screens web pages viewed through Chrome has over-saturated solid colors, compared to Firefox.
Please see https://code.google.com/p/chromium/issues/detail?id=44872. Also, all color management related feature requests can be found here: https://code.google.com/p/chromium/issues/list?q=label:Feature-Color-Management

Comment 52 by pdk...@gmail.com, Feb 26 2014

Just for reference, this is defined pretty well in section "Standard Color Space in Practice" of the following link.

http://www.w3.org/Graphics/Color/sRGB.html

Comment 53 Deleted

If you treat untagged images as sRGB without treating CSS colors as sRGB at the same time, many web sites will look broken, as their images are designed to be interpreted in the same color space as their CSS. It's probably better to leave both CSS and untagged images in monitor color space until both issues can be fixed.


Comment 55 by pdk...@gmail.com, Mar 14 2014

PS. This does not fix the problem for BMP and GIF, which have no color profile code to attach to. If they do, as filed in issue 284015, the patch is just as trivial.

Comment 56 by pdk...@gmail.com, Mar 14 2014

They will look inconsistent, but less broken technically.

PS. When this is fixed, Chrome ignoring the sRGB chunk in PNGs should be fixed en passant.

Comment 57 by lemon...@gmail.com, Mar 14 2014

Chrome needs something like gfx.color_management.mode in Firefox so that users can choose! This is really necessary for those who have wide-gamut monitors.

Comment 58 by pdk...@gmail.com, Mar 15 2014

Chrome doesn't do switches for for options, only preliminary features.

Comment 59 by noel@chromium.org, Mar 16 2014

#56 pdknsk
> They will look inconsistent, but less broken technically.

Either way, web sites will look broken _to users_.

#54 tpayne
> If you treat untagged images as sRGB without treating CSS colors as sRGB at the same time, many web sites will look broken, as their images are designed to be interpreted in the same color space as their CSS.

Yes. Games sites break, web sites break or slow down, site color matching is man-overboard.
https://www.webkit.org/blog/73/color-spaces

#59 Noel:
Websites viewed in Chrome are broken for me -- I have a wide gamut monitor.  At least with Firefox I have the option to fix that.  Incidentally, what's being suggested here is that Chrome follow the W3C recommendation (see #52).
Screen Shot 2014-03-15 at 10.32.01 pm.png
2.7 MB View Download

Comment 61 by Deleted ...@, Mar 16 2014

@mcampos...: I guess you forgot to embed your wide gamut monitor colour profile in the screenshot to allow the readers see what you might have seen.
#61:
Thanks for pointing this out.  Looks like the Chrome defect tracking system strips out ICC profiles in uploaded attachments (how ironic).  Here's the original image:

http://stuff.bpsw.biz/misc/20140316-chrome_profile/red_canyon.png

Comment 63 Deleted

Comment 64 Deleted

Comment 65 by noel@chromium.org, Mar 17 2014

#60 mcampos393
> Websites viewed in Chrome are broken for me -- I have a wide gamut monitor.

Some unknown web site is broken, in an unknown chrome, on some unknown os.

> At least with Firefox I have the option to fix that.  

If firefox has some option that fixes the problem for you, then use that.

#65 noel:

> Some unknown web site is broken, in an unknown chrome, on some unknown os.

The functionality will be broken on any computer that has a non-sRGB monitor profile. E.g., on my MacBook Air, images on Google Plus look washed out because they don't embed their ICC profile. The effect will be much more pronounced and annoying on a wide-gamut monitor (or any display that is far from sRGB), and is in any case pretty much a deal breaker if you're into photography.

From what I understand from all these comments, there are no versions of Chromium that assign sRGB to untagged images/CSS elements. This means that this issue will affect every version of Chromium on every OS.

> If firefox has some option that fixes the problem for you, then use that.

I guess the hope was that Chromium developers wanted Chromium to be at least as good as its competitors. I think people have been quite constructive, even suggesting specific ways of fixing this. If you think it's a complicated fix and you don't have the time to do it, then say that. Telling us to just use another browser is pointless.

Comment 67 by ka...@goodtimes.fi, Mar 17 2014

#65 noel:
> Some unknown web site is broken, in an unknown chrome, on some unknown os.

This affects virtually every website for every user with a professional-level monitor. Corporate logos and website graphics have screaming colors, skin tones appear extremely red, and so on.

Even Safari now performs full color management out of the box; untagged images and CSS values are interpreted as being in sRGB.

Unfortunately it is not possible to produce a screenshot that would accurately illustrate (on a basic monitor) the extent of the oversaturation (as experienced on a wide-gamut monitor) because the distorted colors routinely fall outside of the sRGB gamut.

Personally I don't mind using Firefox as suggested, but it's a poor solution to the overall issue. As computers' color capabilities get better, the web will look increasingly worse when viewed on Chrome.

#65 noel:
Website:  Google image search.  Searching for "red canyon"
Browser: Chrome 33.0.1750.152 and Firefox 27.0.1 (gfx.color_management.mode=1)
OS:  Mac OS X 10.9.2
Labels: -Hotlist-GoodFirstBug
Chrome should be fully color managed and this probably means treating all untagged stuff is treated as sRGB.

When we first looked at this, there was a lot of concern that some people have random color profiles attached to their monitors. Since most stuff isn't color managed, they don't notice. Here's Mozilla's experience at the time:
http://bholley.wordpress.com/2008/09/12/so-many-colors/
There are also performance concerns.

Firefox gets around the "bad profile" and performance problems by having an obscure option that most people never use. We don't add this kind of option by policy. Either something is good enough for everybody, or we don't ship it. There are some flags but these are either things that are intended. Safari gets around the bad profile problem by only running on OSs that are more color managed so people don't have bad profiles.

It's possible with the new accelerated rendering architecture that good color color management could be implemented on the GPU with minimal performance overhead. But that needs to be carefully studied. And there is still the very-difficult-to-measure problem of bad profiles that adds risk.

So while we should do this, it's a bunch of work to validate and test, and adds risk for relatively little benefit. Few people don't have high gamut monitors, and stuff doesn't really look that bad if you do. I have a 99% AdobeRGB profiled monitor (I wrote the now-broken --enable-monitor-profile switch). If there is a photo that somebody cares about, it will have an attached profile and it will look correct. So I wouldn't expect this bug to be fixed soon.

Removing GoodFirstBug tag, this is the worst possible first bug. Needs somebody careful to drive a long-term transition.

Comment 70 by pdk...@gmail.com, Mar 17 2014

> Either way, web sites will look broken _to users_.

Yes, but only because they are broken. If a picture has a wrong profile, erroneously stripped profile, or maybe the monitor profile is incorrect, then setup and/or page are broken, plain and simple. Google has not been shy in the past to enforce specs.

As I tried to explain in a comment on a related bug, performance impact is likely minimal.

https://code.google.com/p/chromium/issues/detail?id=44872#c37
It doesn't matter if the user's setup is at fault. If it looks bad in Chrome and not in Firefox, it's Chrome's problem.

The performance numbers you mention are significant. Most people do not have Haswell processors, and even then, 0.1 seconds is *enormous* compared to the types of performance that we typically worry about.

Comment 72 by pdk...@gmail.com, Mar 17 2014

> If it looks bad in Chrome and not in Firefox, it's Chrome's problem.

It does look bad in both Chrome and Firefox currently. Only less bad in some cases. Is that a good trade-off? I don't know.

What do you say about caching in a LUT? I'm not so good at this, but I guess it's just limited by memory speed. So pretty much instant.

Comment 73 by cbozh...@gmail.com, Mar 17 2014

> Firefox gets around the "bad profile" and performance problems by having an obscure option that most people never use. We don't add this kind of option by policy. Either something is good enough for everybody, or we don't ship it.

Are you sure it's a good policy? I think "focus on the user" doesn't mean just "focus on an average user". As a geek I get increasingly annoyed by lack of control in Google products. This is the reason I don't use Chrome, even though it is faster than Firefox.
#69: brett

Regarding the random color profiles: at least on my MacBook Air (Mac OS X 10.7.5) running Chrome version 33.0.1750.149, the monitor profile *is* used for all the images and CSS elements that have a profile. This means that any online picture that includes a color profile already is transformed to the monitor color space, with all the problems this might bring if people have 'random' color profiles (and all the performance issues). An example of a website that assigns color profiles to all its pictures is Facebook https://www.facebook.com/notes/facebook-engineering/under-the-hood-improving-facebook-photos/10150630639853920, so it's fair to say that at least the 1.2 billion Facebook users don't have issues with random monitor color profiles. Also, I think most photo managers do use the monitor profile (iPhoto does, Shotwell and F-Spot on Linux do, and Picasa does on some platforms [seems to fail on my Mac, though]), so again, any user who has any pictures on his/her computer will probably have noticed any big issues with the monitor profile and taken steps to fix them.

#73: cbozh...

> I think "focus on the user" doesn't mean just "focus on an average user". 

Exactly! Also, I don't think it should be assumed that users, even the average ones, are idiots. You don't have to be a geek to understand tradeoffs, and you don't need to explain color management in detail to the users to make them understand that there's a switch which allows for potentially better colors at the expense of speed. Make it an advanced option, add a pop-up warning that this might lead to problems, and everyone would be happy.

Comment 75 by glenjeh@gmail.com, Mar 17 2014

The argument from Mozilla 2008 (http://bholley.wordpress.com/2008/09/12/so-many-colors/) that some people's display profiles might be buggy is an argument that a small fraction of users who have buggy systems should hold back the entire population of users.

They also discussed the issue of plugins not being color managed, which is an argument that the browser should not follow the spec because others don't and we wouldn't want to be different from them. Normally Google takes the lead in such matters and does the right thing so that others will follow suit, rather than to follow others who are wrong for fear of standing out.

The performance argument is still valid, but I don't see why Chrome can't add it as an option in settings or allow it to be enabled as an extension. I see options under Chrome settings that are even more opaque and useless to the average user than this.

brettw: Tagged photos may look correct but CSS is still an issue. Every page still looks off on an AdobeRGB monitor, like how cnn.com's front page glows radioactive red. Much thanks for --enable-monitor-profile though while it lasted.

Comment 76 Deleted

Looks like getting CSS color rendered in sRGB is now being prioritized.  Can this issue be prioritized as well?

"Safari on OS X 10.9 recently switched to be properly color profile aware and to produce web page content properly into the sRGB color space. The fact that Safari was able to make this change demonstrates that Chrome should be able to as well without impacting web compatibility. Chrome should be color profile and multi-monitor aware on *all* of its supported platforms to the best of the underlying OS's ability."

https://code.google.com/p/chromium/issues/detail?id=368694#c11

Comment 78 Deleted

Comment 79 Deleted

Comment 80 Deleted

Comment 81 Deleted

Comment 82 by a...@chromium.org, Nov 5 2014

Labels: Restrict-AddIssueComment-EditIssue
If you want updates, please star this bug.
Cc: senorblanco@chromium.org reed@chromium.org noel@chromium.org

Comment 84 Deleted

Blocking: chromium:333619

Comment 86 by noel@chromium.org, Jun 23 2015

Blocking: -chromium:333619

Comment 87 by hcm@chromium.org, Jul 16 2015

Issue 238840 has been merged into this issue.
Owner: andyb...@chromium.org
Owner: ----
Mergedinto: 44872
Status: Duplicate (was: Available)

Sign in to add a comment