madVR - high quality video renderer (GPU assisted)

[huhn]

what's your GPU?

[ikarad]

what's your gpu?

gtx780

[JackCY]

NEDI is also nice enough to take care of chroma while it's at it so we got winning combos here IMHO. I haven't truly experimented with SR on chroma yet, though but last time I tried I didn't seem to like it.
Personally I don't see any changes when using more expensive chroma upscaling, nonetheless I set it to the same I use for image upscaling since it doesn't eat much power.

LOL! That is exactly the same content I used to test Shiandow's debanding and all other madVR features as far as Low / Medium Quality content goes.

I disagree though. I sit about 8 feet away from my 40" 1080p HDTV and with my settings + 12bit color depth on my HDTV, the result is much better with madVR de-banding because it leaves enough detail to see the outline of black/dark parts of the image. For example, Captain/Major/Kernel Samantha Carter often wears black tops. With madVR's debanding set to Medium on top and High on bottom, I can see the outline of her boobies when she wears a black top, but with Shiandow's, her chest looks flat and un-sexish.

Sure that detail is quite LQ, but as long as you use the highest quality settings and sit reasonably far enough away, madVR's debanding does an excellent job.


Regarding new features. SuperRes is definitely here to stay! I figured that LumaSharpen for Upscaling does very little, but for Image Enhancement it does quite a lot at its default setting. The same exact content I talked about above (SMPTE 170M) looks a bit too sharp with default Image Enhancement LumaSharpen values. I decrease strength to 0.50 and clam to 0.30 and its much better!


You know, sometimes I wonder if madVR does too much when it tries to improve image quality. The original film image, when played with WMP without madVR rendering, using only LAV decoders looks sharper than madVR's image without LumaSharpen. However, vanilla image also has banding, artifacts, pixelation, etc. madVR HQ rendering settings fix all those vanilla issues and leave the image soft. Then LumaSharpen offsets the softness, but the end image looks both - 1. better IMO and 2. different from the original. The original/vanilla image sharpness looks more natural than madVR + LumaSharpen. I have not been able to restore that vanilla sharpness with any madVR settings.

I need to figure out how to create side by side comparisons shots using different madVR settings. Otherwise its hard to backup what I am saying...

I'm pretty close (arm length) to a monitor, not TV, so I see all the harsh and rough there is because there simply isn't better quality available to play. cca 2.5x upscale is a lot and it makes all the "small" details on 480p look huge upscaled to 1080p especially after SuperRes (SR). Some of the image is even bad because the master was low quality as well, practically all effects scenes are low quality, it's how it was made, shot on film (S01-07) and effects added in LQ since the target was TV and DVD, not HD or FHD at the time.

Damn what TV has 12bit? That's pretty ridiculous considering above 6-8bit one can't really tell the difference without pixel peeping anyway.
Yeah Madhi's leaves more detail but in the case of this 480p content even High removes nearly nothing, literally, as the banding and rough parts have too high step/contrast to get caught for removal by Madhi's alg. Where as Shiandow doesn't use such strict selection and applies easily to everything. Sure it washes out some detail away, inevitable price for reducing the rough detail the small detail gets taken too, hence I add grain to so the rough parts that remain don't look as prominent compared to the rest that is "washed".

Tried the Lumasharpen values, lowered, SR first otherwise SR will mask the sharpen as it does mask lower Q upscale algorithms. Don't like Sharpen, SR is enough for me.

I'm not sure I even have WMP installed, but it's simple to switch to other renderers in MPC and see how the colors are interpreted differently, with madVR supposedly and IMHO interpreting them more correctly. And other renderers also use other tricks such as more vivid colors apart from them being shifted, maybe even some sharpen, who knows, depends on renderer selected. Sure hey it's watchable, most of us did use them before.

To me all madVR seems to do compared to EVR CP is properly represent colors and allows to use better scaling alg. Plus now the added features for debanding and sharpening. I don't get any softening of the image or something unless you count the better scaling as softening the image, or the added aggressive deband. Then sure that's normal for these alg. But by default there doesn't seem to be any added softening or some such, if I would select equal scaling alg. and disable extra features in madVR it would look the same as EVR CP except for the color. I have all performance options disabled in madVR.
I use LAV with DXVA2 native (dxva2n). Read for some old madVR that this wasn't supported but I don't see any difference when I switch to software (avcodec) and everything seems to work fine for any LAV decoder selected.

Post screenshots of the same frame in PNG or other lossless with lossless upload.
There is http://screenshotcomparison.com/ for mouse over but it's a little meh to use, I prefer to click, ctrl+tab etc. instead.

That's what I use:
http://i.imgur.com/mCoLzlqm.png (http://imgur.com/mCoLzlq.png)
EVR CP, makes colors vivid as always, whether it interprets the color space right I don't know but the vividness is bad enough already:
http://i.imgur.com/hUVF69Zm.png (http://imgur.com/hUVF69Z.png)
Highest Q madVR without deband and SR:
http://i.imgur.com/jU8m8Bfm.png (http://imgur.com/jU8m8Bf.png)
Highest Q madVR with only madshi deband, has almost no effect except a couple parts in background top right:
http://i.imgur.com/Kab2IJ1m.png (http://imgur.com/Kab2IJ1.png)

madVR to me looks sharper and less artifacted due to better scaling alg. even NNEDI3-16 is enough to get better/less antialiased edges at 2x or more upscale.
At equal alg. the sharpness would be equal. But with madVR one doesn't have to hunt for shaders and can simply add deband and SuperRes now.

No shaders used in any of the pics, I don't use shaders.

[madshi]

If you're looking for feedback for LumaSharpen madshi, I remember seeing this post a few weeks ago and it seems to have been lost amongst the influx of new stuff happening at the time.

The first two points are certainly important things for you to look into. In the original SweetFX thread (http://forum.doom9.org/showthread.php?t=170357&highlight=sweetfx) opinion was unanimous that Pattern 3 was better for video than Pattern 2.
I'm already using the latest code and Pattern 3. Never used anything else.

There is an issue with 0.88.10 and 0.88.11: the playback freezes sometimes. It happens to me a couple of times on two different BDRemuxes. The issue is unstable; I've tried to reproduce it later (same video, same time, same player, etc.) but had no luck. Maybe the issue was introduced in one of the earlier 0.88.x builds - I can't use them on the regular basis because of http://bugs.madshi.net/view.php?id=284. But I've never experienced it on 0.87.14. WinXP, GF 8800 GT, driver v340.52.
XP, euwh.

Ok, if these freezes occur, does the media player still react to you? e.g. does the menu open? Do the buttons react? Or is it totally frozen? If it's totally frozen, try to create a freeze report by pressing Ctrl+Alt+Shift+Break/Pause. Maybe that could help me figuring out what's going on.

Tested new image ehancement option using this image https://cloud.mail.ru/public/AbGY/UwuASurxH

Can not see horisontal lines when FS OFF and the same with SuperRes filter OFF for chroma upsampling.
Not sure I understand your conclusion. Which horizontal lines do you mean and do you want to see them or not? And you're talking about FS and SuperRes, but I'm not sure if you like either or not.

Now that we moved on to Image Refinement, may I ask - what exactly is the different between LumaSharpen, FineSharp, and SuperRes? I assume they deal with increasing sharpness, which is a bit odd because AFAIK madVR was all about making the image as soft as possible.
madVR was never about making the image "soft". It was always about rendering the image as accurately as possible. If you display movies at 1:1 pixel mapping, nothing has changed and all the "upscaling refinement" options don't have any effect. I've explained all the reasoning for these algorithms in the "feedback" post (the one right after the v88.11 release post). Read that again, please. A lot is explained in there.

LumaSharpen und FineSharp are straight image sharpening algorithms. SuperRes also sharpens, but that's only one part of it, more details see Shiandow's post.

If quadrupling resolution, would it be better to run SuperRes twice with 1 pass or once with 2 passes?
Again, please read the "feedback" post (the one right after the v88.11 release post). I've explained a lot there, and I don't feel like explaining it all again.

I tested default settings LumaSharpen (Image Enhancement) and default settings FineSharp (Image Enhancement) with both HQ and MQ content, but I did not like either at all. Both features made dithering, noise, blockiness, banding, or artifacts more obvious/visible/emphasized in MQ, LQ, and even moderately HQ content. Its like these settings canceled all the madVR's image improvement through softness. LumaSharpen and FineSharp were only helpful in absolute best HQ content (full BD's, not rips). I have not tested LumaSharpen and FineSharp Upscaling Refinement.
The "image enhancement" options are only meant to be used for sources that are very soft to begin with. If your sources are reasonably sharp, or if they have lots of compression artifacts, then sharpening them might not be such a good idea.

Again, I love SuperRes but it is expensive to run, and somehow it is much more expensive than it should on 480p videos.
I'm not terribly worried about performance issues at this point, I'm mainly interested in image quality discussions. Maybe performance can be improved.

With 88.11 mpc-hc the queues emptying and will NOT filling back up after I seek, thus the videos stuttering after seeking.
I need to pause or exit full screen (not FSE) to "refresh" the queues.

EDIT:
Sometimes it happen all by itself without seeking.

EDIT2:
*On secondary screen only!
Not enough information. Is this a new problem with v0.88.11? Or did you always have this problem? Is it specific to DX11 presentation? Or does it also occr with DX9? Which queues are not filling exactly?

i never saw a picture where anti ring even at 1.0 would harm the picture. i totally love it!

upscaler is currently jinc 3 LL AR.
It's interesting that you use linear light. Since you have the SuperRes AR set to such a high value, do you still need to use Jinc AR at all? Or could you go with straight Jinc instead and let SuperRes take care of the ringing? Just wondering, haven't tried that myself yet...

That's weird. I found SuperRes to make quality considerably worse with super lo-res material (240-360p) . The more passes I have it do the worse the effect. Most of my super lo-res material is DVR/TIVO/VHS/Capture card rips from late 90's to mid 2000's. Needless to say they aren't pristine, tbh though, I don't think you will get pristine image quality at those resolution anyways. If there is any type of blocking or aliasing it makes matters worse. When I try to compensate with increasing softness or anti-alaising it creates very weird artifacts. I lack the knowledge to properly describe it but, it looks like I put plastic wrap over my screen. Strange distortions on edges and such. This is leaving the settings at default. It gets much worse when increasing softness or anti-alaising to compensate.
Could you maybe upload a sample where these weird effects/distortions are especially strong?

As XRyche noted SuperRes introduces some strange distortions to the image edges (in my case the text overlay) as I cranked up the passes. It appeared to add a somewhat opaque overlay while adding extra edges outside the original text edges (not ringing - just sorta smudged out with faint new edges).
A sample would be great!

Seem like only works when scale factor >2 when rule is "if (scalingFactor.x > 1 )"

480p to windowed 15,0,2404,1264 or full screen 1,0,2561,1440- works
720p to windowed "" - not works
720p to full screen 1,0,2561,1440 - works
1080p or 800p scale to any size(meaning less than 1440p) - not works

confirmed by toggling options on the fly and pull up setting menu in windowed mode.

edit: hmm.. rule change to "if (scalingFactor.x > 0.9 )" and everything seem to work correct~
edit2: hmm nvm, "if (scalingFactor.x > 0.9 )" isnt it~
Could you please report this to the bug tracker? Not sure when I'll find the time to fix it.

http://madVR.bugs.madshi.net

I need to figure out how to create side by side comparisons shots using different madVR settings. Otherwise its hard to backup what I am saying...
Please don't use "side-by-side", please use separate screenshots for each configuration - but it has to be exactly the same video frame.

Why does superres have multiple passes anyway? I don't understand the benefit
One part of the SuperRes algorithm compares the "final" result with the original image before upscaling, and then tries to substract any "errors" from the final image, compared to the original image. Something like this sometimes works better in multiple passes.

I only just had the opportunity to start doing some testing today (only had the time spare to even watch one film this whole month) and my initial thoughts are similar to yours.

Madshi's debanding seems very good at low levels, but Shiandow's seems to look more natural at high levels of debanding - especially with the "add grain" option enabled. At higher strengths, Madshi's debanding can start to look artificial.
Though Shiandow's debanding may lose more detail (I need to spend more time tweaking to see whether that is actually the case) it looks natural when that happens - with filmed footage at least. I haven't tested any animated content - where Madshi's deband may still fare better.
Unfortunately I've already made my decision. The last round of feedback was in favor of madVR's original debanding algorithm. huhn also found and documented an artifact of Shiandow's algorithm in motion, which madVR's algo didn't have.

Before I can post a v0.88.11 is released and Shiandow deband is removed? :(
Don't know why such a useful post-processing is suddenly removed soon after it was added.
I'm keeping v0.88.10 for sure.
Well, the Shiandow deband algorithm was in madVR for nearly a full month, and feedback had been coming in all the time in that month. At some point I had to finish the feedback "phase" and make a decision about what to do.

I have always been saying right from the start that the Shiandow deband algorithm will not stay as a separate algorithm. The only question was whether it would replace the original deband algorithm partially or fully or not at all. After all the feedback I decided to keep the original algorithm, so the Shiandow algo had to go. Too many options are not good for the majority of users.

It's useful, it's stronger than high settings of the artifact removal and Shiandow works sort of as clear skin, removing as much or as little as you want of the harshness from images.
But that's not what a deband filter should do. A deband filter should remove banding and nothing else. If you want a filter that removes harshness from images then that should be a separate filter, with a suitable name which describes what it does. And then it should be tested for that purpose exactly by all users and tuned to produce good results. None of that has happened here.

As you can see above, Madshi's does pretty much nothing on rough LQ content even at High, but Shiandow serves nicely to "wash" the image, which true removes a bit of contrast but the rough detail is reduced as much as you like. As long as margin is minimal it's not that crazy with altering features of faces and objects.
Ouch. From what I can see in your images, with the settings you're using, the Shiandow deband quite drastically alters the look of the image. In my eyes you not only lose some contrast, but also quite a bit of detail. Maybe you find the look of the image more pleasing this way. But this is definitely *not* what a deband filter should do, or what Shiandow has intended the algorithm for.

[madshi]

Debug log: https://www.dropbox.com/s/hi8yiom7xcwayc3/madVR%20-%20log.txt?dl=0

Same results as before - unfilled queues with high prepresented frames.
Yeah, looks exactly as expected. Will have to do some more test builds. Stay tuned...

[madshi]

Thanks everyone for your FEEDBACK so far, appreciated!

Some conclusions I could draw from your combined feedback:

1) The SuperRes "high error upscaling quality" can be deleted.
2) Some users like FineSharp a lot, others not at all. <sigh>
3) Most users found LumaSharpen to be moderately useful, although not perfect.
4) With some sources sharpening before upscaling doesn't work well.
5) SuperRes seems to be well liked, but performance hungry.

My impression is that - although we've made some progress - we won't get to where we want to get, with everyone testing everything. I fear my last feedback request was too broad and not specific enough. Would you guys agree? I'm wondering whether we should switch two gears back and simply start by looking at one algorithm at a time, to reduce each algorithm's complexity first, before looking at how they interact. E.g. we could start with FineSharp, looking at all the available options, and reducing them to a low/med/high. Then move on to LumaSharpen etc. Doing this would also make testing of the combined effects of all algos easier. Or what do you guys think?

[JackCY]

I have always been saying right from the start that the Shiandow deband algorithm will not stay as a separate algorithm. The only question was whether it would replace the original deband algorithm partially or fully or not at all. After all the feedback I decided to keep the original algorithm, so the Shiandow algo had to go. Too many options are not good for the majority of users.
I get that, is it or can it be available as a shader for MPC/MPCHC?

Or does anyone know if a similar shader that would "soften" rough textures/gradients but preserve edges?

But that's not what a deband filter should do. A deband filter should remove banding and nothing else. If you want a filter that removes harshness from images then that should be a separate filter, with a suitable name which describes what it does. And then it should be tested for that purpose exactly by all users and tuned to produce good results. None of that has happened here.

Ouch. From what I can see in your images, with the settings you're using, the Shiandow deband quite drastically alters the look of the image. In my eyes you not only lose some contrast, but also quite a bit of detail. Maybe you find the look of the image more pleasing this way. But this is definitely *not* what a deband filter should do, or what Shiandow has intended the algorithm for.
I know. My use of it is not what it was made for originally. Only showing that it can be useful nonetheless for something else.

---
SuperRes is great even if it eats a decent amount of power, with how it works the loss off power is easily compensated by a use of simpler upscaling which doesn't affect the image much when SR is enabled.
I like more options and algorithms present rather than only one with a low/med/high preset. Presets are fine, but IMHO shouldn't replace the options, it would be nice if the presets could be set to other values, as in offer not only load but also save, one could change the presets to his own values.
And I can't stress enough, please editable boxes instead of only two buttons that move by 0.01 or other small step that is not perceptible and takes forever to move the value from 0.00 to 1.00. I've tried ctrl+click, shift+click but nothing seems to increase the step.

[nevcairiel]

My impression is that - although we've made some progress - we won't get to where we want to get, with everyone testing everything. I fear my last feedback request was too broad and not specific enough. Would you guys agree? I'm wondering whether we should switch two gears back and simply start by looking at one algorithm at a time, to reduce each algorithm's complexity first, before looking at how they interact. E.g. we could start with FineSharp, looking at all the available options, and reducing them to a low/med/high. Then move on to LumaSharpen etc. Doing this would also make testing of the combined effects of all algos easier. Or what do you guys think?

If you want people to test one thing, you need to give them one thing, and one thing only. By adding all the features at once to madVR, you will spark their interest. They are not going to stop testing all the toys and just focus on one at a time.

That ship has sailed now, I guess, but if you plan 5 new features in the future, maybe add them one at a time and wait for feedback in between. ;)
Best you can do now is like you said, try to test one thing at a time anyway!

[huhn]

i find it hard to find something that is good in general.

for example you can easily move superres sharping to one of the sharpening filter when the sharpening from superres is not what you want.

It's interesting that you use linear light. Since you have the SuperRes AR set to such a high value, do you still need to use Jinc AR at all? Or could you go with straight Jinc instead and let SuperRes take care of the ringing? Just wondering, haven't tried that myself yet...
i have AR on 1.0 in general i haven't found any issue with it at this setting what so ever. and even jinc3 LL AR looked totally fine.

[SecurityBunny]

Yeah, looks exactly as expected. Will have to do some more test builds. Stay tuned...

Sure thing. On stand-by. :)

[omarank]

My impression is that - although we've made some progress - we won't get to where we want to get, with everyone testing everything. I fear my last feedback request was too broad and not specific enough. Would you guys agree? I'm wondering whether we should switch two gears back and simply start by looking at one algorithm at a time, to reduce each algorithm's complexity first, before looking at how they interact. E.g. we could start with FineSharp, looking at all the available options, and reducing them to a low/med/high. Then move on to LumaSharpen etc. Doing this would also make testing of the combined effects of all algos easier. Or what do you guys think?
I agree. You asked the users to specifically focus on debanding first, and finally after all the feedbacks, the three presets could be finalized as you intended. I think the same approach should be followed for each algo.

I haven’t had the time to test the sharpening and refinement algos. I will be doing some extensive testing by this weekend and post my feedback soon. However, if we focus on just one algo at a time, it will need less time to do the testing and I wouldn’t have to wait for the weekend to come.

[aufkrawall]

nevcairiel is kinda right. I already did SuperRes and Finesharp tests for myself weeks ago.
Now my interest got somewhat low.
But I'll post some cartoon comparisons this week.

What I remember:
high error upscaling quality can look better, but hard to say if it's worth the extra resources.
SuperRes for chroma gives undesired results, vanishes contours.
SuperRes for luma is great, image can look much sharper with almost no artifacts introduced (with the correct settings).
NNEDI is still worse than NNEDI3, also with SuperRes (introduces visible aliasing).
I find FineSharp more natural than Lumasharpen. Problem with sharp sources could be solved to some degree if we had a deblock pass first.

[madshi]

I get that, is it or can it be available as a shader for MPC/MPCHC?
Technically not possible right now, because custom shaders are not flexible/powerful enough to run Shiandow's deband. At some point in the future, that should be possible, though.

And I can't stress enough, please editable boxes instead of only two buttons that move by 0.01 or other small step that is not perceptible and takes forever to move the value from 0.00 to 1.00. I've tried ctrl+click, shift+click but nothing seems to increase the step.
Of course my plan is to get rid of the edit boxes altogether and just offer low/medium/high. I could allow the edit boxes to be edited, but it's not that simple, then I also must parse the text and complain if the format isn't correct etc. So some extra work involved there...

If you want people to test one thing, you need to give them one thing, and one thing only. By adding all the features at once to madVR, you will spark their interest. They are not going to stop testing all the toys and just focus on one at a time.
You're right. Introducing one new feature at a time would have been better for feedback. But it is what it is now. For debanding the concentrated feedback effort did work, more or less. So I'll try my luck with the other algos, too, separately...

for example you can easily move superres sharping to one of the sharpening filter when the sharpening from superres is not what you want.

i have AR on 1.0 in general i haven't found any issue with it at this setting what so ever. and even jinc3 LL AR looked totally fine.
I'm wondering: Do you still need madVR's anti-ringing filter if you use SuperRes with AR processing?

Sure thing. On stand-by. :)
Ok, here's a test build somewhere between v0.88.8 and v0.88.9. You said the problem started with v0.88.9, right? Please let me know if this test build fills the queues like v0.88.8 did, or not.

http://madshi.net/madVR889test1.rar

I agree. You asked the users to specifically focus on debanding first, and finally after all the feedbacks, the three presets could be finalized as you intended. I think the same approach should be followed for each algo.

I haven’t had the time to test the sharpening and refinement algos. I will be doing some extensive testing by this weekend and post my feedback soon. However, if we focus on just one algo at a time, it will need less time to do the testing and I wouldn’t have to wait for the weekend to come.
Ok, thanks.

nevcairiel is kinda right. I already did SuperRes and Finesharp tests for myself weeks ago.
Now my interest got somewhat low.
But I'll post some cartoon comparisons this week.

What I remember:
high error upscaling quality can look better, but hard to say if it's worth the extra resources.
SuperRes for chroma gives undesired results, vanishes contours.
SuperRes for luma is great, image can look much sharper with almost no artifacts introduced (with the correct settings).
NNEDI is still worse than NNEDI3, also with SuperRes (introduces visible aliasing).
I find FineSharp more natural than Lumasharpen. Problem with sharp sources could be solved to some degree if we had a deblock pass first.
Deblocking will probably come, but rather later than sooner.

[madshi]

Ok, here's a test build somewhere between v0.88.8 and v0.88.9. You said the problem started with v0.88.9, right? Please let me know if this test build fills the queues like v0.88.8 did, or not.

http://madshi.net/madVR889test1.rar
Sorry, this was a bad one. Use this instead:

http://madshi.net/madVR889test2.rar

And don't use error diffusion in this build.

[Shiandow]

I'm wondering: Do you still need madVR's anti-ringing filter if you use SuperRes with AR processing?

Well, SuperRes only removes the ringing afterwards, so enabling MadVR's anti ringing should have some effect. I suspect SuperRes will converge slightly faster if you use madVR's anti-ringing. The difference, if any, will be most visible when you use a low number of passes (which seems to be the popular choice).

[madshi]

Feedback

I've changed my mind. I think we'll make bigger steps faster, if we concentrate the feedback on very specific things. So while you're welcome to do further tests with SuperRes etc, if you like, please concentrate your efforts on FineSharp. I would like to remove all the FineSharp controls, and just end up with low/medium/high (for both "image enhancement" and "upscaling refinement"). When testing FineSharp, it would make sense to disable LumaSharpen and SuperRes, so that you really only test FineSharp separately. You can test FineSharp either in image enhancements (before upscaling) or in upscaling refinement (after upscaling). Testing it before upscaling should have a stronger effect, so it might be easier to see the difference between various settings there. But you decide whether you want to test it before or after upscaling.

Questions:

1) Do you prefer linear light on or off?
2) In my own very short tests I found that FineSharp sometimes introduces aliasing artifacts. These seem to be mostly fixed by setting the "repair" option to rather high values. Personally, I've tried setting "repair" to 1.0, and liked the result. But what is your opinion about this? Do you find "repair" at 1.0 works for you? Or would you prefer it at a lower value?
3) Do you see a difference worth noting between the 3 different modes? Please note that these modes will make more of a difference if the sources have stronger grain. So in order to judge which modes work best and which worst, it might make sense to also test with a source with a lot of grain in it. FWIW, mode 3 is slower, modes 1 and 2 are faster. So if you like mode 3 best, but not much better than 1 and 2, then it would still be useful to know whether you prefer 1 over 2 or the other way round.
4) Which combinations of strength and thinning would you suggest for low/medium/high presets?

Thanks! :)

[SecurityBunny]

Sorry, this was a bad one. Use this instead:

http://madshi.net/madVR889test2.rar

And don't use error diffusion in this build.

Could I get a 64 bit version to test or do you want me to downgrade to 32bit MPC-HC? Renaming the file to madVR64 didn't seem to force the file to load.

[TheLion]

Feedback Finesharp

I find Finesharp extremely useful for high quality sources (e.g. high bitrate BluRay). With lesser source material artifacts become too obvious, but put great stuff in, and it results in a nice boost of clarity, apparent sharpness without the "fat look" of traditional "Edge Enhancement". Very nice!

So I will only comment on using it with native 1080p BluRay playback (therefor no scaling, -> image enhancement).

1) I certainly prefer linear light ON. It introduces less ringing/halos/artifacts in many examples to my eye. There are test charts that make that more than obvious: eg. https://drive.google.com/file/d/0B9JsGIAbr0VARUR5cFRCOG9Fa00/view?usp=sharing

2) The default values + linear light are working great for me. Repair 1.0 does no harm either from what I can see.

3) I prefer mode 3 (slightly less artifacts), can't find an example where I can see a relevant difference between 1 and 2

4) Again, default values + linear light + mode 3 work great for me. everything over strength 2.0 get's problematic, I wouldn't go over ~2.5 even on very good sources.

[GCRaistlin]

XP, euwh.

Ok, if these freezes occur, does the media player still react to you?


Yes, it does, I'm able to close it.

[baii]

finesharp (only mode 1, strength from .4- 1.0, repair default)

I like it as image refinement(which had been known since it was a avisyth script), not so much for upscaling. finesharp on upscale material seem to bring artifact out(which can also say it do a good job sharpening?) . linear light on seem to make the artifact harder, prefer it off.

[ryrynz]

Could I get a 64 bit version to test or do you want me to downgrade to 32bit MPC-HC? Renaming the file to madVR64 didn't seem to force the file to load.
Just download the 32 bit version. Much faster that way. You could've done that and been posting a reply rather than asking and waiting for something that might not come.

[huhn]

I'm wondering: Do you still need madVR's anti-ringing filter if you use SuperRes with AR processing?

hard to judge in general. in the newest test i did it wasn't needed.
but jinc it self has little to no effect too.

[MysteryX]

hard to judge in general. in the newest test i did it wasn't needed.
but jinc it self has little to no effect too.
I was wondering the same question, and then tried to use only SuperRes for anti-ringing. It did NOT remove ringing resulting from upscaling.

[Anime Viewer]

Feedback
please concentrate your efforts on FineSharp. I would like to remove all the FineSharp controls, and just end up with low/medium/high (for both "image enhancement" and "upscaling refinement"). When testing FineSharp, it would make sense to disable LumaSharpen and SuperRes, so that you really only test FineSharp separately. You can test FineSharp either in image enhancements (before upscaling) or in upscaling refinement (after upscaling). Testing it before upscaling should have a stronger effect, so it might be easier to see the difference between various settings there. But you decide whether you want to test it before or after upscaling.

Questions:

1) Do you prefer linear light on or off?
2) In my own very short tests I found that FineSharp sometimes introduces aliasing artifacts. These seem to be mostly fixed by setting the "repair" option to rather high values. Personally, I've tried setting "repair" to 1.0, and liked the result. But what is your opinion about this? Do you find "repair" at 1.0 works for you? Or would you prefer it at a lower value?
3) Do you see a difference worth noting between the 3 different modes? Please note that these modes will make more of a difference if the sources have stronger grain. So in order to judge which modes work best and which worst, it might make sense to also test with a source with a lot of grain in it. FWIW, mode 3 is slower, modes 1 and 2 are faster. So if you like mode 3 best, but not much better than 1 and 2, then it would still be useful to know whether you prefer 1 over 2 or the other way round.
4) Which combinations of strength and thinning would you suggest for low/medium/high presets?

Thanks! :)

I realized one thing I forgot to mention in my previous post on my thoughts and testing of finesharp (http://forum.doom9.org/showpost.php?p=1725657&postcount=30819): On my Optimus system if I use any of the FineSharp modes in upscaling refinement combined with having image doubling enabled while using my Intel GPU the screen has spasams of what look like flashes of repeated frames (but it doesn't report any delayed frames). A ton of presentation glitches occur along with a handful of dropped frames. (Presentation glitches far out number the amount of dropped frames reported in that same time period). Using the Nvidia GPU no such problem occurs. This is another reason why I prefer using the FineSharp in image enhancement as opposed to the FineSharp in upscaling refinement. With the the FineSharp in image enhancement I can combine it with image doubling and playback using the Intel without any problems.

Now to your specific questions:
1) Like I said in my previous post in FineSharp testing I like FineSharp better with linear light enabled if I'm using the image enhancement version, but if I'm using the upscaling refinement version I prefer it off.
2) The repair setting has no noticable effect as far as I can tell on my system. I see no difference (no improvement) between having a setting of 0.10 and 1.0.
Is there another madVR setting that might be interfering with the the repair effect?
3) I'm not seeing a significant difference between the three modes. (I guess my test videos don't have enough grain).
4) I think I prefer lesser amounts of strength. What else is combined with with FineSharp to enhance/refine/upscale can be a factor to what to set FineSharp to. With more power choices in other areas FineSharp can be used with lesser power. I think 0.5 isn't a bad setting. Depending on other peoples thoughts that might make a good low. Thinning could be left at the current default unless there is a general consensus by other users that another setting works better.

I think its worth people reporting if they used any type of image doubling during their testing. For me image doubling has a very strong effect on FineSharp.

[MysteryX]

madshi, did you remove the feature that displays the volume level when scrolling up and down with the mouse?

[MysteryX]

I was wondering the same question, and then tried to use only SuperRes for anti-ringing. It did NOT remove ringing resulting from upscaling.
I withdraw this.

SuperRes's anti-ringing *can* replace the upscaler's anti-ringing, but .50 is not enough. It takes more something like .75.

Madshi, does that anti-ringing apply to both chroma and luma?

It doesn't do as good of an anti-ringing job than the standard anti-ringing, but removing standard anti-ringing allows to save on performance, increase other settings, or afford SuperRes.

I know you're looking into FineSharp for now, but when you get to SuperRes, perhaps you could have a few preset, and then the option of having 1 or 2 passes. If doing a single pass, all the values need to be higher to give a similar result. I can only afford a single pass.

[SecurityBunny]

Just download the 32 bit version. Much faster that way. You could've done that and been posting a reply rather than asking and waiting for something that might not come.

For all you could know, the issue may lie within the 64 bit operation since that is what I use and originally tested with. The last test build madshi provided to me had a 64 bit version, but I digress.

Sorry, this was a bad one. Use this instead:

http://madshi.net/madVR889test2.rar

And don't use error diffusion in this build.

Version shows 0.88.9 when checking with this build. Queues unfortunately still do not fill with D3D11 and 10-bit output. D3D9 with 10-bit output, queues fill.

And of course again, testing 0.88.8 with D3D11 10-bit, queues fill.

A 64 bit .ax file for testing, similar to the previous debugging builds you provided, would be preferred - to avoid having to use a 32bit player. Thanks. :)

[ryrynz]

For all you could know, the issue may lie within the 64 bit operation

The likelihood of that is extremely low. But then if you'd just downloaded the 32 bit version and tested then you'd know that too.

[kalston]

madshi, did you remove the feature that displays the volume level when scrolling up and down with the mouse?

Volume level display? That sounds like a media player thing.

[madshi]

Well, SuperRes only removes the ringing afterwards, so enabling MadVR's anti ringing should have some effect. I suspect SuperRes will converge slightly faster if you use madVR's anti-ringing. The difference, if any, will be most visible when you use a low number of passes (which seems to be the popular choice).
Ok, thanks.

Feedback Finesharp

I find Finesharp extremely useful for high quality sources (e.g. high bitrate BluRay). With lesser source material artifacts become too obvious, but put great stuff in, and it results in a nice boost of clarity, apparent sharpness without the "fat look" of traditional "Edge Enhancement". Very nice!

So I will only comment on using it with native 1080p BluRay playback (therefor no scaling, -> image enhancement).

1) I certainly prefer linear light ON. It introduces less ringing/halos/artifacts in many examples to my eye. There are test charts that make that more than obvious: eg. https://drive.google.com/file/d/0B9JsGIAbr0VARUR5cFRCOG9Fa00/view?usp=sharing

2) The default values + linear light are working great for me. Repair 1.0 does no harm either from what I can see.

3) I prefer mode 3 (slightly less artifacts), can't find an example where I can see a relevant difference between 1 and 2

4) Again, default values + linear light + mode 3 work great for me. everything over strength 2.0 get's problematic, I wouldn't go over ~2.5 even on very good sources.
Thanks. So for "image enhancements" you would suggest a strength of 2.0 for the "high" preset, using the default "thinning"? Have you played with the "thinning" a bit to find out whether you like it at its default value or slightly different maybe?

What would you suggest for medium and low presets?

And how much better do you like mode 3? I'm asking because it costs more performance. So the question is whether it's worth the added performance cost?

finesharp (only mode 1, strength from .4- 1.0, repair default)

I like it as image refinement(which had been known since it was a avisyth script), not so much for upscaling. finesharp on upscale material seem to bring artifact out(which can also say it do a good job sharpening?) . linear light on seem to make the artifact harder, prefer it off.
Do you dislike linear light only for upscaling refinement, or also for image enhancement? Do you have a specific sample where linear light makes FineSharp look worse? Thanks.

1) Like I said in my previous post in FineSharp testing I like FineSharp better with linear light enabled if I'm using the image enhancement version, but if I'm using the upscaling refinement version I prefer it off.
Can you explain why you like it better/worse in either of these sections? In which way does it look better in image enhancement? In in which way does it look worse in upscaling refinement? Have you tested FineSharp alone (without SuperRes etc) in upscaling refinement? Do you still dislike linear light there? Or maybe it's only when used together with SuperRes?

2) The repair setting has no noticable effect as far as I can tell on my system. I see no difference (no improvement) between having a setting of 0.10 and 1.0.
Is there another madVR setting that might be interfering with the the repair effect?
Not really. Try this image:

http://madshi.net/castleOrg.png

Double it with NNEDI3, then apply FineSharp as upscaling refinement. Then compare repair with 0.0 to 1.0. Look at the diagonal roof lines. They contain a bit of aliasing when using repair 0.0, which is mostly gone with 1.0. Using 0.25 is somewhere in between. It's a subtle difference in this image. I've seen far worse aliasing caused by FineSharp in other images. Sadly I can't find them on a quick look right now.

4) I think I prefer lesser amounts of strength. What else is combined with with FineSharp to enhance/refine/upscale can be a factor to what to set FineSharp to. With more power choices in other areas FineSharp can be used with lesser power. I think 0.5 isn't a bad setting. Depending on other peoples thoughts that might make a good low. Thinning could be left at the current default unless there is a general consensus by other users that another setting works better.
So you'd suggest 2.0 for "high" and 0.5 for "low"? Can you play with "thinning" a bit to see if you like those values to be changed in any way for high or low?

I think its worth people reporting if they used any type of image doubling during their testing. For me image doubling has a very strong effect on FineSharp.
You mean using FineSharp in image enhancements, and then afterwards doubling? What kind of effect does doubling have on FineSharp in your experience?

madshi, did you remove the feature that displays the volume level when scrolling up and down with the mouse?
I've got nothing to do with such controls. Never had.

I withdraw this.

SuperRes's anti-ringing *can* replace the upscaler's anti-ringing, but .50 is not enough. It takes more something like .75.

Madshi, does that anti-ringing apply to both chroma and luma?

It doesn't do as good of an anti-ringing job than the standard anti-ringing, but removing standard anti-ringing allows to save on performance, increase other settings, or afford SuperRes.
Ok, thanks. madVR's anti-ring applies to both chroma and luma, if that's your question.

Version shows 0.88.9 when checking with this build. Queues unfortunately still do not fill with D3D11 and 10-bit output. D3D9 with 10-bit output, queues fill.

And of course again, testing 0.88.8 with D3D11 10-bit, queues fill.

A 64 bit .ax file for testing, similar to the previous debugging builds you provided, would be preferred - to avoid having to use a 32bit player. Thanks. :)
Does this one fix the issue? It's based on the latest v0.88.11:

http://madshi.net/madVR64queueFix1.rar

If it does fix the issue, please also double check with 23/24p display modes (if your display supports them), with both this build and v0.88.8. Your logs so far were mostly 59p, IIRC.

[GCRaistlin]

There's another annoying issue that is present in all madVR builds I've used so far. The problem is that it should be very hard to reproduce.
I use Mozilla Firefox, and there are always a lot of tabs open there (185 for now). When playing a video with madVR on the 2nd monitor Firefox sometimes crashes, sometimes behaves weird (only the window title is displayed, the rest is "transparent" - the contents of a background window is visible). I don't know if this is caused either by some of the opened tabs, or by playing on the 2nd monitor, or even by madVR (EVR CP looks really ugly on the projector + 140" screen, and the issue is too unstable and relative rarely appearing to perform a good test). But it does exist.

[Anime Viewer]

For reference when I refer to FineSharp (i) below I am referring to FineSharp in Image Enhancements, and when I refer to FineSharp (u) I am referring to FineSharp in Upscaling Refinement. Its easier that typing each phrase over and over again.


Can you explain why you like it better/worse in either of these sections? In which way does it look better in image enhancement? In in which way does it look worse in upscaling refinement? Have you tested FineSharp alone (without SuperRes etc) in upscaling refinement? Do you still dislike linear light there? Or maybe it's only when used together with SuperRes?

The main benefit I see from using the Image Enhancement version as opposed to the Upscaling Refinement version is that the Image Enhancement version doesn't increase render times. That makes it more problem free (more universally usable) when it comes to using it across different gpus. Using the Upscaling Enhancement version the render times increase, and it can drag down a weak gpu.

The tests I have done when I made the second report (above) and this one were done without SuperRes, so only the first test I did involved using SuperRes in combination with FineSharp. As I reported in the first test report I felt that if one is combining FineSharp with SuperRes they seem to work better if they are both used from the Upscaling Refinement area.

When enabling Linear Light in FineSharp (i) I notice a significant change in shading and around black areas on the screen. Its a look I prefer having enabled as opposed to disabled in the (i) version. Linear Light in the (u) version has much less (an almost unperceptive) effect. Enabling Linear Light in the (u) version makes it look like a very small (insignificant) increase in sharpness/jaggedness. Very much insignificant in my view, and I'd have no objection to it enabled by default when used by the (u) version. I don't notice the change in blacks and shading with the (u) version like I do with the (i) version.


Not really. Try this image:

http://madshi.net/castleOrg.png

Double it with NNEDI3, then apply FineSharp as upscaling refinement. Then compare repair with 0.0 to 1.0. Look at the diagonal roof lines. They contain a bit of aliasing when using repair 0.0, which is mostly gone with 1.0. Using 0.25 is somewhere in between. It's a subtle difference in this image. I've seen far worse aliasing caused by FineSharp in other images. Sadly I can't find them on a quick look right now.

I'm having a hard time seeing a difference. As I'm toggling things off and on I thought I may have been seeing a small change in the roof edges, but then when I toggle again I don't think I see any change, so I'm not sure if I'm seeing any effect from the repair feature. With that being said if its believed a 1.0 value improves things then I say go ahead and set it to that. I don't see anything getting worse or negatively effected by having it set to 1.0, so I see no reason not to have it default to that value.


So you'd suggest 2.0 for "high" and 0.5 for "low"? Can you play with "thinning" a bit to see if you like those values to be changed in any way for high or low?

If Image Doubling is combined with FineSharp I think higher settings can be used with less negative effects (artifacts). Increasing the thinning setting gives the impression the image is composed of more tiny dots/circles and looks to increase sharpness slightly. In FineSharp (i) it higher settings (beyond default) give (for lack of a better term) a bit of an artificial look. I like the look of the sharpening increasing the setting gives when used in FineSharp (u). When I have more time I'll try to spend more time adjusting the thinning settings and see if there are certain values that appeal to me in each type of FineSharp situation.


You mean using FineSharp in image enhancements, and then afterwards doubling? What kind of effect does doubling have on FineSharp in your experience?

Doubling smooths out the jaggedness (alaising) I see that is created when using FineSharp especially at the FineSharp's higher strength settings. Interestingly enough I feel like I see it having different effects depending on which FineSharp it is used with. When using Doubling with the FineSharp in image enhancements it greatly reduces the amount of artifacts I see.
When using Doubling with the FineSharp in upscaling refinement it smooths out jaggedness of alaising lines. (When comparing FineSharp (i) to FineSharp (u) at the same strengths FineSharp (u) is more of a blurry image with far less artifacts. To a degree Doubling may be reducing artifacts with FineSharp (u) as well, and reducing sharping edges with FineSharp (i), but given that the pre-doubled image was already pretty smooth with FineSharp (i), and the pre-doubled image with FineSharp (u) was pretty artifact free before doubling the effects are less noticeable). Combining both FineSharps (aka enabling both) doesn't appear to look too bad as long as both are reduced in strength by half (causing the total strength to FineSharp to remain the same when all is said and done), but then you bring in the possibility of FineSharp (u) increasing render speeds and dragging down weaker gpu.


------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
There's another annoying issue that is present in all madVR builds I've used so far. The problem is that it should be very hard to reproduce.
I use Mozilla Firefox, and there are always a lot of tabs open there (185 for now). When playing a video with madVR on the 2nd monitor Firefox sometimes crashes, sometimes behaves weird (only the window title is displayed, the rest is "transparent" - the contents of a background window is visible). I don't know if this is caused either by some of the opened tabs, or by playing on the 2nd monitor, or even by madVR (EVR CP looks really ugly on the projector + 140" screen, and the issue is too unstable and relative rarely appearing to perform a good test). But it does exist.

It sounds to me like you are running out of memory. If you either leave task manager open, or open it once you encounter the problem how much memory does it say your browser is using? How much memory do you have in your system? I've seen similar effects to what you describe when people run out of memory. The fault is with the browser and it leaking memory as opposed to madVR. If you type "about:memory" in your address bar you can use the buttons under free memory to reclaim some of it. Tabs that are running Adobe, Java, and video plugins (even if you don't have any of them actively playing) can be huge memory leaks. You can try FireFox developer edition, and see if that works better - in my testing it leaks far less memory. Finally as it relates to madVR you can reduce the queue settings, so that it uses less memory (and frees up more for your browser), but doing that may have a negative effect on your video playback. Its something you'd have to experiment with yourself, and determine if it makes things better or worse.

[GCRaistlin]

madshi, should I create a ticket on the bug tracker for my request about the ability to change the refresh rate from the icon menu (http://forum.doom9.org/showthread.php?p=1721850#post1721850)?

[GCRaistlin]

How much memory do you have in your system?
3 GB. I'll check how much memory Firefox use next time I'll experience the issue.

[SecurityBunny]

Does this one fix the issue? It's based on the latest v0.88.11:

http://madshi.net/madVR64queueFix1.rar

If it does fix the issue, please also double check with 23/24p display modes (if your display supports them), with both this build and v0.88.8. Your logs so far were mostly 59p, IIRC.

That does seem to fix the issue. Queues fill fine with D3D11 10-bit output. The only issue I'm able to tell is with D3D11, present queue is 15-15/15 while on D3D9 it bounces between 15-16/16 | 16-16/16. So you seem to lose one prepresented frame with D3D11.

Unfortunately I don't believe my monitor supports 23/24p display modes since it switches back to 59.95 hz after going fullscreen for a few seconds. But for those few seconds testing 24hz (display reporting 24.00 in madvr), queues fill all the way with prepresented at 14-15/15. Testing 23hz (presuming you don't mean 23.976hz) queues did not fill but the display was outputting 22.99hz.

Testing 0.88.8 at 24hz, queues fill perfectly fine. But similar to above, D3D11 seems to lose a prepresented frame in present queue when compared to D3D9.

All testing done with Ordered Dithering with both options enabled.

Edit: Probably doesn't mean much but with the test build, D3D11 10-bit, present queue displays 14-15/15 in windowed mode, whereas fullscreen it is completely stable at 15-15/15.

[madshi]

There's another annoying issue that is present in all madVR builds I've used so far. The problem is that it should be very hard to reproduce.
I use Mozilla Firefox, and there are always a lot of tabs open there (185 for now). When playing a video with madVR on the 2nd monitor Firefox sometimes crashes, sometimes behaves weird (only the window title is displayed, the rest is "transparent" - the contents of a background window is visible). I don't know if this is caused either by some of the opened tabs, or by playing on the 2nd monitor, or even by madVR (EVR CP looks really ugly on the projector + 140" screen, and the issue is too unstable and relative rarely appearing to perform a good test). But it does exist.
Doesn't sound like madVR would be at fault.

I'm having a hard time seeing a difference. As I'm toggling things off and on I thought I may have been seeing a small change in the roof edges, but then when I toggle again I don't think I see any change, so I'm not sure if I'm seeing any effect from the repair feature. With that being said if its believed a 1.0 value improves things then I say go ahead and set it to that. I don't see anything getting worse or negatively effected by having it set to 1.0, so I see no reason not to have it default to that value.
Ok. Anybody else objecting to setting "repair" to 1.0?

When I have more time I'll try to spend more time adjusting the thinning settings and see if there are certain values that appeal to me in each type of FineSharp situation.
Would appreciate that, thanks.

When using Doubling with the FineSharp in upscaling refinement it smooths out jaggedness of alaising lines.
That's what "repair" also is supposed to help with, I think.

madshi, should I create a ticket on the bug tracker for my request about the ability to change the refresh rate from the icon menu (http://forum.doom9.org/showthread.php?p=1721850#post1721850)?
The bug tracker is only for bugs, not for feature wishes. About your feature wish see my reply here:

http://forum.doom9.org/showthread.php?p=1721943#post1721943

That does seem to fix the issue. Queues fill fine with D3D11 10-bit output. The only issue I'm able to tell is with D3D11, present queue is 15-15/15 while on D3D9 it bounces between 15-16/16 | 16-16/16. So you seem to lose one prepresented frame with D3D11.

Unfortunately I don't believe my monitor supports 23/24p display modes since it switches back to 59.95 hz after going fullscreen for a few seconds. But for those few seconds testing 24hz (display reporting 24.00 in madvr), queues fill all the way with prepresented at 14-15/15. Testing 23hz (presuming you don't mean 23.976hz) queues did not fill but the display was outputting 22.99hz.

Testing 0.88.8 at 24hz, queues fill perfectly fine. But similar to above, D3D11 seems to lose a prepresented frame in present queue when compared to D3D9.
If your monitor doesn't support 23/24p, then you shouldn't see any image at all. You do seem to see an image. Not sure why it's switching back to 59p, though.

What is important to me is if v0.88.8 is in any way better than the test build or not. If v0.88.8 is not better (not at any refresh rate), then we can consider the problem in v0.88.9+ fixed, and we can stop investigating. You're saying v0.88.8 filled the queue at 24hz, and the test build, too. But the test build doesn't seem to fill the queues at 23hz. So does v0.88.8 do that?

[Hyllian]

Hi, sorry for hijacking the thread a bit. For some time I have developed some shaders for other systems (emulators) and would like to know how one of them compares to the shaders used to upscale videos. My shaders are used primary for games, but I think some of them could be used for videos too.

What do you think about the quality of this 4x upscaled image?

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

[madshi]

@Hyllian,

that looks quite nice, actually. Compared to NNEDI3, I would say in some areas it's a bit better (e.g. the wheels of the white van) and in others a bit worse. However, I do see some ringing in your image. Did you sharpen it with a bad sharpener? Or does your scaler introduce ringing itself? FWIW, here's what NNEDI3 does, without and with sharpening:

NNEDI3 (http://madshi.net/ClownNnedi3.png) -|- NNEDI3 - sharpened (http://madshi.net/ClownNnedi3Sharpened.png)

What kind of algorithm does your shader use? How fast is it?

[TheLion]

Thanks. So for "image enhancements" you would suggest a strength of 2.0 for the "high" preset, using the default "thinning"? Have you played with the "thinning" a bit to find out whether you like it at its default value or slightly different maybe?

What would you suggest for medium and low presets?

And how much better do you like mode 3? I'm asking because it costs more performance. So the question is whether it's worth the added performance cost?



For FineSharp as Image Enhancement i would suggest:

Preset:Strength= low:0.5 medium:1.0 high:2.0
Always with linear light ON

Thinning seems fine at default for all three modes, but it's very hard to come up with a preference for me I am afraid - so I would certainly not object when this parameter is changed from default. I guess it would seem logical that the "optimum" thinning setting changes as well with different strength presets.

Mode 3 is certainly not "night and day" ;) but in my opinion the difference is relevant enough to make it the default, with mode 1 or 2 perhaps a new "trade quality for performance" checkbox. I know you hate additional options, but madVR is all about best quality first, afterall :)

[Hyllian]

@Hyllian,

that looks quite nice, actually. Compared to NNEDI3, I would say in some areas it's a bit better (e.g. the wheels of the white van) and in others a bit worse. However, I do see some ringing in your image. Did you sharpen it with a bad sharpener? Or does your scaler introduce ringing itself? FWIW, here's what NNEDI3 does, without and with sharpening:

NNEDI3 (http://madshi.net/ClownNnedi3.png) -|- NNEDI3 - sharpened (http://madshi.net/ClownNnedi3Sharpened.png)

What kind of algorithm does your shader use? How fast is it?
To tell you the truth, my algorithm is only for 2x, as NNEDI3 or NEDI. I have used my other jinc2 shader to go from 2x to 4x. And in fact it has some ringing, though most of them come from the jinc2 pass (the last pass). I didn't use any kind of sharpener and maybe it could improve the image a bit more.

My algorithm is called super-xbr, as it was derived from the standard xbr algorithm I already had developed for cartoon games some years ago and is largely used in emulators. The super-xbr is more focused in high color gradient images than cartoons, so I think it could be good for videos. For now, it's only in cg shader language and available for emulators like Retroarch. The sources are in this repository: https://github.com/libretro/common-shaders/tree/master/xbr/super-xbr

Unfortunately, I don't know other shaders languages to port it, but maybe you could port it and test in madVR or other players/systems. It's a bit less aggressive then the NEDI shader.


If I disable the anti-ringing I get this: http://i.imgur.com/bDA74E2.png

[SecurityBunny]

If your monitor doesn't support 23/24p, then you shouldn't see any image at all. You do seem to see an image. Not sure why it's switching back to 59p, though.

What is important to me is if v0.88.8 is in any way better than the test build or not. If v0.88.8 is not better (not at any refresh rate), then we can consider the problem in v0.88.9+ fixed, and we can stop investigating. You're saying v0.88.8 filled the queue at 24hz, and the test build, too. But the test build doesn't seem to fill the queues at 23hz. So does v0.88.8 do that?

At 23hz (22.99hz), with 0.88.8, queues seem to fill. Not as stable / completely filled as 59/24hz (15/15 queue size), but filled. Numbers like 12-15/15 for present queue, whereas the test build it is 2-8/15 for present queue.

So it seems odd integer refresh rates aren't fixed but 3:2 pulldown & 1:1 is fine?

[huhn]

At 23hz (22.99hz), with 0.88.8, queues seem to fill. Not as stable / completely filled as 59/24hz (15/15 queue size), but filled. Numbers like 12-15/15 for present queue, whereas the test build it is 2-8/15 for present queue.

So it seems odd integer refresh rates aren't fixed but 3:2 pulldown & 1:1 is fine?

what? 23 hz is supposed to be 24000/1001 = ~23.976

[starla]

In case someone happens to have performance issues with madVR rendering (excluding cases where DXVA scaling seems to work) one thing that could cause it is a buggy motherboard bios.

Same HW, but different MB bios versions resulted quite different texture upload speeds:


A8R8G8B8 Texture speed test:
default: upload 17 fps, download 138 fps
dynamic: upload 9 fps, download 8 fps, trick download 121 fps

vs.


A8R8G8B8 Texture speed test:
default: upload 132 fps, download 167 fps
dynamic: upload 239 fps, download 9 fps, trick download 131 fps

[SecurityBunny]

what? 23 hz is supposed to be 24000/1001 = ~23.976

Check my previous message. :P I tested both 24hz and 23hz since madshi asked for both. Setting my display to 23hz puts it in 22.99 whereas 24hz puts it at 24.00.

Though there still seems to be some type of problem if 0.88.8 can play 22.99hz with relatively full queues and the test build can't at this specific hz. Even if it isn't the norm.

[nlnl]

madshi
tested new image ehancement option using this image https://cloud.mail.ru/public/abgy/uwuasurxh
the results:
Fine sharp on
http://i71.fastpic.ru/thumb/2015/0606/71/13ccff64eada2845eb182c947ee5e371.jpeg (http://fastpic.ru/view/71/2015/0606/13ccff64eada2845eb182c947ee5e371.png.html)
fs off
http://i71.fastpic.ru/thumb/2015/0606/48/63c8ef050be3d12bf0a61c92cbe5da48.jpeg (http://fastpic.ru/view/71/2015/0606/63c8ef050be3d12bf0a61c92cbe5da48.png.html)

can not see horisontal lines when fs off and the same with superres filter off for chroma upsampling.
madshi
I mean that horisontal lines in window (marked using arrow)
FS OFF, image inhancement
http://i70.fastpic.ru/thumb/2015/0609/0c/47e4090e90f1d5b8487a5e78daf9b70c.jpeg (http://fastpic.ru/view/70/2015/0609/47e4090e90f1d5b8487a5e78daf9b70c.png.html)
no horisontal lines
and
FS ON, image inhancement,
http://i70.fastpic.ru/thumb/2015/0609/c6/212c521b2b48920f9d5f98f0605e9ac6.jpeg (http://fastpic.ru/view/70/2015/0609/212c521b2b48920f9d5f98f0605e9ac6.png.html)
we see lines.
This is the test image for correct chroma upsampling (Spears & Munsil) and we should see horisontal lines with and without Fine Sharpening?

[MysteryX]

Madshi, I'll add one more thing about SuperRes anti-ringing. It adds distortion to the image so you have to be careful. If it's too low, it doesn't quite remove anti-ringing, but then if it is too high, the image looks "flat"

[nevcairiel]

madshi
I mean that horisontal lines in window (marked using arrow)
FS OFF, image inhancement
http://i70.fastpic.ru/thumb/2015/0609/0c/47e4090e90f1d5b8487a5e78daf9b70c.jpeg (http://fastpic.ru/view/70/2015/0609/47e4090e90f1d5b8487a5e78daf9b70c.png.html)
no horisontal lines
and
FS ON, image inhancement,
http://i70.fastpic.ru/thumb/2015/0609/c6/212c521b2b48920f9d5f98f0605e9ac6.jpeg (http://fastpic.ru/view/70/2015/0609/212c521b2b48920f9d5f98f0605e9ac6.png.html)
we see lines.
This is the test image for correct chroma upsampling (Spears & Munsil) and we should see horisontal lines with and without Fine Sharpening?

I see lines in both cases on your screenshot, on a PC monitor with guaranteed 4:4:4 reproduction. Maybe it interacts badly with your chroma sampling test?

[madshi]

For FineSharp as Image Enhancement i would suggest:

Preset:Strength= low:0.5 medium:1.0 high:2.0
Always with linear light ON

Thinning seems fine at default for all three modes, but it's very hard to come up with a preference for me I am afraid - so I would certainly not object when this parameter is changed from default. I guess it would seem logical that the "optimum" thinning setting changes as well with different strength presets.

Mode 3 is certainly not "night and day" ;) but in my opinion the difference is relevant enough to make it the default, with mode 1 or 2 perhaps a new "trade quality for performance" checkbox. I know you hate additional options, but madVR is all about best quality first, afterall :)
Ok, thanks.

To tell you the truth, my algorithm is only for 2x, as NNEDI3 or NEDI. I have used my other jinc2 shader to go from 2x to 4x. And in fact it has some ringing, though most of them come from the jinc2 pass (the last pass). I didn't use any kind of sharpener and maybe it could improve the image a bit more.
Why don't you use your super-xbr twice, like 2*2x = 4x? That's what I'm doing with NNEDI3/NEDI, too.

My algorithm is called super-xbr, as it was derived from the standard xbr algorithm I already had developed for cartoon games some years ago and is largely used in emulators. The super-xbr is more focused in high color gradient images than cartoons, so I think it could be good for videos. For now, it's only in cg shader language and available for emulators like Retroarch. The sources are in this repository: https://github.com/libretro/common-shaders/tree/master/xbr/super-xbr

Unfortunately, I don't know other shaders languages to port it, but maybe you could port it and test in madVR or other players/systems. It's a bit less aggressive then the NEDI shader.

If I disable the anti-ringing I get this: http://i.imgur.com/bDA74E2.png
Ouch, looks very ugly without anti-ringing!

Which license does your super-xbr algo (and the shaders) come with? I might be interested trying it for madVR, but it depends on the license. Thanks!

At 23hz (22.99hz), with 0.88.8, queues seem to fill. Not as stable / completely filled as 59/24hz (15/15 queue size), but filled. Numbers like 12-15/15 for present queue, whereas the test build it is 2-8/15 for present queue.

So it seems odd integer refresh rates aren't fixed but 3:2 pulldown & 1:1 is fine?
I know what the problem is: In v0.88.9 I extended the refresh rate fix for Direct3D11. The refresh rate fix monitors which refresh rate D3D11 tries to set, and modifies that, if needed. If I leave the refresh rate untouched, your queues fill. If I modify the refresh rate, you get the problems with the non-filling queues. In v0.88.9+ I *always* modified the refresh rate. v0.88.8 only filled the refresh rate in some very special situations. The test build walks middle ground by changing the refresh rate when D3D11 tries to set a refresh rate which is too far away from what we really want to get. In your case with 23Hz madVR sees 23p and expects 23.976Hz, but D3D11 asks for 23.000Hz. That's too far apart, so madVR changes that to 23.976Hz. And that makes the queue no filling. Nothing I can do about it, I guess.

I'm not sure exactly *why* the queues aren't filling. I mean I know it's caused by me modifying the refresh rate. But I'm not sure why modifying the refresh rate causes the queues to not fill - and only in 10bit mode. Strange. And it seems to only affect some users, not all. In any case, I've done what I could do. I think I'll call it a day now and leave things as they are in the test build.

In case someone happens to have performance issues with madVR rendering (excluding cases where DXVA scaling seems to work) one thing that could cause it is a buggy motherboard bios.
Yep, especially when the upload queue doesn't fill, a BIOS update has just proven one possible fix.

Madshi, I'll add one more thing about SuperRes anti-ringing. It adds distortion to the image so you have to be careful. If it's too low, it doesn't quite remove anti-ringing, but then if it is too high, the image looks "flat"
Yes, I've seen issues with anti-ringing set to 1.0, and I think the same issues also occur with lower values, just not as strongly.

I mean that horisontal lines in window (marked using arrow)
FS OFF, image inhancement
no horisontal lines
and
FS ON, image inhancement,
we see lines.
This is the test image for correct chroma upsampling (Spears & Munsil) and we should see horisontal lines with and without Fine Sharpening?
I see lines in both cases on your screenshot, on a PC monitor with guaranteed 4:4:4 reproduction. Maybe it interacts badly with your chroma sampling test?
^ What nevcairiel said.

[SecurityBunny]

I know what the problem is: In v0.88.9 I extended the refresh rate fix for Direct3D11. The refresh rate fix monitors which refresh rate D3D11 tries to set, and modifies that, if needed. If I leave the refresh rate untouched, your queues fill. If I modify the refresh rate, you get the problems with the non-filling queues. In v0.88.9+ I *always* modified the refresh rate. v0.88.8 only filled the refresh rate in some very special situations. The test build walks middle ground by changing the refresh rate when D3D11 tries to set a refresh rate which is too far away from what we really want to get. In your case with 23Hz madVR sees 23p and expects 23.976Hz, but D3D11 asks for 23.000Hz. That's too far apart, so madVR changes that to 23.976Hz. And that makes the queue no filling. Nothing I can do about it, I guess.

I'm not sure exactly *why* the queues aren't filling. I mean I know it's caused by me modifying the refresh rate. But I'm not sure why modifying the refresh rate causes the queues to not fill - and only in 10bit mode. Strange. And it seems to only affect some users, not all. In any case, I've done what I could do. I think I'll call it a day now and leave things as they are in the test build.


Sounds good. The test build seems to function just fine with both 24hz and 60hz in D3D11 10-bit mode. As long as the queues fill, I would consider the issue fixed. At least would fix my problem.

Any idea why 1 prepresented frame is being dropped when using D3D11 though? With frames in advance set to 16, 15-15/15 present queue with D3D11, 15-16/16 present queue with D3D9.

[JackCY]

Technically not possible right now, because custom shaders are not flexible/powerful enough to run Shiandow's deband. At some point in the future, that should be possible, though.
So, where does it run right now? What HW (CPU/GPU), what part of HW (if not GPU shaders).
I might ask Shiandow about the alg. then.

Of course my plan is to get rid of the edit boxes altogether and just offer low/medium/high. I could allow the edit boxes to be edited, but it's not that simple, then I also must parse the text and complain if the format isn't correct etc. So some extra work involved there...

Yeah I know checking user input is rather a PITA, I guess C++, gotta write too much and able to reuse only a little.