SmoothAdjust [v3.20 - Update 2015/11/15]

[dansrfe]

LaTo,

I have a couple of questions which I hope won't be flagged as completely noob questions.

1) What are the apparent and technical differences between brightness and gamma.
2) What exactly is contrast technically speaking and as changing it would show in video.

I know what most of these "apparently" do but i only know how to use them after a long time of trial-and-error. I would like to know the exact differences between the three in such a way that it would take me less time to decide the what final values I should use and also what will end up looking good. Just some easy to understand yet very exclusive and specific uses and definitions of each.

Also where can I find the correct parameter usages for mt_masktools functions. Something for a relatively new person in using mt_masktools functions directly rather than indirectly through other functions and scripts. I just want to start getting the feel of using mt_masktools functions separately.

Thanks.

[Gavino]

1) What are the apparent and technical differences between brightness and gamma.
2) What exactly is contrast technically speaking and as changing it would show in video.
http://www.poynton.com/notes/brightness_and_contrast/
http://www.poynton.com/GammaFAQ.html
http://www.n9pby.com/psp/psp3%20-%20brightness%20contrast.html
Also where can I find the correct parameter usages for mt_masktools functions.
Have you looked at the mt_masktools documentation?

[Emulgator]

Although I am not the questioned one:

Applying Brightness just adds the value of <brightness> to every Y value of every pixel.
In YUV U,V stay untouched, in RGB the visual differences between colours stay untouched.

Applying Brightness+10 would make a normally perfectly exposed picture look pale and clip the lights.
Brightness +10: 0->10; 10->20; 63->73; 127->137; 191->201; 235->245; 245->255; 255->255

Applying Brightness-10 would make a normally perfectly exposed picture look dark and clip the shades.
Brightness -10: 0->0; 10->0; 63->53; 127->117; 191->181; 235->225; 245->235; 255->245

So Brightness just shifts Y values and can IMHO be only of use
if a shifting of the exact same characteristics shall be compensated.
But this would happen very rarely under normal circumstances.


Contrast applies a slope with ratio=<contrast> onto Y only,
the neutral point being Y=127,
in YUV U and V (in RGB the visual difference between primary colours) stay untouched.
The difference between the Y-value of the actual pixel and the neutral point Y=127 is amplified by <contrast>
Contrast=1.0 is neutral.
Contrast +2.0: 0->0; 32->0; 64->1; 127->127; 191->255; 235->255; 245->255; 255->255
Contrast +0.5: 0->62; 32->80; 64->96; 127->127; 191->159; 235->181; 245->186; 255->191
Applying Contrast is useful only if the resulting curve does not clip the histogram.
This would be the case for an underexposed and pale-shadowed source.
Applying Contrast <1 may clip the lights and swallow the shadows.
An already clipped source can not be mended by applying contrast<1.
The clipping would only be shifted.

Gamma applies a curve with the exponent <gamma> to Y only;
the neutral points being Y=0, Y=255
in YUV U and V (in RGB the visual difference between primary colours) stay untouched.
Gamma=1.0 is neutral and won't change the source. In any case the whites and blacks stay untouched.
Gamma=2.0 brightens the lights, midtones and lifts the shadows, but pure white and black stay untouched.
Gamma=0.5 dims the lights, midtones and darkens the shadows, but pure white and black stay untouched.


To me Gamma is the most valuable tuning, because it won't clip.

Clipping is irreversible and is to be avoided in any case.

It is useful to use Histogram and if appropriate, a tiny Y-shift by brightness before applying Gamma.
Because Gamma can not shift, only multiply.


http://upload.wikimedia.org/wikipedia/de/7/78/Helligkeit_Kontrast_Gamma.png

But the master of it all is applying an arbitrary cubic spline transfer function to Y
using adjustY or even better LaTo's SmoothCurve after applying the necessary shifts by LaTo's SmoothTweak.

Here you can compensate for any transfer characteristic of video cameras or film stock in any decay state..
And the best of it: LaTo's Smooth set dithers and works for U and V too !

P.S. Ah, Gavino was faster.

[dansrfe]

Wow. I'm impressed. All of the explanations are so good! :D Thanks Emulgator and Gavino! So if I understand correctly. Brightness, contrast, and gamma are in a hierarchy of adding, multiplying, and exponential, respectively, to its own scale of the Y plane values. Brightness just shifts the Y values, contrast applies a slope on a ratio used mainly for exposure adjustments. And gamma affects the lights, midtones, and shadows on an exponential scale. Also I have yet another question. I'm not exactly sure what SmoothCurve does or more so how to use it. Does it do level adjustments with options to apply to all three of the YUV planes separately? If I am using all three of LaTo's functions which order should they be used in? SmoothTweak, SmoothCurve, SmoothLevels or would it be sufficient to use just SmoothTweak and SmoothCurve if I plan on making level adjustments as well? The diagram of all the brightness, contrast, and gamma curves is great :)

[Emulgator]

You will easily find out where you land if you just add

#ConvertToYV12(interlaced=true)#Histogram needs YV12 !
histogram(mode="classic")
histogram(mode="levels")

before and after SmoothTweak/Curve/Levels.

Here is a small piece of my recent script to pre-compensate
a dead, overexposed and purple-sick film transfer.
First I had to shift the U and V planes using SmoothTweak,
leaving Y untouched
then I had to use SmoothCurve to
remap Y nicely and spread the U and V planes
to smoothly extend to saturated colours where they once belonged.
SmoothLevels were not needed in this case.

#/*#-------------------------------------------------------------LaTo's Smooth Adjust Set----------------------------------------------------------------
#ConvertToYV12(interlaced=true)#LaTo's Smooth set needs YV12 !
#Smooth means: internal results will be dithered, a smooth histogram will be achieved, banding avoided.
#It won't dither a source that came in banding !
SmoothTweak(Smode=4, strength=100, brightness=0.0, contrast=1.0, saturation=1.0, hue1=+2, hue2=-10, limiter=true)#Bright/Cont/Sat/Hue1(G->B)/Hue2(G->R)-Adjustments
SmoothCurve(Smode=4, strength=100, interp=100, limiter=true, \
Ycurve="0-15;16-16;127-120;200-180;220-195;230-202;240-210;248-218;255-230", \
Ucurve="0-16;100-40;127-127;140-180;255-240", \
Vcurve="0-16;100-80;135-127;140-135;150-160;255-240")
#SmoothCurve(Smode=4, strength=100, interp=100, limiter=true, \
#Ycurve="0-15;16-16;127-120;200-180;220-195;230-202;240-210;248-218;255-230", \
#Ucurve="0-16;100-40;127-127;140-180;255-240", \
#Vcurve="0-16;100-30;135-127;140-140;255-240")
#SmoothLevels(gamma=0.78, Lmode=2, Ecenter=128)#Gamma-Adjustments,Lmode=1: dark and bright stay unaffected,=2: dark stays unaffected, =3: bright stays unaffected
#SmoothLevels(0,1.2,255,32,235,Lmode=1,Ecenter=64,protect=16)
#*/#----------------------------------------------------------End of LaTo's Smooth Adjust Set-----------------------------------------------------------

P.S. While using splines, be aware of the intricacy of spline points.
If you specify these too close and too differing these may force steep curves
with negative slopes which you might not intend...
A print of the resulting transfer function would come in handy.

[LaTo]

P.S. While using splines, be aware of the intricacy of spline points.
If you specify these too close and too differing these may force steep curves
with negative slopes which you might not intend...
A print of the resulting transfer function would come in handy.

A debug view is planned, but these days I am working on another plugin...

So for the moment, you can check using GIMP->Color->Curves panel... With interp=50 in SmoothCurve, the result is very close to the one used in Gimp.

[LaTo]

v1.30:
fixed a bug in spline interpolation
cleaned various stuff

[sonu patel]

i need help i get error can any one tell me ehy i get error ......as i put avs file in fillter pluging

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\gradfun2db.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainHD.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools-26.dll")

this requirment plugin also

SmoothLevels(gamma=1.6,Ecenter=32,Lmode=1)

[LaTo]

i need help i get error can any one tell me ehy i get error ......as i put avs file in fillter pluging

LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\gradfun2db.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\RemoveGrainHD.dll")
LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\mt_masktools-26.dll")

this requirment plugin also

SmoothLevels(gamma=1.6,Ecenter=32,Lmode=1)

You need to load "SmoothAdjust-x86.dll" for 32bits or "SmoothAdjust-x64.dll" for 64bits.

[sonu patel]

You need to load "SmoothAdjust-x86.dll" for 32bits or "SmoothAdjust-x64.dll" for 64bits.

can u have the "SmoothAdjust-x86.dll" for 32bits i canot find plz upload it ....plzz thnks in advance

[LaTo]

v1.40:
added debugview (see show=true)


A screenshot of SmoothCurve(show=true):

http://latoninf.free.fr/d9/SA/SCshow_mini.png (http://latoninf.free.fr/d9/SA/SCshow.png)
*Click the image to enlarge*

:devil:

[royia]

Does it have "Automatic Mode"?
Something with the effect of "Auto Levels" and Tone Mapping / DRC (http://en.wikipedia.org/wiki/Tone_mapping) (Shadows / Highlights in Adobe Photoshop).

Thanks.

[LaTo]

Does it have "Automatic Mode"?
Something with the effect of "Auto Levels" and Tone Mapping / DRC (http://en.wikipedia.org/wiki/Tone_mapping) (Shadows / Highlights in Adobe Photoshop).

Thanks.
No, but something like this is planned.

[royia]

Do you know which Algorithm Adobe uses in Shadows / Highlights?
Might it be a USM Filter with "Shadow / Highlights" masks?

[Wilbert]

Looks like a great plugin! Would you be willing to release it as open source?

[Emulgator]

Beautiful ! Many thanks.
Just as a hint, not as complaint:
I happen to have a frame interpolator inserted post Smooth...based on MVTools2.
If show=true and the resulting screen size is 1920x1200 (SmoothCurve & SmoothTweak)
this interpolator will stall somewhere (almost different line everytime) in its MFlowInter part with
Avisynth open failure: Evaluate: unrecognised exception !
1280x1024 (SmoothLevels) is displayed without hickups.

P.S. Was wondering about the difference and SmoothLevels showing version 1.02.
I still happened to have SmoothLevels 1.02.avsi in my plugins folder.
Now I deactivated the 1.02.avsi by renaming.
The call uses 1.40 now and the MFlowInter stall behaviour is the same now
as for the other two Smoothies.

Will try if screenW and screenH would respond as in LSFmod...no they don't.
So the size might be the culprit and it would be a good addition
to have the display size adjustable with show=true.

[LaTo]

v1.44:
added screenW & screenH for debugview
fixed a bug in font drawing
cleaned code

[LaTo]

Will try if screenW and screenH would respond as in LSFmod...no they don't.
So the size might be the culprit and it would be a good addition
to have the display size adjustable with show=true.
Done in v1.44!

Looks like a great plugin! Would you be willing to release it as open source?
Maybe I don't know, but before I need to complete my todo-list ;)

[Usedocne]

SmoothAdjust is one of those filters that should be in everyone's plugin folder.

Nice job LaTo.

[royia]

SmoothAdjust is one of those filters that should be in everyone's plugin folder.

Nice job LaTo.
Once it has "Auto Levels" + DRC it will be.

[LaTo]

SmoothAdjust is one of those filters that should be in everyone's plugin folder.

Nice job LaTo.

Thanks! :)


Once it has "Auto Levels" + DRC it will be.

AutoLevels/DRC is difficult to implement into the video domains, simply because you need a efficient algorithm for scene change handling and for uniform scaling between different frames.

If you're so good, do it yourself!

[Emulgator]

So the size might be the culprit and it would be a good addition
to have the display size adjustable with show=true.
Done in v1.44!

Many thanks, this fixes it !

[royia]

Thanks! :)




AutoLevels/DRC is difficult to implement into the video domains, simply because you need a efficient algorithm for scene change handling and for uniform scaling between different frames.

If you're so good, do it yourself!

I didn't say I'm so good.
Just expressed what I think.

I have no knowledge in Programming.
If it helps, I can do it in Matlab.


I would Implement DRC using Bilateral Filter for each Frame. It works great on Still Frames.
Now, you have more knowledge in Video to make a limitation how will successive frames will be different.

You wrote some kind of DRC and Autolevels is planned. I just wrote once it's implemented this will be a must have Plug In for me.

Thank You.

[LaTo]

I didn't say I'm so good.
Just expressed what I think.

I have no knowledge in Programming.
If it helps, I can do it in Matlab.


I would Implement DRC using Bilateral Filter for each filter. It works great on Still Frames.
Now, you have more knowledge in Video to make a limitation how will successive frames will be different.

You wrote some kind of DRC and Autolevels is planned. I just wrote once it's implemented this will be a must have Plug In for me.

Thank You.

Ok, sorry I misunderstood your previous post.

Bilateral filter is great for photo, but for video it's too slow.
I didn't get a better result than AutoLevels plugin at this time, as I haven't much free time these days this functionnality is a bit postponed.


Apart from this, this is comparison of SmoothLevels and Ylevels with a simple gamma's adjustment:

Source (http://latoninf.free.fr/d9/SA/Orig.png)
SmoothLevels (http://latoninf.free.fr/d9/SA/SmoothLevels.png)
Ylevels (http://latoninf.free.fr/d9/SA/Ylevels.png)

;)

[royia]

There are approximations for the Bilateral Filter which are very fast (O(1), others as fast as Gaussian Blur).
So it won't be slower than a decent Noise Reduction filter.

[LaTo]

v1.46:
tweaked smoothing code
removed useless Smode=1 & Smode=2
prepared support for YV16 & YV24 in Avisynth 2.6.x
switched from VS2008 to VS2010

[LaTo]

v1.52:
added SSE2 code (Smode=1 is 2x faster & Smode=2 is 3x faster)
added useopt parameter

:devil:

[Usedocne]

Veeery nice. First nnedi3 gets a speed increase, now this. It's not Christmas yet, ya know. :D

[LaTo]

Someone could test the x64 build? Are SmoothLevels/Curve/Tweak functional?
A speed-test would be useful too (with useopt=true and useopt=false).

:thanks:

[Usedocne]

Quick speed test of SmoothAdjust v1.52 (x86).

10000 frames (720x480i)

Smode=1
0m.59s useopt=true
1m.22s useopt=false

Smode=2
3m.42s useopt=true
9m.20s useopt=false

DGDecode_mpeg2source("D:\My Videos\VOB\TEST\TEST.d2v")
SmoothLevels(Smode=, useopt=, preset="pc2tv")
Trim(0, 9999)

[LaTo]

Thanks! Nobody for the x64 build ..?

[Usedocne]

Thanks! Nobody for the x64 build ..?

Why not setup a VM to test your x64 build(s)?... Too much hassle?

[LaTo]

v1.56:
added SSSE3 code
changed CPU detection routine

[seojuhyun]

use the avisource script was avsp down.. at 1.56 ver o.o

AVISource(bla) << Source Res 1280x720
.....
.....
Crop(bla)
Tweak(bla)
Smoothadjust(bla)
Resize(624,352)

and push F5, shutdown avsp.

so i'm try test

downgrade. 1.56 >> 1.44

and use the same script


AVISource(bla)
.....
.....
Crop(bla)
Tweak(bla)
Smoothadjust(bla)
Resize(624,352)

Do Not AVSP DOWN, plz re-checking dll
thank you LaTo ;)

[LaTo]

use the avisource script was avsp down.. at 1.56 ver o.o

AVISource(bla) << Source Res 1280x720
.....
.....
Crop(bla)
Tweak(bla)
Smoothadjust(bla)
Resize(624,352)

and push F5, shutdown avsp.

so i'm try test

downgrade. 1.56 >> 1.44

and use the same script


AVISource(bla)
.....
.....
Crop(bla)
Tweak(bla)
Smoothadjust(bla)
Resize(624,352)

Do Not AVSP DOWN, plz re-checking dll
thank you LaTo ;)

Try with useopt=false in SmoothAdjust, it works?

[seojuhyun]

Try with useopt=false in SmoothAdjust, it works?
oh, good :goodpost: thx :)

[LaTo]

oh, good :goodpost: thx :)

The problem is fixed?

[seojuhyun]

The problem is fixed?

yeh fixed, but it's uncomfortable

mpeg2source and avisource,directshowsource etc...

problem at all... so i hope the fix, for option ;)

[LaTo]

Maybe someone else can confirm this bug... No problem on my side :?

[leeperry]

it's taking forever to open in ffdshow, I don't recall the older .avs version being this slow..I've tried to MT it on 4 threads both in auto and single thread mode.

[LaTo]

it's taking forever to open in ffdshow, I don't recall the older .avs version being this slow..I've tried to MT it on 4 threads both in auto and single thread mode.

Yes, the plugin version is slower at startup but is much faster after (I will try to reduce the startup time with v1.58)

And, it's not necessary to use MT, it is already multithreaded (check "multithread" parameter and set it to max)

External MT use 4 instances of SmoothAdjust, it's why it's so slow when you open your script...

[seojuhyun]

hm... just ignore lol.. i'm use the 1.44, i can't use 1.56

[leeperry]

I will try to reduce the startup time with v1.58
ok, cool! I've also tried SmoothLevels(preset="tv2pc",multithread=2,useopt=true), but it still takes quite a while to open and it's quite a CPU hog too(I run a 3.5Ghz Q9450) :o
SmoothLevels(preset="tv2pc",multithread=0,useopt=true)
=76fps
SmoothLevels(preset="tv2pc",multithread=1,useopt=true)
=93fps
SmoothLevels(preset="tv2pc",multithread=2,useopt=true)
=125fps
SmoothLevels(preset="tv2pc",multithread=3,useopt=true)
=119fps
colorYUV(levels="tv->pc")
=700fps

But considering that 1.58 might be faster to open, I'll try lower quality settings.

[LaTo]

ok, cool! I've also tried SmoothLevels(preset="tv2pc",multithread=2,useopt=true), but it still takes quite a while to open and it's quite a CPU hog too(I run a 3.5Ghz Q9450) :o
SmoothLevels(preset="tv2pc",multithread=0,useopt=true)
=76fps
SmoothLevels(preset="tv2pc",multithread=1,useopt=true)
=93fps
SmoothLevels(preset="tv2pc",multithread=2,useopt=true)
=125fps
SmoothLevels(preset="tv2pc",multithread=3,useopt=true)
=119fps
colorYUV(levels="tv->pc")
=700fps

But considering that 1.58 might be faster to open, I'll try lower quality settings...right now it adds more than one second of latency to the startup time.

If you need maximum speed to watch in realtime, simply use Smode=0. It should be enough...

[leeperry]

If you need maximum speed to watch in realtime, simply use Smode=0.
ok, I get 200fps w/ SmoothLevels(preset="tv2pc",multithread=2,Smode=0,useopt=true) using Avisynth 2.57, and 275fps using Avisynth 2.6. BTW, I get more fps if I disable MT in your plugin and run it w/ together my other scripts all at once using MT""" <> """,4) or SetMTmode(2,4).

I guess CUDA acceleration wouldn't possible? :o

This would be really great if the initialization time could shortened, indeed! I need to run more comparisons but your plugin seems more enjoyable to look at than colorYUV(), more contrasty/3D and less "noisy"..perfect for post-processing http://forum.slysoft.com/images/smilies/agreed.gif

PS: It looks so good! a faster opening and no more MOD4 error messages would be beyond words if any possible. :thanks:

[leeperry]

OK, so I've done a bit of comparisons between enabling dithering in SmoothLevels() or in mVR. I've used a noisy/bandy WMV SD video, and 2 of its corners to see how noise levels go IRL:

1)default dithering in SmoothLevels/no dithering in madVR
2)default dithering in SmoothLevels/dithering in madVR
3)no dithering in SmoothLevels/dithering in madVR

http://thumbnails34.imagebam.com/10460/33ca51104593699.jpg (http://www.imagebam.com/image/33ca51104593699) http://thumbnails34.imagebam.com/10460/dfcff0104593701.jpg (http://www.imagebam.com/image/dfcff0104593701) http://thumbnails26.imagebam.com/10460/7df1a7104593702.jpg (http://www.imagebam.com/image/7df1a7104593702)

http://thumbnails27.imagebam.com/10460/678fed104593704.jpg (http://www.imagebam.com/image/678fed104593704) http://thumbnails27.imagebam.com/10460/9aa909104593706.jpg (http://www.imagebam.com/image/9aa909104593706) http://thumbnails24.imagebam.com/10460/085168104593707.jpg (http://www.imagebam.com/image/085168104593707)

It's kinda late, I'll look at it again tomorrow but I believe that my Avisynth scripts do benefit from having some dithering done beforehand...it's not about suppressing banding, it's about trying to minimize it. SmoothLevels() uses dithering to smooth the TV>PC levels mapping, when madVR uses it to dither 16bit to 8? I might be wrong, though.

The picture seems clearer when I disable it in madVR and LSF seems cleaner looking when it's enabled in SmoothLevels() beforehand, as it's not trying to sharpen up big posterizing noise blocks anymore. But it's all very subjective, I'll do more comparisons(I should state that I'm colorblind)...it might very well be that both dithering passes actually compliment each other :)

[LaTo]

v1.60:
improved startup time
fixed MOD4 error message
tweaked various things
added ICC11 build

;)

[leeperry]

awesomeness, :thanks:

do you mean ICL11? I will try to run some VDUB benchmarks and report back :)

did you compare O2/O3 etc etc?

[LaTo]

Yes, ICC / ICL it is the same (http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler)... On my computer, ICC is 10% faster.

[leeperry]

oh OK, always only heard ICL :o

did you compare all the different options in ICL? Apparently there's a dozen way to compile stuff in ICL11 and some are faster than others depending on what code it's been optimized for.

when feeding 1272*686, I get: http://www.pixelz.fr/b/6/f/44448ed24e7602dfa02e205b0d0d2.png

if I use mmod(4,4) (http://forum.doom9.org/showpost.php?p=1453641&postcount=22), then it's padded to 1272*688 and it works fine. Maybe you could add an option to do the same internally? It'd be convenient for realtime use.

indeed, it seems a lot less laggy when seeking using SetMTMode(2,4) http://forum.slysoft.com/images/smilies/agreed.gif