If I use the far-spread iterative patches only, I end up with overly bright (actually reddish) dark (“shadow”) range. If I include per-channel and gray patches manually I end up with pink clipping. I tried different set of patches but couldn’t get it right so far. The standard space is a huge, very few if any displays can do more than 5-20% of the standard luma range (10000 cd/m^2, yeah, 10k), so the usual test charts produce a lot of redundant measurements (dispread will go through different device values which produce the exact same output as they are clipped on the device gamut edges and we end up with too few meaningful measurement points or spend too much time on measurements).Īnd I have a question (mostly offtopic here since it concerns ArgyllCMS): Does anybody know how well colprof supposed to handle this clipping (from Rec2020 +2048 to real-world device gamuts) and/or the anisotropy of the WRGB space (individual, saturated R,G,B channels start clipping in luma a lot sooner than grays + there is that unknows-shaped crossover between saturated colors and grays in the high luma range…)?

I guess it would be nice to have a user-friendly option which limits patch generation to a certain preset 3D gamut inside the Rec 2020 + 2048 space (in this case that would be DCI-P nit). Now let me get to the point which concerns Displa圜AL / ArgyllCMS and HDR. The CMS is supposed to be tunable (to some extent) in TV Cinema HDR mode but there are some problems with that: those few sliders can’t possibly solve all these relatively complex gamut mapping errors and even if they could, adjusting them by more than a few clicks causes crazy errors (heavy color banding, mostly manifesting as weird nose on motion picture). saturated colors are notably darker than their gray counterparts - and this is with relatively dark colors, it’s not the inherent and expected anisotropy of the WRGB space yet, this is just plain software gamut mapping error or questionable design choice of the LG firmware ). The limited set of HCFR gamut measurements say that most colors have the right chroma (more or less) but fall short on luminance (eg. – in TV mode, the Auto gamut mode looks semi-decent but even the naked eye can pick up some problems, like life-less, almost “metallic like” gray skins (like every single movie features sick people or zombies). I guess the same precision is used for the narrow SDR and wider HDR contrast ranges but the wider range obviously needs more precision for the same apparent smoothness and it’s just not enough in PC mode for HDR…). You can easily see with the naked eye how the gradient steps band together in PC mode compared to TV mode (This effects the SDR PC mode too but for a far less extent.

This Wide/native gamut mode could be suitable for profiling but PC mode has noticeably too low precision for HDR. Most PC picture modes are locked to Auto gamut mode which is badly broken (it emulates Rec709 colors for Rec2020 input which is obviously not what anybody possibly wants in HDR mode) and the Wide gamut mode (the PC Standard HDR mode is locked to Wide) effectively gives you the native gamut (which is far from ideal if you feed it with Rec2020 input: even if it’s DCI-P3 colorspace encoded in Rec2020, it won’t work correctly with this setup ). – the PC mode is pretty much useless for HDR altogether. However, when it comes to HDR, you might end up getting headaches: I consider it a waste of time and effort to profile it (it won’t get any better but there is the potential to make it worse if you can’t get the profile right for some reason). LG’s current gen OLED TVs (a 55C7V in my case) have virtually perfect Rec709 color reproduction after some fine-tuning applied to the ISF preset (which works flawlessly in both TV and PC modes). Let me start with some intro to this (skip ahead a few paragraphs if you are not interested in every details).

Displaycal profile extended