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

[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.

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]

Originally Posted by cretindesalpes

Actually Dogway mentioned the dirty but convenient hack I implemented in Dither 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.

Originally Posted by 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)

@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

Originally Posted by 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.

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.

Originally Posted by LaTo

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]

Originally Posted by LaTo

@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, 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]

Originally Posted by cretindesalpes

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_]

Originally Posted by cretindesalpes

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, 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]

Originally Posted by LaTo

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]

Originally Posted by ChaosKing

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 <


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

[LaTo]

Originally Posted by Yellow_

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.

[leeperry]

Originally Posted by LaTo

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

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

[Yellow_]

Originally Posted by LaTo

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]

Originally Posted by 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

@ninja_racoon: This one still crash with useOPT=2? SmoothAdjust-ICL-x86.dll

[ninja_racoon]

Originally Posted by LaTo

@ninja_racoon: This one still crash with useOPT=2? SmoothAdjust-ICL-x86.dll

still crashes.

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

[LaTo]

Originally Posted by ninja_racoon

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]

Originally Posted by LaTo

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]

Originally Posted by ninja_racoon

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

Originally Posted by LaTo

[...] SmoothAdjust-ICL-x86.dll

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

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.