SMDegrain and ContraSharpeningHD

[Nikos]

A remark on the ContraSharpeningHD function that exists in SMDegrain script.


ssDD = avs26 ? SSDD.mt_lutxy(ssD,"x range_half - abs y range_half - abs < x y ?",use_expr=2)
\ : SSDD.mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?") # abs(diff) after limiting may not be bigger than before.

denoised.mt_adddiff(ssDD,U=2,V=2) # Apply the limited difference. (Sharpening is just inverse blurring)


HD ? mt_clamp(last,pmax,pmin,overshoot,overshoot,chroma="copy first") : last

yuy26 ? last.ConvertToYUY2().Interleaved2planar() : last
}


With the blue line we have limited the sharpening against the source (for SD and HD source).

With the red line (if the source is HD) what else is there to limit?

I do not think there are two limiters needed.

In my opinion the second limiter (red line) is wrong. The "mt_clamp" need a "sharpened" clip. The last clip is a "calmed" clip.

I copy from here (https://forum.doom9.org/showthread.php?t=153170) an example from Didee:
"spatial sharpen, temporally limited".

source = whatever
sup = source.MSuper(pel=2,sharp=2)
bv1 = sup.MAnalyse(isb=true, delta=1, [more params to liking], ...)
fv1 = sup.MAnalyse(isb=false,delta=1, [more params to liking], ...)
bc1 = source.MCompensate(sup,bv1,thSAD=500)
fc1 = source.MCompensate(sup,fv1,thSAD=500)
max = mt_logic(bc1,fc1,"max").mt_logic(source,"max")
min = mt_logic(bc1,fc1,"min").mt_logic(source,"min")
sharp1 = source.sharpen(1).mergechroma(last) # chroma sharpen usually is unadvantageous

sharp1.mt_clamp(max,min,0,0,U=2,V=2)

The result of the sharpening process is limited to not exceed the temporal [min, max] span.

I would like the opinion of an experienced user for the above because I may be wrong.
Thanks.

[kgrabs]

Just an idea, but you could instead simply clamp the sharpened clip to be between the filtered and original clips.

Most implementations use spatial limiting (3x3 clamping with repair), some also absolute value limiting (lut with "x 128 - abs y 128 - abs < x y ?"), and then there's the simple pixelwise temporal limiting

The original intent was to limit the sharpening to no more than the original clip, hoping to avoid any kind of sharpening artifact (aside from possibly disrupting the balance of contrast I guess), but absolute value limiting allows for sharpening to occur in the "opposite direction" i.e. brightening when the original was darker or vice versa.

IMO these methods tend to jump through hoops that could be solved by simply doing this:

source = clip
filtered = smdegrain(clip)
sharp = filtered.sharpen(1)

mt_lutxyz(source, filtered, sharp, "z x y min max x y max min")

The theory here being that if it's limited to the range of values between the source and filtered clips, no calculation of the difference is needed, as it could never exceed this range in the first place, and there's no reason for the sharpened difference to go in a different "direction" (brighter/darker) than the input, as it would be inherently undesired behavior

[Nikos]

kgrabs thanks for your answer.
Your method is clear and technically correct.

I think the SMDegrain function needs a correction to sharpening.
There must be two Sharpening functions with limiters.
If someone wants something more, he can use LSFMod separately with their own settings.
I suggest something similar to what's in the MC_Spuds (http://avisynth.nl/index.php/MC_Spuds) function.

1. Sharpening is just inverse blurring (Something that already exists).

FUNCTION ContraSharpening(clip denoised, clip original, int frames, int strength)
{
# contra-sharpening: sharpen the denoised clip, but don't add more to any pixel than what was removed previously.
# script function from Didee from the VERY GRAINY thread
s = denoised.MinBlur_di(1,1) # Damp down remaining spots of the denoised clip.
allD = mt_makediff(original,denoised) # The difference achieved by the denoising.

# The difference of a simple kernel blur. Use a larger radius for stronger strength values
ssD = (strength < 4) ? mt_makediff(s,s.removegrain(11,-1)) \
: mt_makediff(s,s.removegrain(11,-1).removegrain(20,-1))

# Limit the difference to the max of what the denoising removed locally. Use a larger radius for larger strenght values
ssDD = (strength < 4) ? ssD.repair(allD,1) \
: ssD.repair(ssD.repair(allD,1),1)

ssDD = SSDD.mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?") # abs(diff) after limiting may not be bigger than before.

denoised.mt_adddiff(ssDD,U=2,V=2) # Apply the limited difference. (Sharpening is just inverse blurring.)

RETURN (last)
}


2. Sharpening with non linear sharpener from LSF and limited to not exceed the temporal [min, max] span (plus overshoot if we want).
FUNCTION MCSharpening(clip denoised, clip original, int frames, int strength, bool flow, int thsad, int sharpen_strength, float ss_x, float ss_y)
{
# determine our clamping limits based of our original clip and a simple MVcompensate
global idx_pointer = (flow) ? idx_pointer : idx_pointer + 1
comp_bw1 = (flow) ? sv_cb1 : original.MVCompensate(sv_b1,thsad=thsad,idx=idx_pointer)
comp_fw1 = (flow) ? sv_cf1 : original.MVCompensate(sv_f1,thsad=thsad,idx=idx_pointer)
pmax = original.mt_logic(comp_bw1,"max",u=3,v=3).mt_logic(comp_fw1,"max",u=3,v=3)
pmin = original.mt_logic(comp_bw1,"min",u=3,v=3).mt_logic(comp_fw1,"min",u=3,v=3)

# Work on an upsized clip to improe edge detection
ox = denoised.width
oy = denoised.height
xxs=round(ox*ss_x/8)*8
yys=round(oy*ss_y/8)*8
ss_x != 1.0 || ss_y != 1.0 ? denoised.spline36resize(xxs,yys) : denoised

# non linear sharpener with variable strength, from LSF, smode=4
Str=string(float(sharpen_strength)/80.0)
tmp = last.RemoveGrain(11,-1)
sharp = mt_lutxy(last,tmp,"x y == x x x y - abs 16 / 1 2 / ^ 16 * "+Str+" * x y - 2 ^ x y - 2 ^ "+Str+" 100 * 25 / + / * x y - x y - abs / * + ?")

# return clip size to normal
ss_x != 1.0 || ss_y != 1.0 ? sharp.spline36resize(ox,oy) : sharp

# limit the sharpened clip to not exceed the original temporal neighborhood
last.mt_clamp(pmax,pmin,0,0,U=3,V=3)

RETURN (last)
}


There is also your own suggestion for a limiter that is very simple and does not require MVTools.
In a test I did I had good results.
Because I have not tried it extensively, however, I can not suggest it for general use.

[real.finder]

didn't test it yet but what the point of this changes? speed or quality?

[Nikos]

real.finder the ContraSharpeningHD function, is not technically correct.
Because with the blue line we have already limited spatialy the sharpening, the red line (temporal limiter) does not have a reason to exist.
Αnd moreover there is a mistake in the syntax. The temporal limiter (mt_clamp...) needs a sharpened clip.
One correct limiter is enough.

And here comes the question ... why should we have temporal limiter only for HD sources?

For these reasons, I suggest that there be two sharpening functions in SMDegrain, one with spatial limiter and one with temporal limiter for both SD and HD sources, similar to those found in MC_Spuds (http://avisynth.nl/index.php/MC_Spuds) function.

The temporal limiter gives you more room for sharpening, especially if you use overshoot.

Finally, according to the tests I made, the limiter of kgrabs is very good if we want a weak but safe sharpening.

PS.
kgrabs the explanatory way you write reminds me of Didee :)

[real.finder]

ok, I did read the posts without urgency, dogway who added the ContraSharpeningHD said he get the code from unknown person

anyway usually I don't use sharp much and if I did I don't use the one in SMDegrain so it has no priority for now

[Nikos]

real.finder thanks for the response.
And I do not use sharpening with SMDegrain, just by practicing to improve my construction functions I noticed the "wrong" syntax.
I'm trying to improve the ContraSharpeningHD so I have a temporal limiter for SD sources, but I do not know how to change the 575-579 lines:
HD ? eval("""
cb1=original.MCompensate(Super, cb1, planar=planar)
cf1=original.MCompensate(Super, cf1, planar=planar)
pmax = ...
pmin = ... """) : nop()


If you have time, write me what change I have to do.

[real.finder]

since you need it in the SD then it should be

!HD ? eval("""

note the !

[Nikos]

Unfortunately with !HD I get the message:
I do not know what "Super" means.
... SMDegrain.avsi line 579
... SMDegrain.avsi line 545


Further changes are needed that my knowledge does not allow me to do.
I have been frustrated with the error messages I have received for days :(

In any case, I thank you for your help.

Edit:
Eventually I found the culprit on line 312 :devil:
if4 should be !if4.

I am happy now that I have spatial sharpen, temporally limited for SD sources within SMDegrain function :D

[real.finder]

good, share the full script so maybe in next update I will add your changes

[Motenai Yoda]

maybe the temporal repair is mandatory to restore the pixel's rank, that can make sense as reference clips are a motion compensation with previous and next frames
IIRC original ContrasharpeningHD rely on RemovegrainHD to work, maybe this 2.0 mod is just an alternative using faster filters/routines.

[Nikos]

real.finder finally think that such a complex function as SMDegrain does not need another complicated Sharpening function.

The safest choice for the simple user is the old good ContraSharpening function for SD and HD sources:

# Limiting according to denoiser's removal.
# Practically: ... than the denoiser removed from any pixel in a 3x3 neighborhood.
FUNCTION ContraSharpening(clip denoised, clip original, bool "HD", bool "planar"){
HD = default(HD ,false)
planar = default(planar,false)
avs26 = VersionNumber() < 2.60 ? false : true

# Damp down remaining spots of the denoised clip.
# When we have satisfactory denoising, the MinBlur may not be needed.
s = denoised.MinBlur(HD?2:1,1,planar=planar)

# The difference achieved by the denoising.
allD = mt_makediff(original,denoised)

# The difference of a simple kernel blur.
# I changed the 20 to 11
ssD = mt_makediff(s,HD?s.removegrain(11,-1,planar=planar).\
removegrain(20,-1,planar=planar):\
s.removegrain(11,-1,planar=planar))

# Limit the difference to the max of what the denoising removed locally.
# For HD i changed the 12 to 1
ssDD = ssD.repair(HD?ssD.repair(allD,1,planar=planar):allD,1,planar=planar)

# abs(diff) after limiting may not be bigger than before.
# From Didee post: (https://forum.doom9.org/showpost.php?p=1140791&postcount=11)
# Without that line, you might get back some of the crud that already was successfully removed.
ssDD = avs26 ? SSDD.mt_lutxy(ssD,"x range_half - abs y range_half - abs < x y ?",use_expr=2)
\ : SSDD.mt_lutxy(ssD,"x 128 - abs y 128 - abs < x y ?")

# Apply the limited difference. (Sharpening is just inverse blurring)
denoised.mt_adddiff(ssDD,U=2,V=2)
}


Question: What is the significance of avs26=...?
For range_half I will ask another time :p

Because we already use mvtools we can add another sharpening function for SD and HD sources:


# Τemporally limited sharpening by using motion compensation.

# Line 312 --> ifC && if0 ? eval("
FUNCTION ContraSharpeningMC(clip denoised, clip original, bool "HD", bool "planar", int "overshoot"){
HD = default(HD ,false)
planar = default(planar,false)
overshoot = default(overshoot,0)

(HD || !HD) ? eval("""
cb1=original.MCompensate(Super, cb1, planar=planar)
cf1=original.MCompensate(Super, cf1, planar=planar)
pmax = original.mt_logic(cb1, "max").mt_logic(cf1, "max")
pmin = original.mt_logic(cb1, "min").mt_logic(cf1, "min")""") : nop()

# Damp down remaining spots of the denoised clip.
# When we have satisfactory denoise, this line may not be needed.
s = denoised.MinBlur(HD?2:1,1,planar=planar)

# Here are many options for sharpening!!!
# The difference of a simple kernel blur.
ssD = mt_makediff(s,HD?s.removegrain(11,-1,planar=planar).\
removegrain(20,-1,planar=planar):\
s.removegrain(11,-1,planar=planar))
# Apply the difference.
sharp = denoised.mt_adddiff(ssD,U=2,V=2)

# The sharpening process is limited to not exceed the temporal
# [min, max] span (plus overshoot/undershoot if we want).
mt_clamp(sharp,pmax,pmin,0,0,chroma="copy first")
}


Both functions, as they are written have the same weak sharpening.

The ContraSharpeningMC, if configured properly can have a good effect.
But... there is not one setting for all movies :D

Motenai Yoda from this Didee post (https://forum.doom9.org/showpost.php?p=1206891&postcount=93):
"Therefore, first doing spatial limiting, then the temporal one on top of that, won't achieve much benefit."

[Motenai Yoda]

I never wrote about temporal limiting, it clamps to the max and min of the same frame mc'ed
maybe we need to summon mawen1250 ask him why

[real.finder]

Question: What is the significance of avs26=...?
For range_half I will ask another time :p



avs26 mean it will be used in avs 2.6 or avs+ cuz the script keep avs 2.5 support, you should already know that from read the script itself or the link to my post in the videohelp

for range_half, read the masktools changes and wiki

[Nikos]

real.finder by reading the function I understood the meaning of avs26, I just could not believe that today there is a man using avisynth 2.5.

I read the wiki and understood the meaning of range_half.

What is difficult for me is the "scale_inputs" parameter.
For 8bit YV12 clips, in a lutxy expression with which criteria will I write "allf" or "floatf" or ...?
For example, let me modify for avs26 the sharpen2 function from SeaSaw function:

function sharpen2(clip clp, float strength, float power, float zp, float lodmp, float hidmp, int rgmode)
{
power = Int(power)
Assert(power>0,"SeeSaw::Sharpen2: Power must be integer value 1 or more")
STR = string( strength )
PWR = string( 1.0/float(power) )
ZRP = string( ZP )
DMP = string( lodmp )
HDMP = (hidmp==0) ? "1" : "1 x y - abs "+string(hidmp)+" / 4 ^ +"

mt_lutxy( clp, clp.RemoveGrain(rgmode,-1,-1), \
"x y == x x x y - abs "+ZRP+" / "+PWR+" ^ "+ZRP+" * "+STR+" * x y - 2 ^ x y - 2 ^ "+DMP+" + / * x y - x y - abs / * "+HDMP+" / + ?",chroma="copy first")
return( last )
}


I will write scale_inputs = "allf" or "all" or "int" or ... at the end or I need to write scalef where needed.
I read LSFmod but unfortunately I did not understand the logic of "scale"
Is scale_inputs = "none", enough for 8bit YV12 clips?

Sadly, the high bit depth has made our life difficult and I'm an old man :(

[real.finder]

real.finder by reading the function I understood the meaning of avs26, I just could not believe that today there is a man using avisynth 2.5.


I think there are some, anyway, I don't like drop old things support if it possible to keep it, and it's kinda useful in debug(you can see the original expr for example)

I read the wiki and understood the meaning of range_half.

What is difficult for me is the "scale_inputs" parameter.
For 8bit YV12 clips, in a lutxy expression with which criteria will I write "allf" or "floatf" or ...?
For example, let me modify for avs26 the sharpen2 function from SeaSaw function:

function sharpen2(clip clp, float strength, float power, float zp, float lodmp, float hidmp, int rgmode)
{
power = Int(power)
Assert(power>0,"SeeSaw::Sharpen2: Power must be integer value 1 or more")
STR = string( strength )
PWR = string( 1.0/float(power) )
ZRP = string( ZP )
DMP = string( lodmp )
HDMP = (hidmp==0) ? "1" : "1 x y - abs "+string(hidmp)+" / 4 ^ +"

mt_lutxy( clp, clp.RemoveGrain(rgmode,-1,-1), \
"x y == x x x y - abs "+ZRP+" / "+PWR+" ^ "+ZRP+" * "+STR+" * x y - 2 ^ x y - 2 ^ "+DMP+" + / * x y - x y - abs / * "+HDMP+" / + ?",chroma="copy first")
return( last )
}


I will write scale_inputs = "allf" or "all" or "int" or ... at the end or I need to write scalef where needed.
I read LSFmod but unfortunately I did not understand the logic of "scale"
Is scale_inputs = "none", enough for 8bit YV12 clips?

Sadly, the high bit depth has made our life difficult and I'm an old man :(

you can use one of them only, theoretically the expr scale is faster but it's harder to make for Human in many cases (and impossible in few cases as the one in the LSFmod), the scale inputs theoretically not fast as the expr scale but it's easy in almost all cases (pinterf did explained everything here in doom9 and in the wiki page)

the high bit depth may made our life difficult but it give better results
but if you want to made changes but not support HBD then do the changes as you do in old masktools (without any scale things) and if you share the script say that it's not work with HBD, it's simple :)

BTW, how old are you?

[Nikos]

real.finder thanks for the explanations.
I suggest that you make the necessary corrections to SeeSaw on the wiki and add the line:

head = head.mt_merge(tame,tame.mt_edge("prewitt",0,255,0,0,U=1,V=1).mt_expand()removegrain(20,1)


Because according to Didee's old post:

Ah, a forgotten artefact in SeeSaw.

The edgedetection function Prewitt() was implemented by mg262 (aka Clouded) before
it made it's way into MaskTools. Either consider it an exercise of searching abilities
(to go out and find prewitt.dll somewhere ...)

... or more quickly, exchange

# head = head.mt_merge(tame,tame.prewitt(multiplier=1.0).mt_expand().removegrain(20))
with
head = head.mt_merge(tame,tame.mt_edge("prewitt",0,255,0,0,U=1,V=1).mt_expand().removegrain(20,-1))


My age is LVIII years old :p

[Groucho2004]

Sadly, the high bit depth has made our life difficult and I'm an old man :(
My age is LVIII years old :p
Lame excuse. I'm ξ and still able to adapt to (some) new technologies. :p

[Nikos]

Then make the effort to correct SeeSaw, so it's compatible with new technologies :p

[real.finder]

I note that I already have some modified one already from somewhere

so I change the name of it to seesaw2

here are the both https://pastebin.com/RJEweXRv

not much edit, just replaced that line, no more no less

[StainlessS]

I think I did the mod of the 1st script linked by prev post r.finder, did it after this from v2.6 Changelist

Force int call arguments to user script function float params to be explicit floats.


So that v2.58 and v2.6 produced same results.
ie
ssy = default( ssy, ssx )
became
ssy = Float(default( ssy,ssx ))
(Unless it were some other changes that you mean).

EDIT: For v2.58, if called with eg ssy=42 then would (pre mod) inside of function be 42, whereas in v2.6, is forced to 42.0.

EDIT: But I did that mod about 2015, I think.

[Nikos]

SeeSaw2 ( modified for standard definition dvds. by jeremy duncan november 11, 2008 )

Spower = default( Spower, 1.0 ) # exponent for modified sharpener
Szp = default( Szp, 1 ) # zero point - below: overdrive sharpening - above: reduced sharpening


According to Didee:
Szp=1 : drives sharpening strength way beyond sanity.
Useful is 8 ~ 64
I can not find the original link.
Edit: I found it (https://forum.doom9.org/showpost.php?p=970503&postcount=414).

According to Lato (https://forum.doom9.org/showpost.php?p=1211533&postcount=14):

It's not a problem, because Spower=1... So no effect ;)

[Wolfberry]

SeeSaw per default tries to strongly enhance the weak (where some detail might appear out of the blue), and only weakly enhance the strong (where you'll mostly get nothing but oversharpening anyway). However, this behaviour is kicked down the drain when the user sets Spower=1. :p

Of course, if the source contains haloing/ringing already from the start - !even if only minor! - then this needs additional prefiltering. Else, SeeSaw will sharpen the source artifacts without mercy! :D

When Spower>1, you have a non-linear sharpening function (weak detail is enhanced more than the strong one)

When Spower=1, you have a linear sharpening function (source+(source-blur)*strength)

The function becomes ((Diff/Szp)^1)*Szp = Diff, that's why Szp has no effect when Spower=1

[Nikos]

https://213e1e41-a-62cb3a1a-s-sites.googlegroups.com/site/neosistotopos/files/image/Doom9_SeeSaw.png?attachauth=ANoY7cqsogYHHdonmiMra99ad82y9ysK0qBuXPTyo8ss3Leo4S6oqYZ12eypMJ09hCxg3kP4bf6az6pA_EP0oBlE93R8to3psv-5PL8PX6RDVDeu6FlWPXW13Zykcve9KU_saLZ4P9_c6bpQVpJ8uxVbND8oDwBsI5C3Z6xN4tamQtb456g8NL_d4u1CQ3XuQuiXttOoOtRSciNeHb2954ju7yIUc30jA_I205gpMK3jkFtqEb5QHjw%3D&attredirects=0

Wolfberry, to be accurate :p
Sstr=1
red line: linear
blue line: Spower=4, Szp=16, SdampLo=0, SdampHi=0
green line: Spower=4, Szp=16, SdampLo=5, SdampHi=24
brown line: Spower=1, Szp=1, SdampLo=25, SdampHi=52 (jeremy duncan default settings)

I hope I did not make a mistake :rolleyes:

Edit:
Link (https://213e1e41-a-62cb3a1a-s-sites.googlegroups.com/site/neosistotopos/files/image/Doom9_SeeSaw.png?attachauth=ANoY7cqTI3wu-muTBgR7w0dF-gq_D36YTXHt7zEQKAUBHweY3k4am99bp4hC3APudp_lp1No6BxzeOr_6PbofUSCF5qdBzKZLrjdBnlXB5ce7XeB9887TtniHjYRpzo8SR7WToTsIbex1YTUbQxg53VTHeY_n0-qIYOVZTtxahb124VsNEZ_0PM1I6Gqgoh_4U-R22WuPyhEDO1svsQqbr3yg_5F6Z_PFvw8v-0PyXHATkEkYc8Mfng%3D&attredirects=2) for the graph.

[Wolfberry]

Adding damping terms does make it (slightly) behaves more like non-linear

Spower=1, Szp=1, SdampLo=25, SdampHi=52 : ((abs(diff)/1)^1)*1*((diff^2)*(25+(1^2))/(diff^2+25)*(1^2))*((1+((1/52)^4))/(1+((diff/52)^4)))
Note that Szp still has effect in the damping terms

Spower=1, Szp=any number, SdmpLo=SdmpHi=0: pure linear (and wasted power doing unnecessary computation)

EDIT: your graph seems like Smode=4 in LSFmod, in Smode=5 the zero point is always preserved regardless of the damping terms.

[Nikos]

The graph is based on the function that jeremy duncan uses in SeeSaw2 and is the same as Smode=4 of LSFmod.

I think we need to protect SeeSaw and LSF from user failures that do not understand the meaning of the variables.

I prefer Smode=4 because it is simpler to read and according to Didee:
One may note that the "neutral point" (Szp = Sharpening Zero Point) isn't always located exactly at Szp, since it gets shifted alittle by the damping parameters ... I was too lazy to make a long complicated formula to compensate for that ... doesn't matter, since absolute exactness of Szp is not really important.

[Nikos]

Wolfberry i read carefully the RPN functions for Smode=4 and Smode=5 and i concluded that the infix functions are:
Smode = 4:
(x/Szrp)^(1/Spwr) * Szrp * str * x^2/(x^2+SdmpLo) / (1+(x/SdmpHi)^4)

Smode = 5:
(x/Szrp)^(1/Spwr) * Szrp * str * x^2*(Szrp^2+SdmpLo) / ((x^2+SdmpLo)*Szrp^2) * ((1+(Szrp/SdmpHi)^4)) / ((1+((x/SdmpHi)^4)))
Where x is the abs difference and SdmpHi > 0.

https://213e1e41-a-62cb3a1a-s-sites.googlegroups.com/site/neosistotopos/files/image/Doom9_LSF.png?attachauth=ANoY7cpNYQmIaKUo2xrTbY0H5KK5DnkDbIMP7GDPBDqFY9AUZahGuV2z_LfpyN0eRslrDClBRoR9ruBSYx61F686Iop2pPSMysC6vtxz2DELT8oy7LvWYED3B0x3WAXcB5FIFwd_Pr0T2uothBNhCL23P4n3errVc4ScMSVQjAtnxIjEGzoLVdST5YaS4dFlPlsnBs6sFmGdRpgCBqLPeZYQA0RufBSIEuDE3Vo6x4a0k-aiRbavU6o%3D&attredirects=0

Link (https://213e1e41-a-62cb3a1a-s-sites.googlegroups.com/site/neosistotopos/files/image/Doom9_LSF.png?attachauth=ANoY7coxj0L0ZFeJNHaJ1aeuWat1JvUMJBnoRoD7iYVdPgN4lWIwoGTnuN-Pp5LcfCMaFppOWPuRP8bwvrHXvKp2g9eFUZQf9ob-mBM-yCOQgiv4SrXjYqmNJARICBC2PnZzrtFzbzqPUlI3cga9Vlo1DFjFl24UlKIP0QBLlGfzfjwXECoAkLIjHq861qdKhwXPwBQrydb3S70zbMsRpnixH5cjTYXxL48_UmVyENcLLSYnZ4BA-fg%3D&attredirects=0) for the graph (if it does not appear).

str=1
red line: linear
green line: Smode=4, Spower=4, Szrp=16, SdmpLo=5 SdmpHi=24
pink line: Smode=5, Spower=4, Szrp=16, SdmpLo=5, SdmpHi=24
black line: Smode=4 or Smode=5, Spower=4, Szrp=16, SdmpLo=0.01, SdmpHi=255 (SdmpLo and SdmpHi practically disabled)

If i have made some mistake, please write to me to fix it.

[Wolfberry]

Hopefully this doesn't count as necro posting, here's my graph (https://imgur.com/a/vRQn0AP) and some comments.

In Smode=4, SdmpLo and SdmpHi do nothing other than damping (so the zero point is damped as well)

In Smode=5, in order to preserve the zero point, SdmpLo and SdmpHi has different behavior contrary to Smode=4
SdmpLo: do damping when diff<Szrp, do nothing at Szrp, amplifying when diff>Szrp
SdmpHi: do damping when diff>Szrp, do nothing at Szrp, amplifying when diff<Szrp

So SdmpLo and SdmpHi is effectively tearing down against each other in Smode=5, resulting an overall stronger sharpening effect compared to Smode=4.

Also in Smode=5, the use of SdmpLo and SdmpHi will often cause some interval to be amplified compared to SdmpLo=SdmpHi=0 (no damping), which may be wanted, or maybe not.

[Nikos]

Wolfberry thanks for the answer.
I agree with what you write.

I need a little help because my pink line for
Smode=5, str=1, Spower=4, Szrp=16, SdmpLo=5, SdmpHi=24
does not match your own pink line.
Did I misspell the function for Smode = 5?

Smode = 5:
(x/Szrp)^(1/Spwr) * Szrp * str * x^2*(Szrp^2+SdmpLo) / ((x^2+SdmpLo)*Szrp^2) * ((1+(Szrp/SdmpHi)^4)) / ((1+((x/SdmpHi)^4)))