LG C8 Lut

Home Forums General Discussion LG C8 Lut

Viewing 15 posts - 151 through 165 (of 206 total)
  • Author
    Posts
  • #21752

    chros
    Participant
    • Offline

    @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 range

    Black 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 hdr

    Perfect, thanks!

    • This reply was modified 2 months, 1 week ago by chros.
    #21754

    chros
    Participant
    • Offline

    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

    It 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 🙂

    • This reply was modified 2 months, 1 week ago by chros.
    #21787

    Josh Bendavid
    Participant
    • Offline

    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?

    #21795

    János Tóth F.
    Participant
    • Offline

    @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.

    i1Basic Pro 2 on Amazon  
    Disclosure: As an Amazon Associate I earn from qualifying purchases.

    #21825

    Florian Höch
    Administrator
    • Offline

    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 --experimental command 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).

    #21827

    János Tóth F.
    Participant
    • Offline

    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?

    #21830

    Florian Höch
    Administrator
    • Offline

    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. ]

    #21843

    János Tóth F.
    Participant
    • Offline

    [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.

    #21844

    chros
    Participant
    • Offline

    I just don’t see why.

    Can it happen that the TV uses a 3dlut in HDR mode in a different way?

    #21846

    Florian Höch
    Administrator
    • Offline

    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).

    #21847

    Josh Bendavid
    Participant
    • Offline

    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.

    #21848

    Florian Höch
    Administrator
    • Offline

    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).

    #21849

    Josh Bendavid
    Participant
    • Offline

    Ok, is that also true if I’m reading the .cal file directly to upload to the 1d lut in the TV?

    #21850

    Florian Höch
    Administrator
    • Offline

    The .cal file is never scaled, it’s always full range.

    #21851

    János Tóth F.
    Participant
    • Offline

    In case of a 65×4 R,G,B,W ramp test chart both the tone response and the white balance come out pretty bad from a Rec2020 simulation (Edit: click on the “use absolute”).

    Attachments:
    You must be logged in to view attached files.
Viewing 15 posts - 151 through 165 (of 206 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS