Dogway's Filters Packs

[real.finder]

sh_LimitChange looks to me like simple ex_clamp/mt_clamp. In SPresso there are two modes with negative and positive 'Limit' and also additional 'Bias' args. To be honest I haven't researched the algo I simply optimized from Didee's original. There's also a limiter by cretindesalpes that I haven't ported.

Check here (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/Spresso.avsi) if it works fine for you.

I think ex_limitchange should be in ExTools

as for "limiter by cretindesalpes" https://github.com/realfinder/AVS-Stuff/blob/832a3e0d9ff501c04483cb05a34055d121ce531e/avs%202.5%20and%20up/Zs_RF_Shared.avsi#L476

[Dogway]

Thanks! I'm a bit busy with Zopti currently but I will try to optimize when I can. Tuning MAnalyse is important as it impacts QTGMC, FrameRateConverter and SMDegrain by picking the optimal pareto of the convex hull. I also want to finish the Harris corner detection and SAD Analysis tool.
I normally don't add ports to ExTools or at least expressions that I don't have full understanding of, I will check what I do as a limiter is some kind of a mask so also considered MasksPack.

[anton_foy]

Your mod of ChromaReconstructor_faster() is not available anymore? It looks like it does not have a function in the latest transformspack.avsi.

[Dogway]

Thanks for heads up. I fixed "ChromaReconstructor v3mod" and also a few things in TransformsPack. Should work fine now, let me know.

[Boulder]

Is there something broken with ex_minblur, or have I copy-pasted/updated something incorrectly? In this example, the clip 'prefilt' is very much washed out, and if you comment ex_minblur out, it's ok.

clp=DGSource("test.dgi") # regular 8-bit source
prefiltbits=8
orgbits=8

prefilt = clp.convertbits(bits=prefiltbits)
prefilt = prefilt.ex_minblur(r=2, uv=3)
prefilt = prefilt.ex_luma_rebuild(s0=3.0, uv=3)
prefilt = prefilt.convertbits(orgbits)
clp = clp.ex_luma_rebuild(s0=3.0, uv=3)

interleave(clp, prefilt)

[Dogway]

Loader probably didn't write "_ColorRange" frameprops, then ex_minblur() wrongly assumes PC level and writes the frameprops (will investigate this), and the brightening is performed by ex_luma_rebuild() reading the wrong frameprops, for the time being use ex_luma_rebuild(s0=3.0, uv=3, tv_range=true)

EDIT: The output of ex_minblur() is inheriting the frameprops of the masks (ex_makediff()) so that's why it's "_ColorRange" = 0. By changing the clip order this is fixed. Normally I pay attention to this but it might happen somewhere else.
Fixed line in ex_minblur():
ex_lutxyz(clp,rg12D,RG4D,"y "+bi32+" A@ x z - B@ * 0 < x A abs B abs < x A - z ? ?",Y=y,UV=uv,fulls=fs)

[Boulder]

Loader probably didn't write "_ColorRange" frameprops, then ex_minblur() wrongly assumes PC level and writes the frameprops (will investigate this), and the brightening is performed by ex_luma_rebuild() reading the wrong frameprops, for the time being use ex_luma_rebuild(s0=3.0, uv=3, tv_range=true)

PropShow does indicate _ColorRange=1 after loading the source. Using it after ex_minblur shows that the function overwrites the information with _ColorRange=0, so there's something strange happening there.

[Dogway]

Check now, I updated SMDegrain(). Results from Zopti will come on a later version fro v3.5.0.

[Boulder]

Check now, I updated SMDegrain(). Results from Zopti will come on a later version fro v3.5.0.

Thanks, it's working now. Looking forward to seeing what you find out with Zopti :)

[anton_foy]

Thanks for heads up. I fixed "ChromaReconstructor v3mod" and also a few things in TransformsPack. Should work fine now, let me know.

Thanks but I get an error Script error: there is no function named 'SI_physicalcores' on line 105 of the chromareconstructor_v3.2.avsi
My Avs+ version is this Avisynth 3.7.1 FINAL x64 (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.1)

[kedautinh12]

I think it's belong to Sysinfo
https://forum.doom9.org/showthread.php?t=176131

[anton_foy]

I think it's belong to Sysinfo
https://forum.doom9.org/showthread.php?t=176131

Thanks! Now this: KNLMEANSCL:'rclip' doesn't match the source clip! line 120.
Maybe because my clip is 3840x2160?

[Dogway]

What's your call and clip format? is it YV12?

EDIT: Fixed it. Check here (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/ChromaReconstructor%20v3mod.avsi).

[mp3dom]

Uhm, maybe I'm missing something, but just a plain:

colorbars(width=1920,height=1080,pixel_type="yv16")
qtgmc()

gives me a

System Exception - Access Violation
ExTools.avsi at line 67
SMDegrain.avsi at line 797
QTGMC.avsi at line 643

Plugins/scripts are all at the latest versions and AVS+ is 3.7.1

[Dogway]

Works fine here. The error points to ex_luma_rebuild() and this in turn to ex_lut(). Try with a simple call like: "ex_Luma_Rebuild(S0=3.0, uv=3, tv_range=true)"

[mp3dom]

I get the exact same error (at the same lines), but without the last error that refers to QTGMC.avsi)

[Dogway]

If you are on AVS+ v3.7.1 final, SMDegrain v3.4.3 and ExTools v7.2 I might try to test with AVSmeter to check it's not a conflict with AvspMod or the editor you use. You are using AVS+ x64 right?

Try this:
s0= 3.0
c = 1.0/16
k = (s0 - 1) * c
l = 1 - k
d = 1 + c
f = d * c
Expr(Format("f32 {k} {d} {f} x ymin - 0 max ymax ymin - / A@ {c} + / - * A {l} * + range_max *"), "x cmin - range_max cmax cmin - / *", \
scale_inputs="none", clamp_float=false, lut=1)

[mp3dom]

Yeah, AVS is the final 3.7.1, SMDegrain is 3.4.3d, ExTools 7.2 and QTGMC 3.73. Had same errors on both x86/x64 with VDub2 but something strange happened. I've reinstalled 3.7.1 final using the installer (previously I replaced just the .dll) and now it works on x64 but still I have the same error under x86, but considering you asked me about x64, I guess that's to be expected?
Thanks!

Edit: Oh, and by the way...
Try this:

This works on x64 but gave me access violation on x86 on the last line (scale_inputs=...)

[Dogway]

anton_foy was having issues before with x86. I think there's something odd in x86 AVS+ but pinterf has to confirm, simply by testing the above Expr() call.


Edit: Oh, and by the way...

This works on x64 but gave me access violation on x86 on the last line (scale_inputs=...)

Ok, so 'scale_inputs' is broken on x86, I will try to ask pinterf when he's around.

[mp3dom]

Oh well, at least now I can use it on x64, which is better than nothing.
Thanks.

[anton_foy]

Thanks for heads up. I fixed "ChromaReconstructor v3mod" and also a few things in TransformsPack. Should work fine now, let me know.

Thanks although I get now: KNLMEANSCL: Fatal error! (AvisynthGetFrame)

EDIT: aha when I use ex_knlmeanscl() I also get this error but using ordinary knlmeanscl() it works but I don't know if that helps.

[Dogway]

Post your call and source resolution.

[anton_foy]

Post your call and source resolution.

Source resolution: 3840x2160

Sorry I decieved you (not on purpose) it was ex_KNLMeansCL(D=2, A=1, h=1, s=6, device_type="gpu") that is giving me the error.

So the following does NOT give me error:
ex_KNLMeansCL()
KNLMeansCL()
KNLMeansCL(D=2, A=1, h=1, s=6, device_type="gpu")

ClearAutoloadDirs()
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\mp_pipeline.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\lsmashsource.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\gradationcurve_x64.dll")
#LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\manyPlus.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\awarpsharpmt.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\hqdn3d.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\fft3dgpu.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\rgtools.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\masktools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\SysInfo64.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\deblock-x64.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\KNLMeansCL.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\vscube.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\vscnr2.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\neo-f3kdb.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\neo-dfttest.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\neo-fft3d.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\reduceflicker.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\fastblur.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64\dctfilter.dll")
import("C:\Program Files (x86)\AviSynth+\plugins\Deblock_QED_MT2.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\gradepack.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\deblockpack.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\maskspack.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\extools.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\knlmc.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\transformspack.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\resizerspack.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\smdegrain.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\chromareconstrucor.avsi")
import("C:\Program Files (x86)\AviSynth+\plugins\basiq.avsi")


#Index
LSMASHVideoSource("C:\Users\comp\Videos\C0561.mp4")


convertbits(16) #bits=16,fulls=true
Deblock_QED_mt(quant1=26, aOff1=1, aOff2=1, bOff1=2, bOff2=2, uv=3)
Levels(0, 1, 255*256, 0, 235*256, coring=false, dither=false)

#### Denoise ###
#ChromaReconstructor_faster()
ex_KNLMeansCL(D=2, A=1, h=1, s=6, device_type="gpu")
#KNLMeansCL(D=2, A=1, h=1, s=6, device_type="gpu")

#Chroma Upscaling
ConverttoYUV444()
ConvertBits(bits=10, dither=1)

Prefetch (SI_PhysicalCores ())

[Dogway]

Works ok for me with your script and using also a 4K source clip.
Maybe this might be a memory issue, try to play with SetMemoryMax(16384/n) # 'n': 1, 2, 4, 8

In any case the issue might be instead VRam, try to remove all calls except ex_KNLMeansCL(), if that doesn't work, resize your clip to half size and test again if you still get the issue.

[DTL]

New idea about degraining processing with MDegrainN added - https://forum.doom9.org/showthread.php?p=1962418#post1962418 . Also new params to adjust by content. Now it is possible to lower thSAD 'old/general' param significantly to try to keep low contrast textures better while keeping the same or better 'denoise strength' in terms of lower output MPEG encoded speed/filesize. Though still only implemented with MDegrainN (not with fixed-tr MDegrainX). Also speed will be somehow lower because of new conditions checks added.

[tormento]

@Dogway

Am I wrong or did you plan to convert to XYZ color space before denoising?

[Dogway]

XYZ is not a perceptually uniform space, IPT or OkLab are but conversion is slow so I don't know to what degree it might be useful. What I might add is a HUE plane for MAnalyse for better detection of chroma MV, but this has implications of current settings so I need more testing for correlation and magnitudes.

I just uploaded some updates for my other scripts so maybe now I have more time for MVTools tests.

[Boulder]

Can you tell me if the "grid" which appears with ex_makediff is normal with this script? I noticed that it appears with HBD input to SPresso even with rather light options like limit=0.5, I've increased the limit here to make it more obvious.


DGSource("clip.dgi",ct=140,cb=140)
ConvertBits(bits=16)
test=spresso(bias=20, biasc=40, limit=2.5, limitc=5, rgmode=4, rgmodec=4)
ex_makediff(last, test, aug=100)


https://i.ibb.co/ZSPBFKg/lotr-spresso-grid.png (https://ibb.co/ZSPBFKg)


EDIT: hmm.. I suppose they are macroblock boundaries so should be ok.

[Dogway]

Sorry I was watching Nadal's match :rolleyes:
Yes it's normal, they are compression DCT blocks, normally they are not seen but at x100 they are visible. I've seen worse than that example so it's ok.
Here's an HBD vs 8-bit example. Only at x100 you start to see some difference (basically quantization difference) so they are a practical match
test1=spresso(bias=20, biasc=40, limit=2.5, limitc=5, rgmode=4, rgmodec=4).ConvertBits(bits=16)
ConvertBits(bits=16)
test2=spresso(bias=20, biasc=40, limit=2.5, limitc=5, rgmode=4, rgmodec=4)

ex_makediff(test1, test2, metric="none", aug=100, dif=true, show=2)


Some summary of what I'm doing right now:

I'm yet to update a few scripts to level them out to current ExTools and LSFmod, namely SMDegrain and TransformsPack. SharpenersPack has also seen some optimization edits yet to upload.

I updated LSFmod to v5.0, following old Didée's notes and porting some original LSF concepts, mainly turning LSFmod into a capable HD sharpener. I also simplified, improved and optimized the code, merging preblur and secure code into the sharpening expression, and replacing preblur denoising with ex_minblur() and edge method to kroon which is both better and faster. I have to give the limit modes a second look to check how it behaves with the updates but most probably they are ok.

I'm also making a deep_resize() filter, which again simplifies+optimizes the original nnedi3_resize16(). It's one of my preferred upscalers but I didn't like it had so many dependencies specially the Dither tools and that it was slow. It won't be limited to nnedi3 but any preferred upscaler ("nnedi3", "FSRCNN", "FCBI", "SuperResXBR") because it will call ConvertFormat() internally. This allows you to simply call the kernel by its alias ("DPID","Mitchell","Catrom","Zopti"...) and ConvertFormat() will take care of everything else. I fixed some scalers implementations there and added more EWA lanczos modes by Robidoux recommendations. In order to make deep_resize() I will need to finally port limit_dif(), I will try to compare all version and find the sweet spot. That will open the doors for a debanding filter.

After that (or meanwhile) I have some ideas to develop a 1-pass scene based workflow with SC lookahead. Port some more color models (ZCAM, etc) and make an SDR to HDR filter.

[tormento]

Some summary of what I'm doing right now
What I would like to see: a white balance filter without n dependencies, aware of scene change and resilient to mostly black background with small amount of foreground enlighted objects.

And, yes, some stabilization filter inside SMDegrain, to recycle otherwise wasted vectors.

[Dogway]

What do you mean without n dependencies? GreyWorld() only requires ExTools, RgTools (might drop it) and TransformsPack.
In any case I have already the idea for SC detection that will enable scene based filtering. This will actually turn things around workflow-wise, so probably it will require adapting some of my high-level filters(?) sigh!

The current problem with GreyWorld, aside of temporal stability is that I didn't manage to align the gamut assymetry so I have to look into that a bit further. Also I probably should look for color cast/tint only on the 10% brightest percentile to have a more accurate reading (after all it's called WHITE point), but I need to test.

As for stabilization, it's a bit of a rabbit hole which I tend to avoid (like the MVTools' Zopti optimizations) so I don't get stuck in things for too long. The thing with reusing motion vectors is that you probably don't want the jittery MV for degraining, it will mostly imply creating new vectors.

I just ported latest LSFmod to EX mod, ex_limitdif() (VERY optimized) and deep_resize() (initial version but already faster (x8) and higher quality than nnedi3_resize16() ). Will upload tomorrow.

[Dogway]

Here are a few examples of deep_resize() compared to nnedi3_resize(). It's sharper while being over 4 times faster.
It's not a straight port since I added a few ideas of my own, to start with the flat resizer is now SincResize. Also the edge pass with nnedi3 which is naturally on the soft side is sharpened with LSFmod (very slightly), it's fast because of my last update. With this I noticed a big contrast change in the image, it wasn't because the sharpener but because nnedi3 and the support resizers. Well this contrast just happens to be low frequency "sharpening" akin to what you can do with ex_unsharp(), can't I undo it? Yes, I did a very small tweak to ex_unsharp() and now you can deconvolute, it gives a less coarse image while keeping high frequency sharpness. I will be uploading in the next few hours.

raw (sorry @Tormento for beating this sample lol)
http://i.imgur.com/09rWtGpm.png (https://i.imgur.com/09rWtGp.png)
spline36 (from 'Zopti' downscaled 720p)
http://i.imgur.com/pukfKorm.png (https://i.imgur.com/pukfKor.png)
nnedi3_resize16
http://i.imgur.com/PmIIxuTm.png (https://i.imgur.com/PmIIxuT.png)
deep_resize
http://i.imgur.com/ebb5TUCm.png (https://i.imgur.com/ebb5TUC.png)
deep_resize v2
http://i.imgur.com/HcAbAofm.png (https://i.imgur.com/HcAbAof.png)

spline36 (sample from FranceBB)
http://i.imgur.com/nvC3LfXm.png (https://i.imgur.com/nvC3LfX.png)
nnedi3_resize16
http://i.imgur.com/xC1qz64m.png (https://i.imgur.com/xC1qz64.png)
deep_resize
http://i.imgur.com/nbd7qdum.png (https://i.imgur.com/nbd7qdu.png)
deep_resize v2
http://i.imgur.com/sJV4EwVm.png (https://i.imgur.com/sJV4EwV.png)

[guest]

Hi Dogway, I've hit a bit of a "wall", and I don't know when what causes my problems, happened.

I have been "religiously" updating my scripts, whenever you release new ones (that I use), and I have been testing them to see if they at least pass a AVSMeter "test", but haven't been encoding with them until recently, and to my despair, I am getting errors when using certain scripts, mainly when using BM3D.

I know that SMDegrain is pretty complex, and maybe I'm missing something, especially when it comes to get BM3D to use CPU or CUDA commands.

The error is :- y4m [error]: bad sequence header magic
x264 [error]: could not open input file `-'
I have noticed in the past that this has been associated with an OpenCL problem, BUT the KNLMeansCL scripts DO work.

I have been backdating my scripts to see if I can find a point where the error doesn't occur, with no luck, yet.

I'm not sure if there's been a change with BM3D, or some of your updates have affected how BM3D is used, maybe there's more or different dependencies for recent builds.

So any suggestions would be greatly appreciated.

[Boulder]

It would be much easier to debug if you open the script in VirtualDub, or any other tool that would give the exact error message and hopefully the position as well.

[Dogway]

@TDS, with yesterday updates all the packs are now in sync and should work without issues. Normally errors will come from bugs from AVS+ x86, the plugins or the client (AVSmeter, AvsPmod...), and occasionally my fault. Just attack one at a time.
To be honest when testing BM3D a week ago I saw artifacts I didn't like, I'm not sure if it was always the case but it seemed to denoise only vertically. With that said I don't get that error, try to open in another client software to reproduce the issue. Also that hyphen error message(?) do you have strange unicode characters in your x246 output path or filename?

I will try to have a closer look later today and prepare a simple BM3D call for you to test.

[guest]

@ Boulder & Dogway, thanks for your prompt replies & suggestions...I need to remind you that I use RipBot264, and it's taken me quite a while (with help from this Forum) to incorporate these scripts into the app, and have them work successfully....I'm pretty sure I had it all running sweet several weeks ago (haven't done much for a long time, except update my scripts), so like I said earlier, I ONLY test them within RipBot264, and it uses AVSMeter to "check" the scripts, and it a little vague in "pinpointing" the actual error :(

RipBot264 uses a Distributed Encoding feature, and my problem is mainly showing up on the "remote" encoding PC's, not on the Main PC, but it's not on ALL of them, despite them all being set up the same, and there's where it becomes even more frustrating.

It's quite a time consuming process, and I'm sure you're more than aware.

Thanks

[pinterf]

anton_foy was having issues before with x86. I think there's something odd in x86 AVS+ but pinterf has to confirm, simply by testing the above Expr() call.



Ok, so 'scale_inputs' is broken on x86, I will try to ask pinterf when he's around.
Pls report bugs, I accidentally found this, so yes, there was a bug (an unaligned internal buffer) which affected LUT operation on AVX2 machines. I'm gonna make a test build later.

[Dogway]

Yes sorry had a few busy days. Aside from scale_inputs there might also an issue with 'lut' arg in Expr (ah yes what you said) and frameprops calls outside runtime environment but I can't tell because I don't use AVS x86, this is all from what users report to me. In x64 everything seems to work fine on my side.

[Fjord]

@Dogway, I'm very appreciative of your work on optimizing plugins with ExTools etc. And thanks also to all the other great contributors here!
I need some help understanding the mod versions. "EX" mods seems obvious, but what is a "MIX" mod? And why are there both EX and MIX versions of LSFmod? I don't know which I should be downloading. Or are they the same?

[Dogway]

EX mods is kind of what I would like it to be, everything run from internal functions, low dependencies.
MIX mods in turn has more dependencies as it uses RgTools, masktools2, etc

The reason I had to make MIX mods is because some operations are slower with internal code like Expr() pixel addressing being only SSSE3 accelerated vs masktools2 which uses AVX2.
ex_merge() is also generally slower than mt_merge(), and removegrain(12) or removegrain(4) are insanely faster than than ex_boxblur(mode="weighted") or ex_median("median") respectively.

In general terms MIX mods are slightly faster but output should be the same.

[StainlessS]

Maybe a Doggy glossary is in order.

[Dogway]

hahaha and I thought it was clear in OP.

[gispos]

I like to use this function (found here somewhere), but it's not the fastest. Does anyone see potential to make it faster or improve it. HBD > Dogway?

function Highlighter(clip v, float "gblur", bool "gradient", int "threshold", bool "twopass", int "amount", int "method")
{
gradient = default (gradient,true)
gblur = (gradient==true) ? default (gblur,100) : default (gblur,5.0)
threshold = default (threshold,100) #The lower the value, the more sensitive the filter will be.
twopass = default (twopass,false)
amount = default (amount,10)
method = default (method, 1) #0,1,2

amount = (amount<0) ? abs(amount) : amount

lighten= v.Tweak(sat=0).mt_lut("x "+string(threshold)+" > 0 x ?")
blurred= (gradient==true) ? lighten.gaussianblur(gblur).gaussianblur(gblur+100).gaussianblur(gblur+200) : lighten.gaussianblur(gblur)


photoshop_overlay = (method==1) ? mt_lutxy(v,blurred.invert(),"x 127.5 > y 255 x - 127.5 / * x 255 x - - + y x 127.5 / * ? ") : \
(method==2) ? mt_lutxy(v,blurred.invert(),"255 255 x - 255 y - * 255 / -") : v.Tweak(bright=amount)

photoshop_overlay = (twopass==true) ? photoshop_overlay.SmoothLevels(gamma=2.0, Lmode=2) : photoshop_overlay
return mt_merge(v,photoshop_overlay,blurred)
}

[Dogway]

Yes, big potential, give me some minutes.

EDIT: Here it is. By the way, what is it for?

function Highlighter(clip v, float "gblur", bool "gradient", int "threshold", bool "twopass", int "amount", int "method") {

bi = BitsPerComponent(v)
fs = propNumElements (v,"_ColorRange") > 0 ? \
propGetInt (v,"_ColorRange") == 0 : false

grad = Default (gradient,true)
gblur = Default (gblur, grad ? 100 : 5)
thres = Default (threshold,100) #The lower the value, the more sensitive the filter will be.
twopass = Default (twopass,false)
amount = Default (amount,10)
method = Default (method, 1) # 0, 1 or 2

amount = ex_bs(abs(amount), 8, bi, true)
thres = ex_bs(thres, 8, bi, true)

lighten = v.ex_lut(Format("x {thres} > 0 x ?"), UV=128)
blurred = grad ? lighten.ex_gaussianblur(0.073*gblur+17.78,UV=1) : \
lighten.ex_gaussianblur(0.064*gblur+ 3.75,UV=1)


photoshop_overlay = (method==1) ? ex_lutxy(v,blurred,"x range_half > range_max y - Y@ range_max x - X@ range_half / * range_max + Y x range_half / * ? ", fulls=fs) : \
(method==2) ? ex_lutxy(v,blurred,"range_max range_max x - y * range_max / -",fulls=fs) : v.ex_lut(Format("x {amount} + ")+(!fs?"ymax min":""), fulls=fs)

photoshop_overlay = twopass ? photoshop_overlay.ex_contrast(-0.8,1,167,tv_range=!fs) : photoshop_overlay
return mt_merge(v,photoshop_overlay,blurred) }

[gispos]

Yes, big potential, give me some minutes.

EDIT: Here it is. By the way, what is it for?


To brighten up dark scenes (Maybe wrongly worded, 'dark areas' is probably more correct).
Will test your changes with a 'Preview Filter'. :D
Thank you!

[gispos]

What am I missing?

Script error: There is no function named 'nmod'.
(D:\Tools\AviSynth\plugins64\DogwayFilters\ExTools.avsi, line 1691)

Found:
Located in ResizerPack.avsi
Hm, wouldn't it make more sense to put it in ExTools.avsi.

I don't really want to have to load all your packs... that's too much 'resources' for me if I only want to use one function 'ex_Highlighter'

Now I get:

Expr: Failed to convert '{amount}' to float
(D:\Tools\AviSynth\plugins64\DogwayFilters\ExTools.avsi, line 67)

[Dogway]

Yes sorry, I forgot to add Format() to the expression (edited), I got a phone call in between and got distracted.
Don't be like that, it's only 5 packs, I really don't like scripts that are like a junkyard where you put everything in it with no correlation.
ExTools is only for core filters, low level or build block functions. I only try to be conservative at big names like SMDegrain or QTGMC.
Give the functions a try, mmod(), PadBorders(), deep_resize(), you will surely get in the loop and won't come back :P

[gispos]

Hi Dogway,
the 'Highlighter' filter is now called 'ex_Highlighter' and is 6 - 8 times faster with almost identical results. So full success.

And therefore (if you feel like it) you may try the opposite function. 'HighlightLimiter' and 'HighlightLimiterMod'
The filter reduces too bright areas. The mod version was changed by me (long time ago).

function HighlightLimiter(clip v, float "gblur", bool "gradient", int "threshold", bool "twopass", int "amount", int "method")
{
gradient = default (gradient,true) #True uses the gaussian blur to such an extent so as to create an effect similar to a gradient mask being applied to every area that exceeds our threshold.
gblur = (gradient==true) ? default (gblur,100) : default (gblur,5.0) #The strength of the gaussian blur to apply.
threshold = default (threshold, 160) #The lower the value, the more sensitive the filter will be.
twopass = default (twopass, false) #Two passes means the area in question gets darkened twice.
amount = default (amount, 20) #The amount of brightness to be reduced, only applied to method=2
method = default (method, 0) #0,1 Method 0 is multiply, the classic HDR-way. Any other method set triggers a brightness/gamma approach.

amount = (amount>0) ? -amount : amount

darken=v.Tweak(sat=0).mt_lut("x "+string(threshold)+" < 0 x ?")
blurred= (gradient==true) ? darken.gaussianblur(gblur).gaussianblur(gblur+100).gaussianblur(gblur+200) : darken.gaussianblur(gblur)
multiply = (method==0) ? mt_lut(v,"x x * 255 /") : v.Tweak(bright=amount)
multiply = (method==0) ? eval("""
(twopass==true) ? mt_lutxy(multiply,v,"x y * 255 /") : multiply""") : eval("""
(twopass==true) ? multiply.SmoothLevels(gamma=0.9, Lmode=2) : multiply""")

return mt_merge(v,multiply,blurred)
}

function HighlightLimiterMod(clip clp, Int "threshold", Int "dark", Int "rad", int "mode", float "gamma1_2"){
threshold=default(threshold, 160)
dark=default(dark, 255)
rad=default(rad, 64)
mode=default(mode, 0) # 0,1,2
gamma1_2=default(gamma1_2, 0.6) # for mode 1,2

m = clp.Width() >= clp.Height() ? clp.Height() : clp.Width()
rad = round(m/rad/4) < 1 ? max(round(m/4.0),16): rad
darken=clp.Tweak(sat=0).mt_lut("x "+string(threshold)+" < 0 x ?")
blurred=darken.bicubicresize(round(clp.width()/rad/4)*4, round(clp.height()/rad/4)*4).bicubicresize(clp.width(),clp.height(),1,0)
multiply = (mode==0) ? mt_lut(clp,"x x * " + string(dark) + " /") : (mode==1) ? SmoothLevels(clp, gamma=gamma1_2) : mt_lut(clp,"x x * " + string(dark) + " /").SmoothLevels(gamma=gamma1_2)
return mt_merge(clp,multiply,blurred)
}

Thanks already

[guest]

Hey Dogway, and the updates just keep on coming...

So I just noticed in the latest iteration of SMDegrain, that KNLMeansCL (pre filter=5) has "disappeared" !!!!

In it's place, has appeared DGDecNV !!!! How does that work.

Can "we" have KNLMeansCL back ???

I haven't done anymore testing BM3D since my post a few days ago (been busy with other things), I will post my script & call's soon, and I would appreciate your help with that.

Have the dependencies for BM3D changed recently ??

[kedautinh12]

You can try TemporalDegrain2 (postFFT=4), that option have KNLMEANSCL :D