Quartz wrote: >> This >> caused some smaller (matrix / shaper?) profiles to map saturated blues >> to more purple tints on the screen. Hi, to be technically correct, matrix profiles don't do any gamut mapping, and any clipping is done by the CMM and is likely to be simplistic, per component clipping. > So I've been doing more research on this. I notice that dispcalGUI has the > following > option: "Normally, profiles created by dispcalGUI only incorporate the > colorimetric > rendering intent, which means colors outside the display's gamut will be > clipped to the > next in-gamut color. Note that cLUT type profiles will at least clip to the perceptually closest in-gamut color. > LUT-type profiles can also have gamut mapping by implementing > perceptual and/or saturation rendering intents." (I'm not exactly sure what > this is doing > under the hood, or what options dispcalGUI is passing to argyll). It will be passing the -s or -S option to colprof. Note that some displays have primaries that lie outside the ICC L*a*b* range, so an XYZ based cLUT profile is required if mapping or clipping is to operate correctly. > The blue primary on my MacBook Pro display lies outside sRGB as best I can > tell (it's kind > of off to the side, but I'm not exactly sure how to read these graphs yet so > I'm not sure > if saying it's 'purple' is necessarily correct). Two explanations have been suggested to me for "blue goes purple" type problems. One is the use of "wrong Von-Kries" chromatic adaptation in adapting white points between D65 and D50. The other is gamut mapping or clipping in L*a*b* space, since perceptually constant hue lines have quite a curve on them near blue. > Would using a large LUT profile and enabling perceptual intent possibly solve > or help > address my blue-turns-purple issue? It may, but be warned than some systems/programs expect display profiles to be matrix based, and choke on cLUT profiles. Graeme Gill.