Odd shadow behavior (regression?) with “XYZ LUT + matrix” profile generation

[Sami Boukortt]

Hi,

I am seeing somewhat strange behavior with DisplayCAL 3.8.9.3 + ArgyllCMS 2.1.2 when profiling my monitor after calibrating to a 2700K whitepoint with sRGB TRC (my “night-time calibration”). In the resulting profile, the tone response curves look like this:

Which has significant black crush. Out of curiosity, I tried creating a “Curves + matrix” profile from the exact same measurement data and the curves looked more reasonable:

So, then, I tried regenerating an “XYZ LUT + matrix” profile from old measurement data (from last July). On the left are the tone response curves from the (also XYZ LUT + matrix) profile that was generated in July, and on the right are the curves of the new profile generated from the same data:

 

What could be going on here?

I suppose it might plausibly be caused by ArgyllCMS rather than by DisplayCAL but I am reporting this here first just in case.

Thanks.

Sami

Attachments:

You must be logged in to view attached files.

[Florian Höch]

Your blue channel is clipping, the measurements are zero. Reduce the number of patches considerably, especially near black.

[Sami Boukortt]

Hi Florian, thank you for the quick response.

If I convert the XYZ measurements to L*a*b*, I can indeed see that the low-luminance samples have a b* that doesn’t get much closer to 0 than -8 or so. Is that the clipping that you are referring to? I am not sure that I see what you mean by “the measurements are zero”. Do you mean the result of going back to device RGB?

I am still somewhat puzzled by the difference in behavior compared to last year. Would you consider the old behavior to be less correct?

Also, it seems that a possible mitigation for me would be to enable black point compensation when generating the profile. From what I understand, the main compromise would be that shadows would be a bit too bright and too blue. Is that correct? If I generate a self-check report with the “XYZ LUT + matrix” profile as the simulation+display profile, the result looks decent (maximum ΔE*00 of 0.99), but perhaps that’s not the relevant procedure to check.

The tone response curves for the profile with BPC look like:

which seems closer to what I would have expected.

Thanks again.

• This reply was modified 4 years, 1 month ago by Sami Boukortt.
• This reply was modified 4 years, 1 month ago by Sami Boukortt.

[Florian Höch]

I am still somewhat puzzled by the difference in behavior compared to last year. Would you consider the old behavior to be less correct?

The old behavior was problematic because it let values above zero below the blackpoint through in some cases. This is due to how xicclu does the inverse lookup. I fixed this by clipping any non-zero values that are below the blackpoint (which technically are incorrect anyway, there cannot be “color” below black).

Also, it seems that a possible mitigation for me would be to enable black point compensation when generating the profile.

Probably a side-effect. Judging from the graph, it doesn’t work completely right in that case – the blue line should also start at zero.

I would just use the default profiling patchset (175 patches), that uses the alternate forward profiler internally which seems to be a bit more robust in this scenario.

[Sami Boukortt]

Oh, thank you for clarifying. I didn’t realize that using fewer patches would use another profiling approach entirely, somehow I got the idea that it would only be to get fewer problematic measurements. I will try that.

Many thanks for your help! It is very much appreciated.

[Sami Boukortt]

Just as an update, I tried with 175 patches and the resulting profile indeed looks sensible:

[Author]

Posts