Dogway's Filters Packs

[tormento]

The range expansion is only for the motion vectors
Oh, wow, thanks. Why didn't you default to 0? Perhaps not everybody wants the video to be "touched" on the dark parts.

Please, give me a hint: some movies, such as Transformers saga, has too much sharpness, giving really low compressibility ratio. FranceBB suggested me to use some vertical only MedianBlur or Blur.

What kind of command would you suggest me from your ex_plugins? And should it be applied before or after denoising?

[Dogway]

I need to see what kind of sharpness. If there isn't any overshoots a simple blur before denoising can do ( ex_boxblur(mode="weighted") with 0.5 or 0.3 value ) passed through an edge mask or even ex_smooth() but -had an idea- needs limiting. If source has overshoots (ringing or halo) you might need to use a FIR filter as once cretindesalpes pointed to me, read here (https://forum.doom9.org/showthread.php?p=1178759#post1178759)for FIR filtering.

[tormento]

I need to see what kind of sharpness
A clip is enough?

And what about str=0 vs str=3 as default?

[Dogway]

Default is Str=3 because most sources benefit from a slight bump in dark areas. Clips that might not benefit as much are generally sports, TV programs which are tuned for a bright surround viewing environment.

Yes, small clip is enough. I will try to bench ex_smooth() against it.

[tormento]

Yes, small clip is enough. I will try to bench ex_smooth() against it.

Here it is (https://send.cm/d/4ybo).

Object countours are insanely sharp, just look at sides of houses, cars and robots.

FranceBB knows the issue and solved it with some blur.

[FranceBB]

FranceBB knows the issue and solved it with some blur.

Yes I do and yes I did.
I work in post production and this generally happens with some rather sharp shots. What happens is that when I get a shot from like a Drone or even a downscaled shot from a 4K camera to FULL HD 50p and I divide it in fields to get 25i I always always always get aliasing. Even if I get 25p materials and I leave them like that and I just flag them as interlaced (so they're progressive) I still have aliasing.
For this very reason I always always always suggest to blur vertically only a bit to avoid aliasing.

blur(0, 1)

Works.

See this: https://forum.doom9.org/showthread.php?p=1875091

[tormento]

@Dogway, is it correct that setting contrasharp=true, it requires RGTools? I was almost sure that you put removegrain into ex_tools.

[tormento]

blur(0, 1)
Plain and simple :)

Let's see what Dogway will pull out of the hat. :p

[Dogway]

Yes, sorry I didn't have time to check it (battle in RGB to HSV conversion!), but I tweaked Savitzky-Golay smoothing filter a few hours ago to remove haloes. I even added clamp to ex_luts but that will be uploaded in the next few days.
function ex_smooth(clip a, int "radius", int "radiusV", bool "sharp", bool "limit", string "mode", int "UV", bool "fulls") {

rgb = isRGB(a)
isy = isy(a)
bi = BitsPerComponent(a)

rd = Default(radius, 1) # from 0 to 3
rv = Default(radiusV, rd) # from 0 to 3
sh = Default(sharp, false) # Sharp version of S-G mode
lm = Default(limit, sh) # Enable limiting for Sharp smoothing
md = Default(mode, "SG")
UV = Default(UV, rgb ? 3 : 1)
fs = Default(fulls, rgb)
rd = max(rd, 0)
rv = max(rv, 0)

rd == 3 || rv == 3 ? Assert (!sh, "S-G Sharp mode only supports radius < 3") : nop()
md == "SNN" ? Assert (rd == rv && rd < 2 && rv < 2, "SNN mode only supports radius < 2") : nop()

if (!sh) {

# Quadratic/Cubic (2nd and 3rd degree polynomials)
strv = rv == 1 ? "x[0,1] x[0,-1] + 4 * x[0,0] 5.666666666 * + x[0,-2] x[0,2] + - 0.085714286 *" : \
rv == 2 ? "x[0,1] x[0,-1] + 2 * x[0,0] 2.333333333 * x[0,-2] x[0,2] + + + x[0,-3] x[0,3] + 0.666666666 * - 0.142857143 *" : \
rv == 3 ? "x[0,3] x[0,-3] + 4.666666666 * x[0,2] x[0,-2] + 13 * x[0,1] x[0,-1] + 18 * x[0,0] 19.666666666 * + + + x[0,-4] x[0,4] + 7 * - 0.012987013 *" : ""

strh = rd == 1 ? "x[-1,0] x[1,0] + 4 * x[0,0] 5.666666666 * + x[2,0] x[-2,0] + - 0.085714286 *" : \
rd == 2 ? "x[-1,0] x[1,0] + 2 * x[0,0] 2.333333333 * x[2,0] x[-2,0] + + + x[3,0] x[-3,0] + 0.666666666 * - 0.142857143 *" : \
rd == 3 ? "x[3,0] x[-3,0] + 4.666666666 * x[2,0] x[-2,0] + 13 * x[1,0] x[-1,0] + 18 * x[0,0] 19.666666666 * + + + x[-4,0] x[4,0] + 7 * - 0.012987013 *" : ""

} else {

# Quartic/Quintic (4th and 5th degree polynomials) (sharper)
strv = rv == 1 ? "x[0,1] x[0,-1] + 15 * x[0,0] 26.2 * x[0,3] x[0,-3] + + + x[0,-2] x[0,2] + 6 * - 0.021645022 *" : \
rv == 2 ? "x[0,2] x[0,-2] + 2 * x[0,1] x[0,-1] + 9 * x[0,0] 11.933333333 * x[0,4] x[0,-4] + + + + x[0,-3] x[0,3] + 3.666666666 * - 0.034965035 *" : ""

strh = rd == 1 ? "x[1,0] x[-1,0] + 15 * x[0,0] 26.2 * x[3,0] x[-3,0] + + + x[-2,0] x[2,0] + 6 * - 0.021645022 *" : \
rd == 2 ? "x[2,0] x[-2,0] + 2 * x[1,0] x[-1,0] + 9 * x[0,0] 11.933333333 * x[4,0] x[-4,0] + + + + x[-3,0] x[3,0] + 3.666666666 * - 0.034965035 *" : ""

}

strv = md == "SNN" ? "x[0,0] X@ x[-1,1] A@ - abs X x[1,-1] H@ - abs + M@
X x[0,1] B@ - abs X x[0,-1] G@ - abs + N@ min
X x[1,1] C@ - abs X x[-1,-1] F@ - abs + O@ min
X x[-1,0] D@ - abs X x[1,0] E@ - abs + min W^
W M == A H + W N == B G + W O == C F + D E + ? ? ? 0.500001 *" : strv

rv == 0 ? a : \
isy ? Expr(a, strv ) : \
UV == 1 ? Expr(a, strv, "" ) : \
Expr(a, strv, ex_UVexpr(strv, UV, bi, rgb, fs), scale_inputs="none")
rd == 0 || md == "SNN" ? last : \
isy ? Expr(last, strh ) : \
UV == 1 ? Expr(last, strh, "" ) : \
Expr(last, strh, ex_UVexpr(strh, UV, bi, rgb, fs), scale_inputs="none")

lm && sh ? ex_clamp(last,a.ex_expand(min(1,rd),"horizontal").ex_expand(min(1,rv),"vertical"),a.ex_inpand(min(1,rd),"horizontal").ex_inpand(min(1,rv),"vertical"),0,0) : last

# ex_luts(last,a,mode="clamp",UV=uv) performance update in the next few days
}

Call like "ex_smooth(1 or 2, sharp=true, limit=true)"
If it's only vertical I guess "ex_smooth(0, 1, sharp=true)" can do.
EDIT: SantiagMod also works very good. But I see there's some ringing in the source.

EDIT2: Some alternatives:
Finedehaloer

SantiagMod(strh=2,strv=2)
a=last
ex_luts(last,last.removegrain(12,0),mode="clamp",UV=1)
ex_lutxy(last,a,"x y - abs 7 > y x y min ?")
# ex_boxblur(0.15,mode="weighted") # optional


FIR:
deconv_h = "0 -5 25 100 25 -5 0 "
mt_convolution (deconv_h, deconv_h, Y=3, U=2, V=2)

@Dogway, is it correct that setting contrasharp=true, it requires RGTools? I was almost sure that you put removegrain into ex_tools.

ExTools do have counterpart filters of RGTools, but is not SO hellish fast (90% there still), so SharpenersPack is in MIX mod. I should probably place it inside the MIX mods folder.

[anton_foy]

Sorry but what is ex_smooth? The purpose? HSV conversion sounds very interesting! Just wondering because of the way I try to make my filters.

[Dogway]

A smoothing filter, between antialiasing and blur. I just added a limiter because it was creating some 2nd order halos.

Yes, HSV conversion is proving to be more complex than I thought. There are better cylindrical models and easier to implement but I want to add HSV to TransformPack for completion and also comparison for the Skin_qualifier()

[anton_foy]

Interesting indeed although I must check into "skin_qualifier", guess that the name says it all? Please shout out if you get to finish the hsv-conversion you mentioned a while ago. I would love to try to base a denoising filter off of that colorspace.

[tormento]

Yes, HSV conversion is proving to be more complex than I thought. There are better cylindrical models and easier to implement but I want to add HSV to TransformPack for completion and also comparison for the Skin_qualifier()
So you suggest me to wait for the definitive version?

[wonkey_monkey]

Moved from the Avisynth+ discussion:

"x 0 > y x / atan A@ x 0 < y 0 >= & A pi + x 0 < y 0 < & A pi - x 0 == y 0 > pi 0.5 * y 0 < pi -0.5 * 0 0 ? ? ? ? ? ?"

I think there's some things wrong with this. If you map it to pixel coordinates (with suitable multiplication and offset) you get this:

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

Note the vertical line.

Separately, the deepest conditional seems to be:

pi -0.5 * 0 0 ?

Which will always equate to zero.

While attempting to find an alternative, I've got as far as


y x / atan

dup pi - x 0 < swap2 ?

dup 2 pi * + x 0 < y 0 > & swap2 ?


though it seems to still work even when x should be 0 (I used sx instead as a pixel coordinate), which makes no sense to me.

I use "swap2 ?" for conditionals because to me it makes far, far more sense to have the condition last.

[Dogway]

Thanks for looking into it. I found the error was at the first conditional, changing it to ">=" fixes the line issue (despite originally being ">" in the wiki).

The first 0 stands for "undefined" when all the ternaries fail, and the last 0 when "x < 0" (first conditional) which seems wrong because following we have "minus than 0" comparisons, so might need to reorder the ternaries.

I implemented the compact version and also works.
ex_lutspa(mode="absolute", expr="x 255 - X@ 0 > y 255 - Y@ X / atan A@ Y 0 > pi 0.5 * X Y / atan B@ - Y 0 < 0 B - pi 0.5 * - X 0 < A pi + X 0 == Y 0 == & 0 0 ? ? ? ? ? pi 180 / * 2048 * 128 +", UV=128)


And another one without conditionals (only for the sign(x) operator):
ex_lutspa(mode="absolute", expr="x 255 - X@ 0 == 0 x dup abs / ? SX^ y 255 - Y@ 0 == 0 y dup abs / ? SY^ SX dup * Y X / atan * 1 X 0 < -1 1 ? - 0.5 * SY dup dup * - 1 + * pi * + pi 180 / * 4096 *", UV=128)
Improved (maybe) and much faster:
ex_lutspa(mode="absolute", expr="x 255 - X^ y 255 - Y^ X dup abs / SX^ Y dup abs / SY^ SX dup * Y X / atan * 1 SX - 0.5 * SY dup dup * - 1 + * pi * + 180 pi / * 128 + ", UV=128)

Please forgive my awkward normalization, I don't know what I'm doing lol

@tormento: yes, wait for the improved "HSV". I already implemented IPT model in other projects, it's miles better than HSV as it is UCS (uniform color space) in the HUE domain. But I need HSV to correlate skin HUE on HSV (33.5º) to IPT.

[tormento]

@tormento: yes, wait for the improved "HSV".
In your opinion, would I lose more details and general quality using some light vertical blur or increasing from tr=3, thsad=300 to tr=4, thsad=400?

[Dogway]

I didn't spot any staircasing so vertical blur seems very destructive to me.

[tormento]

I didn't spot any staircasing so vertical blur seems very destructive to me.
Staircasing?

[Dogway]

A type of aliasing.

EDIT: By the way:

Can't you use Taylor series? Usually with 5/6 terms you have very good approximation.

Wow, had no idea of it. At some point I searched for optimizing exponent operator and found nothing. This is a game changer. I tried though to implement to ex_contrast() without success, these days I'm a bit slow (fatigue...)
cont = 5.0
pivot = 0.5

knee = 1. / (1. + exp(cont * pivot))
shldr = 1. / (1. + exp(cont * (pivot - 1.)))
shmkn = shldr - knee
rshmkn = 1. / shmkn

# 'exp' Taylor series
exp = "X@ X 2 ^ 0.500001 * + X 3 ^ 0.166666666 * + X 4 ^ 0.041666666 * + 1 +"
Expr(last, Format("1 1 {cont} {pivot} x ymin - ymax ymin - / - * "+exp+" + / {knee} - {rshmkn} * ymax ymin - * ymin +"), "")

[tormento]

Wow, had no idea of it.
I am really happy to be of help to one of the few who have helped us all!

[tormento]

I tried though to implement to ex_contrast() without success
Look at this (https://en.wikipedia.org/wiki/Bhaskara_I%27s_sine_approximation_formula) and this (https://www.johndcook.com/blog/2021/03/21/simple-trig-approx/) too.

[pinterf]

'exp' is a valid Expr function, and is using SIMD, probably worth using it.
In your replacement code above, luckily power with small integer exponents like 1, 2, 3 and 4 are optimized internally into mul (and dup), but for larger exponent values the result is calculated using a^b = exp(b*ln(a)) which needs much more computing.

[Dogway]

I didn't want to make the snippet more complex than it is so I used "n ^", in real I'm using vars to reuse operations.
I tested with taylor series and gave a great performance improvement over 'exp' but it might not be valid for high steepness, I crafted a graph to see what was happening, I still might be doing something wrong. https://www.desmos.com/calculator/guetsfy9ww
Guess I can join another polynomial but it makes things more complex.

EDIT: just tested and yes, 'exp' is as fast. I had the notion that not when coding ex_bilateral() removing 'exp' gave a huge speed boost.

@tormento: thanks. I think cos, sin and tan are the easiest, I already adapted 'interpolation' mode in ex_blend(), the problem comes when 'x' uses derivatives and other complex functions like atan. If I'm not wrong atan(x) = tan(y) = sin(y) / cos(y)

[tormento]

If I'm not wrong atan(x) = tan(y) = sin(y) / cos(y)
Nope, the arctan function is the inverse of the tangent function: it returns the angle whose tangent is a given number.

There is a Taylor series (https://math.stackexchange.com/questions/128514/solving-the-arctan-of-an-angle-radians-by-hand) & here (https://proofwiki.org/wiki/Power_Series_Expansion_for_Real_Arctangent_Function) for it too. Look here (https://math.stackexchange.com/questions/982838/asymptotic-approximation-of-the-arctangent) also.

Explicit algorithm (https://stackoverflow.com/questions/42537957/fast-accurate-atan-arctan-approximation-algorithm) is present too.

[Dogway]

Thanks tormento, I managed to build a piecewise function for atan(x) since the Taylor series didn't converge between 0.8 and 1.65 so I built a polynomial in that section. https://www.desmos.com/calculator/bb392gsvnu
I tested on avisynth and works fine, now I will try to optimize it and benchmark, and see if I can reduce it on a case by case basis.

Here's the code and bench (400% speed increase):
Expr(last,Format(" x 255 / atan 255 *"),"") # 90


e8 = "X dup dup * X2@ X * X3@ 0.333333 * - X2 X3 * X5@ 0.200001 * + X5 X2 * X7@ 0.142857143 * - X7 X2 * 0.111111111 * + X7 X3 * 0.0909090909 * -" # up to 0.8
e16 = " X2 -0.245982 * X 1.00976 * + 0.021622 +" # up to 1.65
els = "pi 0.5 * 1 X / - 1 X3 3 * / + 1 X5 5 * / - 1 X7 7 * / - " # from 1.65 onwards
atan = "X@ 0.8 <= "+e8+" X 1.65 >= "+els+" "+e16+" ? ?"
# atan = "X@ 0.8 <= "+e8+" "+e16+" ?" # for atan([0-1])

Expr(last,Format("x range_max / "+atan+" range_max *"),"") # 413

[tormento]

Thanks tormento, I managed to build a piecewise function for atan(x) since the Taylor series didn't converge between 0.8 and 1.65
You are the most welcome. AFAIK you used a McLaurin (x=0) and not a Taylor series (where x is an arbitrary point), that's why it doesn't fit for |x| larger than 0.

[Dogway]

Yes I know, I'm currently working on cos(x) where x is pi/2 since some functions need cosines as high as pi.

Here's the Taylor series of cos(x) when x=pi/2, converges between 0 and pi.
cosTP = " pi 0.500001 * - X@ 0.00000367321 swap - X dup * X2@ 0.0000018366 * + X2 X * X3@ 0.166666666 * + X2 dup * 0.00000015305 * - X2 X3 * 0.008333333 * -"
Expr(last,Format("x range_max / pi * "+cosTP+" range_max *"),"") # 390
#Expr(last,Format("x range_max / pi * cos range_max *"),"") # 70

[wonkey_monkey]

If pi/2 < x < pi, can't you just subtract x from pi and then take the negative of the result?

Or have I misunderstood... you say you're working on cos(x) when x = pi/2, but that's just zero every time...

Possible helpful reading: http://gruntthepeon.free.fr/ssemath/sse_mathfun.h

[Dogway]

It's not cosine of pi/2 but a cosine function approximation around pi/2, so when cos(pi) it gives more accurate results than if I design the Taylor series around x=0.
Here (https://www.desmos.com/calculator/kaolz1jyav) is the desmos graph (check around x=pi )

[wonkey_monkey]

I see, so as per my previous comment: you could design your calculation around 0 < x' < pi/2, reducing x to this range appropriately first. It might be faster for the same accuracy (or more accurate for the same speed).

The purple one needs 5 powers of x, the green one only needs 3. You would basically be taking the first part of the green line (up to pi/2) and rotating it around its endpoint to extend it to pi.

https://www.desmos.com/calculator/bktakxsm7u

Edit: there is a slight discontinuity at pi/2 but you can remove that my nudging the coefficients.

[Dogway]

Yes, makes total sense, inverting the function and make it piecewise. I will bench speed and quality in case the discontinuity is visible.

[tormento]

Here's the Taylor series of cos(x) when x=pi/2, converges between 0 and pi.
Please share the desmos, it was really interesting.

[wonkey_monkey]

Using 0.0013934 (this is just a rough approximation, not a calculated value) as the x^6 coefficient should all but remove the discontinuity. The maximum error is about 0.0000924. Adding an x^8 term can make the max error almost 100x smaller.

I'll try and work on best coefficients tomorrow, if I have time.

[Dogway]

I tested and speed is 2% faster, it was already pretty fast, from 420 to 430fps. Quality wise I think it's better because it doesn't touch range extremes which are always sensible and the discontinuity is not appreciable. But if you can find a better coefficient that would be great.

There's another approximation noted by tormento, the Bhaskara I approx. but it's not as good as the six degree polynomial.
(pi^2 - 4x^2) / (pi^2 + x^2)

BTW, if I compute the Taylor series for x=pi/4 it might fix the discontinuity -> graph (https://www.desmos.com/calculator/gdug4dk5wh)
EDIT: yep, coefficient 0.001329 is almost a match, much better.


tormento: check wonkey_monkey's link (https://forum.doom9.org/showthread.php?p=1953271#post1953271) above. He includes all the three approximations, the one from my post is the purple.

[guest]

Hi Dogway (and the rest),

I asked a question back here :-

https://forum.doom9.org/showthread.php?p=1953024#post1953024

That didn't get answered.
Do any of you ppl that are constantly improving & testing these filters & scripts, actually do any encoding with them ??

Like I mean a full length, 4K movie with your filters, just to see how they REALLY perform !!!

If you're only "benching" them, that's probably NO indication on how they will work in an encoding job.

[kedautinh12]

Hi Dogway (and the rest),

I asked a question back here :-

https://forum.doom9.org/showthread.php?p=1953024#post1953024

That didn't get answered.


If you're only "benching" them, that's probably NO indication on how they will work in an encoding job.

He was answered you
https://forum.doom9.org/showthread.php?p=1953031#post1953031

[guest]

He was answered you
https://forum.doom9.org/showthread.php?p=1953031#post1953031

Hi,

I don't consider that as an answer...it's very a confusing comment, and I still can't get the latest builds to work.

And I do remember encoding DVD's at a very slow pace, my fave tool was DVD2SVCD, and I had a very powerful dual Athlon MP2600 system to churn thru it.

[wonkey_monkey]

Best coefficients I've found so far:

Up to x^6:

1 - 0.5x^2 + 0.041574811029363x^4 - 0.001292112506266x^6

Max error: 0.000019976279586 (43x better than truncated Taylor series, 4.6x better than modifying only last term to avoid discontinuity)


Up to x^8:

1 - 0.5x^2 + 0.041666666666667x^4 - 0.001387723061268x^6 + 0.000023661684925x^8

Max error: 0.000000330438621 (72x better than truncated Taylor series, 6x better than modifying only last term to avoid discontinuity)

[Dogway]

Thanks a lot. Will keep the first one for performance reasons.


EDIT: By the way, I managed to also create a Taylor (Maclaurin) series for exp(x), I know 'exp' is accelerated in Expr but it was the main cause of ex_bilateral() drop in performance ('exp' called many times) so I decided to give it a go. Well it works very well for as low as a 5th degree polynomial even in PC levels, it increased from 115fps for ex_bilateral(1) to 167fps, so it's faster than vsTBilateral(). In ex_contrast() it isn't worth it as it's only called once, and the range of action is larger (from -8 to +8 in x)

[Dogway]

Access violation, not sure if my fault or a bug in avs+:
a=FlipHorizontal()
#~ ex_blend(a,"interpolation",1,0.7)
cosTS = "X dup * X2@ 0.500001 * 1 swap - X2 dup * X4@ 0.041574811029363 * + X4 X2 * 0.001292112506266 * -" # 0.00129 to fix discontinuity at pi/2
cosT = "X@ pi 0.500001 * <= "+cosTS+" dup pi swap - -1 * ? "

Expr(last,a,"x ymin - ymax ymin - / pi * "+cosT+" 0.250001 * 0.500001 swap - y ymin - ymax ymin - / pi * "+cosT+" 0.250001 * - ymax ymin - *" ,"")

I also tried with "dup pi swap - 1 neg * ? " but the neg operator seems to not be working.


This works though:
cosTS = "X dup * X2@ 0.500001 * 1 swap - X2 dup * X4@ 0.041574811029363 * + X4 X2 * 0.001292112506266 * - dup"
cosT = "X@ pi 0.500001 * <= "+cosTS+" pi swap - -1 * ? "

Looks like I cannot dup a referenced string(?)

[wonkey_monkey]

Must be expr, I would think.

Out of curiosity, why do you use 0.500001 and 0.250001?

Very strange that just moving dup into the other string fixes it. It's all just strings that point so I don't see how expr can be to blame.

[Dogway]

Never mind, might have just tested further. "0 max" fixed it. Anyway, the string behaviour was very strange nonetheless. I might replace it with 'cos' now that is in SIMD, was just benchmarking.

About the decimals, I saw it in a vs script, so I asked here (https://forum.doom9.org/showthread.php?p=1950751#post1950751). I tested against Merge(a,b,0.5) and it happened to match Expr(a,b,"x y + 0.500001 * ")

[wonkey_monkey]

Could be down to different rounding modes or just how precision is lost in different ways with different operation orders. I don't think it's a good indication that you should use 0.500001/0.250001 in general.

[pinterf]

You cannot know if Merge is the more correct. Filters are usually using scaled-up fix point integer arithmetic which mimics floating point. e.g. 14 bit precision for intermediate calculations which fit into a 32 bit integer when dealing with 8-10 bit data.

[tormento]

I didn't spot any staircasing so vertical blur seems very destructive to me.
I have tried to reduce the bitrate of the Transformer clip that I sent with a simple Blur(0,1) and I did a couple of trials with Blur before and after SMDegrain(4,400). In both cases I had an increase in size with x264 -crf 20 -preset slow.

How could that be possible? Any idea to increase compressibility of such a sharp clip?

[Dogway]

Ok, I thought about Merge() as the reference. This (https://github.com/Asd-g/AviSynthPlus-Scripts/blob/master/IQA_downsample.avsi)is the vs script I saw it first. Anyway I will revert back all the decimal guided rounding, much easier.

@tormento: That escapes me, maybe x264 is not deterministic. Did you try my suggestions?

By the way, I managed to finish HSV conversion, took me a week! Also probably today I will upload new ExTools version with the latest changes.

[tormento]

Did you try my suggestions?
I am waiting for your latest iteration of tools :)

[wonkey_monkey]

That's possibly an attempt to avoid banker's rounding (round half-values to the nearest even number) which can introduce banding.

Compare the pixel values of the following:

expr("sx 0.5 +") # 0 2 2 4 4 6 6 8 8 10 10 ...

and

expr(sx 0.5001 + ") # 1 2 3 4 5 6 7 8 9 10 11 ...

In most cases banker's rounding is preferable as, on average, it has no bias, but in certain very specific situations it can cause banding. Dithering is one solution.

Your trig functions won't be affected because you're using so many (approximations to) irrational numbers.

[Dogway]

Wow so interesting, I see. Well when the output is dependent of such value I may use it, inside an amount of operations I don't think so because operations are done in float point. I propagated my scripts with such decimals so I need to consider it on a case by case, I guess for the Merge() behavior is a yes (?).

On another note I'm finishing IPT color space and hence Skin_Qualifier(), it's slow because it uses atan2, and I noticed some issues with my atanT() and atan2T() approximations, atan2T() has the potential to be 5 times faster (about 60fps)

[tormento]

@Dogway

I saw you released ExTools 6.0. Can I consider ex_smooth as definitive version to play with? :)