663212 - Color management treats some valid ICC profiles as "bogus"

Status: NEW

(Core :: Graphics: Color Management, defect)

Description

[Patrik Floding]

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0.2pre) Gecko/20110607 Firefox/4.0.2pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.2pre) Gecko/20110607 Firefox/4.0.2pre

I tracked down what I think may be a bug in gfx/qcms/iccread.c where the ICC profile sanity checker qcms_profile_is_bogus() decides that a valid profile is invalid. The check stumbles on the part where tolerances are checked.

As a result the profile is discarded and a generic built in sRGB profile is used by Firefox. The same Argyll genrated ICC profile works fine with other color managed applications, both on the Windows 7 and OSX platforms.

The profile in question was generated using Argyll 1.3.3.
The qcms_profile_is_bogus() function seems to have come about due to bug report 450923, but may not be doing the correct calculations when trying to verify the ICC profile.

Chris Murphy gave some initial advice for the bogus check function, and pointed to a possible reason for this issue:

"I'm going to guess that the bogus profile check is only checking the XYZs of the RGB tags, and not computing actual XYZ of the RGB's based on both the matrix as well as the TRC."

The author of Argyll, Graeme Gill, emailed the following information:

"As far as I can tell, the Argyll profile is perfectly valid according
to the ICC V2 specification. The XYZ values and the curves combine
to form a model of the device behavior, and for device white in (1,1,1),
the output is the PCS D50 white within tight tolerances (< 0.02 delta E).

There is no constraint that the curves have to map 0 to 0 or 1 to 1.

The ICC spec. is somewhat archaic and misleading in referring to the matrix
components as "colorant tristimulus values". This is evident in particular for
the case of the input matrix profiles, since input devices simply don't
have colorants. Way back when it was probably not so practical
to optimize all of the model parameters together, and the assumption
that it would have to be built a separate linearization and colorant
measurements crept into the terminology and tag arrangement (matrix models
were the first and only ones in ColorSync 1.0), but the display matrix profile
description is clear that the colorant and TRC tags are there to form
the mathematical shaper + matrix model.

A profile which characterized the phosphor values and the curve values
independently would give a worse result in general than one that optimizes
the whole model for the best fit. But doing so means that the xxxColorantTag
values do not accurately represent the colorant chromaticities.

The bottom line is that the correct thing to do to check what the
device model maps white to, is to feed device white into the whole
device model, not just part of it! "

"It should simply be changes [changed] to lookup the value through the whole model."
----

I do not know how difficult it would be to rewrite the "bogus checker" to work correctly, but if it is a substantial task I would suggest that it would be better not to discard any profiles based on tolerances, and instead make it much easier for users to turn on and off color management (see Picasa's easily accessible "Color management" menu choice), for cases similar to the one that led to the introduction of the "bogus checker".

Reproducible: Always

Steps to Reproduce:
1.Install the specific ICC/ICM that FF doesn't like.
2.Specify that FF use it as its color profile.
3.Verify that FF ignores it (easiest done in the debugger)

Actual Results:  
Color management doesn't work

Expected Results:  
Color management should work

I will make accessible the Argyll profile that triggers this bug.

Comment 1

[Patrik Floding]

Attachment: An example, presumably correct, profile that Firefox rejects

Comment 2

[Chris Murphy]

Basically all that the bogus profile check should do is pass RGB 1.0, 1.0, 1.0 through the CMS with this display profile, to L*a*b*. The result should be 100, 0, 0. There is a tolerance built in, but I'm not sure how it's computed. The tolerance can be done with ∆Eab with the Lab(1) values being 100,0,0 and the Lab(2) values being the result from passing 1,1,1 through the display profile (asking qcms or lcms to convert those RGB values to L*a*b*) and then applying the difference equation. If the number is 3 or larger, fail the profile. If the number is less than 3, pass it. This is a pretty wide yet reasonable tolerance, but another tolerance could be suggested.

I *think* that what must be going on is the current check is looking directly at the display profile rXYZ, gXYZ, bXYZ tags themselves. Rather than the actual XYZ of the primaries (which includes the TRC).

Comment 3

[Benoit Girard (:BenWa)]

Thanks for the detailed report. The assessment is accurate, just adding the qcms specific values.

The failure occurs here:
http://mxr.mozilla.org/mozilla-central/source/gfx/qcms/iccread.c#267

sum_X = 0.988037109
rTRC maps 1 to ~0.98
Giving a value close to 0.96 (sum_X*rTRC), within the tolerance anyways.

Comment 4

[Chris Murphy]

Well I think the way to handle this is to not test individual parts of the profile, but rather than net effect of the transform that's defined by the profile. The CMS's job is to do conversions. So just have it convert Display RGB 1, 1, 1 into L*a*b* and compare that with 100, 0, 0 using ∆E.

While it doesn't seem like a good idea to have a TRC that starts at 0.5, it does not appear to be invalid. Therefore the only real way to ascertain if the profile is actual bogus or not is to take its defined transform as a whole, not separate pieces.

Comment 5

[Joosa Riekkinen]

Attachment: Another "bogus" profile created with Argyll

I profile my display with dispcalGUI/Argyll. The profiles work fine in other programs such as Photoshop, so I'm assuming they are not "bogus". Firefox won't load and use them. I attached one.

Comment 6

[Anton Katsarov]

I have the same issue. dispcalGUI/Argyll. For other profiles it works but not for the right one.

Comment 7

[Anton Katsarov]

Attachment: HP LP2475w 2014-02-03 D6500 2.2 F-S 3xCurve+MTX.icc