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