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

[-Vit-]

This is the FineSharp avisynth script (http://forum.doom9.org/showthread.php?p=1569035#post1569035) by Didée converted to MPC-HC shaders. It was written for madVR (need the 16-bit accuracy in the shader chain), but also works in MPDN.

FineSharp is designed to sharpen clean HD sources. I find it gives a nice clarity boost to clean 720p material when upscaling to 1080p, and gives a modest boost to native 1080p material too. When upscaling it is very effective used together with NNEDI3 luma doubling, if your GPU has the power for that.
The sharpener makes no attempt to filter noise or source artefacts and will sharpen those too. So denoise/clean your source first if necessary. Probably won't work very well on a really old GPU, the weakest I have tried is a GTX 560 at 1080p 60fps with no problems.


Installation

Get zip from attachment below or download here (V1.11) (http://www.mediafire.com/download/7g82h7kisz8o6ou/finesharp_shaders_1.11.zip)

There are a collection of shaders in the attached zip file, import them all into MPC-HC. How to do that depends on the version of MPC-HC. In the older versions you paste the code into the shader editor, type a name and select ps_3_0. In the recent versions you can save all the shaders in a folder and add them all at once (Play->Shaders->Select Shaders...). Search the web for detailed instructions.

When you have imported the shaders they must be selected in the correct order (again check the web for details if you don't know how):

ToYUV
RemoveGrain11
RemoveGrain4
FineSharpA
FineSharpB
FineSharpC
ToRGB

You can select them as "pre-resize shaders" or "post-resize shaders", or both if you wish. In newer versions of MPC-HC, when you have selected your shaders type a preset name (e.g. "FineSharp - Pre-Resize") in the "Shader Presets" box and press "Save".

Pre-resize shaders have a stronger effect when upscaling (e.g. showing 720p on 1080p monitor), post-resize shaders are stronger when downscaling. Sharpening in both stages is too strong for my liking, but you could do this if you find the sharpening too delicate - this works best when NNEDI3 luma doubling is enabled.


Controls

In newer versions of MPC-HC, right click, and select Shaders>>Your Shader Preset to enable. You can also go to Options>>Player>>Keys, scroll down to find Next and Prev Shader Preset and assign a key there (a key combination that isn't used, like Ctrl+P or Ctrl+Y). In MPC-HC 1.70 and below, toggle pre-resize shaders with Ctrl-P and post-resize shaders with Ctrl+Alt+P.

The script settings are in the FineSharpA and FineSharpC files. They mirror the original script settings exactly.
The main sharpness control is "sstr" in FineSharpA, use it to control the sharpness more precisely than just toggling pre or post shaders. When you change sstr, you should also change cstr - suggested values are in the script.
I also added an extra feature of my own "xrep", which helps reduce artefacts from the second pass of sharpening.


Notes

The shaders are not compatible with the MadVR setting: "run custom pixel shaders in video levels instead of PC levels".

V1.12 - Color conversion improvement by Shaindow
V1.11 - Bug fix
V1.1 - Optimised sorts and medians for a good speed-up. Fixed a bug in the second sharpening pass & tweaked xrep range. Removed a couple of unnecessary files.
v1.0 - First release

-Vit-

[Asmodian]

Impressive, thanks for these!

[PetitDragon]

This is nothing else.

Just great!:thanks:

[Reel.Deel]

Awesome! Thank you very much for this litttle present.

[foxyshadis]

This is one of the coolest things I've seen in a long time, and it works amazingly well. Thank you, Vit!

[Ge'in]

Thanks again :)

[feelingblue]

time ago I asked for a shader can return the same quality of finesharp.
I tried with the lumasharp but nothing to do..

Thanks!

[feelingblue]

But if i copy all files content in only one single file.. is the same thing or not?

[Shiandow]

But if i copy all files content in only one single file.. is the same thing or not?

You mean combining all shaders in a single file? That won't work, the resulting 'shader' won't even compile.

If you really wanted to you could combine them into 1 shader, but unless you find a way to do this efficiently the resulting shader will be a few orders of magnitude slower.

[Zachs]

You mean combining all shaders in a single file? That won't work, the resulting 'shader' won't even compile.

If you really wanted to you could combine them into 1 shader, but unless you find a way to do this efficiently the resulting shader will be a few orders of magnitude slower.

This gives me an idea for MPDN's image processor - Presets.
We could let user save and load the FineSharp shader sequence as a preset. Then it's as simple as adding ImageProcessor (Preset: FineSharp) in the render chain, which would be more intuitive than the long list of hlsl files it currently shows in its description.

On a more on topic note, I can't seem to get these shaders to work correctly - they seem to change the colour of the image to one that has a magenta hue.

http://i.imgur.com/otfxetu.png

[Anima123]

Zachs, is it possible to add the FineSharp scripts on the original yuv space with MPDN, since the convert to YUV step will only degrade the chroma, by doubling and reversing to half video size another time? I also doubt the convert to RGB would have the same quality of the renderer doubling, which can choose a fancy chroma doubling method.

[Zachs]

While MPDN does provide YUV inputs if a render script requests for it, the ImageProcessor script is created to be fully compatible with MPC-HC/madVR style shaders - i.e. shaders that rigidly expect its inputs in RGB. MPDN also provides the YUV colorimetry being used for the video, so it's possible to write a render script that does proper YUV to RGB conversion in the final step.

e.g. in FineSharp's case, you would create a render script that
Asks MPDN to give you YUV inputs
Do RemoveGrain11 RemoveGrain4 FineSharpA FineSharpB FineSharpC
Then convert to RGB based on the colorimetry info MPDN gives you

This actually gives me another idea. ImageProcessor could do with a "YUV input" option.
That way, all you have to do is add RemoveGrain11 RemoveGrain4 FineSharpA FineSharpB FineSharpC to the list, and MPDN will do the proper YUV/RGB conversions with the user selected / stream selected colorimetry.

[Shiandow]

Zachs, is it possible to add the FineSharp scripts on the original yuv space with MPDN, since the convert to YUV step will only degrade the chroma, by doubling and reversing to half video size another time? I also doubt the convert to RGB would have the same quality of the renderer doubling, which can choose a fancy chroma doubling method.

The ToYuv shader doesn't downsample the chroma. The only possible loss is rounding errors by converting back and forth, but that shouldn't be a problem if you use a high enough bit depth.

Edit: Also note that there's no additional value whatsoever to perform sharpening in the original YUV, besides preventing unnecessary colour conversions.

[Zachs]

The ToYuv shader doesn't downsample the chroma. The only possible loss is rounding errors by converting back and forth, but that shouldn't be a problem if you use a high enough bit depth.

I should've mentioned that too.

Anyway, it should be possible to get rid of the ToYuv step to save some time if ImageProcessor supports YUV input (no need for YUV to RGB conversion only for the script to convert it back to YUV).

I will probably add a IRenderer.ConvertToRGB() method which I could then include as a final step in Render() if InterfaceDescriptor.WantsYuv is true. I'll continue this in PM.

[-Vit-]

On a more on topic note, I can't seem to get these shaders to work correctly - they seem to change the colour of the image to one that has a magenta hue.

Maybe you have tweaked some of MadVR's performance/quality settings. <snip>edited for correction</snip>. Selecting "run custom pixel shaders in video levels instead of PC levels" will cause a magenta tint. Is that it I wonder? You would need a different ToYUV for video levels.

[Zachs]

Maybe you have tweaked some of MadVR's performance/quality settings. The YUV<->RGB conversion needs to operate in 16bit. So selecting the "Use 10bit chroma buffer instead of 16bit" gives a slight magenta hue.

Also choosing "run custom pixel shaders in video levels..." breaks it too.

I'll update the OP shortly.

This is with MPDN, not MadVR. None of the others who've tested it seem to report such problems though.

And MPDN doesn't do 10bit buffers, only 16bit floats.

[-Vit-]

I haven't tried MPDN, I will do.
You could single out if it's the YUV<->RGB conversion by removing all the other filters.

[foxyshadis]

Going to magenta sounds like BT.709 was used to convert to YUV and then BT.601 back to RGB.

Edit: Also note that there's no additional value whatsoever to perform sharpening in the original YUV, besides preventing unnecessary colour conversions.

Sharpening in linear light (RGB or YUV) would probably be more valuable than any transformation between gamma-corrected RGB or YUV.

[Shiandow]

Sharpening in linear light (RGB or YUV) would probably be more valuable than any transformation between gamma-corrected RGB or YUV.

Not something perceptually uniform like Lab? Although I agree that for unsharp mask sharpening it might be better to perform the blurring in linear light.

[Zachs]

This is with MPDN, not MadVR. None of the others who've tested it seem to report such problems though.

And MPDN doesn't do 10bit buffers, only 16bit floats.

Scratch that. I can no longer replicate the problem. It may have been a problem with my own development scripts that caused the problem which probably explains why no one else reported the problem.

[madshi]

Wow, this is great - I've always been a fan of FineSharp and planned to look into making it work for madVR at some point in the future. Now -Vit- has done all the work, thank you very much!

http://madshi.net/icon_crazy.gif

@-Vit-, have you found some madVR settings which damage the alpha channel? I think madVR's shader processing should preserve the alpha channel between passes. The alpha channel will probably get lost during scaling (I skip the alpha channel there to save performance). But since all the FineSharp scripts should probably be executed right after each other, there should be no problem, correct?

FWIW, I plan to add a more complex shader editor to madVR in the near future, which should make it possible to put something like your HLSL FineSharp scripts into one "shader plugin" (or however it will be called). I plan to support multiple rendering passes, and also exportable options/parameters which the user can then modify through the madVR GUI or maybe assignable keyboard shortcuts etc. Of course the shaders will also be profilable, so users can use different shaders/settings depending on e.g. source resolution or framerate etc. Haven't thought this all fully through yet, though. Do you have any wishes that you'd like to see implemented in madVR to make porting of AviSynth scripts more easy/nice for you?

One thing I've been wondering about is whether it might make sense to handle grain outside of the shaders. E.g. maybe it would make sense to remove/reduce the grain before running all the shaders and scaling etc, and then after all shaders and scaling is done, maybe the grain could be put back in somehow? As opposed to every script doing this on its own separately. To be honest, although I'm a fan of several AviSynth scripts, I haven't really looked into how most of them work inside yet. So maybe what I wrote above is an old hat for AviSynth experts. Just wondering if there's anything I could do in madVR to make things easier/better...

> The shaders are not compatible with the MadVR
> setting: "run custom pixel shaders in video levels
> instead of PC levels".

I expect several shaders might have problems with that setting. I still added it as an option to make some shaders perform faster for users of very slow GPUs. In the madVR shader editor I plan to offer an option like "this shader/plugin needs to run in PC levels", which would then effectively force that "run custom pixel shaders in video levels" option off, when such a shader is activated by the user.

[Zachs]

Scratch that. I can no longer replicate the problem. It may have been a problem with my own development scripts that caused the problem which probably explains why no one else reported the problem.

Just a quick update - FineSharp scripts now run perfectly well under MPDN. It was indeed a bug in the render script system. This is now fixed.

Even better, you can now tell MPDN how / when you want to enable FineSharp via render script - e.g. you can choose to enable them for 720p videos only, or use different sets of FineSharp shader files for 1080p etc.

[-Vit-]

@madshi
No I haven't found any problem with the alpha channel. I only mentioned it because it's kinda undocumented to do that. If it's officially supported, then I'll remove that note. There is no need for the alpha channel after the shader chain completes so it's fine to drop it for the scaling afterwards.

--

The single most powerful feature that could be added to shader chaining would be the ability to store intermediate results and then use multiple inputs for a later shader
E.g.
Source->Shader1->Shader2->A
Source->Shader3->B
Source and A and B->Shader4->Output

That would make most non-temporal scripts achievable in theory I suppose (memory and performance notwithstanding). Technically it shouldn't be difficult. But what user interface to provide? The MPDN guys have some kind of C# meta-scripting language, I haven't looked at in in detail, but I think it can do something like that. Or some kind of GUI can work for simpler cases.

--

There are a couple of scripts that remove grain then add it back later, QTGMC for example. It's not especially common though. You mention adding grain back in after scaling. QTGMC has an option to scale (well, deinterlace) the grain using a different process than the degrained image - it injects extra noise with similar local properties. Would people want something like that in the madVR scaling, "resampled grain"? I don't know...

It would be ideal to do temporal (motion compensated) denoising for sharpening. With spatial-only denoising you might (temporarily) lose the fine detail that you want to sharpen. However, temporal work in the shaders will be a much greater challenge I guess.

--

I ought to note that I'm mostly retired now, lol. (edit: from video-related development that is)

[madshi]

No I haven't found any problem with the alpha channel. I only mentioned it because it's kinda undocumented to do that. If it's officially supported, then I'll remove that note. There is no need for the alpha channel after the shader chain completes so it's fine to drop it for the scaling afterwards.
I've just rechecked my rendering chain and I see no way that the alpha channel could be lost/hurt in between of multiple shaders / shader passes. So you can remove the alpha channel note.

The single most powerful feature that could be added to shader chaining would be the ability to store intermediate results and then use multiple inputs for a later shader
E.g.
Source->Shader1->Shader2->A
Source->Shader3->B
Source and A and B->Shader4->Output

That would make most non-temporal scripts achievable in theory I suppose (memory and performance notwithstanding). Technically it shouldn't be difficult. But what user interface to provide? The MPDN guys have some kind of C# meta-scripting language, I haven't looked at in in detail, but I think it can do something like that. Or some kind of GUI can work for simpler cases.
Haven't looked at the MPDN solution yet in detail, either. But I think the ability to store intermediate results in an extra texture and reuse it later should be doable in any case.

There are a couple of scripts that remove grain then add it back later, QTGMC for example. It's not especially common though. You mention adding grain back in after scaling. QTGMC has an option to scale (well, deinterlace) the grain using a different process than the degrained image - it injects extra noise with similar local properties.
Wow. That's *exactly* what I've been thinking about myself. Reducing the grain, then scaling it seperately or just replacing it with grain which has similar local properties. That sounds quite awesome to me. At least in theory.

Personally I like grain and I prefer not to remove it. But I do notice that some algorithms work much better if the grain is removed/reduced before. E.g. the madVR debanding algorithm (based on f3kdb) doesn't work well if there's lots of grain in the image.

Would people want something that in the madVR scaling, "resampled grain"? I don't know...
From what I've read in the madVR thread, some people hate grain while others love it. So everybody may have a different opinion. Personally, I like grain (at least if it's in the original source), so I personally would like a concept of "resampled grain" or "restaurated grain" or whatever a good term for that would be. I'm not sure if I'd prefer to try to scale the grain or to replace it with "new" noise which just has similar local properties, though. Whatever looks better in the end, I guess... :)

In any case, I think it might be good for performance if grain is removed/reduced only once before all the custom shaders are run, and then eventually (if the user wants it) added back in at the very end. This way all the custom shaders could skip the de-graining.

It would be ideal to do temporal (motion compensated) denoising for sharpening. With spatial-only denoising you might (temporarily) lose the fine detail that you want to sharpen. However, temporal work in the shaders will be a much greater challenge I guess.
From my side, I don't think it would be a big problem. madVR already has a relatively large frame queue size, so I could make the past and future frames available to a shader. A big question would be how to make such temporal work perform well. It might make sense for a shader to only look at the current and next frame and store motion information in a separate texture. This might perform better than to reevaluate motion over multiple past and future frames again and again for every video frame. But that's a topic that the shader writer would have to worry about. Technically it would be possible for madVR to make past and future frames available. In certain situations (e.g. after a seek) past frames might have to be set to be identical to the current frame, of course.

I ought to note that I'm mostly retired now, lol.
From your daily job? Or from home cinema related development? If you're retired from your daily job, that should give you more time for home cinema related development, no? :p

In any case, thanks a lot for your work, I much appreciate it!

Would you be ok if I shipped your FinalSharp shaders with a future madVR version? I'm not sure yet in which form I would do that (e.g. preconfigured plugin or totally built into the settings GUI etc), but in any case I'd of course note somewhere, at least in the readme, that the original script is from Didée and that you did the HLSL conversion. And of course I'll ask Didée's permission, too, if you're ok with it.

[Shiandow]

FWIW, I plan to add a more complex shader editor to madVR in the near future, which should make it possible to put something like your HLSL FineSharp scripts into one "shader plugin" (or however it will be called). I plan to support multiple rendering passes, and also exportable options/parameters which the user can then modify through the madVR GUI or maybe assignable keyboard shortcuts etc. Of course the shaders will also be profilable, so users can use different shaders/settings depending on e.g. source resolution or framerate etc. Haven't thought this all fully through yet, though


That sounds somewhat similar to what Zachs and I are doing with MPDN. Anyway, consider me interested!


The single most powerful feature that could be added to shader chaining would be the ability to store intermediate results and then use multiple inputs for a later shader
E.g.
Source->Shader1->Shader2->A
Source->Shader3->B
Source and A and B->Shader4->Output

That would make most non-temporal scripts achievable in theory I suppose (memory and performance notwithstanding). Technically it shouldn't be difficult. But what user interface to provide? The MPDN guys have some kind of C# meta-scripting language, I haven't looked at in in detail, but I think it can do something like that. Or some kind of GUI can work for simpler cases.


That's pretty much what we've currently achieved with the so called "Render Scripts". Although a render script also needs to handle settings and determine how it is displayed in the GUI, if you want something that more closely resembles a shader then you should look at the Filter class. For example with the current render script API you could build a Filter which performs that chain of shaders with the code:

var A = CreateFilter(Shader1, SourceFilter);
A = CreateFilter(Shader2, A);
var B = CreateFilter(Shader3, SourceFilter);

return CreateFilter(Shader4, SourceFilter, A, B);


For a good example you could look at the implementation of NEDI (the relevant part is in the "CreateNediScaler" method, the rest just deals with preparing shaders, settings, GUI, etc.)


Haven't looked at the MPDN solution yet in detail, either. But I think the ability to store intermediate results in an extra texture and reuse it later should be doable in any case.

I think that MPDN's render scripts are currently the closest thing to the more advanced shader editor you had in mind, although we're still working on making it easier to write them yourself. It would be nice if MadVR could have something similar, or even better, if render scripts could be made compatible with MadVR. Anyway I think it's worth a look and if you have any questions, feel free to ask.

[-Vit-]

Wow. That's *exactly* what I've been thinking about myself. Reducing the grain, then scaling it seperately or just replacing it with grain which has similar local properties. That sounds quite awesome to me. At least in theory.
Well, I didn't find it quite so awesome in QTGMC. It works well, and makes a nice fine result... but it's not much different from just rescaling the grain (although it does help to use a different rescaler for the grain). Having said that QTGMC only rescales vertically 2x, so it's not adding much grain - perhaps I shouldn't be surprised that it is underwhelming. However for a big resize, making a lot more grain - I wonder how well it will work? Will you be able to retain the "flavor" of the grain?

In any case, I think it might be good for performance if grain is removed/reduced only once before all the custom shaders are run, and then eventually (if the user wants it) added back in at the very end. This way all the custom shaders could skip the de-graining.

Since not many filters degrain and readd, then surely this doesn't represent much of a performance gain? Having said that, maybe more filters should work with the grain separately...?

I could make the past and future frames available to a shader. A big question would be how to make such temporal work perform well.
This discussion is heading towards replacing all of avisynth with shaders and a shader chaining language... Except that's a huge amount of work.

From your daily job? Or from home cinema related development?
Retired from video related development. Too much other work. I can help out a little, but only a little...

Would you be ok if I shipped your FinalSharp shaders with a future madVR version?
Of course. I probably should optimize them though. I wrote the shaders a year ago just as a convenience for myself. Didn't make any effort to make them fast.

That's pretty much what we've currently achieved with the so called "Render Scripts".
I had a look at that NEDI script and saw it had the power needed to make complex chaining scripts. It's cool... but, and I mean this as constructive criticism, all that C# baggage decreases readability considerably. You mention that you want to make them easier to write, what do you have in mind?

[madshi]

Well, I didn't find it quite so awesome in QTGMC. It works well, and makes a nice fine result... but it's not much different from just rescaling the grain (although it does help to use a different rescaler for the grain). Having said that QTGMC only rescales vertically 2x, so it's not adding much grain - perhaps I shouldn't be surprised that it is underwhelming. However for a big resize, making a lot more grain - I wonder how well it will work? Will you be able to retain the "flavor" of the grain?
Good questions. I'll make sure to look into the QTGMC grain algorithms when I find some time.

Since not many filters degrain and readd, then surely this doesn't represent much of a performance gain? Having said that, maybe more filters should work with the grain separately...?
Well, it's useful at least for debanding and sharpening. Maybe also for dehaloing and deblocking? I'm not sure (yet).

This discussion is heading towards replacing all of avisynth with shaders and a shader chaining language... Except that's a huge amount of work.
Well, "all of AviSynth" aims a bit high, I would think. But I sure would love to have at least one good HLSL implementation available for all key algorithms which are most useful for real time playback. Coming to mind is mostly good quality denoising, dehaloing, deblocking and maybe de-mosquito-ing. I'd also love to have the core functionality of QTGMC available. I can dream, can't I? :p

I'm not a big fan of using an additional scripting (or other) language to do shader chaining etc. Personally, I'd prefer to simply use whatever means HLSL offers, and to do the chaining/configuration with a nice and easy to use GUI.

Retired from video related development. Too much other work. I can help out a little, but only a little...
Ah, that's too bad. But I can understand you very well. Development can eat time like crazy.

Of course.
Thank you!

I probably should optimize them though. I wrote the shaders a year ago just as a convenience for myself. Didn't make any effort to make them fast.
If you do have some development time available for video related stuff, and if I could voice my preferences for how to spend your limited resources :o I'd much prefer if you could convert maybe some other algorithm to HLSL without any optimization. With your AviSynth experience you could do that a hundred times faster than I ever could. Optimizing the HLSL shaders is something a lot of people can do (including myself). Understanding and converting AviSynth scripts is much harder - at least for me. But of course it's all up to you! I'm already very happy with getting FineSharp. It was a very nice surprise when I stumbled over this thread today.

[Shiandow]

I had a look at that NEDI script and saw it had the power needed to make complex chaining scripts. It's cool... but, and I mean this as constructive criticism, all that C# baggage decreases readability considerably. You mention that you want to make them easier to write, what do you have in mind?

Yeah using c# is both a curse and a blessing, a lot of changes have been efforts to remove extra boilerplate, simplify common patterns etc.

Anyway did you look at the "MyRenderScript.cs" class? That is currently the simplest way to write a render script. Hopefully it can be made even simpler, although I'm not sure how much more can be done without inventing some kind of script language.

[madshi]

I think that MPDN's render scripts are currently the closest thing to the more advanced shader editor you had in mind, although we're still working on making it easier to write them yourself. It would be nice if MadVR could have something similar, or even better, if render scripts could be made compatible with MadVR. Anyway I think it's worth a look and if you have any questions, feel free to ask.
From what I can see, your render script solution looks very powerful and flexible. But I hate DotNet, and I'm not a big fan of C#, either. I'd prefer to not introduce just another language into it all. I think not all of the flexibility and power you're offering is really necessary. I'd prefer a simpler solution and so I'll probably try to get along with just HLSL and a good GUI editor. But these are just my current thoughts. I haven't fully made up my mind yet.

[Shiandow]

From what I can see, your render script solution looks very powerful and flexible. But I hate DotNet, and I'm not a big fan of C#, either. I'd prefer to not introduce just another language into it all. I think not all of the flexibility and power you're offering is really necessary. I'd prefer a simpler solution and so I'll probably try to get along with just HLSL and a good GUI editor. But these are just my current thoughts. I haven't fully made up my mind yet.

I suspected that allowing arbitrary scripts in c# was probably not entirely what you were thinking off. And I agree that you could probably achieve a lot of it using only HLSL and an easy way of chaining shaders. It would be nice if it could be made compatible with MPDN though, although that shouldn't be a problem if the way you save these 'shader chains' is easy to read.

[madshi]

I can make the file format readable, or at least explain how it works, that's not a problem.

[Zachs]

The ultimate goal for MPDN's render script is to have AviSynth like simplicity with none of the C# baggage on the top level (AviSynth scripting level), yet allowing you to go deeper and deeper if you need to implement more complicated filters, which is exactly the model AviSynth offers via its 'plugin' system. For the plugin system, you could use C++/CLI, VB.NET, or C# if you compile them into DLLs for the former two languages, or either C# script or compiled DLL if you opt for the latter.

If anyone feels like joining MPDN's render script development, feel free to contact either Shiandow or myself.

[-Vit-]

Just updated the first post with v1.1. It's faster now.

I just had to get rid of those badly implemented sorts and medians, replaced them now with more efficient network-sort-style sequences in RemoveGrain4 and FineSharpB. Not theoretically optimal, but close enough - I wanted to avoid conditionals and excessively long shaders.

I tweaked the second sharpening stage (xstr and xrep), which were not operating correctly. You'll probably not notice, that stage has a small impact in this script.

I noticed how well the sharpener works with NNEDI3 luma doubling (the sharpener doesn't affect chroma). Really helps when using pre-resize and post-resize shaders together. Although NNEDI3 does use quite a bit of GPU time.

[madshi]

Thank you for the updated shaders! Yes, NNEDI3 + FineSharp works very well. When playing with doubling the resolution of test images I also like a combination of NNEDI3, FineSharp, LimitedSharpen and aWarpSharp2, though:

nnedi3x(dw=1, nns=2, qual=1)
LimitedSharpenFaster(strength=100)
aWarpSharp2(depth=5)
FineSharp()
At least this looks nice to me with this test image: castle (http://madshi.net/castleOrg.png). Probably a touch oversharpened, but at least it's crisp.

[-Vit-]

I'd much prefer if you could convert maybe some other algorithm to HLSL without any optimization. With your AviSynth experience you could do that a hundred times faster than I ever could. Optimizing the HLSL shaders is something a lot of people can do (including myself). Understanding and converting AviSynth scripts is much harder - at least for me.
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.

[kasper93]

@-Vit-: There is typo in FineSharpC.hlsl:L20 missing one ")".

[-Vit-]

@-Vit-: There is typo in FineSharpC.hlsl:L20 missing one ")".
Yes, thanks. Updated the first post, please update everyone - I double checked this time, lol

This happens because the shader editor in MPC-HC isn't connected to the files, so it's easy to get out of sync. It's better in the new versions of MPC-HC, but that's doesn't have shortcut keys for shaders, which makes using them annoying.

[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)

ToYUV
RemoveGrain11
RemoveGrain4
FineSharpA
FineSharpB
FineSharpC
ToRGB

Then I have one which has the above shaders in both pre-resize and post-resize, and when I have a 720p clip on a 1080p screen and I toggle I don't see a difference at all in the image. I must be doing something wrong? (yes I'm using latest MadVR, tried with NNEDI3 luma doubling on and off and notice no difference)

[Neet009]

Mediafire's link still finesharp_shaders_1.1.zip, not finesharp_shaders_1.11.zip:confused:.And it seems doesn't work here too.(Both MPC-BE and MPC-HC)

[-Vit-]

Mediafire's link still finesharp_shaders_1.1.zip, not finesharp_shaders_1.11.zip:confused:.And it seems doesn't work here too.(Both MPC-BE and MPC-HC)
One of those days... Link in the OP fixed.

[Neet009]

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

Thank you for updating.　It works well now.:thanks:

[-Vit-]

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]

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

[-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]

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-]

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 :eek:. 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]

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.

(2) - QTGMC in shaders :eek:. 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?

(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]

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 (http://www.mediafire.com/download/7g82h7kisz8o6ou/finesharp_shaders_1.11.zip), just below the caption "installation".

[BetA13]

The first post also contains this link (http://www.mediafire.com/download/7g82h7kisz8o6ou/finesharp_shaders_1.11.zip), just below the caption "installation".

:thanks: 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?

:thanks:

[TheElix]

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

[kasper93]

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]

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]

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.

[Kirk Lazarus]

I guys,
I'm very new about this HTPC area so please have patience if I ask stupid stuff.

I use MPC HC with MadVR (AMD r9 280X card) to go in UHD to my tv.

I've installed the shaders.
I played my favourite Blu ray and go to still frame.

I've activated the shaders like you can see in this image:

https://dl.dropboxusercontent.com/u/261382755/finesharp.jpg

I activated the shaders and with my face near Tv I can't see any difference!!

Is it normal? Maybe the still frame is not good to see differences?

I also tried FinesharpB and C but my eyes can't see the difference?!

Where I'm wrong?

I've to say that when I activate the shaders the average rendering time increase and when I deactivate them the rendering time goes down but ... I can't see any improvement in the image quality.

Another question:
I'm worried about the double color space conversions (toYUV + toRGB) ... May those two conversions lower the quality bringed into MadVR processing?

thank you so much.

[toniash]

I guys,
I'm very new about this HTPC area so please have patience if I ask stupid stuff.

I use MPC HC with MadVR (AMD r9 280X card) to go in UHD to my tv.

I've installed the shaders.
I played my favourite Blu ray and go to still frame.

I've activated the shaders like you can see in this image:

https://dl.dropboxusercontent.com/u/261382755/finesharp.jpg

I activated the shaders and with my face near Tv I can't see any difference!!

Is it normal? Maybe the still frame is not good to see differences?

I also tried FinesharpB and C but my eyes can't see the difference?!

Where I'm wrong?

I've to say that when I activate the shaders the average rendering time increase and when I deactivate them the rendering time goes down but ... I can't see any improvement in the image quality.

Another question:
I'm worried about the double color space conversions (toYUV + toRGB) ... May those two conversions lower the quality bringed into MadVR processing?

thank you so much.

When you have imported the shaders they must be selected in the correct order (again check the web for details if you don't know how):

ToYUV
RemoveGrain11
RemoveGrain4
FineSharpA
FineSharpB
FineSharpC
ToRGB

You can select them as "pre-resize shaders" or "post-resize shaders", or both if you wish. In newer versions of MPC-HC, when you have selected your shaders type a preset name (e.g. "FineSharp - Pre-Resize") in the "Shader Presets" box and press "Save".

Pre-resize shaders have a stronger effect when upscaling (e.g. showing 720p on 1080p monitor), post-resize shaders are stronger when downscaling. Sharpening in both stages is too strong for my liking, but you could do this if you find the sharpening too delicate - this works best when NNEDI3 luma doubling is enabled.

Your rendering times are too high so you have dropped frames!

[Kirk Lazarus]

When you have imported the shaders they must be selected in the correct order (again check the web for details if you don't know how):

ToYUV
RemoveGrain11
RemoveGrain4
FineSharpA
FineSharpB
FineSharpC
ToRGB

....

Thank you so much for the feedback!
Now It's clear; all shaders must to be actived and in the same order you listed.

So, Yesterday I've tried Finesharp...

I remember that I use my HTPC on a UHDTV so my output res. is 2160p@23hz.

If I use the Finesharp chain in the PRE section of the shader I can see an evident work of the filter ...but the result do not like me so much!
Infact I can see too much halos and ringhing in the image.

If I put the shaders in the "POST" section I can't see any change in the image!!!

I've the rendering time near 48 (if I remember well) so I've massive frame-drop but .... I can't see any difference!!

It's normal for you?

Is there anybody that use Finesharp (shader) on a UHD TV?

Maybe those shaders do not work when the output is 2160?

thank you all.

[Carpo]

Has anyone tried these using an Intel HD4000? I seem to get strange colour issues if I use ToYUV, ToRBG, or any of the FineSharp filters, yet no issues if I use just the RemoveGrain filters, seems all the colours are wash out, with mainly blue and red being the main colours

[Elconite]

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.

This fix destroys color. Without it on the new versions of MadVR there are no red and green or they're screwed up but with the fix the reds are all crushed down . Any ideas how to fix the problem? The last version of MadVR that works with finesharp properly is 87.14

Before
http://i.imgur.com/nnSy5qG.jpg

After
http://i.imgur.com/03DPpLh.jpg

[kasper93]

See here http://forum.doom9.org/showpost.php?p=1715342&postcount=57

[Shiandow]

This fix destroys color. Without it on the new versions of MadVR there are no red and green or they're screwed up but with the fix the reds are all crushed down . Any ideas how to fix the problem? The last version of MadVR that works with finesharp properly is 87.14

Before
[...]

After
[...]

I had a quick look, and it seems that the type of YUV it uses has a slightly wider range than the one madshi was thinking of. Normally you'd have chroma values between -0.5 and 0.5, but the matrices used by finesharp has values between -0.436 and 0.436 for the U channel and -0.615 and 0.615 for the V channel. I think those values were useful for analog transmissions for some reason. Anyway, it should be possible to fix that by replacing those matrices with the following:


#define RGBtoYUV(Kb,Kr) float3x3(float3(Kr, 1 - Kr - Kb, Kb), float3(-Kr, Kr + Kb - 1, 1 - Kb) / (2*(1 - Kb)), float3(1 - Kr, Kr + Kb - 1, -Kb) / (2*(1 - Kr)))
#define YUVtoRGB(Kb,Kr) float3x3(float3(1, 0, 2*(1 - Kr)), float3(Kb + Kr - 1, 2*(1 - Kb)*Kb, 2*Kr*(1 - Kr)) / (Kb + Kr - 1), float3(1, 2*(1 - Kb),0))

static const float3x3 RGBtoYUV_601 = RGBtoYUV(0.114,0.299)
static const float3x3 RGBtoYUV_709 = RGBtoYUV(0.0722,0.2126)

static const float3x3 YUVtoRGB_601 = YUVtoRGB(0.114,0.299)
static const float3x3 YUVtoRGB_709 = YUVtoRGB(0.0722,0.2126)

[madshi]

Yep, Shiandow got it right, of course.

[burfadel]

Thank you so much for the feedback!
Now It's clear; all shaders must to be actived and in the same order you listed.

So, Yesterday I've tried Finesharp...

I remember that I use my HTPC on a UHDTV so my output res. is 2160p@23hz.

If I use the Finesharp chain in the PRE section of the shader I can see an evident work of the filter ...but the result do not like me so much!
Infact I can see too much halos and ringhing in the image.

If I put the shaders in the "POST" section I can't see any change in the image!!!

I've the rendering time near 48 (if I remember well) so I've massive frame-drop but .... I can't see any difference!!

It's normal for you?

Is there anybody that use Finesharp (shader) on a UHD TV?

Maybe those shaders do not work when the output is 2160?

thank you all.

If you do it before the resize, you are resizing the sharpened image. At 1080P, the artifacts may not be visible, but if you resize it to 2160P you are also resizing the artifacts...

You probably aren't seeing much sharpening at 2160P because the sharpen shader is optimised for a lower resolution (1080P or whatever). Basically, the relevant shader files need to be edited and the sharpen strength values upped.

However, at 2160P this shader is probably a bit taxing, you may be better off using the lumasharpen filter that has been ported from SweetFX. Again, you may need to up the strength (these shader files are text files, and they are laid out in the manner where it 'tells' you what to change). Lumasharpen produces a nice sharpen and is very fast.

[kasper93]

About YUV<->RGB conversion, we could save one operation by doing


#define RGBtoYUV(Kb,Kr) float3x3(float3(Kr, 1 - Kr - Kb, Kb), float3(-Kr, Kr + Kb - 1, 1 - Kb) / (2*(1 - Kb)), float3(1 - Kr, Kr + Kb - 1, -Kb) / (2*(1 - Kr)))
#define YUVtoRGB(Kb,Kr) float3x3(float3(1, 0, 2*(1 - Kr)), float3(Kb + Kr - 1, 2*(1 - Kb)*Kb, 2*Kr*(1 - Kr)) / (Kb + Kr - 1), float3(1, 2*(1 - Kb),0))

static const float3x3 YUVtoRGB = height <= 576 ? YUVtoRGB(0.114, 0.299) : YUVtoRGB(0.0722, 0.2126);
static const float3x3 RGBtoYUV = height <= 576 ? RGBtoYUV(0.114, 0.299) : RGBtoYUV(0.0722, 0.2126);

[Shiandow]

Aboit YUV<->RGB conversion, we could save one operation by doing


#define YUVtoRGB(Kb,Kr) float3x3(float3(1, 0, 2*(1 - Kr)), float3(Kb + Kr - 1, 2*(1 - Kb)*Kb, 2*Kr*(1 - Kr)) / (Kb + Kr - 1), float3(1, 2*(1 - Kb),0))

static const float3x3 YUVtoRGB = height < 576 ? YUVtoRGB(0.114,0.299) : YUVtoRGB(0.0722,0.2126);


I'm pretty sure it that one operation you save would have gotten optimized away anyway. In fact, the entire matrix is probably calculated up front.

[kasper93]

Sure it is calculated up front. I'm talking about `height < 576` comparison. It doesn't have to be done every time. And it is not optimized, 14 vs 13 operations for ToRGB.

EDIT:

And the check should be height <= 576

[Shiandow]

Sure it is calculated up front. I'm talking about `height < 576` comparison. It doesn't have to be done every time. And it is not optimized, 14 vs 13 operations for ToRGB.



Hmm, it does use less operations for some reason, although the height<576 operation is still there (twice even). Not sure why it decided to do something different.

[MCDamo]

About YUV<->RGB conversion, we could save one operation by doing


#define RGBtoYUV(Kb,Kr) float3x3(float3(Kr, 1 - Kr - Kb, Kb), float3(-Kr, Kr + Kb - 1, 1 - Kb) / (2*(1 - Kb)), float3(1 - Kr, Kr + Kb - 1, -Kb) / (2*(1 - Kr)))
#define YUVtoRGB(Kb,Kr) float3x3(float3(1, 0, 2*(1 - Kr)), float3(Kb + Kr - 1, 2*(1 - Kb)*Kb, 2*Kr*(1 - Kr)) / (Kb + Kr - 1), float3(1, 2*(1 - Kb),0))

static const float3x3 YUVtoRGB = height <= 576 ? YUVtoRGB(0.114, 0.299) : YUVtoRGB(0.0722, 0.2126);
static const float3x3 RGBtoYUV = height <= 576 ? RGBtoYUV(0.114, 0.299) : RGBtoYUV(0.0722, 0.2126);


Sorry for the entry level question, but where do i enter this in relation to the shader file?
Ive attempted every which way that seems logical to my very limited understanding!

[Shiandow]

Sorry for the entry level question, but where do i enter this in relation to the shader file?
Ive attempted every which way that seems logical to my very limited understanding!

Like this (http://www.mediafire.com/download/yi9tla70y8sts47/ToYuv_ToRGB.zip).

source code:

ToYUV

// $MinimumShaderProfile: ps_2_0
// Converts source rgb into yuv. A copy of the y value is put in the output alpha. By -Vit-
//----

sampler s0 : register(s0);
float4 c0 : register(c0);
float2 c1 : register(c1);
#define width (c0[0])
#define height (c0[1])

#define Src(a,b) tex2D(s0, uv+c1*float2(a,b))

#define RGBtoYUV(Kb,Kr) float3x3(float3(Kr, 1 - Kr - Kb, Kb), float3(-Kr, Kr + Kb - 1, 1 - Kb) / (2*(1 - Kb)), float3(1 - Kr, Kr + Kb - 1, -Kb) / (2*(1 - Kr)))
#define YUVtoRGB(Kb,Kr) float3x3(float3(1, 0, 2*(1 - Kr)), float3(Kb + Kr - 1, 2*(1 - Kb)*Kb, 2*Kr*(1 - Kr)) / (Kb + Kr - 1), float3(1, 2*(1 - Kb),0))

static const float3x3 YUVtoRGB = height <= 576 ? YUVtoRGB(0.114,0.299) : YUVtoRGB(0.0722,0.2126);
static const float3x3 RGBtoYUV = height <= 576 ? RGBtoYUV(0.114,0.299) : RGBtoYUV(0.0722,0.2126);

float4 main(float2 uv : TEXCOORD0) : COLOR
{
float3 yuv = mul( RGBtoYUV, Src(0,0).rgb ) + float3(0.0, 0.5, 0.5);
return float4(yuv,yuv.x);
}


ToRGB

// $MinimumShaderProfile: ps_2_0
// Assumes source rgb is in fact yuv, and converts it to real rgb. Source alpha is copied as is. By -Vit-
//----

sampler s0 : register(s0);
float4 c0 : register(c0);
float2 c1 : register(c1);
#define width (c0[0])
#define height (c0[1])

#define Src(a,b) tex2D(s0, uv+c1*float2(a,b))

#define RGBtoYUV(Kb,Kr) float3x3(float3(Kr, 1 - Kr - Kb, Kb), float3(-Kr, Kr + Kb - 1, 1 - Kb) / (2*(1 - Kb)), float3(1 - Kr, Kr + Kb - 1, -Kb) / (2*(1 - Kr)))
#define YUVtoRGB(Kb,Kr) float3x3(float3(1, 0, 2*(1 - Kr)), float3(Kb + Kr - 1, 2*(1 - Kb)*Kb, 2*Kr*(1 - Kr)) / (Kb + Kr - 1), float3(1, 2*(1 - Kb),0))

static const float3x3 YUVtoRGB = height <= 576 ? YUVtoRGB(0.114,0.299) : YUVtoRGB(0.0722,0.2126);
static const float3x3 RGBtoYUV = height <= 576 ? RGBtoYUV(0.114,0.299) : RGBtoYUV(0.0722,0.2126);

float4 main(float2 uv : TEXCOORD0) : COLOR
{
float4 o = Src(0,0);
o.rgb = mul( YUVtoRGB, o.xyz - float3(0.0, 0.5, 0.5));
return o;
}

[Zachs]

Shiandow, perhaps it would be a good idea to upload the fixed version so everyone could just download and use it?

[Shiandow]

If possible I'd rather avoid having both an official version and an unofficial "fixed" version of the finesharp shaders. I could upload the "fixed" ToYUV and ToRGB shaders though, I'll add a link to my previous comment.

[MCDamo]

Thank you Shiandow, very much appreciated!

[foxyshadis]

-Vit- sadly hasn't been around in a long time, so I went ahead and uploaded a new version of the zip with the fixed shaders (and the originals in a subfolder).

[madshi]

JFWIW, the latest madVR build now has -Vit-'s FineSharp() included. I've also added a "linear light" option. Not sure yet if I like that option, though. It looks a bit different, but I'm not sure if it's better.

[kasper93]

-Vit- sadly hasn't been around in a long time, so I went ahead and uploaded a new version of the zip with the fixed shaders (and the originals in a subfolder).

Seems like my post hasn't been noticed about height < 576 it should be less or equal for BT.601. PAL have 576px height.

[Shiandow]

Seems like my post hasn't been noticed about height < 576 it should be less or equal for BT.601. PAL have 576px height.

I think you're correct. I've edited my post. Could take a while before the zip files in the first post are updated. Especially since it's not that important to use the original YUV space.

[foxyshadis]

I think you're correct. I've edited my post. Could take a while before the zip files in the first post are updated. Especially since it's not that important to use the original YUV space.

Done as well. Thinking about it, I agree that it really makes little or no difference what YUV space it's done in, but at least it's consistent with the thread. Maybe if it was wide-gamut BT.2020.

[Music Fan]

Hi,
I'd like to understand what means "converted to shader" for an avs script. Does it mean Avisynth is used in background when your shaders are used ?
How to convert avs to hlsl ?
My idea was to create a script that I could use easily with MPC-HC as a shader to avoid to modify the script each time I play a video to change the path of this video in the script.
This trick works with Virtual Dub Mod which allow templates based on avs script (with avst extension placed in the template sub-folder of Virtual Dub Mod).

[huhn]

Hi,
I'd like to understand what means "converted to shader" for an avs script. Does it mean Avisynth is used in background when your shaders are used ?
How to convert avs to hlsl ?
My idea was to create a script that I could use easily with MPC-HC as a shader to avoid to modify the script each time I play a video to change the path of this video in the script.
This trick works with Virtual Dub Mod which allow templates based on avs script (with avst extension placed in the template sub-folder of Virtual Dub Mod).


by taking the AVS scripting code and/or the code from the plugin and transform it to HLSL code if possible.


it's like translation from english to japanese. kind of ...

[Music Fan]

by taking the AVS scripting code and/or the code from the plugin and transform it to HLSL code
Ok but how ?
I looked into a hlsl file, it's quite different from an avs.

if possible.
How to know when it possible or not ?

[huhn]

Ok but how ?
I looked into a hlsl file, it's quite different from an avs.[quote]
like i said "translation". you need to "speak" both languages and trans late it than.

[quote]How to know when it possible or not ?

HLSL is a shader language it is pretty limited unlike the code used in AVS plugins.

[Bloax]

"Converting" an AVS file to HLSL would imply reimplementing all the filters you use in the avisynth script in HLSL and then using them in the same manner you use them in the avisynth script.
You might notice that the "reimplement the filters in HLSL" is probably the part where it gets difficult.

[Music Fan]

Ok, thus it's not that easy.
Is there another way to use easily an avs script for all videos with MPC-HC, as the avst templates for Virtual Dub Mod ?

[huhn]

try ffdshow.

AVS usually uses the CPU which is terrible slow for picture processing and has not optimal multi threading performance. so realtime processing is maybe out of question for a lot of filter.

[Music Fan]

Right, but I didn't wan't to make complex scripts, it's mainly to de-interlace AVI files which are not de-interlaced by MPC-HC while other formats are :confused:

It works with VLC but I prefer MPC-HC.

Anyway, how to use ffdshow filters with MPC-HC ?

[huhn]

just use madVR and press control+shift+alt+d to force deinterlacing.

there should a lot of ffdshow mpc-hc guides on the internet

lavfilter can deinterlace too.

[Music Fan]

I'd like to avoid to install another tool (madVR), I won't use it a lot.
LAV is included in MPC-HC but whatever the settings (auto, force, with and without Yadif), AVI's are not de-interlaced.:confused:
The only solution I found with MPC-HC is to use the de-interlacer (blend) in shader's list (and I add it as pre-size shader). But I'm not sure this is a very good de-interlacer and I don't know how does LAV's de-interlacer work in this case : are there 2 successive de-interlacers ?

[huhn]

are you even sure the avi are interlanced?

[Music Fan]

Of course.

[Music Fan]

But it seems to concern only Lagarith avi (and Xvid encoded as progressive, I mean without checking "interlaced" in encoding options). But as I said, even when I check "force" in LAV's de-interlacing options, these avi's are not de-interlaced. The source of these avi's is DV (dvsd).

[huhn]

sample?

[Music Fan]

Just open an interlaced video in Virtual Dub and export a sample in Lagarith in YV12, that's very fast.

[huhn]

every normal file if interlaced or not that is forced to be deinterlaced with lavfilter is deinterlaced so this doesn't help.

[Music Fan]

every normal file if interlaced or not that is forced to be deinterlaced with lavfilter is deinterlaced so this doesn't help.
But it's not de-interlaced ! While it should be when forced to.
Thus I wonder what this force mode is supposed to do.
MPC-HC probably needs a header that specify the video as interlaced, which is not possible with Lagarith.
Anyway, VLC does the job with these files.

[lanzorg]

Does anyone could port this shader to glsl? It would be wonderful!

[bob88]

Hello,

I'm using MPC-HC latest version. I wanted to try this shader out, I added it to post resize in the described order but it just makes everything almost completely white, you can barely make out anything of the movie. Does anybody know how to fix this? And is there a later version after 1.11?

Thank you very much!

[BetA13]

hy there,

just yesterday i switched back to Finesharp from adaptive sharpen. (performance reasons)
And its working wonderfull here..

i hope i can help you by posting a screenshot of my shader settings so that might help..

First of all, get the "finesharp_shaders_1.12_bugfix_by_shiandow.zip" version. it should be in the first post..
Screens:

heres a screen for MPDN player:

https://abload.de/img/mpdnliy5y.png

aand for mpchc:

https://abload.de/img/mpchccfxx9.png

works perfect here, no white or black screen..
i hope this helps..

greetings

[Shiandow]

FWIW the next version of MPDN's extensions (i.e. the most recent state of the git repo) will add an option to process shaders in YUV, so then you will no longer need the 'ToYUV' and 'ToRGB' files. This also allows MPDN to optimize away unecessary conversions.

[bob88]

Thank you for replying.
I downloaded v1.12 but it works the same way. I have added the shaders as described and the end result is white.
Without toYUV and toRGB I can get it to sort of blue or yellow and without any of the two it's red.... So there is no working combination.
Any ideas?

PS: I don't have performance issues. Is there a better shader that I can use instead of this.

Thank you!

[toniash]

Thank you for replying.
I downloaded v1.12 but it works the same way. I have added the shaders as described and the end result is white.
Without toYUV and toRGB I can get it to sort of blue or yellow and without any of the two it's red.... So there is no working combination.
Any ideas?


PS: I don't have performance issues. Is there a better shader that I can use instead of this.

Thank you!

You can try adaptive sharpen http://forum.doom9.org/showthread.php?t=172131