madVR - high quality video renderer (GPU assisted)

[mark0077]

According to nvidia inspector its staying in state P2 regardless of this checkbox.

[Manni]

Profiles! :)

If I could find the option, maybe :)

[ibius]

devices -> "device name" -> calibration

[Manni]

Simply configure madVR to "this display is already calibrated to BT.2020".


devices -> "device name" -> calibration

Thanks, that's where I would have looked first, but there is no such option there (or anywhere that I can see):

At least not for my display.

[ibius]

Thanks, that's where I would have looked first, but there is no such option there (or anywhere that I can see):

At least not for my display.

Em, what options do you get on that page?

You don't see "this display is already calibrated"?

[Manni]

Em, what options do you get on that page?

You don't see "this display is already calibrated"?

Sure, I see this option, but how does this help? It disables all the 3D LUTs, so it would only work if I wanted to select a display mode with a native rec2020 calibration and no 3D LUT with MadVR, which isn't what I'm trying to do.

What I'm trying to do is to be able to get MadVR not to convert rec2020 content to P3 when there is a rec2020 3D LUT.

This is why I didn't understand Madshi's answer to my question, as I don't see an option that allows you to select "this display is already calibrated to rec2020" when using a rec2020 3D LUT.

[aufkrawall]

Just thought it was worth mentioning anyways for those not using fullscreen exclusive mode. I'm using GTX 980 in Windows 10.
Those statistics can be deceiving, there shouldn't be any real performance difference between D3D9 or 11 path.
The differences in overhead or whatever between the APIs are neglectable compared to shader run times.
When GPU load gets a little too high, I get dropped frames, no matter if D3D9 or 11. Got a 980 and Win 10 as well.

[huhn]

According to nvidia inspector its staying in state P2 regardless of this checkbox.

try GPU-z

[aufkrawall]

It will say the same. What's interesting is not the used power state but the actual clocks.

[Warner306]

Can you show a screenshot where the ringing is visible? Ideally a short video sample with which I could reproduce it? Improving the sharpening anti-ringing filter is on my to do list, but it's not too easy. We want to supress the ringing, but we want to allow sharpening, too. If I make the anti-ringing filter too strict, I might also remove some valid sharpening.

I don't have any screenshots showing excess ringing with sharpen edges. My concerns with sharpen edges relate mostly to watching uncompressed 1080p Blu-rays on a 1080p display. The "shimmer" effect during scenes of motion is due to the aggressive and obvious edge enhancement of this sharpener. I am sure this is lessened considerably when sharpen edges is applied instead from upscaling refinement.

Let me clarify. I currently use image sharpening with all profiles to keep the appearance of the image consistent:

SD -> 1080p (crispen edges (1.0), SuperRes (3))
720p -> 1080p (SuperRes (1))
1080p -> 1080p (sharpen edges (0.5))

The 1080p profile is where madVR begins to look inconsistent. SuperRes is the primary image sharpener on other profiles. Not only does SuperRes produce less aggressive edges; it also looks much better in motion. Normally I don't like crispen edges because it alters image brightness. But I find it is not offensive at a 2x scaling factor and actually blends very well with SuperRes, which can look bloated at high values, and crispen edges helps with this.

So, for the 1080p profile, I am left using small values of image enhancements to match the look of the other profiles. Of the bunch, I prefer sharpen edges, but it is very harsh (almost clinical) when applied to 1080p Blu-ray rips. Even at small values, the haloing around objects, which can be a combination of fattened lines and/or ringing is sometimes distracting. The sharper the Blu-ray, the more distracting the ringing can be. If you could tame the edges, even slightly, this would be my prefered sharpener. I know crispen edges is available, but I find it changes the brightness of the image in unwanted ways.

An even better solution than improving sharpen edges would be to introduce an image enhancement that looks similar to SuperRes. Also, perhaps the sharpening anti-ringing filter needs to be more aggressive with image enhancements?

[madshi]

Also if there is a rec2020 3D LUT, would you consider not converting rec2020 content to P3?
1) Where is this option? I've probably missed it, but I've never seen it.

2) Will this allow to use a rec-709 calibration for rec-709, PAL and SMPTE-C, a P3 calibration for P3 and a rec2020 calibration for rec2020? Or will it force us to use the same baseline for all calibrations?
I think there is a misunderstanding somewhere. Let me sum up some things, in the hope that it will clear things up:

1) madVR does *not* convert native 2020 content to P3, as I've already said before. Exceptions: If you have a P3 3dlut file loaded in the 2020 slot (see point 5). Or if the 2020 slot is empty and a P3 3dlut file is loaded in the P3 slot *). Or if you have setup calibration to "this display is already calibrated to P3".

2) When talking about "P3 in 2020 container" content, madVR treats that as P3 content - because it is! The container doesn't matter.

3) "Conversion" between different gamuts is lossless - except if somebody somewhere clips (3dlut processing does clip). Conversion from a smaller to a wider gamut is always lossless.

4) You can force madVR to process P3 content (and "P3 in 2020 container" content) through a 2020 processing pipeline by either leaving the P3 slot empty and filling the 2020 slot with a 2020 3dlut *). Or by filling the P3 slot with a 2020 3dlut (see point 5). Or by setting "this display is already calibrated to 2020".

5) Generally when using a 3dlut, madVR does *not* convert to the gamut identified by the slot. The slot just makes madVR choose the 3dlut file. But the 3dlut file might have a different gamut stored in its header. Meaning: You could create a 3dlut for e.g. BT.709 and then load it into a 2020 slot. If you do that, madVR will pick that 3dlut for 2020 content, because the slot says so. But madVR knows that the 3dlut was made for BT.709, so madVR converts the source to BT.709 in this situation, because that's the only way to get correct colors out of that 3dlut file. Usually I would expect the 3dlut gamut to match the slot it's loaded in, but you *can* load a 3dlut into a slot which wasn't made for the slot gamut. So this can complicate things.

*) The exact behaviour which slot to use (if the slot that matches the source gamut) is not well designed right now. Currently if the slot is empty always the BT.709 slot is used instead. That will be improved in the next build, where P3 will use 2020 and 2020 will use P3 as the first workaround slot if the source slot is empty.

[madshi]

KNLMeansCL was initially an OpenCL version of TNLMeans, so I guess yeah,
parameters used in chromareconstructor:
ax=ay= radius
az=0
sx=sy=bx=by=0
a=1.0
h=str
ssd=1
"rclip" (external clip as the weighting reference) wasn't implemented in TNLMeans, guess you have to do that by yourself, but it should be pretty easy..
Ok, thanks, will have a look.

wouldn't IVTC fail in this case too?

ok it could kind of survive 30p. are the informations from media info unreliable or unaccessible?

can madVR always read the repeat flag and act different when they are found? like enabling smoothmotion.

so every case that is not interlaced is not harmed by this.
IVTC handles 30p sections just fine. However, display refresh mode selection and smooth motion activation always assumes 23p.

The general problem here is that the repeat flag is not guaranteed to be constant throughout the whole movie file. It can change at any time. So if there's such a flag at the start of the video file, that doesn't say anything about playback at runtime 5 seconds, or vice versa. Furthermore the flags might change back and forth all the time, even very quickly. So adjusting refresh rate and smooth motion activation all the time when the flags change would result in weird behaviour with a lot of content. Especially broadcasts and also some DVDs have very inconsistent flags.

I don't have any screenshots showing excess ringing with sharpen edges. My concerns with sharpen edges relate mostly to watching uncompressed 1080p Blu-rays on a 1080p display. The "shimmer" effect during scenes of motion is due to the aggressive and obvious edge enhancement of this sharpener. I am sure this is lessened considerably when sharpen edges is applied instead from upscaling refinement.

Let me clarify. I currently use image sharpening with all profiles to keep the appearance of the image consistent:

SD -> 1080p (crispen edges (1.0), SuperRes (3))
720p -> 1080p (SuperRes (1))
1080p -> 1080p (sharpen edges (0.5))

The 1080p profile is where madVR begins to look inconsistent. SuperRes is the primary image sharpener on other profiles. Not only does SuperRes produce less aggressive edges; it also looks much better in motion. Normally I don't like crispen edges because it alters image brightness. But I find it is not offensive at a 2x scaling factor and actually blends very well with SuperRes, which can look bloated at high values, and crispen edges helps with this.

So, for the 1080p profile, I am left using small values of image enhancements to match the look of the other profiles. Of the bunch, I prefer sharpen edges, but it is very harsh (almost clinical) when applied to 1080p Blu-ray rips. Even at small values, the haloing around objects, which can be a combination of fattened lines and/or ringing is sometimes distracting. The sharper the Blu-ray, the more distracting the ringing can be. If you could tame the edges, even slightly, this would be my prefered sharpener. I know crispen edges is available, but I find it changes the brightness of the image in unwanted ways.

An even better solution than improving sharpen edges would be to introduce an image enhancement that looks similar to SuperRes. Also, perhaps the sharpening anti-ringing filter needs to be more aggressive with image enhancements?
The problem for me is that it's hard to improve something if I can't reproduce the exact problem you're seeing. I kind of understand what you mean, but if I don't see a screenshot or a sample video to reproduce that shimmering effect on my PC, then I can know whether changing the algorithm has improved things or not?

[Manni]

I think there is a misunderstanding somewhere. Let me sum up some things, in the hope that it will clear things up:

1) madVR does *not* convert native 2020 content to P3, as I've already said before. Exceptions: If you have a P3 3dlut file loaded in the 2020 slot (see point 5). Or if the 2020 slot is empty and a P3 3dlut file is loaded in the P3 slot *). Or if you have setup calibration to "this display is already calibrated to P3".

2) When talking about "P3 in 2020 container" content, madVR treats that as P3 content - because it is! The container doesn't matter.

3) "Conversion" between different gamuts is lossless - except if somebody somewhere clips (3dlut processing does clip). Conversion from a smaller to a wider gamut is always lossless.

4) You can force madVR to process P3 content (and "P3 in 2020 container" content) through a 2020 processing pipeline by either leaving the P3 slot empty and filling the 2020 slot with a 2020 3dlut *). Or by filling the P3 slot with a 2020 3dlut (see point 5). Or by setting "this display is already calibrated to 2020".

5) Generally when using a 3dlut, madVR does *not* convert to the gamut identified by the slot. The slot just makes madVR choose the 3dlut file. But the 3dlut file might have a different gamut stored in its header. Meaning: You could create a 3dlut for e.g. BT.709 and then load it into a 2020 slot. If you do that, madVR will pick that 3dlut for 2020 content, because the slot says so. But madVR knows that the 3dlut was made for BT.709, so madVR converts the source to BT.709 in this situation, because that's the only way to get correct colors out of that 3dlut file. Usually I would expect the 3dlut gamut to match the slot it's loaded in, but you *can* load a 3dlut into a slot which wasn't made for the slot gamut. So this can complicate things.

*) The exact behaviour which slot to use (if the slot that matches the source gamut) is not well designed right now. Currently if the slot is empty always the BT.709 slot is used instead. That will be improved in the next build, where P3 will use 2020 and 2020 will use P3 as the first workaround slot if the source slot is empty.

Thanks a lot for taking the time to write this, it does help to clear things up. :)

My experience of 1) is different, as with a rec2020 3D LUT loaded in the rec2020 slot and no 3D LUT in the P3 slot MadVR still reported rec2020>P3 when playing rec2020 encoded but P3 mastered HDR content (as in say the Exodus HDR10 trailer). Unless that falls in 2) for you. In that case this is related to the ongoing discussion in the Spectracal thread, so let's not discuss here. I was asking you to give us the option of not doing this conversion so we could compare the results, but I respect your decision if you believe it's better not to, for whatever reason. 4) should help to test this in the next build anyway if I understand you correctly.

Thanks again for these explanations, especially 4) and 5). Much appreciated.

[madshi]

The "2020 -> P3" is not necessarily a representation of the processing pipeline, but just the best I could up with to show the 2086 metadata in the OSD. The meaning is simply "2020 container -> P3 2086 metadata". Whether or not madVR remaps the 2020 coordinates to P3 depends on the exact calibration configuration. The exact gamut processing pipeline is not shown in the OSD.

[Manni]

The "2020 -> P3" is not necessarily a representation of the processing pipeline, but just the best I could up with to show the 2086 metadata in the OSD. The meaning is simply "2020 container -> P3 2086 metadata". Whether or not madVR remaps the 2020 coordinates to P3 depends on the exact calibration configuration. The exact gamut processing pipeline is not shown in the OSD.

Thanks again for this clarification. I've edited my post above as I understood further (I think) what 4) could help us to do in the next build.

[chros]

Those statistics can be deceiving, there shouldn't be any real performance difference between D3D9 or 11 path.
The differences in overhead or whatever between the APIs are neglectable compared to shader run times.
As I said couple of times, there's a huge performance difference between FSE D3D9 Old Path and the rest of the modes on my optimus system while others couldn't confirm this (they are not using the same hardware).

[mark0077]

It will say the same. What's interesting is not the used power state but the actual clocks.

OK with gpu-z I have looked at the core and memory clocks when using the D3D9 vs D3D11 paths.

The small change in mhz definitely doesn't explain the huge advantage D3D11 gives. I'll certainly be sticking with D3D11 on my machine anyways.

D3D9
Core Clock: 1215
Memory Clock: 1502
Rendering Time Average: 15.95ms

D3D11
Core Clock: 1328
Memory Clock: 1502
Rendering Time Average: 3.34ms

On my older GTX 295 I had to tick "present a frame for every VSync" to avoid glitches, but not so on the GTX 980. I guess it shows its worth trying these options out.

Maybe itd be a good idea for madVR 2.0 in a few decades time, to have an auto setup feature that could try various combinations of these settings on the users sytem, and analyze their behaviour very quickly by playing a few seconds of a clip and seeing how each performs, and automatically choosing what gives the best results.

[aufkrawall]

I suspect the statistics to be misleading in this case, maybe it's simply a bug how they got calculated or whatever.
When the GPU runs with a higher clock, this usually means that the load is higher.
The difference in your case is small however. Are you sure these clocks are reproducible? Sometimes the driver may decide differently.

[mark0077]

Yeah the core clock can deviate slightly but all in or around the 1200 - 1350 mark, so nothing that explains a 500% increase. I guess its either a calculation error or there is something else funny going on. Strange thing is, with D3D9 in non fullscreen windowed mode, its around 3ms also. Even if I drag the size of the mpc-be window to pretty much fullscreen, its 3ms. Its only when it goes into the fully maximized mode that it makes the jump to ~16ms. Whats different between the two I do not know.

[huhn]

there is something wrong why should the GPU even use a high clock like this if it can be done in 3 ms.

[mark0077]

Well I use SVP to get to 60fps so I'm not surprised my gpu is working reasonably hard.

[aufkrawall]

there is something wrong why should the GPU even use a high clock like this if it can be done in 3 ms.
It starts with a high clock and then should fall if load isn't high.

[Shiandow]

KNLMeansCL was initially an OpenCL version of TNLMeans, so I guess yeah,
parameters used in chromareconstructor:
ax=ay= radius
az=0
sx=sy=bx=by=0
a=1.0
h=str
ssd=1
"rclip" (external clip as the weighting reference) wasn't implemented in TNLMeans, guess you have to do that by yourself, but it should be pretty easy..

That looks pretty similar to what the Bilateral chroma scaler does, only with a much larger radius.

[ryrynz]

SD -> 1080p (crispen edges (1.0), SuperRes (3))
720p -> 1080p (SuperRes (1))
1080p -> 1080p (sharpen edges (0.5))



Why just the one pass at 720? Is performance an issue with more than one pass?

[Warner306]

Why just the one pass at 720? Is performance an issue with more than one pass?

No, I was aiming more for accuracy. Higher values look too aggressive to my eyes. 720p really isn't that far behind 1080p in terms of detail. Not a whole lot of sharpening is required. Granted, that is the only profile I still experiment with. What do you prefer?

[madshi]

That looks pretty similar to what the Bilateral chroma scaler does, only with a much larger radius.
Hmmmm... Overall it looks like a quite different algo to me. The radius is bigger, obviously. But also letting a "normal" upscaling algo do the initial upscaling is different, then using supersampling to do the corrections, not using the distance in the weight calculation and finally the way the corrections are "applied" to the original upscaled chroma channels. That's all different.

[Shiandow]

Hmmmm... Overall it looks like a quite different algo to me. The radius is bigger, obviously. But also letting a "normal" upscaling algo do the initial upscaling is different, then using supersampling to do the corrections, not using the distance in the weight calculation and finally the way the corrections are "applied" to the original upscaled chroma channels. That's all different.

Yeah, I was just referring to the "NLmeans" part. In general the NLmeans algorithm is different because it takes into account the neighbourhood of pixels, but with those parameter the neighbourhood has a radius of 1.

[bran]

I'm getting a very dark almost black/sepia image when trying to watch HDR clips with madVR.

http://i.imgur.com/N5jWTdB.png

For example the "Life of Pi HDR" demo (http://demo-uhd3d.com/fiche.php?cat=uhd&id=88). But happening on all of the few HDR clips I've found.

This is happening on both my computers. Both having a GTX 980Ti and madVR 0.89.19. Using the latest stable build of mpc-hc or the nightly LAV Filters makes no difference.

One computer is connected to my Samsung JS9505 SUHD TV (12-bit reported in nvidia control panel), the other to my LG 34UM95 10-bit monitor (10 bit nvidia ctrl panel). Obviously the computer monitor can't do HDR, but at least before (I just reinstalled Windows with latest nvidia drivers and madvr/mpc-hc) I got a washed out colour picture.

Trying the different "this monitor is already calibrated" options makes no big difference either, the sepia is just turned towards a more orangish tone.

Changing to EVR the clips are displayed as expected, the right colour but washed out.

[madshi]

Try resetting madVR to default settings. Are you using DXVA copyback decoding? Try disabling everything DXVA in the madVR settings. If you can't get it to work, enable the OSD (Ctrl+j) and post a screenshot with the OSD on.

[Probe]

I'm getting a very dark almost black/sepia image when trying to watch HDR clips with madVR.


I had the same problem with my GTX 960...only enabling DVXA gpu decoding bypassed the corruption for whatever reason. Seems to happen after playing with the full and limited range settings. The only way I found to resolve the issue was to create a new OS user profile, which cleared up the corruption.

[bran]

Try resetting madVR to default settings. Are you using DXVA copyback decoding? Try disabling everything DXVA in the madVR settings. If you can't get it to work, enable the OSD (Ctrl+j) and post a screenshot with the OSD on.

I was using DXVA copyback, yes. However I had tried just software as well. Resetting the settings with the .bat-file now renders the video in windowed mode. But going fullscreen just gives audio playing with a black screen, no OSD or nothing. I've disabled what I could find regarding DXVA.

http://i.imgur.com/NZ7MgWr.jpg

Changing to 10-bit for the monitor in madVR didn't help either.

EDIT: Changing to DX11 is now rendering the video in FS as well.

EDIT2: !!! Enabling "Activate SuperRes Filter" is what is yielding the sepia image. !!!

[Uoppi]

Which would be more preferable and why (SD -> 1080p upscale):
- Double luma at NNEDI3 256 (no quadrupling)
or
- Use luma quadrupling at NNEDI3 32 and doubling at however high you can go with NNEDI3 (which would be significantly less than the 256 above, of course)

Assuming in both cases the resulting resource expenditure is about equal, that is, near the absolute max available.

[aufkrawall]

Quadrupling doesn't make much sense in this situation since 576p or 480p doubled is already more than 1080p or almost as much.
Instead of using that many neurons, I'd suggest SuperRes. NNEDI3 is mostly very artifact free, but it can look a bit artificial. SuperRes can help a lot against this.
e.g. try NNEDI3 64 doubling with SuperRes strength 2 or 3. You can also put a little of sharpen edges, enhance detail or Adpative Sharpen on top of that.

[Uoppi]

Quadrupling doesn't make much sense in this situation since 576p or 480p doubled is already more than 1080p or almost as much.
Instead of using that many neurons, I'd suggest SuperRes. NNEDI3 is mostly very artifact free, but it can look a bit artificial. SuperRes can help a lot against this.
e.g. try NNEDI3 64 doubling with SuperRes strength 2 or 3. You can also put a little of sharpen edges, enhance detail or Adpative Sharpen on top of that.

Hmm, you're right. Maybe I thought of quadrupling because horizontally 720 -> 1920 is almost a 3x upscale. Still, a waste of resources though.

So for SD -> 1080p upscale the "correct" way is to use doubling with the setting "only when scaling factor is 1.5 or more"? I think for 720p I've got it set at "always when needed".

I use SuperRes (at 1 or 2) with NNEDI3 (32 and more) for all upscales. And I don't usually want any further sharpening (even the sharpness setting on my tv is at 0).

[aufkrawall]

Hmm, you're right. Maybe I thought of quadrupling because horizontally 720 -> 1920 is almost a 3x upscale. Still, a waste of resources though.

Yeah, I forgot that there can be many differences in horizontal resolutions.
I'd use super-xbr for quadrupling after NNEDI3 doubling in such situations then. Someone claimed here that it would look pixelated compared to pure NNEDI3 quadrupling, but I'm not aware of any proof for that. With my tests, I could hardly distinguish NNEDI3 64 doubling + super-xbr 75 quadrupling vs. NNEDI3 64 doubling + NNEDI3 64 quadrupling. SuperRes also reduces the remaining differences.

[GCRaistlin]

I get dropped frames playing NTSC SD video (http://mir.cr/0JGNT9O8) on 30 Hz and no dropped frames playing it on 60 Hz. Also, I get dropped frames playing PAL SD video (http://mir.cr/0TO7HKQ7) on 24 Hz (with ReClock) and no dropped frames playing it on 50 Hz (and no such issue when playing NTSC HD video on 24 Hz).
HD5770 + Catalyst 14.4, WinXP SP3, MPC-HC 1.7.10.40, madVR 0.89.19

[huhn]

without OSD screenshots it's hard to judge.

but the NTSC SD file is 60 HZ and should be watched at that.

[e-t172]

Not entirely related to madVR, but wanted to share that the "UHD Premium" announcement (http://arstechnica.com/gadgets/2016/01/just-after-you-bought-a-4k-tv-for-christmas-uhd-alliance-announces-uhd-premium/) might end up bringing order into the chaos that HDR currently is. Hopefully.

[nevcairiel]

Not entirely related to madVR, but wanted to share that the "UHD Premium" announcement (http://arstechnica.com/gadgets/2016/01/just-after-you-bought-a-4k-tv-for-christmas-uhd-alliance-announces-uhd-premium/) might end up bringing order into the chaos that HDR currently is. Hopefully.

Unfortunately it still doesn't seem to specify how to actually process the HDR data, so experience between TV sets may differ.

[Uoppi]

Yeah, I forgot that there can be many differences in horizontal resolutions.
I'd use super-xbr for quadrupling after NNEDI3 doubling in such situations then. Someone claimed here that it would look pixelated compared to pure NNEDI3 quadrupling, but I'm not aware of any proof for that. With my tests, I could hardly distinguish NNEDI3 64 doubling + super-xbr 75 quadrupling vs. NNEDI3 64 doubling + NNEDI3 64 quadrupling. SuperRes also reduces the remaining differences.

I actually tried NNEDI3 doubling + Super-XBR quadrupling at one point and it looked fine but I remember I opted to "go all out" with NNEDI3 doubling instead (128 or 256).

So from what I can gather, it would indeed be a good strategy to use a moderate NNEDI3 count for doubling + Super-XBR for quadrupling (to kick in for higher upscales) INSTEAD of allocating all available resources towards maxing NNEDI3 doubling? I mean, I'm having a hard time spotting differences between 64 vs. 256 neurons anyway unless zooming up close.

[Thunderbolt8]

a question regarding range conversion. what is the recommendation here for a TV, set the graphic card to 0-255 and then let madVR do the conversion to 16-235? someone I know who has a Panasonic plasma TV says that when he does so, forcing the nvidia driver to output 0-255, and then setting 16-235 in madVR will leave whiter than whites (236-255) pass through and make 235, which is supposed to be white, darker. According to him the only way to get proper output with nvidia is to set the gpu to 16-235 and madvr to 0-255.

he made some pictures using the AVSHD calibration disc:

madvr 16-235, GPU 0-255: http://someimage.com/TIY4nz2

madvr 0-255, GPU 16-235: http://someimage.com/uy1kWWj

[huhn]

depends on the screen setting.
madvr 16-235, GPU 0-255 and madvr 0-255, GPU 16-235 should result in the same output type (limited) which should look the same.

so either the TV settings are changed or the screen act strange with a full range signal which doesn't make a lot of sense.

or in "short" this should count:
There are 3 possible HTPC level configurations, when using madVR:

(1) Display wants 0-255. GPU and madVR are consequently also both set to 0-255.

This is the most recommended setup because it doesn't (shouldn't) have any banding problems, and still has all video, desktop and games with correct black/white levels. In this case test patterns need to have black at 0,0,0, obviously.

(2) Display wants 16-235. GPU is set to 16-235. madVR has to be set to 0-255.

This is not recommended, because the GPU stretches the madVR output, probably in 8bit without dithering, so banding could be introduced. However, this is not a big problem for ArgyllCMS. Argyll still needs to create test patterns with black at 0,0,0. The GPU will then stretch the test patterns from 0-255 to 16-235, so the display will get 16,16,16, although Argyll rendered 0,0,0. So the levels are correct.

(3) Display wants 16-235. GPU is set to 0-255. madVR is set to 16-235.

This is the recommended setup for best image quality if your display can't do 0-255. This setup results in banding-free madVR image quality. However, levels for desktop and games will be incorrect, because desktop and games will render black at 0,0,0, while the display expects black at 16,16,16. This is a problem for ArgyllCMS, because Argyll will create test patterns with black at 0,0,0, and the display will also receive these at 0,0,0. So basically Argyll test patterns will have wrong levels, which will screw up the whole calibration.

It is my understanding that Graeme implemented the -E switch specifically for (3), because without the -E switch Argyll test patterns would send wrong levels to the display. Basically the -E switch tells Argyll to render test patterns with black at 16,16,16 and white at 235,235,235, which Argyll never had to do before. When using VMR/EVR, you usually switch your GPU to 0-255 or 16-235. In both cases Argyll can render test patterns with black at 0,0,0, and they will still be sent to the display with the correct levels. However, due to my recommendation to use (3) if your display doesn't support 0-255, Argyll suddenly needs to render test patterns differently. Hence Graeme implemented the -E switch.

So my understanding is that -E should be used only for (3) and in no other situation. If you use the -E switch for (1), Argyll will create test patterns with black at 16,16,16 which would be incorrect!

source: http://www.avsforum.com/forum/139-display-calibration/1471169-madvr-argyllcms.html#post23274961

[KoD]

Nvidia GPUs and drivers are able to properly output a full range [0-255] signal, it's Panasonic plasmas that used to not accept full range signals. I know this first hand, I had a Panasonic plasma myself. More recent models might no longer have this issue though.

So what your friend does is the right thing to do for him. He has to set his output to [16-235] in the GPU because his TV set would ignore the [0-16] and [235-255] range of values were he to send a full range signal [0-255]. This is option (2) in the quote from huhn's post. I do not agree that option (3) in huhn's quoted post is preferable to (2) for two reasons: one is that we don't use TVs to see movies only, but we also want the desktop, images, games and everything else to be displayed properly - and this is not what happens with option (3); and second, because from my experience the [0-255] signal is not properly interpreted by a TV which only expects [16-235] - the gamma or something else is not right, the image in movies does not look quite the same as when you use option (2).


If you have a TV that accepts a full range signal, the best thing to do is to output full range from the GPU [0-255] and configure madVR to do the conversion from 16-235 to [0-255] as intended - that's exactly option (1) from the post quoted above. You need to look into the controls of your TV set to enable it to accept a full range signal though. How to do this varies from brand to brand and model to model. It may involve setting the input as a PC input, or activating some mode (like "Game"), or toggling some "black level" option. On my Sony TV, everything is properly working out of the box with its auto setting, the TV properly recognizes when the GPU sends limited range or full range signals. But if I were to force full range for an input, what I would have to do would be to set Display -> Video Input Settings -> HDMI Dynamic Range to "Full" for that HDMI port.

In the past some TVs were not being able to accept a full range signal at all.

[Manni]

Unfortunately it still doesn't seem to specify how to actually process the HDR data, so experience between TV sets may differ.

This is just the press release, signatories of the UHD Alliance have access to the full specs.

[Thunderbolt8]

madvr 16-235, GPU 0-255 and madvr 0-255, GPU 16-235 should result in the same output type (limited) which should look the samebut they arent as you can see in the pictures. his TV only accepts 16-235 via HMDI.

[Razoola]

a question regarding range conversion. what is the recommendation here for a TV, set the graphic card to 0-255 and then let madVR do the conversion to 16-235? someone I know who has a Panasonic plasma TV says that when he does so, forcing the nvidia driver to output 0-255, and then setting 16-235 in madVR will leave whiter than whites (236-255) pass through and make 235, which is supposed to be white, darker. According to him the only way to get proper output with nvidia is to set the gpu to 16-235 and madvr to 0-255.

he made some pictures using the AVSHD calibration disc:

madvr 16-235, GPU 0-255: http://someimage.com/TIY4nz2

madvr 0-255, GPU 16-235: http://someimage.com/uy1kWWj

This problem does not just affect Panasonic plasmas. I have a Samsung and see the same problem. In fact, its always been like this with all tvs I have used with madVR (Samsung, Panasonic and Philips). Its been an issue since forever and was brought up by someone years back.

I have tv set to accept full RGB, NVidia driver to send full range RGB and madVR to send limited range (16-235)... In this setup whiter than white is sent (236-255) but blacker than black is not (0-16). If you however change madVR color range to custom and then select the range (16-255) madVR will then loose the whiter than white and the color range will be correct between 16-235 with the avshd tests. Its not logical but it works.

Raz

[David]

I have tv set to accept full RGB, NVidia driver to send full range RGB and madVR to send limited range (16-235)... In this setup whiter than white is sent (236-255) but blacker than black is not (0-16). If you however change madVR color range to custom and then select the range (16-255) madVR will then loose the whiter than white and the color range will be correct between 16-235 with the avshd tests. Its not logical but it works.

If you set madvr to sending 16-235 and GPU driver to sending 0-255 then you will be sending 16-235 (16 reference black and 235 reference white, plus BTB&WTW). So your TV have to be set to accept 16-235. Desktop will be wrong levels.

[raymondjpg]

Using latest versions of madVR 89.19 and Emby for WMC (Windows 7 Professional). With MPC-HC 1.7.10 after refresh rate switching by madVR (windowed overlay mode) then video hangs and does not play. Video will play after closing then re-starting MPC.

Refresh rate switching when using MPC-HC 1.7.9 works with video playing fine after refresh rate switching.

Has anyone else seen this, better still have a solution for it? I have also posted this in the MPC-HC forum as I suspect it is more of an issue with the latest version of MPC-HC than madVR.

[Warner306]

I actually tried NNEDI3 doubling + Super-XBR quadrupling at one point and it looked fine but I remember I opted to "go all out" with NNEDI3 doubling instead (128 or 256).

So from what I can gather, it would indeed be a good strategy to use a moderate NNEDI3 count for doubling + Super-XBR for quadrupling (to kick in for higher upscales) INSTEAD of allocating all available resources towards maxing NNEDI3 doubling? I mean, I'm having a hard time spotting differences between 64 vs. 256 neurons anyway unless zooming up close.

I thought you were upscaling DVDs? This would be a 2x to 2.25x resize, no?

[Thunderbolt8]

same RGB range question for my old AMD laptop. in the video settings under colour there is the setting dynamic range. the options here are full, limited or leave this option unticked. unticked appears to be the same as full though. not sure if theres really a difference here. I unticked all video & quality options in the AMD settings just to be sure drivers dont mess with the content. so should I leave the dynamic range option as well unticked or set it to full?

madvr: is currently set to display expects PC levels (default).

with my panasonic plasma (VT60) I can choose HDMI range normal (default setting) or full. when I set it to full though then black becomes gray. but according to "(1) Display wants 0-255. GPU and madVR are consequently also both set to 0-255." setting it to full range should be right, shouldnt it?

another thing: with my TV theres also an option called HDMI content type from which I can choose Auto (default), graphics, foto or off. which is the recommended setting here when watching movies? auto, graphic and foto look all the same, that setting is a little bit brighter than off.


edit: I need to double check if I really read the RGB level values for my TV in madVR or my laptop screen, not sure any more. will do tomorrow.