Dogway's Filters Packs

[Dogway]

I could approximate a mean blur with "box" resize down, mean blur rad=2, resize up in softcubic. But then I thought, is there a reasoning for using mean blur and not other blur? If you observe mean blur in high radii it's far from ideal, like image doubling. So I went and used gaussian blur with some padding.

function SmoothGradPlus(clip m, int "radius", float "thr", clip "ref", float "elast", int "Y", int "UV")
{
radius = Default(radius, 16)
Y       = Default(Y,         3)
Y2     = Y==3 ? 3 : 1
UV     = Default(UV,      3)
UV2   = UV==3 ? 3 : 1
pad = ceil(radius)
m = sh_Padding(m, pad, pad, pad, pad)
smooth = ex_GaussianBlur(m, (radius-1)/1.5,Y=Y2, UV=UV2)
slimit_dif(smooth, m, ref, thr, elast, Y=Y, U=UV, V=UV)
crop(pad, pad, -pad, -pad)
}

EDIT: some benchs, 126fps, with optimized slimit_dif() 183fps, without padding 285fps. Maybe we can replace GaussResize() with a border aware resizer...

[real.finder]

Originally Posted by Dogway

is there a reasoning for using mean blur and not other blur?

to make it output similar to SmoothGrad, or it will no point of use it name and it better to use SmoothGrad2 instead of SmoothGradPlus, I make it Plus since it work only in avs+ and it give almost same output

edit: btw, vs port not give similar output (again), so likely we will see more posts like this and this which is bad since it kinda misinformation

[kedautinh12]

I think real.finder release SmoothGradPlus cause it's similar smoothgrad and dogway will release SmoothGrad2 cause it's different smoothgrad

[Dogway]

Making match something for the sake of it is just an unnecessary added burden, if it does what it says and does it well, who cares? I will try to roughly match the output but I will not be nitpicky about it.
I will call it ex_deband() in any case.

I'm now working with GaussResize cropping features to add and crop borders at the same time of resizing, it's tricky, resizing down is done, up is yet.

[real.finder]

Making match something for the sake of it is just an unnecessary added burden, if it does what it says and does it well, who cares?

aside from what I said before, it necessary in case of those dll filters used in another functions that maybe very sensitive to those changes, Especial if someone replace them without know they are not same in output

[Pauly Dunne]

Hard to keep up to all the changes & updates...

I got SMDegrainv3.3.1d today, and got an error, seems to be OK on one PC, but no the other, both are Ryzens, but one has nVidia GPU, the other has AMD.

If I recall, it was Line 498 (489).

But everything is SO SLOW when encoding 4K with these "strong" filters

[Dogway]

Can you be more precise? what is your SMDegrain call?
I have tested and everything seems to work, given you updated the other scripts (in case they are being used).

SMDegrain is the fastest UHD temporal denoiser because AFAIK is the only one that implements vector scaling.
You can speed it up further using another degrain mode like ML3DEx (limited to tr=1) or STWM (tr=2) or even temporalsoften.

Anyway most of the recent changes are features rather than bugfixes.

[Pauly Dunne]

Originally Posted by Dogway

Can you be more precise? what is your SMDegrain call?
I have tested and everything seems to work, given you updated the other scripts (in case they are being used).

SMDegrain is the fastest UHD temporal denoiser because AFAIK is the only one that implements vector scaling.
You can speed it up further using another degrain mode like ML3DEx (limited to tr=1) or STWM (tr=2) or even temporalsoften.

Anyway most of the recent changes are features rather than bugfixes.

Well, 3.3.0d worked fine, and 3.3.1d has quite a few more lines, that's about it for changes, I made to my script.

I'd certainly like to know how to use those "modes" you mentioned above...might have to have a look tomorrow.

Cheers

[Dogway]

Originally Posted by Pauly Dunne

3.3.1d has quite a few more lines

"More lines" doesn't mean "does more", by default SMDegrain works the same as before.

[tormento]

Originally Posted by Dogway

"More lines" doesn't mean "does more", by default SMDegrain works the same as before.

Please, please, please, update your filter documentation, SMDegrain mostly.

There are some switches that are not clear to me and others rather obscure.

[Pauly Dunne]

I think I'm going to have to go back to my older filters that did a real good job, and didn't take a LONG time....these filters might be way to complex, and trying to do too much, they're just slow.

Reasonable quality, but at good speed !!

[Dogway]

@Pauly Dunne: Funny when almost all my changes are biased for speed, check OP for benchmarks. By the way, you just duplicated the post in the HQMC thread. You have been advised before of such demanding attitudes. We are all here to help and nothing is given for granted. So thank what is given.

@tormento: Yes I have to, it's cumbersome but with the latest additions (limitS, mode, Str) it makes more sense. Before that I want to finish ex_vibrance() and skin_qualifier() for peace of mind.

[Pauly Dunne]

Originally Posted by Dogway

@Pauly Dunne: Funny when almost all my changes are biased for speed, check OP for benchmarks. By the way, you just duplicated the post in the HQMC thread. You have been advised before of such demanding attitudes. We are all here to help and nothing is given for granted. So thank what is given.

You're exactly right, Dogway...

https://forum.doom9.org/showthread.p...80#post1952980

[tormento]

Originally Posted by Dogway

Before that I want to finish ex_vibrance() and skin_qualifier() for peace of mind.

SMDegrain (tr=4, thSAD=400, refinemotion=true, contrasharp=false, PreFilter=5, plane=4, chroma=true)

Script error: the named argument "sigma" to BM3D_CUDA had the wrong type (passed an array to a non-array parameter)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.1d~Dogway.avsi, line 775)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-3.3.1d~Dogway.avsi, line 170)

No problems with prefilter=4.

[Dogway]

Yes, you have to update.

[tormento]

Originally Posted by Dogway

Yes, you have to update

I did not notice the update.

Thank you, it's working now.

[Dogway]

Just updated SMDegrain, LSFmod and SharpeningPack. All related to SMDegrain.
Ok, in lack of proper documentation for the time being I will brief the latest changes.

Recently there have been only three meaningful changes; denoiser mode, temporal-limiting sharpening, and ex_retinex.

ex_retinex: 'Str' is the argument that controls what kind of luminance optimization is performed. When set to 0, it only expands from TV range to PC range. When set to 1.0 or below uses ex_retinex() and over 1.0 to ex_luma_rebuild(). Default is 3.0, at this value not only a TV to PC range is performed but also some dark areas are brightened in a gentle manner. ex_retinex though uses the Multi-Scale Retinex algorithm, this is best suited for dark and/or low contrast sources and works better than ex_luma_rebuild(), since Retinex requires a range normalization the 'Str' defines the lower bound value, so when set to 0.40 it means that the retinex output will be normalized to PC range from value 40 to 255-lo/3. As always check the clip in 'show' mode to adjust values.

denoiser mode: I was developing TSMC script mod, and also having a glance to Didèe's LTSMC. When I realised, why take the whole SMDegrain to TSMC and not simply add the few lines to SMDegrain itself? So I did. Now you can use brute force denoising with all the features of SMDegrain like vector scaling, prefiltering, sharpening, etc. On the way I also had to auto activate a few switches so mode="TemporalSoften" really means "Degrain this shit out". It involved creating motion compensated frames and from there it was just a matter of including other denoisers I had created, so now you can use ex_median() temporal denoisers instead of MDegrain, some of them perform faster and with similar (better or worse) quality, just without scene change detection (should be handled by motion vectors). In today's update I included recursion mode, meaning it will denoise with past frames already denoised. It's a poor man's recursion so performance is like if called twice. Simply call like "rML3DEx" with an "r" preceding the denoiser name.

Temporal Limiting: There's not much to say about this. I reworked the temporal limiting in ex_contrasharpening(), and added it also to LSFmod, so by disabling spatial limiting with limitS=false you will enable temporal limiting. Depending on source it might work better or worse.

Some examples with the new features:

# Heavy grain denoising (mfilter to filter -blur here- where block matching was bad, aka action scenes, sudden movements). It needs a low pass recover pass that I will add in the future to avoid blending/motion blur effect.

smdegrain(tr=2,mode="temporalsoften",blksize=32,thSAD=900,contrasharp=false,refinemotion=true)
smdegrain(tr=2,mode="temporalsoften",blksize=32,thSAD=300,mfilter=ex_blur(1),contrasharp=true,refinemotion=true)

# Dealing with dark sources

smdegrain(tr=2,thSAD=300,Str=0.4,contrasharp=20,refinemotion=true)

# Using another denoiser and temporal limiting (MC frames directly fed to ex_contrasharpening() so saving a few CPU cycles)

smdegrain(tr=2,thSAD=300,mode="medianT5",contrasharp=true,limitS=false,refinemotion=true)

# Spatio Temporal denoising with recursion (STWM only uses a temporal radius of 2, so you won't see changes past tr=2)

smdegrain(tr=3,thSAD=300,mode="rSTWM",prefilter=5,contrasharp=true,refinemotion=true)

Main alternative denoisers:

Default:  "MDegrain"
tr=1  ->  "medianT" "MedianST", "ML3DEx"
tr=2  ->  "medianT5", "STWM", "GaussT5"
tr<8  ->  "TemporalSoften"

[Pauly Dunne]

I have a question before I take a break....

Do any of you ppl that are constantly improving & testing these filters & scripts, actually do any encoding with them ??

Like I mean a full length, 4K movie with your filters, just to see how they REALLY perform !!!

[tormento]

Originally Posted by Dogway

it only expands from TV range to PC range

Out of curiosity: what is the advantage to expand from TV to PC range if the majority of people will watch the movie on a TV set? Won't the expanded range be discarded by player/tv?

[Dogway]

@Pauly Dunne: Looks like you haven't updated LSFmod to 3.5mix, EX mod still needs to be updated to 3.5. Apparently you got bad timing because I didn't update any of my filters since 2015 and soon I will leave again. If you want to encode 4K you need to relax the settings, I'm sure you didn't live the times where filtering DVDs were at a rate of 0.5fps.

@Tormento: The range expansion is only for the motion vectors, not the denoising clip. Read from here.