Possible ColorSync discontinuity bug introduced in OS 10.14.6 with display "r/g/bTRC" tags?
I'm starting to get reports of a severe banding problem that seems to be related to the recent macOS 10.14.6 update which includes some (unknown) changes to ColorSync. I've duplicated this and 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 - depending on the gamma value. I'm using a simple grayscale test image in the Preview app. The canned "Adobe RGB (1998)" profile encodes the 2.2 gamma as a "simple gamma" and this issue is evident when selected as a display profile. However the "Generic RGB Profile" encodes gamma 1.8 this way also but the discontinuity isn't very obvious. So higher gamma values make this more obvious. Re-encoding the profile's response curve as an array of points instead of a single "simple gamma" value seems to avoid the issue. However it was perfectly OK in previous macOS versions. Is anyone else experiencing this issue? It looks like X-Rite encode their TRCs as an array of points regardless, so probably most people won't see it. Anyone at Apple aware of this? Thanks Will Hollingworth
Coming back from holidays, all was well when comparing my iMac to the new BenQ SW270C. Until the auto update which occurred during the night. After the update I cannot trust what I am seeing on my iMac 27” 5K. Color and contrast are washed out, even the icons in the dock are not as before. Glad you pointed out where this is happening. Not sure there is an easy fix, as I am now chasing around with all monitors to get a color match even close. On 13 Aug 2019, at 05:21, William Hollingworth via colorsync-users <colorsync-users@lists.apple.com> wrote: I'm starting to get reports of a severe banding problem that seems to be related to the recent macOS 10.14.6 update which includes some (unknown) changes to ColorSync. I've duplicated this and 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 - depending on the gamma value. I'm using a simple grayscale test image in the Preview app. The canned "Adobe RGB (1998)" profile encodes the 2.2 gamma as a "simple gamma" and this issue is evident when selected as a display profile. However the "Generic RGB Profile" encodes gamma 1.8 this way also but the discontinuity isn't very obvious. So higher gamma values make this more obvious. Re-encoding the profile's response curve as an array of points instead of a single "simple gamma" value seems to avoid the issue. However it was perfectly OK in previous macOS versions. Is anyone else experiencing this issue? It looks like X-Rite encode their TRCs as an array of points regardless, so probably most people won't see it. Anyone at Apple aware of this? Thanks Will Hollingworth Neil Snape
Neil 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 Why not try basICColor display, it makes a 16 bit LUT profile which should work around the issue Apple seem to have with profile, where the profile's response curve is "simple gamma" *basICColor display 5, download demo:* MAC: http://mylicense.biz/getProduct.asp?proId=180&downloadKey=w8hz-pe6q-2n2s WIN: http://mylicense.biz/getProduct.asp?proId=181&downloadKey=uxr7-3m2p-bzx3 [full disclosure, yes I am a basICColor reseller] Best Regards, Neil Barstow Imaging & Colour Management Specialist http://www.colourmanagement.net proud to be part of: http://www.colormanagementgroup.com www.colormanagement.com On Tue, Aug 13, 2019 at 1:02 PM Neil Snape via colorsync-users < colorsync-users@lists.apple.com> wrote:
Coming back from holidays, all was well when comparing my iMac to the new BenQ SW270C. Until the auto update which occurred during the night. After the update I cannot trust what I am seeing on my iMac 27” 5K. Color and contrast are washed out, even the icons in the dock are not as before. Glad you pointed out where this is happening. Not sure there is an easy fix, as I am now chasing around with all monitors to get a color match even close.
On 13 Aug 2019, at 05:21, William Hollingworth via colorsync-users < colorsync-users@lists.apple.com> wrote:
I'm starting to get reports of a severe banding problem that seems to be related to the recent macOS 10.14.6 update which includes some (unknown) changes to ColorSync.
I've duplicated this and 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 - depending on the gamma value. I'm using a simple grayscale test image in the Preview app.
The canned "Adobe RGB (1998)" profile encodes the 2.2 gamma as a "simple gamma" and this issue is evident when selected as a display profile. However the "Generic RGB Profile" encodes gamma 1.8 this way also but the discontinuity isn't very obvious. So higher gamma values make this more obvious.
Re-encoding the profile's response curve as an array of points instead of a single "simple gamma" value seems to avoid the issue. However it was perfectly OK in previous macOS versions.
Is anyone else experiencing this issue? It looks like X-Rite encode their TRCs as an array of points regardless, so probably most people won't see it.
Anyone at Apple aware of this?
Thanks
Will Hollingworth
Neil Snape _______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/colorsync-users/listservmail%40colou...
This email sent to listservmail@colourmanagement.net
Hi William, I hope you're keeping well So, am I reading this right please? An LUT profile would be OK and a "MATRIX" not, in this setting. Is an LUT what you are calling "encoded as - - an array of points" I guess a 16 bit LUT may be OK? I am just thinking about basICColor display. Are you able to communicate with Apple about it - now John Zimmerer's gone I've no idea who'd be in charge of Colorsync? I saw a post from Steve about his NEC on the Adobe forum [compressed blacks] and I think he may have been chatting with you about the issue? https://forums.adobe.com/thread/2645572?prevContainerType=14&prevContainerID... Best Regards, Neil Barstow Imaging & Colour Management Specialist http://www.colourmanagement.net proud to be part of: http://www.colormanagementgroup.com www.colormanagement.com On Tue, Aug 13, 2019 at 4:21 AM William Hollingworth via colorsync-users < colorsync-users@lists.apple.com> wrote:
I'm starting to get reports of a severe banding problem that seems to be related to the recent macOS 10.14.6 update which includes some (unknown) changes to ColorSync.
I've duplicated this and 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 - depending on the gamma value. I'm using a simple grayscale test image in the Preview app.
The canned "Adobe RGB (1998)" profile encodes the 2.2 gamma as a "simple gamma" and this issue is evident when selected as a display profile. However the "Generic RGB Profile" encodes gamma 1.8 this way also but the discontinuity isn't very obvious. So higher gamma values make this more obvious.
Re-encoding the profile's response curve as an array of points instead of a single "simple gamma" value seems to avoid the issue. However it was perfectly OK in previous macOS versions.
Is anyone else experiencing this issue? It looks like X-Rite encode their TRCs as an array of points regardless, so probably most people won't see it.
Anyone at Apple aware of this?
Thanks
Will Hollingworth
_______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/colorsync-users/listservmail%40colou...
This email sent to listservmail@colourmanagement.net
On 8/14/2019 11:57 AM, Neil Barstow wrote:
So, am I reading this right please?
An LUT profile would be OK and a "MATRIX" not, in this setting.
Is an LUT what you are calling "encoded as - - an array of points" I guess a 16 bit LUT may be OK? I am just thinking about basICColor display.
The rTRC. bTRC and gTRC tags in the display profile are "curv" types encoding the tone reproduction curve of each color. I believe LUT based display profiles must also include TRC tags, but maybe someone like Graeme Gill could step in and confirm. According to the ICC.1:2001-04 spec: ---------------------------------- 6.5.3 curveType- The curveType contains a 4-byte count value and a one-dimensional table of 2-byte values. The count value specifies the number of entries in the curve table except as follows: - when countis 0, then a linear response (slope equal to 1.0) is assumed, - when countis 1, then the data entry is interpreted as a simple gamma value encoded as a u8Fixed8Number. Gamma is interpreted canonically and notas an inverse. Otherwise, the 16-bit unsigned integers in the range 0 to 65535 linearly map to curve values in the interval[0.0, 1.0]. ---------------------------------- The problem occurs with the case of using a single value to represent a simple gamma value in the profile. In this case ColorSync seems to mess up curve generation. It looks like most software nowadays is encoding as an array of points - which is probably how this one slipped by Apple. I would have thought that especially canned profiles would use the simple gamma rather than an array of points. I'd be interested in knowing the reasoning for not doing this. Thanks Will
Would someone restate the problem being discussed I don't have access to the earlier posts Thanks On Wednesday, August 14, 2019, William Hollingworth via colorsync-users < colorsync-users@lists.apple.com> wrote:
On 8/14/2019 11:57 AM, Neil Barstow wrote:
So, am I reading this right please?
An LUT profile would be OK and a "MATRIX" not, in this setting.
Is an LUT what you are calling "encoded as - - an array of points" I guess a 16 bit LUT may be OK? I am just thinking about basICColor display.
The rTRC. bTRC and gTRC tags in the display profile are "curv" types encoding the tone reproduction curve of each color. I believe LUT based display profiles must also include TRC tags, but maybe someone like Graeme Gill could step in and confirm.
According to the ICC.1:2001-04 spec:
----------------------------------
6.5.3 curveType- The curveType contains a 4-byte count value and a one-dimensional table of 2-byte values.
The count value specifies the number of entries in the curve table except as follows:
- when countis 0, then a linear response (slope equal to 1.0) is assumed,
- when countis 1, then the data entry is interpreted as a simple gamma value encoded as a u8Fixed8Number. Gamma is interpreted canonically and notas an inverse.
Otherwise, the 16-bit unsigned integers in the range 0 to 65535 linearly map to curve values in the interval[0.0, 1.0].
----------------------------------
The problem occurs with the case of using a single value to represent a simple gamma value in the profile. In this case ColorSync seems to mess up curve generation. It looks like most software nowadays is encoding as an array of points - which is probably how this one slipped by Apple.
I would have thought that especially canned profiles would use the simple gamma rather than an array of points. I'd be interested in knowing the reasoning for not doing this.
Thanks
Will
_______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/ wire%40lexiphanicism.com
This email sent to wire@lexiphanicism.com
I am using 10.14.6 build 18G87 (latest) on a supported Macbook Pro and I am also seeing what Hollngworth originally reported: TEST PATTERNS USED http://www.lagom.nl/lcd-test/black.php http://www.lagom.nl/lcd-test/gradient.php http://www.lagom.nl/lcd-test/contrast.php When I set a basic RGB profile, like AdobeRGB, in Displays > Color, and look at the black patch pattern in Preview side by side with the same in Firefox, they differ. For example here is Firefox (68.0.1, gfx.color_management.mode=2) compared to Preview under Adobe RGB 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Firefox 0 9 9 9 9 9 9 9 10 10 10 10 10 11 11 11 Preview compared to Firefox This affects some profiles and not others, and the degree of rendering discontinuity varies depending on the profile. DIFFER IN PREVIEW VS FIREFOX AdobeRGB PALSECAM SMPTE-C CIERGB WideGamutRGB REC ITU-R BT.2020-1 DisplayCal custom profile for Macbook Pro built-in display DisplayCal custom profile for LG Ultrafine DO NOT DIFFER IN PREVIEW VS FIREFOX sRGB Display P3 Apple supplied Macbook Pro built-in display profile ColorMatchRGB AppleRGB REC ITU-R BT.709-6 LG Ultrafine (EDID) Quicklook appears to behave exactly the same as Preview. In Photoshop, there's a third interpretation! Under some profiles the rendering of Photoshop doesn't agree with either of the others, For example under REC ITU-R BT.709-6 none agree. But under sRGB and ColorMatchRGB all agree! I didn't check GraphicConverter. Nor did I look carefully at mid and high tones. The primaries stepwedge test pattern has discernible steps low to high in all. Primary color gamut rendering changes believably with change of display profile and overall curve is roughly appropriate, but certainly not accurate. (Because this MBP has a TN display I can see differences in the very lowest patches when viewing off-axis high that would be difficult to discern on an IPS display. Per a previous post—this is how I can see that ColorMatchRGB and AppleRGB are not affected in spite of the blacks being pulled down by the profile) Re banding, I see quantization error appropriate to this MPB display in very dark tones but it seems exaggerated. There are variations in lumpiness overall esp in the bottom quarter beyond this display's native lumpiness. The degree of banding/lumpiness depends on the profile chosen and tone range. By using Accessibility Zoom I can see some crazy looking color dithering at very bottom end under some profiles and not for others. HTH On Sun, Aug 18, 2019 at 12:28 PM Wire Moore <wire@lexiphanicism.com> wrote:
Would someone restate the problem being discussed I don't have access to the earlier posts
Thanks
On Wednesday, August 14, 2019, William Hollingworth via colorsync-users < colorsync-users@lists.apple.com> wrote:
On 8/14/2019 11:57 AM, Neil Barstow wrote:
So, am I reading this right please?
An LUT profile would be OK and a "MATRIX" not, in this setting.
Is an LUT what you are calling "encoded as - - an array of points" I guess a 16 bit LUT may be OK? I am just thinking about basICColor display.
The rTRC. bTRC and gTRC tags in the display profile are "curv" types encoding the tone reproduction curve of each color. I believe LUT based display profiles must also include TRC tags, but maybe someone like Graeme Gill could step in and confirm.
According to the ICC.1:2001-04 spec:
----------------------------------
6.5.3 curveType- The curveType contains a 4-byte count value and a one-dimensional table of 2-byte values.
The count value specifies the number of entries in the curve table except as follows:
- when countis 0, then a linear response (slope equal to 1.0) is assumed,
- when countis 1, then the data entry is interpreted as a simple gamma value encoded as a u8Fixed8Number. Gamma is interpreted canonically and notas an inverse.
Otherwise, the 16-bit unsigned integers in the range 0 to 65535 linearly map to curve values in the interval[0.0, 1.0].
----------------------------------
The problem occurs with the case of using a single value to represent a simple gamma value in the profile. In this case ColorSync seems to mess up curve generation. It looks like most software nowadays is encoding as an array of points - which is probably how this one slipped by Apple.
I would have thought that especially canned profiles would use the simple gamma rather than an array of points. I'd be interested in knowing the reasoning for not doing this.
Thanks
Will
_______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/colorsync-users/wire%40lexiphanicism...
This email sent to wire@lexiphanicism.com
When I set a basic RGB profile, like AdobeRGB, in Displays > Color,
That’s not technically a display profile, it’s a “Space” profile. There’s also no ‘vcgt’ tag in it (though not all display profiles have those). Don’t know if that’s relevant to this behavior or not, but it’s something to consider.
Re "not a display profile," yes I know. Maybe I misunderstand the original post? The issue at hand as I took it is that when you config a MacOS display with a minimal profile (e.g., working space) tonal rendering glitches in Preview (and maybe elsewhere inc Photos, and I recall seeing a complaint about Lightroom). I am interested in this for its own sake, but also because if it's true, it may be relevant to other known problems with certain display profiles. Particularly per the stackexchange article reference I posted here last week, about LUT display profiles made with DisplayCal. And also per this thread on Luminous Landscape: https://forum.luminous-landscape.com/index.php?topic=124542.0 What's confusing is that on the LL thread there's a post which seems to dismiss the whole concern:
"Has anyone tested this with another software product to confirm it's an Apple bug?" "I did. There's nothing's wrong with Argyll XYZ LUT profile (High Sierra 10.13.4)." The dialog continues with another user's expression of doubt "I'm not at all confident we know yet where the problem is." Someone else chimes in with "I don't use LUT profiles, so who cares." At end the reference to Argyll XYZ LUT profiles working properly is accepted as definitive and the convo peters out.
Well, over at the DisplayCal (GUI on ArgyllCMS) forums, it's considered to be common knowledge by the developers that MacOS built-ins glitch XYZ LUT display profiles, and have for ages. So much so, that DisplayCal UI directs users to avoid XYZ LUT profiles in favor of matrix style. "XYZ LUT==AVOID ON MACOS" I can confirm that on latest MacOS 10.14.6 DIsplayCal XYZ LUT profiles are still broken in Preview / Quicklook, and produce glitches similar to that described in the old stackexchange post. (pls see my only other thread on colorsync-user forum). And that Photoshop seems to have no problemo with them—Apple is the only one getting this wrong is also conventional wisdom at DisplayCal forums, Moreover—to increase the intrigue—another user on DisplayCal forums, who is using a plasma TV for a display via HDMI, is seeing the same glitch symptoms with a DisplayCal matrix (***) profile as I see with an XYZ LUT profile! A grey ramp basically rolls off to black up in the midtones, and image tonality does weird things up high too. So back here on this thread, with this discussion of classic working space profiles producing glitches in MacOS Preview, it looks like maybe this will all will come to a head and can get fixed? That's where I'm coming from On Tue, Aug 20, 2019 at 2:40 PM John Gnaegy via colorsync-users < colorsync-users@lists.apple.com> wrote:
When I set a basic RGB profile, like AdobeRGB, in Displays > Color,
That’s not technically a display profile, it’s a “Space” profile. There’s also no ‘vcgt’ tag in it (though not all display profiles have those). Don’t know if that’s relevant to this behavior or not, but it’s something to consider.
_______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/colorsync-users/wire%40lexiphanicism...
This email sent to wire@lexiphanicism.com
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.
participants (6)
-
John Gnaegy
-
Lars Borg
-
Neil Barstow
-
Neil Snape
-
William Hollingworth
-
Wire Moore