450283 - Investigate way to detect bogus color profiles

Status: ASSIGNED

(Core :: Graphics: Color Management, defect)

Description

[Bobby Holley (:bholley)]

We've run into several cases (in bug 440940 and its duplicate) where people get weird display issues as the result of a bogus profile. Ideally, it would be nice if we could programmatically detect at least some bogus profiles and ignore them.

Comment 1

[Bobby Holley (:bholley)]

CCing chris murphy given his expertise.

Chris, any ideas on possible approaches for doing this?

Comment 2

[Chris Murphy]

Yes, but I don't know how practical it would be to do this. In my view the operating system should do this, because a bogus display profile will affect all applications. (I use operating system in the context of a full package, such as Mac OS X, or Windows.) Specifically this is something the display manager could do, possibly in concert with the color management system.

At first glance you might come up with an algorithm that says, OK here is the maximum standard deviation for the red primary, and the StdDev for the green, and StdDev for the blue, for all display technologies on the planet. That would require some data but not a ton of it because you're just looking for extremes for actual behavior. Anything reported by EDID or measured that is outside of this realm is then assumed to be wrong.

There are a number of flaws with this approach, with the increasingly divergent display technologies out there, it's possible to have a display containing bogus EDID data, resulting in a bogus display profile, but falls within the necessarily extreme parameters mentioned above. So you may only get a small percent of profiles that aren't describing actual display behavior.

What is used instead of the bogus profile? Well, probably disable display compensation entirely.

Another way to do this, would be building a database (which could be remote) for the unique ID of the display (manufacturer and model) and compare the current display profile with the expected primaries for that make/model. If it's way off, then flag the user (or disable the profile). At least here you're comparing the current display profile to the expected behavior of its own make/model rather than all display technologies.

Again, not sure how practical any of this is. But there is a real problem with EDID data containing incorrect display behavior information. And there is also a problem with LED based displays having custom display profiles with incorrect primaries reported by the measuring device (colorimeters) since they're not designed with that spectra in mind.

Comment 3

[Glenn Randers-Pehrson]

In bug #450923 a Vista user apparently has nothing in the gfx.color_management.display_profile string and has gfx.color_management.mode=1 (which was formerly "enabled=true"), and gets yellow in areas that should be white.  It should be easy enough to detect an empty profile and reject it.

Comment 4

[Bobby Holley (:bholley)]

Glenn - If the display profile string is empty, thebes queries the OS in various platform specific ways to read the system ICC profile (if that fails, it uses sRGB). As such I'm guessing that the user is seeing problems related to a problematic system profile, which is harder to detect.

Comment 5

[Bobby Holley (:bholley)]

Hrm - doesn't look like anything we'll be able to do in the short term. Removing as blocking turning CMS on.

Comment 6

[Bobby Holley (:bholley)]

Given all the crappiness we see with the LG profiles, this is becoming more and more of an issue.

Chris - The problem we're seeing time and time again has to do with whites being distinctly yellow. Could we detect this by looking at the white point? Alternatively, one thing we could do would just be to try transforming white and ignore the profile if it transforms it past a certain threshold away from 0xffffff. Given that Most monitors end up displaying at least _some_ uncorrected RGB pixels, presumably white should be pretty close to that value.

One last nuclear option would just be to assume sRGB as the output on every display. This punts on a lot of the color management stuff, but we've already done a lot of that by going tagged images only. This way, at least images will be converted to sRGB out of their native color space so flickr stuff should look right.

Comment 7

[Chris Murphy]

(In reply to comment #6)
> Given all the crappiness we see with the LG profiles, this is becoming more and
> more of an issue.

Can you forward one to me offlist?

> Chris - The problem we're seeing time and time again has to do with whites
> being distinctly yellow. Could we detect this by looking at the white point?
> Alternatively, one thing we could do would just be to try transforming white
> and ignore the profile if it transforms it past a certain threshold away from
> 0xffffff. Given that Most monitors end up displaying at least _some_
> uncorrected RGB pixels, presumably white should be pretty close to that value.

White as in content having an equivalent 8bpc value of 255,255,255, and yet it displays on-screen with RGB values other than 255,255,255?

As long as perceptual or (media)-relative colorimetric rendering is being used, the white point should not be compensated for. So white should be unmodified by the CMS.

It's possible there is a malformed profile? I need to see examples of these profiles. Adobe apps (Photoshop at least) parses display profiles and can refuse to use them, if sufficiently malformed, and informed the user with a dialog stating as such.

> One last nuclear option would just be to assume sRGB as the output on every
> display. This punts on a lot of the color management stuff, but we've already
> done a lot of that by going tagged images only. This way, at least images will
> be converted to sRGB out of their native color space so flickr stuff should
> look right.

It does actually punt on display compensation, that is true. What it does do is normalize all content to the same color space, as untagged is assumed to be sRGB also. Of course we know displays are increasingly not described by sRGB. I think this is a very minor improvement to managing color in the web browser, but possibly it's a good stepping point in terms of collecting more data and determining what the next steps are.

On the other hand, it is a kind of heresy to go to the trouble of color management objects explicitly tagged as device-independent and then intentionally and knowingly incorrectly converting them. :-D

But at least you'd have platform parity, since all Mac OS machines use non-sRGB color space for the Display profile, and all Windows machines are using sRGB as their default Display profile. So the conversions on Windows are overwhelmingly already sRGB as destination now; saying the destination profile is sRGB instead of whatever Mac OS comes up with as the display profile would in effect do the same thing.

Chris Murphy

Comment 8

[Bobby Holley (:bholley)]

Chris - see bug 450923 for the people complaining about white becoming yellow.

Are you saying that if 255,255,255 is transformed to anything but itself (maybe allowing a small threshold to account for floating point weirdness), it means we definitively have a bogus profile? If so, this would be a superb way we could check for and eliminate a lot of the problems we're seeing from users.

Comment 9

[Chris Murphy]

Unclear. It could be a problem with the display profile or a bug in the CMM. It appears unlikely that it's a problem with the hard-wired sRGB profile being used to assume untagged objects, as bug 450923 reports the problem with mode 2 which would not assume sRGB, but only use an explicitly embedded profile as source.

I'm hard pressed to consider how a destination profile (the display profile) could report a white point so blue that the CMS would determine it must make the display so yellow, without any other apparent consequence to the image. I think we're looking for a CMM bug, but that's speculation at this point.

Comment 10

[Chris Murphy]

I definitely need to see one of these display profiles. I wonder if maybe somehow they have a malformed PCS Illuminant value, which is found in the ICC profile header. This should always be D50: 0.96420, 1, 0.82491. If it's not, CMMs can freak out. I'm not clear on why CMMs don't just assume the value is D50, and instead read it and then perform different math, which *might* cause this to occur. If the offending profiles have a bogus PCS illuminant, it could easily explain this - i.e. if the display profile reports the PCS illuminant is D65 for example.

Comment 11

[Török Edwin]

I am seeing bug #490537, and here is what firefox thinks my ICC profile is:
lcms: Error #12288; Read from memory error. Got 0 bytes, block should be of 128 bytes
lcms: Error #12288; Corrupted memory profile
EDID gamma: 2.030000
EDID whitepoint: 0.435547 0.390625 1.000000
EDID primaries: [0.395508 0.448242 1.000000] [0.395508 0.390625 1.000000] [0.125977 0.302734 1.000000]
ICM profile read from XFree86_DDC_EDID1_RAWDATA successfully

If I explicitly set a display_profile, then all the colors are fine, but if I let it fallback to EDID then its all wrong. This happens both in firefox 3.5, and firefox 3.0.12, the above printfs are from 3.0.12 with #define DEBUG_tor 1.

Here's the EDID data from xprop, its a Samsung T220 monitor:
XFree86_DDC_EDID1_RAWDATA(INTEGER) = 0, 0, 0, 0, 0, 0, 0, 0, 58, 32, 80, 114, 105, 110, 116, 105, 110, 103, 32, 68, 68, 67, 32, 103, 97, 116, 104, 101, 114, 101, 100, 32, 77, 111, 100, 101, 108, 105, 110, 101, 115, 58, 10, 0, 113, 79, 1, 1, 1, 1, 1, 1, 1, 1, 124, 46, -47, 0, 0, 0, 0, 0, 0, 0, 48, 20, -98, 2, 0, 0, 0, 0, 32, -127, -91, 2, 0, 0, 0, 0, 0, -127, -91, 2, 0, 0, 0, 0, 0, 0, 0, 0, 72, 0, 0, 0, -40, -48, 1, 0, -112, 6, 0, 0, -64, 6, 0, 0, -32, 6, 0, 0, 48, 7, 0, 0, 0, 0, 0, 0, 26, 4, 0, 0, 29, 4, 0, 0

Is the ICC profile generated from the EDID correct?
It would be useful to have a way to dump the ICC profile used by firefox.

Not sure if relevant here, but for #490537 I have an image that has D65 whitepoint in the image's profile (not the display's), and its colors are shown wrong.

This is what gimp shows:
"sRGB IEC61966-2.1
Copyright (c) 1998 Hewlett-Packard Company
WhitePoint : D65 (daylight)
"

gimp also says:
lcms: skipping conversion because profiles seem to be equal:
 sRGB IEC61966-2.1
 sRGB built-in

And this is what iccgamut says:
iccgamut -vb -w out.icc
Header:
  size         = 3144 bytes
  CMM          = 'Lino'
  Version      = 2.1.0
  Device Class = Display
  Color Space  = RGB
  Conn. Space  = XYZ
  Date, Time   = 9 Feb 1998, 6:49:00
  Platform     = Microsoft
  Flags        = Not Embedded Profile, Use anywhere
  Dev. Mnfctr. = 'IEC '
  Dev. Model   = 'sRGB'
  Dev. Attrbts = Reflective, Glossy
  Rndrng Intnt = Relative Colorimetric
  Illuminant   = 0.964203, 1.000000, 0.824905    [Lab 100.000000, 0.000498, -0.000436]
  Creator      = 'HP  '

Which is almost exactly the same as /usr/share/doc/xicc/examples/sRGB.icm, except the intent is not Perceptual.

Comment 12

[Török Edwin]

(In reply to comment #11)
> XFree86_DDC_EDID1_RAWDATA(INTEGER) = 0, 0, 0, 0, 0, 0, 0, 0, 58, 32, 80, 114,
> 105, 110, 116, 105, 110, 103, 32, 68, 68, 67, 32, 103, 97, 116, 104, 101, 114,
> 101, 100, 32, 77, 111, 100, 101, 108, 105, 110, 101, 115, 58, 10, 0, 113, 79,
> 1, 1, 1, 1, 1, 1, 1, 1, 124, 46, -47, 0, 0, 0, 0, 0, 0, 0, 48, 20, -98, 2, 0,
> 0, 0, 0, 32, -127, -91, 2, 0, 0, 0, 0, 0, -127, -91, 2, 0, 0, 0, 0, 0, 0, 0, 0,
> 72, 0, 0, 0, -40, -48, 1, 0, -112, 6, 0, 0, -64, 6, 0, 0, -32, 6, 0, 0, 48, 7,
> 0, 0, 0, 0, 0, 0, 26, 4, 0, 0, 29, 4, 0, 0

This EDID data looks completely bogus, parse-edid says the checksum is wrong too, maybe firefox could check the EDID checksum before using it?

Comment 13

[Bobby Holley (:bholley)]

Reassigning to jeff to do what he wants with it.