Re: Possible ColorSync discontinuity bug introduced in OS 10.14.6 with display "r/g/bTRC" tags?
Re: Possible ColorSync discontinuity bug introduced in OS 10.14.6 with display "r/g/bTRC" tags?
- Subject: Re: Possible ColorSync discontinuity bug introduced in OS 10.14.6 with display "r/g/bTRC" tags?
- From: Wire Moore via colorsync-users <email@hidden>
- Date: Tue, 20 Aug 2019 10:44:22 -0700
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 <email@hidden> 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 <
> email@hidden> 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 (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>>
>> This email sent to email@hidden
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden