Dogway's Filters Packs

[Dogway]

Originally Posted by real.finder

#ex_boxblur(5,mode="mean")
Dither_convert_8_to_16().Dither_box_filter16(5).DitherPost()

but I can see that they are not similar

They are the same, the only difference is that Dither_box_filter16 is frequency domain based so it's faster for higher sigma, when above 5 in ex_boxblur().

a=Dither_convert_8_to_16().Dither_box_filter16(5).DitherPost()
ex_boxblur(4,mode="mean")
ex_makediff(a, aug=true, UV=128)

So if the question is if we need a DFT box filter, probably the answer is yes, same with binomial blur. Of course with HBD support and asymmetric blur option. I would also vouch for porting CTM (Constant Time Median) from VapourSynth, so doing a 5x5 or 7x7 median isn't as slow as it is now.

ex_bilateral() gives same output as vsTBilateral(), speed is similar as well. Dither_bilateral16() employs shortcuts to speed up the process but in my opinion the output doesn't look nice.

Excerpt from docs.

"Actually, this implementation is an approximation of a bilateral filter, like many other image processing tools do. The spatial weighting is not a gaussian curve but a box, and the value weighting is a trapezoid."

Thanks for LimitFilter link, I will have a look when I got time, I've been busy porting *.mp4 sharpeners

[real.finder]

a=Dither_convert_8_to_16().Dither_box_filter16(5).DitherPost()
ex_boxblur(4,mode="mean")
ex_makediff(a, aug=true, UV=128

)

so Dither_box_filter16(x) = ex_boxblur(x-1, mode="mean")

CTM (Constant Time Median) from VapourSynth

https://github.com/pinterf/MedianBlur2

Dither_bilateral16() employs shortcuts to speed up the process but in my opinion the output doesn't look nice.

but there are people who like the Dither_bilateral16 more than others

[Dogway]

MedianBlur2 didn't perform well on my benchmarks, something is going on there, occasionally it would perform "fine" but must of the time it crawls so I don't know.

I will try to post comparison shots for ex_bilateral() and Dither_bilateral16() when I got some time.

[Dogway]

Here's the comparison (brighten to see better):

Converttostacked().Dither_bilateral16(radius=2,thr=10,flat=1.0,u=1,v=1).Convertfromstacked()


ex_bilateral(1)


As you can see Dither_bilateral16() output is very dirty/grainy, and artifacts similar to combing.



By the way, updated SharpenersPack with new sharpeners; SSSharp, ReCon, blah, MedSharp, ex_unsharp and SharpenComplex2

[real.finder]

Originally Posted by Dogway

Here's the comparison (brighten to see better):

Converttostacked().Dither_bilateral16(radius=2,thr=10,flat=1.0,u=1,v=1).Convertfromstacked()


ex_bilateral(1)


As you can see Dither_bilateral16() output is very dirty/grainy, and artifacts similar to combing.



By the way, updated SharpenersPack with new sharpeners; SSSharp, ReCon, blah, MedSharp, ex_unsharp and SharpenComplex2

I think it depends on the settings and the source

here a friend words

Originally Posted by Pauly Dunne

Well, I have tried a lot of different things to diagnose this, but it seems to be on only 4 servers that I use for the Distributed Encoding function of RipBot.

So they are simply connected via a LAN, and don't need the complete program to encode (very clever, actually), and yet other pc's on the LAN don't have the problem,

So I think my only recourse is a fresh setup of Windows.

Update:- It turned out that I needed to update these:-VC_redist.x86.exe & VC_redist.x64.exe

There must be some subtle change in Dog's ExTools & SMDegrain.

I've finally figured out what the problem is....

Even tho it was good to update VC, it's an OpenCL problem when using KNLMeansCL, as a pre-filter in Doggy's SMDegrain !!!

The pc's that have this error haven't got a compatible GPU, and I'm not sure if you can get a "driver" for older Xeon Intel CPU's for OpenCL Support.

[kedautinh12]

Wait a minute, i remember you said you had Ryzen cpu??

Originally Posted by kedautinh12

Wait a minute, i remember you said you had Ryzen cpu??

Good memory, I actually have 2

I also have a few I7 Intels, some E5 Xeons, And a LOT of older X series Xeons.

And the older Xeons have no "proper" Gpu's....

Its a RipBot264 Distributed Encoding set up...

[kedautinh12]

Originally Posted by Pauly Dunne

Good memory, I actually have 2

I also have a few I7 Intels, some E5 Xeons, And a LOT of older X series Xeons.

And the older Xeons have no "proper" Gpu's....

Its a RipBot264 Distributed Encoding set up...

Rich oldman. When you want discard any old amd ryzen 5000 series, can you give me

[Emulgator]

Be kind, ask for grannys. These are good too ;-)

Originally Posted by kedautinh12

You welcome

I'll see you @ the other Forum.

[Dogway]

ExTools updated to v5.4
-ex_vinverse() - small optimization
-ex_blur() - 'bifit' arg to toggle between gaussian or binomial distribution
-ex_guidedblur(), ex_ANguidedblur() - moved to yugefunc.avsi
-ex_GaussianBlur() - New. Optimized true gaussian blur approximation for high sigma
-ex_luts() - bugfix when using two clips. 'exprf' arg to append code to the end.
-ex_shape() - add anisotropy for shapes (except 'cross')
-sel_med() - more medians, fill up to n=49

Just updated ExTools to v5.4, required for my recent updates (from today updates, and before for SharpenersPack). This feels like the last version although I will fix any reported bugs or add things if it feels convenient, but my update rate on ExTools will be much slower from now on.
I also uploaded today v1.0 of SharpenersPack, because it feels very solid. There are possible additions like Oyster, qUINT Sharp, NLM Sharp and other kind of sharpeners, but for now it will stay like this.
Also updated SMDegrain to refine ex_retinex() with the new ex_GaussianBlur() function.

Now I will focus on yugefunc and port worthy functions from VapourSynth, I added a list in the header for the filters I wish to port.
I will also have a look at QTGMC to optimize it more, port Didée's LTSMC, remake ex_vibrance() and whatever arises.

Originally Posted by Dogway

ExTools updated to v5.4
-ex_vinverse() - small optimization
-ex_blur() - 'bifit' arg to toggle between gaussian or binomial distribution
-ex_guidedblur(), ex_ANguidedblur() - moved to yugefunc.avsi
-ex_GaussianBlur() - New. Optimized true gaussian blur approximation for high sigma
-ex_luts() - bugfix when using two clips. 'exprf' arg to append code to the end.
-ex_shape() - add anisotropy for shapes (except 'cross')
-sel_med() - more medians, fill up to n=49

Just updated ExTools to v5.4, required for my recent updates (from today updates, and before for SharpenersPack). This feels like the last version although I will fix any reported bugs or add things if it feels convenient, but my update rate on ExTools will be much slower from now on.
I also uploaded today v1.0 of SharpenersPack, because it feels very solid. There are possible additions like Oyster, qUINT Sharp, NLM Sharp and other kind of sharpeners, but for now it will stay like this.
Also updated SMDegrain to refine ex_retinex() with the new ex_GaussianBlur() function.

Now I will focus on yugefunc and port worthy functions from VapourSynth, I added a list in the header for the filters I wish to port.
I will also have a look at QTGMC to optimize it more, port Didée's LTSMC, remake ex_vibrance() and whatever arises.

Busy, busy, busy...I'm having a hard time just keeping up



Edit :- Unfortunately, since changing up to SMDegrain 3.2.8, I'm getting another Line 161 error...go back to 3.2.7, it's good , when using BM3D in CPU mode.

On further investigation, the difference was :-

function ex_BM3D(clip a, float "sigma", int "radius", int "UV") {

rgb = isRGB(a)
isy = isy(a)
bi = BitsPerComponent(a)

s = Default(sigma, 3)
r = Default(radius, 1)
UV = Default(UV, rgb ? 3 : 1)

ch = !(isy || UV!=3)
ch ? ConverttoYUV444(a,chromaresample="spline16") : a
ConvertBits(bits=32, fulls=fs)

BM3D_CPU(sigma=[s,ch?s/2:0,ch?s/2:0], radius=r, chroma=ch)
BM3D_VAggregate(radius=r)

if (bi < 32) {
ConvertBits(bits=16, dither=-1, fulls=fs)
ConvertBits(bits=bi, dither= 1, fulls=fs)
}
ch ? MatchColorFormat(a) : mergechroma(a) }

full=fs was the only change I could see, so whatever that's for, didn't work for me.

Also note other change in "red" (thanks to kedautinh12)

[tormento]

Originally Posted by Pauly Dunne

Unfortunately, since changing up to SMDegrain 3.2.8, I'm getting another Line 161 error...go back to 3.2.7, it's good , when using BM3D in CPU mode.

Updated to last BM3D of a few days ago?

[tormento]

Originally Posted by Dogway

I will also have a look at QTGMC to optimize it more, port Didée's LTSMC, remake ex_vibrance() and whatever arises.

Is Zs_RF_Shared still required to use SMDegrain?

Originally Posted by tormento

Updated to last BM3D of a few days ago?

I only have a problem when using it in CPU mode..

[Dogway]

@Pauly Dunne: Thanks for the report! I updated SMDegrain, last minute changes are never good. Also added CPU mode but it's not callable from SMDegrain args, just change to CUDA=false in line 159.

@tormento: I think it's needed only for sh_GetUserGlobalIMTint(), but when I used it it didn't report my threads. I still don't know how AviSynth doesn't have a thread reporting internal function...

[real.finder]

Originally Posted by Dogway

@tormento: I think it's needed only for sh_GetUserGlobalIMTint(), but when I used it it didn't report my threads. I still don't know how AviSynth doesn't have a thread reporting internal function...

there are https://forum.doom9.org/showthread.p...53#post1925253 but seems no one use it

[Dogway]

Can avstp report cores/thread as string?

Here an image for ex_shapes(), still need to work out cross anisotropy (EDIT: fixed):

[real.finder]

Originally Posted by Dogway

Can avstp report cores/thread as string?

don't think so, I didn't mean avstp but https://forum.doom9.org/showthread.p...21#post1777021 and https://forum.doom9.org/showthread.p...46#post1778346