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

[Dogway]

How can I make smoothcurve look like smoothlevels(preset="tv2pc")?

I tried with:
smoothcurve(ycurve="0-0;16-0;235-255;255-255",interp=0)
but colors are off

[Gavino]

colors are off
Add ucurve="0-0;16-0;240-255;255-255", and same for vcurve.

[Dogway]

Thanks!
Its better but still not exactly, does it have to be maybe with the decoding matrices leeperry (http://forum.doom9.org/showthread.php?p=1460710#post1460710) talked about?

edit: I used smoothlevels with chroma=100, which for instance gives different results than omitting the parameter (despite 100 is the default)

[poisondeathray]

Thanks!
Its better but still not exactly, does it have to be maybe with the decoding matrices leeperry (http://forum.doom9.org/showthread.php?p=1460710#post1460710) talked about?

edit: I used smoothlevels with chroma=100, which for instance gives different results than omitting the parameter (despite 100 is the default)

default value is chroma=50 in the older versions - it must have changed ?

EDIT: yes it did according to docs. Maybe it was typo? (No mention of change in changelog)

v1.7 default 50
v.1.74 default 100

[leeperry]

the right value for 601/709 is 84.

[Dogway]

I tested over tv2pc with chroma=84. So I made adjustments to fit tv2pc, gamma adjustments, and saturation all in one neat 16bit processing function. I found in my case 239 worked better instead 240. And this is not mathematical accurate, but should be near. By doing this you prevent artifacting and get a more accurate result:

smoothcurve(\
ycurve="0-0;14-0;80-96;118-140;205-255;255-255",\
ucurve="0-0;16-0;74-58;127-127;185-201;239-255;255-255",\
vcurve="0-0;16-0;74-58;127-127;185-201;239-255;255-255",\
interp=0,smode=0,show=false,limiter=true)

In this case Im using this just after loading source, so denoisers have enough range to "play" with.

[Floatingshed]

I like smoothtweak and have been using it a lot. Today something very odd occurred..
A very simple script ended with smoothtweak and looked fine in AvsPmod and VDub. However when encoded by X264 the framerate was halved and the vertical dimension doubled. Changing smoothtweak to tweak or removing it corrected the problem. Later I found that putting Assumeframebased() before smoothtweak also fixed it so that's how I encoded...
Any thoughts?

[Gavino]

Very strange. Reduce it to the smallest script possible that reproduces this effect, and ...
:script:

[nhope]

ICC & MSVC are the same for quality, it's only a speed difference. Pick the fastest for you.

Is there a generic recommendation for which one to try first, depending on the user's computer spec? It's for an online tutorial that will be read by a variety of users.

[LaTo]

Is there a generic recommendation for which one to try first, depending on the user's computer spec? It's for an online tutorial that will be read by a variety of users.

ICC should be faster with Intel CPU.
But if you don't care about minor speed gain, simply use MSVC.

[Dogway]

I played a bit with stainless toys, but couldn't figure out. Is there a way with smoothcurves to tweak UV only in bright/dark parts? I think it is not possible but, I was thinking about maybe a new function for smoothadjust "SmoothCoCo", I think that maybe color correction in yuv would be possible taking RGB values as inputs, and then mapping those to YUV values upon a LUT. I think that is what Whitebalance (http://forum.doom9.org/showthread.php?t=106196) does at least, its open source so maybe someone can look if that is what it does.

[StainlessS]

I played a bit with stainless toys

Hi Dogway, just wanna suggest that you might like the
RGBAdjust() Graffer too. you may have missed the recent
addition. If you need source, I could provide that but am
reluctant to put it out in general at this moment.

EDIT:- Source is VB6.

[Dogway]

What's the recent addition? for adjusting RGB I use Photoshop, but yuv2graff is the neat one because is the only real time yuv graph Im aware of.
Im talking about Whitebalance source which has some interesting way of mapping input rgb values to working yuv values. My idea is something like:
SmoothCoCo(\
rcurve="0-0;128-128;255-255",\
gcurve="0-0;128-128;255-255",\
bcurve="0-0;128-128;255-255",\
sat=0,interp=0,smode=0,strength=0,show=false,limiter=true)
Saturation is not possible in rgb but as we are working in yuv it can be introduced after the values remap. This can be very useful because all possible color corrections would be possible in one single step, in float point and with the benefits of the dither options of smoothadujst, like white point, black point, saturation, gamma, tonal variation, and custom color correction.

I also think that all float point working filters should have as default an option to choose whether output as is, or downgrade to 8bit which is the current method.

[StainlessS]

What's the recent addition?

see here:-
http://forum.doom9.org/showthread.php?p=1489256#post1489256

It's a graffer for RGBAdjust() filter. Not in the toys zip.

Thanks for name dropping the "yuv2graff", shall be hunting this out.

EDIT:- Google shows up only your, and my post for "yuv2graff", any
clues as to where this can be found?

[Dogway]

COLORYUV2_GRAF.exe I meant this one, I think its yours.
Thanks for RGBAdjust, I had it grabbed already. But that doesn't do anything related to YUV...

[nhope]

Yes I know, this will be fixed with avisynth v2.6.0 because it supports YV16 (which is exactly the same as YUY2 but planar).

The code is ready, I am just waiting after the release of avs 2.6.0 :D

Could YUY2 not work with SEt's builds of 2.6 (http://forum.doom9.org/showthread.php?t=148782)? Or might there be another way to support it? Just wondering, because -Vit- managed to add YUY2 support to QTGMC recently.

[LaTo]

Could YUY2 not work with SEt's builds of 2.6 (http://forum.doom9.org/showthread.php?t=148782)? Or might there be another way to support it? Just wondering, because -Vit- managed to add YUY2 support to QTGMC recently.

I will not support YUY2 because it is not planar.

You will need to do YUY2->YV16->YUY2 conversion. This is not a problem because it is a lossless conversion.

[LaTo]

v2.00 alpha:
improved smoothing algorithm
deleted Smode parameter
added AVX code
switched from ICL11 to ICL12
reduced startup delay
prepared higher bitdepth support (up to 16bits)
changed a lot of code
cleaned the code

Todo-list for v2.00 beta:
- implement a faster mode with lower quality for realtime viewing???
- finish higher bitdepth support
- finish avisynth 2.6.x support
- fix all the bugs reported


Download here: > SmoothAdjust v2.00 alpha < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00alpha.zip)

I have rewritten a lot of things in this release, so it's an alpha version.
The quality is much better with the new algorithm.

I need some people for testing the AVX part because I haven't a Sandy Bridge CPU.
Just use a function with useOPT=0/1/2 and post the result here.

Any comments are welcome :)

[Dogway]

compared to v1.74 with same settings, lineart and shadows get washed out...

[leeperry]

very nice, an update to one of my fav AVS plugins :)

too bad there's no "Smode=0" usable in realtime anymore, and you've ditched the "multithread" argument too...I need it coz I use all my plugins together within the same MT("""____""",4).

[LaTo]

compared to v1.74 with same settings, lineart and shadows get washed out...
Please post screenshots. It's maybe because the default strength is a bit too high.


very nice, an update to one of my fav AVS plugins :)

too bad there's no "Smode=0" usable in realtime anymore, and you've ditched the "multithread" argument too...I need it coz I use all my plugins together within the same MT("""____""",4).
To turn off smoothing in realtime, set smooth=0.
And "multithread" is replaced by "useMT" ;)



PS: I have updated the readme.txt in the package (you need redownload it)

[Ponder]

@Lato,
Todo-list for v2.00 beta:
- implement a faster mode with lower quality for realtime viewing???

No need for lower quality for realtime viewing, perhaps as follow:

It would be very powerful if we can have two variables, refined luma average and refined median.
refined_luma_average(25,204) or rlav(25,204) means the user want a luma average of pixels between
25 to 204 to guide a levels function. I use rlav(25,200) with Didee's Ylevelss and tweak with great
success, since it catches fake dark scene (black clothings, objects move close to camera); fake
bright scenes (flashes, lights in dark environment) and many other difficult scenes described in
the refined luma average thread.

A constant gamma is somewhat limited, a lot of the time, gamma=1 is right, but some scenes
need gamma 1.1 to 1.2x for smoothadjust. A pure luma average to guide gamma miss all kind of scenes,
either brighten or darken a scene too much. On the hand, using rlav(25,200), or rlav(27,190)..
it guides gamma, or brightness variable intelligently to give very good viewing.

At the moment, ScriptClip("smoothlevels(0,gamma=1.x1-x2*rlav,255,0,255,darkSTR=rlav-10)") is
unusable, 90% slower,:-(, due to avisynth's speed penalty. x1, x2 chosen by user environment.

Is it technical hard to implement rlav into smoothadjust? Clip,to frame incompatible thing?
Keep up the good work.

[LaTo]

@Lato,


No need for lower quality for realtime viewing, perhaps as follow:

It would be very powerful if we can have two variables, refined luma average and refined median.
refined_luma_average(25,204) or rlav(25,204) means the user want a luma average of pixels between
25 to 204 to guide a levels function. I use rlav(25,200) with Didee's Ylevelss and tweak with great
success, since it catches fake dark scene (black clothings, objects move close to camera); fake
bright scenes (flashes, lights in dark environment) and many other difficult scenes described in
the refined luma average thread.

A constant gamma is somewhat limited, a lot of the time, gamma=1 is right, but some scenes
need gamma 1.1 to 1.2x for smoothadjust. A pure luma average to guide gamma miss all kind of scenes,
either brighten or darken a scene too much. On the hand, using rlav(25,200), or rlav(27,190)..
it guides gamma, or brightness variable intelligently to give very good viewing.

At the moment, ScriptClip("smoothlevels(0,gamma=1.x1-x2*rlav,255,0,255,darkSTR=rlav-10)") is
unusable, 90% slower,:-(, due to avisynth's speed penalty. x1, x2 chosen by user environment.

Is it technical hard to implement rlav into smoothadjust? Clip,to frame incompatible thing?
Keep up the good work.

Try Lmode=1, I think this is what you are looking for...

[Dogway]

Yes, it was the default. I didnt realise you changed strength parameter to smooth, so the higher default was being applied.
2 Qs:
Is it correct to use "0-16;x-16;127-x;x-235;255-235" for TV range inputs? It is for SmoothContrast.avsi (http://www.mediafire.com/?n8wxgjvp79ywwsf)
Is this or will be faster than ICC-x86?

it would be cool if you could implement 16bit I/O, for non destructive workflow for those filtering with dtiher.v1.8

[ChaosKing]

I made ​​some quick tests, but the results do not look good. Either I use the plugin incorrectly or there is a bug somewhere...

Tested on: 2500K CPU, Avisynth 2.6
#loadplugin("..\SmoothAdjust-ICL-x86.dll")
loadplugin("..\SmoothAdjust-MSVC-x86.dll")

directshowsource("..\a.avi")
blackmanresize(1240,720) # ~150 fps


#SmoothLevels(useMT=0,lmode=1,gamma=2.22,useOPT=0,show=false) # ICL = ~63.7 fps | MSVC = 56.6 FPS
#SmoothLevels(useMT=0,lmode=1,gamma=2.22,useOPT=1,show=false) # ~63.1 fps | MSVC = 56.5 fps
#SmoothLevels(useMT=0,lmode=1,gamma=2.22,useOPT=2,show=false) # ~63.4 | 56.5

#SmoothLevels(useMT=-1,lmode=1,gamma=2.22,useOPT=0) # ~63.3 | 56.6
#SmoothLevels(useMT=-1,lmode=1,gamma=2.22,useOPT=-1) # ~63.0 | 56.3

#SmoothLevels(gamma=2.22) # /!\ CRASH. ICL + MSVC
#SmoothLevels(gamma=2.22,lmode=1) # OK

http://img.ihack.se/?dm=1313062451129 (http://img.ihack.se/?pm=1313062451129)

[LaTo]

I made ​​some quick tests, but the results do not look good. Either I use the plugin incorrectly or there is a bug somewhere...

Tested on: 2500K CPU, Avisynth 2.6
#loadplugin("..\SmoothAdjust-ICL-x86.dll")
loadplugin("..\SmoothAdjust-MSVC-x86.dll")

directshowsource("..\a.avi")
blackmanresize(1240,720) # ~150 fps


#SmoothLevels(useMT=0,lmode=1,gamma=2.22,useOPT=0,show=false) # ICL = ~63.7 fps | MSVC = 56.6 FPS
#SmoothLevels(useMT=0,lmode=1,gamma=2.22,useOPT=1,show=false) # ~63.1 fps | MSVC = 56.5 fps
#SmoothLevels(useMT=0,lmode=1,gamma=2.22,useOPT=2,show=false) # ~63.4 | 56.5

#SmoothLevels(useMT=-1,lmode=1,gamma=2.22,useOPT=0) # ~63.3 | 56.6
#SmoothLevels(useMT=-1,lmode=1,gamma=2.22,useOPT=-1) # ~63.0 | 56.3

#SmoothLevels(gamma=2.22) # /!\ CRASH. ICL + MSVC
#SmoothLevels(gamma=2.22,lmode=1) # OK

http://img.ihack.se/?dm=1313062451129 (http://img.ihack.se/?pm=1313062451129)

I think there is something wrong with your FPS measurement because useOPT=1 is 4 times faster on my CPU than useOPT=0.
On top of that, useMT=-1 is also 4 times faster than useMT=0 with a quad core.

For the crash, strange... So SmoothLevels crash only with Lmode=0?
The crash occurs at startup or later in the video?

Can you try this:
SmoothLevels(gamma=2.22,Lmode=0,useOPT=0)
SmoothLevels(gamma=2.22,Lmode=1,useOPT=0)

SmoothLevels(gamma=2.22,Lmode=0,useOPT=2)
SmoothLevels(gamma=2.22,Lmode=1,useOPT=2)
Which one crash?

And with Avisynth 2.5.8? The crash is still here?

[LaTo]

it would be cool if you could implement 16bit I/O, for non destructive workflow for those filtering with dtiher.v1.8

It's more or less implemented, but Avisynth doesn't support any clip with higher bitdepth...

So you need to wait after a new Avisynth version, maybe it's ready for Avisynth 2.6 ??? I don't know :D

[Dogway]

Im about to wrap a project, could you confirm my 2 questions?

[LaTo]

Im about to wrap a project, could you confirm my 2 questions?

Sorry, but I didn't understand your 2 previous questions... Can you rephrase?

[cretindesalpes]

It's more or less implemented, but Avisynth doesn't support any clip with higher bitdepth...

Actually Dogway mentioned the dirty but convenient hack I implemented in Dither (http://forum.doom9.org/showthread.php?p=1386559#post1386559) to encode 16-bit pixel components : stack a clip made with the MSB parts on the top of the LSB clip. I second his request, as I'm trying to put together the basic functions which would benefit a 100% 16-bit processing chain (denoising, debanding, levels, colorspace conversion, resizing, final dithering...) without having to go back to 8 bits between each step.

[Dogway]

-Is this version faster than previous v.1.74? edit: yeah, tests indicate ~1.35x faster : D
-If I were to process a TV range yuv source (almost most of sources) the proper starting point for smoothcurves for example would be "0-16;16-16;127-127;235-235;255-235"? (Like in your first picture of the 2nd post)

[Ponder]

@Lato

Gamma above 1.17 already mess up some bright scenes. This is why I want gamma to collapse
to very near 1.0x ish. Loosely speaking, with gamma above 1.17, 5 to 15% of the frames suffer
some contrast washout.

I tried all Lmodes weeks ago. Constant gamma ,or brightness(using tweak) just won't work no
matter how one tweak existing parameters. Knowing autogain and autolevels also failed in many
scenerios. That was the main reason leading me to figured out the "refined" luma average which
came out to be very good at brightness detection and mighty useful when moderate gamma.

Given any clips that has all 3: dark, normal and bright scenes,"constant gamma" will always fail
partially either at the dark or the bright scenes. Its constantness will never allow it to work in
all 3 scenes. DarkSTR, BrightSTR are good features, but being constants also limit its usefulness.

For clips that have dark to bright scenes. I use rlav, Ymedian and testing some Ymax(loose)
in YLevelss lately. rlav, with Ymedian together is even better at brightness detection, thus give
great result when controlling gamma and brightness. I surely like to use at least these 2 variables
with SmoothLevels.

That being said, It is wasteful seeing all these useful variables, Gamma, DarkSTR, BrightSTR,rlav,
Ymedian not used to their full potentials. Please consider adding these functionalities in your
future releases. :thanks:

The good news is, calculating rlav and median are extremely fast using 1/14 or 1/16 size of the
clip if it is large. It will not slow down SmoothLevels if implemented.

[LaTo]

Actually Dogway mentioned the dirty but convenient hack I implemented in Dither (http://forum.doom9.org/showthread.php?p=1386559#post1386559) to encode 16-bit pixel components : stack a clip made with the MSB parts on the top of the LSB clip. I second his request, as I'm trying to put together the basic functions which would benefit a 100% 16-bit processing chain (denoising, debanding, levels, colorspace conversion, resizing, final dithering...) without having to go back to 8 bits between each step.

@cretindesalpes: OK, I will add this in the beta (until avisynth support 16bits).
The stacked 16bits is linear? Because I will assume that it is.


-Is this version faster than previous v.1.74? edit: yeah, tests indicate ~1.35x faster : D
-If I were to process a TV range yuv source (almost most of sources) the proper starting point for smoothcurves for example would be "0-16;16-16;127-127;235-235;255-235"? (Like in your first picture of the 2nd post)

@Dogway:
- Q1: It should be more or less the same speed as the old Smode=2. (I will make some benchmark with the next release)
- Q2: Yes, the starting & ending are good for TV range



@Lato

Gamma above 1.17 already mess up some bright scenes. This is why I want gamma to collapse
to very near 1.0x ish. Loosely speaking, with gamma above 1.17, 5 to 15% of the frames suffer
some contrast washout.

I tried all Lmodes weeks ago. Constant gamma ,or brightness(using tweak) just won't work no
matter how one tweak existing parameters. Knowing autogain and autolevels also failed in many
scenerios. That was the main reason leading me to figured out the "refined" luma average which
came out to be very good at brightness detection and mighty useful when moderate gamma.

Given any clips that has all 3: dark, normal and bright scenes,"constant gamma" will always fail
partially either at the dark or the bright scenes. Its constantness will never allow it to work in
all 3 scenes. DarkSTR, BrightSTR are good features, but being constants also limit its usefulness.

For clips that have dark to bright scenes. I use rlav, Ymedian and testing some Ymax(loose)
in YLevelss lately. rlav, with Ymedian together is even better at brightness detection, thus give
great result when controlling gamma and brightness. I surely like to use at least these 2 variables
with SmoothLevels.

That being said, It is wasteful seeing all these useful variables, Gamma, DarkSTR, BrightSTR,rlav,
Ymedian not used to their full potentials. Please consider adding these functionalities in your
future releases. :thanks:

The good news is, calculating rlav and median are extremely fast using 1/14 or 1/16 size of the
clip if it is large. It will not slow down SmoothLevels if implemented.

@Ponder: OK, I have understand. I will not implement something like this in the near future because dynamic variable will need a major rewrite of the filter and it need a good scene change algorithm to avoid jitter in the same scene. These 2 things will slow down a lot the processing.



I need some people for testing the AVX part because I haven't a Sandy Bridge CPU.
Just use a function with useOPT=0/1/2 and post the result here.

@EVERYONE: Nobody for testing the AVX part???

[cretindesalpes]

@cretindesalpes: OK, I will add this in the beta (until avisynth support 16bits).
The stacked 16bits is linear? Because I will assume that it is.

No, there is no assumption on the nature the 16-bit content, and currently, only planar YUV is supported. By default, consider they are standard YUV components extended to 16 bits, as defined here (http://msdn.microsoft.com/en-us/library/bb970578.aspx), for example. So a straightforward 8 to 16 bits conversion is just a StackVertical (last, last.BlankClip (color_yuv=$000000)).

By the way, how would you expect linear YUV to be encoded? Just by undoing the sRGB curve on the luma, leaving the chroma channels unchanged? Or by applying a regular sRGB->YUV conversion matrix on linear RGB data?

[LaTo]

By the way, how would you expect linear YUV to be encoded? Just by undoing the sRGB curve on the luma, leaving the chroma channels unchanged? Or by applying a regular sRGB->YUV conversion matrix on linear RGB data?
The correct conversion should be: 8bits YUV->8 bits sRGB->16bits linear RGB->16bits linear YUV.
But it's much slower than a simple Uint16(Uint8(YUV)<<8).

For now you're right, it's better to stuck with the simple solution (no gamma correction) until avisynth choose about linear vs gamma encoded for 16 bits.
Maybe informations are in the avisynth 2.6.x thread, I haven't checked.

[Yellow_]

No, there is no assumption on the nature the 16-bit content, and currently, only planar YUV is supported. By default, consider they are standard YUV components extended to 16 bits, as defined here (http://msdn.microsoft.com/en-us/library/bb970578.aspx), for example. So a straightforward 8 to 16 bits conversion is just a StackVertical (last, last.BlankClip (color_yuv=$000000)).

By the way, how would you expect linear YUV to be encoded? Just by undoing the sRGB curve on the luma, leaving the chroma channels unchanged? Or by applying a regular sRGB->YUV conversion matrix on linear RGB data?

Sorry to just jump in here with a dumb question but is it being considered in this thread to be able to get 16bit out of Avisynth in any way? Is it possible to get the LSB and MSB out and combine them in an external app?

[ChaosKing]

I think there is something wrong with your FPS measurement because useOPT=1 is 4 times faster on my CPU than useOPT=0.
On top of that, useMT=-1 is also 4 times faster than useMT=0 with a quad core.

For the crash, strange... So SmoothLevels crash only with Lmode=0?
The crash occurs at startup or later in the video?

Can you try this:
SmoothLevels(gamma=2.22,Lmode=0,useOPT=0)
SmoothLevels(gamma=2.22,Lmode=1,useOPT=0)

SmoothLevels(gamma=2.22,Lmode=0,useOPT=2)
SmoothLevels(gamma=2.22,Lmode=1,useOPT=2)
Which one crash?

And with Avisynth 2.5.8? The crash is still here?


My Results:
SmoothLevels(gamma=2.22,Lmode=0,useOPT=0) # no crash
SmoothLevels(gamma=2.22,Lmode=1,useOPT=0) # no crash

SmoothLevels(gamma=2.22,Lmode=0,useOPT=2) # no crash
SmoothLevels(gamma=2.22,Lmode=1,useOPT=2) # no crash

If I try it without the lmode parameter:
SmoothLevels(gamma=2.22) # crash at startup, immediately


I also tried Avisynth 2.58, but I still don't see any speed gain. I test with vdub 1.9.10 "run video analysis pass". This always worked for me.

by the way, the crash occures also on my other pc (Q9550 CPU).


Maybe you can suggest another tool for benchmarking

[LaTo]

My Results:
SmoothLevels(gamma=2.22,Lmode=0,useOPT=0) # no crash
SmoothLevels(gamma=2.22,Lmode=1,useOPT=0) # no crash

SmoothLevels(gamma=2.22,Lmode=0,useOPT=2) # no crash
SmoothLevels(gamma=2.22,Lmode=1,useOPT=2) # no crash

If I try it without the lmode parameter:
SmoothLevels(gamma=2.22) # crash at startup, immediately


I also tried Avisynth 2.58, but I still don't see any speed gain. I test with vdub 1.9.10 "run video analysis pass". This always worked for me.

by the way, the crash occures also on my other pc (Q9550 CPU).


Maybe you can suggest another tool for benchmarking

Ok, and SmoothLevels(gamma=2.22,useOPT=0) & SmoothLevels(gamma=2.22,useOPT=2)... Crash?

Sound really strange, are you sure that only one dll is loaded?

EDIT: I found the bug, a stupid copy/paste error... It's also why useOPT doesn't work on your PC. Thanks!

[LaTo]

v2.00 beta1:
fixed a bug that disable optimization
fixed a bug in AVX code
added avisynth 2.6.x support (and YV16/YV24 support)
decreased default strength: "smooth=50"

Todo-list for beta2:
- finish higher bitdepth support
- fix all bugs reported


Download here: > SmoothAdjust v2.00 beta1 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta1.zip)


@ChaosKing: Should be OK now, can you make FPS measurement on your 2500K between useOPT=0/1/2 please?

[LaTo]

Sorry to just jump in here with a dumb question but is it being considered in this thread to be able to get 16bit out of Avisynth in any way? Is it possible to get the LSB and MSB out and combine them in an external app?

Yes it's possible, but the external app need to be compatible.

[Ponder]

@Lato, no problem, Rome wasnt built in days. Actually, you don't need to use any scene change
algorithm at all. This is why varying gamma is so useful. A simple gamma=1.xx - b*RAVL already
smooth out everything. I never once encounter jitterness watching complex dancing scenes with
light beams flying all over the places, Dancing with the stars for example, bright foreground and
dark background panning during dances if that not complicate enough :-).

RAVL(0,255) almost = traditional luma average, may fail at such difficult scenes.
RAVL(25,200) will ignore all bright lights or dancing in the dark. Voila, problem solved.

I like to clarify how RAVL work(numerically), With a very very bright scene, the old luma average
can read 190, RAVL(25,200) will read about 95. On a bright scene, the old luma average read
130, RAVL(25,200) will read about 80. Now use it to regulate gamma, it will slightly darken a
frame, On the other hand, a "raw" luma average of 190 will crush the frame into darkness.
Ravl works as well in the very dark to dark scene by the same principle. Very effective.

A conditionfilter of if luma average < 45 do this, > 110 dont do that, will get jitters, and
one have to have very good scene change algorithm too. This is another reason why I use varing
gamma, to avoid scene change detection (slow, somewhat inaccurate). Awhile ago, I used the
old luma average in levels to regulate output_low and _high, did not experience jitterness
either, from what I remember.

I hope I can save you lot of time, by not going into the route of scene change detection. It
is not needed. For RAVL(25,200), Users still need to specify gamma=1.xx - b*RAVL to their taste,
video sources and settings nevertheless.

One final thought, I know you are quite busy working on 2.0beta, Any chance of a
Ecurve = Ylevelss type only if it is not too time consuming in the future. :thanks:

[leeperry]

To turn off smoothing in realtime, set smooth=0.
And "multithread" is replaced by "useMT" ;)
fair enough :)

but:
MT("""
SmoothLevels(preset="tv2pc",multithread=0,Smode=0)
""",4)
=400fps

MT("""
SmoothLevels(preset="tv2pc",useMT=0,smooth=0)
""",4)
=120fps :o

that's on an o/c Q9650, XPSP3, Avisynth 2.6

[Yellow_]

Yes it's possible, but the external app need to be compatible.

Could you elaborate regarding approach and in what way compatible.

The external app I'm considering is Blender, it has a 32bit float, linear space nodal compositor that includes image and video import nodes, splitting / combining channels etc.

Blender uses ffmpeg to import video and on Windows ffmpeg is built with avisynth support so it is possible to work with .avs scripts directly in Blenders nodal compositor and/or video sequence editor (a layer based approach). It can take multiple .avs imports and combine them. So in theory would I use two scripts for any given video file, one for LSB the other MSB and recombine them in blender if it turns out to be compatible?

I've been using yesgreys yCMS for YCbCr to RGB conversion using the option to go from 8bit YCbCr to 16bit linear, then dither to 8bit gamma encoded RGB for export from Avisynth. But 16bit would be very useful. :-)

Maybe just better to hang on a while longer if beta2 is slated for higher bit depth support?

[ninja_racoon]

It crashes whenever I change the gamma setting to anything other than 1.0, same for brightnes, contrast and saturation.
using SmoothAdjust v2.00 beta1

*edit*It only crashes when I enable useOPT=2 avx, using i5 2500k

[LaTo]

It crashes whenever I change the gamma setting to anything other than 1.0, same for brightnes, contrast and saturation.
using SmoothAdjust v2.00 beta1

*edit*It only crashes when I enable useOPT=2 avx, using i5 2500k

@ninja_racoon: This one still crash with useOPT=2? SmoothAdjust-ICL-x86.dll (http://latoninf.free.fr/d9/SA/SmoothAdjust-ICL-x86.dll)

[ninja_racoon]

@ninja_racoon: This one still crash with useOPT=2? SmoothAdjust-ICL-x86.dll (http://latoninf.free.fr/d9/SA/SmoothAdjust-ICL-x86.dll)
still crashes.

SmoothLevels(gamma=1.1,Lmode=2,protect=16,useMT=4,useOPT=2)
avisynth 2.5.8, x86

[LaTo]

still crashes.

SmoothLevels(gamma=1.1,Lmode=2,protect=16,useMT=4,useOPT=2)
avisynth 2.5.8, x86
Still crashes with SmoothLevels(gamma=1.1,Lmode=2,protect=16,useMT=0,useOPT=2) ?

[ninja_racoon]

Still crashes with SmoothLevels(gamma=1.1,Lmode=2,protect=16,useMT=0,useOPT=2) ?
with that settings it gives me this error.. i'm using v2.0 beta1(the one in /x86/ICL folder)

Errow Window
Traceback (most recent call last):
File "AvsP.pyo", line 5819, in OnMenuVideoToggle
File "AvsP.pyo", line 8925, in ShowVideoFrame
File "AvsP.pyo", line 9467, in PaintAVIFrame
File "pyavs.pyo", line 322, in DrawFrame
File "pyavs.pyo", line 301, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0xFFFFFFFF
Traceback (most recent call last):
File "AvsP.pyo", line 7123, in OnPaintVideoWindow
File "AvsP.pyo", line 9467, in PaintAVIFrame
File "pyavs.pyo", line 322, in DrawFrame
File "pyavs.pyo", line 301, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0xFFFFFFFF

[LaTo]

i'm using v2.0 beta1(the one in /x86/ICL folder)

[...] SmoothAdjust-ICL-x86.dll (http://latoninf.free.fr/d9/SA/SmoothAdjust-ICL-x86.dll)

Have you tried this fixed dll? It's a "beta2 prerelease" :D

And, SmoothTweak crashes too?

[ninja_racoon]

^I've tried the beta2, it still giving me error
(gamma=1.1,Lmode=2,protect=16,useMT=0,useOPT=2) beta2 <-- error
(gamma=1.1,Lmode=2,protect=16,useMT=4,useOPT=2) beta2 <-- crash

error message
Traceback (most recent call last):
File "AvsP.pyo", line 5819, in OnMenuVideoToggle
File "AvsP.pyo", line 8925, in ShowVideoFrame
File "AvsP.pyo", line 9467, in PaintAVIFrame
File "pyavs.pyo", line 322, in DrawFrame
File "pyavs.pyo", line 301, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0xFFFFFFFF
Traceback (most recent call last):
File "AvsP.pyo", line 7123, in OnPaintVideoWindow
File "AvsP.pyo", line 9467, in PaintAVIFrame
File "pyavs.pyo", line 322, in DrawFrame
File "pyavs.pyo", line 301, in _GetFrame
File "avisynth.pyo", line 277, in GetFrame
WindowsError: exception: access violation reading 0xFFFFFFFF


I'm currently using useOPT=1, works perfectly. :)