Dogway's Filters Packs

[kedautinh12]

I don't know why they need develop back to old ver (2012) when avs+ still development???

[Dogway]

Don't worry I'll open a poll tomorrow and see what people decide, fragmentation or unification.

Does this updating the rest of the filters includes filters that QTGMC is relying on. I have downloaded all the necessary files and about to test your QTGMC and do some comparison. Should i hold off a bit until you finish your update or what?

You can use it, there's nothing in the new updates that affect QTGMCp.

[gispos]

I'm not that far behind.:) Had already posted my Version, 'QTGMC 3.382 2021 mod by A.SONY, based on v3.33d by Dogway'
With QTGMC I don't want to start discussions and stress now. Leave everything as it is, I just have to find a solution myself.

I also understand Dogway, everything neatly in one file, and so that there are not multiple versions using the same names. At first glance, that's also kind of reasonable.
In my opinion, however, this is not the right way. Functions are replaced in the background. Of course, this can also happen the other way. Someone wants to use Dogway's filter but a filter with the same name is loaded later and so Dogway's filter is replaced.

For me, the whole thing then becomes opaque, and I have to look everywhere to see what is now being used.
And if a version of Dogway should require other values or even have other parameters, it will be cruel.

[real.finder]

ok, so I will bring back this https://pastebin.com/raw/SYMD7ij5 QTGMC to https://github.com/realfinder/AVS-Stuff and make the STGMC as a wrapper for QTGMC but with TV_range as true by default

[Ceppo]

Now I'm going to make my QTGMC as well just to confuse everyone more :) thanks for the mod versions!

[gispos]

ok, so I will bring back this https://pastebin.com/raw/SYMD7ij5 QTGMC to https://github.com/realfinder/AVS-Stuff and make the STGMC as a wrapper for QTGMC but with TV_range as true by default
You don't have to do this for my sake. Do what is best for you and others.
Thanks!

[2ndR]

ChromaReconstructor does not work with the following error message
ChromaReconstructor_faster is working

Expr:All inputs mus have the same number of planes and the same dimensions, subsampling included
(ExTools.avsi, line 459)
(ChromaReconstructor v3mod.avsi, line 54)

ImageSource("chroma-444.png", pixel_type = "RGB48")
ConvertToYUV420(matrix = "Rec709")
u = ExtractU().nnedi3_rpow2(rfactor = 2, nns = 4, qual = 2, pscrn = 4, opt = 3).Spline36Resize(width, height, src_top = -0.5)
v = ExtractV().nnedi3_rpow2(rfactor = 2, nns = 4, qual = 2, pscrn = 4, opt = 3).Spline36Resize(width, height, src_top = -0.5)
YToUV(u, v, last)
ChromaReconstructor()

[Dogway]

Yes, it seems to be broken, I made an annotation in the offending line here (https://github.com/Dogway/Avisynth-Scripts/blob/532fbbc3f8d04889fd6a91e1e3e9e509794bbf23/MIX%20mods/ChromaReconstructor%20v3mod.avsi#L54). I have to look closer though. Can you use the faster version?

EDIT: Ok, saw the issue, will be uploading soon along a batch of other updates.

EDIT2: Done, check here (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/ChromaReconstructor%20v3mod.avsi).

[2ndR]

Confirmed to work properly
Thanks for the quick turnaround!

[gispos]

Dogway,
you can have a look at ex_contrast the lower code gives a division by 0 if cont == 0.0

cont = pow(cont + sign(cont), 3.)
rcont = 1. / cont

[Dogway]

you can have a look at ex_contrast the lower code gives a division by 0 if cont == 0.0

Does it output any error? I saw it but it works fine on my end.

[Ceppo]

Dogway,
you can have a look at ex_contrast the lower code gives a division by 0 if cont == 0.0
If you do 1/0 you get the division by zero error, if you do 1./0 it gives infinity and won't give you an error.

[Dogway]

If you do 1/0 you get the division by zero error, if you do 1./0 it gives infinity and won't give you an error.

Nice to know, wasn't aware of that.

By the way, I plan to upload a kind of special video/tutorial for AvsPMod to feature function definitions, sliders and preview filters, so beginners can get a handle of how things work and also get to know more about some of the more complex filters of my packs like ConvertFormat(). Maybe in a few weeks.

[Blankmedia]

With

QTGMCp( Preset="Slower", InputType=2 )

and


QTGMCp( Preset="Slower", InputType=3 )

I got an error in line 832 of QTGMCp

mt_merge( innerClip.nonyuy2clipin(true), edi1.nonyuy2clipin(true), inputTypeBlend, U=2,V=2 ))

MT_MERGE : Clip should have identical bit depths

Thank you for your good work

[Dogway]

in HBD right. Will have a look.

EDIT: Fixed (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/QTGMC%2B.avsi).

[gispos]

Does it output any error? I saw it but it works fine on my end.

If you do 1/0 you get the division by zero error, if you do 1./0 it gives infinity and won't give you an error.
Is already so written 1./0, nevertheless with me an error message comes if I use the avisynth.dll with another program 'AvsPThumb'.
I don't know what the problem is, there must be a hidden switch in avisynth that I haven't turned on. So it would be desirable to fix that. Thanks.
https://i.postimg.cc/SQdGV0t5/error.jpg (https://postimages.org/)


By the way, I plan to upload a kind of special video/tutorial for AvsPMod to feature function definitions, sliders and preview filters...
Now that is surprising, I had also planned. Time saved...;)

[Dogway]

Ok, I added epsilon. This issue could be in other functions though so it needs reporting when that happens.

Now that is surprising, I had also planned. Time saved...;)
I don't know when I'm gonna do it, if I do it at all, I still have ton of things to finish before.

[anton_foy]

Included at the first page are benchmarks of sharpeners. What is XshapenPlus and CasP? These I cannot find them anywhere.

[Dogway]

I just renamed the functions (update SharpenersPack), it's better to keep some consistency so I'm renaming some filters (especially mods) with the "ex_" prefix so you can search them starting from their original name.

[gispos]

I don't know when I'm gonna do it, if I do it at all, I still have ton of things to finish before.
It's the same with me, I've only had it in my head for about 2 weeks. But when I will really start it...
it doesn't matter if there will be more than one video... so who tackles it first doesn't matter.
If it suits you, go for it.

Another topic.
I have read through my recent responses to your postings. I can't find an angry response.
Only the last sentence of mine could be misinterpreted. I forgot to put a smile on it.

I think the whole thing is a misunderstanding, you think I'm annoying and I sometimes think your posts don't read like feedback but more like nagging.
In these times we need peace.

[Dogway]

The idea for the video came to me the last week while working on ConvertFormat() I realized there are many hidden features, like say set kernel as Lanczos8 instead of Lanczos to define the taps. The different aliases that ConvertFormat supports, check the 'show' panel, play with the preview filters and sliders to show how the curve changes in real time for example in ex_contrast(), etc. I also want to showcase GamutWarning 'show' panel and explain its options, same with SoftLimiter and a few more filters. So it's not only AvspMod.

The problem for recording is two sided, I only have a classic microphone from 20 years ago (at least its a shure) but without a pedestal and it's a pain to set up. And the other my monitor is 4K so everything would look too small for those with 1080p monitors.

Also I'm yet to finish ConvertFormat's more flagrant issues, do SceneChange and SceneStats and finish MVTools correlations probably having to implement CoS by hand. There are a few more little things but I won't do.


https://forum.doom9.org/showthread.php?p=1943568#post1943568
https://forum.doom9.org/showthread.php?p=1944894#post1944894
https://forum.doom9.org/showthread.php?p=1950216#post1950216
https://forum.doom9.org/showthread.php?p=1957617#post1957617
https://forum.doom9.org/showthread.php?p=1961128#post1961128
https://forum.doom9.org/showthread.php?p=1962333#post1962333
https://forum.doom9.org/showthread.php?p=1963062#post1963062
https://forum.doom9.org/showthread.php?p=1964768#post1964768
https://forum.doom9.org/showthread.php?p=1965507#post1965507

The common evasive or snarky comments. It doesn't affect me, used to, but now I'm calm like zen :D It's a bit sad because I do care a lot about user experience and half (or more) of my observations are directly ignored or dumped, some not of course and I do appreciate but AvsPmod has a lot of potential, I rarely repeat myself so those suggestions are now in the thrash bin. You say "do it yourself", no thanks I hate python to death, just about to install Julia and start learning a sane language (+maths).

For months I had a list of AvspMod UX quirks that I drip-feed as to not overload you. I guess before retiring here I will post them all at once, and whoever sees that can keep improving the program. "nagging"... might be reading too much, reporting != nagging, actually quite the contrary, it's someone using the tools you created, caring for them and giving you in return some feedback. Some people bring their daily affairs frustrations online so I can understand, but I do not, I don't have social media or anything. For me online is reading news, learning and working, nothing else.

[gispos]

You will have to learn Python after all.
Because I will only take it slowly, there are other things in life. If here and there is a bug to find or smaller things that do not cost me my nerves.

I had not seen the whole extent at the beginning and wanted to change for me personally only a few small things.
But then it just didn't stop, and the next big thing would be to update AvsPmod to Python 3, but I am too 'late' for this...

So I will slowly retire and continue only as I please, otherwise I'd like to leave the field to younger people with more verve.
Greetings.

[videoh]

Don't let the entitled script kiddies get to you, gispos. You are a legend.

[kedautinh12]

I think Dogway learned Python cause he ported some scripts from Vapoursynth to Avisynth:D

[Dogway]

Don't let the entitled script kiddies get to you, gispos. You are a legend.
videoh (neuron2) is just a troll who spreads (https://forum.doom9.org/showthread.php?p=1965710#post1965710) hate (https://forum.doom9.org/showthread.php?p=1954197#post1954197) around (https://forum.doom9.org/showthread.php?p=1963049#post1963049) and I don't know how he is not censored already (again). Do you realize Python is also script based? Are you insulting gispos as well?

I have ported from GLSL, C, C++, Python and assembly. It's pretty ridiculous for some programmers to feel superior and talk down to others just because they don't use their beloved programming language. It's like a painter laughing out at another painter because they use a lower grade canvas when they can't even draw a hand (while not even using the highest grade canvas).

The all glory C++ is already phased out by Rust, and Python slowly by Julia. As for AVS+, your beloved C++ mt_luts() is in several orders of magnitude slower than ex_luts().

I know Python, I made myself some (https://github.com/Dogway/Computer-Graphics-Tools/tree/master/Blender%202.8x) addons (https://www.artstation.com/artwork/W214QE) for Blender to make it behave with Pies more like Maya's MarkingMenus and more additions, it took me several months. I also use Python for external scripts. It's just a horrible language to work with and I'm weeks away from leaving Doom9 so I don't care about AvsPmod, just thought on helping while I was here, to those that care to listen that is.

[guest]

@ Dogway, this is a little scary, we've lost way too developer's recently, hopefully you're not serious....

I'm weeks away from leaving Doom9

I could understand if you do, it can be a thankless task.

I certainly appreciate what you've done, and even tho I've probably only scratched the surface, it's improved what I do.

Cheers

[anton_foy]

videoh (neuron2) is just a troll who spreads (https://forum.doom9.org/showthread.php?p=1965710#post1965710) hate (https://forum.doom9.org/showthread.php?p=1954197#post1954197) around (https://forum.doom9.org/showthread.php?p=1963049#post1963049) and I don't know how he is not censored already (again). Do you realize Python is also script based? Are you insulting gispos as well?

I have ported from GLSL, C, C++, Python and assembly. It's pretty ridiculous for some programmers to feel superior and talk down to others just because they don't use their beloved programming language. It's like a painter laughing out at another painter because they use a lower grade canvas when they can't even draw a hand (while not even using the highest grade canvas).

The all glory C++ is already phased out by Rust, and Python slowly by Julia. As for AVS+, your beloved C++ mt_luts() is in several orders of magnitude slower than ex_luts().

I know Python, I made myself some (https://github.com/Dogway/Computer-Graphics-Tools/tree/master/Blender%202.8x) addons (https://www.artstation.com/artwork/W214QE) for Blender to make it behave with Pies more like Maya's MarkingMenus and more additions, it took me several months. I also use Python for external scripts. It's just a horrible language to work with and I'm weeks away from leaving Doom9 so I don't care about AvsPmod, just thought on helping while I was here, to those that care to listen that is.

You are going to leave doom9??? But why? To me you are top reason of being here it is such a joy and amazement to see all your updates. What you do is mind blowing! Come on :confused:

[kedautinh12]

I think you need complete all scripts WIP and RC ver before leave doom9 :D

[videoh]

I'm weeks away from leaving Doom9 Any chance to pull up the schedule?

Maybe this forum will suit you better:

https://digitalvideofordummies.blogspot.com/

Or come on over to the DG tools forum. I hang out there a lot. We can be buddies.

[guest]

Doesn't QTGMC require vinverse anymore ??

[Dogway]

Doesn't QTGMC require vinverse anymore ??

Why? It requires it. I updated QTGMC+ replacing some ex_vinverse() calls with vinverse(), as Asd-g updated and optimized the plugin.

[guest]

Why? It requires it. I updated QTGMC+ replacing some ex_vinverse() calls with vinverse(), as Asd-g updated and optimized the plugin.

Well it's just that I updated QTGMC, and the next time I went to run it, it had a problem with vinverse, so I need to change something in my script, so what do I need to change ?

[Dogway]

Download Vinverse (https://github.com/Asd-g/vinverse)by Asd-g and update QTGMC+ (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/QTGMC+.avsi). If you still run into issues let me know.

[guest]

Download Vinverse (https://github.com/Asd-g/vinverse)by Asd-g and update QTGMC+ (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/QTGMC+.avsi). If you still run into issues let me know.

Yep, all good, once again, Thanks :)

[Dogway]

This is the first version of SceneRange(). It pushed me to the limits for the last week, besides I wasn't very focused due to birthday celebrations, repo bug reports, etc.
The filter writes "_SceneRange" frame properties with lookahead, so at the start of the scene you already know on what frame it ends. This is useful for scene based stats/filtering.

If you see something odd or that can be optimized please chime in, I need all the help here.

# Dependencies ResizersPack()
# Core SC algo from ScSelect_HBD()

function SceneRange(clip a, int "radius", clip "dClip", float "dfactor", float "MinDif", bool "show") {

rgb = isRGB(a)
FC = FrameCount(a)
FR = FrameRate (a)
fs = propNumElements (a,"_ColorRange") > 0 ? \
propGetInt (a,"_ColorRange") == 0 : rgb

rad = Default(radius, 0) # 0~2 Currently noop
dfactor = Float(Default(dfactor,3.5)) # Range 2.5~4.0 ::: Change default to 4.0 to emulate ScSelect
Mindif = Float(Default(MinDif ,1.0)) # Range 0.5~4.0 ::: Change default to 0.0 to emulate ScSelect
Show = Default(show, false)
ddClp = Defined(dClip)

Assert(!rgb, "SceneRange: DClip YUV Only")
Assert(1.0 <= dFactor,"SceneRange: 1.0 <= dFactor")
Assert(0.0 <= Mindif ,"SceneRange: 0.0 <= MinDif")

# Prefiltering
dClip = ddClp ? dClip : a
dClip = dClip.ExtractY().ConvertBits(8, dither=-1, fulls=fs, fulld=true)
dClip = width(dClip) > 1024 ? dClip.RatioResize(720.,"adjust2w",2,"bicubic",b=-0.5,c=0.25) : dClip

ScriptClip(a, function [dClip,dfactor,MinDif,show,FC,FR] () {

SF = propNumElements("_SceneRange",offset=-1) > 0
SA = SF ? propGetAsArray ("_SceneRange",offset=-1) : [-1,-1]

n = current_frame
nDf0 = 0
nTh = 0
last

if (n-1>SA[1]) {

# 60 secs MAX lookahead
lookahead = min(round(FR*60), FC-n-1)

for (f=1, lookahead, 1) {

dClip = dClip.SelectEvery(1,1)
pDf0 = dClip.YDifferenceFromPrevious()
nDf0 = dClip.YDifferenceToNext()

nTh = pDf0*dfactor+MinDif

SE = n+f
f = nDf0>nTh ? lookahead : f # stopper
}

propSet("_SceneRange", [n,SE])
}
} )

# Set Start (and fix End)
ScriptClip( function[] () {
SD = propGetAsArray("_SceneRange",offset=-1)
SD1 = SD[1]
n = current_frame
LP = last

# lookback
for (lb=n, 1, -1) {
LP = LP.SelectEvery(1,-1)
PR = propGetAsArray(LP,"_SceneRange")
PE = PR[1]
lb = PE != SD1 ? 1 : lb }

SA = propGetAsArray("_SceneRange",offset=-(n-PE)-1)
propSet("_SceneRange", [(n+1 > SD1 ? PE : SA[1]) + 1, SD1])
} ) }

[Dogway]

Uploaded ScenesPack (https://github.com/Dogway/Avisynth-Scripts/blob/master/ScenesPack.avsi), a new pack to deal with scene statistics. Includes SceneRange() to write scene change frame numbers into frame properties and SceneStats() to write scene statistics (min, max, thresholded min, thresholded max, average and median) into frame properties, with an option also to write to a file.

It works dynamically, without the need to write to a file. Every frame knows about its own scene bounds and scene statistics.
You need to update to latest ExTools v8.2.

https://i.imgur.com/1e7NGrbh.png (https://i.imgur.com/1e7NGrb.png)



By the way, I have been experimenting with an idea for protecting shading from smearing. The idea is to accentuate shading in local space so motion estimation can pick up motion vectors.
This first example is a simple isoparam, mode included soon into PseudoColor(). It's simple.
https://i.imgur.com/ZJfWKQFm.png
This other one has ex_luma_rebuild() as a preprocessor to expand dark areas, later I apply the same sinusoidal remap in a non-linear fashion. Higher amplitude and frequency on the lower half.
https://i.imgur.com/8uD6KY6m.png

[anton_foy]

Uploaded ScenesPack (https://github.com/Dogway/Avisynth-Scripts/blob/master/ScenesPack.avsi), a new pack to deal with scene statistics. Includes SceneRange() to write scene change frame numbers into frame properties and SceneStats() to write scene statistics (min, max, thresholded min, thresholded max, average and median) into frame properties, with an option also to write to a file.

It works dynamically, without the need to write to a file. Every frame knows about its own scene bounds and scene statistics.
You need to update to latest ExTools v8.2.

https://i.imgur.com/1e7NGrbh.png (https://i.imgur.com/1e7NGrb.png)



By the way, I have been experimenting with an idea for protecting shading from smearing. The idea is to accentuate shading in local space so motion estimation can pick up motion vectors.
This first example is a simple isoparam, mode included soon into PseudoColor(). It's simple.
https://i.imgur.com/ZJfWKQFm.png
This other one has ex_luma_rebuild() as a preprocessor to expand dark areas, later I apply the same sinusoidal remap in a non-linear fashion. Higher amplitude and frequency on the lower half.
https://i.imgur.com/8uD6KY6m.png

Looks really interesting. Do you plan to add the shading protection into SmDegrain or on its own? Because I started to use your TSMCmod alot and I think this would be perfect in combination with that. By the way is mode="temporalsoften" in SmDegrain very similar to TSMC?

[Dogway]

Yes, TSMCmod is the same as mode="temporalsoften". I realized I was porting many things from SMDegrain so I thought why not the other way around?, and that's how 'mode' arg was implemented. This also helped make some non-motion-protected median modes be usable very easily like ML3Dex.

SMDegrain is pending a big rehaul from the results of the Zopti correlations, so I will have a look on implementing this at that time. It competes with the low frequency expansion call, so I will run some tests to check which achieves better qual/perf.

[anton_foy]

Yes, TSMCmod is the same as mode="temporalsoften". I realized I was porting many things from SMDegrain so I thought why not the other way around?, and that's how 'mode' arg was implemented. This also helped make some non-motion-protected median modes be usable very easily like ML3Dex.

SMDegrain is pending a big rehaul from the results of the Zopti correlations, so I will have a look on implementing this at that time. It competes with the low frequency expansion call, so I will run some tests to check which achieves better qual/perf.

Thanks, I have waited for this moment to see how SMDegrain performs after Zopti optimizations!

[wonkey_monkey]

By the way, I have been experimenting with an idea for protecting shading from smearing. The idea is to accentuate shading in local space so motion estimation can pick up motion vectors.
This first example is a simple isoparam, mode included soon into PseudoColor(). It's simple.
https://i.imgur.com/ZJfWKQFm.png

What's the theory behind that? I can't imagine it creating more good motion vectors than bad ones.

[Dogway]

The isoparam mode is only for visualization but it serves well to illustrate the concept.

The rugged remap helps pick up shading differences, but it needs to be applied on a lowpassed prefiltered clip and ideally on HBD.
This is better than per frame normalization which is inconsistent, here x remaps always to the same y.
https://i.imgur.com/hsOTmI1.png

@anton_foy: I don't think it's going to be night and day but you'd most likely get a bit better while a bit faster.

[mp3dom]

Hi, I'm trying to use deep_resize going from a UHD to SD, but I'm getting these errors (actually even from UHD to HD):

Select: index value out of range
transformspack.avsi, line 3479
transformspack.avsi, line 539
resizerspack.avsi, line 163
resizerspack.avsi, line 214


Any idea? All the "packs" and "extools" are so far up to date and avs+ is 3.7.2.
Thanks!

[Ceppo]

@mp3dom
For UHD to SD I did CReasize in CTools.avsi to get the least amount of aliasing and the least amount of blur, that you can find here (https://forum.doom9.org/showthread.php?p=1963693#post1963693). You can look at the idea and mod it to your taste, if you want to give it a shot.

@Dogway
Sorry for the advertising :D

[Dogway]

My above luma remap worked well in some places, and bad in many places, I think probably due to the null points as I feared. An alternative would be to do it gentler, add a mix of sigmoid contrast with ex_luma_rebuild(), kind of a camel hump shape. In any case probably not as worth it as my current ex_unsharp() solution.

@mp3dom: Probably a TransformsPack regression from my last update, it's working fine on my internal version so will try to update later, with some deep_resize() tweaks.

@Ceppo: Yeah, that's fine, I don't think downsizing is such a problem aliasing wise, the problem has more to do with local contrast. 'Zopti2' does a great and fast job but it adds low freq sharpening that you have to deconvolute, 'DPID' is also great and a reference, it doesn't add much of a local contrast, and finally 'SSIM2' has a great balance between local contrast (actually 0 added) and sharpness. Local contrast is fine if you are not going to upscale later, but for SD you surely will. For intermediary purposes I normally use 'Didée', has a great balance of sharpness, speed and local contrast.

For synthetic tests like zone plates, etc the best all around are Robi and RobiSharp as they approach a 2 taps EWA filter.

[Ceppo]

After the update I will give it a try, your point made me curious. Also, I meant to ask but I always forget:
The ancient QTGMC version doesn't use vinverse, your does, can you please explain what is the function of vinverse in QTGMC?

I'm working on my own bob, starting from scratch I got good results with less shimmering and blending, but it still has some problems in particular cases which QTGMC doesn't have, so I thought to just mix it with QTGMC and see if get better.

[Dogway]

I haven't delved too deep into QTGMC internal logic, you might ask real.finder for that. My work there was to optimize filters, expression and small blocks of code, and some logic flow besides adding the customary HBD and frameprops support. I plan to update MVTools related settings with the Zopti outcomes but no further.

I recommend you to check initial versions of QTGMC to understand the core principle and have a look at the deshimmer filter. For a simple antialiased dumb bob I implemented nnedi3 into ex_bob(), might help for ideas.

For deep_resize() I'm now adding a regrain option as a cheap hallucination option and fixing some low ratio resize bugs.

[mp3dom]

@Ceppo and Dogway: Thanks to both of you, I'll try both the solutions.

[Dogway]

@mp3dom: Please, test now with updated TransformsPack

I updated deep_resize(). Many changes, mainly functionality, now there's a 'show' arg so you know what's going on underneath. Also added a 'grain' arg to add grain for some hallucination (psychovisual detail) for SD to HD and HD to UHD.
I changed back 'flat' kernel to 'sinc', but only when HD to UHD, since at these sizes the faint halo is not visible, less so with grain. For SD to HD now I changed from Blackman8 to Lanczos8 as it's sharper and faster than Blackman16, halos are not visible.

Also fixed apparently a few bugs with low ratio resizes, and remapped 'deconv' to be higher for higher ratios.

Original 1080p
http://i.imgur.com/J7cahxrl.png (https://i.imgur.com/J7cahxr.png)
Upscaled to 1080p (x2)
http://i.imgur.com/oho7QrUl.png (https://i.imgur.com/oho7QrU.png)

spline36 HD to UHD
http://i.imgur.com/qKkiByzl.png (https://i.imgur.com/qKkiByz.png)
deep_resize HD to UHD (grain=0)
http://i.imgur.com/rIUT2pzl.png (https://i.imgur.com/rIUT2pz.png)

[mp3dom]

Hi Dogway,
I'm getting the same error but at different lines now (probably because you added lines and the previous ones shifted a bit):

Select: index value out of range
transformspack.avsi, line 3489
transformspack.avsi, line 548
resizerspack.avsi, line 178
resizerspack.avsi, line 229


What I try so far:

colorbars(width=1920,height=1080,pixel_type="yv16")
deep_resize(3840,2160)

This works


colorbars(width=3840,height=2160,pixel_type="yv16")
deep_resize(1920,1080)

Same errors as above


colorbars(width=3840,height=2160,pixel_type="yv16")
deep_resize(720,576)

Same errors as above


colorbars(width=1920,height=1080,pixel_type="yv16")
deep_resize(720,576)

This works


I'm currently trying to downscale from UHD to SD.

[Ceppo]

@Dogway
I updated the whole repository and I get the same errors as mp3dom, something is off ;)

EDIT:
There are any dll/avsi external requirements to use deep_resize??
EDIT:
With yv12 8bit source works fine.

[Dogway]

I will have a look now. Thanks for the call snippets!


EDIT: Test now, only need to update TransformsPack (https://github.com/Dogway/Avisynth-Scripts/blob/master/TransformsPack.avsi).

[real.finder]

After the update I will give it a try, your point made me curious. Also, I meant to ask but I always forget:
The ancient QTGMC version doesn't use vinverse, your does, can you please explain what is the function of vinverse in QTGMC?

I'm working on my own bob, starting from scratch I got good results with less shimmering and blending, but it still has some problems in particular cases which QTGMC doesn't have, so I thought to just mix it with QTGMC and see if get better.

I haven't delved too deep into QTGMC internal logic, you might ask real.finder for that. My work there was to optimize filters, expression and small blocks of code, and some logic flow besides adding the customary HBD and frameprops support. I plan to update MVTools related settings with the Zopti outcomes but no further.

I recommend you to check initial versions of QTGMC to understand the core principle and have a look at the deshimmer filter. For a simple antialiased dumb bob I implemented nnedi3 into ex_bob(), might help for ideas.

For deep_resize() I'm now adding a regrain option as a cheap hallucination option and fixing some low ratio resize bugs.

it happened here http://forum.doom9.net/showthread.php?p=1921844#post1921844 (read until #72 post) and it's not mandatory :)

[mp3dom]

EDIT: Test now, only need to update TransformsPack (https://github.com/Dogway/Avisynth-Scripts/blob/master/TransformsPack.avsi).
Yes, it works now, thank you!
However, I'm facing another issue. Using colorbars as a source "reference" I see this:
yuv444p16/p10/p8 sources -> output is OK
yuv422p16/p10 sources -> lower part of the bars seems wrong
yuv422p8 sources -> output is OK
yuv420p16/p10/p8 sources -> output is OK

[Dogway]

Thanks, yes a typo, 'src_width' and 'src_height' should default to 0.0 I think. Fixed!

[Ceppo]

I still get an error:
https://i.ibb.co/ydVsBg0/error.jpg

colorbars(width=3840,height=2160,pixel_type="yv16")
deep_resize(720,576)


line 828:
Y = Eval("Y." + resampler + cplaceY + (noring ? Ynr : ""))
line 832:
}
line 1072:
} }

@real.finder, thanks!

[mp3dom]

DPID is an additional (external) DLL, but even with that you still need z.lib DLL (avsresize)

@Dogway: Thanks!

[Ceppo]

@mp3dom

Thanks, it works now!

[Ceppo]

@Dogway, I need your opinion:

Source (https://i.ibb.co/SmHTXV7/source.png)
deep_resize(720,480).spline36resize(1920,1080) (https://i.ibb.co/pxZ1x4d/deep-resize-720-480.png)
CResize(720,480).spline36resize(1920,1080) (https://i.ibb.co/4fjr4vx/CResize-720-480.png)

Default deep_resize is too aliased for my tastes, is possible to tune it to get it aliasing free like CResize, and save more details?

[Dogway]

Use a better upscaler:

deep_resize(720,480)
deep_resize(1920,1080,grain=0)


---------------------------------------

By the way, I updated ScenesPack v1.0 final. I merged SceneRange() and SceneStats() so performance is not harmed. I also included 'mode', as I added an option for '_SceneMotion' frameprops. Now you can do crazy things like the following:


Level normalization
SceneStats() or ReadStats("D:\Stats.log")

ScriptClip(function [] () {
sts = propGetAsArray("_SceneStats")
ex_levels(max(16,sts[0]),1.0,min(235,sts[1]))
} )

Higher Temporal Radius for calm scenes
SceneStats("Motion") or ReadStats("D:\Stats.log")

ScriptClip(function [] () {
mo = propGetFloat("_SceneMotion")
mo = -5*mo+0.85
SMDegrain(tr= round(mo*10))
} )


I see a rise in ScriptClip abusing, sadly all filters need to pass through ScriptClip as frame properties at frame#0 are not dynamic, details here (https://forum.doom9.org/showthread.php?p=1966333#post1966333) by pinterf.

[Ceppo]

I can't see why it is related to the upscale filter, it is just to make easier the comparison, and spline36 is pretty much neutral, if I upscale with like nnedi it would end up fixing the aliasing, which is pointless cuz TVs don't use nnedi or deep_resize for the upscaling, at least not mine.

[Dogway]

I don't know what scalers SmartTVs use but I thought they were some kind of edge directed upscalers which would be similar to nnedi3. A good upscaler is one that antialiases so this is not a problem of downscaling but upscaling.

A reference "cheap" upscaler is typically lanczos4 not spline36 (although I do like bicubic "precise" also). lanczos antialiases a bit better than spline36 and 4 taps adds more sharpness at the cost of almost no additional halo because the 4th lobe is negative which in gamma encoded images is almost invisible.

I mean I didn't invent DPID, you can read the paper. All "recognized" downscalers would be pretty aliased in your terms; DPID, SSIM_downsample, "Didée", "Zopti"...

CResize discards too much information by blurring, it can be nearly replicated with RobiSoft:

bicubicresize(720,480,0.679623,0.160189)
spline36resize(1920,1080)

[Ceppo]

Thanks for your answer.

I did try your suggestion, but all of them seem to output too much aliasing on the character's edges. Then I just did CResize(720,480,aastr=1) and got a close result with the details and less aliasing on the edges.

Do you have some idea to better detect "visible" aliasing?

What I do now, is to just use a sharp resize and a soft one then I make the difference. I apply antialiasing to the difference then I add the difference to the soft one to recover details. Sangnom2 and nnedi3 seem too strong for the job, so I had to make CAntialiasing for it, but it still doesn't cut it, as you said.

[Dogway]

To detect visible aliasing use your preferred antialias.

AA = SantiagMod(strh=1,strv=1) # My favorite (nnedi3 at its core)
ex_makediff(AA) # diff centered at range_half

Your current method is what is commonly used to remove ringing, the difference of Hermite vs your kernel.

[Ceppo]

Thanks :)

[anton_foy]

No rush just eagered for the Zopti ootimization of SMDegrain, when is it going to be released approximately? And is this optimization going to affect modes such as temporalsoften aswell?

[Dogway]

No rush just eagered for the Zopti ootimization of SMDegrain, when is it going to be released approximately? And is this optimization going to affect modes such as temporalsoften aswell?

I said I would start end of this week, I noticed small issues in SceneStats so I will work on it tomorrow and probably start with Zopti correlations on Monday.

[anton_foy]

I said I would start end of this week, I noticed small issues in SceneStats so I will work on it tomorrow and probably start with Zopti correlations on Monday.

Sorry I missed that okay I will await with great anticipation :)

[DTL]

"what scalers SmartTVs"

For cheap end-users displays it mostly probably something close to bicubic (with low kernel size). Because it is most universal and cheap and not show too much ringing at badly conditioned content. For more expensive end-user displays it may be also some non-linear and if user need best result - the downscaler need to be tuned for given display's scaler.

[kedautinh12]

I think they just use fastest and don't show too much ringing scalers in SmartTVs

[Dogway]

I think for most SmartTVs and for some years now (since 4K implementation) they include a dedicated chip for upscaling even for mid tier models (Quantum Processer 4K for Samsung, LG Tru Engine 4K for LG, etc).
LG (https://www.lg.com/us/support/video-tutorials/ultra-hd-4k-tv-upscaling-uhd-tv-video-CT10000018-1432737109927) and Samsung (https://www.samsung.com/us/televisions-home-theater/tvs/qled-4k-tvs/55-q70a-qled-4k-smart-tv-2021-qn55q70aafxza/#benefits)

[Dogway]

I finished ScenesPack to what I consider a stable version so please give it a try. I know there are some false positives/negatives scene changes, but overall it should give more matches than SCSelect, or other SC filters. There are ways to improve the SC algo but I'm done here for now (will only update as soon as pinterf adds 'average' stat to PlaneMinMaxStats() )
I will start today with the Zopti correlations by porting CoS to Python and doing the correlations there. It will take me some time though. Then I will try to draw some non-linear functions that correlate different parameters for MVTools.

[tormento]

The remastered Godfather box arrived me since a couple of days and even if they recovered the tint, that was yellowish in the last set I had, they did a terrible, horrible work with compression and perhaps some denoising.

Just look at the clusters of noise in these two images:

https://i.lensdump.com/i/rhPyVK.md.png (https://lensdump.com/i/rhPyVK)

https://i1.lensdump.com/i/rhP5vZ.md.png (https://lensdump.com/i/rhP5vZ)

@Dogway: here you can find some clips of the movies.

Godfather_desk (https://krakenfiles.com/view/cVyqTvw78p/file.html)
Godfather_doorface (https://krakenfiles.com/view/zied2pS3bt/file.html)
Godfather_greenwall (https://krakenfiles.com/view/97v5hUlb2M/file.html)
Godfather_greysuit (https://krakenfiles.com/view/bcip6D1e3T/file.html)
Godfather_hug (https://krakenfiles.com/view/L2v5zDArmu/file.html)
Godfather_phone (https://krakenfiles.com/view/53T9Ju2V6S/file.html)
Godfather_picture (https://krakenfiles.com/view/x5Do3vQkaX/file.html)
Godfather_shades (https://krakenfiles.com/view/sQi35igzPo/file.html)
Godfather_table (https://krakenfiles.com/view/UJjUlrmRSh/file.html)

I have tried to play a little with SMDegrain switches but I can't find consistent settings that can be applied to a whole movie recode. The worse parts are in flat areas of colors and in dark scenes.

To get rid of the noise on the desk of Godfather_desk, I would lose tiny details in the lighter scenes. I was thinking: as darker scenes suffers from higher film grain noise (perhaps higher ISO film?), wouldn't be possibile to adapt denoising strenght to the general darkness of a scene?

In the mean while, what kind of script could I use on such a difficult movie?

[Dogway]

Woow, what happened to the doorface scene! looks like they copy-pasted the face from another source without postpro of any kind.

In these old films grain typically shows when a high ISO stock is used, for example for dark scenes, so you can run per-scene stats to detect them and perform more aggressive denoising like explained in a previous post (https://forum.doom9.org/showthread.php?p=1966366#post1966366).

My recommendation for performance is to do a stats prepass with:
SceneStats("Range+Stats+StdErr",lookahead=90,path="D:\mystats.log")

Then load the stats with:
ReadStats(path="D:\mystats.log")

In any case I found SceneStats() has issues with long scenes (over 20 seconds) as it's very slow.
I was waiting for pinterf to update PlaneMinMaxStats(), but I will upload what I have now and try to check feedback to see if I can speed things up.

You can detect dark scenes with

ScriptClip(function [] () {

sts = propGetAsArray("_SceneStats")

avg = sts[4]
med = sts[5]
skw = sts[6]

dark = avg < 80 && med < 60 || skw > 0.8
} )

[Julek]

You might be interested in this:
https://github.com/dnjulek/jvsfunc/blob/main/jvsfunc/expr.py#L10-L55

I did ccd using only Expr, I saw that AVS does not yet have a native plugin (https://forum.doom9.org/showthread.php?p=1947846#post1947846) and I think this might help.

To help with vs-expr: https://github.com/AkarinVS/vapoursynth-plugin/wiki/Expr#translating-avs-expr-expressions

[Dogway]

Thanks for the note. I might need to read a bit more about CCD denoise, is it some kind of debayer denoise?
Looks like it can be implemented, as for the rest we lack (https://forum.doom9.org/showthread.php?p=1946915#post1946915) 'sort' operator in Expr. I'm curious to know the performance gap compared to my sorting network approach.

Can you compare:
ExtractY()
ex_median("median5")
Prefetch(6) # for 4C/8T or tune according to CPU
to
y_clip = core.std.ShufflePlanes(planes=0, colorfamily=vs.YUV)
medianblur(y_clip,2)

And also with "median7" and n=3


---------------


As for SceneStats() code wise it is correct now, but it suffers a lot with long scenes/shots (>20s). This is mainly because due to lack of a loopback, for each frame we do a lookahead and a lookback to set start and end scene frames. Ideally we should only do this once at start of scene and then copy _SceneRange props from previous frame (here's what we need a loopback/feedback for) if current frame is not a SC.

[Julek]

Thanks for the note. I might need to read a bit more about CCD denoise, is it some kind of debayer denoise?
You can find a more complete explanation here: https://github.com/DomBito/VapourSynth-CCD/blob/main/README.md


Tests:


BlankClip(length=5000, width=1920, height=1080, pixel_type="Y16")

ex_median("median5")
Prefetch(12)
Result: https://i.imgur.com/VcISpEt.png

from jvsfunc import medianblur
import vapoursynth as vs
core = vs.core

src = core.std.BlankClip(None, 1920, 1080, vs.GRAY16, 5000)
blur = medianblur(src, 2)

blur.set_output()
Result: https://i.imgur.com/IUCU4cZ.png

BlankClip(length=5000, width=1920, height=1080, pixel_type="Y16")

ex_median("median7")
Prefetch(12)
Result: https://i.imgur.com/zab2gdQ.png

from jvsfunc import medianblur
import vapoursynth as vs
core = vs.core

src = core.std.BlankClip(None, 1920, 1080, vs.GRAY16, 5000)
blur = medianblur(src, 3)

blur.set_output()
Result: https://i.imgur.com/Tc8hpLI.png

CPU: AMD 3700X

#EDIT: now that I noticed the note about Prefetch, I will redo the tests, as I don't use AVS I'm not familiar with the tool
#EDIT2: updated tests

[Dogway]

Wow, about 2.5x the performance, could be very worth it, not sure if it makes use of internal optimizations with LLVM or something though.

[Dogway]

I updated ScenesPack to deal with issues on long scenes, now it only performs lookahead on scene start frames (not every frame as previous versions). I also optimized other code blocks and generally performs about 30% faster. There are still some issues with StdErr mode, so avoid that mode or 'ALL'.

Later I realized that the culprit for long scenes was a low memory assignment, so for good measure I recommend going no less than setmemorymax(2048*3).

I might ask you now what would you consider a "dark" frame, ideally 'dark' as synonymous of high ISO film stock. We might agree that a low scene's average and median would depict a dark frame. But "dark scenes" could also show a bright spotlight. I didn't find any paper talking about ISO or dark scene detection but would you consider a frame/scene with 90% below 8-bit 80 avg/median value and 10% <200 bright a dark frame/scene?

In other words:
dark = avg < 80 && med < 60
or
dark = avg < 80 && med < 60 && mx < 150

Now I also feel confident to finish the SAD analysis tool, it's not an unsupervised tool though nor a fast one, but can help on defining scene's grain density.


I also implemented reading '_SceneStats' on several filters like ex_retinex, softlimiter, greyworld, and made ex_autolevels. Will be uploading soon.

[anton_foy]

I updated ScenesPack to deal with issues on long scenes, now it only performs lookahead on scene start frames (not every frame as previous versions). I also optimized other code blocks and generally performs about 30% faster. There are still some issues with StdErr mode, so avoid that mode or 'ALL'.

Later I realized that the culprit for long scenes was a low memory assignment, so for good measure I recommend going no less than setmemorymax(2048*3).

I might ask you now what would you consider a "dark" frame, ideally 'dark' as synonymous of high ISO film stock. We might agree that a low scene's average and median would depict a dark frame. But "dark scenes" could also show a bright spotlight. I didn't find any paper talking about ISO or dark scene detection but would you consider a frame/scene with 90% below 8-bit 80 avg/median value and 10% <200 bright a dark frame/scene?

In other words:
dark = avg < 80 && med < 60
or
dark = avg < 80 && med < 60 && mx < 150

Now I also feel confident to finish the SAD analysis tool, it's not an unsupervised tool though nor a fast one, but can help on defining scene's grain density.


I also implemented reading '_SceneStats' on several filters like ex_retinex, softlimiter, greyworld, and made ex_autolevels. Will be uploading soon.

Now this is interesting! But did you take into consideration the red channel? With cmos red tint combined with low exposures makes for noisy footage. I mean high ISO usually gets more noise when light is on the red side. Blue light (daylight balanced LED lights for example) is less noisy. EDIT: Sorry I read wrong (tired) you said film stock and I talked about high ISO video.

[Dogway]

Thanks, yes that is an idea, probably for grain detection.
I was thinking a bit and researching, and made up a 2D matrix for evaluating scene exposure.
Raw exposure takes the scene's median and classifies it within the 5 blocks/zones (ymax/5)
Contrast does the same but takes the range (th_max - th_min) and classifies it in 5 zones as well. It acts as a bias for Raw exposure.

| \ | | | | | |
| \Med| V.Dark | Dark | Mid | Bright |V.Bright|
|Rng \ | | | | | |
|-------|--------|--------|--------|--------|--------|
| | | | | | |
| Flat | 0 | 1 | 2 | 3 | 4 |
| | | | | | |
|-------|--------|--------|--------|--------|--------|
| | | | | | |
| Mid | 0 | 1 | 2 | 3 | 4 |
| | | | | | |
|-------|--------|--------|--------|--------|--------|
| | | | | | |
| Cont | 1 | 2 | 3 | 4 | 4 |
| | | | | | |
|-------|--------|--------|--------|--------|--------|
| | | | | | |
| V.Cont| 2 | 3 | 4 | 4 | 4 |
| | | | | | |
|-------|--------|--------|--------|--------|--------|
| | | | | | |
| Bimod | 3 | 4 | 4 | 4 | 4 |
| | | | | | |
|-------|--------|--------|--------|--------|--------|


I think I should decouple 'th' from the calculation of th_min and max and lock it at 1%. I also built a grid to show what 'th' represents in pixels in 'show=true' mode. Uploading in a moment.


EDIT: Updated to v3.2 to fix Exposure expression. Also converted divisions to multiplication for performance.
Here's a snapshot of the 'show' panel where it shows all the possible stats.
Each square of the grid represents the percentage of 'th' so you can figure out the size of discarded pixels for 'th_min' and 'th_max' (in this case 1%).
Pearson's skewness wasn't accurate for Exposure detection, as you can have negative skewness (meaning bright) in the lower portion of the histogram, and it was sensitive to outliers.

https://i.imgur.com/Qd4Lbdkh.png (https://i.imgur.com/Qd4Lbdk.png)

[Shinkiro]

broken flatmask
Script error: ex_retinex does not have a named argument "tv_range"
(C:/AviSynth+/plugins64+/MasksPack.avsi, line 161)
(New (3), line 24)

[Dogway]

Thanks, uploaded now. I will be uploading now all my left over internal commits.

[Fjord]

MasksPack v6.2 error - line 580, column 149: missing comma after dct=0

[Dogway]

MasksPack v6.2 error - line 580, column 149: missing comma after dct=0

Thanks! Was a bit busy and couldn't finish my uploads. Updates done now.

[Boulder]

Do you have any recommendations for a subtle sharpener to apply after a 1080p -> 720p or a 4k -> 1440p/1080p downscale? This would be just to restore a bit of sharpness lost during downscaling.

[Dogway]

Do you mean edge sharpness? Did you try deep_resize() with some of the recommended downscalers? I found them to work quite good. For example yesterday I had to resize down a book cover and DPID didn't work as fine as I thought but SSIM2 did. Bicubics though added a bit of overshoots. ex_unsharp() also works fine for subtle sharpening all around.

This reminds me that I need to update TransformsPack because my last internal fix was indeed fixing SSIM2 mode.
I have been a bit busy with ScenesPack (finished already) and backing up my 870 EVO that I use for all my programs' cache which started failing just one year after buy! It's in warranty so I hope they replace it back.

[Boulder]

Do you mean edge sharpness? Did you try deep_resize() with some of the recommended downscalers? I found them to work quite good. For example yesterday I had to resize down a book cover and DPID didn't work as fine as I thought but SSIM2 did. Bicubics though added a bit of overshoots. ex_unsharp() also works fine for subtle sharpening all around.

This reminds me that I need to update TransformsPack because my last internal fix was indeed fixing SSIM2 mode.
I have been a bit busy with ScenesPack (finished already) and backing up my 870 EVO that I use for all my programs' cache which started failing just one year after buy! It's in warranty so I hope they replace it back.

I briefly tested deep_resize yesterday at default settings, but it produced a clearly blurrier result than a Spline36 + FineSharpPlus(0.1) and didn't look at it any further then. I usually use Zopti to process the Didée Bicubic idea of negative b and positive c using MDSI or GMSD, but in this case the BDs are very grainy (but mostly very high quality for an 80s TV show) and the bitrate goes through the roof in encoding. For these cases, I'm looking for a middle way solution between Spline36 and a full Didée :)

[Dogway]

Well, that's very strange since DPID captures the most important features for downscaling, it's a bit like downscaling in linear light, and yes it can be a bit blurry in some cases but I hard coded it to lambdaY=0.5 which gave me the most natural look after upscaling back with reference upscaler. In this case you can use SSIM2 as it will give you slightly sharper output.

I'm curious to see if there's value in edge/flat mixing for downscale, as you say your source is grainy so you might want a sharp edge and a soft flat, maybe share a sample so I can have a look. I implemented your 'Zopti' coefficients as scaling preset so you can also try deep_resize(1280,720,edge="Zopti2"), that's -0.6,0.4. I found -0.6,0.3 ("Zopti") to be more neutral though, maybe with softer 'flats'.

[Boulder]

Well, that's very strange since DPID captures the most important features for downscaling, it's a bit like downscaling in linear light, and yes it can be a bit blurry in some cases but I hard coded it to lambdaY=0.5 which gave me the most natural look after upscaling back with reference upscaler. In this case you can use SSIM2 as it will give you slightly sharper output.

I'm curious to see if there's value in edge/flat mixing for downscale, as you say your source is grainy so you might want a sharp edge and a soft flat, maybe share a sample so I can have a look. I implemented your 'Zopti' coefficients as scaling preset so you can also try deep_resize(1280,720,edge="Zopti2"), that's -0.6,0.4. I found -0.6,0.3 ("Zopti") to be more neutral though, maybe with softer 'flats'.

Here's a short sample:
https://drive.google.com/file/d/1mITC71QTGeJyYk4MyUl8EWIvcJr-wH2y/view?usp=sharing

It might be a good idea to use a softer flat area resizer as the grain is rather heavy and needs a little damping down. Zopti or Zopti2 are a bit sharper than DPID, especially if you take a look after upscaling back to the original resolution.

By the way, edge="SSIM2" gives an error "CombinePlanes: source has no such plane U"

[Dogway]

I see now. Yes DPID didn't yield good results either on this source, I think it was trained with clean sources, I will change default downscaling kernel to SSIM2, it represents source accurately and it's sharp, so for this case it also enhances grain. I think I will implement downscaling edge/flat mixing but not as default.

I did some tests upscaling back with deep_resize() (defaults settings).
I found spline36+finesharp a bit plasticky in the look (like a median filter), spline36 plain works fine as well for sources of these kind without too much detail but I found Zopti2 to be sharper. So in this case SSIM2 for accuracy (probably not worth it) and Zopti2 for speed, both edge limited after I update the script.

source.....................................................Spline36+finesharp.....................................................Zopti2.....................................................SSIM2
http://i.imgur.com/GCib3Khm.png (https://imgur.com/GCib3Kh.png)http://i.imgur.com/kkrXoHnm.png (https://imgur.com/kkrXoHn.png) http://i.imgur.com/eTTBq6Qm.png (https://imgur.com/eTTBq6Q.png) http://i.imgur.com/SAEZpqAm.png (https://imgur.com/SAEZpqA.png)


The error, yes as I said above it's fixed internally but haven't uploaded yet, I will between today and tomorrow after I also update SoftLimiter() for SceneStats.


EDIT: Edited deep_resize(), it didn't look good though, no good settings avoid the image from looking broken. grain sneaks in and the transition to flat->edge is not smooth.
deep_resize(958.0, 720.0,edge="SSIM2",flat="SoftCubic100",show=false,th=0.6,elast=9)
http://i.imgur.com/ADC77hmm.png (https://imgur.com/ADC77hm.png)

In my opinion I would just do Zopti and if needed compression run SPresso or some subtle degraining, before or after resize.

[Boulder]

EDIT: Edited deep_resize(), it didn't look good though, no good settings avoid the image from looking broken. grain sneaks in and the transition to flat->edge is not smooth.
deep_resize(958.0, 720.0,edge="SSIM2",flat="SoftCubic100",show=false,th=0.6,elast=9)
http://i.imgur.com/ADC77hmm.png (https://imgur.com/ADC77hm.png)

In my opinion I would just do Zopti and if needed compression run SPresso or some subtle degraining, before or after resize.

Yes, I agree that it's just a bit too difficult to process so that it won't start looking strange. I'm probably resorting to a simple Spline36 downscale, I already do a combination of a very light SPresso and a light MDegrain + contrasharpening before the resizing part.

[Shinkiro]

I used this expression mt_lut("x "+string(mthr)+" <= x 1 >> x 1 << ?", U=1, V=1), tell me how to write it correctly for ex_lut()?

[Shinkiro]

I can't figure out what I'm not doing wrong, seem all the clips YUV420P16
mthr = 34

ConvertBits(16)
Source=last
mask1b=last.ex_edge("kirsch",6,10)
mask2b=last.ex_edge("kirsch",4,7)
mask=last.ConditionalFilter(mask1b, mask2b, "AverageLuma()",">","50").mt_lut("x "+string(mthr)+" <= x 1 >> x 1 << ?", U=1, V=1).RemoveGrain((980>960) ? 20 : 11, -1)

deb = Source.neo_f3kdb(sample_mode=2, Y=68, Cb=68, Cr=68, grainy=54, grainC=40, range=15, dynamic_grain=true)
ex_merge(deb ,Source ,mask, luma=true, Y=3, UV=3)
returns an error

why does he say that it is not so, or does ex_merge not know how to handle 10-16bit?
I found the culprit of this error, it turned out to be a script SeparateResize_v1.6.avsi (https://github.com/dsamahentai/AviSynth_Filters/blob/master/SeparateResize_v1.6.avsi)
Everything works as it should without it

[kedautinh12]

I used this expression mt_lut("x "+string(mthr)+" <= x 1 >> x 1 << ?", U=1, V=1), tell me how to write it correctly for ex_lut()?

maybe:
bi = BitsPerComponent(input)
mthrHBD = ex_bs(mthr, 8, bi, true)
ex_lut("x {mthrHBD} <= x 1 >> x 1 << ?", UV=1)

[Shinkiro]

maybe:
bi = BitsPerComponent(input)
mthrHBD = ex_bs(mthr, 8, bi, true)
ex_lut("x {mthrHBD} <= x 1 >> x 1 << ?", UV=1)
I get this error
Expr: Failed to convert '{mthrHBD}' to float
(C:/AviSynth+/plugins64+/ExTools.avsi, line 66)

[Dogway]

Use Format() like:
bi = BitsPerComponent(input)
mthrHBD = ex_bs(mthr, 8, bi, true)
ex_lut(Format("x {mthrHBD} <= x 1 >> x 1 << ?"), UV=1)

I didn't know Expr() supported bitshifts operators...

[Shinkiro]

Now such a error
Expr: Failed to convert '>>' to float
(C:/AviSynth+/plugins64+/ExTools.avsi, line 66)

[Dogway]

Ah, then it doesn't support them, do manually:
ex_lut(Format("x {mthrHBD} <= x 0.5 * x 2 * ?"), UV=1)

[Shinkiro]

Ah, then it doesn't support them, do manually:
ex_lut(Format("x {mthrHBD} <= x 0.5 * x 2 * ?"), UV=1)

It works that way, thank you!

[kedautinh12]

It works that way, thank you!

Can you share script you were change to expr??

[Dogway]

I updated a few scripts today. Wanted to call out Boulder as I updated TransformsPack so now 'SSIM2' works over there or deep_resize().
deep_resize() also supports now ratio resize, so deep_resize(2) will mean to double the size, likewise deep_resize(0.5) is halving the size.

As I said I finally added accumulated scene stats to SoftLimiter, making the limiting work on a per-scene basis.
My plan is to include per-scene filtering in more functions so if you have a request for one of my filters let me know.

Now all the scripts are up-to-date with internal (oops, nope, ExTools needs a minor update). From now on I will add global stats parser to SceneStats, work on Zopti optimizations and finally finish TransformsPack final.

[Shinkiro]

Can you share script you were change to expr??

setmemorymax(6000)
ffms2("video.mkv",cache=true)

ContinuityFixer(left=4, top=0, right=5, bottom=0, radius=0)
FillBorders(left=3,top=0, right=4, bottom=0, mode=0, y=2, u=3, v=3)
EdgeCleaner(strength=10, rep=false, rmode=17, smode=0, hot=false)

W=1920
H=1080
nnedi3_rpow2(rfactor=2, nsize=0, nns=4, qual=2, etype=0, pscrn=4, cshift="spline36resize", threads=8)
Blackmanresize(W, H, taps=4,0,0,-0,0)
ConvertTo16bit()

mthr = 16
bi = BitsPerComponent(last)
mthrHBD = ex_bs(mthr, 8, bi, true)
mlight1=last.flatmask(2, scale=5.0, lo=4, MSR=70, invert=false)
mdark1=last.flatmask(3, scale=7.0, lo=4, MSR=50, invert=false)
mask=last.ConditionalFilter(mlight1, mdark1, "AverageLuma()",">","60").ex_lut(Format("x {mthrHBD} <= x 0.5 * x 2 * ?"), UV=1).RemoveGrain((W>960) ? 20 : 11, -1)

deg1 = last.SMDegrain(tr=3,thSAD=340, thSADC=150, thSCD1=250,thSCD2=96, contrasharp=false, refinemotion=true, chroma=true, plane=4)
deg2 = last.SMDegrain(tr=2,thSAD=121, thSADC=50, thSCD1=156,thSCD2=96, contrasharp=false, refinemotion=true, chroma=true, plane=4)
deg=ConditionalFilter(deg1, deg2, "AverageLuma()",">","60")
ex_merge(deg ,last ,mask, luma=true, Y=3, UV=3)

LSFmod(ss_x=1.0,ss_y=1.0,strength=4,Smode=5)
FineDehalo(rx=2.8, ry=2.8, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=0.0, brightstr=1.0, showmask=0, contra=0.0, excl=true)#.aWarpSharp2(depth=2)

db=last.neo_f3kdb(sample_mode=2, Y=64, Cb=64, Cr=64, grainy=44, grainC=0, range=15, dynamic_grain=false)
ex_merge(db, last, mask, luma=true, Y=3, UV=3) # пкрвый клип (дебандинг) второй клип(чистые линии)

z_ConvertFormat(colorspace_op="470bg:601:470bg:f=>709:709:709:f",dither_type="none")
ConvertBits(bits=10)
Prefetch(8)

[Boulder]

I updated a few scripts today. Wanted to call out Boulder as I updated TransformsPack so now 'SSIM2' works over there or deep_resize().
deep_resize() also supports now ratio resize, so deep_resize(2) will mean to double the size, likewise deep_resize(0.5) is halving the size.

Thanks, did some eyeballing tests. It's definitely much sharper than a simple Spline36. 'SSIM' looks like it could be a good replacement for that instead. Are there any caveats I should be aware of?

[Dogway]

Thanks, did some eyeballing tests. It's definitely much sharper than a simple Spline36. 'SSIM' looks like it could be a good replacement for that instead. Are there any caveats I should be aware of?

Prerequisites only as it needs SimilarityMetrics, fmtconv, vsTCanny... Speed wise I guess slower but haven't benchmarked. Hopefully I didn't break something/logic.

[Boulder]

Something I noticed - 'Didée' as a string doesn't work correctly as it requires UTF8 support. VDub2 won't put the 'é' there in the script editor.

EDIT: and show=true won't help to see what is really being used since it shows whatever string is given in the function call.

[Dogway]

Something I noticed - 'Didée' as a string doesn't work correctly as it requires UTF8 support. VDub2 won't put the 'é' there in the script editor.

EDIT: and show=true won't help to see what is really being used since it shows whatever string is given in the function call.

Thanks, "Didee" is also supported as alias so I changed default for that.

Do you mean to show also 'b' and 'c' coefficients? I know them by memory mostly, expected people to also familiarize but I can add them no problem.

[Boulder]

Do you mean to show also 'b' and 'c' coefficients? I know them by memory mostly, expected people to also familiarize but I can add them no problem.

Yes, I think it would be good to see what the actual resizer parameters are for each case. There's quite a few of them there :)

[tormento]

@DogWay

I recently bought the Aniplex version of Full Metal Alchemist Brotherhood (an anime) and (I could easily guess) it's an upsampled version of the broadcast show.

There are many aliased black line arts (with some halo too) and what was some grain (not excessive though) now became pixel blocks, mostly in dark areas.

Is there anything I could do with your tools?

Some examples:
https://i.lensdump.com/i/trQBue.md.png (https://lensdump.com/i/trQBue) https://i1.lensdump.com/i/trQsAk.md.png (https://lensdump.com/i/trQsAk)
https://i2.lensdump.com/i/trQ3Qx.md.png (https://lensdump.com/i/trQ3Qx) https://i3.lensdump.com/i/trQ4nH.md.png (https://lensdump.com/i/trQ4nH)

[Julek]

@DogWay

I recently bought the Aniplex version of Full Metal Alchemist Brotherhood (an anime) and (I could easily guess) it's an upsampled version of the broadcast show.

There are many aliased black line arts (with some halo too) and what was some grain (not excessive though) now became pixel blocks, mostly in dark areas.

Is there anything I could do with your tools?

FMAB is a 960x540 animation upscaled to 1920x1080 with bicubic 0/1, the correction process (using VS) looks like this:

from vsutil import depth, split, join
import vapoursynth as vs
core = vs.core

src = core.dgdecodenv.DGSource(r"D:\Encodes\FMAB\00000.dgi")
src32 = depth(src, 32)
y, u, v = split(src32)
dsc = core.descale.Debicubic(y, width=960, height=540, b=0, c=1)
w2x = core.caffe.Waifu2x(dsc, noise=-1, scale=2, model=6, cudnn=True, tta=False)
w2x = join([w2x, u, v])
depth(w2x, 10).set_output()
Result: https://slow.pics/c/zSsrC5HW

[ChaosKing]

Lineart looks great now!

[tormento]

FMAB is a 960x540 animation upscaled to 1920x1080 with bicubic 0/1, the correction process (using VS) looks like this
Is possible to have a AVS+ script?

I am really a noob with VS. Anyway, is it the CUDA filter version?

P.S: Results are awesome.

[Dogway]

Yes, I was going to recommend de-scalers, probably the aliasing is due to a bad upscaling, so it should be fixed by returning it to the original size and optionally upscaling with a better (AI) upscaler.

Julek example is wonders, not even it cleaned the aliasing but also the ringing.

A port attempt:
src = DGSource("D:\Encodes\FMAB\00000.dgi")
src32 = ConvertBits(src, 32)
dsc = DeBicubicResizeMT(ExtractY(src32), 960, 540, b=0, c=1)
# w2x = Waifu2x(dsc, nr=0, scale=2, models="C:\opt\waifu2xAvisynth-models\models", jobs=4)
w2x = nnedi3resize(dsc, 1920,1080)
w2x = CombinePlanes(w2x, src32, planes="YUV",Pixel_Type="YUV420PS")
Adaptive_sharpen(w2x,0.5)
ConvertBits(10, dither=1)

[Julek]

Waifu2x for AVS has the cunet model? It is the only model with good results, the other models damage the image a bit.
The second option is to use just nnedi3_rpow2.

[Dogway]

I don't know, it's this build (https://github.com/sunnyone/Waifu2xAvisynth) but only for AVS 2.6 x86.

There are other AI upscalers in AVS+ like FCBI, SuperResXBR or FSRCC. But I don't think any is modeled for anime.

EDIT (alternative with less ringing):

src = DGSource("D:\Encodes\FMAB\00000.dgi")
src32 = ConvertBits(last, 32)

dsc = deep_resize(ExtractY(src32), 960, 540)
w2x = deep_resize(dsc, 1920,1080,grain=0,deconv=0)
w2x = CombinePlanes(w2x, src32, planes="YUV",Pixel_Type="YUV420PS")
w2x
ConvertBits(10, dither=1)
aWarpSharp2(depth=4,type=1,blur=3,thresh=128,chroma=2)
FastLineDarkenMOD(prot=0, thinning=10, strength=30)
# some denoise
sec = ex_bs(0.51, 8, 10, fulls=true, flt=true)
ex_lutxy(ex_median("median5"), Format("x y == x dup y x - sgn {sec} * + ?"), UV=3)

[tormento]

but only for AVS 2.6 x86.
We need something that works with GPU of we can get old waiting :)

[tormento]

Waifu2x for AVS has the cunet model? It is the only model with good results, the other models damage the image a bit.
The second option is to use just nnedi3_rpow2.
Can you "take my hand" and lead me to files needed, i.e. urls etc?

I can "stupidly" apply your script if you give me some coordinates.

[Julek]

Can you "take my hand" and lead me to files needed, i.e. urls etc?

I can "stupidly" apply your script if you give me some coordinates.

Talk about a VS installation? I am a little busy today, but I can give a very detailed explanation tomorrow.
In advance I can tell you that we have 3 cunet options:
caffe (CUDA ver) (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-Waifu2x-caffe) which has a brightness bug (https://github.com/HomeOfVapourSynthEvolution/VapourSynth-Waifu2x-caffe/issues/20)
w2xnvk (Vulkan ver) (https://github.com/Nlzy/vapoursynth-waifu2x-ncnn-vulkan), which is slower than caffe, but has a bug-free release (https://github.com/Nlzy/vapoursynth-waifu2x-ncnn-vulkan/issues/10).
mlrt (CUDA ver) (https://github.com/AmusementClub/vs-mlrt) which is the fastest of them, but has the same bug as caffe (https://github.com/AmusementClub/vs-mlrt/issues/2)

It's possible to mitigate the effects of the bug with Expr, or just use w2xnvk R3.2

[tormento]

Talk about a VS installation? I am a little busy today, but I can give a very detailed explanation tomorrow.
Thank you in advance. Please cover every aspect so that other users can have benefits too. [emoji4]

[Dogway]

You might be interested in this:
https://github.com/dnjulek/jvsfunc/blob/main/jvsfunc/expr.py#L10-L55

I did ccd using only Expr, I saw that AVS does not yet have a native plugin (https://forum.doom9.org/showthread.php?p=1947846#post1947846) and I think this might help.

To help with vs-expr: https://github.com/AkarinVS/vapoursynth-plugin/wiki/Expr#translating-avs-expr-expressions

Finally ported (https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/DeblockPack.avsi#L203). It acts more like a chroma deblocker so added into DeblockPack. I added a few optimizations and features so you might want to give it a look.

[Boulder]

FMAB is a 960x540 animation upscaled to 1920x1080 with bicubic 0/1

Is there a clear method for defining the upscale method? I have some film sources which are clearly rather poor upscales and would like to downscale back to the original resolution for the encode.

[Reel.Deel]

Is there a clear method for defining the upscale method? I have some film sources which are clearly rather poor upscales and would like to downscale back to the original resolution for the encode.

Here's a nice article on descaling: https://guideencodemoe-mkdocs.readthedocs.io/encoding/descaling/

[tormento]

Is there a clear method for defining the upscale method?
The university professor of a friend of mine talked about it but that friend of mine lost the notes.... :scared:

[Boulder]

Here's a nice article on descaling: https://guideencodemoe-mkdocs.readthedocs.io/encoding/descaling/

Thanks :)

[anton_foy]

Finally ported (https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/DeblockPack.avsi#L203). It acts more like a chroma deblocker so added into DeblockPack. I added a few optimizations and features so you might want to give it a look.

Thanks for this! But with CCD(30,HD=true) on UHD clip something strange is happening with the colors, like a tint of pink and grey. As if the green channel is gone or something.

EDIT:
src=last
CCD(10,HD=true)
CombinePlanes(src, last, src, planes="YUV")
This works wonders though on my noisy high ISO Slog2 footage!

[tormento]

I am a little busy today, but I can give a very detailed explanation tomorrow.
Waiting :)

Perhaps it's better that you open a new thread about it.

[Dogway]

@anton_foy: Yes, I could test on grainy chroma and works great as well. As for your issue I haven't seen it... also tested on a 4K clip. I updated today the filter again to be able to turn off either chroma plane either U or V. Also removed the HD arg since it works fine for all resolutions whereas 4 and 12 step size was giving issues.

Also wanted to bring to the attention a new filter. Was unexpected but it occurred to me while reading around. Called FindTemp() will infer color temperature from the image, therefore it will only make sense for natural acquired images without grading of any kind. This tool is useful to know if you shot with a temperature of D50, D55 or other and then fix according with WhitePoint() as a step of the color correction process.

Tomorrow I will be uploading the last battery of script changes to resume the mvtools Zopti optimizations.

[Julek]

Waiting :)

Perhaps it's better that you open a new thread about it.
Sorry for the delay, I made a video explaining how to setup vapousynth in windows with editor: https://youtu.be/DBL8nc2hp3U
Link for the mentioned guide: https://silentaperture.gitlab.io/mdbook-guide/introduction.html
And for specific questions, I prefer that you join our discord, where there are many VS users who can help: https://discord.gg/qxTxVJGtst

Finally ported (https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/DeblockPack.avsi#L203). It acts more like a chroma deblocker so added into DeblockPack. I added a few optimizations and features so you might want to give it a look.
Cool, I'll try to implement the matrix size resizer as well.

[real.finder]

Julek, tormento, what about just use https://github.com/theChaosCoder/vapoursynth-portable-FATPACK/releases it got editor and stuff, Personally I use it to spy on vs things :D

[Julek]

Julek, tormento, what about just use https://github.com/theChaosCoder/vapoursynth-portable-FATPACK/releases it got editor and stuff, Personally I use it to spy on vs things :D

I prefer to avoid portable installation because I have had issues with some plugins.
And his editor doesn't have autocomplete for scripts, you can see how it looks in vs code at this minute: https://youtu.be/DBL8nc2hp3U?t=764

This is really important for things like QTGMC, which has a lot of parameters.

[real.finder]

Either way, I don't care, it's do the job for test (spy), I even use avs/avs+ as portable in my personal laptop, I just hate install things and I love things be portable :) and as aside note for vs, it's kinda bloated with python so I may never use it in my personal laptop

[Dogway]

Julek, tormento, what about just use https://github.com/theChaosCoder/vapoursynth-portable-FATPACK/releases it got editor and stuff, Personally I use it to spy on vs things :D

I think the latest Win7 supported version is the 3.8.x branch. I don't know about vs support though.

[tormento]

Sorry for the delay, I made a video explaining how to setup vapousynth in windows with editor
Thanks, man. I just wanted to understand how to use the various versions of waifu2x :)
I prefer that you join our discord
Just joined.

[LeXXuz]

Dogway I've used SMDegrain v3.1.2d quite a lot before. Now I'm trying out your version but get very different visual results.

Is there any kind of correlation for tr, thSAD etc to get kind of 'similar' results?

f.e. I've used these parameters with SMDegrain(+LSFmod):
PRE=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:0 0.5:2 0.9:8 1.0:16", chrslocation="0.0:0 0.5:0.5 0.9:2 1.0:4"))
SMDegrain(tr=3, thSAD=200, thSADC=50, contrasharp=100, refinemotion=true, truemotion=false, Str=1.0, pel=1, subpixel=2, prefilter=PRE, chroma=true, plane=4)


By just copying these I get a much more grainy output. :o

[Dogway]

I think you mean neo_dfttest()?
PRE=neo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:0 0.5:2 0.9:8 1.0:16", nlocation="0.0:0 0.5:0.5 0.9:2 1.0:4")
NotSMDegrain(tr=3, thSAD=200, thSADC=50, refinemotion=true, truemotion=false, Str=1.0, pel=1, subpixel=2, prefilter=PRE, chroma=true, plane=4)

That's the your call updated and without contrasharp.

I compared to:
PRE=neo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:0 0.5:2 0.9:8 1.0:16", nlocation="0.0:0 0.5:0.5 0.9:2 1.0:4")
SMDegrain(tr=3, thSAD=400, thSADC=50, refinemotion=true, truemotion=false, Str=5.0, pel=1, subpixel=2, prefilter=PRE, chroma=true, plane=4)

I see less smearing and better detail retention. SMDegrain has been partially optimized with Zopti for better qual/perf, and it's going to see better improvements on the following weeks.

With contrasharp=100 all your grain is back because the prefilter clip 'PRE' barely denoises and now 'contrasharp=n' (LSFplus) is doing a better recovery job. You can try with:
SMDegrain(tr=3, thSAD=300, thSADC=50, contrasharp=40, refinemotion=true, truemotion=false, Str=5.0, pel=1, subpixel=2, prefilter=2, chroma=true, plane=4)
Other internal prefilters also ok 0~7.

[LeXXuz]

Thanks for your reply Dogway. I think I should've added more detail about how I use SMD in the first place, sorry. :o
I think you mean neo_dfttest()?
PRE=neo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:0 0.5:2 0.9:8 1.0:16", nlocation="0.0:0 0.5:0.5 0.9:2 1.0:4")
NotSMDegrain(tr=3, thSAD=200, thSADC=50, refinemotion=true, truemotion=false, Str=1.0, pel=1, subpixel=2, prefilter=PRE, chroma=true, plane=4)


I've used real.finder's stuff so far. sneo_dfttst() is a helper function to use neo_dfttest() with different sigma strings for luma and chroma




That's the your call updated and without contrasharp.

I compared to:
PRE=neo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:0 0.5:2 0.9:8 1.0:16", nlocation="0.0:0 0.5:0.5 0.9:2 1.0:4")
SMDegrain(tr=3, thSAD=400, thSADC=50, refinemotion=true, truemotion=false, Str=5.0, pel=1, subpixel=2, prefilter=PRE, chroma=true, plane=4)

With contrasharp=100 all your grain is back because the prefilter clip 'PRE' barely denoises and now 'contrasharp=n' (LSFplus) is doing a better recovery job.


I already had the feeling that something was off with LSFmod in NotSMDegrain(). I had to use quite high values to even recognize some sharpening in the final output (and some increase in file size). You may remember I already mentioned this here. (https://forum.doom9.org/showthread.php?p=1966480#post1966480)

I understand now that the value is much too high for your version of SMD as the sharpener seems to be working (again) as it should. So I have to find new values for my presets.

I made myself a few different presets over the past months for a wider variety of grain in sources. From sources with hardly visible grain to extremely grainy ones.
My example above was for a source with very little grain, hence the small values for dfttest and thSAD.


I see less smearing and better detail retention. SMDegrain has been partially optimized with Zopti for better qual/perf, and it's going to see better improvements on the following weeks.


That's one of the major problems I had with SMDegrain so far. On higher values with very grainy sources I decided to skip sharpening at all because some subtle textures like skin pores, fine suit textures and such became blurry/smeared as soon as there was movement involved and on the other hand looked very sharp when they stood still. This gave the picture a very unnatural look which, to my taste, was worse than the original grainy look.

I'm also very carefull with chroma denoising, that's why I prefer a ratio of 3:1 or even 4:1 between luma and chroma, depending on source.

[Dogway]

LSFplus is a top-to-bottom refactor of LSFmod (more over the contrasharpening block), and it makes much more sense. I didn't repurpose the filter, just made more sense out of it following some Didée's suggestions and greatly optimizing and improving the code at the same time.

The thing is LSFmod was mostly meant to be used for SD content. I had to add back 'old' (now named 'LSF') method and make it default for HD.

The sharpening method people prefers varies greatly, as it also depends on the source condition so you can even use a separate sharpener with some temporal limiting (ie. with soothe), etc. By the way you can also use temporal limited sharpening within SMDegrain, simply set 'limitS=false'.

As for the smearing, I made great efforts with that. First there is the internal luma_rebuild, I recommend the default Str=5.0 to separate dark elements better. Then I made LFR, to recover low frequency smearing.
As for the chroma, all my tests showed an ideal ratio (scaleCSAD) of 1:2 for good content, even for grainy HD. For SD it switches to 2:1. There are HUE lines that MAnalyse can pick up in chroma and are not clear in luma so it's important for vector structure.
There are some automations internally for defaults, so check defaults with show=true to have some ground to test from.

EDIT: To make it clear. Prefiltering is as important as MDegrain. Prefilter spatially as you would stand-alone, no need to be perfect but in the ballpark (falling short if any). Then let MDegrain do the dirty job.

[LeXXuz]

Thanks for that detailed explanation Dogway.

Guess I have quite a lot to play around with to find some new presets for me. In theory any movie/source is different and needs special adjustment on its own for optimum results. But this would clearly exceed the free time and motivation I have, so I'm trying to find some different presets as a compromise for most of my sources.

What about the temporal radius? I used tr=6 with values even up to 12 in old SMDegrain for some of the nastier stuff. I see the range is now 1-9 so I guess the scale is different? How high would/should you go with tr for little grain up to really nasty ones?

[Dogway]

IMO anything higher than 3-4 is a waste of time, it might indicate a problem with prefiltering.
I don't know what you work with but for live action there's little temporal correlation.

Try to play with the function definition sliders to get there faster, I only exposed the main ones to care about.

[LeXXuz]

It's mostly movies and TV-Shows on Blu-ray as source.

Yes I've seen there's a lot more switches and functions to play around with. :)

[tormento]

IMO anything higher than 3-4 is a waste of time, it might indicate a problem with prefiltering.
There are really bad movies outta there :p

Sometimes I had to use thsad=900 up to 1200 :eek:

Then I learned about double pass denoising.

I always thought that increasing the frame span, besides denoising better, increases its precision. Am I wrong?

[LeXXuz]

That is very high. The result would most likely show quite some ghosting/smearing in moving objects. Wouldn't it?

[Dogway]

There are really bad movies outta there :p

Sometimes I had to use thsad=900 up to 1200 :eek:

Then I learned about double pass denoising.

I always thought that increasing the frame span, besides denoising better, increases its precision. Am I wrong?

Theoretically yes, maybe for true static like anime, but for live action half a pixel is the difference between sharp and blurry, MAnalyse might have a hard time picking half a pixel change more so in noisy clips and the higher the 'tr' the blurrier the output. MAnalyse is lacking rotational and zoom predictors, so the stakes are high.

Double pass is more effective as it performs a binomial weighting to the pixel motion estimation, the furthest frames having less weight.
Also for larger 'tr' all the truemotion and vector penalty settings lose their meaning and turn basically to noop. Read that on a DTL post but can't track it. So for my next Zopti tests I'm going to optimize for tr=1.

[VoodooFX]

What that means: "Resize: height must be greater than 0.", when I add to script "FlatMask()"?

ExTools.avsi line 1793
ExTools.avsi line 1820
SMDegrain v3.5.0d.avsi line 893
MasksPack.avsi line 161

AvS+ 3.7.2, and latest scripts from your github.

PS:
Could it do magic on sample there? -> https://forum.doom9.org/showthread.php?p=1968672#post1968672

[Dogway]

Yes thanks, looks like an ex_retinex() issue with small clips (actually ex_gaussianblur() ). I'm having a look, for the time being you can disable that line (161 ln on MasksPack), as it's doesn't seem essential for this task even maybe harmful as it wasn't designed for halos...

https://i.imgur.com/nuPZtCf.png

[LeXXuz]

I did a few more encodes with SMDegrain in the meantime.

I think there is a slight visible improvement over the old version when it comes to detail retention, movement and the ghosting/smearing problem. Which is very nice. :)

But the differences in file size are kinda worrying me, because in comparison to the slight visual improvements they are 'huge'.

I already raised thSAD and prefiltering values beyond what I was used to from the old version. And yet there is still quite a big difference in filesize.

To give an example. With the old version and these settings:

LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\neo-dfttest_rf-fix\64\neo-dfttest.dll") #fixed version by real.finder from 05/29/21
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\neo-f3kdb_r6\clang-x64\neo-f3kdb.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\masktools2-v2.2.26\x64_clang\masktools2.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\mvtools-2.7.44\x64\mvtools2.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\RgTools-v1.1\x64_LLVM_build\RgTools.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\MedianBlur2_v1.1\x64_Clang\MedianBlur2.dll")
#
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\LSFmod.avsi") #v2.193
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\NotSMDegrain.avsi") #v3.1.2.116s mod for v3.1.2d
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\Zs_RF_Shared.avsi") #v1.147
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\mtmodes.avsi")
#
ConvertBits(16)
PRE=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:0 0.5:2 0.9:8 1.0:16", chrslocation="0.0:0 0.5:0.5 0.9:2 1.0:4"))
NotSMDegrain(tr=3, thSAD=200, thSADC=50, contrasharp=100, refinemotion=true, truemotion=false, Str=1.0, pel=1, subpixel=2, prefilter=PRE, chroma=true, plane=4)
neo_f3kdb(range=30, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(12,12)
Return(Last)


I ended up with an HEVC file of 8,04GB.

With the new version and these settings:

LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\neo-dfttest_rf-fix\64\neo-dfttest.dll") #fixed version by real.finder from 05/29/21
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\neo-f3kdb_r6\clang-x64\neo-f3kdb.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\masktools2-v2.2.26\x64_clang\masktools2.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\mvtools-2.7.44\x64\mvtools2.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\RgTools-v1.1\x64_LLVM_build\RgTools.dll")
LoadPlugin("c:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\MedianBlur2_v1.1\x64_Clang\MedianBlur2.dll")
#
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\GradePack.avsi") #v7.1
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\ResizersPack.avsi") #v9.2
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\SharpenersPack.avsi") #v4.2
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\ExTools.avsi") #v8.4
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\LSFplus.avsi") #v5.3
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\SMDegrain.avsi") #v3.5.0.d
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\Zs_RF_Shared.avsi") #v1.147
Import("C:\Video Editing\MeGUI (x64)\tools\avisynth_plugin\mtmodes.avsi")
#
ConvertBits(16)
PRE=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:0 0.5:8 0.9:16 1.0:32", chrslocation="0.0:0 0.5:4 0.9:8 1.0:16"))
SMDegrain(tr=3, thSAD=400, thSADC=200, contrasharp=20, refinemotion=true, truemotion=false, Str=5.0, pel=1, subpixel=2, prefilter=PRE, chroma=true, plane=4)
neo_f3kdb(range=30, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(12,12)
Return(Last)

I ended up with an HEVC file of 10,86GB.
Encoder settings are exactly the same for both files of course.

That's a 35% gain in file size. I just wonder if I may do something wrong or something is not working right. (Or was not working right before) :o

[VoodooFX]

disable that line (161 ln on MasksPack)
That made it work. Thanks.

[Dogway]

That's a 35% gain in file size. I just wonder if I may do something wrong or something is not working right. (Or was not working right before) :o

Let me have a deeper look as it seems LSFplus smode=5 had issues with secure implementation. secure=false retrieves what seems LSFmod parity, but this is not good for flat areas where banding might occur. I need some time and concentration so will check the expression when I have time.

EDIT: Looks like it was a simple swap of clip variables. I'd swear I had fixed that before, but anyways check now, updated LSFplus and ExTools.

[LeXXuz]

Let me have a deeper look as it seems LSFplus smode=5 had issues with secure implementation. secure=false retrieves what seems LSFmod parity, but this is not good for flat areas where banding might occur. I need some time and concentration so will check the expression when I have time.

I'm very grateful guys like you share their vast knowledge about digital video with the community. Giving normal 'users' like me tools at hand that even professional studios don't have (judging by the quality of many commercial sources out there...) :thanks:

So take all the time you need. ;) In the meantime I'll do some double encodes without contrasharp at all to see how the differences between old and new SMDegrain play out.

[Julek]

Finally ported (https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/DeblockPack.avsi#L203). It acts more like a chroma deblocker so added into DeblockPack. I added a few optimizations and features so you might want to give it a look.
I finally updated my version (https://github.com/dnjulek/jvsfunc/blob/ef910ec7d499f20df11fa99e8bf4e60401abf36e/jvsfunc/expr.py#L31-L35), I made the matrix size more settable.

[anton_foy]

I try to find ex_occlusion() but I cannot find it, in which pack is it?

[Julek]

I try to find ex_occlusion() but I cannot find it, in which pack is it?

rebranded as MotionMask() (https://github.com/Dogway/Avisynth-Scripts/blob/3ff93a06fb641afc7f712efe54929e03bb1f2fa3/MasksPack.avsi#L345)

[anton_foy]

rebranded as MotionMask() (https://github.com/Dogway/Avisynth-Scripts/blob/3ff93a06fb641afc7f712efe54929e03bb1f2fa3/MasksPack.avsi#L345)

Oh I see, thanks!

[LeXXuz]

EDIT: Looks like it was a simple swap of clip variables. I'd swear I had fixed that before, but anyways check now, updated LSFplus and ExTools.

Oops. Totally missed your edit in that post. :o

Just wanted to tell my findings with the (now obsolete) old version. But I'll do it anyway. :D

Did a couple of tests with Blu-ray and DVD sources.
- there was not much of a difference between cs=50 and cs=100 in filesize
- cs=5 however resulted in a notably bigger file than cs=100/50 (setting too low or out of range maybe?)
- LSFplus with CS=50 & limitS=false produced filesizes about equal to cs=true setting
- limitS=true produced much bigger files than limitS=false (that really confused me, thought the limiter should reduce sharpen strength? Or is this because of the swap error in the code?)

However, I'll get the new versions and redo those encodes. Let's see how filesizes will behave. :)

[Dogway]

Just wanted to tell my findings with the (now obsolete) old version. But I'll do it anyway. :D

Yes sorry, retest if you can as the output made no sense. I think I had been working with another 'secure' optimization with that order and got them mixed up.
Now it should behave as expected (I hope). At the time I recall I preferred contrasharp=true rather than LSF, but now I don't know, specially with the limiters.

[LeXXuz]

Yes sorry, retest if you can as the output made no sense. I think I had been working with another 'secure' optimization with that order and got them mixed up.
Now it should behave as expected (I hope). At the time I recall I preferred contrasharp=true rather than LSF, but now I don't know, specially with the limiters.

No worries. ;)

Can't run the new LSFplus version though. Get an error upon avs import. See pic:
https://abload.de/thumb/screenshot2022-05-141y5j0f.jpg (https://abload.de/image.php?img=screenshot2022-05-141y5j0f.jpg)

My script has not been changed. Just replaced LSFPlus and Extools with newer versions.

[Dogway]

Thanks, you are using EX mod right? sometimes some bug might sneak in there as I don't hammer test them as much as MIX mods. Did a 'mode' remap in ExTools so it should work now. Update also LSFplus EX.

[LeXXuz]

Once again shame on me. :o
Just realized there are 2 different mods.
Yes, I downloaded the Ex mods.
But if you recommend Mix mods for max. speed I'd better switch to those.

[Dogway]

Yes no prob, just depends what suits you best. EX mods is there for legacy reasons and also max support for those out of Windows.

By the way I was playing a bit and came up with a faster method for corner masks.
removegrain(12)
a=removegrain(17)
removegrain(26)

ex_makediff(a, metric="none", aug=5, dif=true, show=3)

Yes, it's a bit hacky and not as good as CornerMask() but it's much faster.
I cobbled it up into one call for a 18% speed increase:
removegrain(12)
ex_lut("
x[-1,1] A@ x[1,-1] H@ dup1 dup1 min swap2 max
x[0,1] B@ x[0,-1] G@ dup1 dup1 min swap2 max
x[1,1] C@ x[-1,-1] F@ dup1 dup1 min swap2 max
x[-1,0] D@ x[1,0] E@ dup1 dup1 min swap2 max
swap3 max swap2 min
swap3 swap1 swap5 max swap3 min
min swap2 max
dup1 dup1 max swap2 min
x swap2 clip


A B dup1 dup1 min swap2 max
B C dup1 dup1 min swap2 max
C E dup1 dup1 min swap2 max
E H dup1 dup1 min swap2 max
swap7 swap1 swap5 max swap1 swap4 swap2 max max LO^
swap1 swap2 min min min HI^

G H dup1 dup1 min swap2 max
F G dup1 dup1 min swap2 max
D F dup1 dup1 min swap2 max
A D dup1 dup1 min swap2 max
swap7 swap1 swap5 max swap1 swap4 swap2 max max LO max LO^
swap1 swap2 min min min HI min HI@ LO

x swap2 min LO HI max clip

- abs 5 *")

# ex_luts(mode="max",pixels=ex_shape(3,mode="disk"),exprf=" ymin 2 * - 5 * 0 max") # (augmenting the dots)

Compared to CornerMask() (36fps) it's about 3 times faster, including the dot augmentation (101fps).

[LeXXuz]

Okay I did a few encodes with the new version. Source was an old movie on DVD in black & white.

This is roughly the filtering I used:
#
AssumeFPS(25)
CTelecine()
CPostProcessing()
crop(4, 0, 0, 0)
ConvertBits(16)
PRE=(sneo_dfttest(Y=3, U=1, V=1, tbsize=1, slocation="0.0:2 0.5:12 0.9:24 1.0:48"))
SMDegrain(tr=3, thSAD=600, thSADC=0, LFR=false, contrasharp=25, limitS=true, refinemotion=true, truemotion=true, DCTFlicker=true, Str=5.0, pel=2, subpixel=2, prefilter=PRE, chroma=false, plane=0)
neo_f3kdb(range=30, Y=64, Cb=0, Cr=0, grainY=32, grainC=0, sample_mode=4)
Greyscale()
Prefetch(16,16)
Return(Last)

Results (old faulty version in brackets):
contrasharp=25, limitS=false: 1.42GB (/)
contrasharp=25, limitS=true: 1.66GB (/)

contrasharp=50, limitS=false: 1.42GB (1.62GB)
contrasharp=50, limitS=true: 1.68GB (2.07GB)

contrasharp=100, limitS=false: 1.41GB (1.61GB)
contrasharp=100, limitS=true: 1.70GB (2.07GB)

contrasharp=true, limitS=false: 1.73GB
contrasharp=true, limitS=true: 1.65GB

Encoding speed with limitS=true was slightly faster than with limitS=false.


Conclusion:
- with limitS=false there is no difference in filesize between contrasharp=25/50/100
- with limitS=true the difference in filesize is quite small
- files with limitS=true are bigger than with false.

==>

If all this is correct I clearly misunderstand the 'limit' in limitS-parameter. I expected it to be the other way round. Maybe you can explain a little.

The value for contrasharp (strength of LSFplus) has little to no effect.

Is this what is to be expected with these settings or is there still something wrong maybe?

[Dogway]

That makes total sense to me, with limitS=false you are using temporal limiting, therefore having more temporal coherence and easier for the codec to compress interframe.

Also I understand you are using limitS=true with contrasharp=true right?

[LeXXuz]

with limitS=false you are using temporal limiting, therefore having more temporal coherence

Ah now I get it. Yes of course, that makes sense.


Also I understand you are using limitS=true with contrasharp=true right?

EDIT: Yes. I updated the results above and added:
contrasharp=true, limitS=false: 1.73GB
contrasharp=true, limitS=true: 1.65GB

I swear I double checked those numbers. It acts the other way round as with LSFplus. I'm confused again.

And the question remains why has the strength of LSFplus so little to no effect.
And what better to choose from. Contrasharp or LSFplus? Speed is of no concern. Quality is.

[DTL]

Okay I did a few encodes with the new version. Source was an old movie on DVD in black & white.

This is roughly the filtering I used:

SMDegrain(tr=3, thSAD=600,
Is this what is to be expected with these settings or is there still something wrong maybe?

If you need more degraining with quality you need to use as high tr value as possible (memory/threads/speed may limit) and as low thX values as possible. thSAD 600 may be too high for all-frame processing even in the DVD medium grain footage and cause more detail blurring. Typical mvtools builds support tr up to 128 with MDegrainN. It is not physical but some old programming limit like 'as high as never used value' being too slow at old CPUs. Unfortunately it is static array allocation limit so it is good to make dynamic in some new versions to remove this limit. Typically visible effect makes doubling of tr-value like 2,4,8,16,... Changing from 10 to 11 may be close to invisible.

Typically you adjust th-values just above starting to catch noise levels in the footage (and as high as allow to keep valueable details for example at skin textures) and next adjust tr-value to get the most practical degraining (if you not limited by hardware and time to process it have some bitdeph + encoder settings limit: after some high enough value the MPEG output speed and file size almost stop to decrease).

The new alt versions of MDegrain have motion-adaptive th-settings - https://forum.doom9.org/showthread.php?p=1962762#post1962762 . To increase th-values at static and large coherent moving patches and to use 'base' th-value at other blocks to decrease blurring and to increase degraining at static areas.

Theoretically yes, maybe for true static like anime, but for live action half a pixel is the difference between sharp and blurry, MAnalyse might have a hard time picking half a pixel change more so in noisy clips and the higher the 'tr' the blurrier the output.

To decrease noise-affected false movement in MAnalyse output for noisy footages the new MVLPF processing is added in the latest builds of MDegrainN - https://forum.doom9.org/showthread.php?p=1968988#post1968988
Currently 2 filter kernels available - hard cut-off sinc-based and some 'LPF-too' gauss kernel. I currently use gauss as it simple to control and not create over-under shoots in any setting. But I hope some day will read DSP filter design book and will finish filter design with definition both cut-off frequency and some controllable roll-off in pass-band to make it non over/under shooting and ringy. After filtering of MVs the SAD of new positions is re-checked again so too bad SAD-wise new positions are skipped and replaced with original from MAnalyse.

In theory any movie/source is different and needs special adjustment on its own for optimum results.

Practically every cutscene in a movie require its own best settings. It may be shot with different film ISO roll or different camera gain or other noise-reduction manual or auto settings in camera.

"What about the temporal radius? "

Theoretical limit of tr-value for 'ideal engine' sit between typical cutscene duration (several seconds to dozens of seconds X FPS/2 = 100..1000+) to total movie length (about 100000). This theoretical engine must find all occurrences of patch in the cutscene or total movie, perform compensation for all possible transforms and reconstruct patch looking in every frame removing random component that is typically noise. It is really sort of total rebuilding of movie using object-oriented approach. Practically the MPEG encoder makes something close to it but with encoding of residual noise as additional component that can not be compensated using current very limited and poor computing capabilities. So the 'ideal engine' do not have tr-param at all - it analyse all input frames to find all possible occurrences of object. And to prevent blurring (and other distortions like colour) it simply have 'ideal protection' from applying not ideally compensated transforms. Currently all protection from passing to blending operation too badly back-transformed block is based on simple SAD-checking. So to make protection better - we need to set thSAD as low as possible.

Also the protection from too bad blending based on 2 parts:
1. Hard limit by thSAD for total skipping too bad by SAD block from blending.
2. Some soft function for weighting of block's weight in blending for range of SAD in 0..thSAD. The shape of this function is hardcoded in old MDegrain* and some controllable by wpow param in new builds. Old hardcoded default of wpow=2. New builds allow to use 1 to 7 where 7 is simple equal weighting below thSAD (fastest). The actual shape of this weighting function is also subject to big research for some types of footages. Setting wpow above 2 allow to use more weight inside thSAD range and get more degraining, but may cause more distortions in some cases. In my encodings I typically use wpow=4.

Also planned but still not finally debugged some statistical analysis based on idea to check not SAD of current ref block vs current src in tr-scope but make first relative statistical analysis of all frames in tr scope to found most likely looking block in tr-scope and check thSAD of current ref block relative to most likely block. This should help not skip some ref blocks with SAD close to the edges of normal SAD distribution if current source block is located on the other side of normal distribution and SAD-distance close to 2x of the width of distribution. So with successful implementation will allow to set lower 'base' thSAD value with same degraining level and better protection from blurring.

Currently the mvtools makes very limited part of this - it find occurrences of some patch in tr-scope of frames around current and compensate of translate (shift) transform only. But for static parts of cutscene it already works very well so tr-scope for static parts of the frame may cover all cutscene duration.
For scripting it is possible to create motion-mask using mvtools may be too like MMask and process static and moving parts of cutscene with different tr-value (and th-values) to have less blurring of moving (complex transformed) areas of a frame. Though this sometime create effect of very clean static background and still noised moving areas. It still make MPEG average speed lower but some users may prefer evenly covered by noise image. Though in better case required noise should be added at playback.

[Dogway]

@DTL, a simple low-pass is going to distort edges too much you want to invert the the gauss weighting, just like I pointed with IQM, similar but more complex filters are MinBlur, guidedblur, ANguidedblur and of course bilateral (with some slight blur on top).

AFAIK whatever filtering you apply in the spectrum domain translates to the spatial domain but with less required radius (hence faster), so convert with FFT, apply gaussian LPF and convert back. Gaussian (or binomial) roll-off is smooth so that translates well to the image. For prefiltering I don't know if it's worth it at all, for things like Retinex it does because you apply high sigma radius.
That's unless you want to do passband filtering, in that case have a look at the ex_MFR() diagram in ExTools, since you do substraction spectrum energy is maintained.

The problem with high temporal radius is that the further frames are rarely correlated, since MDegrain performs a temporal mean average this looks risky. Maybe it might be worth to test a weighted average instead, it would lead to less denoising by default so some higher 'tr' should be used.

Did you mention before that 'pzero' or 'pnew' were not relevant for higher than tr=1? I tried to find your post without luck.

@LeXXuz: Yes, those numbers are suprising, but in any case they are two different monsters, I would try to visually compare them and see what they do and don't. If I recall correctly temporal limiting required a bit more sharpening, although some places are never going to sharpen due to the temporal nature.
After LSFplus v5.0 I would say that LSFplus should give more quality, as I chained the Smode algorithm directly to the LSFplus contrasharpening code block, but check visually anyway. I think the lower effect of the strength is because you are contrasharpening, that's totally different than plain LSFplus() sharpening, I also set over/undershoot to 0 to avoid ringing at any cost, so the sharpening is conservative. If you want stronger or very strong sharpening add it post SMDegrain().

[DTL]

"a simple low-pass is going to distort edges too much"

It is filtering of a sequence of MVs in 'time' domain. Not in 2D spatial. The 'ringing or over/under shoot' distortions of the edges values will decrease its efficiency and system just fallback to 'old MAnalyse output MVs' if SAD of the new expected-filtered position is too bad (hard above thSAD, but new filtered position is accepted if its SAD higher in compare with MAnalyse output because it may be distorted by noise). So I not like hard-cutoff sinc-based LPF without some smoothing and use gauss kernel now (with not as sharp cutoff of noise frequencies but easier in implementation and control and possibly better keeps the edges values from running away of good positions because of filtering issues). The actual noise-affected MVs coordinates of static blocks really jumps as hell here and there and their sequence definitely not follow any Nyquist-limiting or anti-gibbs conditioning so all nice developed filtering practices for 2D good images is not applicable to this type of input data to filter. To see how it jumps you can see MShow output in consecutive frames.

" so convert with FFT"

Currently it uses simple C-based convolution and runs fast enough with kernel size about 10. I do not think making FFT with too small size will make speed better. The only good thing of FFT-filtering is a way to apply required curve in 'graphical' form. Not create impulse kernel of filter with desired response.

"The problem with high temporal radius is that the further frames are rarely correlated"

It greatly depends on content - the static background with static lighting is about ideally correlated at the total cutscene duration. Example - static camera and static lighting and small narrator - https://imageban.ru/show/2022/05/13/931e829b35a87b3811aa82e872601c0c/png . About 90..90+% of blocks are close to ideally correlated at the all cutscene duration. In theory it is possible to mix MShow functions with MDegrain to enable 'debug output' text overlay of some statistics to help adjust parameters. For example % of totally skipped blocks in current tr-scope for each frame.
Also with slow enough camera pan we have lots of frames for translate-only compensation and again got very good correlation until block is still in camera visibility. This creates the effect of uneven degraining of static and slow moving areas without other transforms and other fast transformed areas with 'high enough' tr-value.

"Did you mention before that 'pzero' or 'pnew' were not relevant for higher than tr=1? "

I do not think so. They are applicable to every pair of current+ref pairs of frames sent to MAnalyse to process and these pairs processed completely independent (if temporal predictor is disabled). These penalties are about searching steps inside each level inside frames pair. Not about anything inbetween different pairs of frames to analyse. So influence of penalty values should not be any interconnected with tr-value.

"Maybe it might be worth to test a weighted average instead, it would lead to less denoising by default so some higher 'tr' should be used."

MDegrainN already in the 'old' 2.7.45 version create weighted blending based both on tr-distance and SAD value. For tr-distance it is controlled by thSAD2 param interpolation is something about cosine-shaped https://github.com/DTL2020/mvtools/blob/f0da1d9174e65867486d1321ba330471b3e4ee64/Sources/ClipFnc.cpp#L171 and for SAD value it is not user-controllable hardcoded weighting function https://github.com/pinterf/mvtools/blob/d8bdff7e02c15a28dcc6e9ef2ebeaa9d16cc1f56/Sources/MVDegrain3.h#L880 . In the newer builds SAD-weighting is controlled by wpow param.

[LeXXuz]

Thank you very much DTL and Dogway for your valued input.

I did a lot of encodes with SMDegrain 3.5.0.d recently before I started to test out Dogways current build. And I really mean A LOT.

My findings with that old build clearly backed up what you just wrote DTL. I had presets from (tr=2 & thSAD=150) up to (tr=16
and/or thSAD up to 600) for really really bad sources. Depending on the kind of grain/noise I had to deal with.

And of course you're right, technically every scene can be different. Some scenes looked awesome while others felt worse to the eye than their original counterpart. So it was/is always a compromise to use filtering. I kept some encodes to replace their originals. But I also discarded many encodes because I was not satisfied with the results. I have to admit I'm picky and if the results look (even just partially) bad in any way, I'd rather stay with the untouched source.

Adjusting the filtering for every movie anew already is tiresome work if you plan to transcode a vast collection. Adjust filtering on scene basis clearly exceeds the time I would and could spend on my hobby. I just want to reduce the size of my movie collection and optimize the visuals a little in the process so I have a smaller file with equal or even better visual quality in the end.

However, with Dogways current build my old presets don't work anymore. With his build there has been some great improvement on tricky scenes or objects with much less ghosting or smearing. From what I can see so far, I can use much higher thSAD values than before without destroying detail that would've been with the old version. Right now I'm very happy on that part. All I need now is to find a good setting for the sharpener as the cleaned output is a little softer without it, than the original. It's also funny how noise can be perceived as detail which really isn't there. So the cleaned picture 'feels' dull and a little blury, but it isn't in direct comparison.

I didn't really bother with transcoding in years. With storage space being dead cheap I just remuxed the movies I bought onto my NAS and be done with it.
But through other circumstances I now have quite a lot of CPU power at my disposal which made me revive my old hobby, very much to the burden of my electrical bill. :D

[Dogway]

Yeah, actually I don't know why I still develop SMDegrain lol. I do like my films grainy, but I still use it when grain is blocky or uneven/dirty, then add grain back.

You can automate scene based SMDegrain filtering with SceneStats, you need to enclose it in a ScriptClip block and tune your values according to the stats.

[tormento]

You can automate scene based SMDegrain filtering with SceneStats, you need to enclose it in a ScriptClip block and tune your values according to the stats.
Show us. :)

And please don't stop developing. GPU MVTools are arriving and perhaps a new native CUDA BM3D.

[LeXXuz]

Yeah, actually I don't know why I still develop SMDegrain lol.

Don't you dare and stop your amazing work! :eek::D

Looking at the early days of this forum and the filters/tools available back then, it's amazing how these evolved over the past two decades thanks to each and everyone involved in this process. :thanks:

And with filters like these some movie gems finally get the treatment they deserve. :)

[Dogway]

By the way Asd-g just released AGM (for AdaptiveGrainMask) plugin. I didn't know what it did until I read it's some kind of exposure reading so there is less overall grain on bright scenes, as it would happen naturally on film.
I'm tempted to try this with cretindesalpes plugin, haven't had time to check it.

Now that I think about it... it only looks for averageluma. Maybe I can implement the '_SceneExposure' algo described here (https://forum.doom9.org/showthread.php?p=1967432#post1967432) on a per frame basis, and use that for modulation in GrainFactory3mod. I mean, AGM is just an opacity mask, it won't tune grain size (among other) based on pixel value.

Scene based SMDegrain:

SceneStats(mode="Range+Stats+Motion+Detail+EV", interval=0.5, th=0.5, dFactor=3.7, show=false)

ScriptClip(function [] () {

sts = propGetAsArray("_SceneStats")
mo = propGetFloat ("_SceneMotion")
de = propGetFloat ("_SceneDetail")
ev = propGetInt ("_SceneExposure")
mo1 = min(6,round(exp(0.54*pow(mo,-0.44)+0.7)-2.9))
mo2 = round(-125*mo+112)
ev1 = ev==5?0:max(0,round(7.7*pow(ev,-0.44)-2.7))

SMDegrain(mo1, 400, prefilter=-1, ContraSharp=mo2, Str=ev1, RefineMotion=true)
} )


Probably for performance reasons it would be better to precompute prefilter clip outside ScriptClip.
Here I only plugged motion and exposure variables but you are free to use other stats or mix them to configure SMDegrain settings.

[LeXXuz]

And he just pulls that out of the hat. Just like that. :D

However integrating that succesfully into my scripts exceeds a little my Avisynth knowledge which is not much more than loading filters and setting parameters here and there. :o

[tormento]

However integrating that succesfully into my scripts exceeds a little my Avisynth knowledge which is not much more than loading filters and setting parameters here and there. :o
We share the same boat, pal. :o

[kedautinh12]

I meet error: "there is no function named "ZoptiResize" when use with video
https://drive.google.com/file/d/1b0WGyIOisK6GgJNs-M_49n7MuG4XFism/view?usp=sharing

my scripts:
LoadPlugin("C:\Megui\MeGUI-2924-64\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("C:\Users\ADMIN\Downloads\Yuuri - Betelgeuse [1440x1080i MPEG2 SSTV HD].ts")
AnimeIVTC(mode=1)
deep_resize(1920.0, 1080.0,edge="Zopti2",flat="SoftCubic100",show=false,th=0.6,elast=9)

[Dogway]

Yes sorry, Zopti2 has been deprecated, it's now called "Zopti" as original name, and old Zopti is now "ZoptiN" for Neutral.

[LeXXuz]

I've been playing around with different settings.

And I don't get it why this setup:
ConvertBits(16)
PRE=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:4 0.5:16 0.9:32 1.0:64", chrslocation="0.0:2 0.5:8 0.9:16 1.0:32"))
SMDegrain(tr=6, thSAD=600, contrasharp=50, limitS=true, LFR=150, DCTFlicker=true, refinemotion=true, truemotion=true, Str=5.0, pel=2, subpixel=3, prefilter=PRE, chroma=true, plane=4)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(16,16)
Return(Last

is much slower than this one:
ConvertBits(16)
PRE=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:4 0.5:16 0.9:32 1.0:64", chrslocation="0.0:2 0.5:8 0.9:16 1.0:32"))
PRE2=SMDegrain(tr=3, thSAD=600, blksize=32, contrasharp=false, limitS=true, LFR=150, DCTFlicker=true, refinemotion=true, truemotion=true, Str=5.0, pel=2, subpixel=3, prefilter=PRE, chroma=true, plane=4)
SMDegrain(tr=6, thSAD=300, blksize=32, contrasharp=50, limitS=true, LFR=false, DCTFlicker=false, refinemotion=true, truemotion=true, Str=5.0, pel=2, subpixel=3, prefilter=PRE2, chroma=true, plane=4)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(16,16)
Return(Last)

Or this one:
ConvertBits(16)
PRE=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:4 0.5:16 0.9:32 1.0:64", chrslocation="0.0:2 0.5:8 0.9:16 1.0:32"))
PRE2=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:2 0.5:8 0.9:16 1.0:32", chrslocation="0.0:1 0.5:4 0.9:8 1.0:16"))
SMDegrain(tr=6, thSAD=600, blksize=32, contrasharp=false, limitS=true, LFR=150, DCTFlicker=true, refinemotion=true, truemotion=true, Str=5.0, pel=2, subpixel=3, prefilter=PRE, chroma=true, plane=4)
SMDegrain(tr=3, thSAD=300, blksize=32, contrasharp=50, limitS=true, LFR=false, DCTFlicker=false, refinemotion=true, truemotion=true, Str=5.0, pel=2, subpixel=3, prefilter=PRE2, chroma=true, plane=4)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(16,16)
Return(Last)

Results:
https://abload.de/img/enc_times5mjl4.png (https://abload.de/image.php?img=enc_times5mjl4.png)

Filesizes don't differ that much so the encoder has about the same workload. What do I miss here? :eek:

[Dogway]

Sure, you are using blksize=32, so 4 times less blocks than say 16, but precision in MV is not going to very good so visually check everything is fine.

[LeXXuz]

Sure, you are using blksize=32, so 4 times less blocks than say 16, but precision in MV is not going to very good so visually check everything is fine.

Totally missed that. Thanks Dogway. :)

EDIT: So increase in blocksize decreases mv precision. 16 is default, right? Would it benefit to go down to 8 if speed is of less concern? Or is the possible visual gain negligible?

[DTL]

Mvtools default blocksize is 8. In some scripts I see recalculation down to 4 for best quality.

increase in blocksize decreases mv precision. '

Not only. It will either blur areas with small different moving objects with large enough thSAD or not degrain with low. Also will more distort edges of objects even with overlap enabled.

[LeXXuz]

That's interesting and could explain some effects I've seen during my tests.
I'll give it a try with 4 then if there is no other penalty than speed.

[DTL]

"give it a try with 4"

4 may be too low to search directly. It may be better to start search from 8x8 or bigger and recalculate (refine) down to 4x4.

MRecalculate: Refines and recalculates motion data of previously estimated (by MAnalyse) motion vectors with different super clip or new parameters set (e.g. lesser block size), after divide, etc. The two-stage method may be also useful for more stable (robust) motion estimation. The refining is at finest hierarchical level only. Interpolated vectors of old blocks are used as predictors for new vectors, with recalculation of SAD. Only bad quality new vectors with SAD above threshold thSAD will be re-estimated by search. thSAD value is scaled to 8x8 block size. Good vectors are not changed, but their SAD will be re-calculated and updated.

As I see at github the SMDegrain script can do 1 step half size refining with MRecalculate in refinemotion=true mode. So if you use initial blocksize 8 and set refinemotion=true it makes refining to 4x4.

More complex scripts can do >1 step refining so you can start from larger block size like 32x32 to decrease probability of gross search error and make 3 steps refining to 4x4 for best quality.

[LeXXuz]

So if you use initial blocksize 8 and set refinemotion=true it makes refining to 4x4.


Thanks DTL, I'll give that a try. :)


More complex scripts can do >1 step refining so you can start from larger block size like 32x32 to decrease probability of gross search error and make 3 steps refining to 4x4 for best quality.

Maybe Dogway will add that one day to SMDegrain. :rolleyes::D

[DTL]

"Maybe Dogway will add that one day to SMDegrain"

refinemotion may be changed from single true/false bool to 0 if no refine or number of refine steps. Typical everyday scripts may be designed to have acceptable speed/quality. Not best possible results with low speed.

Also for possibly a bit better quality you may check pel=4. It looks like typical precision of MPEG encoders search now. If found and applied correctly it should save from blurring a bit better. Though it is much slower and need about 4x more RAM in compare with pel=2. So with too much of threads and large frame size it is easy to run out of memory.

[LeXXuz]

Just running a test. Performance is lower but still okay with blksize=8, pel=4, subpel=3. Around 14FPS now which was ~19FPS before. Machine has 128GB. So memory should not become a bottleneck.

[DTL]

About 'blocksize' in processing: Smallest possible for refining with 'full-samples' size and 4:2:0 is 2x2 luma and 1 chroma samples pair. Though if going down to subsample processing it may be smaller. So it is in theory possible to make refining down to 'per-sample' processing - not per-block. It possibly may reduce some limitations of method based on very limited number of possible to process transforms in current MVtools.

Do not know why current limitation of SMDegrain is: SMDegrain: For RefineMotion you need a blksize of at least 8. If set 4x4 and refine to 2x2 it should be still supported by MVtools ? May be because overlap of 1 is not valid for 2x2 4:2:0 blocks ? So it is needed to convert to 4:4:4 to use refining to lower blocksizes.

Current limitation of min blocksize processing may be easily workarounded by upsizing clip before process and downsizing back after process. But it will be slower and require more RAM.
The script for test about:
N=2 (or 3,4,5...)
MyLovelyResize(width*N, height*N)
SMDegrain(...)
MyLovelyResize(width/N, height/N)

(may be a bit better to use Upsample/Desample functions pairs from jpsdr ResampleMT)

With N=2 and blocksize in degrain 8 and refinemotion=true it will be equal to processing blocksize 4x4 and refining to 2x2 (and doubling of pel precision). Unfortunately it may degrade quality with 'large starting blocksize' so it is better to add more refining steps in degrain script.

Also for better resistance to noise-errors with small blocksizes it may be better to use multi-stage processing starting from large blocksize and lower thSAD values to keep from error-blurring at stages with large blocksize. Also for processing with small blocksize to get less noise-based positions errors it may be good to test with new MVLPF processing versions.

Like
my_thSAD=...(typical thSAD/1.2)
next_step=1.2
SMDegrain(blocksize=16, thSAD=my_thSAD, refinemotion=true)
SMDegrain(blocksize=8, thSAD=my_thSAD*next_step, refinemotion=true)

[LeXXuz]

Like
my_thSAD=...(typical thSAD/1.2)
next_step=1.2
SMDegrain(blocksize=16, thSAD=my_thSAD, refinemotion=true)
SMDegrain(blocksize=8, thSAD=my_thSAD*next_step, refinemotion=true)

Thanks DTL. I'll give that a try, too. :)
The last time I actively used 2-stage denoising I wasn't really happy with the results. Because smearing and ghosting in fine textures was kinda awful. However, that was with a rather old version way before Dogway implemented all those updates and without modifying the blocksize because I simply didn't know better at that time. :o

[LeXXuz]

I have a DVD film here with some poor black levels and lots of noise in those black areas.

https://abload.de/thumb/darknoise38jys.png (https://abload.de/image.php?img=darknoise38jys.png)

I've used this so far:


ConvertBits(16)
PRE1=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:3 0.5:12 0.9:24 1.0:48", chrslocation="0.0:1.5 0.5:6 0.9:12 1.0:24"))
PRE2=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:2 0.5:8 0.9:16 1.0:32", chrslocation="0.0:1 0.5:4 0.9:8 1.0:16"))
SMDegrain(tr=6, thSAD=400, blksize=8, contrasharp=false, limitS=true, LFR=150, DCTFlicker=true, refinemotion=true, truemotion=true, Str=5.0, pel=4, subpixel=3, prefilter=PRE2, chroma=true, plane=4)
SMDegrain(tr=3, thSAD=600, blksize=8, contrasharp=50, limitS=true, LFR=false, DCTFlicker=false, refinemotion=true, truemotion=true, Str=5.0, pel=4, subpixel=3, prefilter=PRE1, chroma=true, plane=4)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(16,16)
Return(Last)


Daylight sceenes and even indoors look fine. But dark areas still have either noise or somethin that looks like a static noise curtain now.

Would appreciate any advice where/how to tweak.

[DTL]

It may be better to provide sample video for download.

[LeXXuz]

It may be better to provide sample video for download.

You are probably right. Here is a sample file:
https://send.cm/d/BLrs

[DTL]

I check it. It looks the script somewhere create great 'shadow detail gain up' and it greatly increase residual dark noise.

I run simple mvtools-based script using my latest build from https://forum.doom9.org/showthread.php?p=1968988#post1968988


LoadPlugin("mvtools2.dll")
LoadPlugin("ffms2.dll")

FFMpegSource2("testsample-001.mkv")

tr = 12 # Temporal radius
super = MSuper (mt=false, chroma=true,pel=2, hpad=8, vpad=8, levels=0)
multi_vec = MAnalyse (super, multi=true, blksize=8, delta=tr, chroma=true, overlap=4, mt=false, optSearchOption=1, levels=0, scaleCSAD=0)
MDegrainN(super, multi_vec, tr, thSAD=300, thSAD2=290, mt=false, wpow=4, thSCD1=350, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16, MVLPFGauss=0.9, thMVLPFCorr=50)


And it make much less noise at the dark areas of this frame - https://i1.imageban.ru/out/2022/05/26/00c0f8ed1ec8806b2abbe1d49b49deb3.png . I do not tweak parameters - it is some defaults from some testing of different versions with not very noisy content.

[LeXXuz]

I check it. It looks the script somewhere create great 'shadow detail gain up' and it greatly increase residual dark noise.
Dogway where are you? :D


And it make much less noise at the dark areas of this frame - https://i1.imageban.ru/out/2022/05/26/00c0f8ed1ec8806b2abbe1d49b49deb3.png . I do not tweak parameters - it is some defaults from some testing of different versions with not very noisy content.

Thank you DTL. :) That looks much better indeed. :eek:
I'll give that a try on the entire film and see how it plays out. :)

[DTL]

May be it is something about attempt to keep more details in shadows ? Also can it be levels 0<->16 different conversions to RGB ? I make preview of script in VirtualDub and framegrab via Ctrl+1 command.

May be you can start from disabling most of additional processing like neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4) to see what cause dark noise increasing.

[LeXXuz]

I have a DVD film here with some poor black levels and lots of noise in those black areas.

https://abload.de/thumb/darknoise38jys.png (https://abload.de/image.php?img=darknoise38jys.png)


Just to clarify: this is NOT the encoded output. It's a frame from the untouched source.

[DTL]

So you can show the processed source with a script of a dark scene to show the result.

[LeXXuz]

Sorry for any misunderstanding. I wanted to show the source pic to show you guys what I'm up against. And maybe to give some hints on how to tackle such noise the best way.

The output with SMdegrain() has much less noise but still visible in these scenes. Likewise I'm unsure about the black level as dark scenes clearly look too bright in the source. However, if I play around with PC/TV conversions the ouput got too dark. And it looks too bright when playing the DVD on my TV, too.

I'll show some comparisons with SMDegrain() when I'm back home later this weekend. :)

[guest]

Hi,

Can you please have a look at this...

https://forum.doom9.org/showthread.php?p=1969586#post1969586

DTL has been posting builds of Mvtools2, and I get an SMDegrain Line 645 error when checking with AVSMeter.

[LeXXuz]

So you can show the processed source with a script of a dark scene to show the result.

Okay I've encoded the film with the script provided by DTL and my script with SMDegrain. In addition I added sharpening by calling LSFPlus after denoising and finally debanding with f3kdb.

Scripts as follows:
tr = 12 # Temporal radius
super = MSuper (mt=false, chroma=true,pel=2, hpad=8, vpad=8, levels=0)
multi_vec = MAnalyse (super, multi=true, blksize=8, delta=tr, chroma=true, overlap=4, mt=false, optSearchOption=1, levels=0, scaleCSAD=0)
MDegrainN(super, multi_vec, tr, thSAD=300, thSAD2=290, mt=false, wpow=4, thSCD1=350, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16, MVLPFGauss=0.9, thMVLPFCorr=50)
ConvertBits(16)
LSFPlus(preset="slow", strength=100)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(16,16)
Return(Last)

I could not run DTL's script with 16 bit. I always got an Access Violation error, so I had to convert to 16 bit afterwards.

This is the script I used with SMDegrain:

ConvertBits(16)
PRE=(sneo_dfttest(Y=3, U=3, V=3, tbsize=1, slocation="0.0:2 0.5:8 0.9:16 1.0:32", chrslocation="0.0:1 0.5:4 0.9:8 1.0:16"))
SMDegrain(tr=12, thSAD=400, blksize=8, contrasharp=false, refinemotion=true, truemotion=true, Str=5.0, pel=2, subpixel=2, prefilter=PRE, chroma=true, plane=4)
LSFPlus(preset="slow", strength=100)
neo_f3kdb(range=15, Y=64, Cb=32, Cr=32, grainY=32, grainC=16, sample_mode=4)
Prefetch(20,20)
Return(Last)


First of, DTL's script filters the content fairly stronger, resulting in an about 20% smaller output file.

(Also the encoding speed was twice as fast, 23FPS <> 11FPS. BUT that comparison is not fair, as it filters only in 8 bit and is leaving less noise in the output for x265 to handle. So I just put this as a side note in parentheses.)

However, both versions produce a blurring effect I really dislike and keeps me questioning if I should use noise reduction after all to convert my collection.
(I also did encodes without LSFPlus and f3kdb which hat little to no effect to the problem.)

To elaborate:
I've uploaded three files onto send.cm. Please download them to watch as that site doesn't support Matroska containers for direct playback.
File1 (https://send.cm/d/Bk1B)
File2 (https://send.cm/d/Bk1C)
File3 (https://send.cm/d/Bk1D)

File 1 is the original MPEG2 source. File 2 is a conversion with DTL's script to HEVC. File 3 the conversion with SMDegrain.
(Note: I slightly changed the black levels in the conversions, so pay no mind on that pls.)

If you compare both conversions with the original, take a very close look at the texture of John Nettles' (the actor on the left) suit. As he moves away the texture will be washed out making the suit look like an uni-coloured blanket. So to speak.

On a frame-by-frame close-up I saw that some frames are even washed out in the orginal frames, however overall the suit has much more detail in the original than in both conversions.

Right now I'm so focused on this effect that I may be exaggerating. So I'd like some honest opinions on this.:)

No matter what I tweaked, I could NOT get a solution that got rid of this blurring while still doing a decent denoising job overall. Maybe this is just wishful thinking anyway without scene based denoising?

Someone once told me: you can't denoise a video without sacrificing at least some detail. And as much as noise filters have improved, I'm still entitled to say he's probably right. :(

[Dogway]

The blurring, which I call smearing is a known side-effect, it smears low frequency details.

For that I made the LFR arg to recover some, it brings back some dirt blobs so it's better used with DCT=true (I might improve this area).

ConvertBits(16)
SMDegrain(tr=12, thSAD=400, blksize=8, contrasharp=100, refinemotion=true, LFR=150, DCTflicker=true, Str=3.0, pel=2, subpixel=2, prefilter=6, chroma=true, plane=4)
ConvertBits(8,dither=1)

This is low frequency detail that is recovered, low contrast high frequency detail is going to be lost since it will read as noise because getting that fine motion vectors is unpractical. For that reason I usually add grain afterwards for some "hallucination". But I think you are going for the high compressibility/clean look.

If you just want to denoise low luma areas pass the denoiser through a lumamask()


---------------------------

By the way, on another note. I'm making a BATCH file to process images in an easy way, so one can leverage the powerful AVS tools with cjxl, the state-of-the-art JPEG XL image compression encoder.
As I observed all the programs I found either don't support JXL or they support it but scarce on filtering options. As an example, ImageMagick doesn't support jxl --quality argument, besides its bicubic scaler coefficients don't match avisynth's (avisynth adds a preblurring of some sorts) so it's hard to relate.
Will upload soon with some TransformsPack updates.

[DTL]

"I could not run DTL's script with 16 bit. I always got an Access Violation error, so I had to convert to 16 bit afterwards."

It looks some bug with 16bit input to MAnalyse now. Current workaround is to feed MAnalyse with 8bit input:


ConvertBits(16)
tr = 12 # Temporal radius
super = MSuper (mt=false, chroma=true,pel=2)
super8 = ConvertBits(8).MSuper (mt=false, chroma=true,pel=2)
multi_vec = MAnalyse (super8, multi=true, blksize=8, delta=tr, chroma=true, overlap=4, mt=false, optSearchOption=1)
MDegrainN(super, multi_vec, tr, thSAD=300, thSAD2=290, mt=false, wpow=4, thSCD1=350, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16, MVLPFGauss=0.9, thMVLPFCorr=50)


" take a very close look at the texture of John Nettles' (the actor on the left) suit. As he moves away the texture will be washed out making the suit look like an uni-coloured blanket. "

To possibly keep more low contrast details you can try more extreme settings like

tr = 15
super = MSuper (mt=false, chroma=true,pel=2)
super8 = ConvertBits(8).MSuper (mt=false, chroma=true,pel=2)
multi_vec = MAnalyse (super8, multi=true, blksize=8, delta=tr, search=3, searchparam=4, truemotion=true, chroma=true, overlap=4, mt=false, optSearchOption=1)
MDegrainN(super, multi_vec, tr, thSAD=100, thSAD2=100, mt=false, wpow=4, thSCD1=350, adjSADzeromv=0.3, adjSADcohmv=0.3, thCohMV=4, MVLPFGauss=0.9, thMVLPFCorr=20)


It will reduce global degrain level visibly. Though Dogway's script work also good. To keep more details - also try to use as low thSAD values as possible.

[Blankmedia]

I'm only here to talk about our lord and savior :

Flatmask

ex_retinex as no argument tv_in error on line 161.

Thanks again for your splendid work.

[Dogway]

I'm only here to talk about our lord and savior :

Flatmask

ex_retinex as no argument tv_in error on line 161.

Thanks again for your splendid work.

Did you update? tv_in was added in last commit (https://github.com/Dogway/Avisynth-Scripts/blob/2d509f9c8dacc332c090fd3560fc1b2e331296f1/SMDegrain%20v3.5.0d/SMDegrain%20v3.5.0d.avsi#L871).

Anyway just updated SMDegrain now with the most recent changes.

[Blankmedia]

Did you update? tv_in was added in last commit (https://github.com/Dogway/Avisynth-Scripts/blob/2d509f9c8dacc332c090fd3560fc1b2e331296f1/SMDegrain%20v3.5.0d/SMDegrain%20v3.5.0d.avsi#L871).

Anyway just updated SMDegrain now with the most recent changes.

-_-

Only thing I didn't update and I didn't check in what script ex_retinex was before posting.

thank you

[DTL]

"comparison is not fair, as it filters only in 8 bit "

If source is 8bit it may be faster to use 8bit processing before MDegrain and use out16=true switch to get 16bit output. So you can use dithered conversion to 8bit if required or left higher bitdepth if encoder support. Currently I see SMDegrain do not have such functionality but it may be not hard to add. It may make processing speed visibly faster because host RAM speed to handle large 'super' clips in double size in 16bit is slow now.

[tormento]

…
Why prefilter=7 wants VStCanny?

[Dogway]

Why prefilter=7 wants VStCanny?

Because ex_LFR(), depends on strength and source characteristics that the filter fallsback to vsTCanny.

[tormento]

Because ex_LFR(), depends on strength and source characteristics that the filter fallsback to vsTCanny.


Am I remembering wrong that 7 is DgDenoise prefilter? Why is it different in processing than 5 or 6 to need that procedure?

[Dogway]

Because I observed that it smeared low frequency details more than the other two (BM3D and KNLMeansCL) at parity settings, but have a look to double check just in case.

KNLMeansCL wmode=1 doesn't suffer of this issue.

By the way, vsTCanny is running on mode=-1, that means no edge detection, just a simple gaussian blur.

[kedautinh12]

Just use SMDegrain(prefilter=6, gpuid=-1). SMDegrain will choose BM3DCPU is prefilter

[guest]

Just use SMDegrain(prefilter=6, gpuid=-1). SMDegrain will choose BM3DCPU is prefilter

Hi ked, you've done it again, :thanks:

Just tested, seems to work :D


@ Line 200... gpuid = Default ( gpuid, 0) change to gpuid = Default ( gpuid, -1)

I had to change @ Line 1030, also....

[Dogway]

Wanted to share a script I'm using for processing 600dpi scans, to remove color half-tone (aka descreening).
It works nice with not too strong half-tones, preserving most details.

I know the common way to do this is in the frequency domain but I needed an automated way to process it.
I will upload the tools I'm using for cleaning scans (straighten, trimming, descreening) when I finish them.
Currently using OpenCV for Python as that's what I had on hand.

FFImageSource()
ConvertBits(16)
ConvertToYUV444(matrix="PC.601",ChromaInPlacement="MPEG1",chromaresample="spline36")

# EDGE SMOOTHING
a=ex_smooth(2, mode="SG", limit=true, sharp=true, UV=3)

# FLAT SMOOTHING
bl=a.ex_median(mode="CAM", thres=255, recursion=false,UV=3)

# MASK
ex_edge("kroon",100,120, scale=0.25, invert=false)
ex_binarize(200)
ex_expand(radius=2, mode="disk")
mt_deflate()
mt_deflate()
mt_merge(bl,a,last,luma=true)

# RESIZE
deep_resize(0.5,edge="ZoptiH",chroma="Zopti",grain=0.3)

# SHARPENING (Optional)
ex_unsharp(0.2, Fc=width(), th=0, safe=false)

# CLEAN REMAINING DOTS with threshold
a=removegrain(1)
expr(last,a,"y x - abs 16 > y x ?","") # Undot only for biggest change

ConvertFormat(1,fmt_out="RGB",cs_in="170M",cs_out="",EOTF="",cplace_in="center",mod=2,tv_in=false)
ConvertBits(8,dither=1)

[Blankmedia]

Wanted to share a script I'm using for processing 600dpi scans, to remove color half-tone (aka descreening).
It works nice with not too strong half-tones, preserving most details.

I know the common way to do this is in the frequency domain but I needed an automated way to process it.
I will upload the tools I'm using for cleaning scans (straighten, trimming, descreening) when I finish them.
Currently using OpenCV for Python as that's what I had on hand.

FFImageSource()
ConvertBits(16)

# EDGE SMOOTHING
a=ex_smooth(2, mode="SG", limit=true, sharp=true, UV=3)

# FLAT SMOOTHING
bl=a.ex_median(mode="CAM", thres=255, recursion=false,UV=3)

# MASK
ex_edge("kroon",100,120, scale=0.25, invert=false)
ex_binarize(200)
ex_expand(radius=2, mode="disk")
mt_deflate(radius=1)
mt_deflate(radius=1)
mt_merge(bl,a,last,luma=true)

# RESIZE
deep_resize(0.5,edge="ZoptiH",chroma="Zopti",grain=0.3)

# SHARPENING (Optional)
ex_unsharp(0.2, Fc=width(), th=0, safe=false)

# CLEAN REMAINING DOTS with threshold
a=removegrain(1)
expr(last,a,"y x - abs 16 > y x ?","") # Undot only for biggest change

ConvertBits(8,dither=1)

That's pretty for you to share

[VoodooFX]

Wanted to share a script I'm using for processing 600dpi scans, to remove color half-tone (aka descreening).
It works nice with not too strong half-tones, preserving most details.

ScanTailor not good?

[tormento]

ScanTailor not good?
Is there any recent release?

[Dogway]

ScanTailor not good?

Woow never heard of it. Looks good despite I'm a Photoshop hardcore user.

I downloaded ScanTailor Advanced, a fork with Windows build of 2019. Will play a bit, I think it also has a command line option so can do in bulk. I don't think it has descreening though.

Still I'm very interested on piping avisynth as I can do HBD conversion to RGB and HQ downscaling (using 'ZoptiH' in my case). I have a draft in BATCH which I'm using but want to make a GUI in AutoHotkey or something. Already using ExifTool to copy metadata and cjxl to compress in JXL. Saves quite a bit of space.


EDIT: Found updated builds here (https://github.com/vigri/scantailor-advanced/releases), which includes auto-dewarp. Unfortunately the latest version 1.0.18 implements Qt6 whichs is known to not support Win7 (many programs are following this trend these days)



EDIT2: I'm experimenting a bit with descreening. There's also ex_luts() but details are a bit too smoothed.
# Disk kernel trimmed mean
sh=ex_shape(2,mode="disk") # or sh=ex_shape(2,mode="ring")
str=sel_med(37)
ex_luts(mode="average", pixels=sh, exprf=" X^ "+str)

[tormento]

@Dogway

I need a fast and effective GPU only (well, for the heavy part at least) to remove grain and noise from anime.

I tried with BM3D+neof3 but I think you can pull a better rabbit from the hat.

My current script is:
ConvertBits(32)
BM3D_CUDA(sigma=3, radius=2)
BM3D_VAggregate(radius=2)
fmtc_bitdepth (bits=10,dmode=8)
neo_f3kdb(range=15, Y=65, Cb=40, Cr=40, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, mt=false, keep_tv_range=true)
I'd like also to give a try to the DGDenoise filter, how can I invoke your "mod" that we talked about from outside SMDegrain?

I'd like to reduce the CPU part at minimum, as I am encoding with x265. Even something with KNLMeansCL would be great.

Which filter is the most effective one as standalone or with very little CPU usage addon filter?

[Dogway]

non-local means is in my experience the best algo for flat areas (aka anime), I would try ex_KNLMeansCL(), by default it recovers low-frequency (wmode=0) so disable it if you want, LFR=0.

ex_KNLMeansCL(h=5,a=1,d=0,LFR=0) # play with h,a,d

You can pass it through FlatMask if you want to protect lineart.

[tormento]

non-local means is in my experience the best algo for flat areas
DGDenoise is non-local too.

Is there a way to call it externally, as I asked you, with the corrections you put in script?
You can pass it through FlatMask if you want to protect lineart.
Is it a simple FlatMask() call? Has it to be used before or after denoise?

[ChaosKing]

https://github.com/Dogway/Avisynth-Scripts/blob/66d33628a115e9f493e9ae9785a40258cb25c4c1/MasksPack.avsi#L113
### Example:
### filt = YourFilter()
### flatmask(1,filt=filt) # to merge with filtered clip

[Blankmedia]

DGDenoise is non-local too.

Is there a way to call it externally, as I asked you, with the corrections you put in script?

Is it a simple FlatMask() call? Has it to be used before or after denoise?

Little bit of cleanup/bluring before masking (in this case qith Flatmask) can do wonder.

https://forum.doom9.org/showthread.php?p=1959701#post1959701

Dogway helped me with this months ago.

Edit: I wasn't fully clear but I do something like this in some cartoon encode based on what Dogway shown me:

masklisse = ex_median("IQM").Flatmask(lo=2,MSR=45,scale=10).Removegrain(4).maa2()
# return ex_adddiff(masklisse.converttoyuv420(), dif=False)

denoised = last.denoisefilter()

MT_Merge(denoised , last ,masklisse.ex_Expand(1, "disk"),Luma=True)

you can pass the filtered clip directly in flatmask, but i like to do in sepratly in case i want to expand, inpand, infltate, deflate

[tormento]

@Dogway

I did many tests with anime filtering and the best results so far are with BM3D.

I have found, reading documentation, that it is actually an extension of non-local denoising, that's why it performs even better.

[kedautinh12]

@Dogway

I did many tests with anime filtering and the best results so far are with BM3D.

I have found, reading documentation, that it is actually an extension of non-local denoising, that's why it performs even better.

And how about with real world???

[tormento]

And how about with real world???
I always use it as prefilter in SMDegrain.

I have found it has the most consistent and detail preserving results.

[guest]

Hi, I updated to the latest Extools, and now I'm getting an error in SMDegrain @ Line 252

Lthres = ex_bs(75, 8, bi, tv_in=true, tv_out=!fsp)

[Dogway]

Hi, I updated to the latest Extools, and now I'm getting an error in SMDegrain @ Line 252

Lthres = ex_bs(75, 8, bi, tv_in=true, tv_out=!fsp)

Works fine here. ex_bs() now uses clamp() helper included in latest ExTools.

[guest]

Works fine here. ex_bs() now uses clamp() helper included in latest ExTools.

Of course it does, you modified it...

I don't know how to fix this, where does "clamp()" go ??

Whats a "helper" ?

Is it added to my scripts call ??

[Dogway]

Version is ExTools v8.6, clamp() function is declared here (https://github.com/Dogway/Avisynth-Scripts/blob/f3ce6e8e7cb59a3efe89836c882dbe2269562b5e/ExTools.avsi#L6929).

Without your call and the error log, I cannot do anything.

[guest]

Version is ExTools v8.6, clamp() function is declared here (https://github.com/Dogway/Avisynth-Scripts/blob/f3ce6e8e7cb59a3efe89836c882dbe2269562b5e/ExTools.avsi#L6929).

Without your call and the error log, I cannot do anything.

A thousand apologies, I just double checked the v8.6 script, and somehow I'd copied it incorrectly.
I had the QTGMC script in there, instead :(
It's now copied correctly, and IS working.

[guest]

Can anyone tell me how to get "lsb" (or it's equivalent) to work in SMDegrain, I have had no luck at all.

TIA

[kedautinh12]

Need errors log

[guest]

Need errors log

Hi ked, there really isn't any error logs.

I have a funny feeling that lsb=true (or similar), is not supported by Dogway's builds.

If I add lsb=true (or false), AVSMeter doesn't start it's query.

I'm not sure what dependencies it may or may not need.

[madey83]

hi All,

i've got very noisy source and i would like to clean it up as much as possible and keep as much as possible picture details to avoid waxy faces.

Could you please advice what SMDgrain settings should i use to achieve that?

[Dogway]

@madey83, depends on source noise. The more you remove the more waxy it ends. Basically just use refinemotion=true, a good prefilter and some type of contrasharpening. Adding back some grain also helps.

@TDS, Why do you want 'lsb'? It's deprecated. I don't know if real.finder version still supports it but I don't recommend you using lsb over internal HBD.

[ChaosKing]

Using smdegrain with very high settings and feeding it as a prefilter to smdegrain again can also help alot.

[Dogway]

Using smdegrain with very high settings and feeding it as a prefilter to smdegrain again can also help alot.

Yes, I have used that before for extreme cases and works really nice, the problem is mvtools performs rather bad when called more than once. Any pyramidal denoising approach (here pyramidal vector refinement) is good, it's actually employed also in audio denoising.

[guest]

@TDS, Why do you want 'lsb'? It's deprecated. I don't know if real.finder version still supports it but I don't recommend you using lsb over internal HBD.

Thanks for the explanation, as I haven't used real.finder's build for a long time, I cannot comment on that.

It was just something I tried, and it wouldn't work, so now I know.

Cheers

[LeXXuz]

Dogway what setting would you use, expecially what prefilter to use, to run SMDegrain as a general purpose filter which just removes/reduces very high frequency noise for a little bit better compressibility?

Also I'd like to know what you use to add grain after cleaning up the source. I also would like to try an approach to have a medium strong noise filter and add back some noise for a more natural look in the end.

After doing lots of testing with the last settings we spoke about I came to the conclusion to give up on my goal to clean all my sources as much as possible. I always found scenes and/or textures that looked just awful.

Don't get me wrong, SMDegrain is a damn fine denoiser compared to things I used years ago. Some movies look simply terrific with it. But I'm losing motivation to spend nearly hours on every damn movie to find the somewhat 'best' settings.

[Boulder]

For some minor compressibility improvement, I'd simply use SPresso or STPresso. The encoder will happily mangle the rest anyway :D

[Dogway]

Yes, STPresso is fine for very fine grain or compressibility.
For mid to high frequency only, pass it through ex_LFR(). I don't know if it's exactly the look you are after though. It depends a lot on source grain, more/coarser grain buries deeper into low frequencies, otherwise you can use SMDegrain(refinemotion=true, LFR=width()/2, DCTFlicker=true) or something along those lines (play with LFR values). Using SMDegrain gives more temporal coherence to the image, which helps further on compressibility.

SMDegrain is plain simple in concept, it doesn't try to do any voodoo but you can bend it any way you want with prefilters, mfilters, LFR, etc. With the trick ChaosKing mentioned, since SMDegrain prefiltering is too strong you can use LFR to recover everything but higher frequencies, so it doesn't distort much, and acts as a very high quality prefilter to feed again to SMDegrain. I don't know if at this stage it's better than ex_BM3D() or not.

I said before, I barely use SMDegrain myself. One good use is to give it a medium clean pass to add grain on top, not grain recovery but new high quality grain, this adds some hallucination that is lost with degrainers.

For the time being I use GrainFactory3mod, it's "good enough", but for over a year now I have wanted to find a good grain model for PP. In compositing, grain plates are commonly blended straight into the clip, there are some filters too but not too good, so I'm very interested on the papers shared by cretindesalpes in chickendream, I haven't had time to read in depth, I also have other papers on the topic, there actually aren't that many.

[ChaosKing]

I also use smdegrain as a prefilter (ref parameter) for BM3D sometimes to produce the mentioned "temporal coherence". Not sure if it can be achieved with bm3d only, still learning how to use this filter properly :D
Will definitely check out the lfr smdegrain combo.

[madey83]

Yes, STPresso is fine for very fine grain or compressibility.
For mid to high frequency only, pass it through ex_LFR(). I don't know if it's exactly the look you are after though. It depends a lot on source grain, more/coarser grain buries deeper into low frequencies, otherwise you can use SMDegrain(refinemotion=true, LFR=width()/2, DCTFlicker=true) or something along those lines (play with LFR values). Using SMDegrain gives more temporal coherence to the image, which helps further on compressibility.

SMDegrain is plain simple in concept, it doesn't try to do any voodoo but you can bend it any way you want with prefilters, mfilters, LFR, etc. With the trick ChaosKing mentioned, since SMDegrain prefiltering is too strong you can use LFR to recover everything but higher frequencies, so it doesn't distort much, and acts as a very high quality prefilter to feed again to SMDegrain. I don't know if at this stage it's better than ex_BM3D() or not.

I said before, I barely use SMDegrain myself. One good use is to give it a medium clean pass to add grain on top, not grain recovery but new high quality grain, this adds some hallucination that is lost with degrainers.

For the time being I use GrainFactory3mod, it's "good enough", but for over a year now I have wanted to find a good grain model for PP. In compositing, grain plates are commonly blended straight into the clip, there are some filters too but not too good, so I'm very interested on the papers shared by cretindesalpes in chickendream, I haven't had time to read in depth, I also have other papers on the topic, there actually aren't that many.
@Dogway,

could you please provide exact commands for SMDegrain with all prefilters as LeXXuz said for below general purpose:

1) minor background grain:

2) average grain for foreground and background

3) hard grain, like for example: band of brothers, pacific TV Shows


my general SMDegrain settings looks like:

import("E:\4k encode\Avisynth-Scripts-master\ExTools.avsi")
ConvertBits(16)
SMDegrain(tr=1, thSAD=300, thSCD2=100, contrasharp=false, refinemotion=true, pel=2, subpixel=3, search=3)
ConvertBits(bits=10, dither=1)

but when it comes to clean up hard grain like from Pacific tv show it wont work well.

[kedautinh12]

Yes, STPresso is fine for very fine grain or compressibility.
For mid to high frequency only, pass it through ex_LFR(). I don't know if it's exactly the look you are after though. It depends a lot on source grain, more/coarser grain buries deeper into low frequencies, otherwise you can use SMDegrain(refinemotion=true, LFR=width()/2, DCTFlicker=true) or something along those lines (play with LFR values). Using SMDegrain gives more temporal coherence to the image, which helps further on compressibility.

SMDegrain is plain simple in concept, it doesn't try to do any voodoo but you can bend it any way you want with prefilters, mfilters, LFR, etc. With the trick ChaosKing mentioned, since SMDegrain prefiltering is too strong you can use LFR to recover everything but higher frequencies, so it doesn't distort much, and acts as a very high quality prefilter to feed again to SMDegrain. I don't know if at this stage it's better than ex_BM3D() or not.

I said before, I barely use SMDegrain myself. One good use is to give it a medium clean pass to add grain on top, not grain recovery but new high quality grain, this adds some hallucination that is lost with degrainers.

For the time being I use GrainFactory3mod, it's "good enough", but for over a year now I have wanted to find a good grain model for PP. In compositing, grain plates are commonly blended straight into the clip, there are some filters too but not too good, so I'm very interested on the papers shared by cretindesalpes in chickendream, I haven't had time to read in depth, I also have other papers on the topic, there actually aren't that many.

You can try f3kgrain for add grain
https://github.com/kedaitinh12/AVSPlus-Scripts/blob/master/f3kgrain_v0.4MOD.avsi

[kedautinh12]

Dogway, can you share scripts when remove grain only work in smooth area and bypass details area??

[madey83]

Could someone explain to me where i did something wrong:

import("E:\4k encode\Avisynth-Scripts-master\ResizersPack.avsi")
import("E:\4k encode\Avisynth-Scripts-master\ExTools.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Main.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Models.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Transfers.avsi")
import("E:\4k encode\Avisynth-Scripts-master\EX mods\GrainFactory3mod.avsi")
import("E:\4k encode\Avisynth-Scripts-master\MIX mods\LSFplus.avsi")
ConvertBits(16)
SMDegrain(tr=2, thSAD=600, thSCD2=80, contrasharp=false, prefilter=6, refinemotion=true, LFR=150, DCTflicker=true, pel=2, subpixel=2, chroma=true, plane=4)
ConvertBits(bits=10, dither=1)


Script Error

Script error: There is no function named 'BM3D_CUDA'.
(E:\StaxRip-v2.13.0-x64\Apps\Plugins\AVS\SMDegrain\SMDegrain.avsi, line 1060)
(E:\StaxRip-v2.13.0-x64\Apps\Plugins\AVS\SMDegrain\SMDegrain.avsi, line 266)

[kedautinh12]

You lack bm3d filter
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/issues/7#issuecomment-886173346

[kedautinh12]

You need read dependencies in dogway's script .avsi

[madey83]

@kedautinh12

i have found it on github but this is VapourSynth not AviSynth plugin.

i tried load into StaxRip this dll: VapourSynth-BM3DCUDA-R2.8\bm3dcuda.dll

but it failed.

if you have direct download link to avi+ BM3DCUDA please share it.

[madey83]

You need read dependencies in dogway's script .avsi
it could be useful if dogway's script .avsi would have some remarks where to find additional plugins required by his functions.

this is not complain but only suggestion for noobies like me.

[StainlessS]

Avisynth Wiki:- http://avisynth.nl/index.php/Main_Page
With external filters link to,
External filters:- http://avisynth.nl/index.php/External_filters
64 bit filters linked from External Filters,
http://avisynth.nl/index.php/AviSynth%2B_x64_plugins

Google search:-

"avisynth" "BM3DCUDA"

https://www.google.co.uk/search?q=%22avisynth%22+%22BM3DCUDA%22+&ei=TgKzYsL1PNSA8gLusa8g&ved=0ahUKEwjC1Oev_8D4AhVUgFwKHe7YCwQQ4dUDCA0&uact=5&oq=%22avisynth%22+%22BM3DCUDA%22+&gs_lcp=Cgdnd3Mtd2l6EANKBAhBGAFKBAhGGABQlOwIWJTsCGCC8AhoAnAAeACAAYABiAGAAZIBAzAuMZgBAKABAcABAQ&sclient=gws-wiz


or google search with links ONLY from doom9 forum

"avisynth" "BM3DCUDA" site:forum.doom9.org

https://www.google.co.uk/search?q=%22avisynth%22+%22BM3DCUDA%22+site%3Aforum.doom9.org&ei=BQWzYsKCEJaX8gLD6b-QAQ&ved=0ahUKEwiCme76gcH4AhWWi1wKHcP0DxIQ4dUDCA0&uact=5&oq=%22avisynth%22+%22BM3DCUDA%22+site%3Aforum.doom9.org&gs_lcp=Cgdnd3Mtd2l6EANKBAhBGAFKBAhGGABQjwhYnRBg7S5oAXAAeACAAZ4FiAH4CJIBBzQuMS41LTGYAQCgAQHAAQE&sclient=gws-wiz

or Doom9 Search (at top of D9 page, use Advanced) for posts [not threads] "BM3DCUDA" (or try D9 search threads, Titles Only for main thread of plugin [if there is one]).

[kedautinh12]

@kedautinh12

i have found it on github but this is VapourSynth not AviSynth plugin.

i tried load into StaxRip this dll: VapourSynth-BM3DCUDA-R2.8\bm3dcuda.dll

but it failed.

if you have direct download link to avi+ BM3DCUDA please share it.

Please read slowly my link share and what tittle of that issuses?? And you don't click to my link share

[kedautinh12]

it could be useful if dogway's script .avsi would have some remarks where to find additional plugins required by his functions.

this is not complain but only suggestion for noobies like me.

That why you don't read my comment slowly. Just open .avsi with text edit application and read Dependencies
https://github.com/Dogway/Avisynth-Scripts/blob/f3ce6e8e7cb59a3efe89836c882dbe2269562b5e/SMDegrain%20v3.5.1d/SMDegrain%20v3.5.1d.avsi#L30

[madey83]

@kedautinh12

thank you for your links but i have already checked them and all pointing me out to the same source: https://github.com/WolframRhodium/VapourSynth-BM3DCUDA:
Script Error

'C:/VapourSynth-BM3DCUDA_RTC-R2.8/bm3dcuda_rtc.dll' cannot be used as a plugin for AviSynth.

i heave read dependencies from the SMDegrain script and i can't find any information about external plugins which needs to be added.

this is also mentioned in the script:

Wrapper for BM3D CUDA by WolframRhodium for AviSynth+
# Requires TransformsPack for OPP=true, RGB clips or processing chroma
#
# Disclaimer: ffvideosource() causes issues with BM3D for UV=1 or r>3
# BM3D() causes issues when gpuid >= 0 (CUDA) and you crop with DGSource()
# BM3D() causes issues when gpuid >= 0 (CUDA) and a high combination of radius + sigma unless you fine tune 'block_step' argument
#
# # Some of the following arguments aren't available on the BM3D AVS+ port but included here for reference (namely group_size, block_size, bm_step and ps_step)

so i added few additional avsi+ scripts into my StaxRip. Maybe it is to much but....

Import("E:\4k encode\Avisynth-Scripts-master\ResizersPack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\MIX mods\LSFplus.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\MIX mods\SharpenersPack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\GradePack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\ScenesPack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\MasksPack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\MIX mods\Spresso.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\SMDegrain v3.5.1d\SMDegrain v3.5.1d.avsi")
import("E:\4k encode\Avisynth-Scripts-master\ExTools.avsi")
import("E:\4k encode\Avisynth-Scripts-master\EX mods\GrainFactory3mod.avsi")
import("E:\4k encode\Avisynth-Scripts-master\EX mods\DeblockPack.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Main.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Models.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Transfers.avsi")
loadplugin("C:\Users\lukas\Downloads\VapourSynth-BM3DCUDA_RTC-R2.8\bm3dcuda_rtc.dll")

SetMemoryMax()
ConvertBits(16)
SMDegrain(tr=2, thSAD=600, thSCD2=80, contrasharp=false, prefilter=6, truemotion=true, refinemotion=true, LFR=150, DCTflicker=true, pel=2, subpixel=2, chroma=true, plane=4)
ConvertBits(bits=10, dither=1)


in my humble opinion if i use "prefilter=6" which is defined in the SMDgrain script (script line 1018) i should not be forced to load something - i can be wrong of course.

[Fjord]

I've not actually tried it myself, but I think the BM3DCUDA release version at https://github.com/WolframRhodium/VapourSynth-BM3DCUDA: is for VapourSynth, not Avisynth. On that repository you need to go to Issues, "AVS+ Support" and download the "test8" version, which is the latest experimental port for Avisynth+ --- https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/files/8068864/BM3DCUDA_AVS-test8.zip

[kedautinh12]

I've not actually tried it myself, but I think the BM3DCUDA release version at https://github.com/WolframRhodium/VapourSynth-BM3DCUDA: is for VapourSynth, not Avisynth. On that repository you need to go to Issues, "AVS+ Support" and download the "test8" version, which is the latest experimental port for Avisynth+ --- https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/files/8068864/BM3DCUDA_AVS-test8.zip

My link share him had your link but he is blind to see that
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/issues/7#issuecomment-886173346
https://i.imgur.com/YPK5ulj.jpg

[kedautinh12]

### Dependencies:
### MVTools2
### ExTools
### LSFplus/SharpenersPack (for Contrasharp or LFR)
### ResizersPack (for Contrasharp
### or Str=0.1 to 1.0 ~ex_retinex()~ or show)
### GradePack (for Str=0.1 to 1.0 ~ex_retinex()~ or show)
### ScenesPack (for Str=0.1 to 1.0 ~ex_retinex()~ if '_SceneRange' frameprops exist)
### MasksPack (for show)
### RgTools (for Contrasharp
### or prefilter=0~3)
### DFTTest (for prefilter=4)
### KNLMeansCL (for prefilter=5)
### BM3D (for prefilter=6) # Buggy when used along ffvideosource() or cropping within DGSource()
### DGDecNV (for prefilter=7)
### TransformsPack (for prefilter=6 or prefilter=7)
### neo_tmedian (for mode="medianT")
### nnedi3 (for subpixel=4)
### SysInfo (for subpixel=4)
### Average (for mfilter + (Contrasharp or mode!=MDegrain) )

Check Dependencies above with this link to findout what external plugins need to be add
http://avisynth.nl/index.php/External_filters

[guest]

@kedautinh12

thank you for your links but i have already checked them and all pointing me out to the same source: https://github.com/WolframRhodium/VapourSynth-BM3DCUDA:
Script Error

'C:/VapourSynth-BM3DCUDA_RTC-R2.8/bm3dcuda_rtc.dll' cannot be used as a plugin for AviSynth.

i heave read dependencies from the SMDegrain script and i can't find any information about external plugins which needs to be added.

this is also mentioned in the script:

Wrapper for BM3D CUDA by WolframRhodium for AviSynth+
# Requires TransformsPack for OPP=true, RGB clips or processing chroma
#
# Disclaimer: ffvideosource() causes issues with BM3D for UV=1 or r>3
# BM3D() causes issues when gpuid >= 0 (CUDA) and you crop with DGSource()
# BM3D() causes issues when gpuid >= 0 (CUDA) and a high combination of radius + sigma unless you fine tune 'block_step' argument
#
# # Some of the following arguments aren't available on the BM3D AVS+ port but included here for reference (namely group_size, block_size, bm_step and ps_step)

so i added few additional avsi+ scripts into my StaxRip. Maybe it is to much but....

Import("E:\4k encode\Avisynth-Scripts-master\ResizersPack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\MIX mods\LSFplus.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\MIX mods\SharpenersPack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\GradePack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\ScenesPack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\MasksPack.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\MIX mods\Spresso.avsi")
Import("E:\4k encode\Avisynth-Scripts-master\SMDegrain v3.5.1d\SMDegrain v3.5.1d.avsi")
import("E:\4k encode\Avisynth-Scripts-master\ExTools.avsi")
import("E:\4k encode\Avisynth-Scripts-master\EX mods\GrainFactory3mod.avsi")
import("E:\4k encode\Avisynth-Scripts-master\EX mods\DeblockPack.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Main.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Models.avsi")
import("E:\4k encode\Avisynth-Scripts-master\TransformsPack - Transfers.avsi")
loadplugin("C:\Users\lukas\Downloads\VapourSynth-BM3DCUDA_RTC-R2.8\bm3dcuda_rtc.dll")

SetMemoryMax()
ConvertBits(16)
SMDegrain(tr=2, thSAD=600, thSCD2=80, contrasharp=false, prefilter=6, truemotion=true, refinemotion=true, LFR=150, DCTflicker=true, pel=2, subpixel=2, chroma=true, plane=4)
ConvertBits(bits=10, dither=1)


in my humble opinion if i use "prefilter=6" which is defined in the SMDgrain script (script line 1018) i should not be forced to load something - i can be wrong of course.

Hi madey83,

I can relate to your frustration here, and although I don't use Staxrip, this is what I need to use it in RipBot264 :-

LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\BM3DCUDA\BM3DCUDA_AVS.dll")
LoadPlugin("%AVISYNTHPLUGINS%\BM3DCUDA\BM3D_VAggregate_AVS.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\GRADE-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain.avs")
Import("%AVISYNTHPLUGINS%\TRANSFORM-PACK\Transforms Pack.avs")
Import("%AVISYNTHPLUGINS%\UTILS-R41\Utils-r41.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")

I use Avisynth "test 8" build of BM3D, by default it uses CUDA, but with a couple of simple changes to SMDegrain, you can have it use the CPU, instead (which I think is the better option)

Good luck.

[madey83]

My link share him had your link but he is blind to see that
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/issues/7#issuecomment-886173346
https://i.imgur.com/YPK5ulj.jpg
@kedautinh12

thank you, but i missed look on this and did not though that this is the avs+ file i was looking for.

[madey83]

thank you for direct link :)

[madey83]

I've not actually tried it myself, but I think the BM3DCUDA release version at https://github.com/WolframRhodium/VapourSynth-BM3DCUDA: is for VapourSynth, not Avisynth. On that repository you need to go to Issues, "AVS+ Support" and download the "test8" version, which is the latest experimental port for Avisynth+ --- https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/files/8068864/BM3DCUDA_AVS-test8.zip
thank you for direct link :)

[madey83]

Hi madey83,

I can relate to your frustration here, and although I don't use Staxrip, this is what I need to use it in RipBot264 :-

LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\BM3DCUDA\BM3DCUDA_AVS.dll")
LoadPlugin("%AVISYNTHPLUGINS%\BM3DCUDA\BM3D_VAggregate_AVS.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\GRADE-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain.avs")
Import("%AVISYNTHPLUGINS%\TRANSFORM-PACK\Transforms Pack.avs")
Import("%AVISYNTHPLUGINS%\UTILS-R41\Utils-r41.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")

I use Avisynth "test 8" build of BM3D, by default it uses CUDA, but with a couple of simple changes to SMDegrain, you can have it use the CPU, instead (which I think is the better option)

Good luck.
@TDS,

could you please share those changes for SMDgrain?

i would like to compare both CUDA and CPU results and see if it worth to use CPU over CUDA.

Thank you in advance.

[guest]

@TDS,

could you please share those changes for SMDegrain?

i would like to compare both CUDA and CPU results and see if it worth to use CPU over CUDA.

Thank you in advance.

Yes, if you go here, you'll see what I needed to change, in SMDegrain :-

https://forum.doom9.org/showthread.php?p=1969908#post1969908

And you'll have re-direct these,

LoadPlugin("%AVISYNTHPLUGINS%\BM3DCUDA\BM3DCUDA_AVS.dll")
LoadPlugin("%AVISYNTHPLUGINS%\BM3DCUDA\BM3D_VAggregate_AVS.dll")

mainly BM3DCUDA, to BM3DCPU.

Good luck.

[kedautinh12]

@TDS,

could you please share those changes for SMDgrain?

i would like to compare both CUDA and CPU results and see if it worth to use CPU over CUDA.

Thank you in advance.

Cause r9 5950x of him stronger than rtx 3050 in encode :D

[guest]

Cause r9 5950x of him stronger than rtx 3050 in encode :D

Hi ked, it actually had nothing to do with that, I found the quality of the encode to be quite bad, in comparison to the CPU variant.

But I have stopped using any of the BM3D filters.

[ChaosKing]

Not sure if it affects only the gpu version but the readme says
Lowering the value of "block_step" will be useful in reducing blocking artifacts at the cost of slower processing.
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA

[kedautinh12]

Hi ked, it actually had nothing to do with that, I found the quality of the encode to be quite bad, in comparison to the CPU variant.

But I have stopped using any of the BM3D filters.

Why??

[madey83]

Yes, if you go here, you'll see what I needed to change, in SMDegrain :-

https://forum.doom9.org/showthread.php?p=1969908#post1969908

And you'll have re-direct these,

LoadPlugin("%AVISYNTHPLUGINS%\BM3DCUDA\BM3DCUDA_AVS.dll")
LoadPlugin("%AVISYNTHPLUGINS%\BM3DCUDA\BM3D_VAggregate_AVS.dll")

mainly BM3DCUDA, to BM3DCPU.

Good luck.
Thank you :D

[guest]

Why??

Well, one encode I did using BM3D CUDA, a particular scene had a large lake in the background, and it was all "swirled up" (not the water), and looked terrible, encoding it with BM3D CPU it was good, so that was enough for me.

But I am using medium settings with pre-filter 2, pretty happy with the results.

[kedautinh12]

Well, one encode I did using BM3D CUDA, a particular scene had a large lake in the background, and it was all "swirled up" (not the water), and looked terrible, encoding it with BM3D CPU it was good, so that was enough for me.

But I am using medium settings with pre-filter 2, pretty happy with the results.

Try Lowering the value of "block_step"

[guest]

Try Lowering the value of "block_step"

So I would have to add this to the "call"...

video=SMDegrain(video,tr=4,thSAD=400,thSADC=200,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true,block_step = [8,8,8])
or
pre=ex_BM3D(video,sigma=5,radius=1,block_step = [8,8,8]) with or without the brackets ?

Are you sure this is an Avisynth option ???, 'cause I can't get it to work.

[kedautinh12]

Try
pre=ex_BM3D(video,sigma=5,radius=1,preset="normal")
video=SMDegrain(video,tr=4,thSAD=400,thSADC=200,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)

[LeXXuz]

What's better as a prefilter regarding quality? DFTtest or BM3D? I like the idea to run prefiltering via the GPU but not if quality is compromised.

I changed the preset for BM3D from "fast" to "normal" but can't go any higher as my GPU card is running out of memory with the higher settings and the GPU also slows down my CPU.

[guest]

Try
pre=ex_BM3D(video,sigma=5,radius=1,preset="normal")
video=SMDegrain(video,tr=4,thSAD=400,thSADC=200,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)

Hi ked, thanks yet again, that has worked (meaning no errors), yet to try an encode :)

[guest]

What's better as a prefilter regarding quality? DFTtest or BM3D? I like the idea to run prefiltering via the GPU but not if quality is compromised.

I changed the preset for BM3D from "fast" to "normal" but can't go any higher as my GPU card is running out of memory with the higher settings and the GPU also slows down my CPU.

Hi LeXXuz,

I did quite a few encodes once I got all these pre-filters setup, and I think it is up to the individual, to which one is better.

I am currently using pre-filter #2, which in "Minblur". and it's pretty good.

[kedautinh12]

What's better as a prefilter regarding quality? DFTtest or BM3D? I like the idea to run prefiltering via the GPU but not if quality is compromised.

I changed the preset for BM3D from "fast" to "normal" but can't go any higher as my GPU card is running out of memory with the higher settings and the GPU also slows down my CPU.

Cause preset="normal" will increase r to 3. You will need more ram, vram to do with this preset and your encode will slower than fast and low. You can change preset to "low" will suitable with your machine
https://github.com/Dogway/Avisynth-Scripts/blob/5011d2124fb1d15d5adbfa536d24512117934ac9/SMDegrain%20v3.5.1d/SMDegrain%20v3.5.1d.avsi#L1042

[guest]

Cause preset="normal" will increase r to 3. You will need more ram, vram to do with this preset and your encode will slower than fast and low. You can change preset to "low" will suitable with your machine
https://github.com/Dogway/Avisynth-Scripts/blob/5011d2124fb1d15d5adbfa536d24512117934ac9/SMDegrain%20v3.5.1d/SMDegrain%20v3.5.1d.avsi#L1042

So just "fmi" (for my information), is "fast" the default setting, if you haven't got this command in the script ??

[kedautinh12]

Your default setting if you don't add preset parameter is preset="low"

[guest]

Your default setting if you don't add preset parameter is preset="low"

Thanks...I just tried a "normal", and it's a lot slower....

[kedautinh12]

Thanks...I just tried a "normal", and it's a lot slower....

Try edit 3 from here to 2 or 1. Your encode speed will increase very much
https://github.com/Dogway/Avisynth-Scripts/blob/5011d2124fb1d15d5adbfa536d24512117934ac9/SMDegrain%20v3.5.1d/SMDegrain%20v3.5.1d.avsi#L1043

[guest]

Try edit 3 from here to 2 or 1. Your encode speed will increase very much
https://github.com/Dogway/Avisynth-Scripts/blob/5011d2124fb1d15d5adbfa536d24512117934ac9/SMDegrain%20v3.5.1d/SMDegrain%20v3.5.1d.avsi#L1043

Is that the "radius" setting ??

I'm running "radius=1", atm.

[kedautinh12]

Is that the "radius" setting ??

I'm running "radius=1", atm.

Value below "np" you can change 3 to 2 or 1 for more speed in encode

[guest]

Value below "np" you can change 3 to 2 or 1 for more speed in encode

So something like this ??

pre=ex_BM3D(video,sigma=5,radius=1, preset=normal, np=3)

[kedautinh12]

So something like this ??

pre=ex_BM3D(video,sigma=5,radius=1, preset=normal, np=3)

Lol
Value "3" in this line
https://github.com/Dogway/Avisynth-Scripts/blob/5011d2124fb1d15d5adbfa536d24512117934ac9/SMDegrain%20v3.5.1d/SMDegrain%20v3.5.1d.avsi#L1043

Change it to 2 or 1 for more speed in encode

[kedautinh12]

Try
pre=ex_BM3D(video,sigma=5,radius=1,preset="normal")
video=SMDegrain(video,tr=4,thSAD=400,thSADC=200,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=pre,str=1.2,refinemotion=true)

After edited, try again with this scripts

[guest]

Lol
Value "3" in this line
https://github.com/Dogway/Avisynth-Scripts/blob/5011d2124fb1d15d5adbfa536d24512117934ac9/SMDegrain%20v3.5.1d/SMDegrain%20v3.5.1d.avsi#L1043

Change it to 2 or 1 for more speed in encode

Sorry, I don't understand what you want me to do ?

# fast lc np high vn
r = Default( radius, Select(pr, 1, 2, 3, 4, 4 ) ) # temporal radius

EDIT:- I think I figured it out (by trial & error), I physically change the number under "np" to either a 2 or a 1. in SMDegrain.avs(i)

By changing that value, and checking speed with AVSMeter, it made a very noticeable difference.

Will it affect the "quality" ?

[kedautinh12]

Sorry, I don't understand what you want me to do ?

# fast lc np high vn
r = Default( radius, Select(pr, 1, 2, 3, 4, 4 ) ) # temporal radius

EDIT:- I think I figured it out (by trial & error), I physically change the number under "np" to either a 2 or a 1. in SMDegrain.avs(i)

By changing that value, and checking speed with AVSMeter, it made a very noticeable difference.

Will it affect the "quality" ?

You only care about block_step value than radius. Radius don't make very much different

[LeXXuz]

Cause preset="normal" will increase r to 3. You will need more ram, vram to do with this preset and your encode will slower than fast and low. You can change preset to "low" will suitable with your machine
https://github.com/Dogway/Avisynth-Scripts/blob/5011d2124fb1d15d5adbfa536d24512117934ac9/SMDegrain%20v3.5.1d/SMDegrain%20v3.5.1d.avsi#L1042

Yeah I already decreased radius down to 1 manually to use it only as spatial filter. However, my old GTX 1050 only has 4GB VRAM. Will do some testing with a RTX 3060 soon. The video engine is newer of course but I don't think it will be that much faster than the one implemented in GTX 1050 GPU. Will see.

[guest]

Why??

Hi ked, I thought I'd go back to comment on your question, again..

I have done another encode using BM3D CUDA, and again, the results are terrible, so I doubt that I will EVER use this filter again !!

BM3D CPU is good, however, but it's a little slower than the filter I generally use, which is pre-filter #2 Minblur.

I will try DFTtest (pre-filter #4) again, just for comparison.

So here's a 2 minute cut from the encode I did using BM3D CUDA, you will quickly see how bad it is :-

https://www.mediafire.com/file/ai7y4ild8fe6opn/bm3d_cuda_test.mkv/file

[kedautinh12]

You can report to author's bm3d
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/issues

[LeXXuz]

Hi ked, I thought I'd go back to comment on your question, again..

I have done another encode using BM3D CUDA, and again, the results are terrible, so I doubt that I will EVER use this filter again !!

BM3D CPU is good, however, but it's a little slower than the filter I generally use, which is pre-filter #2 Minblur.

I will try DFTtest (pre-filter #4) again, just for comparison.

So here's a 2 minute cut from the encode I did using BM3D CUDA, you will quickly see how bad it is :-

https://www.mediafire.com/file/ai7y4ild8fe6opn/bm3d_cuda_test.mkv/file

That's definitely a bug. I don't have that bug with my GTX 1050ti. Maybe it's CUDA drivers, maybe there's something wrong in BM3D that causes these faulty macroblocks with your GPU. What GPU do you have?

Driver's up to date? Is that card overclocked in any way?

[LeXXuz]

Right now I'm chewing my fingers on an old German movie from the 1950s which has been released on Blu-ray, remastered of course. Well, that's what is printed on the cover at least...

I usually do CRF18 10-bit encodes with x265. But if my encode gets bigger than the original, it's definitely time to do some cleaning.

With one instance of SMDegrain I couldn't get the filesize down enough. Even with tr=12 and thSAD=1000.

So, for a better understanding on how the SMDegrain script works I'd like to ask a few more questions regarding custom prefilters and cascading.

Prefiltering:
If SMDegrain is set to process all three planes, is the prefilter called just one time to process all three planes at once? Or for every plane seperately, meaning three times in total?

I'm still no good with Avisynth syntax, so maybe someone can explain to me this line from the BM3D wrapper function:
UV = Default(UV, rgb ? 3 : 1)

What does the question mark and the colon mean in that context?

If I add BM3D on my own as a prefilter, does it have to be set up to process all planes (if SMDegrain is set to process all planes) or still just luma?


Cascading:
It has been mentioned a few times now that calling SMDegrain twice in a row may be worth a try if speed is of no concern.

So for example this call of SMDegrain:

ORG=last
PREGPU=(ex_BM3D(sigma=32, preset="Low", Radius=1, CUDA=true, UV=1))
SMDegrain(tr=12, thSAD=800, contrasharp=false, LFR=width()/2, DCTFlicker=true, refinemotion=true, truemotion=false, pel=1, Str=3.0, prefilter=PREGPU, chroma=true, plane=4)
SMDegrain(tr=6, thSAD=400, contrasharp=true, CClip=ORG, limitS=false, LFR=width()/2, DCTFlicker=true, refinemotion=true, truemotion=false, pel=1, Str=3.0, prefilter=PREGPU, chroma=false, plane=0)

tr & SAD: Should the same values be used for both stages? Should the second stage have lower/higher values? If so, please briefly explain why.

Contrasharp: I think it's obvious that contrasharp should only be applied in the last stage, with optional reference to the unfiltered clip.

LFR & DCTFlicker: Should they only be used in the first, last or both stages?

prefiltering: Should the 2nd stage also use prefiltering or would that be overkill since the 2nd stage already gets a filtered version of the video from the 1st stage?

Chroma filtering: I read quite often in the forums that some people don't filter chroma as it is hardly stable enough to get decent results.
No idea if this was merely only true for old SD rather than HD content. Some of these posts are rather old.
So I was thinking not to overdo it on chroma and maybe only filter luma in the 2nd stage. Thoughts?

Globals: I did not use globals, because, if I'm not mistaken, it was mentioned that calculating fresh mv for the second stage would deliver better results.

[anton_foy]

Chroma filtering: I read quite often in the forums that some people don't filter chroma as it is hardly stable enough to get decent results.
No idea if this was merely only true for old SD rather than HD content. Some of these posts are rather old.
So I was thinking not to overdo it on chroma and maybe only filter luma in the 2nd stage. Thoughts?


For chroma I use CCD like this before smdegrain:
src=last
CCD(10,HD=true)
CombinePlanes(src, last, src, planes="YUV")

[guest]

That's definitely a bug. I don't have that bug with my GTX 1050ti. Maybe it's CUDA drivers, maybe there's something wrong in BM3D that causes these faulty macroblocks with your GPU. What GPU do you have?

Driver's up to date? Is that card overclocked in any way?

I have an RTX 3050, with almost the latest drivers, and is not overclocked.

But here's the thing, I use RipBot264, and it's Distributed Encoding feature uses multiple pc's, to dramatically decrease encoding times, BUT they will use whatever GPU is in them, so I can be using many different nVidia GPU's for a CUDA encode.

And they will have different driver version's due to the different model's of the GPU.

So I think my best option is not to use BM3D CUDA.

I know I could do a test on a single PC with the RTX 3050 in it, but there's no real point.

[tormento]

So I think my best option is not to use BM3D CUDA.
BM3DCUDA works perfectly fine here, alone and with other CUDA filters applied in the same script.

[Dogway]

@LeXXuz: The way you are cascading SMDegrain is for MDegrain cascading. I only do this for grain fest like 300 or 21 Grams, otherwise I use prefiltering cascading.
For LFR it's the same concept, initial LFR values can be somewhat higher than last LFR (wouldn't go over 300 or 400 for 1080p).
For chroma it depends how damaged it is, otherwise use @anton_foy's suggestion.

By the way, big update day today. Was holding back TransformsPack update for some time now. The big additions are Broadcast(), MatrixTranspose() refactor, RGB_to_XYZ() refactor, and probably RGB_to_ICtCp() (and reverse func). Also SVM() a sharpness metric score in SimilarityMetrics.
I ported ICtCp from this paper (https://professional.dolby.com/siteassets/pdfs/ictcp_dolbywhitepaper_v071.pdf). It passes the roundtrip test and double (triple, quadruple) checked the values and transformations, but I don't have any ICtCp encoded video to test. Unfortunately this is no IPTPQc2, even when adjusting for 2% crosstalk. There's a reshaping transfer that I might need to add to make it work, it's included in mpv which they claim to have succeeded in decoding IPTPQc2.

[LeXXuz]

For chroma I use CCD like this before smdegrain:
src=last
CCD(10,HD=true)
CombinePlanes(src, last, src, planes="YUV")

I can't find any binaries for AVS+. Anyone may help me out here?

[anton_foy]

I can't find any binaries for AVS+. Anyone may help me out here?

It is in Dogway's deblockpack.

[LeXXuz]

It is in Dogway's deblockpack.

Perfect. :thanks:

[DTL]

Even with tr=12 and thSAD=1000"

tr=12 is not highest valid value and reallt average with todays hardware. Max internal for MDegrainN is 128. So if MPEG output speed is not fine it is good to test at first how it depends on tr-setting with doubling at each step like 6-12-24-48 as example. Also pel=1 is about fast processing and not high quality. For quality it is better pel 2 or 4. Chroma planes need to be processed if they have any noise if you do colour MPEG encodings. Also it is good to try max settings of x26x executables like --placebo preset.
If you have unnaturally high noise level content you also need to raise mvtools common params or increasing of thSAD to 1000 will be useless. It is thSCD params described in commons section of mvtools2 docs.

thSCD1 (int, 400): threshold which decides whether a block has changed between the previous frame and the current one. When a block has changed, it means that motion estimation for it isn't relevant. It occurs for example at scene changes. So it is one of the thresholds used to tweak the scene changes detection engine. Raising it will lower the number of blocks detected as changed

To force process more or all blocks by MDegrainN I sometime set thSCD1 as high as 2000. But it may cause buggy blends at scene changes at real multi-scenes movie.

Here is my example of tr to MPEG and ripping speed dependance (FullHD 1080i documentaries and x264 encoding, YV12 format):
tr=15, 6 fps, MPEG speed mean 4534K
tr=30, 3 fps, 4208K (-8% to tr=15)
tr=60, 1.5 fps, 4159K (-1.1% to tr=30)
So for this ripping work (degrain output and MPEG encoding bitdepth of 8, input noise levels, other settings) I select tr in range about 12..25. Values over 30 makes very small decrease of output file size. With 10-bit MPEG it may be better benefit from higher tr but I currently do not use 10-bit MPEGs.

Also made a graphics to show how thSAD setting work with input SAD distribution because of noise - https://forum.doom9.org/showthread.php?p=1970981#post1970981

[Dogway]

Initial implementation of IPTPQc2. Needs to implement polynomial reshaping.

[Blankmedia]

Did you update? tv_in was added in last commit (https://github.com/Dogway/Avisynth-Scripts/blob/2d509f9c8dacc332c090fd3560fc1b2e331296f1/SMDegrain%20v3.5.0d/SMDegrain%20v3.5.0d.avsi#L871).

Anyway just updated SMDegrain now with the most recent changes.

Hi, with SMDegrain v3.5.1d.avsi and Flatmask I got an error here

UV == 3 ? CombinePlanes(last, clp, planes=rgb ? "RGB" : "YUV", pixel_type=PixelType(clp)).\
propCopy(clp,true,props="_ChromaLocation") : last
propSet("_ColorRange", tvo ? 1 : 0)

CombinePlanes: too many target planes(3)! Target video plane count is 1!

It works with SMDegrain v3.4.3d.avsi (if I remove "tv_in=!fs" in Flatmask ex_retinex call)

[Dogway]

Thanks. Yes follow this issue (https://github.com/Dogway/Avisynth-Scripts/issues/55). It was fixed last week but I'm adding a feature for ex_retinex. Will resume now since I just finished TransformsPack. The problem was mainly using CombinePlanes for single channel clips.

[Blankmedia]

Sorry about that, I'll look there before posting here next time.

[LeXXuz]

Even with tr=12 and thSAD=1000"

tr=12 is not highest valid value and reallt average with todays hardware. Max internal for MDegrainN is 128. So if MPEG output speed is not fine it is good to test at first how it depends on tr-setting with doubling at each step like 6-12-24-48 as example. Also pel=1 is about fast processing and not high quality. For quality it is better pel 2 or 4. Chroma planes need to be processed if they have any noise if you do colour MPEG encodings. Also it is good to try max settings of x26x executables like --placebo preset.
If you have unnaturally high noise level content you also need to raise mvtools common params or increasing of thSAD to 1000 will be useless. It is thSCD params described in commons section of mvtools2 docs.

thSCD1 (int, 400): threshold which decides whether a block has changed between the previous frame and the current one. When a block has changed, it means that motion estimation for it isn't relevant. It occurs for example at scene changes. So it is one of the thresholds used to tweak the scene changes detection engine. Raising it will lower the number of blocks detected as changed

To force process more or all blocks by MDegrainN I sometime set thSCD1 as high as 2000. But it may cause buggy blends at scene changes at real multi-scenes movie.

Here is my example of tr to MPEG and ripping speed dependance (FullHD 1080i documentaries and x264 encoding, YV12 format):
tr=15, 6 fps, MPEG speed mean 4534K
tr=30, 3 fps, 4208K (-8% to tr=15)
tr=60, 1.5 fps, 4159K (-1.1% to tr=30)
So for this ripping work (degrain output and MPEG encoding bitdepth of 8, input noise levels, other settings) I select tr in range about 12..25. Values over 30 makes very small decrease of output file size. With 10-bit MPEG it may be better benefit from higher tr but I currently do not use 10-bit MPEGs.

Also made a graphics to show how thSAD setting work with input SAD distribution because of noise - https://forum.doom9.org/showthread.php?p=1970981#post1970981

Thanks for your valued input DTL. :thanks: I finally start to understand a little better how the relation between these parameters influences output. And of course why my high thSAD and tr (I usuallally use about a third of these values) didn't do anything desired. Instead they just increased encoding time and decreased output quality.

[LeXXuz]

@LeXXuz: The way you are cascading SMDegrain is for MDegrain cascading. I only do this for grain fest like 300 or 21 Grams, otherwise I use prefiltering cascading.
For LFR it's the same concept, initial LFR values can be somewhat higher than last LFR (wouldn't go over 300 or 400 for 1080p).
For chroma it depends how damaged it is, otherwise use @anton_foy's suggestion.


Thanks again Dogway. :) I've adjusted the settings for LFR and a first test looks promising so far regarding detail retention in difficult areas.

[Dogway]

Finally updated SMDegrain. Adds RGB support to ex_luma_rebuild() and fixes the issue in ex_retinex(), also added option to disable highlight compression to ex_retinex(), so in essence working as a shadow enhancer, it's built inline so for lvl=1 it's faster than before.
Also for GradePack fixed saturation in ex_contrast() as it was a regression I didn't notice.

[DTL]

About high thSAD:

As I see in current version of SMDegrain:
thSCD1 = Default( thSCD1, round(0.35*thSAD+260)) # Typically between 330 and 400

So if user want to use thSAD of 1000 the default internal thSCD1 will be about 610 only. So if blocks SAD generally > 610 it will quickly overload the counter of too bad blocks per frame and frame will be marked as not-usable and any increasing of tr (and thSAD) will be useless (also the total MDegrain processing will be disabled if all ref frames will be marked as non-usable). So for large noise level content is it better to manually set thSCD1 param or increasing of thSAD above about 500 will quickly become useless and will not take more blocks/frames into processing.

It is good to add as a note to script users: if thSAD > 500 it is recommended to set thSCD1 manually about thSAD (not less). With a caution about possibly more errors of bad blocks blending at scene change. Or may be added into script as a condition.

So the formula thSCD1=0.35*thSAD+260 stop working good with thSAD about 500..600+. And user will silently got no-degrained result. May be it is a design feature of SMDegrain to save user from more distorted result but with more noise left ? If so it is good to be documented.

The function for marking total frame as non-usable is https://github.com/pinterf/mvtools/blob/d8bdff7e02c15a28dcc6e9ef2ebeaa9d16cc1f56/Sources/FakePlaneOfBlocks.cpp#L72

IsSceneChange(sad_t nTh1, int nTh2) const
{
int sum = 0;
for ( int i = 0; i < nBlkCount; i++ )
sum += ( blocks[i].GetSAD() > nTh1 ) ? 1 : 0;

return ( sum > nTh2 );
}


Where nBlkCount - total number of blocks per frame, Th1 and Th2 is scaled to SAD and normalized to blocks number thSCD1 and thSCD2 params. 'sum' is counter of 'too bad' blocks in the frame.

So 'scene change' detector may trigger frame-non-usable flag also with too noisy content (too high interframe SAD of blocks) and too low thSCD1 param. When frame is marked as non-usable - no any one block of frame is used for useful denoising of output. Whole frame is failed.

[Dogway]

The formula was modeled after scene change detection. For noisy sources anything higher than ~600 was not detecting any scene change at all and hence blending scenes. It's typically always above default of 400 so already improving on defaults. Maybe we should decouple it from pure SC detection.

[tormento]

The formula was modeled after scene change detection.
Do you plan to support newer DTL development in MVTools?

It could boost his development a lot, as SMDegrain and your tools are so widely used.

[DTL]

"Maybe we should decouple it from pure SC detection."

There is no other 'scene detect' in MAnalyse+MDegrain system. So the only high quality solutions for very noisy movies may be to cut scenes manually or some automatically using AVS plugins to separated clips and process each clip separately and concatenate back. It will save from different scenes frames blending inside falling in 2_x_tr group of neibour frames. With any high thSAD values and with completely removed SCD functionality with setting thSCD1 to some high value like 10000 and thSCD2 to 255.

[Dogway]

Do you plan to support newer DTL development in MVTools?

It could boost his development a lot, as SMDegrain and your tools are so widely used.

I think block size of 16 is not supported, which is the default for HD. Should look into other changes though. Current defaults are modeled after vanilla mvtools so I would need to account for the changes. In any case I still haven pendant of the final Zopti optimization run with synthetic grain. What I'm seeing more and more is playback film grain addition in codecs like JXL, AV1, HEVC, etc. So the trend is to encode clean and add synthetic grain on top on playback, although I'm suspicious of such real-time grain quality.

[DTL]

" block size of 16 is not supported"

It is supported as max current block size of DX12-ME HW accelerated mode and also in most of already working MDegrainN new modes. It simply not tested well because it produces lower quality and I currently use 8x8 only for HD. As for speed in hardware ME I not remember if using 16x16 makes significantly better speed. There planned some 'fastest' hacking mode of ME processing with supplying half sized image to ME engine (level 1 of MSuper clip instead of level 0) and search with block size 8x8 and interpolate MVs to double sized with 16x16 block size. But still not finished. It is also already should work with 'onCPU' MAnalyse with optPredictorType about 5 (output only interpolated prediction at level 0 and SAD recalculation).

[tormento]

It is supported as max current block size of DX12-ME HW accelerated mode
Perhaps it's better to have testing on both sw and hw MVTools versions, so that we can understand if it's a DirectX issue or a programming one.

[LeXXuz]

I'm playing around with prefilters at the moment. I can't decide between DGDenoise and BM3DCuda.

DGDenoise is very fast even on older graphic cards but I read quite a few times now it should be used mainly on anime and not films because it is very soft?

I don't know how much this is valid if it's running as a prefilter for MDegrain. Comments? :)

[anton_foy]

I'm playing around with prefilters at the moment. I can't decide between DGDenoise and BM3DCuda.

DGDenoise is very fast even on older graphic cards but I read quite a few times now it shoould be used mainly on anime and not films because it is very soft?

I don't know how much this is valid if it's running as a prefilter for MDegrain. Comments? :)

I have been using it on film/slog-footage with low settings (str=0.3) with good results but if its low light I compensate with levels to brighten up the lift and gamma a bit before degraining and then darken it back with levels immediately after otherwise it seems to miss alot of motion vectors in the shadows.

Edit: although I only used it on 4K resolution material, I would think it needs different settings for lower resolutions.

[LeXXuz]

I have been using it on film/slog-footage with low settings (str=0.3) with good results but if its low light I compensate with levels to brighten up the lift and gamma a bit before degraining and then darken it back with levels immediately after otherwise it seems to miss alot of motion vectors in the shadows.

Edit: although I only used it on 4K resolution material, I would think it needs different settings for lower resolutions.

That is interesting. Could you post an example on raising the levels maybe?

[anton_foy]

That is interesting. Could you post an example on raising the levels maybe?

This you can try:

Convertbits(16)

#Levels shadow compensate:
Levels(0, 1, 255*256, 36*256, 255*256, coring=false)

#Prefilter:
p=levels(12*256,1.0,100*256,0,255*256).temporalsoften(3,20,255,15,2).ex_DGDenoise(str=0.3)

#Denoise:
SMDegrain(prefilter=p)

#levels reset:
Levels(36*256,1.0,255*256,0,255*256)

I found that adding temporalsoften before DGDegrain stabilize the "wobblyness" that the heavy noise creates on lines and objects. Tweak it to your taste.

[anton_foy]

ex_reduceflicker(strength=1) is great but it gives me strange halos and sometimes like double exposed offset lightsources on 4K sources. Can post before after images if needed. It seems to only happen in bright areas.

[DTL]

I'm playing around with prefilters at the moment. I can't decide between DGDenoise and BM3DCuda.

DGDenoise is very fast even on older graphic cards but I read quite a few times now it should be used mainly on anime and not films because it is very soft?

I don't know how much this is valid if it's running as a prefilter for MDegrain. Comments? :)

Typically prefilter is not for MDegrain but for MAnalyse. So the output of MDegrain is not affected directly by the output of prefilter. The only direct way to modify MDegrainX/N output is to provide custom per-refining clip for pel > 1 (and for old method of fetching samples of pel-refined clip for pel > 1 and not integer sample coordinates). The idea of prefilter is to reduce MVs noise caused by luma/chroma noise and the way of MAnalyse detect the motion coordinates of the block. But it also may degrade the quality of motion search (small position errors will cause detail smoothing) and cause up to gross position errors (cause visible bad blocks blends of thSAD too high) because after removing noise with details the difference between blocks also become smaller and it is possible to run far from original block position if running full tree of hierarchical search with too much search radius (so with prefiltering the use of lots of hacks in MAnalyse like penalties and other 'truemotion' stuff may be more important, also may be not good to set too big search radius and even use not all levels).

In new approach of 2.7.45+ builds the noise from MVs is more or less removed after MAnalyse search and before MDegrain blending using the properties of long enough time-domain vectors. Like for static block the MV in each frame of the tr-scoped group of frames should be zero and with some real life motion the coordinate of MV in a sequence of frames can not change too fast.

I still not found significant benefit from prefilter while running hardware ME from GTX1060 and applying MVLPF in the new builds of mvtools as intermediate processing before ME and MDegrain blending to fix some noise from MVs. Currently the some implementation of MVLPF filtering is intergated into MDegrainN (of 2.7.45+ builds) and not available for direct tweaking by script writers. I really interesting why so useful and not very complex processing was still not implemented many years ago at the active development of mvtools. Or may be it is somehow working at MRecalculate or other parts of mvtools ? The only idea that first MDegrainX of X 1,2,3 runs too slow on old CPUs so not efficient time-domain filtering may be applied visibly profitable. Nowdays with MDegrainN and tr > 10 running at acceptable speed and ME-acceleration where available it become more usable and allow to use more complex transfer functions filters in time domain for motion of each block.

It really very science-loaded processing (may not have some single best for all implementation of linear or even non-linear filter) and may be need to be tweaked for per-movie or per-scene basis. So it planned to add some long-requested interface for script-accessible MVs format of datastream between MAnalyse and MDegrain so script-writers may make lots of testing with intermediate MVs data additional processing to get best results. As well as lots of work was put for pre-processing before MAnalyse in the past. Though any anti-noise processing of MVs is not image-processing task but DSP processing in time-domain and can not be performed fast with existing 2D processing filters and direct data access scripts in interperting mode may be much slower. So it mostly for finding some profitable filtering methods for future addition in the compiled executable form.

[LeXXuz]

Typically prefilter is not for MDegrain but for MAnalyse. So the output of MDegrain is not affected directly by the output of prefilter. The only direct way to modify MDegrainX/N output is to provide custom per-refining clip for pel > 1 (and for old method of fetching samples of pel-refined clip for pel > 1 and not integer sample coordinates). The idea of prefilter is to reduce MVs noise caused by luma/chroma noise and the way of MAnalyse detect the motion coordinates of the block. But it also may degrade the quality of motion search (small position errors will cause detail smoothing) and cause up to gross position errors (cause visible bad blocks blends of thSAD too high) because after removing noise with details the difference between blocks also become smaller and it is possible to run far from original block position if running full tree of hierarchical search with too much search radius (so with prefiltering the use of lots of hacks in MAnalyse like penalties and other 'truemotion' stuff may be more important, also may be not good to set too big search radius and even use not all levels).

In new approach of 2.7.45+ builds the noise from MVs is more or less removed after MAnalyse search and before MDegrain blending using the properties of long enough time-domain vectors. Like for static block the MV in each frame of the tr-scoped group of frames should be zero and with some real life motion the coordinate of MV in a sequence of frames can not change too fast.

I still not found significant benefit from prefilter while running hardware ME from GTX1060 and applying MVLPF in the new builds of mvtools as intermediate processing before ME and MDegrain blending to fix some noise from MVs. Currently the some implementation of MVLPF filtering is intergated into MDegrainN (of 2.7.45+ builds) and not available for direct tweaking by script writers. I really interesting why so useful and not very complex processing was still not implemented many years ago at the active development of mvtools. Or may be it is somehow working at MRecalculate or other parts of mvtools ? The only idea that first MDegrainX of X 1,2,3 runs too slow on old CPUs so not efficient time-domain filtering may be applied visibly profitable. Nowdays with MDegrainN and tr > 10 running at acceptable speed and ME-acceleration where available it become more usable and allow to use more complex transfer functions filters in time domain for motion of each block.

It really very science-loaded processing (may not have some single best for all implementation of linear or even non-linear filter) and may be need to be tweaked for per-movie or per-scene basis. So it planned to add some long-requested interface for script-accessible MVs format of datastream between MAnalyse and MDegrain so script-writers may make lots of testing with intermediate MVs data additional processing to get best results. As well as lots of work was put for pre-processing before MAnalyse in the past. Though any anti-noise processing of MVs is not image-processing task but DSP processing in time-domain and can not be performed fast with existing 2D processing filters and direct data access scripts in interperting mode may be much slower. So it mostly for finding some profitable filtering methods for future addition in the compiled executable form.

Thank you very much DTL for another detailed insight. :thanks:

This you can try:

Convertbits(16)

#Levels shadow compensate:
(0, 1, 255*256, 36*256, 255*256, coring=false)

#Prefilter:
p=levels(12*256,1.0,100*256,0,255*256).temporalsoften(3,20,255,15,2).ex_DGDenoise(str=0.3)

#Denoise:
SMDegrain(prefilter=p)

#levels reset:
Levels(36*256,1.0,255*256,0,255*256)

I found that adding temporalsoften before DGDegrain stabilize the "wobblyness" that the heavy noise creates on lines and objects. Tweak it to your taste.

Thanks anton_foy for sharing that script. That may prove useful for some material I have with lots of troublesome dark areas. :)

[DTL]

The sad truth may be that mvtools was not designed as denoise tool and the degrain part is only small part. Its main task was the frame interpolation for motion smoothing and it cause the main hacks and tweaks in MAnalyse for better motion interpolation (less visible bugs) and not for best possible degraining for video compression. So mvtools old versions do not have built-in prefiltering and interfiltering of data for best possible denoising and users need to test different handmade approaches around the given filters set in mvtools project.

*After again reading mvtools2 doc* : Do the MStoreVect and MRestoreVect functions work for converting MVs internal format to 'standard clip' and back so script writer can get access to MVs data and make intermediate filtering of MVs too (between MAnalyse and MDegrain) and continue to pass the changed data to next mvtools filters ? So may be this functionality already exist (but not initially designed for this process) and no need to be developed again ? It is very few documented and do not document the mapping of each block MV to sample data of the 'normal clip' but it may be checked. A question to Dogway: Was it tested as a way to access MAnalyse MVs data (of both dx, dy data for inter-filtering and so frequently asked SAD for script-based automation like auto-thSAD assignment) ? Using MStoreVect and 'pixel-accessing' functions from a script (like Eval ?) ?

Also about MFlow: documentation says it can be used for pixel-based and not block-based compensation and for denoising too (without block artefacts and may be not required overlap mode directly). So in theory it can create less detail smoothing at the small and complex moving images like facial animation where even mid-sized blocks like 8x8 is still too large (and typical 16x16 and 32x32 are awfully large) and downsampling to 4x4 for the total clip is too slow in processing: Was it used in the known degrain scripts already ? Or it was too slow so the old single-filter MDegrain block-based runs faster ? Are there plans to look for MFlow-based degrain in Dogway scripts to test it quality compared to MDegrain-block-based execution engine ? Unfortunately it looks not currently support 'wrapped' multi-tr data passing from MAnalyse to degraining so need long hand-written scripts for passing +-forward/backward compensated groups of frames to blending engine like old MDegrainX for every tr-value (or may be it is possible to create a function in script ?).

The simulation of simplest MDegrain1 with MFlow in documentation is already awfully large:

super = MSuper()
backward_vectors = MAnalyse(super, isb = true)
forward_vectors = MAnalyse(super, isb = false)
forward_compensation = MFlow(super, forward_vectors, thSCD1=500) # or use MCompensate
backward_compensation = MFlow(super, backward_vectors, thSCD1=500)
# create interleaved 3 frames sequences
interleave(forward_compensation, last, backward_compensation)

DeGrainMedian() # place your preferred temporal (spatial-temporal) denoiser here

selectevery(3,1) # return filtered central (not-compensated) frames only

And still do not have complete example with exact blending engine. Also not passes SAD to blending engine to protect from too badly compensated areas blends.
Or it is a task for some future MDegrainNFlow() function or a option to MDegrainN like (UseFlowInterpolation=0/1).


Also as addition to new 2.7.45+ builds with supporting hardware ME acceleration and different block sizes: Currently Microsoft DX12-ME API support only 8x8 and 16x16 block size. But as I see from mvtools2 doc there are existing special functions for 'scale' of MVs between different block sizes (for faster processing). So if blocksize of 32x32 and higher is required the downsampled clip can be feed to MAnalyse with blocksize 16x16 and post-processed with MScaleVect to 32x32 block size. It same idea as optSearchOption=6 for the internals of MAnalyse but looks not required and may be removed if it already designed as developed function of mvtools. It may be important in the era of HD/UHD/UHD2 mix formats or for 8K that is not currently directly covered by old ME-accelerators of mid-201x years. So blocksize of 8x8 may be processed for 4K downsampled clip from 8K source and after MScaleVect to 16x16 being supplied to MDegrain of 8K processing full size input clip. The reserve of precision default down to qpel at 8x8 and 16x16 block sizes from ME-accelerators at full speed is very enough for 4K and 8K processing - even after scaling to double block size the precision is only lowered to half pel.

[anton_foy]

The sad truth may be that mvtools was not designed as denoise tool and the degrain part is only small part. Its main task was the frame interpolation for motion smoothing and it cause the main hacks and tweaks in MAnalyse for better motion interpolation (less visible bugs) and not for best possible degraining for video compression. So mvtools old versions do not have built-in prefiltering and interfiltering of data for best possible denoising and users need to test different handmade approaches around the given filters set in mvtools project.

*After again reading mvtools2 doc* : Do the MStoreVect and MRestoreVect functions work for converting MVs internal format to 'standard clip' and back so script writer can get access to MVs data and make intermediate filtering of MVs too (between MAnalyse and MDegrain) and continue to pass the changed data to next mvtools filters ? So may be this functionality already exist (but not initially designed for this process) and no need to be developed again ? It is very few documented and do not document the mapping of each block MV to sample data of the 'normal clip' but it may be checked. A question to Dogway: Was it tested as a way to access MAnalyse MVs data (of both dx, dy data for inter-filtering and so frequently asked SAD for script-based automation like auto-thSAD assignment) ? Using MStoreVect and 'pixel-accessing' functions from a script (like Eval ?) ?

Also about MFlow: documentation says it can be used for pixel-based and not block-based compensation and for denoising too (without block artefacts and may be not required overlap mode directly). So in theory it can create less detail smoothing at the small and complex moving images like facial animation where even mid-sized blocks like 8x8 is still too large (and typical 16x16 and 32x32 are awfully large) and downsampling to 4x4 for the total clip is too slow in processing: Was it used in the known degrain scripts already ? Or it was too slow so the old single-filter MDegrain block-based runs faster ? Are there plans to look for MFlow-based degrain in Dogway scripts to test it quality compared to MDegrain-block-based execution engine ? Unfortunately it looks not currently support 'wrapped' multi-tr data passing from MAnalyse to degraining so need long hand-written scripts for passing +-forward/backward compensated groups of frames to blending engine like old MDegrainX for every tr-value (or may be it is possible to create a function in script ?).

The simulation of simplest MDegrain1 with MFlow in documentation is already awfully large:

super = MSuper()
backward_vectors = MAnalyse(super, isb = true)
forward_vectors = MAnalyse(super, isb = false)
forward_compensation = MFlow(super, forward_vectors, thSCD1=500) # or use MCompensate
backward_compensation = MFlow(super, backward_vectors, thSCD1=500)
# create interleaved 3 frames sequences
interleave(forward_compensation, last, backward_compensation)

DeGrainMedian() # place your preferred temporal (spatial-temporal) denoiser here

selectevery(3,1) # return filtered central (not-compensated) frames only

And still do not have complete example with exact blending engine. Also not passes SAD to blending engine to protect from too badly compensated areas blends.
Or it is a task for some future MDegrainNFlow() function or a option to MDegrainN like (UseFlowInterpolation=0/1).


Also as addition to new 2.7.45+ builds with supporting hardware ME acceleration and different block sizes: Currently Microsoft DX12-ME API support only 8x8 and 16x16 block size. But as I see from mvtools2 doc there are existing special functions for 'scale' of MVs between different block sizes (for faster processing). So if blocksize of 32x32 and higher is required the downsampled clip can be feed to MAnalyse with blocksize 16x16 and post-processed with MScaleVect to 32x32 block size. It same idea as optSearchOption=6 for the internals of MAnalyse but looks not required and may be removed if it already designed as developed function of mvtools. It may be important in the era of HD/UHD/UHD2 mix formats or for 8K that is not currently directly covered by old ME-accelerators of mid-201x years. So blocksize of 8x8 may be processed for 4K downsampled clip from 8K source and after MScaleVect to 16x16 being supplied to MDegrain of 8K processing full size input clip. The reserve of precision default down to qpel at 8x8 and 16x16 block sizes from ME-accelerators at full speed is very enough for 4K and 8K processing - even after scaling to double block size the precision is only lowered to half pel.

Interesting. But I see you use degrainmedian/"use your favourite spatial/temporal denoiser" there, is this like motion compensation without mdegrain?

[DTL]

" I see you use degrainmedian/"use your favourite spatial/temporal denoiser""

It is example copied from mvtools2 doc directly with comments. Now I see the DeGrainMedian() is possibly some real external denoiser plugin/script.

" is this like motion compensation without mdegrain?"

In this example of simulating MDegrain1 processing the motion compensation is performed by MFlow. But for final blending some external engine is used (may be with protection from too bad blending based on absolute difference of samples values ?).
Or with even number of frames and/or with equal weigthing may be AVS internal blenders may be used like Overlay() or Layer() with 1/3 weight mask for each of 3 clips (current, -1 frame compensated, +1 frame compensated).

The MDegrainX/N is compiled executable for several operations:
1. Motion compensation of blocks based on MAnalyse data
2. Blending of compensated blocks in the tr-scoped pool of surrounding frames using some weighting based on SAD values relative to thSAD params (also scene change detection). Simple or overlapped mode blending based on service data from MAnalsye.

[LeXXuz]

I'm looking for a preset between 'Low' and 'Normal' for ex_BM3D in SMDegrain.

I'm asking because the low profile still leaves a lot of headroom for my GPUs on 1080p sources. The 'Normal' profile however drops performance significantly and makes the GPU the bottleneck. Both with radius=1, of course.

I just don't want to tweak numbers here as long as I don't understand what they are really doing and maybe risk to worsen quality. :o

I also don't quite understand why the RTX 30 GPU performs just slightly better than an old GTX 10 GPU, although it has several times the CUDA processing power according to Geekbench.

[DTL]

About accessing MVs from MAnalyse via MStoreVect:

Made a small test:

LoadPlugin("mvtools2.dll")

BlankClip(pixel_type="YV12")

super=MSuper()
mvs=MAnalyse(super)

MStoreVect(mvs, "RGB24")

FlipVertical()

It shows some vertical lines for 0 frame (the VECTOR structure is filled with 'invalid' values that is 0,0 for dx,dy and max/invalidSAD like 65535) because the MVs for the 0-1 frame are invalid and not calculated. And 1 and later frames are black (the MVs for static black frame are dx=dy=SAD=0) after header data.

Vertical Flip is looks to reverse lines scan order for RGB imaging so to start from top left corner. It have a small header (may be 256 bytes total of AnalysisData structure) and a sequence of VECTOR structures for all blocks in sequential scan order (from top to bottom and from left to right I hope). VECTOR structure of MVs data for each block is 12bytes of dx, dy and SAD as 32bit integers (looks like all signed). The mapping to RGB24 pixel data is not very easy to read because the starting offset to the VECTOR structures may be not integer part of RGB24 pixel array of 3 bytes per addressable pixel. So the function to get MVs data for some x,y of block or blocknum=y*blocks_per_row+x is not very simple. Also the width and height of the output frame by MStoreVect is in some form calculated from blocks X,Y count to form some not very narrow frame I think to be good to view as rectangle and not thin line.

" why the RTX 30 GPU performs just slightly better than an old GTX 10 GPU,"

May be it is limited by memory transfter speed or some other processing not offloaded to accelerator.

[LeXXuz]

" why the RTX 30 GPU performs just slightly better than an old GTX 10 GPU,"

May be it is limited by memory transfter speed or some other processing not offloaded to accelerator.

I don't think it's memory related. Bandwith is much higher.

RTX 3060ti: 8GB GDDR6 / 256bit / 448GB/s
GTX 1050ti: 4GB GDDR5 / 128bit / 112GB/s

Maybe code is not optimized for Ampere architecture. Something probably only Wolfram knows.

[DTL]

Memory transfer between accelerator and host CPU internals. It may be very great bottleneck for attempt to 'offload' processing of some small chunks of data between host CPU executed program and some external accelerator support via PCI-E bus (also the already awful memory subsystem of current PC architecture chips of multi level caches and so on). So any real data transfer between host and accelerator it is a very long task nowdays. Like scheduling of special host memory buffer and putting command to a queue of some dispatcher for DMA transfer from host RAM to accelerator when its time come to the scheduled task. So speed optimization of 'offload' processing of small sequential pieces of work here and there at host CPU and accelerator is hardly possible. Only offloading large pieces of work (using upload to accelerator) and waiting to complete and getting result back from some host RAM area after download back from accelerator. Best case is full frame uploading or a set of frames and download ready result back to AVS caching system.

You may look at the performance counters of accelerator in Win10 task manager - its CUDA, Compute, Copy graphs. May be accelerator CUDA simply sit and wait for data transfer to/from host to complete. So RTX 3060 will simply show more free CUDA resources available. Also the upload/download tasks to/from accelerator is so important so it have already separate performance counter Copy (or even Copy_0, Copy_1 and other).

"/ 256bit / 448GB/s"

It is peak onboard RAM to chip of accelerator transfer speed. The real task data transfer between register file or L1D cache of CPU and internals of accelerator may be 1000x times slower and more. The scheduling overhead quickly become the main limiting factor if trying to operate small enough chunks of data. The typical random RAM byte fetching performance of current PCs with total latency of about 100ns is still only about 10 MB/s.

[LeXXuz]

You may look at the performance counters of accelerator in Win10 task manager - its CUDA, Compute, Copy graphs. May be accelerator CUDA simply sit and wait for data transfer to/from host to complete. So RTX 3060 will simply show more free CUDA resources available. Also the upload/download tasks to/from accelerator is so important so it have already separate performance counter Copy (or even Copy_0, Copy_1 and other).

For the GTX 1050ti Windows 10 task manager is showing usage under the 'Cuda' section of the GPU.

On the other system with the RTX 3060ti there is no Cuda section in Windows 10 task manager. The usage is shown in 3d section. Odd.

Both have latest NV drivers.

Just checked another system with Windows 11 and a GT 710. There is no Cuda section either and computing usage is shown in the 3d section as well.

The usage under any of the Copy sections is so minimal on all systems that I have to full screen Windows task manager to even barely see some tiny peaks.

[DTL]

"RTX 3060ti there is no Cuda section in Windows 10 task manager. The usage is shown in 3d section. Odd."

May you not add required compute-related performance counters views to task manager 'GPU' window ? Or the CUDA is not available in the drop-down list of available performance counters ? May be it is named as some other Compute (may be added to Compute_0 or Compute_1) in more new accelerators. The DX12 compute shaders execution is displayed in Compute_ performance counters for GTX1060.

[LeXXuz]

It's not available under performance counters. When running BM3DCUDA the GPU load is shown by the 3d performance counter.

There is close to none usage shown on any of the other counters.

https://abload.de/thumb/gpu_taskman_1050tirnkdf.png (https://abload.de/image.php?img=gpu_taskman_1050tirnkdf.png)
https://abload.de/thumb/gpu_taskman_3060ti8pjdw.png (https://abload.de/image.php?img=gpu_taskman_3060ti8pjdw.png)

[DTL]

Oh - it is strange. No Compute, no cuda. It looks they collapsed all computing and other 3D texturing to single 3D. But 3D shows 95% load.

[LeXXuz]

Dogway would it be possible to get DGSharpen() as another sharpener for the Contrasharp routine into SMDegrain?

It's very fast and quality wise somewhere between Contrasharp() and LSFplus().

[Dogway]

You can simply use it after SMDegrain. The reason Contrasharp and LSFplus are integrated is because they use CClip and other complex correlated settings, but DGSharpen has just one argument.

By the way, I wanted to share a sneak peak of coming CMF (Color Matching Function) for TransformsPack, will update soon when I fix an issue on CAT().

https://i.imgur.com/1WTpzrOl.png (https://i.imgur.com/1WTpzrO.png)

[LeXXuz]

The reason Contrasharp and LSFplus are integrated is because they use CClip and other complex correlated settings


That's why I asked, because I thought the result may be a little different when calling a sharpener after SMD script. Just trying to gain a little speed but don't want to lose quality of course. :)

[LeXXuz]

I've noticed a deviation in colours when comparing the source and filtered video in MeGUI's Avisynth preview window. See screenshots.

I was wondering if this is due the massiv picture processing with SMDegrain or maybe a bug in MeGUI?

https://abload.de/thumb/2022-07-171w6jrx.png (https://abload.de/image.php?img=2022-07-171w6jrx.png)https://abload.de/thumb/2022-07-176lkvb.png (https://abload.de/image.php?img=2022-07-176lkvb.png)

(It's 4k content with BT2020 SMTPE2084 static HDR. But I noticed this with BT709 SDR content too.)

Anyone else noticed slight colour/luma differences?

[Dogway]

LeXXuz, did you feed tonemapped as prefilter? It's suggested on the header of SMDegrain, something like DGHDRtoSDR(mode="pq",white=100) will do.
SMDegrain shouldn't do any color manipulation.

[LeXXuz]

LeXXuz, did you feed tonemapped as prefilter? It's suggested on the header of SMDegrain, something like DGHDRtoSDR(mode="pq",white=100) will do.

... if you compare those two screenshots closely you will already notice a slight deviation in colour. Which becomes clearly visible when playing the encoded video on an HDR capable screen. That only occurs when I use SMDegrain on that input.

I've used these settings for some subtle filtering:

SMDegrain(tr=6, thSAD=250, thSCD1=250, contrasharp=100, limitS=true, LFR=round(width()/6), DCTFlicker=false, refinemotion=true, truemotion=false, pel=2, Str=2.0, prefilter=7, chroma=true, plane=4)
Prefetch(32,32)
Return(Last)

EDIT: removed some wrong statements

[Dogway]

You don't tonemap the source but the prefilter clip to compute MV.
MAnalyse is going to have a hard time finding good vectors on such a compressed space.

You can do this:

tm = DGHDRtoSDR(mode="pq",white=100)
pr = tm.ex_DGDenoise(str=0.10,LFR=width()/2.,UV=3).ex_boxblur(0.5, mode="weighted", UV=3)

SMDegrain(tr=6, thSAD=250, thSCD1=250, contrasharp=100, limitS=true, LFR=round(width()/6.), DCTFlicker=false, refinemotion=true, truemotion=false, pel=2, Str=2.0, prefilter=pr, chroma=true, plane=4)


There might be a point of failure though, ex_DGDenoise() requires YV12 input, so if yours is 422 or 444 it's going to read primaries from frame properties, depending on your source loader it might be not retrieving this. I use latest DGSource.

[LeXXuz]

You don't tonemap the source but the prefilter clip to compute MV.
MAnalyse is going to have a hard time finding good vectors on such a compressed space.


Now I understand what you mean. :o I use latest DG tools as well. Thanks, I will add this to my script when processing HDR content. But are you sure about white=100? That is almost pitch black. :)

Anyway, I have to apologize to you. It seems neo_f3kdb() is the root of evil here and not SMDegrain. I totall forgot I usually add this later as the final filter to my scripts. :o

Was quite happy with its results and speed but I guess it's time to look for another debanding filter.

EDIT:

There might be a point of failure though, ex_DGDenoise() requires YV12 input, so if yours is 422 or 444 it's going to read primaries from frame properties, depending on your source loader it might be not retrieving this. I use latest DGSource.

Well I chose DGDenoise() as it's an animation movie. Would it be beneficial to use BM3d instead?

[Boulder]

Do you actually need debanding for 10bit sources?

[LeXXuz]

Do you actually need debanding for 10bit sources?

I came across quite a few movies with banding even in 10bit.

Technically it shouldn't be necessary, you're right. But I like to have a debanding filter running for those scenes that are poorly mastered.

Maybe I overexaggerate, but I absolutely hate banding. Especially in scenes like underwater and stuff. Completely ruins the movie experience for me. :(

[Dogway]

Well I chose DGDegrain() as it's an animation movie. Would it be beneficial to use BM3d instead?

Both DGDenoise and KNLMeansCL ar nlmeans based so they are fine for anime. Although your source looked clean from the screenshot.
For debanding you can try my mod GradFun3plus, it's on the fast side with default mode.

[Boulder]

But are you sure about white=100? That is almost pitch black. :)

That's definitely a small mistake there. The default is 1000 which should be a good value to use.


Anyway, I have to apologize to you. It seems neo_f3kdb() is the root of evil here and not SMDegrain. I totall forgot I usually add this later as the final filter to my scripts. :o
I noticed some strange happenings with neo_f3kdb with HDR encodes a long time ago (https://forum.doom9.org/showthread.php?p=1912378#post1912378), but I've never seen any changes in color in SDR or HDR. Is it reproducable by some bare minimum script? To me it looks more like an issue with the colormatrix.

[Dogway]

That's definitely a small mistake there. The default is 1000 which should be a good value to use.


I don't know, I can go as low as 48 and still shows fine. Check here (https://forum.doom9.org/showthread.php?p=1941217#post1941217).
Anyway, it's a prefilter so it doesn't need to be perfect, I guess it depends on source master level, simply use the value that saturates the bit range.

[Boulder]

I don't know, I can go as low as 48 and still shows fine. Check here (https://forum.doom9.org/showthread.php?p=1941217#post1941217).
Anyway, it's a prefilter so it doesn't need to be perfect, I guess it depends on source master level, simply use the value that saturates the bit range.

That's odd. The range is 1-2000 I think, and a regular rather bright movie like Green Book was pitch black with 100..

EDIT: Oh, a pointer regarding GradFun3plus, I think the default threshold for PQ sources should be higher. The default value is a bit too low, I'd go maybe for 0.75 or something like that.

[LeXXuz]

I noticed some strange happenings with neo_f3kdb with HDR encodes a long time ago (https://forum.doom9.org/showthread.php?p=1912378#post1912378), but I've never seen any changes in color in SDR or HDR. Is it reproducable by some bare minimum script? To me it looks more like an issue with the colormatrix.

I was still using neo_f3kdb_r6 version. Tried out _r7 and no problems with colour deviations so far. :)

But if that doesn't work, I'll try out Dogways mod of Gradfun.

[guest]

Just use SMDegrain(prefilter=6, gpuid=-1). SMDegrain will choose BM3DCPU is prefilter

Hi ked,

I have a very belated question about this gpuid "switch" in SMDegrain..

It has been bought to my attention that with the changes Dogway did to this function a few builds ago, that if it's left to default, any SMDegrain filter will use the GPU for filtering / pre-filtering.

Would that be the case ???

Do I need to change it to gpuid=-1 for CPU instead, for my scripts ??

Cheers

[kedautinh12]

Hi ked,

I have a very belated question about this gpuid "switch" in SMDegrain..

It has been bought to my attention that with the changes Dogway did to this function a few builds ago, that if it's left to default, any SMDegrain filter will use the GPU for filtering / pre-filtering.

Would that be the case ???

Do I need to change it to gpuid=-1 for CPU instead, for my scripts ??

Cheers

You need use gpuid=-1 for CPU. If not, Smdegrain will choose GPU is default

[guest]

You need use gpuid=-1 for CPU. If not, Smdegrain will choose GPU is default

Thankyou for that, I will need to change all my script's then :(

And another question, with KNLMeansCL as a pre-filter, how do you change that to use the CPU, in SMDegrain....it looks like it's written a little differently to BM3D "instruction's".

Cheers

[kedautinh12]

Thankyou for that, I will need to change all my script's then :(

And another question, with KNLMeansCL as a pre-filter, how do you change that to use the CPU, in SMDegrain....it looks like it's written a little differently to BM3D "instruction's".

Cheers

Just use SMDegrain(prefilter=5, gpuid=-1)

[guest]

Just use SMDegrain(prefilter=5, gpuid=-1)
:thanks:

[madey83]

Now I understand what you mean. :o I use latest DG tools as well. Thanks, I will add this to my script when processing HDR content. But are you sure about white=100? That is almost pitch black. :)

Anyway, I have to apologize to you. It seems neo_f3kdb() is the root of evil here and not SMDegrain. I totall forgot I usually add this later as the final filter to my scripts. :o

Was quite happy with its results and speed but I guess it's time to look for another debanding filter.

EDIT:



Well I chose DGDenoise() as it's an animation movie. Would it be beneficial to use BM3d instead?


HI LeXXuz,

i use a lot neo_f3kdb() and you mentioned that this is the root cause for color "changing". Do you know what would be the best alternative for neo_f3kdb?

this is my basic command for this filter:
neo_f3kdb(preset="veryhigh/nograin", dynamic_grain=false, output_depth=10)

Could you share yours for alternative?

[LeXXuz]

HI LeXXuz,

i use a lot neo_f3kdb() and you mentioned that this is the root cause for color "changing". Do you know what would be the best alternative for neo_f3kdb?

this is my basic command for this filter:
neo_f3kdb(preset="veryhigh/nograin", dynamic_grain=false, output_depth=10)

Could you share yours for alternative?

I was still using r6 version of neo_f3kdb().

With version r7 I could not reproduce this problem so far:
https://github.com/HomeOfAviSynthPlusEvolution/neo_f3kdb/releases/tag/r7

[LeXXuz]

Dogway I noticed some faint distortions in my encodes, barely noticeable.
So I played around with the preview mode a little and saw a lot of erroneous frames of the prefiltered clip. See pics below:

https://abload.de/thumb/2022-07-291tjjv3.png (https://abload.de/image.php?img=2022-07-291tjjv3.png)https://abload.de/thumb/2022-07-292b4kjm.png (https://abload.de/image.php?img=2022-07-292b4kjm.png)https://abload.de/thumb/2022-07-2931lknh.png (https://abload.de/image.php?img=2022-07-2931lknh.png)https://abload.de/thumb/2022-07-29452j8t.png (https://abload.de/image.php?img=2022-07-29452j8t.png)https://abload.de/thumb/2022-07-2958qk14.png (https://abload.de/image.php?img=2022-07-2958qk14.png)https://abload.de/thumb/2022-07-290uk5b.png (https://abload.de/image.php?img=2022-07-290uk5b.png)

EDIT: I turned off DGDenoise and the errors are gone. Tried with no prefilter (-1) and BM3DCUDA (6) with no errors.

Btw. about "speed, memory and quality" shown on the right with different colours. Are they displayed anywhere? All I see is the gamma curve in the preview.

[Dogway]

LeXXuz, I cannot reproduce your issue. I used your settings over a 2.40 ratio 1080p source at 16-bit.

What did you change between this (https://abload.de/img/2022-07-29452j8t.png)and this (https://abload.de/img/2022-07-2958qk14.png)? Result looks fine but no settings changed?

The legend is when you define show="speed" in string format so you can have some hint where to tweak for optimization.

[LeXXuz]

What did you change between this (https://abload.de/img/2022-07-29452j8t.png)and this (https://abload.de/img/2022-07-2958qk14.png)? Result looks fine but no settings changed?


Weird. I changed nothing, just stepped a frame forward in MeGUIs preview window and took a new screenshot. Some frames look fine, others have these strange colour distortions.

I did a few encodes with DGDenoise() just alone to see if these errors occur, but no. Have latest nVidia Studio drivers installed for RTX 2060. I will check this very same script on another machine with a RTX 3060TI once that's free as it's currently occupied by running a longer encoding job.

EDIT: That is actually not true. It does also happen with DGDenoise() alone.

[Dogway]

Just upload a small sample and your script so I can test here.

Is the source interlaced? (a possible point of failure)

[LeXXuz]

Is the source interlaced? (a possible point of failure)

No it's 1920x800 @23p.

[madey83]

Dogway I noticed some faint distortions in my encodes, barely noticeable.
So I played around with the preview mode a little and saw a lot of erroneous frames of the prefiltered clip. See pics below:

https://abload.de/thumb/2022-07-291tjjv3.png (https://abload.de/image.php?img=2022-07-291tjjv3.png)https://abload.de/thumb/2022-07-292b4kjm.png (https://abload.de/image.php?img=2022-07-292b4kjm.png)https://abload.de/thumb/2022-07-2931lknh.png (https://abload.de/image.php?img=2022-07-2931lknh.png)https://abload.de/thumb/2022-07-29452j8t.png (https://abload.de/image.php?img=2022-07-29452j8t.png)https://abload.de/thumb/2022-07-2958qk14.png (https://abload.de/image.php?img=2022-07-2958qk14.png)https://abload.de/thumb/2022-07-290uk5b.png (https://abload.de/image.php?img=2022-07-290uk5b.png)

EDIT: I turned off DGDenoise and the errors are gone. Tried with no prefilter (-1) and BM3DCUDA (6) with no errors.

Btw. about "speed, memory and quality" shown on the right with different colours. Are they displayed anywhere? All I see is the gamma curve in the preview.

hi LeXXuz,

could you please tell me what is the application used by you to show SMDegrain results? Is this application shows in real time results of denoise without encode?

[LeXXuz]

hi LeXXuz,

could you please tell me what is the application used by you to show SMDegrain results? Is this application shows in real time results of denoise without encode?

No. That is just the Avisynth preview window of MeGUI:
https://forum.doom9.org/showthread.php?t=112496

[StainlessS]

could you please tell me what is the application used by you to show SMDegrain results? Is this application shows in real time results of denoise without encode?
I'm not sure what you are after, but maybe WaveForm_FilmStrip() will fit the bill.

https://i.postimg.cc/nV44Lx6B/Waveform-Filmstrip-00.jpg (https://postimg.cc/4n378D4x)

Here in WaveForm thread:- https://forum.doom9.org/showthread.php?p=1965005#post1965005

Here client script with SHOWAUDIO=False [where it dont need Waveform plugin]


# Import(".\Waveform_FilmStrip.avsi")
#AviSource("D:\G.avi")
Colorbars.Trim(0,-100)

WINDOW = 3 # Frames Wide = 2 * WINDOW + 1
HEIGHT = 0.33 # Audio graphs height, 0.333 = 1/3 of result filmstrip image height.
UNDER = false # True, then audio graphs stacked under video, else overlay over video.
ZOOM = 1.0 # Amplify audio signal for viewing (1.0=No Amp).
SUBSIZE = 0.5 # Suggest 0.0(off) to about 0.5. (0.0 <= SubSize <= 1.0) : 0.0 = No Frame Number, 1.0=biggest size for current clip Height (probably too big).
SHOWAUDIO = False # Default True. If False, Switches OFF WaveForm Display, Shows FilmStrip Only.
W = 264 # Default -1, (or 0 or +ve). -1 = Normal Downscale behaviour, filmstrip width ~= input clip width.
#H = Undefined # Undefined, Let W govern height of thumbnail images (or just dont use h=H in function call, same as h=Undefined).

###### Can Remove this lot ######
TONE = False # Replace Colorbars tone with selected TONETYPE tone
TONETYPE ="NOISE" # Pick from:- "Silence", "Sine", "Noise", "Square", "Triangle" or "Sawtooth"
TONECHANS = 5 # Tone Channels Count (test channels display)
#
(TONE) ? AudioDub(Tone(Length=FrameCount/FrameRate,Type=TONETYPE,Channels=TONECHANS)) : Last
###### End Of Can Remove ######
WaveForm_FilmStrip(window=WINDOW,Height=HEIGHT,under=UNDER,zoom=ZOOM,subSize=SUBSIZE,ShowAudio=SHOWAUDIO,w=W) #,h=H)
Return Last


EDIT: The Waveform_FilmStrip() script at linked post is the most recent version.

EDIT: If Waveform_FilmStrip.avsi aint in plugins, then need to import it.

EDIT: And here with SHOWAUDIO=TRUE [but animated gif(via VDub2 export) dont have audio, so silent]
https://i.postimg.cc/6p1FqnD7/Waveform-Filmstrip.gif (https://postimg.cc/xXM6FJjY)

EDIT: If required, you could eg Interleave(Clip_A, Clip_B) and use result with WaveForm_FilmStrip, even frames would be Clip_A, odd Clip_B,
or just use eg StackHorizontal(Clip_A,Clip_B) to view side by side.

[ENunn]

Using SMDegrain and I'm having issues with random corruption artifacts. It happens randomly and I can't seem to find a fix.

https://i.imgur.com/0fMctji.png
SMDegrain(prefilter=5, str=0.8, refinemotion=true)


Any fix? Running AVS+ 2.7.2 and using the latest SMDegrain script. This doesn't occur in the source, and I have been using TempDegrain2 in the meantime with no issue, but it's painfully slow.

[Dogway]

AVS+ 3.7.2?
Update a small sample and full script since I'm not getting that issue.
Try with prefilter=-1 to see if it's ex_KNLMeansCL() related. Check dependencies as well.

[ENunn]

AVS+ 3.7.2?
Yeah, typo :P

Update a small sample and full script since I'm not getting that issue.
Here's the sample. (https://mega.nz/file/n8d12YZR#mWX-AXbxCvVbY5tM0V0oHBqXhsDokvdXBLaw1AF6ayE)


AVISource("G:\virtualdub\tape transfers\sampledegrain.avi", true, pixel_type="YUY2")
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
tweak(bright=-9, cont=1.04, hue=-10.0, sat=1.12, coring=false, dither=true).convertbits(8)
Trim(58, 554)
qtgmcp()
#ChromaShiftSP(X=-.85, Y=-.25)
ConvertToYv16(matrix="rec601",interlaced=false)
MergeChroma(aWarpSharp2(depth=20,threads=4))MergeChroma(aWarpSharp2(depth=10,threads=4))
santiag(strv=0, nns=4, nsize=5, threads=4)
#converttoyuy2(matrix="rec601", interlaced=false)
SMDegrain(prefilter=-1, str=0.8)


I also tried simply

AVISource("G:\virtualdub\tape transfers\sampledegrain.avi", true, pixel_type="YUY2")
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
tweak(bright=-9, cont=1.04, hue=-10.0, sat=1.12, coring=false, dither=true).convertbits(8)
Trim(58, 554)
qtgmcp()
SMDegrain(prefilter=-1, str=0.8)

The issue was still there, although the result is different. Looks like it depends on both the source and what's behind smdegrain. Might not show up for you at all yet it shows up for me.

I did take out the tweak and convertbits lines, looks like the issue doesn't happen there, but I need those lines.

Try with prefilter=-1 to see if it's ex_KNLMeansCL() related.

Same result.

Check dependencies as well.
Where can I find a list of them?

[Dogway]

I don't have any global HuffYUV decoder installed so I used FFMS2 loader and it didn't show any issue.

I think it must have to do with the source loader, try other one. Also just updated QTGMC+ although I don't think it's related.

For good measure try to trim after deinterlacing.

[Boulder]

You could also try adding RequestLinear(clim=100) right after the source and see if the issue disappears.

[kedautinh12]

Yeah, typo :P


Here's the sample. (https://mega.nz/file/n8d12YZR#mWX-AXbxCvVbY5tM0V0oHBqXhsDokvdXBLaw1AF6ayE)


AVISource("G:\virtualdub\tape transfers\sampledegrain.avi", true, pixel_type="YUY2")
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
tweak(bright=-9, cont=1.04, hue=-10.0, sat=1.12, coring=false, dither=true).convertbits(8)
Trim(58, 554)
qtgmcp()
#ChromaShiftSP(X=-.85, Y=-.25)
ConvertToYv16(matrix="rec601",interlaced=false)
MergeChroma(aWarpSharp2(depth=20,threads=4))MergeChroma(aWarpSharp2(depth=10,threads=4))
santiag(strv=0, nns=4, nsize=5, threads=4)
#converttoyuy2(matrix="rec601", interlaced=false)
SMDegrain(prefilter=-1, str=0.8)


I also tried simply

AVISource("G:\virtualdub\tape transfers\sampledegrain.avi", true, pixel_type="YUY2")
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
tweak(bright=-9, cont=1.04, hue=-10.0, sat=1.12, coring=false, dither=true).convertbits(8)
Trim(58, 554)
qtgmcp()
SMDegrain(prefilter=-1, str=0.8)

The issue was still there, although the result is different. Looks like it depends on both the source and what's behind smdegrain. Might not show up for you at all yet it shows up for me.

I did take out the tweak and convertbits lines, looks like the issue doesn't happen there, but I need those lines.



Same result.


Where can I find a list of them?

Depen here:
https://github.com/Dogway/Avisynth-Scripts/blob/1c94f882e232768d2d7b60fa13b47b94a2af1793/SMDegrain%20v3.5.3d/SMDegrain%20v3.5.3d.avsi#L30

[ENunn]

I don't have any global HuffYUV decoder installed so I used FFMS2 loader and it didn't show any issue.

I think it must have to do with the source loader, try other one. Also just updated QTGMC+ although I don't think it's related.
Loaded it with LWLibavVideoSource, same issue. Updated QTGMC+ and it said something along the lines of "there's no such thing as field" or something like that, so I rolled back.

For good measure try to trim after deinterlacing.
"RequestLinear: internal error (frame not cached)!" It wouldn't be a reliable fix even if it was a solution because scrubbing with QTGMC is painfully slow hence why I trim before deinterlacing.

You could also try adding RequestLinear(clim=100) right after the source and see if the issue disappears.
Didn't fix it.

Depen here:
https://github.com/Dogway/Avisynth-Scripts/blob/1c94f882e232768d2d7b60fa13b47b94a2af1793/SMDegrain%20v3.5.3d/SMDegrain%20v3.5.3d.avsi#L30
Thanks, issue still persists even with everything installed/updated though.

[Dogway]

I borked it (QTGMC), fixed now hopefully (along ResizersPack). In any case previous version (3.85) should be working.

My guess is that something is not up to date...

As per your comments everything runs fine until the SMDegrain call? Are you on x86 or x64?

Another thing, try with str=1 or str=0, str=0.8 invokes ex_retinex() which is good but that might be causing you some issue.

I'm going to update SMDegrain very soon but I don't think anything is related to your issue (mostly fixes for UHD)

[DTL]

"going to update SMDegrain very soon"

There is a faster interpolated overlap modes of MDegrainN - 4x in current release of 2.7.45+ and even faster diagonal overlap 2x hope in next release this week. It allow to run MAnalyse(overlap=0) for faster processing and make interpolating of MVs for 'classic' overlap (4x mode IntOvlp 1 and 2) and close or equal to BlockOverlap old plugin (IntOvlp 3 and 4) - 2x 'diagonal shifted' mode. 4x and 2x are number of blocks to process by blending engine so 2x expected to be about 2x faster. No overlap is 1x blocks number. So there will be very many combinations of speed/quality settings. May be for warp-around scripts it need to be arranged into 'speed_quality' single setting with values like slowest/slow/medium/fast/fastest or 1..10 integer value decoded internally into set of different processing modes.

Also 'diagonal' shifted mode may be further expanded for speed/quality different sets of processing modes like 'diagonal overlap' onCPU MAnalyse and diagonal overlap onHWAcc MAnalyse (it is easy compatible with accelerators ME search). With 'real searched' 2 sets of MVs (not interpolated second set inside MDegrainN). Though simple and fastest 2x diagonal interpolated mode already shows good results for everyday usage. Most of 4x-classic modes are expected to move to 'rarely use placebo'.

[Dogway]

I think I should do a fork of SMDegrain with your plugin so we can debug and get a hang of it. I'll make two versions a stripped down to focus only debugging, and another aligned with master. I'll wait for your release, then I'll try to update the ancient documentation.

[DTL]

I already update most of documentation for changed mvtools filters params at github https://github.com/DTL2020/mvtools/blob/mvtools-pfmod/Documentation/mvtools2.html . Only will add IntOvlp modes 3 and 4 (2x diagonal overlap with SAD re-check and 2x with interpolated SAD) after new fixed release. Currently it working only for inside frame and to use full frame area without distorted edges require addborders and crop of block-size size. Going to fix overlap windows for borders of frame processing soon. The 2x diagonal overlap require full separate set of overlap windows different from classic overlap of mvtools.

In classic mvtools the blocks number of 'dynamic' so 4x is worst case with overlap=blocksize/2 V and H. With large blocksize like 16 or 32 and small overlap size like 2 the number of blocks may be less than 2x even. But large blocks do not track complex motion good and only good for large static of no-detailed areas.

The formula of blocks number in 'classic' mvtools overlap is
nBlkX = (nWidth - nOverlapX)
/ (nBlkSizeX - nOverlapX);
nBlkY = (nHeight - nOverlapY)
/ (nBlkSizeY - nOverlapY);

So total blocks number nBlkX_x_nBlkY greatly depends on overlap length and block size and so overhead of overlap processing and speed degradation.
With small block size like 8 or 4 even small overlap like 2 greatly increases blocksnumber and degrades processing speed.

Update: New version with faster 2x diagonal overlap mode ready for testing - https://forum.doom9.org/showthread.php?p=1972579#post1972579

[hello_hello]

Dogway,
I've just started playing around with some of your functions.... lots of good stuff there.... but I have some questions regarding ConvertFormat's color conversion. Mostly regarding the change in transfer function from rec.709, but also regarding the change in primaries when _Matrix is correct for the target resolution. If _Matrix is correct but the primaries and transfer aren't set, should they be assumed to be correct too?
Also, what's the logic behind automatically changing the primaries from 601-625 to 601-525 (I'm assuming that's what colorspace refers to when show=true)? That also happens when the image is already SD and there's no resizing.

Thanks.

A 720p image without any color correction before resizing.
Spline36Resize(640,360)
https://i.ibb.co/CQGJ0G3/A.jpg
ConvertFormat(640,360,show=true)
https://i.ibb.co/ns8LFtN/AA.jpg

Matrix only color conversion before downscaling (fmtconv).
Spline36Resize(640,360)
propShow()
https://i.ibb.co/pXnWD7v/B.jpg
ConvertFormat(640,360,show=true)
https://i.ibb.co/251L6dM/BB.jpg

Matrix and primaries to 601-625 before downscaling.
Spline36Resize(640,360)
propShow()
https://i.ibb.co/ydwnXNZ/C.jpg
ConvertFormat(640,360,show=true)
https://i.ibb.co/JyFqphT/CC.jpg

Matrix and primaries to 601-525 before downscaling.
Spline36Resize(640,360)
propShow()
https://i.ibb.co/h8k711s/D.jpg
ConvertFormat(640,360,show=true)
https://i.ibb.co/Ytz6fXb/DD.jpg

[Dogway]

hello_hello, all the settings in ConvertFormat are infered from matrix/primaries (or frameprops as fallback). So if you type "709" it will assume D65, 1886 transfer, etc, unless you explicitly override them. If for example you want to keep 1886 transfer instead of correct (for SD) 170M one, set EOTF="".

There's a point of contemption for 470BG transfer, for RC54 I just changed it from academic 470BG transfer (2.8 gamma) to 170M transfer which is what was used in real world. But I'm open to suggestions.

By the way you can simply do ConvertFormat(640,show=true) to keep ratio.

TransformsPack is a bit of my color lab, I'm trying to do things a bit differently than other solutions out there by not hard-coding values but deriving them as most as possible. Also playing with more advanced concepts as alternative LMS spaces and soon gamut compression. As well as adding different color models while keeping usability intuitive enough.

I'm fixing chromatic adaptation and a small issue in PC levels and releasing v1.0 very soon maybe within this month, so bug reports will be very welcome. I also need to have a look at libplacebo from asd-g to see what can be integrated. From there on until 2.0 I will add the rest of primaries+transfer list, implement color models into ConvertFormat, gamut compression and preset system (in no order).

[hello_hello]

Thanks for the reply.
I'm still not sure I understand the changing of transfer from 1886 to 170m when resizing HD to SD though. I thought 1886 was a display gamma (simulating a CRT) and rec.709 and SD used the same transfer function, but maybe I'm misunderstanding that. 1886 to 170m obviously changes the picture though (and 170m to 1886 when upscaling makes it brighter), and I would've assumed the idea of color conversion when changing resolution would be for the picture to display the same as it did originally.

I used fmtconv to convert the colors, and the transfer choices for SD appear to be "601" or "470BG". I used the former and fmtconv set _transfer=6, which I assume is the same as 170m, but I was curious about the need to change the primaries from "470bg" (5) to "170m" (6) when _transfer=6, assuming they both do use the same transfer function.

This stuff still confuses me at times, so I'm asking out of curiosity, rather than implying it's wrong.

Cheers.

[Dogway]

Yes I checked again H.273 and indeed Transfer ID 1, 6, 14 and 15 all share same transfer (170M) (quote: For
TransferCharacteristics equal to 1, 6, 14 or 15, a has the value 1 + 5.5 * ß = 1.099296826809442... and ß has the value
0.018053968510807....), but this is contradictory because elsewhere (DaVinci, Nuke) Rec709 is associated with pure power gamma of 2.4 or 1886 set to 2.4, check for example here (https://github.com/ampas/aces-dev/blob/eaf92310789f3e45284214c56f806a965c087a08/transforms/ctl/odt/rec709/ODT.Academy.Rec709_100nits_dim.ctl#L115). ACES reference ODT Rec709.

This is typical for delivery, you use 2.40 for consumer media, 2.60 for theaters... Now what is 170M for Rec709 then? In Nuke there's also a Rec709 (~1.95) option, this is acquisition gamma as far as I know and matches roughly 170M. I read a lot about it at the time and there are many places that discusses the topic.

Here is a quote from my notes:
*While Rec. 709 does not specify the display referred gamma, display gamma is discussed in EBU Tech 3320 and specified in ITU-R BT.1886 as a gamma of 2.4. This is a higher gamma than the 1.95 the math shown above would indicate, because the television system has been deliberately designed with an end-to-end system gamma of about 1.2, to provide compensation for the ‘dim surround’ effect. Therefore, the monitor gamma is not the inverse of the camera gamma.

I would've assumed the idea of color conversion when changing resolution would be for the picture to display the same as it did originally.

If you do a color space conversion the colors are going to change no matter what, unless you pass it through a viewing transform ( Display_referred() )

I used fmtconv to convert the colors, and the transfer choices for SD appear to be "601" or "470BG". I used the former and fmtconv set _transfer=6, which I assume is the same as 170m, but I was curious about the need to change the primaries from "470bg" (5) to "170m" (6) when _transfer=6, assuming they both do use the same transfer function.

I don't know about fmtconv but in ConvertFormat() the transfer and illuminant are inferred from matrix/primaries not the other way around. In any case as I commented above, academic 470BG is 2.8 gamma, but as I could read this was never used in practice (just like 470M space), so I changed the infer to point PAL->170M, you can still override the transfer with "470BG".


EDIT: Here is an excerpt of page 6 of REC-BT.601-7 (in force).
In typical production practice the encoding function of image sources is adjusted so that the final picture has the desired look, as viewed on a reference monitor having the reference decoding function of Rec.ITU-R BT.1886, in the reference viewing environment defined in Rec. ITU-R BT.2035. Although some parameters listed in Recommendation ITU-R BT.2035 are intended for HDTV signal viewing, scaled viewing distances for SDTV signals should be used.

So probably I should switch all SD transfer functions to 1886, and leave 170M when you need to get the linear signal (inverse OETF or EETF).

[hello_hello]

When I said that after a color conversion I'd expect the video to display the same way, I realise the colors have to change, but I was looking at it in terms of a matrix conversion where if you convert from 709 to 601 for downscaling the colors change, but they display the same way (ignoring the difference in primaries).

*While Rec. 709 does not specify the display referred gamma, display gamma is discussed in EBU Tech 3320 and specified in ITU-R BT.1886 as a gamma of 2.4. This is a higher gamma than the 1.95 the math shown above would indicate, because the television system has been deliberately designed with an end-to-end system gamma of about 1.2, to provide compensation for the ‘dim surround’ effect. Therefore, the monitor gamma is not the inverse of the camera gamma.

Is that where the change in brightness/gamma is coming from in ConvertFormat?

I had assumed that to convert rec.709 gamma to SD gamma, which I gather has the same OETF anyway, but if it didn't you'd apply an inverse of the rec.709 OETF, taking you back to linear light, and from there apply the destination gamma curve. The way it seems to me is the BT.1886 EOTF would only be used at the display stage. The example for converting the rec.709 primaries on wikipedia (https://en.wikipedia.org/wiki/Rec._709#Transfer_characteristics) says BT.1886 shouldn't be involved.

As far as 470BG goes, I'm not worried about being able to use it as a transfer function, but if PAL->170M, does that mean ConvertFormat can't convert the primaries to 470BG/601-625/PAL? Not that I think it matters much, but given the 470BG primaries are closer to the rec.709 primaries than 170m I'm wondering if they'd be a better choice, or even if it'd be better not to convert them at all for playback using a HD display.
Cheers.

Edit: I deleted the rest of this post after reading a bit more. Continued next post though.....

[hello_hello]

According to Wikipedia, analog PAL was broadcast with a gamma of 2.8, hence the 470BG transfer function.
Although a citation on wikipedia led me to a PDF with a list of analogue broadcast gammas and a note for PAL which says:
"(13) Assumed value for overall gamma approximately 1.2. The gamma of the picture tube is defined as..."

In the section on rec.709 transfer characteristics (https://en.wikipedia.org/wiki/Rec._709#Transfer_characteristics) on Wikipedia it says:
"Old CRTs had a EOTF of 2.35 pure gamma"
yet analogue NTSC was broadcast with a gamma of 2.2.

Somewhere on wikipedia there was a citation that led me to this page:
https://www.chromapure.com/colorscience-gamma-new.asp
"The combination of these two opposite nonlinear luminance curves—camera gamma at the production end and display gamma at the device end—results in a linear system gamma of 1.0, which is what we want. However, when viewing material in a dim environment, it is generally thought desirable to have a system gamma that is slightly higher: somewhere between 1.1 and 1.2 is most often quoted figure."

Obviously the "system gamma" of 1.2 continued into the digital era, but from what I've read I assume there was no standard way to achieve it before BT.1886. I can't get my head around how it's anything but a display gamma though, and as such nothing you'd apply when doing a colorspace conversion, at least not for SDR<->SDR conversions. If you do, doesn't it result in an OOTF of 1.0 instead of 1.2, or depending on the direction greater than 1.2, or something else entirely?

In fact, now that I read it again....
rec.709 transfer characteristics (https://en.wikipedia.org/wiki/Rec._709#Transfer_characteristics)
"Rec. 709 doesn't specify the display EOTF (electro-optical transfer function) which describes how HDTV displays should convert the non-linear electrical signal into linear displayed light, that was done in BT.1886."

[Dogway]

When I said after a color conversion I'd expect the video to display the same way, I realise the colors have to change, but I was looking at it in terms of a matrix conversion where if you convert from 709 to 601 for downscaling the colors change, but they display the same way (ignoring the difference in primaries).

Change in what terms, colors (primaries) or tones (transfer)? For transfer I'm going to perform a few changes I will list below, for color it's going to change no matter what because AvsPmod nor any other GUI for AVS are color managed (like Photoshop or Firefox are), so to visualize all your videos and having them match color space-wise you should append Display_referred() to the end of the script ideally with a calibration-LUT referenced, comment it before encoding though.

As for the issue with gamma, I will change all OETF (read "inverse EOTF", will deal with naming later) and EOTF to 1886 as most content we work with are consumer delivery media. To get the scene-referred linear signal one should do an inverse 1886 EOTF, then a 1886 to 170M (or according acquisition gamma) OOTF (misnamed in above post as EETF).

This is going to clash and go against with many of the current source loaders and color conversion plugins frame properties support which indicate transfer characteristics IDs based on matrix and not on consumer media standard EOTF. And will also require a 32-bit pipeline to avoid crushing blacks as 1886 has not a linear part to protect those areas (16-bit is not enough), I will try to force 32-bit in such cases only for the required parts to save performance.

To illustrate:
709-Camera (170M: Acquisition) -> Linear (post-production) -> 1886 EOTF (delivery)

Depending on what linearization process was used in post-production one would get scene-referred linear signal with a simple inverse 1886 EOTF, or an additional OOTF should be used. Otherwise all you get is electrical-linear, not scene-referred.

For color space conversion (your fmtc example) and all processing electrical-linear is sufficient, as that's the linear space where (I think) all post-production is performed (assuming they linearize by inverse 1886 EOTF).

What does "the encoding function of image sources is adjusted" mean? Not a rec.709 OETF?

That implies they use a simple inverse 1886 EOTF and not an inverse 709-camera (170M OETF technically) because by default their monitors should be calibrated to 1886. So they simply get linear by reversing a Display 1886 EOTF without the need to add OOTF and such.

OOTF of 1.2 is in case you want to get "scene-referred" linear, or undo the dim surround adaptation to re-adjust to an EOTF of 2.2 or 2.6.

Some remarks from you latest post

(13) Assumed value for overall gamma approximately 1.2. The gamma of the picture tube is defined as...
It means an end-to-end absolute gamma after OETF+EOTF, because a dim surround requires a higher gamma.
In the section on rec.709 transfer characteristics on Wikipedia it says:
"Old CRTs had a EOTF of 2.35 pure gamma"
yet analogue NTSC was broadcast with a gamma of 2.2.
That would make an end-to-end absolute gamma of 1.07 which is within reason, some CRTs were 2.4 or even 2.5. Technically they should set the programming to a 170M gamma.

results in a linear system gamma of 1.0, which is what we want.
We surely don't want an absolute gamma of 1.0. TV systems were designed to be played from the evening onwards, that's why the CRTs gamma were dialed to 2.4 and the concept of "dim surround" which is a night living room with lights on.


I will be uploading an update later today so you can tell me if it makes better sense to you (it does so for me).

[DTL]

"Depending on what linearization process was used in post-production one would get scene-referred linear signal with a simple inverse 1886 EOTF, or an additional OOTF should be used. Otherwise all you get is electrical-linear, not scene-referred."

It looks using or not OOTF part also may visibly affects the other processing attempt to perform in 'linear' like scaling -
https://forum.doom9.org/showthread.php?p=1970995#post1970995 . May be only jpsdr plugin may switch on/off OOTF part to see the difference. And many other plugins for convert to 'linear' can not.

[Dogway]

I'm pretty sure all SDR content today is mastered to 1886 2.4 gamma for consumer media so "what you see is what you get". But back in the day (pre-grading ages) it was about playing with gamma and let the end device do the heavy lifting, therefore encoding with 170M gamma with a linear part in the foot region to "minimize noise in the darker areas of the image". Then it was naturally shown with 2.3-2.4 power gamma by the CRT Electron Gun.

@DTL: Just noticed some issues with internal scalers and float bitdepth, overshoots are not clipped so they can create some NaN pixels later on. I will have a look at your linked post. I recall running some tests some time ago.

This leads to some below 0 values:
Blankclip(width=256, height=256, pixel_type="YUV420PS")
Expr("sx 128 > range_max 0 ?","")
bicubicresize(2048,2048,0,0.75)

[DTL]

Below 0 is normal for undershoots because AVS float format is in 0.0 .. 1.0 nominal range as I read at forums - not 16.0..235.0 as may be expected. So any undershoot with 0.0 black will go below zero in the negative numbers.
I check

Blankclip(width=256, height=256, pixel_type="YUV420PS")
Expr("sx 128 > range_max 0 ?","")
bicubicresize(2048,2048,0,0.75)

ColorYUV(gain_y=-100, off_y=50)

ConvertBits(8)

It looks like normal over/undershoots but no significant bugs visible if even NaN values exist somewhere (?). In bad case NaN may converted to integer in some really buggy 8bit values like 0 or 255 and cause gross distortions.
I think the too low undershoots like -1.0 float will be clipped to 0 integer. Same with too high overshoots to 255 8bit.

Good linear scaler must not clip any over/undershoots if possible. So using float allow to keep over/undershoots of any amplitude. And integer scaler will clip to 0 and MAX_INT unsigned or to (-)MIN_INT and MAX_INT signed.

[Dogway]

Depending on the following expression I can get white NaN pixels (from the -0.1 values). This is going to be normal for linear resizing so I don't know if a clamp argument would be beneficial in scalers... or something along the lines of "don't change sign".

Not sure how to handle this except for avoid resizing in float.

Blankclip(width=256, height=256, pixel_type="YUV420PS")
Expr("sx 128 > range_max 0 ?","")
propSet("_ColorRange",0)
ConvertBits(32)
bicubicresize(2048,2048,0,0.75)
ex_Luma_Rebuild(5.0, 0.03, tv_in=false)

[kedautinh12]

Hi Dogway, your deep_resize proplem with 1440i, i tried but error with both gpuid=0 and -1.

My script:
AnimeIVTC(mode=1)
deep_resize(1920,1080)

I got error NNEDI3CL: field must be 0 or 1 when dw=True

and with this script:
AnimeIVTC(mode=1)
deep_resize(1920,1080, gpuid=-1)

I got video don't match with audio

my example: https://mega.nz/file/eHQSWJxB#eSXcMype583W9Bij7L0jpot5Hse3WNdg9B2t4mxACPw

[DTL]

"I can get white NaN pixels (from the -0.1 values)."

If you think there is some bug around zero or in going negative - the float allow to add some 'big' positive offset like 10.0 to 'nominal' 0.0..1.0 range before operation and subtract after. I think it should completely avoid using any negative values and zero crossing at resampling engine.
This also works without visible distortions

Blankclip(width=256, height=256, pixel_type="YUV420PS")
Expr("sx 128 > range_max 0 ?","")
ColorYUV(off_y=50000)
bicubicresize(2048,2048,0,0.75)
ColorYUV(off_y=-50000)
ColorYUV(gain_y=-100, off_y=50)
ConvertBits(8)

[Dogway]

Hi Dogway, your deep_resize proplem with 1440i, i tried but error with both gpuid=0 and -1.

My script:
AnimeIVTC(mode=1)
deep_resize(1920,1080)

I got error NNEDI3CL: field must be 0 or 1 when dw=True

and with this script:
AnimeIVTC(mode=1)
deep_resize(1920,1080, gpuid=-1)

I got video don't match with audio

my example: https://mega.nz/file/eHQSWJxB#eSXcMype583W9Bij7L0jpot5Hse3WNdg9B2t4mxACPw

Interlaced isn't supported in deep_resize only progressive, try also to check frame properties.

Thanks DTL, yes I was trying to avoid adding an additional calls like preshaping or clamping. It's for the scaling spaces in ConvertFormat (gamma, linear, sigmoid, log)

[kedautinh12]

Interlaced isn't supported in deep_resize only progressive, try also to check frame properties.

Thanks DTL, yes I was trying to avoid adding an additional calls like preshaping or clamping. It's for the scaling spaces in ConvertFormat (gamma, linear, sigmoid, log)

But i used to animeITVC to deinterlace

[kedautinh12]

I used to deep_resize with other interlaced after deinterlace with animeITVC and got no error.

[Dogway]

@kedautinh12, can you check frame properties after AnimeIVTC? I don't have the script and its dependencies installed so I can't check but for me your clip works by deinterlacing with ex_bob(nnedi3=true).
Try adding propSet("_FieldBased",0) before deep_resize()


It looks using or not OOTF part also may visibly affects the other processing attempt to perform in 'linear' like scaling -
https://forum.doom9.org/showthread.php?p=1970995#post1970995 . May be only jpsdr plugin may switch on/off OOTF part to see the difference. And many other plugins for convert to 'linear' can not.

OOTF looks to be as simple as o_transfer/i_transfer. In any case I still don't support HDR in ConvertFormat, HLG nor PQ so can't help with your issue.


EDIT: hello_hello, you can download now updated TransformsPack here (https://github.com/Dogway/Avisynth-Scripts/blob/master/TransformsPack%20-%20Main.avsi). Default OETF and EOTF have been changed for consumer delivery spaces. I might need to add more in the future.

I also created a new function OOTF() in TransformsPack - Transfers. It will take a single remap gamma value in OOTF, but you can also specify OETF and EOTF gamma values as floats, or their transfer names as strings. For those transfers with piece-wise functions (a linear part towards zero) a minimization algo was implemented to find the power law match, so for example for sRGB it would minimize to 2.223. This is faster than linearizing then gamma encoding back.

On another note I'm finally updating the SMDegrain documentation, half done already.

[kedautinh12]

@kedautinh12, can you check frame properties after AnimeIVTC? I don't have the script and its dependencies installed so I can't check but for me your clip works by deinterlacing with ex_bob(nnedi3=true).
Try adding propSet("_FieldBased",0) before deep_resize()

Oh, it's work with propSet("_FieldBased",0) before deep_resize(). Thanks

[hello_hello]

Well... I've tried, but I just don't understand the world anymore..... :(

720p Rec.709 YV12 source.
No Avisynth+ frame properties.
Transforms Pack 1.0 RC55

ConvertBits(16)
ConvertToDoubleWidth()
Matrix(From=709, To=601, Bitdepth=16)
ConvertFromDoubleWidth()
Spline36Resize(640,360)
https://i.ibb.co/zx4gq2g/1.jpg

ConvertToYUV444()
ConvertBits(16)
ConvertYUVtoLinearRGB(Color=2)
ConvertLinearRGBtoYUV(Color=4)
ConvertBits(8)
ConvertToYV12()
Spline36Resize(640,360)
https://i.ibb.co/dt886c9/2.jpg

fmtc_bitdepth(bits=16)
fmtc_resample(css="444")
fmtc_matrix(mat="709", bits=16)
fmtc_transfer(transs="709", transd="linear")
fmtc_primaries(prims="709", primd="601-625")
fmtc_transfer(transs="linear", transd="601")
fmtc_matrix(mat="601", bits=16)
fmtc_resample(640,360,css="420")
fmtc_bitdepth(bits=8)
https://i.ibb.co/191WJpG/3.jpg

ConvertFormat(640,360)
https://i.ibb.co/VHKC1Dc/4.jpg

ConvertFormat(640,360, OETF="170m", EOTF="170m")
https://i.ibb.co/3dGfynG/5.jpg

ConvertFormat(640,360, EOTF="170m")
https://i.ibb.co/CBN1ZLY/6.jpg

Bugs be here?
Display_Referred("1886")
https://i.ibb.co/PTPxJzd/7.jpg

Display_Referred()
ConvertFormat(640,360)
https://i.ibb.co/FgXV3j1/8.jpg

[Dogway]

There's a regression when I repurposed Matrix_coef() to retrieve primaries for XYZ_to_RGB() a few weeks ago so it's reading 470M instead of 170M, hold on a bit. I've been thinking for some time on a manner to restructure the matrices vertically since I'm going to add many more but still haven't come with a solution...

Display_referred() should be working. You don't specify the transfer but the color space, if your source is "170M" and your display is calibrated to Rec.709 with 1886 transfer set:
Display_Referred ("170M","709") # 709 or sRGB whatever your display is calibrated against
Ideally you should set a LUT profile in the "profile" argument.


EDIT: @hello_hello, updated TransformsPack to RC56 with the above fix. I can't follow your first two examples but for fmtconv you might want to use "601-525" which corresponds to "170M". And as I commented a few posts back you want to use 1886 transfer for going to and from linear since all/most media is delivered in this ODT (display referred).

[ENunn]

Sorry for the late response.

I borked it (QTGMC), fixed now hopefully (along ResizersPack). In any case previous version (3.85) should be working.

My guess is that something is not up to date...
Everything was up to date as of my last post. I just downloaded the pack again just to be safe and the issue still happens.

As per your comments everything runs fine until the SMDegrain call?
Yes, and if I move the converttoyuv422/convertbits/tweak/convertbits line after SMDegrain, the issue doesn't happen.

Are you on x86 or x64?
x64

Another thing, try with str=1 or str=0, str=0.8 invokes ex_retinex() which is good but that might be causing you some issue.
Looks like that fixed it.

[Dogway]

@ENunn, that's very strange specially after the last fix for ex_retinex(), simply try directly:
ex_retinex(lo=80, tv_in=true, tv_out=false)
And just in case revise you are on latest vsTCanny plugin version.

[ENunn]

@ENunn, that's very strange specially after the last fix for ex_retinex(), simply try directly:
ex_retinex(lo=80, tv_in=true, tv_out=false)
And just in case revise you are on latest vsTCanny plugin version.
Tried before and after SMDegrain and without SMDegrain and the issue is still there, plus it makes the image much brighter as well.

I updated vsTCanny and it's still there.
https://i.imgur.com/JNxq8z4.png
https://i.imgur.com/zAIC8Il.png

[hello_hello]

Dogway, is there a RC56 version of Transforms Pack - Models? It's just that I'm only producing "no function named Matrix_coef" errors with ConvertFormat since updating the other two scripts.

I can't follow your first two examples but for fmtconv you might want to use "601-525" which corresponds to "170M".

1. Matrix-only conversion with HDRMatrix.
2. 709 -> 601-625 conversion with HDRTools.

What's the logic behind always converting to NTSC primaries?
I was pondering over whether "170M" should still be used to describe a transfer function earlier, which led me to discover... unless the list is incomplete or I'm blind.... it no longer does for h265. http://www.vapoursynth.com/doc/functions/video/resize.html
And as rec.601 is the matrix for both digital "PAL" & "NTSC", the only reason I can think of for using 170M or 480bg is to differentiate between them.
601_525, 601_625 & 601 cover all the bases, although for CropResize I went with 601N, 601P and 601 even though the NTSC and PAL implication isn't accurate.

For a while I was fairly anal about converting the primaries to 601, and I generally chose 601_625 because they're closer to 709, but if HD displays and players don't concern themselves with the primaries and simply assume 709, which I suspect they mostly do, a matrix-only conversion might be better.

And as I commented a few posts back you want to use 1886 transfer for going to and from linear since all/most media is delivered in this ODT (display referred).

I'll take your word for that, but I still can't get my head around it as everything I've read indicates it's only a display transfer function, and because 1886 is designed to factor in the black (and white?) levels of a calibrated display, and because the display used for mastering is an unknown, and because the definition of "deliver" might be one that doesn't imply it's not converted to 709 (scene) before it reaches my TV, and because to me it defeats the purpose of 1886, but what do I know.....

[Dogway]

TransformsPack - Models was updated here (https://github.com/Dogway/Avisynth-Scripts/commit/e093a2c428078ba1dd134716cd8f90d5fdd188c4). I simply forgot version update.
What's the logic behind always converting to NTSC primaries?
You mean NTSC matrix coefficients? Both PAL and NTSC inherited the matrix coefficients of 470M (FCC) for historical reasons. Read here (https://github.com/Dogway/Avisynth-Scripts/blob/75ac682b5559a426d43d1ca7abda8574ffa0f341/TransformsPack%20-%20Main.avsi#L1854).
I was pondering over whether "170M" should still be used to describe a transfer function earlier, which led me to discover... unless the list is incomplete or I'm blind.... it no longer does for h265. http://www.vapoursynth.com/doc/funct...eo/resize.html
And as rec.601 is the matrix for both digital "PAL" & "NTSC", the only reason I can think of for using 170M or 480bg is to differentiate between them.

H.265 ITU paper calls the transfer function by their related matrix, they are inconsistent though, they call the 2020 transfer ST.2084 which is the (SMPTE) paper that defines the 2020 space characteristics. Yes, a mess, they mix ITU, IEC, FCC, and SMPTE naming standards. I say, stick to one or two, you can read here some of my rant (https://forum.doom9.org/showthread.php?p=1957275#post1957275). To start with, the first time (or one of the firsts) the 170M transfer was defined was in SMPTE ST 170 in 1994, your linked table makes use of this transfer for 709, 601, 2020_10 and 2020_12 and state "functionally the same", yes, another mess. "Functionally the same" reads as different but yields the same result, which is not true, they employ not "functionally" but the exact same transfer, so I gave it a single name.
Now why did I keep 470BG transfer (2.8 gamma)? because in TransformsPack I allow you to do whatever you want to. Limited TV range for float? Also OK. AP0 primaries? Also OK (not listed in ITU)
Another aspect is the matrix coefficient table, so RGB "is" a matrix ? ICtCp is a matrix? YCoCg? Another mess. They are color models, and the said "matrix" coefficients only refers to the YCbCr model matrix coefficients, not the ICtCp, not the YcCbcCrc or any other. No wonder you are confused, not even the standards make it right. I do my best to add comments on my scripts to give some background but I don't adhere strictly to ITU or any other standard.
For a while I was fairly anal about converting the primaries to 601, and I generally chose 601_625 because they're closer to 709, but if HD displays and players don't concern themselves with the primaries and simply assume 709, which I suspect they mostly do, a matrix-only conversion might be better.
I want to think they do convert from 170M for SD, the same reason they still keep deinterlacing capabilities, now I don't know what they assume for 640x360, maybe you should scale it based on height (854x480 or 1024x576).
I'll take your word for that, but I still can't get my head around it as everything I've read indicates it's only a display transfer function, and because 1886 is designed to factor in the black (and white?) levels of a calibrated display, and because the display used for mastering is an unknown, and because the definition of "deliver" might be one that doesn't imply it's not converted to 709 (scene) before it reaches my TV, and because to me it defeats the purpose of 1886, but what do I know.....
You can also take cretindesalpes' word for that, as I found an example (https://github.com/EleonoreMizo/fmtconv/blob/0adef1c811c5715077448c41997d7ece116232d6/doc/fmtconv.html#L177) yesterday in the docs.
The display used for mastering DVD/BD consumer media is calibrated to 1886, they make different (grade) trims depending on delivery media and it's always display referred (for the last 20 years at least). The workflow typically involves an IDT (OETF) -> Log/Linear (trim pass under EOTF proof) -> ODT (EOTF). So they work in log or linear space under an EOTF (1886) viewing transform.
To be more specific, the input device might be calibrated so the IDT could be transformed from a custom (unknown) profile, and similarly the EOTF viewing transform is also a mastering monitor profile characterized against 1886. When encoding the EOTF into the image instead you don't use your display profile (with custom 1886 settings) but a generic one that assumes a perfect imaginary display with 0 black, so in essence a power law gamma of 2.4 and a generic color space with known primaries, like 709. This makes it possible to "undo" the transfer and primaries and convert to your display profile in case it's calibrated, or play very close to intended in case it's not calibrated

--------------------------------------

@ENunn, what do you mean with "the issue is still there, plus it makes the image much brighter as well." Either the issue is present or it's making the image brighter which means it's working fine (that's retinex) if it shows your image black or as your above example, then there's an issue. But I'm not experiencing it with FFMS2 loader.

[hello_hello]

TransformsPack - Models was updated here (https://github.com/Dogway/Avisynth-Scripts/commit/e093a2c428078ba1dd134716cd8f90d5fdd188c4). I simply forgot version update.

I didn't update it because the version number was the same. Obviously I should have.
It's working now so I'll have a play with it again soon.

You mean NTSC matrix coefficients? Both PAL and NTSC inherited the matrix coefficients of 470M (FCC) for historical reasons. Read here (https://github.com/Dogway/Avisynth-Scripts/blob/75ac682b5559a426d43d1ca7abda8574ffa0f341/TransformsPack%20-%20Main.avsi#L1854).

No I was referring to the primaries, as you said I should use 601_525 with fmtconv rather than 601_625. It's the fmtconv method for choosing the SD primaries.

H.265 ITU paper calls the transfer function by their related matrix, they are inconsistent though, they call the 2020 transfer ST.2084 which is the (SMPTE) paper that defines the 2020 space characteristics. Yes, a mess, they mix ITU, IEC, FCC, and SMPTE naming standards. I say, stick to one or two, you can read here some of my rant (https://forum.doom9.org/showthread.php?p=1957275#post1957275). To start with, the first time (or one of the firsts) the 170M transfer was defined was in SMPTE ST 170 in 1994, your linked table makes use of this transfer for 709, 601, 2020_10 and 2020_12 and state "functionally the same", yes, another mess. "Functionally the same" reads as different but yields the same result, which is not true, they employ not "functionally" but the exact same transfer, so I gave it a single name.

Now why did I keep 470BG transfer (2.8 gamma)? because in TransformsPack I allow you to do whatever you want to. Limited TV range for float? Also OK. AP0 primaries? Also OK (not listed in ITU)

I think it's fine to keep the 470bg transfer option, although given it was an analog-only thing it possibly adds to the confusion.
That's why I think replacing 170m with 601 (in respect to naming) as the transfer curve and matrix for digital is a good idea because if you read the wikipedia page (Rec. 601) it was intended for both PAL and NTSC and was later updated to include both the PAL and NTSC primaries.
Some plugins (colormatrix) use 601 as the SD matrix, while some (avsresize) use it for the transfer curve but not for the matrix.
Of course because the primaries are different for PAL and NTSC you do need a way to differentiate between them.

Another aspect is the matrix coefficient table, so RGB "is" a matrix ? ICtCp is a matrix? YCoCg? Another mess. They are color models, and the said "matrix" coefficients only refers to the YCbCr model matrix coefficients, not the ICtCp, not the YcCbcCrc or any other. No wonder you are confused, not even the standards make it right. I do my best to add comments on my scripts to give some background but I don't adhere strictly to ITU or any other standard.

For RGB to have a matrix does seem meaningless, but from our perspective it'd be useful if you could use it to correct RGB colorimetry without having to convert to a different colorspace and back. For example, if YUV was converted to RGB using rec.709 instead of rec.601, it'd be nice to be able to correct it this way (using an avsresize type example)
709:srgb:170m=>601:srgb:170m
but I don't think any plugins will do that sort of thing for RGB without a format conversion in between. Maybe there's a reason for that I'm unaware of.

I want to think they do convert from 170M for SD, the same reason they still keep deinterlacing capabilities, now I don't know what they assume for 640x360, maybe you should scale it based on height (854x480 or 1024x576).

640x360 was just a 16:9 resolution I chose because I'd originally planned to add the pictures to my post, but when there ended up being several of them I posted links instead.

You can also take cretindesalpes' word for that, as I found an example (https://github.com/EleonoreMizo/fmtconv/blob/0adef1c811c5715077448c41997d7ece116232d6/doc/fmtconv.html#L177) yesterday in the docs.
The display used for mastering DVD/BD consumer media is calibrated to 1886, they make different (grade) trims depending on delivery media and it's always display referred (for the last 20 years at least). The workflow typically involves an IDT (OETF) -> Log/Linear (trim pass under EOTF proof) -> ODT (EOTF). So they work in log or linear space under an EOTF (1886) viewing transform.
To be more specific, the input device might be calibrated so the IDT could be transformed from a custom (unknown) profile, and similarly the EOTF viewing transform is also a mastering monitor profile characterized against 1886. When encoding the EOTF into the image instead you don't use your display profile (with custom 1886 settings) but a generic one that assumes a perfect imaginary display with 0 black, so in essence a power law gamma of 2.4 and a generic color space with known primaries, like 709. This makes it possible to "undo" the transfer and primaries and convert to your display profile in case it's calibrated, or play very close to intended in case it's not calibrated

I understand what you're saying, but it seems to cover what production companies can do with delivered content, not necessarily how it ends up being streamed to my TV. I was looking at the Netflix delivery specs (https://partnerhelp.netflixstudios.com/hc/en-us/articles/214806618-Netflix-Branded-Delivery-Specifications-v4-1) yesterday, and for HD SDR it's:
10 bit
ITU-R BT.709 / D65 / ITU-R BT.1886
(Gamma 2.4)

So then I checked out the packaging requirements:
All deliveries to Netflix must be compliant to either SMPTE ST 2067-21:2016 or SMPTE ST 2067-21:2020 Interoperable Master Format (IMF) Application #2E.

Okay, so what does SMPTE ST 2067-21:2020 (https://ieeexplore.ieee.org/document/9097487) say?
COLOR.1
Mapped as specified for 625-line systems in Section 2.6 of Recommendation ITU-R BT.601-7.
COLOR.2
Mapped as specified for 525-line systems in Section 2.6 of Recommendation ITU-R BT.601-7.
COLOR.3
Mapped as specified in Section 1 of Recommendation ITU-R BT.709-6.

Note: In Recommendation ITU-R BT.601 and Recommendation ITU-R BT.709, the signals... ...correspond to gamma pre-corrected signals.

The above seems to serve as support for only using 601 too, but off to ITU-R BT.709-6.
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf
Overall opto-electronic transfer characteristics at source
It doesn't seem to copy and past properly but it's the standard 709 OETF with the following footnote:
(1) In typical production practice the encoding function of image sources is adjusted so that the final picture has the
desired look, as viewed on a reference monitor having the reference decoding function of Recommendation
ITU-R BT.1886, in the reference viewing environment defined in Recommendation ITU-R BT.2035.

Just kill me now. Could "the encoding function of image sources" mean "the encoding function of the source video when it's decoded"?
It won't install on this PC, but sometime soon I'm going to check out Davinci Resolve to see what it actually does. I've looked at a few instructional videos and what they show is what you've said, with the exception of rendering when choosing rec.709 as the output colorspace. There, the transfer curve used wasn't really clear.

[Dogway]

although given it was an analog-only thing it possibly adds to the confusion.
That's why I think replacing 170m with 601 (in respect to naming) as the transfer curve and matrix for digital is a good idea because if you read the wikipedia page it was intended for both PAL and NTSC and was later updated to include both the PAL and NTSC primaries.

You are not going to see the 470BG curve referenced anywhere today since it's considered "deprecated" by current standards, so all the references you are going to see for PAL transfer is the original 170M curve. I even had a hard time finding its alpha and phi values.

I'm adding or planning to add all sorts of analog models and spaces, for example YIQ, YPbPr and so on. NTSC 1953 was also analog only and it's included everywhere (for some reason).

My design choice is similar to avisynth's "give people enough rope to hang themselves", replacing "hang" with the chance of being more capable or experimental, all while keeping a good user experience and defaults.

it'd be useful if you could use it to correct RGB colorimetry without having to convert to a different colorspace and back
YCbCr is not a linear model, so you can't change color space without going to RGB and back.
709:srgb:170m=>601:srgb:170m
That line doesn't make sense to me, change matrix while keeping primaries? sRGB transfer for YUV?

Could "the encoding function of image sources" mean "the encoding function of the source video when it's decoded"?
It's only a convoluted way to say, grade your (decoded -as in inverse OETF-) footage until it looks fine in your 1886 calibrated reference monitor.

[ENunn]

@ENunn, what do you mean with "the issue is still there, plus it makes the image much brighter as well." Either the issue is present or it's making the image brighter which means it's working fine (that's retinex) if it shows your image black or as your above example, then there's an issue. But I'm not experiencing it with FFMS2 loader.

The issue is still present, as shown in my first screenshot.

I loaded it with ffms2, and the issue is still there. (https://imgur.com/a/gdQShAS)

EDIT: It has something to do with the tweak line. I removed the convertbits parts and the issue persists. I also tried another tweak plugin, SmoothTweak, and the issue happens there as well. Tweak before SMDegrain causes the issue, tweak after SMDegrain does not have any issues.

[hello_hello]

You are not going to see the 470BG curve referenced anywhere today since it's considered "deprecated" by current standards, so all the references you are going to see for PAL transfer is the original 170M curve. I even had a hard time finding its alpha and phi values.

All I was trying to say is 480bg is analog, as I assume was 170M originally, then along came rec.601 for digital which once again I assume has the same transfer function as 170M, but either way, rec.601 replaced both 170M and 480bg for digital video so to me it makes sense if 601 was used to describe the digital SD matrix and transfer function. Just as an example, that's what fmtconv does for matrix, there is no 170M option, and for transfer it's the same, except 480bg is still an option if you want to use it. For the SD primaries there's several presets for choosing them, but my preference is to stick with the 601 theme and use the 601_525 and 601_625 presets for digital "NTSC" and "PAL".

Lots of options is good, but for presets that'd be my preferred naming scheme.

YCbCr is not a linear model, so you can't change color space without going to RGB and back.

That line doesn't make sense to me, change matrix while keeping primaries? sRGB transfer for YUV?

Isn't changing the matrix while staying in YUV what colormatrix does?
My example probably should have looked like this
709:srgb:709=>601:srgb:170m
but it was in reference to my fantasy for being able to correct the incorrect matrix used when converting YUV to RGB without changing color space. So it'd be RGB in and RGB out. For the above example you'd have RGB that was converted from YUV using the 709 matrix when it should've been 601, so in my fantasy it would correct that while staying in RGB.
Maybe it's something that can't actually be done, although I was under the impression that's what the following would do for HDRTools, but looking at it again now I'm not really sure what it does. I think it's just changing the primaries.
ConvertToRGB(matrix="rec709")
ConvertRGBtoXYZ(Color=2)
ConvertXYZtoRGB(Color=4)

It's only a convoluted way to say, grade your (decoded -as in inverse OETF-) footage until it looks fine in your 1886 calibrated reference monitor.

Well it does say "the encoding function of image sources is adjusted", and if it's referring to the source video it shouldn't apply if the source video was 1886. Anyway, it's obviously just guessing because I don't actually know.

[Dogway]

601 is too ambiguous, for SD I follow the SMPTE nomenclature because they were the reference standard at the time and CCIR (now ITU) was behind. They simply knew what they were doing. All SD related content from ITU is badly copy/pasted from SMPTE standards or directly don't have a paper for the recommendation and simply refer to the SMPTE.

The good news in ConvertFormat is that it supports aliases, so if you like "601" or "601_525" (to remove ambiguity) simply input that and it will retrieve the best match. And the property IDs are unified so they will be the same for fmtconv, TransformsPack, avsresize, etc I expanded them though.

Isn't changing the matrix while staying in YUV what colormatrix does?
The use case for ColorMatrix is such a corner case scenario that I haven't even implemented it.
Read here (https://github.com/EleonoreMizo/fmtconv/blob/0adef1c811c5715077448c41997d7ece116232d6/doc/fmtconv.html#L163).
It shouldn't be a thing really. My question is, how do you know it's using the wrong matrix but the correct primaries?

Well it does say "the encoding function of image sources is adjusted"
You shouldn't read too much into it, they are full of inconsistencies otherwise we wouldn't be going rounds in Doom9 about the topic. You don't "adjust" a transfer function, you choose it according to your delivery choice and master monitor.

[madey83]

Hello,

Could you advice how to setup denoiser like SMDegrain to clear this out?
https://i.postimg.cc/cCW67vT2/example.png

EDIT:
on the screen there is less noise than on the video.

i tired these without any spectacular effects:

SMDegrain(tr=2, thSAD=500,thSADC=100, thSCD2=80, contrasharp=false, refinemotion=true, truemotion=false, search=4, subpixel=3, Chroma=true, plane=4, LFR=false, DCTFlicker=false)

### Dogway this is a good compromise between quality and speed
Code:
smdegrain(tr=2,mode="temporalsoften",blksize=32,thSAD=700,LFR=2,contrasharp=false,refinemotion=true)
smdegrain(tr=2,mode="MDegrain",blksize=32,thSAD=400,LFR=false,contrasharp=true,refinemotion=true)

EDIT:
i've just adjusted in the latest version of SMDegrain below line acordingly:

(prefilter== 5) ? pref.ex_KNLMeansCL(a=3,s=3,d=3,h=9.0,wmode=2,chroma=chroma,gpuid=gpuid,LFR=0*(nw/1920.)).ex_boxblur(0.5, mode="weighted", UV=Chr)

and got some promissing results, but encode speed drop off beacuse CPU usage is only for about 70%.

[Dogway]

I don't think you need to run the double call, I don't see the source that grainy (300 style).

Simply use a good prefilter, maybe BM3D, and raise 'tr' a bit. I don't know the reason to tweak thSCD2, also everything else is already the default so you can omit.

KNLMeansCL runs in GPU with OpenCL, you can also try DGDenoise which runs over CUDA.

[DTL]

SMDegrain(tr=2,"

Max possible temporal denoising amplitude is about doubled with about 4x of tr-value. So tr=2 with 4 ref frames may only about half of noise amplitude. To decrease noise more it is required something like 2x4=8 or 2x16=32 (about 4 times less noise in lucky case of all ref blocks found and used).

With too big noise level and too high thSAD it is good to set thSCD1 not below thSAD value.

I think it is visibly faster to increase tr-value with single pass. Also if any prefiltering used - all th-values require re-adjustment. Because prefiltering typically make SAD values lower.

[kedautinh12]

Hi, i report that deep_resize had problem when downscale from 4k to 1080p
I tried with this script:
deep_resize(1920,edge="Zopti1080")
But in video, her hair is wrong color
My sample: https://youtu.be/49R_nMEW7X8

[Dogway]

Thanks, updated TransformsPack - Main with a fix and some cosmetics.

[LeXXuz]

Dogway I noticed some faint distortions in my encodes, barely noticeable.
So I played around with the preview mode a little and saw a lot of erroneous frames of the prefiltered clip. See pics below:

https://abload.de/thumb/2022-07-291tjjv3.png (https://abload.de/image.php?img=2022-07-291tjjv3.png)https://abload.de/thumb/2022-07-292b4kjm.png (https://abload.de/image.php?img=2022-07-292b4kjm.png)https://abload.de/thumb/2022-07-2931lknh.png (https://abload.de/image.php?img=2022-07-2931lknh.png)https://abload.de/thumb/2022-07-29452j8t.png (https://abload.de/image.php?img=2022-07-29452j8t.png)https://abload.de/thumb/2022-07-2958qk14.png (https://abload.de/image.php?img=2022-07-2958qk14.png)https://abload.de/thumb/2022-07-290uk5b.png (https://abload.de/image.php?img=2022-07-290uk5b.png)

EDIT: I turned off DGDenoise and the errors are gone. Tried with no prefilter (-1) and BM3DCUDA (6) with no errors.


Just a heads up regarding this issue. Sorry for the late reply.
It doesn't seem to be SMDegrain related. My old statement that DGDenoise() works fine is not valid. I get the very same errors when using DGDenoise() alone and denoising the chroma planes. With cstrength=0 the problem seems to be gone.

Will report this to DG. Maybe he can reproduce that error.

[Dogway]

@LeXXuz, thanks for reporting back. Just retested with ConvertBits(16).DGDenoise(cstrength=2) and I don't get the issue so as it looks it's driver/GPU related. I'm still on Win7 so I use the latest 400 branch driver version.

[ChaosKing]

I'm on the lastest driver win10x64 - 3070TI, no issues here.
Post your script.

[LeXXuz]

Problem is solved. And it was much simpler and stupider than expected. I downloaded a new mtmodes.avsi on that machine a few weeks back and some smart person thought it would be a good idea to set DGDenoise() as a NICE_FILTER. Well, you can guess the rest, I think. :rolleyes:

[tormento]

Could you please suggest me some good quality resizer to resample from 720p to 1080p (1.5x)?

Unfortunately Waifu2x accepts 1.5 only. Any workaround or better to use deepresize or nnedi3resize?

How to use them with nnedi3cl? What about the parameters? I always hope you find the time to write some documentation. :)

[Dogway]

ResizersPack was updated with NNEDI3CL by default, you can switch to nnedi3 cpu with gpuid=-1 (read dependencies)

Yes, deep_resize is the way to go for quality resizing (like nnedi3_resize16() was before), it mixes different kernels for edge/flat/chroma areas. By default it's set to optimal kernels (check examples) but you can play with other ones if you want FCBI, etc.
I haven't implemented waifu2 yet.

[tormento]

Yes, deep_resize is the way to go for quality resizing
Any hint for anime? As usual 1080p are 720p with bicubic. I inverted the process and now I want to rescale to proper resolution.
I haven't implemented waifu2 yet.
I have tried w2xncnnvk by Asd-g but, as I told, it supports only 2x.

[DTL]

With typical non-linear resamplers of 2x you make processibg in 2 steps - make 2x resize to closer upper size and downsize with second variable scale method to required output size.

[tormento]

With typical non-linear resamplers of 2x you make processibg in 2 steps - make 2x resize to closer upper size and downsize with second variable scale method to required output size.
Can you suggest me a good downsizer for anime (lineart)?

[Dogway]

I have tried w2xncnnvk by Asd-g but, as I told, it supports only 2x.

Then it's the same behavior than nnedi3, loop waifu2 until closest target dimensions then use alternative scaler to downscale or upscale. Didee bicubic coeffs are very good for small downscales.

[tormento]

@Dogway where can I find some explanation of the deep_resize parameters? Some are obscure to me, even reading the avsi.

[Dogway]

What do you need to know, it's pretty straight forward.

Read the comments for the settings. In any case everything is already tuned for best results by default depending on up/dw scaling and the ratio of it.

rth = Default(th_rat, 1.25) # threshold for mix mode. Lower than this (target_size/source_size) will use only 'kernel1' kernel
krn1 = Default(edge, rat<=rth*0.95 ? "Didee" : /* # Resize kernel for the edge area. AI upscalers recommended here: nnedi3, FSRCNN, FCBI, SuperResXBR... or for downscaling: DPID, SSIM2, Zopti */
\ rw<1 && rh<1 ? isUHD ? "Zopti1080" : "SSIM2" : /* # By default, for small upscales -> "blackman" (define *small* with 'th_rat' value) */
\ rat<=rth ? "Blackman" : "nnedi3") /* # By default, for big upscales -> "nnedi3"
# By default, for small downscales -> "Didée"
# By default, for big downscales -> "Zopti1080"
# By default, for mid downscales -> "SSIM2" (DPID also fine for down to 720p) (Beware!! for UHD to HD against all logic I recommend going with Zopti1080 (b=-0.99,c=0.06) ) */
krn1c = Default(chroma,rw<1 && rh<1 ? "Zopti" : "Blackman") # Chroma resizing kernel (no edge/flat discretion) *Remember you can directly call "kernel + taps". ie. Blackman6, Lanczos4
krn2 = Default(flat, rw<1 && rh<1 ? krn1 : isHD && isUHD2 ? "Sinc" : "Lanczos" ) # Resize kernel for the flat area (noop when downscaling). Ringing kernels are ok here (specially when up ratio is <1.7) like SincLin, Blackman, Lanczos, Sinc... ('Sinc' low taps -ie. 4- is worth testing, creates some faints halos specially for SD to HD so see whether it's faint enough for you)
etp = Default(e_taps, krn1 =="Blackman" ? 6 : krn1 =="Lanczos" ? 4 : 0) # taps for edge kernel (0 for undefined)
ftp = Default(f_taps, krn2 =="Blackman" ? 16 : krn2 =="Lanczos" ? 8 : 0) # taps for flat kernel (0 for undefined)
ctp = Default(c_taps, krn1c=="Blackman" ? 6 : krn1c=="Lanczos" ? 4 : 0) # taps for chroma kernel (0 for undefined)
thr = Default(th, 1.0) # 0-255 (normally up to 10)
ela = Default(elast, 4.0) # 1-255 (normally up to 10)
qual = Default(qual, 1)
sh = Default(show, false)
gpuid = Default(gpuid, 0) # Set to -1 for "cpu" nnedi3
dec = Default(deconv, 0) # 0~10 (0 is disabled, raise to apply deconvolution when upscaling a very sharpened downscale -anything sharper than Catmull-Rom-)
gr = Default(grain, rw>1 && rh>1 && rat>rth ? 0.6 : 0 ) # Grain strength. >0 Add grain to big upscales as a mean of cheap hallucination

[Boulder]

DGSource("test.dgi",ct=44,cb=44,cl=0,cr=0)
a=deep_resize(1920, 1040)
interleave(bicubicresize(1920, 1040, b=-0.5, c=0.25).propshow, a.propshow)


I was testing deep_resize with this simple script on a regular UHD (HDR) source, and I noticed that the colors of the deep_resize version are a bit warmer than in the source. Also the chroma location property seems to go missing.

[Dogway]

Yes, the chroma loc property was already fixed internally yesterday, and about the warmer tones I don't get them, but as I said I made some changes and fixes to TransformsPack, will release tomorrow probably.

[tormento]

about the warmer tones I don't get them
Dunno if related but have a look in the fmtc thread.

Seems planes and spaces sometimes don't mix well. :p

[Dogway]

fmtc hard codes 32-bit to full range so it's going to confuse you a little bit.
I have been refactoring a few things in ConvertFormat() to make it more robust, fixed quite a bit. With luck the next version after this one will finally be v1.0.
Also added waifu2xresize() a wrapper for w2xncnnvk. Quality is very good as expected, sharper than nnedi3 but very slow (~1fps on my card)

[tormento]

fmtc hard codes 32-bit to full range so it's going to confuse you a little bit.
I "solved" the issue from 32 bits to lower, with some obscure Converbits(32) switches. Now it's the planar to YUV that's bugging me.

[tormento]

Also added waifu2xresize()
Crawling here too.

In the mean time, people, which one (https://imgsli.com/MTIyMDQw) do you prefer?

The title of the image says it all. (i.e. downsample to 720p, waifu2x to 1440p and then downsample again to 1080p.

[DTL]

" people, which one do you prefer?"

It is better to compare scaling in real movie running. Because if you going to have as sharp as possible image also using non-linear processing inbetween it it easy to fall into gibbs/aliasing issues so it may be not (clearly) visible at static frame but start to show moire at textures or flickering at small objects at movie frames running.

The 'sharpest/detailed possible' non-linear upscaler for static images may be not best for moving images. Moving-images non-linear upscaler need to reconstruct the object's shape and preform new moving_pictures_camera_AA processing for moving images to be safe from gibbs/aliasing. It is much less important for static images upscalers.

So some 'reference' or 'enough fail-safe' non-linear upscaling is sort of

MyLovelyNonLinearUpscaler(width*16, height*16) (for power-2 upscalers)
UserDefined2ResizeMT(output_width, output_height, b=__, c=__), where output_width is about input_width*2 (so ratio of NLUp/downscale is about 5 or more, 10 may be close to ideal limit) and b,c depend on 'image makeup type video/film' required.

The physical idea of processing:
1. MyLovelyNonLinearUpscaler(width*16, height*16) - create virtually infinite resolution image dataset as free of aliasing as possible and as detailed as possible (really the upscale factor depends on 'Luma range', so for HDR best value may be much more 10).
2. UserDefined2ResizeMT(target_width, target_height,makeup_params) - condition input infinite resolution image dataset to target resolution with adjustment of 'makeup/look' (acts as virtual moving pictures first transform camera) and protection from aliasing/gibbs. Also may convert low precision (8bit) to high presicion (8+bit) data to decrease banding or other defects. 1+2 is real 'digital image data mining process' - require lots of computing power :) .

The single frame intermediate datapath from 1 to 2 may be very RAM-non-friendly - so better solution is using sliced-processing of a small pieces or frame. Or some moving-picture data 'conditioner' need to be integrated in the NL_upscaler engine so user may download ready to use frame with target resolution from accelerator.

[Dogway]

Crawling here too.

In the mean time, people, which one (https://imgsli.com/MTIyMDQw) do you prefer?

The title of the image says it all. (i.e. downsample to 720p, waifu2x to 1440p and then downsample again to 1080p.

08 looks best to me. What DTL said is right, maybe you can get away with waifu for anime (using model=0) but for live action there are better upscalers like basicvsrpp or PP-MSVSR.

I thought on adding a limiter to give more temporal coherence, I think I will add it as default when model!=0 is used. Something like Soothe() or so.

[tormento]

you can get away with waifu for anime
I wish I had a brand new 4090 TI for free.

On my 1660 SUPER, I get 1 fps BEFORE encoding. :(

[Dogway]

In any case I mostly only use waifu for vector art, logos, etc. For real anime there are much better models in ESRGAN. I don't know how fast that is in VS.

The good news is that waifu2x with model=1 already blows NGU out of the water.

EDIT: By the way, w2xncnnvk() has a bug which causes a green tint when matrixed back to YUV

[tormento]

I don't know how fast that is in VS.
Is there for AVS+?

[Reel.Deel]

Is there for AVS+?

Nope. Although the ncnn-vulkan version is not available in VapourSynth, at least there is some hope: https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan

It uses the same framework as rife-ncnn-vulkan and waifu2x-ncnn-vulkan.

[tormento]

Nope. Although the ncnn-vulkan version is not available in VapourSynth
So what program is Dogway talking about?

[StvG]

EDIT: By the way, w2xncnnvk() has a bug which causes a green tint when matrixed back to YUV

Did you try with clamped w2xncnnvk output within [0,1]?

[Dogway]

So what program is Dogway talking about?
vs-realesrgan, I think you already use it?

Did you try with clamped w2xncnnvk output within [0,1]?
I tried that and several settings. I think it has to do with discrepancies in RGB to YUV conversion as I get the same one (ConvertFormat) compared to fmtconv or avsresize, but mines does a roundtrip and I think it has to do with the coeff derivations. I don't know if waifu does a YUV conversion internally but it looks so (or modelled after a conversion), the problem for whatever that is is it doesn't roundtrip.

EDIT: Updated TransformsPack

[tormento]

vs-realesrgan, I think you already use it
I tried but I don't find VS "friendly". I can't get proper control over threads and I keep on saturating my computer and graphic memory.

P.S: Do you have some fmtc laying around in your scripts? I think you saw the thread about tint changing. How are your conversion function speeds and can they be competitive to fmtc?

[Boulder]

EDIT: Updated TransformsPack

Looks like the color issue I observed is fixed :)

[Dogway]

Looks like the color issue I observed is fixed :)
Thanks for report!

I tried but I don't find VS "friendly". I can't get proper control over threads and I keep on saturating my computer and graphic memory.

P.S: Do you have some fmtc laying around in your scripts? I think you saw the thread about tint changing. How are your conversion function speeds and can they be competitive to fmtc?

Yeah, I find Python too verbose, like writting a letter, I want to type and read less while doing more. More expressive languages. Too bad I want to make Android apps.

What thread is that? I don't make use of fmtconv to minimize on dependencies, I just tested and performance seems on par for a YUV to RGB conversion. I think ConvertFormat() benefits when you add more things into the mix like upscaling, etc but cretindesalpes is making Convert() so maybe that can make things faster (and more user friendly).
TransformsPack is my personal notebook, it has a very different approach like color models, color matching functions, different tristimulus matrices, derived coefficients... It's not perfect but helps me to learn about it and code better (hopefully).

[tormento]

What thread is that?
CPU and GPU threads ;)

[DTL]

One of practical usage of neural-networks 2x upscalers may be higher quality RAW debayer. Nowdays some enduser hardware can write RAW bayer stream (like some smartphones cameras setups) and require debayer before starting of 'standard' processing.
So for debayer the grey/bayer-RAW input may be separated into RGB low-sized planes, 2x upscaled and combined to full-size standard 4:4:4 RGB format.

[Dogway]

CPU and GPU threads ;)

You said "thread about tint changing".

One of practical usage of neural-networks 2x upscalers may be higher quality RAW debayer. Nowdays some enduser hardware can write RAW bayer stream (like some smartphones cameras setups) and require debayer before starting of 'standard' processing.
So for debayer the grey/bayer-RAW input may be separated into RGB low-sized planes, 2x upscaled and combined to full-size standard 4:4:4 RGB format.

I read about it last week on this paper (https://www.eecs.yorku.ca/~mbrown/ICCV19_Tutorial_MSBrown.pdf#page=226). In page 128 there's a simple "edge aware" algo for demosaicing. But it's also being considered for gray world (auto white balance), as it's one of the harder tasks for cameras.

I personally would like it used for color science: gamut mapping, CMFs, etc

[tormento]

You said "thread about tint changing".
That was the fmtc one.

[tormento]

Ok, I did some tests with an anime (Knights of Sidonia) with both deep_resize and w2xncnnvk.

The second, while giving better results, is really too slow (~1.5 fps on a 1660 SUPER) to be feasible. And I would have to encode it too.

So I had to play with deep_resize only.

The script I did is like

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 3)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\Knights of Sidonia\Knights 01A.dgi")
ConvertBits(32)
DeBicubicResizeMT(target_width=1280,target_height=720,threads=1)
BM3D_CUDA(sigma=3, radius=2)
BM3D_VAggregate(radius=2)
deep_resize(1920,flat="nnedi3",grain=0,qual=2)
fmtc_bitdepth (bits=10,dmode=8, fulld=true)
neo_f3kdb(range=15, Y=65, Cb=40, Cr=40, grainY=0, grainC=0, sample_mode=2, blur_first=true, dynamic_grain=false, mt=false, keep_tv_range=true)
Prefetch(4)

but I am not getting impressive results on aliased lines.

Need some help. If you want to try, I put a small untouched clip here (https://krakenfiles.com/view/fJTGN2gqEw/file.html).

[Dogway]

For some reason I'm not liking w2xncnnvk here, on model=0, but also tested the other models. It creates jaggies, and some lineart thinning. It also accentuates ringing.

I find nnedi3 more pleasant, yes it's on the soft side so I played a bit with sharpening and result is rather good.

While at it I spotted two issues, one bug on Soothe() for 32-bit, and another one in LSFplus() for Lmode=2 at 32-bit (actually ex_edge() in 32-bit). Will upload the fixes (done already) today along a new argument (sharpness) for deep_resize() and nnedi3resize().

EDIT: oh I forgot to say, I don't get jaggies at all after nnedi3. But your debicubic is too strong, not sure if you measured the upscaling correctly. Are you aware of VapourSynth GetNative()? If there's no similar one in AVS+ I might give a chance at it, I won't port it, just create my own version following what I did for OOTF() last week.

[tormento]

deep_resize() and nnedi3resize()
What is the difference between the two?[/QUOTE]
EDIT: oh I forgot to say, I don't get jaggies at all after nnedi3
Please post your script.
not sure if you measured the upscaling correctly
I did use GetNative:

Bicubic b 0.33 c 0.33 AR: 1.78 Steps: 1
Native resolution(s) (best guess): 720p

Isn't my debicubic correct? What should I use?

You can try on the same mkv I posted in my previous message.

[Dogway]

nnedi3resize() is a nnedi3 all around upscaler, as simple as that.
deep_resize() is a power user oriented high quality scaler (up and down), with appropriate defaults, and post-processing options (grain, sharpening, deconvolution)

My script is the same as yours. I haven't tested GetNative because I don't use VS, was just wondering, but I will create an AVS+ version. I don't promise ultra performance (GetNative claims 13s).

EDIT: I updated ResizersPack.

The correct use in this case with edge=flat="nnedi3" is to use nnedi3resize, because the sharpening is performed in (usually) super sampling mode.

So something like:
nnedi3resize(1920,qual=2,sharpness=30)

[tormento]

My script is the same as yours.
But you wrote
I don't get jaggies at all after nnedi3. But your debicubic is too strong
So... if the same script how can I have different results? ;)
So something like
Thanks!

P.S: I can't really find any difference between quality 1 and 2. What are those values supposed to do?

[Boulder]

Dogway, I strongly suggest considering some other kernel than SSIM2 for downscaling, at least in 1080p -> 720p it causes considerable changes in the image colors near edges. Probably due to local contrast being changed? I've been using Zopti720 which sharpens the image slightly but doesn't have other issues, or at least they are not so apparent.

[Dogway]

Dogway, I strongly suggest considering some other kernel than SSIM2 for downscaling, at least in 1080p -> 720p it causes considerable changes in the image colors near edges. Probably due to local contrast being changed? I've been using Zopti720 which sharpens the image slightly but doesn't have other issues, or at least they are not so apparent.

I did a comparison and while Zopti720 is sharper it also creates some aliasing compared to SSIM2.
Using ex_makediff(metrics="All") SSIM2 showed better scores for all metrics compared to Zopti720.
Analyzing the diff map you can pin point such aliasing issues.
A good alternative I think would be to run SSIM2 for edges and Zopti720 for flat.

deep_resize(1280, edge="SSIM2", flat="Zopti720")

I didn't spot any change in color near borders, can you show an example?

[Boulder]

I did a comparison and while Zopti720 is sharper it also creates some aliasing compared to SSIM2.
Using ex_makediff(metrics="All") SSIM2 showed better scores for all metrics compared to Zopti720.
Analyzing the diff map you can pin point such aliasing issues.
A good alternative I think would be to run SSIM2 for edges and Zopti720 for flat.

deep_resize(1280, edge="SSIM2", flat="Zopti720")

I didn't spot any change in color near borders, can you show an example?
This is a good sample clip for the issue, see the computer panel in the background.

https://drive.google.com/file/d/1U2LcJlQ1bN19uDYnBsfI4YoPIYJS9X--/view?usp=sharing

I tested using those different kernels and it seems to work fine with this clip so it probably is safe to adjust things like that. Is it possible to see visually which parts are marked as edge and flat?

[Dogway]

This is the diff map with no augmentation (augment didn't show anything relevant either).
https://i.imgur.com/I1eRPSJl.png (https://i.imgur.com/I1eRPSJ.png)

It actually isn't an edge mask as it uses the nnedi3_resize16() original method of limitdif "masking". This is faster as it processes the whole thing in one call.
I could have implemented a one call mask+merge limiter as well but wanted to keep the rationale as in nnedi3_resize16() and the elast and thr args.
The internal mask actually is "filtered - original", typically you will get more differences around edges so it will naturally create an edge mask tailored with the elast and thr values.
I can try to implement a show mask arg to ex_limitdif().

[tormento]

I own both the BD and the UHD version of Akira movie.

I am using it to make some tests with LUTs and tone mapping, as the BD version is too saturated and I'd like to recover a nicer SDR version from the UHD.

I have some problems with the luma level after PQ to SDR conversion, i.e. luminosity is a bit low, even in its higher value.

This is the original SDR:

https://i.lensdump.com/i/194vVF.md.png (https://lensdump.com/i/194vVF)

This is the converted SDR (Akira PQ to SDR 26nit grey - gamma 2.40):

https://i1.lensdump.com/i/194MG0.md.png (https://lensdump.com/i/194MG0)

I'd like to "expand" the luminosity thru the usueful range (limited, of course) seeing that there is a nice clipped part to use as reference.

Expand because I'd like to leave the black where it is and fill just the upper part.

Should I touch a bit some color level too?

[Dogway]

I'm not and expert on HDR, but can't you define another master level so diffuse white saturates SDR range?

If for any reason you want to post-fix it, simply use ex_levels(), something like ex_levels(0,1,200,0,255).
Check if chroma is also compressed and adjust saturation according (watch out out-of-gamut with GamutWarning() )

[tormento]

can't you define another master level so diffuse white saturates SDR range?
Applying a LUT allows no additional tuning.

You can apply a different one and I am using the brighter one already.

Is there any "interpolation" used in ex_levels or is it a very basic correction?

[Dogway]

It's a basic linear scaling. You can also take the measured white point and divide 255 with it to get the multiplier (full scale)

255/200 = 1.275 -> "x 1.275 *" # in case source was PC range, otherwise use ex_levels()

Do you have MaxCLL and maxFALL info? Maybe I can try with EOTFi_2084(), you can also try with avsresize and fmtconv.
Usually for HDR I run a measurement with madMeasureHDR so one can get more accurate values.

[tormento]

Do you have MaxCLL and maxFALL info?
The original PQ stream has the following characteristics:

ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 2 h 4 min
Bit rate : 95.3 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.479
Stream size : 82.9 GiB
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primar : BT.2020
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Le : 369 cd/m2
format_identifier : HDMV
Source : 00003.m2ts
Maybe I can try with EOTFi_2084(), you can also try with avsresize and fmtconv.
How?
Usually for HDR I run a measurement with madMeasureHDR so one can get more accurate values.
Never heard of that, thanks. I will give it a try.
It's a basic linear scaling.
How to behave, instead, when we have a HLG or PQ, i.e. hybrid log or full log? I don't think that is linear anymore.

[Dogway]

Sorry I have been having a look at transfers, see, looks like my EOTFi_2084() functions might need some work but I just created the method C tonemapper from BT.2446. By default works better than fmtconv mapping (less blown outs).

You can try the next (play with lws and lwd params). EDIT: Those params don't seem to be doing anything, might be reported to cretindesalpes'

ConvertBits(32)
fmtc_resample (css="444")
fmtc_matrix (mats="2020", matd="rgb")
fmtc_transfer (transs="PQ",transd="linear",lws=1000,lwd=100)
TM_2446C(cs_in="2020",cs_out="709",EOTFi="1886")


Here is TM_2446C (will update soon in TransformsPack):
# BT.2446 Method C tonemapper
# Input must be HDR linear RGB, output is full range SDR gamma RGB (EOTFi gamma encoded)
function TM_2446C (clip c, string "cs_in", string "cs_out", string "EOTFi", float "k1", float "k3", bool "show") {
c
isy = isy(c)
fs = propNumElements("_ColorRange") > 0 ? \
propGetInt ("_ColorRange") == 0 : true
props = color_propGet(c)
cs_in = Default (cs_in, props[2])
cs_out = Default (cs_out, "709")
EOTF = Default (EOTFi, "1886")
k1 = Default (k1, 1) # SDR white level to HDR reference white (diffuse white) ratio. Details on BT.2408 Annex 4
k3 = Default (k3, 0.52) # How much birght detail you want to keep in

cs_out = color_Fuzzy_Search (cs_out)[0]
EOTF = color_Fuzzy_Search (EOTF)[2]

# De-saturation coefficient to avoid hue shifts
a = 0.04 # Should be between 0.01 and 0.33
Cross= [ 1-2*a, a, a, \
a, 1-2*a, a, \
a, a, 1-2*a]

c
if (!isy) {
MatrixClip(Cross)
RGB_to_XYZ(cs_in)
XYZ_to_Yxy()
}

k1 = k1
ip = 58.5 / k1 / 100. # Inflection point of the tonemapper, usually just above skin tones (80% SDR which maps to 58.5 nits over 100 nits SDR display)
ipr = 1. / ip
k3 = k3
k2 = k1 * (1 - k3) * ip
k4 = k1 * ip - k2 * log(1 - k3)

# From BT.2446-0 Section 5 (Method C)
ex_lut(Format("x {ip} < x {k1} * x {ipr} * {k3} - log {k2} * {k4} + ?"),UV=1)

if (!isy) {
Yxy_to_XYZ()
XYZ_to_RGB(cs_out)
MatrixClip(MatrixInvert(Cross))
}

s_gam = moncurve_coef(EOTF)
moncurve_r(s_gam[0],s_gam[1], false, false)

if (sh) {
w = c.width()
h = c.height()
sw = nmod(w/5.) sh = min(h,sw)
plt = GradientLinear(last,zoom=1, precision=4, positive=true, smooth=true, tv_range=false)
plt = plt.ExtractY().TM_2446C(k1=k1,k3=k3,EOTFi=EOTF)
plt = HistoCurve(plt,size=2,gradient=false).BicubicResize(sw,sh,0.262015,0.368993)
plt = plt.ConvertToPlanarRGB()
plt = Merge(PadBorders(plt,w-sw,0,0,h-sh))
ex_merge(plt,BoxMask(w-sw,w,0,sh),UV=3)
} }


You might also need to update XYZ_to_Yxy() to avoid NaN:
function XYZ_to_Yxy (clip XYZ, clip "Y", clip "Z", bool "fulls") {

isy = isy(XYZ)
bi = BitsPerComponent(XYZ)
fs = Default (fulls, true)

clp = !isy ? ExtractClip(XYZ) : nop()
X = !isy ? clp[0] : XYZ
Y = !isy ? clp[1] : Y
Z = !isy ? clp[2] : Z


if (isy) {

xl = Expr(X, Y, Z, "x 0 <= 0.3805 x dup y z + + / ?", optSingleMode=false)
yl = Expr(X, Y, Z, "y 0 <= 0.3769 y dup x z + + / ?", optSingleMode=false)
[Y, xl, yl]

} else {

Expr(X, Y, Z, "y", "x 0 <= 0.3805 x dup y z + + / ?",\
"y 0 <= 0.3769 y dup x z + + / ?", optSingleMode=true, format=PixelType(XYZ)) } }

[tormento]

Sorry I have been having a look at transfers
Thanks for your work. ;)

But how would that help me to expand luma range after that I already used a cube to SDR or HLG? :)

[Dogway]

For a post-fix just use ex_levels(), I don't know how it behaves with HLG though, I haven't worked much with HDR.


If for any reason you want to post-fix it, simply use ex_levels(), something like ex_levels(0,1,200,0,255).)

[guest]

Hey guy's,

This is probably a bit off topic, but I need to be able to add an audio delay call to my video scripts.

LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\MedianBlur2\MedianBlur2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=8,thSAD=800,thSADC=400,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=2,str=1.2,refinemotion=true)
DelayAudio(1)

This doesn't work :(

[Dogway]

You need to load the audio first, use ffaudiosource() or other loader.
You can then "merge" video and audio streams and filter both in-line
AudioDub(video, audio).DelayAudio(1)

Try open a thread next time if it's not related to my filters.

[tormento]

know how it behaves with HLG though, I haven't worked much with HDR.
Perhaps it's time to. :p

[Dogway]

It's important but other things more important first like gamut compression which actually there's not a single solution in AviSynth (nor VS I think). I'm also implementing new things yet to be seen elsewhere like full ACES implementation and OpenDRT, to name a few yet to come.

As I said HDR is a target for TransformsPack 2.0, I'm not even in 1.0 yet and still there are some important additions like 2084 EOTF, some HDR models, the 2446 TM. I've been busy making GetNative in AVS+ and other things, color science is a field in construction, a moving target.

[tormento]

I've been busy making GetNative in AVS+ and other things, color science is a field in construction, a moving target.
And we are so thankful for your work. :)

[kedautinh12]

I meet error with ex_bob(nnedi3=true) when deinterlaced video, Screenchange repeat

my sample: https://drive.google.com/file/d/1TqPZyX0HfjdTCO3PNyhslgYxV87C4EUI/view?usp=sharing

[Dogway]

Do you get any error? It works fine here, schene change and all. Try other clip to check it's an issue with the source.

[kedautinh12]

Do you get any error? It works fine here, schene change and all. Try other clip to check it's an issue with the source.

i seen it's repeat in screenchange. Please check from frame 2992

My scripts:
LWLibavVideoSource("C:\Users\ADMIN\Downloads\Lie - No Sleeves.mpg")
ex_bob(nnedi3=true)

[Dogway]

That's LWLibavVideoSource not setting field parity switch correctly to frame props. Use DGSource and works fine (ex_bob() honors frame props over GetParity() )

[kedautinh12]

That's LWLibavVideoSource not setting field parity switch correctly to frame props. Use DGSource and works fine (ex_bob() honors frame props over GetParity() )

Ok, so i will use tfm with L-Smash:D

[guest]

You need to load the audio first, use ffaudiosource() or other loader.
You can then "merge" video and audio streams and filter both in-line
AudioDub(video, audio).DelayAudio(1)

Try open a thread next time if it's not related to my filters.

Hi Dogway, I wasn't sure where to post a question like this, but I think why I did is that the DelayAudio(1) works with this script :-

Loadplugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
video=MDegrain1(video,super,bv1,fv1,thSAD=400)
when adding these lines:-

#Return
DelayAudio(1)

or

#AVSameLength
DelayAudio(1)

but not with this one :-

LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\MedianBlur2\MedianBlur2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=8,thSAD=800,thSADC=400,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=2,str=1.2,refinemotion=true)

Keep in mind that these are scripts used by RipBot264...so they're a little different.

I do have a couple of "work around" options, but it would be nice to know why it works with one & not the other.

[LeXXuz]

Well, here is something I'm really scratching my head on.

I'm still struggling with a bluring effect with SMDegrain in moving areas which really disturbs the overall look of the picture.
To elaborate: I've uploaded four samples of a short scene. Original, 2x denoised with SMDegrain (thSAD 400 and 200) and denoised with DFTtestMC.

Here are comparison screenshots in exactly that order:
https://abload.de/thumb/test_orgslebc.png (https://abload.de/image.php?img=test_orgslebc.png)https://abload.de/thumb/test_enc_thsad4003peom.png (https://abload.de/image.php?img=test_enc_thsad4003peom.png)https://abload.de/thumb/test_enc_thsad2008udrz.png (https://abload.de/image.php?img=test_enc_thsad2008udrz.png)https://abload.de/thumb/test_enc_dftmc6eie2.png (https://abload.de/image.php?img=test_enc_dftmc6eie2.png)

And here are the short clips those screenshots are taken from:
Original: https://send.cm/d/EYfK
SMD-400: https://send.cm/d/EYfN
SMD-200: https://send.cm/d/EYfP
DFTmc: https://send.cm/d/EYfT

Notice how blury/smooth the faces of the actors become as soon as they move their heads.
And how crisp and detailed they become again once they hold still.
Compared to dfttest (and the original of course), the effect is pretty strong with SMDDegrain, even with a quite low thSAD of 200
which does not denoise the movie properly anymore as it's too weak. But that blur still remains.

I tested different prefilters, played around with the gamma ramp with different settings for ex_luma_rebuild() and even ex_retinex(),
increased accuracy with blocksize and pel, increased temporal radius up to 24 (which btw doesn't do really much else than just killing speed). Nothing seems to help.

To outrule anything else I dumbed down both scripts to the simplest content:

AVS Script used with SMDegrain:

#
SetMemoryMax(32768)
SetCacheMode(0)
#
LoadPlugin("...\MeGUI (x64)\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("...\test_org.mkv")
#crop
#resize
#
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\masktools2-v2.2.30\x64\masktools2.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\mvtools-2.7.45\x64\mvtools2.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\RgTools-v1.2\x64_LLVM_build\RgTools.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\vinverse-0.9.3\x64\Release\vinverse.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\vsTCanny-1.1.8\x64\Release\vsTCanny.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\BM3DCUDA_AVS-test9\x64\BM3D_VAggregate_AVS.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\BM3DCUDA_AVS-test9\x64\BM3DCPU_AVS.dll")
LoadPlugin("...\MeGUI (x64)\tools\avisynth_plugin\BM3DCUDA_AVS-test9\x64\BM3DCUDA_AVS.dll")
#
Import("...\MeGUI (x64)\tools\avisynth_plugin\ResizersPack.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\ExTools.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\SharpenersPack.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\GradePack.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\TransformsPack - Main.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\TransformsPack - Models.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\TransformsPack - Transfers.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\SMDegrain.avsi")
Import("...\MeGUI (x64)\tools\avisynth_plugin\mtmodes.avsi")
#
ConvertBits(16)
SMDegrain(tr=6, thSAD=400, contrasharp=false, LFR=false, DCTFlicker=false, refinemotion=true, truemotion=false, blksize=16, pel=2, Str=5.0, Amp=0.03, prefilter=6, chroma=true, plane=4)
Prefetch(32,32)
Return(Last)


AVS Script used with DFTtestMC from real.finder:

#
SetMemoryMax(32768)
SetCacheMode(1)
#
LoadPlugin("...\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("...\test_org.mkv")
#
LoadPlugin("...\tools\avisynth_plugin\neo-dfttest_rf-fix\64\neo-dfttest.dll")
LoadPlugin("...\tools\avisynth_plugin\masktools2-v2.2.30\x64\masktools2.dll")
LoadPlugin("...\tools\avisynth_plugin\mvtools-2.7.45\x64\mvtools2.dll")
LoadPlugin("...\tools\avisynth_plugin\RgTools-v1.2\x64_LLVM_build\RgTools.dll")
#
Import("...\tools\avisynth_plugin\dfttestMC_and_MC_things.avsi")
Import("...\tools\avisynth_plugin\Zs_RF_Shared.avsi")
Import("...\tools\avisynth_plugin\mtmodes.avsi")
#
ConvertBits(16)
dfttestMC(Y=true, U=true, V=true, thSAD=400, MCContrasharp=false, rStr=1.0, MC=5, sstring="0.0:4 0.5:9 1.0:16")
Prefetch(32,32)
Return(Last)


I may have misunderstood the entire concept of mc denoising,
but (beside better noise removal on moving objects) - shouldn't a motion compensated denoiser prevent exactly this from happening?

[Boulder]

Have you tried pel=4, or blksize=32 (or both)? Could be related to motion detection, and your settings make it average 6 frames so it will get blurry if ME is not good.

[LeXXuz]

Have you tried pel=4, or blksize=32 (or both)? Could be related to motion detection, and your settings make it average 6 frames so it will get blurry if ME is not good.

Tried all block- and pixel sizes. Isnt it temporal radius not diameter? Anyway, like I wrote even very high tr doesn't change anything. If in doubt, try the source material yourself. ;)

[Boulder]

Temporal radius, yes - which means it will average (weighted averaging) blocks over 6 frames. So lowering that might be better, but it will do less denoising.

[DTL]

I may have misunderstood the entire concept of mc denoising,
but (beside better noise removal on moving objects) - shouldn't a motion compensated denoiser prevent exactly this from happening?

It may be limitations of 'simple' degrain script based on old mvtools.

Attempt to keep more skin details on moving face require very low thSAD of about 80. But to keep removing noise on other areas it is require to apply different MDegrain settings to different frame areas. So with old mvtools it may exist in other more complex degrain scripts with masked processing of moving and static areas with different MDegrain settings.

It looks the motion tracking is not very good on rotating head (it is really other transform not supported by mvtools at all and partially working on some simple projections of rotating subject by translate-only support in mvtools). Also it may be even worse with prefiltering washing out last low-contrast details to work on by motion search engine.

With more new version of mvtools (03.08.22 build - https://github.com/DTL2020/mvtools/releases/tag/r.2.7.46-a.15 )

and some tweaking of 'base very low thSAD' with additional adjustments with total mvtools degrain part of script

tr=6
super=MSuper(mt=false, chroma=true, pel=2)
multi_vec=MAnalyse (super, multi=true, blksize=8, delta=tr, overlap=0, search=3, searchparam=2, chroma=true, optSearchOption=1, mt=false)
MDegrainN(last,super, multi_vec, tr, thSAD=80, thSAD2=70, mt=false, wpow=4, thSCD1=400, adjSADzeromv=0.4, adjSADcohmv=0.7, thCohMV=2, MVLPFGauss=1.1, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=3)


result keeps better skin details

https://drive.google.com/file/d/1JQ5pR0rKcb6jjdo5jt2x2ukscXFuHP9W/view?usp=sharing

while still provide some help to MPEG 264 encoder (crf=18 degrained version 7.1Mbit/s, source not degrained 9.6Mbit/s).

It have many new params to play with but it may be completely not degraining for other scenes of the complete movie (like using higher ISO speed film or higher gain camera setting and others). So it is only params adjusted per current scene.

Also if it is natural movie with long enough frame exposure time the textures of moving subjects are also more or less damaged by motion blur. So keeping best possible details on moving subjects typically not possible because cinema shooters not like very small shutter speeds - it uses very few light from scene (require very powerful lighting) and also may create very visible jitter (on non smooth-motion displays).

"I tested different prefilters, played around with the gamma ramp with different settings for ex_luma_rebuild() and even ex_retinex(),
increased accuracy with blocksize and pel, increased temporal radius up to 24 (which btw doesn't do really much else than just killing speed). Nothing seems to help."

First to save from blurring you need to have one of 2 things:
1. Perfect motion compensation
or
2. Protection from too bad blending (using thSAD or any other ways like masking or other).

1. Is far from possible with current mvtools with translate motion estimation and compensation only but even translate not tracked perfectly with real not very contrast and detailed sources and damaged by random noise.
So first is good to adjust motion search as best as possible for given source. As I see at the rotating head of the left male talent the motion is tracked about good only on low-left part of face and much worse at the upper part of face (above eyes). To see the result of motion search and to make adjustments to MAnalayse the MShow can be used. So I make test script for MAnalyse tuning -


LoadPlugin("ffms2.dll")
LoadPlugin("mvtools2-pint.dll")
#LoadPlugin("mvtools2.dll")

FFMpegSource2("test_org.mkv")

ConvertToYV24()

prefilt=GeneralConvolution(0, "
-0 -0 -1 -0 -0
-0 -1 -2 -1 -0
-1 -2 17 -2 -1
-0 -1 -2 -1 -0
-0 -0 -1 -0 -0", auto=true, luma=true, chroma=true)

#prefilt=Blur(1)
#prefilt=last

super = MSuper(prefilt, mt=false, pel=2)
super_std = MSuper(mt=false, pel=2, hpad=32, vpad=32)
forward_vec1 = MAnalyse(super, blksize=8, isb = false, search=3, temporal=false, trymany=false, searchparam=2, chroma=true, delta = 1, truemotion=false, pzero=0, pnew=0, levels=2, mt=false)
MShow(super_std,forward_vec1, showsad=true, thSCD1=1000, scale=2)

I set penalties to zero so EXA search can test all possible locations for best SAD value without skipping low SAD enchancements. The temporal and trymany are subject to more testing. Also limit levels to 2 to try to avoid too far bad MVs.

It tests 3 different pre-processing modes to try to help to MAnalyse: low-pass (blur) prefiltering, no-prefiltering, and high-pass (sharp) prefiltering (using GeneralConvolution because Blur(-arg) adjusts mostly too high frequencies).
The results for medium head-rotation frame 37 are
https://ibb.co/hKsTLPR - blur prefilter
https://ibb.co/cQWK6Hz - no prefilter
https://ibb.co/gz1fzL1 - sharp prefilter (also greatly increase median SAD)
The sharp prefiltering looks like a bit better - at least it saves from gross error vertical MVs on horizontally rotated head at some blocks (near lips for example).

It may be good to see the MVs after temporal low-pass filtering to better understand real processing data inside new MDegrainN with MVLPF additional processing but to view with MShow it require to do either some script to process MStoreVect data or separated new filter for mvtools with output of processed MVs in compatible with MShow format.

So tried more encoding using 'sharp' prefiltering with

LoadPlugin("mvtools2.dll")
LoadPlugin("ffms2.dll")

FFmpegSource2("test_org.mkv")

ConvertToYUV420(matrix="Rec709")

prefilt=ConvertToYV24().GeneralConvolution(0, "
-0 -0 -1 -0 -0
-0 -1 -2 -1 -0
-1 -2 17 -2 -1
-0 -1 -2 -1 -0
-0 -0 -1 -0 -0", auto=true, luma=true, chroma=true).ConvertToYV12()

super = MSuper(prefilt, mt=false, pel=2)
super_std = MSuper(mt=false, pel=2)

tr=12

multi_vec=MAnalyse(super, blksize=8, multi=true, search=3, temporal=false, trymany=false, searchparam=2, chroma=true, delta = tr, truemotion=false, pzero=0, pnew=0, levels=2, mt=false, overlap=4)
MDegrainN(last,super_std, multi_vec, tr, thSAD=90, thSAD2=80, mt=false, wpow=4, thSCD1=500, adjSADzeromv=0.4, adjSADcohmv=0.7, thCohMV=2, MVLPFGauss=1.1, thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=0)


The interpolated overlap of mode 3 fails at some frame with grid structure - so I set full 4x 'classic' overlap - it uses more real searched MVs and possibly better in quality.
thSAD (and all other absolute th-s like thSAD2 and thSCD*) depends on prefiltering so not compatible with previous encoding and need to be re-adjusted for each prefiltering type/settings.
https://drive.google.com/file/d/12iBU3QtnJ6TuhtLb3UYnPUwXk-d1rUUS/view?usp=sharing
The x264 with crf18 also looks eats some details from skin texture - the frame number 37 looks better at script output - https://ibb.co/Jn9sxmM

The DFTtestMC looks uses too high denoise settings so degrade skin textures more.
Also you can apply some sharpening plugin (non-linear for fine details) to make residual texture details after degraining better visible.

[LeXXuz]

Temporal radius, yes - which means it will average (weighted averaging) blocks over 6 frames. So lowering that might be better, but it will do less denoising.

If that is true then the term radius is very misleading, if not wrong. A radius of n should process (2n+1) frames not just n. At least thats what my mathematical understanding tells me.

I did so many tests over the past 2 years, I can say for certain that any tr value above 6 rarely gives better results in forms of better denoising and smaller output. I've compared countless sources with a tr value of 6,12 and 18 and the difference in filesize of the entire encode was always less than 5%, very often even less than 1% whereas the encoding time more than doubled. I was not able to see real differences in a direct comparison of 2 1080p windows on a calibrated 40" UHD screen standing less than 1m before me on my desk. Pointless and a waste of energy imho.

[Boulder]

If that is true then the term radius is very misleading, if not wrong. A radius of n should process (2n+1) frames not just n. At least thats what my mathematical understanding tells me.

I did so many tests over the past 2 years, I can say for certain that any tr value above 6 rarely gives better results in forms of better denoising and smaller output. I've compared countless sources with a tr value of 6,12 and 18 and the difference in filesize of the entire encode was always less than 5%, very often even less than 1% whereas the encoding time more than doubled. Pointless and a waste of energy imho.

Yes, my small mistake of not writing "forward and backward". The effect probably diminishes close to zero due to the weighing with blocks from nearby frames contributing much more than the ones which are several frames away. I always use radius 1 with MDegrain, but then again, I only tend to press the noise or grain down a bit and not remove it.

[DTL]

"radius of n should process (2n+1) frames not just n. "

Yes - tr=6 mean it uses 12 ref frames for current frame. So it is radius symmetrical around current frame (for realtime denoisers with very small delay it may be non-symmetrical). So at the scene change it have drop of number of usable frames to n/2 and drop of denoising effect. Same is before scene change at the frames scene_change_number-n. Some people see it and make notes.

"the weighing with blocks from nearby frames contributing much more than the ones which are several frames away. "

It greatly depends on thSAD2 value and type of movement (transform) around block. If block is static and not changed or only translate move (same lighting and so on) - so it continue to contribute to output with the weight depending of thSAD and block_SAD. So for non-changed areas of the scene the tr may cover all frames in the cutscene. Though some users not like the effect of uneven noise-reduction when static areas are very clean and transformed shows more and more noise. But MPEG coder very like large clean areas and visibly decrease file size.

[LeXXuz]

It may be limitations of 'simple' degrain script based on old mvtools...


Thanks DTL. I really appreciate the time and effort you put into testing this out. :thanks:

I have to find some quite time to occupy myself with your script in way more detail. Right now this feels a little bit over my head.

It's a pitty. Mvtools can really produce amazing results when used for denoising. But so many times I carefully tested out parameters with many different scenes and was very satisfied. Then I encoded the entire film and when watching the result, I stumbled upon at least the same amount of scenes that really looked bad.

Again, Dogway once asked me if I prefer a completely clean look. I do. Because I think only a correctly denoised picture is worth keeping over the original. Anything just half-hearted denoised looks much worse than the source and belongs into the recycle bin. Just my 2 cents of course.

[DTL]

" Then I encoded the entire film and when watching the result, I stumbled upon at least the same amount of scenes that really looked bad."

Unfortunately there still no 'auto-adjust' of the main params like thSAD on the each cutscene. And the typical mix of cutscenes from different film ISO or types with different grain level cause either some scenes not good degrained or some scenes too blurred where there is a small. In theory it is possible to create some 'simple auto' mode on the same ideas as scene detect is created - to calculate mean value of the SAD of the all (valid) frames in current frame pool (in tr-scope) and to set thSAD in given % of this value (like from 80 to 150%). And call this param like 'low-med-high' noise reduction adjustment. But it not work good in all cases. May be need more complex statistical analysys like SAD-histogram (probability or % of SAD values on vertical vs SAD value on horizontal axis) and make tests what good thSAD value corresponds to a series of histogram looking. May be not mean SAD but close to the lowest historgam edge (the min possible SAD even on flat blocks are limited by current noise level). But this auto-algo may fail if frame is padded and some blocks will have zero SAD. So may be need to check only some center of the frame area skipping some safe-borders. This also can fail if the frame is letterboxed and so on.

[guest]

Hi Dogway,

I have encountered a new problem when trying to encode a HDR UHD file.

AVSMeter displays an error with Line 239 of SMDegrain

https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain%20v3.5.4d/SMDegrain%20v3.5.4d.avsi#L239

And I don't know what to do.

This is my script :-

#Custom
LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\MedianBlur2\MedianBlur2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
Import("%AVISYNTHPLUGINS%\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\Zs_RF_Shared\Zs_RF_Shared.avs")
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=2,str=1.2,refinemotion=true)


but I don't get the error with this script :-

#Custom
Loadplugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
super=MSuper(video,pel=2)
fv1=MAnalyse(super,isb=false,delta=1,overlap=4)
bv1=MAnalyse(super,isb=true,delta=1,overlap=4)
video=MDegrain1(video,super,bv1,fv1,thSAD=400)

Mediainfo :-

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L6.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 5 min 0 s
Bit rate : 15.8 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.079
Stream size : 565 MiB (72%)
Title : GalenMao@HDSky
Default : No
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : BT.2020
Mastering display luminance : min: 0.0020 cd/m2, max: 1000 cd/m2

[Dogway]

Hi TDS, I was having a break from AviSynth for a few days. That line just uses nmod(), ResizersPack is now mandatory as per line 22 (https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain%20v3.5.4d/SMDegrain%20v3.5.4d.avsi#L22). Try to load it.

As for LeXXuz's "issue", smearing of shades or low frequency detail is a known side effect of MDegrain. SMDegrain comes bundled with other denoisers (motion compensated), check the 'mode' argument, Dfttest is not implemented though, probably I should. In any case for these cases I made the LFR and DCTFlicker args. Give them a try, they use a mix of low freq sharpened prefilter with a final low freq recovery. DCTFlicker denoises remnant low freq "noise".
I will have a closer look when I get time.

[guest]

Hi TDS, I was having a break from AviSynth for a few days. That line just uses nmod(), ResizersPack is now mandatory as per line 22 (https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain%20v3.5.4d/SMDegrain%20v3.5.4d.avsi#L22). Try to load it.

Hi Dogway, thanks for getting back to me about this, I just added ResizersPack to that script, and it's working :)

I've done a little bit of investigation, and this dependency on ResizersPack was introduced in 3.5.4d.

So thankyou VERY much :)

[LeXXuz]

As for LeXXuz's "issue", smearing of shades or low frequency detail is a known side effect of MDegrain. SMDegrain comes bundled with other denoisers (motion compensated), check the 'mode' argument, Dfttest is not implemented though, probably I should. In any case for these cases I made the LFR and DCTFlicker args. Give them a try, they use a mix of low freq sharpened prefilter with a final low freq recovery. DCTFlicker denoises remnant low freq "noise".
I will have a closer look when I get time.

I usually use LFR on film material, I wasn't sure for DCTFlicker though. I've used it for my DVD transcodes but not for HD so far as I was uncertain if I should use it with HD or not.

I have no experience with any of the other denoiser modes. Anything you could recommend from that lot to try out? :)

[DTL]

"smearing of shades or low frequency detail "

The skin details are not shades and not low spatial frequency - they are low contrast fine details typically. So when contrast of texture is comparable or lower the typical noise amplitude - the chance of bad motion tracking is big and thSAD-protection from bad blending is bad.

I think the tr-value inside MDegrainN may be also made 'dynamic' to protect from too many bad and smoothing blends on some selected blocks. It is very easy in current blending engine of MDegrain, only required some function to provide current tr-value for current block being processed by final blending.
The rules of tr-value modulation may be based for example on the 'classic' skin-DTL method in video cameras based on the colour tone (some range of Hue in HSB model) or may be on the 'contrast' of block. But typically the noise is more visible on 'low contrast' areas like clear sky or windows and so on. So may be method of dynamic tr-value applying need to use several ideas.
Also the wpow-value can be dynamic too - it will be close to additional modulation of thSAD.

[Boulder]

Would it be possible to have the DCTFlicker part as a separate function? It might be quite useful in some cases by itself.

[anton_foy]

I usually use LFR on film material, I wasn't sure for DCTFlicker though. I've used it for my DVD transcodes but not for HD so far as I was uncertain if I should use it with HD or not.

I have no experience with any of the other denoiser modes. Anything you could recommend from that lot to try out? :)

Try the "temporalsoften" mode it is great! Also to retain more shadow detail you can try what I suggested to you earlier in this thread. Or by cranking up gamma with levels then denoise then pull back gamma with levels. :)

Like this:
Levels(0,1.47,255*256,0,255*256)
#denoiser#
Levels(0,0.68,255*256,0,255*256)

earlier post (https://forum.doom9.org/showpost.php?p=1971371&postcount=1313)

[Dogway]

I usually use LFR on film material, I wasn't sure for DCTFlicker though. I've used it for my DVD transcodes but not for HD so far as I was uncertain if I should use it with HD or not.

I have no experience with any of the other denoiser modes. Anything you could recommend from that lot to try out? :)

TemporalSoften is one I tend to use for very grainy sources, it fixes the sticky fizz-grain issues. You can also try medianT, STWM or ML3D, I give some recommendations in ex_median() header.
I'm planning to add DFTTest as well if you see value in it, but I have to come with fixed freq weights, I will have a look at what is the general consensus on that.
In general terms if you are applying strong denoising (high thSAD or tr) motion compensation delivers more temporal congruence than motion occlusion.

Would it be possible to have the DCTFlicker part as a separate function? It might be quite useful in some cases by itself.

To be honest I wanted a reliable temporal denoiser and couldn't come with anything better than SMDegrain itself, so in SMDegrain DCTFlicker is just another (very optimized) call to SMDegrain. A wannabe DCTFlicker filter is ex_LFR(), it passes only high frequency details of 'c' clip to 'ref' clip with a given cutoff. In this case DCTFlicker uses the "shift-back-by-one (http://forum.doom9.org/showthread.php?p=1539241)" trick, it works to some degree only so it's not as versatile as in SMDegrain.

"smearing of shades or low frequency detail "

The skin details are not shades and not low spatial frequency - they are low contrast fine details typically. So when contrast of texture is comparable or lower the typical noise amplitude - the chance of bad motion tracking is big and thSAD-protection from bad blending is bad.


Low contrast fine details can be interpreted as noise by MDegrain. Since details are small maybe refining subpixel detection can improve motion vectors for these. Something like pel>1 and subpixel 4 for nnedi3 or subpixel 3 for blackman, on top of LFR.

[LeXXuz]

Try the "temporalsoften" mode it is great! Also to retain more shadow detail you can try what I suggested to you earlier in this thread. Or by cranking up gamma with levels then denoise then pull back gamma with levels. :)

Like this:
Levels(0,1.47,255*256,0,255*256)
#denoiser#
Levels(0,0.68,255*256,0,255*256)

earlier post (https://forum.doom9.org/showpost.php?p=1971371&postcount=1313)

Thanks anton_foy. But it's not shadow detail that troubles me in this movie, it's movement of fine skin detail. See sample videos.
Isn't raising the gamma like that a little bit too much, regarding that SMDegrain already raises gamma/brightness quite a lot for the prefiltered clip? And is this really reversible? Won't you lose high brightness detail through clipping?


TemporalSoften is one I tend to use for very grainy sources, it fixes the sticky fizz-grain issues. You can also try medianT, STWM or ML3D, I give some recommendations in ex_median() header.
I'm planning to add DFTTest as well if you see value in it, but I have to come with fixed freq weights, I will have a look at what is the general consensus on that.
In general terms if you are applying strong denoising (high thSAD or tr) motion compensation delivers more temporal congruence than motion occlusion.

TemporalSoften produced a much smaller output file size with the very same settings. (I just added mode="TemporalSoften" to the SMDegrain call). So I guess I may have to tweak some more settings for that mode?

I used DFTtestMC before I started denoising with SMDegrain and I put it in just for comparison. It does a better job regarding the blur Mdegrain produces in this scene, but it also has its cons as well. Overall I'd say SMDegrain with Mdegrain produced more satisfying results than DFTtestMC did. I never used DFTtest anymore after I started denoising with SMDegrain. I'd say if you implement it I would only use it for some special cases anyway.



Low contrast fine details can be interpreted as noise by MDegrain. Since details are small maybe refining subpixel detection can improve motion vectors for these. Something like pel>1 and subpixel 4 for nnedi3 or subpixel 3 for blackman, on top of LFR.

I did that scene with pel=2 and subpel=3 plus LFR=300. Raising LFR too much leaves too much residual noise again. The only thing that helped in that scene was lowering the thresholds considerably. But that was unsatisfying for the entire movie. I guess the only way to go is scene based thresholds/denoising.

It's up to you guys to tinker something semi-automatic for that, as this clearly exceeds my knowledge and abilities in Avisynth. But like DTL already mentioned; any automated process will have its downsides with situations where it may fail. But I think it is still worth a try as it may still be better than a fixed setting for an entire movie.

Damn, I really regret I did not take those lectures in digital image processing when I was in university. :(

[Dogway]

@LeXXuz: I could analyze your source. I don't think DFTTestMC looks better overall, yes, some middle frequency detail is preserved but everything above and below is very blurry.
Your initial settings were way too overboard, specially with prefilter=6.
To compare apples to apples your DFTTestMC line should roughly match:
SMDegrain(tr=5, thSAD=300)
This retains some middle frequency better. If you pair it with LFR it preserves some more. And with pel=2 some more again.
SMDegrain(tr=5, thSAD=300, pel=2, subpixel=3, LFR=true)
Following you can add some post-sharpening like ex_unsharp() it sharps two frequencies at the same time, the top-most and the following (half-rate) emphasizing mid-freqs.
ex_unsharp(0.5,safe=true)
or for all the bells and whistles:
LSFplus(strength=50, preset="LSF", Lmode=3, soft=-2, soothe=false, smode=3)
But probably internal contrasharp=true is good enough as it won't sharpen already sharp edges and also accounts for all frequencies.

EDIT: Looks like we were posting at the same time. I also implemented DFTTest as a 'mode' option, not a fan of it though (more blur).

[DTL]

Low contrast fine details can be interpreted as noise by MDegrain.

MDegrain do not know anything about noise. The noise-reduction is 'side-effect' of the MDegrain operation. MDegrain only perform 'compensation' of movement based on MVs from MAnalyse and blends compensated blocks with weight derived from relation of block SAD vs thSAD.

So MDegrain do not know anything about noise and fine texture details. The smearing of fine texture details is issue of 2 steps:
1. Low contrast fine texture details are masked by noise so MAnalyse can not output correct motion vector for correct motion compensation. It can point to completely wrong position far form real. Because of random noise nature the lowest SAD may be really far from real block's position. It may looks strange at first how SAD with wrong position may be lower in compare with 'real' position - but the motion search do not search for 'ideal not-noised block' vs noised ref frames. It search of current frame noised block vs noised blocks in ref frames. So the search result may be from small to great error in motion vector. So I also have some ideas about more complex 'statistical' approach of multi-pass MAnalyse/MDegrain operations so the second searches may be search more noise-reduced block vs noised ref blocks and may produce less search errors.

2. The errorneous motion vector with low contrast texture can not produce high enough block-SAD so the only protection engine from bad blends based on relation between block-SAD vs thSAD can not prevent this bad compensated block from being used into blending operation (the weight of bad compensated block is not zero). So the result of blending of incorrectly compensated block is degradation of low contrast textures. Because of mixing blocks from different 'real' positions with different 'real' textures. So the only current way to decrease this issue is set thSAD as low as possible (but it may significantly decrease 'noise-reduction effect' over total frame).

Some possible idea is to use motion (and may be skin tone-colour) mask and combine degrained clips with different thSAD settings via motion/colour mask so the moving (and/or skin-tone-coloured) areas will be taken from lower-thSAD processed clip (saved more fine details) and other frame areas will come from higher-thSAD processed clip with better denoised. So the total complexity of frame to MPEG encoder will be lower with better saving of fine skintone details.

"Since details are small maybe refining subpixel detection can improve motion vectors for these."

The more real improvement may be much more complex - like moving from blocks-based motion search to objects-oriented motion analysis (of many transforms - not only translate). So if motion analyse engine will detect object as head and detect if it is natural moving rotating head at neck - it finally can create more correct motion vectors for block-based frame tesselation and compensating-blending denoising engine. It still looks like far future of motion-analysis software (of HW engines).
Currently in MAnalyse we have very simple begining of 'motion field correlation' approach based on attempt to analyse neibour blocks (3 of current block) found motion vector and use it as higly-weighted (first in order) predictor and protection with new-penalty from possibly better SAD position. But it is very limited in number of used for analysis blocks and if starting found blocks are not good - the error may be propagated to next blocks in search operation. No multi-pass search currently to make more complex analysis of motion field of large enough areas (covered by many blocks like 10 or 100 or more).

Addition: It may be interesting to make MAnalyse accepting 2 input clips - one for ref frames and one for current frame. So it can be tested how it perform with 'prefiltered' current source frames and with searching inside non or different 'prefiltered' frames. Currently with 1 input clip (super) MAnalyse can only search of current and ref frames from same clip. It may limit best performance. So if current frame is 'low-pass' prefiltered it may look better as current frama but the 'low-pass' prefiltered ref frames looks too low detailed to the motion search of blocks with low contrast fine textures may fail more. Or may be 'current-super' clip may be already 'prefiltered' with MAnalyse/MDegrain with lower settings and so on.

"Under-the-noise" detail recovering on the complex moving targets is the very complex process. For large static areas sometime the block size may be set to 'very large' (like 64x64 or more) and it will be less sensitive to noise. But for complex moving targets with more or less equally moving areas of small size this approach not work too. So it looks required some 'recursive' noise reduction with progressive refining of shape/view of low contrast texture small block severily damaged by noise. It definitely require many frames 'statistical analysis' to found most probable shape/view of block.

[anton_foy]

Thanks anton_foy. But it's not shadow detail that troubles me in this movie, it's movement of fine skin detail. See sample videos.
Isn't raising the gamma like that a little bit too much, regarding that SMDegrain already raises gamma/brightness quite a lot for the prefiltered clip? And is this really reversible? Won't you lose high brightness detail through clipping?

I process in 16bit so just by push and pullback the gamma I never noticed any degradation but someone else here might know that better.
Yes the movement bit is tricky and I would think to use spatialfiltering (fft3d/knlmeansCL...) -> mvtools/mdegrain like temporaldegrain does which preserves motion really good. But I like a simplified version since TD2 it is really slow for me for UHD. Have you tried using fft3d bt=0 for kalman filtering as a prefilter? I got good results but it is slower than the other bt-modes and does not filter spatially as much.

[anton_foy]

Dogway do you have a suggestion for an edge mask/mask to only detect "hard"/"distinct" edges? What I mean is for it to ignore fine details and only cover the larger edges. The prewitts are good to detect the harder edges (even the big blurry ones) but also picks up alot of finer detail. I was thinking I have to downscale, blur, ex_edge, inpand, expand x2 and upscale but maybe you have a better idea? Trying to get rid of ringing and compression artefacts and was thinking to use neo_f3kdb with the mask.

[Dogway]

@anton_foy: Tune the 'lo' arg in ex_edge(), it clips low values. The best modes are the ones that use the Euclidean distance method like qprewitt, sobel, kroon... frei-chen is also good for noisy sources.

[LeXXuz]

Dogway does the show feature of SMDegrain work with UHD?

I got an error message:
StackHorizontal: image hights don't match in line 587 and 651 of SMDegrain.avsi

Video resolution is 3840x2076.

[anton_foy]

Dogway does the show feature of SMDegrain work with UHD?

I got an error message:
StackHorizontal: image hights don't match in line 587 and 651 of SMDegrain.avsi

Video resolution is 3840x2076.

Uhd usually is 3840x2160 so maybe need padding, smdegrain, cropping?

[anton_foy]

@anton_foy: Tune the 'lo' arg in ex_edge(), it clips low values. The best modes are the ones that use the Euclidean distance method like qprewitt, sobel, kroon... frei-chen is also good for noisy sources.

Thank you, it looks like from your picture chart of ex_edge that "max" is most suitable mode for this? But I have not been able to try yet.

[Dogway]

@LeXXuz: Strange, it's working for me. Is SMDegrain updated? what's your call?
@anton_foy: Try frei-chen first, adjusting 'lo' arg.

[LeXXuz]

@LeXXuz: Strange, it's working for me. Is SMDegrain updated? what's your call?


I think the version I have is still based on 3.5.2d. I tweaked quite a few things of contrasharp and prefilters 6 & 7 to my liking. That's why I avoided updating for now.

Anyhow, I helped myself with just a quick downsize to 1080p before calling SMD. Just wanted to check brightness levels of the prefiltered clip, so resolution wasn't really that important. :)

[kedautinh12]

All plugins of Dogway is affect each other. If you update, you need update all plugins

[LeXXuz]

SMDegrain: Is 6 the tr-limit with mode=temporalsoften? With tr>6 performance drops significantly.

[Dogway]

Merge back the changes, the UHD 'show' issues were fixed in 3.5.3 I think.
TemporalSoften max radius is 7, but from 6 onwards SMDegrain uses the 'multi' codepath of MVTools. Maybe that's the reason, that's why I warned with a "# MDegrainN is slower, so avoid >6 at possible"

[LeXXuz]

Merge back the changes, the UHD 'show' issues were fixed in 3.5.3 I think.
TemporalSoften max radius is 7, but from 6 onwards SMDegrain uses the 'multi' codepath of MVTools. Maybe that's the reason, that's why I warned with a "# MDegrainN is slower, so avoid >6 at possible"

Thanks Dogway. :) I saw that line but I was uncertain, so I thought I'd better ask. :)
I'll update my tweaked script to the latest version. :thanks:

[DTL]

Since details are small maybe refining subpixel detection can improve motion vectors for these. Something like pel>1 and subpixel 4 for nnedi3 or subpixel 3 for blackman, on top of LFR.

I got one more idea - make one more switch to MAnalyse to make 'reverse' motion search from ref to current frame. And make MDegrain accept this second reverse-search MVclip.

So the MDegrain can analyse if forward and backward motion vectors for some area are in good coherency. If not - treat this area as unstable and lower the weight for ref blocks for this frame. It will decrease degraining effect but keep more details at this block/area. So it may additionally protect from blurring when motion search is not good. Though for onCPU ME it will make processing speed visibly lower (may be not twice because MDegrain also takes some visible time).
Now need to find some math how to check 'quality of reversability' of motion vector from different tesselation grid because back-search of motion vectors will use again standard tesselation grid and the coordinates even of ideally reversed vectors will not be equal.

Also already made the new testversion accepting different 'super' clip as source for 'current' frames clip so will try to check the 'progressive-refining' of current-clip using a sequence of MDegrain with tr from 1 to N (with linear step like 1,2,3,..N or 1,2,4,8,..N) and decreasing thSAD from max to about initial/2 to degraning 'current' clip and use it as a 'current-source' for MAnalyse for later iterations. In theory if 'current' clip become more and more denoised the SAD of blocks vs noised blocks will decrease to about 1/2 of initial because for equal blocks (ideally compensated) with only noise added:
SAD for noised vs noised block = block - block + noise+noise = noise*2
SAD for clean vs noised block = block - block + noise + 0 = noise
SAD for clean vs clean block = block - block = 0

So any multi-pass processing scripts with several MDegrain in a sequence need to adjust thSAD for next steps using any cleaned by first MDegrain clips to lower values to keep 'details' to about equal level or if use equal thSAD it will cause more degraining but also may cause more details blurring.

[anton_foy]

I got one more idea - make one more switch to MAnalyse to make 'reverse' motion search from ref to current frame. And make MDegrain accept this second reverse-search MVclip.

So the MDegrain can analyse if forward and backward motion vectors for some area are in good coherency. If not - treat this area as unstable and lower the weight for ref blocks for this frame. It will decrease degraining effect but keep more details at this block/area. So it may additionally protect from blurring when motion search is not good. Though for onCPU ME it will make processing speed visibly lower (may be not twice because MDegrain also takes some visible time).
Now need to find some math how to check 'quality of reversability' of motion vector from different tesselation grid because back-search of motion vectors will use again standard tesselation grid and the coordinates even of ideally reversed vectors will not be equal.

Also already made the new testversion accepting different 'super' clip as source for 'current' frames clip so will try to check the 'progressive-refining' of current-clip using a sequence of MDegrain with tr from 1 to N (with linear step like 1,2,3,..N or 1,2,4,8,..N) and decreasing thSAD from max to about initial/2 to degraning 'current' clip and use it as a 'current-source' for MAnalyse for later iterations. In theory if 'current' clip become more and more denoised the SAD of blocks vs noised blocks will decrease to about 1/2 of initial because for equal blocks (ideally compensated) with only noise added:
SAD for noised vs noised block = block - block + noise+noise = noise*2
SAD for clean vs noised block = block - block + noise + 0 = noise
SAD for clean vs clean block = block - block = 0

So any multi-pass processing scripts with several MDegrain in a sequence need to adjust thSAD for next steps using any cleaned by first MDegrain clips to lower values to keep 'details' to about equal level or if use equal thSAD it will cause more degraining but also may cause more details blurring.

Very interesting! I would like to try that approach but with mvtools motion compensated temporalsoften since it keeps more detail than mdegrain but removes more noise. Maybe this new version is something for you to try Dogway? Zopti on top of that...:D

[madey83]

Very interesting! I would like to try that approach but with mvtools motion compensated temporalsoften since it keeps more detail than mdegrain but removes more noise. Maybe this new version is something for you to try Dogway? Zopti on top of that...:D


hey @anton_foy,

could you please share if possible your mvtools based script for noise removal?

i'm only use SMDegrain so i'm very cuirius to compare as you sugested mvtools do better job to prevent more details.

thank you in advance. :thanks:

[anton_foy]

hey @anton_foy,

could you please share if possible your mvtools based script for noise removal?

i'm only use SMDegrain so i'm very cuirius to compare as you sugested mvtools do better job to prevent more details.

thank you in advance. :thanks:

Hello Madey83! Sure I am just writing a new one that is almost ready to post here. Really good stuff if I may say so. Watch out for my post on the Avisynth Usage section I will call it OIC denoiser. Used alot from Dogway's tool box, brilliant stuff for sure. But also you can already use Smdegrain(mode="temporalsoften",tr=5) or whatever tr you need and just try it out. Dogway has implemented many more modes into SMdegrain aswell.

Edit: try it with ex_contrasharpen to regain lost detail.

[madey83]

Hello Madey83! Sure I am just writing a new one that is almost ready to post here. Really good stuff if I may say so. Watch out for my post on the Avisynth Usage section I will call it OIC denoiser. Used alot from Dogway's tool box, brilliant stuff for sure. But also you can already use Smdegrain(mode="temporalsoften",tr=5) or whatever tr you need and just try it out. Dogway has implemented many more modes into SMdegrain aswell.

Edit: try it with ex_contrasharpen to regain lost detail.

hi.

Thank you :D.

Looking forwad your post and meanwhile goint to test your tip.

:D

[madey83]

@anton_foy,

i did some test and i see that "temporalsoften" gives soft results even if i use LSFmod or LSFPlus by Dogway's implementation:

LSFmod(defaults="slow", strength=200, Smode=5, Smethod=3, kernel=11, secure=true, Szrp=16, Spwr=4, SdmpLo=4, SdmpHi=48, Lmode=4, overshoot=1, undershoot=1, Overshoot2=1, Undershoot2=1, soft=-2, soothe=true, keep=20, edgemode=0, edgemaskHQ=true, ss_x=1.50, ss_y=1.50, dest_x=%target_width%, dest_y=%target_height%, show=false, screenW=%target_width%, screenH=%target_height%)

or

LSFplus(strength=60, preset="LSF", Lmode=3, soft=-2, soothe=false, smode=3)

[madey83]

@Dogway,

base on my last test i see that your implementation of SMDegrain (v3.5.4d) retain more details in the picture like on below screenshot. But on top right corner you can see some fuzzy pixels.
Bottom picture it's a results of old SMDegrain (v3.1.2d)
https://imgur.com/a/xwtv3fc

and funny think at least for me is that the bitrate different for the test file (800 frames) is in my opition huge:

old SMD: 3196 kb/s // SMDegrain(tr=4, thSAD=400, thSCD2=100, contrasharp=false, lsb=true, refinemotion=true, truemotion=false, search=3, subpixel=3, Chroma=true, plane=4)
new SMD: 4978 kb/s // SMDegrain(tr=5, thSAD=300, thSCD2=100, LFR=false, refinemotion=true, search=3, subpixel=3)

[DTL]

"4978 kb/s // SMDegrain(tr=5, thSAD=300,"

To compare versions it is good to keep both tr and thSAD the equal. If not directly noted about non-compatibility of the old thSAD settings with new versions.

[madey83]

"4978 kb/s // SMDegrain(tr=5, thSAD=300,"

To compare versions it is good to keep both tr and thSAD the equal. If not directly noted about non-compatibility of the old thSAD settings with new versions.

Thank you DTL for pointing me out my oversight.

i made another tests with the same value for TR and thSAD and what i can clearly say that old SMDegrain clear noise more of the background of the picture. For new SMDegrain implementation i can stil see "fuzzy" pixels in the top righ corner of the picture.

please take a look on this comparison.
https://imgur.com/cmxO3uV

when i increase theSAD to 500 it removed "fuzzy" pixels on top right corrnet but noise on the t-shirt was greater also, compare to old version.


Sorry for being snippy on this matter but i would like to swichover from old verion to new one, but i sitll do not know how to set it up to get thinks right.

[kedautinh12]

Old clean more but new keep more details inside collar

[madey83]

i was able to "fix" this when i use for sharpening filter with this param: LSFplus(preblur="FFT3Dfilter(sigma=4,plane=0)",.......)
noise on the t-shirt was nicely blured.

[LeXXuz]

You can't compare old SMDegrain with new one because too many things have been changed or added.

Even with same thSAD and tr values you will get quite different results and bigger filesizes because the new version preserves much more detail than the old one.

[Dogway]

New SMDegrain does a better job at retaining details, the problem is that in this case it's detecting "fizz-grain" as details. You can do two things raise values, use prefilters, or a mix of both. For example KNLmeansCL (prefilter=5) or try other ones.

You can also use 'mblur' arg to temporally blur areas where motion matching was wrong such as in that grain.

[DTL]

Zopti on top of that...:D

Yes - it is close to the need of automated optimizers: The new version of 'prefiltering with pre-MDegrain' uses different thSAD and final MDegrain uses much lower thSAD (like 200 for 'pre-filter' and 80 for final MDegrain at some current tests).

So there are several params that require long manual encodings and frames review to pick best values. If some automation is available it may be time to look into it.

Unfortunately the very first tests of using forward and backward search MVs and attempt to use simple MV length to detect 'quality of MV search' still about useless - at both smooth and low-contrast detailed areas both fw/bw MVs looks like very different so simple algorithm based on decreasing 'degraining' (weight of ref blocks) on areas with 'bad MVs quality' leaves too much grain on large non-detailed areas (like out-of focus background and so on) too. It is required some more ideas how to use the 2-directional search results to make things better.

[anton_foy]

Yes - it is close to the need of automated optimizers: The new version of 'prefiltering with pre-MDegrain' uses different thSAD and final MDegrain uses much lower thSAD (like 200 for 'pre-filter' and 80 for final MDegrain at some current tests).

So there are several params that require long manual encodings and frames review to pick best values. If some automation is available it may be time to look into it.

Unfortunately the very first tests of using forward and backward search MVs and attempt to use simple MV length to detect 'quality of MV search' still about useless - at both smooth and low-contrast detailed areas both fw/bw MVs looks like very different so simple algorithm based on decreasing 'degraining' (weight of ref blocks) on areas with 'bad MVs quality' leaves too much grain on large non-detailed areas (like out-of focus background and so on) too. It is required some more ideas how to use the 2-directional search results to make things better.

Very strange but I had only one script of mcdegrain that actually shows any difference between thsad, all others does not show any difference between thsad = 180 to thsad = 1600.

Edit:
Yes but I think simplicity in steps are the best for denoising. A motioncompensated temporalsoften has been my leading star for every project latey. The prefiltering is crucial though. Otherwise it blurs too much. I will post soon the before and after comparisons and the .avsi of course. Right now my avs-script works but as a function it ignores some steps and I try to figure out why. Faster than temporaldegrain2 and retains more detail while it also automatically detects noise amount and tweaks the strength. Startup time is a bit slow though still.

Edit2: I modded temporalsoftenmc to be able to change blocksize/overlap of mrecalculate and even to do a normal manalyse with blocksize=32 and mrecalculates blocksize=8 (or even 4) is very accurate and fast.

[DTL]

"do a normal manalyse with blocksize=32 and mrecalculates blocksize=8 (or even 4) is very accurate"

May be initially big blocksize of 32 with full levels search work more stable for low contrast areas (less distorted by noise and low contrast) and MRecalculate as documentation says only refine of finest level (it may be level of 'full-pel' I think so pel 2 and 4 still refined in more passes if set). So can not make as big search error as full levels MAnalyse with small block size. It is not directly supported by hardware accelerators (as I see NVIDIA currently only support 8x8 and 16x16 blocks) but may be emulated with search with block size 16 over half sized frame and make interpolate to full size frame with MScaleVect. It is also a subject to test.

"all others does not show any difference between thsad = 180 to thsad = 1600."

May be too low tr is used (like 1..2), may be the thSCD1 is set too low so work as 'secondary protector' from too bad blending (though it also stops denoising activity too). Also the actual SAD and the corresponding thSAD of MDegrain very significantly depends on 'prefiltering' (if used). Typically denoising prefilter cause more or less SAD decreasing so to keep thSAD just above 'noise level SAD' it need to be lowered too. So may be after strong prefiltering the thSAD 180 already above residual noise-SAD and increasing to 2..3x do not change output noise result (though can quickly start to blur low contrast textures if present). Also setting thSAD > thSCD1 typically change nothing because thSCD1 become limiting.

"A motioncompensated temporalsoften"

Is it a MCTemporalDenoise http://avisynth.nl/index.php/MCTemporalDenoise ?

[kedautinh12]

"do a normal manalyse with blocksize=32 and mrecalculates blocksize=8 (or even 4) is very accurate"

May be initially big blocksize of 32 with full levels search work more stable for low contrast areas (less distorted by noise and low contrast) and MRecalculate as documentation says only refine of finest level (it may be level of 'full-pel' I think so pel 2 and 4 still refined in more passes if set). So can not make as big search error as full levels MAnalyse with small block size. It is not directly supported by hardware accelerators (as I see NVIDIA currently only support 8x8 and 16x16 blocks) but may be emulated with search with block size 16 over half sized frame and make interpolate to full size frame with MScaleVect. It is also a subject to test.

"all others does not show any difference between thsad = 180 to thsad = 1600."

May be too low tr is used (like 1..2), may be the thSCD1 is set too low so work as 'secondary protector' from too bad blending (though it also stops denoising activity too). Also the actual SAD and the corresponding thSAD of MDegrain very significantly depends on 'prefiltering' (if used). Typically denoising prefilter cause more or less SAD decreasing so to keep thSAD just above 'noise level SAD' it need to be lowered too. So may be after strong prefiltering the thSAD 180 already above residual noise-SAD and increasing to 2..3x do not change output noise result (though can quickly start to blur low contrast textures if present). Also setting thSAD > thSCD1 typically change nothing because thSCD1 become limiting.

"A motioncompensated temporalsoften"

Is it a MCTemporalDenoise http://avisynth.nl/index.php/MCTemporalDenoise ?
Latest ver
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/MCTemporalDenoise.avsi

[anton_foy]

"do a normal manalyse with blocksize=32 and mrecalculates blocksize=8 (or even 4) is very accurate"

May be initially big blocksize of 32 with full levels search work more stable for low contrast areas (less distorted by noise and low contrast) and MRecalculate as documentation says only refine of finest level (it may be level of 'full-pel' I think so pel 2 and 4 still refined in more passes if set). So can not make as big search error as full levels MAnalyse with small block size. It is not directly supported by hardware accelerators (as I see NVIDIA currently only support 8x8 and 16x16 blocks) but may be emulated with search with block size 16 over half sized frame and make interpolate to full size frame with MScaleVect. It is also a subject to test.

"all others does not show any difference between thsad = 180 to thsad = 1600."

May be too low tr is used (like 1..2), may be the thSCD1 is set too low so work as 'secondary protector' from too bad blending (though it also stops denoising activity too). Also the actual SAD and the corresponding thSAD of MDegrain very significantly depends on 'prefiltering' (if used). Typically denoising prefilter cause more or less SAD decreasing so to keep thSAD just above 'noise level SAD' it need to be lowered too. So may be after strong prefiltering the thSAD 180 already above residual noise-SAD and increasing to 2..3x do not change output noise result (though can quickly start to blur low contrast textures if present). Also setting thSAD > thSCD1 typically change nothing because thSCD1 become limiting.

"A motioncompensated temporalsoften"

Is it a MCTemporalDenoise http://avisynth.nl/index.php/MCTemporalDenoise ?

Regarding Thsad I actually have a tr 5-7. Maybe thSCD1 is limiting then.
No I never tried MCTemporaldenoise.
Here is the original TemporalSoftenMC: here (http://forum.doom9.net/showthread.php?p=1950632#post1950632)

[guest]

Latest ver
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/MCTemporalDenoise.avsi

I thought I'd try and get this to work with RipBot264, here's my script :-

LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\AddGrainC\AddGrainC.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\DCTFilter\DCTFilter.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\Deblock\Deblock-x64.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\EEDI2\EEDI2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\FFT3dFilter\fft3dfilter.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\GradFun2db\GradFun2db.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\SangNom\SangNom2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\TTempSmooth\TTempSmooth.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\GradFun2DBmod\GradFun2DBmod.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Deblock_QED\Deblock_QED_MT2Mod.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\LSFmod\LSFmod.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\MCTemporalDenoise\MCTemporalDenoise.avs")
video=MCTemporalDenoise(video, settings="medium")

But AVSMeter show error with this :-

https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/MCTemporalDenoise.avsi#L477

I'm pretty sure I've got something very wrong, here :(

[kedautinh12]

You lack call plugin sysinfo.dll

[guest]

You lack call plugin sysinfo.dll

Thanks, but it didn't make any difference :(

[Zetti]

You need this file:

https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Zs_RF_Shared.avsi

[kedautinh12]

You need this file:

https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Zs_RF_Shared.avsi

Yeah, that script and sysinfo plugin. I was forgot it when comment to TDS

[kedautinh12]

Your pc lack vc++ or directX 9 SDK to load plugins fft3dGPU.dll. Try install them
https://www.microsoft.com/en-us/download/details.aspx?id=6812
https://github.com/abbodi1406/vcredist/releases

And please make sure to place the correct file HLSL in the same directory with fft3dGPU.dll

[tormento]

Move it to System32 inside Windows directory.

[kedautinh12]

You need download d3dx9_43.dll x64 ver and copy to Windows/System32. I think you lack that file. If not here the list of file you need for FFT3DGPU to work
d3dx9_43.dll: D3DXGetVertexShaderProfile
d3dx9_43.dll: D3DXFloat32To16Array
d3dx9_43.dll: D3DXFloat16To32Array
d3dx9_43.dll: D3DXGetPixelShaderProfile
d3dx9_43.dll: D3DXCompileShaderFromFileA
d3d9.dll: Direct3DCreate9
DINPUT8.dll: DirectInput8Create
VERSION.dll: VerQueryValueA
VERSION.dll: GetFileVersionInfoSizeA
VERSION.dll: GetFileVersionInfoA
ole32.dll: CoUninitialize
ole32.dll: CoCreateInstance
ole32.dll: CoInitialize
OLEAUT32.dll: @8
OLEAUT32.dll: @7
OLEAUT32.dll: @9

[LeXXuz]

Has anyone a subtle to medium grain setting for GrainFactory3mod? The default setting is way too strong for my taste and I haven't worked with this before.

It's for SD material, one of these awful DVDs where the content suffers from almost every kind of noise there is, including way too low bitrate used upon creation. So the cleaned output looks too sterile and almost as bad as the untouched source.

I need some kind of good compressable grain-coating back on that material to make it look more natural again.

[kedautinh12]

Or not, you can download that app and drag FFT3DGPU.dll to app. It's will show what lack requirements of FFT3DGPU

[kedautinh12]

Has anyone a subtle to medium grain setting for GrainFactory3mod? The default setting is way too strong for my taste and I haven't worked with this before.

It's for SD material, one of these awful DVDs where the content suffers from almost every kind of noise there is, including way too low bitrate used upon creation. So the cleaned output looks too sterile and almost as bad as the untouched source.

I need some kind of good compressable grain-coating back on that material to make it look more natural again.

You can base here to findout best value for you
https://github.com/Dogway/Avisynth-Scripts/blob/767e90f7cbf02976d112fe85716fa0d39174f462/ResizersPack.avsi#L271

[kedautinh12]

Is this for me ??

What app ??

Sr, forgot link :D
https://github.com/lucasg/Dependencies/releases

[anton_foy]

@Dogway, some ideas and speculations. Since I cannot get waifu2x to work I have no idea how good its denoising is. I read it can be used for 1x in cunet mode with noise=3? Is it a good denoising (spatial/temporal, slow, fast)? Could waifu2x maybe be used to reconstruct chroma as an alternative to chromareconstructor-script? Vulkan makes me think its faster...

[Dogway]

Quality wise I don't know, I presume something like a bilateral filter? It's spatial only.
I gave it a run to test performance and got a system semi-freeze, scary. Tested without prefetch and ran at around 2.3fps.

DGSource("source"")
ConvertBits(32)
ConverttoPlanarRGB()
w2xncnnvk(noise=3,scale=1,model=2)

------------------

By the way I was having a look at the non-linearity of vision (psychovisual) and found the INRF algorithm here (https://www.nature.com/articles/s41598-020-73113-0).
I gave it a stab, although had to reverse the last expression to get the values on positive, and then normalize.
From here you can extract the INRF-IQ similarity metric.

# Variables are both Gaussians stds, 3.88 lamda, and the two exponens 0.63 and 0.78
m=vsTCanny(0.81,mode=-1)
w=vsTCanny(2.77,mode=-1)

# Neighbor contribution to x (weighted by Gaussian)
Delta= Expr(last,w,\
"x[1,1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[1,1] *
x[1,0] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[1,0] *
x[1,-1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[1,-1] *
x[-1,1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[-1,1] *
x[-1,0] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[-1,0] *
x[-1,-1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[-1,-1] *
x[0,1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[0,1] *
x[0,-1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[0,-1] * + + + + + + + ")
# OR
#~ ex_luts(mode="avg", pixels=ex_shape(1,mode="square",center=true),expr="Y X - S@ 0 >= S 0.63 ^ S abs 0.78 ^ neg ? Y *", exprF="9 *")


# Not sure if x[0,0] should be added to the computations
Delta= Expr(last,Delta,w,\
"x[1,1] y[1,1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[1,1] *
x[1,0] y[1,0] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[1,0] *
x[1,-1] y[1,-1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[1,-1] *
x[-1,1] y[-1,1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[-1,1] *
x[-1,0] y[-1,0] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[-1,0] *
x[-1,-1] y[-1,-1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[-1,-1] *
x[0,1] y[0,1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[0,1] *
x[0,-1] y[0,-1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[0,-1] *
x y - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z * + + + + + + + + 3.88 *")

RF=Expr(last,m,\
"x[1,1] y[1,1] *
x[1,0] y[1,0] *
x[1,-1] y[1,-1] *
x[-1,1] y[-1,1] *
x[-1,0] y[-1,0] *
x[-1,-1] y[-1,-1] *
x[0,1] y[0,1] *
x[0,-1] y[0,-1] * x y * + + + + + + + + ")


Expr(RF, Delta, "y x - 25.5 /")

[anton_foy]

Quality wise I don't know, I presume something like a bilateral filter? It's spatial only.
I gave it a run to test performance and got a system semi-freeze, scary. Tested without prefetch and ran at around 2.3fps.

DGSource("source"")
ConvertBits(32)
ConverttoPlanarRGB()
w2xncnnvk(noise=3,scale=1,model=2)

------------------

By the way I was having a look at the non-linearity of vision (psychovisual) and found the INRF algorithm here (https://www.nature.com/articles/s41598-020-73113-0).
I gave it a stab, although had to reverse the last expression to get the values on positive, and then normalize.
From here you can extract the INRF-IQ similarity metric.

# Variables are both Gaussians stds, 3.88 lamda, and the two exponens 0.63 and 0.78
m=vsTCanny(0.81,mode=-1)
w=vsTCanny(2.77,mode=-1)

# Neighbor contribution to x (weighted by Gaussian)
Delta= Expr(last,w,\
"x[1,1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[1,1] *
x[1,0] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[1,0] *
x[1,-1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[1,-1] *
x[-1,1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[-1,1] *
x[-1,0] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[-1,0] *
x[-1,-1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[-1,-1] *
x[0,1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[0,1] *
x[0,-1] x - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? y[0,-1] * + + + + + + + ")
# OR
#~ ex_luts(mode="avg", pixels=ex_shape(1,mode="square",center=true),expr="Y X - S@ 0 >= S 0.63 ^ S abs 0.78 ^ neg ? Y *", exprF="9 *")


# Not sure if x[0,0] should be added to the computations
Delta= Expr(last,Delta,w,\
"x[1,1] y[1,1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[1,1] *
x[1,0] y[1,0] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[1,0] *
x[1,-1] y[1,-1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[1,-1] *
x[-1,1] y[-1,1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[-1,1] *
x[-1,0] y[-1,0] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[-1,0] *
x[-1,-1] y[-1,-1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[-1,-1] *
x[0,1] y[0,1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[0,1] *
x[0,-1] y[0,-1] - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z[0,-1] *
x y - X@ 0 >= X 0.63 ^ X abs 0.78 ^ neg ? z * + + + + + + + + 3.88 *")

RF=Expr(last,m,\
"x[1,1] y[1,1] *
x[1,0] y[1,0] *
x[1,-1] y[1,-1] *
x[-1,1] y[-1,1] *
x[-1,0] y[-1,0] *
x[-1,-1] y[-1,-1] *
x[0,1] y[0,1] *
x[0,-1] y[0,-1] * x y * + + + + + + + + ")


Expr(RF, Delta, "y x - 25.5 /")

Thanks for checking it out. I don't get any freeze with prefetch but only black frames and errors in the terminal.

Was curious about your INRF-script but all I get is a green image.
EDIT: oh its for metrics only...my bad.

[madey83]

Hi,

Sorry for stupid question (please forgive) how i can remove more noise on background and do not touch forground?

[anton_foy]

Hi,

Sorry for stupid question (please forgive) how i can remove more noise on background and do not touch forground?

What is background/foreground? Out of focus background (blurry)?

[Reel.Deel]

TDS,

It's probably best to open your own thread since your posts in the last page and a half have nothing to do with Dogway's filters.

[guest]

TDS,

It's probably best to open your own thread since your posts in the last page and a half have nothing to do with Dogway's filters.

Heard...

But someone (and then others) mentioned MCTemporalDenoise, so I just followed it.

I got some help, but not fixed :(

[kedautinh12]

Hi ked,

So, a new day, same problem.

There were no issues with that dependencies app, I have looked high & low for a solution, but I'm still getting a problem with this :-

https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/MCTemporalDenoise.avsi#L711

There is still clearly something missing :(

You need download latest Gradfrun2dbmod
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/GradFun2DBmod.avsi
And you need dither tools too
http://avisynth.nl/index.php/Dither_tools#SmoothGrad

[kedautinh12]

I really appreciate all your help, but this is going nowhere.

I'm still getting that line 711 error msg.

Can you share again your call plugins, scripts??

[kedautinh12]

Sure...Reel.Deel not going to like all this...

LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\AddGrainC\AddGrainC.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\DCTFilter\DCTFilter.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\Deblock\Deblock-x64.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\dither\dither.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\EEDI2\EEDI2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\FFT3dFilter\fft3dfilter.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\FFT3dGPU\FFT3dGPU.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\GradFun2db\GradFun2db.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\SangNom\SangNom2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\SysInfo\SysInfo64.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\TTempSmooth\TTempSmooth.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\GradFun2DBmod\GradFun2DBmod.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Deblock_QED\Deblock_QED_MT2Mod.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\LSFmod\LSFmod.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Zs_RF_Shared\Zs_RF_Shared.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\MCTemporalDenoise\MCTemporalDenoise.avs")
video=MCTemporalDenoise(video, settings="medium")

You forgot call Dither_Tools.avsi
http://avisynth.nl/index.php/Dither_tools

[madey83]

What is background/foreground? Out of focus background (blurry)?

@anton_foy,

something like this:
https://imgur.com/9VoMBEv

King's face and clothes are clean and fairly sharp (forground), but background behing him is blurred ( i know this is related to camera and recording technics) and it is very clean, without noise.

when i call SMDegrain like this:
SMDegrain(mode="MDegrain", tr=4, thSAD=400, thSCD2=100, LFR=false, refinemotion=true, search=3, subpixel=3).

it cleans to much noise on first plan (king's details) but background noise removes quite good.

Is there anything that could separate forground and background and specify different denoise values?

[kedautinh12]

Sorry 'bout that..

Now added, still same error :(

I think you need use other app can autoload all plugins and scripts to save time for fix your errors. And other app can tell what errors exactly

[guest]

I think you need use other app can autoload all plugins and scripts to save time for fix your errors. And other app can tell what errors exactly

You're probably right, but this is the app I want to use.

I may not even like what this filter does, anyway.

Thanks again for your help, I think I might now go back and delete all the posts, to keep reel.deel happy.

[kedautinh12]

You're probably right, but this is the app I want to use.

I may not even like what this filter does, anyway.

Thanks again for your help, I think I might now go back and delete all the posts, to keep reel.deel happy.

Yeah, reel.deel always angry, you need delete your post before he alarm to moderator like me when i thanks all threads with my honor :D

[guest]

Yeah, reel.deel always angry, you need delete your post before he alarm to moderator like me when i thanks all threads with my honor :D

OK, well if you want to go back and delete your replies, I'm OK with that :D

FYI, I just had a look at Staxrip script for this filter, and it's MASSIVE...but I think they included everything, just to cover all variables.

[anton_foy]

@anton_foy,

something like this:
https://imgur.com/9VoMBEv

King's face and clothes are clean and fairly sharp (forground), but background behing him is blurred ( i know this is related to camera and recording technics) and it is very clean, without noise.

when i call SMDegrain like this:
SMDegrain(mode="MDegrain", tr=4, thSAD=400, thSCD2=100, LFR=false, refinemotion=true, search=3, subpixel=3).

it cleans to much noise on first plan (king's details) but background noise removes quite good.

Is there anything that could separate forground and background and specify different denoise values?

Maybe lower tr and thsad (and try LFR=true ? ) until the face is good and then try this (https://forum.doom9.org/showthread.php?p=1973275#post1973275) after smdegrain.

[madey83]

Maybe lower tr and thsad (and try LFR=true ? ) until the face is good and then try this (https://forum.doom9.org/showthread.php?p=1973275#post1973275) after smdegrain.

thanks.

i will try.:thanks:

[LeXXuz]

Are other blocksizes allowed than 2^n? SMDegrain seems to accept them (f.e. blksize=24) but I don't know if this may cause problems.

[DTL]

If script accepts both blocksize (asumed as H) and blocksizeV - you can probably set any supported by mvtools (see documentation) and also blocksize must be compatible with colour mode used (4:2:2 and 4:2:0 require special ratio of luma and chroma). Possibly may work:
List of available block sizes (blksize x blksizeV)
64x64, 64x48, 64x32, 64x16
48x64, 48x48, 48x24, 48x12
32x64, 32x32, 32x24, 32x16, 32x8
24x48, 24x24, 24x32, 24x12, 24x6
16x64, 16x32, 16x16, 16x12, 16x8, 16x4, 16x2
12x48, 12x24, 12x16, 12x12, 12x6, 12x3
8x32, 8x16, 8x8, 8x4, 8x2, 8x1
6x24, 6x12, 6x6, 6x3
4x8, 4x4, 4x2
3x6, 3x3
2x4, 2x2
Note: some smaller block sizes can only be available in 4:4:4 formats, due to block size division (chroma subsampling) with mvtools about 2.7.45.

[LeXXuz]

Oh good. On some sources with very coarse grain/noise a higher blocksize does a way better job and gives a more homogeneous look than thSAD and tr could achieve. Thanks DTL :thanks:

[madey83]

If script accepts both blocksize (asumed as H) and blocksizeV - you can probably set any supported by mvtools (see documentation) and also blocksize must be compatible with colour mode used (4:2:2 and 4:2:0 require special ratio of luma and chroma). Possibly may work:
List of available block sizes (blksize x blksizeV)
64x64, 64x48, 64x32, 64x16
48x64, 48x48, 48x24, 48x12
32x64, 32x32, 32x24, 32x16, 32x8
24x48, 24x24, 24x32, 24x12, 24x6
16x64, 16x32, 16x16, 16x12, 16x8, 16x4, 16x2
12x48, 12x24, 12x16, 12x12, 12x6, 12x3
8x32, 8x16, 8x8, 8x4, 8x2, 8x1
6x24, 6x12, 6x6, 6x3
4x8, 4x4, 4x2
3x6, 3x3
2x4, 2x2
Note: some smaller block sizes can only be available in 4:4:4 formats, due to block size division (chroma subsampling) with mvtools about 2.7.45.

hi,

how can this be used in StaxRip with SMDegrain?

Could you please provide some example for test purpose?

[madey83]

Maybe lower tr and thsad (and try LFR=true ? ) until the face is good and then try this (https://forum.doom9.org/showthread.php?p=1973275#post1973275) after smdegrain.

Hi anton_foy,

could you advice where i made mistake ?

in StaxRip i put this:
Import("E:\4k_Encode\UnBand.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
Loadplugin("E:\4k_Encode\mvtools-2.7.45-with-depans20210608\x64\mvtools2.dll")
Loadplugin("E:\4k_Encode\ApplyEvery031_32_64\ApplyEvery64.dll")
LoadPlugin("E:\4k_Encode\apps\StaxRip-v2.12.0-x64\Apps\Plugins\Dual\f3kdb Neo\neo-f3kdb.dll")
loadplugin("E:\4k_Encode\apps\StaxRip-v2.12.0-x64\Apps\Plugins\AVS\FFT3DFilter\fft3dfilter.dll")
Uband(loC=3, grainY=23, mt=false)

but i got this error:
Script error: There is no function named 'si_physicalcores'

and is this change something even if i use f3kdb Neo?

[DTL]

Oh good. On some sources with very coarse grain/noise a higher blocksize does a way better job and gives a more homogeneous look than thSAD and tr could achieve. Thanks DTL :thanks:

Mostly probably the large blocksize is good only for primary search and need refine (recalculate) to lower blocksize in second (other) pass/passes because large blocksize can not track complex motion good. thSAD and tr are tuning params for selected search/degrain architecture.
So usage of large blocksize is typically require 'refinemotion' in SMDegrain or other plugins. May be even not single refine but several more stages like blocksize 64->32->16->8. It may allow to work with lower thSAD params and get less detail smoothing.

[kedautinh12]

Hi anton_foy,

could you advice where i made mistake ?

in StaxRip i put this:
Import("E:\4k_Encode\UnBand.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
Loadplugin("E:\4k_Encode\mvtools-2.7.45-with-depans20210608\x64\mvtools2.dll")
Loadplugin("E:\4k_Encode\ApplyEvery031_32_64\ApplyEvery64.dll")
LoadPlugin("E:\4k_Encode\apps\StaxRip-v2.12.0-x64\Apps\Plugins\Dual\f3kdb Neo\neo-f3kdb.dll")
loadplugin("E:\4k_Encode\apps\StaxRip-v2.12.0-x64\Apps\Plugins\AVS\FFT3DFilter\fft3dfilter.dll")
Uband(loC=3, grainY=23, mt=false)

but i got this error:
Script error: There is no function named 'si_physicalcores'

and is this change something even if i use f3kdb Neo?

You call lack some plugins and script, you can check from dependencies here
https://github.com/Dogway/Avisynth-Scripts/blob/57d4d0a9f3bb39753fef5314440767b848c27027/SMDegrain%20v3.5.5d/SMDegrain%20v3.5.5d.avsi#L30

[DTL]

hi,

how can this be used in StaxRip with SMDegrain?

Could you please provide some example for test purpose?

Try to set blksize above default and RefineMotion=true.

Docs at avisynth.nl need to be updated to correct link - current download link https://github.com/realfinder/AVS-Stuff/raw/master/avs%202.5%20and%20up/SMDegrain.avsi is not work more - return 404 error.

Current version of SMDegrain at Dogway github lists
[int "blksize"=16 (4 to 64 by 4)],
Assert(blksize==4 || blksize==8 || blksize==16 || blksize==24 || blksize==32 || blksize==48 || blksize==64,"SMDegrain: MAnalyse: Block's size must be 4x4, 8x8, 16x16, 24x24, 32x32, 48x48 or 64x64")

So it looks not limited to 16 as lists at http://avisynth.nl/index.php/SMDegrain but can be only 4x4, 8x8, 16x16, 24x24, 32x32, 48x48 or 64x64 for SMDegrain.

[anton_foy]

Hi anton_foy,

could you advice where i made mistake ?

in StaxRip i put this:
Import("E:\4k_Encode\UnBand.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
Loadplugin("E:\4k_Encode\mvtools-2.7.45-with-depans20210608\x64\mvtools2.dll")
Loadplugin("E:\4k_Encode\ApplyEvery031_32_64\ApplyEvery64.dll")
LoadPlugin("E:\4k_Encode\apps\StaxRip-v2.12.0-x64\Apps\Plugins\Dual\f3kdb Neo\neo-f3kdb.dll")
loadplugin("E:\4k_Encode\apps\StaxRip-v2.12.0-x64\Apps\Plugins\AVS\FFT3DFilter\fft3dfilter.dll")
Uband(loC=3, grainY=23, mt=false)

but i got this error:
Script error: There is no function named 'si_physicalcores'

and is this change something even if i use f3kdb Neo?

For Uband you are e missing sys_info.dll (sysinfo plugin) but I can also update the uband function for you this evening for a better new version without the sysinfo plugin.

[LeXXuz]

So usage of large blocksize is typically require 'refinemotion' in SMDegrain or other plugins. May be even not single refine but several more stages like blocksize 64->32->16->8. It may allow to work with lower thSAD params and get less detail smoothing.

Yes I always use motion refinement. Otherwise flat texture areas could start to 'wobble' with too high blocksizes. Especially when there is some pumping involved in the noise.

[DTL]

Yes I always use motion refinement. Otherwise flat texture areas could start to 'wobble' with too high blocksizes. Especially when there is some pumping involved in the noise.

It looks 'interfiltering' of MVs is really good to make as separate mvtools filter so it can be included into any search filterchain (like as intermediate between large and refined blocksize search) and not only inside MDegrainN as final processig of MVs before usage.

[Dogway]

Just wanted to chime in to show how I deal with SMDegrain.
I downloaded a video from a streaming service and H264 artifacts are all over the place.
So my approach is to denoise and then regrain. It's not perfect but it was a fast cobble up to improve the perceived quality.

Original - Restored
http://i.imgur.com/qMBEiYCm.png (https://i.imgur.com/qMBEiYC.png)......http://i.imgur.com/gVwe95Dm.png (https://i.imgur.com/gVwe95D.png)
Line by line:
ConvertBits(16)
CCD(15) # Remove big chroma "blocks"

# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40,UV=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

# Prefiltering with radius 3 for more coherence. I found preset "normal" to clean edges better.
pre=ex_BM3D(sigma=10,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)

# Large radius for more coherence. LFR to recover some smearing. limits=false to don't sharpen motion areas
SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)
# Debanding to reduce posterization in walls/defocused backgrounds
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)

# Fine grain
str=0.7
size=0.8
GrainFactory3mod(g1str=6.0*str,g2str=8.0*str,g3str=5.5*str,g1size=1.20*size,g2size=1.50*size,g3size=1.40*size,g1cstr=0.5,g2cstr=0.3,g3cstr=0.1,temp_avg=1)

# Good quality dithering
fmtc_bitdepth(bits=8, dmode=7)

As you can see I don't use internal prefiltering. Internal prefiltering is simply a convenience, but you are supposed to build your own ones.
I also need to remove the TV bugs with inpaintdelogo.

By the way, SMDegrain up-to-date documentation is now here (https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain%20v3.5.5d/SMDegrain%20v3.5.5d.html). It's still work in progress though, but about 70% done.

[kedautinh12]

Why you use gradfun3flus replace f3kdb in debanding??

[tormento]

Line by line
Thanks :)
By the way, SMDegrain up-to-date documentation
❤️

[Dogway]

Why you use gradfun3flus replace f3kdb in debanding??

Looks worse. Simply try:

ex_GaussianBlur(10.00,pad=true,mblur=true,UV=3)
ex_posterize(bits=6, mode=-1)
ConvertBits(16)
# GradFun3plus(thr=0.6, radius=6, mask=1, smode=0)
neo_f3kdb(y=100,cb=48,cr=48,range=10)

ConvertBits(8,dither=1)
PseudoColor(mode="isoparam", iso=1.0)

[kedautinh12]

Looks worse. Simply try:

ex_GaussianBlur(10.00,pad=true,mblur=true,UV=3)
ex_posterize(bits=6, mode=-1)
ConvertBits(16)
# GradFun3plus(thr=0.6, radius=6, mask=1, smode=0)
neo_f3kdb(y=100,cb=48,cr=48,range=10)

ConvertBits(8,dither=1)
PseudoColor(mode="isoparam", iso=1.0)

F3KDB_3 can better than neo_f3kdb
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/F3KDB_s.avsi

[LeXXuz]

Just wanted to chime in to show how I deal with SMDegrain.

# Prefiltering with radius 3 for more coherence. I found preset "normal" to clean edges better.
pre=ex_BM3D(sigma=10,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)


What performance do you get with this?

I can't use radius >1 on 1080p or above with the normal preset. Even my RTX 3060ti slows down so much that it becomes the bottleneck. Not to mention my RTX 2060 and GTX 1050ti. I use avs_test09 version of BM3D. It's CUDA code surely could use some more speed optimization.
Right now I stick with DGDenoise(). It's lightning fast compared to BM3D, although it's a little unfair to compare block matching with non-local means algo.

[Dogway]

Now that you say probably very slow. I only tested on avspmod. I only got a 1070 (looking forward a 4060 Ti, prolly too expensive :( ) so probably should lower it to 2 or maybe 1.
My intention was to use 2 passes, encode lossless (or transparent) 16-bit after SMDegrain. Then final deband, regrain, and encode. And in 2 chunks (movie is 172 mins).

[Reel.Deel]

By the way, SMDegrain up-to-date documentation is now here (https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain%20v3.5.5d/SMDegrain%20v3.5.5d.html). It's still work in progress though, but about 70% done.

Nice! I went ahead and added the link to the wiki page since the docs there are outdated.

[guest]

Hi anton_foy,

could you advice where i made mistake ?

in StaxRip i put this:
Import("E:\4k_Encode\UnBand.avsi")
Import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
Loadplugin("E:\4k_Encode\mvtools-2.7.45-with-depans20210608\x64\mvtools2.dll")
Loadplugin("E:\4k_Encode\ApplyEvery031_32_64\ApplyEvery64.dll")
LoadPlugin("E:\4k_Encode\apps\StaxRip-v2.12.0-x64\Apps\Plugins\Dual\f3kdb Neo\neo-f3kdb.dll")
loadplugin("E:\4k_Encode\apps\StaxRip-v2.12.0-x64\Apps\Plugins\AVS\FFT3DFilter\fft3dfilter.dll")
Uband(loC=3, grainY=23, mt=false)

but i got this error:
Script error: There is no function named 'si_physicalcores'

and is this change something even if i use f3kdb Neo?

Hi madey83,

Now this isn't a Staxrip script, but I think you will soon see what the problem is.

This works for me (on most videos) :-

Loadplugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\ApplyEvery\ApplyEvery64.dll") works without this, too !!!
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\neo-f3kdb\neo-f3kdb.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\FFT3dFilter\fft3dfilter.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\SysInfo\SysInfo64.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\UBand\Uband.avs")
video=Uband(video, loC=3, grainY=23, mt=false)


See here :- https://forum.doom9.org/showthread.php?p=1975087#post1975087

[madey83]

Hi madey83,

Now this isn't a Staxrip script, but I think you will soon see what the problem is.

This works for me (on most videos) :-

Loadplugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\ApplyEvery\ApplyEvery64.dll") works without this, too !!!
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\neo-f3kdb\neo-f3kdb.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\FFT3dFilter\fft3dfilter.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\SysInfo\SysInfo64.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\UBand\Uband.avs")
video=Uband(video, loC=3, grainY=23, mt=false)


See here :- https://forum.doom9.org/showthread.php?p=1975087#post1975087


thank you :)

[madey83]

Just wanted to chime in to show how I deal with SMDegrain.
I downloaded a video from a streaming service and H264 artifacts are all over the place.
So my approach is to denoise and then regrain. It's not perfect but it was a fast cobble up to improve the perceived quality.

Original - Restored
http://i.imgur.com/qMBEiYCm.png (https://i.imgur.com/qMBEiYC.png)......http://i.imgur.com/gVwe95Dm.png (https://i.imgur.com/gVwe95D.png)
Line by line:
ConvertBits(16)
CCD(15) # Remove big chroma "blocks"

# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40,UV=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

# Prefiltering with radius 3 for more coherence. I found preset "normal" to clean edges better.
pre=ex_BM3D(sigma=10,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)

# Large radius for more coherence. LFR to recover some smearing. limits=false to don't sharpen motion areas
SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)
# Debanding to reduce posterization in walls/defocused backgrounds
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)

# Fine grain
str=0.7
size=0.8
GrainFactory3mod(g1str=6.0*str,g2str=8.0*str,g3str=5.5*str,g1size=1.20*size,g2size=1.50*size,g3size=1.40*size,g1cstr=0.5,g2cstr=0.3,g3cstr=0.1,temp_avg=1)

# Good quality dithering
fmtc_bitdepth(bits=8, dmode=7)

As you can see I don't use internal prefiltering. Internal prefiltering is simply a convenience, but you are supposed to build your own ones.
I also need to remove the TV bugs with inpaintdelogo.

By the way, SMDegrain up-to-date documentation is now here (https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain%20v3.5.5d/SMDegrain%20v3.5.5d.html). It's still work in progress though, but about 70% done.

@Dogway,

thank you so much for this.
i did few test with GradFun3plus and neo_f3kdb and i see that GradFun3plus does better job.

prefilter for SMDegrain is also good so this is my for now base for upcoming encodes.

i did not test this though yet:

CCD(15) # Remove big chroma "blocks"

# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40,UV=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

due to fact that these are new for me and i do not really know what is advanteges to call it before SMDegrain.

BTW: Thx for documentation update :thanks:

[Dogway]

neo_f3kdb seems to simply add noise instead of dithering so output is noisier and consumes more bitrate. Yes it's a few times faster but for me quality is first.

The lines you mention are source specific. In this case it's a heavily compressed clip so you want to get rid of blocking. CCD removes chroma macroblocks, while Deblock_QED removes luma blocking. Unfortunately Deblock_QED is not perfect so some high contrast lines (quant1 arg) are left jagged. I run ex_smooth() on top for that, it's a bit destructive but since it's passed through mfilter it will only be applied on motion areas.


####################

By the way, wanted to share some experiment I have been working on these days. Per-shot grain adjustment.

First you output some scene stats (use SceneStats (https://github.com/Dogway/Avisynth-Scripts/blob/master/ScenesPack.avsi), updated today)
# First Pass
setmemorymax(2048*3)
DGSource("Q:\source.dgi",cl=0,ct=0,cr=0,cb=0)

SceneStats(mode="Range+Motion",path="Q:\Range+Motion.log")

Prefetch(1)


Now we are going to detect grain level an a per-shot basis. One assumes that the difference between source and a degrained/denoised version estimates the amount of grain level, so that's what we do. First degrain, then compare source with degrained for a diff mask, and subtract edges from it. Export new stats (we want average diff mask values per-shot).

# Second Pass
setmemorymax(2048*3)
DGSource("Q:\source.dgi",cl=0,ct=0,cr=0,cb=0)

ReadStats("Q:\Range+Motion.log")
ExtractY()
dirt = last
# If this is too slow use a faster spatio-temporal denoiser
SMDegrain(1, 400, ContraSharp=false, RefineMotion=false, LFR=400)

gm = ex_edge (cln,mode="frei-chen", scale=1.0, invert=true).ex_inpand(2,mode="disk")
ex_lutxyz(dirt,gm,"x y - abs z range_max / *") # dirt mask
SceneStats(mode="Stats", path="Q:\Stats.log") # per-shot dirt mask average

Finally we load both stat files and do some parametrization. I intentionally lower grain level slightly when scene has higher motion.

# Third Pass
setmemorymax(2048*3)
DGSource("Q:\source.dgi",cl=0,ct=0,cr=0,cb=0)

ConvertBits(16)
CCD(15)
mb = Deblock_QED(quant1=30, quant2=40,UV=1)
mb = mb.ex_smooth(1, mode="SG", limit=true, sharp=true)
pre = ex_BM3D(sigma=10,preset="normal",radius=2,UV=1,gpuid=0,tv_range=true)

SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)

ReadStats("Q:\Range+Motion.log")
ReadStats("Q:\Stats.log")

# per-shot modulated grain
ScriptClip(function [] () {

avg = propGetAsArray("_SceneStats")[4]
mot = propGetFloat ("_SceneMotion")
navg = avg / (mot + 1)
size = 2*navg + 0.4 # between 0.7 and 1.1 mostly
str = navg + 0.5 # between 0.6 and 0.8 mostly

GrainFactory3mod(g1str=6*str,g2str=8*str,g3str=7*str,g1size=1.20*size,g2size=1.50*size,g3size=1.40*size,g1cstr=0.5,g2cstr=0.3,g3cstr=0.1,temp_avg=1)
} )

ConvertBits(8, dither=1)

[tormento]

F3KDB_3 can better than neo_f3kdb
And what about speed?

[kedautinh12]

And what about speed?

Like Dogway said, prefer quality :D

[kedautinh12]

Here, little-bit faster ver
https://github.com/kedaitinh12/AVSPlus-Scripts/blob/master/F3KDB_sMOD.avsi

[LeXXuz]

mb = Deblock_QED(quant1=30, quant2=40,UV=1)
mb = mb.ex_smooth(1, mode="SG", limit=true, sharp=true)
SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)


That kinda interests me. I usually just use a simple blur for mfilter on sources with little blocking in high-motion areas . I'm talking about some Blu-ray sources. Not that really nasty stuff from broadcasting/streaming that very often craves for way more bitrate. ;)

I'd be interested in a higher quality solution than just blur. Could you give some tips on ex_smooth usage?

[Dogway]

That kinda interests me. I usually just use a simple blur for mfilter on sources with little blocking in high-motion areas . I'm talking about some Blu-ray sources. Not that really nasty stuff from broadcasting/streaming that very often craves for way more bitrate. ;)

I'd be interested in a higher quality solution than just blur. Could you give some tips on ex_smooth usage?

It depends on what your goal is. Maybe Deblock_QED is less destructive than a simple blur but this example is very case specific with a highly compressed source. For blurays maybe you can get away with some faint blur which helps for extra compression.

In my case I wanted the opposite, reconstruct the detail, so Deblock_QED for flat areas and ex_smooth for edge areas. ex_smooth is like a high quality blur, technically it's a polynomial, in practice it performs between a blur and an antialiaser. Helps also to smooth out binary masks, etc.

[DTL]

Well, here is something I'm really scratching my head on.

I'm still struggling with a bluring effect with SMDegrain in moving areas which really disturbs the overall look of the picture.


It is example with updated MDegrainN - https://send.cm/d/FAb2

With simple usage without prefiltering now -

ConvertToYUV420(matrix="Rec709")
super = MSuper(mt=false, pel=2)
tr=12
multi_vec=MAnalyse(super, blksize=8, multi=true, search=3, temporal=false, trymany=false, searchparam=2, chroma=true, delta = tr, truemotion=false, pzero=0, pnew=0, levels=2, mt=false, overlap=0)
MDegrainN(last,super, multi_vec, tr, thSAD=110, thSAD2=100, mt=false, wpow=4, thSCD1=500, adjSADzeromv=0.4, adjSADcohmv=0.7, thCohMV=2, MVLPFGauss=1.1,
thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=3, MPBthSub=10, MPBthAdd=20, MPBNumIt=2, MPB_SPC=1.5)


Was lazy to wait for full 4x overlap at my very old home CPU so used lower quality interpolated.
Version of mvtools from release - https://forum.doom9.org/showthread.php?p=1975256#post1975256 . x264 with settings in metadata in mp4 file makes average speed about sub 7 MBit/s. Though x264 with crf=18 also delete some fine low-contrast details.

[LeXXuz]

It is example with updated MDegrainN - https://send.cm/d/FAb2

With simple usage without prefiltering now -


Impressive result. :eek: Thanks for sharing that script. Will try it out. :thanks:

[LeXXuz]

It depends on what your goal is. Maybe Deblock_QED is less destructive than a simple blur but this example is very case specific with a highly compressed source. For blurays maybe you can get away with some faint blur which helps for extra compression.

In my case I wanted the opposite, reconstruct the detail, so Deblock_QED for flat areas and ex_smooth for edge areas. ex_smooth is like a high quality blur, technically it's a polynomial, in practice it performs between a blur and an antialiaser. Helps also to smooth out binary masks, etc.

Is the threshold when the mfilter is used adjustable somehow?

I added a simple Greyscale() to the mfilter call and was quite surprised about all the greyed out areas in scenes I really didn't expect this to happen. :eek:

[Boulder]

Is the threshold when the mfilter is used adjustable somehow?

I added a simple Greyscale() to the mfilter call and was quite surprised about all the greyed out areas in scenes I really didn't expect this to happen. :eek:

From the docs: "This clip will be passed through those areas where smdegrain() couldn't find a matching block."

That points to thSAD - the higher thSAD is, the less non-matching blocks.

[madey83]

It is example with updated MDegrainN - https://send.cm/d/FAb2

With simple usage without prefiltering now -

ConvertToYUV420(matrix="Rec709")
super = MSuper(mt=false, pel=2)
tr=12
multi_vec=MAnalyse(super, blksize=8, multi=true, search=3, temporal=false, trymany=false, searchparam=2, chroma=true, delta = tr, truemotion=false, pzero=0, pnew=0, levels=2, mt=false, overlap=0)
MDegrainN(last,super, multi_vec, tr, thSAD=110, thSAD2=100, mt=false, wpow=4, thSCD1=500, adjSADzeromv=0.4, adjSADcohmv=0.7, thCohMV=2, MVLPFGauss=1.1,
thMVLPFCorr=50, adjSADLPFedmv=0.9, IntOvlp=3, MPBthSub=10, MPBthAdd=20, MPBNumIt=2, MPB_SPC=1.5)


Was lazy to wait for full 4x overlap at my very old home CPU so used lower quality interpolated.
Version of mvtools from release - https://forum.doom9.org/showthread.php?p=1975256#post1975256 . x264 with settings in metadata in mp4 file makes average speed about sub 7 MBit/s. Though x264 with crf=18 also delete some fine low-contrast details.


@DTL,

thank you for this, but could you please share what would be the best call, if the power of CPU does not matter but quality has matter only?

[DTL]

For simple script with single MAnalyse and no prefilter the only better is full 4x overlap (search and blend) and possibly pel=4 as better precision of search and blend. So

super = MSuper(mt=false, pel=4)
tr=12
multi_vec=MAnalyse(super, blksize=8, multi=true, search=3, temporal=false, trymany=false, searchparam=2, chroma=true, delta = tr, truemotion=false, pzero=0, pnew=0, mt=false, overlap=4)
MDegrainN(last,super, multi_vec, tr, thSAD=110, thSAD2=100, mt=false, wpow=4, thSCD1=500, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16, MVLPFGauss=0.9,
thMVLPFCorr=50, adjSADLPFedmv=0.9, MPBthSub=10, MPBthAdd=20, MPBNumIt=2, MPB_SPC=1.5)

Also it have some more 'universal' params settings not optimized for current content. Also remember to adjust thSAD,thSAD2,thSCD1,tr for current content and processing performance.

For possibly better result it require integration in SMDegrain script so it can use different prefiltering and also may need research if different prefiltering for 'current' and 'ref' clips may produce better results. Also may be single or more stages of 'refining blocksize' with MRecalculate may produce better results.

[madey83]

:thanks::script:For simple script with single MAnalyse and no prefilter the only better is full 4x overlap (search and blend) and possibly pel=4 as better precision of search and blend. So

super = MSuper(mt=false, pel=4)
tr=12
multi_vec=MAnalyse(super, blksize=8, multi=true, search=3, temporal=false, trymany=false, searchparam=2, chroma=true, delta = tr, truemotion=false, pzero=0, pnew=0, mt=false, overlap=4)
MDegrainN(last,super, multi_vec, tr, thSAD=110, thSAD2=100, mt=false, wpow=4, thSCD1=500, adjSADzeromv=0.5, adjSADcohmv=0.5, thCohMV=16, MVLPFGauss=0.9,
thMVLPFCorr=50, adjSADLPFedmv=0.9, MPBthSub=10, MPBthAdd=20, MPBNumIt=2, MPB_SPC=1.5)

Also it have some more 'universal' params settings not optimized for current content. Also remember to adjust thSAD,thSAD2,thSCD1,tr for current content and processing performance.

For possibly better result it require integration in SMDegrain script so it can use different prefiltering and also may need research if different prefiltering for 'current' and 'ref' clips may produce better results. Also may be single or more stages of 'refining blocksize' with MRecalculate may produce better results.

:thanks:

[DTL]

As processing of noisy VHS captures shows the settings like MPBNumIt=2, MPB_SPC=1.5 may be too aggressive and leave too much noise too. So if the residual noise level is too high even with big enough tr and thSAD values may be good either to try lower like MPBNumIt=1, MPB_SPC=1.2 settings or even make some linear mix of 2 processed clips - with MPBNumIt > 0 and with 'old' standard blending mode with MPBNumIt=0 (default) to make balance between residual noise and possible keeping of details. The MPB_SPC may be lowered to about 1.02 and still produce visible difference. It should be > 1.0.

[LeXXuz]

Dogway how do I use dfttest as mode with the 3.5.5d version of SMDegrain properly? Any info on the possible parameters?

A lot of parameters cause errors. Right now I just managed to do a simple call like SMDegrain(mode="dfttest", tr=3).
I know tbsize needs to be odd so tr has to be too, I guess?

[kedautinh12]

Dogway how do I use dfttest as mode with the 3.5.5d version of SMDegrain properly? Any info on the possible parameters?

A lot of parameters cause errors. Right now I just managed to do a simple call like SMDegrain(mode="dfttest", tr=3).
I know tbsize needs to be odd so tr has to be too, I guess?

You can use with prefilter=4
https://github.com/Dogway/Avisynth-Scripts/blob/23515d5ca598503c789fca687f8032846a58ac4c/SMDegrain%20v3.5.5d/SMDegrain%20v3.5.5d.avsi#L258

[LeXXuz]

You can use with prefilter=4
https://github.com/Dogway/Avisynth-Scripts/blob/23515d5ca598503c789fca687f8032846a58ac4c/SMDegrain%20v3.5.5d/SMDegrain%20v3.5.5d.avsi#L258

That is NOT what I asked. Version 3.5.5d supports dfttest as a denoising mode not just as a prefilter.

[Dogway]

I didn't notice that requirement. Yes, to make it behave smooth add the next into the dfttest call:
,tmode=(tr-1)%2
What other settings are giving you issues?

By the way, I'm still finishing TransformsPack, just did an overall rehaul to Transfers module. Will focus now on Main module to solve for the chroma location. Chromatic Adaptation fix is reserved for the following (last?) RC version, technically 1.0 final.
ResizersPack will benefit a lot from these so an update is also on due.

[madey83]

F3KDB_3 can better than neo_f3kdb
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/F3KDB_s.avsi

hi kedautinh12,

i did 3 tests:

#1) neo_f3kdb(preset="veryhigh/nograin", dynamic_grain=false, output_depth=10):
preset="veryhigh/nograin" == [y=80/cb=80/cr=80/grainy=0/grainc=0]
neo_f3kdb_8.30 fps_1858.66kbs_QP22.58

#2) GradFun3plus(thr=0.25, radius=10, mask=2, thr_det=2, elast=4, smode=2, UV=1):
GradFun3plus_5.17fps_1962kbs_QP22.42

#3) F3KDB_3(range=10, Y=100, Cb=48, Cr=48, grainY=80, grainC=80, sample_mode=2, dynamic_grain=false, opt=-1, keep_tv_range=true, output_depth=10, chroma=true):
F3KDB_3_8.03 fps_1957.32kbs_QP22.65


and i can see on my eyes that neo_f3kdb produced less details than F3KDB_3 and GradFun3plus.

Between F3KDB_3 and GradFun3plus i do not see any differents but speed is quit big.

i do not really know if this is correct comparision....

[LeXXuz]

I didn't notice that requirement. Yes, to make it behave smooth add the next into the dfttest call:
,tmode=(tr-1)%2

Thanks I'll add that. :)


What other settings are giving you issues?

Never mind that. I got confused with the parameters as I've been using neo_dfttest before which uses different syntax. Btw, you may consider using the neo-fork of dfttest. I've used that one with real.finders dfttestMC for quite a while and it was considerably faster than the original dfttest. Unless there has been a more speed optimized version since 1.9.7 in the meantime.


By the way, I'm still finishing TransformsPack, just did an overall rehaul to Transfers module. Will focus now on Main module to solve for the chroma location. Chromatic Adaptation fix is reserved for the following (last?) RC version, technically 1.0 final.
ResizersPack will benefit a lot from these so an update is also on due.
Very nice! Looking forward to it. :)

As a side note; I've encoded a film twice. Denoised with tr=6 and tr=12. Rest of the parameters identical.
(SMDegrain(mode="MDegrain", tr=6/12, thSAD=300, thSADc=200, contrasharp=true, LFR=true, DCTFlicker=true, refinemotion=true, truemotion=false, blksize=16, search=5, pel=2, subpixel=3, prefilter=3, chroma=true, plane=4))

The file encoded with tr=6 got smaller in total size than the version with tr=12. Not in a huge amount, but noticeably. Like 5.46GB vs 5.53GB for the entire film in 1080p.

I was wondering how to interpret this?
Would this mean the denoising with tr=12 kept more detail or interpreted less content as noise because of higher precision through the higher radius?
Since the tr=12 version took 2 hours longer to encode I was wondering if it's worth the time or merely just a waste? :rolleyes:

[real.finder]

neo_f3kdb produced less details than F3KDB_3

by default F3KDB_3 use neo_f3kdb(smode=4) also it use masking which the same used in GradFun3 (I think it also same in GradFun3plus)

[Dogway]

If you can run dfttest and neo_ benchmarks with different threads, and prefetch combinations I might consider it. When I benchmarked them last year speed difference was negligible (I think dfttest was a bit faster, not sure).

For the tr=12 case, it might be the case of ghosting probably? If not maybe the contrasharp is hitting back harder. You can test with a snippet with contrasharp=false.
For me personally I like keeping a half a second windows, tr=6 for a 24fps source, as it's not either too fast nor too slow for the eye to notice temporal denoising changes. It's a good pacing threshold to capture action.

[DTL]

@anton_foy,

something like this:
https://imgur.com/9VoMBEv

King's face and clothes are clean and fairly sharp (forground), but background behing him is blurred ( i know this is related to camera and recording technics) and it is very clean, without noise.

Is there anything that could separate forground and background and specify different denoise values?

You can check the 'IVS-mask' feature of that release - https://forum.doom9.org/showthread.php?p=1976044#post1976044

It not directly about 3D space fore/back separation but tried to separate sharp detailed areas from flat non-detailed to apply 'anti-blur'/detail saving/restoration' processing only to detailed areas to save from increasing noise on non-detailed.
To generate this mask the property of motion search engines used:
1. At sharp detailed areas the MVs are typically stable enough and random component in MVs length and direction angle is low enough (in completely static areas with ideal search result all MVs = (0,0) so zero length and (zero ? assumed) angle.
2. At flat non scene-detailed but noise added areas the motion search engine typically output a sequence of random enough MVs (in theory the length of each MV may be limited only by search radius) and typical angle is very random too.
So current algo of IVS-mask (it is from 'Is Vectors Stable') calculates acceleration in the MVs from past to the future and angle difference and after multiplication creates some metric of MVs stability for current block to compare with user-provided threshold to make decision if this area are mostly noise without details (and typical degrain settings/processing may be applied) or it is possibly detailed area and details keepig/saving processing may be selected.
If this mask will be good for some other outside MDegrain scripting it may be added special mode of MDegrain to output only 2levels of greyscale mask from this algorithm. Currently it is used only for threshold adjustment and only assumed as detailed blocks are marked with zero-black (not any nice but quick method to mark something - slow but not used in production processing - only for params control/setup).
Currently the generated mask is not very precisely tracks the border between sharp and blurred areas may be because some motion-search engines trying to use area-adaptive methods of blocks tracking with inter-blocks dependencies (like truemotion=true in MAnalyse) so blocks MVs search are not completely independent. So for best results of IVS-mask it is recommended special inter-blocks-independent search mode of MAnalyse (like truemotion = false preset, zero penalties, may be lambda special adjustment too and so on) and seperate input in MDegrain provided if user want to use other search methods for main degraining work (like prefiltered clip for MAnalyse).

[madey83]

You can check the 'IVS-mask' feature of that release - https://forum.doom9.org/showthread.php?p=1976044#post1976044

It not directly about 3D space fore/back separation but tried to separate sharp detailed areas from flat non-detailed to apply 'anti-blur'/detail saving/restoration' processing only to detailed areas to save from increasing noise on non-detailed.
To generate this mask the property of motion search engines used:
1. At sharp detailed areas the MVs are typically stable enough and random component in MVs length and direction angle is low enough (in completely static areas with ideal search result all MVs = (0,0) so zero length and (zero ? assumed) angle.
2. At flat non scene-detailed but noise added areas the motion search engine typically output a sequence of random enough MVs (in theory the length of each MV may be limited only by search radius) and typical angle is very random too.
So current algo of IVS-mask (it is from 'Is Vectors Stable') calculates acceleration in the MVs from past to the future and angle difference and after multiplication creates some metric of MVs stability for current block to compare with user-provided threshold to make decision if this area are mostly noise without details (and typical degrain settings/processing may be applied) or it is possibly detailed area and details keepig/saving processing may be selected.
If this mask will be good for some other outside MDegrain scripting it may be added special mode of MDegrain to output only 2levels of greyscale mask from this algorithm. Currently it is used only for threshold adjustment and only assumed as detailed blocks are marked with zero-black (not any nice but quick method to mark something - slow but not used in production processing - only for params control/setup).
Currently the generated mask is not very precisely tracks the border between sharp and blurred areas may be because some motion-search engines trying to use area-adaptive methods of blocks tracking with inter-blocks dependencies (like truemotion=true in MAnalyse) so blocks MVs search are not completely independent. So for best results of IVS-mask it is recommended special inter-blocks-independent search mode of MAnalyse (like truemotion = false preset, zero penalties, may be lambda special adjustment too and so on) and seperate input in MDegrain provided if user want to use other search methods for main degraining work (like prefiltered clip for MAnalyse).



HI DTL, thank you for that, but to be honest this is to advanced for me. I think i'll stick with SMDegrain or try to learn more about MDegrainN and of course observe the discussion on this topic.... :)

[ENunn]

I'm getting this error whenever I use QTGMC+ with AVISource. I started to get this error after updating it.
https://i.imgur.com/05y3lPt.png

This doesn't happen when I load the video with LSMASH, but loading and scrubbing is just way too slow. Is there a fix?

[Dogway]

I don't recommend you loading interlaced with avisource since it doesn't index the frames.
You can try LSmash, FFMS2, DGIndex or DGDecNV. I prefer the later two because it will detect parity swaps on interlaced content.

[LeXXuz]

I get an error with NNEDI3 (pel=4 & subpixel=4 and set gpuid=-1), I can't pinpoint and need some help:
https://abload.de/thumb/pel4_errormqfvy.png (https://abload.de/image.php?img=pel4_errormqfvy.png)


Furthermore with NNEDI3CL (set gpuid=0), I get the following error:
https://abload.de/thumb/pel4_cl_error3gi5e.png (https://abload.de/image.php?img=pel4_cl_error3gi5e.png)

SMDegrain call:

SMDegrain(mode="MDegrain", tr=6, thSAD=600, thSADc=600, thSCD1=550, contrasharp=200, limitS=true, CClip=ORG, LFR=300, DCTFlicker=true, refinemotion=true, truemotion=false, pel=4, subpixel=4, gpuid=-1/0, prefilter=3, chroma=true, plane=4)



NNEDI3 v0.9.4.60 and NNEDI3CL 1.0.4.0 installed.
Source video is 720x576@25.

pel=4 & subpixel=1/2/3 is working without errors.

[Dogway]

Ok, I think it has to do with the slated updates on ResizersPack because it's working fine on my internal version.
I've been dawdling a bit but hope to release ASAP.

Currently I was testing the new modes in latest RIFE update, specially useful for the faster modes.
Does anyone got the halos_ghosts_judder (https://forum.doom9.org/showthread.php?p=1941970#post1941970)clip? I want to pass it through FrameRateConverterMIX.

[tormento]

@Dogway

Is there a way with the newer Asd-g filter such as RIFE (or anything else) to interpolate frames in reduced real frame material such as anime?

They usually have 23.976 stream fps but the frames are far less, often repeated.

I'd like to match stream fps with "real" frame fps, i.e. replace all duplicated frames with interpolated ones.

[Dogway]

Did you try with "RIFEAnime" preset? I haven't checked though, as I implemented as MysteryX dictated, but I'm currently testing with some live action samples and I don't like the masking logic.

The masking logic treats RIFE as a fallback for MFlowFps ver.1 and MFlowFps ver.2 difference mask. This means, if both match (regardless a match of crap blending or not) the ver.1 is chosen.

I'm now going to reformulate that to pass RIFE always on high motion areas with a motion mask, and then fallback to above logic where RIFE might also be used when both MFlowFps versions don't match.

I want to test this with the halos_ghosts_judder clip. But I think it might also work with Anime, I will give it a look.

[kedautinh12]

Did you try with "RIFEAnime" preset? I haven't checked though, as I implemented as MysteryX dictated, but I'm currently testing with some live action samples and I don't like the masking logic.

The masking logic treats RIFE as a fallback for MFlowFps ver.1 and MFlowFps ver.2 difference mask. This means, if both match (regardless a match of crap blending or not) the ver.1 is chosen.

I'm now going to reformulate that to pass RIFE always on high motion areas with a motion mask, and then fallback to above logic where RIFE might also be used when both MFlowFps versions don't match.

I want to test this with the halos_ghosts_judder clip. But I think it might also work with Anime, I will give it a look.

If it's bug with live action, you can report to Asd-g

[Dogway]

No, it was a problem with FrameRateConverter, but to be honest, I don't see a point on it anymore. RIFE is mostly always better than FRC, and when not the huge performance drop of FRC isn't worth it.

I made a wrapper for RIFE, will add soon to ResizersPack.

#
# OpticalFlowRIFE()
#
# Wrapper around RIFE port by Asd-g
#
# Dependencies:
# RIFE
# ExTools
# TransformsPack
#
function OpticalFlowRIFE(clip a, int "model", int "FrameNum", int "FrameDen", bool "FrameDouble", bool "Anime", int "gpuid") {

isy = isy (a)
rgb = isRGB (a)
rgbp = isPlanarRGB (a)

numD = Defined(FrameNum)
denD = Defined(FrameDen)

num = propNumElements (a,"_DurationDen") > 0 ? \
propGetInt (a,"_DurationDen") : FrameRateNumerator(a)
den = propNumElements (a,"_DurationNum") > 0 ? \
propGetInt (a,"_DurationNum") : FrameRateDenominator(a)
fs = propNumElements (a,"_ColorRange" ) > 0 ? \
propGetInt (a,"_ColorRange" ) == 0 : rgb

pID = color_propGet(a)
bi = pID[7]
pri = pID[2]
mat = "PC"+pri
isHD = (width (a) > 1099 || height(a) > 599)

ver = VersionString()
Assert(Eval(MidStr(ver,FindStr(ver,"(r")+2,4))>=Eval("3689"),"OpticalFlowRIFE: Update AviSynth+ version")

num = Default(FrameNum, num)
den = Default(FrameDen, den)
md = Default(model, 22) # model: 3 - for Anime or lineart, 17,6,22 - for photos or live action (in ascending order of qual/speed)
fd = Default(FrameDouble, !(numD || denD))
an = Default(Anime, false)
gid = Default(gpuid, 0)

ConvertBits(a, 32, fulls=fs, fulld=true)
rgb ? rgbp ? last : ConvertToPlanarRGB() : isy ? MergeRGB(last,last,last) : ConvertToPlanarRGB(matrix=mat,chromaresample="lanczos4")

RIFE(model=fd ? md : max(md,9), sc=true, skip=an, fps_num=fd ? Undefined() : num, fps_den=fd ? Undefined() : den, tta=false, gpu_id=max(0,gid), gpu_thread=isHD ? 4 : 2)

isy ? ExtractR() : \
!rgb ? MatchClip(a,matrix=pri,size=false,props=false) : last
fd ? Interleave(a.propSet("_DurationDen",den*2), SelectOdd()) : last

propCopy(a,true,props=["_DurationNum","_DurationDen","_PictType"], exclude=true) }

[tormento]

But I think it might also work with Anime, I will give it a look.
Please keep us informed and, when ready, show us some script examples.

[Boulder]

Would it be possible to make deep_resize use linear space scaling for downscales by default?

[madey83]

@Dogway,

coud it be an option to add paramiter to SMDegrain to look ahead, let say 24 frames and calculate some avarage value for thSAD to be more "dynamically" insted fix value?
i think this is used for X265 encoder: option: --rc-lookahead - of course i could be wrong.....

[tormento]

@Dogway

I think I have missed some SMDegrain iteration but did you add support for DTL cpu and/or gpu mvtools?

[Dogway]

No I haven't, I think I was waiting for support of blocksize of 16, not sure if that's possible now? Does he have a git?
If so I can make a fork version but I don't think I can benchmark it as I don't have DX12 (Win7 here), will install W10 in a month though, when 22H2 arrives.

@madey83: You don't need to lookahead, you can access the whole scene range stats with ScenesPack, without overflowing into adjacent scenes.
Here's an example for SMDegrain (https://forum.doom9.org/showthread.php?p=1969107#post1969107).
And here's another one for GrainFactory3mod (https://forum.doom9.org/showthread.php?p=1975232#post1975232)so you can get the gist of it.

You can get an idea of the GrainFactory3mod example to derive the thSAD for SMDegrain example.

Would it be possible to make deep_resize use linear space scaling for downscales by default?

Not by default, you can mimic linear space downscaling with SSIM2 kernel, but I can add an option to resize in linear space if it doesn't modify much the structure of the function.

I'm off now to work a little.

[LeXXuz]

What do you use for halo removal on bad DVD sources?

Tried Blinddehalo and Dehaloalpha. But all they did was (over)smoothing the picture no matter what parameters I changed. Although their edgemasks looked fine, the result was poor.

[tormento]

No I haven't, I think I was waiting for support of blocksize of 16, not sure if that's possible now? Does he have a git?
https://github.com/DTL2020/mvtools

Plus a couple of threads in Avisynth Development subforum.
as I don't have DX12
There are a CPU branch and a GPU one, with different (almost) capabilities each.

[DTL]

"CPU branch and a GPU one, with different (almost) capabilities each."

The current sources are single now. The build may be created with DX12_ME define so it will be Win10 (DX12 and later) compatible to load mvtools2.dll and its DX12 dependencies. And this build can use optSearchOption 5 or 6 for MAnalyse for hardware if found. If build without DX12_ME compiler define it will be standard mvtools2 (may be only no 32bit directly because of a few new functions in MAnalyse need to be fixed). optSearchOption 5 or 6 for MAnalyse will throw error message to mark it was no DX12 build. Compatible with Win7 at least.

Block size 16x16 with DX12ME runs somehow buggy and my remote debug do not breaks at crash. May be it is local non-compatibility with my Win 10 + GTX1060 or bug somewhere. So I not use this. Only 8x8. So we need some more developers with complete build and debug system with Win10 and HW accelerator to try to check what cause crash.

Much more sad for Dogway public scripts may be next notes:
1. Currently 2.7.45 mvtools2 version from pinterf was fine tuned for many years to fix possible bugs and support many blocksizes and bitdepths and colour formats. But current my builds have many new features but support only very limited blocksizes/bitdephts/colour formats. Some combinations not implemented, some will use slow C-reference. Some may simply crash. Most new features were only tested at 8x8 8bit YV12.
2. The most sad issue for plugins users - the 2.7.45 and my builds can not be separated in single process because they use equal functions names. And so it looks not possible to run some complex scripts without modifications (like QTGMC). So my build can not be complete replacement of 2.7.45 version - it may cause bugs somewhere (may be crashes). The only typical use case is keep it in current working directory and load as local .dll (not from common plugins folder). Currently it is mostly somehow working tech demo and can be used for production only in very limited scenarios (like simple degrain script). All other use cases of mvtools of 2.7.45 version may or may not work.

Most of new features are about onCPU processing now so not use accelerator. May be I will add SSIM (and/or some more) metric to compute shader someday if tests will show some good use cases for it. Currently I not found them. The SSIM metric only shows some significantly different resulting MVs with onCPU MAnalyse (though direct MDegrain with there MVs also not visibly better) so currently planned use case is higher quality IVS mask of using SAD and SSIM different searches and combined metric from MVs difference. It is to be tested in future.
Most of DX12-dependent simple search features is finished many months ago (planned some fix to compute shader to have more equal SAD result with onCPU but still not finished).

[guest]

I don't have DX12 (Win7 here), will install W10 in a month though, when 22H2 arrives.

FYI, Windows 10 22H2 has been "out" for a month or more...

[DTL]

Minimum required Windows version is looks like 19H1 - https://devblogs.microsoft.com/directx/new-in-d3d12-motion-estimation/ from May 2019.

[madey83]

No I haven't, I think I was waiting for support of blocksize of 16, not sure if that's possible now? Does he have a git?
If so I can make a fork version but I don't think I can benchmark it as I don't have DX12 (Win7 here), will install W10 in a month though, when 22H2 arrives.

@madey83: You don't need to lookahead, you can access the whole scene range stats with ScenesPack, without overflowing into adjacent scenes.
Here's an example for SMDegrain (https://forum.doom9.org/showthread.php?p=1969107#post1969107).
And here's another one for GrainFactory3mod (https://forum.doom9.org/showthread.php?p=1975232#post1975232)so you can get the gist of it.

You can get an idea of the GrainFactory3mod example to derive the thSAD for SMDegrain example.



Not by default, you can mimic linear space downscaling with SSIM2 kernel, but I can add an option to resize in linear space if it doesn't modify much the structure of the function.

I'm off now to work a little.

@Dogway,

thank you answering.

i tried to test the code you pointed me to, but it requires Avisynth 3.7.3 which is not available for download.

[kedautinh12]

@Dogway,

thank you answering.

i tried to test the code you pointed me to, but it requires Avisynth 3.7.3 which is not available for download.

Here:
https://gitlab.com/uvz/AviSynthPlus-Builds

[kedautinh12]

neo_f3kdb seems to simply add noise instead of dithering so output is noisier and consumes more bitrate. Yes it's a few times faster but for me quality is first.

The lines you mention are source specific. In this case it's a heavily compressed clip so you want to get rid of blocking. CCD removes chroma macroblocks, while Deblock_QED removes luma blocking. Unfortunately Deblock_QED is not perfect so some high contrast lines (quant1 arg) are left jagged. I run ex_smooth() on top for that, it's a bit destructive but since it's passed through mfilter it will only be applied on motion areas.


####################

By the way, wanted to share some experiment I have been working on these days. Per-shot grain adjustment.

First you output some scene stats (use SceneStats (https://github.com/Dogway/Avisynth-Scripts/blob/master/ScenesPack.avsi), updated today)
# First Pass
setmemorymax(2048*3)
DGSource("Q:\source.dgi",cl=0,ct=0,cr=0,cb=0)

SceneStats(mode="Range+Motion",path="Q:\Range+Motion.log")

Prefetch(1)


Now we are going to detect grain level an a per-shot basis. One assumes that the difference between source and a degrained/denoised version estimates the amount of grain level, so that's what we do. First degrain, then compare source with degrained for a diff mask, and subtract edges from it. Export new stats (we want average diff mask values per-shot).

# Second Pass
setmemorymax(2048*3)
DGSource("Q:\source.dgi",cl=0,ct=0,cr=0,cb=0)

ReadStats("Q:\Range+Motion.log")
ExtractY()
dirt = last
# If this is too slow use a faster spatio-temporal denoiser
SMDegrain(1, 400, ContraSharp=false, RefineMotion=false, LFR=400)

gm = ex_edge (cln,mode="frei-chen", scale=1.0, invert=true).ex_inpand(2,mode="disk")
ex_lutxyz(dirt,gm,"x y - abs z range_max / *") # dirt mask
SceneStats(mode="Stats", path="Q:\Stats.log") # per-shot dirt mask average

Finally we load both stat files and do some parametrization. I intentionally lower grain level slightly when scene has higher motion.

# Third Pass
setmemorymax(2048*3)
DGSource("Q:\source.dgi",cl=0,ct=0,cr=0,cb=0)

ConvertBits(16)
CCD(15)
mb = Deblock_QED(quant1=30, quant2=40,UV=1)
mb = mb.ex_smooth(1, mode="SG", limit=true, sharp=true)
pre = ex_BM3D(sigma=10,preset="normal",radius=2,UV=1,gpuid=0,tv_range=true)

SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)

ReadStats("Q:\Range+Motion.log")
ReadStats("Q:\Stats.log")

# per-shot modulated grain
ScriptClip(function [] () {

avg = propGetAsArray("_SceneStats")[4]
mot = propGetFloat ("_SceneMotion")
navg = avg / (mot + 1)
size = 2*navg + 0.4 # between 0.7 and 1.1 mostly
str = navg + 0.5 # between 0.6 and 0.8 mostly

GrainFactory3mod(g1str=6*str,g2str=8*str,g3str=7*str,g1size=1.20*size,g2size=1.50*size,g3size=1.40*size,g1cstr=0.5,g2cstr=0.3,g3cstr=0.1,temp_avg=1)
} )

ConvertBits(8, dither=1)

You can trans it for one pass encode??

[Boulder]

Not by default, you can mimic linear space downscaling with SSIM2 kernel, but I can add an option to resize in linear space if it doesn't modify much the structure of the function.

Hmm, I figured it would only mean calling ConvertFormat with the appropriate scale_space parameter. Of course, if deep_resize could pass that parameter on, it would require only a minor change (I would then just add it to my template).

[madey83]

Here:
https://gitlab.com/uvz/AviSynthPlus-Builds

Thank you :D

[Dogway]

@Boulder: I had a look, it works so unless you use nnedi3. I will study the possibility to call nnedi3wrap through ConvertFormat.

FYI, Windows 10 22H2 has been "out" for a month or more...
Those are insider's preview releases, AFAIK the stable release is happening at the end of the month.
Will surely be updated in the wiki (https://en.wikipedia.org/wiki/Windows_10)when that happens.

@kedautinh12: It's basically the next script, but good luck making it run, it iteratively runs out-of-order calls with the several SceneStats and SMDegrain calls.
You are better off creating a batch script that execute each pass back-to-back, it will run orders of magnitude faster.

# Denoise highly compressed grainy MP4 and regrain back
# First Pass
setmemorymax(2048*4)
DGSource("Q:\source.dgi",cl=0,ct=0,cr=0,cb=0)

SceneStats(mode="Range+Motion")

# Second Pass
ExtractY()
dirt = last
# If this is too slow use a faster spatio-temporal denoiser
SMDegrain(1, 400, ContraSharp=false, RefineMotion=false, LFR=400)

gm = ex_edge (cln,mode="frei-chen", scale=1.0, invert=true).ex_inpand(2,mode="disk")
ex_lutxyz(dirt,gm,"x y - abs z range_max / *") # dirt mask
SceneStats(mode="Stats") # per-shot dirt mask average

# Third Pass
ConvertBits(16)
CCD(15)
mb = Deblock_QED(quant1=30, quant2=40,UV=1)
mb = mb.ex_smooth(1, mode="SG", limit=true, sharp=true)
pre = ex_BM3D(sigma=10,preset="normal",radius=2,UV=1,gpuid=0,tv_range=true)

SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)
# Debanding, optional
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)

# per-shot modulated grain
ScriptClip(function [] () {

avg = propGetAsArray("_SceneStats")[4]
mot = propGetFloat ("_SceneMotion")
navg = avg / (mot + 1)
size = 2*navg + 0.4 # between 0.7 and 1.1 mostly
str = navg + 0.5 # between 0.6 and 0.8 mostly

GrainFactory3mod(g1str=6*str,g2str=8*str,g3str=7*str,g1size=1.20*size,g2size=1.50*size,g3size=1.40*size,g1cstr=0.5,g2cstr=0.3,g3cstr=0.1,temp_avg=1)
} )

ConvertBits(8, dither=1)

[Boulder]

@Boulder: I had a look, it works so unless you use nnedi3. I will study the possibility to call nnedi3wrap through ConvertFormat.

My tests did show a difference between the default value "gamma" and "linear" for scale_space in ConvertFormat when using deep_resize to downscale. I've only used the Zopti presets in deep_resize so NNEDI3 is not involved there.

[guest]

Those are insider's preview releases, AFAIK the stable release is happening at the end of the month.
Will surely be updated in the wiki (https://en.wikipedia.org/wiki/Windows_10)when that happens.

Oh, OK, well, I was obviously misled there...

But why don't you just go to W11 22H2, that's what I use, and it's great, especially once you "tweak" it up :)

[guest]

FrameRateConverterMIX

Would someone be so kind as to give me a basic explanation of what this can do ?

With maybe a simple script :rolleyes:

And is it different to this :-

http://avisynth.nl/index.php/SVPflow

[kedautinh12]

FrameRateConverterMIX

Would someone be so kind as to give me a basic explanation of what this can do ?

With maybe a simple script :rolleyes:

And is it different to this :-

http://avisynth.nl/index.php/SVPflow
Full info for you
https://github.com/mysteryx93/FrameRateConverter

[guest]

Full info for you
https://github.com/mysteryx93/FrameRateConverter

Thanks K, but I have been there several times already.

I'd actually like to know what it is used for...

But as per usual, I can't get it to work for me.

I doubt that I would use it....anyway.

[poisondeathray]

I'd actually like to know what it is used for...


It's for changing framerates using interpolation (in contrast , vs. inserting or deleting frames via blends or duplicates). Think of it as synthesizing "in between" frames at new intermediate points in time, so the result is smoother than blends or dupes. The main issue is artifacts - some types of content work ok, others are terrible

You can use it for slow motion, reversing some types of conversions, adapating to some specific standards where you need a specific frame rate

The original used mvtools2, but dogway's version has been modified to use rife as an option and can produce better results in some scenarios. FRC is more advanced than standard methods because of additional features such as artifact masking and blending

[Dogway]

Oh, OK, well, I was obviously misled there...

But why don't you just go to W11 22H2, that's what I use, and it's great, especially once you "tweak" it up :)

Yeah, Microsoft decided it wasn't a good idea to install on old systems. Anyway I'm not too fond of installing OS in a productive environment that are still too "green". Win11 22H2 might resolve some, but still...

FrameRateConverterMIX

Would someone be so kind as to give me a basic explanation of what this can do ?

With maybe a simple script :rolleyes:

And is it different to this :-

http://avisynth.nl/index.php/SVPflow

Yes, it's similar but CPU mvtools2 based with some masking to hide artifacts. I simply reviewed MysteryX's script to see if I could improve performance, later I added RIFE as he explained.

In any case I ditched the idea and with Asd-g's latest RIFE update I prefer to directly use RIFE (I made a wrapper (https://forum.doom9.org/showthread.php?p=1976257#post1976257) for it), better quality and similar speed, haven't benchmarked though.

Still working on the updates, had an issue yesterday where I almost lost all files from my Desktop :scared: Luckily could restore most with Recuva.

[guest]

Yes, it's similar but CPU mvtools2 based with some masking to hide artifacts. I simply reviewed MysteryX's script to see if I could improve performance, later I added RIFE as he explained.

In any case I ditched the idea and with Asd-g's latest RIFE update I prefer to directly use RIFE (I made a wrapper (https://forum.doom9.org/showthread.php?p=1976257#post1976257) for it), better quality and similar speed, haven't benchmarked though.

Still working on the updates, had an issue yesterday where I almost lost all files from my Desktop :scared: Luckily could restore most with Recuva.

Great explanations from both you & poisondeathray, but I still can't seem to get it to work properly, and does RIFE need any other dependencies ??

Might have to try it out of the ResizersPack...

[guest]

Yeah, Microsoft decided it wasn't a good idea to install on old systems. Anyway I'm not too fond of installing OS in a productive environment that are still too "green". Win11 22H2 might resolve some, but still...

You know you can download a genuine .ISO from MS, and then use Rufus 3.20 to create a bootable USB, and ALL the restrictions are disabled, so you should be able to install it just about anything...

Works for me :)

PS:- Rufus can actually download the .iso itself ;)

UPDATE (just for Dogway):- I just did a test install of W11 22H2, on an OLD (2008) i7 920 CPU, on an ASUS P6T WS PRO....EFI BIOS, worked like a charm :)

[poisondeathray]

and does RIFE need any other dependencies ??


Dependencies are listed under the Requirements section

https://github.com/Asd-g/AviSynthPlus-RIFE

Post any error messages

[kedautinh12]

You need GPU with Vulkan support to use with RIFE

[StainlessS]

You know you can download a genuine .ISO from MS, and then use Rufus 3.20 to create a bootable USB, and ALL the restrictions are disabled, so you should be able to install it just about anything...

Works for me :)

PS:- Rufus can actually download the .iso itself ;)

Could install W11 on external Hard drive via hard drive dock. [I'de BIOS/FIRMWARE disable ALL SSD, Harddrive's before install so as to not be dependent upon existing boot loader],
can use HDV in external dock like you can a USB flash drive or SD Card and boot OS or tools from it.
One of my docks:- https://www.amazon.co.uk/FIDECO-Docking-Station-Aluminum-External/dp/B075TZJMWW/ref=sr_1_3?crid=3QQIJLZWES0SV&keywords=fideco&qid=1665891234&qu=eyJxc2MiOiI0LjI0IiwicXNhIjoiMy44NiIsInFzcCI6IjMuNTgifQ%3D%3D&sprefix=fideco%2Caps%2C228&sr=8-3
FIDECO Aluminum Hard Drive Docking Station, USB 3.0 Docking Station for 2.5 and 3.5 inch SATA HDD or SSD, Support Offline Clone and 2x 16TB Hard Drives
Above, just for testing, obviously speed would suffer a bit compared to eg internal nvme SSD.

EDIT: I was booting emergency Linux Cinnamon Mint [already got mint on SSD with W10] from dock HDV, but recent update to HP FIRMWARE causes boot failure on mint and Dragon OS [linux], but other linux
distros work OK [eg LMDE ie Debian edition mint]. Probably a problem with [EDIT: Ubuntu based] mint booting rather than HP firmware (some extra security added).
HP will not let me revert to old firmware, and Mint from New Setup has same problem, so we are a bit stuffed.

[guest]

You need GPU with Vulkan support to use with RIFE

Hi K,

I had a sneaking suspicion that I would need that....now I need to suss out my GPU's.

Cheers

[madey83]

@Dogway,

could you please tell me how can i use more GPU power/performance in regard using prefilter=7? Currently it uses only 15-20% of my mobile RTX2060.

[tormento]

I saw the CCD filter named many times here.

I have tried to find with no luck. Where can I find it?

[Reel.Deel]

I saw the CCD filter named many times here.

I have tried to find with no luck. Where can I find it?

Avisynth-Scripts/EX mods/DeblockPack.avsi (https://github.com/Dogway/Avisynth-Scripts/blob/master/EX%20mods/DeblockPack.avsi)

[tormento]

DeblockPack
TIL

Thanks!

[LeXXuz]

@Dogway,

could you please tell me how can i use more GPU power/performance in regard using prefilter=7? Currently it uses only 15-20% of my mobile RTX2060.

DGDenoise() is very fast and well optimized as CUDA filter. Your CPU will most likely be the bottleneck. That's why your GPU usage is only ~20%.

[madey83]

DGDenoise() is very fast and well optimized as CUDA filter. Your CPU will most likely be the bottleneck. That's why your GPU usage is only ~20%.

Hi LeXXuz,

thank you for answer.
have you used Dogway's settings from SMDegrain file or do you have some additional configuration for prefilter=7 to do more denoise on GPU and gain some CPU performence for x265 encoder?


Edit:

Could you please advice what could be the best avisynth filter (performance/efficiency) to do resize from 2160p to 1080p?

[tormento]

DGDenoise() is very fast and well optimized as CUDA filter. Your CPU will most likely be the bottleneck. That's why your GPU usage is only ~20%.
I prefer (a lot) BM3D_CUDA filter. IMHO DGDenoise is a bit too soft when used as a prefilter too.

[madey83]

I prefer (a lot) BM3D_CUDA filter. IMHO DGDenoise is a bit too soft when used as a prefilter too.

Hi tormento,

could you please share your settings for it?

[LeXXuz]

I prefer (a lot) BM3D_CUDA filter. IMHO DGDenoise is a bit too soft when used as a prefilter too.

I'd say that highly depends upon the source material and the kind of noise you're facing. I always use the show function to have a look at the preview how good the prefiltering works. I noticed with some types of noise, block matching filters can produce terrible artifacts where non-local means don't. Here, I clearly prefer NLM or even a simple prefilter like Fluxsmooth which also does a good job for many scenarios at great speeds.

Hi LeXXuz,

thank you for answer.
have you used Dogway's settings from SMDegrain file or do you have some additional configuration for prefilter=7 to do more denoise on GPU and gain some CPU performence for x265 encoder?

Could you please advice what could be the best avisynth filter (performance/efficiency) to do resize from 2160p to 1080p?

There really is no best way to do something in video filtering. The art is to find a good balance between noise removal and keeping as much source detail as possible.

Sadly, there is no general recipe for noise removal. If you want good results, you always have to tinker around anew for every source.

If you need smaller files you either have to increase the strength of your filtering or have to chose smaller bitrates in your encoder (or set higher CRF values if you do CRF encodes).

Look into the prefiltering section of SMDegrain (lines 252-264).
There you'll find the used settings for BM3D (prefilter 6) and DGDenoise (prefilter 7). You can tweak the strength/sigma values here.
But don't overdo it! The default values here are already a fair compromise between noise removal and detail retention. Too strong values may oversmooth your source and you will lose too much detail. ;)

Hi tormento,

could you please share your settings for it?

You could just try prefilter=6 :)

[kedautinh12]

Hi tormento,

could you please share your settings for it?

settings from Dogway:
# Prefiltering with radius 3 for more coherence. I found preset "normal" to clean edges better.
pre=ex_BM3D(sigma=10,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)
# Large radius for more coherence. LFR to recover some smearing. limits=false to don't sharpen motion areas
SMDegrain(6, 400, prefilter=pre, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)

[tormento]

I tried CCD and it halves my fps... is there any lighter workaround?

[Dogway]

Just a heads up, I was holding back many updates so I decided to upload what I had with TransformsPack which was many changes and features, and attack chroma location from a clean slate.

FrameRateConverter was also updated with a new preset RIFE-HQ, which is based on "Slowest", while RIFE preset is based on "Slower". This is my last version for FRC as I consider it now legacy and switch my efforts to OpticalFlowRIFE(), the wrapper I made for Asd-g's port of RIFE for avisynth.

By the way, it seems Windows 10 22H2 stable was released yesterday. I will be looking into it after I update ResizersPack. IMO installing Win11 on a not supported CPU is risky and bothersome, you have to depend on hacks that might or not work, and later pray for an update to don't ruin it all. Besides it's still too green, many BSODs as seen recently for Nvidia cards, taskbar issues (might be fixed with yesterday's update), and generally no drivers for a PC 10 years old like mine. I will install it when I get a new PC in a few years time when AVX-512 is again a thing, prices go down and Win11 is more mature.

[kedautinh12]

Ryzen 7000 series support AVX 512 now. I think you can buy it :D
Any chance for speed-up RIFE when RIFE updated with more new models??

[tormento]

IMO installing Win11 on a not supported CPU is risky and bothersome
Enough you can get TPM in some way.

I managed to find a TPM v1.2 HW key for my motherboard and I am using Win 11 since day one on a i7-2600k.

[DTL]

RIFE can be also tested as pre-degrain for SMDegrain (or may be for MAnalyse only) - https://forum.doom9.org/showthread.php?p=1976763#post1976763 . But the default 'model' may give some artifacts at repeating structures and also the scenechange may need tweaking.

[guest]

By the way, it seems Windows 10 22H2 stable was released yesterday. I will be looking into it after I update ResizersPack. IMO installing Win11 on a not supported CPU is risky and bothersome, you have to depend on hacks that might or not work, and later pray for an update to don't ruin it all. Besides it's still too green, many BSODs as seen recently for Nvidia cards, taskbar issues (might be fixed with yesterday's update), and generally no drivers for a PC 10 years old like mine. I will install it when I get a new PC in a few years time when AVX-512 is again a thing, prices go down and Win11 is more mature.

I doubt that you would have ANY issues, I have been using W11 on "unsupported" CPU's, etc, for quite a while now, and have had many successful updates along the way.

Like I mentioned before, you can download a genuine .iso from MS, and when using Rufus to create a bootable USB, it's "kill's" ALL the annoying problems that a "normal" W11 install has, easy peasy.

You can also modify/customise the installation setup using NTLite.

And tbh, I have had more problems with my AMD GPU, than nVidia.

You can also customise the nVidia drivers, so they ONLY install the driver, and not all the other crap that can cause problems.

https://www.techpowerup.com/nvcleanstall/

And there are so many other "addon's" that make W11 a pleasure to use, and easy on the eye :), and yesterday's update added even more good stuff.

If you wait too long, it will be W12, and you'll have the "mature" problem all over again....no time like the present.

[tormento]

I have tried the following script on a 1080p (badly upsampled) anime:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
#LoadPlugin("D:\Eseguibili\Media\DGHDRtoSDR\DGHDRtoSDR.dll")
DGSource("F:\In\Saishuu heiki kanojo\01.dgi", fieldop=1)
DeBicubicResizeMT(target_width=960,target_height=540,threads=1,b=0.3,c=0.3)
nnedi3resize(1920,qual=2,sharpness=30)
fmtc_bitdepth (bits=8,dmode=7)
Prefetch(4)

It jumps:

https://i3.lensdump.com/i/1yjaLM.png

Tried with fmtc_resample (960, 540, kernel="bicubic", a1=0.3, a2=0.3, invks=True) instead of DeBicubicResizeMT(target_width=960,target_height=540,threads=1,b=0.3,c=0.3)

too but I get the very same error. If I delete the downsize line, it works fine but with no effect (of course).

I can't find any reference about dh parameter.

[tormento]

Another error:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
#LoadPlugin("D:\Eseguibili\Media\DGHDRtoSDR\DGHDRtoSDR.dll")
DGSource("F:\In\Tatami\01.dgi")
ConvertBits(16)
CCD(15) # Remove big chroma "blocks"

# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40,UV=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

# Prefiltering with radius 3 for more coherence. I found preset "normal" to clean edges better.
pre=ex_BM3D(sigma=10,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)

# Large radius for more coherence. LFR to recover some smearing. limits=false to don't sharpen motion areas
SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)
# Debanding to reduce posterization in walls/defocused backgrounds
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)
Prefetch(4)

https://i2.lensdump.com/i/1yjhaQ.png

P.S: I updated to your last versions before trying these 2 scripts.

[kedautinh12]

I have tried the following script on a 1080p (badly upsampled) anime:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
#LoadPlugin("D:\Eseguibili\Media\DGHDRtoSDR\DGHDRtoSDR.dll")
DGSource("F:\In\Saishuu heiki kanojo\01.dgi", fieldop=1)
DeBicubicResizeMT(target_width=960,target_height=540,threads=1,b=0.3,c=0.3)
nnedi3resize(1920,qual=2,sharpness=30)
fmtc_bitdepth (bits=8,dmode=7)
Prefetch(4)

It jumps:

https://i3.lensdump.com/i/1yjaLM.png

Tried with fmtc_resample (960, 540, kernel="bicubic", a1=0.3, a2=0.3, invks=True) instead of DeBicubicResizeMT(target_width=960,target_height=540,threads=1,b=0.3,c=0.3)

too but I get the very same error. If I delete the downsize line, it works fine but with no effect (of course).

I can't find any reference about dh parameter.

Add propSet("_FieldBased", 0) before nnedi3resize

[kedautinh12]

Another error:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
#LoadPlugin("D:\Eseguibili\Media\DGHDRtoSDR\DGHDRtoSDR.dll")
DGSource("F:\In\Tatami\01.dgi")
ConvertBits(16)
CCD(15) # Remove big chroma "blocks"

# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40,UV=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

# Prefiltering with radius 3 for more coherence. I found preset "normal" to clean edges better.
pre=ex_BM3D(sigma=10,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)

# Large radius for more coherence. LFR to recover some smearing. limits=false to don't sharpen motion areas
SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)
# Debanding to reduce posterization in walls/defocused backgrounds
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)
Prefetch(4)

https://i2.lensdump.com/i/1yjhaQ.png

P.S: I updated to your last versions before trying these 2 scripts.

Maybe you put deblock.dll and DGDecode.dll in same folder got error cause DGDecode has Deblock() function too

[anton_foy]

Maybe you put deblock.dll and DGDecode.dll in same folder got error cause DGDecode has Deblock() function too

I get the same error and I even removed DGdecode to load from my script and moved the dll to another folder.

[Reel.Deel]

https://i2.lensdump.com/i/1yjhaQ.png


"Deblock_deblock" means that the plugin must be named "deblock.dll" otherwise you will get an error.

Docs (http://avisynth.nl/index.php/Plugins#Plugin_Autoload_and_Conflicting_Function_Names):
AviSynth's DLLName_function() feature automatically creates prefix aliases; so for example, foo.dll's bar() function may be called as foo_bar().

Maybe you put deblock.dll and DGDecode.dll in same folder got error cause DGDecode has Deblock() function too

Official x64 DGDecode does not have the Deblock function, and even if it does have the unofficial x64 DGDecode loaded it would not cause the error he has.

[kedautinh12]

I think need change Deblock_deblock to deblock won't meet same error in future anymore

[tormento]

Let's wait for the final word of Dogway :)

[Dogway]

You need to download Deblock (https://github.com/299792458m/Avisynth-Deblock/releases) plugin.

The plugin prefix Deblock_ is to not be confused with other Deblock called functions, it was a change in 2014 by GMJCZP.
It shouldn't trigger an error, it doesn't for me. As Reel.Deel stated the plugin should be called Deblock.dll (case insensitive).

As for the nnedi3resize bug I will try to do a commit later today with the recent changes.

[kedautinh12]

nnedi3resize bug had same bug with deep_resize when use with AnimeITVC or TDecimate().TFM()

[Reel.Deel]

The plugin prefix Deblock_ is to not be confused with other Deblock called functions, it was a change in 2014 by GMJCZP.
It shouldn't trigger an error, it doesn't for me. As Reel.Deel stated the plugin should be called Deblock.dll (case insensitive).

The problem is that the x64 binary from MysteryX is named Deblock-x64.dll. I doubt many are changing of the name of the binaries. I just download them and stick in the auto-load folder.

I also use 299792458m version so the binary is already named deblock.dll.

[kedautinh12]

But if ver from real.finder, i think Deblock_deblock change to deblock won't have any error when use different others name for Deblock.dll
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.5%20and%20up/Deblock_QED_MT2.avsi

[tormento]

You need to download Deblock (https://github.com/299792458m/Avisynth-Deblock/releases) plugin.
Where can I find a build? There are sources only there.

[Reel.Deel]

Where can I find a build? There are sources only there.

In the Release and x64/Release folders: https://github.com/299792458m/Avisynth-Deblock/tree/master/Src

[tormento]

/Avisynth-Deblock/tree/master/Src
Looking for a build inside a src directory, unfortunately, goes beyond the capabilities of my OCD mind. :p

[DTL]

Ryzen 7000 series support AVX 512 now. I think you can buy it :D
Any chance for speed-up RIFE when RIFE updated with more new models??

As I see AVS RIFE is based on rife-ncnn-vulkan and it is based on ncnn https://github.com/Tencent/ncnn that can support both CPU and GPU on windows. So may be if CPU is underloaded or much faster it may help to ncnn. Need to ask RIFE and rife-ncnn-vulkan developers if they can support both CPU and GPU execution of ncnn.

[tormento]

You need to download Deblock plugin.
Downloaded and installed but the error about deblock_deblock is still there.

Looking at the dll itself, it has a Deblock function but not a deblock_deblock one.

[kedautinh12]

Downloaded and installed but the error about deblock_deblock is still there.

Looking at the dll itself, it has a Deblock function but not a deblock_deblock one.

You can change deblock_deblock to deblock in script. Error will gone :D

[Reel.Deel]

Downloaded and installed but the error about deblock_deblock is still there.

Looking at the dll itself, it has a Deblock function but not a deblock_deblock one.

Did you rename the plug in to something else? The dll must be named "deblock.dll".

[tormento]

You can change deblock_deblock to deblock in script. Error will gone :D
I have changed deblock_deblock to deblock in the script but AVSPmod crashes when I try to preview, without any error message.

In VirtualDub2 I get:

An instruction not supported by the CPU was executed in module 'VirtualDub64'.

If Deblock.dll needs something more than AVX, on my Sandy Bridge I am f*cked.

Anyway, the script is:
SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
#LoadPlugin("D:\Eseguibili\Media\DGHDRtoSDR\DGHDRtoSDR.dll")
DGSource("F:\In\Tatami\01.dgi")
ConvertBits(16)
CCD(15) # Remove big chroma "blocks"

# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40,UV=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

# Prefiltering with radius 3 for more coherence. I found preset "normal" to clean edges better.
pre=ex_BM3D(sigma=10,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)

# Large radius for more coherence. LFR to recover some smearing. limits=false to don't sharpen motion areas
SMDegrain(6, 400, prefilter=pre, mfilter=mb, ContraSharp=true, RefineMotion=true, plane=4, LFR=300, limits=false, DCTFlicker=false)
# Debanding to reduce posterization in walls/defocused backgrounds
GradFun3plus(thr=0.25, radius=10, mask=2, smode=0,UV=1)

[kedautinh12]

opt in deblock plugin of 299792458m will auto-detect, if you use cpu had AVX and below, opt will choose sse4.2. Try add opt=2 in deblock() or maybe you copy wrong ver: x86 in VirtualDub64

[tormento]

opt in deblock plugin of 299792458m will auto-detect, if you use cpu had AVX and below, opt will choose sse4.2. Try add opt=2 in deblock() or maybe you copy wrong ver: x86 in VirtualDub64
Nope, I did it right.

As far as I can see, deblock doesn't have a opt switch.

[DTL]

An instruction not supported by the CPU was executed in module 'VirtualDub64'.

If Deblock.dll needs something more than AVX, on my Sandy Bridge I am f*cked.



May be try to add manual limiting of CPU in AVS in the script with SetMaxCPU ?

Like SetMaxCPU("mmx+, sse+, sse2+, sse3+, ssse3+, sse4+, sse4.1+, sse4.2+, avx+") . May be even start from SetMaxCPU("none") to check if it help any.

But it will not help if executable was compiled for AVX2 or later execution environment and compiler may add some AVX2 or newer instructions not guarded by AVS environment or internal detector of MaxCPU features avaialble.

The project build settings lists
<EnableEnhancedInstructionSet>AdvancedVectorExtensions2</EnableEnhancedInstructionSet>
https://github.com/299792458m/Avisynth-Deblock/blob/9802e0366dc17c693bb310c7f0441e28debdac11/Src/Deblock.vcxproj#L98

So it most probably compiled with instructions used up to AVX2. So someone need to download source and compile for SSE2 as lower option in typical visual studio or any other compatible compiler.

[Reel.Deel]

As far as I can see, deblock doesn't have a opt switch.

299792458m Deblock does have an opt parameter. But you might be onto something. When I use deblock() it works but when I use deblock_deblock() or deblock(opt=x) I get the "An instruction not supported by the CPU was executed in module 'VirtualDub64'." error.


The project build settings lists
<EnableEnhancedInstructionSet>AdvancedVectorExtensions2</EnableEnhancedInstructionSet>
https://github.com/299792458m/Avisynth-Deblock/blob/9802e0366dc17c693bb310c7f0441e28debdac11/Src/Deblock.vcxproj#L98

So it most probably compiled with instructions used up to AVX2. So someone need to download source and compile for SSE2 as lower option in typical visual studio or any other compatible compiler.

https://i.ibb.co/fC8hnrn/deblock-compile.png

Should it be "Not Set" ?

Edit: compiled with "Not Set" and now the opt parameter works without crashing ...

[kedautinh12]

Nope, I did it right.

As far as I can see, deblock doesn't have a opt switch.

Are you sure??
https://github.com/299792458m/Avisynth-Deblock#moded-by-299792458m

[kedautinh12]

Can you share "not set" compiled file, Reel.Deel??

[tormento]

Are you sure??
Nope. Another pair of glasses is needed. :cool:

Anyway I have to edit the avsi to use it. I will try.

[Boulder]

https://drive.google.com/file/d/1AO1_n7dKhjEAbb6Au5qTL9RrfzFHyzjP/view?usp=sharing

Straight from the Avs+ wiki.

[Reel.Deel]

https://drive.google.com/file/d/1AO1_n7dKhjEAbb6Au5qTL9RrfzFHyzjP/view?usp=sharing

Straight from the Avs+ wiki.

I forgot it was there. Asd added that. No wonder when I went to replace the deblock plugin it showed a more recent date.

Edit: updated the Deblock wiki page (http://avisynth.nl/index.php/DeBlock) with 299792458m's version built by Asd. I modified the folder structure of the zip so that the binaries are not inside the src folder: https://files.videohelp.com/u/223002/Avisynth-Deblock_299792458m_noAVX2req.7z

[DTL]

https://i.ibb.co/fC8hnrn/deblock-compile.png

Should it be "Not Set" ?



Not set is something undefined (may be something like SSE/SSE2 to make not completely poor build). I typically set line ending with /arch:SSE2 for SSE2 builds. It is expected at 2022 year with x64 CPUs most users have at least SSE2.

[StvG]

Not set is something undefined (may be something like SSE/SSE2 to make not completely poor build). I typically set line ending with /arch:SSE2 for SSE2 builds. It is expected at 2022 year with x64 CPUs most users have at least SSE2.

The default arch is SSE2. For x64 SSE2 is also the minimum arch.

[tormento]

@Dogway

Is possible to have a porting of maa2 (http://avisynth.nl/index.php/MAA2) inside your tools?

[kedautinh12]

@Dogway

Is possible to have a porting of maa2 (http://avisynth.nl/index.php/MAA2) inside your tools?

real.finder was updated it
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.6%20and%20up/maa2.avsi

[madey83]

real.finder was updated it
https://github.com/realfinder/AVS-Stuff/blob/Community/avs%202.6%20and%20up/maa2.avsi

hi,

what is the benefit of using maa2 filter?

[kedautinh12]

hi,

what is the benefit of using maa2 filter?

Anti-aliasing scripts

[tormento]

real.finder was updated it
Thanks. Does it support Asd-g porting of VS Sangnom2?

I was asking Dogway as he did a real good job optimizing scripts within his extools "library".

I read about the use of nnedi3 as antialiasing tool but don't really know how. It would be even faster as it has a OpenCL port.

[kedautinh12]

Yes, it supports Asd-g's porting

[madey83]

Yes, it supports Asd-g's porting

hi,

could i ask for some example how to use it with SMDegrain, LSFplus, GradFun3plus

[kedautinh12]

hi,

could i ask for some example how to use it with SMDegrain, LSFplus, GradFun3plus

You only need use it when your video had aliasing

[madey83]

You only need use it when your video had aliasing

@kedautinh12

based on what criteria i will know if my video needs this filter?

That this do the same:
# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40,UV=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

?

[kedautinh12]

@kedautinh12

based on what criteria i will know if my video needs this filter?

That this do the same:
# Remove blocking and smooth out jagged edges (only applies where motion match fails)
mb=Deblock_QED(quant1=30, quant2=40,UV=1)
mb=mb.ex_smooth(1, mode="SG", limit=true, sharp=true)

?
That script used if your video had blocking. maa2 use in some case your video had aliasing. Example for anti-aliasing:
https://forum.doom9.org/showthread.php?p=1060089#post1060089

[madey83]

That script used if your video had blocking. maa2 use in some case your video had aliasing. Example for anti-aliasing:
https://forum.doom9.org/showthread.php?p=1060089#post1060089


:thanks:

[Dogway]

Ok sorry for the delay, I couldn't deal with ResizersPack since I was involved with WhitePoint() for the last few days non-stop, but now that's finished I will resume ResizersPack from tomorrow.

What I did with WhitePoint was to calculate a new fit for the Planckian and Daylight locus of the 1931 matching function, minimizing errors. The twist here is that I used new derivations for the temperatures with the colour-science Python module. But not only I calculated new chromaticity coordinates, I went as far as recalculate them from the SPD (Spectral Power Distribution) with updated universal constants (Boltzman, Avogadro, etc). Also the SPDs were linear interpolated from 10nm intervals, I reinterpolated them with Sprague interpolation as recommended now by the CIE. The same procedure was done for the 1964 10º Standard Observer color matching function, which is a novel thing since nobody tried to fit a locus for this observer (that I know of).

I know this might all look like a free offshoot from the official standard specifications, but it follows the rationale I chose for TransformsPack which is to derive all the values. My intention is to also put the fits in CMF() to good use to derive values from a SPD standpoint for any matching function (ie. WhitePoint in CIE 2015 2º), this is the goal for the work-in-progress Chromaticity_xy() function.

Matching functions are and will always be the weakest link in any color science/management procedure, but using derivations will ensure the most accurate representation for the given CMF, only limited in AviSynth by its single float precision constraint.


On another note, last week I updated EOTF_2084() and now is production ready. Paired with TM_2446C() tonemapper it can give a good SDR rendition of the HDR counterpart.

"420P10 source"
ConvertBits(32)
YUV_to_RGB("2020")

EOTF_2084()
TM_2446C(k1=1,k3=0.52,EOTFi="linear")

ConvertFormat(1,1,"RGB","420",cs_out="709",OETFi="linear",EOTFi="1886",tv_out=true)
ConvertBits(8,dither=1)

In the future the plan is to implement this within ConvertFormat().
I also want to output peak white stats from ScenesPack() and do some IQM averaging for the tonemapper. I will be adding more tonemappers as time permits.

[ENunn]

I'm getting this error whenever I use QTGMC+ with AVISource. I started to get this error after updating it.
https://i.imgur.com/05y3lPt.png

This doesn't happen when I load the video with LSMASH, but loading and scrubbing is just way too slow. Is there a fix?

I don't recommend you loading interlaced with avisource since it doesn't index the frames.
You can try LSmash, FFMS2, DGIndex or DGDecNV. I prefer the later two because it will detect parity swaps on interlaced content.

Going back to this problem, using LWLibav works (although I'm not a fan because of how slow it is to index and I can't use DGDecNV because the source codec is FFV1). However, I'm using a Virtualdub filter (CCD) before I deinterlace, so I converted to RGB32 and then to YV24, however I get this exact same error when I run the latest version of QTGMC after it. I grabbed an older version of it that I downloaded back in August, and the issue goes away.

My script is like this:
setmemorymax(63448)
v = lwlibavvideosource("G:\virtualdub\tape transfers\g4techtv and misc 2004 cap 2.mkv", fpsnum=30000,fpsden=1001)
a = lwlibavaudiosource("g:\recordings\g4techtv and misc 2004.w64")
audiodub(v,a)
delayaudio(-0.100)
assumetff().converttoyuv422(matrix="rec601", interlaced=true).convertbits(10)
#Crop(8, 4, -24, -6)
#tweak(bright=-23.5, cont=1.11, coring=false, dither=true).convertbits(8)
#Levels(85, 1, 1008, 0, 1023, coring=false,dither=true).convertbits(8)
Levels(85, 1, 1008, 0, 1023, coring=false,dither=true).tweak(hue=-3, coring=false, dither=true).convertbits(8)
#turnRight().Histogram().TurnLeft()
Trim(68, 628838)
LoadVirtualdubPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\ccd_64bit.vdf", "CCD", 1)
ConverttoRGB32(matrix="rec601",interlaced=true)
CCD(10,1)
ConvertToYv24(matrix="rec601",interlaced=true)
qtgmcp(preset="faster")

Any fixes?

[kedautinh12]

Are you using this latest ver??
https://gitlab.com/uvz/AviSynthPlus-Builds

And i think L-Smash Source faster in index than ffms and DGDecNV

[Dogway]

FFV1? That had to be converted from another format.
You can do two things, use Avisynth's CCD() (https://github.com/Dogway/Avisynth-Scripts/blob/5993a9c51144f0778927c54906ab9a22393e7071/EX%20mods/DeblockPack.avsi#L227) or sideload the original file with DGDecNV and copy its frameproperties to the FFV1 video.

Second option looks like this:

orig = DGSource("original.dgi")
ffvideosource("FFV1_YUV444")

propCopy(orig,props="_ChromaLocation", exclude=true)

[tormento]

Would you please expose all the parameters for NNEDI3CL 1.0.4 version in the wrapper?

What is the advantage of using it instead of a direct call? I mean, how do the various script added values interact with native NNEDI3CL ones? Such as sharpness.

[Dogway]

What settings do you miss for NNEDI3CL?

You mean advantage of using nnedi3wrap()? nnedi3 was fine as it was, but NNEDI3CL wasn't, it doesn't have a factor multiplier so a loop is needed, also it doesn't fix pixel/chroma shift. Making a wrapper was also useful to simply change from cpu to gpu nnedi3 without tinkering with settings. I also made it simpler to deal with interlaced content, 'dh' has to be set to true for interlaced, then frameprops are honored. So several QoL changes, for myself and whoever finds it useful. It makes it simpler when implemented into SMDegrain, deep_resize(), etc.

I haven't resumed yet the work in ResizersPack because I was researching on typefaces, for coding in general but also for a side project I have where legible fonts are much needed. The problem I had wasn't Lucida Console, it's monospaced, but the grammar scheme was mixing bold and regular fonts, after I removed the bold types everything aligned nicely. I also tested other mono fonts, but Lucida Console really grew on me, everything else is too condensed (vertical), or interline space is too big.

[madey83]

hi,

could someone advice what to do with this issue:

Script Error

BM3D: 'cudaMallocPitch( &d_src.data, &_d_pitch, max_width * sizeof(float), (final_() ? 2 : 1) * num_input_planes * temporal_width * max_height)' failed: CUDA-capable device(s) is/are busy or unavailable
(E:\4k_encode\Avisynth-Scripts-master\SMDegrain v3.5.5d\SMDegrain v3.5.5d.avsi, line 1094)
(E:\4k_encode\Avisynth-Scripts-master\SMDegrain v3.5.5d\SMDegrain v3.5.5d.avsi, line 264)
(E:\movie.avs, line 146)

SMDegrain call: SMDegrain(tr=2, thSAD=275, thSCD1=415, thSCD2=115, prefilter=6) and this

and this:
BM3D: 'cudaMallocPitch( &d_src.data, &_d_pitch, max_width * sizeof(float), (final_() ? 2 : 1) * num_input_planes * temporal_width * max_height)' failed: CUDA-capable device(s) is/are busy or unavailable
(E:\4k_encode\Avisynth-Scripts-master\SMDegrain v3.5.5d\SMDegrain v3.5.5d.avsi, line 1094)
(E:\movie.avs, line 145)

for this call:
pre=ex_BM3D(sigma=10,preset="normal",radius=3,UV=1,gpuid=0,tv_range=true)
SMDegrain(tr=2, thSAD=275, thSCD1=415, thSCD2=115, prefilter=pre)

this started when i have updated drivers to my RTX 2060

edit:
reboot solved the issue. but i did reboot many times, so i do not really knew what fixed it.

[tormento]

What settings do you miss for NNEDI3CL?
Field, to override, force or ignore frame properties.
DW an DH I can't find the utility right now but who knows.
Planes, to achieve some speed.
ST to give it a run and see if it's useful.
Console really grew on me, everything else is too condensed (vertical), or interline space is too big.
What about variable fonts? I find them really nice to use.

[Dogway]

Ok so:
field=-2 (interlaced forced. Automatic order)
field=-1 (automatic)
field= 0 (progressive forced)
field= 1 (interlaced forced. "bottom-field first" forced)
field= 2 (interlaced forced. "top-field first" forced)

DW and DH go away.

'ST' is deprecated I think, the issue it pretended to fix was solved AFAIK.
Planes? How that works? You can't resize only one plane, or deinterlace only one plane... If your thought is more like 420 to 444 you can try UVrecon, maybe directly using ConvertFormat which handles plane multiplexing.

EDIT: oops, looks like I already did pass the 'planes' arg from NNEDI3CL, it's an int_array though


Variable fonts depend on software support I think because in Notepad2 and Notepad3 they didn't seem to work. Maybe Visual Studio Code? where do you use it?

[ENunn]

Are you using this latest ver??
https://gitlab.com/uvz/AviSynthPlus-Builds
Didn't even know there was a new version out, thanks. It didn't fix the issue sadly.

And i think L-Smash Source faster in index than ffms and DGDecNV
Still really slow for my cases.

FFV1? That had to be converted from another format.
It was, the original file was huffyuv. I converted it to FFV1 for the file size decrease while still keeping it lossless. However, the issue happens regardless of source.

You can do two things, use Avisynth's CCD() (https://github.com/Dogway/Avisynth-Scripts/blob/5993a9c51144f0778927c54906ab9a22393e7071/EX%20mods/DeblockPack.avsi#L227)...

Didn't even know that was a thing! :p Anyways, I get this error:
https://i.imgur.com/HH52eoY.png
My source is YUY2.

...or sideload the original file with DGDecNV and copy its frameproperties to the FFV1 video.
I don't have the original file unfortunately. Even if I did, it doesn't seem to support huffyuv.
https://i.imgur.com/W8bhmuO.png

[Dogway]

Ok, I will update soon, meanwhile edit the first CombinePlanes line with:
a4 = CombinePlanes(y.BicubicResize(w/2, is422(a) ? h : h/2, -0.5, 0.3), a, planes="YUV", pixel_type="YUV444P"+string(bi==32 ? "S" : bi))

Then you have to preconvert the 422 to planar and call with CCD():
ConvertToYUV422()
CCD()

Try to play a bit with the CCD() values so the effect scales to your artifacts.

[kedautinh12]

Still really slow for my cases.



You want fast like Directshowsource?? But it't almost error accurate frame and you're greed. I think more fast more cost error. Why you don't still waiting CPU can support it to below 1s in Index :D

[tormento]

Variable fonts depend on software support I think because in Notepad2 and Notepad3 they didn't seem to work. Maybe Visual Studio Code? where do you use it?
I use multiple editors, Notepad3 (https://github.com/rizonesoft/Notepad3/issues/1129) too. You need to have OS support and enable DirectWrite (Direct 2D) rendering in the software configuration. Thus doing, you have full variable font support.

[Adub]

This might be an ill informed question, but while reading the SMDegrain source code, the use of searchparam seems a bit odd.

https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain%20v3.5.5d/SMDegrain%20v3.5.5d.avsi#L171

Notably, when using search=4 (like in the case of RefineMotion), searchparam values range from 1-5, all of which seems quite low given the MVTools documentation:

> search = 4 : Hexagon search, searchparam is the range. (similar to x264).

For x264, the 'merange' defaults to around 16, and can be scaled up for (U)HD footage to values like 24, 32, etc.

Given this, using range values of 1, 2, 5, etc seem extremely small when using search=4.

[Dogway]

The performance to quality ratio is going to drop severely when raising the range (and not necessarily leads to better quality), there's no need here since we already have RefineMotion. The exact values were derived from Zopti optimized pareto fronts, you can read some of it here (https://forum.doom9.org/showthread.php?t=175723&page=14) but most of my tests aren't published.

[DTL]

For x264, the 'merange' defaults to around 16, and can be scaled up for (U)HD footage to values like 24, 32, etc.

Given this, using range values of 1, 2, 5, etc seem extremely small when using search=4.

MAnalyse use hierarchical search with many levels of details (each level is 2x smaller). So searchparam is the search range at each level. It is not directly equal to x264 search range. So with MAnalyse search range is about equal to x264 if limit levels to 1 and may be use pel=1. It _may_ be sometime useful to save from too long bad MVs (like at no detail noise only areas).

Typically search radius =2 at each level give good enough result and increasing it mostly drops performance with may be very low quality gain.

[ENunn]

Ok, I will update soon, meanwhile edit the first CombinePlanes line with:
a4 = CombinePlanes(y.BicubicResize(w/2, is422(a) ? h : h/2, -0.5, 0.3), a, planes="YUV", pixel_type="YUV444P"+string(bi==32 ? "S" : bi))

Then you have to preconvert the 422 to planar and call with CCD():
ConvertToYUV422()
CCD()

Try to play a bit with the CCD() values so the effect scales to your artifacts.

Thanks for your help! This worked!

You want fast like Directshowsource?? But it't almost error accurate frame and you're greed. I think more fast more cost error. Why you don't still waiting CPU can support it to below 1s in Index :D

I'm not expecting miracles but when you're dealing with 6-8 hour long tape transfers it can get really slow. Wish there was something as good as lwlibav but faster and supported FFV1.

Yuck to DirectShowSource

[Boulder]

I'm not expecting miracles but when you're dealing with 6-8 hour long tape transfers it can get really slow. Wish there was something as good as lwlibav but faster and supported FFV1.

Are you using an SSD or a regular HDD? I'd expect the hard drive read performance playing a big part if the file is big.

[ENunn]

Are you using an SSD or a regular HDD? I'd expect the hard drive read performance playing a big part if the file is big.

HDD's, don't got the space to put them on my SSD sadly. File sizes can be 150-180gb at most.

[StainlessS]

Well if its that slow, why not take a nap, take dog for a walk, or go feed the ducks.
You dont have to sit and time it. :)
(I've just ordered a 1TB 2.5" sata SSD for £61.00, prices are coming down) :- https://www.amazon.co.uk/dp/B07YD579WM/ref=pe_27063361_485629781_TE_item_image

EDIT: Or here a 1TB Crucial P2 nvme @ £60.00:- https://www.amazon.co.uk/Crucial-CT1000P2SSD8-Internal-2400-NAND/dp/B089DNM8LR/ref=sr_1_2?crid=37HYTNISNX7GY&keywords=crucial+p2&qid=1667418761&qu=eyJxc2MiOiIyLjMyIiwicXNhIjoiMS4zNyIsInFzcCI6IjEuMDkifQ%3D%3D&s=computers&sprefix=crucial+p2%2Ccomputers%2C139&sr=1-2

I've got a P1 (not quite as good as P2) and two P5 PLUS [4th gen PCI-e nvme], which may be a bit overkill on 3rd gen PCI-e as you only get half gen 4 speed.

Here a REALLY GOOD report on nvme SSD, and which to buy [EDIT:2019]:- https://www.youtube.com/watch?v=GlGjd1GZWdo
For most people it dont matter much which one you buy, so long as you have one.

I only bought 4th gen nvme crucial P5 Plus, in hope that I would one day have 4gen PCI-e, and just yesterday I ordered a
(2nd hand) Lenovo M70Q Gen 2 mini /i5-11400T/8GB Ram/256GB SSD/W10/B :- https://uk.webuy.com/product-detail/?id=sdeslenm70q96b&categoryName=desktops-windows&superCatName=computing&title=lenovo-m70q-gen-2-mini-i5-11400t-8gb-ram-256gb-ssd-w10-b&referredFrom=search&queryID=a4265986dbfa8ba48634a9fcbd5f6090&position=1
which does have 4th gen PCI-e, and also AVX512 which really persuaded me to get it. (its probably a bit slow due to being a tiny little thing and low clock speed),
but I also wanted to try out the AVX512 when it becomes commonplace.

Lenovo M70Q Gen 2 mini /i5-11400T: Tiny little thing (about 7.5" square by 1.75 inches)
https://www.amazon.co.uk/Lenovo-ThinkCentre-M70q-Intel-Windows/dp/B09M43H7X1/ref=sr_1_1?crid=20BRERMF1VSWV&keywords=Lenovo+M70Q+Gen+2+mini&qid=1667419550&qu=eyJxc2MiOiIxLjUxIiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sprefix=lenovo+m70q+gen+2+mini%2Caps%2C300&sr=8-1
EDIT: I just had a little bit of panic, the amazon link says i5-11400T is "processor count = 2" whereas it is actually 6 core / 12 thread,
also says "Processor Speed = 2.1GHz" whereas it is "Processor Base Frequency = 1.3GHz - burst to 3.7GHz", so panic over.
Intel doc on i5-11400T:- https://www.intel.co.uk/content/www/uk/en/products/sku/212273/intel-core-i511400t-processor-12m-cache-up-to-3-70-ghz/specifications.html


The 1TB SATA SSD and one of the 1TB 4th gen Crucial P5 Plus's is going into the Lenova tiny little thing, and also gonna add either 8 or 16GB RAM to the existing 8GB.

DO WATCH the youtube report, it'll defo help make up your mind about nvme's [gen 4 PCI-e was not 'a thing' when youtube report was created - 2019].

EDIT:
Here an update to the above Youtube report [2022], the same guy [he's VERY GOOD]:- https://www.youtube.com/watch?v=9PA0DrV_kiw
I have not watched it yet, only just found it and downloading as we speak.
Suggest that you ALL watch both youtube videos.

EDIT: The first Youtube is longer in-depth review of about 7 or 8 3rd gen nvme's is the better one, 2nd youtube clip is much shorter
and not so interesting but also worth a watch.

EDIT: Got the tiny little thing, a bit pissed off that PCI-e gen 4.0 only used for graphics on the Lenovo M70q Tiny Gen 2, nvme uses Gen 3.0 Pci-e,
you need the M70q Gen 3 (with 12th gen processor) to get PCI-e 4.0 for nvme. Waste of time and cash putting the crucial P5 Plus in it :(

[anton_foy]

Is there a way to make ex_edge motion sensitive? What I mean is that atm it finds detail/edges too much where it is higher motion and motionblur.

[Dogway]

Is there a way to make ex_edge motion sensitive? What I mean is that atm it finds detail/edges too much where it is higher motion and motionblur.

Sure, raise the 'lo' cutoff. And use it with a HQ kernel like frei-chen. If that's still picking too much you might want to prefilter, or mask with a spatial or motion mask.

[anton_foy]

Sure, raise the 'lo' cutoff. And use it with a HQ kernel like frei-chen. If that's still picking too much you might want to prefilter, or mask with a spatial or motion mask.

Great thanks!

[madey83]

Sure, raise the 'lo' cutoff. And use it with a HQ kernel like frei-chen. If that's still picking too much you might want to prefilter, or mask with a spatial or motion mask.

@Dogway

could you please explain what is benefit of using this and when it could be used?

:thanks:

[tormento]

I have an anime with mixed 23.976p, 29.97p and 60i (on purpose not because of laziness, perhaps to maintain details?) with 29.97p video tagging. I'd like to give your QTGMC+ a try to port everything to 23.976p.

Do you have some hints not to change video duration and have a good result with 60i? In the 60i part (CGI) every field has different details, so it would be a bit hard to have proper deinterlacing without flickering.

P.S.: How is possible that I have Scenes Pack v4.4 (24-09-2022) when on GitHub there is version 4.2? xD

[guest]

P.S.: How is possible that I have Scenes Pack v4.4 (24-09-2022) when on GitHub there is version 4.2? xD

No, it's v4.4 (24-09-2022)

https://github.com/Dogway/Avisynth-Scripts/blob/master/ScenesPack.avsi#L4

[Dogway]

Do you have some hints not to change video duration and have a good result with 60i? In the 60i part (CGI) every field has different details, so it would be a bit hard to have proper deinterlacing without flickering.

You can deinterlace to double rate (with option for flicker reduction), then decimate to 23.976 and interpolate where appropriate.

To expand a little:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
0 I 2 I 4 I 6 I 8 I 10 I 12 I 14 I 16 I 18 I 20 I 22 I 24


So deinterlace to 60 progressive, then interpolate to 120fps, and then pick every 5 frames.

QTGMCp()
FrameInterpolation
SelectEvery(5,0)

[tormento]

You can deinterlace to double rate (with option for flicker reduction), then decimate to 23.976 and interpolate where appropriate.
Thanks! Simply creating the table needed some effort! :cool:

You mean, bring everything to 120p or just the 60i part?

Can you be more clear about function and your suggestions about parameters?

I am a complete noob about fields and related :p

[tormento]

What (https://www.youtube.com/watch?v=uFpUJ3cHkNY) I'd like to achieve.

[Dogway]

Yes, I can see the aircraft at 1:00 being interpolated really badly. That won't happen with my above method.

You want everything at 23.976 constant framerate, right. Trim out the 60i portion, apply the above and chain it back to the IVTCed (or whatever) 23.976 anime content.

I personally like a sense of craftsmanship on what I see, the kinds of waifu upscales without hallucination... I don't like.

[tormento]

You want everything at 23.976 constant framerate, right. Trim out the 60i portion, apply the above and chain it back to the IVTCed (or whatever) 23.976 anime content.
That's the easiest way to achieve something good but I should have the frame ranges of the fps changings. Anything useful to do it automatically?

I saw that using TIVTC is a hit and miss to get those variations.

[Dogway]

Automatically I don't know, maybe AnimeIVTC but I never used it, I never did episodes only OVA/Films so I did manually. An alternative is to export scene changes to a log, maybe with ScenesPack, convert that to bookmarks, and F4 iteratively to go through scene changes so you analyze the content much faster.

[tormento]

Automatically I don't know
Is there any other way for AVS+ to work differently based on current fps? I have thought about treating every fps differently.

What do you think about?

[Dogway]

If you mean VFR, I have no experience with that.

[Ryushin]

I've been using SMDegrain with RipBot264 using Pauly Dunne's Tools folder that is using Dogway's filters.

I have a 4K source that I'm trying to use blksize=4 on to try minimize some banding/blotching but it seems to be erroring out. I had good success with blksize=8 before on another source that I had that really helped minimize the blotching that I was seeing. Setting blksize=8 works fine, along with leaving the default of 16.

My SMDegrain script for RB:
#Custom
LoadPlugin("%AVISYNTHPLUGINS%\masktools\masktools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\mvtools\mvtools2.dll")
LoadPlugin("%AVISYNTHPLUGINS%\RgTools\RgTools.dll")
LoadPlugin("%AVISYNTHPLUGINS%\PD_TOOLS\MedianBlur2\MedianBlur2.dll")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\LSF-PLUS\LSFplus.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SHARPENERS-PACK\Sharpeners Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\SMDEGRAIN\SMDegrain cpu.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\Zs_RF_Shared\Zs_RF_Shared.avs")
Video=SMDegrain(video,tr=4,thSAD=400,thSADC=200,contrasharp=true,prefilter=1,refinemotion=true,blksize=4)

Is there something I'm missing in order for blksize=4 to work?

[Boulder]

Set refinemotion=false?

[Ryushin]

Set refinemotion=false?

Afraid that did not work. Odd. Everything I read said blksize=4 should work.

[Boulder]

The exact error message would definitely be very helpful ;)

[DTL]

4*4 in theory can be refined to 2*2 even with 4:2:0 chroma subsampling but overlap may not work. Do overlap is default enabled ?
Disabling overlap may additionally damage quality so to process with blocksize 2*2 and overlap it may be need feed 4:4:4 to MDegrain.
Other possible solution of 'supersampling' is to upsize 2x before degrain and use blocksize=8 and downsize 2x after.

[kedautinh12]

The exact error message would definitely be very helpful ;)

I think no error messages cause ripbot264 don't show it. Do you remember TDS only show scripts with ripbot264 with no error messages?? :D

[guest]

I think no error messages cause ripbot264 don't show it. Do you remember TDS only show scripts with ripbot264 with no error messages?? :D

Mr K,

I'm right here :D

I know Ryushin, and I have sent him a PM, shouldn't be a problem :sly:

BTW, it was an SMDegrain error at Line 214, Refinemotion setting options, with low blksize.

[Boulder]

Well, blocksize 4 is simply not supported. This is the content of line 214. Anyways, blocksize 4 with a 4K source is... not very common :D

RefineMotion ? Assert(blksize > 7, "SMDegrain: For RefineMotion you need a blksize of at least 8")

[guest]

Well, blocksize 4 is simply not supported. This is the content of line 214. Anyways, blocksize 4 with a 4K source is... not very common :D

RefineMotion ? Assert(blksize > 7, "SMDegrain: For RefineMotion you need a blksize of at least 8")

It worked for me with Refinemotion=false, or when Refinemotion wasn't in the call at all.

I guess I will see what Ryushin has to say, when he replies to my PM.

[Boulder]

It worked for me with Refinemotion=false, or when Refinemotion wasn't in the call at all.

I guess I will see what Ryushin has to say, when he replies to my PM.

Yes, probably some version conflict or something like that. There doesn't seem to be any other restrictions for size 4 than with Refinemotion enabled.

[DTL]

Very low size blocks require very sharp source to produce any good quality MVs. Also 4K and blocksize=4 (and full overlap if possible) may run at very low speed. SAD-based search with 2 random fields at denoising work do not always provide true-best MVs - it provide SAD-best MVs for current random input blocks. Refined to 2x2 blocks and with large search radius enabled may produce many really bad MVs. So it may be disabled to save user from slow and may be not good results.

"There doesn't seem to be any other restrictions for size 4 than with Refinemotion enabled."

For 4:2:0 chroma subsampling may be possible either refine to 2x2 blocks with 1x1 chroma samples or overlap with size of 2. Not refine + overlap at the same time. The overlap may be more valuable in compare with refining to 2x2.

[StainlessS]

Any testing with YUV444 ?

[tormento]

If you mean VFR, I have no experience with that.
It's not VFR, each part has its own fps. It's sort of a collage video among different fps.

[Dogway]

That also applies as VFR I think. I have no experience with that really.
VFR compatibility is low so I personally would fill with dups to maintain the perceived FPS but with CFR.

On another note finally yesterday I fixed the "devil that chases me" chroma location, I'm doing some other tweaks and releasing an updated ResizersPack and TransformsPack soon, before WC. After that I will be out for a while installing and tuning Win10.

[poisondeathray]

That is considered a type of "VFR" . It's "VFR content in a CFR stream" (or "VFR in CFR") , where different effective content FPS have repeated fields or frames in various patterns to achieve a CFR stream such as 29.97i in order statisfy some standard like broadcast, or DVD-video, or BD. e.g. a 12fps (actually ~ 11.98) anime pan in a section might have duplicate frames in a 23.976 animation. And if that were hard telecined it would have repeated fields (standard 3:2 pulldown) to achieve 29.97i (59.94 fields/s)

Timecode (timestamp, refers same thing) VFR is a 2nd different type of "VFR" , where you have unique frames, but the frame display times are specified in the timecode file .

Usually the 1st type is transformed into the 2nd, because the 1st is the distribution type (e.g. DVD, BD) , where the 2nd is more efficient (you're not encoding extra fields or frames)

[LeXXuz]

I may need a new debanding filter. No idea why I didn't see this much sooner. :rolleyes:

I've used neo_f3kdb() for a long time and was quite happy with the results when it comes to debanding and speed.

But now I realized that it kills A LOT of details in dark/ low contrast scenes. It also enhances the smearing effect in moving objects, again in dark or low contrast textures when using SMDegrain.

Although I always encode everything to 10bit, I still need a debanding filter as my TV is sadly very picky on very clean films and shows off banding in backgrounds very quickly. :(

I played around with Grainfactory() but it increases filesizes quite a lot until I get satisfying results on my TV. So simply adding grain back again doesn't cut it.

What do you guys use?

[Dogway]

As I observed f3kdb adds a nice amount of grain, specially on dark areas, even when grain is set to none, so it adds distortion to details.
Maybe use other debanding filters, there's mine Gradfun3mod, also cretindesalpes' Gradfun3 but doesn't support HBD, or more recently libplacebo_Deband (https://github.com/Asd-g/avslibplacebo#debanding).

If you need grain, unless it's for artistic purposes, add in the renderer in realtime.

[kedautinh12]

I may need a new debanding filter. No idea why I didn't see this much sooner. :rolleyes:

I've used neo_f3kdb() for a long time and was quite happy with the results when it comes to debanding and speed.

But now I realized that it kills A LOT of details in dark/ low contrast scenes. It also enhances the smearing effect in moving objects, again in dark or low contrast textures when using SMDegrain.

Although I always encode everything to 10bit, I still need a debanding filter as my TV is sadly very picky on very clean films and shows off banding in backgrounds very quickly. :(

I played around with Grainfactory() but it increases filesizes quite a lot until I get satisfying results on my TV. So simply adding grain back again doesn't cut it.

What do you guys use?

You can use F3KDB_3() to replace neo_f3kdb()
https://github.com/kedaitinh12/AVSPlus-Scripts/blob/master/F3KDB_sMOD.avsi

About add grain, you can use this scripts don't increases filesizes quite a lot
gr = 0.3
size = 0.8
GrainFactory3mod(g1str=6*gr,g2str=8*gr,g3str=5*gr,g1size=1.2*size,g2size=1.5*size,g3size=1.4*size,g1cstr=1.5*gr,g2cstr=1.5*gr,g3cstr=1.5*gr,temp_avg=0)

[LeXXuz]

Maybe use other debanding filters, there's mine Gradfun3mod, also cretindesalpes' Gradfun3 but doesn't support HBD, or more recently libplacebo_Deband (https://github.com/Asd-g/avslibplacebo#debanding).


Gradfun3mod looks interesting. Do you have a subtle setting for very clean sources at hand which I may use as a starting point for tweaking? :)

You can use F3KDB_3() to replace neo_f3kdb()
https://github.com/kedaitinh12/AVSPlus-Scripts/blob/master/F3KDB_sMOD.avsi


Thanks. I'll give that a try, too. :)

[LeXXuz]

As I observed f3kdb adds a nice amount of grain, specially on dark areas, even when grain is set to none, so it adds distortion to details.
Maybe use other debanding filters, there's mine Gradfun3mod, also cretindesalpes' Gradfun3 but doesn't support HBD, or more recently libplacebo_Deband (https://github.com/Asd-g/avslibplacebo#debanding).

If you need grain, unless it's for artistic purposes, add in the renderer in realtime.

I tried Gradfun.
This is the filtered film with the banding I'd like to get rid of:
https://abload.de/thumb/2022-11-17gqe7y.png (https://abload.de/image.php?img=2022-11-17gqe7y.png)

This is with default call GradFun3plus() as last filter:
https://abload.de/thumb/2022-11-171xpf5o.png (https://abload.de/image.php?img=2022-11-171xpf5o.png)

No, I did NOT accidently swap the screenshots. :D
It really made things much worse. What do I miss here? :o

[VoodooFX]

It really made things much worse. What do I miss here? :o

GradFun2DBmod()

[Dogway]

Probably?:
ConvertBits(16)
GradFun3plus()
ConvertBits(8,dither=1)

Without HBD your only option is to add grain like with GradFun2DBmod()

[LeXXuz]

Probably?:
ConvertBits(16)
GradFun3plus()
ConvertBits(8,dither=1)

Without HBD your only option is to add grain like with GradFun2DBmod()

It's running in 16bit. (I feed the source in 16bit to x265 which dithers it down to 10bit internally.)
That's why the output confuses me. Something is off.

[Dogway]

It mimics the original GradFun3 strength so maybe you need to increase radius? Without a small sample I don't know, it works for me for skies, etc

[LeXXuz]

Without a small sample I don't know, it works for me for skies, etc

That's quite alright.

One other thing. A lot of old movies have some kind of luminance flickering which of course becomes way more noticeable after the layer of grain was removed through denoising. Is there any filter that can soothe this a little?

[kedautinh12]

You can add grain after denoise with GrainFactory3mod :D

[anton_foy]

That's quite alright.

One other thing. A lot of old movies have some kind of luminance flickering which of course becomes way more noticeable after the layer of grain was removed through denoising. Is there any filter that can soothe this a little?

Ex_reduceflicker(strength=2) #or 1?

[LeXXuz]

Ex_reduceflicker(strength=2) #or 1?

I can't find that function. Which package does this belong to?

[Dogway]

It's called DCTFlicker, you can enable the option in SMDegrain (requires LFR>200) or simply use ex_LFR() from ExTools with DCTFlicker enabled. It's not perfect though. You can also try ex_reduceflicker() from QTGMC+

[LeXXuz]

It's called DCTFlicker, you can enable the option in SMDegrain (requires LFR>200) or simply use ex_LFR() from ExTools with DCTFlicker enabled. It's not perfect though. You can also try ex_reduceflicker() from QTGMC+

Is it enough to set LFR=true and DCTFlicker=true for SD sources or do I have to set it to 200 manually at least?
I remember a post where you mentioned LFR~150 as the default for SD.

Also I'm not so sure anymore if flickering is the right description of what I mean. It could also be described as a pumping effect of the luma in the backgrounds.
No idea what the correct expression for that effect may be. :o

[Dogway]

Yes I know the effect, it's the grain low frequency contribution from the DCT compression. Basically you have to strongly temporal denoise low frequencies, this can lead to smearing so you have to be careful. LFR=true is a default, but if the effect is strong you have to lower it to make it stronger (recover less of the high frequencies). It really depends on the content, maybe you can get away with a a very crude mode="TemporalSoften".

[LeXXuz]

Yes I know the effect, it's the grain low frequency contribution from the DCT compression. Basically you have to strongly temporal denoise low frequencies, this can lead to smearing so you have to be careful. LFR=true is a default, but if the effect is strong you have to lower it to make it stronger (recover less of the high frequencies). It really depends on the content, maybe you can get away with a a very crude mode="TemporalSoften".

Thanks Dogway. :) So actually lowering the LFR-value from its default strengthens the effect of the filter? Is the default 150/300/600 for SD/HD/UHD and this value is used for LFR=true?
Just want to make sure I get it right this time. :D

[Dogway]

Default is 300 for all modes, rising or lowering that has a different effect since they all converge at maximum dimension resolution.
So 300 is same for all and max(width,height) is same for all, interpolated in between. It's made so for LFR=true to look similar at all resolutions.

By the way, I took the liberty to help Notepad3 (https://github.com/rizonesoft/Notepad3/issues/1129) devs with AVS+ lexer and handed them an updated list of Internal Functions, Plugins and User Functions definitions. They were kind to update it immediately.
I also made two syntax schemes, a "light" one and a dark one, you can have a glance here (https://github.com/rizonesoft/Notepad3/issues/4014#issuecomment-1320734339).

The problem now that I made Notepad3 my default text editor is that it feels glitchy. Opening a file takes like 300ms, and the GUI flickers while writing... Dunno if it's a Win7 thing here.

[LeXXuz]

Default is 300 for all modes, rising or lowering that has a different effect since they all converge at maximum dimension resolution.
So 300 is same for all and max(width,height) is same for all, interpolated in between. It's made so for LFR=true to look similar at all resolutions.


Good I asked. :D It seems my info was a little outdated from somewhere quite early in this thread. Must've missed that they are scaled now internally according to resolution so I don't have to worry that much about.

Btw. on some sources I had the feeling LFR may increase the pumping/flickering effect. But it improved textures on clothing and stuff so I kept it. Greyish / dark suit textures are often the first things that get blurry in moving scenes.

[LeXXuz]

From the helpfile here:
https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain%20v3.5.5d/SMDegrain%20v3.5.5d.html

If instead you want to use your own prefilter denoiser, just define it in a variable and reference it here. Remember to:

Feed always 8 bit clips.
Input in fields for interlaced content *(read below)
Feed here planar ( by using Interleaved2Planar() ) YUY2 clips (not interleaved) when working with YUY2 sources.

Is that still valid or outdated info from the older helpfile?

[Ryushin]

Set refinemotion=false?

That actually did fix it. Thanks. I had problem in my x265 settings that propagated to other jobs that was causing it to keep restarting the encoding chunks and not make any progress.

[Boulder]

Hello,

i'm looking reason why my dolby vision encodes have significaly higher bitrate compare to SDR encodes with all the same avisynth filters and x265 settings (DV - has few more additional tweaks).

AQ-mode 3.

[madey83]

AQ-mode 3.

hi,

any reson for that? if so which i should use?

[madey83]

AQ-mode 3.


Thank you. You were right :D

[kedautinh12]

hi,

any reson for that? if so which i should use?

I seen many people use aq-mode 2 for HDR and aq-mode 3 for sdr

[Dogway]

Major update today that I've been holding back for a few months.

QTGMC+: Implemented EEDI3CL for faster EEDI3 deinterlacing

TransformsPack: Refined illuminant chromaticities. Fixed chroma placement algo (finally). More robust range and gamma conversions. Still need to finish CAT.

ResizersPack: Fixes on chroma placement and pixel center shifts in nnedi3/eedi3. New functions/wrappers (eedi3resize, RAVUresize, FSRresize, RIFEwrap, EEDI3wrap)

Please test and report since I won't be working much further on these anymore.

[LeXXuz]

Thanks Dogway! :thanks:
Doing a lot of DVD stuff soon. I always let QTGMC+ as part of Ceppo's tools run in these scripts to take care of nasty phase shifts which a lot of the ordinary deinterlacers can't handle properly. Will let you know if I see something unusual. :)

Btw. what about NNEDI3CL and subpixel=4? Is the issue still present?
https://forum.doom9.org/showthread.php?p=1976247#post1976247

[Dogway]

I tested again and it's working fine for me, no errors. However I noticed a ghosting artifact caused by big pixel center shift with high pel. That is because by default the center shift is not being fixed for nnedi3 in SMDegrain, as that matches the internal motion vectors shift. But with high pel the deviation is higher, so I better fix it for that case. I will update tomorrow with a few other cosmetics.

[kedautinh12]

Your latest ver can't fix with propSet("_FieldBased",0) anymore

- When i use with tfm().tdecimate() i got this error

https://i.imgur.com/i1d3SFh.png

- After add propSet("_FieldBased",0), i got this error (fine with older vers)

https://i.imgur.com/vevJ9KG.png

[Dogway]

Thanks for the report! Test now (https://github.com/Dogway/Avisynth-Scripts/commit/8e0941bbfa9cf91d74e362ab231758411fdf77c0).

[kedautinh12]

Ok, error gone with propSet("_FieldBased",0) but error still have without propSet("_FieldBased",0)

[Dogway]

Yes, TIVTC needs to be updated for frameprops support.
BTW I'm updating SMDegrain in a moment.

[madey83]

@Dogway,

Your last release give me below errors:

Script Error

Script error: There is no function named 'libplacebo_Resample'.
(E:\4k_encode\Avisynth-Scripts-master\TransformsPack - Main.avsi, line 927)
(E:\4k_encode\Avisynth-Scripts-master\TransformsPack - Main.avsi, line 1302)
(E:\4k_Encode\Avisynth-Scripts-master\ResizersPack.avsi, line 230)
(E:\4k_Encode\Avisynth-Scripts-master\ResizersPack.avsi, line 274)
(E:\myVideo.avs, line 159)

line 159 of avs script is: deep_resize(1920,edge="Zopti1080")

my plugns:
import("E:\4k_Encode\Avisynth-Scripts-master\MIX mods\GradFun3plus.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\ExTools.avsi")
import("E:\4k_encode\Avisynth-Scripts-master\SMDegrain v3.5.6d\SMDegrain v3.5.6d.avsi")
Import("E:\4k_encode\Avisynth-Scripts-master\ResizersPack.avsi")
Import("E:\4k_encode\Avisynth-Scripts-master\MIX mods\LSFplus.avsi")
Import("E:\4k_encode\Avisynth-Scripts-master\MIX mods\SharpenersPack.avsi")
Import("E:\4k_encode\Avisynth-Scripts-master\GradePack.avsi")
Import("E:\4k_encode\Avisynth-Scripts-master\ScenesPack.avsi")
Import("E:\4k_encode\Avisynth-Scripts-master\MasksPack.avsi")
Import("E:\4k_encode\Avisynth-Scripts-master\MIX mods\Spresso.avsi")
import("E:\4k_encode\Avisynth-Scripts-master\EX mods\GrainFactory3mod.avsi")
import("E:\4k_encode\Avisynth-Scripts-master\EX mods\DeblockPack.avsi")
import("E:\4k_encode\Avisynth-Scripts-master\TransformsPack - Main.avsi")
import("E:\4k_encode\Avisynth-Scripts-master\TransformsPack - Models.avsi")
import("E:\4k_encode\Avisynth-Scripts-master\TransformsPack - Transfers.avsi")
import("E:\4k_Encode\Avisynth-Scripts-master\ResizersPack.avsi")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3DCPU_AVS.dll")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3DCUDA_AVS.dll")
loadplugin("E:\4k_encode\BM3DCUDA_AVS-test9\x64\BM3D_VAggregate_AVS.dll")
loadplugin("E:\4k_encode\dgdecnv_244\DGDecodeNV.dll")
loadplugin("E:\4k_encode\vsTCanny-1.1.8\x64\Release\vsTCanny.dll")
loadplugin("E:\4k_Encode\neo_FFT3D_r11\x64\neo-fft3d.dll")
loadplugin("E:\4k_Encode\fmtconv-r30\win64\fmtconv.dll")


Do i miss something? Your previous release worked fine with the same AVS settings.

[kedautinh12]

You need load this plugin
https://github.com/Asd-g/avslibplacebo

[madey83]

You need load this plugin
https://github.com/Asd-g/avslibplacebo

Thank you. It was so quick :)

[madey83]

now i have got this:

Script Error

System exception - Access Violation
(E:\4k_encode\Avisynth-Scripts-master\EX mods\DeblockPack.avsi, line 239)
(E:\myVideo.avs, line 164):: CCD(15)

function CCD (clip a, float "thres", bool "interlaced", int "U", int "V") - function definition.

[kedautinh12]

Are you got avs+ and vc++ latest ver???
https://gitlab.com/uvz/AviSynthPlus-Builds
https://github.com/abbodi1406/vcredist

[madey83]

Are you got avs+ and vc++ latest ver???
https://gitlab.com/uvz/AviSynthPlus-Builds
https://github.com/abbodi1406/vcredist

i will test this out later today.

Thank you for support :)

[LeXXuz]

Dogway, when I use globals in SMDegrain for 2-stage denoising I can't use subpixel=3 in the 2nd stage.

Error message:
Scrip error: the named argument "pelclip" to MSuper had the wrong type. Lines 299 and 656.

I have to use subpixel=2 for the 2nd stage if globals are active.

[madey83]

Are you got avs+ and vc++ latest ver???
https://gitlab.com/uvz/AviSynthPlus-Builds
https://github.com/abbodi1406/vcredist

i did encode with CCD and without deep_resize(1920,edge="Zopti1080")

and it went fine and i did not change anything regarding AVS and VC versions.

[madey83]

Are you got avs+ and vc++ latest ver???
https://gitlab.com/uvz/AviSynthPlus-Builds
https://github.com/abbodi1406/vcredist

Good morning,

you were right. thank you :D

[Dogway]

Dogway, when I use globals in SMDegrain for 2-stage denoising I can't use subpixel=3 in the 2nd stage.

Error message:
Scrip error: the named argument "pelclip" to MSuper had the wrong type. Lines 299 and 656.

I have to use subpixel=2 for the 2nd stage if globals are active.

Sure, with globals some parameters must match, read docs (https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain/SMDegrain.html#Globals).
You are trying to reinterpret the same motion vectors you are loading.

[LeXXuz]

Sure, with globals some parameters must match, read docs (https://raw.githack.com/Dogway/Avisynth-Scripts/master/SMDegrain%20v3.5.6d/SMDegrain%20v3.5.6d.html#Globals).
You are trying to reinterpret the same motion vectors you are loading.

Yeah I know they have to match. First stage was also set to subpixel=3, of course.

It only works if both are set to 2.
It does not work when both are set to 3.
(And of course it doesn't work when they don't match.)

[Dogway]

Thanks, I spotted the issue, promoted to v3.5.7. Not sure what was the logic of my !GlobalR ternary but I removed it and works now. Also fixed Globals=3 and a typo on nnedi3 pixel_shift.

[LeXXuz]

Nice! Will give it a go again soon. :thanks:

[madey83]

Yeah I know they have to match. First stage was also set to subpixel=3, of course.

It only works if both are set to 2.
It does not work when both are set to 3.
(And of course it doesn't work when they don't match.)


HI LeXXuz

what is the benefit to use globals in denoising?
Could it improve denoise, could it replace prefilters....

have you got some script to share to do some comparison test with my current setup?

Thank you in advance.

[LeXXuz]

HI LeXXuz

what is the benefit to use globals in denoising?
Could it improve denoise, could it replace prefilters....

have you got some script to share to do some comparison test with my current setup?

Thank you in advance.

You may want to take a look into the docs with the link Dogway provided.

The globals parameter can be helpful if you want to run more than one instance of SMDegrain for denoising. The benefit is you dont't have to recalculate motion vectors again for your second instance of SMDegrain which can improve performance.

Some forms of noise can better be reduced by two instances of SMDegrain (each with weaker settings) than just one instance with stronger settings.

This doesn't replace prefiltering in any way. Appropriate prefiltering is always important to get best results with SMDegrain.

[kedautinh12]

Hi Dogway, your scripts requirements need only transforms pack. I wonder it's need 3 parts of them or only main version?? Of cause i load all and I ask for my friend (old man) :D

[guest]

@ Dogway ,

"Old Man" here, just to give a little more info on kedautinh12's post above.

I asked him for some help a little earlier today, and he mentioned about the 3 Transforms Packs:-

Transforms Pack-Main

Transforms Pack-Models

Transforms Pack-Transfers

I have ONLY been using the "Main" one, with my scripts that need Transforms Pack, and it works....adding the other 2 didn't make any difference to the script I was working on.

Respect.

[Reel.Deel]

Transforms Pack-Main has lots of functions and some of those are dependent on the functions included in the Models/Transfers pack. If you're using the Main pack and it's not complaining about a missing function, then it does not anything from the other two packs. It does not hurt one bit to have all of the scripts.

[kedautinh12]

Hi, i report new issue: when i use this scripts, i got that error (test with some video but i still got same issue. I think issue not from my video)

src=last
RatioResize(0.25,"%",kernel="bicubic")
DeStripeV(3,1,255)
ex_boxblur(1,0,mode="weighted")
bicubicresize(1338,974)
ex_LFR(src,last, LFR=150)
src=last

ex_edge("kroon")
ex_boxblur(0,5)
ex_binarize(80,true,hi=-1)
ex_lut("x[-1,0] x[1,0] - abs 5 *").ex_inpand().ex_expand()
ex_boxblur(0,10)
ex_lut("x 40 - 0 max 20 *") # Assumes 8-bit
# ex_deflate().ex_deflate()

InpaintDelogo(src, mask=last, Loc="0,0,0,0")
ex_lutxy(src,"y 5 + x > y x ?") # Assumes 8-bit


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

ex_bilateral(5,0, ithres=10.0, sthres=10.0, dejaggie=false)

https://i.imgur.com/6otW7D0.png

[Dogway]

Sure, you are comparing the original with a scaled clip in ex_LFR().

By the way, among other things I finished the CAT refactor so I'm uploading TransformsPack v1.0 final in a few moments. Will write a full fledged post later in the day with examples and benchmarks.

[kedautinh12]

Ah, ok thanks

[Dogway]

I had time to run some speed benchs and some examples for ConvertFormat()
Mind you, I still need to work on the Preset system and Model conversion within ConvertFormat()

In my tests all filters run better at Prefetch(4). P8 indicates the speed at 8-bit for comparison.

The template script is as follows:
setmemorymax(2048*4)
DGSource("src.dgi")

ConvertBits(16)

[...] # Filters

Prefetch(4)


YUV to RGB
100 329 P8 520 z_ConvertFormat(pixel_type="RGBP16",colorspace_op ="709:709:709:l=>rgb:709:709:l",resample_filter="spline36")
fmtc_resample(kernel="spline36", css="444")
65 213 P8 251 fmtc_matrix(mat="709", col_fam="RGB",fulld=false)
64 209 P8 372 ConvertFormat(1,1,"YUV","RGB",kernel="spline36",tv_out=true)
59 194 P8 368 ConverttoPlanarRGB(matrix="709:f",chromaresample="spline36")

RGB to YUV
100 216 z_ConvertFormat(pixel_type="YUV420P16",colorspace_op ="rgb:709:709:f=>709:709:709:l",resample_filter="spline36")
76 163 ConverttoYUV420(matrix="709:l",chromaresample="spline36")
fmtc_matrix(mat="709", col_fam="YUV")
75 161 fmtc_resample(kernel="spline36", css="420")
64 138 ConvertFormat(1,1,"RGB","YUV",kernel="spline36")

1080p to UHD
100 253 P8 351 z_ConvertFormat(3840,2072,resample_filter="spline36")
83 210 P8 243 fmtc_resample(3840,2072,kernel="spline36")
63 158 P8 246 ConvertFormat(3840,cs_out="",kernel="spline36")

Rec.601 to Rec.709 (no P8 since speeds are similar except avsresize with a 25% speed increase)
100 294 z_ConvertFormat(pixel_type="YUV420P16",colorspace_op ="601:709:170m:l=>709:709:170m:l",resample_filter="spline36")
fmtc_resample (css="444",kernel="spline36")
fmtc_matrix (mats="601", matd="rgb")
fmtc_transfer (transs="1886", transd="linear")
fmtc_primaries(prims="170m", primd="709")
fmtc_transfer (transs="linear", transd="1886")
fmtc_matrix (mats="rgb", matd="709")
26 77 fmtc_resample (css="420",kernel="spline36")
13 38 ConvertFormat(cs_in="601",cs_out="709",kernel="spline36")


Some useful examples for ConvertFormat()


No Moirée
https://i.imgur.com/vZKuDBl.png
ConvertFormat(0.5,nomoiree=true,kernel="RobiSharp")


Ringing
Plain lanczos4 x4 upscale
https://i.imgur.com/6ASu3TK.png
With sigmoid scaling, a bit better.
https://i.imgur.com/LxNfXXr.png
ConvertFormat(4,cs_out="",kernel="lanczos4",scale_space="sigmoid")
But noring=true makes the difference
https://i.imgur.com/LdP142w.png
ConvertFormat(4,cs_out="",kernel="lanczos4",noring=true)
yes, you can mix them to get less 'bloating'
https://i.imgur.com/hv5uRqS.png
ConvertFormat(4,cs_out="",kernel="lanczos4",noring=true,scale_space="sigmoid")
Now nnedi3, nice
https://i.imgur.com/8ja8523.png
ConvertFormat(4,cs_out="",kernel="nnedi3")
But it can also be further improved
https://i.imgur.com/FJ7Tkbx.png
ConvertFormat(4,cs_out="",kernel="nnedi3",noring=true)


UHD upscale
Talking about nnedi3, you can upscale to UHD with decent speed at 72fps (nnedi3 GPU):
ConvertFormat(3840,cs_out="",kernel="nnedi3")

Or if you want some more sharpness
deep_resize(3840,grain=0) # 12 fps


Downscaling

Now for the opposite. With typical downscale kernels you can't go too far.
See in this example with 'Zopti1080', which is a bicubic with -0.99 and 0.06 coefs.

Source (https://download.hrz.tu-darmstadt.de/media/FB20/GCC/dpid/res/userstudy/069/Reference.png)
Spline64
https://i.imgur.com/Ry8jKeS.png
ConvertFormat(0.25,cs_out="",kernel="spline64")
Zopti1080
https://i.imgur.com/rhALgDc.png
ConvertFormat(0.25,cs_out="",kernel="Zopti1080")
Of course, you can try using linear scaling but result doesn't look nice at all (even worse with Zopti1080)
https://i.imgur.com/F3tDXTA.png
ConvertFormat(0.25,cs_out="",kernel="spline64",scale_space="linear")

Now check using 'SSIM2' downscaler
https://i.imgur.com/7d2om8R.png
ConvertFormat(0.25,cs_out="",kernel="SSIM2")

This is streamlined in deep_resize() by default:
deep_resize(0.25)

[kedautinh12]

Wow, amazing result

[tormento]

I had time to run some speed benchs and some examples for ConvertFormat()

[…]

ConvertBits(16)
On older machines (like mine) ConvertBits seems to be slower than other HBD conversion such as avsresize and fmt_, beside giving problems when converting to RGB and back (there are some posts about the need of fulld=true).

Moreover, if I am not wrong, avsresize allows to compact the conversion process in a single line instead of two calls. I can't remember about fmt_ :p.

Perhaps you could gift us with some more tests. :)

[Dogway]

Well, I can't compete with compiled programs and yet ConvertFormat() manages to equal fmtconv and internal Convert_ in some modes. avsresize is another thing, I don't know if they handcrafted the code in assembly or what but it's insanely fast.

In any case it was never my purpose, the beauty of it is to for example, scale up with nnedi3, using noring, in linear scale, with correct chroma placement, and change transfer or color space with gamut compression all in "one step" and with a self explanatory one-liner. Moreover, all the coefficients are derived so you might probably get more accurate* results (though not standard). It also serves me and others as a notebook for color management, as I write notes here and there, and the code isn't populated with CPU/SIMD specific intrinsics.
*Yeah, I realize CIE 1931 is far from being accurate, that's why I keep working on the CMFs.

Running these tests gave me some ideas for further optimizations, namely while fixing several bugs deep_resize() saw a near 50% speed decrease, so I might give it a look for a refactor.

[DTL]

"With typical downscale kernels you can't go too far."

Scaling for moving pictures systems is very complex task if trying to get sharpest result. Static scalers may give nice results but may cause significant artifacts in motion. So may be next generation scalers can be scene-adaptive so can apply best static scaler for static areas of the scene (it is really very common for many motion pictures footages like static camera for the total scenecut) and use motion-friendly not as sharp scaler for moving parts of the scene.
So 'classic' non-content adaptive scalers for motion pictures may be not as sharp as best static but fast and produce average result for the total movie in both static and moving parts of frames.

If possible it is nice to see 'motion' test of scalers using some synthetic or external slow motion speed content with typical motion speed about 0.1..0.3 samples per frame to see different content positions relative to sampling grid. 'As sharp as single (pixel)sample' static scalers may significantly fail this test. Because moving of single sample keeping its amplitude and 'width' in any real number position relative to sampling grid is not possible. May be animated .GIF file may be natural for text forum to see 'motion test' result.

Typical issue for motion of too-sharp and/or non-linear scalers is 'temporal aliasing' that looks like flickering of small details and sharp edges.

So selecting same for all moving pictures scaler is some balance between temporal artifacts and spatial artifacts and sharpness. Skipping temporal tests for moving pictures scaler may cause selecting too sharp scaler but producing too much temporal artifacts at natural moving pictures.

The 'classic' AVS convolution based linear scalers are result of some balance between temporal artifacts and spatial artifacts and sharpness.

[Boulder]

Can you do a test with that astronomical image and linear scale downscaling with avsresize (using HBD for all steps)? I'd be interested in seeing the result as I've always understood that linear light is better for such source material.

[kedautinh12]

Can you do a test with that astronomical image and linear scale downscaling with avsresize (using HBD for all steps)? I'd be interested in seeing the result as I've always understood that linear light is better for such source material.

I think Transforms Pack of Dogway just finished in 8 bit. HBD will support in future

[Dogway]

Can you do a test with that astronomical image and linear scale downscaling with avsresize (using HBD for all steps)? I'd be interested in seeing the result as I've always understood that linear light is better for such source material.

I did the test but with fmtconv and result was same.

I think Transforms Pack of Dogway just finished in 8 bit. HBD will support in future

It works at any bitdepth (color space is even hard-coded to 32-bit, that's why is so slow AVS wise), what is not supported currently in ConvertFormat() is HDR, but I want to post a few examples of what you can do using ancillary model functions.

[madey83]

@Dogway,

What is your recommendation to downscale dolby vision 2160p source to 1080p Dolby vision?

[Dogway]

What is your recommendation to downscale dolby vision 2160p source to 1080p Dolby vision?

By default deep_resize() uses 'Zopti1080' for going down to 1080p. This is correct in the sense you get a good speed and good quality.
Since you are keeping Dolby Vision (you need to attach metadata to the reencode), the metrics might be changed, but not so much than if you downscaled further.

I did a test and scaling in Dolby Vision 'log' with SSIM2 has a similar effect than scaling with Zopti1080 in 'gamma' (because you lose some sharpness in log)


Scaling for moving pictures systems is very complex task if trying to get sharpest result. Static scalers may give nice results but may cause significant artifacts in motion.

That is true, it really depends whether your downscale is display referred or scene referred. For display referred you want something softer and motion aware, maybe a PP filter like Soothe() or ex_reduceflicker() can help, it is also content dependent. On the other side, with scene referred downscales, you are better relying on smart guest device upscalers/PP, similar to basicvsr and such.

[tormento]

Well, I can't compete with compiled programs
I was talking about internal ConvertBits function, that you used in your benchmarks. :)

[tormento]

By default deep_resize() uses 'Zopti1080'
What about DPID?

[kedautinh12]

What about DPID?

I think with downscale, Zopti1080 and ssim2 is better

[Dogway]

I was talking about internal ConvertBits function, that you used in your benchmarks. :)
I can do a benchmark for fmtconv bitdepth down conversion, but I doubt it'd make such a difference, the bottleneck is due to several Expr() calls in the 32-bit color space code block. Expr() cannot format out to YUV420 (not sure it should though) so that's a limiter.

What about DPID?
There was some kind of issue with DPID, IIRC a subpixel shift or something, maybe some aliasing, can't remember, so I defaulted to SSIM2 in deep_resize().

[poisondeathray]

Nice work Dogway

Can you post the src images for the zone plate and ringing test in post #1789 ?

Thanks

[Reel.Deel]

Can you post the src images for the zone plate and ringing test in post #1789 ?


https://geekhack.org/index.php?action=dlattach;topic=50386.0;attach=42180;image and rings: https://legacy.imagemagick.org/Usage/img_photos/rings_lg_orig.png

[poisondeathray]

I'm trying to match libplacebo_Shader using adaptive_sharpen.glsl settings to Adaptive_Sharpen() in the Sharpener's Pack, as the results are quite different. I like Adaptive_Sharpen in more in many cases because there is less ringing, but it's slower. But there are 3 entries that are not in the .glsl that might explain this, and I don't know how to modify the glsl besides the simple parameter settings . The entries are dW_lothr, dW_hithr, lowthr_mxw - any ideas ?

[Dogway]

arrff, Adaptive_sharpen is a monster I'd rather leave behind, it was hard to port, and more to optimize, really the last optimizations already got me about 20 or 25% speed increase by decoupling an expression, I don't really think I can squeeze more out of it but maybe someone (Asd-g?) is interested in a plugin port?

To be honest I don't understand libplacebo_Shader() much either myself, I think I'm doing it right in for example RAVUresize() but I have my doubts specially when it comes to "filter" and "radius", maybe try playing with those first. Also keep in mind avslibplacebo requires RGB, that involves resizing chroma up, sharpening the 3 planes, then chroma down, it's not going to match 100% and the later being more prone to ringing and/or fringing.

There are other mismatches I observed in for example the EWA___ modes for gpuid=0 or -1 (libplacebo or JincResize). I will try to ask about it later on.

As for the shader, I think you are using the abridged version that I promised to port but never did. My version is the original 2 pass from bacondither, and here (https://github.com/bacondither/Adaptive-sharpen/blob/0da6654e464c4136e3a68d80f5cd3bd7563762b9/shaders/Adaptive-sharpen%20-%20Pass%20two.hlsl#L59) you can check the definitions of the args you mention.

Some updates on TransformsPack, I did some fixes related to scalers, but I'm holding back until I solve some issues with linear sources, as they need to be accounted when changing gamma encode required formats and scale_spaces... it's like a puzzle. Really would like an IDE that would highlight the code path of a call, for better debugging logic.

For zone plates you can also create one like with the example (https://github.com/Dogway/Avisynth-Scripts/blob/88d7dd948b6ce852d3c847c7ead9b0574f9b2c5d/ExTools.avsi#L935)in ExTools.

[poisondeathray]

As for the shader, I think you are using the abridged version that I promised to port but never did. My version is the original 2 pass from bacondither, and here (https://github.com/bacondither/Adaptive-sharpen/blob/0da6654e464c4136e3a68d80f5cd3bd7563762b9/shaders/Adaptive-sharpen%20-%20Pass%20two.hlsl#L59) you can check the definitions of the args you mention.


ahhh thanks

Originals are a hlsl shader, but I think the libplacebo_Shader() only accepts glsl in mpv syntax . Does anyone have a glsl version around ?

I don't use shader much, but the speeds for some of the filters are nice

[LeXXuz]

I have a film here from a low budget production which seems to be recorded with a poor DV cam. It's quite clean but has some very bad aliasing around sharp edges, see pic:
https://abload.de/thumb/aliasing8zfbq.jpg (https://abload.de/image.php?img=aliasing8zfbq.jpg)

The material is 1080p and was recorded as such. So this is not from some poor deinterlacing with field mismatch or something.

Any good filter/script setting you could recommend to reduce this a little?

[Dogway]

Yes, that is possibly a flaw from RGB debayering. It can be fixed with SantiagMod(strh=8,strv=0).

Recently I had to fix a similar issue and finally decided to mix SantiagMod() for flat areas, and DeGaussResizeMT() for edges, as it gave me better edges.
https://i.imgur.com/9tqjZEi.png..............https://i.imgur.com/QtgbUMJ.png

This was my script:
a=last
w=1904/2
h=808/1
DeGaussResizeMT(nmod(w),nmod(h),order=1,p=100)
nnedi3wrap(2,1,fwidth=1920,fheight=814) # for edge
ex_limitdif(SantiagMod(a,strh=0,strv=4).spline36resize(1920,814), last, thr=1, elast=4, UV=4) # santiag for flat

ex_unsharp(0.2, Fc=1920)

[kedautinh12]

Can you explain why width=1920 and height=814 but w=1904 and h=808?

[Dogway]

It was just pre-cropping. If you don't have garbage edges or black borders you can use 1920x1080. 814 is to keep aspect ratio when scaling from 1904 to 1920.

[LeXXuz]

Where do I find SantiagMod()? Only found the original Santiag() from cretindesalpes.

DeGaussResizeMT is the one from jpsdr's ResampleMT, right?

[Dogway]

It's in this post (https://forum.doom9.org/showthread.php?p=1953852#post1953852). I guess I would better upload it Git, I will after I add GPU support.

[Reel.Deel]

It's in this post (https://forum.doom9.org/showthread.php?p=1953852#post1953852). I guess I would better upload it Git, I will after I add GPU support.

Isn't this the same: https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/LSharpAAF.avsi#L568 ?

[Dogway]

Yes, that's right, forgot about it.
I think I will delete it from there, SantiagMod is a staple so I want more visibility. I updated it with NNEDI3CL and some speed optimizations here (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/SantiagMod.avsi).


DeGaussResizeMT is the one from jpsdr's ResampleMT, right?

Yes, it's included in plugins_JPSDR.dll along CPU nnedi3, and some more.

[LeXXuz]

Yes, that's right, forgot about it.
I think I will delete it from there, SantiagMod is a staple so I want more visibility. I updated it with NNEDI3CL and some speed optimizations here (https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/SantiagMod.avsi).



Yes, it's included in plugins_JPSDR.dll along CPU nnedi3, and some more.

I get an access violation error in the Transforms Pack when running your little script.
I have NNEDI3CL and plugins_JPSDR.dll installed and just changed all resolutions to 1920,1080.

[kedautinh12]

Waiting for mod approval forever :D
Are you got avs+ and vc++ latest ver???
https://gitlab.com/uvz/AviSynthPlus-Builds
https://github.com/abbodi1406/vcredist

[Dogway]

It might be related to an issue I fixed internally these days, also affected RAVUresize I think. I'm updating TransformsPack partially today, and Main for tomorrow.

EDIT: By the way, I'm preparing a guide for a correct home theater set up in regards to display and surround environment luminance levels, as well as white point. It will be scientific based, not by the common known standards.

[guest]

Could someone please provide a simple script/call for Whitepoint.

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1466

[Reel.Deel]

Could someone please provide a simple script/call for Whitepoint.

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1466

Simple script/call for Whitepoint: Whitepoint()

Same as above (except for matrix and tv_range, they use frame properties so they may default to something else): WhitePoint (temperature=6504, matrix="709", locus="Daylight", observer=1931, list=false, tv_range=true)

You literally linked to the part that has all of the information. Read from line #1446: https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1446

[guest]

Simple script/call for Whitepoint: Whitepoint()

Same as above (except for matrix and tv_range, they use frame properties so they may default to something else): WhitePoint (temperature=6504, matrix="709", locus="Daylight", observe=1931, list=false, tv_range=true)

You literally linked to the part that has all of the information. Read from line #1446: https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1446

Thankyou, but no success :(

I'm clearly missing something important...

There has to be more dependencies !!

Import("C:\RipBot264_PD (16-12-22)\Tools\AviSynth plugins\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("C:\RipBot264_PD (16-12-22)\Tools\AviSynth plugins\PD_TOOLS\TRANSFORM-PACK\Transforms Pack.avs")
video=WhitePoint(video,temperature=6504, matrix="709", locus="Daylight", observe=1931, list=false, tv_range=true)

[kedautinh12]

Don't have error message, can't fix :D

[Reel.Deel]

Thankyou, but no success :(

I'm clearly missing something important...

There has to be more dependencies !!

......

It might need the other TransformsPack scripts (models and/or transfers). I'm not going to check the script to see what functions it uses. Regardless, I told you back in #1785 (https://forum.doom9.org/showthread.php?p=1979448#post1979448) that you should load all of them, as it does no harm to do so.

[kedautinh12]

Dogway just update latest ver some scripts, you need update too

[guest]

Don't have error message, can't fix :D

Yeah, I know, all I can add it when I check it with AVSMeter, it won't even start the "test", so no info :(

[guest]

It might need the other TransformsPack scripts (models and/or transfers). I'm not going to check the script to see what functions it uses. Regardless, I told you back in #1785 (https://forum.doom9.org/showthread.php?p=1979448#post1979448) that you should load all of them, as it does no harm to do so.

Sorry, I DID try one script with ALL the Transforms Pack, same outcome :(

[guest]

Dogway just update latest ver some scripts, you need update too

Yes, I noticed that, and have updated the one's I use :)

[kedautinh12]

Yeah, I know, all I can add it when I check it with AVSMeter, it won't even start the "test", so no info :(

Try with AvsPmod

[Reel.Deel]

Sorry, I DID try one script with ALL the Transforms Pack, same outcome :(

It's hard to know without any errors messages and your scripts always seen to be missing something. Not sure if that is because of RipBot but to make it easier for everyone, you should try to first get in running on VDub2 or something.

There was a typo in my first post (observer=1931). I fixed that and tried the script myself:

video = LSMASHVideoSource("somevideo.mp4")
WhitePoint(video, temperature=6504, matrix="709", locus="Daylight", observer=1931, list=false, tv_range=true)

And it gives me the following error:

Avisynth open failure:
Script error: Invalid arguments to function 'CCTF'.
(C:/Program Files (x86)/AviSynth+/plugins64+/GradePack.avsi, line 1559)
(C:/Program Files (x86)/AviSynth+/plugins64+/GradePack.avsi, line 1584)

Same thing if I just called it with "Whitepoint()". I'm not in the mood to look for the error, so let's wait for dogway :)

[guest]

It's hard to know without any errors messages and your scripts always seen to be missing something. Not sure if that is because of RipBot but to make it easier for everyone, you should try to first get in running on VDub2 or something.

There was a typo in my first post (observer=1931). I fixed that and tried the script myself:

video = LSMASHVideoSource("somevideo.mp4")
WhitePoint(video, temperature=6504, matrix="709", locus="Daylight", observer=1931, list=false, tv_range=true)

And it gives me the following error:

Avisynth open failure:
Script error: Invalid arguments to function 'CCTF'.
(C:/Program Files (x86)/AviSynth+/plugins64+/GradePack.avsi, line 1559)
(C:/Program Files (x86)/AviSynth+/plugins64+/GradePack.avsi, line 1584)

Same thing if I just called it with "Whitepoint()". I'm not in the mood to look for the error, so let's wait for dogway :)

I know that "we" need to be "in the mood" to work thru things like this, so thankyou for your suggestions :)

However, from the script you showed, I added GradePack, and it now works :)

Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\GRADE-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Models.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Transfers.avs")
video=WhitePoint(video,temperature=6504, matrix="709", locus="Daylight", observer=1931, list=false, tv_range=true)

I just need to tweak the settings until I get the desired result.

FYI, it DOES need all the Transforms ;)

:thanks:

[guest]

Try with AvsPmod

I'm not familiar enough with that, to use it to test scripts :p

[Reel.Deel]

However, from the script you showed, I added GradePack, and it now works :)

Hmm, glad it works now. I'm still getting the same error, just updated all of dogway's scripts and nothing... Maybe I'll figure it out later.

[guest]

Hmm, glad it works now. I'm still getting the same error, just updated all of dogway's scripts and nothing... Maybe I'll figure it out later.

I could be very wrong here, but could this be the problem you're having :-


video = LSMASHVideoSource("somevideo.mp4")
WhitePoint(video, temperature=6504, matrix="709", locus="Daylight", observer=1931, list=false, tv_range=true)

I think the "video" might be "leftover" from my script, and that's a RipBot thing...wouldn't you need to use something different, like "clip" or similar ??

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1466

[Reel.Deel]

I could be very wrong here, but could this be the problem you're having :-


video = LSMASHVideoSource("somevideo.mp4")
WhitePoint(video, temperature=6504, matrix="709", locus="Daylight", observer=1931, list=false, tv_range=true)

I think the "video" might be "leftover" from my script, and that's a RipBot thing...wouldn't you need to use something different, like "clip" or similar ??

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1466

The name can be whatever. I can name my clip chickenwings = xxxsource("video.mkv") and then call it later on with Whitepoint(chickenwings). Clip in a function is just the type.

[kedautinh12]

I'm not familiar enough with that, to use it to test scripts :p

Just copy your script to AvsPmod and it will show errors

[guest]

Just copy your script to AvsPmod and it will show errors

But you must need to load a video file as well, otherwise it has nothing to work with ?

[guest]

This really seems to slow the encoding down, a LOT !!!!!

[kedautinh12]

But you must need to load a video file as well, otherwise it has nothing to work with ?

Just copy scripts contain video from ripbot and AvsPmod will load script successly :D

[guest]

Just copy scripts contain video from ripbot and AvsPmod will load script successly :D

I'm pretty sure that RipBot does the video & audio side of things very differently.

[Dogway]

You got me in the middle of a TransformsPack update, today I release the Main branch. They are mostly the three of them always needed, as they were once a single script. Typically the same for ResizersPack, they call each other several times, kind of inception thing, ConvertFormat(kernel="deep"), calls deep_resize() which in turn calls back ConvertFormat() which uses nnedi3resize() which in turn is in ResizersPack(), and this itself calls ConvertFormat() for pixel centering.

Anyway, the main problem was you were calling the arg 'observe' when it's 'observer'. Also it's better you omit the arg as below 5000K it should shift to the Planckian locus. Basically call WhitePoint(8000) and you are good to go.

Also as as a tip, for example I made a folder with all real.finder scripts, as I don't want them auto-loaded or mixed with the main plugins64+ folder.

Then create a script called IMPORT_ALL.avsi with content:
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\ContraSharpen_mod.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\dither.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\GradFun2DBmod.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\GrainFactory3.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\mt_xxpand_multi.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\nnedi3_resize16.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\ResizeX.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\Utils-r41.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\Utils-r42.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\Vinverse_avsi.avsi")
Import( "C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\Zs_RF_Shared.avsi")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\AutoAdjust.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\ConvertStacked.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\dither.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\FluxSmooth.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\neo_dfttest.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\neo_f3kdb.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\neo_fft3d.dll")
LoadPlugin("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\SmoothAdjust.dll")
...

And simply import that from your script:
Import("C:\Program Files (x86)\AviSynth+\plugins64+\real.finder tests\IMPORT_ALL.avsi")
Your Script

[LeXXuz]

Waiting for mod approval forever :D
Are you got avs+ and vc++ latest ver???
https://gitlab.com/uvz/AviSynthPlus-Builds
https://github.com/abbodi1406/vcredist

Yeah that kinda sucks. :rolleyes: The Doom forums could use an overhaul on that. I'm tired of using imagehosts just to post a screenshot...
All is up to date. Rebuild all my systems with Win11 recently.

It might be related to an issue I fixed internally these days, also affected RAVUresize I think. I'm updating TransformsPack partially today, and Main for tomorrow.

No worries. I'll get back to that film after the holidays. ;)



EDIT: By the way, I'm preparing a guide for a correct home theater set up in regards to display and surround environment luminance levels, as well as white point. It will be scientific based, not by the common known standards.

Definitely interested on that. :)

[Fjord]

I am looking for a spatial median filter with variable x and y radius, where radius is large (for example 30 to 80 pixels). Something like ex_blur() with radius and radiusV parameters, or ex_gaussianblur() with sigma and sigmaV parameters, but where the operation is median rather than mean/smooth. MedianBlur2 woud be good if it had separate horizontal and vertical radius parameters - but it does not.

The purpose is for filling in sprocket holes and film gate edges on overscan scans of 8mm film - prior to image stabilization.

I have tried ex_median(mode="vertical") and VerticalMedian(), but these don't seem to make any noticable change in my 2K videos - probably because these are radius=1 or 2 operations, and I am looking for much bigger spatial effect.

Since ex_median() does not have a radius parameter, what would be the proper way to obtain an effective larger spatial radius using ex_median()? Chaining calls to ex_median() doesn't seem to do anything on my video. (ie. ex_median().ex_median().ex_median()...)

ps. I have even tried AvsInpaint() with masking, but this is very difficult to tune for my purposes, and it doesn't work very well at edges of the frame.

[Dogway]

Use ex_luts() for anything convolution related.

For example you can use any shape for median defined in ex_shape() with mode="median" or "med"
ex_luts(mode="med",pixels=ex_shape(3,2))

The problem is there's a limit in pixel fetching, not per Expr() but I only could make up to 49 entries sorting networks which saturates a 7x7 square matrix (rad=3). I do think this is enough though, it will also run pretty slow already.

If it is for filling you can probably leverage ex_expand() with some masking. Or with the same mask downscale to half or quarter and apply the above ex_luts(), then upscale back and copy over. There's also infinite dilation that I think is what you tried using AvsInpaint.

Finally there's a trick to create your mask (without having a look at your footage), downscale down to holes matching 7 pixels on the highest dimension, do a Top Hat with ex_shape roughly matching the shape, and clean the mask. Now you can apply any kind of blur/median and copy over the upscaled version.

[Fjord]

Thanks, I’ll try your suggestions in the coming days and report back.

[guest]

I know that "we" need to be "in the mood" to work thru things like this, so thankyou for your suggestions :)

However, from the script you showed, I added GradePack, and it now works :)

Import("%AVISYNTHPLUGINS%\PD_TOOLS\EXTOOLS\ExTools.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\GRADE-PACK\Grade Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Models.avs")
Import("%AVISYNTHPLUGINS%\PD_TOOLS\TRANSFORM-PACK\Transforms Pack-Transfers.avs")
video=WhitePoint(video,temperature=6504, matrix="709", locus="Daylight", observer=1931, list=false, tv_range=true)

I just need to tweak the settings until I get the desired result.

FYI, it DOES need all the Transforms ;)

:thanks:

This has stopped working for me :(

Has a problem with this:-

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1584

[Dogway]

Ok, scale_space logic in "TransformsPack - Main" was dragging out the release, so I will upload what I have in the evening after some checks. The logic refactor is only for linear inputs with scale_space, a bit of a corner case, but it can be extended for log inputs as well.

After this update, only the scale_space logic refactor remains.

[Tempter57]

Dogway

Now at usage QTGMCp it is necessary to use ahead
propSet ("_DurationDen", mode =?)
Why about it it is not told words?
What value mode is necessary for setting for different source codes?

[Dogway]

@Tempter57: Good point. I don't know what source loaders don't populate the '_Durationxxx' props, but just in case I added some checks in QTGMC+ and ResizersPack nnedi3wrap() and EEDI3wrap().

@TDS: Please check now, I updated all three TransformsPack scripts. I will keep working on it further if issues arise and for the mentioned scale_space logic, as well as finishing some HDR wip functions I added today.

[guest]

@Tempter57: Good point. I don't know what source loaders don't populate the '_Durationxxx' props, but just in case I added some checks in QTGMC+ and ResizersPack nnedi3wrap() and EEDI3wrap().

@TDS: Please check now, I updated all three TransformsPack scripts. I will keep working on it further if issues arise and for the mentioned scale_space logic, as well as finishing some HDR wip functions I added today.

Just reporting back :)

Have updated EVERYTHING and it's now working like a charm ;)

PS:- Hopefully this will fix Reel.Deel's problems from here:-

https://forum.doom9.org/showthread.php?p=1980010#post1980010

&

https://forum.doom9.org/showthread.php?p=1980015#post1980015

:thanks: :thanks:

[Tempter57]

Dogway

Thanks you for the done adjustment of scripts. Now another matter: all works well and anything before QTGMCp it is not necessary to register.

[anton_foy]

https://forum.doom9.org/showthread.php?p=1953018#post1953018

It needs a low pass recover pass that I will add in the future to avoid blending/motion blur effect.

I know this is an old post but did you add this feature later on?

[Dogway]

https://forum.doom9.org/showthread.php?p=1953018#post1953018

I know this is an old post but did you add this feature later on?

I guess it's the 'LFR' option, the higher the more you recover.

I'm taking a few off days, will resume to finish the HDR functions and the scale_space logic, I've been brewing some ideas.

[VoodooFX]

What is "SMPTE_legal" and "nmod" in your Stabilization Tools Pack?
Btw, Stab there duplicates with original, maybe rename it to Stab4.

[Dogway]

Stabilization Tools Pack is considered legacy. It needs a serious rehaul but it's not easy task.
nmod (https://github.com/Dogway/Avisynth-Scripts/blob/58cd3bc0aba9d41dbdad913095783fd490d5d0f8/ResizersPack.avsi#L1200)() is to round numbers to multiples of modulo. Reduces boilerplate code like (n/mod)*mod and adds some features.
SMPTE_legal (https://github.com/Dogway/Avisynth-Scripts/blob/58cd3bc0aba9d41dbdad913095783fd490d5d0f8/TransformsPack%20-%20Transfers.avsi#L1185)() is to convert clip range into SMPTE legal range (from full saturated range) or the inverse operation. Also adds some features like SMPTE+ (aka broadcast range), and decoupled Y/UV conversion.
What is the original Stab?

[VoodooFX]

There is no mention of "ResizersPack.avsi" & "TransformsPack - Transfers.avsi" in requirements, I was wondering why it's not working.

Original Stab: http://avisynth.nl/index.php/Stab

[Dogway]

It's slightly updated internally but didn't upload cause it needs a bigger refactor. I just uploaded what I have but it's still considered legacy.

[guest]

Does Whitepoint() require MT, it's just that when I use it, or add it another script, the encoding speed drop's of a cliff :(, especially with 4K HDR.
It's not pushing the CPU anywhere near 100%.

[kedautinh12]

Add prefetch

[guest]

Add prefetch

I was just coming back to update my post...there is an option within RipBot where you can add certain filters/scripts to a multi-thread option, I guess it's a prefetech of some kind, and it's made a HUGE difference, the CPU is running at 100% most of the time :)

[Dogway]

If you want more speed you can exploit the function by replacing YUV_to_RGB() and RGB_toYUV() with avsresize.

[guest]

If you want more speed you can exploit the function by replacing YUV_to_RGB() and RGB_toYUV() with avsresize.

Thanks, but I think I'm going to need an example (or 2)

Sorry.

[Dogway]

Replace lines 1484,1485 and 1582,1583 with:
z_ConvertFormat(pixel_type="RGBP"+string(ID[7]),resample_filter="spline36")
and
z_ConvertFormat(pixel_type="YUV420P"+string(ID[7]),resample_filter="spline16")
respectively

[guest]

Replace lines 1484,1485 and 1582,1583 with:
z_ConvertFormat(pixel_type="RGBP"+string(ID[7]),resample_filter="spline36")
and
z_ConvertFormat(pixel_type="YUV420P"+string(ID[7]),resample_filter="spline16")
respectively

This doesn't make too much sense to me...

This is changing GradePack.avsi directly, correct ??

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi

So these are lines 1484 & 1485 :-

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1484

rgb ? rgbp ? c : ConvertToPlanarRGB(c) : \
YUV_to_RGB(c, mat[0], tv_in=tv, tv_out=false, kernel="lanczos", b=3)

And these are lines 1582 & 1583 :-

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1582

rgb ? rgbp ? last : MatchClip(c,internal=true) : \
RGB_to_YUV( mat[0], tv_in=false, tv_out=tv, kernel="bicubic", b=-0.5, c=0.25, Jab=PixelType(c))

How can replacing 2 lines with one, work...I don't understand :(

Do I need to add avsresize to the script ??

I'm clearly in the wrong place, here.

[kedautinh12]

You can change
YUV_to_RGB(c, mat[0], tv_in=tv, tv_out=false, kernel="lanczos", b=3)to
z_ConvertFormat(pixel_type="RGBP"+string(ID[7]),resample_filter="spline36")

And
RGB_to_YUV( mat[0], tv_in=false, tv_out=tv, kernel="bicubic", b=-0.5, c=0.25, Jab=PixelType(c))to
z_ConvertFormat(pixel_type="YUV420P"+string(ID[7]),resample_filter="spline16")

[guest]

You can change

Thankyou my friend, I will try this tomorrow :)

[StainlessS]

You can change
...
to
z_ConvertFormat(pixel_type="RGBP"+string(ID[7]),resample_filter="spline36")
And
...
to
z_ConvertFormat(pixel_type="YUV420P"+string(ID[7]),resample_filter="spline16")


Looks to me like too many closing parentheses ")"

[kedautinh12]

Looks to me like too many closing parentheses ")"

I just copy from Dogway :D

[VoodooFX]

Looks to me like too many closing parentheses ")"
Looks OK for me.

[StainlessS]

Yeah, sorry, I missed this one,
z_ConvertFormat(pixel_type="RGBP"+string(ID[7]),resample_filter="spline36")
Old Age :(

[VoodooFX]

Old Age :(
Happens, we will train ChatGPT on your posts, and after you are gone we'll replace you with StainlessS-GPT. It will continue to help us with the scripts and maybe even it will write the new nice plugins for us. :sly:

[StainlessS]

Somebody just released a Chat Bot thingy to tell if essay/article was written by human or bot.
Was in the press either yesterday or day before.

EDIT: Maybe it was an Android/iPad app, accessing a chatbot whotsit.
Think I maybe saw it linked via CodeProject stuff I get via email.

[guest]

Thankyou my friend, I will try this tomorrow :)

Originally Posted by kedautinh12
You can change

YUV_to_RGB(c, mat[0], tv_in=tv, tv_out=false, kernel="lanczos", b=3) original line 1485
to
z_ConvertFormat(pixel_type="RGBP"+string(ID[7]),resample_filter="spline36")
And
RGB_to_YUV( mat[0], tv_in=false, tv_out=tv, kernel="bicubic", b=-0.5, c=0.25, Jab=PixelType(c)) original line 1583
to
z_ConvertFormat(pixel_type="YUV420P"+string(ID[7]),resample_filter="spline16")

So despite all the comments about ), I am getting an error with Line 1485.

And before anyone ask's, I cannot provide an error log :(

https://github.com/Dogway/Avisynth-Scripts/blob/master/GradePack.avsi#L1485

Which strangely is the first one to be changed :(

So there's a possibility that line 1583 will produce a similar error.

[guest]

Yeah, sorry, I missed this one,
z_ConvertFormat(pixel_type="RGBP"+string(ID[7]),resample_filter="spline36")
Old Age :(

Speaking of which :-

It would be nice if this was updated :-

https://forum.doom9.org/showthread.php?t=176546

[kedautinh12]

Don't ask age of ssS, it's no meaning. He/she is a android :D

[StainlessS]

All I/we need is a little squirt of oil:- https://www.youtube.com/watch?v=louBM-Mix7s

EDIT: To below: thanks, nice of you to say so :)

EDIT: To Below below: So, was not a total waste of time, I thought it way too subtle for the average D9'er. :)

[guest]

All I need is a little squirt of oil:- https://www.youtube.com/watch?v=louBM-Mix7s

HeartlessS

EDIT: To above: You're welcome, I got the connection from the ending of that YT clip... :D

[anton_foy]

In MCDeblockFFT3D I noticed that you use "pre" (which is converted to 8bits) before MCompensate followed by convertbits(bi,etc...). Is there a particular reason that you need to use mcompensate in 8bits here? Also when I tried this script but replaced with only deblock() after compensation I get weird blocking artefacts on higher motion.

[Dogway]

In MCDeblockFFT3D I noticed that you use "pre" (which is converted to 8bits) before MCompensate followed by convertbits(bi,etc...). Is there a particular reason that you need to use mcompensate in 8bits here? Also when I tried this script but replaced with only deblock() after compensation I get weird blocking artefacts on higher motion.

If I don't do that I have to create another super clip for the original bitdepth clip. All in all turns to slow down the script quite a bit, FFT3D is already hella slow anyway...

[anton_foy]

If I don't do that I have to create another super clip for the original bitdepth clip. All in all turns to slow down the script quite a bit, FFT3D is already hella slow anyway...

Ok thanks I see now. But still I don't understand why I get these strange artifacts.

[Dogway]

Just checked with default MCDeblockFFT3D() and it's not blocking but bad block matching of MCompensate. This was a very early approach to motion compensated deblocking back in the days. Currently I would recommend you to feed a deblocked prefilter to SMDegrain, so MDegrain can do the temporal deblock, and probably feed the same clip to Mfilter to deblock spatially on non-matching blocks.

[madey83]

Just checked with default MCDeblockFFT3D() and it's not blocking but bad block matching of MCompensate. This was a very early approach to motion compensated deblocking back in the days. Currently I would recommend you to feed a deblocked prefilter to SMDegrain, so MDegrain can do the temporal deblock, and probably feed the same clip to Mfilter to deblock spatially on non-matching blocks.

@Dogway

Could you please provide some example how to add deblocking into SMDegrain and Mfilter?

[Dogway]

It's straight forward:
pre=Deblock_QED(quant1=30, quant2=40) # You can (it's safe to) go overboard or use more destructive deblockers here
SMDegrain(2, 200, mode="MDegrain", prefilter=pre, mfilter=pre)

You might be tempted to simply use deblock before smdegrain (as input), but that's blurrier.

[madey83]

It's straight forward:
pre=Deblock_QED(quant1=30, quant2=40) # You can (it's safe to) go overboard or use more destructive deblockers here
SMDegrain(2, 200, mode="MDegrain", prefilter=pre, mfilter=pre)

You might be tempted to simply use deblock before smdegrain (as input), but that's blurrier.

Thank you 😊

[Emulgator]

Just throwing in a suggestion to extend QTGMCp requirements list
# AviSynth 3.7.3 (because of propcopy extended parameters)
(I was searching today for dependencies, it took some good time to get these all together and finally serving the first frame.)

And while we are at it:
Who was unlucky so far to get Groucho's sysinfo64.dll running:
sysinfo64.dll wants msvcr100.dll 10.0.30319.1 (18.03.2010 809KB) in system32
https://forum.doom9.org/showthread.php?p=1981167#post1981167

[kedautinh12]

I remember still use normally QTGMCp with lastest ver of sysinfo. I think you can try install latest vc++ pack
https://github.com/abbodi1406/vcredist/releases

[Dogway]

Visual C++ 10.0.30319.1 ? I don't have that but VCPP 2010 10.0.40219.325 and it works.

Maybe it works with any of the 2010 family.

I will try to check when propcopy extended params were implemented, because if that's so I'll need to promote all scripts to 3.7.3 requirement.

[kedautinh12]

Visual C++ 10.0.30319.1 ? I don't have that but VCPP 2010 10.0.40219 and it works.

Maybe it works with any of the 2010 family.

I will try to check when propcopy extended params were implemented, because if that's so I'll need to promote all scripts to 3.7.3 requirement.

Cause you have later ver, you meet error only when have former ver

[Dogway]

@Emulgator, the propcopy extended features belong to 3.7.2 (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.2), unless it's something else that requires v3.7.3.

EDIT: It must be the new NNEDI3CL requirements (https://github.com/Asd-g/AviSynthPlus-NNEDI3CL#requirements), r3682 (r3689 recommended) and VCPP. The exact VCPP I don't know, maybe someone can have a look at dependency walker. And r3682 is basically v3.7.3 right?

[LeXXuz]

New year and I think it's time to do some house keeping. :D

What is the deal with this AVS+ 3.7.3?

I updated QTGMC+ and all other things that have been changed/updated recently (gee, I really could use an auto-updater for all those files :D) because I could not get QTGMC+ to work, even with default settings. MeGUI simply crashed upon script load and sadly didn't tell me where it hurts.

Now, after updating the files QTGMC+ requires 3.7.3 but there is still 3.7.2 the latest version on avs-plus.net :confused:

And if I'm just at it: which version of NNEDI3CL/EEDI3CL should I use and (where to get)?

Also which version of mvtools? Still the kinda old 2.7.45? What about DTL's latest versions? I tried those, but couldn't get them to work with SMDegrain.

I kinda lost overview with all those updated files, I know. :o

[kedautinh12]

I use latest ver of all with Megui normally. About MVtool still use Pinterf stable ver than DTL beta build

[kedautinh12]

If Megui crash don't alert error. You can try AvsPMod, errors will appear

[guest]

New year and I think it's time to do some house keeping. :D

What is the deal with this AVS+ 3.7.3?

I updated QTGMC+ and all other things that have been changed/updated recently (gee, I really could use an auto-updater for all those files :D) because I could not get QTGMC+ to work, even with default settings. MeGUI simply crashed upon script load and sadly didn't tell me where it hurts.

Now, after updating the files QTGMC+ requires 3.7.3 but there is still 3.7.2 the latest version on avs-plus.net :confused:

And if I'm just at it: which version of NNEDI3CL/EEDI3CL should I use and (where to get)?

Also which version of mvtools? Still the kinda old 2.7.45? What about DTL's latest versions? I tried those, but couldn't get them to work with SMDegrain.

I kinda lost overview with all those updated files, I know. :o

Yes, there were certainly a LOT of updates...

I also haven't had any success with DTL's mvtools builds :(

https://gitlab.com/uvz/AviSynthPlus-Builds

https://github.com/Asd-g/AviSynthPlus-NNEDI3CL/releases/

[kedautinh12]

With NNEDI3CL 1.0.6 need bin from here to work
https://github.com/Asd-g/AviSynthPlus-NNEDI3CL/blob/main/src/nnedi3_weights.bin

[LeXXuz]

Yes, there were certainly a LOT of updates...

I also haven't had any success with DTL's mvtools builds :(

https://gitlab.com/uvz/AviSynthPlus-Builds

https://github.com/Asd-g/AviSynthPlus-NNEDI3CL/releases/

Thanks TDS. Up and running. :)

However, I still can't get subpixel=4, pel=4 to work with gpuid=0 in SMDegrain. Still that "nnedi3wrap: Field must be 0 or 1 for scaling" error in ResizersPack, line 678. Again, subpixel 1,2,3 work fine.

Updated SMDegrain and ResizersPack to latest version (and about a dozen other script files from Dogways repo :D)

[kedautinh12]

Thanks TDS. Up and running. :)

However, I still can't get subpixel=4, pel=4 to work with gpuid=0 in SMDegrain. Still that "nnedi3wrap: Field must be 0 or 1 for scaling" error in ResizersPack, line 678. Again, subpixel 1,2,3 work fine.

Updated SMDegrain and ResizersPack to latest version (and about a dozen other script files from Dogways repo :D)

Can you share full scripts??

[kedautinh12]

Thanks TDS. Up and running. :)

However, I still can't get subpixel=4, pel=4 to work with gpuid=0 in SMDegrain. Still that "nnedi3wrap: Field must be 0 or 1 for scaling" error in ResizersPack, line 678. Again, subpixel 1,2,3 work fine.

Updated SMDegrain and ResizersPack to latest version (and about a dozen other script files from Dogways repo :D)

just add propSet("_FieldBased",0) before SMDegrain, and it's work well. It's same error when use Deep_Resize after Deinterlaced with TIVTC, you need add propSet("_FieldBased",0) between Deep_Resize and Deinterlaced filter to work well. I know you don't rep me cause you think me noob:p

[Dogway]

I'm adding a fix for nnedi3wrap() and SMDegrain(), uploading in a few minutes, but for Deep_Resize() TIVTC should be updated with frameprops, not my fault that progressive is still tagged as interlaced.

[LeXXuz]

I know you don't rep me cause you think me noob:p

I never said nor think that! :confused: I appreciate your readiness to help others. ;)

I'm adding a fix for nnedi3wrap() and SMDegrain(), uploading in a few minutes, but for Deep_Resize() TIVTC should be updated with frameprops, not my fault that progressive is still tagged as interlaced.

Thanks Dogway for the quick response. And please never ever think someone here is blaming you for anything. Quite the contrary, your tireless efforts with all your scripts are very much appreciated and a tremendous help! :thanks:

[Dogway]

Just updated the remaining ResizersPack. Hope all issues are ironed out now.

[LeXXuz]

Just updated the remaining ResizersPack. Hope all issues are ironed out now.

https://abload.de/img/screenshot2023-01-181tzf0a.png (https://abload.de/image.php?img=screenshot2023-01-181tzf0a.png)

Please don't shoot me. :D

[Dogway]

WARN: From here on and for the next 9 pages mostly @TDS basic AVS usage questions (deleted posts make it down to 6 pages). Skip to page 102 (https://forum.doom9.org/showthread.php?t=182881&page=102).

You need to provide your SMDegrain call.

EDIT: Just updated adding some additional checks, still if your source is progressive and is flagged as interlaced you need to explicitly declare interlaced=false

[LeXXuz]

Here's the entire script:
# Set DAR in encoder to 162 : 95. The following line is for automatic signalling
global MeGUI_darx = 162
global MeGUI_dary = 95
#
SetMemoryMax(40960)
SetCacheMode(0)
#
LoadPlugin("C:\Video Editing\MeGUI (x64)\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("G:\WORK\Test.mkv")
#
AssumeFPS(25)
CTelecine()
CPostProcessing()
crop(28, 4, -28, -4)
#
ConvertBits(16)
SMDegrain(mode="MDegrain", tr=12, thSAD=240, contrasharp=true, LFR=true, DCTFlicker=true, refinemotion=true, truemotion=true, blksize=16, search=5, pel=4, subpixel=4, chroma=false, plane=0, gpuid=0)
SMDegrain(mode="MDegrain", tr=12, thSAD=120, thSADc=120, contrasharp=false, LFR=false, DCTFlicker=false, refinemotion=true, truemotion=true, blksize=24, search=5, pel=4, subpixel=4, chroma=true, plane=4, gpuid=0)
F3KDB_3(range=20, Y=36, Cb=24, Cr=24, grainY=24, grainC=12, dither_algo=2)
Prefetch(48,48)
Return(Last)
#

The 2nd call of SMDegrain causes the error, like the one with the fields before. If I just run the first call it works with subpixel=4.
With subpixel=3 both instances run fine.

[Dogway]

Yes, so what I said above, if your source is progressive and tagged as interlaced, either change the tag with propSet("_FieldBased",0), or use interlaced=false.

Just updated SMDegrain for a typo.

[LeXXuz]

But I don't understand why the 2nd call causes the error and the 1st one doesn't. They are literally the same, no?

[madey83]

@Dogway,

in your SMDegrain script you mentioned lot of modes, but in dokumention i can't find them and what are differents between them and use cases:
string "mode"="MDegrain" ("MDegrain"/ "MedianT"/ "MedianST"/.........

Could it be possible to give a light on them?

[Dogway]

@LeXXuz: The first call isn't correct either, you are treating a progressive clip as interlaced, therefore denoising might not behave as you expected. If it doesn't raise an error it doesn't mean it's correct.

@madey83: Yes, docs are work in progress. Check mode descriptions here (https://github.com/Dogway/Avisynth-Scripts/blob/b54d3880314a3e19f345136adec33df26f56101e/ExTools.avsi#L2298).

[LeXXuz]

@LeXXuz: The first call isn't correct either, you are treating a progressive clip as interlaced, therefore denoising might not behave as you expected. If it doesn't raise an error it doesn't mean it's correct.


Sorry but I can't follow you. I clearly must've missed something in the docs. I thought quarter-pel and Nnedi (may) increase accuracy or are these for interlaced sources especially and not suitable for progressive video:confused:
I just wanted to use NNEDICL to distribute a little more work to the GPU.

EDIT: It works now with propset but don't think I will use NNEDICL in this constellation. It eats up GPU memory like crazy. Thx kedautinh12 and Dogway.

[StainlessS]

Here's the entire script:
...
SetMemoryMax(40960)
Is that intentional ? (40GB) :eek:

[LeXXuz]

Is that intentional ? (40GB) :eek:

Yes. I edited out custom prefiltering which eats a lot of memory.

[LeXXuz]

FIY: Wolfram Rhodium pushed a new update of BM3DCUDA for Avisynth+ :)
https://github.com/WolframRhodium/VapourSynth-BM3DCUDA/discussions/20

[anton_foy]

Dogway can you explain what the denoising part in this (https://forum.doom9.org/showthread.php?p=1968320#post1968320) post is doing and how please?

[Dogway]

WARN: From here on and for the next 9 pages mostly @TDS basic AVS usage questions (deleted posts make it down to 6 pages). Skip to page 102 (https://forum.doom9.org/showthread.php?t=182881&page=102).

Dogway can you explain what the denoising part in this (https://forum.doom9.org/showthread.php?p=1968320#post1968320) post is doing and how please?

I don't remember well. He said it was a bit noisy so whatever denoiser it suited. Then I run ex_median() with the "shift back by one" trick, not sure why maybe to reduce ringing a bit further I think.

[guest]

I have been able to use this on a couple of encodes, but on other's, it just refuses to start encoding :(

I checked the dependencies,

https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi#L75

And I have all but "vsTCanny" & "fmtconv".

I'm just using deep_resize(3840,grain=0)

will adding these, fix it ??

[kedautinh12]

What errors?? Can't fix without errors

[kedautinh12]

Do you add propSet("_FieldBased",0) before deep_resize??

[Dogway]

This works for me:
setmemorymax(2048*4)
ffvideoSource("720p_src.mkv")

ConvertBits(16)

deep_resize(3840,grain=0)

Prefetch(8)

You don't need "_FieldBased" frameprop for my scripts.

[kedautinh12]

Thanks for the info, but I'm still have a strange problem.

I am wanting to upscale a 1920 to 3840, but in this case, if I use the 3840 it won't start, but if I change it down to 1920, it's OK, and 1280 downscaling doesn't work either.

It worked on a couple of other video's. They must be different, some how :(

Strange (to me)

Are you try me suggestion??

[kedautinh12]

If your source interlaced you need add propSet("_FieldBased",0)

[kedautinh12]

Just add propSet("_FieldBased",0) above deep_resize
propSet("_FieldBased",0)
Deep_Resize(...)

[kedautinh12]

Yes, that position

[kedautinh12]

Sorry to say, it doesn't change anything.

It's OK @ 1920, but as soon as it's 3840, it doesn't start.

In AVSMeter, it starts to check the script, the little cursor is flashing, then it stops :(

I'm going to delete my previous post.

Can you share your scripts and sample??? I think Deep_Resize relate post, don't need delete. Reel.Deel won't angry for that :D

[kedautinh12]

Of course

[Dogway]

Wel 1920 for 1920 is noop right? By the way I found that TIVTC was updated recently and didn't notice, it's now v1.0.27 with preliminar frame properties support, but still won't change "_FieldBased" prop, it seems to write other non normative props like "_FieldOrder" and so on... so for any issue related to IVTCed clips not tagging properly refer to its repo, either here (https://github.com/pinterf/TIVTC/issues/36), here (https://github.com/pinterf/TIVTC/issues/32)or here (https://github.com/pinterf/TIVTC/issues/18).

Also share a small snippet of the clip to see what's going on, but more likely must be an outdated script?

[Dogway]

Basically wait until TIVTC supports frame property writing and in the meanwhile add propSet("_FieldBased",0) after IVTCing your source. QTGMC+, ex_bob() or nnedi3wrap() are fine on that regard for deinterlacing. If that's not your issue post a clip with the script so I can test if something is going wrong.

[LeXXuz]

@LeXXuz: The first call isn't correct either, you are treating a progressive clip as interlaced, therefore denoising might not behave as you expected. If it doesn't raise an error it doesn't mean it's correct.


Dogway could you please explain this to me in more detail? I'd like to understand what I may did wrong. 🤔
I paused my work for now as I'm afraid I have to do it all over again because I misunderstood some of the parameters. 😭

[simple_simon]

I'm getting an avisynth script error

NNEDI3CL: Invalid Program

and it lists lines 738, 739, 740, 355, 234, 260 in the Resizers Pack and lines 938 & 1318 in the Transforms Pack

I'm using the latest versions of everything and default settings

propSet("_FieldBased",0)
deep_resize(960)

If I change "edge" to something other than nnedi3 then it works

[Dogway]

You didn't post the most important, your source loader.

In any case the script worked for me, the clip is progressive, and quite scarce of details so you are not going to gain that much by simply deep_resize() without extra sharpening. And SMDegrain, didn't find a reason to use.

My suggestion:

video=ffvideosource("src.mkv")
video=ConvertBits(video,16)
video=Tweak(video,hue=0,sat=0.8,bright=2,cont=1)
video=deep_resize(video,3840,grain=0.4,qual=2,deconv=-1,sharpness=30)

video

Don't forget to output to 10-bit or 8-bit, depending on encoding settings.

grain is a personal choice, it adds detail hallucination as well as a more filmic look.

My guess is something must be outdated on your end. You need AVS+ v3.7.3 test3 and NNEDI3CL v1.0.6, latest versions of FFMS2 (https://forum.doom9.org/showthread.php?p=1982035#post1982035) or DGDecNV, and latest versions of ExTools, ResizersPack, SharpenersPack and TransformsPack.

Dogway could you please explain this to me in more detail? I'd like to understand what I may did wrong. ��
I paused my work for now as I'm afraid I have to do it all over again because I misunderstood some of the parameters. ��

Simply add propSet("_FieldBased",0) after TIVTC, since as I explained above (https://forum.doom9.org/showthread.php?p=1981961#post1981961) the plugin is not tagging properly the clip.

[Reel.Deel]

It would be great if there was some automatic notifier for your "stuff".


"Watch" the project on GitHub. You'll get notified for any activity if you choose to.

https://i.ibb.co/jvVNM0y/github-watch.png

[poisondeathray]

I used ripbot many years ago. I just downloaded ripbot and it works for me on that sample and script either by loading a script (ripbot will Import()) , or pushing the avisynth button in ripbot and adding the lines (I'm assuming the latter way is you're using it)

I think writing a script is the better way to do it - and it's easier to debug errors . You should learn how - because it's slower to use ripbot as a script editor. You will thank yourself later.

If you don't seem to be getting error messages or feedback... Look in the temp folder, the job1 folder for the log files and info files to see if you've missed something . Hard for anyone to help with no clues or error messages

BTW, there is nothing unique about the avisynth aspect of ripbot - it just uses the notation video=blah instead of "implied last"

eg.
video=deep_resize(video,3840,grain=0,qual=2)

is really the same thing as

deep_resize(last, 3840,grain=0,qual=2)

where the "last" is implied , so you don't have to write it

deep_resize(3840,grain=0,qual=2)

[poisondeathray]

BUT, I have to ask, if you just downloaded RB, it would have been an older build, and it doesn't support ANY of Dogway's scripts (whatever you want to call them).

RipBot264v1.26.0 from 1st post
https://forum.doom9.org/showthread.php?t=127611




How do I do this :- "You should learn how - because it's slower to use ripbot as a script editor. You will thank yourself later"


Learn basic avisynth, use avspmod or vdub2. It takes longer for ripbot to "get info" and parse. Moreover, you can get useful error message all the time, and people can actually help you

As mentioned above, ripbot will work perfectly fine with "other" scripts . It will use Import() ("underneath the hood", you can look at the temp files to see what it's actually doing)

[poisondeathray]

I'm sorry, I strongly disagree that that script will work with RB 1.26.0.

That "vanilla" build doesn't support many of the calls in that script !!! I just tried it with RB 1.26.2 vanilla, and AVSMeter threw up an error immediately.

I also "imported" that script, and it had a decoding error with mvtools2.

Yes it definitely works.

Ripbot will use the local avisynth configuration, it doesn't need to support any calls. eg. If I have avisynth installed locally, it can and will use that. If I have autoloading plugins on the local avisynth install, it can and will use them. Ripbot runs on avisynth - it's not some completely different entity . Ask atak if you don't believe me...

So all I added when pushing avisynth button , was:


video=ConvertBits(video,16)
video=Tweak(video,hue=0,sat=0.8,bright=2,cont=1)
video=propSet(video,"_FieldBased",0)
video=deep_resize(video,3840,grain=0,qual=2)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=2,str=1.2,refinemotion=true)


because Ripbot autogenerated the video=LWLibavVideoSource... line

I didn't use your LoadPlugin calls or Import calls, because my paths are different. Check that yours are correct. (And you don't need SMDegrain for that source, but i left it in there for fun)



When you push the aviysnth button, add the lines, push ok, does ripbot accept it ? After pushing ok on ripbot's avisynth screen, a valid script should produce an info.txt file in the job1 temp folder. If the script is invalid, info.txt will be missing. For example if I purposely sabotage the script by adding video=blah it will not generate info.txt

If you push avisynth button (check that the added lines are still there and correct), push preview script, the default media player should pop up (mine is set to mpchc), and it should give you an error message if something is wrong . What does it say? or does it hang ?

[kedautinh12]

@TDS, sr for answer lately, i'm busy all yesterday. I checked your sample and it's work with deep_resize normally

[poisondeathray]

I don't follow your "procedure"..."push the avisynth button", then where do you go to add that....



I mean back on the Encoding Settings page.

To be clear:
When I add the .mkv, the page will say "Encoding Settings" at the top right. There is an avisynth button besides the CRF box.

Pushing the avisynth button, and pushing "show video script" will display the current script. I copy/paste into that script in the location directly underneath the autogenerated video=LWLibavVideoSource... line. There is a "preview script" button, and an "ok" button on the bottom right. Is this sufficient description?



MPC-HC doesn't not display any errors, either.


But does it play the filtered video properly ? Is it 3840 width ? What does it show, exactly ? black screen ? 1920 video ? what ??

If you change the script to just the video=LWLibavVideoSource... line (ie. delete all the added stuff) , preview script, what does MPCHC show, exactly ?



Do you have avisynth+ installed , or is everything under the ripbot directory in a sort of "portable" version ?

[poisondeathray]

I do not have Avisynth installed, it's ALL in the RipBot folder, so it's installed for RB to use.


When you "upgrade" avisynth , how are you doing that ? Just drop in / replace the .dll ?


AVSMeter stalls, MPC-HC doesn't display anything, naturally.

Does MPCHC pop up with black screen? That still displays black screen. That's something. Or does MPCHC not open at all ? Describe it exactly

Answer the other question



If you change the script to just the video=LWLibavVideoSource... line (ie. delete all the added stuff) , preview script, what does MPCHC show, exactly ?

[poisondeathray]

What question.


Seriously ? The question in quotes . Look closely at the last post. I quoted myself because you didn't answer the question the first time, I thought maybe you missed it


Delete all the added lines and replace LWLibavVideoSource line with

video=version()


You might have to push ok, the avisynth button again for the changes to get accepted. Push preview script. What does it say ?



I have to add that I am using the Pauly Dunne build that are highly modded !!!
Maybe some things got broken ? Where is it ?

[Reel.Deel]

I had other ppl tell me how to use scripts with RipBot, and it doesn't work, even tho they say it does.


It did and does work, PDR and I proved it to you in another thread (https://forum.doom9.org/showthread.php?p=1965689&highlight=ripbot#post1965689). You're set on using RipBot and don't want to learn another way. That is fine and all, but it makes it harder for anyone trying to help you. A simple problem becomes a 20+ post discussion... I don't use RipBot, and this would be my second time using it and I was able to follow all that PDR said.

Anyways, I have not used or updated Dogway's script in a while and updated just now to see if I could help out.

No error:
Blankclip(width=1920, height=1080, pixel_type="YUV420P8")
deep_resize(1920)

Error:
Blankclip(width=1920, height=1080, pixel_type="YUV420P8")
deep_resize(3480)

Avisynth open failure:
ArrayGet: Array index out of range. Problematic index count: 1
(TransformsPack - Main.avsi, line 519)
(ResizersPack.avsi, line 245)
(ResizersPack.avsi, line 260)
(E:test.avs, line 9)

BTW Dogway, you have some duplicate scripts in the EX mods and MIX mods folders.

[poisondeathray]

Yeah, seriously, this is getting way off topic AFAIC, all I wanted to know is why this Dogway deep_resized script works on some clips, and not on others, but on the clips it doesn't start, simply changing the res size to the size of the clip, it works, so what is the point.

Which clips does it work on? What are the differences ? For example, do you have other same dimension sources where you upscale the same amount and it works ?

They are important questions if you want to get it working

Version verifies the avs version loaded. Dogway's scripts requires a specific version or newer. You have a portable version, are you certain it's getting called correctly ? This will verify which version is getting called within your version of ripbot

The MPCHC question with "regular script" is to debug whether or not you have issues with the MPCHC chain - how reliable of a feedback tool is it, if you cannot preview other scripts or get "regular" error messages ? You need to start at a baseline with known debugging tools.


Now you're trying to teach me how to use RipBot in way that I feel is not necessary.

Changing the default scripts just leads to errors (for me).

What I wrote works for Atak's ripbot



I had other ppl tell me how to use scripts with RipBot, and it doesn't work, even tho they say it does.

How std RipBot can use a script with multiple Dogway scripts & dependencies, is beyond me.


It definitely works here with Atak's version. Both methods work - loading an avs script directly , or through the copy/paste procedure outlined above

One difference is I have installed avs+, installed plugins - and I can verify the script works in multiple programs (ie. previews in avspmod) . The problem on your end "feels" like one of the dependencies is wrong




All I can say is that most custom scripts I "throw" at RipBot, using the "Custom" script procedure works about 99% of the time, and with the one's I can't get to work, I won't pursue them further.


ok, just trying to help

[poisondeathray]

It did and does work, PDR and I proved it to you in another thread (https://forum.doom9.org/showthread.php?p=1965689&highlight=ripbot#post1965689). You're set on using RipBot and don't want to learn another way. That is fine and all, but it makes it harder for anyone trying to help you. A simple problem becomes a 20+ post discussion... I don't use RipBot, and this would be my second time using it and I was able to follow all that PDR said.


And I verified the copy/paste ripbot method works too (loading video directly, pushing avisynth button, push show video script, copy/paste, etc...)

But I noticed for certain types of changes, you need to push ok, to go back to the 1st screen and avisynth button again for things to get accepted properly - that might be a user beware issue

[Reel.Deel]

Error:
Blankclip(width=1920, height=1080, pixel_type="YUV420P8")
deep_resize(3480)

Avisynth open failure:
ArrayGet: Array index out of range. Problematic index count: 1
(TransformsPack - Main.avsi, line 519)
(ResizersPack.avsi, line 245)
(ResizersPack.avsi, line 260)
(E:test.avs, line 9)


False alarm. I somehow missed that I still had an old "TransformsPack.avsi" script in the auto-load folder. I deleted it and now it works as it should.

And I see you found the same error in the deep resize script :)

What do you mean the same error? You have yet to tell us any error message besides it doesn't work :p

[poisondeathray]

And again, as I said it's a random fault, as I had success with it a few days ago where it resized from 1920 to 3840 without issue, and then when I tried the same script to others, then this "stalling" problem appeared :(


If you go back and repeat one of the "success" encodes, does it work today ?

Have you ruled out changes that you've made since then - e.g. maybe swapped in some bad version of a dependency ? Some windoze update ?

Have you ruled out HW issues, like overheating/cooling etc... ? Unlikely if it doesn't really even start encoding or previewing, but you have to rule out HW issues whenever you get something "random" happening



As for MPC-HC, I am using the latest build 2.0.0, if that's the difference there, so beit.

If it previews other scripts ok, posts error messages ok - you can rule that out as being the problem.

make an error script in ripbot like I posted earlier

video=blah

It should say "I don't know what 'blah' means" . If you don't get any error messages, then you have other problems you need to solve


I'm wondering if your test works as you have dependencies setup differently to me ???


I'm thinking something along those lines - it's the only likely explanation if other stuff works

installed avs+ version , autoloaded plugins - but it really shouldn't matter if you Import() avs/avsi's and LoadPlugin() for the correct .dlls.

There might be an issue if multiple .dll's with the same name are loaded or autoloaded and you have manual LoadPlugin() concurrently - which version actually gets loaded ? The usual avisynth answer is to clean out your plugins directory . You can move them, and/or change the directory name, and manually load all plugins explicitly, so you know exactly which ones are getting loaded


But if I run any scripts that have Dogways stuff, with std RB, it's does not work !!!


I don't see why it would work for a modded ripbot version, but not the original. Avisynth is avisynth. Ripbot is just a GUI

Maybe if the loaded avisynth.dll version, or some .dll was different or .dll conflict, or if some script referenced a path structure that was different - but you should get error messages for path errors

No error message is very bizzare... and makes it very difficult for anyone to help


Would you be interested in "testing" the Pauly Dunne build ??
I don't have time right now, but post the link, I might get to it eventually

[Boulder]

Try taking a look at the Details tab in Task Manager when the problem occurs. Is there some encoding related process that appears to be doing something, yet nothing visible happens?

[poisondeathray]

I could almost guarantee that if you didn't have this autoload folder (and I think most here, do have this), that using those scripts with std RipBot, would NOT work !!!

It will work - Because nothing in those scripts require autoloading. Autoloading is a convenience, not a necessity for those scripts. A handful of people still manually load everything. Your problem likely has more to do with specific versions

You perform the "cleanout plugins" procedure I mentioned above and load and import everything manually in the script. I can test it tomorrow if you're really interested



Some of your script names differ from Dogway's. Did someone (PD?) just rename them? Are you certain they are the correct updated versions ?
e.g

.
.

Import("C:\RipBot264_PD (17-01-23)\Tools\AviSynth plugins\PD_TOOLS\RESIZERS-PACK\Resizers Pack.avs")


There are spaces , where dogway's has none eg. "Resizers Pack.avs" instead of "ResizersPack.avsi" . You can Import .avsi files too. The point is when more stuff gets changed there is more chance of errors or mixups

The date in the path "C:\RipBot264_PD (17-01-23)" , suggests Jan 17,2023, yet there are updated versions by Dogway on the 18th including ResizersPack.avsi if you check the commits

[Reel.Deel]

I could almost guarantee that if you didn't have this autoload folder (and I think most here, do have this), that using those scripts with std RipBot, would NOT work !!!

I'm not petty enough to prove you wrong again :)... But hey, instead of doing things backwards, why don't you install avs+ with the installer? There's even a "Install.cmd" in the AviSynth Ripbot folder which installs the files in the same location as the official installer.

I thought you'd found an error...and the error is, no error message, it just doesn't start !!!


I did find an error, and the error was because of an old file I had. I corrected that and now it works. Maybe you have that too, who knows... It's just odd that there's no error message of any kind, and then you can't even try a simple "Version()" command like PDR asked. Oh well, hope you get it all sorted out.

[LeXXuz]

Simply add propSet("_FieldBased",0) after TIVTC, since as I explained above (https://forum.doom9.org/showthread.php?p=1981961#post1981961) the plugin is not tagging properly the clip.

Ah. Now I get you. I must have missed that somehow and thought my SMDegrain parameters may be wrong. Thanks. :)

[Dogway]

Hey TDS, calm a bit we are all helping here. Basically your issue is NNEDI3CL related I think. Three points I want to check, first, your Avisynth version is r3849 while pinterf latest version (test3) is r3835, at least for x64, unless you are in x86.
Second, never use anything other than FFMS2 or DGDecNV. To reassure this, I simply tested with LSMASH and it errored out ([Fatal] Failed to read an input file). Not sure if outdated plugin though.
Third, I presume you have nnedi3_weights.bin in your plugins path.
Fourth, test with a simple example to check whether it runs to discard deep_resize() from the equation.
video=ConvertBits(video,16)
video=nnedi3wrap(video,2)

video

[Dogway]

I don't know where you got r3849 from, test r3835 to be on the same page. (EDIT: Tested with r3849 and no issues, so you can skip this)

nnedi3_weights.bin is placed in the same folder as NNEDI3CL.

Test as I said with only the nnedi3wrap() call after doing the above, then we talk.

[kedautinh12]

He got from here:
https://gitlab.com/uvz/AviSynthPlus-Builds

[poisondeathray]

I just tried this "version()" where I believe that PDR told me to put it, and it just errors asking for the lsmash path.


What I meant by deleting the added lines is the copy/pasted lines that got from your test example:


video=ConvertBits(video,16)
video=Tweak(video,hue=0,sat=0.8,bright=2,cont=1)
video=propSet(video,"_FieldBased",0)
video=deep_resize(video,3840,grain=0,qual=2)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=2,str=1.2,refinemotion=true)


The last line of video=something is what counts . So now , if you had:

LoadPlugin(".../LSmashSource.dll")
video = LWLibavVideoSource...
# delete all those added lines
video = version()



The video loaded by LWLibavVideoSource would be "replaced" by version() . Remember, you have to push "ok", and hit the avisynth button again for the changes take effect



I still think it's an issue that Dogway needs to address.

Maybe, but since it works with several other people, it's more likely a configuration/setup issue on your end.

It's a no-op when nothing is resized, that's the same as not including the deep_resize, or deleting the line. You can summarize your problem as when you try to use deep_resize (and 1920 doesn't count, because the filter gets skipped), you get the no preview /no error message/ hanging problem, but only some of the time.

[poisondeathray]

Something has changed dramatically, recently, prefilter=4 used to be for dfttest, but now dfttest is #5.

https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain/SMDegrain.avsi#L46

However, if I remove the prefilter= from the call, it still works, but I now don't know what filter it's using.

Is this line even still relevant ??

video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,thSCD1=400,thSCD2=130,contrasharp=true,prefilter=4,str=1.2,refinemotion=true)

If you omit the prefilter call, the default is "-1", which is "off"

BTW, you can enable the settings debug display by toggling show=true (probably nicer to use a script editor, it's kind of "clunky" to do in ripbot)

[Reel.Deel]

Something has changed dramatically, recently, prefilter=4 used to be for dfttest, but now dfttest is #5.

https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain/SMDegrain.avsi#L46

However, if I remove the prefilter= from the call, it still works, but I now don't know what filter it's using.

Read the docs: https://htmlpreview.github.io/?https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain/SMDegrain.html

The "prefilter" parameter description section (https://htmlpreview.github.io/?https://github.com/Dogway/Avisynth-Scripts/blob/master/SMDegrain/SMDegrain.html#prefilter) still lists dfttest as #4 but the dependecies section is correct: DFTTest (v1.9.7 or higher) (for prefilter=5)
KNLMeansCL (v1.1.1e or higher) (for prefilter=6)
DGDecNV (v246 or higher) (for prefilter=7)
BM3D (test9 or higher) (for prefilter=8)

And according to the changelog: v3.5.8d (16-01-2023)
Add IQMV as prefilter=3 and tune ex_FluxSmoothST (prefilter=4)

---

BTW Dogway, IDK if you're still on Win7 but BM3D test10 no longer works with Win7 due to it using the Cuda 12 SDK.
Edit: I reported the issue and WolframRhodium compiled a version with the older sdk, test10-cuda118 works in Win7 :).

---

Yesterday
Do not let that "date" fool you, EVERYTHING is as up to date as Dogway's releases !!!


Today

I'll have to update most of my scripts, since the changes in SMDegrain, since 3.5.7d (currently using 3.5.9d), which may have been part of the problem.

:rolleyes:

[poisondeathray]

So unless proven otherwise, this is what works for me :-

Seems to work with prefilter -1 thru 3 & 5 (didn't test any higher)

video=ConvertBits(video,16)
video=Tweak(video,hue=0,sat=0.8,bright=2,cont=1)
video=nnedi3wrap(video)
video=deep_resize(video,3840,grain=0,qual=2)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,thSCD1=400,thSCD2=130,contrasharp=40,prefilter=3,str=1.2,refinemotion=true)

Seems to work with prefilter -1 thru 3 & 5 (didn't test any higher)

video=ConvertBits(video,16)
video=Tweak(video,hue=0,sat=0.8,bright=2,cont=1)
video=deep_resize(video,1920,grain=0,qual=2)
video=SMDegrain(video,tr=2,thSAD=200,thSADC=100,thSCD1=400,thSCD2=130,contrasharp=40,prefilter=3,str=1.2,refinemotion=true)

Hopefully this is the end of this saga.

I'll have to update most of my scripts, since the changes in SMDegrain, since 3.5.7d (currently using 3.5.9d), which may have been part of the problem.


deep_resize isn't actually used in those examples (no-op), because it's upscaled before to 3840 by nnedi3wrap(video) in the 1st example, or stays at the current 1920 resolution for the 2nd example. So they provide no addition information about your original deep_resize problem

[poisondeathray]

Well, that's interesting to know, but how does it know to upscale to 3840 ??

video=nnedi3wrap(video) , would take the input width *2 , input height*2 , because the default setting is 2.

eg. If source video was 640x480, output from that line would be 1280x960

[poisondeathray]

https://github.com/Dogway/Avisynth-Scripts/blob/master/ResizersPack.avsi#L317

There must be some "tweak's" to that...I don't understand all the hieroglyphics.

nnedi3resize (and related derivatives) scales by powers of 2 by default. It accepts xfactor and yfactor scaling parameters, but only valid values are powers of 2 ; so 2,4,8... If you enter a non power of 2, like 3, it will go down to 2. fwidth and fheight are for secondary scaling, so after the power scaling step, you can downscale to the final width and height (for cases where you need a specific non power of 2 scaling)


So I could drop the deep_resize line, then ??

deep_resize is not being used in those 2 examples

You can obviously do whatever you want, I thought you wanted to get the deep_resize function working

I'm just curious about the "hanging" without error message . It's not common for that to happen, and it's unexpected with that script .

[Reel.Deel]

Do you know what this is ??

https://forum.doom9.org/showthread.php?p=1982132#post1982132

It's now prefilter #3. (or part of it)

Prefilter 3 is ex_Median(mode="IQMV") in line 2355 of ExTools (https://github.com/Dogway/Avisynth-Scripts/blob/master/ExTools.avsi#L2355) it describes it as "Switches between IQM and IQM5 depending on a difference threshold for better edge protection. *Similar to ex_MinBlur(3) in output but near 3 times faster."

[Dogway]

First post on page 100 !!!!
Thanks! You made it possible! lol
Man I wouldn't mind all the posts involving your issue go to a single thread, since you seem to go in rounds without actually following my (and others) debug suggestions.
Well, I need to wait and see what Dogway is going to suggest...
I suggest this post (https://forum.doom9.org/showthread.php?p=1982099#post1982099). And yes, use FFMS2 always.
What is IQMV ??
It's a replacement of ex_MinBlur(3), output is very similar and speed 3 times faster, on par with ex_MinBlur(2). It's only spatial denoising so you might want to check if it's worth for you for its speed versus temporal variants. I might see an use in noisy Anime maybe, but KNLMeans also fits that role.

BTW Dogway, IDK if you're still on Win7 but BM3D test10 no longer works with Win7 due to it using the Cuda 12 SDK.
Edit: I reported the issue and WolframRhodium compiled a version with the older sdk, test10-cuda118 works in Win7
Ahh well, thanks for the info! Yes, AVS dev has me from focusing on OS change. That requires all my focus to clean the disaster of Win10 and want to leave all scripts in perfect condition before that.
I'm gonna finish SMDegrain docs as soon as possible too, it's up on my todo list.

[kedautinh12]

And @TDS help post reach 100 pages very much :D

[LeXXuz]

It's a replacement of ex_MinBlur(3), output is very similar and speed 3 times faster, on par with ex_MinBlur(2). It's only spatial denoising so you might want to check if it's worth for you for its speed versus temporal variants. I might see an use in noisy Anime maybe, but KNLMeans also fits that role.


Btw is there an overview of what prefilter may suit what source/noise type best if not better than others?

[Reel.Deel]

Hi guy's,

A pretty simple question...

Does it matter what order the call's are in a script ??

eg:-

.....

I do recall shuffling around some of the lines in one script a bit, made the difference of it not working, & working, so it must matter to some degree !!

For loading plugins/scripts what matters is that LoadPlugin/Import are above the call that uses the plugin(s)/filter(s). For example:

Import("somefunction.avsi") # this works
video = somefunction()

video = somefunction()
Import("somefunction.avsi") # this does not

By the way, you're question is not as simple as you may think. There are times when the order of the processing does matter and sometimes it does not. It all depends on what you're doing.

[simple_simon]

I figured out that my "Invalid Program" error was caused by my gpu not supporting opencl so I had to change gpuid=-1 and that fixed it.

But now I'm getting this error with some videos:

ConvertYV24ToRGB: Unknown matrix

Any idea what might be causing this one? deep_resize is the only filter being used in the script.

[simple_simon]

Can you post the script ?

Maybe some of your video's aren't the correct "structure" to start with.

http://avisynth.nl/index.php/Convert

https://mediaarea.net/en/MediaInfo

Like I said, deep_resize is the only filter being used.

LoadPlugin("F:\USER\My Applications\Video Tools\MeGUI x64\tools\lsmash\LSMASHSource.dll")
LSMASHVideoSource("F:\USER\Desktop\Great.mov")
propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

Mediainfo says the video is YUV 4:2:0 8bits

[Boulder]

It's probably the source filter playing tricks on you. I think you can force it to output the correct format with specific parameters.

[simple_simon]

It's probably the source filter playing tricks on you. I think you can force it to output the correct format with specific parameters.

What format is required? What format do I force the output to?

[Boulder]

What format is required? What format do I force the output to?

Hmm.. maybe format="YUV420P8" would be correct if MediaInfo is outputting the correct information.

[anton_foy]

@Dogway, any suggestions how to modify soothe or make a similar filter to temporally stabilize after purely spatial denoising? Getting rid of the "nervous" or "jittery" artifacts.

[LeXXuz]

@Dogway, any suggestions how to modify soothe or make a similar filter to temporally stabilize after purely spatial denoising? Getting rid of the "nervous" or "jittery" artifacts.

I second that.

Also how to cope with wobbling backgrounds after degraining with SMDegrain. It usually shows up on older movies with flickering luma.
The problem is the denoised movie with the wobble looks worse than the original with noise and flickering.
I'm almost at the point of giving up denoising these films. As I can't find any setting that reduces this succesfully. Maybe degrain is the wrong denoiser for these.

A special prefilter which stabilizes luminance flicker may be helpful, idk. LFR and DCTFlicker don't help me here.

[anton_foy]

I second that.

Also how to cope with wobbling backgrounds after degraining with SMDegrain. It usually shows up on older movies with flickering luma.
The problem is the denoised movie with the wobble looks worse than the original with noise and flickering.
I'm almost at the point of giving up denoising these films. As I can't find any setting that reduces this succesfully. Maybe degrain is the wrong denoiser for these.

A special prefilter which stabilizes luminance flicker may be helpful, idk. LFR and DCTFlicker don't help me here.

Have you tried to use ex_reduceflicker in the prefiltering phase?

[Dogway]

Btw is there an overview of what prefilter may suit what source/noise type best if not better than others?
Generally I divide them between median like or gaussian blur like .
For example for 2D cel animation:
median / surface blur → bilateral → NLMeans
Then you have blurs with block matching:
MVTools → BM3D
And finally FFT based , which leave an ugly aftermark IMO unless your source is really blocky :
FFT3D → DFTTest

Finally you have mixes of them like Minblur , Fluxsmooth , IQM ...

IMO block matching is the superior for video but for anime median like filters seem move appropiate. The spatial - only prefilter variants are there solely for performance reasons .
But now I'm getting this error with some videos:

ConvertYV24ToRGB: Unknown matrix
Any idea what might be causing this one? deep_resize is the only filter being used in the script.
Probably my filter is trying to retrieve source matrix information from a clip untagged by the source loader. I'm without computer today, so will have a look during the weekend. Meanwhile try with FFMS2 loader.
Have you tried to use ex_reduceflicker in the prefiltering phase?
I also was confused at a time with "reduceflicker" plugin. In the above three posts four different kinds of flicker were described; luma flicker, motion flicker, DCTflicker and (de)interlacing flicker.
If the problem is luma flicker you need to stabilize it with ex_autolevels or other solution.

[simple_simon]

Hmm.. maybe format="YUV420P8" would be correct if MediaInfo is outputting the correct information.

Yeah I tried doing that already since that's what mediainfo said it was but it didn't change the error message. This is what I added:

LSMASHVideoSource("F:\USER\Desktop\Great.mov", format="YUV420P8")


Probably my filter is trying to retrieve source matrix information from a clip untagged by the source loader. I'm without computer today, so will have a look during the weekend. Meanwhile try with FFMS2 loader.

I tried FFMS2 which detected the correct colorspace but still getting the same error message.

Just thinkin' out loud here, but I recently had some "indifferent" experience with deep_resize, but wouldn't you need some more dependencies to get this to work ??

Like, I dunno, ResizersPack, and whatever else ??

Yes I have all the required updated dependencies. I've successfully used deep_resize with some other videos files already but there are two that are throwing up this same error. The dimensions for both of the problematic files are below 480p so I think that might have something to do with it but I can't figure out what.

[Boulder]

Yeah I tried doing that already since that's what mediainfo said it was but it didn't change the error message.

Try adding just Info() or propShow() after the source is loaded, see what is actually output.

[simple_simon]

Try adding just Info() or propShow() after the source is loaded, see what is actually output.

Strangely, Info() reports the colorspace as YV12. Adding format="YUV420P8" to LSMASHVideoSource doesn't seem to change it.

[kedautinh12]

YV12 is YUV420 in avs+
http://avisynth.nl/index.php/Planar

[Boulder]

Strangely, Info() reports the colorspace as YV12. Adding format="YUV420P8" to LSMASHVideoSource doesn't seem to change it.

Then it definitely looks like a problem involving deep_resize.

[Dogway]

Yes I have all the required updated dependencies. I've successfully used deep_resize with some other videos files already but there are two that are throwing up this same error. The dimensions for both of the problematic files are below 480p so I think that might have something to do with it but I can't figure out what.

Works fine here, even clearing all frame props for under 480p clips.
spline16resize(320,240)
propClearAll()
deep_resize(960,720,grain=0,qual=2,gpuid=-1)

[LeXXuz]

Generally I divide them between median like or gaussian blur like .
For example for 2D cel animation:
median / surface blur → bilateral → NLMeans
Then you have blurs with block matching:
MVTools → BM3D
And finally FFT based , which leave an ugly aftermark IMO unless your source is really blocky :
FFT3D → DFTTest

Finally you have mixes of them like Minblur , Fluxsmooth , IQM ...

IMO block matching is the superior for video but for anime median like filters seem move appropiate. The spatial - only prefilter variants are there solely for performance reasons .


Thanks Dogway. I agree with block matching being best suitable for most films. After countless tests over the last year I ended up with a combination of BM3D+FluxSmooth for prefiltering which gave me the best results so far. Depending on noise of the source I use both with modified parameters. Their default settings were too strong for my taste.


I also was confused at a time with "reduceflicker" plugin. In the above three posts four different kinds of flicker were described; luma flicker, motion flicker, DCTflicker and (de)interlacing flicker.
If the problem is luma flicker you need to stabilize it with ex_autolevels or other solution.

I've uploaded two samples here, the noisy source with the luma flicker and the cleaned version with the wobble.
Just watch the left and upper side of the archway the actor is walking through and you can't miss it. Looks awful on a big screen TV.
Original:
https://send.cm/d/JxeF
Denoised:
https://send.cm/d/JxeG

Will play around with reduceflicker and autolevels. Would appreciate some input on starting parameters from where to go as I have no experience with both filters. :o

[Dogway]

Interesting clip, interlaced? I think you might treat it as progressive, so set propSet("_FieldBased",0).
For prefilter I noticed issues for FluxSmooth on temporal domain, it causes some ghosting, probably better to go with it's spatial MinBlur which is fantastic as far as spatial prefilter, then BM3D, then MVTools.

Back to the clip I was thinking yesterday to include IQM to SceneStats since the function was added weeks ago to ExTools. This is a more robust metric.
I was playing now with ex_autolevels() but I didn't map the gamma but after that albeit the result is better the overall is not still good enough, median bad, average too dark for first scene, will try next with IQM.
Following that you might need to apply a strong temporal denoiser. Anyway videoFred is a specialist on these kind of sources, I would also ask him too since he has a lot of experience on old rusty films like this.

[LeXXuz]

Thanks Dogway for having a look at this. :thanks:

Interesting clip, interlaced? I think you might treat it as progressive, so set propSet("_FieldBased",0).

Well this old film actually is progressive, but the DVD, like many low budget productions, suffers from many PAL phase shifts from poor AD transfer. So I use Ceppos tools to correct those errors. After that I use propset as you already suggested before.


For prefilter I noticed issues for FluxSmooth on temporal domain, it causes some ghosting, probably better to go with it's spatial MinBlur which is fantastic as far as spatial prefilter, then BM3D, then MVTools.

I only use FluxSmooth in spatial domain, 'cause I noticed that too, and BM3D with a temporal radius of up to 5. Although the differences between r=5 and r=1 are much more subtle when using BM3D as prefilter for Mvtools.

Furthermore I use BM3D first then FluxSmooth because block matching tends to produce some poor artefacts in rare cases on some forms of noise. FluxSmooth filters these a little and smoothes some residual low freq noise from block matching quite nicely.

But I rarely use ex_FluxSmooth with a radius >1 as it smoothes fine detail too much with 2 or even 3. Only if residual noise is still too present and the trade-off is worth it.


Back to the clip I was thinking yesterday to include IQM to SceneStats since the function was added weeks ago to ExTools. This is a more robust metric.
I was playing now with ex_autolevels() but I didn't map the gamma but after that albeit the result is better the overall is not still good enough, median bad, average too dark for first scene, will try next with IQM.

Please let me know about any suitable results. I have quite a lot of these kind of films to give them a test run.


Following that you might need to apply a strong temporal denoiser.

As general noise filter or as a prefilter? Any suggestions which ones to give a try maybe?

[simple_simon]

I noticed that deep_resize is changing the colors slightly. Is that intentional for some reason?

[Boulder]

A rather simple question regarding prefiltering, this is something I've often wondered.

If you remove most or all the noise from the prefilter clip, you are also bound to remove plenty of fine details as well. Is this not a problem when trying to keep the details but remove the noise with MDegrain? I've usually taken a precarious way like using a ex_MinBlur with radius 1 or 2 depending on the source. Running ex_BM3D on the clip definitely removes all the noise but much of the finer details as well. (By the way, I couldn't replicate the issue with DGSource cropping and BM3D so maybe it's fixed now.)

[DTL]

A rather simple question regarding prefiltering, this is something I've often wondered.

If you remove most or all the noise from the prefilter clip, you are also bound to remove plenty of fine details as well. Is this not a problem when trying to keep the details but remove the noise with MDegrain?

Typically noise removed from source to MAnalyse to attempt get more stable motion vectors. The input to MDegrain depends on processing script and may be input source (not prefiltered). The detail smoothing at the output of MDegrain depends on the motion vectors stability and precision (quality). So with prefiltering to MAnalyse you may get more details saved at the output of MDegrain with higher thSAD and more denoising effect.

If you get a sequence of stable photos with noise and provide zeroed motion vectors to MDegrain it will not smooth details at all with any high thSAD (it will work as simple static Average() processing). But with real footage the MDegrain do not know which blocks have zeroed motion vectors at real motion pictures camera shooting with noised blocks so motion vectors search with MAnalyse may provide more and more false non-zeroed motion vectors for real fixed parts of frame and it one of the reason to details lost at the MDegrain output. With prefiltering you remove part of noise from the source to MAnalyse and increase probability to compute more correct motion vector (zero for fixed blocks and correct pointing to moving). But it is not guaranteed because prefiltering also cause details lost for MAnalyse and it also may be the reason of non-correct motion vectors. In current versions of mvtools there is no implementation of multi-pass iterative motion search and degrain and next iteration motion vectors refining and so on. Only some attempts exist with script writers to make 'prefiltering' and some multi stages processing with possible data refining.

[LeXXuz]

A rather simple question regarding prefiltering, this is something I've often wondered.

If you remove most or all the noise from the prefilter clip, you are also bound to remove plenty of fine details as well. Is this not a problem when trying to keep the details but remove the noise with MDegrain? I've usually taken a precarious way like using a ex_MinBlur with radius 1 or 2 depending on the source. Running ex_BM3D on the clip definitely removes all the noise but much of the finer details as well. (By the way, I couldn't replicate the issue with DGSource cropping and BM3D so maybe it's fixed now.)

You're quite right. You can't overdo it with prefiltering. Finding the best balance between noise filtering and detail preservation is key. And it is ALWAYS a compromise. Setting up prefilters correctly is the most important part imho.

That's why I created myself 10 different profiles, ranging from sources with extreme high quality to extreme low quality.

So when denoising a film I pick one of these profiles as a general direction and then still fine-tune it more or less, because every source is different.

[DTL]

I've uploaded two samples here, the noisy source with the luma flicker and the cleaned version with the wobble.
Just watch the left and upper side of the archway the actor is walking through and you can't miss it. Looks awful on a big screen TV.
Original:
https://send.cm/d/JxeF


It is spatial distortion in the source. To fix it some advanced 'area stabilization' processing required to keep real objects motion and to attempt to decrease this 'scale+translate' transform on more or less big ares of the frame. May be initial film frames were distorted so the filmscan already distorted too.

[poisondeathray]

I noticed that deep_resize is changing the colors slightly. Is that intentional for some reason?

In what situation ? What are the details of videos and script ? It does not change the colors here:

eg.

colorbarshd(1920,1080)


vs


colorbarshd(1920,1080)
deep_resize(1280,720, grain=0)

[Dogway]

As general noise filter or as a prefilter? Any suggestions which ones to give a try maybe?

As a general noise with good temporal prefilter (BM3D), because the luma flicker is not homogeneous so the ex_autolevels() is never going to fix it completely.

The update to SceneStats with IQM is finished except for an issue on the accumulator that I have to fix, it's challenging me.

If you remove most or all the noise from the prefilter clip, you are also bound to remove plenty of fine details as well. Is this not a problem when trying to keep the details but remove the noise with MDegrain?

The real case scenario for prefiltering is one where you use masks and smart filtering. The built-in prefilters are only a convenience for not advanced users. In any case the prefiltering is not the real output, it can be a bit more blurry than expected since you only need the structure for the motion vectors. Motion vectors from MVTools itself are neither as fine detailed as you think (blocks of 4x4 for refinemotion like a 480x270 clip for a 1080p source with blksize=8) so if there are finer elements you want to recover you will need to add them back later with custom masks (corner masks, detail masks, luma masks...). I chose to keep SMDegrain "simple", which suits all kind of sources, like an interface or agnostic extension of MVTools.


EDIT: ScenesPack updated, ex_autolevels() in GradePack also updated.

[simple_simon]

In what situation ? What are the details of videos and script ? It does not change the colors here:

eg.

colorbarshd(1920,1080)


vs


colorbarshd(1920,1080)
deep_resize(1280,720, grain=0)


Here's my sample.

https://send.cm/d/K1aD

Compare

spline36resize(960,720)

to

propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

[simple_simon]

Works fine here, even clearing all frame props for under 480p clips.
spline16resize(320,240)
propClearAll()
deep_resize(960,720,grain=0,qual=2,gpuid=-1)

Here's one of the clips giving me the "ConvertYV24ToRGB: Unknown Matrix" error

https://send.cm/d/K1b5

propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

[poisondeathray]

Here's my sample.

https://send.cm/d/K1aD

Compare

spline36resize(960,720)

to

propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

I don't see any color change, or it's negligible.

Also, you're upscaling "SD" to "HD", the usual convention is to apply colormatrix or similar transform from 601 to 709 , and flag the encode properly

"HD" material by default uses 709 , "SD" by default 601 (some rare exceptions) . Some players will use 709 to convert to RGB for display for HD (height > 576), so video colors will look shifted if it uses the wrong matrix



Here's one of the clips giving me the "ConvertYV24ToRGB: Unknown Matrix" error

https://send.cm/d/K1b5

propSet("_FieldBased",0).deep_resize(960,720,grain=0,qual=2,gpuid=-1)

Works for me, no error messages with either LWLibavVideoSource, or FFVideoSource

Check your dependencies


Color primaries : Display P3
Transfer characteristics : BT.709
Matrix coefficients : BT.709


The primaries are atypical

Maybe try setting the matrix property

propSet("_Matrix",1) #709

[simple_simon]

I don't see any color change, or it's negligible.

Also, you're upscaling "SD" to "HD", the usual convention is to apply colormatrix or similar transform from 601 to 709 , and flag the encode properly

Strange that you aren't seeing the color change. But I did wonder if deep_resize was converting the colorspace to HD also but I couldn't find anywhere where that was stated. So that's good to know so I can apply the encoding settings correctly in x264.

Here's screenshots of what I'm seeing.

Spline36Resize
https://send.cm/oo8tlpqk5ey7

deep_resize
https://send.cm/4izbhjbte3rw

Works for me, no error messages with either LWLibavVideoSource, or FFVideoSource

Check your dependencies



The primaries are atypical

Maybe try setting the matrix property

propSet("_Matrix",1) #709

Well I'm stumped on this one. I doublechecked all dependencies and their dependencies and everthing is up to date as far as I can see.

I tried adding propSet("_Matrix",1) before deep_resize like you suggested and still get the error.

[poisondeathray]

Here's screenshots of what I'm seeing.


Screenshots definitely show a 709 vs. 601 mismatch. But I cannot reproduce it with deep_resize and that script

How are you taking screenshots ? Is this a preview or encode ? How are you viewing it ? How is the RGB conversion being done ?




Well I'm stumped on this one. I doublechecked all dependencies and their dependencies and everthing is up to date as far as I can see.

I tried adding propSet("_Matrix",1) before deep_resize like you suggested and still get the error.

What is the full error message for "ConvertYV24ToRGB: Unknown Matrix" ? Does it give a line number ?

What avs+ version ?

[simple_simon]

Screenshots definitely show a 709 vs. 601 mismatch. But I cannot reproduce it with deep_resize and that script

How are you taking screenshots ? Is this a preview or encode ? How are you viewing it ? How is the RGB conversion being done ?

Screenshots are window captures of the MeGUI Preview window using Greenshot. I'm not doing any RGB conversion.


What is the full error message for "ConvertYV24ToRGB: Unknown Matrix" ? Does it give a line number ?

What avs+ version ?

Nope, no line number. I gave all the details that were provided. It doesn't even say what filter is throwing the error. Here's a screenshot of the actual error message in MeGUI.

https://send.cm/ifax6um50ces

And using AviSynthPlus-3.7.3_r3877, which is the very latest revision that I'm aware of.

[poisondeathray]

Screenshots are window captures of the MeGUI Preview window using Greenshot. I'm not doing any RGB conversion.


MeGUI is doing the RGB conversion for the preview

If you don't know what it's doing for the preview, you can explicitly control the conversion by addding ConvertToRGB(matrix="rec709"), or ConvertToRGB(matrix="rec601") (just don't forget to remove them when encoding)



Nope, no line number. I gave all the details that were provided. It doesn't even say what filter is throwing the error. Here's a screenshot of the actual error message in MeGUI.

https://send.cm/ifax6um50ces

And using AviSynthPlus-3.7.3_r3877, which is the very latest revision that I'm aware of.

Maybe an issue with that version ? I was using r3835 . But I checked with r3877 - no problems either, I cannot reproduce either of your issues


Did you check the script in another application, such as mpchc, avspmod ? Maybe some specific issue with megui ?

[simple_simon]

MeGUI is doing the RGB conversion for the preview

If you don't know what it's doing for the preview, you can explicitly control the conversion by addding ConvertToRGB(matrix="rec709"), or ConvertToRGB(matrix="rec601") (just don't forget to remove them when encoding)

I checked the script in AvsPmod and didn't see the change in color when applying deep_resize. However AvsPmod has a setting to explicitly select which color matrix to use when previewing so that's probably why. What program did you use to preview?

I did use the Frame Properties tool in AvsPmod and the color primaries/matrix/tranfer are read as undefined until deep_resize is applied. Then they change to Rec.709. So I think what's happening in MeGUI is since the matrix properties are undefined it's just making an assumption based on frame size that the matrix is Rec.601 and using that to preview. But deep_resize explicitly sets the matrix properties to Rec.709 so when I apply that filter MeGUI changes it's preview matrix to match and that's why I'm seeing the difference.

Now I'm wondering, is deep_resize actually converting the color primaries/matrixes/transfers to Rec.709 or is it just flagging it as that in the frame properties. If it's just flagging it wouldn't that lead to improper color display at playback. But also if it's actually converting it, I noticed that it still changes it to Rec.709 if downsizing 480p video. Wouldn't that be incorrect? Shouldn't it stay at Rec.601 in that case?


Maybe an issue with that version ? I was using r3835 . But I checked with r3877 - no problems either, I cannot reproduce either of your issues


Did you check the script in another application, such as mpchc, avspmod ? Maybe some specific issue with megui ?

I also checked this script in AvsPmod. It didn't have any issues running it. No errors. According to the frame properties though, deep_resize is changing the matrix from (1 [709]) to (12 [Chroma ncl]). Like you noted earlier the source video has odd color primaries, (12 [ST 432-1]). Since the code numbers are the same I'm guessing deep_resize is changing the matrix to match the primaries. And I'm assuming MeGui doesn't recognize the nonstandard matrix so throws back the error I've been getting when trying to preview. So how do I convert the color primary for this video? Or force deep_resize to use 709 instead of Chroma ncl?

But it seems both problems were in the MeGui previewer, not deep_resize. Although in the first instance I think MeGui handled the matrix display correctly, make an assumption about matrix based on source frame dimensions until matrix is specified. I prefer that to the way AvsPmod does it.

[poisondeathray]

However AvsPmod has a setting to explicitly select which color matrix to use when previewing so that's probably why. What program did you use to preview?

avspmod, I have it set not to read from source, and resolution based . You can also explictly control the RGB conversion as mentioned earlier. It doesn't matter, as long as you keep in the back of your mind how it's being done


Now I'm wondering, is deep_resize actually converting the color primaries/matrixes/transfers to Rec.709 or is it just flagging it as that in the frame properties.


You can insert a propshow() any point to determine if a filter is changing frame properties. If you set up avspmod correctly, you can view the actual YUV values with the color picker to see if any actual pixel value changes are occurring due to a filter. For colors, you can also test colorbars (and colorbars videos with tags) to easily see what's happening

Avisynth can pass frame properties to some programs -e.g. ffmpeg - so it actually can affect the end result and tagging and other program behaviour. Beware of or learn the new behaviour. Some people like to clear the props before encoding, and/or after loading video - so one option is to clear some or all of the properties after the source filter, or set some or all of them specifically .

Props are good and bad - but in some cases they can screw up the results if you're not careful - if a filter makes assumptions or uses values based on props. Sometimes videos are tagged incorrectly . A common one is "PAL" area distribution e.g. progressive content DVD's or BD's , that are encoded interlaced. Vapoursynth users are used to these "props" problems (props have been there a few years longer) but it has invaded avisynth now. Beware and there will be growing pains

You should notify megui developers about the preview issue

[LeXXuz]

EDIT: ScenesPack updated, ex_autolevels() in GradePack also updated.

Should I give that a try? If so, where to put it best and what settings to start from? I don't expect to get rid of that wobble, but I take anything that helps to reduce it. :)

Also right now I'm trying with much smaller temporal radii which seems to reduce the effect, as expected, but at the cost of losing precision. Maybe a mix of denoising and leaving some residual noise is best here. It still beats that clean but wobbly look.

[DTL]

I don't expect to get rid of that wobble, but I take anything that helps to reduce it. :)


As a starting solution you can try 'blind fix' - cut frame to a sub-clips with a fixed grid like 2x2 or 3x3 or more and apply stabilization to each sub-clip and stack subclips back. But it will produce more or less visible issues at the stacking borders looking like a fixed grid.

Second part of solution may be combining first and second (shifted to half of grid step diagonally) clips with same method as overlapping blocks for denoise - you can use BlockOverlap plugin or Overlay with manually painted mixing mask (or may be masktools can help).

But shifting diagonally 1/2 grid step for very dense grids for small blocks of denoise work good - leaving only 1/2 of blocksize uncovered regions near the very edges of frame. And shifting very large 'blocks' of stabilization with only something like 3x3 cutting grid may still leave large enough unfixed lines at the edges of the frame and may need more edges of frame workarounds.

Next step may be pad original frame with 'stab blocksize/2' borders and so you can provide 2 sets of the stabilized clips to BlockOverlap covering all parts of original frame.

BlockOverlap is https://forum.doom9.org/showthread.php?t=101307 and https://github.com/DTL2020/BlockOverlap/releases/tag/v0.2-x64 x64 build.

[Dogway]

Should I give that a try? If so, where to put it best and what settings to start from? I don't expect to get rid of that wobble, but I take anything that helps to reduce it. :)

Yes, you can play with it, it will reduce the luma flicker. I just updated ScenesPack with a small fix to switch to plain mean metric when samples are too low.

Right now I'm playing with some ideas from Stab() using TemporalSoften to reduce the flicker further.


An example:
ffvideosource("noisy_original.mkv")

propSet("_FieldBased",0)
Stab()
SceneStats("Range+Stats")
pref = ex_autolevels()
temp = Pref.TemporalSoften(5,255,0,25,2) # SC thr to 25 otherwise pans will stutter
rep = temp.Repair(Pref.TemporalSoften(1, 255,0,25,2))

pref=ex_merge(rep, pref,MotionMask(rep,scale=10,sharpness=5))
SMDegrain(6, 1000, mode="TemporalSoften",prefilter=pref,LFR=false,RefineMotion=true)

ex_unsharp(0.3)
gr = 1
size = (720/2133.) * 3.3
GrainFactory3mod(g1str=7*gr,g2str=9*gr,g3str=7*gr,g1size=1.7*size,g2size=1.4*size,g3size=1.4*size,g1cstr=0.5*gr,g2cstr=0.3*gr,g3cstr=0.1*gr,temp_avg=1,tv_range=true)


Result not perfect but hopefully an improvement: link (https://www.mediafire.com/file/s48ohvwd8mnlczt/New_File_%2528328%2529_3.mp4/file)

[LeXXuz]

Thanks DTL and Dogway for your input. Really appreciate it. :thanks:
Something new to fiddle around with the next couple of days. :D

[simple_simon]

avspmod, I have it set not to read from source, and resolution based . You can also explictly control the RGB conversion as mentioned earlier. It doesn't matter, as long as you keep in the back of your mind how it's being done

I don't really care if the colorspace isn't displayed correctly in the temporary preview. I just want it to be correct in the final playback file.

You can insert a propshow() any point to determine if a filter is changing frame properties. If you set up avspmod correctly, you can view the actual YUV values with the color picker to see if any actual pixel value changes are occurring due to a filter. For colors, you can also test colorbars (and colorbars videos with tags) to easily see what's happening

propshow() is just going to tell me if the frame properties tags have changed. That still doesn't give me an answer about whether deep_resize is actually doing the colorspace conversion to go from SD --> HD colorspace when upsizing. Or just adding HD colorspace frame property tags. Maybe Dogway can chime in and specify what's actually going on behind the scenes.

You should notify megui developers about the preview issue

The developer of megui hasn't been very active for a number of years now, unfortunately. It's still possible to update the various external supporting tools but the actual framework gui pretty much is what it is.

[poisondeathray]

That still doesn't give me an answer about whether deep_resize is actually doing the colorspace conversion to go from SD --> HD colorspace when upsizing.

It's not currently. You get (essentially) the same results as Spline36Resize in terms of YUV values - Those are the actual values that get encoded

[simple_simon]

It's not currently. You get (essentially) the same results as Spline36Resize in terms of YUV values - Those are the actual values that get encoded

Well that really doesn't make sense for deep_resize to be changing the frame properties to 709 colorspace when it isn't. It should either assume the colorspace by the input frame resolution or leave it unspecified. Or require the user to explicitly state the input colorspace so it knows what frame property to output.

So what's the best way to handle this? Should I clear props after deep_resize to not confuse anything further along in the chain? And just encode it as 601? Or since deep_resize is flagging the video as 709 and since most playback software/hardware will assume 709 based on the HD frame resolution, should I already be converting the colorspace & range myself when upscaling to 720p or higher? Adding this before deep_resize:

ColorMatrix(mode="Rec.601->Rec.709",outputfr=true)

Or whatever the equivalent is in fmtconv. It's probably better but I haven't been able to decipher how to use it yet.

[poisondeathray]

Well that really doesn't make sense for deep_resize to be changing the frame properties to 709 colorspace when it isn't. It should either assume the colorspace by the input frame resolution or leave it unspecified. Or require the user to explicitly state the input colorspace so it knows what frame property to output.


Many growing pains in avs-land for props


So what's the best way to handle this? Should I clear props after deep_resize to not confuse anything further along in the chain? And just encode it as 601? Or since deep_resize is flagging the video as 709 and since most playback software/hardware will assume 709 based on the HD frame resolution, should I already be converting the colorspace & range myself when upscaling to 720p or higher? Adding this before deep_resize:

ColorMatrix(mode="Rec.601->Rec.709",outputfr=true)

Or whatever the equivalent is in fmtconv. It's probably better but I haven't been able to decipher how to use it yet.


I definitely would not encode and tag as 601. You have the highest chance of it playing correctly everywhere with the 601=>709 shift when going SD=>HD , and tagged as 709 in the encoder

Personally , I clear and do everything manually , because there are many "growing pains" with avisynth frame props right now. I also clear before the pipe out, because some filters screw up the props right now. I flag in the encoder instead of relying if avisynth will pass props correctly . (Some encoders do not accept, so do). You decide what works "best" for you

Yes, colormatrix, or zimg, or fmtc, or avisynthshader

avsresize would look like


z_convertformat(pixel_type=last.pixeltype, colorspace_op="170m:709:709:l=>709:709:709:l")