madVR - high quality video renderer (GPU assisted)

[mclingo]

yeah, we've taken up far too much of this thread with this apologies.

[Sunset1982]

ok thanks! that what I did. it's weird they don't do 10 bit in RGB but only in ycbcr

really? where did you got that from?

HI, perhaps this is later panel, I have DEFINATELY have ABL disabled mate.

I'll see if I can find the discussion about this and get some details.


For at least LG OLED 2016+, ABL cannot be disabled, only ASBL.


the issue I had was the whole panel would suddenly dim in a movie less often but mostly on web sites in windows, this was super annoying, this is ABL, since disabling this it no longer happens.

looks like i did it later than I thought, here is the the discussion back in 2016

https://www.avforums.com/threads/lg-ef950v-owners-and-discussion-thread-part-4.2047799/page-40#post-24331874

Yeah, this dimming in static elemts is ASBL. It is deactivated by the TPM option in the service menu. ABL is defeated by a low oled light setting (or calibration) like you said. Mine is calibrated to 140 nits, means a setting of 35 oled light.


I wonder how I could further improve picture quality on my 2018 C8 oled with madvr.

PC mode on lg oleds only work in 4:4:4 in 60hz mode and only when input is labeled "PC". in 23/24hz mode it wil not work in 4:4:4 RGB.

That they are only 8 bit in RBG is new to me.

My setup is GPU RGB 4:4:4, madvr 0-255 and tv set to Blacklevel high.

Maybe I should try ycbcr, but that should be one more conversion step... :confused:

I tried to find a good solution for hdr files. Experimented a bit with the new .16 build but couldn't find a good setting for now.

If there are more oled/madvr user, maybe we can open a new oled/madvr thread were we can exchange settings and impressions...

[mclingo]

another thread I think if people want to discuss this further, i'd be interested to know how ive managed to get rid of ABL on mine with my OLED light at 60.

[mclingo]

https://forum.doom9.org/showthread.php?p=1853185#post1853185


New thread here, if it gets used enough it may get sticky.

[famasfilms]

That they are only 8 bit in RBG is new to me.



I believe to select 12 bit on an LG OLED then you have to be playing a movie, have madVR display mode switching active, then alt tab to Nvidia control panel and select 12 bit.

That's how I do it anyway

[mytbyte]

Sounds like MicroLED is gonna be a godsend when it finally arrives..
It's probably more efficient to output in 12bpc? Someone here will have the answer to that.

What leads you to believe that? Industry insiders claim it's niche only and will stay niche, they will never be able to bring LED subpixels down to the size required for smaller screens at marketable price...

[nevcairiel]

What leads you to believe that? Industry insiders claim it's niche only and will stay niche, they will never be able to bring LED subpixels down to the size required for smaller screens at marketable price...

"Smaller screens" as in what? The funny thing about display technology is that the resolutions don't really change much these days, only size does.

So we have 4K smart phone displays in 5", and 4K TVs in >50". Maybe it won't work in smartphones, but TVs is quite another ballpark entirely.

[mclingo]

there is a physical limitation in size that micro LEDs can drop to apparently as they currently have to installed one by one by robots and according to some sources this just isnt possible at the small scales to produce at 40-65 inch main stream TV, have read that a few places.

maybe they will find some way of 3d printing them.


https://www.tomsguide.com/us/micro-led-faq,review-5282.html

[YGPMOLE]

The nit value to use into the "target nit" box in madVR should be exactly the amount of the nit value the TV is capable of, am I right?

Does exist some sort of conversion table of that value for PJs, due to the fact in this case we are talking about Lux and reflecting screen, not of emitting display? Or even an aproximative suggestion?

If I well recall, the madVR default is 200 nit for PJs and 400 for digital display: are this for a correct calibration according to the HDR standard nit target?

[mytbyte]

The nit value to use into the "target nit" box in madVR should be exactly the amount of the nit value the TV is capable of, am I right?

Does exist some sort of conversion table of that value for PJs, due to the fact in this case we are talking about Lux and reflecting screen, not of emitting display? Or even an aproximative suggestion?

If I well recall, the madVR default is 200 nit for PJs and 400 for digital display: are this for a correct calibration according to the HDR standard nit target?

yes, target nits should be the measured nits of the brightness of 100% brightness pattern...this is a bit tricky when it comes to plasma :D

I'm pretty sure the default target is 200 for TVs/monitors as well if you "let MadVR decide"...I don't know of any table for lux to reflected nits conversion but it surely should take distance to screen and screen gain into account as well as other factors specific to different projectors, which is a stretch, so you'll have to assume nit value of a typical projector with the given lumen output, a couple of tens of nits of difference are really not that impactful, IMHO.

[madshi]

Please no more discussion here about MicroLED, ABLs etc, unless it's really madVR related, thanks!

The nit value to use into the "target nit" box in madVR should be exactly the amount of the nit value the TV is capable of, am I right?
Not really. Pick any value which looks good to you. Lowering the target nit will make the image brighter, on the cost of losing HDR highlights.

[jmone]

Great work on the HDR -> SDR work, looks good across a range of screens (JVC x7500, LG OLED, Sony LCD). Also tested and working well with a range of GPU's (a lowly iGPU (NUC), 970, 1070 using some preset settings.bin that nev just added over at JRiver Media Center for various "levels" of GPU).

Thanks to Madshi and all over at AVS.

[jmone]

Is it possible to bring up the madVR Settings GUI from a command line?

[alps006]

Anyone try 411.70 yet to see if the HDR issues have been resolved? I'm downloading it now.

EDIT: Nope....still a broken mess for HDR. How nice. Back to 399 I go.

Just an FYI. I got really frustrated with Winows 10 having so many issues recently with nvidia drivers. I switched back to Windows 8.1, to tell you the truth, with the latest nvidia driver, playback of 4K HDR is fantastic without even a single glitch. I have correct composition rate (In Windows 10 it was always 23,980). HDR- SDR conversion is also working great. Really happy with the results. Thanks madshi for his nice work.

[huhn]

when i change the gamma in calibration it changes the image.
this is unexpected behaviour because if i calibrated a screen to gamma x i expect madVR to honor this and not change something related to the image.

example why this is a problem.

when i put 2 screen next to each other one with gamma 2.4 and one with gamma 2.2 than i expect an image that is mathematical different with a gamma of 0.2.

but this can't be true because if i change the gamma setting under calibration the image changes and to get this results madVR has to send both screen a bit identical image.

the gamma of the image should not be change just by the calibration setting it should only be changed in conjunction with "color & gamma -> enable gamma processing". that's assuming it is just a gamma setting and has nothing todo with internal HDR calculation. if it does something different in HDR calibration well... than this is not the correct place to do that.

edit: this is an issue with HDR-> SDR conversation. SDR is working as expected.

[SamuriHL]

Just an FYI. I got really frustrated with Winows 10 having so many issues recently with nvidia drivers. I switched back to Windows 8.1, to tell you the truth, with the latest nvidia driver, playback of 4K HDR is fantastic without even a single glitch. I have correct composition rate (In Windows 10 it was always 23,980). HDR- SDR conversion is also working great. Really happy with the results. Thanks madshi for his nice work.That's awesome. I wish I could go back to 8.1 but it's not a really for my htpc unfortunately. Glad it's working for you though! Madshi always says to use 8.1.

Sent from my Pixel XL using Tapatalk

[mytbyte]

@huhn: but you need to be able to tell madvr the target gamma of the tv, and you can set this independently for each screen , also HDR-SDR conversion is also some kind of "gamma processing" as under "color & gamma" section...

Here I would like to point out that addition of the option for BT.1886 would be in order for TV's with non-0 blacks

Sent from my GM 5 Plus d using Tapatalk

[huhn]

but you need to be able to tell madvr the target gamma of the tv, not quite sure what you're aiming at...

what is the point of telling the gamma if it is not honored?
if madVR changes the image than your gamma is not your gamma anymore it is something else.

here I would like to note that addition of the option for BT.1886 would be in order.


that's impossible because bt 1886 can be quite a lot of different effective gamma.

[mytbyte]

what is the point of telling the gamma if it is not honored?
if madVR changes the image than your gamma is not your gamma anymore it is something else.



that's impossible because bt 1886 can be quite a lot of different effective gamma.

Second point: Damn you're right, in that case madvr should be told the measured black and white level of the tv but that falls under "processing" section actually..

On the first point - still don't understand why you think it's not honored? There is nothing to be honored - HDR processing needs to know the TV's gamma, while SDR video has no gamma defined and gamma setting has no effect, but you need to manipulate HDR gamma.

Sent from my GM 5 Plus d using Tapatalk

[huhn]

for what do you know what type of gamma a TV has? and why should you instantly change something. change means you don't get your "gamma" anymore.

the HDR -> SDR conversation produces an SDR image.
if you tick the default setting "disable calibration controls for this display" you will get on a gamma 2.2 calibrated TV a relative gamma of 2.2 on a 2.4 a gamma 2.4 you know what i mean. because every screen gets a bit identical image and everything is working as it should.

but as soon as you select "this display is already calibrated" with an option that is not 2.2 you will get an altered image. so the 2.4 calibrated TV doesn't get an 2.4 gamma relative to a gamma 2.2 calibrated TV. HDR or not this is incorrect if 2.4 is not 2.4 relative to 2.2 it is not 2.4 it's that simple.

don't change the image by just setting a gamma at this option or user don't get there "gamma" of choice.

[mytbyte]

@huhn: I think I understand now what you want to say but default values are for people who don't know their gamma, white and black levels and that (must be) ok. But HDR levels are absolute and those values won't be converted to absolute brightness levels unless you specify actual SDR gamma you calibrated your tv to if you have the possibility to do that. I know, you'll say that top brightness differs from Tv to Tv (even HDR models) anyway so why stick to absolute levels but for my way of thinking, HDR-SDR conversion is also designed to simulate, on an SDR TV with high brightness, as close as possible how it would look on a HDR display, not just losely convert to SDR, if you calibrated your SDR tv and know it's characteristics. Of course, it means multiple processing, quality depends on TV's gamma precission and lut bitdepth and thus banding is a risk.

Sent from my GM 5 Plus d using Tapatalk

[Klaus1189]

Just an FYI. I got really frustrated with Winows 10 having so many issues recently with nvidia drivers. I switched back to Windows 8.1, to tell you the truth, with the latest nvidia driver, playback of 4K HDR is fantastic without even a single glitch. I have correct composition rate (In Windows 10 it was always 23,980).

You do know it's the Nvidia driver which is broken?
Why is 399.xx working fine for HDR? Because the 399.xx driver is fine.

You get another installer for Win 8.1 which is also smaller:

Version: 411.70 WHQL
Freigabedatum: 2018.9.27
Betriebssystem: Windows 7 64-bit, Windows 8.1 64-bit, Windows 8 64-bit
Dateigröße: 469.19 MB
--------------------------------------------------------------------------------------------
Version: 411.70 WHQL
Freigabedatum: 2018.9.27
Betriebssystem: Windows 10 64-bit
Dateigröße: 520.35 MB

But I have the same opinion that Win 8.1 is better suited for HTPC use, but since I am using Win10 for over 3 years now, I think Nvidia should be able to deliver a working driver and not brk things repeatedly.

I stay with Win 10 for the next time.

[madshi]

madVR v0.92.17 released

http://madshi.net/madVR.zip

* modified/simplified HDR tone mapping settings page
* small HDR tone mapping saturation improvement
* OSD now also shows the measured luminance of the current frame (in addition to the average)
* fixed: render & present queues didn't always fill in Windows 10 build 1803
* fixed: using XySubFilter sometimes resulted in black screen / freeze
* fixed: using HDR "processing" resulted in dark and red-ish image
* fixed: using BT.601/709 gamma curve with HDR tone mapping produced gray-ish image
* fixed: settings dialog sometimes crashed on display mode / custom mode tab
The HDR settings dialog changes *could* maybe introduce some new bugs, but I hope not. I've modified the HDR settings to make it less confusing. I don't want users to think that they somehow lose HDR by doing tone mapping.

[magic144]

Thanks for the swift XySubFilter-associated fix madshi, very much appreciated!

[jespermart]

I get all sort of display devices in madvr, for the moment i have Yamaha RX2070, Intel Vertex twice and Visio M50-E1
and for the moment only the Visio M50 are active but I don't own a Visio M50, so what is happening with my devices and how do i get rid of an active device I don' own?

[ashlar42]

No, because you *can* test HDR on your Kuro, by using madVR's HDR -> SDR conversion.


First of all, I never stated that *all* TVs are not smart enough, I'm usually careful enough to talk about "many" or "most" TVs. There may be TVs which are smart enough. Maybe the latest Panasonic OLED could be, I don't know.

If the TV is not smart enough, it will simply apply a compression curve to every pixel. If madVR has already applied tone mapping before, that means the TV will compress the content even further. It might not be a dramatic problem, but it's far from optimal.


What does ABL have to do with tone mapping? I don't think that the tone mapping algo in the OLED TVs is smart enough to consider ABL. As such, there's no reason to think that madVR couldn't provide a better tone mapping result than the internal system.

You don't seem to understand the whole tone mapping concept. What do you think the 2017 LG OLED does internally when you feed it HDR? In case you don't know: It applies tone mapping! Same as what madVR does when you activate HDR -> SDR conversion.

Probably I should rename the options in madVR, because they seem to be confusing for users. People seem to think that HDR TVs can somehow do magic, and letting madVR convert HDR to SDR will produce worse results than if the HDR TV receives the full HDR content. In reality the HDR TV will do the same processing madVR does - only in worse quality.
I fear there's a misunderstanding.

First: I've never doubted that madVR could do a better tone mapping job than what internally LG OLEDs achieve. The internal SoC is most likely no match for a powerful enough GPU. *And* I have better faith in your algorithms than LG's. :)

You might be right that LG's algorithm isn't smart enough to take into account ABL. But that's no reason for madVR not to do it, correct? Assuming RTings values are correct (and they do provide them for many TVs out there), it would be a great option to have to provide even better tone mapping, wouldn't it? Having peak nits values according to "screen space" occupied by high nits content. Maybe it's too hard to do that calculation in real time, I don't know. Or maybe it's useless, I don't know.
Although, if it's impossibile to disable tonemapping on the TV, from what you state I conclude that it would be better to turn off the option in madVR anyway, am I right?

Lastly, although I know the above was not directed to me, I have pretty clear in mind the fact that all OLEDs tone map HDR content. There's 1000 nits mastered content and 4000 nits mastered content. Peak nits highlights in OLEDs don't even reach 900, so tone mapping is a must.

[Ver Greeneyes]

* fixed: render & present queues didn't always fill in Windows 10 build 1803
Just tested and I can confirm that my problems are gone! Thanks for the great work :)

[thighhighs]

windowed mode OSD (rendering time) still is broken for me. I think Windows 10 1803 (x64) introduce this bug. OSD show ~9ms rendering, but this impossible for my old Kepler GPU. Also i'm get different stast for FSE with same settings: ~9ms (wrong) vs ~20ms FSE (looks like truth).This bug is now fixed :thanks:

[madshi]

I fear there's a misunderstanding.

First: I've never doubted that madVR could do a better tone mapping job than what internally LG OLEDs achieve.
Yes, you did! ;) You wrote:

> I doubt that madVR can provide a better tone mapping
> results than the internal system in an OLED screen

You might be right that LG's algorithm isn't smart enough to take into account ABL. But that's no reason for madVR not to do it, correct? Assuming RTings values are correct (and they do provide them for many TVs out there), it would be a great option to have to provide even better tone mapping, wouldn't it? Having peak nits values according to "screen space" occupied by high nits content. Maybe it's too hard to do that calculation in real time, I don't know. Or maybe it's useless, I don't know.
Taking the ABL into account would only make sense if I knew exactly how the ABL was implemented. But I don't. It could differ from LG to Panasonic to Sony (all using the same LG OLED panel). It could differ from LG generation to LG generation. It could even differ from firmware version to firmware version!

If I don't know the *exact* way the ABL works, then trying to adjust to the ABL may make things worse than better.

RTings might measure some thing, but they don't measure everything. E.g. does the ABL react to the brightest subpixel? Or to the combined brightness of all subpixels? What happens if there's very bright green, but blue and red are off? Which number of pixels exactly have to surpass a specific threshold to activate ABL? And is it a fixed threshold, or a "fuzzy" logic? I would basically need access to the exact formulas used by the ABL, for this to make any sense.

Although, if it's impossibile to disable tonemapping on the TV, from what you state I conclude that it would be better to turn off the option in madVR anyway, am I right?
No. Even when sending HDR to the display, double tone mapping *could* be better than not letting madVR doing any tone mapping at all. Or maybe not. It's impossible to say without testing it. Furthermore, you can let madVR tone map and then send the video as SDR to the display. This way tone mapping in the TV should definitely be disabled.

Lastly, although I know the above was not directed to me, I have pretty clear in mind the fact that all OLEDs tone map HDR content. There's 1000 nits mastered content and 4000 nits mastered content. Peak nits highlights in OLEDs don't even reach 900, so tone mapping is a must.
That's not true, either. There are several UHD HDR Blu-Rays out there which have a MaxCLL value (brightest subpixel in the whole movie) below what current OLEDs can do. So a good OLED tone mapping implementation could detect this situation and then completely disable tone mapping.

Thanks for the swift XySubFilter-associated fix madshi, very much appreciated!
Just tested and I can confirm that my problems are gone! Thanks for the great work :)
This bug is now fixed :thanks:
:)

I get all sort of display devices in madvr, for the moment i have Yamaha RX2070, Intel Vertex twice and Visio M50-E1
and for the moment only the Visio M50 are active but I don't own a Visio M50, so what is happening with my devices and how do i get rid of an active device I don' own?
The devices come from the EDIDs that your GPUs or the OS report. Yamaha RX2070 sounds like your receiver? What kind of display are you using? It seems the EDID of your display reports itself as "Visio M50", for whatever reason. Of course you can manually rename the display in the madVR settings. madVR just sets the names by default, based on what the EDID reports.

[huhn]

@huhn: I think I understand now what you want to say but default values are for people who don't know their gamma, white and black levels and that (must be) ok. But HDR levels are absolute and those values won't be converted to absolute brightness levels unless you specify actual SDR gamma you calibrated your tv to if you have the possibility to do that. I know, you'll say that top brightness differs from Tv to Tv (even HDR models) anyway so why stick to absolute levels but for my way of thinking, HDR-SDR conversion is also designed to simulate, on an SDR TV with high brightness, as close as possible how it would look on a HDR display, not just losely convert to SDR, if you calibrated your SDR tv and know it's characteristics. Of course, it means multiple processing, quality depends on TV's gamma precission and lut bitdepth and thus banding is a risk.

Sent from my GM 5 Plus d using Tapatalk

i'm not even saying this option should be removed. the problem is the place it is used.

i even can turn the whole thing on the top.
what about bt 1886 or a 3D LUT so we just do nothing in this case?

or why is gamma 2.4 used in the first place over 2.2 by user in a dark room? ambient light sources and so much more gamma related things. nothing of this changes even if the source is HDR. even the brightness in an SDR file is absolute if someone would follow would follow it exactly and even that doesn't change that a gamma of 2.1 and lower can be quite handy depending on other factor.

and how does any of this help user that don't know there gamma? that the calibration tab not something to guess about.

[Warner306]

The only thing the user should know is that this setting will not impact SDR content. Most of that content today is 2.40 based on the calibration of the most popular mastering monitors out there. You have to guess at what your calibrated gamma might be for HDR -> SDR because there is no way for madVR to measure this. Even then, you may get the best result with a gamma other than 2.20. For some people (me included), 2.20 crushes black when PQ is converted to pure power gamma. Not everyone would understand they can experiment with this setting without upsetting SDR content.

[jespermart]

The devices come from the EDIDs that your GPUs or the OS report. Yamaha RX2070 sounds like your receiver? What kind of display are you using? It seems the EDID of your display reports itself as "Visio M50", for whatever reason. Of course you can manually rename the display in the madVR settings. madVR just sets the names by default, based on what the EDID reports.

I have a samsung 59" plasma screen and a Jvc X5000 connected via a HdFury Vertex to a Yamaha RX-A2070 reciever

[huhn]

would be nice if gamma would be such a simple topic than bt 1886 wouldn't be the "new" thing.

gamma 2.4 is a "bat cave" gamma and that's not a good idea in a daylight filled room and one of the reason is not generally correct and why there is no correct answer. getting the same gamma as a mastering screen is not always getting you proper result on a screen.

[blu3wh0]

On the topic of gamma, my SDR mode has always been calibrated to BT.1886 (which is power 2.40 on an OLED), and has been the perfect option from a pitch dark to a dim/low light room. As long as there wasn't direct sunlight or glare, details were properly visible. However, HDR mode is forced into power 2.2 on my OLED, without the option to change it. I took this to imply that all HDR content is mastered in 2.2, and the picture is perfect under this gamma. How do the HDR to SDR or just HDR pixel processed modes take this into account? Does SDR have to be calibrated for 2.2 or does madVR process it correctly into BT.1886? How does madVR know the TV gamma if you disable calibration controls (or what is the default)?

[Warner306]

HDR mode is always absolute PQ and not 2.20. HDR -> SDR is up to user preference and should match your known calibrated SDR gamma, but you could choose anything you want.

SDR content is mastered to a specific gamma as set by the mastering display, so madVR doesn't have to convert anything. As mentioned previously, the most commonly used mastering monitors today are a perfectly flat 2.40.

[mytbyte]

However, HDR mode is forced into power 2.2 on my OLED, without the option to change it. I took this to imply that all HDR content is mastered in 2.2, and the picture is perfect under this gamma. How do the HDR to SDR or just HDR pixel processed modes take this into account? Does SDR have to be calibrated for 2.2 or does madVR process it correctly into BT.1886? How does madVR know the TV gamma if you disable calibration controls (or what is the default)?

Bold: That's weird - how do you come to this conclusion? In HDR mode PQ curve is in effect and the TV should inform you so - it should have nothing to do with gamma actually...it shouldn't get converted to gamma first to get converted for display, it goes straight from PQ to display (digital displays are linear)...

You calibrate to PQ or ideally, to BT.2390 curve that defines the tone mapping for TV's that can't reach required brightness.
MadVR doesn't know the gamma of your TV but is doesn't need to if your TV is HDR and you feed it HDR signal.

[ashlar42]

Yes, you did! ;) You wrote:

> I doubt that madVR can provide a better tone mapping
> results than the internal system in an OLED screen
Ok, you got me! :D

In my defense I meant it in the contest of being unable to take ABL into account (which is something I hope the TV internally does, I don't know for sure though) while I was asking if that could somehow be implemented in madVR. In any case, I'll stop here. I don't have an OLED screen yet (still plasma for me, last model Kuro), so I'm just discussing to stay "up to date" of where everything is going.

[blu3wh0]

Sorry, my mistake. The configuration is greyed out at 2.2, but I should have taken it as disabled. You can ignore the previous comment.

[alps006]

I don't think the driver size matters as long as it works as expected, and it does work well on Windows 8.1. Just think why Madshi keeps recommending 8.1 for HTPC, that is for a reason. You can see most users here and other forums are having issues with Windows 10.Anyway, all I can say is 8.1 resolved all the issues that I was having on windows 10. You do know it's the Nvidia driver which is broken?
Why is 399.xx working fine for HDR? Because the 399.xx driver is fine.

You get another installer for Win 8.1 which is also smaller:

Version: 411.70 WHQL
Freigabedatum: 2018.9.27
Betriebssystem: Windows 7 64-bit, Windows 8.1 64-bit, Windows 8 64-bit
Dateigröße: 469.19 MB
--------------------------------------------------------------------------------------------
Version: 411.70 WHQL
Freigabedatum: 2018.9.27
Betriebssystem: Windows 10 64-bit
Dateigröße: 520.35 MB

But I have the same opinion that Win 8.1 is better suited for HTPC use, but since I am using Win10 for over 3 years now, I think Nvidia should be able to deliver a working driver and not brk things repeatedly.

I stay with Win 10 for the next time.

[suanm]

I played several movies just now with MadVR v0.92.17.The visual effects between the HDR mode and the non-HDR mode(I can't regard it as HDR->SDR mode any more,LOL,because of modified name) look undifferentiated when I set peak nits to 1099,899,699,499,299,200 separately.I guess the non-HDR mode should be devoted to the oled TV set with lower brightness.Unfortunatedly,Running the highlights recovery algorithm will consume pc resources tremendously so that the playback of HDR movies gets stammering and stuttering very much.I'm expecting the algorithm will improve dramatically soon later.
Thanks to super master Madshi for your diligent work.

[Chouonsoku]

madshi, 0.92.17 completely resolved the red tint / black crush issues I mentioned before with the old "process HDR via pixel shader math" option. The new menu correctly triggers the HDR mode on my LG C7 and tonemaps with your algorothm instead of the TV's dumb mode. Watching Pacific Rim at 700 nits with "are you nuts!?" highlight recovery and the dream has finally been realized.

:thanks:

[khanmein]

I don't think the driver size matters as long as it works as expected, and it does work well on Windows 8.1. Just think why Madshi keeps recommending 8.1 for HTPC, that is for a reason. You can see most users here and other forums are having issues with Windows 10.Anyway, all I can say is 8.1 resolved all the issues that I was having on windows 10.

I think that W10 undisclosed certain stuff which Madshi unable to optimize & just like NVIDIA unable to fix certain issues which related to the OS itself.

[ryrynz]

* fixed: render & present queues didn't always fill in Windows 10 build 1803


Madshi, what was the problem here?


madshi, 0.92.17 completely resolved the red tint / black crush issues

So a madVR bug then? With all the upgrades that happen, settings files can cause all sorts of problems over time.

[alps006]

You are most probably right. But my second HTPC is running Windows 10 with AMD RX-460 without any issues.Go figure! My guess is that it's indeed nvidia driver bugs rather than the OS itself. I think that W10 undisclosed certain stuff which Madshi unable to optimize & just like NVIDIA unable to fix certain issues which related to the OS itself.

[khanmein]

You are most probably right. But my second HTPC is running Windows 10 with AMD RX-460 without any issues.Go figure! My guess is that it's indeed nvidia driver bugs rather than the OS itself.

AMD no issue? This is really bull-shit. AMD is a piece of junk.

[Sunset1982]

madVR v0.92.17 released

http://madshi.net/madVR.zip

* modified/simplified HDR tone mapping settings page
* small HDR tone mapping saturation improvement
* OSD now also shows the measured luminance of the current frame (in addition to the average)
* fixed: render & present queues didn't always fill in Windows 10 build 1803
* fixed: using XySubFilter sometimes resulted in black screen / freeze
* fixed: using HDR "processing" resulted in dark and red-ish image
* fixed: using BT.601/709 gamma curve with HDR tone mapping produced gray-ish image
* fixed: settings dialog sometimes crashed on display mode / custom mode tab
The HDR settings dialog changes *could* maybe introduce some new bugs, but I hope not. I've modified the HDR settings to make it less confusing. I don't want users to think that they somehow lose HDR by doing tone mapping.

And where can I find the HDR to SDR conversion settings now?

[Klaus1189]

AMD no issue? This is really bull-shit. AMD is a piece of junk.

:rolleyes:

[creativeopinion]

@madshi

Same here, so red tint / black crush issues are resolved.

The only thing that is confusing for me is that now using lower nits gets the picture to become darker and setting more nits means I will get the brighter picture. Now correct me If I'm wrong but wasn't this the other way around in the previous builds? Anyway, 700 seems way to bright so I think I will settle for 600 but I'm glad I can finally set more than 100.

Also, it seems the TV is not doing any additional tone mapping even though it switches to its HDR mode but this might not be true, I don't know. Just trying to trust what I see but the picture looks fine and I will no longer use passthrough. I'm pretty sure madVR can do the better job.

Thank you madshi!

[ryrynz]

And where can I find the HDR to SDR conversion settings now?

You didn't need to quote his release post, people really need to stop doing this. Also you quoted the part that's applicable to your answer.


I don't want users to think that they somehow lose HDR by doing tone mapping.


It's renamed to 'tone map HDR using pixel shaders' click on that and voila.. Options. ;)
Not a hard program to find your way around ya know.

[Ver Greeneyes]

Madshi, what was the problem here?
The new build uses substantially less CPU for me. I also noticed previously that the problem got worse if any CPU-intensive background processes were active. So I suspect that Windows 10 r1803 created some sort of (single threaded) CPU bottleneck.