Dogway's Filters Packs

[Dogway]

Limiter() is there just for comparison purposes, it simply chops off out of range values. SafeColorLimiter() is the same as Limiter() but with HBD support so I didn't add.
There are still a few small bits that can be improved, like 'tolerance' response, pass arguments in dynamic mode, or finer precision in the min/max values, so I will refine those at a later point.

[StainlessS]

Originally Posted by VoodooFX

What is that Limiter() there?

Are you asking what the Limiter() plugin is, if so then here[its avs builtin]:- http://avisynth.nl/index.php/Limiter

[VoodooFX]

Originally Posted by StainlessS

[its avs builtin]:- http://avisynth.nl/index.php/Limiter

Now I remember using it for something few years ago...
What ColorYUV(levels="pc->tv) does in comparison?

[poisondeathray]

Originally Posted by VoodooFX

Now I remember using it for something few years ago...
What ColorYUV(levels="pc->tv) does in comparison?

ColorYUV(levels="pc->tv") does the same as levels(0,1,255,16,235,false) - it scales the clip 0-255 to 16-235. Notice slope of curve is changed, and "banding" is introduced as some values are duplicated (steps in the waveform)

Limiter just cuts off values, all values <16 become 16. >235 become 235. The slope of curve in values 16-235 is unchanged



soft rolloff is a welcome adjustment option, instead of "harsh" transitions

[Dogway]

Originally Posted by StainlessS

Are you asking what the Limiter() plugin is, if so then here[its avs builtin]:- http://avisynth.nl/index.php/Limiter

Ah so nice, I included a tweaked panel of the debug example in the wiki.
Also updated SoftLimiter() with a straight input remap. The curve fitting wasn't accurate plus I assessed it in 8-bit.

[Boulder]

Testing SoftLimiter(show=true) gives me the error "StackVertical: image widths don't match", lines 2235 and 2239.

[Dogway]

Thanks, what I presumed, incompatibilities with mod sizes. Will have a look

EDIT: Fixed. Test now, I also optimized the code a bit.

[Shinkiro]

SMDgraim broken

I can't figure out what he wants from me.

[Dogway]

Strange, what version of avs+ are you on? propNumElements() works for me outside runtime environments.

[Shinkiro]

Dogway
3.7.1 r4351

SMDegrain v3.3.4d works without errors, other versions have not checked

[Dogway]

You mean r3351? Can you try newer version? I think props for frame index#0 was added recently.
Try test build 27 from its thread.

[Shinkiro]

With the new version it works, thanks!

[tormento]

I was trying to clean up the BD of Brazil (small clip here) from excessive noise and I am really torn between

SMDegrain (tr=6, thSAD=600, refinemotion=true, contrasharp=false, PreFilter=4, plane=4, chroma=true, LFR=true, DCTFlicker=true)

and

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

The first gives more detail behind fog or clouds but it has some dancing noise or textures in the most disturbed areas of the video, mostly visible in clouds or walls.

The second is more stable but loses some details.

The bitrate of both is similar, i.e. 3716 kb/s vs 3623 kb/s (on whole movie).

Some years ago a plugin to calm grain (I can't remember the exact name) was out and I was used to implement it in my scripts.

Can you stabilize in some way more the noise before reapplying with LFR=true, DCTFlicker=true?

Moreover I have some slight color change between the two, such as on the falling pictures on this clip:



Look at the pictures falling on the left.

[Dogway]

I will have a closer look later today or tomorrow with more time since currently I'm porting NIS sharpen but I made some templates for noisy sources, maybe you can try, tweaking the parameters in red.

Mild to strong:
	pre=smdegrain(tr=1,mode="temporalsoften",blksize=32,thSAD=900,LFR=400,prefilter=5,DCTFlicker=true,contrasharp=false,refinemotion=true)
	smdegrain(tr=2,mode="MDegrain",blksize=32,prefilter=pre,thSAD=400,LFR=false,contrasharp=true,refinemotion=true)

Very strong (ie. 300, 21 grams):
	smdegrain(tr=2,mode="temporalsoften",blksize=32,thSAD=900,LFR=300,DCTFlicker=true,contrasharp=false,refinemotion=true)
	smdegrain(tr=1,mode="MDegrain",blksize=32,thSAD=300,LFR=false,contrasharp=true,refinemotion=true)

For calming grain I think the most popular were FluxSmoothT and STPresso. There were Deen, etc but they are older and based on the same concept (thresholded medians). You can try those or some of my implementations like ex_FluxSmoothT() or STTWM(), or ex_FluxSmoothST() if using as prefilter.

[Boulder]

Originally Posted by Dogway

Thanks, what I presumed, incompatibilities with mod sizes. Will have a look

EDIT: Fixed. Test now, I also optimized the code a bit.

I'm still getting the error with RC27. Tried without any cropping (i.e. 1080p) and with 240 pixels cropped off the left and right sides.

[Boulder]

Ex_makediff also seems to be broken, "I don't know what 'fmt' means." is the error, lines 1895 and 1910 in transformspack.avsi.

Tested by loading the 1080p source and with these as the only lines after that:
ConvertBits(16)
ex_makediff(last, SPresso(bias=20, biasc=40, rgmodec=4, limit=0.3, limitc=0.6), aug=true)

There's something strange happening with the SPresso limit, if I use limit=0.29, the output seems to change drastically.

[Dogway]

Thanks, yes stupid typo for 'aug=true'. Should be format=PixelType(RGB) in TransformsPack

As for SoftLimiter() debug panel I tested with decimal resizing (using RatioResize) for a few minutes and I had no issues. What's the exact resolution of the clip so I can check?

I did some tests for SPresso and didn't get such behaviour, the parameter response was smooth so it might be clip dependent. I would need a small sample.

[Boulder]

Originally Posted by Dogway

As for SoftLimiter() debug panel I tested with decimal resizing (using RatioResize) for a few minutes and I had no issues. What's the exact resolution of the clip so I can check?

It's 1920x1080, reproducable if I just load the source with DGSource and then use SoftLimiter(show=true).

I did some tests for SPresso and didn't get such behaviour, the parameter response was smooth so it might be clip dependent. I would need a small sample.

Try with this one. The same one can also be used for the SoftLimiter test.
https://drive.google.com/file/d/1oPb...ew?usp=sharing

You can use this script to see how it looks, if you change the value of limit between 0.29 and 0.3, the difference is quite big compared to 0.3 and 0.31. It doesn't seem to matter if the source is 8 or 16 bits.

DGSource("spresso_testclip.dgi")
limit = 0.3
convertbits(16)
ex_makediff(last, mcdegrainsharp(last, c2=SPresso(bias=20, biasc=40, rgmodec=4, limit=limit, limitc=limit*2), frames=1), aug=50, uv=128)

Function MCDegrainSharp(clip c, clip "c2", int "frames", float "bblur", float "csharp", bool "bsrch",bool "Precise",Int "Limit",Int "LimitC") {
  # From:- http://forum.doom9.org/showthread.php?p=1737045#post1737045
  # Based on MCDegrain By Didee, http://forum.doom9.org/showthread.php?t=161594
  # Also based on DiDee observations in this thread: http://forum.doom9.org/showthread.php?t=161580
  # "Denoise with MDegrainX, do slight sharpening where motionmatch is good, do slight blurring where motionmatch is bad"
  # In areas where MAnalyse cannot find good matches, the blur() will be dominant.
  # In areas where good matches are found, the sharpen()'ed pixels will overweight the blur()'ed pixels
  # when the pixel averaging is performed.
  #
  # Mod by StainlessS to add Precise, 3 Sept 2015.
  # Mod by StainlessS, Default bblur mod for HD. bs (blocksize) mod for HD. Added Limit, LimitC. 17 Feb 2020.
    frames = Default(frames, 2)
#    bblur  = Default(bblur, (c.width>1920) ? 0.75 : (c.width>1280) ? 0.7 : (c.width>960 ) ? 0.65 : 0.6)
    csharp = Default(csharp, 0.6)
    bsrch  = Default(bsrch, true)
    Precise= Default(Precise,False)  # Use MRecalculate
    Limit  = Default(Limit,255)
    LimitC = Default(LimitC,Limit)

    bs     = (c.width>1920) ? 32 : (c.width>1280) ? 24 : (c.width>960 ) ? 16 : 8
    super = bsrch ? c2.MSuper(pel=2, sharp=1) : c.MSuper(pel=2, sharp=1)
    super_rend  = c.sharpen(csharp).MSuper(pel=2, sharp=1,levels=1)   # Only 1 Level required for sharpened Super (not MAnalyse-ing)
    backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=bs, overlap=bs/2)
    forward_vec1  = MAnalyse(super, isb = false, delta = 1, blksize=bs, overlap=bs/2)
    backward_vec1 = (Precise) ? MRecalculate(super, backward_vec1, blksize=bs/2, overlap=bs/4,thSAD=100) : backward_vec1
    forward_vec1  = (Precise) ? MRecalculate(super, forward_vec1 , blksize=bs/2, overlap=bs/4,thSAD=100) : forward_vec1
    #
    (frames<=0) ? c :\
    (frames==1) ? c2.MDegrain1(super_rend, backward_vec1,forward_vec1,thSAD=400,Limit=Limit,LimitC=LimitC) :\
    (frames==2) ? c2.MDegrain2(super_rend, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,Limit=Limit,LimitC=LimitC) \
                : c2.MDegrain3(super_rend, backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=400,Limit=Limit,LimitC=LimitC)
    return(last)
}

[Dogway]

Ok uploaded an update. The debug panel in SoftLimiter() is hopefully fixed. Also fixed the typo for ex_makediff(aug=true).
SharpenersPack is also updated with a new sharpener NVSharpen(), this is Nvidia's NIS sharpener, but I didn't like it too much. And reworked/optimized SSSharpenEX() for good I hope.

Now I will have a look at the SPresso thing and Tormento's clip.
I have a somewhat big change pending in the case masks should use fullscale bitdepth, just waiting for confirmation. In my opinion it shouldn't despite masks being PC range (except when source is also PC range).

[tormento]

Originally Posted by Dogway

SharpenersPack is also updated with a new sharpener

Did you work out some other unsharpener? I have tried many solutions but I don't see lot of improvements on bitrate output side. Always too high.

P.S: Do you plan to introduce the new development MVTools options soon or will you wait for a stable release?