LG C8 Lut

Home Forums General Discussion LG C8 Lut

Viewing 15 posts - 136 through 150 (of 279 total)
  • Author
    Posts
  • #21610

    János Tóth F.
    Participant
    • Offline

    @josh-2 I think this depends on many things, starting with the question if you want to get it done as quickly as possible through the least amount of steps and complexity involved or you are after the best possible validation reports (which doesn’t always necessarily mean the best overall picture quality, even if it often does).

    As much I know, LightSpace can create a decent 1DLUT from static grayscale measurements (it can’t do iterative calibration at all). And even CalMAN with it’s known 3DLUT engine issues can create a decent enough “Lighting LUT” at least as far as the grayscale is concerned (from mostly gray measurements) with a neutral 1DLUT in place (I tried this on the C8 in SDR but it’s disabled for HDR for various reasons).

    Regardless, in this particular case, the grayscale has fairly great white balance all over the luminance range but the tone response is significantly off. If setting the white point before profiling helps I see that as a workaround, rather than a fix. May be it’s impossible for ArgyllCMS/DisplayCAL to get this right from this patch set and the resulting profile with this exotic WRGB HDR behavior. But may be it should be possible and there is some bug somewhere, or we simply need different profile/3DLUT creation settings (or slightly different “minimalistic” patch set) for this to work. So I wouldn’t just write this off as “use a different approach” so easily.

    I remember experimenting with “profile only” 3DLUTs on SDR-only RGB  LCD displays set to as close to “native” response as they got. There were issues at first but they worked eventually. I think there is some info on this on the ArgyllCMS mailing list. So, I wonder if this happens because of WRGB with “W boost”  or may be because DisplayCAL (if I am right, I didn’t look into it’s inner workings for years) uses some more generic tools instead of collink for 3DLUT creation (and that tool which I can’t name from memory wasn’t updated to the same behavior as collink was).

    Of course, if you calibrate the 1DLUT (or at least leave the factory one in place if it’s better than a neutral one), you won’t see if the 3DLUT generation is able to handle the relatively huge grayscale adjustments or not. But that doesn’t mean it shouldn’t be able to do so (at least in theory).

    I think I shall try this same workflow in SDR on the OLED (with the “W boost” off) with more scrutiny on the validation report. If that’s fine then we can start narrowing it down further…

    For now, I decided to calibrate the TV with CalMAN (1D + matrix based 3D LUT). But I don’t like the result too much. There is some magenta banding on saturated dark blue shades (like the (like the Lion King hyena scene), similar to how it was on the C8. I still think that might comes from the 1DLUT calibration.

    #21612

    Josh Bendavid
    Participant
    • Offline

    Ok, at least one mistake I was making with Profile Only was to use Absolute colorimetric rendering intent.  Using Absolute Colorimetric with white point scaling seems to do something much more sensible when the white point is not pre-calibrated.

    #21613

    chros
    Participant
    • Offline

    So yes it is tracking gamma 2.2 when calibration mode is enabled.

    Thanks!

    Again, just look at the damn picture with your naked eyes in calibration mode! What do you Ccccc? ???? I tell you what: ~P3 gamut, ~10k WP, gamma ~2.2. No HCFR or sensor required, only your bioassy to tell it’s not PQ.

    ???? I wasn’t sure anymore ???? Now you convinced me! Thanks!

    Actually – after thinking about it more – I’m still not convinced! Note that we only talk about HDR10.

    Do you remember this test I made in SDR and HDR Module = On in Service Menu?
    Take a look at the attached graphs: the 2 gamma graphs look pretty close to what I measured yesterday! Aren’t they tracking PQ instead? (I forgot to check it yesterday.)


    @j82k
    , are you sure that these graphs were made in HDR10 mode and not in SDR? 🙂

    So, at first to get know how our TV behaves, I’m interested in the following 20p greyscale graphs (by HCFR) in calibration (!) mode:
    – SDR: factory 1dlut + unity 3dlut
    – SDR: unity 1dlut + unity 3dlut
    – HDR: factory 1dlut + unity 3dlut
    – HDR: unity 1dlut + unity 3dlut

    After this we can start thinking about the next step.

    • This reply was modified 4 years, 3 months ago by chros.
    #21615

    János Tóth F.
    Participant
    • Offline

    @chros Just plot my .ti3 file (captured after full DDC reset) in excel and realize that even though there could be a conspiracy, it’s not the alienz (this time).

    • This reply was modified 4 years, 3 months ago by János Tóth F.. Reason: wrong chart
    Attachments:
    You must be logged in to view attached files.
    #21659

    chros
    Participant
    • Offline

    Actually – after thinking about it more – I’m still not convinced! Note that we only talk about HDR10.

    You were right, it’s definitely not PQ. But it behaves differently in SDR mode.

    So, at first to get know how our TV behaves, I’m interested in the following 20p greyscale graphs (by HCFR) in calibration (!) mode:<br>
    – SDR: factory 1dlut + unity 3dlut<br>
    – SDR: unity 1dlut + unity 3dlut<br>
    – HDR: factory 1dlut + unity 3dlut<br>
    – HDR: unity 1dlut + unity 3dlut
    After this we can start thinking about the next step.

    I played with it:
    – SDR: Cinema preset (OLED light 33, gamma 2.4, warm2, rest is default / recommended settings)
    – HDR: Technicolor (factory 1dlut + unity 3dlut); Cinema (unity 1dlut + unity 3dlut)

    Attached images (from top to bottom):
    – SDR: factory 1dlut + factory 3dlut (Cinema) (is there a factory 3dlut at all?)
    – SDR: factory 1dlut + unity 3dlut (Cinema)
    – SDR: unity 1dlut + unity 3dlut (Cinema)
    – HDR: factory 1dlut + unity 3dlut (Technicolor)
    – HDR: unity 1dlut + unity 3dlut (Cinema)

    Interestingly, in HDR mode, the shape of the curve is almost the same, but it’s shifted again between the 2 modes!

    So, as we saw, it behaves completely differently in HDR. So probably we have to create a 1dlut.
    So 2 test cases left back for HDR with large greyscale patchsets:
    – unity 1dlut + user 3dlut (calibration with DisplayCal + WBRGB patchset?)
    – user 1dlut (calibration with DisplayCal) + user 3dlut (WBRGB patchset)

    • This reply was modified 4 years, 3 months ago by chros.
    Attachments:
    You must be logged in to view attached files.
    #21677

    János Tóth F.
    Participant
    • Offline

    – SDR: Cinema preset (OLED light 33, gamma 2.4, warm2, rest is default / recommended settings)

    From those graphs it looks like gamma was set to 2.2 (and rightly so) not 2.4 as you stated. You should compare the neutral 1DLUT to the factory 1DLUT + 2.2 setting (not 2.4 or anything else).

    is there a factory 3dlut at all?

    If the panel response is assumed to be accurate (weather the 1DLUT is really calibrated or not) the 3DLUT should not change the tone response and white balance at all (beyond  small random inaccuracies/errors), so this shouldn’t come as a surprise.

    Coming to think of it, the earlier results look like colprof might assumed the display had a perfect  gamma 2.2 response and that’s why there was no meaningful gamma correction applied by the 3DLUT. I am not sure why but may be adding R,G,B ramps (some 33-65 patches per channel) could help. The next idea is disabling the curves in the XYZ profile or trying curves+matrix again (I can’t remember what went wrong with that).

    #21698

    chros
    Participant
    • Offline

    @Josh, I upgraded your tool (before I made the above tests) to 0.2.2 (that includes the unity 3dlut fix) and now I *do* see a clear difference between Cinema Home and Technicoor factory 1dlut + unity 3dlut, not like before (as I mentioned earlier). So if it’s the right behaviour then good job!

    And as we talked about it, can you double check the user 3dlut upload as well if you’ll have spare time? Thanks!

    – SDR: Cinema preset (OLED light 33, gamma 2.4, warm2, rest is default / recommended settings)

    From those graphs it looks like gamma was set to 2.2 (and rightly so) not 2.4 as you stated. You should compare the neutral 1DLUT to the factory 1DLUT + 2.2 setting (not 2.4 or anything else).

    No, it was set to 2.4 in the preset, but all measurements were done in Calibration mode (as the test case described it).
    What interesting is with SDR presets that when unity 1dlut *and* unity 3dlut is used the panel indeed has native gamma 2.2 response (no matter what settings you used in the preset).

    But not with HDR presets! The HDR module does some funky stuff 🙂

    is there a factory 3dlut at all?

    If the panel response is assumed to be accurate (weather the 1DLUT is really calibrated or not) the 3DLUT should not change the tone response and white balance at all (beyond  small random inaccuracies/errors), so this shouldn’t come as a surprise.

    Thanks.

    Coming to think of it, the earlier results look like colprof might assumed the display had a perfect  gamma 2.2 response and that’s why there was no meaningful gamma correction applied by the 3DLUT. I am not sure why but may be adding R,G,B ramps (some 33-65 patches per channel) could help.

    But take a look at the 2 HDR graphs (factory1d + unity3d and unity1d + unity3d) :
    – the shape of the curve is almost the same, the difference is that they are shifted!
    – and exactly that’s what we saw with unity 1dlut + matrix filled user 3dlut (compare it to the factory 1dlut + unity 3dlut), so it actually works! 🙂 The resulting curve is different a bit (causing a bit of black crush), but not much, maybe bigger greyscale patch count (255?) helps more. The bigger problem is that the colors are way off, e.g. green color (produced by the 3 RGB patches).

    Do we know exactly what Calman does in HDR? (I don’t have it)
    – what settings does it use for 1dlut? (gamma, etc)
    – and for 3dlut? (gamma, etc)

    The next idea is disabling the curves in the XYZ profile or trying curves+matrix again (I can’t remember what went wrong with that).

    I think it was a fog layer on the image and/or DCI-P3 coverage was decreased (~76%) (but I’m not sure either 🙂 ).

    • This reply was modified 4 years, 3 months ago by chros.
    #21705

    János Tóth F.
    Participant
    • Offline

    Ah, then it seems like calibration mode temporarily disables the user menu gamma control even if you don’t upload a 1DLUT (which disables it permanently).

    The bigger problem is that the colors are way off, e.g. green color (produced by the 3 RGB patches).

    So, for the third time: The green patch has high dE because the native gamut doesn’t fully cover DCI-P3. I used P3 for validation for two reasons: laziness (to create a reference ICC with native gamut primaries) and because CalMAN uses P3 as well (so the two validations reports are comparable). See my CalMAN screenshot below.

    Do we know exactly what Calman does in HDR? (I don’t have it)
    – what settings does it use for 1dlut? (gamma, etc)
    – and for 3dlut? (gamma, etc)

    It calibrates the tone response and white balance to user defined targets (it recommends Rec1886 for SDR, strictly sets gamma 2.2 for HDR and suggests D66 for both) through the 1DLUT and then creates a 3DLUT from measuring the calibrated responsne (in case of “matrix method” it supplements tone response measurements with the nominal calibration target, works as any other 3D color space profiler otherwise) against the user defined targets (suggests Rec 709 gamut for SDR, strictly sets Rec2020 for HDR, the tone response and white point targets are shared for both LUTs). 3D profiling methods (everything besides “matrix”) are disabled for HDR (at least in the current version).

    Attachments:
    You must be logged in to view attached files.
    #21725

    chros
    Participant
    • Offline

    The green patch has high dE because the native gamut doesn’t fully cover DCI-P3.

    🙂 I understand, but something is off with it on my B8.

    It calibrates the tone response and white balance to user defined targets (it recommends Rec1886 for SDR, strictly sets gamma 2.2 for HDR and suggests D66 for both) through the 1DLUT

    Thanks. What White Level (nits) does it use?
    In DisplayCal there’s an option for it under calibration: measured or specified value.

    There’s a fix in Displaycal (2-3 days ago): “When using a custom profiling testchart with very few or no dark RGB gray patches, try to better maintain slope of existing points during shaper curve generation.” As a result:
    – if you select small patches, it reverts to “curves + matrix”
    – I can’t create 5 patches (WBRGB) 3dlut anymore: “not enough chrominance data available” (or something similar)

    I noticed couple of things about madTPG:
    – if OSD is *not* on then it stops in HDR mode! (here’s a ticket for it in madvr) (no such problem with SDR!)
    — hence SDR madvr profile needs to be selected in DisplayCal!!! (not the HDR one)
    – sometimes DisplayCal can’t select the proper options in madTPG, so run it manually at first and select everything that is needed:
    — x stay on top
    — x disable OSD
    — x enable fullscreen
    — disable HDR mode
    — x disable 1dlut/3dlut

    I tried couple of measurements, but the result is always bad, so I have no clue how to proceed with HDR10 🙂

    #21726

    Josh Bendavid
    Participant
    • Offline

    Hi,

    A few more technical things.

    1. In order for any of the calibration and profiling to work properly, there has to be a proper mapping from 0.0-1.0 values being sent by ArgyllCMS and the first and last entries of the LUTs on the TV.  In order to get the proper alignment of values, I found that the following combination of black level, brightness and contrast values give consistent behaviour.
      • SDR modes:  Black level = Low, Brightness = 50, Contrast = 83 properly maps RGB values 64-1023 (16-255) onto the full range of the LUTs
      • HDR10 modes: Black level = Low, Brightness = 50, Contrast = 100 properly maps RGB values 64-940 (16-235) onto the full range of the LUTs
    2. In order to properly use this with e.g. madTPG, the madTPG output range should be set to 16-255 for SDR (or 16-235 for HDR)
    3. 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?)

    Having taken care of the above (and also some further minor tweaks of the floating point to integer conversion for the LUTs which should have a tiny effect and may or may not be relevant), here is a comprehensive set of validation runs on my C8 (with firmware 5.10.40)  with different combinations of factory/unity LUTs and LUTs from profiling and/or calibration in DisplayCal, and also some comparisons of Calibration mode on vs off.  All of the validation runs are being compared to Rec 709 with BT 1886 gamma, since this is my ultimate calibration target for SDR.

    For the uncalibrated validation runs, where the options are not grayed out from non-factory LUTs, I set “passthrough” settings for gamma/color gamut and white balance: gamma 2.2, color gamut wide, and white balance set to Cool with corresponding values in the service menu set to 192/192/192/64/64/64

    For calibration I explore several different options:

    1. Manual calibration of white point and OLED light for 100 cd/m^2 using Warm settings in service menu (and selecting Warm 2 in the user menu, together with BT1886 gamma and auto color gamut).  This requires OLED light = 26 on my set, and this is what I use for all of the other cases as well. (expert2_strongdither_factory1d_factory3d_contrast83_caloff_gamma1886_gamutauto_WBwarm2)
    2. Factory 1D LUT, 3D LUT from profiling:  (Using “passthrough” settings for white balance and gamma)  (expert2_strongdither_factory1d_profile3d_contrast83_caloff)
    3. Factory 1D LUT, 3D LUT from calibration+profiling (with calibration applied to 3D LUT) (expert2_strongdither_factory1d_calibrateprofile3d_contrast83_caloff)
    4. Unity 1D LUT, 3D LUT from profiling (expert1_weakdither_unity1d_profile3d_contrast83_caloff) (expert1_weakdither_unity1d_profile3d_contrast83_caloff)
    5. Unity 1D LUT, 3D LUT from calibration + profiling (with calibration applied to 3D LUT) (expert1_weakdither_unity1d_calibrateprofile3d_contrast83_caloff)
    6. 1D LUT from calibration, 3D LUT from profiling (expert1_weakdither_calibrate1d_profile3d_contrast83_caloff)

    For the calibration and/or profiling I’m using the Video  (D65, Rec 1886) preset with the following settings changed:

    • Display and Instrument Tab:
      • White Drift Compensation ON
      • Correction: Spectral WOLED (LG OLED 6-Series) (using an i1 Display Pro OEM)  (@janos-toth-f was the correction you created for the C8 significantly different?  I may try this one.  I don’t have the equipment to make my own unfortunately)
      • Calibration tab
        • Interactive display adjustment OFF
        • Black Point Correction 100%
        • Calibration Speed: High
        • (when profiling only, of course I set Tone Curve to “as measured”)
      • Profile Tab:
        • Profile Type : XYZ LUT (what would be the advantages/disadvantages of using XYZ LUT + Matrix instead?)
        • Test Chart: Auto-optimized 175
      • 3D LUT Tab:
        • Apply calibration ON for cases 3 and 5, OFF for cases 2,4,6
        • Rendering intent: Absolute Colorimetric with whitepoint scaling
        • 3D LUT File Format (IRIDAS .cube)
        • 3d LUT Resolution 33x33x33

    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)

    Currently we do not know how to keep the “strong” dithering with anything other than the factory 1D LUT, but with the factory 1D LUT one can temporarily switch to the “weak” dithering by starting calibration, then setting any of the calibration data immediately causes it to switch back to the “strong” dithering as long as the 1D LUT has not been touched.  This effectively means that from the above list of calibration options, 1,2, and 3 use the new “strong” dithering behaviour, and 4,5 and 6 use the old “weak” dithering behaviour.

    A few comments on the results:

    • Calibration mode on vs off makes no difference as long as “passthrough” settings are used for gamma/color gamut and white balance, (and the dithering behaviour is forced back to the “strong” mode by setting e.g. one of the extra gamma flags to its default 0 value in the non-factory 1D LUT case).  E.g. see expert2_strongdither_factory1d_factory3d_contrast83_caloff vs expert2_strongdither_factory1d_factory3d_contrast83_calon or  expert1_weakdither_unity1d_unity3d_contrast83_caloff vs expert1_weakdither_unity1d_unity3d_contrast83_calon
    • There is a significant difference in tone response between the two dithering modes as we already knew (see expert2_strongdither_factory1d_factory3d_contrast83_calon vs expert2_weakdither_factory1d_factory3d_contrast83_calon)
    • 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)
    • 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)
    • All of the calibrations have some issues with gamma increasing a bit very close to white.  In practice this is a non-issue because it’s in the whiter-than-white region, but could maybe be improved with more patches in calibration and/or profiling
    • The Calibration+profiling cases with non-factory 1D lut (calibrations 5 and 6) have a small issue with reduced gamma very close to black.  Maybe this could be fixed with more points for the calibration, or maybe related to limitations of the i1 Display Pro with ArgyllCMS in measuring values this close to black (period mode is used with max 10 second integration window)
    • Now that I have consistently calibrated modes with the two different dithering/near black behaviours I can compare the chrominance overshoot behaviour, and indeed calibrations 4,5,6 exhibit substantial flashing on the relevant test patterns, so for this reason I prefer to use calibration 3.

    I’ll start looking at HDR more closely next.

    Attachments:
    You must be logged in to view attached files.

    Calibrite Display Pro HL on Amazon  
    Disclosure: As an Amazon Associate I earn from qualifying purchases.

    #21735

    Josh Bendavid
    Participant
    • Offline

    And with the rest of the attachments.

    Attachments:
    You must be logged in to view attached files.
    #21741

    János Tóth F.
    Participant
    • Offline

    The green patch has high dE because the native gamut doesn’t fully cover DCI-P3.

    ???? I understand, but something is off with it on my B8.

    Could it be the way Alpha7 branded TVs handle the de-saturation of dark colors (the entire luma range is “W boosted”, not just above 100 nit)?

    I played around some more with the C9 (gave the curves+matrix another spin and tried somewhat different patch sets for the XYZ profile) and I can never get it quiet right (the grayscale is an effectively perfect match but the saturated primaries still hit dE 3-4). This time I used high quality cLUT tables for the ICM profile (33^3 with smoothing) and validated the ICM profile itself against the full DDC reset state (without uploading any LUT to the LG hardware or simulating some standard color space like DCI-P3 or Rec2020 in software).

    Honestly, I was surprised and happy to see that one of my first attempts with DisplayCAL HDR10 calibration produced sane results at all. Moreover, it looked adequate (at least from very limited subjective testing), hell, even preferable to the CalMAN results for my naked eyes (because I didn’t see either magenta banding on dark blues [it was present on my C8 after CalMAN calibration and we know it’s present with some factory calibrations as well], nor denaturation on dark colors [the factory calibration of my C8 did this, looked like sort of a white fog over the dark saturated colors]). Thus, I though a little fine-tuning could make it an obvious preferebale choice.

    But anything I tried so far (like adding more patches) only makes things worse compared to the workflow I shared a few days ago. As I expected, as soon as I step above the bare minimum, colprof starts requiring MMOOAARR patches to work reliably. For example, I tried adding R,G,B ramps to the W ramp and the result is insane, so I would need to start adding mixed colors. But even ~200 patches take a fairly long time (and the panel is not very stable).

    One thing I didn’t try yet is validating the CalMAN HDR10 calibration results (mainly in calibration mode with LG’s tone-mapping OFF but both hardware LUTs calibrated with the recommended settings). Because I have a hunch we won’t see much better dE numbers. Let’s not forget this is a WRGB panel where the W intentionally “boosts” the brightness at high levels (knowingly destroying color accuracy). Although the ALpha 9 banded TVs (like a C8) handle this much better in the SDR range than your B8 (which starts desaturating much sooner) but I guess even the C9 has notably worse color accuracy in the SDR luma range as well (in HDR mode) when compared to it’s SDR mode (let alone a real RGB display). And we can’t get around that. Well, may be an insanely huge patch set would do wonders but let’s not forget the profile and LUT generator algos were not created/optimized with this kind of display color space in mind. And much more importantly we know it’s simply impossible to keep these displays even remotely stable in HDR mode to collect tons of measurements.

    So, all in all, regarding dE numbers on validation reports and subjective opinions on movie content (known corner cases) I think the goal should be getting close enough to CalMAL’s 1DLUT + matrix and nothing more.

    Calibrating the hadrware 1DLUT with DisplayCAL (or applying the calibration to the 3DLUT, depending on which option causes less banding/artifacts on the final image) and then using a gamma+matrix profile with RGBW 1005 + 50% W (to paint the gamma curve for colprof) would probably reproduce the CalMAN results in terms of 3D color handling but I have no idea if the 1DLUT calibration would be better or worse. I can’t find the black frame insertion option in DisplayCAL. And CalMAN uses WOLED optimized measurement points whereas dispcal tries to find those in real-time (which could be better or worse depending on the panel but due to the stability problems of the panel, we should aim for a fast method).

    Thanks. What White Level (nits) does it use?

    There is no option to reduce it (neither with 1DLUT, nor with 3DLUT, unless erroneously) but this should be done with the OLED Light anyways (although it could, well, SHOULD iterate the OLED Light for the user automatically in SDR during the 1DLUT calibration because the white luma change with the white balance adjustments but it doesn’t, moreover, it let’s you iterate the first number AFTER the reset, not with the factory Warm2 which is just stupid).

    I can’t create 5 patches (WBRGB) 3dlut anymore: “not enough chrominance data available” (or something similar)

    Exactly. I didn’t understand how you managed to go with no mid-point patch. I tried that some years ago out of sheer curiosity, even though I understood why that can’t work. I guessed the current versions assume gamma 2.2 in the absence of any tone curve midpoints (or gamma 1.0 and you didn’t realize why the results are bad).

    I noticed couple of things about madTPG:

    Use madTPG to control NVAPI HDR with the HDR switch and use the dispread patch generator. There is no reason unless madTPG works in native 10bit with DisplayCAL and you prefer those percentage testchart values translated to RGB as close as possible but I think there is an option now to round the RGB numbers to 8bit (I am not sure if the percentages in the ti3 file are recalculated though).

    #21742

    János Tóth F.
    Participant
    • Offline

     

    1. In order for any of the calibration and profiling to work properly, there has to be a proper mapping from 0.0-1.0 values being sent by ArgyllCMS and the first and last entries of the LUTs on the TV.  In order to get the proper alignment of values, I found that the following combination of black level, brightness and contrast values give consistent behaviour.
      • SDR modes:  Black level = Low, Brightness = 50, Contrast = 83 properly maps RGB values 64-1023 (16-255) onto the full range of the LUTs
    2. In order to properly use this with e.g. madTPG, the madTPG output range should be set to 16-255 for SDR (or 16-235 for HDR)

    Contrast 83? Really? Not 85?
    What’s wrong with feeding 0-255 RGB straight from disread and setting the TV to HDMI Black: High, Contrast to 100 (for both SDR and HDR)? As much as I know, the LUTs work in Full RGB (whatever the previous step works with, it’s converted to Full RGB before the LUTs). Are there some bugs or rounding errors with Full RGB input?
    Even LG’s built-in pattern generator (2019) works with Full RGB and completely ignores the Contrast/Brightness sliders.
    You don’t have to mess with the 16-255 stuff if you set the Contrast to 100 in SDR. 85 is there to support SuperWhite which is practical useless (but it’s fine to revert to 85 after the calibration if you wish, just figure out the desired OLED Light before you temporarily set it to 100).

      <li style=”list-style-type: none;”>
      <li style=”list-style-type: none;”>
    • Correction: Spectral WOLED (LG OLED 6-Series) (using an i1 Display Pro OEM)  ( @janos-toth-f was the correction you created for the C8 significantly different?  I may try this one.  I don’t have the equipment to make my own unfortunately)
      • Profile Tab:
        • Profile Type : XYZ LUT (what would be the advantages/disadvantages of using XYZ LUT + Matrix instead?)

    Allegedly, some of the older WOLED EDR/ccss files was created in SDR mode with Rec709 mapping (Auto or calibrated) active during the characterization  (and probably also white balance adjustments to D65) which is not ideal. Moreover, there are small tweaks to the display panels in virtually every year (differently sized red subpixel, possibly different AR coatings, etc). I created the C8 and C9 ccss files in SDR mode right after a Full DCC Reset (CalMAN), so it’s as close to “native” as we can get. (I am not sure if the C9 upload was apprived yet.)

    #21746

    Josh Bendavid
    Participant
    • Offline

    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:

    SDR Black Level Low Brightness 50 Contrast 85: 66-1014

    SDR Black Level Low Brightness 50 Contrast 84: 65-1017

    SDR Black Level Low Brightness 50 Contrast 83: 65-1023

    SDR Black Level Low Brightness 51 Contrast 83: 64-1022

    SDR Black Level Low Brightness 50 Contrast 100:  64-937

    SDR Black Level Low Brightness 50 Contrast 99:  65-942

    SDR Black Level High Brightness 50 Contrast 100: 0-1020

    HDR Black Level Low Brightness 50 Contrast 100: 64-940

    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 and close to perfect for SDR (but SDR black level low brightness 50 contrast 85 is clearly clipping if one expects a 16-255 range)

    #21747

    chros
    Participant
    • Offline

    Honestly, I was surprised and happy to see that one of my first attempts with DisplayCAL HDR10 calibration produced sane results at all.

    🙂 Proper test case (screnshots, etc) ? 🙂

    the goal should be getting close enough to CalMAL’s 1DLUT + matrix and nothing more.

    Calibrating the hadrware 1DLUT with DisplayCAL (or applying the calibration to the 3DLUT, depending on which option causes less banding/artifacts on the final image) and then using a gamma+matrix profile with RGBW 1005 + 50% W (to paint the gamma curve for colprof) would probably reproduce the CalMAN results in terms of 3D color handling but I have no idea if the 1DLUT calibration would be better or worse.

    Agreed, let us know if you managed to get some decent result 🙂

    I can’t find the black frame insertion option in DisplayCAL.

    It’s only available for certain TPGs. That’s why I use madTPG.

    There is no option to reduce it (neither with 1DLUT, nor with 3DLUT, unless erroneously) but this should be done with the OLED Light anyways

    You misunderstood me: the question was regarding to HDR. Since we create a calibration (!) and in HDR the measured peak is >=700 nits, but we want to have gamma 2.2 and the whitepoint in HDR is around 94 nits … But you will understand the question when you try it out.

    Exactly. I didn’t understand how you managed to go with no mid-point patch.

    Well, me neither 🙂 I just wanted to simulate what Calman does with HDR 3dluts (measuring only WBRGB 5 patches).
    In previous DisplayCal versions I couldn’t do it from 4 patches (WRGB), but it worked from 5 patches (WBRGB). Not anymore.

    I created the C8 and C9 ccss files in SDR mode right after a Full DCC Reset (CalMAN), so it’s as close to “native” as we can get.

    Err, silly question from my side: wouldn’t you recommend to use your correction with normal SDR presets (without entering calibration mode and applying unity luts)?


    @Josh
    , I uploaded Janos’s corecction to this post.

    • This reply was modified 4 years, 3 months ago by chros.
    Attachments:
    You must be logged in to view attached files.
Viewing 15 posts - 136 through 150 (of 279 total)

You must be logged in to reply to this topic.

Log in or Register

Display Calibration and Characterization powered by ArgyllCMS