- This topic has 278 replies, 20 voices, and was last updated 2 years, 10 months ago by
.
-
Posts
-
@Josh, first of all, you did an amazing job with the SDR test cases (as well)! Thanks and congrats!
I have couple of questions.2. In order to properly use this with e.g. madTPG, the madTPG output range should be set to 16-255 for SDR
Where can/do you set it? In madvr itself (under display properties -> custom levels)?
I needed to hack the code in DisplayCal
😀 Good job! If I edit the code locally, would it use the modification on the next run?
further minor tweaks of the floating point to integer conversion for the LUTs
Thanks, upgraded to 0.2.3.
or the calibration and/or profiling I’m using the Video (D65, Rec 1886) preset
What pattern generator did you use, madTPG? If so, why didn’t you use the madvr SDR preset?
In the attached files I also keep track of which dithering/near black mode is in use, denoted by “weak” for the pre-flashing-fix behaviour and “strong” for the new behaviour (it’s not just the dithering which changes, but also the use of the white subpixels near black as has been discussed elsewhere)
Amazing stuff! Since I’m on an ancient firmware (4.10.25) with my B8, here only the weak dithering applies.
Calibration mode on vs off makes no difference as long as “passthrough” settings are used for gamma/color gamut and white balance
Woow!
Results with calibration+profiling give significantly better Gray Balance than profiling only
So DisplayCal’s documention is correct 🙂
If both calibration and profiling are performed, results are very similar applying the calibration using the 1D LUT or applying it as part of the 3D LUT
That’s good news for SDR! So we can use a unity 1dlut and only deal with the 3dlut.
The Calibration+profiling cases with non-factory 1D lut (calibrations 5 and 6) have a small issue with reduced gamma very close to black.
That’s interesting, I usually get increased gamma not in the opposite way 🙂
indeed calibrations 4,5,6 exhibit substantial flashing on the relevant test patterns
Just a note about this: maybe the “old” test patterns are not valid anymore, like with the new Panasonic series as @j82k pointed out here.
I’ll start looking at HDR more closely next.
Amazing, I’m hardly waiting for your thoughts on this!
I test this by setting the 1D lut to all white except for the first and last elements which are set to output black, and the 3D LUT to unity. The first and last RGB values which produce black are then as follows:
Can you tell me more about this, where do you set these and how? I can test it as well here if I understand what I do. 🙂
SDR Black Level Low Brightness 50 Contrast 83: 65-1023
SDR Black Level Low Brightness 51 Contrast 83: 64-1022
…
SDR Black Level High Brightness 50 Contrast 100: 0-1020
…
SDR black level low brightness 50 contrast 85 is clearly clipping if one expects a 16-255 rangeBlack Level High is close as well and the others are also not perfect.
What about: SDR Black Level High Brightness 50 Contrast 85?HDR Black Level High Brightness 50 Contrast 100: 0-1023
So in fact yes, black level high brightness 50 contrast 100 is perfect for hdrPerfect, thanks!
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 matrixIt popped in my mind from these hidden features, whether an endpoint exists for getCalibration: and it does!
Unfortunately I couldn’t make it work: it needs a payload param called “command”, but I don’t know what value it requires.ECHO {"id":"81d922ab0006","type":"request","uri":"ssap://externalpq/getExternalPqData","payload":{"command":"1D_DPG_DATA","picMode":"expert1"},"client-key":"5bdee7b081a662a99e2680d483a48c74"} | websocat_win64.exe ws://192.168.1.78:3000/ -n1 {"type":"error","id":"81d922ab0006","error":"500 Application error","payload":{"returnValue":false,"errorCode":"DISPLAY_ERROR_0000","errorText":"Unknown error"}}The same happens when I set e.g. “abc” instead of “1D_DPG_DATA”, so either the value is wrong and/or additional params are missing (I also put all the existing ones that aiopylgtv uses during uploading). It would be nice to get it work especially to get back the factory luts, if it’s possible at all 🙂
I think I uploaded the LG C8 .ccss but I can’t find it in the database.
And I just remembered I was wary about using a ccmx because it’s a WRGB panel, so the pure R,G,B readings (captured for the gamut mapping) will be drifted by including W in the ccmx calculation. CalMAN didn’t show me by how much but DisplayCAL gave me an idea (probably de~0.4 on which is not much).
Oh, and that 1DLUT thing would be extremely helpful with DolbyVision modes which currently requires expensive pattern generators (or semi-expensive metadata injectors) for CalMAN when in actual reality DV probably needs the exact same 1DLUT as the HDR10 mode does (but CalMAN won’t allow to save and re-upload a 1DLUT, not even between HDR10 presets – I think for this very reason, to sabotage DolbyVision workarounds).
@janos-toth-f is there a reason this correction profile was created for a “refresh” type display rather than LCD?@janos-toth-f is there a reason this correction profile was created for a “refresh” type display rather than LCD?
Not at all. It was an oversight. I measured a PDP before and forgot to adjust the settings. But I think it’s completely harmless or actually even better. I don’t think the i1Pro2 has a true refresh-sync mode and even then it should work fine in case a refresh rate can not be determined. And the same applies to the i1d3. Considering the C8 can do 60+60 and 50+50 Hz BFI, refresh mode is probably a safer default. If BFI is inactive, refresh mode should still work fine. If BFI is turned on then non-refresh mode could run into issues.
Calibrite Display Pro HL on Amazon
Disclosure: As an Amazon Associate I earn from qualifying purchases.In order avoid DisplayCal and/or ArgyllCMS from messing further with the ranges, I needed to hack the code in DisplayCal, changing https://sourceforge.net/p/dispcalgui/code/6382/tree/trunk/DisplayCAL/madvr.py#l638 to always return (0., 255.) regardless of what level is actually set in madTPG. ( @fhoech is there a proper way of dealing with this, or does an additional checkbox need to be added to DisplayCal somewhere to deal with this situation?)
I guess I do not understand this. When DisplayCAL/ArgyllCMS is driving madTPG, the output levels are completely controlled by the latter.
Results with calibration+profiling give significantly better Gray Balance than profiling only (maybe this could be mitigated by using more patches for profiling, and/or switching from collink to xicclu for the 3D LUT creation)
The xicclu vs collink bit seems unlikely. But you can try with the
--experimentalcommand line switch (only works for colorimetric intents)If both calibration and profiling are performed, results are very similar applying the calibration using the 1D LUT or applying it as part of the 3D LUT (Calibrations 5 vs 6)
This is basically expected, at least with 33x33x33 cLUT points which is about equal to a “fast” calibration in terms of gray axis resolution (final iteration 32 points).
I guess I do not understand this. When DisplayCAL/ArgyllCMS is driving madTPG, the output levels are completely controlled by the latter.
The default SDR Contras=85 (/100) and Brightness=50 settings require 16-255 input range, not “standard” 0-255 or 16-235 (Contrast=100 maps the 235 input to internal 1023, Contrast=85 to internal 940 — at least theoretically, his findings indicate some unexpected small drifts).
If both calibration and profiling are performed, results are very similar applying the calibration using the 1D LUT or applying it as part of the 3D LUT (Calibrations 5 vs 6)
Any idea why colprof leaves the tone response pretty much uncorrected with small 65gray+RGB100% patches (unlike the white balance which seems fine)? Is this sorf-of expected?
The default SDR Contras=85 (/100) and Brightness=50 settings require 16-255 input range, not “standard” 0-255
That’s not what i was asking.
Any idea why colprof leaves the tone response pretty much uncorrected with small 65gray+RGB100% patches (unlike the white balance which seems fine)? Is this sorf-of expected?
Not enough patches to determine which combinations of R, G, B will produce neutral (at least obviously, not accurately enough).
[Edit: colprof doesn’t correct anything. This is profiling we’re talking about. collink does the correction. ]
[Edit: colprof doesn’t correct anything. This is profiling we’re talking about. collink does the correction. ]
Oh, yes, collink in that context (although I am not sure if the problem is in the display profile or the link profile).
I just don’t see why. A profile made from 65 gray patches should paint the tone curve fairly well, at least for the gray-scale (but also for R,G,B with the assumption that W=R+G+B — which is indeed technically false in this case but I deliberately want it to make that assumption, otherwise it might tries to correct the saturation errors in the “W boost” range…). But the validation was also done on gray patches (at least considering the tone response). I tried adding R, G, B ramps (4×65 in total) but that produced worse results (possibly due the anisotropic and non-additive nature of the WRGB panel in HDR mode). And multidimensional measurements with 1000+ points would face stability issues.
I just don’t see why.
Can it happen that the TV uses a 3dlut in HDR mode in a different way?
I just don’t see why. A profile made from 65 gray patches should paint the tone curve fairly well
Not necessarily. Equal RGB is not guaranteed to be neutral (same hue as white).
In order avoid DisplayCal and/or ArgyllCMS from messing further with the ranges, I needed to hack the code in DisplayCal, changing https://sourceforge.net/p/dispcalgui/code/6382/tree/trunk/DisplayCAL/madvr.py#l638 to always return (0., 255.) regardless of what level is actually set in madTPG. ( @fhoech is there a proper way of dealing with this, or does an additional checkbox need to be added to DisplayCal somewhere to deal with this situation?)
I guess I do not understand this. When DisplayCAL/ArgyllCMS is driving madTPG, the output levels are completely controlled by the latter.
My concern is the part of the code in worker.py with
if white and (black, white) != (0, 255): self.log("Need to scale vcgt to video levels (%s..%s)" %Since this code will be triggered when madvr is set to something other than 0-255 given
self.madtpg_bw_lvl = self.madtpg.get_black_and_white_level() if not self.madtpg_bw_lvl: self.log("madVR_GetBlackAndWhiteLevel failed") else: self.log("Output levels: %s-%s" % self.madtpg_bw_lvl)I agree with Janos though that it should be possible to avoid this by doing the calibration and profiling with black level set to high and contrast=100 with madvr set to 0-255 output, modulo the remaining small clipping/lut alignment issues which I’m trying to still fully understand.
My concern is the part of the code in worker.py with
if white and (black, white) != (0, 255): self.log("Need to scale vcgt to video levels (%s..%s)" %Since this code will be triggered when madvr is set to something other than 0-255 given
That shouldn’t matter. The vcgt is automatically un-scaled when extracted for application to (e.g.) a 3D LUT (see code in argyll_cgats.py, extract_cal_from_profile).
Ok, is that also true if I’m reading the .cal file directly to upload to the 1d lut in the TV?
