- This topic has 6 replies, 2 voices, and was last updated 6 years, 4 months ago by
.
-
Posts
-
Let me start with some intro to this (skip ahead a few paragraphs if you are not interested in every details).
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). 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).
However, when it comes to HDR, you might end up getting headaches:
– the PC mode is pretty much useless for HDR altogether. 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 [which the native space happens to match closely] encoded in Rec2020, it won’t work correctly with this setup [because 2020/P3 is not the same as P3 when you work with Rec2020]). This Wide/native gamut mode could be suitable for profiling but PC mode has noticeably too low precision 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. 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…).
– 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). The limited set of HCFR gamut measurements say that most colors have the right chroma (more or less) but fall short on luminance (eg. 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 [or built-in fix-function processor?]). 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).
—
Now let me get to the point which concerns DisplayCAL / ArgyllCMS and HDR.
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-P3 and 1000 nit). 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).
And 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 tried different set of patches but couldn’t get it right so far. If I include per-channel and gray patches manually I end up with pink clipping. If I use the far-spread iterative patches only, I end up with overly bright (actually reddish) dark (“shadow”) range.
It seems like colprof has a hard time tracking the Rec2048-like device curve with the iterative patches (while many patches are wasted on out-of-gamut values) and cLUT profiles but also doesn’t like the anisotropy of the RGB-driven WRGB device space (it would probably require more patches to figure out the shape of the cross-over zone where the R,G,B channels clip out and the W sub-pixel starts to kick in…) but there is obviously a limit of how much patches you can use. For starters, the display will start to drift a lot (notable image retention) if “tortured” in HDR mode for extended amounts of time (with bright test patches to no end). The IR will go away (the “health” of the display is not my primary concern here) but probably will affect the measurements (these drifted readings probably won’t represent the normal operation of the device).
Any suggestions?
-
This topic was modified 6 years, 5 months ago by
.
-
This topic was modified 6 years, 5 months ago by .
-
This topic was modified 6 years, 5 months ago by .
-
This topic was modified 6 years, 5 months ago by .
-
This topic was modified 6 years, 5 months ago by .
-
This topic was modified 6 years, 5 months ago by .
-
This topic was modified 6 years, 5 months ago by .
-
This topic was modified 6 years, 5 months ago by .
Hmm… I think I just rediscovered the secrete sauce: the command line parameter set which makes colprof behave (I am not sure which one of these make the difference, I always applied them all if any):
-ni -np -no
… and suddenly everything looks as expected with the 3DLUT applied (black remains black and near-black isn’t reddish and/or overly bright).
Interesting. What happens if you use the default testchart with 175 patches (colprof will not be used in that case)?
Interesting. What happens if you use the default testchart with 175 patches (colprof will not be used in that case)?
I find the result unsatisfactory overall (it seems like it over-compensates on some of the the color luminance issue, making some of the originally dulled colors appear way to bright now) but that’s probably due the small number of patches. However, I see no obviously reddish (or even just too bright) shadows or pinkish highlights (so, in this regard, it’s similar to the colprof results with the no-curve options).
Do you want to look at the actual measurements, LUTs, etc..?
but that’s probably due the small number of patches.
Possibly. If you want to test the hypothesis, all the LUT testcharts (small – extended – large – very large) use a regular grid layout that will trigger the use of the alternate forward profiler.
Do you want to look at the actual measurements, LUTs, etc..?
Yes, that would be interesting as I don’t have a HDR capable TV, thanks.
I guess the .ti3 and .log files are sufficient (I used the official ArgyllCMS Win64 binaries). This folder contains the default 175-patch run and a much bigger testchart (4096 far spread patches) which I actually use now.
https://1drv.ms/f/s!Au_qZy4aTXxC4wgxxe3ITnNXLLAu
By the way, ReShade seems to work fine with 16-bit PNG files, so after I have the .fx shader installed, I create a generic 16-bit PNG for it (DisplayCAL doesn’t let me choose the bit depth in the ReShade preset).
By the way, ReShade seems to work fine with 16-bit PNG files
Have you changed texture format to RGBA16 in ColorLookupTable.fx? Otherwise, the 16-bit PNG will be converted to 8-bit by integer truncating (increased banding). I just checked and RGBA16 texture format gives incorrect results (extreme color shift/clipping), so it doesn’t seem like it is supported.
-
This topic was modified 6 years, 5 months ago by
