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 8th June 2015, 20:01   #30861  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by RainyDog View Post
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 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.

Quote:
Originally Posted by GCRaistlin View Post
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.

Quote:
Originally Posted by nlnl View Post
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.

Quote:
Originally Posted by XMonarchY View Post
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.

Quote:
Originally Posted by MysteryX View 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.

Quote:
Originally Posted by XMonarchY View Post
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.

Quote:
Originally Posted by MysteryX View Post
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.

Quote:
Originally Posted by James Freeman View Post
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?

Quote:
Originally Posted by huhn View Post
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...

Quote:
Originally Posted by XRyche View Post
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?

Quote:
Originally Posted by MistahBonzai View Post
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!

Quote:
Originally Posted by baii View Post
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

Quote:
Originally Posted by XMonarchY View Post
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.

Quote:
Originally Posted by JarrettH View Post
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.

Quote:
Originally Posted by 6233638 View Post
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.

Quote:
Originally Posted by JackCY View Post
Before I can post a v0.88.11 is released and Shiandow deband is removed?
Quote:
Originally Posted by JackCY View Post
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.

Quote:
Originally Posted by JackCY View Post
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.

Quote:
Originally Posted by JackCY View Post
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 is offline   Reply With Quote
Old 8th June 2015, 20:04   #30862  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by SecurityBunny View Post
Debug log: https://www.dropbox.com/s/hi8yiom7xc...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 is offline   Reply With Quote
Old 8th June 2015, 20:09   #30863  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
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?
madshi is offline   Reply With Quote
Old 8th June 2015, 20:20   #30864  |  Link
JackCY
Registered User
 
Join Date: Jun 2015
Posts: 15
Quote:
Originally Posted by madshi View Post
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?

Quote:
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.

Last edited by JackCY; 8th June 2015 at 20:38.
JackCY is offline   Reply With Quote
Old 8th June 2015, 20:30   #30865  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 9,818
Quote:
Originally Posted by madshi View Post
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!
__________________
LAV Filters - open source ffmpeg based media splitter and decoders

Last edited by nevcairiel; 8th June 2015 at 21:05.
nevcairiel is offline   Reply With Quote
Old 8th June 2015, 20:30   #30866  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,901
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.

Quote:
Originally Posted by madshi View Post
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.
huhn is online now   Reply With Quote
Old 8th June 2015, 20:39   #30867  |  Link
SecurityBunny
Registered User
 
Join Date: Jul 2013
Posts: 76
Quote:
Originally Posted by madshi View Post
Yeah, looks exactly as expected. Will have to do some more test builds. Stay tuned...
Sure thing. On stand-by.
SecurityBunny is offline   Reply With Quote
Old 8th June 2015, 20:55   #30868  |  Link
omarank
Registered User
 
Join Date: Nov 2011
Posts: 180
Quote:
Originally Posted by madshi View Post
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.
omarank is offline   Reply With Quote
Old 8th June 2015, 21:36   #30869  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,716
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.
aufkrawall is offline   Reply With Quote
Old 8th June 2015, 22:33   #30870  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by JackCY View Post
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.

Quote:
Originally Posted by JackCY View Post
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...

Quote:
Originally Posted by nevcairiel View Post
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...

Quote:
Originally Posted by huhn View Post
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?

Quote:
Originally Posted by SecurityBunny View Post
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

Quote:
Originally Posted by omarank View Post
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.

Quote:
Originally Posted by aufkrawall View Post
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 is offline   Reply With Quote
Old 8th June 2015, 22:43   #30871  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
Quote:
Originally Posted by madshi View Post
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.
madshi is offline   Reply With Quote
Old 8th June 2015, 22:51   #30872  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 752
Quote:
Originally Posted by madshi View Post
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).
Shiandow is offline   Reply With Quote
Old 8th June 2015, 22:52   #30873  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,137
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!
madshi is offline   Reply With Quote
Old 8th June 2015, 23:47   #30874  |  Link
SecurityBunny
Registered User
 
Join Date: Jul 2013
Posts: 76
Quote:
Originally Posted by madshi View Post
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.
SecurityBunny is offline   Reply With Quote
Old 9th June 2015, 00:26   #30875  |  Link
TheLion
Registered User
 
Join Date: Dec 2010
Posts: 62
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/0B9J...ew?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.

Last edited by TheLion; 9th June 2015 at 00:30.
TheLion is offline   Reply With Quote
Old 9th June 2015, 00:32   #30876  |  Link
GCRaistlin
Registered User
 
GCRaistlin's Avatar
 
Join Date: Jun 2006
Posts: 262
Quote:
Originally Posted by madshi View Post
XP, euwh.

Ok, if these freezes occur, does the media player still react to you?
Yes, it does, I'm able to close it.
__________________
Magically yours
Raistlin
GCRaistlin is offline   Reply With Quote
Old 9th June 2015, 01:20   #30877  |  Link
baii
Registered User
 
Join Date: Dec 2011
Posts: 180
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.
baii is offline   Reply With Quote
Old 9th June 2015, 01:23   #30878  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,215
Quote:
Originally Posted by SecurityBunny View Post
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.
ryrynz is offline   Reply With Quote
Old 9th June 2015, 01:33   #30879  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 5,901
Quote:
Originally Posted by madshi View Post
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.
huhn is online now   Reply With Quote
Old 9th June 2015, 04:32   #30880  |  Link
MysteryX
Soul Architect
 
MysteryX's Avatar
 
Join Date: Apr 2014
Posts: 2,173
Quote:
Originally Posted by huhn View Post
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.

Last edited by MysteryX; 24th June 2015 at 07:03.
MysteryX 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 00:40.


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