- This topic has 278 replies, 20 voices, and was last updated 2 years, 10 months ago by
.
-
Posts
-
If someone has a 2019 set it would be interesting to check if they behave the same way.
I played around a bit with the parameters passed to the start calibration command, but they don’t seem to make any difference either way. Further ideas on that front are welcome (I was actually hoping that they control the near black dithering behaviour, but this is probably wishful thinking.)
I no longer have a 55C8 and my 55C9 didn’t arrive yet. But my experience was different with the 5.10.35 firmware. I am pretty sure I got the new dithering after I initiated a factory reset (I always did this before I decided to calibrate following a firmware update to see the new default state) and calibrated some picture modes with CalMAN (always the latest available public release). I double-checked this after the dithering discussion surfaced on AVSForum (and saw Vincent’s video). But I didn’t even need any special test patterns: I had a blank (solid fill black) Windows background with the default gray taskbar color and auto-hide ON… and the dithering is “”awfully” visible on the thin line when the taskbar is hidden. It’s like those cheap TN+Film LCD panels in some notebooks: full of visible blocks of noise like a checkerboard. I also calibrated a 65C8 for a friend which I didn’t reset before the calibration (I am not sure how long he had it running with auto-updates) and I showed him the dithering noise on the dark gray test patches. So, may be something is missing and CalMAN’s “Full DDC Reset” clears and disables that “calibrated” flag.
Ok thanks, I’ll test with the latest version of Calman, since I realized I had only been using the penultimate version, and also try a factory reset (since I think I was on 05.10.20 the last time I did that)
I no longer have a 55C8 and my 55C9 didn’t arrive yet. But my experience was different with the 5.10.35 firmware. I am pretty sure I got the new dithering after I initiated a factory reset (I always did this before I decided to calibrate following a firmware update to see the new default state) and calibrated some picture modes with CalMAN (always the latest available public release). I double-checked this after the dithering discussion surfaced on AVSForum (and saw Vincent’s video). But I didn’t even need any special test patterns: I had a blank (solid fill black) Windows background with the default gray taskbar color and auto-hide ON… and the dithering is “”awfully” visible on the thin line when the taskbar is hidden. It’s like those cheap TN+Film LCD panels in some notebooks: full of visible blocks of noise like a checkerboard. I also calibrated a 65C8 for a friend which I didn’t reset before the calibration (I am not sure how long he had it running with auto-updates) and I showed him the dithering noise on the dark gray test patches. So, may be something is missing and CalMAN’s “Full DDC Reset” clears and disables that “calibrated” flag.
I have firmware version 04.10.15, and I have the same Windows settings for the background and taskbar. The visible checkerboard dithering is present here too on the taskbar, with a static pattern (the blocks don’t change at all in time, neither their luminosity, nor their position) and a thin line is visible when the taskbar is hidden. The visible thin line was the same on the C7 I had (which has no LUT upload capability), so I always assumed this is a bug in Windows: a thin one pixel line of the taskbar does not get hidden when the taskbar is supposed to be hidden – this is something that’s not visible at all when watching on small computer displays, so I’m not surprised it was not spotted by Microsoft’s devs/POs. Initially I did not notice a checkerboard pattern on the tray, but then I used sRGB tone curve instead of gamma 2.2 and the checkerboard became visible. As I said, the dithering pattern seems to be entirely affected by the luminance of the area where the dithering is applied.
János, did you not spot the same things on the old firmware version? Maybe the different tone curve of the new firmware made the checkerboard visible (this is the tone curve applied after you did a factory reset), while the previous tone curve was not making it visible.
@stoma
Yes, it’s possible the dithering became more visible on that certain shade of color as the tone response drifted with different LUTs (new factory or fresh custom).
I think this line is meant to be visible and it’s at least 2 pixels tall (exactly 2 lines on my current 1080p display, could be 4 in 2160p). It’s informative, you can sill see the number of open programs (they are brighter lines or have yellow color if they have notifications, red if they crashed, etc). This is a solid color on secondary desktop LCD and shows up with much more finely detailed noise on an old Panasonic G30 PDP (it’s pixel level dynamic noise, not 2×2 or bigger blocks of static dither) which I currently have in front of me. May be LG should try adding dynamic dither, especially for their 2019 panels which supposedly can run at 240Hz (so even native 120 content or interpolated material could be displayed at high frequency rotated alteration to hide the checkerboard pattern and iterate the real colors at pixel level).
However, I also looked at some test patterns from close distance while switching between a factory Cinema (with enhancers turned off but no LUT programming or manual color calibration) and a CalMAN calibrated Prof mode (reprogrammed 1D and 3D LUTs). And even though the different tone response indeed made this comparison much more difficult (I wasn’t looking at exactly the same shades as the constant input was mapped to different panel values though the different LUTs) but the solid dark gray patches looked comparably noisy (after cycling though a few close luminance levels). And that’s very subjective but I don’t remember ever seeing a comparable amount of dither noise (the checkerboard patterns) on that C8 with older firmwares and I doubt that was brought in by the aging after a mere ~2100 hours of total active time (although I did read some forum posts about subjectively decreased near-black performance following the first 2000 hour compensation cycle but I always treated that with doubt).
Hmm… I wonder how the 2019 models tackle this “macro block” issue. May be I will be able to test several firmware versions on the C9 (depending on the out-of-box version). But I will eventually be forced to install the currently latest one (which brings G-Sync Compatible support, the main selling point). Was this tweaked at the panel driver level in 2019 or did they handle it with similar dithering enhancements in SoC software?
@stoma
Hmm… I wonder how the 2019 models tackle this “macro block” issue. May be I will be able to test several firmware versions on the C9 (depending on the out-of-box version). But I will eventually be forced to install the currently latest one (which brings G-Sync Compatible support, the main selling point). Was this tweaked at the panel driver level in 2019 or did they handle it with similar dithering enhancements in SoC software?I think it was said the C9 models came out-of-the box with a firmware that had the new tone map, the one introduced to C8 with 4.10.31, but I think there was no need to increase Brightness above 50 to raise out of black like it happened to many on the C8.
New HDR10 DisplayCal settings for factory 1dlut:
– no more fog-layer
– image is not darkenedI couldn’t figure out how to measure just 5 patches (WBRGB, as Calman does), but this result is way better than the previous was.
Ok thanks, I’ll test with the latest version of Calman, since I realized I had only been using the penultimate version, and also try a factory reset (since I think I was on 05.10.20 the last time I did that)
I see the same behaviour using (the latest version of) calman, and also after a factory reset, so I’m not sure why we’re seeing different things here.
I should say that I never actually used the tv with any of the 4.x firmwares, so I don’t exactly know what the “old” dithering/near black handling looks like but it’s definitely the case that the dithering is weaker when enabling calibration and/or uploading a new 1D LUT with either Calman or aiopylgtv.
I think it was said the C9 models came out-of-the box with a firmware that had the new tone map, the one introduced to C8 with 4.10.31, but I think there was no need to increase Brightness above 50 to raise out of black like it happened to many on the C8.
I read some speculation that 240Hz (120+120 flicker) BFI was pulled from the 2019 firmware before retail release because LG implemented temporal dithering for 2019 models and they didn’t let the user choose between better motion or less near-black flashing (I guess they wanted to put a final end to the flashing discussions above all else). I am not sure if 120Hz dynamic dithering should be visible for the naked eye (if we are staring at a static homogeneous gray patch) because it’s fairly high frequency noise.
New HDR10 DisplayCal settings for factory 1dlut:
– no more fog-layer
– image is not darkenedI couldn’t figure out how to measure just 5 patches (WBRGB, as Calman does), but this result is way better than the previous was.
CalMAN uses the nominal 1DLUT calibration target (usually gamma 2.2) as profile gamma for the 3DLUT calculation. ArgyllCMS needs at least 2 different luminance points to calculate the actual (assumed) gamma. (2 points are fine for matrix+gamma but you usually need much more for curve(s)+matrix or cLUTs).
This shouldn’t make any difference with a neutral VGA LUT state but you don’t need the “apply vcgt” option unless you did a grayscale calibration with dispcal which you do not intend to upload to the LG hardware’s 1DLUT but you still want to carry those results to your 3DLUT (because you profiled the display with the modified VGA LUT actively in use during the profiling measurements).
Windows sometimes writes a slightly modified 1DLUT to the VGA (it’s probably a bug in Win10 19xx), so it’s better to reset the VGA LUT before profiling (unless you do a VGA LUT calibration which overwrites it anyways). But you are probably not affected with 16xx LTSC.
I see the same behaviour using (the latest version of) calman, and also after a factory reset, so I’m not sure why we’re seeing different things here.
I should say that I never actually used the tv with any of the 4.x firmwares, so I don’t exactly know what the “old” dithering/near black handling looks like but it’s definitely the case that the dithering is weaker when enabling calibration and/or uploading a new 1D LUT with either Calman or aiopylgtv.
Hmm. So you see more dither patterns in an accurate factory mode (say, Cinema) than in a CalMAN calibrated mode after your did a “full DDC reset”, finished programming both LUTs and quite from calibration mode? Do you also see more near-black flashing (on that test video with the rectangles on black background) in the calibrated mode? Is it an EU or US/SK model?
CalMAN uses the nominal 1DLUT calibration target (usually gamma 2.2) as profile gamma for the 3DLUT calculation. ArgyllCMS needs at least 2 different luminance points to calculate the actual (assumed) gamma. (2 points are fine for matrix+gamma but you usually need much more for curve(s)+matrix or cLUTs).
Thanks.
you don’t need the “apply vcgt” option unless you did a grayscale calibration with dispcal which you do not intend to upload to the LG hardware’s 1DLUT but you still want to carry those results to your 3DLUT
Sorry Janos, but I don’t understand: do you say that I have to uncheck “Apply calibration (vcgt)” on 3dlut page with my above settings?
We are still talking about profiling HDR10 + factory 1dlut.
Hmm. So you see more dither patterns in an accurate factory mode (say, Cinema) than in a CalMAN calibrated mode after your did a “full DDC reset”, finished programming both LUTs and quite from calibration mode? Do you also see more near-black flashing (on that test video with the rectangles on black background) in the calibrated mode? Is it an EU or US/SK model?
Yes that’s right.
On the other hand the amount of near-black flashing wasn’t noticeably higher to me, so maybe the dithering and different subpixel usage are not totally coupled. I’ll take a closer look at the subpixel usage and take some photos maybe.
Calman also sets some additional flags if you tell it you have a 2019 model (it doesn’t actually check that the specified model matches the TV). Not sure if they have any effect on the 2018 sets, but will investigate.
The additional data sent during a DDC Reset for SDR BT709 for a 2019 model are:
1D_2_2_EN = 0 (unsigned int16)
1D_0_45_EN = 0 (unsigned int16)
BT709_3BY3_GAMUT_DATA = [1. 0. 0. 0. 1. 0. 0. 0. 1.] (float), ie a 3×3 identity matrix
On the other hand the amount of near-black flashing wasn’t noticeably higher to me, so maybe the dithering and different subpixel usage are not totally coupled. I’ll take a closer look at the subpixel usage and take some photos maybe.
Calman also sets some additional flags if you tell it you have a 2019 model (it doesn’t actually check that the specified model matches the TV). Not sure if they have any effect on the 2018 sets, but will investigate.
The additional data sent during a DDC Reset for SDR BT709 for a 2019 model are:
1D_2_2_EN = 0 (unsigned int16)
1D_0_45_EN = 0 (unsigned int16)
BT709_3BY3_GAMUT_DATA = [1. 0. 0. 0. 1. 0. 0. 0. 1.] (float), ie a 3×3 identity matrix
The first version of the fix was similar: it did something directly beneficial and additionally made the near-black colors way too dark (trying to hide the less severe but still present flashing issue). They later dialed back on the near-black cheat without changing much else. And the last time around they left the TRC unchanged (or close to the last, fairly normal state) and it looks like they tweaked the direct solution further but additionally increased the near-black dithering noise (so basically they replaced the black crush cheat with dither cheat). So, if we calibrate, then both versions of the “core” fix are active but the black crush is either fixed by the calibration itself or (as it seems) the dithering is dialed back after calibration (via some calibration state flag). May be this heavy dither is deemed detrimental to the image quality (similarly to black crush) and that’s why it’s off for calibrated profiles (to achieve better image quality).
As I indicated earlier, it was hard to decide (for various reasons) if the amount of dithering is really the same. I got convinced it had to be the same after I checked the rectangle video and that obviously looked better than before and clearly comparable between calibrated and factory modes. It was assumed that flashing decreased due to the dithering and there was plenty of dithering in any case. My bad (unless it really did behave differently for me).
I forgot to add: it would be nice to implement that matrix calibration method. CalMAN always uploads a 3DLUT (even when it’s done by running the numbers though a matrix to fill the cube). I am interested to see how a 1DLUT calibration + a real matrix behaves compared to a 1DLUT calibration + a 3DLUT filled from a matrix in HDR10 mode where the CalMAN 1D+3D result has some magenta issues.
Ok, some additional information, and mostly good news.
Firstly, on the behaviour of these two mysterious flags 1D_2_2_EN and 1D_0_45_EN
These both seem to be treated as booleans with default 0 (and in principle should be set to 0 as part of ddc reset). Despite only being used by calman when addressing 2019 sets, these flags are valid for 2018 sets as well (though no guarantees the behaviour described below is the same.)
1D_0_45_EN when set to anything other than 0 significantly darkens the picture (and crushes blacks significantly). Not sure exactly what it’s doing.
1D_2_2_EN when set to anything other than 0 significantly brightens the picture (again, not sure exactly what it’s doing), but ONLY for picture modes using the factory 1D LUT. For picture modes where the 1D LUT has been reset, this flag seems to have no effect.
One other extremely interesting feature. For picture modes with the factory 1D LUT, starting calibration mode immediately changes the dithering behaviour as already discussed (the dithering becomes weaker, possibly corresponding to the default behaviour in older firmware versions). However, setting one or both of these flags to 0 (which should be the default) kicks the set back to the stronger dithering. I checked this in both SDR and HDR10 modes. But, as soon as a 1D LUT is uploaded, regardless of what has been done with these flags, the set switches back to the weaker dithering (and stays there even after calibration mode is ended).
So, if one wants to calibrate using the factory 1D LUT, then this can be done consistently, but measurements taken in calibration mode must be taken by calling
start_calibration
set_1d_2_2_en
set_1d_0_45_en
and then starting measurements. (calling the latter two functions without an argument will set the values to the default zero, but with this funny feature that it restores the dithering behaviour for modes with factory 1D LUT as said.)
What we don’t know how to do yet or if it’s possible is to reset the 1D lut but keep the stronger dithering. (But at least now one can consistently calibrate and choose to keep the stronger dithering by keeping the factory 1D LUT if desired.)
The other good news is that the color gamut matrices are supported on the 2018 sets as well.
I’ve added additional functions to set these set_bt709_3by3_gamut_data(picMode, data) and set_bt2020_3by3_gamut_data(picMode, data), where data is a 3×3 numpy array with dtype=np.float32. and of course the default is the identity matrix. Most likely the dolby vision modes are using the bt709 matrix as for the 3d luts.
(Is there some file input which would be convenient to implement for these matrices?)
I’ve released a 0.2.1 version of the library with these additions.
One other point is the custom tone mapping. This is definitely not supported on 2018 models, but I think it should be straightforward to add for the 2019 case.
A small update here. In fact it looks like when starting calibration mode for a picture mode with factory 1D LUT, uploading a 3D LUT will also restore the stronger dithering behaviour. (Possibly/probably sending any calibration data to the tv aside the 1D LUT will trigger this), so it’s not specifically related to these extra flags at least, which I guess are controlling some other gamma transformation type steps in the image processing chain (and where whichever step is associated with 1D_2_2_EN is apparently bypassed when using a custom 1D LUT)
