Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 25th April 2018, 09:38   #50361  |  Link
suanm
Registered User
 
Join Date: Apr 2011
Posts: 121
Quote:
Originally Posted by LigH View Post
3D APIs are just different ways to the same goal: Graphic card internal features. DirectX under Windows is a more direct way there (and there may be even shorter paths), OpenGL under Windows rather a detour in comparison. The advantage of OpenGL is portability across different operating systems; that's not important for a DirectShow renderer which will work only under Windows anyway.
I got it,thank you,master.OpenGL would rather make a detour to the final goal.D3D11 can take a shortcut to the final goal,instead.That also means both d3d11 and openGL actually are not different for the final image quality except processing algorithm. May i think so?
i will keep doing the test with madVR on 4K HDR and 1080p movies till i get some best color images
suanm is offline   Reply With Quote
Old 25th April 2018, 13:39   #50362  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,127
Quote:
Originally Posted by stefanelli73 View Post
But there is also to say that no TV or vpr, currently, sufficiently covers the color space BT.2020 (for example my vpr OPTOMA UHZ65 covers it at 56%), while there are some displays that cover the DCI-P3 to 100% .... then also in Madvr in the information says "BT.2020> DCI-P3", so "in this dispalay is already calibrated" would not it be fair to use DCI-P3?
This is really not clear. Some users report correct colors with DCI-P3. Others report correct colors with BT.2020. If you report BT.2020, then gamut mapping might be unnecessary as the source input is already BT.2020. It is unclear if BT.2020 is a container in madVR like it is reported in the OSD or if the source is mapped to BT.2020 primaries. If it is a container, then DCI-P3 and BT.2020 should produce the same results, unless the BT.2020 mapping goes over the DCI-P3 limit.

One user pointed out it may be safer to select BT.2020 because the display expects a BT.2020 container.

Last edited by Warner306; 25th April 2018 at 13:54.
Warner306 is offline   Reply With Quote
Old 25th April 2018, 13:44   #50363  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,127
Quote:
Originally Posted by Warner306 View Post
Target nits is completely up to preference and experimentation. Increasing the peak nits value has a similar effect to increasing the gamma; the image gets progressively darker. This is because the tone mapping is more gradual in the transition from dark to light. The result is more contrast and dynamic range. So you should aim for the highest peak nits value you can use without crushing black. This will produce more highlights and a greater HDR effect. A properly calibrated HDR display should be a little darker than SDR without crushing shadow detail.
I read a post that better explains target nits than the post above.

The closer to the display's actual peak nits, the more the top end is compressed leaving 0 to 100 nits pixels as close to normal as possible. At higher target nits, the more the low end is compressed creating black crush at 0 to 100 nits but adding more highlight detail at the top end. So you are creating more space for specular highlights by choosing a higher peak nits value at the expense of shadow detail.

That is probably a simpler way to think of things.

Last edited by Warner306; 25th April 2018 at 13:51.
Warner306 is offline   Reply With Quote
Old 25th April 2018, 14:00   #50364  |  Link
stefanelli73
Registered User
 
Join Date: Jul 2016
Posts: 52
Quote:
Originally Posted by Warner306 View Post
This is really not clear. Some users report correct colors with DCI-P3. Others report correct colors with BT.2020. If you report BT.2020, then gamut mapping might be unnecessary as the source input is already BT.2020. It is unclear if BT.2020 is a container in madVR like it is reported in the OSD or if the source is mapped to BT.2020 primaries. If it is a container, then DCI-P3 and BT.2020 should produce the same results, unless the BT.2020 mapping goes over the DCI-P3 limit.

One user pointed out it may be safer to select BT.2020 because the display expects a BT.2020 container.
Perhaps I found the answer to our doubts, read the post from nr. 112:
http://www.avsforum.com/forum/26-hom...working-4.html
stefanelli73 is offline   Reply With Quote
Old 25th April 2018, 16:07   #50365  |  Link
Manni
Registered User
 
Join Date: Jul 2014
Posts: 942
Quote:
Originally Posted by Warner306 View Post
This is really not clear. Some users report correct colors with DCI-P3. Others report correct colors with BT.2020. If you report BT.2020, then gamut mapping might be unnecessary as the source input is already BT.2020. It is unclear if BT.2020 is a container in madVR like it is reported in the OSD or if the source is mapped to BT.2020 primaries. If it is a container, then DCI-P3 and BT.2020 should produce the same results, unless the BT.2020 mapping goes over the DCI-P3 limit.

One user pointed out it may be safer to select BT.2020 because the display expects a BT.2020 container.
It's not clear because Madshi for some reason doesn't want to change the way he reports the information (I respect whatever his reasons are, but it's just really confusing).

MadVR reports the information in the OSD as BT2020 -> DCI-P3, which suggests that the content is converted to P3. It's not. What it means is that the container is BT2020, but the content doesn't go further than P3. It's the -> sign that makes it confusing, because it suggests a conversion, as when MadVR converts it uses the > sign to signal it. I suggested to Madshi to report it differently to avoid such confusion a long time ago, maybe as BT2020 [DCI-P3] or BT2020 (DCI-P3) or whatever wouldn't suggest a conversion. The DCI-P3 here only reports the mastering monitor capability (i.e. the content doesn't go further than P3), not the way the content is conveyed, which is BT2020.

From a calibration point of view, there is no consumer content in DCI-P3. It's rec-709 or BT2020.

So if you don't do any conversion, your display should be calibrated to BT2020 (saturations), which doesn't mean that it has to reach BT2020. Most consumer displays do not go further than DCI-P3, but they still have to be calibrated to BT2020 to display say UHD Bluray content properly, for example with a UHD Bluray player.

What MadVR allows you to do though is to convert any content to the maximum capability of your display. For example, if your display can only reach DCI-P3, instead of creating a BT2020 calibration that will reach say 65% of BT2020, you'll create a DCI-P3 calibration that will reach 100% (or close) of DCI-P3. It should result in the same picture, as long as what the display expects matches what MadVR sends.

Overall, it goes like this:

During grading, the colorist usually has a DCI-P3 able monitor, so grades up to DCI-P3. But because DCI-P3 is only a stepstone towards the full gamut, it's wrapped into a BT2020 container. That way, UHD Bluray content needs only one calibration, and can display content graded in Rec-709, DCI-P3 or BT-2020 using the same container/calibration.

Usually, the source will send BT2020 without conversion, so if you want to use the same calibration for your UHD Bluray player and MadVR, you should use a BT2020 calibration.

If, however, you only use MadVR as a source, or you're happy to have a different calibration for MadVR, or if your display is old and doesn't have a BT-2020 mode, then you can create a DCI-P3 calibration and ask madVR to convert the BT2020 content into DCI-P3. But you have to specify this in the calibration tab.

In conclusion, you should specify in the calibration tab the calibration used on your display. If you don't know what it is, you have to measure it or decide what looks more right. The content is always BT2020 and always expect a BT2020 calibration (even when it was graded on a DCI-P3 monitor, as reported in the OSD), unless you tell MadVR that your display is calibrated to DCI-P3 or Rec-709.

A BT2020 calibration allows to display the content as is (if we're talking about UHD Bluray).

A DCI-P3 or Rec-709 calibration requires a conversion.

I hope it's clearer!

Quote:
Originally Posted by Warner306 View Post
I read a post that better explains target nits than the post above.

The closer to the display's actual peak nits, the more the top end is compressed leaving 0 to 100 nits pixels as close to normal as possible. At higher target nits, the more the low end is compressed creating black crush at 0 to 100 nits but adding more highlight detail at the top end. So you are creating more space for specular highlights by choosing a higher peak nits value at the expense of shadow detail.

That is probably a simpler way to think of things.
This is not correct.

The way it works is as follow:

If your display isn't able to display 10,000nits, or rather if the content goes above the capability of your display, you need to tonemap. The lower your display actual peakY, the more you have to compress highlights.

If your display is a 1500nits LCD, there is very little compression, so you'll get both good highlights and good near black resolution.

However, as the actual peakY of your display goes down, you have to compress highlights more and more, and because of the way MadVR does it, it goes against resolving the low end.

So if you have a bright display, you can probably tell your actual peakY. But if you have a projector, you have to lie to leave some room for highlights.

Hopefully at some point this will change so that MadVR can both reproduce the low end of dim titles and the highlights of bright titles with the same parameters.

At the moment, if your display is less than at least an OLED at 500-600nits actual peakY, then you probably have to lie.

In order to decide which parameter to use, you have to test both very dim 1000nits titles (for example some scenes in The Revenant) and some very bright 4000nits titles with highlights going to 4000nits and more (Life, Mad Max, Batman vs Superman etc).

You should find a parameter that reproduces the low end of dim titles satisfactorily and yet doesn't clip too much the highlights of bright titles, or you should use profiles (soon to be automated when Madshi implements a new field to test the content's max brightness).

For example, on my JVC PJ with an actual peakY of 120nits in low lamp/iris open, I have to use a target nits of around 500nits to get a decent compromise for both.
__________________
Win11 Pro x64 b23H2
Ryzen 5950X@4.5Ghz 32Gb@3600 Zotac 3090 24Gb 551.33
madVR/LAV/jRiver/MyMovies/CMC
Denon X8500HA>HD Fury VRRoom>TCL 55C805K

Last edited by Manni; 25th April 2018 at 16:13.
Manni is offline   Reply With Quote
Old 25th April 2018, 16:46   #50366  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,127
Quote:
Originally Posted by Manni View Post
From a calibration point of view, there is no consumer content in DCI-P3. It's rec-709 or BT2020.
Yes, it was you that recommended BT.2020. As long as the input is not converted to color values wider than the source, then it is like selecting passthrough. The conversion to DCI-P3 should result in the same outcome, though, if your display only covers a percentage of DCI-P3. It's just madVR that adjusts the saturations, not the display. The display could make an error, though, if it is expecting BT.2020 primaries.


Quote:
Originally Posted by Manni View Post
This is not correct.

The way it works is as follow:
Yes, got that, too. The quote came from madshi:


Quote:
Originally Posted by madshi View Post
If you actually tell madVR the proper peak Nits value that you measure your display as, all the pixels in the lower Nits range (ideally from 0-100 Nits) are displayed absolutely perfectly, in the same way a true 10,000 Nits display would show them. Tone mapping only starts somewhere above this lower Nits range. However, we can't simply jump abruptly from 0 compression to strong compression, so the tone mapping curve needs to start smoothly, otherwise the image would get a somewhat unnatural clipped look. Practically, if you set madVR's peak luminance value to 200 Nits, the tone mapping curve starts compressing pixels at 23 Nits. If you set madVR's peak luminance value to 400 nits, the tone mapping curve starts compressing at 75 Nits.


If you enter the measured Nits value, the top end is heavily compressed. You don't like that. If you enter a much higher than measured Nits value, the bottom end becomes too dark (= compressed in a sense). You don't like that. So if you don't like compression at the top end and not at the bottom end, where should be compress instead?
So you are saying, at a certain nits value (say 1,000 nits), you no longer have to lie because the top end will not be compressed that badly. So most users will have to lie?

This is just madVR jargon, not how it should work in a practical way. madshi mentioned he wanted to leave the peakY value to imply the actual measured peak nits and leave the decision on how to tone map to madVR. That will make tone mapping much more useful for the average user.

Last edited by Warner306; 25th April 2018 at 16:51.
Warner306 is offline   Reply With Quote
Old 25th April 2018, 17:35   #50367  |  Link
Manni
Registered User
 
Join Date: Jul 2014
Posts: 942
Quote:
Originally Posted by Warner306 View Post
Yes, it was you that recommended BT.2020. As long as the input is not converted to color values wider than the source, then it is like selecting passthrough. The conversion to DCI-P3 should result in the same outcome, though, if your display only covers a percentage of DCI-P3. It's just madVR that adjusts the saturations, not the display. The display could make an error, though, if it is expecting BT.2020 primaries.
You have to make a distinction between the native capability of the display and calibration.

Regarding calibration, you can calibrate a rec-709 display or a DCI-P3 display to BT2020. It simply will display up to its capabilities, and then it will clip (unless there is some tonemapping applied) if the content goes further than that.

So you can send BT2020 content to a rec-709, DCI-P3 or BT2020 display, as long as it's calibrated to BT2020.

If it's calibrated to its native capability (be it rec-709 or DCI-P3), then you have to convert the UHD Bluray content, because it will be using a BT2020 container, irrespective of the limitations of the mastering monitor.

Quote:
Originally Posted by Warner306 View Post

Yes, got that, too. The quote came from madshi:
The problem with the current approach is that you can't reproduce 0-100nits as is (1:1) for displays that have 100nits or less, which is most projectors, or there is no room for highlights. For projectors, you need something like 2:1 or even 3:1 for the dimmest ones (less than 50nits peak brightness), then you start rolling off.

We'll be working on improving this later but Madhsi has asked to focus on getting color right for now.

Quote:
Originally Posted by Warner306 View Post
So you are saying, at a certain nits value (say 1,000 nits), you no longer have to lie because the top end will not be compressed that badly. So most users will have to lie?

This is just madVR jargon, not how it should work in a practical way. madshi mentioned he wanted to leave the peakY value to imply the actual measured peak nits and leave the decision on how to tone map to madVR. That will make tone mapping much more useful for the average user.
This is NOT the way it works in the current build. It was possible to do this in the test builds because we could specify diffuse white, but now that Madshi has taken diffuse white away, most people - especially projectors owners with less than 500-600nits actual peakY) have to lie.

This is why Madshi is now calling that field "target nits" and not "actual display peak brightness", because it's simply a virtual value.

If you enter the actual brightness of your display, you will be able to show HDR content with no highlights pretty well (although the picture will likely be too bright, HDR shouldn't be brighter than SDR most of the time), but as soon as content goes above say 200nits you'll be in trouble.

I'm sure Madshi will explain when he has the time to post, but as he's super busy at the moment I'm just trying to clarify what users should expect.

Target nits is NOT the actual peakY of the display in most cases, especially displays dimmer than say a 600nits OLED, and the content is ALWAYS BT2020 when MadVR reports BT2020, even when there is a "->DCI-P3", which only means that the mastering monitor was limited to DCI-P3, hence content won't exceed DCI-P3, but by default a BT2020 calibration and saturations is expected to display the content properly, unless you specify a different calibration in the calibration tab, but in that case the display should be calibrated to whatever you specify, and MadVR will take care of the rest.
__________________
Win11 Pro x64 b23H2
Ryzen 5950X@4.5Ghz 32Gb@3600 Zotac 3090 24Gb 551.33
madVR/LAV/jRiver/MyMovies/CMC
Denon X8500HA>HD Fury VRRoom>TCL 55C805K

Last edited by Manni; 25th April 2018 at 17:37.
Manni is offline   Reply With Quote
Old 25th April 2018, 17:55   #50368  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,127
Quote:
Originally Posted by Manni View Post
If it's calibrated to its native capability (be it rec-709 or DCI-P3), then you have to convert the UHD Bluray content, because it will be using a BT2020 container, irrespective of the limitations of the mastering monitor.
Yes, as long as BT.2020 calibration is 1:1 with the source values, then you have no problems with clipping. You are probably right.


Quote:
Originally Posted by Manni View Post
The problem with the current approach is that you can't reproduce 0-100nits as is (1:1) for displays that have 100nits or less, which is most projectors, or there is no room for highlights. For projectors, you need something like 2:1 or even 3:1 for the dimmest ones (less than 50nits peak brightness), then you start rolling off.
I don't think diffuse white helps anything if you don't know what diffuse white means. But the concept of adjusting white does make more sense in the context of what the tone mapping seems to be doing - it is crushing diffuse white with increased intensity to make room for spectral highlights.

Maybe target nits should be called compression ratio and show the peakY with a multiplier?

It sounds like you need to recruit more projector owners to your testing. Based on the screenshots I've seen, I think both "dumb" and "scientific" have a place in madVR and it doesn't matter which is the default. If left two options, most users will try both.

Last edited by Warner306; 25th April 2018 at 18:00.
Warner306 is offline   Reply With Quote
Old 25th April 2018, 18:11   #50369  |  Link
Manni
Registered User
 
Join Date: Jul 2014
Posts: 942
Quote:
Originally Posted by Warner306 View Post
I don't think diffuse white helps anything if you don't know what diffuse white means. But the concept of adjusting white does make more sense in the context of what the tone mapping seems to be doing - it is crushing diffuse white with increased intensity to make room for spectral highlights.

Maybe target nits should be called compression ratio and show the peakY with a multiplier?

It sounds like you need to recruit more projector owners to your testing. Based on the screenshots I've seen, I think both "dumb" and "scientific" have a place in madVR and it doesn't matter which is the default. If left two options, most users will try both.
That's for Madshi to decide. Personally I'd prefer a single mode that works well with everything. At the moment it's a "pick your poison" situation.

Re the target nits parameter, Madshi has specifically asked not to discuss this until color is settled, so please let's not discuss this further. I know what diffuse white means, but most users don't and that's why Madshi took it off. You can get exactly the same results multiplying your actual peakY by your brightness factor (100/ref white), so it's not an issue at all.

I was only trying to clarify how "target nits" works at the moment so that people can try and report what works best with their display and provide the feedback that Madshi has requested at this stage, which is which tonemapping works best. The way target nits works is not ideal, but now isn't the time to discuss how to improve this.
__________________
Win11 Pro x64 b23H2
Ryzen 5950X@4.5Ghz 32Gb@3600 Zotac 3090 24Gb 551.33
madVR/LAV/jRiver/MyMovies/CMC
Denon X8500HA>HD Fury VRRoom>TCL 55C805K

Last edited by Manni; 25th April 2018 at 18:14.
Manni is offline   Reply With Quote
Old 25th April 2018, 18:12   #50370  |  Link
Sunset1982
Registered User
 
Join Date: Sep 2014
Posts: 280
nvidia just released driver 397.31. Looks like it got some new features and a new hdmi driver part. hopefully they fixed some bugs and it works better with madvr / hdr than the last versions...
__________________
Intel i5 6600, 16 GB DDR4, AMD Vega RX56 8 GB, Windows 10 x64, Kodi DS Player 17.6, MadVR (x64), LAV Filters (x64), XySubfilter .746 (x64)
LG 4K OLED (65C8D), Denon X-4200 AVR, Dali Zensor 5.1 Set
Sunset1982 is offline   Reply With Quote
Old 25th April 2018, 18:19   #50371  |  Link
Manni
Registered User
 
Join Date: Jul 2014
Posts: 942
Quote:
Originally Posted by Sunset1982 View Post
nvidia just released driver 397.31. Looks like it got some new features and a new hdmi driver part. hopefully they fixed some bugs and it works better with madvr / hdr than the last versions...
Thanks. I'll wait until someone confirms they have fixed the video levels...
__________________
Win11 Pro x64 b23H2
Ryzen 5950X@4.5Ghz 32Gb@3600 Zotac 3090 24Gb 551.33
madVR/LAV/jRiver/MyMovies/CMC
Denon X8500HA>HD Fury VRRoom>TCL 55C805K
Manni is offline   Reply With Quote
Old 25th April 2018, 19:13   #50372  |  Link
brazen1
Registered User
 
Join Date: Oct 2017
Posts: 331
Don't bother wasting your time like I just did. This new pos driver still ignored the stereo vs multi channel switch when you turn your AVR on/off. Also ignored no RGB 10 bit setting as usual along with dropped frames every few minutes. I'm beginning to think no one wants us using HTPC's anymore and instead direct us to streaming boxes with limited crap video output and lots of monthly subscription fees instead to help obliterate physical media . Meanwhile, keeping the MSRP on cards through the roof so only gamers want them as miners are diminished and continue to provide lots of driver upgrades for individual games to keep them jubilant and in the market. In the mean time we can continue to sit around for months/years/decades waiting to see if by some miracle any A/V related bone is tossed our direction. As the new Windows update hits the masses, this might turn into a real clusterfluck with even less remedies ever provided. Yep, I'm disappointed..... again.
__________________
HOW TO-Kodi 2D-3D-UHD (4k) HDR Guide Internal & External Players
W11 Pro 24H2 GTX960-4GB RGB 4:4:4 @Matched Refresh Rates 8,10,12bit
KODI 22 MPC-HC/BE 82" Q90R Denon S720W
brazen1 is offline   Reply With Quote
Old 25th April 2018, 19:23   #50373  |  Link
Manni
Registered User
 
Join Date: Jul 2014
Posts: 942
Quote:
Originally Posted by brazen1 View Post
don't bother wasting your time like i just did. ... Yep, i'm disappointed..... Again.
385.28
__________________
Win11 Pro x64 b23H2
Ryzen 5950X@4.5Ghz 32Gb@3600 Zotac 3090 24Gb 551.33
madVR/LAV/jRiver/MyMovies/CMC
Denon X8500HA>HD Fury VRRoom>TCL 55C805K
Manni is offline   Reply With Quote
Old 25th April 2018, 19:28   #50374  |  Link
brazen1
Registered User
 
Join Date: Oct 2017
Posts: 331
Yep, just DDU reinstalled it for about the 30th time. Still dropped frames and no 10 bit otherwise I'd never upgrade the damn thing.
__________________
HOW TO-Kodi 2D-3D-UHD (4k) HDR Guide Internal & External Players
W11 Pro 24H2 GTX960-4GB RGB 4:4:4 @Matched Refresh Rates 8,10,12bit
KODI 22 MPC-HC/BE 82" Q90R Denon S720W
brazen1 is offline   Reply With Quote
Old 25th April 2018, 19:43   #50375  |  Link
Manni
Registered User
 
Join Date: Jul 2014
Posts: 942
Quote:
Originally Posted by brazen1 View Post
Yep, just DDU reinstalled it for about the 30th time. Still dropped frames and no 10 bit otherwise I'd never upgrade the damn thing.
I must be lucky, I only have dropped frames with 3D, with 2D at least in UHD I get a dropped frame every hour or so, which is perfectly acceptable.

12bits works fine on my display (pixel shader, not passthrough), so I guess that's luck too as I don't need a 10bits mode. I didn't need it with the UB900 either, but I know many users did.

There is really little incentive for me to upgrade from 385.28, except if one day a new driver made no frame drop in 3D possible.

Did you have a chance to see if the levels are fixed?
__________________
Win11 Pro x64 b23H2
Ryzen 5950X@4.5Ghz 32Gb@3600 Zotac 3090 24Gb 551.33
madVR/LAV/jRiver/MyMovies/CMC
Denon X8500HA>HD Fury VRRoom>TCL 55C805K
Manni is offline   Reply With Quote
Old 25th April 2018, 19:58   #50376  |  Link
brazen1
Registered User
 
Join Date: Oct 2017
Posts: 331
I mean no dropped frames without the need to use madVR custom modes. Yes, I know you could care less about 8, 10, and 12bit offerings since your PJ handles 12bit correctly. I need 10bit passthrough personally and I think a whole bunch of other folks do too unless you like banding. Meanwhile we digress to 8bit after making sure all our equipment was at least 10bit. I don't know what the "levels' you are referring to is?
__________________
HOW TO-Kodi 2D-3D-UHD (4k) HDR Guide Internal & External Players
W11 Pro 24H2 GTX960-4GB RGB 4:4:4 @Matched Refresh Rates 8,10,12bit
KODI 22 MPC-HC/BE 82" Q90R Denon S720W
brazen1 is offline   Reply With Quote
Old 25th April 2018, 20:27   #50377  |  Link
Manni
Registered User
 
Join Date: Jul 2014
Posts: 942
Quote:
Originally Posted by brazen1 View Post
I mean no dropped frames without the need to use madVR custom modes. Yes, I know you could care less about 8, 10, and 12bit offerings since your PJ handles 12bit correctly. I need 10bit passthrough personally and I think a whole bunch of other folks do too unless you like banding. Meanwhile we digress to 8bit after making sure all our equipment was at least 10bit. I don't know what the "levels' you are referring to is?
Custom modes are needed on nVidia to not have dropped frames, that's been the case forever.

I'm talking about video levels. They are broken in 391.xx. In 390.65, they are inverted (you need to specify 0-255 in MadVR to get limited to the display). 385.28 is the latest fully working driver here.
__________________
Win11 Pro x64 b23H2
Ryzen 5950X@4.5Ghz 32Gb@3600 Zotac 3090 24Gb 551.33
madVR/LAV/jRiver/MyMovies/CMC
Denon X8500HA>HD Fury VRRoom>TCL 55C805K
Manni is offline   Reply With Quote
Old 25th April 2018, 20:52   #50378  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
looks like Samsung doesn't believe in 10 bit and 120 hz at the same time...

http://www.panelook.com/bramodlist.p...size_inch=6500

so i recommend you to lay back set it to 8 bit forget this 10 bit garbage and just enjoy.
huhn is offline   Reply With Quote
Old 25th April 2018, 20:57   #50379  |  Link
LigH
German doom9/Gleitz SuMo
 
LigH's Avatar
 
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
@suanm:

Don't focus too much on D3D11; madVR does not require D3D11, it will work as well with older graphic hardware, using interfaces which have been specified in earlier generations already (D3D9 / PS3.0).
__________________

New German Gleitz board
MediaFire: x264 | x265 | VPx | AOM | Xvid
LigH is offline   Reply With Quote
Old 25th April 2018, 22:33   #50380  |  Link
Asmodian
Registered User
 
Join Date: Feb 2002
Location: San Jose, California
Posts: 4,406
You do need D3D11 for HDR.
__________________
madVR options explained
Asmodian is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 09:26.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.