Wiliam wrote:

what I'm seeing is that when a display profile has the r/g/bTRC "curv" tag encoded as a "simple gamma" value rather than an array of points (typically 256), then there can be a big luminance discontinuity between level RGB=0 and RGB=1

and

...

Anyone at Apple aware of this?

I*?ll ask around.

...

After the update I cannot trust what I am seeing on my iMac 27? 5K. Color and contrast are washed out,

Sounds like the profile and/or LUT associated with the display changed after the update, maybe reverted to the factory profile (the one created at login). Open System Prefs - Displays and reselect the profile you?d chosen before, even if it?s already selected in the list. If the display appearance changes, that?s what happened.

(John Gnaegy: that’s not it; it’s not an issue with display profiles or LUTs changing or reverting - please see below) ******* There’s definitely something wrong here in 10.14.6, and you don’t even need to use a display profile to see it. Set the display profile to Adobe RGB. It uses the TRC tags with the “curv” type and simple gamma value. It also doesn’t have any calibration LUTs, which essentially turns off all LUT calibration and linearizes the contents of the video card. When you do this, use a 256 grayscale image with evenly spaced steps in Preview. What you’ll see is a large discontinuity between the first step (RGB 0,0,0) and everything that follows (much lighter). Here’s a very exact description of the problem. I have an image with 256 gray boxes, starting at 0,0,0 all the way to 255,255,255. On a properly functioning MacOS, with Adobe RGB set as the display profile, opening the image with Preview, and using Digital Color Meter to examine each box’s RGB value (set it to Native), each RGB patch measurement corresponds to the image’s digital value. In OSX 10.14.6, this is what I get instead: Box: RGB: 0 0,0,0 (correct) 1 14,14,14 (….wrong….should be 1,1,1) !!! 2 16,16,16 (……wrong…should be 2,2,2) !!! 3..89 Varying degrees of (wrong). Wrongness diminishes proportionately approaching box 90. 90..254 90,90,90 up through 255,255,255 (all correct) So there’s the problem. Starting with RGB 1,1,1 and up through 89,89,89, something is going wrong in 10.14.6 and pulling all of the shadows UP. The biggest discontinuity is going from box 0 to box 1, and the error gradually decreases per box step, until you eventually reach box 90, at which point everything is fine, the rest of the way. This is easily provable using the image and setup described above. (could also easily be proven in any image editing application for specific RGB gray values without even constructing an image) It looks to me as if there are other secondary effects from this issue; I’ll have to spend more time testing this. For instance, what we’re seeing this happening with is essentially the -uncalibrated state- of the display, with color management turned off (a side effect of using Adobe RGB as the display profile, with no calibration luts). If display calibration software, which puts native RGB values up on the screen with calibration disabled, instead gets colors that are artificially lighter in the shadows with the largest error being immediately above pure black), it’s going to compensate by using the calibration luts in the final display profile to pull down the shadows to compensate. This is what I think I’m seeing, after having run some preliminary tests. Assuming this “proves out”, it means that display calibration software can still, to a certain extent, make up for this problem by compensating in the eventual calibration luts that go into the profile. However, this is artificially compensating for the uncalibrated display response being “wrong”, and will result in the shadows being unnecessarily compressed. (And even then, I’m not seeing a completely smooth progression using a display profile; there’s still a “bump” going from box 0 to the boxes which follow). David Miller Manager/Lead Developer, Consumer Graphics Datacolor