Color Management Woes
This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| Color Management Woes | Frank Gore | 13 Jan 23:46 |
| Color Management Woes | Michael J. Hammel | 14 Jan 00:09 |
| Color Management Woes | Frank Gore | 14 Jan 00:20 |
| Color Management Woes | Michael J. Hammel | 14 Jan 00:45 |
| Color Management Woes | Milan Knížek | 15 Jan 23:05 |
| Color Management Woes | David Gowers | 14 Jan 00:23 |
| Color Management Woes | Frank Gore | 14 Jan 00:34 |
| Color Management Woes | Michael J. Hammel | 14 Jan 00:47 |
| Color Management Woes | Frank Gore | 14 Jan 01:36 |
| Color Management Woes | Frank Gore | 14 Jan 01:55 |
| Color Management Woes | David Gowers | 14 Jan 05:43 |
| Color Management Woes | Frank Gore | 14 Jan 06:48 |
| Color Management Woes | David Gowers | 14 Jan 09:26 |
| Color Management Woes | Milan Knížek | 14 Jan 20:56 |
| 54b2ccaa1001141834j41fb2af5... | 07 Oct 20:20 | |
| Color Management Woes | Frank Gore | 15 Jan 03:35 |
| Color Management Woes | Tom Williams | 15 Jan 03:43 |
| Color Management Woes | Milan Knížek | 15 Jan 22:41 |
| 54b2ccaa1001151412o5b353f04... | 07 Oct 20:20 | |
| Color Management Woes | Milan Knížek | 16 Jan 09:32 |
| Color Management Woes | Frank Gore | 16 Jan 12:40 |
| Color Management Woes | Alexandre Prokoudine | 16 Jan 15:03 |
| 54b2ccaa1001162030j580bfafc... | 07 Oct 20:20 | |
| Color Management Woes | Frank Gore | 17 Jan 23:16 |
| Color Management Woes | Frank Gore | 18 Jan 02:02 |
Color Management Woes
I've been pulling my hair out trying to figure out color management in Gimp.
In the preferences, I clearly have "File Open Behaviour" set to "Ask what to do". My working profile is sRGB, and so is my Monitor profile. I have "Display rendering intent" set to "Relative colorimetric". Yet, everytime I open an image, Gimp never asks me what to do about the color profile. It always assumes sRGB, even if the embedded color profile is Adobe RGB or ProPhoto or whatever else. I always have to manually assign the right color profile after the file has been opened.
Further, when I go to assign a color profile, I have to know in advance what the profile of that image was. Gimp doesn't tell me. It lets me change to whatever profile I want, but it won't let me know which one is embedded in the image. Sometimes, the color profile is not listed in the EXIF data at all, which makes it harder to guess. For example, when my camera is set to Adobe RGB, it leaves the EXIF "Color space" field set to "Unassigned".
Is this normal Gimp behavior? It's making color management a real nightmare and giving me all kinds of headaches. I sometimes receive images in many different color spaces and I don't always know which ones. Some people love working in ProPhoto because it makes them feel all 1337 and superior. Others send me stuff in Adobe RGB because that's what their printing company requires. I try to stick to sRGB whenever possible, but it's not always ideal.
I hope someone can help me with this issue.
I have Gimp 2.6.8 on openSUSE 11.2 x86_64. It's a backport from the Gnome OBS repository.
Color Management Woes
On Wed, 2010-01-13 at 17:46 -0500, Frank Gore wrote:
In the preferences, I clearly have "File Open Behaviour" set to "Ask what to do". My working profile is sRGB, and so is my Monitor profile.
I'm no expert about this so my wild-ass guess is that it doesn't ask because there is nothing to do. Consider that the working profile is what a file *HAS* to be converted to or else you can't open it. If the file has an Adobe RGB profile but there is no such working profile the file couldn't be edited unless it was automatically converted, right?
So the conversion would be to your Monitor profile. If you had a monitor profile different than the working profile then the Adobe RGB would have to converted to the monitor profile first and then to the working profile to be edited. Since the monitor profile and working profile are the same then there is nothing to ask - you simply get an automatic conversion to sRGB.
But again, that's just a wild guess. I've never dug into that part of the code to know what's really going on. Hopefully Sven or one of the developers will correct me here.
Color Management Woes
On Wed, Jan 13, 2010 at 6:09 PM, Michael J. Hammel wrote:
I'm no expert about this so my wild-ass guess is that it doesn't ask because there is nothing to do. Consider that the working profile is what a file *HAS* to be converted to or else you can't open it. If the file has an Adobe RGB profile but there is no such working profile the file couldn't be edited unless it was automatically converted, right?
So the conversion would be to your Monitor profile. If you had a monitor profile different than the working profile then the Adobe RGB would have to converted to the monitor profile first and then to the working profile to be edited. Since the monitor profile and working profile are the same then there is nothing to ask - you simply get an automatic conversion to sRGB.
But the problem is that it doesn't convert when I open the file. It just assumes the picture is in sRGB and interprets the color space that way. Have you ever seen the colors of a file in Adobe RGB that's incorrectly interpreted as sRGB? They're flat and dull, bland, lifeless. I lose a bunch of contrast and saturation.
Oh I can assign the right color profile and it fixes it right away, no conversion necessary. But how do I know which color profile to assign? What if the original was SUPPOSED to look bland and lifeless? What if I'm messing up the colors by assigning an Adobe RGB profile where I was supposed to leave it as sRGB? That tends to mess up the colors the other way, adding contrast and saturation where there should be less.
In any case, like I mentioned in my original post, I specifically have it set to "Ask what to do" in the Preferences, and it doesn't ask.
Color Management Woes
On Thu, Jan 14, 2010 at 9:16 AM, Frank Gore wrote:
I've been pulling my hair out trying to figure out color management in Gimp.
In the preferences, I clearly have "File Open Behaviour" set to "Ask what to do". My working profile is sRGB, and so is my Monitor profile. I have "Display rendering intent" set to "Relative colorimetric". Yet, everytime I open an image, Gimp never asks me what to do about the color profile. It always assumes sRGB, even if the embedded color profile is Adobe RGB or ProPhoto or whatever else. I always have to manually assign the right color profile after the file has been opened.
Further, when I go to assign a color profile, I have to know in advance what the profile of that image was. Gimp doesn't tell me. It lets me change to whatever profile I want, but it won't let me know which one is embedded in the image.
Also.. does that mean that you go to the 'Color profile' section of Image Properties and it says nothing / is blank?
Color Management Woes
On Wed, Jan 13, 2010 at 6:21 PM, David Gowers wrote:
That sounds very much like it is attached in a non-standard way.
Actually, you're entirely right. If I assign an Adobe RGB profile to the picture, then save it, and re-open it, THEN it asks me what to do with the color profile, just like I expected it to. Apparently the original file has the profile embedded in some different manner. However, [big-brand commercial application] has no trouble determining what the color space should be, even with the original files.
On Wed, Jan 13, 2010 at 6:23 PM, David Gowers wrote:
Also.. does that mean that you go to the 'Color profile' section of Image Properties and it says nothing / is blank?
Nope, it says it's sRGB. Regardless of what it SHOULD be, it always says sRGB (until I assign a different color space manually). This is wrong.
The files I'm working with right now are from my Pentax K-7 DSLR. The JPG and TIF files it produces apparently have the color profile embedded in a weird way, thereby keeping Gimp from seeing it. Now I don't know how "weird" it is, since every commercial application I've used has had no problems with it so far. It's only Gimp and Digikam that are giving me trouble.
Color Management Woes
On Wed, 2010-01-13 at 18:20 -0500, Frank Gore wrote:
But the problem is that it doesn't convert when I open the file. It just assumes the picture is in sRGB and interprets the color space that way. Have you ever seen the colors of a file in Adobe RGB that's incorrectly interpreted as sRGB? They're flat and dull, bland, lifeless. I lose a bunch of contrast and saturation.
Possibly, but then you don't provide a display color profile so maybe it's your display that's washed out, not the image. What may happen is that the Adobe RGB->sRGB happens just fine but what you *SEE* is the sRGB, not what the image should be when mapped to the color profile of the monitor.
Again, I'm mostly talking out my be-hind here. I've done some articles on the color management stuff so I've played with it and I have both monitor and print profiles set up. But I'm not completely sure where the conversions happen on the file open and display pipeline.
Oh I can assign the right color profile and it fixes it right away, no conversion necessary. But how do I know which color profile to assign? What if the original was SUPPOSED to look bland and lifeless? What if I'm messing up the colors by assigning an Adobe RGB profile where I was supposed to leave it as sRGB? That tends to mess up the colors the other way, adding contrast and saturation where there should be less.
Again, this seems to me to point to an incorrect monitor color profile.
In any case, like I mentioned in my original post, I specifically have it set to "Ask what to do" in the Preferences, and it doesn't ask.
Like I said, this could be because there is nothing to ask about. The file is opened by converting from its original color space to the working space and then displayed that way. The "asking" may only happen when you want to convert from the original color space to your display color space (which could be your monitor profile or a print profile, for example) before conversion to sRGB for working.
Again, this just a guess. I'm talking enough to convince myself but we really need someone with more color management experience explaining it.
Color Management Woes
On Wed, 2010-01-13 at 18:34 -0500, Frank Gore wrote:
On Wed, Jan 13, 2010 at 6:21 PM, David Gowers wrote:
That sounds very much like it is attached in a non-standard way.
Actually, you're entirely right. If I assign an Adobe RGB profile to the picture, then save it, and re-open it, THEN it asks me what to do with the color profile, just like I expected it to. Apparently the original file has the profile embedded in some different manner. However, [big-brand commercial application] has no trouble determining what the color space should be, even with the original files.
Ah. See? I told you we needed someone who understood it better. :-)
Color Management Woes
I just tested this with other Pentax cameras. So far, files from the K-7, K20D and K-x all open in Gimp without asking me to specify color profile, and they all incorrectly default to sRGB. All these images DO have an Adobe RGB profile embedded. But those are the only cameras I can check with that include an Adobe RGB option.
As I mentioned, all the commercial applications I've tried had no problems determining the appropriate color space for these files. It's only open source tools that are unable to, including Gimp.
So is this a bug? Or is Pentax really that crazy with their file formats? They can't be that crazy if commercial applications have no trouble with the files.
Color Management Woes
On Wed, Jan 13, 2010 at 7:36 PM, Frank Gore wrote:
As I mentioned, all the commercial applications I've tried had no problems determining the appropriate color space for these files. It's only open source tools that are unable to, including Gimp.
So is this a bug? Or is Pentax really that crazy with their file formats? They can't be that crazy if commercial applications have no trouble with the files.
Someone mentioned I should perhaps post examples of these files, and that's a fine idea. Wish I'd thought of it sooner. These were taken at seriously-reduced megapixels in the interest of file size. I figured the file format was more important than the quality of the picture.
Here's one straight from my K-7, in Adobe RGB: http://picasaweb.google.ca/lh/photo/Wc8Lq42A20qRxDoTj1dNRQ?feat=directlink
And here's another one in sRGB, taken immediately after the above: http://picasaweb.google.ca/lh/photo/c7_78WNLRXvEgHnmb6QM4g?feat=directlink
Both can be downloaded in full by using the "Download" link
Color Management Woes
On Thu, Jan 14, 2010 at 11:25 AM, Frank Gore wrote:
On Wed, Jan 13, 2010 at 7:36 PM, Frank Gore wrote:
As I mentioned, all the commercial applications I've tried had no problems determining the appropriate color space for these files. It's only open source tools that are unable to, including Gimp.
So is this a bug? Or is Pentax really that crazy with their file formats? They can't be that crazy if commercial applications have no trouble with the files.
That's a fallacy, I'm afraid.
We don't know if their formats are crazy. But they certainly appear to be undocumented. Until they are documented, or someone reverse-engineers them, we are unlikely to gain support for them in open-source software.
(OTOH, it could just be attached in the metadata. EXIF / IPTC support is not complete yet.)
Someone mentioned I should perhaps post examples of these files, and that's a fine idea. Wish I'd thought of it sooner. These were taken at seriously-reduced megapixels in the interest of file size. I figured the file format was more important than the quality of the picture.
Here's one straight from my K-7, in Adobe RGB: http://picasaweb.google.ca/lh/photo/Wc8Lq42A20qRxDoTj1dNRQ?feat=directlink
And here's another one in sRGB, taken immediately after the above: http://picasaweb.google.ca/lh/photo/c7_78WNLRXvEgHnmb6QM4g?feat=directlink
These could be quite helpful if someone is inclined to reverse engineer it to spot the difference
Color Management Woes
On Wed, Jan 13, 2010 at 11:43 PM, David Gowers wrote:
We don't know if their formats are crazy. But they certainly appear to be undocumented. Until they are documented, or someone reverse-engineers them, we are unlikely to gain support for them in open-source software.
(OTOH, it could just be attached in the metadata. EXIF / IPTC support is not complete yet.)
ok... but why is Gimp assuming sRGB? Even if the color profile is attached in some bizarre non-standard manner, Gimp should detect NO color profile and ask me about it when I open the file. Isn't that how it's supposed to work? That's what other applications do, for example Digikam/showFoto.
Color Management Woes
On Thu, Jan 14, 2010 at 4:18 PM, Frank Gore wrote:
On Wed, Jan 13, 2010 at 11:43 PM, David Gowers wrote:
We don't know if their formats are crazy. But they certainly appear to be undocumented. Until they are documented, or someone reverse-engineers them, we are unlikely to gain support for them in open-source software.
(OTOH, it could just be attached in the metadata. EXIF / IPTC support is not complete yet.)
ok... but why is Gimp assuming sRGB? Even if the color profile is attached in some bizarre non-standard manner, Gimp should detect NO color profile and ask me about it when I open the file. Isn't that how it's supposed to work? That's what other applications do, for example Digikam/showFoto.
Don't you think that would be very tiresome? Most images have no ICC profile attached; in this case, sRGB is indeed implied. Producing images that are not sRGB but have no ICC profile attached is wrong (more precisely, it's a miscommunication, saying that the image is sRGB when it's not. ). I appreciate your situation of needing to correct the profile here, OTOH, have you considered using tools like imagemagick and jpegicc to detect the camera it came from and then attach an appropriate profile. this would allow you to assign profiles automatically in large batches. IMO this is much less painful all around.
BTW, I just checked the exif information on those JPEGs and both have no EXIF information. So it does look indeed like the profile data is stored in some custom format; there may even be no profile per se stored, just a reference to or description of one.
Color Management Woes
David Gowers píše v ?t 14. 01. 2010 v 18:56 +1030:
On Thu, Jan 14, 2010 at 4:18 PM, Frank Gore wrote:
color profile and ask me about it when I open the file. Isn't that how it's supposed to work? That's what other applications do, for example Digikam/showFoto.
In digiKam, the user can pre-set what to do in case of a missing profile. Majority would probably use "assign sRGB" instead of asking each time.
BTW, I just checked the exif information on those JPEGs and both have no EXIF information. So it does look indeed like the profile data is stored in some custom format; there may even be no profile per se stored, just a reference to or description of one.
How about the filenames? AdobeRGB image starts with "_" (underscore).
As far as I can tell, ImageMagick, exiv2 and exiftool do not report any metadata, even not the maker's non-readable ones.
Regards,
Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only)
Color Management Woes
On Thu, Jan 14, 2010 at 3:26 AM, David Gowers wrote:
Don't you think that would be very tiresome? Most images have no ICC profile attached; in this case, sRGB is indeed implied. Producing images that are not sRGB but have no ICC profile attached is wrong (more precisely, it's a miscommunication, saying that the image is sRGB when it's not. ).
Nope, I wouldn't find that tiresome at all. Many other applications have an option to allow just that. When I edit a file in Digikam, I have it set so that if there's no color profile detected, it asks me what the source color profile should be and whether or not to convert it to my default working space. This is neither tiresome nor annoying. If I did find it tiresome, I could just turn that off and have it use a default profile (like sRGB) for the source file when none is detected. As far as I'm concerned, this is just part of having proper color management in my workflow.
I appreciate your situation of needing to correct the profile here, OTOH, have you considered using tools like imagemagick and jpegicc to detect the camera it came from and then attach an appropriate profile. this would allow you to assign profiles automatically in large batches. IMO this is much less painful all around.
That would add a bunch more steps to my workflow, and it would only work on this computer. I frequently have to work on other people's computers with files straight from the camera (and other people's cameras), and Gimp is the only cross-platform tool I have that does what I need.
BTW, I just checked the exif information on those JPEGs and both have no EXIF information. So it does look indeed like the profile data is stored in some custom format; there may even be no profile per se stored, just a reference to or description of one.
Sorry, those were links to the version of the pictures as displayed by Picasa, which has the metadata stripped. The direct download links are as follows:
Adobe RGB:
http://lh6.ggpht.com/_HAZjMzZWrtc/S05qkb7KkYI/AAAAAAAABCw/oPJ80XXYH-Y/d/_GOR3359.JPG
sRGB: http://lh3.ggpht.com/_HAZjMzZWrtc/S05qk1yxBOI/AAAAAAAABC0/5kXGfiIIF7s/d/GORE3360.JPG
There's a LOT of metadata, Pentax fills in more metadata than I thought existed.
On Thu, Jan 14, 2010 at 2:56 PM, Milan Knížek wrote:
How about the filenames? AdobeRGB image starts with "_" (underscore).
Yes, the link to the Adobe RGB file I posted is named _GOR3359.JPG and the sRGB one is named GORE3360.JPG
As I stated in my original post, the sRGB image has the EXIF tag "Color space" set as "sRGB". The Adobe RGB picture has that same EXIF tag set as "Uncalibrated". That's how it comes right out of the camera. Changing it to "Adobe RGB" does not change anything. Gimp still doesn't detect the color space properly and still assumes it's sRGB.
Color Management Woes
Frank Gore wrote:
Sorry, those were links to the version of the pictures as displayed by Picasa, which has the metadata stripped. The direct download links are as follows:
Adobe RGB:
http://lh6.ggpht.com/_HAZjMzZWrtc/S05qkb7KkYI/AAAAAAAABCw/oPJ80XXYH-Y/d/_GOR3359.JPGsRGB: http://lh3.ggpht.com/_HAZjMzZWrtc/S05qk1yxBOI/AAAAAAAABC0/5kXGfiIIF7s/d/GORE3360.JPG
There's a LOT of metadata, Pentax fills in more metadata than I thought existed.
When I open the Adobe RGB image in GIMP 2.6.7 on Ubuntu 9.10 Linux (64-bit), the EXIF browser shows the ColorSpace as:
Internal error (unknown value 65535)
Peace...
Tom
Color Management Woes
Frank Gore píše v ?t 14. 01. 2010 v 21:35 -0500:
Sorry, those were links to the version of the pictures as displayed by Picasa, which has the metadata stripped. The direct download links are as follows:
I thought your camera would be very unusual to provide JPEGs w/o metadata...
Adobe RGB:
http://lh6.ggpht.com/_HAZjMzZWrtc/S05qkb7KkYI/AAAAAAAABCw/oPJ80XXYH-Y/d/_GOR3359.JPG
$ exiftool -a -G -H _GOR3359.JPG | grep Color [File] - Color Components : 3 [EXIF] 0xa001 Color Space : Uncalibrated [MakerNotes] 0x0037 Color Space : Adobe RGB
$ exiv2 -pa _GOR3359.JPG | grep Color Exif.Pentax.ColorSpace Short 1 Adobe RGB Exif.Pentax.ColorTemperature Short 1 0 Exif.Pentax.ColorInfo Undefined 18 32 131 31 100 31 125 32 156 33 72 32 246 31 51 31 10 0 0 Exif.Photo.ColorSpace Short 1 Uncalibrated
As I stated in my original post, the sRGB image has the EXIF tag "Color space" set as "sRGB". The Adobe RGB picture has that same EXIF tag set as "Uncalibrated". That's how it comes right out of the camera. Changing it to "Adobe RGB" does not change anything. Gimp still doesn't detect the color space properly and still assumes it's sRGB.
Here you talk about Exif.ColourSpace. The info above is included in the blob of nonstandard metadata of Pentax... They do in on purpose, since the standard for Exif does not allow AdobeRGB:
"While the EXIF header in your images does have a field called "color space", use of this data is very limited because the only two values allowed in the EXIF color space field are (1) sRGB and (2) unspecified."
Anyway, it would be good if graphics programs try to identify also the known maker notes to find out the colour space.
Regards,
Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only)
Color Management Woes
Frank Gore píše v St 13. 01. 2010 v 18:20 -0500:
In any case, like I mentioned in my original post, I specifically have it set to "Ask what to do" in the Preferences, and it doesn't ask.
I agree with you, it is definitely a bug. GIMP should not assume that JPEG is in sRGB colour space when exif header says "Uncalibrated".
regards,
Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only)
Color Management Woes
Frank Gore píše v Pá 15. 01. 2010 v 17:12 -0500:
But this begs the question, what does Gimp use to determine the embedded color profile? The EXIF data, or something else? Because even if I change that tag from "Uncalibrated" to "Adobe RGB", it still doesn't change how Gimp treats it.
Again, you are mixing two different things:
embedded profile means that there is an actual binary data inside of JPEG. This can be extracted to a profile.icc if needed.
Color Space tag (either standard exif or some proprietary maker note) just says that the image data is in some standard colour space (sRGB, AdobeRGB), but the profile itself is not embedded and the program must supply it on its own.
Use of tags instead of embedding profile is an advantage: the image file is a bit smaller.
I would assume that GIMP does not care about tags, just looks for any embedded profile. But the developers would have to confirm it.
regards,
Milan Knizek knizek (dot) confy (at) volny (dot) cz http://www.milan-knizek.net - About linux and photography (Czech language only)
Color Management Woes
On Sat, Jan 16, 2010 at 3:32 AM, Milan Knížek wrote:
I would assume that GIMP does not care about tags, just looks for any embedded profile. But the developers would have to confirm it.
Upon further research, I just noticed there are two major versions of the ICC specification, 2.x and 4.x. Does Gimp support both? Does it support the latest? (4.2)
Color Management Woes
On 1/16/10, Frank Gore wrote:
Upon further research, I just noticed there are two major versions of the ICC specification, 2.x and 4.x. Does Gimp support both? Does it support the latest? (4.2)
Upon even further research you would find out that GIMP doesn't care about that, because this is what GIMP uses LittleCMS library for :) Which coincidentally supports both 2.x and 4.x. Not 4.2, perhaps, but chances that anyone has v4.2 profiles around are floating around 0.
Alexandre
Color Management Woes
So I moved upstream and asked about this on the LittleCMS mailing list. From what the users and devs there were able to figure out, there is no ICC profile embedded in my camera's JPG and TIF files. In fact, DSLR cameras do not embed an ICC profile at all. The Digital Camera File system (DCF) specification explicitly states that color profile information should be specified as part of the EXIF metadata. There's a whole series of tags in a digital camera's file which defines which colorspace should be used to interpret it. It's not just "ColorSpace", but others as well all taken together.
So again, this goes back to the application level, and not the color management library. If the application (in this case Gimp) was properly DCF-aware, then it would detect the proper color profile that's specified in the image file.
So... is this the right mailing list for this discussion, or do I need to subscribe to the Dev mailing list?
Here are the relevant emails from the LittleCMS mailing list.
On Sun, Jan 17, 2010 at 7:32 AM, Larry Reeve wrote:
The first image is in "DCF Colorspace". This can be seen from the following entries in the EXIF:
Color Space: Uncalibrated WhitePoint X: 0.31
WhitePoint Y: 0.33
Chromaticity Red(X): 0.64
Chromaticity Red(Y): 0.33
Chromaticity Green(X): 0.21
Chromaticity Green(Y): 0.71
Chromaticity Blue(X): 0.15
Chromaticity Blue(Y): 0.06
YCbCrCoefficient 1: 0.30
YCbCrCoefficient 2: 0.59
YCbCrCoefficient 3: 0.11A DCF aware application sees this information and processes the image accordingly (which means use an Adobe RGB profile).
On Sun, Jan 17, 2010 at 5:03 PM, Larry Reeve wrote:
LCMS does not have anything to do with the color space defined in the EXIF block of a JPEG file. There is no embedded profile. It is up to the application using LCMS to evaluate the color space definitions in the EXIF and take the action to load and use an Adobe RGB profile if it is needed. The DCF Optional Color Space (see paragraph 6.2 of of JEITA CP-3461 "Design rule for Camera File system DCF Version 2.0") defines the values that should alert an application to take this action:
Color Space: Uncalibrated WhitePoint X: 0.31
WhitePoint Y: 0.33
Chromaticity Red(X): 0.64
Chromaticity Red(Y): 0.33
Chromaticity Green(X): 0.21
Chromaticity Green(Y): 0.71
Chromaticity Blue(X): 0.15
Chromaticity Blue(Y): 0.06
YCbCrCoefficient 1: 0.30
YCbCrCoefficient 2: 0.59
YCbCrCoefficient 3: 0.11
Color Management Woes
HAH! All of this has been a long-standing bug:
