I just got a new monitor and I've been profiling it using ArgyllCMS. From the measured test patches I made 3 kinds of profiles: 1) A LUT profile with dummy matrices (this is the quickest to make, and gives the highest quality, but programs that don't support LUT profiles will look completely wrong) 2) A matrix profile (just for the error measures, to see how well just a matrix can correct the colors) 3) A 'full' LUT+matrix profile (so I can apply the profile system-wide and have it work with Windows Photo Viewer) After applying the full profile I noticed that colors in Firefox look completely wrong. It's as though it's applying the matrix *and* the LUT on top of each other. I checked in GIMP, and the LUT and full profiles look identical. The matrix profile looks subtly different, but still a step up from no profile at all. I checked using screenshots that the matrix and LUT profiles *do* work. They both look different from not using a profile at all. It's just the full profile that looks exaggerated. I have the following preferences set in about:config: gfx.color_management.enablev4 = true gfx.color_management.mode = 1 and I used gfx.color_management.display_profile to quickly switch between profiles for testing (though it requires a restart of the browser to take effect). In addition, according to about:support I'm getting full Direct3D 11 + Direct2D 1.1 hardware acceleration.
The attached profiles are what I'm testing with. I'm currently using the Matrix+LUT profile system-wide, but overriding Firefox to use the LUT profile using gfx.color_management.display_profile. Incidentally, the reason I never noticed this before is that with my old monitor, using a matrix profile at all was out of the question - only a LUT could tame it. So this may well have been broken for a long time.
Milan, your name shows up in the hg history around color profile related stuff, any idea?
We're not really supporting ICC v4 (e.g., bug 488800), but if this is a recent regression, perhaps there is something we can do to quickly fix it - Emanuel, has this worked for you before? If it has, any chance of running mozregression to let us know when it stopped?
I don't think this is a recent regression - I remember finding the colors in Firefox odd at various points in the past, but never looked into it. More recently, I've always used a profile with only the LUT, since the matrix takes so long to generate, and matrix profiles were always too badly wrong for my old monitor to be of any use.
Benoit, does this sound like being covered by things we know we haven't gotten to, or is it something you'd expect to work? If former, it'd have to wait for us to properly implement things.
FWIW, my interpretation could be wrong, but it looks to me like the *components* are there - the matrix and LUT profiles both work correctly. It's just that the matrix in a matrix+LUT profile should be ignored.
It could be a spec interpretation issue or a simple bug in the control flow when picking transforms. Your profile has an A2B0 (lutAtoB type) which as I understand it should take precedence over the TRC tags. The A2B0 tag has matrix which we should use but it's an identity matrix in any case so probably not what you're taking about anyways. I checked the spec and it does appear to say that A2B0's matrix should be applied before the LUT. When you say 'matrix' do you mean the tone response curves TRC which are models as tables in profiles? If so then if they are stacked it is a bug and should be easy to fix.
Looking at the spec it does refer to TRC as 'matrix tone reproduction curve (TRC)'. I just want to confirm this point before I investigate further.
I'm not really too savvy on the actual terms; the ArgyllCMS documentation refers to a matrix profile (using -as) as a "shaper curve and matrix profile" and a LUT profile (using -ax) as a "cLUT based table profile" (with a profile connection space of XYZ). So from what I can tell, yes: the A2B0's matrix and LUT (though here the matrix is unused) should take precedence over the TRC shaper curves and matrix. But take that with a grain of salt, since all I did was compare what Firefox does to what the GIMP does :)
Er, meant to link the colprof documentation there too: http://argyllcms.com/doc/colprof.html#a (though it doesn't say much more than what I already said)
Doh, I was wrong about what caused the difference here. It wasn't the addition of a matrix, it was using an sRGB input profile rather than a BT.709 input profile. My sRGB profile may have been slightly nonstandard so I'm trying again with the standard one from ArgyllCMS.
Okay yeah, apparently something was badly wrong with my sRGB input profile. GIMP still treated it differently, but that might just be a limitation of GIMP.