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
Register FAQ Calendar Today's Posts Search

Reply
 
Thread Tools Search this Thread Display Modes
Old 15th June 2015, 00:56   #31061  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
One other thing first:
Here you can also see how SuperRes for chroma vanishes some contoures.
super-xbr + SuperRes:


NNEDI3 256:


You can see some dark lines almost vanish compared to NNEDI3 256. I don't think this is desired, since NNEDI 256 is considered to be dam good with clear dark lines in simple structures.

Now luma:
NNEDI3 is still far superior for this strong cartoon resizing. However, super-xbr seems definitely better than NNEDI to me.

NNEDI:


NNEDI3 256:


super-xbr:


super-xbr + SuperRes:


SuperRes settings:


The difference is very visible. But source's resolution is just 640x368, kinda extreme.
With 720p -> WQHD, the difference is almost neglectable.

NNEDI3 64:


super-xbr + SuperRes:
aufkrawall is offline   Reply With Quote
Old 15th June 2015, 01:19   #31062  |  Link
JarrettH
Registered User
 
Join Date: Aug 2004
Location: Canada
Posts: 860
Bicubic75 AR chroma
Jinc3 AR luma
https://farm1.staticflickr.com/554/1...d9662b77_o.png

super-xbr doubling
super-xbr chroma
Jinc3 AR luma
https://farm1.staticflickr.com/341/1...e2fce661_o.png

Didn't we figure out a long time ago that the chroma upscaling method isn't very important past Bicubic75? Cartoon examples really exaggerate things

Last edited by JarrettH; 15th June 2015 at 01:27.
JarrettH is offline   Reply With Quote
Old 15th June 2015, 01:27   #31063  |  Link
aufkrawall
Registered User
 
Join Date: Dec 2011
Posts: 1,812
Forgot to say: FS' thinning is hardcore terrible for cartoons, it introduces extreme aliasing with contoures.
aufkrawall is offline   Reply With Quote
Old 15th June 2015, 02:03   #31064  |  Link
FireFreak111
Registered User
 
Join Date: Apr 2014
Posts: 48
88.12 has some serious improvements. Fullscreen exclusive times in D3D11 exclusive 8 bit has easily been reduced significantly (takes ~80% less time than before on Win 10, HDMI plasma), not sure why, but I can switch between FSE and fullscreen windowed super fast.

Build 10130 of Win 10 has stopped me from being able to use image doubling. Immediate crash with any algo. Hopefully next build it's not a problem. I can use Super-XBR for chroma now however, which works nicely. I didnt activate SuperRes for Chroma. I noticed there's no SuperRes default for Super-XBR doubling. Is there no need? Also, will there be defaults for Chroma?

I'm curious on whether NEDI or Super-XBR is better for chroma. I'll do some testing, but I wonder what others think, especially for animation.
FireFreak111 is offline   Reply With Quote
Old 15th June 2015, 03:31   #31065  |  Link
har3inger
Registered User
 
Join Date: Feb 2014
Posts: 139
Aufkrawall, you've pointed out something I've also noticed with superchromares. Usually in lower quality sources (?), when you have white text on solid red or solid green backgrounds, such as on a street sign or news banner, there's a darkish outline around the white parts. Superchromares likes to attempt to erase these dark halos, but sometimes ends up turning the dark halos into oversaturated colored halos, and even introduce some possible chroma bleed.

This img from google images illustrates the halos I'm talking about.

Notice how there's darkening around the letters of the word "DePAUL". These disappear and sometimes become bright red (or whatever the background color is) halos if you apply superchromares. I think this might be some sort of chroma bleed where the red is going into the letters. It can make the image look strange and IMO pretty ugly. I'd post a sample screenshot, but I lost the file where I first noticed this issue.

This street sign also illustrates the dark halos I'm talking about. Here, it's very obvious that the removal of those dark edges is desirable, and applying superchromares in these sorts of cases does work as intended.


In some other cases, thin red lines on black background will have very different saturation between superchromares and jinc3 ar, but it's harder to say what's supposed to be correct in those cases. Overall, Superchromares can look amazing in some isolated cases (solid red on white/black), but it does have these weird behaviors associated with it. Setting the anti-ringing to 1.00 seems to alleviate the color bleeding, but not the loss of the dark halos.

Last edited by har3inger; 15th June 2015 at 03:38.
har3inger is offline   Reply With Quote
Old 15th June 2015, 04:29   #31066  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by madshi
Quote:
Originally Posted by me
88.12 is completely unusable with my system (i7, gtx660), in D3D9 or D3D11; render & present are empty all the time in windowed fullscreen.
Back to 88.11 for now.
Strange. Can you please try to isolate what is causing the problem? So far nobody else has reported the problem. So it doesn't seem to be a general problem with v0.88.12. E.g. try to reset madVR settings to default. Is it only the render & present queues which are empty? Or also other queues?
It appears that my rendering time raised to 41ms thus the queues not filling up.
* I downclock my GPU to save power.
In version 88.11 the rendering was twice as fast, at about 20-25ms.
Nothing special, just Lanczos 3, Smooth Motion, Ordered Dithering.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 15th June 2015 at 07:15.
James Freeman is offline   Reply With Quote
Old 15th June 2015, 06:03   #31067  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
Quote:
Originally Posted by aufkrawall View Post
Forgot to say: FS' thinning is hardcore terrible for cartoons, it introduces extreme aliasing with contoures.
Try FS in 0.88.11 and de-select LL. The heavy contouring is a side-effect of the LL finesharp, which is also very apparent in the tests I've done. This does not happen with no LL enabled. I already showed screenshots to madshi, hopefully he will listen.

Last edited by iSunrise; 15th June 2015 at 07:34.
iSunrise is offline   Reply With Quote
Old 15th June 2015, 06:54   #31068  |  Link
MistahBonzai
Registered User
 
Join Date: Mar 2013
Posts: 101
Quote:
Originally Posted by har3inger View Post
Aufkrawall, you've pointed out something I've also noticed with superchromares. Usually in lower quality sources (?), when you have white text on solid red or solid green backgrounds, such as on a street sign or news banner, there's a darkish outline around the white parts. Superchromares likes to attempt to erase these dark halos, but sometimes ends up turning the dark halos into oversaturated colored halos, and even introduce some possible chroma bleed.
I've observed many of the video 'oddities' mentioned above while testing these new settings with video test patterns developed for use in calibration procedures. You can use chroma and luma resolution calibration patterns to get a better sense of how the settings affect 'pristine' video.

I thought there were suitable test video sequences in the MP4-2C HDTV Calibration Disc From the AVSForum however I just discovered that the 720p Chroma 4:2:0 and 4:4:4 resolution patterns I have been using aren't included - I must have picked them up elsewhere. Inanycase it shouldn't be that difficult to obtain suitable 720p resolution test sequences for upscaling if so inclined... You might be surprised by how some of the settings we are testing affect the video resolution under test conditions. That way you get a better idea of what to look for when testing on your video samples.

Edit: There are image samples in various resolutions of the Belle Nuit Montage at their web site: http://www.belle-nuit.com/test-chart

Last edited by MistahBonzai; 15th June 2015 at 07:13. Reason: added link to test images
MistahBonzai is offline   Reply With Quote
Old 15th June 2015, 07:45   #31069  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
"original AR" by Hyllian, looks best to me in this image.
It retains the image properties without enhancing anything and remains faithful to the original, as it should (IMO).

Back to 88.11 for testing.
Finesharp:
LL over-enhances the edges and clips the shades = VERY BAD.
Thinning 0.020 as agreed, I see little difference.
Mode 3 as agreed.
IMO, Strength should stay a variable for different content (for now).
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 15th June 2015 at 07:54.
James Freeman is offline   Reply With Quote
Old 15th June 2015, 08:27   #31070  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,650
Double post.

Last edited by ryrynz; 15th June 2015 at 08:30.
ryrynz is offline   Reply With Quote
Old 15th June 2015, 08:29   #31071  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,650
Quote:
Originally Posted by JarrettH View Post
Bicubic75 AR chroma
Jinc3 AR luma
https://farm1.staticflickr.com/554/1...d9662b77_o.png

super-xbr doubling
super-xbr chroma
Jinc3 AR luma
https://farm1.staticflickr.com/341/1...e2fce661_o.png

Didn't we figure out a long time ago that the chroma upscaling method isn't very important past Bicubic75? Cartoon examples really exaggerate things

It doesn't "exaggerate things" it highlights things.

That frame you have screenshot there isn't a good test, there's almost nothing that any chroma resizer is going to make a shred of difference on.

There are many of us that use madVR for upscaling of lower resolution cartoon/animated content where chroma upscaling quality is of more obvious importance but it can still be hard to tell much of a difference in many scenes.

Bicubic 75 AR has been determined to be very good for it's performance penalty, but sometimes people want "better" results.

Last edited by ryrynz; 15th June 2015 at 09:32.
ryrynz is offline   Reply With Quote
Old 15th June 2015, 10:02   #31072  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
Quote:
Originally Posted by JarrettH View Post
...Didn't we figure out a long time ago that the chroma upscaling method isn't very important past Bicubic75? Cartoon examples really exaggerate things
That's why madVR offers profiles and settings that can be tailored to your content and your setup. Not every content will behave and show the same, that's what makes madVR special, it can be specifically configured so that you can get most out of your sources.

On HQ/HD 4:2:0 mastered movies with a high bitrate the differences will be a lot less visible than on cartoon, game recordings or line charts or patterns. But they are just as valid examples and very useful to detect specific behaviours of algorithms madVR uses.
iSunrise is offline   Reply With Quote
Old 15th June 2015, 10:24   #31073  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by XMonarchY View Post
I just compared the same clip in WMP vs. madVR and I have to say that without FineSharp or LumaSharpen madVR (best quality settings) does make the image so soft that some people may dislike it and prefer playback via WMP simply due to sharpness, especially if you sit close to your display.
madVR does not make the image soft at all. I don't know what WMP does, if it's sharper than madVR then WMP probably uses some sort of sharpening.

Quote:
Originally Posted by har3inger View Post
Can't wait to test the version with madshi's AR filter.
It's already implemented in v0.88.12.

Quote:
Originally Posted by MS-DOS View Post
Hmm, found a bug on the image doubling page in the latest version: it shows chroma doubling as enabled for NNEDI3 even though it's actually disabled.
Will check.

Quote:
Originally Posted by Anime Viewer View Post
I like the 0.0 strength and 0.035 (I'm guessing you meant 0.035 and not the 0.35 you typed as you can only go up to 0.27ish, and that setting produces a lot of jaggedness). I hadn't even contemplated 0.0 as a strength setting in my previous testing because I thought 0.0 would effectively be disabling FineSharp. Is that not the case? What about a 0.1 strength, does that produce anything unwanted in your tests? (In mine I don't see a difference in 0.0 and 0.1 strength, but that may be related to the source files I'm testing with...)

I think those settings work just as well when paired with super-xbr for image doubling.

NEDI was my previous image doubling choice (NNEDI3 was far to much of a resource waste and generated too high render stats for what it gives comapared to NEDI in my mind), but now I find I like the sharpness of the super-xbr better. On the 720p video I tested NEDI runs at ~11.5ms while super-xbr runs at ~15.7ms, and for 480p 6.4ms (NEDI) and 8.5ms (super-xbr).
I haven't fully studied yet how FineSharp works inside. But it seems to me that strength and thinning are mostly independent of each other, and control two different sharpening methods, or something like that.

Quote:
Originally Posted by FireFreak111 View Post
88.12 has some serious improvements. Fullscreen exclusive times in D3D11 exclusive 8 bit has easily been reduced significantly (takes ~80% less time than before on Win 10, HDMI plasma), not sure why, but I can switch between FSE and fullscreen windowed super fast.

Build 10130 of Win 10 has stopped me from being able to use image doubling. Immediate crash with any algo. Hopefully next build it's not a problem. I can use Super-XBR for chroma now however, which works nicely. I didnt activate SuperRes for Chroma. I noticed there's no SuperRes default for Super-XBR doubling. Is there no need? Also, will there be defaults for Chroma?
Shiandow is working to further improve SuperRes atm, so I didn't bother creating new defaults for super-xbr yet.

Quote:
Originally Posted by James Freeman View Post
It appears that my rendering time raised to 41ms thus the queues not filling up.
* I downclock my GPU to save power.
In version 88.11 the rendering was twice as fast, at about 20-25ms.
Nothing special, just Lanczos 3, Smooth Motion, Ordered Dithering.
That doesn't make a lot of sense. I haven't changed anything which would explain a performance difference. Are you sure the downclock works the same with v0.88.11 and v0.88.12? I'm rather thinking that maybe with one of those versions the clock of your GPU might be different or something. Nobody else has reported anything like this yet, either. So I think the problem is likely on your side somewhere. Sorry, I wish I could be more specific. But I don't have enough information to say anything more helpful...

Quote:
Originally Posted by James Freeman View Post
"original AR" by Hyllian, looks best to me in this image.
It retains the image properties without enhancing anything and remains faithful to the original, as it should (IMO).
In which image? The clown image? I could pinpoint 10-20 image parts where Hyllian's AR results in artifacts compared to madVR's AR. On the other hand, madVR's AR in 10-20 image parts has left unwanted ringing in the image which Hyllian's AR has removed. But overall I strongly prefer madVR's AR, for the clown image at least. As I said, for cartoonish video games the situation is very different...

Quote:
Originally Posted by aufkrawall View Post
Seems like super-xbr looks nice for chroma scaling.

Regarding sharpening (image enhancement):
FS seems to thicken and darken contoures, I don't like this artificial look for cartoons. Lumasharpen is brighter, but this can be reduced by lowering clamp value (e.g. to 0.02).
I don't like Lumasharpen in your screenshots at all. Can you try the FineSharp strength vs. thinning parameters to check which of them (or both) are responsible for the "thicken & darken"? Also, maybe you could double check with v0.88.11 whether disabling linear light makes a difference for you?

Quote:
Originally Posted by aufkrawall View Post
Now luma:
NNEDI3 is still far superior for this strong cartoon resizing. However, super-xbr seems definitely better than NNEDI to me.
Agreed. Due to the way NNEDI3 works, it removes some of the ringing that is already in the source, while super-xbr instead sharpens/increases the ringing. I think this is one key factor why NNEDI3 looks better with your test video. Another reason is that NNEDI3 produces lines which are "tighter" (less bloated up) compared to super-xbr. The ringing problem might be fixable (at some point in the future) by running a de-ringing algorithm before upscaling it.

I'm not a fan of NEDI at all, at least not when using it "alone". In combination with SuperRes NEDI might work well, though, because SuperRes removes most of the ugly NEDI artifacts. I believe NEDI should not be used alone, but only in combination with SuperRes.

Quote:
Originally Posted by aufkrawall View Post
Forgot to say: FS' thinning is hardcore terrible for cartoons, it introduces extreme aliasing with contoures.
Could I have a sample (or two or three) which nicely show this problem? I've found that FineSharp's "repair" may have to be set to values higher than 1.0, if you increase the "thinning" higher than 0.19, in order to avoid aliasing problems. Maybe I will also have to improve the repair algorithm. Would be good to have some samples to play with for that purpose.

Quote:
Originally Posted by iSunrise View Post
Yes, I missed it indeed. As I said, you are way too fast with changes, extremely hard to keep up.
Currently we have about 2 million options in the upscaling refinement page. I want most of them gone. So is it really too fast to remove an option when after a week's worth of testing *everybody* had the same opinion about that option?

As I wrote in the v0.88.12 release notes, at the moment when you voiced your concerns about FineSharp's linear light option, I had already removed the option from my sources. I only had the choice of either releasing v0.88.12 as it was, or delaying it a full week. Should I have delayed it - keeping super-xbr from all madVR users for a full week? I'm perfectly fine with further discussing the linear light option. I'm willing to revert my decision, if that's what seems the correct choice to me.

The reason I'm trying to make some reasonably fast decisions now is that I want to reduce the complexity of the testing/feedback cycle. The less options there are, the more precise the feedback will be. If you have to test 3 options for an algorithm instead of 2 options, it costs you much more time, and the feedback will be less precise. So that's why I thought it was a good idea to remove an option quickly where every user had the same preference, anyway.

Quote:
Originally Posted by iSunrise View Post
1) All my examples are done in image enhancements, under the processing tab (so before upscaling). This is because all the algorithms will be applied before upscaling, which shows me the differences a lot more clearly.
Fair enough. That also explains your preference for lower sharpness settings, though. When applying sharpening before upscaling you always need lower sharpening strength compared to sharpening after upscaling.

Quote:
Originally Posted by iSunrise View Post
2) Regarding the thinning under upscaling refinement, I agree, lower strengths are also advantageous here, I would say thinning should be between 0.020 and 0.035, not higher. I definitely had some strange artefacts appear with a setting of 0.100 on my first samples I posted, therefore I would not recommend them.
I wouldn't recommend 0.100, either. And maybe I wouldn't go very high in the image enhancement settings. But I think in upscaling refinement higher thinning values may be useful.

Quote:
Originally Posted by iSunrise View Post
4) Regarding your question, which image looks subjectively better, it's pretty clear for me and I invested quite a lot of time to be sure.
It seems several other users are having a different subjective impression, though. Things like this are hard to judge. I can't value one user's subjective impression higher than those of several others.

Quote:
Originally Posted by iSunrise View Post
5) The brightness you see is exactly what a sharpener does if you use way too high strengths
Oh no, you're making it *way* too easy for yourself here.

Do you know how sharpeners technically work? They usually take some sort of "average" of the neighborhood of each pixel, and then kind of substract the average from the image. The key thing here is that the averaging practically blends multiple colors together. And scientifically it is "wrong" to do this in gamma light. It will produce incorrect results. The brightening you're seeing when applying FineSharp with "LL off" with those 3 test images I uploaded shows exactly this problem. Turning LL on fixes this problem and resultingly should make the whole processing scientifically "better".

You saying that we can ignore this problem because it's caused by too high sharpening strength is kind of funny, considering that you zoomed into the squirrel screenshot, created with the same high sharpening strength, and then on top even applied some GIMP processing to make the differences even more visible! If this is not a double standard then what is? Of course lowering the sharpening strength will also lower the brightening that LL off produces with those 3 test images. But in the same way lowering the sharpening strength will also lower the artifacts that you're complaining about. But that doesn't mean that either artifacts isn't there, or should be ignored.

Quote:
Originally Posted by iSunrise View Post
If you need further tests, I can do them, but I think when you look at the enhanced squirrel, you will see the heavy artefacting that I am speaking of.
I can see that there's added ringing in the squirrel image, with LL turned on. I agree that's not a good thing. But you cannot simply ignore that LL off makes some images brighter. On the very same squirrel image some image features appear to get brighter/bigger when turning LL off! You cannot harp on just one type of artifact and ignore the others!

From what I can see, LL on/off both produce different kinds of artifacts. The key question is which kind of artifacts are worse. I know your opinion about it. I'm not sure myself.

I'm wondering whether maybe I should try a FineSharp LL build using the BT.709 gamma curve instead of a 2.2 power curve. Maybe that could give us the best of both worlds? Will have to wait for next weekend, though.
madshi is offline   Reply With Quote
Old 15th June 2015, 10:25   #31074  |  Link
kalston
Registered User
 
Join Date: May 2011
Posts: 164
Does the fact overlay mode report 24fps in fraps while regular FSE report 144 (or whatever my screen refresh rate is) matter in any way? I'm curious because I've started using Smooth motion (as I've heard it's great with high refresh rates) and I've noticed that it doubles the reported framerate when using overlay mode (so 24fps becomes 48, 60 becomes becomes 120 etc.) while obviously with regular FSE it just shows a number equal to my refresh rate no matter what.

(overlay feels just as smooth and reliable as FSE for me so I kinda doubt it matters but I'd rather make sure I'm not doing anything wrong )
kalston is offline   Reply With Quote
Old 15th June 2015, 12:01   #31075  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,926
Quote:
Originally Posted by aufkrawall View Post
That's great! So now AMD users now have good alternative to NNEDI3, combined with SuperRes.
AMD was/is still better at nnedi3 than NVIDIA for the same price even with the interop copyback.

but no real issue for both AMD and NVIDIA they both aim at gaming performance not openCL.
huhn is offline   Reply With Quote
Old 15th June 2015, 12:04   #31076  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,926
Quote:
Originally Posted by kalston View Post
Does the fact overlay mode report 24fps in fraps while regular FSE report 144 (or whatever my screen refresh rate is) matter in any way? I'm curious because I've started using Smooth motion (as I've heard it's great with high refresh rates) and I've noticed that it doubles the reported framerate when using overlay mode (so 24fps becomes 48, 60 becomes becomes 120 etc.) while obviously with regular FSE it just shows a number equal to my refresh rate no matter what.

(overlay feels just as smooth and reliable as FSE for me so I kinda doubt it matters but I'd rather make sure I'm not doing anything wrong )
this has to do how frames are present. you can ignore your fraps results. FSE new path has just more repeated frames drawn while overlay leaves them out and presenting "nothing" which comes don't to the same result.
huhn is offline   Reply With Quote
Old 15th June 2015, 12:22   #31077  |  Link
kalston
Registered User
 
Join Date: May 2011
Posts: 164
Good to know, I really love overlay mode as it combines windowed mode advantages with FSE's performance. My monitor won't accept 10bit input so it appears there is really no point bothering with FSE on my machine.
kalston is offline   Reply With Quote
Old 15th June 2015, 12:26   #31078  |  Link
RyuzakiL
Registered User
 
Join Date: May 2015
Posts: 36
Madvr 88.12 + AMD Crossfire Workaround

First of all i think this is the best version madvr had so far in terms of handling queues especially when using DX11 FSE 10bit mode. (And Display mode switching + FSE was insanely fast this time. Around 3 seconds waiting time compared to previous version where you had to wait for 10-15 seconds at best.)

I'm running on Win 8.1 64bit 2X HD7850 on crossfire + FX8320 @ 4.3ghz

Using Samsung 40inch Led Tv as my monitor. AMD CCC video settings turned all to off except deinterlacing and ITC Processing and Pixel Format: RBG 4:4:4

i followed the madvr setup guide found here https://imouto.my/madvr/
but made some modifications>> i changed NNEDI3 and
use Super-XBR instead since it seems lighter on AMD cards than NNEDI3 + InteropHack enabled.

I'm also using SuperRes Filter on Chroma Upscaling though I know that SuperRes Filter's default settings was for NNEDI3 but it seems picture quality wasn't affected much.

I cannot discern any big difference between Super-XBR vs. NNEDI3 so performance wise i selected Super-XBR since my HD7850 liked it better hehe.

Workaround for AMD Crossfire Users >>

Since the stupid AMD Catalyst always mistake Madvr as a game, ergo Crossfire is always turned on whenever it detects Madvr.

Now i found a simple work around to prevent AMD Catalyst to not use Crossfire when it detects Madvr. Here's the procedure.

Just open your AMD CCC and head on to "My Digital Flat-Panels Tab" and put a Check to "Enable GPU up-scaling" ofcourse put the dot on "scale image to full panel size" and voila! no more crossfire on Madvr yehey!

advantages:

1. No more power wasting due to Crossfire (we already know that madvr will not benefit on using crossfire)

2. In some way performance will be better since crossfire is not enabled (maybe because no more mirroring of data between gpu's)

disadvantages:

1. Madvr Display Mode Switching will not gonna work any longer, I don't know why but it seems using the said work around will bypass Madvr's Display Mode Switching.

2. It may in some way interfere with madvr's handling of things, especially when using DX11 FSE 10bit queues aren't full when using this work around. So you are stuck on using DX11 Windowed Fullscreen 8bit.

So in the end it's up to you.

If you want DX11 FSE 10bit running smoothly with crossfire wasting energy then do not use this work around.

But if you want to save electricity and make the 2nd card enter powersave then use this workaround.

FYI i cannot discern any difference at all using DX11 FSE 10bit vs. DX11 WF (Windowed Fullscreen) 8bit. That's why i'm using this setup.


Any corrections, objections and violent reactions are welcome.

P.S you need to use Madvr Smooth Motion since you are stuck on 60hz when using this workaround.

Last edited by RyuzakiL; 15th June 2015 at 12:30.
RyuzakiL is offline   Reply With Quote
Old 15th June 2015, 12:59   #31079  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
Quote:
Originally Posted by madshi View Post
Currently we have about 2 million options in the upscaling refinement page. I want most of them gone. So is it really too fast to remove an option when after a week's worth of testing *everybody* had the same opinion about that option?
I completely understand your developer point-of-view, I would probably do the same, just so that I could concentrate on the more important points on my checklist. I think you just did too much at the same time, when you introduced too many options in one of the last updates, that's why people really get confused and try out 2 million different settings and they never really provide meaningful feedback for only one option. I have never once had the feeling you did this on purpose though, but I think you can understand that people like me, who also have limited time to do these tests at least need 3-4 weeks to get familiar with the new settings and to concentrate on one specific test case. Otherwise, you will end up with a chaotic mix of feedback, which doesn't really help anyone.

Quote:
Originally Posted by madshi View Post
Fair enough. That also explains your preference for lower sharpness settings, though. When applying sharpening before upscaling you always need lower sharpening strength compared to sharpening after upscaling.
Yes, and it's important that others not just turn up the knobs, but also see the negatives and the positives, that's one of the very reasons why there need to be example shots. And most of the feedback I have read about finesharp was not screenshot based at all, everyone just basically says "I like XX better than YY", but very rarely they took their time to actually show it to everyone else. When we did the dithering tests, there was great communication, screenshots and lots of example shots where you could very clearly detect the positives and negatives and you also reacted very fast to improve them. With finesharp, this was not the case, since no one other than TheLion, me and you even provided screenshots. That's 3 people out of maybe 20 that basically just said "I like A better than B", but they could not tell us, why. If you enable picture processing on a modern LCD, you have to be very careful, but the majority will simply tell you that it's great for picture quality. And we know that such quick judgements are rarely about accuracy, but because of very quick first impressions.

If you show the average Joe two pictures on two of the very same monitors at the same time and you maximize every picture processing setting on one monitor, the majority will fall for it and pick the one with the heavy processing, but not the more accurate one. I, however, specifically look for an accurate representation, that's why I also bought an Eizo CG, because I want to see every detail in the source and I don't think that picking an algorithm that looks totally processed (like finesharp LL does) makes any sense at all when you can have finesharp without LL. The negatives will quickly add up and you end with heavy ringing that destroys every picture.

One of the main reasons why a lot of DVDs were so bad, was not because of their low native resolution, but because of their excessive ringing that was applied in post. They are almost completely unwatchable when you upscale them to HD or 4K. Finesharp with the current LL will amplify that even more and that doesn't make any sense when you can just use finesharp with no LL without these negatives.

Quote:
Originally Posted by madshi View Post
I wouldn't recommend 0.100, either. And maybe I wouldn't go very high in the image enhancement settings. But I think in upscaling refinement higher thinning values may be useful.
At least in image enhancement, I would not go any higher, but that's up for discussion. If someone provides some positives with going a lot higher and proves that it doesn't harm, then there should not be anything against it.

Quote:
Originally Posted by madshi View Post
It seems several other users are having a different subjective impression, though. Things like this are hard to judge. I can't value one user's subjective impression higher than those of several others.
As long as you still value screenshots more and that still rings an alarm when you look at them, I see no harm in that. But the majority is not a good measurement of accurateness, like I already explained above.

Quote:
Originally Posted by madshi View Post
From what I can see, LL on/off both produce different kinds of artifacts. The key question is which kind of artifacts are worse. I know your opinion about it. I'm not sure myself.

I'm wondering whether maybe I should try a FineSharp LL build using the BT.709 gamma curve instead of a 2.2 power curve. Maybe that could give us the best of both worlds? Will have to wait for next weekend, though.
If you can get rid of the heavy ringing, I would not be against LL. However, with results like this, this heavy amount of ringing is what made you create your AR algorithm for the upscalers in the first place. With finesharp, you basically destroy your own work, by adding heavy ringing again. I just cannot see how that's a good thing. Especially not when you're watching cartoons or anime or other things, where this will totally look processed and completely unnatural. I have not found a sample that doesn't exhibit the heavy ringing. If you zoom into your source (PotPlayer can do that natively, so madVR does all the rendering here) it's hard to miss it. It's everywhere.

And like I already explained, I can also see that the diagonal lines will get brightened up a bit, but that's because of the compression artefacts that get amplified by using higher strength values. The squirrel is however completely unnaffected by this, without all of the heavy ringing. And for me, real images are always more important than diagonal lines. In real images, the tiny amount of brightening is not noticable at all. At least not in the shots I saw, including the ones that you kindly provided.

I am pretty sure that 6233638 and cyberbeing would also love to have a say in this, but sadly, both seem to be too time restricted or just not here atm. So please at least leave the LL option in place, so others still are able to test with before/after results.

Last edited by iSunrise; 15th June 2015 at 13:11.
iSunrise is offline   Reply With Quote
Old 15th June 2015, 13:03   #31080  |  Link
Meulen92
Registered User
 
Join Date: May 2014
Posts: 9
Quote:
Originally Posted by RyuzakiL View Post
Workaround for AMD Crossfire Users >>

Since the stupid AMD Catalyst always mistake Madvr as a game, ergo Crossfire is always turned on whenever it detects Madvr.

Now i found a simple work around to prevent AMD Catalyst to not use Crossfire when it detects Madvr. Here's the procedure.

Just open your AMD CCC and head on to "My Digital Flat-Panels Tab" and put a Check to "Enable GPU up-scaling" ofcourse put the dot on "scale image to full panel size" and voila! no more crossfire on Madvr yehey!

advantages:

1. No more power wasting due to Crossfire (we already know that madvr will not benefit on using crossfire)

2. In some way performance will be better since crossfire is not enabled (maybe because no more mirroring of data between gpu's)

disadvantages:

1. Madvr Display Mode Switching will not gonna work any longer, I don't know why but it seems using the said work around will bypass Madvr's Display Mode Switching.

2. It may in some way interfere with madvr's handling of things, especially when using DX11 FSE 10bit queues aren't full when using this work around. So you are stuck on using DX11 Windowed Fullscreen 8bit.

So in the end it's up to you.

If you want DX11 FSE 10bit running smoothly with crossfire wasting energy then do not use this work around.

But if you want to save electricity and make the 2nd card enter powersave then use this workaround.

FYI i cannot discern any difference at all using DX11 FSE 10bit vs. DX11 WF (Windowed Fullscreen) 8bit. That's why i'm using this setup.


Any corrections, objections and violent reactions are welcome.

P.S you need to use Madvr Smooth Motion since you are stuck on 60hz when using this workaround.
AFAIK you could just create a custom game profile in CCC for Madvr, then scroll all the way down and select Disabled as Crossfire mode. Enjoy regular MadVR use without crossfire and without restricting your options.

Last edited by Meulen92; 15th June 2015 at 13:22.
Meulen92 is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling


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 22:44.


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