MadVR in use with LG OLED Thread

[quietvoid]

Played around with ZRO and PGen 1.3, it's pretty fast to read patches.
Much better than Calman, HCFR is somewhat close.
Only tested SDR on a monitor, will try HDR on the C2 this weekend hopefully.

Managed to run DeviceControl on my Linux machine, so that's cool.
I don't really need it with ZRO, though. Useful to shutdown the Pi.

ZRO is really limited, so might try integrating the PGen in DisplayCal.

[chros]

Originally Posted by SamuriHL

Lol! Always triple check the settings in each picture mode.

Yeah, it seems so

Originally Posted by quietvoid

Played around with ZRO and PGen 1.3, it's pretty fast to read patches.
Much better than Calman, HCFR is somewhat close.

Nice to hear it! So Calman is so buggy, laggy and I don't know how a big company can get away with a product like this.
madVR/madTPG also got a big speedup at some point, see below.

Originally Posted by quietvoid

Only tested SDR on a monitor, will try HDR on the C2 this weekend hopefully.

What and how do you want to deal with HDR10?

Originally Posted by quietvoid

Managed to run DeviceControl on my Linux machine, so that's cool.
I don't really need it with ZRO, though. Useful to shutdown the Pi.

Nice! Not sure why it was implemented in perl though

Originally Posted by quietvoid

ZRO is really limited, so might try integrating the PGen in DisplayCal.

Woow, this would be cool! (Although I don't have PGen and maybe never will )
DisplayCal still has issue with x64 version of ArgyllCMS, sometimes it just throws an error after the long profiling session If you can take a look why and fix it?

About madVR/madTPG, still SDR profiling: it got way faster (when exactly???).
Using the preset default ~1545 patches, White level drift comp is on, Maximize RGB diff is set at Patch sequence (to make it faster on OLED) the rest is default, profiling time with:
- old stable release: ~50 minutes
- beta 163: ~35 minutes
verifying with XXL video with 755 patches:
- old stable release: ~22 minutes
- beta 163: ~15 minutes

I also used the latest Argyll 2.31 32bit version and now all is good (using the 2018 ccss spectral correction, maybe AIPP was also on at that time??? ).
The resulting whitepoint is still completely random: sometimes it's 6480K or below, sometimes it's 6520K or above (I prefer the latter), so multiple profiling sessions need to be run to have the desired result.

I haven't tried HDR10 yet with the new beta, that's what I'll do next.

[quietvoid]

Originally Posted by chros

What and how do you want to deal with HDR10?

2pt for HDR10, probably 2pt + config for Dolby Vision.
Might try 22pt Dolby Vision eventually.

[SamuriHL]

22pt DV works very well. I've done it to my G2 and just did a 20pt for my C8 last weekend. Of course I can't validate anything on the G2 in DV but it's certainly better than using the iTPG. PGen 1.3 on an RPI4 absolutely rocks. ColourSpace is getting LG support built in, as well. I'm hoping that means uploading LUTS and all of that will be controllable from CS at some point. No more DeviceControl at all if that happens. The next firmware release should allow us to calibrate 22pt HDR on the C2/G2. Would be curious to see how that goes using 10bit patches. I still need to deal with SDR on the G2 one of these weekends. I've had zero time for anything lately. Right now I don't have it dialed in very well for SDR modes.

[aron7awol]

Originally Posted by chros

I haven't tried HDR10 yet with the new beta, that's what I'll do next.

FYI, I ran into an issue using madTPG with HDR on later betas, I want to say it was 159 at the time. I forget exactly what the issue I ran into was, something like saturation sweeps appearing to show severe gamut compression even when set to HDR passthrough IIRC. I ended up downgrading to 113 for this purpose and everything worked great, so I didn't dig into the issue any further. Will be interesting to see if you have a similar experience.

[or231]

chros, I tried to upload 3dlut on a lg c1 with bscpylgtv but got error "3D LUT Upload not supported by tv model OLED48C1". I'm going to get lg 42c2 soon and wanted to know if there is an option to do it with bscpylgtv or other free way.

[chros]

Originally Posted by or231

chros, I tried to upload 3dlut on a lg c1 with bscpylgtv but got error "3D LUT Upload not supported by tv model OLED48C1". I'm going to get lg 42c2 soon and wanted to know if there is an option to do it with bscpylgtv or other free way.

Newer models are not officially supported, however you can apply this patch to add support for them, but for your own responsibility.
I only uploaded 1dlut into HDR10 and DoVi Cinema presets and that worked fine.
Note that start_calibration method doesn't work for me either in HDR10, it works fine in SDR, I haven't tried DoVi yet. You can start calibration mode using DeviceControl and the free 2021 PQ param upload template.

[or231]

Originally Posted by chros

Newer models are not officially supported, however you can apply this patch to add support for them, but for your own responsibility.
I only uploaded 1dlut into HDR10 and DoVi Cinema presets and that worked fine.
Note that start_calibration method doesn't work for me either in HDR10, it works fine in SDR, I haven't tried DoVi yet. You can start calibration mode using DeviceControl and the free 2021 PQ param upload template.

Thank you so much, I do not have a c1 anymore, so I can not try it right now, but I will get c2 and will try to upload a sdr 3dlut.

[aron7awol]

Has anyone here made a verification test chart which is only P3 within 2020?

[quietvoid]

Originally Posted by aron7awol

Has anyone here made a verification test chart which is only P3 within 2020?

Not exactly sure what you're looking for. Test patterns? Patch sets?

[aron7awol]

Originally Posted by quietvoid

Not exactly sure what you're looking for. Test patterns? Patch sets?

Patch set to verify a display using DisplayCal with only P3 within 2020 patches so that P3 displays don't have tons of out-of-gamut patches generating high dE.

Separately I want to also filter them to some maximum RGB value, like, say 60% or 65% or 70% or 75% so we aren't asking for patches that are brighter than the display can reach too, but that's easy enough.

I'm almost done working on one that I am trying to manually convert and filter out of the XXXL video patchset. I'll share it when it's done in case it is useful to anyone, but was curious if anyone had already done something similar, and maybe better than what I'll end up with.

[quietvoid]

It's something I've looked into doing, but I couldn't find the right math to figure out the correct RGB range for P3.
Not sure it exists (publicly) but I'd be interested if you manage to do it. Otherwise I might try again later.

Surely DisplayCAL (or ArgyllCMS) has some scripts to generate the ti1 patch sets.
https://argyllcms.com/doc/targen.html

[aron7awol]

I ended up with about 470 patches after converting the XXXL video patchset to P3 within 2020 and then filtering out everything above 60%. I'm doing a test run now to confirm it works as expected. If it does, I'll do some filtered to higher luminance levels and then publish all of them here.

[aron7awol]

Alright, so something went wrong in my first run process based on what I'm seeing for results (still a bunch of patches beyond P3). I'll share everything I've done so far. Graeme Gill suggested I use his icclu tool to convert from P3 RGB to L*a*b* and then to 2020 RGB, which makes sense.

So I started with the 1005-patch "XXXL verification testchart (video)" which is verify_video_xxxl.ti1
Opened that up and pulled out the RGB values and put them in a separate text file called rgbinput.txt
icclu -pl -ff -s 100 -ir ACES_P3.icm < rgbinput.txt > laboutput.txt
Then opened that up and pulled out the L*a*b*values and put them in a separate text file called labinput.txt
icclu -pl -fb -s 100 -ir Rec2020.icm < labinput.txt > rgboutput.txt
Then we also need the XYZ values to populate the testchart file, so I pulled the resulting RGB values out and put them in a separate text file called rgbinput2.txt
icclu -px -ff -s 100 -or Rec2020.icm < rgbinput2.txt > xyzoutput.txt
Optional: Combined the RGB and XYZ values into CSV and removed anything with R,G, or B value >60 (they are in %) to keep everything <240 nits for now.
Converted the RGB and XYZ values into the space-delimited format for testchart .ti1 format and put them into the .ti1 appropriately.
Loaded the testchart into DisplayCal to make sure everything looked normal (it did), then sorted by "Maximize lightness difference" and saved. This is also optional, but figured it was a good step to make sure DisplayCal was happy with the result anyway.

Known potential issues:
1. The XXXL video testchart was probably designed with SDR 709 in mind, which isn't ideal for our HDR purposes, but as a proof of concept I wasn't really concerned if the spacing of patches was optimal by using a pre-conditioning profile of P3 or anything else like that. I don't think this will cause any major issues.
2. When viewing the profiles in DisplayCal, ACES_P3.icm uses Gamma 2.6 tone response curve, DisplayP3.icm uses sRGB, and Rec2020.icm uses Rec.709. This seemed like it could cause some big problems, and so this is what I'm leaning toward as the issue currently. I thought about creating synthetic profiles of P3 and 2020 using 2084 tone curve before I went through this process. I'll try that now. Hopefully that straightens things out.

Edit: Just did some quick manual testing with P3 primaries and the synthetic profiles. I think the conversion is working correctly now! I'll post the testchart as soon as I'm done.

Here's the full 1005 original patches, transformed to P3 within 2020 and in .csv format. From here it can be filtered down (what I'm about to do) and then placed into a testchart file.
https://mega.nz/file/hEkDzAYK#F2Cl1C...C1nyXaA8TfSHNQ

And here's the resulting testchart limited to RGB values of 60% max (369 patches):
https://mega.nz/file/RMcTlDaL#3F4TbH...61NV02dJIvgPxA

And here's the resulting testchart limited to RGB values of 70% max (482 patches):
https://mega.nz/file/xE8GUQRI#hDcYG7...DjmnhwcK7xunss

So if this works we should be able to generate a testchart preconditioned to the synthetic P3 2084 profile and have better spacing and also not have to discard a bunch of generated patches like I did. I'll test it shortly...

Update: the 369 patch filtered chart I shared works really well! Nothing seems to be out of gamut and so average dE is much better. However, my first attempts to generate a new full testchart using my synthetic P3 profile for preconditioning has resulted in targen hanging.

Update2: We can use the P3 D65 2084 10000 nit profile for preconditioning when we generate testcharts.

[Kuler087]

did anyone get the C2/G2 new update that supposedly fixes overly bright DV cinema mode? Is it really fixed?
I read that the firmware is out but still nothing on my TV

[SamuriHL]

Yes, it's fixed. And there's yet another new firmware out today but because people were morons, the one person who has access to the internal release list is no longer posting them so we have no clue what's been fixed. People suck.

[Kuler087]

awesome thanks! I can watch DV again.

[SamuriHL]

The one thing they've not fixed is the DV verify but. I don't know if it's fixed in the latest version or not as I've not applied it yet. But I doubt it. I don't think calibration related issues are ever going to get fixed now.

[Kuler087]

Just did the update and with quietvoid's rpu test file, L1 is no longer clipped (internal player). Nice! And it looks like the L1 response with my X800m2 has been improved as well but it is still different than my internal player and shield.
SDR black levels are no longer raised.
this is a great firmware update.

@SamuriHL I thought we could verify in ZRO? sorry i am really not an expert in the calibration stuff.

[SamuriHL]

We could if lg fixes the bug in their firmware on the 2022 series. Right now no one can verify dv with any equipment because dv verify mode is broken.

Sent from my SM-G998U1 using Tapatalk