madVR - high quality video renderer (GPU assisted)

[James Freeman]

FSE mode fails to engage. Black Screen in 8bit. "exclusive mode failed" message in 10bit.
Nvidia Windows 7 64
Works fine here. Is that a new problem for you? If so, could you please try to find out which exact madVR build introduced this problem for you?
0.88.7 introduced it for me.
I had to run "restore default settings", and everything works fine now.
Is it a standard procedure to reset setting with every new build? If so, my bad sorry.

Now 0.88.7 is rock solid without any apparent bugs, great build Thanks !
Switching to fullscreen is instant with D3D11 and overall feel of 0.88 is snappier and faster.

What I want to hear about is quality differences, maybe quality vs performance considerations, nothing else. Thanks!
Alright, quality wise it is almost impossible to differentiate between the two when they are properly set.
Any one of them will be adequate.

[ryrynz]

I will most likely go with the Titan X, but wanted to see if there was anything else out there to consider. Guess not.
You'd be better off with the 980 Ti. Just hold off a bit.

[Dogway]

Artifacts from different algorithms will be rather low, because the chroma channel is usually very soft. But if you're worried about this kind of problems, you can use both luma+chroma doubling, then this problem should be solved.

Multiple colorspace conversions are not "nice", but I'm using 16bit integer textures which have a LOT of precision, and I'm not cutting away BTB/WTW, either, so there's really not much to worry about. The colorspace conversions in madVR are not 100% lossless, but they should be nearly lossless.

Artifacts would be rather low... unless you use something as aggressive as NNEDI3. As you said (http://forum.doom9.org/showthread.php?p=1721413#post1721413) in the quote of my last post, "image" doubling is done with NNEDI3 for luma and Catmull-Rom for chroma, I want to point out what kind of artifacts you are going to get with such decision, in this post (http://forum.doom9.org/showthread.php?p=1721754#post1721754) there are various screenshots using "chroma upscale" as a case in point, but the same applies to "Image doubling". (nnedix2 (http://abload.de/img/nnedi3chromax2posri.png), catromAR (http://abload.de/img/nnedi3catv2misgl.png)). Just look at the mountains, you will see a lot of aliasing on the chroma plane because the luma is properly antialiased but chroma isn't, this might not be relevant on live films but on animation you are calling for problems.

Using high bitdepth precision is not going to save you from strong chroma plane degradation. Every conversion behaves like a lowpass filter in the chroma plane precisely because as you say chroma channel is usually very soft. You can check this using Color bars or calibration targets (or better yet colored grain). Anyways my question wasn't rhetorical, I'm interested on why you can't use YUV filtering/scaling until the very last step, specially when not using post-processing filters. What prevents you on doing so since it forces a great degradation mostly when the option "image doubling" is used.

[Asmodian]

Artifacts would be rather low... unless you use something as aggressive as NNEDI3. As you said (http://forum.doom9.org/showthread.php?p=1721413#post1721413) in the quote of my last post, "image" doubling is done with NNEDI3 for luma and Catmull-Rom for chroma, I want to point out what kind of artifacts you are going to get with such decision, in this post (http://forum.doom9.org/showthread.php?p=1721754#post1721754) there are various screenshots using "chroma upscale" as a case in point, but the same applies to "Image doubling".

madshi added chroma doubling back with v0.88.6 so I suppose this is not an issue anymore?

edit: BTW, the screen shots from that post were not using "chroma upscale", the source was RGB so "chroma upscale" was never needed or possible. The point was to test luma only doubling (with Jinc3 or Catmull-Rom for chroma scaling) v.s. both luma and chroma doubling.

Using high bitdepth precision is not going to save you from strong chroma plane degradation. Every conversion behaves like a lowpass filter in the chroma plane precisely because as you say chroma channel is usually very soft.

A lowpass filter?! A 16-bit RGB->YCbCr->RGB does not behave like a lowpass filter. It isn't going to YCbCr 4:2:0.

[MysteryX]

SuperRes is doing a GREAT job on 768p laptop display without too much cost on performance.

On 1080p TV, however, the performance hit is WAY too high!! It goes from 14ms rendering to 39ms. Even with basic upscaling algorithm, it won't work with SVP at 60fps.

Is it normal that there is such a big difference of performance hit with SuperRes between 768p and 1080p?

[Dogway]

edit: BTW, the screen shots from that post were not using "chroma upscale", the source was RGB so "chroma upscale" was never needed or possible. The point was to test luma only doubling (with Jinc3 or Catmull-Rom for chroma scaling) v.s. both luma and chroma doubling.

As I said, it behaves exactly as it currently does and as madshi stated, luma and chroma doubling don't use the same upscaler. This produces aliasing mismatches like the ones seen in the picture.

A lowpass filter?! A 16-bit RGB->YCbCr->RGB does not behave like a lowpass filter. It isn't going to YCbCr 4:2:0.
Don't raise any eyebrows, every conversion behaves like a lowpass filter when done successively, even with full chroma. This is original chroma plane (http://i.imgur.com/3lRMjr5.png), this is chroma plane after YUV,RGB,YUV444,RGB,YUV (http://i.imgur.com/eFUTk5E.png). And yes, it even has a lowpass filter feel to it when I use YUV444 for the last conversion (http://i.imgur.com/xhKvyus.png). Test script (http://pastebin.com/qq8YPaeq).

[omarank]

Thanks for the feedback! Seems there'll be another Shiandow deband iteration coming. <sigh> Of course it's all good, the algorithm getting better all the time. But I hope you users/testers won't be bored at some point, retesting revised algos all the time?
No, you may rest assured that we won’t be bored with the testing. The subsequent rounds of testing for the same feature actually help it evolve to become perfect.

However, it so happens that every time madVR is in active development, I have a relatively higher workload. So I am not able to contribute as much as I could normally do.:(


It's on my list.
Ok, thanks!

[James Freeman]

It seems Direct3D11 FSE stopped showing an image during playback for me in this release. Direct3D11 FS Windowed works as well as all modes of Direct 3D9. Direct3D11 FSE was working fine in the previous release.

I don't think DX11 is working for me after updating to 88.7.

FSE mode says "fullscreen exclusive mode new path" instead of FSE 10 bit.

Going back to 88.5 with same settings fixed issue.

I'm on Windows 7 x64, GTX 780, x64 MPC HC.

There is a "restore default settings.bat" in the madVR folder, run it and test again.
It fixed the problem for me.

[detmek]

If you see no advantage for D3D11 than there's no problem at all staying with D3D9. I think I didn't answer to your previous comment: If "use a separate device for presentation" causes the same problem with D3D9 then that points to a driver issue. I've had several of those with Intel already. Many of them have to do with sharing textures over multiple devices, sadly.


Thanks Madshi. If its a driver problem then it exists more then a year. Last year I switched from Nvidia GPU to IGPU. With Nvidia I had active "use a separate device for presentation" because it used to give me lower rendering times. After switching I forgot to reset madVR and I had some stutters. I resetted madVR settings and in process of elimination I found that mentioned option was a problem. I forgot about that until you asked me to activate that option.

[nijiko]

@madshi : Will madVR support multi-languages? I can help to translate to Japanese & Trad. Chinese.

[nevcairiel]

Don't raise any eyebrows, every conversion behaves like a lowpass filter when done successively, even with full chroma. This is original chroma plane (http://i.imgur.com/3lRMjr5.png), this is chroma plane after YUV,RGB,YUV444,RGB,YUV (http://i.imgur.com/eFUTk5E.png). And yes, it even has a lowpass filter feel to it when I use YUV444 for the last conversion (http://i.imgur.com/xhKvyus.png). Test script (http://pastebin.com/qq8YPaeq).

Thats absolute nonsense. Maybe if you store the intermediates in 8-bit all the time (like your test script appears to do), but if you store them with enough precision, it does not result in any image degredation.
I don't know what kind of Matrix madshi uses for this intermediate steps, but for example YCgCo is proven to be mathematically perfectly lossless given enough intermediate precision.

[Razoola]

I can confirm for me in 088.7 full screen exclusive mode is not reported as DX11 but in windows mode it is. Though I can't remember checking if there was ever a message to show it was in FSE DX11 or DX9

[Werewolfy]

Thanks for the feedback! Seems there'll be another Shiandow deband iteration coming. <sigh> Of course it's all good, the algorithm getting better all the time. But I hope you users/testers won't be bored at some point, retesting revised algos all the time?


I tested the lastest iteration so far and it's definitely better. In some cases it's better than the high preset but I found one case where it's very weak compared to the high preset. I wait until the next iteration comes out and if it's not corrected I will post a picture (or a sample video?) if it can help Shiandow.

[madshi]

Its difficult to explain, but I do know it for a fact. When I made Rec.709 3DLUT I had my TV's setting for Flesh Tone set to 0, but I accidentally left Flash Tone set to -15 when I created Rec.601 3DLUT. That creates an obvious difference when I switch between Rec.709 and Rec.601 3DLUT's using identical TV settings. Rec.709 line is used for SMPTE C content for sure, at least in 88.5.
Ok, let's do some more tests:

1) Leave all your settings just as they are, but rename one of the 3dlut files to something else (e.g. add "dummy" to the file name). madVR should then complain about the missing file. If you do this with a Rect.601 video file, then which file do you have to remain to make madVR complain?

2) If you toggle through the primaries (Ctrl+Alt+Shift+P), does that make madVR load the correct 3dlut?

It's not very time consuming, and if one wants better quality it's not really a sacrifice.
No, you may rest assured that we won’t be bored with the testing. The subsequent rounds of testing for the same feature actually help it evolve to become perfect.
Good to hear - thanks! So Shiandow, bring on the next version of your Deband script! :)

However, have we seen yet example images that show a real advantage for Shiandow's current implementation?
I for myself haven't found such an example yet. Higher threshould values with bad sources can be nice because of that deblocking effect, but it vanishes too much detail with good sources.
Well, to be honest, I'm kinda glad that it appears to be hard for Shiandow to create an algorithm which beats mine, it shows that my algorithm isn't half bad. But as long as he has ideas on how to improve his algorithm, let him keep trying. Maybe we'll and up with a superior solution sooner or later.

FWIW, maybe I could improve my "high" preset, too. I have the "angle" feature for "low" and "med", which is currently disabled for "high". I spent a lot more time developing the low/med algos. So maybe there's some room left in my algorithm to improve for "high". Sadly, I don't have a lot of time left for madVR at the moment. So it'll have to wait...

88.7 works wonderful for me! I get no frame drops, even when I use Chroma Upscaling SuperRes Filter and also enable SuperRes in Image Refinement (High setting). Hell, I even enabled Octuple settings and everything is peachy! Shiandow's debanding and new setting (0.2 for threshold and 1 for detail level) are also better. I used to get obvious big shimmering squares (NOT dithering) on darker grays in Mid/Low-HQ content that were not present when only the original debanding was used. With 88.7 and new Shaindow's settings, those shimmering squares are now a lot smaller. Sometimes I think the original de-banding is still better, not as noisy.
Ok, thanks for your feedback!

Stupid(?) question - When testing deband algos, we should check one or the other, correct? Leaving both checked is effectively using both algos simultaneously, or am I missing something?
Correct.

This version appears to have broken D3D11 entirely on my Win7 GTX770 system, or rather it never activates and madVR always uses D3D9. It works when I reset madVR to defaults though, so it must be something related to my settings/profiles, but so far I've not been able to figure out which causes it.
In the latest build (0.88.7) d3d11 is not enabled at all even if I check the option. The OSD shows always "(new path)" both in windowed mode and FSE.
I don't think DX11 is working for me after updating to 88.7.

FSE mode says "fullscreen exclusive mode new path" instead of FSE 10 bit.

Going back to 88.5 with same settings fixed issue.
There are 2 possible reasons for why the D3D11 path might not be activated:

1) Either you have desktop composition disabled (only possible on Windows 7).
2) Or you have the number of video frames which shall be presented in advance set to 16. I've just found out after releasing v0.88.7 that 15 is that max I can do. Using 16 means the D3D11 device creation fails. So lower this option to 14 (15 isn't currently supported), and D3D11 should start working again.

Should I use native display bitrate 8bit or 10bit ? I'm using the D3D11.
Nobody can tell you. Depends on your display. Zoom the "smallramp.ytp" test pattern (see madTestPatternSource filter download on the first post of this thrad) to fullscreen, then compare 8bit vs 10bit output and use that which looks better to your eyes.

What should I choose for debanding Debanding Strength - medium / fade in/out high ? or to enable shaindow's deband threshold 0.5 detail level 2 ? I don't remember if that's the default
That's still up in the air. If you're not sure, use the "old" algorithm (low, medium or high) instead of Shiandow's deband algorithm for now.

Should I use quadruple luma resolution ?
If your GPU has the power for that, why not?

How come without the Settings.bin file in the folder Madvr keep my settings ? and after that it makes the file, how it remembers all my settings without the settings.bin ?
The settings are also stored in the registry. You can double click on "restore default settings.bat" to clear out all old settings.

In 0.88.6 the refresh rate fix doesn't work. With D3d9 FSE both 24p and 60p work but with d3d11 FSE only 60p works, 24p doesn't work yet.
Let me explain what happens: my monitor has a 23p with a blurred image and a timing of 23.970 so I created a 24p custom resolution with the exact timing of 23.976 and a clear image. When MPC enters in FSE the resolution is switched back to the blurred 23p even if I set my 24p in the nvidia control panel.
I'm using MPC-HC 1.7.8.162 x64, Lav 0.65-2 and Windows 8.1 x64. I have a gtx 660 with 350.12 and an intel q9550.
So your blurred mode is known to Windows as 23p and your "good" mode is known to Windows as 24p? Which modes did you add to the madVR display mode changing list?

It probably changes the error upscale step from bilinear to something else, maybe Jinc3 based on the rendering times?
High quality is Jinc3. Medium quality is SoftCubic50. This is for upscaling the error texture which is part of the SuperRes algorithm.

1. the artefacts are back when using nnedi3, both, in chroma upscaling and image doubling.
It was fine with v0.87.21. (was about kepler gtx670 , win 764bit and 32bit..)
Maybe you need to reapply the fix suggested by cyberbeing, which IIRC was clearing the madVR OpenCL registry storage key and then recreating the kernel with the 64bit madVR build.

2. when using d3d11 mode in FSE/windowed my monitor resolution resets and stuff is cut off..it changes my desktop resolution also and changes teh hz form 60 to 25...
with the normal d3d9 (new path) mode it works fine doh, all 60 hz...
Which modes do you have listed in the madVR display mode changer? And which exact mode does either D3D9 or D3D11 switch to? (Using the same video file)

It seems Direct3D11 FSE stopped showing an image during playback for me in this release. Direct3D11 FS Windowed works as well as all modes of Direct 3D9. Direct3D11 FSE was working fine in the previous release.
You mean you just get a black screen? Does the debug OSD work (Ctrl+J)? Do you have 10bit output enabled? Try with 8bit output.

Thanks Asmodian. I am happy with the settings I am using, but knowing I can do more with a more powerful card is killing me. I am using a Sony VW600ES 4K projector to a 110" screen so every bit of improvement is noticeable. I will most likely go with the Titan X, but wanted to see if there was anything else out there to consider. Guess not.
Next generation GPUs are just around the corner, I'd wait for those, as already suggested by the other users.

0.88.7 introduced it for me.
I had to run "restore default settings", and everything works fine now.
Is it a standard procedure to reset setting with every new build? If so, my bad sorry.
It's not a standard procedure. Not sure which setting was the problem. Anyway, glad to hear it's working fine with default settings now.

Alright, quality wise it is almost impossible to differentiate between the two when they are properly set.
Any one of them will be adequate.
Ok, thanks!

Artifacts would be rather low... unless you use something as aggressive as NNEDI3. As you said (http://forum.doom9.org/showthread.php?p=1721413#post1721413) in the quote of my last post, "image" doubling is done with NNEDI3 for luma and Catmull-Rom for chroma
Only if you configure madVR that way!! In the latest build you can use the same algorithm for both luma and chroma, if you want. So problem solved.

Using high bitdepth precision is not going to save you from strong chroma plane degradation. Every conversion behaves like a lowpass filter in the chroma plane
Ok, let's do a simple check. Do this math for me, please:

34 * 0.222 = x
x / 0.222 = y

Do x and y differ? If not, then there's your proof that not *every* conversion behaves like a lowpass filter. Converting between RGB and YCbCr is pretty similar to what I wrote above. It's just a series of multiplications and additions. And there's an *exact* inversion math to go back to the old colorspace. If I used float32 textures, the colorspace conversions would probably be perfectly lossless. Since I'm only using 16bit integer textures, there's a very small quality loss to be expected. But it's nothing like a lowpass filter. A lowpass filter requires that each pixel is influenced by its neighbor pixels. That's simply not the case when doing a color space conversion. The color space conversion might lose 0.00001% of precision, but the precision loss is much lower than any instrument or even our eyes could ever measure.

I'm not sure where you got your ideas from (lowpass filter and all). Those ideas are clearly technically incorrect.

SuperRes is doing a GREAT job on 768p laptop display without too much cost on performance.

On 1080p TV, however, the performance hit is WAY too high!! It goes from 14ms rendering to 39ms. Even with basic upscaling algorithm, it won't work with SVP at 60fps.

Is it normal that there is such a big difference of performance hit with SuperRes between 768p and 1080p?
The key factor will be how many upscaling steps there are. What does the debug OSD (Ctrl+J) say about those 2 situations? What is the exact upscaling chain (e.g. "Nnedi32 > Jinc3 AR" or something like that) in either case?

every conversion behaves like a lowpass filter
No, it does not. Maybe there's degradation when using AviSynth, I don't know. Is that where you drew your conclusions from? AviSynth is limited to 8bit, IIRC? AviSynth tests don't tell you how madVR behaves. madVR has a dramatically higher calculation bitdepth than AviSynth.

E.g. 34 * 0.222 = 7.548 -> rounded to 8bit = 8
8 / 0.222 = 36.04 -> rounded to 8bit = 36

So by using 8bit math, a value of 34 after one color conversion step suddenly becomes 36. That's terrible!!! But now let's check what madVR does:

34 * 0.222 = 7.548 -> rounded to 16bit = 494666 / 0x10000
494666 / 0x10000 / 0.222 = 34.0000187 -> rounded to 8bit = 34

You see the difference? And 16bit integer is just the storage format used by madVR to store data between different processing steps. Calculation is actually done in 32bit floating point which has an even higher precision than 16bit integer.

[madshi]

Thats absolute nonsense. Maybe if you store the intermediates in 8-bit all the time (like your test script appears to do), but if you store them with enough precision, it does not result in any image degredation.
I don't know what kind of Matrix madshi uses for this intermediate steps, but for example YCgCo is proven to be mathematically perfectly lossless given enough intermediate precision.
Exactly.

Thanks Madshi. If its a driver problem then it exists more then a year. Last year I switched from Nvidia GPU to IGPU. With Nvidia I had active "use a separate device for presentation" because it used to give me lower rendering times. After switching I forgot to reset madVR and I had some stutters. I resetted madVR settings and in process of elimination I found that mentioned option was a problem. I forgot about that until you asked me to activate that option.
Yes, it's been a long standing issue with Intel drivers, unfortunately.

@madshi : Will madVR support multi-languages? I can help to translate to Japanese & Trad. Chinese.
Maybe at some far away time in the future, but not any time soon. Hey, I'm German, and madVR doesn't even support German yet!! ;) English will have to do for everyone for the time being.

I can confirm for me in 088.7 full screen exclusive mode is not reported as DX11 but in windows mode it is. Though I can't remember checking if there was ever a message to show it was in FSE DX11 or DX9
Does it say "8 bit" or "10 bit"? Then it's DX11. Only the DX11 FSE mode does that. I didn't add "D3D11" because together with the bitdepth it made the OSD so very wide.

I tested the lastest iteration so far and it's definitely better. In some cases it's better than the high preset but I found one case where it's very weak compared to the high preset. I wait until the next iteration comes out and if it's not corrected I will post a picture (or a sample video?) if it can help Shiandow.
Ok, thanks! :)

[James Freeman]

I can confirm for me in 088.7 full screen exclusive mode is not reported as DX11 but in windows mode it is. Though I can't remember checking if there was ever a message to show it was in FSE DX11 or DX9

In FSE mode the OSD will display the following:

In D3D11;
fullscreen exclusive mode, 8 bit
fullscreen exclusive mode, 10 bit

In D3D9;
fullscreen exclusive mode (new path)
fullscreen exclusive mode (old path)


madshi,
In d3d9 mode when I switch "present several frames in advance" OFF in "exclusive mode settings" it also effects the windoed mode, meaning windowed or FSE it is always (old path).

[cyberbeing]

2) Or you have the number of video frames which shall be presented in advance set to 16. I've just found out after releasing v0.88.7 that 15 is that max I can do. Using 16 means the D3D11 device creation fails. So lower this option to 14 (15 isn't currently supported), and D3D11 should start working again.

That was the problem. Is this something you can fix, considering 16 could be used with DX11 in previous versions, or will 15 now be the new limit going forward?

[iSunrise]

also not sure if this is expected behaviour, but madVR when paused seems to keep rerendering the image, ie I can see the rendering times updating all the time, and cpu usage shows mpc-be is not at 0. I guess this is expected or is the intention that it truly does use 0 when paused?
Think about comparisons, when you change settings. Without madVR updating the image we would not have been able to do comparisons within the player. This is intentional and very useful.

[nijiko]

Maybe at some far away time in the future, but not any time soon. Hey, I'm German, and madVR doesn't even support German yet!! ;) English will have to do for everyone for the time being.

I think you can make the strings output to a .ini file. Then people can modify it for himself/herself.

[mark0077]

Think about comparisons, when you change settings. Without madVR updating the image we would not have been able to do comparisons within the player. This is intentional and very useful.

Yep, madshi confirmed its only when Ctrl-J stats are up which makes sense. Wouldn't have been very useful to have it using cpu / gpu when paused for majority of users.

[madshi]

That was the problem. Is this something you can fix, considering 16 could be used with DX11 in previous versions, or will 15 now be the new limit going forward?
DX9 allows up to 32/31 frames. DX11 only 16/15. So for DX11 15 will be the upper limit.

I think you can make the strings output to a .ini file. Then people can modify it for himself/herself.
It's not a question of how to do it. It's a question of development priorities. Furthermore it doesn't make much sense to work on things like that if the settings dialog is still not in its final form. Lots of options will still come and go. It's better to do things like this once all features are implemented and finalized.

[andybkma]

There are 2 possible reasons for why the D3D11 path might not be activated:

1) Either you have desktop composition disabled (only possible on Windows 7).
2) Or you have the number of video frames which shall be presented in advance set to 16. I've just found out after releasing v0.88.7 that 15 is that max I can do. Using 16 means the D3D11 device creation fails. So lower this option to 14 (15 isn't currently supported), and D3D11 should start working again.




madshi, I have a problem getting your new D3D11 path to be activated on my Win7, mVR 88.7. Following your words above, I have D3D11 enabled, I do not have desktop composition disabled and I have the number of video frames presented in advance below 16 (I have it set to your defaults). Yet in window mode in the OSD it says [old path] and in FSE it says [new path].

Toggling the D3D11 path on/off/on didn't help, it is same OSD display whether it is checked or not.

Thanks

[madshi]

You don't have desktop composition disabled in the madVR options? Or both in the madVR options *and* in the OS? Basically Aero/DWM must be turned on in the OS.

And you do have the Windows 7 Platform Update installed?

[Siso]

I noticed that in D3D11 fullscreen windowed mode the average present stats are around 0.48ms, in D3D9 they are around 0.14ms. What is the difference actually, isn't D3D11 better?

[XRyche]

There is a "restore default settings.bat" in the madVR folder, run it and test again.
It fixed the problem for me.

I actually saw your comment and tried that before I posted last night. Thank you though.

[ibius]

I noticed that in D3D11 fullscreen windowed mode the average present stats are around 0.48ms, in D3D9 they are around 0.14ms. What is the difference actually, isn't D3D11 better?

You're a bit late to the party, it's a known issue.

madVR v0.88.7 released
* fixed: D3D11 render queue didn't fill in Windows 7



Thanks for that, it also fixed my render queue and unusually high CPU usage in FS, on Win8.1.

There's still strange behavior when flushing after copy to backbuffer - half-full render queue in FS/FSE.

With 'flush and wait (sleep)' enabled for 'after copy to backbuffer', I still get render queue 3-5/8, but at least present times go down to reasonable values, although not as low as D3D9's.

'Flush' and 'Flush and wait (loop)' result in additional high CPU usage.

[Dogway]

Thats absolute nonsense. Maybe if you store the intermediates in 8-bit all the time (like your test script appears to do)
That tone... (urghh). Script's pipeline is 16-bit.

Only if you configure madVR that way!! In the latest build you can use the same algorithm for both luma and chroma, if you want. So problem solved.

I'm not sure where you got your ideas from (lowpass filter and all). Those ideas are clearly technically incorrect.

Maybe there's degradation when using AviSynth, I don't know. Is that where you drew your conclusions from? AviSynth is limited to 8bit, IIRC? AviSynth tests don't tell you how madVR behaves. madVR has a dramatically higher calculation bitdepth than AviSynth.
I see, so that post of you for chroma doubling was in relation to a middle build which was working things out differently. No problem then if both use NNEDI.

In avisynth every color conversion is highly avoided due to quality loss, even in 32-bit precision on 16-bit pipelines and YV24 intermediary as in my example (yes, this is possible in avisynth, so unless I missed something -color spaces?- it's an apples to apples comparison).

In that regard, every *real world* conversion leads to quantization errors which translate to blurring. Just run a colored grain test and it will show all the shortcomings of your current process, as nevcairel pointed besides the limited 16-bit it's not even using YCgCo, you also need to use proper wide gamut color spaces to hold the float32 textures otherwise some colors are going to be clipped.

But again I ask, what steps in the process forces you to go to RGB that justifies these color conversions?

[nevcairiel]

In avisynth every color conversion is highly avoided due to quality loss, even in 32-bit precision on 16-bit pipelines and YV24 intermediary as in my example (yes, this is possible in avisynth, so unless I missed something -color spaces?- it's an apple to apples comparison).

YV24 is a 8-bit format (8-bit 4:4:4, thats why its called 24, 24-bits per pixel).

[baii]

Old profiles is buggy in the new build, definitely try reset to default if can't get in to dx11.

Sent from my 306SH

[clsid]

Maybe you need to reapply the fix suggested by cyberbeing, which IIRC was clearing the madVR OpenCL registry storage key and then recreating the kernel with the 64bit madVR build.If there are possible incompatibilities, wouldn't it make sense to store the 64bit kernel separately? And maybe also recreate it whenever madVR version or GPU driver changes?

[nijiko]

It's not a question of how to do it. It's a question of development priorities. Furthermore it doesn't make much sense to work on things like that if the settings dialog is still not in its final form. Lots of options will still come and go. It's better to do things like this once all features are implemented and finalized.

Well, I see. Though English is no problem, mother language is more friendly and kind. This thing you pointed is also a trouble now, so English is OK, thank you very much!

BTW, I bought a new large displayer, and madVR use 8bit output setting by default, how can I check whether my displayer support 8bit or 10bit?

[Dogway]

YV24 is a 8-bit format (8-bit 4:4:4, thats why its called 24, 24-bits per pixel).

I use a 16-bit YV24 format, if you re-analyze the script you will find "lsb=true" in the same line, it's a method to work with files in 16-bit (read here (http://avisynth.nl/index.php/Stack16)).

[huhn]

Well, I see. Though English is no problem, mother language is more friendly and kind. This thing you pointed is also a trouble now, so English is OK, thank you very much!

BTW, I bought a new large displayer, and madVR use 8bit output setting by default, how can I check whether my displayer support 8bit or 10bit?

this should help a lot:
http://forum.doom9.org/showthread.php?t=172128

only the totally high end displays like samsung SUHD can have a true 10 bit panel.

[Razoola]

In FSE mode the OSD will display the following:

In D3D11;
fullscreen exclusive mode, 8 bit
fullscreen exclusive mode, 10 bit

In D3D9;
fullscreen exclusive mode (new path)
fullscreen exclusive mode (old path)


madshi,
In d3d9 mode when I switch "present several frames in advance" OFF in "exclusive mode settings" it also effects the windoed mode, meaning windowed or FSE it is always (old path).

Yes that is the behaviour I'm seeing here so I guess its ok. Maybe if DX11 and DX9 text is added to those messages it could save potential confusion going forward.

[madshi]

I see, so that post of you for chroma doubling was in relation to a middle build which was working things out differently. No problem then if both use NNEDI.
Correct.

In avisynth every color conversion is highly avoided due to quality loss, even in 32-bit precision on 16-bit pipelines and YV24 intermediary as in my example (yes, this is possible in avisynth, so unless I missed something -color spaces?- it's an apples to apples comparison).

In that regard, every *real world* conversion leads to quantization errors which translate to blurring. Just run a colored grain test and it will show all the shortcomings of your current process
I'll say it again: You cannot use AviSynth as a proof for anything related to madVR. AviSynth has historically been limited to 8bit. I know there are some hacks you can use to force higher bitdepth with some filters, if those filters have special support for that. But I wouldn't bet on that every part of the processing pipeline from start to finish really makes full use of the highest bitdepth.

Look at the numbers/math from my previous reply and comment on that. That's a much better ground for discussion than running AviSynth tests with weird bitdepth hacks.

you also need to use proper wide gamut color spaces to hold the float32 textures otherwise some colors are going to be clipped.
Well, madVR's pipeline is running in video levels and not in PC levels, so there's sufficient foot and head room for all channels to not clip anything important.

But again I ask, what steps in the process forces you to go to RGB that justifies these color conversions?
There's RGB, YCbCr, R'G'B' and Y'CbCr. For best scientific scaling you'd need to scale in RGB or YCbCr. And that's what you can do with madVR by enabling the "scale in linear light" option. However, for upscaling this has proven to not work as well a expected. E.g. ringing artifacts get *much* stronger that way. So I'm using R'G'B' scaling instead. There are several reasons for that. One is that R'G'B' is probably a more perceptually uniform colorspace than Y'CbCr, which means that linear scaling algorithms might produce slightly superior results in R'G'B' compared to Y'CbCr. Another is that madVR supports all kinds of input formats. E.g. DCI sources are encoded in R'G'B'. Or PC game recordings, or other stuff. madVR has to handle both Y'CbCr and R'G'B' sources. And it's simply easier to convert them all to the same format, so that I don't have to implement multiple parallel, but totally different processing pipelines.

Anyway, as I said before, the R'G'B' <> Y'CbCr conversions are nearly lossless, due to the high bitdepth I'm using for processing and storage, and due to having enough head room and foot room for out-of-gamut colors. So there's no worry.

Anyway, if you need proof, the FineSharp HLSL shader package contains RGB <-> YCbCr conversion routines:

http://www.mediafire.com/download/yi9tla70y8sts47/ToYuv_ToRGB.zip

You can use them in MPC-HC to let madVR convert between R'G'B' and Y'CbCr, and you can repeat that process e.g. 10 times in a row. Do that with any test video you like, then compare the output with the custom shaders enabled/disabled. I believe you'll not be able to see any difference. Please uncheck all the madVR "trade quality for performance" options in madVR for this test, though.

[Razoola]

@madshi, I see your point about the OSD getting wide in relation to adding DX11 or DX9 to the OSD's 'Fullscreen exclusive mode' line. Have you considered removing 'fullscreen' from that line given that is clearly visible from the screen size anyway. In effect replace 'fullscreen exclusive mode, 8 bit' with 'DX11 exclusive mode, 8 bit'. Then do the same with the DX9 modes also?

[madshi]

Ya, makes sense, I guess...

[huhn]

@madshi, I see your point about the OSD getting wide in relation to adding DX11 or DX9 to the OSD's 'Fullscreen exclusive mode' line. Have you considered removing 'fullscreen' from that line given that is clearly visible from the screen size anyway. In effect replace 'fullscreen exclusive mode, 8 bit' with 'DX11 exclusive mode, 8 bit'. Then do the same with the DX9 modes also?

i would prefer something like FSE D3D11 10 bit.

[Barnahadnagy]

Anyway, if you need proof, the FineSharp HLSL shader package contains RGB <-> YCbCr conversion routines


I wanted to write a little test application for this to prove this precision is more than enough, but with this I just tested it a bit. Surprisingly, if I zoom in 2500%, I can see very faint differences, I didnt expect to see anything really. Then again, I put in about 30 conversions... Anyways, if this doesnt prove that the conversions are high-enough precision, don't know what does.

Regarding OSD: I quite like "FSE D3D11 10 bit".

[Anime Viewer]

Thanks for the feedback! Seems there'll be another Shiandow deband iteration coming. <sigh> Of course it's all good, the algorithm getting better all the time. But I hope you users/testers won't be bored at some point, retesting revised algos all the time?



I think there is something strange at play in madVR resulting in artifacts. Starting by setting both programs to defaults, then configuring both for 10-bit, using the same upscalers, DX11, Shiandow's debanding (with identical settings), SuperChromaRes, and SuperRes (with identical NEDI settings in both), and ordered dithering in both I am seeing more artifacts in madVR than MPDN in the same video scenes. I've included a screen shot below.
Anyone have theories as to what may be causing the additional artifacts in madVR?

http://s17.postimg.org/lznm6e7j1/madvr_vs_mpdn.jpg
In particular I notice the additional artifacts around the Japanese characters/letters, edge and teeth of the creature, and floating green debris. While its not a huge overall difference it is noticeable to me.

[Dogway]

For best scientific scaling you'd need to scale in RGB or YCbCr. And that's what you can do with madVR by enabling the "scale in linear light" option.

Yes, that's true, in avisynth we compress and uncompress gamma in RGB as well. I forgot that bit, it's also prone to ringing or clipping for blacks so it makes sense, thanks for explaining. In that regard is understandable to default to RGB.

I will test with the HLSL shader, it's possible that addgrainC is not deterministic so I can have a better look with the real thing instead. Will be calibrating the panel soon and create a profile for madVR so I still have to learn how the whole thing works.

[tobindac]

It's probably normal seeing detailing artifacts when you pump the sharpening algorithms. Their job is to expose small deviations and make them clear. What did you expect to happen, pull out of a hat that you don't want to expose a small part of them?

If your source isn't anything too damaged, I would start with no filters at all and then start adding only when needed, if you only care about your everyday normal viewing experience.

[madshi]

I think there is something strange at play in madVR resulting in artifacts. Starting by setting both programs to defaults, then configuring both for 10-bit, using the same upscalers, DX11, Shiandow's debanding (with identical settings), SuperChromaRes, and SuperRes (with identical NEDI settings in both), and ordered dithering in both I am seeing more artifacts in madVR than MPDN in the same video scenes. I've included a screen shot below.
Anyone have theories as to what may be causing the additional artifacts in madVR?
For screenshot comparisons it's MUCH better to use two separate images, so you can put each in a browser tab and switch back and forth. Doing that with your images shows that it's not the same frame, which is already a big "no no" for screenshot comparisons. Ignoring that, the madVR image is much much sharper than the other image. Of course if you blur the whole image you also blur the artifacts. So the result is not surprising. I'm not sure why the other image is so much softer. Seems the settings are not perfectly matched, for some reason.

I will test with the HLSL shader, it's possible that addgrainC is not deterministic so I can have a better look with the real thing instead.
Let me know what you find!

[aufkrawall]

@Shiandow:
How can I use it in madVR?
It crashes when the shader files are copied into the specific folder.

[leeperry]

Actually, no. The "octuple" option had nothing to do with that. You can't uncheck "double/quad chroma resolution" if you have NEDI selected because NEDI handles luma+chroma at the same time.
I'm quite sure my problem was real with 0.87.6 using NEDI but then again I was tired so maybe I missed the extra N and 3 at the end as I was doing A/B comparisons between both before you released this build.....long story short 0.87.7 does work exactly as intended TYVM :)

If anything's confusing it's that both algorithms are almost named exactly the same when one is a GPU hog and looks artificial and the other feeds RGB so it'll also double chroma simultaneously.

I really didn't like NNEDI3's chroma upscaling/doubling artificial look and far prefered Jinc3AR so I'm not sure whether I'm too happy with NEDI's chroma doubling being mandatory but it can't be disabled anyway and PQ is fantastic so whatever :devil:

I take it that NEDI chroma upscaling isn't possible?

Isn't "always - if upscaling is needed" exactly the same as 1.01/2.01? I'm confused.
I was hoping this would mean ">1.0" for both so you could go nuts and force 4X/8X in order to go SuperSampling (http://avisynth.nl/index.php/Supersampling).

I would personally prefer if "always - if upscaling is needed" really meant what is says as in "always - if >1.0 upscaling is needed" even for 4X/8X and that the next step was ">1.01" for 2X and ">2.01" for 4X/8X.

AMD still has interop issues which slow them down so I don't think AMD is a better option for NNEDI3 image doubling
Oh yah, NEDI doesn't use OpenCL and I far prefer it in combo with SuperRes to NNEDI3, Error Diffusion runs DirectCompute and apparently the interop lag is only related to OpenCL so that means that I could finally update from the 13.12 drivers then? Anyone tried that on W7SP1? :devil:

AMD will more than likely never fix this issue and might have (far) more efficient GPU's out in a few months so I'd rather not depend on OpenCL anymore.

Think about comparisons, when you change settings. Without madVR updating the image we would not have been able to do comparisons within the player. This is intentional and very useful.
Pausing mVR is a total no can do on my rig(HD7850/W7SP1/13.12) as the GPU load goes completely nuts, it's pretty frigging annoying tbh as I always have to stop playback instead of pausing. Pausing is a privilege I'm not entitled to as it would appear :(

[madshi]

I really didn't like NNEDI3's chroma upscaling/doubling artificial look and far prefered Jinc3AR so I'm not sure whether I'm too happy with NEDI's chroma doubling being mandatory but it can't be disabled anyway and PQ is fantastic so whatever
That confuses me. If NNEDI3 is artificial looking then NEDI is even more so, IMHO. And the effect is more pronounced for luma than for chroma.

I take it that NEDI chroma upscaling isn't possible?
It's possible, but extra work, and I hope that SuperChromaRes will be the better option. But it's too early to talk about that, because we're still in the Deband feedback phase.

Pausing mVR is a total no can do on my rig(HD7850/W7SP1/13.12) as the GPU load goes completely nuts, it's pretty frigging annoying tbh as I always have to stop playback instead of pausing.
That's due to PotPlayer wanting to draw animations and stuff during paused playback. It's madVR's fault, really, but if you turn the PotPlayer madVR specific OSD off, this problem should go away for now. Of course then you'll probably lose the FSE compatible OSD, as well. The high GPU load in paused state with PotPlayer will probably be fixed in a future build, but it has low priority for now.

[James Freeman]

Anything special to look for besides how effective the debanding filter is?
I guess a lot of people don't have a clue (including me) what to look for, that's why this poll is slowish to say the least.

I guess I'll start with a super compressed video where the banding are absolutely everywhere.

[leeperry]

That confuses me. If NNEDI3 is artificial looking then NEDI is even more so, IMHO. And the effect is more pronounced for luma than for chroma.
Well, I think I really hate those "fractal artifacts" with NNEDI3 you mentioned several times (http://forum.doom9.org/showpost.php?p=1685193&postcount=124):
Their NEDI first pass (before running the Super-Res passes) looks very clean, almost without any directional/fractal artifacts.
I realize that you were talking about SmartEdge 2 and maybe it's actually SuperRes that impresses me but at the end of the day I prefer NEDI+SR over NNEDI3, the picture looks more natural to me and it's not a GPU hog so that really kills all birds at once for me.

That's due to PotPlayer wanting to draw animations and stuff during paused playback. It's madVR's fault, really, but if you turn the PotPlayer madVR specific OSD off, this problem should go away for now. Of course then you'll probably lose the FSE compatible OSD, as well. The high GPU load in paused state with PotPlayer will probably be fixed in a future build, but it has low priority for now.
Well, its fully skinnable D3D GUI that doesn't break mVR's FSE is part of the package and I really don't like the "windowed/exclusive" constant nagging in the top left corner when disabling it.

I also wish pausing in mVR would kick in some sort of screensaver in order to avoid leaving a fixed image for too long(crucial issue on plasma, and OLED as well FWIR). When I want to pause, I have to close PotP and switch to a TV channel, oh well PQ is totally worth the hassle so no biggy :cool:

we're still in the Deband feedback phase.
Sorry, can't help with that due to my colorblindness.

[aufkrawall]

NNEDI introduces aliasing, NNEDI3 doesn't do this.
That's why NNEDI3 looks by far the best with cartoon content with extreme scaling. To me it looks most natural and I can't tell if artifacts are because of the source or the scaling itself. All I know is that there are least artifacts and it's much sharper than Jinc3.
At least for luma it's better, imho.

[madshi]

Anything special to look for besides how effective the debanding filter is?
I guess a lot of people don't have a clue (including me) what to look for, that's why this poll is slowish to say the least.

I guess I'll start with a super compressed video where the banding are absolutely everywhere.
The trick is that a good deband algo on the one hand has to remove as much banding as possible, but on the other hand should keep all real image detail intact. This is hard because sometimes the difference between banding and image detail is almost impossible to know for a dumb computer algorithm. So what you need to look for is a video source which has visible banding, but which also has low contrast detail. Debanding doesn't have a problem with high contrast detail. But if there's detail which is only visible very weakly, then debanding is in danger of removing it. E.g. imagine a faint real image detail pattern on some shadow area. This pattern might consist of gray tones which are just 1-2 RGB values apart from each other. This is a situation where debanding could accidently remove this faint image detail.

The perfect deband algorithm would remove all the banding, and at the same time keep all the real image detail. IMHO that's probably impossible to do for a non-human-intelligence algorithm. So the best compromise is needed.

Well, I think I really hate those "fractal artifacts" with NNEDI3 you mentioned several times (http://forum.doom9.org/showpost.php?p=1685193&postcount=124):

I realize that you were talking about SmartEdge 2 and maybe it's actually SuperRes that impresses me but at the end of the day I prefer NEDI+SR over NNEDI3, the picture looks more natural to me and it's not a GPU hog so that really kills all birds at once for me.
NEDI has much stronger fractal artifacts than NNEDI3. However, SuperRes really helps there. So a combination of NEDI+SuperRes *may* be able to compete with NNEDI3. However, you can also combine NNEDI3 with SuperRes, too! So there's a lot of things to try out to find the best quality. But as I said, it's too early to discuss that. We'll come to SuperRes discussion sooner or later, but we're not there yet.

NNEDI introduces aliasing, NNEDI3 doesn't do this.
That's why NNEDI3 looks by far the best with cartoon content with extreme scaling. To me it looks most natural and I can't tell if artifacts are because of the source or the scaling itself. All I know is that there are least artifacts and it's much sharper than Jinc3.
At least for luma it's better, imho.
Agreed. However, SuperRes has the potential to change things. Without SuperRes I would not have added NEDI. Only the combination makes sense, IMHO. But as mentioned before, I'd like to concentrate on debanding for now and move SuperRes/NEDI etc discussion to a later time.

-------

The new Shiandow Deband version will probably be available in madVR on Sunday. It appears to be another step up from the previous build, so I'll be quite interested in hearing your opinions.