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

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

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Aug 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Feature

Blocked on:
issue webkit:81974
issue 61627
issue 129452

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Handle color profiles in tagged images

Reported by xxy...@gmail.com, Sep 2 2008 Back to list

Issue description

Product Version      : 0.2.149.27 (1583)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: OK
    Firefox 3: OK
         IE 7: FAIL

What steps will reproduce the problem?
1. open the attached jpg in the browser
2.
3.

What is the expected result?
The right order starting from 12 o'clock position and in clockwise 
direction is red, yellow, green, cyan, blue and purple.

What happens instead?
It shows blue, purple, red, yellow, green, cyan.

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


 
farbkreis.jpg
226 KB View Download
Showing comments 80 - 179 of 179 Older
@79: Chrome 10.0.648.127 on Vista renders the "Farbkreis" from comment 1 correctly (as shown in the screenshot in comment 75), i.e. the embedded profile is indeed used to transform the colors (unmanaged: blue > embedded: red).

The forum software somehow converts to sRGB when you click the "View" link to open the attachment. So, the test might be flawed (it even work on my Chrome 9 on XP). 

You should click "Download", then open the downloaded file in Chrome.

To make sure the test is valid, use Photoshop to open the image and check the embedded profile. It should be "ColorSpin", and not untagged.
profile_check.png
5.7 KB View Download

Comment 81 by 0x4...@gmail.com, Mar 4 2011

@80: Thank you for pointing out the issue with the forum software and "View". My partial jubilation was premature, in deed.

Correction @79: Chrome 10.0.648.127 on Vista does not color manage at all.
@81: Chrome 10.0.648.127 on Vista does not color manage at all.

Even if you use the "--enable-monitor-profile" command line parameter?
@82:  Not sure if the latest beta/devs builds do anything, but all --enable-monitor-profile seems to do is map untagged images to the proper colorspace for a wide gamut monitor.  That's how it's always worked for me.

I believe the problem lies in tagged images, as noted in the sites that have been mentioned (http://www.color.org/version4html.xalter http://regex.info/blog/photo-tech/color-spaces-page1 http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html )

Chrome still falls flat here.  

Comment 84 by 0x4...@gmail.com, Mar 4 2011

@82: Chrome 10.0.648.127 on Vista started with "--enable-monitor-profile" does not appear to have any effect (reds still appear oversatured on a wg-display). Is there a way to verify that the command line flag is active? about:version tells me that the command line was '"[...]Google\Chrome\Application\chrome.exe" --enable-monitor-profile --flag-switches-begin --flag-switches-end' (resorted alphabetically?)

Comment 85 Deleted

Comment 86 by gzjj...@gmail.com, Mar 12 2011

Chrome 11.0.696.3 dev renders none of the tests in http://gearoracle.com/tools/web-browser-color-management-test/ correct. Can anyone confirm that Chrome doesn't have ICC tagged image color correction support for now?
@86 - Yes, Chrome doesn't support ICC v2 och v4 for images or videos. But the built-in PDF-reader do support v2 and v4.
Issue #76524 is related to this issue.

Comment 89 by mkte...@gmail.com, Apr 1 2011

 Issue 77871  has been merged into this issue.
http://code.google.com/p/chromium/issues/detail?id=78277 is related to this issue (i think)

Comment 91 by dhw@chromium.org, Apr 3 2011

 Issue 78291  has been merged into this issue.

Comment 92 by mkte...@gmail.com, Apr 3 2011

 Issue 78277  has been merged into this issue.
do you know how horrible the result of a sRGB Image on a calibrated Wide Gamut Display looks ?? please fix this issue as quick as possible ...
This is an issue which makes it impossible to use your browser for photographers or any branch which has to do with media ... 
i think it is not so important to read color profiles, as it is important to assume sRGB and display it correctly ... 

Comment 94 Deleted

It's quite amazing that in this day and age when so much of what we view is online that basic ICC support isn't available in any browsers but Firefox (which still has to be turned on since it's off by default... unless that's changed) and Safari (which has been doing it for years).

As a photographer it is a quite disappointing to see my images in any browser but FF or Safari.

Another big problem is that most people don't even tag with an ICC profile their images so they still look wrong even in FF (unless configured properly) and Safari.
@93: The "--enable-monitor-profile" parameter should help your case.
@96: thank you, but if tried this on Mac OSX with no effect at all ... maybe i do something wrong ... i type in the terminal "/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Come --enable-monitor-profile
"

Comment 98 by Deleted ...@, Apr 28 2011

@96 Unfortunately it doesn't. I tried with both version 10 and now 11 (in Win 7 with a wide gamut, fully calibrated monitor) and it still doesn't pass the test.
@97, How do you judge whether it works or not?

@98, What test do you expect it to pass? 
The switch only enables monitor profiles adjustment. It still DOES ignore the embedded profiles.
@99 i simply view a picture in a software which supports color management like Photoshop, Preview, Firefox 4, Safari, iPhoto, with sRGB they all provide the same result.
Most test cases read the embedded profile, but since i know chrome dosen't read the profile, its not possible.
But if you compare the picture within an other software. The picture in chrome is oversaturated, has more contrast and depending at your monitor color-space it has a tint.

But i wounder about the --enable-monitor-profile flag what does it exactly do ?
1) just reads the profile, but doesn't use it => useless
2) reads it and assumes that the profile of the picture is the same as the profile of the monitor => so doesn't convert color-spaces, should end in exactly the same result as doing nothing
3) since chrome doesn't read the profile, it assumes that the profile is sRGB and converts the picture into the monitor color-space/profile => this is what should be done with the flag i think. But that isn't the case actually, or i do something wrong with the flag. 
There is a test website:
http://gearoracle.com/tools/web-browser-color-management-test/

Currently FireFox is the only browser to work completely although you have to do some configuring since it's not enabled by default.
There is a test website:
http://gearoracle.com/tools/web-browser-color-management-test/

Currently FireFox is the only browser to work completely although you have to do some configuring since it's not enabled by default.

Comment 103 by Deleted ...@, Apr 29 2011

@99 I use thess tests:

http://www.color.org/version4html.xalter
http://www.gballard.net/psd/go_live_page_profile/embeddedJPEGprofiles.html

I don't understand what you mean with "enables monitor profiles adjustment". If the embedded profile is ignored or there is no conversion to sRGB or everything is assumed to be in sRGB regardless of the embedded profile, then the switch is basically useless.

Comment 104 by mkte...@gmail.com, Apr 29 2011

FYI it looks like there's a regression in the Chrome 12 Dev channel; see  Issue 80844 .
@100, It should do (3). It always did and does it form me (now 11.0.696.57). If it doesn't and you're sure you do everything right, perhaps it might not work on some platforms/configurations.

@103, These test only show you if the user agent respects image-embedded profiles, which Chrome surely does not. Regarding the "useless" switch - I tend do disagree. Yes, it would be nice if Chrome respected embedded profiles, but 99% of images on the web are sRGB or untagged anyway. Where the switch really helps indeed, is when your monitor is either wide gamut or very off-sRGB.

Comment 106 by mavd...@gmail.com, Apr 29 2011

@105: I agree, the "useless switch" is for those particular monitors.

We (gaming news website) have been using color profiles in screenshots and boxshots for a while now, since they sometimes come with a CMYK profile and it's just better to be able to upload them directly and have the script convert them and assign an RGB profile. We've noticed a big improvement in imagequality using imagemagick and color profiles (we only used GD before). Especially with screenshots that have warmer and bright red colors it looks a lot better. But in Chrome all images look bland, washed of those warm colors. I'm at the point of thinking we should be adding a notice on the site if a visitor is using the Chrome browser, telling them it doesn't support color profiles and thus displays the game screenshots with wrong colors.

So I'm still really hoping this embedded color profiles support gets added to Chrome.
@105: thank you, now i tried it with the dev chanel 12.0.742.12 but it dosent work.
still not able to display sRGB
since it works for you, are you able to view an sRGB picture in Firefox 4 and it looks exactly the same ?
has chrome difficulties with 2 monitors ? what i also can tell that chrome dosen't switch profiles when i drag the browser window from one screen to the second screen. in all color managed software there is a particular point where the software switches monitor profiles you can see that ... can any one see that ? 

@107:since it works for you, are you able to view an sRGB picture in Firefox 4 and it looks exactly the same ?

Yes.
Project Member

Comment 109 by bugdroid1@chromium.org, May 2 2011

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

------------------------------------------------------------------------
r83749 | apatrick@chromium.org | Mon May 02 11:53:02 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/shader_translator.cc?r1=83749&r2=83748&pathrev=83749
 M http://src.chromium.org/viewvc/chrome/trunk/src/DEPS?r1=83749&r2=83748&pathrev=83749

Roll ANGLE r609:r626

Revision: 626
Author: apatrick@chromium.org
Date: 5:24:23 PM, Thursday, April 28, 2011
Message:
Fix compilation errors in translator.cpp.
Review URL: http://codereview.appspot.com/4445073
----
Modified : /trunk/samples/translator/translator.cpp
Modified : /trunk/src/common/version.h

Revision: 625
Author: jbauman@chromium.org
Date: 4:19:51 PM, Thursday, April 28, 2011
Message:
Don't constantly recreate index buffers.

Recreating index buffers for closing loops can take a long time, so use a streaming index buffer instead.

BUG=
TEST=

Review URL: http://codereview.appspot.com/4438080
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/Context.cpp
Modified : /trunk/src/libGLESv2/Context.h

Revision: 624
Author: benvanik@google.com
Date: 1:11:54 PM, Thursday, April 28, 2011
Message:
Updating resource types on Context (Framebuffers and Fences) to use hash_map, as done to other types in r615.

Issue= 148 
Signed-off-by: Daniel Koch
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/Context.h

Revision: 623
Author: benvanik@google.com
Date: 12:44:39 PM, Thursday, April 28, 2011
Message:
Unifying resource handle allocation code with an allocator optimized for O(1) allocs/releases.

Issue= 143 
Signed-off-by: Daniel Koch
----
Modified : /trunk/src/build_angle.gyp
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/Context.cpp
Modified : /trunk/src/libGLESv2/Context.h
Added : /trunk/src/libGLESv2/HandleAllocator.cpp
Added : /trunk/src/libGLESv2/HandleAllocator.h
Modified : /trunk/src/libGLESv2/ResourceManager.cpp
Modified : /trunk/src/libGLESv2/ResourceManager.h
Modified : /trunk/src/libGLESv2/libGLESv2.vcproj

Revision: 622
Author: daniel@transgaming.com
Date: 9:20:58 AM, Thursday, April 28, 2011
Message:
Handle null pointer produced by vertex buffer lock

Issue= 120 
TRAC #16558
Signed-off-by: Daniel Koch
Author: Nicolas Capens (original patch by Jacob Benoit)
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/Blit.cpp

Revision: 620
Author: daniel@transgaming.com
Date: 11:36:43 AM, Tuesday, April 26, 2011
Message:
Add MapLongVariableNames files to standalone vcproj
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/compiler/translator_common.vcproj

Revision: 619
Author: zmo@google.com
Date: 6:30:07 PM, Friday, April 22, 2011
Message:
Implement shader identifier name mapping.

The name mapping happens when an identifier is longer than 32 characters.  The name mapping is behind a flag, so it won't happen by default.  Also, functions to query the mapped names are added.

The purpose of this CL is for the drivers that can't handle long names.  For example, linux NVIDIA driver can't handle 256 character name, whereas WebGL spec requires that.

This CL also fixes the issue that some of the TIntermSymbols' ids are 0s.

ANGLEBUG=144
TEST=test manually with shaders with long identifier names.
Review URL: http://codereview.appspot.com/4428058
----
Modified : /trunk/src/common/version.h
Modified : /trunk/include/GLSLANG/ShaderLang.h
Modified : /trunk/src/build_angle.gyp
Modified : /trunk/src/compiler/Compiler.cpp
Added : /trunk/src/compiler/MapLongVariableNames.cpp
Added : /trunk/src/compiler/MapLongVariableNames.h
Modified : /trunk/src/compiler/ParseHelper.cpp
Modified : /trunk/src/compiler/ParseHelper.h
Modified : /trunk/src/compiler/ShHandle.h
Modified : /trunk/src/compiler/ShaderLang.cpp
Modified : /trunk/src/compiler/VariableInfo.cpp
Modified : /trunk/src/compiler/VariableInfo.h
Modified : /trunk/src/compiler/glslang.y
Modified : /trunk/src/compiler/glslang_tab.cpp
Modified : /trunk/src/compiler/glslang_tab.h
Modified : /trunk/src/compiler/intermediate.h

Revision: 618
Author: daniel@transgaming.com
Date: 4:33:27 AM, Friday, April 22, 2011
Message:
Use StretchRect to speed up simple blits.

Fixed copy position transformation.
TRAC #16494
Signed-off-by: Daniel Koch
Author: Nicolas Capens
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/Blit.cpp
Modified : /trunk/src/libGLESv2/Blit.h
Modified : /trunk/src/libGLESv2/Texture.cpp

Revision: 617
Author: daniel@transgaming.com
Date: 9:18:50 PM, Thursday, April 21, 2011
Message:
Advertise depthbuffer-less surface configs.

TRAC #16493
Signed-off-by: Daniel Koch
Author: Nicolas Capens
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libEGL/Config.cpp
Modified : /trunk/src/libEGL/Display.cpp
Modified : /trunk/src/libEGL/Surface.cpp

Revision: 616
Author: daniel@transgaming.com
Date: 9:17:57 PM, Thursday, April 21, 2011
Message:
Heuristically optimize buffer usage.

TRAC #16343
Signed-off-by: Daniel Koch
Author: Nicolas Capens
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/Buffer.cpp
Modified : /trunk/src/libGLESv2/Buffer.h
Modified : /trunk/src/libGLESv2/IndexDataManager.cpp
Modified : /trunk/src/libGLESv2/VertexDataManager.cpp

Revision: 615
Author: daniel@transgaming.com
Date: 8:03:48 AM, Thursday, April 14, 2011
Message:
Use a hash map for faster resource lookups.
TRAC #14871
Signed-off-by: Daniel Koch
Author: Nicolas Capens
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/Program.cpp
Modified : /trunk/src/libGLESv2/ResourceManager.h

Revision: 614
Author: daniel@transgaming.com
Date: 7:58:33 AM, Wednesday, April 13, 2011
Message:
Optimized prepareVertexData and protect against NULL pointers.

TRAC #14871
Signed-off-by: Daniel Koch
Author: Nicolas Capens
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/IndexDataManager.cpp
Modified : /trunk/src/libGLESv2/VertexDataManager.cpp

Revision: 613
Author: daniel@transgaming.com
Date: 7:57:16 AM, Wednesday, April 13, 2011
Message:
Move the vertex declaration cache to a helper class.

TRAC #14871
Signed-off-by: Daniel Koch
Author: Nicolas Capens
----
Modified : /trunk/src/libGLESv2/Context.cpp
Modified : /trunk/src/libGLESv2/Context.h

Revision: 612
Author: daniel@transgaming.com
Date: 7:56:47 AM, Wednesday, April 13, 2011
Message:
Eliminate lookupAttributeMapping.

TRAC #14871
Signed-off-by: Daniel Koch
Author: Nicolas Capens
----
Modified : /trunk/src/libGLESv2/VertexDataManager.cpp
Modified : /trunk/src/libGLESv2/Context.cpp
Modified : /trunk/src/libGLESv2/Context.h
Modified : /trunk/src/libGLESv2/VertexDataManager.h

Revision: 609
Author: jbauman@chromium.org
Date: 11:59:51 AM, Wednesday, April 06, 2011
Message:
Profiling shows that creating and destroying vertex declarations is extremely expensive, so we can keep a 16-element cache around to speed that up.

BUG=
TEST=JSGameBench

Review URL: http://codereview.appspot.com/4358051
----
Modified : /trunk/src/common/version.h
Modified : /trunk/src/libGLESv2/VertexDataManager.cpp
Modified : /trunk/src/libGLESv2/VertexDataManager.h


TEST=tryBUG=none
Review URL: http://codereview.chromium.org/6865035
------------------------------------------------------------------------
can you also tell chrome to use the monitor profile via chrome://flags ? because i dont have this option there ... 

Comment 111 by Deleted ...@, May 26 2011

I agree with #79: Using Chrome 11.0.696.68 on my wide gamut screen does NOT work well. Colors are too saturated (I'm running my screen in AdobeRGB color space). I believe color management is a very basic feature. Firefox (Windows & Linux) and Safari (on my Mac) do work, though. Any idea when this is going to be fixed?

Comment 112 by Deleted ...@, Jun 11 2011

Nothing has changed in Chrome 12.0.742.91 :(
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 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 114 by rwh...@gmail.com, Jul 28 2011

Talked to Melissa Daniels (Chrome OS Community Manager) & Jacky Hayward (Google Chrome Community Manager) via Google+ hangout today and they pointed me to this issue tracker as I asked them about this issue.

While I can certainly appreciate that there are higher priority issues/features that get fixed/added first, I would think in 3 yrs it would have made it into one of the builds eventually.

This is definitely a huge issue for photographers & graphic designers in particular and one in which prevents them from moving to Chrome from Firefox/Safari.

Comment 115 by rwh...@gmail.com, Aug 18 2011

Still no resolution...not even in Canary O_o
To handle color profiles in tagged images is one thing and to properly interpret the monitor profile is another. Chrome has to do both!
Hmmmm... The preview (below farbkreis.jpg 226 KB   View   Download) shows the wrong order, but when I open the image in a new tab it shows the correct order. I'm using Canary.
Eric Brasseur has a web page about gama-correct(color-correct) image resizing, and it's clear that Chrome doesn't do it.

http://www.4p8.com/eric.brasseur/gamma.html

You have to convert color values to linear space before you do resizing, rotating,(any other transform that needs intepolation), and alpha blending on your images. This includes resized images, browser zoom, CSS transforms, all canvas blending modes and rendering anti-aliased vectors(SVG or canvas).
I'll repeat my question from June 2010:

Can we pull in LittleCMS 2 for color management/matching?

http://littlecms2.blogspot.com
http://www.littlecms.com
QCMS - the current color management library for Firefox - would be nice too. It is faster than LCMS and it also supports ICCv4: http://cgit.freedesktop.org/~jrmuizel/qcms/

An older description here:
http://muizelaar.blogspot.com/2009/06/qcms-color-management-for-web.html

It was already proposed here, with a suggestion of how to do it: http://code.google.com/p/chromium/issues/detail?id=37028#c26
Any update on this?
icc-fail.PNG
464 KB View Download
Labels: nomedia
Cc: caryclark@chromium.org reed@google.com a...@chromium.org
 Issue 109371  has been merged into this issue.
Cc: tpayne@chromium.org
Is this still not fixed? Why can't this be given some priority please?  We've all been waiting a long time for colour management in Chrome.
I'm really looking forward to this problem being fixed for windows. I read somewhere that on Mac OS its been resolved? Is this true?

I switched to chrome from firefox last year when they adopted their rapid release cycle. I didn't like their redesign and have really embraced Chrome since. I would love to be able to use (and trust) chrome for my photo work!

Comment 127 by Deleted ...@, Feb 9 2012

Still broken in 17.0.963.46 :( . i wish this issue would get some attention.
 Issue 114601  has been merged into this issue.
Found reports that I could enable monitor profiles from the shortcut, but doing so didn't actually change anything. Please ... this is  issue #143  out of tens-of-thousands. Want to see it fixed before, after years of avoiding it, I have to go back to FireFox. 

Comment 130 by Deleted ...@, Mar 8 2012

thanks chrome....
Screen shot 2012-03-08 at 11.25.32.png
835 KB View Download

Comment 131 by dhw@chromium.org, Mar 12 2012

 Issue 105282  has been merged into this issue.
Project Member

Comment 132 by bugdroid1@chromium.org, Mar 28 2012

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

------------------------------------------------------------------------
r129510 | tpayne@chromium.org | Wed Mar 28 16:05:14 PDT 2012

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/transform.c?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/transform-sse1.c?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/transform-sse2.c?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/Makefile.in?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/qcms.gyp?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/transform_util.c?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/COPYING?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/README?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/transform_util.h?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/qcmsint.h?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/iccread.c?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/qcms.h?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/README.chromium?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/chain.c?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/matrix.c?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/qcmstypes.h?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/chain.h?r1=129510&r2=129509&pathrev=129510
 M http://src.chromium.org/viewvc/chrome/trunk/src/build/all.gyp?r1=129510&r2=129509&pathrev=129510
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/matrix.h?r1=129510&r2=129509&pathrev=129510

Adding qcms to use for handling ICC tagged images. This will be used by chromium webkit port.

BUG= 143 
TEST=NONE


Review URL: http://codereview.chromium.org/9702032
------------------------------------------------------------------------
Does this mean it's fixed and when will it be available in a stable version?
Project Member

Comment 134 by bugdroid1@chromium.org, Mar 29 2012

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

------------------------------------------------------------------------
r129549 | georgey@chromium.org | Wed Mar 28 18:38:07 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/build/all.gyp?r1=129549&r2=129548&pathrev=129549
 D http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms?r1=129549&r2=129548&pathrev=129549

Revert 129510 - Adding qcms to use for handling ICC tagged images. This will be used by chromium webkit port.

http://chrome-master2.mtv:8011/
Failure on official continuous builder.
http://chrome-master2.mtv:8011/builders/linux32%20trunk/builds/3711

BUG= 143 
TEST=NONE


Review URL: http://codereview.chromium.org/9702032

TBR=tpayne@chromium.org
Review URL: https://chromiumcodereview.appspot.com/9910003
------------------------------------------------------------------------
I was curious about why qcms was chosen over the more robust (i.e. fully ICC 4.3 compliant) LittleCMS. The comparison that is linked to in comment 120 is from October 2009. LittleCMS is up to version 2.3 now. A tutorial, which includes some helpful information about it, can be found at http://www.littlecms.com/LittleCMS2.3%20tutorial.pdf. 

Comment 136 by scr@chromium.org, Mar 30 2012

Cc: est...@chromium.org
Owner: tpayne@chromium.org
Status: Assigned
Project Member

Comment 137 by bugdroid1@chromium.org, Apr 4 2012

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

------------------------------------------------------------------------
r130542 | estade@chromium.org | Tue Apr 03 19:29:36 PDT 2012

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/COPYING?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/matrix.c?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/qcmsint.h?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/matrix.h?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/iccread.c?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/qcms.gyp?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/chain.c?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform-sse1.c?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform-sse2.c?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/chain.h?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/qcmstypes.h?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/README.chromium?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform.c?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform_util.c?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/README?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform_util.h?r1=130542&r2=130541&pathrev=130542
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/qcms.h?r1=130542&r2=130541&pathrev=130542

Adds qcms to third_party for use in handling ICC color profiles.

BUG= 143 
TEST=None
author: Tony Payne <tpayne@chromium.org>
Original review: http://codereview.chromium.org/9969111/

Review URL: https://chromiumcodereview.appspot.com/9956130
------------------------------------------------------------------------
Project Member

Comment 138 by bugdroid1@chromium.org, Apr 4 2012

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

------------------------------------------------------------------------
r130549 | estade@chromium.org | Tue Apr 03 20:07:59 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/build/all.gyp?r1=130549&r2=130548&pathrev=130549

Adds qcms to all.gyp. This was reverted before because qcms' sse2 code didn't compile on linux32 Official build. I believe I've fixed it by adding -msse and -msse2. Will submit late at night and watch the bots.

BUG= 143 
TEST=None
author: Tony Payne <tpayne@chromium.org>
original review: http://codereview.chromium.org/9958140/

Review URL: https://chromiumcodereview.appspot.com/9969139
------------------------------------------------------------------------

Comment 139 by k...@gmx.de, Apr 19 2012

Do you provide nightly builds, so interested people can help testing?

Following are colour management links for Linux developers:
http://www.oyranos.com/wiki/index.php?title=OpenIccDirectoryProposal
http://www.freedesktop.org/wiki/Specifications/icc_profiles_in_x_spec

Comment 140 by scr@chromium.org, Apr 20 2012

Blockedon: webkit:81974
Cc: noel@chromium.org

Comment 141 by noel@chromium.org, Apr 21 2012

How hard would it be to patch qcms to produce bgra output pixels.  My estimate is about a days work.

 1. add an int argument to the qms_tranform() function to indicate if output
    should be bgrx (default output shall be rgbx).

 2. pass that argument through to all qms_transform_xxxx() functions including
    the SSE1 and SSE2 implementations.

 3. Adjust all transform qms_transfrom_xxxx() routines for the required pixel
    outputFormat as follows

 // For each of the rgba variants of the the color transform functions:

 void qms_transfrom_xxxx_rgba( ... unsigned char *src, unsigned char *dest, size_t length, int outputFormat)
 {
    int r_out = outputFormat == BGRX ? 2 : 0;
    int g_out = 1;
    int b_out = outputFormat == BGRX ? 0 : 2;
    int a_out = 3;

    for (int i = 0; i < length; ++i)
    {
       // transform src pixel[i] with this transforms data | table

       out_device_r = yada-yada ...
       out_device_g = yada-yada ...
       out_device_b = yada-yada ...

       // write the transformed pixel[i] to the output destination

       dest[r_out] = clamp_u8(out_device_r*255);
       dest[g_out] = clamp_u8(out_device_g*255);
       dest[b_out] = clamp_u8(out_device_b*255);
       dest[a_out] = alpha;

       dest += 4;
    }
 }

 // For each of the rgb variants of the the color transform functions:

 void qms_transfrom_xxxx_rgb( ... unsigned char *src, unsigned char *dest, size_t length, int outputFormat)
 {
    int r_out = outputFormat == BGRX ? 2 : 0;
    int g_out = 1;
    int b_out = outputFormat == BGRX ? 0 : 2;

    for (int i = 0; i < length; ++i)
    {
       // transform src pixel[i] with this transforms data | table

       out_device_r = yada-yada ...
       out_device_g = yada-yada ...
       out_device_b = yada-yada ...

       // write the transformed pixel[i] to the output destination

       dest[r_out] = clamp_u8(out_device_r*255);
       dest[g_out] = clamp_u8(out_device_g*255);
       dest[b_out] = clamp_u8(out_device_b*255);

       dest += 3;
    }
 }

And why would this be useful?

 Because chromium mac/linux/win is BGRA pixels all the way down.

 Chromium is designed for little endian machines only, reading from src/build/build-config.h.
 http://src.chromium.org/viewvc/chrome/trunk/src/build/build_config.h?view=diff&r1=90424&r2=90425

 Brett made this point in his reply about Chromium endianness on chromium-dev@.
 http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/c6c4a23a33c155f4?fwc=1&pli=1

 The Chromium Skia code states: "All little-endian Chrome platforms agree: BGRA is the optimal pixel layout."
 http://src.chromium.org/viewvc/chrome/trunk/src/skia/config/SkUserConfig.h?view=diff&r1=33862&r2=33863


Seems to me that BGRA output support in qcms would better integrate this library with chrome.

Comment 142 by Deleted ...@, Apr 21 2012

Please...for all that is good in this world, at least add the *option* of color management.  Disable it by default for all I care.

Just give users a choice.

It can't get any more fair than that.
Cc: jrmui...@gmail.com
Jeff, would you mind giving some guidance on Noel's suggestion above? Is this practical? Does 1 day sound like a reasonable estimate for someone unfamiliar with the qcms code? Would you accept such a patch upstream?
I think it might be better to have this as a build time option. I'm not sure there's much of use case for supporting both formats and in the same build and it's probably simpler to implement that way.

Something like this:

@@ -853,9 +853,9 @@ static void qcms_transform_data_rgb_out_lut(qcms_transform *transform, unsigned
        unsigned int i;
        float (*mat)[4] = transform->matrix;
        for (i = 0; i < length; i++) {
-               unsigned char device_r = *src++;
-               unsigned char device_g = *src++;
-               unsigned char device_b = *src++;
+               unsigned char device_r = src[PIXEL_R_OFFSET];
+               unsigned char device_g = src[PIXEL_G_OFFSET];
+               unsigned char device_b = src[PIXEL_B_OFFSET];
                float out_device_r, out_device_g, out_device_b;
 
                float linear_r = transform->input_gamma_table_r[device_r];
@@ -874,9 +874,9 @@ static void qcms_transform_data_rgb_out_lut(qcms_transform *transform, unsigned
                out_device_g = lut_interp_linear(out_linear_g, transform->output_gamma_lut_g, transform->output_gamma_lut_g_length);
                out_device_b = lut_interp_linear(out_linear_b, transform->output_gamma_lut_b, transform->output_gamma_lut_b_length);
 
-               *dest++ = clamp_u8(out_device_r*255);
-               *dest++ = clamp_u8(out_device_g*255);
-               *dest++ = clamp_u8(out_device_b*255);
+               dest[PIXEL_R_OFFSET] = clamp_u8(out_device_r*255);
+               dest[PIXEL_G_OFFSET] = clamp_u8(out_device_g*255);
+               dest[PIXEL_B_OFFSET] = clamp_u8(out_device_b*255);
        }
 }
 

(I'm not sure if you want to change the input format as well...)

This shouldn't be too much work, even for someone unfamiliar with the qcms code.

Comment 145 Deleted

Comment 146 by noel@chromium.org, Apr 24 2012

> (I'm not sure if you want to change the input format as well...)

Nope, input is rgb/rgba currently and that's fine for now.

What I'm sure of is the need to tweak the output format brga|rgba.  Seemed I would just need fiddle with the dest ... and find 3 spare hours on my Sunday ...
qcms-brga-support.git (1).diff
25.6 KB View Download

Comment 147 by noel@chromium.org, Apr 24 2012

> I think it might be better to have this as a build time option. I'm not sure there's much of use case for supporting both formats and in the same build and it's probably simpler to implement that way.

Saw this after writing my patch, but yes a built-time option to control the output (dest) format would work for me. 

Comment 148 Deleted

Comment 149 by noel@chromium.org, Apr 26 2012

Ah correction, WebCore png decodes wants rgba output, and jpeg decodes wants bgra output.  
Project Member

Comment 150 by bugdroid1@chromium.org, May 23 2012

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

------------------------------------------------------------------------
r138414 | estade@chromium.org | Tue May 22 18:46:02 PDT 2012

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/google.patch?r1=138414&r2=138413&pathrev=138414
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/qcmsint.h?r1=138414&r2=138413&pathrev=138414
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/README.chromium?r1=138414&r2=138413&pathrev=138414
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform.c?r1=138414&r2=138413&pathrev=138414
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/iccread.c?r1=138414&r2=138413&pathrev=138414
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform-sse1.c?r1=138414&r2=138413&pathrev=138414
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/qcms.h?r1=138414&r2=138413&pathrev=138414
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform-sse2.c?r1=138414&r2=138413&pathrev=138414
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/qcmstypes.h?r1=138414&r2=138413&pathrev=138414

Add BGRA output format support to qcms

Define QCMS_OUTPUT_BGRX and add qcms_transform_data_type() api to output
BGR or BGRA format for GRAY, GRAYA, RGB, and RGBA input data.

Update all color transform functions with an output format argument, use
that to select RGBX (the default) or BGRX output format.

Add google.patch: patch of the BGRA output changes against upstream qcms
and add README.chromium details about google.patch. TODO: send the patch
to qcms if accepted for review upstream.

Disable Visual Studio warnings when needed.

BUG= 143 
TEST=None
AUTHOR=noel@chromium.org
original review = http://codereview.chromium.org/10387099/

Review URL: https://chromiumcodereview.appspot.com/10407113
------------------------------------------------------------------------
Blockedon: chromium:129452
chrome is a crappy browser for this.
Cc: -brettw@chromium.org
Project Member

Comment 154 by bugdroid1@chromium.org, Jun 7 2012

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

------------------------------------------------------------------------
r140952 | tpayne@chromium.org | Wed Jun 06 21:10:32 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/google.patch?r1=140952&r2=140951&pathrev=140952
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/README.chromium?r1=140952&r2=140951&pathrev=140952
 M http://src.chromium.org/viewvc/chrome/trunk/src/third_party/qcms/src/transform_util.c?r1=140952&r2=140951&pathrev=140952

Fix qcms to allow gamma==1.0

BUG= 143 
TEST=None
NOTRY=true


Review URL: https://chromiumcodereview.appspot.com/10546036
------------------------------------------------------------------------
Project Member

Comment 155 by bugdroid1@chromium.org, Jul 19 2012

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

------------------------------------------------------------------------
r147361 | tpayne@chromium.org | 2012-07-19T00:39:57.264367Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/ui.gyp?r1=147361&r2=147360&pathrev=147361
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/common/view_messages.h?r1=147361&r2=147360&pathrev=147361
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_message_filter.cc?r1=147361&r2=147360&pathrev=147361
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_message_filter.h?r1=147361&r2=147360&pathrev=147361
   A http://src.chromium.org/viewvc/chrome/trunk/src/ui/gfx/color_profile_win.cc?r1=147361&r2=147360&pathrev=147361
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/renderer_webkitplatformsupport_impl.cc?r1=147361&r2=147360&pathrev=147361
   A http://src.chromium.org/viewvc/chrome/trunk/src/ui/gfx/color_profile.cc?r1=147361&r2=147360&pathrev=147361
   A http://src.chromium.org/viewvc/chrome/trunk/src/ui/gfx/color_profile_mac.cc?r1=147361&r2=147360&pathrev=147361
   M http://src.chromium.org/viewvc/chrome/trunk/src/content/renderer/renderer_webkitplatformsupport_impl.h?r1=147361&r2=147360&pathrev=147361
   A http://src.chromium.org/viewvc/chrome/trunk/src/ui/gfx/color_profile.h?r1=147361&r2=147360&pathrev=147361

Adds monitor ICC profile support for win and mac

BUG= 143 
TEST=


Review URL: https://chromiumcodereview.appspot.com/10448110
------------------------------------------------------------------------
Project Member

Comment 156 by bugdroid1@chromium.org, Jul 19 2012

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

------------------------------------------------------------------------
r147429 | bauerb@chromium.org | 2012-07-19T12:15:35.003550Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/ui/gfx/color_profile.cc?r1=147429&r2=147428&pathrev=147429

Fix Mac component build by using correct #define in ui/gfx/color_profile.cc.

TBR=ben@chromium.org
BUG= 143 
TEST=nope


Review URL: https://chromiumcodereview.appspot.com/10796030
------------------------------------------------------------------------
Great, I today tried Canary 22.0.1212.0  and this is the first time I see a partly working color management with chrome on Windows 7 - thanks!

But there is still room to improve, please have a look here:
http://www.color.org/browsertest.xalter
http://ie.microsoft.com/testdrive/graphics/colorprofiles/default.html
http://gearoracle.com/tools/web-browser-color-management-test/

So there is still a problem with ICC v4 profiles, LUT based input profiles and untagged images (not handled as sRGB see  Issue 37028  <- this is a main problem!).

Firefox is AFAIK still the only browser that passes these tests, so it should be possible with qcms.

Blockedon: -chromium:61627 -chromium:129452 -webkit:81974 chromium:61627 chromium:129452 webkit:81974
JP, thank you very much for testing out the new color management feature.

I haven't enabled ICCv4 profiles yet, for the same reason that it's not enabled by default in Firefox. Qcms performance when handling ICCv4 profiles is not where we'd like it to be. The Mozilla team is working on it and I'm sure it will get there.

For handling untagged images as sRGB, you may want to try the --enable-monitor-profile command line flag. On Windows, this option will cause everything, including CSS colors to be converted from sRGB to your monitor profile.
We're tracking the changes needed to enable ICCv4 support by default here:
https://bugzilla.mozilla.org/show_bug.cgi?id=679875

It boils down to fuzzing, performance optimizations and investigating accuracies. Any contributions to these would help enable ICCv4 support in both browsers. Once these issues are solved qcms could be integrated with the hardware compositor.
First, let me thank you again, I'm deep into photography and exact color reproduction is a major concern for me, so your work is very much appreciated by me as well as countless others, I'm sure!

I tried the "--enable-monitor-profile" command line flag, but it does not work as advertised and actually seems to break the use of the monitor profile!

Please see the attached screenshot from http://gearoracle.com/tools/web-browser-color-management-test/
I use a wide gamut LCD-display (not uncommon today), so without a working monitor profile colors appear over-saturated, and with a working profile it should be possible to see the gamut difference in the upper test-bar - please compare with the Firefox sample, it should look like this.

CM_Browser_Comparison.jpg
69.4 KB View Download
Labels: -Mstone-X Mstone-22
JP,

--enable-monitor-profile works by mapping everything to sRGB and then applying the sRGB->monitor profile transformation. This prevents CSS colors and untagged images from becoming oversaturated on a wide gamut monitor but does not preserve the large gamut of color spaces like Pro Photo RGB and Adobe RGB 1998.

A complete color management solution is pending http://code.google.com/p/chromium/issues/detail?id=37028
Labels: Feature-Color-Management
 Issue 2602  has been merged into this issue.
Hello tpa,
actually it seems not to work as described by you, if I set the "--enable-monitor-profile" command line flag I see oversaturated colors on my wide gamut monitor (look at the upper bar in the CM_Browser_Comparison.jpg picture, the canary sample is single colored - there is no saturation step in the upper bar, so there is no sRGB->monitor profile transformation).
JP,

If you open ProPhotoRGB_tagged_bars.jpg in your favorite photo editor and convert to sRGB, you'll see a similar drop in saturation as you're seeing in canary with --enable-monitor-profile. Because this ProPhotoRGB->sRGB conversion is happening before the sRGB->monitor conversion, you don't see the vertical distinction between ProPhotoRGB and sRGB. Both rows look like the sRGB tagged version. To see the larger gamut of the ProPhotoRGB image, the sRGB intermediate step would need to be skipped, which only happens when --enable-monitor-profile is not present.

I hope that helps.
Why would there ever be an intermediate step, no matter what options are used?
tpa,
thanks, it really helped, there should be indeed no distinction between the ProPhotoRGB and sRGB patch, if there is a prior conversion to sRGB. Sorry for misleading, point taken.

But would you please have a second (third?) look at the picture? ;-)
You wrote "Both rows look like the sRGB tagged version" and that is not true, both (all) Canary patches look like the ProPhotoRGB Patch (high saturation). Please compare with Firefox and Canary without "--enable-monitor-profile", the sRGB patches are there less saturated and all Canary patches (with "--enable-monitor-profile") should look like this (less saturated), if there really is a working sRGB->monitor profile transformation.

JP, I see what you're saying, but I cannot reproduce your experience. When I perform the same test, I get the less saturated colors with --enable-monitor-profile.
TPA,
I've double checked that there is no problem on my side (Win 7/64 (latest patches), Canary Version 22.0.1221.0).
The "--enable-monitor-profile" command line flag is recognized by Canary, you can see there is a change in the color rendering after enabling it.
There is also no reason to believe there is something wrong with my monitor profile, because Canary without "--enable-monitor-profile" and Firefox 15 (without enabled V4 profiles) handle it fine.
So, where to look?

Status: Fixed
This should be on beta channel soon and in the subsequent stable release.

Note, that this is not a complete color management solution, but I believe that Windows and Mac are now correctly handling JPGs and PNGs with embedded ICC profiles, on systems with and without a monitor profile.

Note that --enable-monitor-profile on Windows will cause tagged images to be converted to sRGB and then to the monitor profile, at some cost to the color gamut. When using a wide gamut monitor, you will need to decide whether CSS colors/untagged images or tagged images should have priority.
Is there/should there be a meta-bug for the complete solution, covering items like  Issue 44872  and  Issue 37028 ?
edward.coffey, the following search should return the known color management feature issues: http://code.google.com/p/chromium/issues/list?q=label:Feature-Color-Management
What is status of this bug on the linux...?
> Note that --enable-monitor-profile on Windows will cause tagged images to be converted to sRGB and then to the monitor profile

Hm... why is that limitation? Also, what is the switch is not used, will the gamut be preserved? Is there a way to have correct color (both, respect image and monitor prifile) without that switch?
I tried the image (from Comment #0) on all platforms with latest canary build, the bug is *not* repro'able
> Note that --enable-monitor-profile on Windows will cause tagged images to be converted to sRGB and then to the monitor profile

That kills the whole point of having a wide gamut color space. Sure colors will display correctly on the monitor, but you will use all the additional color information in AdobeRGB or ProPhotoRGB images. If you need an intermediate color space use 32bit float CIElab or something like that.

Note that not using --enable-monitor-profile is no solution to displaying wide gamut images. Sure no "downsampling" of color space to sRGB takes place, but nobody has an exact AdobeRGB monitor, those monitor profiles are custom profiles, when coming from a custom calibration they are different for every single monitor device.
Project Member

Comment 177 by bugdroid1@chromium.org, Oct 14 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

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

Labels: -Mstone-22 -Area-Internals -Internals-Skia Cr-Internals-Skia Cr-Internals M-22
Project Member

Comment 179 by bugdroid1@chromium.org, Mar 14 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Showing comments 80 - 179 of 179 Older

Sign in to add a comment