Dogway's Filters Packs

[DTL]

As a workaround it possible to AddBorders before processing and Crop after. I also sometime have completely buggy blocks (arranged in rows, but not complete row) at the last (bottom) rows with 1080 lines frame processing with DX12-ME at GTX1060 and not know where it is come from - simply add 72 samples padding to the bottom and crop after.

Also mvtools Mdegrain not process frame borders not covered with full blocks and simply copy (lines, columns) from source. So to process full active frame area it must be fully covered with blocks. Padding with MSuper not helps.

So may be you use too large block size and frame width/height can not be fully covered. mvtools not add blocks overlapping frame borders (into padded by MSuper area - it is mostly reserved for motion compensation when MV points to the block position outside real frame area and not too out of frame).

[LeXXuz]

As a workaround it possible to AddBorders before processing and Crop after.

It's really an odd issue. Good idea with the extra padding though.

Take this clip for example. This is the uncropped 1080p source (1920x1080):
https://abload.de/thumb/2023-06-191zgcsn.png (https://abload.de/image.php?img=2023-06-191zgcsn.png)

Looks like mvtools doesn't mind the small letterbox borders here.
But it has a problem with the 1920 width here, although it is perfectly divisible by 32,16,8,4,2 of course.
It does not mind that the default 1080p resolution is not divisible by 32 or 16. I process it with the default blocksize of 16 for HD.

Correctly cropping 22 lines of the image at the top and the bottom, resulting in a 1920x1036 resolution, it now DOES mind the source's hight is now additionaly not divisible by 8, showing a red block row at the bottom:
https://abload.de/thumb/2023-06-192dkdci.png (https://abload.de/image.php?img=2023-06-192dkdci.png)

And now it gets really weird. By adding just 2 black lines at the bottom and 2 black rows at the right, creating an unusual resolution of 1922x1038, which now is only divisible by 2, shows only full red (or unprocessed) on the recently added areas while the source picture now seems to be processed correctly:
https://abload.de/thumb/2023-06-1931piga.png (https://abload.de/image.php?img=2023-06-1931piga.png)

And of course after cropping out those extra 2 lines and rows, finally the picture looks as it should have been in the first place:
https://abload.de/thumb/2023-06-1947ke8i.png (https://abload.de/image.php?img=2023-06-1947ke8i.png)

I don't get it. And it's nothing Dogway can do about with SMDegrain if it also happens by using mvtools directly, like you said.
Proofs once more mvtools needs some overhaul. Until then, I have to live with yet another workaround, I guess. Again, thanks for the padding tip DTL.

[DTL]

Also the edge of frame rows and columns of blocks are not completely processed with overlapping (up to blksize/2). For example in versions up to 2.7.45 top row have only horizontal overlap and half vertical (from next row below). In post-2.7.45 in 2x 'diagonal' overlap mode the top blocks row do not have even horizontal overlap at the upper half of block.
To fix it the more padding can be added (so that active frame area will be surrounded with at least 1/2 of blocksize) and all active frame area will be covered with overlapped blocks.

" it's nothing Dogway can do about with SMDegrain"

Required padding can be calculated in scripting from input frame size and block size and added in the library script and cropped after MDegrain. It will make processing somehow slower because of more blocks to process so may be optional function switch.

[LeXXuz]

To fix it the more padding can be added (so that active frame area will be surrounded with at least 1/2 of blocksize) and all active frame area will be covered with overlapped blocks.


Yes, totally forgot about block overlapping. So best way to play it safe would be to first have a resolution divisible by blocksize and then add a padding 'frame' of 1/2 of blocksize around the image?

In which direction does the block overlapping actually occur?
Since I never noticed that problem with the very first line and row of blocks, only the very last ones, I imagined overlapping goes to the right and to the bottom. Which then would mean it'll be enough to pad just 1/2 of blocksize to the right and bottom of the clip.

Or does it go into all four directions (left, top, right, bottom)?

[DTL]

"In which direction does the block overlapping actually occur?"

Second row of blocks is shifted to the right and bottom. Main blocks scan is from left to right and from top to bottom (the MAnalyse have zigzag/meander scan and some new MDegrain in post-2.7.45 too in attempt to reuse near cached data). Though the last (right most) block in shifted row may be skipped (?). Also last row from the bottom may be skipped - need to look in the sources and attempt to understand later.

" best way to play it safe would be to first have a resolution divisible by blocksize and then add a padding 'frame' of 1/2 of blocksize around the image?"

Yes - may be close to this.

"Or does it go into all four directions (left, top, right, bottom)?"

Overlapping _not_ cover (completely) _all_ edges of _covered_by_blocks frame area. So if not all frame area covered by blocks - the 'full' overlap is cover even less.

Overlapping weight function have special cases for 'internal frame blocks' (full overlap processing) and all edges and corners cases (left,top,right,bottom and all 4 corners). So to have all active frame area covered with 'full overlap' it is required to add padding to all 4 frame edges (at least to 1/2 block size if the overlap=blocksize/2 used - max overlap) and to have frame size divisible to block size. Or simply try to add 'big' padding like 2 block size to all edges - it may be also cause covering of active frame area with blocks and with full overlap and all special edge/corners cases will be moved to outside of active frame area zones.

[LeXXuz]

So to have all active frame area covered with 'full overlap' it is required to add padding to all 4 frame edges (at least to 1/2 block size if the overlap=blocksize/2 used - max overlap) and to have frame size divisible to block size.

Okay, sold. I'll just make sure the resolution is divisible by blocksize and add a border of 16 black pixels around the clip to play it extra safe. I don't care about additional processing time. Thx again. :)

[salvo00786]

Hi Guys... A question for you. What is the difference between CAS ans CASm? What is better between these two?

[Dogway]

Hi Guys... A question for you. What is the difference between CAS ans CASm? What is better between these two?

Well the CASm description says it all. An "improvement" over CAS, whether you find an improvement or not you have to test.
CAS as you know is AMD's Contrast Adaptive Sharpening, and Asd-g ported it to a plugin. Then you have CAS+ also inside SharpenersPack, it's my port of CAS to a function, just a tiny bit slower than the plugin.

[salvo00786]

Hi... thanks for you reply, but where I can find the description for CASm? I tried to search for CASm before asking, but I haven't found anything?

[Guest]

Hi... thanks for you reply, but where I can find the description for CASm? I tried to search for CASm before asking, but I haven't found anything?

https://github.com/Dogway/Avisynth-Scripts/blob/master/MIX%20mods/SharpenersPack.avsi#L3064

[salvo00786]

Ok, thanks

[LeXXuz]

Dogway I'm playing around with some parameters in SMDegrain I haven't paid much attention to before.

First, is it advisable to use recursion mode for MDegrain as an additional refinement if quality is of the highest concern? Or better not as some side effects (which I haven't noticed through quick testing yet) may occur? So far the speed penalty was way less than I expected it to be.

Does recursion increase denoising strength and therefore thSAD should be adjusted/lowered? Or does it merely increase precision through the binominal weighting? Or a mixture of both? Again, side effects?

And second, the rfilter setting. Is the cubical filter mode (4) better for any scenario than the default quadratic filter?

[Dogway]

Recursion is for stronger degrain without raising the temporal radius, so it might be a good alternative, specially for busy scenes.

Also it will become center frame weighted (check tent blur in ExTools) so safer than using a higher 'tr'.

As for higher quality I don't know, it depends on source, if it's very grainy it can help I think. thSAD is something different, it's the "noise threshold", like the mask so to speak for MDegrain and it's independent to recursion.

rfilter=3 is what gave me the best qual/perf ratio in Zopti, that is not to say rfilter=4 can't give better results but in such case the performance hit didn't make it worth it, just speculating, I don't remember if it delivered better quality.

[LeXXuz]

:thanks:

I did a b2b comparison between two encodes of a problematic source and had the impression tr6 with r looked better, even a little bit more stable, than tr12. But I wasn't sure and couldn't pinpoint it exactly. It was just the entire scenery that looked better on pans or scenes with lots of motion.

After so many tests you sometimes just start seeing things... :D

[Dogway]

Just updated TransformsPack (https://github.com/Dogway/Avisynth-Scripts/blob/e4a6f2dddc8f585fcdf5c1ff509bf5d76e3a8723/TransformsPack%20-%20Models.avsi#L560) with the conversion functions of YUV and YIQ, to and from RGB and YCbCr as explained in this post (https://forum.doom9.org/showthread.php?p=1989126). Aside from that and some notes and cosmetics a fix in some indexes for color_coef(), basically XYZ and NTSC-J were wrong.

Next I'm going to fix HLG for its two flavors, and implement an state of the art tonemapper.

[LeXXuz]

I'm still fiddling with some settings to upscale SD content to 720p. And deep_resize is still my favourite choice. Is there any tweak to set to put some more punch into textures while hardly touching sharp edges, which causes even stronger halos on poor sources? Well, I could run LSFplus afterwards, but I'd like to use as few steps as possible.

[Dogway]

SD to 720p is not much of an upscale so I don't know what could be the gains, but I started deep_resize() dev using sinc4 and it was quite good for textures, then I noticed some ringing could leak outside the edge mask and decided to default lanczos8 and leave sinc4 only for HD to UHD.
I noted in the script:
'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

I haven't played much with SincLin but it promises similar characteristics as sinc minus the halos, maybe give it a go. Just updated TransformsPack - Main because I didnt update the call args (SincLin is now internal function).
Another crazy idea, is to use static grain to detailed areas, so maybe you can hack FilmGrain+ to be static and pass it through a detail mask. It will work as a cheap way of hallucination.

I want to share a remaster I was doing yesterday which is similar in nature. The source is an horrendous upscale of a dumb deinterlace. So you get aliasing, shimmering and all the stuff.
I didn't know how to proceed, descale, re-deinterlace? didn't seem to work out, so I did a similar job as The Mission (pixelated mess), descale, antialias, QTGMC+ deshimmering, some avisynth-fu and filmgrain to add hallucination.

Source..........................................................................................................................................Remaster
http://i.imgur.com/PRaxJ0Sl.png (https://i.imgur.com/PRaxJ0S.png)............http://i.imgur.com/dLZEN1il.png (https://i.imgur.com/dLZEN1i.png)


DeGaussResizeMT(1024,576,order=1,p=100)
SantiagMod(strh=0,strv=1)

a=last
QTGMCp(TR0=0,TR1=1,TR2=2,Preset="Slower", InputType=1, sharpness=0.0) #deshimmer; some ghosting beware

LR=ex_edge(ex_Luma_Rebuild(5.0, 0.03),"kroon")
MM=MotionMask(LR,lo=10,sharpness=1) # It's better to detect motion from edge masks
ex_merge(ex_LFR(a,LFR=400),MM,luma=true) # Restore LFR only on motion areas (deghost + desmear)

ex_LFR(ex_unsharp(-0.5,Fc=width()/1.5),LFR=700) # Deconv only on LFR areas

a=last
DH=DeHalo_alpha(rx=1.7, ry=1.7, darkstr=1.0, brightstr=1.0, ss=1.5, lowsens=50, highsens=50)

# Flat mask block
FlatMask(1.0,scale=50,invert=true)
ex_boxblur(4)
ex_binarize(200)
ex_expand(3)
ex_inflate()
removegrain(20)

ex_merge(a,DH,last,luma=true) # Dehalo only on edges next to flat areas

deep_resize(1920,grain=0.0)
ex_unsharp(0.3,Fc=width()/1.5,safe=true) # Remove some of the dreamy look
ex_unsharp(1.0,Fc=width()*2.0,safe=true) # Extra fine sharpness
FilmGrainPlus(preset="16mm",sharpness=0.5,skin=0.8,str=1.2,mode="log",hi=0.2)

By the way, I will probably implement the motion mask trick into MotionMask, temporal derivatives are more accurate when computed on edge masks rather than source directly, at least from my tests yesterday.

[LeXXuz]

That is some very nice outcome. :eek: I'll definitely will play around with that. Thanks a lot for sharing the script. :thanks:

[DTL]

I did a b2b comparison between two encodes of a problematic source and had the impression tr6 with r looked better, even a little bit more stable, than tr12.:D

If motion vectors are not correct - increasing tr will cause more blurring. The old idea of MDegrainN was about lowering thSAD for the far frames from current to decrease this effect. So with not very good motion vectors it may be better to set thSAD2 to lower values.

"I started deep_resize() dev using sinc4 and it was quite good for textures"

If sinc (unweighted) is really sharpest - and weighting of sinc cause sharpness loss - may be try to test even more higher amplitude of sin ?
Current sinc is sin(x)/x. With weighted sinc x become higher as x increases. So to make sinc 'more unweighted' we can tweak x-divider in sinc(x). Current sinc(x) is sin(x) x 1/x . The 1/x multiplier can be replaced to higher argument function as x increases. So it will keep sinc(0)=1 to keep current samples values unchanged but will have higher amplitude of near lobes. May be test 1/(0.5x) ? Or 1/(x^0.5) and others.

[Dogway]

If sinc (unweighted) is really sharpest - and weighting of sinc cause sharpness loss - may be try to test even more higher amplitude of sin ?
Current sinc is sin(x)/x. With weighted sinc x become higher as x increases. So to make sinc 'more unweighted' we can tweak x-divider in sinc(x). Current sinc(x) is sin(x) x 1/x . The 1/x multiplier can be replaced to higher argument function as x increases. So it will keep sinc(0)=1 to keep current samples values unchanged but will have higher amplitude of near lobes. May be test 1/(0.5x) ? Or 1/(x^0.5) and others.

Yes, that might work, not sure what filter exposes amplitude though, otherwise I need to model it and feed into fmtc, a bit cumbersome but sinc4 is already bordering the limit, if source is already too sharp it will create pixelation and heavy ringing.

I want to note my above script is a bit rough, but works for me since it's a quick personal remaster I did yesterday, you can go nuts configuring QTGMCp, better dehalo mask, 16-bit pipeline, etc. The trick with SD upscales is to add a bit of de-emphasis, the ex_unsharp deconvolution call in my script.

[LeXXuz]

SD to 720p is not much of an upscale so I don't know what could be the gains,

I think I start to see what you mean. I did an upscale to 1080p for comparison and the overall picture looked a bit better or more balanced if you will.

The resize to 720p was out of a necessity at first. It was for some clips for a 720p display with very poor scaling.

And then I played around and started to realize that the SD content looked a tad better when upscaling. So why not encode my DVD content to 720p or even 1080p now if it benefits the visual impression of the picture.

In this case I don't mind if the final clip gets bigger than the source.

I never considered this because I always thought you can't 'create' new or finer detail through upscaling. What isn't there in the first place, won't be there if you enlarge it. So why even bother?

Yet, it looks a tad better. I even let other people do some blind comparisons and they always chose the upscale with deep_resize. So I guess it can't just be me imagining things.

Which now brings me to an important question. Is it recommended to upscale first and then denoise/clean the picture or clean it first and then do the upscale?

I'm leaning towards the first one, but I'm not quite sure. Obviously there is a speed difference, but that is secondary.

[Dogway]

Rather than 1080p the natural thing to do with upscales is an integer upscale, so 2x, because you don't have to mangle (read blur further) the pixels. So that's the optimal upscale ratio.

You can denoise after upscale but I like before for two reasons, performance, but also because deep_resize upscale will try to sharpen texture and along that noise/grain and that increases SAD. So try both ways, you can always mask out details from the upscaled version.

[DTL]

"Is it recommended to upscale first and then denoise/clean the picture or clean it first and then do the upscale?"

If you can process upscaled (slower) it is better to process upscaled. It will be equal to increasing pel in mvtools over 4. As I see with some synthetic simulation with 'clean' source and AddGrain() and SSIM metric after denoise - going from pel=2 to pel=4 adds SSIM metric significantly. So if you 2x upscale first and process with pel=4 it will be close to processing original with pel=8. Will try to test if 2x upscaling before denoise adds visibly to SSIM metric if process with max currently supported pel=4 of mvtools. But the blocksize may need to be adjusted too (to 2x).

"Yet, it looks a tad better. I even let other people do some blind comparisons and they always chose the upscale with deep_resize. So I guess it can't just be me imagining things."

It may depend on both quality of scaler in display device and MPEG encoder action. If MPEG encoder receive upscaled - it typically uses more bits to output and the resulted bit*(original_pixel)/frame quality measure increases. So the MPEG encoder will keep more textures and other quality things. And display upscaler may be as poor as bilinear or short kernel bicubic so not best for big upscale ratios required for SD sources to FHD and larger screens. With source pre-upscale with some best available scaler you can close to hide any visibility of poor display scaler.

The SD era was really 'long' in current civilization and many good engineers worked in that time to make it close to 'perfect' in 'per_pixel' quality (so for high-end DVD players the DACs of 108 MHz used - not lowest possible 13.5 MHz). In the next move to HD and larger production typically pay much less attention to 'per_pixel' quality so a much poorer display scaler may be used in many consumer display devices. As the visual industry went to digital and HD (HD+) - it really degraded in its engineering potencial already as much as it already forgot to put to standard the restoration display scaler. So any scaler can be used by the manufacturer and give different quality. At the end of analog era with SD the semi-digital design of video systems did not define vertical scaler for line-based frames and the H-scaler expected to be simple sinc of the DAC to display at CRT. So requirements for visual system DAC at first were 'natural' and not put to standard (the standard operates in terms of analog systems like frequency response curve and it must be non-distortive (flat)). And after moving to digital the required standards for scale digital content were completely missed.

[LeXXuz]

Thanks guys for your valued input. :thanks:

[Lan4]

Hello! Help me which kernel to use for deep resize, optimal or with improved textures.
Sources: 1080x1920, about 3500 kb/s, H264
Target: 720x1280, about 800 kb/s, H265

[Dogway]

Default (SSIM2) is fine for downscaling, specially if the display is going to upscale again on TV, tablet, or elsewhere. Downscales don't do edge/flat distinction. If the target display is indeed 720p you might want something softer like spline16 or so.

[Lan4]

If no width or height is specified, is the value applied as the width?

If the kernel is not specified, then the value is taken from the list of default kernels for a specific width?

The point is that phone (portrait) resolutions are reversed, as in my case.

[Dogway]

The kernel is evaluated on horizontal aspect ratios, so if your source is portrait ratio you might want to rotate it 90º, apply a deep_resize() to your target resolution with show=true and check the kernel chosen. Then apply those settings to the original video/image.
TurnLeft()
deep_resize(x,show=true)

If you don't specify a target resolution, for example you say, I wan't half the size: deep_resize(0.5), it will keep the portrait aspect ratio.

[Dogway]

Just released TransformsPack v2.2.0. As promised I ported the state-of-the-art OpenDRT tonescale.

So what's left? Finishing the two HLG flavors and their OOTFs, information/resources are mixed so I will need to do some bit of research.

[LeXXuz]

ex_unsharp(1.0,Fc=width()*2.0,safe=true) # Extra fine sharpness



This line irritates me. Will everything below or above the cutoff frequency heavily sharpened? I always thought everything below, but then I don't quite understand the 'extra fine sharpness' description.

Extra fine sharpness would mean to me to sharpen just the finest details (or highest frequencies), which would imply everything above that high cutoff frequency. It's late and I'm confused :o:D

[Dogway]

Will everything below or above the cutoff frequency heavily sharpened? I always thought everything below, but then I don't quite understand the 'extra fine sharpness' description.

Everything at* the cutoff frequency.

*This is generally how sharpeners work but in my implementation I added a twist by providing 20% of the sharpening from a lower discreet frequency cutoff (for structural support) at no perf cost. Normally you don't want sharpening lower frequencies because they add noticeable thick ringing, but 20% of Fc=width() or even 2*width() is safe and helps details pop up.

In the case of 2*width() you are sharpening at subpixel (and 20% at pixel) level, so kinda "creating" the impression of more details.

[LeXXuz]

Everything at* the cutoff frequency.


Whoops! :o Now it starts to make sense to me. Thanks for the explanation. I guess the name 'cutoff' confused me in that case. Let's blame the language barrier. :D

So just to be sure; if I use ex_unsharp() without any frequency specified, it will sharpen/blur the entire spectrum, right?

[Dogway]

So just to be sure; if I use ex_unsharp() without any frequency specified, it will sharpen/blur the entire spectrum, right?

No, as far as I know you can't do that, you have to sharpen at a certain spectrum. The cutoff term is because you apply a lowpass at that cutoff frequency (everything above will be blurred/ditched), then make a diff + add to the source. You could say, well yes you are sharpening at that cutoff frequency and above, but it's easy to prove that wrong when you sharpen at width()/2.

In the specific case of ex_unsharp() I intentionally included a lower cutoff sharpening with a 20% contribution for structural support. This is, among others, a feature of my unsharp implementation.

[LeXXuz]

In the specific case of ex_unsharp() I intentionally included a lower cutoff sharpening with a 20% contribution for structural support. This is, among others, a feature of my unsharp implementation.

Ah. Now it makes perfect sense and explains the results from my tests which made me really scratch my head before. Shows what I knew about sharpening :rolleyes:
Thanks Dogway. :)

[madey83]

Hi,

So what is the best sharpening method:

Unsharp or LSFplus or maybe contrasharp from SMDegrain?

[Dogway]

So what is the best sharpening method:

Unsharp or LSFplus or maybe contrasharp from SMDegrain?

You also have FineSharp+.

In any case as you can see by my examples I'm lately digging ex_unsharp(), if your source is denoised it can work well, you can also use 'th' to not sharpen subtle changes (left over noise).

LSFplus is also very good as the sharpening is non linear. As explained above what is being sharpened is the roll-off range, in the case of ex_unsharp() a binomial/gaussian roll-off. Either LSFplus or FineSharp+ have settings to model this non-linear roll-off. By default using 'mode="LSF"' is quite good and fast, and won't sharpen noise. The problem is that if you overdo it it can look like oil painting.

I can't tell much more, you have to test depending on source, taste of the moment, etc

[Lan4]

The kernel is evaluated on horizontal aspect ratios, so if your source is portrait ratio you might want to rotate it 90º, apply a deep_resize() to your target resolution with show=true and check the kernel chosen. Then apply those settings to the original video/image.
please clarify how best to proceed.

1. Rotate the video 90 to the left.
2. apply a kernel suitable for the width.
3. Rotate the video back to the right.

Sorry, I did not find a list of automatic selection of kernels by resolution by width. Maybe it's better to always manually choose the kernel that looks best?

[Boulder]

Do you have any recommendations on how to fix the very thin vertical lines in this material? It's not very visible at 100% but when you zoom in, it's easy to see. I'd like to do very light processing so I cannot just blur it all away :)

https://drive.google.com/file/d/1IydxWHsuUf1dnGDnWcAiwzOimSQvB2S4/view?usp=drive_link

[Dogway]

yes, sorry I've been sick. I'm back on Monday

[Dogway]

Do you have any recommendations on how to fix the very thin vertical lines in this material? It's not very visible at 100% but when you zoom in, it's easy to see. I'd like to do very light processing so I cannot just blur it all away

mmm, I'm not seeing it. Do you mean the one frame little dust-like white streaks?
please clarify how best to proceed.

1. Rotate the video 90 to the left.
2. apply a kernel suitable for the width.
3. Rotate the video back to the right.

Sorry, I did not find a list of automatic selection of kernels by resolution by width. Maybe it's better to always manually choose the kernel that looks best?

The defaults are the recommended kernels given the width(), so if your source is height dominant simply turn it 90º to check what deep_resize() suggests, then apply that normally to your source:
Source
TurnLeft()
deep_resize(n,show=true)

Note down the kernel(s) used and taps then:
Source
deep_resize(n,edge="recommended1",flat="recommended2")

[Boulder]

mmm, I'm not seeing it. Do you mean the one frame little dust-like white streaks?

This image shows them quite well, like the area around the character's nose. Not exactly macroblocking but something odd I've not noticed before in sources which are not upscales. It was quite apparent in my ex_makediff comparison, where I compare the downscaled-reupscaled clip with the original.

https://i.ibb.co/C0Y0H6n/hot.png

[poisondeathray]

@Boulder - Did you try destripe ?

[Dogway]

Ah yes, it didn't show well on playback in MPC-HC.

You can use (ex_)vinverse() or some blur and post sharpening:
turnleft()
vinverse()
turnright()
EDIT: ex_vinverse() was blurring more due to a missing HBD var scaling (now fixed)
ex_blur(1,0)
ex_unsharp(1,0)

[Boulder]

@Boulder - Did you try destripe ?

Ah yes, it didn't show well on playback in MPC-HC.

You can use (ex_)vinverse() or some blur and post sharpening:
turnleft()
ex_vinverse() # vinverse() has issues on HBD
turnright()
ex_blur(1,0)
ex_unsharp(1,0)

Thanks, ex_vinverse seems to work well with this one. Destripe blurs quite heavily, though it fixes the issue all right :devil:

[LeXXuz]

Well, still learning, reading and trying to better understand my favourite script. ;)

But may I have a crash course on what is the difference between modes "TemporalGauss", "TemporalSmooth" and "TemporalSoften"?

And maybe a brief explanation on when to prefer one of those over the others or even the default "Mdegrain" mode?

I did some testing and see differences but I can't really conclude what mode may be better for what scenario.

[tormento]

Ah yes, it didn't show well on playback in MPC-HC.
Don't trust players for video quality, sometimes they use shortcuts.

Open them in VDub or AVSPMod.

[tormento]

Now that you called them, please suggest me some filter for macroblocking artefact attenuation from bad AVC compression.

There was grain in the original video and the BD author starved the bitrate, so... shit in shit out.

[Dogway]

Now that you called them, please suggest me some filter for macroblocking artefact attenuation from bad AVC compression.

There was grain in the original video and the BD author starved the bitrate, so... shit in shit out.

Maybe CCD() as prefilter for SMDegrain. Then maybe some structure reinforcement with ex_unsharp(Fc=width()/2.0) or the like. Adding back some grain on top might help to bring out missing high freq details.

[tormento]

With a simple

SMDegrain (tr=3, thSAD=300, refinemotion=false, contrasharp=true, PreFilter=7, plane=4, chroma=true)

I get error

Script error: There is no function named 'color_propGet'.
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-4.5.0d~Dogway.avsi, line 1214)
(D:/Programmi/Media/AviSynth+/plugins64/SMDegrain-4.5.0d~Dogway.avsi, line 329)

[kedautinh12]

It's belong to TransformsPack - Main
https://github.com/Dogway/Avisynth-Scripts/blob/013cd48baac92dfd1c343afdf66b5ece38745924/TransformsPack%20-%20Main.avsi#L1636