View Single Post
Old 9th June 2015, 09:27   #30887  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Shiandow View Post
Well, SuperRes only removes the ringing afterwards, so enabling MadVR's anti ringing should have some effect. I suspect SuperRes will converge slightly faster if you use madVR's anti-ringing. The difference, if any, will be most visible when you use a low number of passes (which seems to be the popular choice).
Ok, thanks.

Quote:
Originally Posted by TheLion View Post
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.
Thanks. So for "image enhancements" you would suggest a strength of 2.0 for the "high" preset, using the default "thinning"? Have you played with the "thinning" a bit to find out whether you like it at its default value or slightly different maybe?

What would you suggest for medium and low presets?

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

Quote:
Originally Posted by baii View Post
finesharp (only mode 1, strength from .4- 1.0, repair default)

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

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

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

http://madshi.net/castleOrg.png

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

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

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

Quote:
Originally Posted by MysteryX View Post
madshi, did you remove the feature that displays the volume level when scrolling up and down with the mouse?
I've got nothing to do with such controls. Never had.

Quote:
Originally Posted by MysteryX View Post
I withdraw this.

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

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

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

Quote:
Originally Posted by SecurityBunny View Post
Version shows 0.88.9 when checking with this build. Queues unfortunately still do not fill with D3D11 and 10-bit output. D3D9 with 10-bit output, queues fill.

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

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

http://madshi.net/madVR64queueFix1.rar

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