LG C8 Lut

Home Forums General Discussion LG C8 Lut

Viewing 15 posts - 196 through 210 (of 279 total)
  • Author
    Posts
  • #22389

    stama
    Participant
    • Offline

    I agree, some documentation on the various commands and parameters would be appreciated.

    I tried using this for the first time last night, and did not know how to specify I wanted to target the isfExpert Dark mode. Finally figured out that if the example was using “expert1”, then this must be “expert2”. Looked over the whole source code, it was not documented anywhere. Same thing about the other sdr, hdr and dolby vision pic modes, the identifiers for them are not specified anywhere.

    Because I just copied some lines of code from the example, I also accidentally cleared out the 1D LUT, which is not what I wanted to do. TV reset to factory defaults followed afterwards. 🙂


    @josh-2
    , I checked out the current source code from github, and run into an issue as soon as I tried to upload a 3d lut file. You have a typo in “upload_3d_lut” method – it should be BT2020 in “if command not in [cal.UPLOAD_3D_LUT_BT709, cal.UPLOAD_3D_LUT_BT202]”.

    I have a couple of questions:

    • what is the expected way to generate the data in the cube file: the result of profiling using full range or legal range?
    • in the ddc_reset method, you are clearing both the bt709 and bt2020 matrices, no matter if we are only interested in SDR mode. Is this intended?
    • I also see that you are setting the 2.2 and 0.45 1D LUTs to 0. What is the reason for this?

    My experiment last night was not very successful, but I suspect it was due to some profile creation issue (I used the argyll executables for the whole process instead of DisplayCal, for the first time ever). Got one profile with severe white levels clipping, and another one which was very dim (used -IB flag for collink, and no calibration file, maybe that’s why?). Used a 5^3 cube with 33 grays ti1 file, and these were the argyll commands used (with a i1Pro2, that’s why the “dispread -s -J -H”), and then I used aiopylgtv to upload the transform.02.cube file:

    dispread -v -d1 -s -J -H patches.02
    colprof.exe -v -qh -aX -bl -M "LG 65C8" -A "LG Electronics" patches.02
    collink.exe -v -qh -G -ia -r33 -n -en -En -b -IB -P -3c Rec709.icm "patches.02.icm" "transform.02.icm"

    Oh, and “-P” with collink did not seem to do what was supposed to do, did not get any diagnostics html files.

    #22390

    VestibulumDapibus
    Participant
    • Offline

    Hey, some progress on HDR? Should I just try again in a few months?

    #22391

    stama
    Participant
    • Offline

    A few months more or less will not make HDR readings stable. 🙂

    Just do what everybody does – enter service menu and calibrate the wp for Warm while in SDR mode, because the white point will be corrected for both SDR and HDR modes. Then, while in HDR mode, change the OLED light so that you get a reading of 700 nits max.

    #22392

    Josh Bendavid
    Participant
    • Offline

    Thanks for catching the typo (this issue was introduced recently as part of other changes unrelated to calibration)

    The valid picture mode strings are listed in the documentation, as well as a warning about ddc_reset (I’ll make it bigger :),  but indeed the mapping to the picture mode names in the TV UI is not written anywhere.  In fact it may differ between different models, but we should probably start a table somewhere.

    I’m still trying to work out myself some of the subtleties related to the input/output ranges.

    For SDR it is intended to reset both BT709 and BT2020 3d luts.  The reason is that BT2020 SDR is a perfectly valid hdmi signal and/or video format, and the TV will use the BT2020 3d lut in case it receives such a signal, even if this is an uncommon use case.  An Nvidia Shield can/will output video like this depending on how it’s configured for example.  For this reason the suggestion would be to upload both luts when calibrating SDR, also because it doesn’t require any additional measurements, you can just create the second 3d lut for bt2020 from the same profile.

    #22397

    stama
    Participant
    • Offline

    Thanks for your reply!

    Any thoughts to share on the 2.2/0.45 1D LUT?

    #22398

    Josh Bendavid
    Participant
    • Offline

    The 2.2 and 0.45 variables are not really LUTs but rather booleans that switch on and off two (opposite) gamma transformations.

    These correspond to the “De-gamma” and “Re-gamma” steps in the signal processing pipeline here:

    https://displaycalibrations.com/lg_2018_oled_profiling_using_lightspace.html

    Calman sets both of them to 0 (disabled) for 2019 sets, but doesn’t touch them for 2018 ones.  In fact they are anyways off, and touching them doesn’t harm anything on the 2018 sets.

    The 3×3 matrix in between is what is being set by the 3BY3_GAMUT_DATA commands (by default to the identity matrix).  Again this is part of the ddc_reset procedure in Calman for the 2019 sets, and doesn’t harm/change anything for the 2018 sets.

    #22399

    stama
    Participant
    • Offline

    Thank you, I understand now.

    I remember Ted saying that using the 3D LUT reset in DeviceControl sets that 3×3 matrix to unity, because it’s used to do that Auto/Wide/Extended gammut mapping available in the user menu for a picture mode. And in SDR modes with Auto setting, it does a native-to-Rec709 transform. I don’t remember if he was speaking only about the 2019 OLEDs though.

    #22580

    VestibulumDapibus
    Participant
    • Offline

    A few months more or less will not make HDR readings stable. ????

    It would seem there’s still confusion about the proper way to do things in HDR, maybe I’d deal with less of that in a few months? You’re mentioning adjusting the WP, do we know how to generate a full LUT after that?

    #22663

    Josh Bendavid
    Participant
    • Offline

    A few more details I’ve managed to work out for the image pipline (for the C8 and in SDR mode at least):

    With brightness and contrast at 50/100, a 10 bit input signal 0-1023 is mapped onto internal values of 0-4092, but with some clipping and not perfect alignment.    The  (33^3) 3D LUT maps an input of 0 onto the first entry, and an input of 4096 onto the last entry.  Despite the fact that brightness and contrast adjustments give a max output of 4092, the 3×3 matrix can be used to scale things up to at least 4096.  In normal usage though, this means that the full input range never reaches the last entry of the 3d lut, similar to the situation described at the top of collink.h in ArgyllCMS for the EEColor 3d luts.

    The (1024 element) 1D LUT maps an input of 0 onto the first element, and an input of 4092 onto the last element.  The current definition of unity LUTs in aiopylgtv will therefore map a 0-4092 input to the 3D LUT perfectly onto the first and last entries of the 1D LUT, and I think this part is ok.

    There are two pieces which are now missing to do things precisely (and these are definitely the reasons for previously observed strange behaviour near white)

    1. Suitable settings of brightness/constrast/black level and pattern generator range to do the calibration
    2. Proper rescaling during the generation of the 3D LUT to account for the fact that the white point doesn’t correspond to the last entry of the LUT (as is already done for the EEColor LUTs in ArgyllCMS and DisplayCal for example)

    Given that 2. is closely tied to the generation of an integer 3d lut, it could make sense to move away from the current use of floating point iridas cube files and generate the exact integer lut to be uploaded already in DisplayCal.

    #22665

    chros
    Participant
    • Offline

    There are two pieces which are now missing to do things precisely (and these are definitely the reasons for previously observed strange behaviour near white)

    1. Suitable settings of brightness/constrast/black level and pattern generator range to do the calibration
    2. Proper rescaling during the generation of the 3D LUT to account for the fact that the white point doesn’t correspond to the last entry of the LUT (as is already done for the EEColor LUTs in ArgyllCMS and DisplayCal for example)

    Hm, interesting, thanks Josh for your work!

    #22674

    chros
    Participant
    • Offline

    There are two pieces which are now missing to do things precisely (and these are definitely the reasons for previously observed strange behaviour near white)

    Note, that I observed the same thing when I created sdr 3dlut for madvr (not for the TV).

    #23428

    koyaa
    Participant
    • Offline

    Hi there, I have successfully calibrated my C8 in SDR thanks to all the advice in this thread. I am however stuck when it comes to HDR, I never get the TV to behave properly during my attempts. Would you guys have pointers to give me? 🙂

    #23433

    chros
    Participant
    • Offline

    I’m afraid no one came up with a valid solution yet. But you can share with us what you’ve tried so far and what its result was.

    #23443

    koyaa
    Participant
    • Offline

    I think it boils down to this weird gamma curve the TV switches to during HDR calibration. All my profiling attempts ended up wrongly “saturated”.

    #23664

    A.ces
    Participant
    • Offline

    Hey i’m a little unsure what settings to use when creating a 3dlut for uploading to the TV,i see all these settings like rendering intent,source color space, input/output encoding, input/output bitdepth etc, does anyone have any tips what to use, the TV is a 2019 LG C9.

    also when uploading a 3dlut is it possible to disable the color gamut emulation but keep the grayscale/gamma calibration that the 3dlut does in the TV, if i for example sometimes want the saturated colors when playing games?

Viewing 15 posts - 196 through 210 (of 279 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS