MadVR in use with LG OLED Thread

[SamuriHL]

Ummm, that would explain why you don't have the expected results. A TON of work has happened in HDR tone mapping in madvr and it's a fallacy to say it's "been about HDR to SDR". The latest test builds have changed a LOT in the HDR tone mapping functionality in madvr compared to the latest release build. Using passthrough is going to do exactly that, pass it through. Using the HDR tone mapping with HDR output checked, however, is going to use madvr's tone mapping solution. You may want to try it and see what you think.

[j82k]

When I said 'passthrough tone mapping' that is actually what I meant, using tone map with the 'output video in HDR format' box checked.

So which test build do you recommend? I know some of them have a ton of new options added for the purpose of testing and I don't want it to be too complicated.
Also, since you own a C8 and you're using test builds why don't you just try this yourself? Play a 4000 nit movie and see what the second last white WB adjustment point is. Then do the same with a 1000 nit movie.

[SamuriHL]

That's not passthrough. That's VERY VERY VERY confusing terminology to use. Call it HDR tone mapping with HDR output please. :)

The very latest test build is what I've been using and I like it. I use measurement files which means I ignore most of the new test options for the live algo. The only things I care about are setting the max target nit, highlight recovery strength, the fire option (it's a preference), and that's about it. And yea I can maybe try it out this weekend if I have time. Work is keeping me busy this week so not much time for testing a whole lot at the moment. I'd have to figure out which of my movies are 4000 nits and which are 1000. I guess I could run my measurement reading tool to figure that out.

[j82k]

Ok I got this to work now, madVR does change the metadata, even with the latest non-test build. Sorry for the confusion.

My problem was that for the metadata change to take affect, the TV needs to be kicked out of HDR mode first. Just hitting stop and play in MPC-HC isn't enough. You need to close the player or re-drag the file into it which causes the HDR logo to pop-up again on the TV.

Unfortunately this means that you can't directly compare passthrough and madVR HDR tone mapping by just switching back and forth between them as one of them will then use the wrong metadata. HDR needs to be retriggered each time for the metadata change to happen (HDR logo popping up on the TV).

[SamuriHL]

No worries. I'm glad it's straightened out!

Oh that's weird. For me with JRiver MC stopping playback and restarting it with play does exactly that, retriggering HDR. That's very strange that it doesn't work with MPC-HC.

[SamuriHL]

Ok, maybe I'm being a moron here, but, when playing an HDR movie, how do I see the WB that's being sent? God this HDR stuff confuses me at times.

[j82k]

expert controls - white balance - method: 20 points - code value

There are 20 adjustment points and the second last one changes depending on what metadata the TV receives. A different value here means that the TV uses a different tone mapping curve.

Here's some values I've found so far while playing Godzilla King of Monsters (4000 nits MDL).
Second last adjustment point value:

passthrough: 713
madVR set to 4000: 713
madVR set to 1000: 696
madVR set to 700: 669

So the TV apparently uses yet another tone mapping curve when receiving 700 nits metadata or rather no tone mapping because it can display 700 nits?
I previously assumed it would be just the same curve as my measured 1000 nits metadata one where the roll-off was almost like clipping already.


About the way HDR is triggered, I think something changed with one of the recent nvidia drivers. When I close the player the TV just stays in HDR mode until I click on the desktop or move some window around. I'm pretty sure it hasn't always been like that and would immediately be kicked out of HDR when closing MPC-HC.

[QBhd]

Okay so I have done some testing just now with the latest madVR release (not the HDR betas)… and I have some interesting results with my ancient R9 270X and LG C8

So to set this up I have a 4000 nits movie and a TV show that was 1561 (not 1000, but close enough I think). I ran both with my settings:
HDR tone mapping settings (http://prntscr.com/ovbwof)

So here is my results:

4000 nits HDR tone mapping using code value 696 (http://prntscr.com/ovbyl6)

1561 nits HDR tone mapping using code value 696 (http://prntscr.com/ovbz6a)

Now the interesting thing that happened when I switched to "passthrough HDR to display" was... nothing happened, it used the same code values as above. So I thought maybe I need to un-check "send HDR metadata to the display"... but all that did was keep the display in SDR (I'm guessing it's due to my old GPU).

Furthermore, I am able to play both files over my network using the built in player of the TV and here are the codes values used:

1561 nits using code value 696 (http://prntscr.com/ovc37d)

4000 nits using code value 713 (http://prntscr.com/ovc3nu)

Just some info to share

QB

[SamuriHL]

expert controls - white balance - method: 20 points - code value

There are 20 adjustment points and the second last one changes depending on what metadata the TV receives. A different value here means that the TV uses a different tone mapping curve.

Here's some values I've found so far while playing Godzilla King of Monsters (4000 nits MDL).
Second last adjustment point value:

passthrough: 713
madVR set to 4000: 713
madVR set to 1000: 696
madVR set to 700: 669

So the TV apparently uses yet another tone mapping curve when receiving 700 nits metadata or rather no tone mapping because it can display 700 nits?
I previously assumed it would be just the same curve as my measured 1000 nits metadata one where the roll-off was almost like clipping already.


About the way HDR is triggered, I think something changed with one of the recent nvidia drivers. When I close the player the TV just stays in HDR mode until I click on the desktop or move some window around. I'm pretty sure it hasn't always been like that and would immediately be kicked out of HDR when closing MPC-HC.

Thank you for this. Much appreciated! I'll have to do some testing, as well. I have an advantage I think because I can throw the disc in my UB820, which as we know on the OLED setting tends to tone map ~1000 nits, and switch between my HTPC and the UB820 to compare. Not an exact comparison, I'll grant you, but, it will be an interesting test anyway. I should have time to play around with this friday night or saturday. I'm very curious now.

[Warner306]

Ok I got this to work now, madVR does change the metadata, even with the latest non-test build. Sorry for the confusion.

My problem was that for the metadata change to take affect, the TV needs to be kicked out of HDR mode first. Just hitting stop and play in MPC-HC isn't enough. You need to close the player or re-drag the file into it which causes the HDR logo to pop-up again on the TV.

Unfortunately this means that you can't directly compare passthrough and madVR HDR tone mapping by just switching back and forth between them as one of them will then use the wrong metadata. HDR needs to be retriggered each time for the metadata change to happen (HDR logo popping up on the TV).

Good that you got it sorted. For some reason QBhd's results aren't matching.

[SamuriHL]

Good that you got it sorted. For some reason QBhd's results aren't matching.

They won't. They're using the latest release build of madvr which has had ALL KINDS of fixes in the betas. So the fact that it doesn't match doesn't surprise me now that j82k is using the latest beta.

[j82k]

I don't have a clue about AMD cards. Do they maybe have similar metadata problems as nvidia had in the past? 696 was the number one would always get with the 1000 nits bogus metadata or windows HDR.

I wasn't using the test builds and still got it to work.

edit:
I can set the target peak nits up to 760 in madVR while keeping the "669" value, at 770 target peak it switches to "696". So 760 target peak nits might be a good value to use for people whose C8 can reach that as I assume that is the point up to where the TV will do no or the least amount of tone mapping.

The fastest way to make the metadata change happen is to disable/enable 'output video in HDR format', so no need to restart the player like I did earlier.

[SamuriHL]

AMD cards use the windows hdr which probably does still send fake metadata at 1000.

That's awesome about the max target nit. I can't wait to play this weekend!

Also I really want to thank you for all this awesome information!! This has been a great learning experience for me and I truly appreciate it!

Sent from my SM-G975U using Tapatalk

[quietvoid]

I have also been testing madVR (latest beta) on my LG C8 and obtain similar results.
With dynamic target nits, using 10 000 nits as a maximal target causes clipping when the target peak nits are automatically set to 1000+.

I've ended up using 750 peak and maximal target nits to avoid clipping.
Even using 800 as maximal target has some clipping.

[huhn]

afaik AMD uses AGS for HDR and not the OS else there would be no need to add this API in madVR if the OS HDR is used anyway.

[SamuriHL]

Hmm I could have sworn there was a discussion about the fact that HDR mode on nvidia had a slight advantage over amd due to the nvidia HDR api vs amd using the windows os HDR. I readily admit I could be 100% wrong though.

Sent from my SM-G975U using Tapatalk

[chros]

There is no standard for tone mapping, but almost all current HDR displays start the roll-off point at some point...
Yes, thanks, but do you understand that I've talked about ABL algos?

So 760 target peak nits might be a good value to use for people whose C8 can reach that
In what window size? 2/5/10/20% ... ?

[j82k]

In what window size? 2/5/10/20% ... ?

I guess that is up to you what window size to use and if you want to account for some ABL by using a larger one or not. I haven't given this much thought and usually use a 5-8% window when measuring peak brightness. I think the way ABL works is that it just evenly dims the whole picture so it shouldn't cause any clipping in highlight but I'm really not sure on this.

[j82k]

I just went back to the good and old 385.28 nvidia driver and guess what....

Metadata changes happen instantly now! I can change madVR's "HDR target peak nits" value and see the C8s second last WB value change immediatley while the movie is playing. So the metadata change happens on the fly without me having to disable/enable HDR.

This is also how I remembered things and is the reason why I was confused and thought madVR didn't change the metadata. Again just an Nvidia driver problem...

I think all the newer Nvidia drivers behave like this, meaning metadata change requires retriggering of the HDR signal whereas with 385.28 it just happens on the fly...

[SamuriHL]

Fascinating. But not entirely surprising.

Sent from my SM-G975U using Tapatalk

[SamuriHL]

expert controls - white balance - method: 20 points - code value

There are 20 adjustment points and the second last one changes depending on what metadata the TV receives. A different value here means that the TV uses a different tone mapping curve.

Here's some values I've found so far while playing Godzilla King of Monsters (4000 nits MDL).
Second last adjustment point value:

passthrough: 713
madVR set to 4000: 713
madVR set to 1000: 696
madVR set to 700: 669



I wanted to come back to this. I SOOOOO appreciate this. I have confirmed exactly what you're seeing. madvr up to 760 is using 669, above that 696, and then 713. I used Aquaman to test 4000 nits and A Wrinkle In Time to test 1000 nits and the results were consistent. To be clear to those who may be looking at this information later down the road, this is with dynamic tone mapping on the C8 turned OFF. I am EXTREMELY pleased with the results we're getting. I've yet to watch a whole movie with these settings but the quick tests I've done so far look outstanding. I do want to compare with the UB820 this weekend when I get some time and just take a look at the same movies. To make it a "fair" comparison, I'll probably set madvr target nits to 1000 cause that's what the UB820 uses for OLED tone mapping. Nonetheless, this is great info and really helps us a lot.

[chros]

I think all the newer Nvidia drivers behave like this, meaning metadata change requires retriggering of the HDR signal whereas with 385.28 it just happens on the fly...
:D I wanted to tell you this, but I didn't know what GPU you have. Which one?
And indeed, everything applies immediately.

@Manni: a huge thanks to you for your endless driver testing and finding the one (!) that is the best for Pascal cards!!!

I can set the target peak nits up to 760 in madVR while keeping the "669" value, at 770 target peak it switches to "696". So 760 target peak nits might be a good value to use for people whose C8 can reach that as I assume that is the point up to where the TV will do no or the least amount of tone mapping.

Here's some values I've found so far while playing Godzilla King of Monsters (4000 nits MDL).
Second last adjustment point value:

passthrough: 713
madVR set to 4000: 713
madVR set to 1000: 696
madVR set to 700: 669

So the TV apparently uses yet another tone mapping curve when receiving 700 nits metadata or rather no tone mapping because it can display 700 nits?

So, here are the second last code values on B8 (DTM off in B8, tested with 4000 and 1000 nits content, madvr latest stable release version):
705 : passthrough 4000
705 : pixelshader 2501 - 10000
692 : passthrough 1000
692 : pixelshader 761 - 2500
669 : pixelshader 100 - 760

So, what does it mean exactly?
- there are slightly different code values on B8 (https://www.rtings.com/tv/reviews/lg/b8-oled#comparison_140) and C8 (https://www.rtings.com/tv/reviews/lg/c8-oled#comparison_140) (I assume due to the max brightness difference)
- the same 760 nits value can be applied in B8 as well!!! (the above mentioned brightness difference doesn't matter)
- I checked and 760 nits value looks the best (vs 500 / 2000 / etc.), I haven't compared to passthrough yet

[ashlar42]

This is curious, as I initially understood things as you described them here to be. But then I read different opinions.
Is it possible to completely disable LG's tone mapping, if madVR does all the work already? In the case of preanalyzed files, it should do that on a frame by frame level, which makes me think it should provide the best results. Better probably than what Dolby Vision can achieve (if that works on a scene by scene basis, as I remember).At the beginning of the month I asked this but was told it couldn’t be done. Am I right in understanding that it’s more or less what you’ve been discussing in the past few pages? Using madVR for tone mapping in order to avoid LG’s built in functionality?

Also, on a different subject, does using Smooth Motion in madVR improve 24fps material playback with regard to motion resolution? Theoretically the frames updating on the screen would be 120 and not 24, which should make things better for a sample and hold display. And with 120 frames to work with, blurring should be minimal, right?

[QBhd]

That might be true if you could do 120 hz... And even then I doubt blending would happen.

QB

[SamuriHL]

At the beginning of the month I asked this but was told it couldn’t be done. Am I right in understanding that it’s more or less what you’ve been discussing in the past few pages? Using madVR for tone mapping in order to avoid LG’s built in functionality?



That's what we've been discussing, yes, but I want to be clear here. There's no way to disable the tone mapping built in to the lg tv. That being said by sending the tv metadata that uses the max target nit that the tv can display it seems to be avoiding triggering the more aggressive tone mapping curves of the built in tone mapping. This is about the best situation we can hope for. And it looks really good.

Sent from my SM-G975U using Tapatalk

[j82k]

Found another really strange behavior of the C8 using the HDR color clipping test pattern from here:
https://drive.google.com/drive/folders/11iYlTaULc_MUV2YL50DUewbFsSXY1r8p

There is a big difference of clipping points with certain colors depending on the color format output.
It's especially noticeable with red and green. I used passthrough HDR and levels were of course set correctly.


Red:
RGB full/limited - clips at ~590
YCbCr 444/422 - clips at ~820

Green:
RGB full/limited - clips at ~780
YCbCr 444/422 - clips at ~590

With other colors the difference wasn't that big but what's really strange is that red clips much earlier with RGB output but with green it's the opposite, it clips much earlier with YCbCr. These big differences can't be minor color conversion rounding errors right? Anyone able to confirm or explain this?? :confused:


:D I wanted to tell you this, but I didn't know what GPU you have. Which one?
And indeed, everything applies immediately.

I have a 1050ti.


So, here are the second last code values on B8 (DTM off in B8, tested with 4000 and 1000 nits content, madvr latest stable release version):
705 : passthrough 4000
705 : pixelshader 2501 - 10000
692 : passthrough 1000
692 : pixelshader 761 - 2500
669 : pixelshader 100 - 760

So, what does it mean exactly?
- there are slightly different code values on B8 (https://www.rtings.com/tv/reviews/lg/b8-oled#comparison_140) and C8 (https://www.rtings.com/tv/reviews/lg/c8-oled#comparison_140) (I assume due to the max brightness difference)
- the same 760 nits value can be applied in B8 as well!!! (the above mentioned brightness difference doesn't matter)
- I checked and 760 nits value looks the best (vs 500 / 2000 / etc.), I haven't compared to passthrough yet

I wouldn't rely on rtings peak measurements. When you look at their C7 burn-in test there are peak differences of more than 100 nits between the 6 TVs even though they're all the same model. Panel variance I guess.

I assumed a different WB value shown means that the TV uses a different tone mapping curve but I could be wrong. Looking at HDR white clipping pattern I can't detect a change when going from 760 to 761 in madVR even though that causes the TV to show a different WB value.

[chros]

That's what we've been discussing, yes, but I want to be clear here. There's no way to disable the tone mapping built in to the lg tv. That being said by sending the tv metadata that uses the max target nit that the tv can display it seems to be avoiding triggering the more aggressive tone mapping curves of the built in tone mapping.
That's correct. As we saw above, there are 3 tone curves implemented in 8 series (just like the 3 modifiable ones in 9 series). And by setting 760 nits in madvr the less aggressive is used but what it means in reality is another question. :) Not to mention the tons of options that can be changed in madVRhdrMeasure86 :)

I'll upload some selected clips later for those who wants to compare the result with pure passthrough (+ DTM).

[ashlar42]

That might be true if you could do 120 hz... And even then I doubt blending would happen.Well, clearly we need to wait for HDMI 2.1 videocards but I don't understand why you say blending wouldn't happen. There is the "always" option for smooth motion, isn't there?

[QBhd]

24x5=120... So nothing to blend... As far as I understand smoothmotion

QB

[chros]

24x5=120... So nothing to blend... As far as I understand smoothmotion
It depends on the refresh rate of the TV you use:
- in your example: 23p -> you're right
- but the guys are experimenting in 60p (!) -> blending

There is a big difference of clipping points with certain colors depending on the color format output.
It's especially noticeable with red and green. I used passthrough HDR and levels were of course set correctly.
...
With other colors the difference wasn't that big but what's really strange is that red clips much earlier with RGB output but with green it's the opposite, it clips much earlier with YCbCr. These big differences can't be minor color conversion rounding errors right? Anyone able to confirm or explain this?? :confused:
Sorry, but I don't understand the test case: you mentioned passthrough as well. So, does it only happen with madvr's pixeslhader?

I wouldn't rely on rtings peak measurements. When you look at their C7 burn-in test there are peak differences of more than 100 nits between the 6 TVs even though they're all the same model. Panel variance I guess.
Good point, I guess I have to dig out my meter during the weekend. :)

I assumed a different WB value shown means that the TV uses a different tone mapping curve but I could be wrong. Looking at HDR white clipping pattern I can't detect a change when going from 760 to 761 in madVR even though that causes the TV to show a different WB value.
I'm pretty sure you are right. There are 3 different tone curves implemented in 8 series and the one that belongs to 100-760 nits in madvr is the less aggressive.
I also can't notice the difference between 760 and 761 (maybe with the test clips below).

[j82k]

Sorry, but I don't understand the test case: you mentioned passthrough as well. So, does it only happen with madvr's pixeslhader?


I'm saying that there is a pretty big difference with saturated colors depending on the color format you send to the TV (RGB or YCbCr) and I don't understand why and I don't know which one is correct.

This is with regular HDR passthrough, so no madVR tone mapping involved...

[chros]

The purpose of this test to compare HDR passthrough (with and without LG's DTM) to madvr's tonemapping with "Output video in HDR format".

Prerequisities:
- use "Cinema" preset (not Cinema Home) for HDR10 content on the TV
-- if this preset isn't calibrated then reset it and turn off every unnecessary processing
- download the test video files (~5.6 GB) from mega.nz (https://mega.nz/#F!n5dzgQbJ!A99MVeafyffB1qK6-ahrTg)
-- there are 10 files all together: 2 files in 4 categories (below 760 / 1000 / 4000 / 10000 nits) and 2 others
- download madVRhdrMeasure86 (http://madshi.net/madVRhdrMeasure86.zip) and use the settings attached to this post (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-204.html#post58458354)
-- create "ShowHdrMode" empty directory in madvr directory (to display more HDR related stats in OSD)
-- it's based on Neo-XP's quoted values (note he uses an OLED that doesn't have HDR)
-- "highlight recovery strength" is set to very high (are you nuts setting produce artifacts sometimes)
-- "apply dynamic clipping" is turned on and only set to 25! (above it clips lot of things and confuses scene detection)
-- "no compression limit" 100 supposed to mean that madvr doesn't touch content in 0-100 nits
-- "dynamic tuning" 50 results in more vivid image (compared to default 75)
-- I'm not sure about "maximal target nits" value
-- and I don't know anything about the tons of option at the bottom :)

Testing:
- compare every clip in:
-- passthrough without LG's DTM
-- pixeshader without LG's DTM
-- passthrough with LG's DTM
- look out for:
-- madvr's tonemapping values in OSD
-- quality of the image
-- potential sharpness differences
- the 2 clips below 760 nits are interesting: take a look how madvr behaves

Happy testing!

[Asmodian]

24x5=120... So nothing to blend... As far as I understand smoothmotion

Smooth motion does not work that way. When enabled it always blends to perfectly match the refresh rate, it does not delay the first frame presentation for a screen update. It always does a weighted blend perfectly timed to the screen refresh. The three options are used to control this behavior but if says enabled in the OSD it is always blending.

Also, on a different subject, does using Smooth Motion in madVR improve 24fps material playback with regard to motion resolution? Theoretically the frames updating on the screen would be 120 and not 24, which should make things better for a sample and hold display. And with 120 frames to work with, blurring should be minimal, right?

I do like smooth motion for 24 fps on OLEDs, the very quick sample and hold looks better with the blends between frames. Especially for content without motion blur, like Anime. This is at only 60 Hz too, at 120 Hz I just use smooth motion all the time.

This does not help motion resolution at all, smooth motion can only make motion resolution worse. As a technology smooth motion trades some motion resolution for smoothness, but at 120 Hz the loss in motion resolution is negligible (the increase in smoothness is less significant as well).

[chros]

This is with regular HDR passthrough, so no madVR tone mapping involved...
This was the part that wasn't clear, thanks, I'll check it during the weekend as well.

[SamuriHL]

I'm saying that there is a pretty big difference with saturated colors depending on the color format you send to the TV (RGB or YCbCr) and I don't understand why and I don't know which one is correct.

This is with regular HDR passthrough, so no madVR tone mapping involved...

I've noticed this before, as well, and I don't know what is going on there. The color format should NOT make a difference. I never knew how to measure it before now, but, it was quite clear in the picture that it's different when switching between them. HTPC users are going to say RGB is correct. However, most consumer equipment is going to drive the signal with YCbCr so, I don't know what's "correct" in this case. It's very strange though. I should check the UB820 in RGB mode and see if it does the same thing to rule out other potential causes of the issue.

[j82k]

I should check the UB820 in RGB mode and see if it does the same thing to rule out other potential causes of the issue.

Can the UB820 output both? RGB and YCbCr?

It would be interesting if it produces the same difference between RGB and YCbCr as a pc does. Just make sure to turn every tone mapping or picture enhancements off.

Try it especially with the red pattern from here:
https://drive.google.com/drive/folders/11iYlTaULc_MUV2YL50DUewbFsSXY1r8p

[Warner306]

Found another really strange behavior of the C8 using the HDR color clipping test pattern from here:
https://drive.google.com/drive/folders/11iYlTaULc_MUV2YL50DUewbFsSXY1r8p

There is a big difference of clipping points with certain colors depending on the color format output.
It's especially noticeable with red and green. I used passthrough HDR and levels were of course set correctly.


Red:
RGB full/limited - clips at ~590
YCbCr 444/422 - clips at ~820

Green:
RGB full/limited - clips at ~780
YCbCr 444/422 - clips at ~590

With other colors the difference wasn't that big but what's really strange is that red clips much earlier with RGB output but with green it's the opposite, it clips much earlier with YCbCr. These big differences can't be minor color conversion rounding errors right? Anyone able to confirm or explain this?? :confused:

YCbCr and RGB are different color spaces of different sizes. I don't think that explains a large difference in color clipping, though. YCbCr converted to RGB is slightly larger than PC RGB converted to display RGB.

RGB untouched by madVR and presented in PC mode should be the most accurate rendition without having to account for any errors by the GPU conversion to YCbCr or the display using the wrong color matrix for RGB to YCbCr 4:2:2 to RGB.

[Warner306]

That's correct. As we saw above, there are 3 tone curves implemented in 8 series (just like the 3 modifiable ones in 9 series). And by setting 760 nits in madvr the less aggressive is used but what it means in reality is another question. :) Not to mention the tons of options that can be changed in madVRhdrMeasure86 :)

I'll upload some selected clips later for those who wants to compare the result with pure passthrough (+ DTM).

It might be worth asking for the original BT.2390 tone curve as an option for HDR output. Someone stated in the madVR thread that the version of BT.2390 tone curve used by madVR is the same one used by DisplayCal with a modified curve shape at the top end. This retains more specular highlight detail but leaves less luminance for the highlights compared to the original BT.2390 curve. I think the version used by madVR was picked because it works well for HDR to SDR tone mapping.

This could just be hearsay, but the poster is knowledgeable about DisplayCal curves.

[Warner306]

The purpose of this test to compare HDR passthrough (with and without LG's DTM) to madvr's tonemapping with "Output video in HDR format".

Prerequisities:
- download the test video files (~5.6 GB) from mega.nz (https://mega.nz/#F!n5dzgQbJ!A99MVeafyffB1qK6-ahrTg)
-- there are 8 files all together: 2 files in 4 categories (below 760 / 1000 / 4000 / 10000 nits)
- download madVRhdrMeasure86 (http://madshi.net/madVRhdrMeasure86.zip) and use the settings attached to this post (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-204.html#post58458354)
-- it's based on Neo-XP's quoted values (note he uses an OLED that doesn't have HDR)
-- "highlight recovery strength" is none on purpose (Neo-XP suggested it)
-- "apply dynamic clipping" is turned on and only set to 25! (above it clips lot of things and confuses scene detection)
-- "no compression limit" 100 supposed to mean that madvr doesn't touch content in 0-100 nits
-- "dynamic tuning" 50 results in more vivid image (compared to default 75)
-- I'm not sure about "maximal target nits" value
-- and I don't know anything about the tons of option at the bottom :)

Testing:
- compare every clip in:
-- passthrough without LG's DTM
-- pixeshader without LG's DTM
-- passthrough with LG's DTM
- look out for:
-- madvr's tonemapping values in OSD
-- quality of the image
-- potential sharpness differences
- the 2 clips below 760 nits are interesting: take a look how madvr behaves

Happy testing!

Some of NEO-XPs values would only apply to HDR to SDR tone mapping.

[SamuriHL]

Can the UB820 output both? RGB and YCbCr?

It would be interesting if it produces the same difference between RGB and YCbCr as a pc does. Just make sure to turn every tone mapping or picture enhancements off.

Try it especially with the red pattern from here:
https://drive.google.com/drive/folders/11iYlTaULc_MUV2YL50DUewbFsSXY1r8p

It can indeed. That thing is a beast. :D I'll see if I can get to that this weekend when I have more time to play around.

[SamuriHL]

It might be worth asking for the original BT.2390 tone curve as an option for HDR output. Someone stated in the madVR thread that the version of BT.2390 tone curve used by madVR is the same one used by DisplayCal with a modified curve shape at the top end. This retains more specular highlight detail but leaves less luminance for the highlights compared to the original BT.2390 curve. I think the version used by madVR was picked because it works well for HDR to SDR tone mapping.

This could just be hearsay, but the poster is knowledgeable about DisplayCal curves.

I think that's why they worked on the Highlight strength recovery option because you do indeed lose a bit of luminance with madvr's tone mapping. I crank that option to Are you nuts? for that very reason.

[SamuriHL]

Some of NEO-XPs values would only apply to HDR to SDR tone mapping.

And a lot of them are only going to apply to the live algorithm, as well. I tend to not use the live algo myself and instead prefer to create measurement files. The improvemenets in the live algo have been remarkable, but, you are exactly right in that they seem to be more targeted to HDR->SDR. That's not to say you COULDN'T use them with HDR output, I suppose.

[j82k]

RGB untouched by madVR and presented in PC mode should be the most accurate rendition without having to account for any errors by the GPU conversion to YCbCr or the display using the wrong color matrix for RGB to YCbCr 4:2:2 to RGB.

Should yes, but this is an LG TV. :rolleyes:

RGB + PC mode + HDR is like the worst combination and produces terrible banding on the C8. :mad:

[quietvoid]

The purpose of this test to compare HDR passthrough (with and without LG's DTM) to madvr's tonemapping with "Output video in HDR format".

Prerequisities:
- download the test video files (~5.6 GB) from mega.nz (https://mega.nz/#F!n5dzgQbJ!A99MVeafyffB1qK6-ahrTg)
-- there are 8 files all together: 2 files in 4 categories (below 760 / 1000 / 4000 / 10000 nits)
- download madVRhdrMeasure86 (http://madshi.net/madVRhdrMeasure86.zip) and use the settings attached to this post (https://www.avsforum.com/forum/24-digital-hi-end-projectors-3-000-usd-msrp/2954506-improving-madvr-hdr-sdr-mapping-projector-204.html#post58458354)
-- it's based on Neo-XP's quoted values (note he uses an OLED that doesn't have HDR)
-- "highlight recovery strength" is none on purpose (Neo-XP suggested it)
-- "apply dynamic clipping" is turned on and only set to 25! (above it clips lot of things and confuses scene detection)
-- "no compression limit" 100 supposed to mean that madvr doesn't touch content in 0-100 nits
-- "dynamic tuning" 50 results in more vivid image (compared to default 75)
-- I'm not sure about "maximal target nits" value
-- and I don't know anything about the tons of option at the bottom :)

Testing:
- compare every clip in:
-- passthrough without LG's DTM
-- pixeshader without LG's DTM
-- passthrough with LG's DTM
- look out for:
-- madvr's tonemapping values in OSD
-- quality of the image
-- potential sharpness differences
- the 2 clips below 760 nits are interesting: take a look how madvr behaves

Happy testing!

I've tested with the clips and got to the same conclusions, have an LG C8.
Changing "dynamic tuning" has no effect for me.

With target nits at 760, passthrough looks the same as pixel shaders for clips that are around 1000 nits.
In the John Wick clip, the lights on the ambulance get a bit brighter using passthrough and LG DTM but no highlight detail loss.

For the 'The Meg' clip, there's clipping with both passthrough and pixel shaders (LG DTM on/off as well) with your settings.
Had posted about this here: https://forum.doom9.org/showthread.php?p=1882574#post1882574

Can be fixed with "maximal target nits" at 760. With that, there's more highlight detail resolved with LG DTM ON.

In Max Max: Fury Road, using passthrough causes specular highlights to become grey (reflection on the car) while pixel shaders keep it white.
That's about it, there's not much difference on that one.

About LG's DTM, overall it seems to be better to keep highlight detail but in lower brightness scenes, it acts like madVR's "apply dynamic clipping" and makes midtones brighter.

However for some reason my WB 20 points show 669 and 1023 all the time so something might be wrong on my side.
Sometimes it's at 713, and everything looks fine when sending 2000 nits to the display instead of clipping though.
Edit:
Yep, with passthrough I can get it to switch to 713 when resending metadata.
With pixel shaders, it doesn't seem to switch at all with the dynamic target nits.
Sadly going back to 385.28 did not fix it, still sticks to 669 even though madVR tonemaps to 2000 nits.

[chros]

RGB untouched by madVR and presented in PC mode should be the most accurate

Should yes, but this is an LG TV. :rolleyes:
@jk82 is right, LG does some crazy things, e.g. there's no proper chroma 4:4:4 in PC mode at 4k resolution (and this is just 1 example). It seems it's more important for them to work on ABL algos than picture quality :devil:

RGB + PC mode + HDR is like the worst combination and produces terrible banding on the C8. :mad:
Yes, but that's what I am using :)

I think that's why they worked on the Highlight strength recovery option because you do indeed lose a bit of luminance with madvr's tone mapping. I crank that option to Are you nuts? for that very reason.
Nep_XP stated that currently it does more harm than good, since it was implemented back then when DTM wasn't in madvr yet, hence he disabled it.

Some of NEO-XPs values would only apply to HDR to SDR tone mapping.
Which ones? (But I don't think so, see below.)

I tend to not use the live algo myself and instead prefer to create measurement files. The improvemenets in the live algo have been remarkable, but, you are exactly right in that they seem to be more targeted to HDR->SDR.
:D But that's the same for measurement files as well. Only 1 guy had 200 nits screen, Neo-XP's 150 nits, Manni's 135 nits, all the others are way less (even 50 nits)!
What nits setting did you use when created your measurement files?

Not to mention that's exactly what we want to do as well - the only diff is the way higher nits setting -, the problem is we can't disable the TV's tonemapping.

But if you insist, you can quickly create measurement files for the uploaded clips as well. But in that case post a screenshot of your settings, please.

This retains more specular highlight detail but leaves less luminance for the highlights compared to the original BT.2390 curve. I think the version used by madVR was picked because it works well for HDR to SDR tone mapping.
Well, I don't think it's worth it, there's only minimal difference between passthrough and pixelshader (see below).

[chros]

Yep, with passthrough I can get it to switch to 713 when resending metadata.
With pixel shaders, it doesn't seem to switch at all with the dynamic target nits.
Sadly going back to 385.28 did not fix it, still sticks to 669 even though madVR tonemaps to 2000 nits.
Strange it works fine here, even when I switch between passthrough and pixelshader (I haven't noticed this before).
Which player do you use? I use MPC-BE / HC.

Changing "dynamic tuning" has no effect for me.
Indeed, I don't see any difference between 50 and 200 (not even in numbers in OSD), and there was a huge diff when I used madmeasure78 with SDR TV.
Maybe the bottom scene detection values, or did it get broken?

With target nits at 760, passthrough looks the same as pixel shaders for clips that are around 1000 nits.
That's what I noticed as well, if there's any difference at all.

In the John Wick clip, the lights on the ambulance get a bit brighter using passthrough and LG DTM but no highlight detail loss.
Same here.

For the 'The Meg' clip, there's clipping with both passthrough and pixel shaders (LG DTM on/off as well) with your settings.
Had posted about this here: https://forum.doom9.org/showthread.php?p=1882574#post1882574

Can be fixed with "maximal target nits" at 760. With that, there's more highlight detail resolved with LG DTM ON.
Thanks, I'll modify the "maximal target nits" to 760, and I'll update the settings screenshot.

In Max Max: Fury Road, using passthrough causes specular highlights to become grey (reflection on the car) while pixel shaders keep it white.
That's about it, there's not much difference on that one.
Good spot! I haven't noticed it. :) And this one is a 10000 nits title.

About LG's DTM, overall it seems to be better to keep highlight detail but in lower brightness scenes, it acts like madVR's "apply dynamic clipping" and makes midtones brighter.
Does "apply dynamic clipping"? I haven't noticed it. Which clip(s) and when?
It should modify the protected 0-100 nits range.
Note that this option is broken since the beginning and madshi didn't fixed it yet, hence the lower 25 value is used. Maybe lowering it helps? 15/10?

Although I only tested 3 of them but there's not much difference between passthrough (without DTM) and pixelshader at 760 nits.

[chros]

I added to the above test requirements (https://forum.doom9.org/showthread.php?p=1882771#post1882771) the following:
- TV settings
- create "ShowHdrMode" empty directory in madvr directory (to display more HDR related stats in OSD)

Just checked the 2 clips (Hunger Games and Alita) that are under 760 nits with pixelshader:
- measured and tonemapped nit values are not always the same
- why? I thought if the content is below the set 760 nits then it shouldn't modify it.
- maybe because of the scene detection algo ...

[chros]

Found another really strange behavior of the C8 using the HDR color clipping test pattern from here:
https://drive.google.com/drive/folders/11iYlTaULc_MUV2YL50DUewbFsSXY1r8p

There is a big difference of clipping points with certain colors depending on the color format output.
It's especially noticeable with red and green. I used passthrough HDR and levels were of course set correctly.


Red:
RGB full/limited - clips at ~590
YCbCr 444/422 - clips at ~820

Green:
RGB full/limited - clips at ~780
YCbCr 444/422 - clips at ~590

The result on B8 using PC mode, 12 bit output and HDR passthrough (I only compared RGB full vs YCbCr422), there's definitely a big difference between the two.


RGB full YCbCr422
white: 860 1000
red: 530 500
green: 820 710
blue: 900 530
cyan: 820 740
magenta: 780 740
yellow: 820 1000


Note: on my B8 HDR10 Cinema preset is *not* calibrated, everything is at its default setting.

[j82k]

RGB + PC mode + HDR is like the worst combination and produces terrible banding on the C8. :mad:

Yes, but that's what I am using :)


Seriously how can you tolerate that? :rolleyes:

I just tried pc-mode HDR again a few days ago. Played the UHD of Brightburn, skipped to some dark scene and it looked like some low bitrate TV broadcast. Even turning madVR's 'reduce banding artifacts" to high didn't make it any better, which makes sense as the banding wasn't in the source but was produced by the TV.

[SamuriHL]

:D But that's the same for measurement files as well. Only 1 guy had 200 nits screen, Neo-XP's 150 nits, Manni's 135 nits, all the others are way less (even 50 nits)!

What nits setting did you use when created your measurement files?



Not to mention that's exactly what we want to do as well - the only diff is the way higher nits setting -, the problem is we can't disable the TV's tonemapping.



But if you insist, you can quickly create measurement files for the uploaded clips as well. But in that case post a screenshot of your settings, please.



You are confused I'm afraid. [emoji846] Your question about what nit setting I used tells me so. You're talking about soulnights measurement modification tool. I am not. His tool is used to dynamically change the measurement file for those doing HDR to SDR. That's not what I want. I create the measurement file with madvr and do not touch it. This is very different then what the dynamic algo guys are doing. I agree with neo-xp about his settings for the dynamic algo but I've been using straight measurement files unmessed with since they were added to drive my HDR output.

Sent from my SM-G975U using Tapatalk