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 20th July 2015, 02:59   #31961  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by ryrynz View Post
He sees things us mere mortals cannot.
I guess tFWo hit the nail for me but nice try buddy, I didn't care enough to bother trying that's all...especially when strength 1 is already so darn sharp with HQ off making screenshots comparisons most shaky.

I mean how anyone could prefer HQ enabled is already beyond my comprehension and I'm running a Sammy LED LCD TV, the biggest sales on the market by far AFAIK. It doesn't take a screenshot for either me or tFWo to see that we hate HQ, but maybe he also has supervision I'll give you that
leeperry is offline   Reply With Quote
Old 20th July 2015, 04:19   #31962  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by madshi View Post
madVR v0.88.20 released

Code:
* changed OSD rendering logic all over again
Everyone who had *new* problems, introduced by v0.88.17, please test this new build and let me know if your problems are fixed.
Sorry, problem still exists.
Testing with full power (P0 state) to avoid misinterpretation of the stuttering,
D3D11, FSE, still has unreported stuttering, Only in FSE.
All other modes are OK.

Overlay is fixed in this one.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.
James Freeman is offline   Reply With Quote
Old 20th July 2015, 05:02   #31963  |  Link
Akeno
Registered User
 
Join Date: Jul 2015
Location: Seattle, Washington
Posts: 53
Quote:
Originally Posted by leeperry View Post
I guess tFWo hit the nail for me but nice try buddy, I didn't care enough to bother trying that's all...especially when strength 1 is already so darn sharp with HQ off making screenshots comparisons most shaky.

I mean how anyone could prefer HQ enabled is already beyond my comprehension and I'm running a Sammy LED LCD TV, the biggest sales on the market by far AFAIK. It doesn't take a screenshot for either me or tFWo to see that we hate HQ, but maybe he also has supervision I'll give you that
Offtopic: You seem to have a problem understanding that people have different preferences than you. You've failed to provide any evidence to justify your claims and madashi still gave you the option to disable HQ. Don't just piggyback on tFWo's work while acting superior about it.

Ontopic: Are their any benefits to using madVR x64 over x32? ReClock doesn't have an x64 version but I'm starting to seriously wonder if I'm just wasting resources as I don't use the media speedup/down option and I'm satisfied with just feeding audio through DirectSound.
Akeno is offline   Reply With Quote
Old 20th July 2015, 05:11   #31964  |  Link
ryrynz
Registered User
 
ryrynz's Avatar
 
Join Date: Mar 2009
Posts: 3,646
Quote:
Originally Posted by Akeno View Post
Offtopic: You seem to have a problem understanding that people have different preferences than you. You've failed to provide any evidence to justify your claims and madashi still gave you the option to disable HQ. Don't just piggyback on tFWo's work while acting superior about it.
If it's import enough to him he'll make the effort. He's certainly aware he has special preferences. Madshi deals with the requests appropriately so don't worry about it.

Quote:
Originally Posted by Akeno View Post
Ontopic: Are their any benefits to using madVR x64 over x32? ReClock doesn't have an x64 version but I'm starting to seriously wonder if I'm just wasting resources as I don't use the media speedup/down option and I'm satisfied with just feeding audio through DirectSound.
There are benefits on the performance side of things. If you're potentially ditching reclock and have no other 32 bit filters active then definitely move to 64 bit.
ryrynz is offline   Reply With Quote
Old 20th July 2015, 06:43   #31965  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Got a new display and trying to create a 3DLUT using madTPG + dispcalGUI + Argyll.

Have a problem here.....
First, I run madTPG with 'stay on top' + 'use fullscreen + disable videluts + disable 3dluts.
I specifically make sure the 'Image Area' slider is moved to the right max 100%. (So that the tiny gray box is way larger.) 'Background' slider is moved to left max 1%.


Then, I run dispcalGUI and set up stuff normally, finally click 'calibrate and profile'.

madTPG finally runs its pattern in full screen.....but the color square patches is way too small in the middle of screen? I thought I already set the image area slider to max size? Is this a known bug?

EDIT: there is 'ArgyllCMS Patches' being displayed at top left corner of the screen. The patches are very small and I noticed the 'image area' slider being reset back to 1%

EDIT2 : each time madTPG loads new batch of patches from displaygui, the 'image area' slider being reset to 1%

EDIT3 : Any idea to keep the 'image area' from being reset?

EDIT4 : Found this -P0.5,0.5,10,10 argument for dispcal, but after 3rd or 4th batch of patches, it resets back to 1% again.

Last edited by JohnLai; 20th July 2015 at 08:35.
JohnLai is offline   Reply With Quote
Old 20th July 2015, 07:37   #31966  |  Link
Siso
Soul Seeker
 
Siso's Avatar
 
Join Date: Sep 2013
Posts: 711
Quote:
Originally Posted by Akeno View Post
New bug with the 88.20. Seems like the OSD is reporting incorrect render times. Render time is lower than what it was in previous updates with the exact same settings (I'm not using SuperRes). It reports even lower render times when I go from NNEDI3 16 -> 32 but the dropped frames and presentation glitches counter begin to rise.
+1 for the incorrect render times, seems overlay mode is fixed tho
Siso is offline   Reply With Quote
Old 20th July 2015, 09:31   #31967  |  Link
sneaker_ger
Registered User
 
Join Date: Dec 2002
Posts: 5,565
My back-forth jumping problems in window mode (old path) appear to be fixed by v0.88.20.
sneaker_ger is offline   Reply With Quote
Old 20th July 2015, 14:01   #31968  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Akeno View Post
New bug with the 88.20. Seems like the OSD is reporting incorrect render times. Render time is lower than what it was in previous updates with the exact same settings (I'm not using SuperRes). It reports even lower render times when I go from NNEDI3 16 -> 32 but the dropped frames and presentation glitches counter begin to rise.
Ok, will have a look at that.

Quote:
Originally Posted by leeperry View Post
I also came to the conclusion this afternoon that sxbr+AS seem to look equally good(or even better?) than SR in .15 with 3@0.42
If you remember, I actually told you that you should try AdaptiveSharpen if you liked the look of LQ SuperRes, because AdaptiveSharpen and LQ SuperRes have a similar look. But then you replied with:

> I'm not interested in running another sharpening filter
> on top but thanks for the advice

Quote:
Originally Posted by leeperry View Post
My point is that for all I know screenshots wouldn't prove anything and I would waste hours looking at microscopic pixels differences.
Different sharpening algorithms and HQ vs LQ SuperRes produce quite noticable differences, if you use a sharp image for testing. Easy to see in screenshots for everybody.

Quote:
Originally Posted by Ver Greeneyes View Post
madshi, I took debug logs for the 'repeated frames show very old frames' thing, comparing d3d9 and d3d11 windowed mode, though I don't know if they show anything. Just let me know when you have time to look at them.
I'll let you know.

Quote:
Originally Posted by tFWo View Post
I'm off on vacation for next two weeks so I'm doing this at the last moment before going.

original
http://www84.zippyshare.com/v/CDsDqi9P/file.html

hq strength 1 radius 0.70
http://abload.de/img/seventhhqjpjxy.png

nohq strength 1 radius 0.70
http://abload.de/img/seventhnohqaejzk.png

It's hard to compare because strength 1 for nohq is too strong.

As I said radius does help. But HQ still has that almost softer than original look with slight ringing around numbers. White is spilled into black area, black is spilled into white area.

NoHQ doesn't have that problem even on higher strengths. But as I said even strength 1 is too strong for my taste.
Yeah, thanks for the screenshots. One problem with such screenshots is that we don't really know what to shoot for. How *should* the image really look like? Ideally we would have a high resolution version of the same image, so we can double check which of the upscaling algos and sharpening/post-processing algos comes nearest to the high res version. Since we don't have that, judging which image looks better is highly subjective. I can see that the LQ (= noHQ) version looks noticeably sharper, but also introduces the typical "sharpened" look, like Unsharp Masking, AdaptiveSharpen, LumaSharpen etc do. Which is a look I don't like.

Quote:
Originally Posted by Deim0s View Post
I have problems with builds after 0.88.16.
Examples and dump below:
OSD (SD MPEG-2)
dump

OSD (720p - presentation glitches when step forward/backward)
dump

Win 7 SP1 Pro x64
ASUS GTX770 2Gb
ASUS VG278H 120 Hz
MPC-HC x64 latest nightly build
LAV x64 latest nightly build
Does that still occur with v0.88.20?

Quote:
Originally Posted by jewshawn2 View Post
I am reporting a bug that was introduced since v0.88.17.

In order for OBS (Open Broadcaster Software) to capture video in Potplayer with madVR, you have to use "Game Capture" source. I was told by someone on the OBS forum that this uses OpenGL to capture video. And it is the only method to capture video with madVR as the renderer.

Since v0.88.17 video capture using OBS (both versions) and Potplayer causes unwatchable jittery/stuttering video. The video looks perfectly fine on screen. But the OBS capture window shows jittery video. v0.88.16 was the last release that worked fine.

The bug can be reproduce on both of my PCs using the default madVR settings and default PotPlayer settings. However, if I use a different video player like MPC-HC x64 or bsplayer with madVR the video capture in OBS is fine. But when I adjust volume level the OSD causes stuttering video in the capture window.

I don't expect this bug report to get a lot of attention since it's very specific but I still wanted to report it for documentation purposes. I hope other forums members can reproduce the bug and verify my claims.

These were the changes introduced to madVR, perhaps one of these changes broke functionality between madVR, Potplayer, and OBS:
v0.88.17
* madVR now renders in paused and stopped mode, too
* added automatic OSD low latency logic
* added SuperRes anti-ringing filter
* fixed little SuperRes quality detoriation introduced in v0.88.16
* fixed: high GPU consumption in paused mode (PotPlayer, Kodi DSPlayer)
* all (useful) IVideoWindow APIs now work even when no pins are connected

My setup:

madVR v0.88.17 thru v0.88.20

x64 bit Potplayer [1.6.55124] 2015/07/10

x64 OBS Multiplatform 0.11.1

x64 OBS Original 0.652b

x64 Win 7 / Nvidia 8800 GTS
I see. I think this is likely to be a bug in OBS. But maybe I can find a solution, nevertheless.

Quote:
Originally Posted by James Freeman View Post
Sorry, problem still exists.
Testing with full power (P0 state) to avoid misinterpretation of the stuttering,
D3D11, FSE, still has unreported stuttering, Only in FSE.
All other modes are OK.
Ok.

Quote:
Originally Posted by JohnLai View Post
Got a new display and trying to create a 3DLUT using madTPG + dispcalGUI + Argyll.

Have a problem here.....
First, I run madTPG with 'stay on top' + 'use fullscreen + disable videluts + disable 3dluts.
I specifically make sure the 'Image Area' slider is moved to the right max 100%. (So that the tiny gray box is way larger.) 'Background' slider is moved to left max 1%.


Then, I run dispcalGUI and set up stuff normally, finally click 'calibrate and profile'.

madTPG finally runs its pattern in full screen.....but the color square patches is way too small in the middle of screen? I thought I already set the image area slider to max size? Is this a known bug?

EDIT: there is 'ArgyllCMS Patches' being displayed at top left corner of the screen. The patches are very small and I noticed the 'image area' slider being reset back to 1%

EDIT2 : each time madTPG loads new batch of patches from displaygui, the 'image area' slider being reset to 1%

EDIT3 : Any idea to keep the 'image area' from being reset?

EDIT4 : Found this -P0.5,0.5,10,10 argument for dispcal, but after 3rd or 4th batch of patches, it resets back to 1% again.
madTPG has APIs that allow the calibration software to control all aspects of madTPG. It seems that ArgyllCMS/dispcal overwrite the "image area" choice you've made in the madTPG GUI. There's nothing I can do about that. You would have to talk to the ArgyllCMS/dispcal developers. I'm sorry, I wish I could be more helpful. But if the calibration software uses the APIs then I must obey. Otherwise the APIs would serve no purpose.

Generally, for ArgyllCMS/dispcal related topics, your best thread for support is this one:

http://www.avsforum.com/forum/139-di...argyllcms.html

Quote:
Originally Posted by sneaker_ger View Post
My back-forth jumping problems in window mode (old path) appear to be fixed by v0.88.20.
Cool, at least some good news.
madshi is offline   Reply With Quote
Old 20th July 2015, 14:17   #31969  |  Link
ashlar42
Registered User
 
Join Date: Jun 2007
Posts: 652
Hi madshi, thanks for all the incredible work you offer for free to us all.

Do you have an ETA of sort (asking about months time range, not specific dates) for rendering subtitles on black bars? I love madVR quality but yesterday, while watching a 2:35 movie I really missed the opportunity to shift the subs where they wouldn't bother the picture.

Thanks.
ashlar42 is offline   Reply With Quote
Old 20th July 2015, 14:18   #31970  |  Link
JohnLai
Registered User
 
Join Date: Mar 2008
Posts: 448
Quote:
Originally Posted by madshi View Post

madTPG has APIs that allow the calibration software to control all aspects of madTPG. It seems that ArgyllCMS/dispcal overwrite the "image area" choice you've made in the madTPG GUI. There's nothing I can do about that. You would have to talk to the ArgyllCMS/dispcal developers. I'm sorry, I wish I could be more helpful. But if the calibration software uses the APIs then I must obey. Otherwise the APIs would serve no purpose.

Generally, for ArgyllCMS/dispcal related topics, your best thread for support is this one:

http://www.avsforum.com/forum/139-di...argyllcms.html
When 'use fullscreen' of madtpg is disabled, the 'image area' slider doesn't get reset at all.

This is weird....
I was able to finish calibration on 3 monitors without the 'image area' getting reset to 1% if the madtpg 'use fullscreen' is disabled.
JohnLai is offline   Reply With Quote
Old 20th July 2015, 14:45   #31971  |  Link
baii
Registered User
 
Join Date: Dec 2011
Posts: 180
Quote:
Originally Posted by ashlar42 View Post
Hi madshi, thanks for all the incredible work you offer for free to us all.

Do you have an ETA of sort (asking about months time range, not specific dates) for rendering subtitles on black bars? I love madVR quality but yesterday, while watching a 2:35 movie I really missed the opportunity to shift the subs where they wouldn't bother the picture.

Thanks.
Use mpc-hc build in sub renderer(or renderer other than xysub filter) as a current work around. It don't have all the fancy feature though ~
baii is offline   Reply With Quote
Old 20th July 2015, 15:17   #31972  |  Link
XMonarchY
Guest
 
Posts: n/a
I am confused about SR HQ settings. Which SR settings are considered HQ for both Chroma Upscaling and Upscaling Refinement? At the moment, I set Chroma Upscaling SR to passes = 4, strength = 1, softness = 0, then I set Upscaling Refinement SR to strength = 1 and radious = 0.66. Are the SR settings I just listed using considered HQ? I do not use any sharpening through madVR because I am kind of forced to use TV's slight sharpening, considering my setup.
  Reply With Quote
Old 20th July 2015, 16:22   #31973  |  Link
Deim0s
Registered User
 
Join Date: Jul 2012
Posts: 20
Quote:
Originally Posted by madshi View Post
Does that still occur with v0.88.20?
Yes. In v0.88.20, performance is even worse than *18, *19.
Deim0s is offline   Reply With Quote
Old 20th July 2015, 17:00   #31974  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by madshi View Post
If you remember, I actually told you that you should try AdaptiveSharpen if you liked the look of LQ SuperRes, because AdaptiveSharpen and LQ SuperRes have a similar look. But then you replied with:

> I'm not interested in running another sharpening filter
> on top but thanks for the advice

Different sharpening algorithms and HQ vs LQ SuperRes produce quite noticable differences, if you use a sharp image for testing. Easy to see in screenshots for everybody.
You're completely right, I assumed that SR was using the same kind of revolutionary CSI-like techniques as what intelligence agencies use or what nvidia got CUDA accelerated a while ago: http://www.motiondsp.com/products/IkenaForensic
Quote:
reconstruct the characters on a license plate using Ikena’s super-resolution (which combines the best information from multiple frames of video)
Then I assumed that SR in mVR was using the implementation Shiandow explained but you then told me that it wasn't, so at this point I do not know what SR in mVR *really* does.....and in the end sxbr+AS would very much appear to fit my needs as well....still need to run more tests on that, though.

I also thought that you meant I should use AS together with SR and I certainly don't see it working, especially in HQ mode as 1 is utterly oversharp in LQ and I hate the look of HQ as much as you seemingly hate LQ.....Also, two seperate knobs for the number of passes and strength are very much required IMO but you're the boss and what matters is your own satisfaction.

Quote:
Originally Posted by madshi View Post
Yeah, thanks for the screenshots. One problem with such screenshots is that we don't really know what to shoot for. How *should* the image really look like?
Exactly what I feared and at the end of the day it might very well be purely subjective and/or display-dependent, but that doesn't change anything to the fact that 1 was way oversharpened and completely unusable in LQ mode using .19.

Quote:
Originally Posted by ashlar42 View Post
rendering subtitles on black bars?
PotP does it, using keyboards shortcuts at that and it also has an option to do it automatically.

Last edited by leeperry; 20th July 2015 at 19:35.
leeperry is offline   Reply With Quote
Old 20th July 2015, 17:07   #31975  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
I apologize for the intrusive question but, how important is this new OSD speed up anyway?
Seems to do more harm than good...
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.

Last edited by James Freeman; 20th July 2015 at 17:10.
James Freeman is offline   Reply With Quote
Old 20th July 2015, 21:18   #31976  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by ashlar42 View Post
Do you have an ETA of sort (asking about months time range, not specific dates) for rendering subtitles on black bars?
I do not give ETAs, sorry. I'm a CIH user myself, though, so can be rest assured that I'd like to see that feature myself.

Quote:
Originally Posted by JohnLai View Post
When 'use fullscreen' of madtpg is disabled, the 'image area' slider doesn't get reset at all.

This is weird....
I was able to finish calibration on 3 monitors without the 'image area' getting reset to 1% if the madtpg 'use fullscreen' is disabled.
Well, as I said, I don't know which madTPG APIs ArgyllCMS is calling, so it's hard for me to comment on any of this. And as I said, your best hope for getting useful feedback about ArgyllCMS related topics is that AvsForum thread I linked.

Quote:
Originally Posted by XMonarchY View Post
I am confused about SR HQ settings. Which SR settings are considered HQ for both Chroma Upscaling and Upscaling Refinement? At the moment, I set Chroma Upscaling SR to passes = 4, strength = 1, softness = 0, then I set Upscaling Refinement SR to strength = 1 and radious = 0.66. Are the SR settings I just listed using considered HQ? I do not use any sharpening through madVR because I am kind of forced to use TV's slight sharpening, considering my setup.
SuperRes for chroma upscaling is not up-to-date, and not up for "discussion" yet. SuperRes for upscaling refinement is always HQ now. You can just change the strength (usually the more the better, but more also costs more GPU power). Don't change the radius unless you know what you're doing.

Quote:
Originally Posted by Deim0s View Post
Yes. In v0.88.20, performance is even worse than *18, *19.
Oh dear...

Quote:
Originally Posted by leeperry View Post
Exactly what I feared and at the end of the day it might very well be purely subjective and/or display-dependent, but that doesn't change anything to the fact that 1 was way oversharpened and completely unusable in LQ mode using .19.
The reason for that is that LQ mode sucks. Big time. But more about that (and the scientific background) in my next post (just writing it).

Quote:
Originally Posted by James Freeman View Post
I apologize for the intrusive question but, how important is this new OSD speed up anyway?
Very important. More important for some media players than others, though.

Quote:
Originally Posted by James Freeman View Post
Sorry, problem still exists.
Testing with full power (P0 state) to avoid misinterpretation of the stuttering,
D3D11, FSE, still has unreported stuttering, Only in FSE.
All other modes are OK.
FWIW, can you try setting the flush setting for "after intermediate render steps" to "flush & wait (sleep)"? Does that help? Probably not, but it would be important to know for me.
madshi is offline   Reply With Quote
Old 20th July 2015, 21:51   #31977  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
I've decided to make a big screenshot comparison post to compare the different upscaling and sharpening / post-processing options we have now. In order to make all this more "scientific", I've decided that we need a "ground truth" image to compare to, because that's the only way to properly judge if an algorithm produces good results or not. If we don't have a ground truth to compare to, all our evaluations are somewhat subjective. So here comes:

GroundTruth -|- 50% downscaled

50% downscaled image (Catmull-Rom LL AR):


So what we're going to do is take the 50% downscaled image, scale it back up, sharpen / post process it, and then we compare to the original ground truth. This way we can objective judge which upscaling algorithm and which post-processing produces the best results, by getting nearest to the original ground truth image.

I've selected this specific image because it contains both small and big geometical features (windows, roofs, etc), and a lot of nature (trees etc). So it's a good image to showcase different weaknesses of the various algorithms.

Let's start with comparing different scaling algorithms without any post-processing:

Bilinear -|- Catmull-Rom -|- Lanczos4 -|- Jinc -|- super-xbr -|- NNEDI3 -|- GroundTruth

Obviously, Bilinear is very bad. It's soft and has aliasing. Catmull-Rom is better, but still has some aliasing and it's still softer than the other algos. Jinc and Lanczos4 are somewhat comparable. Lanczos4 is a bit sharper, but Jinc has a bit less aliasing, so no clear winner between these two, I guess. super-xbr is sharper and has less aliasing than either of these, but the trees look less natural compared to Lanczos4 or Jinc. E.g. look at the tree which covers the bottom left of the castle. It looks more like an oil painting in the super-xbr image. NNEDI3 wins by a mile, I would say. It's more focused and has less artifacts than super-xbr. Trees are ok, not as oily as in the super-xbr image. I used 256 neurons in this comparison, though, which is probably not fair. Anyway...

Next step, let's compare different sharpening/post-processing algorithms, applied via Upscaling Refinement after image doubling with NNEDI3-256:

NNEDI3 -|- NNEDI3+AdaptiveSharpen(0.8) -|- NNEDI3+FineSharp(4.0) -|- NNEDI3+SuperRes(4) -|- GroundTruth

To my eyes FineSharp comes nearest to the ground truth here. FineSharp manages to increase the perceived detail level and to make the image appear sharper, without making it look artificial. On the other hand, it also sharpens the heck out of any artifacts that might be in the original source or produced by the scaling algorithm. NNEDI3 did make some mistakes, and FineSharp gladly makes them even more obvious. SuperRes is near to FineSharp in detail level and sharpness, but at the same time manages to hide all artifacts caused by NNEDI3. So SuperRes is not only a good sharpener, but also manages to repair errors of the upscaling algorithm. AdaptiveSharpen also manages to sharpen the image (of course), but IMHO it moves the image further away from the original image, instead of bringing it nearer. E.g. the trees seem to lose detail when using AdaptiveSharpen, which is pretty bad.

Now let's make the same comparison, but using super-xbr instead of NNEDI3:

super-xbr -|- super-xbr+AdaptiveSharpen(0.8) -|- super-xbr+FineSharp(4.0) -|- super-xbr+SuperRes(4) -|- GroundTruth

Again FineSharp and SuperRes produce a similar look, but FineSharp here mercilessly puts our nose on every small problem super-xbr might have with this image, making directional interpolation artifacts stand out like a sore thumb. AdaptiveSharpen is a bit more forgiving, but again, it reduces perceived details in the trees and moves the overall image look away from the ground truth. SuperRes clearly wins here. It moves the image nearer to the ground truth, and at the same time fixes (or at least improves) many of the super-xbr artifacts.

So my judgement so far would be that SuperRes is the best post-processing algorithm, which brings the upscaled image nearer to the ground truth, and at the same time repairs some of the errors introduced by the (different) weaknesses of the upscaling algorithms. Based on that, here's another comparison, comparing different upscaling algorithms, followed by SuperRes:

Bilinear+SuperRes -|- Jinc+SuperRes -|- super-xbr+SuperRes -|- NNEDI3+SuperRes -|- GroundTruth

What we can see here is that SuperRes works well even when using Bilinear upscaling. However, SuperRes does *not* remove aliasing artifacts caused by the upscaling algorithm. E.g. look at the roof edges of the left two towers. Both Bilinear and Jinc have aliasing problems there. super-xbr and NNEDI3 have not. Because of this reason, my recommendation would be to use either super-xbr or NNEDI3, followed by SuperRes, for best image quality. The difference between super-xbr and NNEDI3 is pretty small, if you follow it up with SuperRes with high strength. So using super-xbr should save some precious GPU performance. Using Jinc+SuperRes might be an option, too, but you'll likely get more aliasing problems compared to super-xbr+SuperRes.

-------

Finally, let's talk about HQ vs LQ SuperRes. In v0.88.15 there was an option to use HQ downscaling or not. Newer versions hard coded this to use HQ downscaling. But some users still prefer having HQ downscaling disabled. So let's compare HQ vs noHQ (= LQ) SuperRes:

super-xbr -|- super-xbr+SuperRes(HQ) -|- super-xbr+SuperRes(HQ)+AdaptiveSharpen -|- super-xbr+SuperRes(LQ) -|- GroundTruth

What you can see here is that SuperRes HQ brings the super-xbr upscaled image much nearer to the ground truth. Obviously some details must be lost through the 50% downscaling + upscaling process, but the overall look of the image is very very near to the ground truth. Compare to that super-xbr+SuperRes(LQ). It looks terrible in comparison, IMHO. It actually moves the super-xbr upscaled image *away* from the ground truth. But for users who (for some reason that I don't understand) prefer the SuperRes(LQ) look, you can get it with v0.88.20, too, by using SuperRes(HQ) and adding some AdaptiveSharpen on top. The end result is near to SuperRes(LQ), but with a better quality. SuperRes(HQ)+AdaptiveSharpen has a similar look for SuperRes(LQ), but with less artifacts and a more natural looking image. It's still far away from the ground truth, though, so I don't recommend using it.

Now I guess the SuperRes(LQ) prefering users will argue that the strength I used for SuperRes(LQ) was *way* too high (I've actually used strength 4, which means 8 passes with the old strength value of 1.0). However, argueing that the strength was too high is beside the point. Why? Let me explain:

SuperRes is by design an iterative algorithm. Which means that it's designed in such a way that we're *supposed* to run multiple passes of the algorithm. The first pass does a lot of changes, the 2nd pass still does some, but less. Every further pass still changes something, but the amount of changes gets less with every further pass. At some point, after running "X" passes, the image will be fully converged into the "final SuperRes" image, and running any more passes will not change anything, anymore. Most of these iterative algorithms ideally aim to be run with as many passes as needed to get to the converged image. We're usually supposed to execute one pass after the other, until there are no further changes done to the image.

So if we want to test if the SuperRes algorithm is any good, ideally we should run a million passes, to get to the fully converged SuperRes image. And then we can judge if we like that final image or not. The LQ vs HQ screenshots above are not fully converged, but they're probably 90% there. So they do allow us to judge whether we like the direction into which SuperRes is going. I think most of us will agree that the direction LQ is going is away from the ground truth, while HQ is going nearer to the ground truth (at least with this specific test image).

With LQ, the users who prefer it are asking for lower strength and passes settings. Why? Because they don't like the look of the fully converged SuperRes LQ image themselves. Which is a clear indication that something is wrong. They like low strength settings because they don't like the full uglyness of the fully converged SuperRes LQ setting.

In contrast to that, using HQ brings us nearer to the ground truth, and there each added pass (with full strength) is actually beneficial. So when using HQ SuperRes, we can give users the simple recommendation to use as high a strength as their GPU power allows. The more the better.

-------

Let me finish by saying that all of the above is of course only *one* test image. Results could in theory vary with other test images. I would like to encourage anyone who is interested in this kind of comparisons to repeat the same tests I've done, with a different test image. But please make sure you have a ground truth to compare to, because only that allows us to objectively judge. Otherwise all we can say is subjective mumbo-jumbo, and every user will have different preferences.

-------

Comments welcome!
madshi is offline   Reply With Quote
Old 20th July 2015, 22:06   #31978  |  Link
Anima123
Registered User
 
Join Date: Jun 2005
Posts: 504
Would you suggest that SuperRes been used right after image-doubling and before final scaling to the target screen resolution, to get scientifically better image quality?

What kind harm can be if applying SuperRes after scaled to screen resolution, does it vary by the scaling algorithm used?

Edit: I understand the convergence you are talking about, but shouldn't the convergence rate be related to the strength SuperRes applied? I guess that's part of reason somebody prefer lower strength, more passes than the contrary. It also can explain why some people like the LQ version with lower strength.

Last edited by Anima123; 20th July 2015 at 22:10.
Anima123 is offline   Reply With Quote
Old 20th July 2015, 22:16   #31979  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
In my test I've downscaled 50% and then doubled image resolution to get back to 100%. So there was no further scaling needed after image doubling. I think this is the fairest test. Of course in real life you often need to scale to "odd" target resolutions. I would recommend to activate "refine the image only once after upscaling is complete", when using SuperRes. If image doubling is then followed by some more up- or downscaling, SuperRes will wait for all scaling operations to complete and only afterwards do its work on the fully scaled image. SuperRes does not really care much about whether it runs after image doubling, or after scaling to an "odd" target resolution. It works well in either case.

If you use a lower strength setting, you need more passes to get to the fully converged image. But the final result should be identical. leeperry believes that 3 passes with 0.65 strength looks better than 2 passes with 1.00 strength, but I call that a myth (I believe he sees what he expects to see, and not what is really there - sorry leeperry!), until it gets proven by screenshots.
madshi is offline   Reply With Quote
Old 20th July 2015, 22:50   #31980  |  Link
Akeno
Registered User
 
Join Date: Jul 2015
Location: Seattle, Washington
Posts: 53
Adaptive Sharpen: Seems pretty destructive when it comes to real life material. It works a lot better for anime material where there aren't as many fine details and is the most ideal image enhancer.

FineSharp: Feels unusable at this point due to the extreme artifacts it produces, although I suppose there would be no problem with a nearly 100% clean source.

LumaSharpen: I can't see a reason to use it personally. It just isn't as noticeable as the other algorithms but maybe my settings are wrong.

SuperRes: NNEDI3 and Super-XBR look damn near identical outside of a tiny artifacts in s-xbr. LQ is also extremely painful to look at. It looks oversharpened and looks slightly pixelated in the edges of the windows.

-----
My system can't run both NNEDI and SuperRes in tandem. My personal choice therefore depends on the material that I intend to watch. Anime material (and CG to a degree) suffers little from Adaptive Sharpen which does a number on live material. I was initially put off by s-xbr but it seems that SuperRes alleviates most of my worries.

On a side note, madshi, you recommend 32 Neurons as a minimum for luma doubling due to artifacts with 16. My system can't run 32 with 30fps material but I haven't noticed anything wrong with 16. Could you elaborate on what kind of artifacts there are or post some pictures?

Last edited by Akeno; 21st July 2015 at 04:45.
Akeno is offline   Reply With Quote
Reply

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

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:12.


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