FineSharp converted to shaders, for MPC-HC + madVR, or MPDN - V1.11

[Neet009]

Originally Posted by -Vit-

One of those days... Link in the OP fixed.

Thank you for updating.　It works well now.

[-Vit-]

Originally Posted by fairchild

I can't seem to get any sharpening to work/be noticeable to my eyes with latest 1.7.7 MPC-HC using the CTRL+Y toggle which basically just toggles through all the different shader presets. I have the default set to no shaders, then I have one setup/labeled as FineSharp which has the order as detailed in first post for pre-size (figured this one would be the best to use to not over sharpen)

Ctrl+Y - that does nothing by default, did you add it manually to the options? If not, then select with right-click>>Shaders..., or edit the keys in the options.

I finally noticed the Next Shader Preset and Prev Shader Preset option far down the list in Options>>Player>>Keys in the recent version. I didn't know about that, can finally upgrade, lol.

Works fine for me. Maybe you're expecting a stronger result, or a different look. Try pre and post resize together, or set sstr=4.0 and cstr=1.19 in FineSharpA, which is about as far as I would take things.

[fairchild]

Originally Posted by -Vit-

Ctrl+Y - that does nothing by default, did you add it manually to the options?

But I finally noticed the Next Shader Preset and Prev Shader Preset option far down the list in Options>>Player>>Keys in the recent version. I didn't know about that, can finally upgrade, lol.

Works fine for me. Maybe you're expecting a stronger result, or a different look. Try changing sstr=4.0 and cstr=1.19 in FineSharpA, which is as far as I would take things.

It's working now, I guess 1.11 did the trick. I see a clear difference now when doing CTRL+Y from my default of no shader preset, to the pre-size one. So I guess to obtain the mildest sharpening using it as a post-resize shader would be the best.

[-Vit-]

That's up to your eyes. And depends on how clean your source is and the amount of upscale you are doing. And the size of your screen I suppose.

In general (upscaling) pre-resize is light, post is stronger, both together is strongest. The default sstr is sensible but can go down to 0.5 or up to about 4.0, with cstr changed to match. You can set a different sstr/cstr for the pre- and post- resize step (make two FineSharpA files) when using both together.

The stronger you apply this filter, the more it will pull out really faint detail, but then the more likely you will see grain like artefacts, especially around detail and edges, and also some fine bright halos. How much you can live with that determines the settings to use.

[madshi]

Originally Posted by -Vit-

I guess you should give me a list of scripts that need HLSL versions. No promises, but on the rare occasions that I get some time I can have a look.

Oh, that would be just wonderful!!!!! I don't expect anything, but if you do find a bit of time at some point in the future, I'd be very happy. Here are my wishes, but to be honest, I don't know how much work converting any of these scripts would cost. Some might be too much work. Some might be relatively easy. I'd be very happy about any of them:

(1) A good general purpose de-noising shader. Ideal would be an algorithm which works reasonably well with the majority of content without needing content specific tweaks (other than a simple "denoise strength" slider). After a quick search maybe FluxSmoothST would be a good choice. Other alternatives might be SMDegain or MCTemporalDenoise.

(2) A basic version of QTGMC (or even TempGaussMC). I wouldn't need all the hoops and hopplas, just the most important core functionality. I could live with losing a few percent of quality by skipping some complicated/difficult algorithms. You could use bicubic interpolation instead of NNEDI3. I could then optionally replace that with NNEDI3 in madVR. But I suppose doing the motion estimation could be problematic in HLSL? Maybe OpenCL or DirectCompute would be more suitable for that?

(3) DeHalo_alpha.

(4) LimitedSharpenFaster.

(5) aWarpSharp2.

(6) Maybe just the part of QTGMC which removes the grain, scales it separately (or replaces it with noise with the same local properties) and later puts it back in. This would help making debanding work better for grainy sources.

BTW, if I allowed your shaders to access to a compute language, would you prefer DirectCompute or OpenCL? If you have no preferences, I might prefer DirectCompute because driver support from the various GPU manufacturers seems to be better, and because it's the same HLSL language, once again.

[-Vit-]

Originally Posted by madshi

Here are my wishes...

All of these will need intermediate textures. I could only do finesharp because it only needed one intermediate value at a time and only the luma, so I could use the alpha. Rarely that simple

(2) - QTGMC in shaders . Well, basic TGMC is pretty short, but needs MVTools2. Has that been converted to GPU yet? Doable with compute shaders but would take more time than I have.

(1) - SMDegain is just a indirect way of using MVTools. So same point as above. MCTemporalDenoise is pretty huge if I recall (and uses MVTools). FluxSmooth is a C(++) plugin, not a script - it's method is the simplest, so probably the most approachable.

(3),(4) dehalo, LSF - need intermediate textures but otherwise very doable.

(5) aWarpSharp. Another C++ plugin. Not looked at it so I don't know the algorithm.

(6) QTGMC noise pathway. Once you have (1), then storing and adding the noise back later is simple. So this is about rescaling noise. Fairly straightforward this one, but whether it will be effective for general rescaling I don't know. More complex if you think about interlaced sources. It's better to denoise prior to deinterlacing then add it back full frame.

DirectCompute or OpenCL is OK. I prefer DirectCompute.

[madshi]

Originally Posted by -Vit-

All of these will need intermediate textures. I could only do finesharp because it only needed one intermediate value at a time and only the luma, so I could use the alpha. Rarely that simple

Makes sense. I'll move the extended shader support up in my to do list, with intermediate textures, maybe DirectCompute etc.

Originally Posted by -Vit-

(2) - QTGMC in shaders . Well, basic TGMC is pretty short, but needs MVTools2. Has that been converted to GPU yet? Doable with compute shaders but would take more time than I have.

AFAIK MVTools2 has not been converted to GPU yet, unfortunately. Maybe I'll put that on my to do list. Do QTGMC, SMDegrain, MCTemporalDenoise etc just use a subset of MVTools2? Or would all of MVTools2 have to be converted to GPU?

Originally Posted by -Vit-

(6) QTGMC noise pathway. Once you have (1), then storing and adding the noise back later is simple. So this is about rescaling noise. Fairly straightforward this one, but whether it will be effective for general rescaling I don't know. More complex if you think about interlaced sources. It's better to denoise prior to deinterlacing then add it back full frame.

Interesting. I didn't think about doing noise reduction before deinterlacing and later putting it back to the full frame. Makes sense, though. In any case, having this work just for progressive sources would already be a good start. Extending it for interlaced sources later should then not be such a big problem.

[kasper93]

Originally Posted by -Vit-

but that's doesn't have shortcut keys for shaders, which makes using them annoying.

You can make preset with shader and toggle through them with hotkeys.

[BetA13]

tiny question?!?!?!

"Attachments Pending Approval
File Type: zip finesharp_shaders_1.11.zip"

why does this approval take so loong.. its been over 3 days now? isnt it??!?!?!

i wanna test this new version, hehe..

gretez

[Shiandow]

The first post also contains this link, just below the caption "installation".

[BetA13]

Originally Posted by Shiandow

The first post also contains this link, just below the caption "installation".

i didnt saw it as link, haha...

much apprechiated..

[RainyDog]

Thanks very much for this -Vit-.

I've been happily using lumasharpen from the CeeJay's SweetFX shaders for the past few months. Can any of you technical fellows explain the main difference between that and FineSharp please?

[TheElix]

Did anyone try combining this shader with ffdshow's unsharp mask (or with Darbee)?

[kasper93]

Originally Posted by -Vit-

It was written for madVR (need the 16-bit accuracy in the shader chain), but also works in MPDN.

We can also enable full/half floating point processing in EVR-CP. And it works just fine with this package.

[feelingblue]

Originally Posted by TheElix

Did anyone try combining this shader with ffdshow's unsharp mask (or with Darbee)?

I have HTPC and darbee as external video preocessor.
I also have the DVD iscan mini.

I have done a lot of test but.. finesharp is is made to be used alone, without other PP.
Best PQ is with FS alone, the only other PP that is acceptable is Unsharp mask used after fine sharp.

The worst of all group is Darbee.
I don't like it. the immage become unnatural, overprocessed and to countered

[shaolin95]

Originally Posted by feelingblue

I have HTPC and darbee as external video preocessor.
I also have the DVD iscan mini.

I have done a lot of test but.. finesharp is is made to be used alone, without other PP.
Best PQ is with FS alone, the only other PP that is acceptable is Unsharp mask used after fine sharp.

The worst of all group is Darbee.
I don't like it. the immage become unnatural, overprocessed and to countered

Thanks for the beedback on Darbee. Some people at avsforum swear by it but I had my doubts though I never have seen it

[kasper93]

New madVR v0.87.15 added option, which is enabled by default:

* new trade option "lose BTB and WTW if it improves performance"

You need to disable this option in order to make this shader pack work. I figured I tell you now to avoid questions later

[madshi]

Thanks for the heads-up, kasper93, that's good to know.

[madshi]

FWIW, I'd suggest to modify the ToYUV und ToRGB shaders slightly like this:

ToYUV:

float3 yuv = mul( height<576 ? RGBtoYUV_601 : RGBtoYUV_709, Src(0,0).rgb ) + float3(0.0, 0.5, 0.5);

ToRGB:

float4 o = Src(0,0) - float4(0.0, 0.5, 0.5, 0.0);

These changes simply move the chroma channels from the [-0.5..+0.5] range to the [0..1] range, which means that we don't have to use floating point textures, anymore.

[Zachs]

Yes this change would be necessary for MPDN's UNORM (which is the default now) texture too.