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 16th June 2015, 15:20   #31141  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by XMonarchY View Post
Any ideas why Direct3D 11 causes so many problems on my rig? I think in previous version of madVR, it was finally working fine, but in the latest, it keeps creating tiny stutters 10-15 times per 45 minute video. I am sorry if I missed a reply to this...
You're not providing enough information for me to say anything useful. Do any of the queues empty when that stuttering happens? Which queue(s)? Do you get frame drops or presentation glitches in that moment?

Quote:
Originally Posted by ryrynz View Post
On a 1080 clip it does this for about 10-15 seconds with standard queue settings, on a smaller video it only lasted a second or so. Adjusting the GPU /CPU setting seemed give the most benefit. Going beyond 24 (max GPU) didn't really help. Changing the delay playback settings didn't change anything.

Just passing on that on the 750Ti I have to disable the present a frame for every vsync option for D3D 11 or I get a small amount of glitches and dropped frames every so often.
Oh, so disabling the "present a frame for every vsync" fixes this issue for you? What's your refresh rate and your movie frame rate? That option should only have an effect when the refresh rate / movie frame rate don't match exactly.

Quote:
Originally Posted by iSunrise View Post
Will have to wait until the weekend, I don't have access to my setup currently (iPhone). Will that reduce the heavy artefacts or what exactly is your goal with it?
As I wrote earlier, I've switched from a 2.2 pure power curve to an 1.7 BT.709 curve. The change in gamma value alone means the test build is somewhere in the middle between LL on and off. The switch to the BT.709 curve further seems to reduce those "black ringing" artifacts. I hope the test build will make a nice compromise everybody can live with.

Quote:
Originally Posted by iSunrise View Post
It's thick relative to the what's left of the black area that originally was a perfectly 0,0,0 black area. The outside ringing on that image is barely noticable in comparison, secondly, the ringing on the outside was already part of the image that just got more pronounced.
Once again "barely noticable" is your subjective impression. To my eyes it's very obvious. And no, the outside ringing around the squirrel "box" was *not* already part of the image. There is zero ringing outside of the black box in the original image. Check my screenshot with FS off again. It's simply incorrect what you're claiming here.

Quote:
Originally Posted by iSunrise View Post
The diag image definitely shows more pronounced outside ringing, I never disagreed with you on that.
Oh yes, you did. Some posts ago I wrote:

> But in the left half of the squirrel test pattern, actually there
> were less ringing artifacts with LL turned on compared to off.

Then you replied with:

> If you refer strictly to the diagonal lines test, please zoom
> into your own images and show me that there is actually less
> ringing, because I could not reproduce that. LL always produces
> darker edges with more heavy ringing.

("diag" shows the same effect as the diagonal lines)

Quote:
Originally Posted by iSunrise View Post
I very rarely watch black (0,0,0) fonts on white backgrounds (255,255,255), though. Not sure about yourself.
Once again simply incorrect information from your side. We're talking about black fonts *and* lines on *gray* background, not white background. I don't have the time atm to go hunting for real image content which has black lines on gray background, but it shouldn't be that rare...

Quote:
Originally Posted by James Freeman View Post
Oh, that's a great idea. Automation is always good!
So for 480 and 720 just scale them 200% and try to match appearance to 1080 right?
Even if MPC-HC will downscale the image to the screen size? OR retain the video frame on "Double Size"?
Well, I think you really need to decide first if you want to test for image enhancements or for upscaling refinement. Either is fine with me, but needs different testing methods. If you want to test upscaling refinement, I'd suggest to double resolution exactly, by setting MPC-HC to "Double Size", and then pick any sharp 480 or 720 source, double resolution and try to find FineSharp settings which more or less restore the original sharpness. That would then be the ideal setting for "high" for upscaling refinement. You may want to play with both "strength" and "thinning", because both are mostly independent of each other and have different effects.
madshi is offline   Reply With Quote
Old 16th June 2015, 15:34   #31142  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
1.7 BT.709 curve looks nice to me:

aufkrawall is offline   Reply With Quote
Old 16th June 2015, 15:46   #31143  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Hmmmm... I've done some checks with Anime content now, and I have to say, although I was able to find some examples where "LL on" looked better, it was much easier to find examples where "LL on" screwed things up quite noticably. The BT.709 test build seems to sit in the middle, but from a quick check with Anime content, my vote right now would still go to "LL off", because there are more situations where "LL off" looks better compared to even the BT.709 middle ground test build.

Can anybody else besides iSunrise, aufkrawall and me go back to v0.88.11 and compare FineSharp with LL on/off with Anime content (and maybe double check with the test build)? There were several votes in favor of "LL on", so I don't want to revert that decision without some more "support". Thanks.
madshi is offline   Reply With Quote
Old 16th June 2015, 15:51   #31144  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Thanks for openly listening to feedback.
aufkrawall is offline   Reply With Quote
Old 16th June 2015, 15:53   #31145  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
What good would it be to ask for feedback - and then ignore it when it comes? Just trying to achieve the best possible image quality. But I always like to look at the good and bad sides of all options first, before making a decision.
madshi is offline   Reply With Quote
Old 16th June 2015, 15:54   #31146  |  Link
Della
Registered User
 
Join Date: Dec 2011
Posts: 32
Quote:
Originally Posted by aufkrawall View Post
Thanks for openly listening to feedback.
And *always* responding politely.
A class act.
Della is offline   Reply With Quote
Old 16th June 2015, 16:07   #31147  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Unlike camera captured material, anime is digitally or hand drawn with ideal and maximum sharpness.
Anime is not blurred (low pass filter or MTF) by the lens or electronics to prevent aliasing or moire that is captured by camera.
Anime or cartoons ARE high contrast material with sharp lines filled with color.

IMO, sharpness algorithms are there so that we can compensate for "less than ideal" camera traits.
This is why super-sampling then dowscaling looks sharper, or capturing with 5K camera and downscaling to HD look WAY better than capturing with HD camera to HD (the Hobbit for example).
Sharpness algorithms are there to emulate that.

That is why I think anime or cartoons are no indicator or the right way to tweak a sharpness algorithm which WILL be applied on camera captured movies also.
In other words, Anime, Fonts and Test Patterns are NOT good test images for sharpness algorithms.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 16th June 2015 at 16:12.
James Freeman is offline   Reply With Quote
Old 16th June 2015, 16:13   #31148  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
Quote:
Originally Posted by madshi View Post
Hmmmm... I've done some checks with Anime content now, and I have to say, although I was able to find some examples where "LL on" looked better, it was much easier to find examples where "LL on" screwed things up quite noticably. The BT.709 test build seems to sit in the middle, but from a quick check with Anime content, my vote right now would still go to "LL off", because there are more situations where "LL off" looks better compared to even the BT.709 middle ground test build.

Can anybody else besides iSunrise, aufkrawall and me go back to v0.88.11 and compare FineSharp with LL on/off with Anime content (and maybe double check with the test build)? There were several votes in favor of "LL on", so I don't want to revert that decision without some more "support". Thanks.
Thanks a lot for listening.

If anyone is against it, please provide some samples. I simply objected to make madVR better for all of us and I hope that people agree that is what we all want.

Last edited by iSunrise; 16th June 2015 at 16:19.
iSunrise is offline   Reply With Quote
Old 16th June 2015, 16:24   #31149  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Dam, it's so cool how 1080p game captures look with high bitrate @WQHD, thanks to FineSharp, super-xbr and SuperRes. I'd almost think it is rendered in realtime in native resolution.
And 60fps aren't any problem performance wise.
aufkrawall is offline   Reply With Quote
Old 16th June 2015, 17:05   #31150  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 753
Quote:
Originally Posted by madshi View Post
Hmmmm... I've done some checks with Anime content now, and I have to say, although I was able to find some examples where "LL on" looked better, it was much easier to find examples where "LL on" screwed things up quite noticably. The BT.709 test build seems to sit in the middle, but from a quick check with Anime content, my vote right now would still go to "LL off", because there are more situations where "LL off" looks better compared to even the BT.709 middle ground test build.

Can anybody else besides iSunrise, aufkrawall and me go back to v0.88.11 and compare FineSharp with LL on/off with Anime content (and maybe double check with the test build)? There were several votes in favor of "LL on", so I don't want to revert that decision without some more "support". Thanks.
I've been following the discussion a bit and the problem might be that you're trying to do everything in linear light. For a simple unsharp mask filter you tend to get better results if you blur the image in linear light but subtract the unsharp mask in gamma light (or maybe even L*a*b). Unfortunately I couldn't immediately figure out how to apply this to finesharp, but at first glance the RemoveGrain11, FineSharpB parts should be done in linear light, for RemoveGrain4 it doesn't matter, so the LL artefacts are probably caused by either FineSharpA or FineSharpC.
Shiandow is offline   Reply With Quote
Old 16th June 2015, 17:24   #31151  |  Link
yukinok25
Registered User
 
Join Date: May 2015
Posts: 17
Quote:
Originally Posted by madshi View Post
Have you tried the tips in this post?

http://forum.doom9.org/showthread.ph...ms#post1724688
Nope! I didn't see that post!Thanks!

I'll try and report back!

Just one question, I deactivated the "how many video frames shall be presented in advance" feature, as I noticed my video was a bit stuttering.

I also disabled the Vsync on the nvidia control panel, and everything worked well after that.

Is the setting "video frames presented in advance" really useful/important, or can I leave it off instead?
yukinok25 is offline   Reply With Quote
Old 16th June 2015, 17:49   #31152  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Shiandow, do you also take a look at SuperRes' AA/AR with your current SR revision?

Taken my low-res cartoon example, both features can produce some weird artifacts like doubled lines where only one should be.
This happens e.g. with super-xbr luma doubling + SR AR or NNEDI luma doubling + SR AA.
This is why I have them disabled.
Not severe since SR still gives a very decent result when the other parameters are adjusted accordingly, but it'd be nice to have a good anti-ringing filter for super-xbr.
aufkrawall is offline   Reply With Quote
Old 16th June 2015, 18:03   #31153  |  Link
Telion
Registered User
 
Join Date: Sep 2011
Posts: 78
Quote:
Originally Posted by James Freeman View Post
Sharpness algorithms are there to emulate that.
That is why I think anime or cartoons are no indicator or the right way to tweak a sharpness algorithm which WILL be applied on camera captured movies also.
In other words, Anime, Fonts and Test Patterns are NOT good test images for sharpness algorithms.
You are right in your grounds, but your conclusion is not.
Sharpness algorithms are also to compensate for blurring brought by upscaling. This is a really distinct issue with animated content which usually has lots of prominent solid contours encompassing saturated colour gradients. Animation and live action are indeed two very different types of content. So the correct way to tune up sharpness algorithms would be not to sacrifice one of them for the sake of another, but to produce two different sets of corresponding parameters which can be easily switched by toggling some global option with a hotkey.
Telion is offline   Reply With Quote
Old 16th June 2015, 18:03   #31154  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Della View Post
And *always* responding politely.
A class act.
Thanks...

Quote:
Originally Posted by James Freeman View Post
Unlike camera captured material, anime is digitally or hand drawn with ideal and maximum sharpness.
Anime is not blurred (low pass filter or MTF) by the lens or electronics to prevent aliasing or moire that is captured by camera.
Anime or cartoons ARE high contrast material with sharp lines filled with color.

IMO, sharpness algorithms are there so that we can compensate for "less than ideal" camera traits.
This is why super-sampling then dowscaling looks sharper, or capturing with 5K camera and downscaling to HD look WAY better than capturing with HD camera to HD (the Hobbit for example).
Sharpness algorithms are there to emulate that.

That is why I think anime or cartoons are no indicator or the right way to tweak a sharpness algorithm which WILL be applied on camera captured movies also.
In other words, Anime, Fonts and Test Patterns are NOT good test images for sharpness algorithms.
It's true that Anime, fonts and test patterns are quite different to content shot with a camera, but Anime is well loved by many users (including me), so we can't ignore it. Also, Anime sometimes shows artifacts that also occur in normal video content, just Anime shows them stronger. So if we can make Anime content look good, that can help with normal video content, too. Just look at super-xbr: It was original written for enlarging cartoonish computer games. But now it's mutated into a very nice upscaling algorithm for normal video content. But yes, there will be situations where optimizing for Anime may result in different settings than you'd otherwise use. In such cases we need a good compromise.

Quote:
Originally Posted by aufkrawall View Post
Dam, it's so cool how 1080p game captures look with high bitrate @WQHD, thanks to FineSharp, super-xbr and SuperRes. I'd almost think it is rendered in realtime in native resolution.
And 60fps aren't any problem performance wise.


Quote:
Originally Posted by Shiandow View Post
I've been following the discussion a bit and the problem might be that you're trying to do everything in linear light. For a simple unsharp mask filter you tend to get better results if you blur the image in linear light but subtract the unsharp mask in gamma light (or maybe even L*a*b). Unfortunately I couldn't immediately figure out how to apply this to finesharp, but at first glance the RemoveGrain11, FineSharpB parts should be done in linear light, for RemoveGrain4 it doesn't matter, so the LL artefacts are probably caused by either FineSharpA or FineSharpC.
Yeah, you're probably right. Maybe I'll investigate that at some point. But right now I don't have the time, unfortunately.

Quote:
Originally Posted by yukinok25 View Post
Just one question, I deactivated the "how many video frames shall be presented in advance" feature, as I noticed my video was a bit stuttering.

I also disabled the Vsync on the nvidia control panel, and everything worked well after that.

Is the setting "video frames presented in advance" really useful/important, or can I leave it off instead?
For windowed or for fullscreen exclusive mode (FSE)? I generally have that setting on, but if playback works better for you with it turned off that's ok, too.

You should set most/all settings in the NVidia control panel to "application control", so madVR can tell the GPU/driver what it wants.

Quote:
Originally Posted by aufkrawall View Post
Shiandow, do you also take a look at SuperRes' AA/AR with your current SR revision?

Taken my low-res cartoon example, both features can produce some weird artifacts like doubled lines where only one should be.
This happens e.g. with super-xbr luma doubling + SR AR or NNEDI luma doubling + SR AA.
This is why I have them disabled.
Not severe since SR still gives a very decent result when the other parameters are adjusted accordingly, but it'd be nice to have a good anti-ringing filter for super-xbr.
I don't think trying to fix the ringing after super-xbr is going to work too well. madVR's AR algorithm already tries to make sure that super-xbr doesn't add ringing which wasn't there in the first place. If the original source already has ringing in it, also SuperRes will try its best to keep the ringing in the upscaled image, and to *not* remove it. What we could really use is a good de-ringing algorithm which would run before upscaling and remove ringing from the source. Then super-xbr would work better, and SuperRes, too!
madshi is offline   Reply With Quote
Old 16th June 2015, 18:20   #31155  |  Link
tFWo
Registered User
 
Join Date: Apr 2011
Posts: 24
Some Finesharp settings i found i like on good old live action movies. (for a change :P )


- suggested strength for image enhancement (depends on grain and source quality, 1080p, no upscaling) - 0.4-0.6 low, 0.8-1.0 medium, 1.4-1.6 high (>2.0 ultra)
* thinning - 0.010 - 0.020 seems ok

- strength for upscaling refinement (720p, s-xbr doubling) - 0.6-0.8
* thinning - 0.000 - 0.005 - any noise or blocking is boosted by a large amount even with the lowest settings

- strength for upscaling refinement (SD, s-xbr quading) - <=0.4
* thinning - 0.000 - same as above and even more pronounced



s-xbr observations on same content

- used NNEDI32/64 for image doubling before trying s-xbr, can't find any reason to go back to NNEDI -_- . s-xbr is faster, sharper and i really can't find major drawbacks for image doubling use.

- tried it for chroma uspcaling on SD content and compared to NNEDI64 s-xbr is worse/different??? It's sharper, but there is some strange detail loss in some places.
tFWo is offline   Reply With Quote
Old 16th June 2015, 18:35   #31156  |  Link
mogli
Registered User
 
Join Date: May 2015
Posts: 106
With D3D11 I do have lower rendering and presentation times. Is this a real performance gain or some pseudo effect like things happening behind madVRs back?

Edit: Clock state stays the same as with D3D9.

Last edited by mogli; 17th June 2015 at 06:38. Reason: addendum
mogli is offline   Reply With Quote
Old 16th June 2015, 18:50   #31157  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
You should check if your GPU is running with the same clock as before.
If clock is higher due to higher load, reported rendering times can in fact be lower.
aufkrawall is offline   Reply With Quote
Old 16th June 2015, 19:09   #31158  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Sharpness algorithms are there to emulate that.
That is why I think anime or cartoons are no indicator or the right way to tweak a sharpness algorithm which WILL be applied on camera captured movies also.
In other words, Anime, Fonts and Test Patterns are NOT good test images for sharpness algorithms.
Quote:
Originally Posted by Telion View Post
You are right in your grounds, but your conclusion is not.
Quote:
Originally Posted by madshi View Post
It's true that Anime, fonts and test patterns are quite different to content shot with a camera, but Anime is well loved by many users (including me), so we can't ignore it.
OK, Agreed.
I can live with a slightly brighter image, but for anime the ringing and haloing is definitely ugly.

After some more testing I can see that above around 1.5, LL shows its bad side around sharp objects.
No good for anything but the most blurry images.
So once again, I definitely can live without LL with a slightly brighter look with higher sharpening strength.

OK, I'll be testing 88.11 Finesharp with the following:
Image Enhancements
LL Off
Repair 1.0
Thinning 0.020
Strength variable

I'll try to match a 480 and 720 downscaled images sharpness to the original 1080 one when they are the same size.
Not HD but surely closer with Sharpening than without.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 16th June 2015 at 19:32.
James Freeman is offline   Reply With Quote
Old 16th June 2015, 19:39   #31159  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 753
Quote:
Originally Posted by aufkrawall View Post
Shiandow, do you also take a look at SuperRes' AA/AR with your current SR revision?

Taken my low-res cartoon example, both features can produce some weird artifacts like doubled lines where only one should be.
This happens e.g. with super-xbr luma doubling + SR AR or NNEDI luma doubling + SR AA.
This is why I have them disabled.
Not severe since SR still gives a very decent result when the other parameters are adjusted accordingly, but it'd be nice to have a good anti-ringing filter for super-xbr.
I have taken a look at those, unfortunately SuperRes and super-xbr have more or less the same problems with images containing ringing. To scale those images "accurately" you'd also need to scale the ringing, but that leads to bad results. I'm beginning to suspect that it might be better to use a separate de-ringing algorithm before scaling the image. Of course you'd then need a good de-ringing algorithm but that might be easier to achieve than trying to make SuperRes not scale something accurately.

At least I've managed to prevent SuperRes from introducing any aliasing, so when combined with super-xbr or NEDI you shouldn't need anti-aliasing, which didn't work too well anyway.

Oh by the way I think I might know why SuperChromaRes didn't preserve dark lines well. You can lose luma information when clipping out of gamut RGB values, normally this doesn't cause much of a problem but each SuperChromaRes pass will do this again, so the luma will drift even more. If that is the problem then it can be easily fixed, and the new SuperRes revision should also help.
Shiandow is offline   Reply With Quote
Old 16th June 2015, 21:32   #31160  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Thanks a lot!
aufkrawall 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 10:35.


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