Interpretation of results

Home Forums Help and Support Interpretation of results

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #15246

    grahamh
    Participant
    • Offline

    So I calibrated my old BenQ LCD monitor.  Its EDID says its primaries are not far off sRGB, and sure enough the Gamut plot without LUT reflects this.

    If I add the LUT, I’m getting colours plotted well outside the sRGB gamut. It looks like the actual primaries are not far off DCI-P3 primaries.

    1. Does that mean my screen is lying about its primaries?
    2. How come the report says gamut coverage is only 89% of sRGB when it looks to be over 100% with the LUT engaged? (ie how is that % calculated?)
    3. Does DisplayCAL/Argyll take the EDID primaries at face value and is there any way to override that?  Surely we should be calculating a matrix based on the actual primaries, rather than letting the CLUT compensate for the difference.
    Attachments:
    You must be logged in to view attached files.
    #15251

    Florian Höch
    Administrator
    • Offline

    Hi,

    you’re misinterpreting the results. The first image shows the gamut of the display (as characterized by the profile). The second image shows the amount of “clipping overshoot” in the B2A tables of the profile (which simply means that several CIE tristimulus values outside the display gamut map to very similar device RGB numbers). EDID has nothing to do with this.

    #15253

    grahamh
    Participant
    • Offline

    OK, so forget EDID, but are you saying the points plotted do not actually represent colours the screen can reproduce?  If so, why plot them (in those locations)?

    #15256

    Florian Höch
    Administrator
    • Offline

    are you saying the points plotted do not actually represent colours the screen can reproduce?

    No, quite the opposite.

    #15258

    grahamh
    Participant
    • Offline

    So I was right – my screen gamut is bigger than sRGB – but it claims it’s only 89%.

    Anyway, just digging through the log file now to understand where those GAMUT_coverage numbers come from.

    Thanks.

    #15259

    Florian Höch
    Administrator
    • Offline

    So I was right – my screen gamut is bigger than sRGB – but it claims it’s only 89%.

    I see no indication in the graph that your screen gamut is larger than sRGB.

    #15261

    grahamh
    Participant
    • Offline

    The coloured line in the second image is almost entirely outside the dotted comparison profile.  Doesn’t that mean the gamut is wider?

    Or am I misunderstanding what the LUT tick box does?  I thought it engaged/disengaged the CLUT in the profile.

    #15262

    Florian Höch
    Administrator
    • Offline

    The coloured line in the second image is almost entirely outside the dotted comparison profile. Doesn’t that mean the gamut is wider?

    Yes, but as I pointed out, that is viewing the B2A tables (PCS to device), not A2B (device to PCS, i.e. gamut).

    #15269

    grahamh
    Participant
    • Offline

    OK, got it (I think):

    • source colours inside the gamut indicated on the B2A plot will be mapped inside the display’s gamut in a way that they should be distinguishable;
    • colours outside the gamut indicated on the B2A plot will be mapped or clipped but will be indistinguishable from each other (ie at the destination gamut boundary)

    From the log, it seems you select a suitable source gamut based on the destination primaries, which in my case resulted in DCI-P3.

    2019-01-10 16:48:27,828 Increasing saturation of actual primaries for PCS candidate to 104%...
    2019-01-10 16:48:27,828 R xy 0.648123 0.337501 -> 0.660219 0.336659
    2019-01-10 16:48:27,829 G xy 0.299046 0.597824 -> 0.297180 0.607396
    2019-01-10 16:48:27,829 B xy 0.151081 0.073214 -> 0.143296 0.061801
    2019-01-10 16:48:27,831 Checking for suitable PCS candidate...
    2019-01-10 16:48:27,832 Skipping PCS candidate based on actual primaries because it does not encompass Rec. 709 blue
    2019-01-10 16:48:27,832 Rec709-encompassing, variant 1 fit: 0.97 (area: 80.63%)
    2019-01-10 16:48:27,834 Rec709-encompassing, variant 2 fit: 0.87 (area: 82.78%)
    2019-01-10 16:48:27,835 Rec709-encompassing, variant 3 fit: 0.89 (area: 80.08%)
    2019-01-10 16:48:27,835 Rec709-encompassing, variant 4 fit: 0.93 (area: 81.66%)
    2019-01-10 16:48:27,836 SMPTE-431-2/DCI-P3-encompassing, variant 1 fit: 1.04 (area: 67.67%)
    2019-01-10 16:48:27,838 Using primaries: SMPTE-431-2/DCI-P3-encompassing, variant 1
    #15270

    Florian Höch
    Administrator
    • Offline

    What the inverse B2A plot shows is not strictly comparable to the A2B plot, because inverting the B2A table is inherently less accurate than inverting the A2B table (which is no surprise since the B2A table was generated in the first place by inverting the A2B table). The only useful information that can really be gleaned from the inverse B2A plot is that its gamut outline is larger than that of the actual device gamut, and also how fine-grained the B2A LUT is (few jaggies and close to A2B outline = high effective LUT resolution). If you want to know your device gamut, only the A2B plot is relevant. The PCS (profile connection space) is not related to a source gamut (which is typically that of an image). Also, colors outside the display gamut will not necessarily be indistinguishable when clipped to the gamut edges, only if the hue stays the same. The rest of your observations are correct.

    #15272

    grahamh
    Participant
    • Offline

    Also, colors outside the display gamut will not necessarily be indistinguishable when clipped to the gamut edges, only if the hue stays the same.

    Of course, I missed that bit out 😉

    Many thanks.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS