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

[LaTo]

+-------------------------------------------------------------------------------------------------------+
| |
| SmoothAdjust plugin: SmoothLevels(), SmoothTweak(), SmoothCurve(), SmoothCustom() & SmoothTools() |
| |
| v3.20 by "LaTo INV." |
| |
| 15 November 2015 |
| |
+-------------------------------------------------------------------------------------------------------+



I. DESCRIPTION
II. DISCLAIMER
III. INSTALLATION
IV. REQUIREMENTS
V. MULTITHREADING
VI. USAGE
VII. COMMON SETTINGS
VIII. SMOOTHLEVELS - GENERAL SETTINGS
IX. SMOOTHLEVELS - LIMITING SETTINGS
X. SMOOTHTWEAK - GENERAL SETTINGS
XI. SMOOTHTWEAK - LIMITING SETTINGS
XII. SMOOTHCURVE SETTINGS
XIII. SMOOTHCUSTOM SETTINGS
XIV. SMOOTHTOOLS SETTINGS
XV. 16 BITS SETTINGS
XVI. CHANGELOG



I. DESCRIPTION :
================

SmoothAdjust is a set of 5 plugins to make YUV adjustements:
- SmoothLevels allows to change levels & gamma with optional limiting
- SmoothTweak allows to change brightness, contrast, saturation & hue
- SmoothCurve allows to change a plane according to a fixed curve
- SmoothCustom allows to change a plane according to a custom expression
- SmoothTools allows to use all the previous filters in one single pass

These 5 plugins have a smoothing & dithering algorithm to avoid banding issue.
Calculations are made in 32bits float to avoid rounding errors and artifacts.
SmoothAdjust is multithreaded (up to 16 threads) and SSE2/AVX2 optimized.

For automatic adjustments, see the "AutoAdjust" standalone plugin.



II. DISCLAIMER :
================

This program is free for non-commercial use only and must be distributed
in its original form without any modification, including this documentation file.
This program is provided as-is in the hope it will be useful but
without any warranty, including any hypothetical damages or issues.

The official home page is "http://forum.doom9.org/showthread.php?t=154971",
it always contains the latest version of this program.
This page acts as the official support center, also the author is reachable
through his member page: "http://forum.doom9.org/member.php?u=131032".

This plugin has required a lot of work and hundreds of coding hours, so if you like
it and feel the need to reward or inspire the author then please consider donating.
Donations are a fast, easy and secure operation through Paypal: simply follow the
link into the "Donate.url" shortcut (you do not need a Paypal account to donate).
All donations will be very useful and I thank in advance all the generous people,
also if you are on the doom9's forum please specify your nickname when donating.



III. INSTALLATION :
===================

There are different versions of SmoothAdjust to suit all installations of Avisynth:
- x86 builds are for Avisynth 32bits
- x64 builds are for Avisynth 64bits



IV. REQUIREMENTS :
==================

- Avisynth v2.6.x or Avisynth Plus
- YUV Planar (Y8, YV411, YV12, YV16, YV24)
- 8bits or 16bits (MSB/LSB)



V. MULTITHREADING :
===================
SmoothAdjust is internally multithreaded with official Avisynth version.
If AvisynthPlus or AvisynthMT is detected, internal multithreading is automatically disabled
even if external multithreading isn't used (this can be reactivated in parameters).

SmoothAdjust is designed to work with external multithreading, so fastest MT mode can be used.
With AvisynthPlus, this plugin is a MT_NICE_FILTER (automatic register, no need to call SetFilterMtMode).
With AvisynthMT, SetMtMode(1) must be called before SmoothAdjust.



VI. USAGE :
===========

- SmoothLevels( input_low, gamma, input_high, output_low, output_high, chroma, limiter, TVrange, preset,
Lmode, darkSTR, brightSTR, Ecurve, Ecenter, protect,
interp, dither, HQ, useMT, useOPT, debug, screenW, screenH, scale )

- SmoothTweak( brightness, contrast, saturation, hue1, hue2, limiter, TVrange,
Lmode, limitSTR, Ecenter,
interp, dither, HQ, useMT, useOPT, debug, screenW, screenH, scale )

- SmoothCurve( Ycurve, Ucurve, Vcurve, mode, limiter, TVrange,
interp, dither, HQ, useMT, useOPT, debug, screenW, screenH, scale )

- SmoothCustom( Yexpr, Uexpr, Vexpr, limiter, TVrange,
interp, dither, HQ, useMT, useOPT, debug, screenW, screenH, scale )

- SmoothTools( filename,
interp, dither, HQ, useMT, useOPT, debug, screenW, screenH, scale )

- SmoothLevels16(...), SmoothTweak16(...), SmoothCurve16(...), SmoothCustom16(...), SmoothTools16(...) for 16 bits


Last version (2015/11/15): SmoothAdjust v3.20 (http://latoninf.free.fr/d9/SA/SmoothAdjust-v3.20.7z)

Old version (for Avs2.5 or WinXP or Wine): SmoothAdjust v2.62 (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.62.7z)


If you really like this filter, please consider donating...
It will help me a lot to continue development and support.
Thanks for all! (link in the .7z package)


v3.20:
updated for Avs v2.6.0 final
fixed AVX2 crash with Win7 without SP1

v3.00:
dropped Avs v2.5.x support
added AVX2 code (10% faster)
modified plugin to be thread-safe (MT_NICE_FILTER)

v2.95:
fixed minor things
tweaked multi-threading code

v2.90:
fixed possible freeze in MT code
added explicit error messages

v2.85:
fixed bugs inside multi-threading code
removed user32 dependency
added AVX2 detection (for future opt)

v2.80:
used new C++11 features
rewritten multi-threading (native)
speed optimization (40% faster)
exception-safe code
added a high quality interpolation mode
changed some parameter names
fixed bugs in SmoothTools parser

v2.62:
fixed minor things & bugs
dropped ICL builds support

v2.60:
used new interface for v2.6.x builds

v2.55:
added small optimizations

v2.51:
fixed crash in SmoothCurve

v2.50:
added SmoothTools
improved SmoothTweak
improved dithering
tweaked memory usage
tweaked multithreading
cleaned various stuff

v2.00:
added Avisynth 2.6.x support
added Y8, YV411, YV16, YV24 support
added 16bits support with stacked MSB/LSB
added SmoothCustom filter
added TVrange parameter
added AVX optimization

improved smoothing algorithm
improved debug view
improved startup delay
improved speed with smoothing OFF

added decimals support in SmoothCurve
fixed interp scaling in SmoothCurve
changed defaults in SmoothLevels
fixed gamma clamping bug in SmoothLevels

fixed crash with mod4 clip
fixed freeze in debug view
deleted Smode parameter
switched from ICL11 to ICL12
cleaned a lot the code
updated the documentation


_

[LaTo]

Screenshots of SmoothCurve(show=true) & SmoothLevels(show=true):

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

http://latoninf.free.fr/d9/SA/SLshow_mini.png (http://latoninf.free.fr/d9/SA/SLshow.png)
* SmoothLevels - Click the image to enlarge *

[Gavino]

Excellent LaTo, many thanks.

Can you clarify one thing.
Are the 'curves' in SmoothCurve composed of linear segments, or is some sort of non-linear interpolation (eg spline) done?
This example suggests linear.

"0-0;16-0;235-255;255-255" = TV to PC conversion

[LaTo]

Excellent LaTo, many thanks.

Can you clarify one thing.
Are the 'curves' in SmoothCurve composed of linear segments, or is some sort of non-linear interpolation (eg spline) done?
This example suggests linear.

Yes it's only linear at this time :)

[Keiyakusha]

So now we have a plugin. Nice, thank you!

P.S.
Oh, I know, I know what we need now -> LSFmod 2.0 -> super fast asm-optimized plugin from LaTo ^__^

[LaTo]

So now we have a plugin. Nice, thank you!

P.S.
Oh, I know, I know what we need now -> LSFmod 2.0 -> super fast asm-optimized plugin from LaTo ^__^

SmoothAdjust is only C code :p

It's on my todo list to add asm code, but before... I need to learn asm :eek:

[elguaxo]

Thanks!

[Keiyakusha]

SmoothAdjust is only C code :p

Oh really? So such speedup only because of avs -> C port... So (probably) there is still place for improvements.

P.S.
Well, then super fast not asm-optimised LSFmod 2.0 from LaTo will be fine! :)

[MatLz]

Un grand merci !
I have to wait to test the dithering part of your plugin...
Can it contain a 'shift' of the space like using a combination of different extra mirrored pixels for gradfun2db ? (Like 32 + 28)

[LaTo]

Can it contain a 'shift' of the space like using a combination of different extra mirrored pixels for gradfun2db ? (Like 32 + 28)
I didn't understand your question but the dithering inside is different from gradfun2db.
GradFun2DB removes band in a video, but this one only prevents banding... So if the banding is already present in the clip, it will not remove it!
It's not the same goal :)

[MatLz]

I didn't understand your questionYeah...my english is so limited :D

Maybe you will better understand if you read my two posts in this page :
http://forum.doom9.org/showthread.php?t=152127&page=25

(I hope you will ;) )

[LaTo]

Yeah...my english is so limited :D

Maybe you will better understand if you read my two posts in this page :
http://forum.doom9.org/showthread.php?t=152127&page=25

(I hope you will ;) )

Ok, it's to remove the edge/border issue?

[MatLz]

Yes and no, this problem is known since a long time now but mirroring a different number of pixels doesn't give the same effect.
And the combination of the two, in serial or parallele, gives really nice results

[LaTo]

Yes and no, this problem is known since a long time now but mirroring a different number of pixels doesn't give the same effect.
And the combination of the two, in serial or parallele, gives really nice results

OK, maybe an addition to GF2mod, I will look at this later :)

[MatLz]

OK, maybe an addition to GF2mod, I will look at this later :)Nice!
(When you will have the time to look at that, don't hesitate to pm me, in french of course :D, to explain me what is the 'technical' reason of these differences)
Thanks.

[LaTo]

Someone could test this x64 version please? SmoothAdjust-x64.dll (http://latoninf.free.fr/d9/SA/SmoothAdjust-x64.dll)

[Didée]

Did only a very quick splash&go test, but the x64 dll it seems to work. (Calling all three filters with default() parameters.)

More later - a thunderstorm is coming up, I'll shut down now.

[Didée]

So far, everything seems to work. No crashes, no garbled output. It works. :)

However, it seems that the dithered-smoothing operation could need a little more work. Example: Pretty dark Intro of an average DVD show. Target operation: Levels(16,2.6,235,0,255,false).

Source frame:
http://img96.imageshack.us/img96/5103/sourceframe.th.png (http://img96.imageshack.us/i/sourceframe.png/)

Results:
http://img709.imageshack.us/img709/8487/smoothadjustlevels.th.png (http://img709.imageshack.us/i/smoothadjustlevels.png/)

The smoothing of the dark blocking isn't as effective as gradfun2db. Also, there is a problem at high-contrast transitions.

(Sorry I didn't cross-check if it's the same with the 32bit build ... funnily, on the new machine the Avisynth64 setup is more complete then the 32bit counterpart...)

[LaTo]

v1.02:
added x64 build
fixed a bug in SmoothLevels

[LaTo]

So far, everything seems to work. No crashes, no garbled output. It works. :)

However, it seems that the dithered-smoothing operation could need a little more work. Example: Pretty dark Intro of an average DVD show. Target operation: Levels(16,2.6,235,0,255,false).

Source frame:
http://img96.imageshack.us/img96/5103/sourceframe.th.png (http://img96.imageshack.us/i/sourceframe.png/)

Results:
http://img709.imageshack.us/img709/8487/smoothadjustlevels.th.png (http://img709.imageshack.us/i/smoothadjustlevels.png/)

The smoothing of the dark blocking isn't as effective as gradfun2db. Also, there is a problem at high-contrast transitions.

(Sorry I didn't cross-check if it's the same with the 32bit build ... funnily, on the new machine the Avisynth64 setup is more complete then the 32bit counterpart...)

Thanks for report!

Problem with high-contrast transitions should be fixed with 1.02

And I'll add later more options to be more aggressive with smoothing :)

[LaTo]

Thanks for report!

Problem with high-contrast transitions should be fixed with 1.02

And I'll add later more options to be more aggressive with smoothing :)

I can't reproduce it with 32bits version, I wait after your report (fixed or not?)

If it's not fixed, can you try with Smode=0...4 ?

[LaTo]

v1.16:
replaced Smode 3 & 4 with stronger smoothing function
changed minors things

About Smode:
In strength order:
+ 3 > 4 >>> 1 > 2 -

In speed order:
+ 2 > 1 >>> 3 >>> 4 -

In fact, Smode=2 is a lighter&faster version of Smode=1 and Smode=4 is a better version of Smode=3 (but much slower).

[carlmart]

This filter might be handy to what I am trying to do now, which is lowering the gamma on a video I have. What I want is getting some more detail in the shadows and darker areas.

What I am not familiar with is about the synthax to combine several functions together, and perhaps set some limiting on the brighter areas.

I have already tried <SmoothLevels(gamma=1.5)> and it brings out a lot. But I wonder if combining others might get more and not make things too "milky".

Limiting brighter areas would be handy too, I think. How do I write all this so I can play with the filters in AvsP?

This is my more critical situation, where the musician on the right is too dark:

http://www.mediafire.com/file/n4w5zu5ezjl/contrast#1.jpg

[LaTo]

This filter might be handy to what I am trying to do now, which is lowering the gamma on a video I have. What I want is getting some more detail in the shadows and darker areas.

What I am not familiar with is about the synthax to combine several functions together, and perhaps set some limiting on the brighter areas.

I have already tried <SmoothLevels(gamma=1.5)> and it brings out a lot. But I wonder if combining others might get more and not make things too "milky".

Limiting brighter areas would be handy too, I think. How do I write all this so I can play with the filters in AvsP?

This is my more critical situation, where the musician on the right is too dark:

http://www.mediafire.com/file/n4w5zu5ezjl/contrast#1.jpg

Lmode=1 should be useful for your clip:
SmoothLevels(gamma=1.6,Ecenter=32,Lmode=1)

Tweak gamma (around 2.0) for intensity and Ecenter (between 32 & 64) for best looking.

[VincAlastor]

thank you lato, smoothadjust is much faster than smoothlevels!

[LaTo]

v1.18:
tweaked Smode 3 & 4
updated avisynth header

:)

[Blue_MiSfit]

Nice! Your scripts are AWEOSME, LaTo! I use SmoothLevels quite frequently so any update or additional functionality is enthusiastically welcomed!

Derek

[Bi11]

I have a video that seems to have been converted from tv->pc levels, which causes details to appear hidden in dark areas and washed-out or clipped in bright areas (think dynamic contrast).

The levels histogram is shown below:
http://img80.imageshack.us/img80/7598/0255.png

Using SmoothLevels(preset="pc2tv") gives the histogram below:
http://img687.imageshack.us/img687/1513/16235.png

That's probably how it was intended to look, but when viewed on a PC monitor it is clearly lacking contrast and vibrancy.
I want to keep the contrast but still see details in bright and dark areas.

I tried SmoothLevels(gamma=1.05, output_low=10, Lmode=3).SmoothTweak(contrast=0.92) giving the histogram below:
http://img205.imageshack.us/img205/1306/adjusted.png

The resulting image looks good enough but I really want to map tv 0 (i.e. 16) to pc 0 and tv white (i.e. 235) to pc 255, and a few levels above and below black and white could be mapped within 0-16 and 235-255 resp.
How can I achieve that?

BTW, it would be convenient to have a "show histogram" option in your plugin.

[LaTo]

I have a video that seems to have been converted from tv->pc levels, which causes details to appear hidden in dark areas and washed-out or clipped in bright areas (think dynamic contrast).

The levels histogram is shown below:
http://img80.imageshack.us/img80/7598/0255.png

Using SmoothLevels(preset="pc2tv") gives the histogram below:
http://img687.imageshack.us/img687/1513/16235.png

That's probably how it was intended to look, but when viewed on a PC monitor it is clearly lacking contrast and vibrancy.
I want to keep the contrast but still see details in bright and dark areas.

I tried SmoothLevels(gamma=1.05, output_low=10, Lmode=3).SmoothTweak(contrast=0.92) giving the histogram below:
http://img205.imageshack.us/img205/1306/adjusted.png

The resulting image looks good enough but I really want to map tv 0 (i.e. 16) to pc 0 and tv white (i.e. 235) to pc 255, and a few levels above and below black and white could be mapped within 0-16 and 235-255 resp.
How can I achieve that?

BTW, it would be convenient to have a "show histogram" option in your plugin.

A sample please?

[Bi11]

I want something like:
# Compress 0-255->10-237
SmoothLevels(gamma=1.05, output_low=10, output_high=237)
# Stretch 10-16->0-16
SmoothLevels(input_low=10, input_high=16, output_low=0, output_high=16)
# Stretch 235-237->235-255
SmoothLevels(input_low=235, input_high=237, output_low=235, output_high=255)
Maybe I need to use MaskTools.

[Didée]

That's S-curve contrast reduction, basically.

Too lazy to work out a general formula ... with fixed values to spread [0-8]>[0,16] and [247,255]>[239,255] :

mt_lut("x 8 < x 2 * x 247 > 255 255 x - 2 * - x 8 - 247 24 - 247 8 - / * 16 + ? ?",U=2,V=2)

[Gavino]

mt_lut("x 8 < x 2 * x 247 > 255 255 x - 2 * - x 8 - 247 16 - 247 8 - / * 16 + ? ?",U=2,V=2)
I think you mean
mt_lut("x 8 < x 2 * x 247 > 255 255 x - 2 * - x 8 - 239 16 - 247 8 - / * 16 + ? ?",U=2,V=2)

[Didée]

No ... I was meaning
mt_lut("x 8 < x 2 * x 247 > 255 255 x - 2 * - x 8 - 247 8 - 8 - 8 - 247 8 - / * 16 + ? ?",U=2,V=2)

In a word, of course you're right.;) Thanks for pointing out.

[Bi11]

... with fixed values to spread [0-8]>[0,16] and [247,255]>[239,255] :

mt_lut("x 8 < x 2 * x 247 > 255 255 x - 2 * - x 8 - 247 24 - 247 8 - / * 16 + ? ?",U=2,V=2)
I tried it but there are still some light-gray details in bright areas that aren't being seen.

I don't know RPN very well, or how mt_lut should be used, but I tried:
mt_lut("x 8 < x 2 * x 252 > 255 255 x - 2 * - x 8 - 235 16 - 252 8 - / * 16 + ? ?",U=2,V=2)
It shows light-gray details while still keeping white at 255.
Original frame: http://img514.imageshack.us/img514/8640/orig.png Code above: http://img42.imageshack.us/img42/4494/mtlut235.png

Now I would like to make the dark levels a little brighter and then smooth the levels curve overall.

Edit: Since this clip is probably supposed to look like tv levels [16,235], I should ask how to properly convert TV->PC such that the video doesn't look like dynamic contrast is turned on. Maybe something like 16-20 -> 0-16 and 233-235 -> 235-255.

[Didée]

I tried it but there are still some light-gray details in bright areas that aren't being seen.
Somehow I have a suspicion. The suspicion that you are using a badly-calibrated (or badly-featured) LCD flatscreen, and that you're trying to work around bad brightlevel resolution.
Check e.g. here (http://www.lagom.nl/lcd-test/white.php) - do you see "everything"?


I don't know RPN very well, or how mt_lut should be used, but I tried:
[*wrong code*]
It shows light-gray details while still keeping white at 255.
That code is not correct. Look at the histogram. There is a gap between 235-250, that range is not used at all, because of the wrong formula.:)

Since this clip is probably supposed to look like tv levels [16,235], I should ask how to properly convert TV->PC such that the video doesn't look like dynamic contrast is turned on.
That's a misconception. A clip is not supposed to "look like" TV levels.
When a clip IS TV levels, then it looks correct on TV-levels display devices, and looks washed-out on fullscale display devices. And vice versa, a PC-scale clip will look correct on fullscale devices, and overcontrasted on TVscale devices.

Ah, I start getting lengthy .... anyway, what you are trying is solely a matter of personal preference. Not any kind of "correction" that would be "needed" to do.


FWIW ... generalized LUT function with "dark point" + "factor", and "bright point" + "factor".

point0 = 8
factor0 = 2.0
point1 = 247
factor1 = 2.0

P0=string(point0)
P1=string(point1)
F0=string(factor0)
F1=string(factor1)

mt_lut("x "+P0+" < x "+F0+" * x "+P1+" > 255 255 x - "+F1+" * - x "+P0+" - "+P1+" "+P0+" - 255 "+P1+" - "+F1+" * - "+P1+" "+P0+" - / * "+P0+" 2 * + ? ?")


There really should be a levels-filter that works with control points and splines, like those brightness/levels/whatever controls that we all know from most existing image graphic editors. More than a decade of Avisynth, and nobody did that yet ...

[Bi11]

The suspicion that you are using a badly-calibrated (or badly-featured) LCD flatscreen, and that you're trying to work around bad brightlevel resolution.
Check e.g. here (http://www.lagom.nl/lcd-test/white.php) - do you see "everything"?
My monitor may not be the best but I can clearly see 251 and 252, it takes a second but I can see 253 as well, and if I stare long enough I think I can see the very light gray squares at 254.
That code is not correct.
I knew the expr was wrong (I didn't know the correct one), but I still posted it so you would know what I was looking for (i.e. keeping white at 255).
A clip is not supposed to "look like" TV levels.
When a clip IS TV levels, then it looks correct on TV-levels display devices, and looks washed-out on fullscale display devices. And vice versa, a PC-scale clip will look correct on fullscale devices, and overcontrasted on TVscale devices.
I know what you mean, but that's not the case here. The video I have was most likely converted to pc levels when they encoded it for distribution. Their master copy is most likely tv levels. (Or maybe it was pc levels to start with and they still did a tv->pc conversion, i don't know. All I know is, when I call SmoothLevels(preset="pc2tv") I can see all the very light gray details as they were meant to be. If I then increase the levels from 235 to, say, 240 (as seen in a histogram) then some of those very light details become invisible.)

I'll experiment with the generalized LUT function to see if I can get the results I want.
:thanks:

[Didée]

I won't argue against that you see what you see. But it doesn't make sense to me. Given that the display doesn't clamp at close-to-white and close-to-black, you should be able to see all details in those areas without any adjustment. After all, these levels-manipulations don't invent any new information to start with. They only shift-around the already-present data.

It could be your playback filterchain. If you see all blacks and whites in the lagom tests, but don't see all blacks and whites during playback of a PC-scale video, then some part of your playback filterchain might do clamping to TV-levels.

[Gavino]

mt_lut("x "+P0+" < x "+F0+" * x "+P1+" > 255 255 x - "+F1+" * - x "+P0+" - "+P1+" "+P0+" - 255 "+P1+" - "+F1+" * - "+P1+" "+P0+" - / * "+P0+" 2 * + ? ?")
You're close... ;)

That 2 on the end should clearly be F0, but the bit in the middle is wrong too.
For the third case you have (x-p0)*[(p1-p0)-(255-p1)*f1]/(p1-p0) + p0*2
when it should be (x-p0)*[255-(255-p1)*f1-p0*f0]/(p1-p0) + p0*f0

It's easier to see if you write it like this:
Y0 = P0+" "+F0+" *"
Y1 = "255 255 "+P1+" - "+F1+" * -"
mt_lut("x "+P0+" < x "+F0+" * x "+P1+" > 255 255 x - "+F1+" * - x "+P0+" - "+Y1+" "+Y0+" - "+P1+" "+P0+" - / * "+Y0+" + ? ?")
There really should be a levels-filter that works with control points and splines, like those brightness/levels/whatever controls that we all know from most existing image graphic editors. More than a decade of Avisynth, and nobody did that yet ...
AdjustY("Spline(y, ...)")

[Didée]

Oh my, yes.

Seems it's not good to write LUTs with a bap in the left, cup'o'coffe in the right, and should've left for work five minutes ago. :D

[LaTo]

There really should be a levels-filter that works with control points and splines

SmoothCurve use control points and linear interpolation...

It's on my todo list, someone has a good documentation/paper about splines?

[LaTo]

v1.24:
added new interpolation mode for SmoothCurve (see interp)

[LaTo]

There really should be a levels-filter that works with control points and splines, like those brightness/levels/whatever controls that we all know from most existing image graphic editors. More than a decade of Avisynth, and nobody did that yet ...
done :cool:

[markanini]

I tried to use smoothlevels on a heavily overexposed jpeg still image. It required a major gamma adjustment downward to 0.06 which resulted in heavy blockiness in bright areas due to 8-bit source. Tweaking smoothing and dither settings didnt yield acceptable results and trying gradfun2dbmod afterwords didnt help either. I ended up working on it in Photoshop. Prior to final gamma adjustment I converted to 16-bit, seperated the image at 0-249 & 250-256, applied biltaeral filter + noise for the high range that contained blocking and added the ranges back together which yielded an acceptable result after gamma adjustment.

During the process I spent some time trying different bluring filters, box, median, gauss and I settled for bilateral as the shapes of the blocks turned out the most natural looking while retaining definition but the gradiations werent particularly smooth which is why I added noise.

May be some of these ideas could be implemented into your plugins like a bilateral mode or stronger processing in the outer extreme tonal ranges?

[royia]

SmoothCurve use control points and linear interpolation...

It's on my todo list, someone has a good documentation/paper about splines?
One easy way would be looking at Matlab's code for Splines.

[LaTo]

One easy way would be looking at Matlab's code for Splines.

Thanks but it's already in v1.24 ;)

I tried to use smoothlevels on a heavily overexposed jpeg still image. It required a major gamma adjustment downward to 0.06 which resulted in heavy blockiness in bright areas due to 8-bit source. Tweaking smoothing and dither settings didnt yield acceptable results and trying gradfun2dbmod afterwords didnt help either. I ended up working on it in Photoshop. Prior to final gamma adjustment I converted to 16-bit, seperated the image at 0-249 & 250-256, applied biltaeral filter + noise for the high range that contained blocking and added the ranges back together which yielded an acceptable result after gamma adjustment.

During the process I spent some time trying different bluring filters, box, median, gauss and I settled for bilateral as the shapes of the blocks turned out the most natural looking while retaining definition but the gradiations werent particularly smooth which is why I added noise.

May be some of these ideas could be implemented into your plugins like a bilateral mode or stronger processing in the outer extreme tonal ranges?

You can make this (blur+noise) easily with mt_masktools:

source=last
process=source.bilateral().noise()
mt_lutxy(source,process,"x 250 >= y x ?",chroma="copy")
SmoothLevels(gamma=0.06,Smode=3)


:devil:

[LaTo]

v1.26:
Smode=3 is now the default (instead of Smode=1)
tweaked smoothing sensitivity
updated documentation about Smode

[markanini]

Thanks for the script LaTo. I may have to try it out some time :)
Still, When I fed Smoothadjust with a non mod4 source and smoothing strenght maxed out the erronious result that came up looked a lot like box blur to me. Maybe it's naive to assume that's what smoothadjust uses but I'm still not getting satisfactory results on the image I mentioned before with the newest version.
No chance of seeing a median Smode 5? :D

[LaTo]

Thanks for the script LaTo. I may have to try it out some time :)
Still, When I fed Smoothadjust with a non mod4 source and smoothing strenght maxed out the erronious result that came up looked a lot like box blur to me. Maybe it's naive to assume that's what smoothadjust uses but I'm still not getting satisfactory results on the image I mentioned before with the newest version.
No chance of seeing a median Smode 5? :D

And with Smode=4? Results should be much better for high strength.

[markanini]

@ LaTo:
Blocking is still there. Its an extreme case though due to lighning conditions being comparable to 'film noir' and besides being overexposed the picture seems to have had and s-curve applied. So I'd rather blame 8-bit format and jpeg compression than smoothlevels.

I've found better results than before on blocky ranges by employing anistotrophic filtering. Such a filter would be ridicoulously slow for video though.
There was also the issue of mosquito noise which was removed perfectly when filtering was limited to outliers above a set threshold, leaving original grainy texture intact.
I hope I've given you some food for thought and anyone else dealing with sources that have severe artefacts afterlarge level/gamma adjustment. Unfortunately I'm avisynth illiterate so I cant write script examples of the processing I've done in Photoshop.

Summaring my method:
Upping bit depth(optional).
Bluring/denoising +adding noise to level ranges that contain blocking.
Levels/gamma adjustment.
Blurring/denoising outliers to remove mosquito noise.
Denoise and sharpen to taste.

Results should be kickass.

[Emulgator]

Many thanks for 1.26, LaTo !
Cubic splines and their smoother derivatives work beautifully on Y and finally U and V !
Smooth histograms from poor sources at last, Smode=4 and strength=100 are welcome !

[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

[LaTo]

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

I will add auto-mod4 later ;)

[Dogway]

Avisynth crashes with smoothlevels and smoothtweak

PD: smoothcurve too, always when a change (smoothlevels(0,1.0,255,0,255) OK)

[leeperry]

I will add auto-mod4 later ;)
ok, cool! I get 370fps w/ the ICC11 build on 4 threads/Q9450, 350fps w/ the MSVC and 280fps w/ 1.56..nice speed boost!

it's still a bit slow to open when using SetMode(2,4) but it's a far cry from 1.56...this one was taking forever :scared:

[LaTo]

Avisynth crashes with smoothlevels and smoothtweak

PD: smoothcurve too, always when a change (smoothlevels(0,1.0,255,0,255) OK)
With which build? MSVC or ICL? x86 or x64?
Crash at startup? or later?
Is it working with useopt=false? with a older version?
What is your entire script? the clip's resolution?

Thanks!

[Dogway]

useopt=false solved it.
Why is it? I have SSE2/SSSE3.

Do you recommend me ICC over MSVC for quality?

I run 2.5.7 MT WinXP SP3 Core2Duo T9400, and I tested the plugin with plugin folder empty to discard possible incompatibilities.

[LaTo]

useopt=false solved it.
Why is it? I have SSE2/SSSE3.

Do you recommend me ICC over MSVC for quality?

I run 2.5.7 MT WinXP SP3 Core2Duo T9400, and I tested the plugin with plugin folder empty to discard possible incompatibilities.
ICC & MSVC are the same for quality, it's only a speed difference. Pick the fastest for you.

Can you provide your entire script and a video sample please?
And have you tested with the official avisynth v2.5.8?

[Dogway]

ImageReader("Boulevard_du_Temple (Paris 1838).jpg")
bicubicresize(860,620)
converttoyv12
smoothlevels(0,1.1,255,0,255)

nothing fancy, Im testing with that photo taken from wikipedia.

I mainly use 2.5.7 because it has the widest compatibility. But I just tested rapidly with 2.5.8 MT and also crashed.
I smell Im lacking some important libraries as Im also having difficulties with importuncompressedfile.dll

[LaTo]

OK I can reproduce the crash, strange... I will investigate, thanks!

edit: fixed in v1.62

[LaTo]

v1.62:
fixed crash with misaligned clip
added MOD2 support

:cool:

[leeperry]

added MOD2 support
http://forum-images.hardware.fr/images/perso/cytrouille.gif

[TheSkiller]

SmoothAdjust is great! But there's something I'm missing ever since I started using it: YUY2 support.
Do you consider adding YUY2 support anytime? :cool:

[LaTo]

SmoothAdjust is great! But there's something I'm missing ever since I started using it: YUY2 support.
Do you consider adding YUY2 support anytime? :cool:

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

[Dogway]

@LaTo: I dont know but contrast here doesnt work as expected, like in sgradation,photoshop,etc. You know, the S curve. And thanks for the update, it works great now!

[LaTo]

@LaTo: I dont know but contrast here doesnt work as expected, like in sgradation,photoshop,etc. You know, the S curve. And thanks for the update, it works great now!

Contrast in SmoothTweak is the same as in avisynth's Tweak().

If you want to apply a "S curve" simply use SmoothCurve:

contrast=16 # [0 to 64]

SmoothCurve(Ycurve="0-0;64-"+string(64-contrast)+";128-128;192-"+string(192+contrast)+";255-255")

[Dogway]

Thats what I meant, when it comes to a simple "contrast" it renders in a complex syntax, when the very purpose of the filter is to be made easy, no? Just my opinion.

[Didée]

Well, S-curve contrast adjustment basically is "freestyle" / "arbitrary", and therefore it is not "simple". In PotoShop et.al. you have a GUI to draw controlpoints etc., whereas Avisynth filters usually don't have a GUI. So you have to specify control points by typing numbers. What do you expect - reckognition of mouse gestures? :D

(And SmoothCurve's syntax is really not difficult ... rather "as simple as it can only get".)

[Dogway]

Hi Didée : D
I just named "the S curve" to specify the type of contrast. Not the method, in fact when I refer to Photoshop's contrast I talk about the brightness/contrast slider, but the effect is the same. And SGradation is as simple as a float number : /

[Didée]

Yeah. But then, Photoshopulus pompous has about ten thousand different filters to make your life easy. The hard part is to find the right filter. :D

To me, syntax of SmoothAdjust is just fine. "in1-out1, in2-out2, in3-out3, .." - simple enough to get grip, yet versatile enough to be adopted to the actual requirements. Really, I couldn't think of a better compromise.

Of course, if you prefer Photopompous ... use it! :p

[Dogway]

no Didée I prefer SGradation, :P
I know you can do all the operations writing directly masktools functions... but for the rest of people why dont to make it easier (dumb if you want), as a matter of fact what does smoothtweak's contrast actually does? smoothlevels(x,1.0,x,0,255)?

[Didée]

"it must be like in Photoshop!"
- "no! it must be like in Gimp!"
--- "no! it must be like in CorelDraw!"
- - - "no! it must be like in Paint Shop!"
- - - - "no! it must be like in Photo Line!"

No. it must be like in SmoothAdjust/Curve. This is fine.

BTW, I didn't even mention masktools.

[Dogway]

There's a reason on why a broad number of applications agree on what contrast is, Im not complaining, Im giving my opinion (to dumb the contrast setting down), given. And asking how is working as for now (range clipping)?

[Didée]

Tweak does the equivalent of "levels(0,1.0,255, 0,x)".

We don't need to start it all over (http://forum.doom9.org/showthread.php?p=1379275#post1379275), do we? :eek:

[Dogway]

nono, just answered my question, thank you (no pun)

[LaTo]

Thats what I meant, when it comes to a simple "contrast" it renders in a complex syntax, when the very purpose of the filter is to be made easy, no? Just my opinion.

You can make a little function with an avsi stored in your plugin's folder:

function SmoothContrast(clip clip, float "contrast")
{
contrast = default(contrast, 0.0) # [-1.0 to +1.0]

return clip.SmoothCurve(Ycurve="0-0;64-"+string(64-64*contrast)+";128-128;192-"+string(192+64*contrast)+";255-255")
}


And use it like this: SmoothContrast(1.0)

[LaTo]

v1.64:
fixed cache problem with UV planes

[LaTo]

v1.68:
improved multithreading

[LaTo]

v1.70:
added curve in debug mode for SmoothLevels

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

[lych_necross]

Just out of curiosity, what settings did you use for the screenshot?

[LaTo]

Just out of curiosity, what settings did you use for the screenshot?

All the settings are on the screenshot... :confused:

[lych_necross]

omg, I can't believe I missed them... :o I feel like an idiot now

[LaTo]

omg, I can't believe I missed them... :o I feel like an idiot now

If you want this debug output, simply use SmoothCurve(show=true) / SmoothLevels(show=true)

;)

[Dogway]

@LaTo: Just wanted to say thanks because your contrast little script was useful in my last source. It was indeed "smoother" than sgradation. Its ok for a few things, but Im unsure smoothlevels + smoothcontrast preserves more data than toRGB-Gicocu-toyv12? I would need to redraw my workflow...

[LaTo]

@LaTo: Just wanted to say thanks because your contrast little script was useful in my last source. It was indeed "smoother" than sgradation. Its ok for a few things, but Im unsure smoothlevels + smoothcontrast preserves more data than toRGB-Gicocu-toyv12? I would need to redraw my workflow...

I don't know, but SmoothAdjust doesn't need/do RGB->YUV conversion.
On top of that, all calculations are made in 32bits and are dithered at the end to 8bits.
It can't be better ;)

[LaTo]

v1.74:
updated preset="tv2pc" & preset="pc2tv"
fixed a bug in smoothing algorithm

:)

[lych_necross]

Thanks for the update LaTo! :D

[leeperry]

Yep, thanks for the 1.74 update!

For those that are curious, the TV>PC and PC>TV presets now fully abide by the REC.601/709 decoding matrixes...you get the same colors as madVR. ColorYUV is slightly off in comparison :devil:

And even in realtime w/ Smode=0, the additional dithering does a great job at smoothing the gradients :cool:

[Dogway]

@LaTo: Im trying to use SmoothCurves now, is there a way to clamp values? Say I want all the values below 2 to be 0, or all the values above 250 to be 255, normally I'd do "2-0;235-255" but it throws me a syntax error. One way would be to stack smoothlevels+smoothcurves but it would overlap dithering and it's just not as beautiful. Is it something hard to implement?

[Gavino]

normally I'd do "2-0;235-255" but it throws me a syntax error.
Try "0-0;2-0;235-255;255-255"

[Dogway]

Nice one, thanky!

[seojuhyun]

what is ICC and MSVC.. :confused:

[lych_necross]

what is ICC and MSVC.. :confused:
ICC and MSVC refer to the different compilers that were used to build SmoothAdjust. ICC is the Intel Compiler while MSVC is the Microsoft Visual Studio Compiler. You can use either the ICC or the MSVC version but not both. ICC builds tend to preform a little faster than MSVC builds; however, the performance difference is minimal (about 10% or less). MSVC builds, in my experience, tend to me slightly more stable (but again your mileage will vary). When in doubt, use the MSVC builds.

[seojuhyun]

ICC and MSVC refer to the different compilers that were used to build SmoothAdjust. ICC is the Intel Compiler while MSVC is the Microsoft Visual Studio Compiler. You can use either the ICC or the MSVC version but not both. ICC builds tend to preform a little faster than MSVC builds; however, the performance difference is minimal (about 10% or less). MSVC builds, in my experience, tend to me slightly more stable (but again your mileage will vary). When in doubt, use the MSVC builds.

ahah, okay, nice guide :) :thanks:

[Alex_ander]

Thank you for the filters.
I started using SmoothTweak() but as an AVSP user, found one thing missing. Usually, all functions including those belonging to the loaded external filters, are highlighted bold in AVSP (this confirms they were found) and they show floating tips while typing parameters. For each used numerical parameter a graphic slider is automatically created. All that doesn't happen with SmoothTweak(), unlike with Tweak() etc. As I can guess, some metadata must be present in .dll. Is it possible to provide it for the described functionality? Thanks.

[Gavino]

Alex_ander, as SmoothAdjust is relatively recent, AvsP has no built-in knowledge of it. However, if the plugin is in Avisynth's plugins folder (and hence loaded automatically), AvsP will find the information it requires (parameter names and types) to give you the floating tooltips. It cannot give sliders as it does not know the parameter defaults or their possible ranges.

You can add the required information for the sliders yourself under Options->Avisynth function definition->Plugins.

[Gavino]

ICC and MSVC refer to the different compilers that were used to build SmoothAdjust. ICC is the Intel Compiler while MSVC is the Microsoft Visual Studio Compiler. You can use either the ICC or the MSVC version but not both. ICC builds tend to preform a little faster than MSVC builds; however, the performance difference is minimal (about 10% or less). MSVC builds, in my experience, tend to me slightly more stable (but again your mileage will vary). When in doubt, use the MSVC builds.
Another difference I discovered recently is that (since LaTo switched to the VC++ 2010 compiler) the MSVC build will not run on older OS versions such as Windows 2000 or XP SP1.

[Alex_ander]

Thanks, Gavino. I had suspected that there could be difference with different ways of loading plugin, but only tested this with older plugins which I usually load in script. Then I'll put this dll into 'plugins', it is definitely worth to be always loaded :) .

[Dogway]

I find myself tweaking smoothcurves u an v plane for hours... trying to match a more intuitive curved rgb version. Is there any tool where I can translate rgb curves to yuv curves? Its really very hard to get the grasp of it.

[Didée]

Is there any tool where I can translate rgb curves to yuv curves?
Nope. You can't just go ahead and translate such a curve from RGB to YUV or viceversa. It's kinda impossible, since those colorspaces are too different. (It would require that the U/V curves are made cross-dependent AND luma-dependent, per pixel. But we have only independent channel-adjustment in Avisynth.)

I find myself tweaking smoothcurves u an v plane for hours... trying to match a more intuitive curved rgb version.
Lesson learned: YUV colorspace usually is not well suited to perform "extensive" color corrections.


ConvertToRGB

R = ShowRed(pixel_type="YV12") .SmoothCurves
G = ShowGreen(pixel_type="YV12") .SmoothCurves
B = ShowBlue(pixel_type="YV12") .SmoothCurves

MergeRGB(R,G,B)
ConvertToYv12()
That's all i can think of ATM.

[Dogway]

I don't expect a 1:1 curve conversion, but something that resembles the rgb counterpart or just maybe an external tool where I can fiddle yuv curve points until I know what Im doing.
Thanks for the workaround, it can benefit still from the dither part of the filter as opposed to gicocu. You use only the ycurve then, right?

[Yellow_]

Lesson learned: YUV colorspace usually is not well suited to perform "extensive" color corrections.


Could I just pick up on this point and ask, with regard to NLE's / video processing where it's generally understood many apps 'transform' the YCC to RGB internally for effects, compositing etc, is that RGB data for all intents and purposes identical to an image written out as say a raw image file with no compression? Or are there further operations done in the chain to get the image, like interpolation for example apart from writing it out to file :-)?

It's something I not quite understand, quite a few workflows that are seen involve conversion of video to image sequences or uncompressed RGB .avis for editing and effects.

My query really relates to the open source offerings where there is no real suitable NLE / Compositing App that does everything 'right' and work arounds are made.

For example no 32bit precision ops on YCC sources whether that be native YCC or a decent internal conversion to RGB by the NLE, they generally rely on FFMPEGs SWScale functions which appear are less than ideal.

In other words in the absence of decent data handling for conversion are there any real downsides to just converting to uncompressed RGB image sequences or avi's to edit and grade with apart from playback speed ie proxy workflow needed generally. For the 'smaller' amount of ops better done in YCC space a tranformation the other way internally.

RAW image editing apps like Rawtherapee or RawStudio offer batch operations and 32bit handling you see, but only for image sources.

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

[ChaosKing]

I just tried your beta, but it still crashes with: SmoothLevels(gamma=2.22)
and now
SmoothLevels(useMT=-1,lmode=1,gamma=2.22,useOPT=-1)
crashes too.

[LaTo]

I just tried your beta, but it still crashes with: SmoothLevels(gamma=2.22)
and now
SmoothLevels(useMT=-1,lmode=1,gamma=2.22,useOPT=-1)
crashes too.
^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
@ChaosKing & @ninja_racoon: Here is a new fixed version (I hope :D): > SmoothAdjust-FIX.dll < (http://latoninf.free.fr/d9/SA/SmoothAdjust-FIX.dll)
(It's a bit hard to debug without the target CPU)


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:
@Ponder: YlevelsS is the same as SmoothLevels(Lmode=2,Ecurve=0)


fair enough :)

but:
[...]
=400fps

[...]
=120fps :o

that's on an o/c Q9650, XPSP3, Avisynth 2.6
@leeperry: Try the fixed version in this post, it should be much faster when smooth=0.

[Ponder]

@Lato
Yes, they are from same sine family, but parameter must be very different, since I can't get
the contrast similar to YlevelsS, I don't want to use tweak to get contrast after SMOOTHLEVELS,
it slows thing down and risk polarizing. Can we have a third Ecurve mode where one can define
their own whacky function?

[leeperry]

@leeperry: Try the fixed version in this post, it should be much faster when smooth=0.
AMAZING, I get +700fps now :eek:

now to try it w/ movies, thank you so much for the quick fix :)

PS: I've A/B'ed the old and new versions around 50 times on many samples...the new one looks noticeably clearer and sharper when doing TV>PC, you've come a long way since the first script version..major kudos to you!

[ninja_racoon]

Does it really prevents banding with smooth=50 and dither=50 settings when I encode using x264?


@ChaosKing & @ninja_racoon: Here is a new fixed version (I hope ): > SmoothAdjust-FIX.dll <
(It's a bit hard to debug without the target CPU)
it still crashes for me.

(gamma=1.1,Lmode=2,protect=16,useMT=0,useOPT=2) <-- error
(gamma=1.1,Lmode=2,protect=16,useMT=4,useOPT=2) <-- crash

[LaTo]

v2.00 beta2:
tweaked smoothing algorithm
fixed crash with mod4 clip
fixed freeze in debug view
tweaked speed when smooth=0

Todo-list:
- finish higher bitdepth support
- repair AVX code
- fix all bugs reported
Download here: > SmoothAdjust v2.00 beta2 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta2.zip)

:)

[LaTo]

@ChaosKing & @ninja_racoon: About the crash/error with AVX stuff, please check the 6 dlls in this package: > AVX_debug.zip < (http://latoninf.free.fr/d9/SA/AVX_debug.zip)

Could you test them with SmoothLevels(gamma=2.0) and with SmoothTweak(contrast=2.0)?
Then see which ones work and report here.

Thanks for all!

[ChaosKing]

Only SmoothAdjust.6.dll is working. 1-5 = big crash

[LaTo]

Only SmoothAdjust.6.dll is working. 1-5 = big crash

Great, I think I got it :devil:

[LaTo]

v2.00 beta3:
fixed misaligned clip in AVX
finished 16bits support (stacked MSB/LSB)

Todo-list:
- check avisynth 2.6.x support (any inputs?)
- fix all bugs
Download here: > SmoothAdjust v2.00 beta3 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta3.zip)

:)

[markanini]

Tell us more about the tweaked smoothing algorithm

[ninja_racoon]

Only SmoothAdjust.6.dll is working. 1-5 = big crash
Yes, no.6 is working :)

[LaTo]

Yes, no.6 is working :)
beta3 should work too, right?

[ninja_racoon]

Download here: > SmoothAdjust v2.00 beta3
Thanks! :)

[mandarinka]

The 16bit hack is a nice idea, imho, getting hig bitdepth working without core changes.
Avisynth itself moves slowly and filters would need rewriting for a new colorspace anyway.
Now if only somebody wrote an import filter for x264cli :)

[cretindesalpes]

Now if only somebody wrote an import filter for x264cli :)
# "last" is a stacked MSB/LSB 16-bit clip

Interleave (Dither_get_lsb (), Dither_get_msb ())
TurnRight ()
AssumeFieldBased ().AssumeTFF ()
Weave ()
TurnLeft ()

# Ready to be encoded with:
#
# avs2yuv -raw "script.avs" -o - | x264-10bit --demuxer raw --input-depth 16 --input-res 1280x720 --fps 24 --output "blah.mp4" -
#
# Set --input-res and --fps according to your video settings.

[LaTo]

v2.00 beta4:
fixed YV16 & YV24 support
added Y8 & YV411 support

Todo-list:
- fix all bugs
Download here: > SmoothAdjust v2.00 beta4 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta4.zip)



Now you can process YUY2 clip without quality loss in Avisynth 2.6.x:

ConvertToYV16() #Lossless
SmoothAdjust(...)
ConvertToYUY2() #Lossless

My todo list is empty, so if you have any feature request...

[cretindesalpes]

My todo list is empty, so if you have any feature request...

Previously...

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 ;)

:devil:

[Dogway]

I was going to test the 16bit version, I think it could be more convenient if you could remap the values internally(?)
I also think you could add an option for when dealing with TVrange sources, specially in smoothlevels and tweak where you have no way.
more room when show=true for settings

[LaTo]

Previously...

[...]

:devil:

Good pick... Maybe with the 2.0final :p


I was going to test the 16bit version, I think it could be more convenient if you could remap the values internally(?)
You only need to multiply value by 256.
If I remap the value internally, it avoids fine adjustments.

I also think you could add an option for when dealing with TVrange sources, specially in smoothlevels and tweak where you have no way.
In SmoothLevels you only need to set output_low/output_high at 16/235 (or 4096/60160 in 16bits).
In SmoothTweak TVrange/PCrange doesn't change the processing (you can set "limiter=true" in TVrange).

more room when show=true for settings
:confused:

[Dogway]

You only need to multiply value by 256.
If I remap the value internally, it avoids fine adjustments.
I never worked with such numbers in 32bit applications, this next line is far from intuitive.
"0-4096;8704-4096;10496-8192;15616-17664;31744-31744;47872-46080;53760-53760;58880-64512;65280-60160",\
For fine adjustments we have always used decimals...
In SmoothLevels you only need to set output_low/output_high at 16/235 (or 4096/60160 in 16bits).
I see, I never use smoothlevels or smoothtweak but I thought about helping. Output_low/output_high at 16/235 is the same as clamping, and I recently read that many TVrange sources have below 16 or above 235 values which should be better leave alone.
In SmoothTweak TVrange/PCrange doesn't change the processing (you can set "limiter=true" in TVrange).
"limiter=true" readme says: Clamp the output to 16-235...
But I dont want to output/clamp TV range values,but instead work in TV range
For example, see this analogy by using smoothcurve
saturation in PC range:
"0-0;64-"+string(64-64*sat)+";128-128;192-"+string(192+64*sat)+";255-255"
saturation in TV range:
"0-16;16-16;74-"+string(74-55*sat)+";127-127;185-"+string(185+55*sat)+";240-240;255-240"
...or I am totally wrong.
:confused:
http://i212.photobucket.com/albums/cc35/Dogway/Misc/Untitled-2.png

[LaTo]

I never worked with such numbers in 32bit applications, this next line is far from intuitive.
"0-4096;8704-4096;10496-8192;15616-17664;31744-31744;47872-46080;53760-53760;58880-64512;65280-60160",\
For fine adjustments we have always used decimals...
No, 16bits values is the only way to go for precision. (SmoothAdjust works in 32bits internally, 16bits is just the input clip)

Example: "Invert" the 16 bits clip
SmoothCurve16("0-65535;65535-0") #Easy
SmoothCurve16("0.0-255,99609375;255,99609375-0.0") #Your proposition with decimals (65535/256 = 255,99609375)
SmoothCurve16("0-255;255-0") #Internal remap: the conversion is wrong (255*256->65280 != 65535)




I see, I never use smoothlevels or smoothtweak but I thought about helping. Output_low/output_high at 16/235 is the same as clamping, and I recently read that many TVrange sources have below 16 or above 235 values which should be better leave alone.
It's not the same as clamping (with limiter=0).



"limiter=true" readme says: Clamp the output to 16-235...
But I dont want to output/clamp TV range values,but instead work in TV range
For example, see this analogy by using smoothcurve
saturation in PC range:
"0-0;64-"+string(64-64*sat)+";128-128;192-"+string(192+64*sat)+";255-255"
saturation in TV range:
"0-16;16-16;74-"+string(74-55*sat)+";127-127;185-"+string(185+55*sat)+";240-240;255-240"
...or I am totally wrong.
Your 2nd script clamp output to TVrange :p (should be "0-0;16-16;...;240-240;255-255")
Also I doesn't understand why you want to leave theses parts "as-is".
If you do that, you will have strange things later.

Example: "Desaturate" a clip
SmoothCurve(UVcurve="0-128;255-128") #In "PCrange", all colors are gone
SmoothCurve(UVcurve="0-0;16-16;17-128;239-128;240-240;255-255") #In "TVrange", extreme colors are still here



http://i212.photobucket.com/albums/cc35/Dogway/Misc/Untitled-2.png
I will try to improve a bit the view ;)

[ChaosKing]

beta4 AVX test
--------------------

#smoothlevels(gamma=2.0, useOPT=0) # 159 fps
#smoothlevels(gamma=2.0, useOPT=1) # 217 fps
#smoothlevels(gamma=2.0, useOPT=2) # 92 fps

#smoothlevels(gamma=2.0, useOPT=0, useMT=0) # 66 fps
#smoothlevels(gamma=2.0, useOPT=1, useMT=0) # 140 fps
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 33 fps

The AVX part still does not seem to work properly :/

[Dogway]

No, 16bits values is the only way to go for precision.
I dont know how other applications deal internally with it, and I can't tell you how but Im pretty sure is possible, that's why I tried to fill a bit your empty todo list. Its unintuitive as hell, thats all.

If you do that, you will have strange things later.
In effect I was totally wrong yey!
Some tests a few months ago I remember I could desaturate with no problems, but it makes sense that out of TVrange bounds colors follow a correlation with the curve

Your 2nd script clamp output to TVrange :p (should be "0-0;16-16;...;240-240;255-255")
Then I guess this example (http://forum.doom9.org/showthread.php?p=1503323#post1503323) wasn't correct at all
What I expect is a curve behaviour inside the TVRange in the same fashion as PCrange, but leaving the out of bounds values practically untouched. That's why my confusion on whether "0-0;16-16... or "0-16;16-16... because the first seems to be more locked on the extremes by the knobs (thus modifying the curve weight) than PCrange curve. While it being at first glance the ideal approach I can't tell behaviour is the same, Im not mathematician.

It's not the same as clamping (with limiter=0).
Then maybe is contradictory. Because "Output_low/output_high at 16/235" in levels is not "0-0;16-16;...;235-235;255-255". Maybe you wanted to say "16,1.0,235,16,235" but this flats values in the range 0-16 to a value of 16. There is no way in levels to do "proper" TVrange like you said in curves "0-0;16-16;...;235-235;255-255" (assuming this is the correct way which I discussed in the previous paragraph.)

edit: I think interp=100 doesn't work, using beta4

[mandarinka]

Hmm, I don't know if I am doing something wrong, here...

I wanted to replicate the effect of tweak(hue=+5) using smoothtweak. After some confusion, I realized that smoothtweak's hue1 and hue2 in fact seem to do the same thing as coloryuv's off_u and off_v, respectively.

(Acording to my very limited understanding, the hue parameter as used by tweak kind of rotates the color spectrum around the center/white/black/grey (or something like that, excuse me please), and strangely enough, a dvd I am trying to color-adjust for some strange reason seem to respond well to this kind of shifting...)

1) Is my observation correct? if it is so, mybe the parameters could use some additional explanation in readme...
2) Is there a way to do the adjustment tweak does for hue with smoothadjust, with its superior precission?

[LaTo]

Hmm, I don't know if I am doing something wrong, here...

I wanted to replicate the effect of tweak(hue=+5) using smoothtweak. After some confusion, I realized that smoothtweak's hue1 and hue2 in fact seem to do the same thing as coloryuv's off_u and off_v, respectively.

(Acording to my very limited understanding, the hue parameter as used by tweak kind of rotates the color spectrum around the center/white/black/grey (or something like that, excuse me please), and strangely enough, a dvd I am trying to color-adjust for some strange reason seem to respond well to this kind of shifting...)

1) Is my observation correct? if it is so, mybe the parameters could use some additional explanation in readme...
2) Is there a way to do the adjustment tweak does for hue with smoothadjust, with its superior precission?
1. Correct
2. No sorry


edit: I think interp=100 doesn't work, using beta4
Yes, just a bad scaling... 50 is in fact 100, so higher than 50 produces strange result :D (fixed in the next beta)


beta4 AVX test
--------------------

#smoothlevels(gamma=2.0, useOPT=0) # 159 fps
#smoothlevels(gamma=2.0, useOPT=1) # 217 fps
#smoothlevels(gamma=2.0, useOPT=2) # 92 fps

#smoothlevels(gamma=2.0, useOPT=0, useMT=0) # 66 fps
#smoothlevels(gamma=2.0, useOPT=1, useMT=0) # 140 fps
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 33 fps

The AVX part still does not seem to work properly :/
Very very strange, I don't understand. The results was with the MSVC or the ICL build?

Can you try the 2 dlls in this package > SmoothAdjust.AVXtest.zip < (http://latoninf.free.fr/d9/SA/SmoothAdjust.AVXtest.zip) and report FPS here (with useMT=0)?

Thanks!

[Dogway]

@LaTo: I was doing some tests and investigations using vectorscope for accuracy. Indeed SmoothLevels can work with TVrange like this "SmoothLevels(16,1.0,235,16,235..." but by doing so you cant avoid out of 16 and 235 values to not be flatten. This procedure overrides limiter=0. I can post samples but dont want to make the post too bulky.

I also noticed that there is no way you can match smoothcurve and smoothlevels in a simple gamma tweak, I get different curves, and results. So I think you are using another valid approach Im not aware of or something is missing.
SmoothCurve(Ycurve="0-0;128-136.3;255-255",smooth=0,dither=0,interp=50,show=true)
!=
SmoothLevels(0,1.1,255,0,255,smooth=0,show=true,dither=0,limiter=0)
About the 16bit input numbers, could this be possible? Fit (0-65535)/256 range values into 0-255. I dont know how range mapping is done in programming so Im probably talking too much.
Also is it broken decimals input in beta4?

[LaTo]

@LaTo: I was doing some tests and investigations using vectorscope for accuracy. Indeed SmoothLevels can work with TVrange like this "SmoothLevels(16,1.0,235,16,235..." but by doing so you cant avoid out of 16 and 235 values to not be flatten. This procedure overrides limiter=0. I can post samples but dont want to make the post too bulky.
Sorry, clamping is a bug. Fixed in the next beta.


I also noticed that there is no way you can match smoothcurve and smoothlevels in a simple gamma tweak, I get different curves, and results. So I think you are using another valid approach Im not aware of or something is missing.
SmoothCurve(Ycurve="0-0;128-136.3;255-255",smooth=0,dither=0,interp=50,show=true)
!=
SmoothLevels(0,1.1,255,0,255,smooth=0,show=true,dither=0,limiter=0)
Yes, it's normal... You need to set more control points because the interpolation doesn't follow a power curve.


About the 16bit input numbers, could this be possible? Fit (0-65535)/256 range values into 0-255. I dont know how range mapping is done in programming so Im probably talking too much.
Also is it broken decimals input in beta4?
Not broken, input points are integer from the beginning. Decimals added in next beta.

[Dogway]

You are right, I get the same identical results as of levels with "mt_lut(yexpr="x 255 / 1 1.1 / ^ 255 * ",Y=3,U=2,V=2)" then what is the "correct" gamma for smoothcurves? Is there an interp value to conform the power curve?

[LaTo]

You are right, I get the same identical results as of levels with "mt_lut(yexpr="x 255 / 1 1.1 / ^ 255 * ",Y=3,U=2,V=2)" then what is the "correct" gamma for smoothcurves? Is there an interp value to conform the power curve?
No, the only solution is to add more control points to approximate the gamma curve.

[Ponder]

@Lato
I do get back a lot more contrast on Lmode1 when using very conservative setting on BrightSTR.
Varying DarkSTR is quite safe on the other hand.

Q1. If I use gamma=1, will smoothing be turn off. Q2.If set Smode=1, will it be on at all time?
At certain situation, I want it to be on at all time with gamma=1.

Q3. Same behavior between v1.74 and v2?

[LaTo]

v2.00 beta5:
tweaked AVX support
fixed clamping bug in SmoothLevels
fixed interp scaling in SmoothCurve
added decimals support in SmoothCurve

Todo-list:
- fix AVX performance?!?
- improve debug view
- add SmoothCustom
- fix all bugs
Download here: > SmoothAdjust v2.00 beta5 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta5.zip)

:devil:

[LaTo]

@Lato
I do get back a lot more contrast on Lmode1 when using very conservative setting on BrightSTR.
Varying DarkSTR is quite safe on the other hand.

Q1. If I use gamma=1, will smoothing be turn off. Q2.If set Smode=1, will it be on at all time?
At certain situation, I want it to be on at all time with gamma=1.

Q3. Same behavior between v1.74 and v2?

Q1: No
Q2: Smode=0 -> always OFF // Smode=1/2 -> always ON
Q3: Yes but Smode is removed ( smooth>0 -> always ON // smooth=0 -> always OFF )




Here is a fast comparison of v1.74 & v2.xx with strength/smooth=100 (very strong):

Source image (http://latoninf.free.fr/d9/SA/compare/SRC.png)
Smoothing OFF (http://latoninf.free.fr/d9/SA/compare/OFF.png)
v1.74 (Smode=2) (http://latoninf.free.fr/d9/SA/compare/OLD.png)
v2.00beta5 (http://latoninf.free.fr/d9/SA/compare/NEW.png) (More effective, more details & sharpness, no artifact...)

SmoothCurve(Ycurve="0-16;16-16;64-128;128-224;235-235;255-235",Ucurve="0-0;64-192;128-128;192-64;255-255",Vcurve="0-255;64-64;128-128;192-192;255-0")

[leeperry]

Here is a fast comparison of v1.74 & v2.xx with strength/smooth=100 (very strong):

Source image (http://latoninf.free.fr/d9/SA/compare/SRC.png)
Smoothing OFF (http://latoninf.free.fr/d9/SA/compare/OFF.png)
v1.74 (Smode=2) (http://latoninf.free.fr/d9/SA/compare/OLD.png)
v2.00beta5 (http://latoninf.free.fr/d9/SA/compare/NEW.png) (More effective, more details & sharpness, no artifact...)
very impressive. :thanks: for the new build, much appreciated http://forum.slysoft.com/images/smilies/agreed.gif

[Dogway]

LaTo, thanks a lot! This plugin feels profesional, I wonder what SmoothCustom is... : D
btw how do you get that fancy colors in the UV debug, the Cb Cr colors...

[Ponder]

@Lato, Thanks, it clears up what I suspected on Q1&2 since DarkSTR was set to some value ,even
when gamma was 1.

[ChaosKing]

beta5 AVX test
------------------


#smoothlevels(gamma=2.0) # 232.56 FPS
#smoothlevels(gamma=2.0, useOPT=0) # 173.86 FPS
#smoothlevels(gamma=2.0, useOPT=1) # 232.89 FPS
#smoothlevels(gamma=2.0, useOPT=2) # 240.10 FPS

#smoothlevels(gamma=2.0, useOPT=0, useMT=0) # 83.33 FPS
#smoothlevels(gamma=2.0, useOPT=1, useMT=0) # 165.28 FPS
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 178.57 FPS

I noticed that smoothlevels(gamma=2.0) doesn't seem to use the AVX part. With useOPT=2 it's always faster!

[LaTo]

beta5 AVX test
------------------

#smoothlevels(gamma=2.0) # 232.56 FPS
#smoothlevels(gamma=2.0, useOPT=0) # 173.86 FPS
#smoothlevels(gamma=2.0, useOPT=1) # 232.89 FPS
#smoothlevels(gamma=2.0, useOPT=2) # 240.10 FPS

#smoothlevels(gamma=2.0, useOPT=0, useMT=0) # 83.33 FPS
#smoothlevels(gamma=2.0, useOPT=1, useMT=0) # 165.28 FPS
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 178.57 FPS

I noticed that smoothlevels(gamma=2.0) doesn't seem to use the AVX part. With useOPT=2 it's always faster!

Thanks for testing! Can you try these 2 dlls (AVXtest.zip (http://latoninf.free.fr/d9/SA/SmoothAdjust.AVXtest.zip)) and report the speed for each?

[ChaosKing]

AVXtest (test)
----------------

##avx 1
#smoothlevels(gamma=2.0) # 233.33 FPS
#smoothlevels(gamma=2.0, useOPT=2) # 232.56 FPS

#smoothlevels(gamma=2.0, useMT=0) # 129.03 FPS
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 128.05


##avx2
#smoothlevels(gamma=2.0) # 241.95 FPS
#smoothlevels(gamma=2.0, useOPT=0) # 105.12 FPS
#smoothlevels(gamma=2.0, useOPT=1) # 227.27 FPS
#smoothlevels(gamma=2.0, useOPT=2) # 243.89 FPS

#smoothlevels(gamma=2.0, useMT=0) # 129.03 FPS
#smoothlevels(gamma=2.0, useOPT=2, useMT=0) # 127.39 FPS

avx1 seems to be slower with useMT=-1. Each test was run with 3-5 runs.

[LaTo]

beta5 AVX test
------------------

[...]

I noticed that smoothlevels(gamma=2.0) doesn't seem to use the AVX part. With useOPT=2 it's always faster!

@ChaosKing: Please redownload beta5, now it will autoselect AVX correctly :)

[kostik]

How can I use 16bit ? what command should be put in avisynth?
I get strange colors when using :
ConvertToYv16()
SmoothCurve16("0-65535;32768-32768;65535-0")

can someone write a code to get 16bit ?
thanks

[Dogway]

hey kostik, I like your code but I think that is not going to work.
download dither (http://forum.doom9.org/showthread.php?p=1386559#post1386559) and write the next code:
Dither_convert_8_to_16()
SmoothCurve16("0-0;32768-36768;65535-65535")
ditherpost()

Play with the values but that is a good starting point.

[kostik]

thanks!

[mandarinka]

I want to try processing in 16bit. I assume the filter doesn't support working from 8bit input to 16bit output, right?
Would this be correct to get the MSB/LSB stacked clip, or do I need to use ditherXpre (even though I don't need any actual dithering at that point)?

video = last
stackvertical(video,blankclip(video,color_yuv=$000000))
# and smoothtweak...
smoothtweak16(contrast=0.84)

[cretindesalpes]

Yes, Dither_convert_8_to_16() does exactly that.

Anyway DitherXPre doesn't do any dithering. Dithering is the inverse operation (from 16 back to 8 bits).

[mandarinka]

Oh, I see. To be honest I got a bit lost in all the functions in Dither and wasn't sure what does what (or doesn't) at all...

Thanks for the tip.

[jmac698]

Interesting, I'll have to add support for your stacked kludge into my HDR tools. I use separate clips for msb/lsb because to me it didn't make sense to stack them; most filters wouldn't produce valid results if applied the same way to both bytes.
If you need to pass a highbit video in one clip, that's the only way of course.

[Yellow_]

Ok I have a bit of a problem getting SmoothAdjust to co operate with writing out 16bit image sequences via avs2yuv and imagemagik.

Basically to get SmoothAdjust 16bit functions to work it appears I need to add 'Dither_convert_8_to_16()' otherwise I get the same split frame as Kostick as posted above.

BUT adding 'Dither_convert_8_to_16()' works so far until I try to use:

Dither_convert_yuv_to_rgb(matrix="601", tv_range=false, cplace="MPEG2", chromak="bicubic", output="rgb48yv12")

And then pipe out via avs2yuv to Imagemagick I get this error:

Dither_resize16: Cannot allocate buffer memory.

And no images get written.

But if I remove the: 'Dither_convert_8_to_16()' and hash out the SmoothAdjust stuff I can write 16bit image sequences.

Is SmoothAdjust msb/lsb stack not be implemented the same as Dither 1.9?

[cretindesalpes]

Your problem comes from Dither_convert_yuv_to_rgb() running very quickly out of memory (it uses Dither_resize16() internally). I'm currently working on this issue, to make Dither_resize16 less memory hungry.

[Yellow_]

Ok, thanks for the explanation, wasn't sure if I was using the functions correctly.

[Dogway]

It would be cool if you added lsb_in feature for inputting 16bits stacked clips. Besides correcting chroma in debug, in case it is a bug.

edit: Also there seems to be a bug in UV planes with smoothcurve16. It is less red than default smoothcurve. Maybe it is related to dither, who knows...

[LaTo]

It would be cool if you added lsb_in feature for inputting 16bits stacked clips. Besides correcting chroma in debug, in case it is a bug.

edit: Also there seems to be a bug in UV planes with smoothcurve16. It is less red than default smoothcurve. Maybe it is related to dither, who knows...
Can you post the curve that you used? I will try to reproduce the problem...

[Dogway]

#~ SmoothCurve(\
#~ ycurve="0-9;16-30;128-128;233-220;255-255",\
#~ ucurve="0-16;255-240",\
#~ vcurve="0-16;255-240",\
#~ interp=50,smooth=10,show=false,limiter=false)

SmoothCurve16(\
ycurve="0-2304;4096-7680;32768-32768;59648-56320;65535-65535",\
ucurve="0-4096;65535-61440",\
vcurve="0-4096;65535-61440",\
interp=50,smooth=10,show=false,limiter=false)

[LaTo]

#~ SmoothCurve(\
#~ ycurve="0-9;16-30;128-128;233-220;255-255",\
#~ ucurve="0-16;255-240",\
#~ vcurve="0-16;255-240",\
#~ interp=50,smooth=10,show=false,limiter=false)

SmoothCurve16(\
ycurve="0-2304;4096-7680;32768-32768;59648-56320;65535-65535",\
ucurve="0-4096;65535-61440",\
vcurve="0-4096;65535-61440",\
interp=50,smooth=10,show=false,limiter=false)

255 in 16 bit is 65280, so your conversion will never be the same as 8 bit.

If you want exactly the same, add 65280-65280 before 65535-65535.
It works?

PS: Why "Besides correcting chroma in debug, in case it is a bug."? What is the problem?

[Dogway]

Im just doing what the readme suggests:
For example: SmoothCurve("0-255;128-128;255-0") --> SmoothCurve16("0-65535;32768-32768;65535-0")

If I change it to 65280 I get an error: *curve have not a correct synthax!

The debug graph for UV planes is different from yours.
http://i212.photobucket.com/albums/cc35/Dogway/Misc/239.png


yours (http://latoninf.free.fr/d9/SA/compare/NEW.png)

[LaTo]

Im just doing what the readme suggests:
For example: SmoothCurve("0-255;128-128;255-0") --> SmoothCurve16("0-65535;32768-32768;65535-0")

If I change it to 65280 I get an error: *curve have not a correct synthax!
Try:
SmoothCurve16(\
ycurve="0-2304;4096-7680;32768-32768;59648-56320;65280-65280;65535-65535",\
ucurve="0-4096;65535-61440",\
vcurve="0-4096;65535-61440",\
interp=50,smooth=10,show=false,limiter=false)


The debug graph for UV planes is different from yours.
http://i212.photobucket.com/albums/cc35/Dogway/Misc/239.png


yours (http://latoninf.free.fr/d9/SA/compare/NEW.png)
It's the debug histogram of avisynth 2.6.x

[Dogway]

Thank you, but result is the same (in other sources too). Does it work with you?

edit: smoothcurve16 doesn't have any benefit over default smoothcurve, right (quality wise)? I realised I dont need it since after that Im processing in 8b. In any case it's still worth a look on why that happens.

[LaTo]

Thank you, but result is the same (in other sources too). Does it work with you?

Oups, sorry... Try:
SmoothCurve16(\
ycurve="0-2304;4096-7680;32768-32768;59648-56320;65280-65280;65535-65280",\
ucurve="0-4096;65280-61440;65535-61440",\
vcurve="0-4096;65280-61440;65535-61440",\
interp=50,smooth=10,show=false,limiter=false)

edit: smoothcurve16 doesn't have any benefit over default smoothcurve, right (quality wise)? I realised I dont need it since after that Im processing in 8b. In any case it's still worth a look on why that happens.
Yes, it has no benefit if your processing chain is 8bits.

[Dogway]

Oups, sorry... Try:
Are you theorizing, or are you getting instead right results? It doesn't work for me either.
You know the insights of SmoothAdjust so you'll probably want to start matching smoothcurve internal dither algorithm with Dither's one, and start from there for testing, and discard either SmoothAdjust or Dither. Although I have just tested a simple resize with Dither vs Spline36 and chroma is alright, so it doesn't look like its fault. (It could be the way it "records"/deals chroma to LSB, cretindesalpes should have more to say on this...)

By the way, overriden parameter in smoothcurve16 are.... "dither" only? Maybe it would be a good idea to delete that option.

[LaTo]

Are you theorizing, or are you getting instead right results? It doesn't work for me either.
It *should* work, but I don't use 16 bits... So I can't verify.


You know the insights of SmoothAdjust so you'll probably want to start matching smoothcurve internal dither algorithm with Dither's one, and start from there for testing, and discard either SmoothAdjust or Dither. Although I have just tested a simple resize with Dither vs Spline36 and chroma is alright, so it doesn't look like its fault.
I haven't checked Dither's code because I don't care (*joke*) :p
Seriously, I don't think that the problem is the dithering.
(Have you tried with "dither=-1"?)


(It could be the way it "records"/deals chroma to LSB, cretindesalpes should have more to say on this...)
Maybe, in SmoothAdjust I use that:
msb[x] = (BYTE)( smooth[x]>>8 );
lsb[x] = (BYTE)( smooth[x] );
It should be correct...


By the way, overriden parameter in smoothcurve16 are.... "dither" only? Maybe it would be a good idea to delete that option.
:confused:

[Dogway]

Sorry sorry, seems that the last example did work. I don't understand still why but its ok. :p

If I use ditherpost (mandatory) after smoothcurve16 or at the end of the 16b chain for dithering, there's no point on having the "dither" parameter in smoothcurve16, just wondering

[LaTo]

Sorry sorry, seems that the last example did work. I don't understand still why but its ok. :p
No problem, it's great that everything works :)

If I use ditherpost (mandatory) after smoothcurve16, there's no point on having the "dither" parameter in smoothcurve16, just wondering
Yes, you can disable it (unless you have a full 16bits chain with a 16bits display ^^)

[LaTo]

v2.00 beta6:
added SmoothCustom

Todo-list:
- improve debug view
- fix all bugs
Download here: > SmoothAdjust v2.00 beta6 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta6.zip)


SmoothCustom is considered "alpha", I can't test everything alone.
So if some people are motivated, here is what to do:
- find expressions that crash
- find expressions that produce a syntax error
- find expressions that output a false result
- find expressions that work but which should not
:thanks:


PS: All informations about SmoothCustom are in the readme.

[LaTo]

v2.00 beta7:
improved debug view
tweaked smoothing

Todo-list:
- fix all bugs
Download here: > SmoothAdjust v2.00 beta7 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta7.zip)

:devil:

[leeperry]

:thanks: for the new build!

[Dogway]

Thanks LaTo!
Is it possible to implement lsb_in, for reading stacked 16b?
I normally put color correction at the end of the chain, that's why

[LaTo]

Thanks LaTo!
Is it possible to implement lsb_in, for reading stacked 16b?
I normally put color correction at the end of the chain, that's why

Yes it's already implemented...
Simply use SmoothLevels16(), SmoothTweak16(), SmoothCurve16() and SmoothCustom16().
;)

[Dogway]

Yay! Thanks you \(^o^)/

[jmac698]

Hey, this is great, I'll have to test it. Can you add avg and std and atan2 to the functions in smoothcustom?
Even better, correlation :)

[Dogway]

LaTo, since long Ive struggling trying to convert PC values to TV values. Normally this is a workflow:
SmoothLevels(preset="pc2tv",smooth=10,limiter=0)

sat=0.0
Cb=0.0
Cr=-0.0
SmoothCurve(\
ycurve="0-0;16-16;30-32;60-50;116-95;190-150;228-208;236-236;255-255",\
ucurve="0-"+string(128*(-sat))+";"+string(int(128-(128*Cb)))+"-"+string(128+(128*Cb))+";255-"+string(255-128*(-sat))+" ",\
vcurve="0-"+string(128*(-sat))+";"+string(int(128-(128*Cr)))+"-"+string(128+(128*Cr))+";255-"+string(255-128*(-sat))+" ",\
smooth=10,show=true,limiter=false)
Is it possible to do everything in one step inside smoothcurve? What operations should I do to convert the ycurve values to PClevels?

I also observed that the first value must be an integer in order to work...

Another issue is the graphs in the debug view, they change position depending on input values length. It makes it hard to compare 2 different graphs to check the changes.

Thanks for all the hard work.

[atra dies]

Is it wrong to use smoothlevels16 on linear y values?

Blacks wash out much earlier on than in ylevelsg, even before gamma=2 whilst ylevels can go up to 9 with this dark movie. I am trying to replicate ylevels with chroma=0.

smoothlevels16(input_low=0,gamma=1.2,input_high=65535,output_low=0,output_high=65535,chroma=0,lmode=0 or 3,ecurve=1,dither=-1,smooth=0,limiter=0)

[LaTo]

Hey, this is great, I'll have to test it. Can you add avg and std and atan2 to the functions in smoothcustom?
Even better, correlation :)
Yes I will add some functions in the next version.
No problem/bug/crash in SmoothCustom?

I also observed that the first value must be an integer in order to work...
ex: SmoothCurve("a-b;c-d;e-f")
In this expression "a", "c" and "e" must be an integer.


Another issue is the graphs in the debug view, they change position depending on input values length. It makes it hard to compare 2 different graphs to check the changes.
I will add a parameter "to fix" the graph position.


Is it wrong to use smoothlevels16 on linear y values?

Blacks wash out much earlier on than in ylevelsg, even before gamma=2 whilst ylevels can go up to 9 with this dark movie. I am trying to replicate ylevels with chroma=0.
It's because ylevelsS or ylevelsG doesn't follow a linear conversion.
Simply use Lmode=1 or 2 in SmoothLevels for the same behaviour.
On top of that you can add protect=16 (or protect=4096 for 16bits) which protects the black parts.

[Dogway]

Thanks LaTo, by chance wouldn't you know what operations requires converting one value from PC levels to TV levels?

for example in PC levels I want to convert the value of 30 to 50 ("30-50"), what is the equivalent in TV levels?

SmoothCurve(\
ycurve="0-0;30-50;255-255",\
smooth=10,show=true,limiter=false)


SmoothCurve(\
ycurve="0-16;30-x;255-235",\
smooth=10,show=true,limiter=false)

[atra dies]

It's because ylevelsS or ylevelsG doesn't follow a linear conversion.
Simply use Lmode=1 or 2 in SmoothLevels for the same behaviour.
On top of that you can add protect=16 (or protect=4096 for 16bits) which protects the black parts.

Well I tried to replicate that with version beta 5, lmode3 (3 = limit conversion on bright areas (apply conversion @100% at luma=0 & @0% at luma=255)), ecurve 1, and chroma=0 which is why I found the result surprising. Should they have behaved similarly? I didn't want to protect anything cause I added borders later to avoid brightening them. Or is ylevelsg supposed to limit on the dark, not the bright? (going to check it now)

Edit: I think ylevelsg does something similar to lmode 1 with a low ecenter thereby protecting the blacks. Would be nice to know the exact center of the curve.

[leeperry]

hi LaTo, is there anything I'm overlooking here please?

http://thumbnails50.imagebam.com/14598/25a218145975896.jpg (http://www.imagebam.com/image/25a218145975896) http://thumbnails28.imagebam.com/14598/ba61ed145975893.jpg (http://www.imagebam.com/image/ba61ed145975893) http://thumbnails43.imagebam.com/14598/d20570145975894.jpg (http://www.imagebam.com/image/d20570145975894)

It works fine w/ 1.33 DAR, but w/ 1.5(untouched SAR) I get this error msg :(

[LaTo]

hi LaTo, is there anything I'm overlooking here please?

http://thumbnails50.imagebam.com/14598/25a218145975896.jpg (http://www.imagebam.com/image/25a218145975896) http://thumbnails28.imagebam.com/14598/ba61ed145975893.jpg (http://www.imagebam.com/image/ba61ed145975893) http://thumbnails43.imagebam.com/14598/d20570145975894.jpg (http://www.imagebam.com/image/d20570145975894)

It works fine w/ 1.33 DAR, but w/ 1.5(untouched SAR) I get this error msg :(

Maybe because you use multithreading, height[480]/threads[4] = 120

[leeperry]

Ah, you nailed it! Any chance of allowing 120 as a minimum instead of 128? http://forum-images.hardware.fr/images/perso/zytradance.gif

[LaTo]

v2.00 beta8:
added "scale" parameter for debug view
relaxed minimum frame size (128 for AVX & 64 for SSE2)
added sinh, cosh & tanh in SmoothCustom

Todo-list:
- fix all bugs
Download here: > SmoothAdjust v2.00 beta8 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta8.zip)

:)

[leeperry]

I was eagerly hoping for a new build w/ more better colors, but this will do :D

:thanks: for the new build, and especially the lower minimum frame size requirement.

[jmac698]

added sinh, cosh & tanh in SmoothCustom

Great, but could you add avg, std, atan2 at some point, as per my original request :)
avg(a,b)=(a+b)/2, std=standard deviation of the pixels, atan2(a,b) like atn

[LaTo]

Great, but could you add avg, std, atan2 at some point, as per my original request :)
avg(a,b)=(a+b)/2, std=standard deviation of the pixels, atan2(a,b) like atn

The parser doesn't recognize multiple arguments in function, so I can't add these for now.

[Dogway]

Thanks LaTo, by chance wouldn't you know what operations requires converting one value from PC levels to TV levels?

I answer myself, well cretindesalpes gave me the TVtpPC formula, from there I could know the PCtoTV range conversion formula.

TV to PC: ((x-16)/219)*255
PC to TV: ((x*219)/255)+16

So I guess this line (in smoothcontrast):
"0-0;16-16;74-"+string(74-55*contrast)+";128-128;185-"+string(185+55*contrast)+";235-235;255-255"
should be:
"0-0;16-16;71-"+string(71-55*contrast)+";126-126;181-"+string(181+55*contrast)+";236-236;255-255"
?

Does chroma stays the same in TV range?:
"0-"+string(128*(-sat))+";255-"+string(255-128*(-sat))+" "

[Gavino]

Does chroma stays the same in TV range?
Chroma in TV range is 16-240, so the conversion formulas are:
TV to PC: ((x-16)/224)*255
PC to TV: ((x*224)/255)+16

[Dogway]

Thanks Gavino. I know that chroma changes when range conversion. Im refering to the contrast formula in TV range as opposed to the same formula for PC range. Should the above formula be good to go with TV range as well? Im guessing so, but just wanted some confirmation on the codes... I can't match smoothtweak saturation with that code in smoothcontrast

[Dogway]

Ok, since nobody confirmed me anything it's time to disclose the work so you can debug and correct me whatever I did wrong.


function SmoothContrast(clip c, float "contrast", float "sat", string "range", string "local", int "median", bool "lsb",\
int "smooth",int "dither", int "interp", bool "limit", bool "show"){

contrast = default(contrast, 0.0) # [-1.0 to +1.0]
sat = default(sat, contrast) # [-1.0 to +1.0] Saturation. By default contrast is also applied to the UV planes.
range = default(range, "TV") # TV or PC. Luma range of your source, probably TV as SmoothAdjust only accepts yuv
smooth = default(smooth, 10) # same as SmoothAdjust; strength of the smoothing
dither = default(dither, 50) # same as SmoothAdjust; fuzziness of the dither. -1 = off
interp = default(interp, 100) # same as SmoothAdjust; curve interpolation curve.
lsb_in = default(lsb, false) # 16 bits I/O. For using in a 16 bits stacked MSB+LSB chain
limit = default(limit, false) # Clamp the output to 16-235 for luma & 16-240 for chroma (TVRange)
show = default(show, false) # Show debug. Doesn't work when using "local" mode.

#local # "local" allows to focus only on the gamma/saturation of the dark or bright parts of the image.
# \ Use "dark" to process dark areas, or "bright" for bright areas.

m = Defined(median) ? (lsb_in ? median*256 : median) : (range=="tv" ? (lsb_in ? 32256 : 126) : (lsb_in ? 32768 : 128))
mf = m*1.000
# median defines the luma center point of your source to process contrast from,
# \ or the luma threshold where you want to process gamma/sat from in the "local" mode.

loc = Defined(local) ? true : false
loc ? Assert(!show, "Debug view cannot be shown in Local mode") : nop



# Variables

b=range=="tv" ? (lsb_in ? 4096 : 16) : 0
w=range=="tv" ? (lsb_in ? 60416 : 236) : (lsb_in ? 65535 : 256)
Cb=(b+mf)/2
Cw=(w+mf)/2
Chb=(mf-b)/2
Chw=(w-mf)/2
Cbi=int(Cb)
Cwi=int(Cw)


# Strings

no = lsb_in ? nop : "0-0;255-255"
Ytv = lsb_in ? nop : "0-0;16-16;"+string(Cbi)+"-"+string(Cb-Chb*contrast)+";"+string(m)+"-"+string(m)+";"+string(Cwi)+"-"+string(Cw+Chw*contrast)+";235-235;255-255"
Ypc = lsb_in ? nop : "0-0;"+string(Cbi)+"-"+string(Cb-Chb*contrast)+";"+string(m)+"-"+string(m)+";"+string(Cwi)+"-"+string(Cw+Chw*contrast)+";255-255"
UV = lsb_in ? nop : "0-"+string(128*(-sat))+";255-"+string(255-128*(-sat))+" "

no16 = !lsb_in ? nop : "0-0;65280-65280;65535-65280"
Ytv16 = !lsb_in ? nop : "0-0;4096-4096;"+string(Cbi)+"-"+string(Cb-Chb*contrast)+";"+string(m)+"-"+string(m)+";"+string(Cwi)+"-"+string(Cw+Chw*contrast)+";60160-60160;65280-65280;65535-65280"
Ypc16 = !lsb_in ? nop : "0-0;"+string(Cbi)+"-"+string(Cb-Chb*contrast)+";"+string(m)+"-"+string(m)+";"+string(Cwi)+"-"+string(Cw+Chw*contrast)+";65280-65280;65535-65280"
UV16 = !lsb_in ? nop : "0-"+string(32768*(-sat))+";65280-"+string(65280-32768*(-sat))+";65535-"+string(65280-32768*(-sat))+" "

Chroma = sat == 0.0 ? false : true
UV = !Chroma ? (lsb_in ? no16 : no) : (lsb_in ? UV16 : UV)
Ytv = contrast == 0.0 ? (lsb_in ? no16 : no) : (lsb_in ? Ytv16 : Ytv)
Ypc = contrast == 0.0 ? (lsb_in ? no16 : no) : (lsb_in ? Ypc16 : Ypc)


# Color Correction

c
s =
\ (range=="TV") ? ( lsb_in ? SmoothCurve16(Ycurve=Ytv16,Ucurve=UV16,Vcurve=UV16,smooth=0, dither=0, show=show, limiter=limit, interp=interp) :
\ SmoothCurve (Ycurve=Ytv, Ucurve=UV, Vcurve=UV, smooth=smooth,dither=dither,show=show, limiter=limit, interp=interp)) :
\ (range=="PC") ? ( lsb_in ? SmoothCurve16(Ycurve=Ypc16,Ucurve=UV16,Vcurve=UV16,smooth=0, dither=0, show=show, limiter=limit, interp=interp) :
\ SmoothCurve (Ycurve=Ypc, Ucurve=UV, Vcurve=UV, smooth=smooth,dither=dither,show=show, limiter=limit, interp=interp)) :
\ Assert(false, "Unrecognised range: "+string(range))



# Selective Gamma/Saturation Mode

Chroma = Chroma ? 3 : 2
msk = loc ? mt_binarize(lsb_in ? last.ditherpost(mode=6) : c,lsb_in ? m/256 : m,upper=
\ (local=="dark") ? true :
\ (local=="bright") ? false :
\ Assert(false, "Unrecognised Local mode")) : nop

loc ? (lsb_in ? Dither_merge16_8(s,msk,luma=true) : mt_merge(s,msk,U=Chroma,V=Chroma,luma=true)) : s}

[cretindesalpes]

w=range=="tv" ? (lsb_in ? 60416 : 236) : (lsb_in ? 65535 : 256)
TV white is 235.000 (60160 in 16 bits), not 236 or 235.999.
PC white is 255.000 on a 8-bit scale, not 256 or 255.999.

Also, use floating point data for all your intermediate calculations (m, Cb, Cw, Chb, Chw) to avoid accumulating rounding errors.

Regarding the chroma correction, I'm not sure the saturation can be mapped directly on the contrast. Generally, the contrast operation is performed in the RGB colorspace, so you'd need at least different multipliers for the U and V channels, and these would depend on the conversion matrix.

Chroma in TV range is 16-240, so the conversion formulas are:
TV to PC: ((x-16)/224)*255
PC to TV: ((x*224)/255)+16
Not exactly, pure grey should stay grey:
TV to PC: ((x-128)/224)*255+128
PC to TV: (((x-128)*224)/255)+128

[Dogway]

I updated the function.

256 is for the calculations, I still keep the white limit to 255 (changed TV's to 235 tho)
The string for a PC range as I have it now is:
"0-0;64-"+string(64-64*contrast)+";128-128;192-"+string(192+64*contrast)+";255-255"
If I change 256 to 255 then it would become:
"0-0;64-"+string(64-64*contrast)+";128-128;191-"+string(191.5+63.5*contrast)+";255-255"
If this is correct then Id change it.

About the chroma, you are right. It is an RGB thing. It would anyways feel akward to change contrast only on luma.
As for now saturation is processed evenly in all places, unlike contrast where towards the mid point and extremes of the curves are untouched, so there's a mismatch here.
What I just have thought is on creating a diff mask to "get" this contrast luma curve, and mask it to saturation. Saturation strength can be scaled correctly upon MAX saturation,
don't know if this is correct, but it can be a workaround. About matrix, I just know nothing : /
edit: I think I had a mental fart, I tested over photoshop and it seems saturation increases even where luma doesn't change in contrast. So it was correct, maybe as you say due to this being another way of processing saturation (and the only one in avisynth) and not curves in rgb, the strength of it can be different. I don't know about saturation differences on different matrix. This is only be going to be processed on yuv material I/O, but probably you mean whether it is 601 or 709. Maybe that's why I can't match smoothtweak saturation (results are near but not same)


edit: An elegant way to mask out only chroma? (Although I still don't know how to mask out chroma, not this is not related in anything to the contrast thinking; is wrong)

This is the difference mask in 16 bit of original clip vs the contrasted clip

msk=Dither_lutxy8(c.ditherpost(mode=6,u=-128,v=-128),s.ditherpost(mode=6,u=-128,v=-128),yexpr="x 256 * y 256 * - 32768 +")

Im struggling to mask out only the chroma planes over the contrasted clip.
edit: ok, I think I solved it, using the function YToUV() for the second example

Dither_merge16_8(s,msk.ditherpost(mode=6,u=-128,v=-128),luma=true) # This line merges UV but luma plane too
Dither_merge16(s,msk,y=4,u=3,v=3) # This line reads the UV planes of the mask for the chroma merging


BTW LaTo, ecenter has a problem on smoothlevels16, or so it seems, the curve gets a pinch...

[LaTo]

Ok, since nobody confirmed me anything it's time to disclose the work so you can debug and correct me whatever I did wrong.

Sorry I don't have much free time these days due to a new job, I will try to take a look later ;)


BTW LaTo, ecenter has a problem on smoothlevels16, or so it seems, the curve gets a pinch...
Already fixed in the next release!

[LaTo]

v2.00 beta9:
added TVrange parameter
added full decimals support in SmoothCurve
rewritted the parser in SmoothCurve (more robust)
changed defaults in SmoothLevels
fixed a bug with Ecenter in SmoothLevels16
added "pi" constant in SmoothCustom
cleaned the code

Todo-list:
- fix all bugs
Download here: > SmoothAdjust v2.00 beta9 < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00beta9.zip)

This release should be the last one before v2.00 final :cool:

[LaTo]

@Dogway: Here is a corrected version of your SmoothContrast using beta9:

function SmoothContrast( clip c, float "contrast", float "sat", string "range", string "local", int "median", bool "bits16", \
int "smooth", int "dither", int "interp", bool "limit", bool "show" )
{

contrast = default(contrast, 0.0) # [-1.0 to +1.0]
sat = default(sat, contrast) # [-1.0 to +1.0] Saturation. By default contrast is also applied to the UV planes.
range = default(range, "TV") # TV or PC. Luma range of your source, probably TV as SmoothAdjust only accepts yuv
smooth = default(smooth, 100) # same as SmoothAdjust; strength of the smoothing. 0 = off
dither = default(dither, 50) # same as SmoothAdjust; fuzziness of the dither. -1 = off
interp = default(interp, 100) # same as SmoothAdjust; curve interpolation curve. 0 = linear
bits16 = default(bits16, false) # 16 bits I/O. For using in a 16 bits stacked MSB+LSB chain
limit = default(limit, false) # Clamp the output to 16-235 for luma & 16-240 for chroma (TVRange)
show = default(show, false) # Show debug. Doesn't work when using "local" mode.

median = default(median, 128) # median defines the luma center point of your source to process contrast from,
# or the luma threshold where you want to process gamma/sat from in the "local" mode.

local = default(local, "default") # "local" allows to focus only on the gamma/saturation of the dark or bright parts of the image.
# Use "dark" to process dark areas, or "bright" for bright areas.

loc_assert = (local=="default") ? true : (local=="dark") ? true : (local=="bright") ? true : false
Assert(loc_assert, "Unrecognised Local mode")

loc_assert = ( (local=="dark") ? true : (local=="bright") ? true : false ) && ( show ) ? false : true
Assert(loc_assert, "Debug view cannot be shown in Local mode")

ran_assert = (range=="TV") ? true : (range=="PC") ? true : false
Assert(ran_assert, "Unrecognised Range")


# Variables

m = (!bits16) ? float(median) : float(median*256)
b = (!bits16) ? 0 : 0
w = (!bits16) ? 255 : 65280
Cb = (b+m)/2.0
Cw = (w+m)/2.0
Chb = (m-b)/2.0
Chw = (w-m)/2.0


# Strings

no = (!bits16) ? "0-0;255-255"
\ : "0-0;65535-65535"

Y = (!bits16) ? "0-0;"+string(Cb)+"-"+string(Cb-Chb*contrast)+";"+string(m)+"-"+string(m)+";"+string(Cw)+"-"+string(Cw+Chw*contrast)+";255-255"
\ : "0-0;"+string(Cb)+"-"+string(Cb-Chb*contrast)+";"+string(m)+"-"+string(m)+";"+string(Cw)+"-"+string(Cw+Chw*contrast)+";65280-65280;65535-65280"

UV = (!bits16) ? "0-"+string(128*(-sat))+";255-"+string(255-128*(-sat))
\ : "0-"+string(32768*(-sat))+";65280-"+string(65280-32768*(-sat))+";65535-"+string(65280-32768*(-sat))

Y = (contrast==0.0) ? no : Y
UV = (sat ==0.0) ? no : UV


# Color Correction

s = (!bits16) ? c.SmoothCurve ( Ycurve=Y, Ucurve=UV, Vcurve=UV, TVrange=(range=="TV")?2:0, smooth=smooth, dither=dither, show=show, limiter=limit, interp=interp )
\ : c.SmoothCurve16( Ycurve=Y, Ucurve=UV, Vcurve=UV, TVrange=(range=="TV")?2:0, smooth=smooth, dither=dither, show=show, limiter=limit, interp=interp )


# Selective Gamma/Saturation Mode

msk = (local=="dark") ? mt_binarize( (!bits16)?c:c.ditherpost(mode=6), (!bits16)?int(m):int(m/256.0), upper=true )
\ : (local=="bright") ? mt_binarize( (!bits16)?c:c.ditherpost(mode=6), (!bits16)?int(m):int(m/256.0), upper=false )
\ : nop()

return (local=="default") ? s : ( (!bits16) ? c.mt_merge(s, msk, U=(sat!=0.0)?3:2, V=(sat!=0.0)?3:2, luma=true) : c.Dither_merge16_8(s, msk, luma=true) )

}

[leeperry]

muchos :thanks: for the new build!

[Dogway]

Wow thanks, so many things, I appreciate your help. Now it looks much more tidier.
I realised a few things, like that now input value can be decimal(?), and TVrange is now a setting. In the help it says "Convert the expressions to TVrange(16-235/16-240) before applying conversion", does it reinterpret the input values, or it runs a range conversion before the current processing? aka, is it a 1 pass or 2 pass workflow?

I think you missed changing the variables since now its referenced as PC values.
# Variables

m = (!bits16) ? float(median) : float(median*256)
w = (!bits16) ? 255 : 65280
Cb = (m) /2.0
Cw = (w+m)/2.0
Chb = Cb
Chw = (w-m)/2.0

But Im not sure, this was my main question in last post after cretindesalpes reply, for calculations would you use 256 or 255?
Its the difference between using 256:
"0-0;64-"+string(64-64*contrast)+";128-128;192-"+string(192+64*contrast)+";255-255"
or 255:
"0-0;64-"+string(64-64*contrast)+";128-128;191-"+string(191.5+63.5*contrast)+";255-255"

I realise the "local" mode for gamma is not to be used much, that's why I started fiddling with smoothlevels lmode. But the option is still there, for completion, I will warn of its countereffects.

edit: I studied the new TVRange parameter, its hard to understand because it does different things in the different functions. For example in smoothlevels you set tvrange=true, but still the syntax for tvrange inputs must be "16,1.0,235,16,235". About smoothcurve I don't think tvrange=2 does the same I had before. You still process below 16 and above 235 values, and thus the curve also gets affected, unlike smoothlevels where gamma is correctly processed between 16-235 (default syntax). Probably for v2.00 final you could add also an option for HD and SD concerning chroma as cretindesalpes indicated.
http://img849.imageshack.us/img849/728/tvrange2.th.png (http://img849.imageshack.us/img849/728/tvrange2.png) http://img571.imageshack.us/img571/3526/tvrange0.th.png (http://img571.imageshack.us/img571/3526/tvrange0.png)
In this pic the pixel x=563,y=32 which the original luma value is 40 converts to 54 in the first pic, and 59 in the second.

[LaTo]

Wow thanks, so many things, I appreciate your help. Now it looks much more tidier.
I realised a few things, like that now input value can be decimal(?), and TVrange is now a setting. In the help it says "Convert the expressions to TVrange(16-235/16-240) before applying conversion", does it reinterpret the input values, or it runs a range conversion before the current processing? aka, is it a 1 pass or 2 pass workflow?

I think you missed changing the variables since now its referenced as PC values.
# Variables

m = (!bits16) ? float(median) : float(median*256)
w = (!bits16) ? 255 : 65280
Cb = (m) /2.0
Cw = (w+m)/2.0
Chb = Cb
Chw = (w-m)/2.0

But Im not sure, this was my main question in last post after cretindesalpes reply, for calculations would you use 256 or 255?
Its the difference between using 256:
"0-0;64-"+string(64-64*contrast)+";128-128;192-"+string(192+64*contrast)+";255-255"
or 255:
"0-0;64-"+string(64-64*contrast)+";128-128;191-"+string(191.5+63.5*contrast)+";255-255"
Yes, you're right, it's a mistake. You should use 0 & 255 for calculations (and not 16 - 235).

edit: I studied the new TVRange parameter, its hard to understand because it does different things in the different functions. For example in smoothlevels you set tvrange=true, but still the syntax for tvrange inputs must be "16,1.0,235,16,235".
Yes, it's different between functions:
- SmoothLevels: only affects limiting part (see Lmode in readme, last line)
- SmoothTweak: only affects contrast
- SmoothCurve/SmoothCustom: remap the curve/expression to the 16-235 range

About smoothcurve I don't think tvrange=2 does the same I had before. You still process below 16 and above 235 values, and thus the curve also gets affected, unlike smoothlevels where gamma is correctly processed between 16-235 (default syntax).
It's because there is no "one way" of doing this, the only fully correct & safest way is to drop out 0-16 & 235-255 informations (see TVrange=1)
Another way is to leave extra-range pixels as-is. (Work great for gamma adjustement, but most of the time it's a *very big* mistake)
The last way is to interpolate extra-range values from the 16-235 curve, this is the best most of time (see TVrange=2)

http://img849.imageshack.us/img849/728/tvrange2.th.png (http://img849.imageshack.us/img849/728/tvrange2.png) http://img571.imageshack.us/img571/3526/tvrange0.th.png (http://img571.imageshack.us/img571/3526/tvrange0.png) In this pic the pixel x=563,y=32 which the original luma value is 40 converts to 54 in the first pic, and 59 in the second.
Your 1rst curve is wrong, 40-60 are remapped with TVrange in the second curve so it's no longer the same (become 27.95-51.23).
Should be something like: "0-0;16-16;50.35-67.53;235-235;255-255" for the 1rst one.

Probably for v2.00 final you could add also an option for HD and SD concerning chroma as cretindesalpes indicated.
More precisely?

[Dogway]

I understand now, so it seems values get remapped instead of a 2 pass workflow. What is good about it is I can still use the old syntax with 16-16 when I want to precisely tweak the values. I was specially confused on what TVrange does on smoothcurve, now is a bit more clear.

Generally, the contrast operation is performed in the RGB colorspace, so you'd need at least different multipliers for the U and V channels, and these would depend on the conversion matrix.

I think he implied that saturation depends on conversion matrix, so probably chroma has to be treated differently in strength and in U and V whether it is SD, or HD.

Thanks for all, and sorry to bother so much :o


edit:
I fixed a few things like
-Input correction for matching TV values in median
-Default median now is 127.5 (255/2)
-When processing saturation only, a gradual mask is applied now in local mode
-Now 'show' works in local mode, the used mask is shown.
-plus more few little tweaks.

function SmoothContrast( clip c, float "contrast", float "sat", float "median", string "range", string "local", bool "lsb", \
int "smooth", int "dither", int "interp", bool "limit", bool "show" )
{

contrast = default(contrast, 0.0) # [-1.0 to +1.0]
sat = default(sat, contrast) # [-1.0 to +1.0] Saturation. By default contrast is also applied to the UV planes.
range = default(range, "TV") # TV or PC. Luma range of your source, probably TV as SmoothAdjust only accepts yuv
smooth = default(smooth, 20) # same as SmoothAdjust; strength of the smoothing. 0 = off
dither = default(dither, 100) # same as SmoothAdjust; fuzziness of the dither. -1 = off
interp = default(interp, 100) # same as SmoothAdjust; curve interpolation curve. 0 = linear
lsb = default(lsb, false) # 16 bits I/O. For using in a 16 bits stacked MSB+LSB chain
limit = default(limit, false) # Clamp the output to 16-235 for luma & 16-240 for chroma (TVRange)
show = default(show, false) # Show debug. Doesn't work when using "local" mode.

local = default(local, "default") # "local" allows to focus only on the gamma/saturation of the dark or bright parts of the image.
# Use "dark" to process dark areas, or "bright" for bright areas.

median = Defined(median)?(range=="TV" && contrast!= 0.0\
? ((median-16)/219.0)*255:median):127.5# median defines the luma center point of your source to process contrast from,
# or the luma threshold where you want to process gamma/sat from in the "local" mode.


# Error Report

loc_assert = (local=="default") ? true : (local=="dark") ? true : (local=="bright") ? true : false
Assert(loc_assert, "Unrecognised Local mode")

ran_assert = (range=="TV") ? true : (range=="PC") ? true : false
Assert(ran_assert, "Unrecognised Range")


# Variables

m = (!lsb) ? median : median*256
w = (!lsb) ? 255 : 65280
Cb = (m) /2.0
Cw = (w+m)/2.0
Chw = (w-m)/2.0


# Strings

no = (!lsb) ? "0-0;255-255"
\ : "0-0;65535-65535"

Y = (!lsb) ? "0-0;"+string(Cb)+"-"+string(Cb-Cb*contrast)+";"+string(m)+"-"+string(m)+";"+string(Cw)+"-"+string(Cw+Chw*contrast)+";255-255"
\ : "0-0;"+string(Cb)+"-"+string(Cb-Cb*contrast)+";"+string(m)+"-"+string(m)+";"+string(Cw)+"-"+string(Cw+Chw*contrast)+";65280-65280;65535-65280"

UV = (!lsb) ? "0-"+string(127.5*(-sat))+";255-"+string(255-127.5*(-sat))
\ : "0-"+string(32640*(-sat))+";65280-"+string(65280-32640*(-sat))+";65535-"+string(65280-32640*(-sat))

Y = (contrast==0.0) ? no : Y
UV = (sat ==0.0) ? no : UV


# Color Correction

s = (!lsb) ? c.SmoothCurve ( Ycurve=Y, Ucurve=UV, Vcurve=UV, TVrange=(range=="TV")?2:0, smooth=smooth, dither=dither, show=local!="default"?false:show, limiter=limit, interp=interp )
\ : c.SmoothCurve16( Ycurve=Y, Ucurve=UV, Vcurve=UV, TVrange=(range=="TV")?2:0, smooth=smooth, dither=dither, show=local!="default"?false:show, limiter=limit, interp=interp )


# Selective Gamma/Saturation Mode


c16 = local!="default" ? (!lsb ? c : c.ditherpost(mode=6)) : nop

mskstr = local=="dark" ? (range=="TV" ? "x "+string(median)+" > 0 255 x 16 - 255 "+string(median)+" 16 - / * - ?" :
\ "x "+string(median)+" > 0 255 x 255 "+string(median)+" / * - ?") :
\ local=="bright" ? (range=="TV" ? "x "+string(median)+" > 255 x 16 - 255 "+string(median)+" 16 - / * ? " :
\ "x "+string(median)+" > 255 x 255 "+string(median)+" / * ? ") : nop


msk = (local=="dark") ? (contrast!=0.0 ? mt_binarize( c16, (!lsb)?int(m):int(m/256.0), upper=true, U=-128,V=-128) :
\ mt_lut(c16, mskstr,U=-128,V=-128)) :
\ (local=="bright") ? (contrast!=0.0 ? mt_binarize( c16, (!lsb)?int(m):int(m/256.0), upper=false, U=-128,V=-128) :
\ mt_lut(c16, mskstr,U=-128,V=-128)) : nop

local=="default" ? s : (show ? msk.smoothlevels(preset="pc2tv",chroma=0,smooth=0,dither=-1).subtitle("This is 'local' debug 'show' mode\n" + " Shows the mask (as TVrange for display)\n" + " used for the selective Gamma/Saturation",lsp=40,size=12,y=10,x=10)
\ : (!lsb ? c.mt_merge(s, msk, U=(sat!=0.0)?3:2, V=(sat!=0.0)?3:2, luma=true) : c.Dither_merge16_8(s, msk, luma=true)))}

[LaTo]

beta9 has a strange bug. After reload a script in virtual dub it shows an error message in call: SmoothCurve("0-0;128-132;255-237") about incorrect parameter of TVrange. I tried different values, but the message repeats again. Sorry, I cannot use your beta 9, because I need to often reload the script. The error message is annoyed. Beta 8 works fine. I use 2.5.8 MT (2.6 MT is not compatible with Deshaker)

Can you post your script and the exact error message?

What did you do exactly to get this bug? (because I can't reproduce it now)

[LaTo]

The message is: Avisynth open failure: 'TVrange' has not a correct value! [0;1;2].
SetMTMode(5,4)
Import("C:\Soft\Video\bin\HDToolboxCore.avsi")
Import("video\avsi\20110619_14088.avsi")
ClipSource(video=true, audio=true) #reading over dss2()
SetMTMode(2)
PreTrim()
PostTrim()
RangeNEXtoTV() #here is the call of SmoothCurve("0-0;128-132;255-237")

It is an x64 edition, and ICL version of your plugin. I open the script in vdub, make changes in 20110619_14088.avsi in function PreTrim() and reload vdub to see changes (trim unwanted chunks). Just File>Reopen video file, or F2. And I see the message box, close it. And all works fine after, but after F2 I see the message again. I dont know what is the difference between first load of vdub and reload a file, but the message is only when I reload the script. The first open is correct.

Also checked it in x86 version. It works fine.
So the x86 beta9 works? Have you tried with x64 beta9 MSVC?

What is the content of RangeNEXtoTV()?
Try to turn off MT before SmoothCurve, it's internally multi-threaded.

[LaTo]

LaTo, I have different scripts where RangeNEXtoTV() is used. The code from my previous message is one of the batch generated files, where it is used. And I need in multithreading and 64 bit code in other scripts. So I cannot switch to 32 bit and disable MT. Sorry, cannot test it now. I have started a very long processing, that will be finished tomorrow. As completed, I will try to experiment.

The function is simple:
function RangeNEXtoTV(clip c) {
c.SmoothCurve("0-0;128-132;255-237")
}

The error message pointed to this function. Yes, beta9 x86 ICL works without this message box.

OK, so it's only with x64. When you can, use the x64 MSVC version from beta9. It's maybe a compiler bug.

edit: Ok I got it, fixed. Thanks for report!

[sven_x]

I'm currently working on a tool that will allow to
a) generate an overall gradiaton curve from a given Virtualdub Filter Chain
b) simulate that curve with SmoothCurve in RGB color space

The goal is to transfer color adjustments for old films with faded colors that work fairly good in Virtualdub. Old film consists of RGB color layers, that's why a correction of faded colors is easier done in RGB color space.

The first part a) is already working. gradationtestavs.zip (http://www.engon.de/audio/avisynth/gradationtestavs.zip)
http://www.engon.de/audio/vhs4/restauration-example1.jpg
http://www.engon.de/audio/avisynth/gradation_old_film.png
Old film and corrected version in Virtualdub,
The effect of the same filter chain to a grey scale and the overall gradiation curve, computed from this output

Part b) can be acchieved with a combination of separated smoothcurves of R G and B that are merged back into one clip. Doing so you also get a nice combinated RGB gradiation curve with show=true in all three layers.

http://www.engon.de/audio/avisynth/smoothgradiationrgb00.png

Here are my requests:

The process might gain some speed when there will be an option to disable processing of U and V in SmoothCurve, because in this case each of the three instances of smoothcurve will calculate Y only.
It will be easier to reconstruct the gradiation curve a), wenn the SmoothCurve gradiation curve will be displayed with a 4x4 grid, as it is seen in the first image.


Thank you very much

[LaTo]

Here are my requests:

The process might gain some speed when there will be an option to disable processing of U and V in SmoothCurve, because in this case each of the three instances of smoothcurve will calculate Y only.
It will be easier to reconstruct the gradiation curve a), wenn the SmoothCurve gradiation curve will be displayed with a 4x4 grid, as it is seen in the first image.

Thank you very much

1. It's already a feature, only modified planes are processed.
2. Why not, good idea!

[sven_x]

SmoothGradationRGB is a 5 point gradation curve in RGB color space.
It provides a 5-point Gradation curve Lo - P0 - Mid - P1 - Hi with global adjustments for Point 0, Mid and Point 1 and R,G,B offset for each point.
Free adjustment of position and offset for P0 and P1.
You can see all 3 curves blendet into the Y curve diagram when ShowRGB=true (example in previous post).

So the function enables individual settings of Min and Max levels and all kinds of S-Kurves for each Color.

The avisynth script for AvsP has sliders that can adjust a RGB gradation curve and add individual offsets for each color with a second set of sliders.

Here's the Script.
#Input ................................................................................................

#SmoothGradationRGB ................................................................................................
# SmoothGradationRGB is a 5 point gradation curve in RGB color space
# This is a 5-point Gradiation Curve Lo - P0 - Mid - P1 - Hi with global adjustments for Point 0, Mid and Point 1 and R,G,B offset for each point
# Free adjustment of position and RGB offset for P0 and P1.
# you can see all 3 curves blendet into the Y curve diagram when ShowRGB=true
# v0.5

loadplugin("J:\plugins\SmoothAdjust.dll")

[<separator="SmoothGradationRGB">]
po1 = [<"Point 1 lights", 180, 255, 214>] #position of point 1
offs1 = [<"Offset 1 (2)", -32, 32, -5>]
offs1R = [<"Offset 1R (2)", -32, 32, 14>]
offs1G = [<"Offset 1G (2)", -32, 32, -10>]
offs1B = [<"Offset 1B (2)", -32, 32, -3>]

midRGB=[<"MidRGB (0)", -64, 64, 0>]
midR=[<"MidR (0)", -64, 64, -25>]
midG=[<"MidG (0)", -64, 64, 0>]
midB=[<"MidB (0)", -64, 64, 24>]

po0 = [<"Point 0 dark (8)", 0, 75, 64>] #position of point 0
offs0 = [<"Offset 0 (2)", -32, 32, 18>] # y offset for point 0
offs0R = [<"Offset 0R (0)", -32, 32, -8>] # additional yR offset for point 0
offs0G = [<"Offset 0G (2)", -32, 32, -5>]
offs0B = [<"Offset 0B (2)", -32, 32, 10>]

HiR=[<"HiR (255)", 222, 254, 254>] # max level
HiG=[<"HiG (255)", 222, 254, 235>]
HiB=[<"HiB (255)", 222, 254, 254>]
LoR=[<"LoR (0)", 1, 32, 1>] #min level
LoG=[<"LoG (0)", 1, 32, 13>]
LoB=[<"LoB (0)", 1, 32, 1>]

SmoothRGB=[<"SmoothRGB (100)", 0, 200, 0>]

TVrange=[<"InputTVrangeRGB (0)", 0, 2, 0>]
LimiterRGB=select([<"LimiterRGBout (0)", 0, 1, 0>],false,true)
ShowRGB=select([<"Show RGB (0)", 0, 1, 1>],false,true)
OutRGB=select([<"RGB out (on)", 0, 1, 1>],false,true)

converttoRGB

R = ShowRed(pixel_type="YV12") .Scurve(Lo=LoR, po0=po0, offs0=offs0+offs0R, mid=midRGB+midR, po1=po1, offs1=offs1+offs1R, Hi=HiR, limiter=limiterRGB,Show=showRGB,TVrange=TVrange, Smooth=SmoothRGB)
G = ShowGreen(pixel_type="YV12") .Scurve(Lo=LoG, po0=po0, offs0=offs0+offs0G, mid=midRGB+midG, po1=po1, offs1=offs1+offs1G, Hi=HiG, limiter=limiterRGB,Show=showRGB,TVrange=TVrange, Smooth=SmoothRGB)
B = ShowBlue(pixel_type="YV12") .Scurve(Lo=LoB, po0=po0, offs0=offs0+offs0B, mid=midRGB+midB, po1=po1, offs1=offs1+offs1B, Hi=HiB,limiter=limiterRGB,Show=showRGB,TVrange=TVrange, Smooth=SmoothRGB)

last=MergeRGB(R,G,B)
last= (OutRGB==true) ? last : last.ConvertToYv12()
return last#.info()


function Scurve(clip "clip", int "Lo", int "po0", int "offs0", int "mid", int "po1", int "offs1", int "Hi", bool "show", bool "limiter", int "TVrange", int "smooth")
{
# interp=2 bicubic interpolation default
po0 = default(po0, 24)
offs0 = default(offs0, 0)
po1 = default(po1, 230)
offs1 = default(offs1, 0)
Lo = default(Lo, 1) # shift of mid point to dark/lights [-1.0 to +1.0]
mid = default(mid, 0) # shift of mid point to dark/lights [-1.0 to +1.0]
Hi = default(Hi, 1) # shift of mid point to dark/lights [-1.0 to +1.0]

show = default(show, false) # show curve
limiter = default(limiter, false) # clamp to tv levels

x0=string(po0)
y0=string(po0+offs0)
x1=string(po1)
y1=string(po1+offs1)

return clip.SmoothCurve(Ycurve="0-0; "+string(Lo)+"-1; "+string(y0)+"-"+string(x0)+"; "+string(128+mid)+"-128;" + string(y1)+ "-" +string(x1)+"; "+string(Hi)+"-254 ;255-255"\
,Limiter=limiter,show=show,TVrange=TVrange, smooth=smooth)
}

New Version: Version 0.5b (http://www.engon.de/audio/avisynth/SmoothGradiationRGB.avs), added debug mode
Gradationtestavs (http://www.engon.de/audio/avisynth/gradationtestavs.zip) to generate overall gradation curve from a Virtualdub Filter chain

USAGE
1. Reset all R, G and B offsets to 0.
2. Set the overall shape (for instance an S curve that darkens bright areas and lifts shadows).
It may help to change input to grey values to get a better visual impression of the result.
3. Add individual offsets to each point for R, G and B.

See SmoothAdjust readme for the rest of the SmoothCurve options that are used here.

It throws a few exceptions when parameters cross a certain range. LaTo, can you please have a look at this effect?

[LaTo]

It throws a few exceptions when parameters cross a certain range. LaTo, can you please have a look at this effect?
OK, what SmoothCurve's call throws an exception?

[sven_x]

Failure in my script.
It must be checked that the combined offsetsRGB + offset R,G,B will not reach certain limits (not below 0, not above 255, not bigger as the point offsets of point P0 and P1.

[LaTo]

v2.00 prere:
fixed a bug with TVrange
added grid in debug view
Download here: > SmoothAdjust v2.00 prerelease < (http://latoninf.free.fr/d9/SA/SmoothAdjust-v2.00prere.zip)

:cool:

[Dogway]

Thanks for the update!
Could you make for next version limiter=2 be an active parameter? Sometimes I like to add smoothlevels(limiter=2) at the end of my script to save bits for encoding.

Also could you allow ecenter for lmode 2 and 3? So we can choose what darks or what brights we want to bring back?

Also when using show=true in 16 bit version it could possibly be a good idea to stack a black clip below with same height, so we don't need to comment out ditherpost to see the full screen

[TheSkiller]

Sometimes I like to add smoothlevels(limiter=2) at the end of my script to save bits for encoding.
Doesn't AviSynth's internal Limiter() do exactly that? It clips anything that is not in the 16-235 range for luma and 16-240 range for chroma.
Hm, while we're at it, if I use SmoothLevels(preset="pc2tv") does it convert full range input (luma and chroma both 0-255) to 16-240 for chroma and luma to 16-235?

[Dogway]

Thanks TheSkiller, nice to know that, although at the same time Im wondering if x264 trash out of TVrange values when encoding in this range, or is only a display flag.
About SmoothLevels(preset="pc2tv"), yes it converts both, you can turn chroma=0 so only luma is processed.
My concern is when TVrange is slightly off and I want to fine tune it. So I switched to manual mode but:

SmoothLevels(preset="tv2pc")
has a different chroma than:
SmoothLevels16(16,1.0,235,0,255)

edit: no problem : ) tv2pc uses chroma=84 as default

[LaTo]

Thanks for the update!
Could you make for next version limiter=2 be an active parameter? Sometimes I like to add smoothlevels(limiter=2) at the end of my script to save bits for encoding.
As TheSkiller said, use avisynth's Limiter()

Also could you allow ecenter for lmode 2 and 3? So we can choose what darks or what brights we want to bring back?
Use "Lmode=1,BrightSTR=0" for Lmode=2 and "Lmode=1,DarkSTR=0" for Lmode=3.
Like that you can tune Ecenter.

Also when using show=true in 16 bit version it could possibly be a good idea to stack a black clip below with same height, so we don't need to comment out ditherpost to see the full screen
Hum, I don't know... This will add problem for people who doesn't use ditherpost.

[Dogway]

-Yes, I didn't know of Limiter() existence I will use that.
-Yes I compared Lmode 3 with Lmode 1 tweaking ecenter and brightstr and darkstr. But still lmode 3 prevents more brightening on brights than using lmode 1 brightstr=0 and ecenter at 20 for example (which is a very extreme value), check yourself please.. At the moment there is no possiblity to limit dark brightening further down to the darks (same with brights).
-People who don't use ditherpost won't likely use smoothXX16()
These are open suggestions based on daily use so you can improve the plugin

[LaTo]

-Yes I compared Lmode 3 with Lmode 1 tweaking ecenter and brightstr and darkstr. But still lmode 3 prevents more brightening on brights than using lmode 1 brightstr=0 and ecenter at 20 for example (which is a very extreme value), check yourself please.. At the moment there is no possiblity to limit dark brightening further down to the darks (same with brights).
As I said, you can emulate Lmode=2 & 3 with Lmode=1.

Lmode=2 is the same as: "Lmode=1,BrightSTR=0,Ecenter=255"
Lmode=3 is the same as: "Lmode=1,DarkSTR=0,Ecenter=0"

[Dogway]

ah well, that makes sense. So the darkest darks that can be brightened are indeed lmode=3, which equals to ecenter=0 in lmode=1. That means that with lmode=1 from ecenter=0 you can only go "worse", in terms of you can only go up brightening more towards brights, and not the opposite, limiting more the darks, which was my original intention. Not too worried about it, I don't need it in any specific situation, just wondering and suggesting.

[LaTo]

ah well, that makes sense. So the darkest darks that can be brightened are indeed lmode=3, which equals to ecenter=0 in lmode=1. That means that with lmode=1 from ecenter=0 you can only go "worse", in terms of you can only go up brightening more towards brights, and not the opposite, limiting more the darks, which was my original intention. Not too worried about it, I don't need it in any specific situation, just wondering and suggesting.

In this case you should try to play with BrightSTR

[Dogway]

Something like BrightSTR=200 (...)? It looks like it works (limits the brights further). I always had the notion it was a 0-100 parameter.
I was a bit confused because in the debug screen using lmode=3 for example, has different darkstr and ecenter than using its lmode=1 counterpart, although the result is the same. If lmode 2 and 3 are indeed lmode 1 shortcuts, wouldn't make more sense to unify the debug outputs? so probably it is easier to read and understand. Unless lmode 2 and 3 do things lmode 1 can't, that is...
The name is also confusing dark strength instead of dark limiting or something, I always need to look twice to make sure what I am doing. yikes

[LaTo]

v2.00:
added Avisynth 2.6.x support
added Y8, YV411, YV16, YV24 support
added 16bits support with stacked MSB/LSB
added SmoothCustom filter
added TVrange parameter
added AVX optimization

improved smoothing algorithm
improved debug view
improved startup delay
improved speed with smoothing OFF

added decimals support in SmoothCurve
fixed interp scaling in SmoothCurve
changed defaults in SmoothLevels
fixed gamma clamping bug in SmoothLevels

fixed crash with mod4 clip
fixed freeze in debug view
deleted Smode parameter
switched from ICL11 to ICL12
cleaned a lot the code
updated the documentation


Finally, here is the final version 2.00 after more than six months of development. It only contains minors fixes and documentation update since the prerelease.
With version 2.00 the plugin has made ​​a lot of quality, speed and functionality improvement.
It has been a lot of work and I hope this plugin will be useful to many people.

Now I will try to focus a bit on my avisynth scripts to update them a little. Then I will spend my time on other ideas for new filters.
So SmoothAdjust will be put a little aside but I still have some ideas of improvements, no worry.

Also my main PC has died from surges, but fortunately the hard drives and data are intact. I work now with an old mono-core CPU.
This issue gave me the idea to set up possibility to make donations, all the necessary informations are in the zip archive.
If you often use this plugin and you like it, please feel free to consider donating. It's really fast, easy and secure.

This will help me a lot to find time to continue updating and creating plugins during my free time.
In fact after my job change, I now have much less free time, that's why the latest versions of development have been so slow to come out.

The zip archive is in the first post of this thread.
Please feel free to give me your comments and ideas for further development.
Happy Version 2.00 :D


edit: @Dogway: this version will output stacked MSB/LSB clip with show=true in 16 bits filters ;)

[leeperry]

I hope this plugin will be useful to many people.
It is, TYVM for your efforts :cool:

Personally, I'd love a plugin version of GrainFactory3(actually I slightly modified it in order to specify grain patterns) :o

[Dogway]

Thanks for that and the final version.
Maybe for future versions you might want to have a look at saturation (http://forum.doom9.org/showthread.php?p=1526997#post1526997) and probably add Vibrance as in a recent thread to round it up, not that I need it, I already wrapped a vibrance function with lsb support.

For "new" filters what it'd be very very cool if you could have a look at stabilise (http://forum.doom9.org/showthread.php?t=100396&highlight=celstabilise), its a wonder plugin but very old and under-developed. Despite it could not fill your motivation, but asking just in case hehe

[TheSkiller]

It has been a lot of work and I hope this plugin will be useful to many people.For me it absolutely is, I couldn't live without SmoothLevels anymore. :cool:
Thanks for your great efforts on this.

[Yellow_]

hi, I have a 16 point curve in a text file for a LOG to LIN (scale not linear light) adjustment, can I use it with SmoothCurve or SmoothCustom?

[LaTo]

hi, I have a 16 point curve in a text file for a LOG to LIN (scale not linear light) adjustment, can I use it with SmoothCurve or SmoothCustom?

Yes, should be OK.

[Yellow_]

If I understand correctly tools like After Effects map an 8bit source into 32bit, centering 8bit level 0 at 0.5000 in the 0.0000 - 1.0000 range. is this possible with SmoothAdjust?

**EDIT** Sorry to clarify this was for the 16bit stacked functions

[stoffal]

Coming back to post #63 :
Is there some kind of auto mode included in smoothlevels?
Something similar to autolevels?

[kutjong]

What would the syntax look like if I simply want to convert a clip with PC range luma to TV range? Would it be as simple as:

ffvideosource("file.avi")
Smoothlevels(preset="pc2tv")


Input is YV12, btw.

I'm still quite a noob at Avisynth, so please excuse me for such novice questions. :)

[matfra]

Hi Guys,
I would like to know if someone code a function of smoothadjust in AVSP.
Smoothadjust is Reall good. But there is so mutch parameter.
I would be nice to have Slider and in AVSP to test live the effect.

[LaTo]

Hi Guys,
I would like to know if someone code a function of smoothadjust in AVSP.
Smoothadjust is Reall good. But there is so mutch parameter.
I would be nice to have Slider and in AVSP to test live the effect.

A QT-GUI for SmoothAdjust was planned just after v2.00 but I'm tired about this community so I gave up... Too bad it would have been nice.

I will release a new version soon (I hope) with a new plugin. The code is almost finished, just need motivation to end it.

The ultimate release will be after this one, when avisynth 2.6 final will come out. So it might not be before a long time.

[matfra]

I hope you find the motivation to do it.
You are a master of AVISynth

[Yellow_]

Hi Guys,
I would like to know if someone code a function of smoothadjust in AVSP.
Smoothadjust is Reall good. But there is so mutch parameter.
I would be nice to have Slider and in AVSP to test live the effect.

You can define the sliders in avsp for any avsynth functions, plugins, scripts etc:

From avspmod Options -> Avisynth Function Definition

Choose function, plugin or script from the tabs, define sliders, fill in the values.

If you copy paste this into a text file and use the import settings from file option under Avisynth Function Definition, then open a script with some smoothadjust functions in it you should see the sliders for the functions defined below, it's a start anyway, just smoothcurve missing but 16bit versions are there.

[PLUGINS]

SmoothAdjust_SmoothCurve16(
clip,
string Ycurve="0-0;65536-65536" (""),
string Ucurve="0-0;65536-65536" (""),
string Vcurve="0-0;65536-65536" (""),
int interp=100 (0 to 100 by 1),
bool limiter=False,
int TVrange=0 (0 to 2 by 1),
int smooth=100 (0 to 200 by 1),
int dither=50 (-1 to 100 by 1),
int useMT=-1 (-1 to 16 by 1),
int useOPT=-1 (-1 to 2 by 1),
bool show=False,
int screenW=-1 (-1 to 1 by 1),
int screenH=-1 (-1 to 1 by 1),
bool scale=False
)

SmoothAdjust_SmoothCustom16(
clip,
string Yexpr="0-0;65535-65535" (""),
string Uexpr="0-0;65535-65535" (""),
string Vexpr="0-0;65535-65535" (""),
bool limiter=False,
int TVrange=0 (0 to 2 by 1),
int smooth=100 (0 to 200 by 1),
int dither=50 (-1 to 100 by 1),
int useMT=-1 (-1 to 16 by 1),
int useOPT=-1 (-1 to 2 by 1),
bool show=False,
int screenW=-1 (-1 to 1 by 1),
int screenH=-1 (-1 to 1 by 1),
bool scale=False
)

SmoothAdjust_SmoothLevels(
clip,
int input_low=0 (0 to 255 by 1),
float gamma=1.0 (0.0 to 5.0 by 0.1),
int input_high=255 (0 to 255 by 1),
int output_low=0 (0 to 255 by 1),
int output_high=255 (0 to 255 by 1),
int chroma=100 (0 to 200 by 1),
int limiter=0 (0 to 2 by 1),
bool TVrange=False,
string preset="Default" ("fullrange"/ "pc2tv"/ "tv2pc"),
int Lmode=0 (0 to 3 by 1),
int darkSTR=100 (0 to 500 by 1),
int brightSTR=100 (0 to 500 by 1),
int Ecurve=0 (0 to 1 by 1),
int Ecenter=128 (0 to 255 by 1),
int protect=-1 (-1 to 255 by 1),
int smooth=100 (0 to 200 by 1),
int dither=-1 (-1 to 100 by 1),
int useMT=-1 (-1 to 16 by 1),
int useOPT=-1 (-1 to 2 by 1),
bool show=False,
int screenW=-1 (-1 to 1 by 1),
int screenH=-1 (-1 to 1 by 1),
bool scale=True
)

SmoothAdjust_SmoothLevels16(
clip,
int input_low=0 (0 to 65535 by 1),
float gamma=1.0 (0.0 to 10.0 by 0.01),
int input_high=65535 (0 to 65535 by 1),
int output_low=0 (0 to 65535 by 1),
int output_high=65535 (1 to 65535 by 1),
int chroma=100 (0 to 200 by 1),
int limiter=0 (0 to 2 by 1),
bool TVrange=False,
string preset="fullrange" ("fullrange"/ "pc2tv"/ "tv2pc"),
int Lmode=0 (0 to 3 by 1),
int darkSTR=100 (0 to 200 by 1),
int brightSTR=100 (0 to 200 by 1),
int Ecurve=0 (0 to 1 by 1),
int Ecenter=32768 (0 to 65535 by 1),
int protect=-1 (-1 to 65535 by 1),
int smooth=100 (0 to 200 by 1),
int dither=50 (-1 to 100 by 1),
int useMT=-1 (-1 to 16 by 1),
int useOPT=-1 (-1 to 2 by 1),
bool show=False,
int screenW=-1 (-1 to 1 by 1),
int screenH=-1 (-1 to 1 by 1),
bool scale=False
)

SmoothAdjust_SmoothTweak(
clip,
int brightness=0 (-255 to 255 by 1),
float contrast=1.0 (0.0 to 10.0 by 1),
float saturation=1.0 (0.0 to 10.0 by 1),
int hue1=0 (-255 to 255 by 1),
int hue2=0 (-255 to 255 by 1),
bool limiter=False,
bool TVrange=False,
int smooth=100 (0 to 200 by 1),
int dither=50 (-1 to 100 by 1),
int useMT=-1 (-1 to 16 by 1),
int useOPT=-1 (-1 to 2 by 1),
bool show=False,
int screenW=-1 (-1 to 1 by 1),
int screenH=-1 (-1 to 1 by 1),
bool scale=False
)

SmoothAdjust_SmoothTweak16(
clip,
int brightness=0 (0 to 65535 by 1),
float contrast=0.0 (0.0 to 10.0 by 0.1),
float saturation=1.0 (0.0 to 10.0 by 0.1),
int hue1=0 (-65535 to 65535 by 1),
int hue2=0 (-65535 to 65535 by 1),
bool limiter=False,
bool TVrange=False,
int smooth=100 (0 to 200 by 1),
int dither=50 (-1 to 100 by 1),
int useMT=-1 (-1 to 16 by 1),
int useOPT=-1 (-1 to 2 by 1),
bool show=False,
int screenW=-1 (-1 to 1 by 1),
int screenH=-1 (-1 to 1 by 1),
bool scale=False
)

[matfra]

Thanks Yellow,
I knew that is was possible to do it manually. But I just wasnt too sure the parameter for this plugin. Thank you very mutch.
Is there a ( Database ) on the internet where people create the script for all kind of mods in avsp ? It would be useful.

[leeperry]

I'm tired about this community so I gave up... Too bad it would have been nice.

I will release a new version soon (I hope) with a new plugin. The code is almost finished, just need motivation to end it.
Yay, sorry to hear that! To me your filter is as important as madVR or Reclock because it drastically increases the enjoyment I get from using my HTPC :cool:

A new version would be full of win, :thanks:

[leeperry]

Hi LaTo, any news on an updated build by any chance please? I still adore your plugin on CRT/DLP, it's only on LCD that it seems to be fighting against their controller dithering(6bit?) :o

[LaTo]

Hi LaTo, any news on an updated build by any chance please? I still adore your plugin on CRT/DLP, it's only on LCD that it seems to be fighting against their controller dithering(6bit?) :o

A new version is in development, but I don't know when I will release it...

(check your MPs)

[LaTo]

Version 2.50 is almost finished, some features requests before releasing?!?

[Didée]

One thing that would be nice to have: Autolevels, with max.change limiting, and taking the input min/max from a separate analysis clip. Current Autolevels in Coloryuv is too crude / too simple, and not (not always) temporally stable.

AutoLevels(clip, analyse_clip, darklimit, brightlimit)

analyse_clip would be an (optional) user-provided preprocessed clip to take the frame's present min & max values from.
- possibly: spatial smoothing to eliminate stray pixels that are very dark / very bright, but are not relevant.
- possibly: temporal smoothing to make operation temporally stable, i.e. avoiding jumping-around of black level.
-- but that's up to the user.

darklimit & brightlimit are clamping the maximum change. I.e. if darklimit=16,brightlimit=20, then a frame covering [20,230] would be spread to [16,235], but a frame covering [50,200] would be spread to only [50-16,200+20).

TV_range switch to specify wether to spread to [16,235] or to [0,255].


Just a rough outline, all points are open for discussion. :)

What do you think about that? Feasable? Too much work / too little time?

[Kisa_AG]

Version 2.50 is almost finished, some features requests before releasing?!?

Hello LaTo!

It would be interesting to have cross-reference between Y, U and U in SMOOTHCUSTOM.

I mean the possibility to use any of three plans (Y, U, V) in any three expressions (Yexpr, Uexpr, Vexpr).
Lets say, Uexpr=U+5*(Y/255).
Now it's not possible.

[Yellow_]

Version 2.50 is almost finished, some features requests before releasing?!?

Curve Editor?

Detail Level Adjustments ie: image frame separated into say 5 detail levels, Coarse to Fine ability to apply SmoothAdjust adjustments individually to each level to tweak contrast?

Generate contrast, luma and saturation masks, apply SmoothAdjust Curve and Tweak through them. http://goodlight.us/writing/tutorials.html

[ajp_anton]

Version 2.50 is almost finished, some features requests before releasing?!?Custom histogram (as good as it can be simulated with finite bitdepth input).
Give a function between 0 and 1, the filter normalizes it and adjusts the levels.

[LaTo]

One thing that would be nice to have: Autolevels, with max.change limiting, and taking the input min/max from a separate analysis clip.

It was on my to-do list, but I wanted to do everything inside the plugin (no external clip used).
It introduced a lot of work: need to build a robust scene change detector, temporal stabilizing and put aside the not relevant values with spatial smoothing (as you said).
In the end, too much work compared to my free time.

Using an external clip simplifies things a lot. In a first time, why not make a standalone filter that can be integrated later into SmoothAdjust if it is convincing. But this introduces an incompatibility with SmoothTools (in version 2.50) and it bothers me a little.


It would be interesting to have cross-reference between Y, U and U in SMOOTHCUSTOM.
Sorry, this can't be done in SmoothAdjust.


Curve Editor?
I was planning a QT-Gui but too much work for now.


Detail Level Adjustments ie: image frame separated into say 5 detail levels, Coarse to Fine ability to apply SmoothAdjust adjustments individually to each level to tweak contrast?

Generate contrast, luma and saturation masks, apply SmoothAdjust Curve and Tweak through them. http://goodlight.us/writing/tutorials.html
If I understand correctly, all this can be done in an avisynth script :)


Custom histogram (as good as it can be simulated with finite bitdepth input).
Give a function between 0 and 1, the filter normalizes it and adjusts the levels.

I don't really understand, can you elaborate please?

[LaTo]

v2.50:
added SmoothTools
improved SmoothTweak
improved dithering
tweaked memory usage
tweaked multithreading
cleaned various stuff

Finally a new version, many changes have been made since the last one.
So this version should be considered as beta because some bugs may occurs.

Just one more thing, the v2.00 final release have been downloaded nearly 6000 times in 18 months.
That's a lot but I have received only 4 donations, it's less than 0.001%...
Seriously I was expecting a bit more generosity, anyways thanks to donators!

So I don't know if I will still get involved much in this project,
because it does not seem to interest many people in the end.

That is, I stop complaining :)

Don't hesitate to report bugs if you find some and enjoy this release!

[ajp_anton]

I don't really understand, can you elaborate please?You write down a function, for example "1" or "x" or "-x*(x-1)". It will then create a curve that, as closely as possible, makes the new histogram the same shape as the desired function between 0 and 1.
I realize you can't make it exact with discrete values, peaks can only be moved and added but never split up. However, this is compensated with a gap with a width proportional to the peak's height, and dithering should partly combat this (plus the result will look about correct anyway).
I also realize there might be functions that mess up everything, but it's the user's fault if he uses one.

[LaTo]

One thing that would be nice to have: Autolevels, with max.change limiting, and taking the input min/max from a separate analysis clip. Current Autolevels in Coloryuv is too crude / too simple, and not (not always) temporally stable.

AutoLevels(clip, analyse_clip, darklimit, brightlimit)

analyse_clip would be an (optional) user-provided preprocessed clip to take the frame's present min & max values from.
- possibly: spatial smoothing to eliminate stray pixels that are very dark / very bright, but are not relevant.
- possibly: temporal smoothing to make operation temporally stable, i.e. avoiding jumping-around of black level.
-- but that's up to the user.

darklimit & brightlimit are clamping the maximum change. I.e. if darklimit=16,brightlimit=20, then a frame covering [20,230] would be spread to [16,235], but a frame covering [50,200] would be spread to only [50-16,200+20).

TV_range switch to specify wether to spread to [16,235] or to [0,255].


Just a rough outline, all points are open for discussion. :)

What do you think about that? Feasable? Too much work / too little time?
A first try: AutoGain-alpha1 (http://latoninf.free.fr/d9/AutoGain-alpha1.7z) :)

[travolter]

Hi!

Im using these Ylevels settings:

YLevelsg(1,0.65,255,1,255)
YLevelsc(1,0.5,255,1,255)
but I want to remove the banding

can I get same result with smoothlevels?

What smoothlevels settings are the equivalent for:
Ylevelsg
Ylevelsc

I ask because Im testing but I cannt get same results.. maybe Im missing some parameter.

[ganymede]

With version 2.50, my typical use of SmoothCurve always triggers an "Access violation" error.
SmoothCurve(YCurve="0-0;16-16;128-126;255-235")The error is like :
Avisynth: access violation at 0x0001E4D5 in C:\Program Files (x86)\AviSynth 2.5\plugins\SmoothAdjust.dll,
attempting to read from 0x00000000I'm using latest 2.6 MT from SEt (20130309) (http://forum.doom9.org/showthread.php?t=148782), under Win7 professional.
I tried both ICL and MSVC builds of SmoothAdjust.dll (x86 only). Enabling or disabling MT mode (with SetMTMode) doesn't change anything.
With SmoothAdjust-2.0, SmoothCurve is working fine.

[Eluent]

With version 2.50, my typical use of SmoothCurve always triggers an "Access violation" error.
Same thing here.

[LaTo]

With version 2.50, my typical use of SmoothCurve always triggers an "Access violation" error.
SmoothCurve(YCurve="0-0;16-16;128-126;255-235")The error is like :
Avisynth: access violation at 0x0001E4D5 in C:\Program Files (x86)\AviSynth 2.5\plugins\SmoothAdjust.dll,
attempting to read from 0x00000000I'm using latest 2.6 MT from SEt (20130309) (http://forum.doom9.org/showthread.php?t=148782), under Win7 professional.
I tried both ICL and MSVC builds of SmoothAdjust.dll (x86 only). Enabling or disabling MT mode (with SetMTMode) doesn't change anything.
With SmoothAdjust-2.0, SmoothCurve is working fine.

Fixed in next version, stupid last-minute copy-paste :)

[ganymede]

Fixed in next version, stupid last-minute copy-paste :)Thank you LaTo, will be happy to test and report.

[LaTo]

v2.51:
fixed crash in SmoothCurve

And another update of AutoGain: AutoGain-alpha2 (http://latoninf.free.fr/d9/AutoGain-alpha2.7z)

[LaTo]

Hi!

Im using these Ylevels settings:

YLevelsg(1,0.65,255,1,255)
YLevelsc(1,0.5,255,1,255)
but I want to remove the banding

can I get same result with smoothlevels?

What smoothlevels settings are the equivalent for:
Ylevelsg
Ylevelsc

I ask because Im testing but I cannt get same results.. maybe Im missing some parameter.

YLevelsS(gamma=xx) -> SmoothLevels(gamma=xx,Lmode=1,Ecurve=0)

YLevelsG(gamma=xx) -> SmoothLevels(gamma=xx,Lmode=1,Ecurve=1)

But for YLevelsC I don't know, the lut seems *special* :p

[Reel.Deel]

Finally a new version, many changes have been made since the last one.
Thank you very much for the update LaTo. :)

Just one more thing, the v2.00 final release have been downloaded nearly 6000 times in 18 months.
That's a lot but I have received only 4 donations, it's less than 0.001%...
Wow, those numbers are very sad. I hope you get the support you deserve.

And another update of AutoGain: AutoGain-alpha2 (http://latoninf.free.fr/d9/AutoGain-alpha2.7z)
I tried using AutoGain with default setting on a 720*480 source and I get the following error:
VirtualDub Error
---------------------------
Avisynth read error:
Avisynth: illegal instruction at 0x00001AF6 in C:\AutoGain.dll


Alpha1 worked fine with the same script, so I doubt I'm doing something silly.

Also, will AutoGain benefit from 16bit processing? If so, it would be nice to have 16 input/output.

[LaTo]

I tried using AutoGain with default setting on a 720*480 source and I get the following error:

Alpha1 worked fine with the same script, so I doubt I'm doing something silly.

Also, will AutoGain benefit from 16bit processing? If so, it would be nice to have 16 input/output.

Hi! :)

Alpha2 need SSE2 CPU, what is your processor?
16 bits should be easy to add, so maybe in the next version.

[travolter]

thanks alot for the help LaTo :)

SmoothLevels(gamma=xx,Lmode=2,Ecurve=1)
is exactly the same as YlevelsS :)

for YlevelsC Ill continue using the old YlevelsC (it does not add so much banding at all)

[LaTo]

thanks alot for the help LaTo :)

SmoothLevels(gamma=xx,Lmode=2,Ecurve=1)
is exactly the same as YlevelsS :)

for YlevelsC Ill continue using the old YlevelsC (it does not add so much banding at all)

No, in the new version 2.5x it's Lmode=1 (in v2.00 it's Lmode=2).

But if you want exactly the same result, simply translate YLevels expression into SmoothCustom.

[Reel.Deel]

Alpha2 need SSE2 CPU, what is your processor?
I have a Intel Core 2 Quad Q6600 which indeed does support SSE2. Also, I'm on Windows XP SP3, Using Avisynth MT 2012.05.16. (http://forum.doom9.org/showthread.php?t=148782)
16 bits should be easy to add, so maybe in the next version.
Thanks!

[LaTo]

thanks alot for the help LaTo :)

SmoothLevels(gamma=xx,Lmode=2,Ecurve=1)
is exactly the same as YlevelsS :)

for YlevelsC Ill continue using the old YlevelsC (it does not add so much banding at all)

function SmoothYlevels(clip clp,
\ int "input_low", float "gamma", int "input_high",
\ int "output_low", int "output_high",
\ string "mode", int "TVrange", bool "limiter", bool "show")
{
input_low = Default(input_low, 0 )
gamma = Default(gamma, 1.0 )
input_high = Default(input_high, 255 )
output_low = Default(output_low, 0 )
output_high = Default(output_high, 255 )
mode = Default(mode, "Y" )
TVrange = Default(TVrange, 0 )
limiter = Default(limiter, false)
show = Default(show, false)

exprY = "(((((Y-"+string(input_low)+")/("+string(input_high)+"-"+string(input_low)+"))^(1/"+string(gamma)+"))*("+string(output_high)+"-"+string(output_low)+"))+"+string(output_low)+")"
exprG = (gamma>1.0) ? "((("+string(exprY)+"*Y)+(Y*(255-Y)))/255)" : "((("+string(exprY)+"*(255-Y))+(Y*Y))/255)"
exprS = "((("+string(exprY)+"*(sin((Y/162.97466))*255))+(Y*(255-(sin((Y/162.97466))*255))))/255)"
exprC = "((("+string(exprY)+"*(255-(cos((Y/162.97466))*255)))+(Y*(cos((Y/162.97466))*255)))/255)"
expr = (mode == "G") ? exprG : (mode == "S") ? exprS : (mode == "C") ? exprC : exprY

return clp.SmoothCustom(Yexpr=expr,TVrange=TVrange,limiter=limiter,show=show)
}


I have a Intel Core 2 Quad Q6600 which indeed does support SSE2. Also, I'm on Windows XP SP3, Using Avisynth MT 2012.05.16. (http://forum.doom9.org/showthread.php?t=148782)

Thanks!

Strange, I will investigate...

[LaTo]

I tried using AutoGain with default setting on a 720*480 source and I get the following error:

Alpha1 worked fine with the same script, so I doubt I'm doing something silly.
Fixed... Min/Max on integer is SSE4.1 and not SSE2

Re-download alpha2 please, it should work now.

[Reel.Deel]

Fixed... Min/Max on integer is SSE4.1 and not SSE2
Re-download alpha2 please, it should work now.

It works, thanks for the quick fix.

[travolter]

LaTo!!!

SmoothYlevels working like a charm!! the best replacement for the old Ylevels functions ;) Same effect without the banding ;)

Thanks a lot for your help ;)

[ganymede]

v2.51:
fixed crash in SmoothCurve Thank you, problem solved.
BTW, made a donation. Keep up the good work.

[Didée]

AutoGain seems to work pretty good so far. Very promising.
One particular issue/shortcoming (though "my fault"), and a question:

1) Limiting

Using a limit for max. change ist not always sufficient. If a scene has very low global contrast (say: nebula scene, or "black screen with some noise"), then all noise etc. still will be blown up (black screen with almost invisible noise becomes black screen with very visible grey-pixel noise), and in nebula/dust scenes the contrast spread still may be too strong.

Okay, when using the external analyse clip, this can be avoided very easily. I simply add two colored borders to the analyse clip: $000000+[darklimit*n] and $FFFFFF- , "n" typically n=1 or n=2, which will automatically prevent those sorts of unwanted too-strong-spreading.
(In fact, such border-adding is exactly the method I've used in the past to tame-down filters like "ColorYUV" or Anschütz' "AutoLevels".)

I think it's really no problem to take such safety-measures manually on the analyse clip. The question is if something similar should be added to the internal analysing chain? For a good and "failsafe" filter it would be a good idea for sure. It's not difficult, it's just one more number-comparison: after figuring clip's min+max, compare them with the global limits, and take whichever will cause less change. - I'm just not sure what would be the most clever way to parametrize it?
a) One could simply specify a 2nd set of dark+bright limits.
b) One could specify a factor, like my "n" above, to make global limits relative to the existing dark/bright lmits.

(There is also another idea c), but that's a bit more complicated.)


[B]2. Gamma-Limit

Could you elaborate a little what you are doing there at all? Is it somehow similar to auto-gamma in "AutoLevels" of T.Anschütz?

Point is: in some scenes I like it a lot, in other scenes I definetly dislike it. That's a bad situation. ;)

Observation:
- with gamma_limit=[positive], it seems the picture sometimes appears brighter, sometimes it appears darker. I don't understand.
- with gamma_limit=[negative], the picture seems to always appear brighter, and much stronger so.

Also, by accident a found a scene with unexplainable misbehaviour:
a pretty dimmed scene, and with gamma_limt=-12 there was very noticeable brightness fluctuation. Those fluctuation did not appear with gamma_limit>=0, and also not with gamma_limt=-16.


Perhaps it would become more clear if you drop some words on how you are manipulating gamma. :)

[LaTo]

1) Limiting

Using a limit for max. change ist not always sufficient. If a scene has very low global contrast (say: nebula scene, or "black screen with some noise"), then all noise etc. still will be blown up (black screen with almost invisible noise becomes black screen with very visible grey-pixel noise), and in nebula/dust scenes the contrast spread still may be too strong.

Okay, when using the external analyse clip, this can be avoided very easily. I simply add two colored borders to the analyse clip: $000000+[darklimit*n] and $FFFFFF-[brightlimit*n] , "n" typically n=1 or n=2, which will automatically prevent those sorts of unwanted too-strong-spreading.
(In fact, such border-adding is exactly the method I've used in the past to tame-down filters like "ColorYUV" or Anschütz' "AutoLevels".)

I think it's really no problem to take such safety-measures manually on the analyse clip. The question is if something similar should be added to the internal analysing chain? For a good and "failsafe" filter it would be a good idea for sure. It's not difficult, it's just one more number-comparison: after figuring clip's min+max, compare them with the global limits, and take whichever will cause less change. - I'm just not sure what would be the most clever way to parametrize it?
a) One could simply specify a 2nd set of dark+bright limits.
b) One could specify a factor, like my "n" above, to make global limits relative to the existing dark/bright lmits.

(There is also another idea c), but that's a bit more complicated.)

Update for AutoGain: AutoGain-alpha3 (http://latoninf.free.fr/d9/AutoGain-alpha3.7z)

This should solve the 1) of your post. I wait after your review for further improvements.

For 2), I will make another post later. :)

[LaTo]

2. Gamma-Limit

Could you elaborate a little what you are doing there at all? Is it somehow similar to auto-gamma in "AutoLevels" of T.Anschütz?

Point is: in some scenes I like it a lot, in other scenes I definetly dislike it. That's a bad situation. ;)

Observation:
- with gamma_limit=[positive], it seems the picture sometimes appears brighter, sometimes it appears darker. I don't understand.
- with gamma_limit=[negative], the picture seems to always appear brighter, and much stronger so.

Also, by accident a found a scene with unexplainable misbehaviour:
a pretty dimmed scene, and with gamma_limt=-12 there was very noticeable brightness fluctuation. Those fluctuation did not appear with gamma_limit>=0, and also not with gamma_limt=-16.

Another update for AutoGain: AutoGain-alpha4 (http://latoninf.free.fr/d9/AutoGain-alpha4.7z)
Gamma processing was broken since day one, simply inverse 2 instructions and welcome strange result :D

One problem with AutoGain: TemporalSoften isn't very good at scenechange, a small luma variation is visible at each one in my test video.
Please test and report, and if you have a not-too-slow idea to replace TemporalSoften that would be great!

[Didée]

Yes, a simple temporalsoften has a few minor issues. I'm not even toooo concerend about scenechanges ... but the black & white point sometimes still can oscillate by +/-1, which may become actually visible when doing contrast expansion. To this end, I think Anschütz' AutoLevels is a bit more robust. What it does is not t'soften the clip ... it first finds the black+white extrema values, and then does a temporal average on the found extremas.

Regarding the new min/max exclusion values: What exactly are these? Number-of-pixels to exclude? Or rather the percentage to exclude? Or completely different? Maybe I'm a little thick today (little sleep because of start of Formula-1 series in Australia;)), but I can't figure how to use them to advantage. For reasonable results in delicate scenes, need to disable that, and add limiting-borders manually as before.

[LaTo]

Yes, a simple temporalsoften has a few minor issues. I'm not even toooo concerend about scenechanges ... but the black & white point sometimes still can oscillate by +/-1, which may become actually visible when doing contrast expansion. To this end, I think Anschütz' AutoLevels is a bit more robust. What it does is not t'soften the clip ... it first finds the black+white extrema values, and then does a temporal average on the found extremas.

Regarding the new min/max exclusion values: What exactly are these? Number-of-pixels to exclude? Or rather the percentage to exclude? Or completely different? Maybe I'm a little thick today (little sleep because of start of Formula-1 series in Australia;)), but I can't figure how to use them to advantage. For reasonable results in delicate scenes, need to disable that, and add limiting-borders manually as before.

Can you provide a sample? I will do some tests...

[Didée]

Scene of "Pirates of the Caribbean", Fist Movie, in the very beginning, when the ship comes slowly through the fog.

0) Original:
http://thumbnails101.imagebam.com/24378/5fb963243776868.jpg (http://www.imagebam.com/image/5fb963243776868)
- very low contrast, roughly in the middle of the spectrum.


1) Full autolevels without any limiting:
http://thumbnails101.imagebam.com/24378/2d7be5243776856.jpg (http://www.imagebam.com/image/2d7be5243776856)
- Someone call the doctor. ;)



2) Autolevels (alpha2) with dark_limit=32, bright_limit=32:
http://thumbnails101.imagebam.com/24378/6251bb243776836.jpg (http://www.imagebam.com/image/6251bb243776836)
- Less catastrophic, but still it's a catastrophe. (In any case when the pictures are actually running)


Moving on to alpha3.

3) dark_max=32, bright_max=32, dark_min=0, bright_min=0
==> same as 2) above.


4) dark_max=32, bright_max=32, dark_min=31, bright_min=31
==> same as original, no change.


5) left to right: dark_min/bright_min = 4, 8, 16, 20, 24
http://thumbnails107.imagebam.com/24378/08df68243777331.jpg (http://www.imagebam.com/image/08df68243777331) http://thumbnails102.imagebam.com/24378/08c3f1243776650.jpg (http://www.imagebam.com/image/08c3f1243776650) http://thumbnails106.imagebam.com/24378/58db0b243776632.jpg (http://www.imagebam.com/image/58db0b243776632) http://thumbnails108.imagebam.com/24378/5e263d243776609.jpg (http://www.imagebam.com/image/5e263d243776609) http://thumbnails107.imagebam.com/24378/f54565243776624.jpg (http://www.imagebam.com/image/f54565243776624)
==> not what the user wants to have, most probably.

____

6) Add borders of $303030 and $C0C0C0 to analyse clip (In RGB/decimal: 0 + 32*1.5 for dark end, 255 - 32*2.0 for the bright end)
http://thumbnails102.imagebam.com/24378/f91766243776814.jpg (http://www.imagebam.com/image/f91766243776814)
==> Seems most serious to me.

What is happening is that the borders create a safety belt, acting as "do not spread any more than this".
If clip has a very narrow dynamic range: 0 -----------|--|---------- 255

Then this is the "safety belt" by adding a dark and a bright border: 0 ---|-------|--|------|--- 255

If the clip actually does have image data in the usual dark-range and bright range, then the borders simply don't matter.



In short: if there is halfway-dark and halfway-bright in a scene, then it (can) make sense to extend the blackpoint and whitepoint by 20, 30, 40 points, in order to create more contrast.
But if the actual dynamic range is very narrow, then such spreading/limiting is way too strong. Required is another measure, something along the lines of "do not increase the present min/max gamut to more than 200%", or something like that.

[LaTo]

Last try of the week-end: AutoGain-alpha5 (http://latoninf.free.fr/d9/AutoGain-alpha5.7z)

It works much better in my tests :)

[Didée]

Thanks for your time so far. Vast improvements made in short time. :)

(And now I've a whole week for scratching-head how the knobs might be working...) :D

[LaTo]

Any others inputs on AutoGain?

On my test it seems much more stable than ColorYUV and better than Autolevels... but I'd like to have other review :)

[yup]

Any others inputs on Autograin?

On my test it seems much more stable than ColorYUV and better than Autolevels... but I'd like to have other review :)

LaTo!
Can use on interlaced source? Or need frame based?
yup.

[LaTo]

LaTo!
Can use on interlaced source? Or need frame based?
yup.

Yes you can use it like that:

SeparateFields()
AutoGain()
Weave()

[Reel.Deel]

Any others inputs on AutoGain?
On my test it seems much more stable than ColorYUV and better than Autolevels... but I'd like to have other review :)

Hi LaTo, I uploaded the sample (https://www.dropbox.com/s/5xi5mz9w1n0u2xa/Test.7z?m) Didée used for testing. I also have another sample (https://www.dropbox.com/s/p6h85a0pvtv72ap/Test2.7z?m) I uploaded of a concert DVD, I'm thinking all of the frequent lighting conditions might make this a good test sample (might be wrong though :)). Unfortunately the DVD sample has other issues, aliasing, noise, and duplicate frames. Hopefully it helps.

[LaTo]

Update of the week: AutoGain-alpha6 (http://latoninf.free.fr/d9/AutoGain-alpha6.7z) :devil:

A lot of changes in this version, interesting thing to test is "temporal_radius=-1"... Slow but very stable results.
Also i need your opinion between the two different "adjust_mode", test and report which is best...

To increase speed, you can try something like this:
AutoGain( last, external_clip = last.PointResize(last.width/2,last.height/2) )

I wait after inputs :)

[LaTo]

New AutoGain: AutoGain-alpha7 (http://latoninf.free.fr/d9/AutoGain-alpha7.7z), the same but faster :D

[Tempter57]

New AutoGain: AutoGain-alpha7 (http://latoninf.free.fr/d9/AutoGain-alpha7.7z), the same but faster :D
:thanks:
If to set parameter scenechange_threshold inside AutoGain(), script error: AutoGain does not have a named argument "scenechange_threshold"

[Didée]

It's a typo in both alpha6 an alpha7. Use "scenechane_threshold", without 'g'. ;)

I'm regularly playing with the new toy, as far as there is time. Generally things look pretty good, but a few things now & then are puzzling. Need (to find) more time for a proper report.

It is not helping that DGDecodeNV - for me at least - doesn't play nicely with the internal read-ahead. Lots of small slowdowns, sometimes severe. RequestLinear solves the issue ... well it would, if it wouldn't throw a "frame not cached!" exception as soon as I "jump" in the timeline. Bugger. Too much stones on the street for making a quick walk. :rolleyes:

[StainlessS]

"frame not cached!" exception as soon as I "jump" in the timeline. Bugger.

Didée, Would Preroll() from v2.6Alpha4 help, never tried it. (works for Audio & Video).
(or is it DGDecodeNV itself throwing exception).

[LaTo]

Some freezes on my PC too but fully functional. I will add an internal cache system, this should alleviate (salve? sorry for my english...) the source filter ;)

[LaTo]

New AutoGain: AutoGain-alpha8 (http://latoninf.free.fr/d9/AutoGain-alpha8.7z), the same but *really* much faster :)

I wasn't expecting so much speed improvement with an internal cache system, but in my tests:
- 5 times faster with DirectShowSource
- 20 times faster with AVCSource

So I hope that speed gain will be as good with DGDecodeNV (I can't test myself because I haven't a license)

[Didée]

Okay ... overall impression so far: Very, very good. And the new caching system really is a VAST improvement!
Take care of one particular bug/shortcoming (see below), and you have the new king of Auto-Levelling. :)

Regarding old/new gaining mode:
I see there are differences, but can't ultimately tell which I "like more". In dark scenes, the old mode sometimes has a tendency to cause a bit more brightening / better dark-contrast (dark detail better visible). In medium/bright scenes, the new mode seems better in keeping the perceived frame luminance. Old mode instead makes everything darker. In particular if there are any full-white spots in the frame.

What's the mode of operation of old/new gaining? From looking at histograms, it seems that: a) old mode takes the full spektrum, and spreads linearily --> [out_dark,out_bright]. New mode seems to reference a middle point (frame mean luma, or whatever?), and separately spread i) [in_dark,mean]-->[out_dark,mean] and ii) [mean,in_bright]-->[mean,out_bright].
Correct? Is that it, is there any more to it?

Unless someone has better ideas, I would vote for just keeping both methods. Leave the choice up to the user.


Stabilization / scenechange bug:
I've noticed that in some circumstances, the dark/black parts are driven below luma Y=16, i.e. illegal sub-black in case of TV_range=true. It usually occurs when there is any "very bright" content appearing a few frames later, but coming in soft enough so that no scenechange can be detected.

Instead of trading samples, you can easily construct the situation:
vid = whatever
a = vid.trim(0,1000).invert().fadeout(10).invert() # fade-out to White
a + vid.trim(1001,0)
Autogain(temporal_radius=20)

Now inspect the section right before frame 1000. If there are any near-black image parts, they will be driven below (way below!) Y=16.

Unless I misunderstand something, that's a misbehaviour. If this can be corrected, then I think you've made a close-to-perfect filter. :)


Oh, and ... I've [I]not-at-all looked into gamma gaining. It is clear that gamma can be manipulated, but I don't understand how anything "auto" can be done in that regard. I don't like things that I don't understand. ;)

[LaTo]

Regarding old/new gaining mode:
I see there are differences, but can't ultimately tell which I "like more". In dark scenes, the old mode sometimes has a tendency to cause a bit more brightening / better dark-contrast (dark detail better visible). In medium/bright scenes, the new mode seems better in keeping the perceived frame luminance. Old mode instead makes everything darker. In particular if there are any full-white spots in the frame.

What's the mode of operation of old/new gaining? From looking at histograms, it seems that: a) old mode takes the full spektrum, and spreads linearily --> [out_dark,out_bright]. New mode seems to reference a middle point (frame mean luma, or whatever?), and separately spread i) [in_dark,mean]-->[out_dark,mean] and ii) [mean,in_bright]-->[mean,out_bright].
Correct? Is that it, is there any more to it?

Unless someone has better ideas, I would vote for just keeping both methods. Leave the choice up to the user.
All is correct, both have downsides... So I will leave the adjust_mode switch.


Oh, and ... I've [I]not-at-all looked into gamma gaining. It is clear that gamma can be manipulated, but I don't understand how anything "auto" can be done in that regard. I don't like things that I don't understand. ;)
"Auto" things will always fail somewhere :p

Gamma processing is very basic, but I found that result are good 99% of time with a limit value of "1.5".
Basically: apply a gamma curve to remap "mean" value to center of "min"/"max".

So, for example, on very dark scene it will bring up dark detail a bit.


Stabilization / scenechange bug:
I've noticed that in some circumstances, the dark/black parts are driven below luma Y=16, i.e. illegal sub-black in case of TV_range=true. It usually occurs when there is any "very bright" content appearing a few frames later, but coming in soft enough so that no scenechange can be detected.

Instead of trading samples, you can easily construct the situation:
vid = whatever
a = vid.trim(0,1000).invert().fadeout(10).invert() # fade-out to White
a + vid.trim(1001,0)
Autogain(temporal_radius=20)

Now inspect the section right before frame 1000. If there are any near-black image parts, they will be driven below (way below!) Y=16.
Yes this occurs when scenechange's detection fail.
Tell me if this is better: AutoGain-alpha9 (http://latoninf.free.fr/d9/AutoGain-alpha9.7z)

And, did you test a bit temporal_radius=-1?
Also, all default values seems safe to me... What do you think?

In any case, thank you for these detailed reports! :)

[IanB]

Is there source code available for me to peruse, I am interested in why the cache is failing for you.

[LaTo]

Is there source code available for me to peruse, I am interested in why the cache is failing for you.

I sent you a PM.

[LaTo]

I've open a new thread for AutoGain, development and support will continue on the other thread... Thanks!

[LaTo]

New version
v2.55:
added small optimizations

[LaTo]

New version
v2.60:
used new interface for v2.6.x builds

[Kisa_AG]

Hello LaTo!

I need to execute few SmoothAdjust plugins one by one, but I don't want to have additional files like .smt, I want to have everything inside the script.
So please can you tell, if it's possible to keep SmoothTool's .smt file inside the script? Let's say, like a loadable function?
Or should I use 16-bits plugins instead?

[LaTo]

Hello LaTo!

I need to execute few SmoothAdjust plugins one by one, but I don't want to have additional files like .smt, I want to have everything inside the script.
So please can you tell, if it's possible to keep SmoothTool's .smt file inside the script? Let's say, like a loadable function?
Or should I use 16-bits plugins instead?

Sorry you should use 16bits to avoid rounding error between filter or use SmoothTools with external .smt files (which will be higher quality if you are doing several pass to a plane).

[Kisa_AG]

Sorry you should use 16bits to avoid rounding error between filter or use SmoothTools with external .smt files (which will be higher quality if you are doing several pass to a plane).

Hello LaTo!

Thanks for the answer!

I'm just making a gray balance function based on you plugin, that's why I want to have everything inside it.
It works like a Photoshop Curves with Black/White/gray balance picker, so it should be easy to adjust picture lightness range and to remove color cast.
I posted my first version here: http://forum.doom9.org/showthread.php?p=1629321#post1629321
But it looks like it's better to move it to this thread...

[LaTo]

New version:
v2.62:
fixed minor things & bugs
dropped ICL builds support

[Sparktank]

If I may, I'm curious whay ICL builds was dropped.
I've just started using this over internal Tweak() to adjust dark areas only (with little to no effect on present brightness) and find this tool wonderful.

I haven't yet done a full test between the ICL builds and MSVC builds in 2.60, but if the minor fixes in 2.62 are not that critical, would I be better using 2.60 on my Intel environment?
How "minor" of fixes are we talking about 2.62?

Thank you for the work on this tool, really saved the intended quality of movies.

[LaTo]

If I may, I'm curious whay ICL builds was dropped.
I've just started using this over internal Tweak() to adjust dark areas only (with little to no effect on present brightness) and find this tool wonderful.

I haven't yet done a full test between the ICL builds and MSVC builds in 2.60, but if the minor fixes in 2.62 are not that critical, would I be better using 2.60 on my Intel environment?
How "minor" of fixes are we talking about 2.62?

Thank you for the work on this tool, really saved the intended quality of movies.
I no longer have access to an ICL compiler suite since a few months.
So unless someone give me a very generous donation to buy a C++ licence (700~1600$ (http://software.intel.com/en-us/intel-xe-product-comparison)), ICL will never be available in future versions.

[cretindesalpes]

I no longer have access to an ICL compiler suite since a few months.
So unless someone give me a very generous donation to buy a C++ licence (700~1600$ (http://software.intel.com/en-us/intel-xe-product-comparison)), ICL will never be available in future versions.

Maybe I’m dumb (or not a good consumer), but instead of paying this huge amount of money, couldn’t someone else with an access to ICL compile the source code? I’m pretty sure there’s a lot of people here who could do that.

[LaTo]

Maybe I’m dumb (or not a good consumer), but instead of paying this huge amount of money, couldn’t someone else with an access to ICL compile the source code? I’m pretty sure there’s a lot of people here who could do that.
No because I don't want to be dependent on someone for each release of new version (and I can't test anything).

Moreover v2.62 with micro opt is nearly as fast as v2.60 ICL, so... :)

[Sparktank]

Moreover v2.62 with micro opt is nearly as fast as v2.60 ICL, so... :)

I was actually just doing a test last night on a full blu-ray remux.
I noticed the two shared the same min/max ranges. :D

So for me, I can do without the ICL builds since the newest version (and future versions) will provide bug fixes and (possibly) newer optimizations. ;)

[mastrboy]

I no longer have access to an ICL compiler suite since a few months.
So unless someone give me a very generous donation to buy a C++ licence (700~1600$ (http://software.intel.com/en-us/intel-xe-product-comparison)), ICL will never be available in future versions.

You can get a free license for non-commercial development:
http://software.intel.com/en-us/intel-education-offerings#pid-2460-93

"Free C++ Tools. If you are a current student and not paid/compensated for software development, the products below are currently freely available under the non-commercial license for your use. Please select a product to initiate the download process:
Intel® C++ Studio XE for Windows*
Includes Intel® C++ Composer XE, Intel® VTune™ Amplifier XE, Intel® Inspector XE, Intel® Advisor XE
https://registrationcenter.intel.com/RegCenter/StuForm.aspx?ProductID=1825 "

[LaTo]

You can get a free license for non-commercial development:
http://software.intel.com/en-us/intel-education-offerings#pid-2460-93

"Free C++ Tools. If you are a current student AND not paid/compensated for software development, the products below are currently freely available under the non-commercial license for your use. Please select a product to initiate the download process:
Intel® C++ Studio XE for Windows*
Includes Intel® C++ Composer XE, Intel® VTune™ Amplifier XE, Intel® Inspector XE, Intel® Advisor XE
https://registrationcenter.intel.com/RegCenter/StuForm.aspx?ProductID=1825 "
From your download link:
I am a full or part-time matriculated student of a higher education institution defined as a public or private, vocational school, correspondence school, junior college, college or university.

That's great but I'm not student anymore...
Anyway thanks for others, this could help them a lot :)

[lansing]

Hi LaTo, i'm trying to color correct my videos based on a reference, i was able to achieve some result with the cymk filter in virtualdub, but the main problem was the original red color would always went up and changed to orange when everything else matched up.

I've seen that SmoothCurve can do color correction with a limiter, so i thought it would be suited for my problem, but right now i'm having a hard time learning how to use it.

Here's the comparison between the reference and the same frame from my videos:

http://imageshack.us/a/img801/706/8sbp.jpg http://imageshack.us/a/img10/1086/1ibx.png

http://imageshack.us/a/img35/8672/3rxe.jpg http://imageshack.us/a/img35/2270/ednd.png

http://imageshack.us/a/img69/406/2mjv.jpg http://imageshack.us/a/img853/371/vxhd.png

how do i even get started with this?

[LaTo]

v2.80:
used new C++11 features
rewritten multi-threading (native)
speed optimization (40% faster)
exception-safe code
added a high quality interpolation mode
changed some parameter names
fixed bugs in SmoothTools parser

Big update :)

Please feel free to report any bugs and problems...

[Sparktank]

:D thanks for huge update! Looking forward to testing it out.

[mandarinka]

Ooooh, nice. Thanks!

[leeperry]

If only you could make a PS script version so it could be used in 16bit with mVR :D

[TheSkiller]

Thanks for the update, but somehow I am unable to use the new 2.80 here. :(
Upon loading the script, trying to load 2.6 x86 version, I get

LoadPlugin: unable to load "SmoothAdjust.dll", error=0x7f


I use AviSynth 2.6 (build Sep 13 2011) and SEt's MT (probably not the latest).


I also tried the 2.5 plugin version, same error.

[StainlessS]

Try dependency walker to establish problem, missing module usually 0x7e (0x7f probably related error).
http://www.dependencywalker.com/

EDIT: Looks like dll not exporting a function, 0x7f == ERROR_PROC_NOT_FOUND.
check out dll with dependency walker.

EDIT: I had a look at it in dependency walker, dont see any obvious problems.

[LaTo]

Thanks for the update, but somehow I am unable to use the new 2.80 here. :(
Upon loading the script, trying to load 2.6 x86 version, I get

LoadPlugin: unable to load "SmoothAdjust.dll", error=0x7f


I use AviSynth 2.6 (build Sep 13 2011) and SEt's MT (probably not the latest).


I also tried the 2.5 plugin version, same error.
Avs 2.6 version need "AviSynth 2.6.0 Alpha4 [Jan 14th, 2013]" (your version is outdated).
Avs 2.5 version can only be used with "Avisynth 2.5.8". MT build are not officially supported.

Please report here if it is working or not. (Anyone else have this problem ?)

[TheSkiller]

Alright, so I downloaded and installed vanilla "AVS 2.6.0 Alpha 4 [130114]" from SourceForge and version() now shows Jan 14 2013.
No MT, and plugins directory empty (except for the plugins the installer puts there). Still the same error. All the earlier versions of SmoothAdjust worked for me no problem at all.


Opening SmoothAdjust.dll (2.6 x86) in Dependency Walker I instantly get an error report.


Module EFSADU.DLL
Error opening file. The System cannot find the requested file (2).



Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.


:(

[LaTo]

Opening SmoothAdjust.dll (2.6 x86) in Dependency Walker I instantly get an error report.
:(

Module EFSADU.DLL is about "Encrypting File System", nothing to do with SmoothAdjust.

Maybe a VS2013 bug, is your windows version XP or lower?

[LaTo]

I have just opened the .dll in dependency walker, wtf are all these loaded dll...
I need to investigate a bit why so much useless dll are loaded.

edit: GetSystemMetrics is the culprit

[TheSkiller]

My OS is Windows XP indeed.

All the earlier versions of SmoothAdjust worked for me no problem at all.
More precisely, what I mean is, 2.60 was the last version that worked for me (I missed 2.62).

[LaTo]

My OS is Windows XP indeed.


More precisely, what I mean is, 2.60 was the last version that worked for me (I missed 2.62).

Is this working: SmoothAdjust-Test.7z (http://latoninf.free.fr/d9/SmoothAdjust-Test.7z) ?

Try it on vanilla 2.6.0a4 please :)

[TheSkiller]

Tested with vanilla 2.6.0a4, still no success.
The error code has changed to 0x45a.

[LaTo]

Tested with vanilla 2.6.0a4, still no success.
The error code has changed to 0x45a.
Strange, it is working on my old XP machine.
Your XP has SP3 and is up-to-date?

[TheSkiller]

It's with SP2, I never really bothered with SP3. Oh well, maybe I should...

But why does it suddenly not work anymore? It used to be so simple. :p

[LaTo]

It's with SP2, I never really bothered with SP3. Oh well, maybe I should...

But why does it suddenly not work anymore? It used to be so simple. :p

It's because VS 2012 & 2013 requires SP3 on windows XP (older version was compiled with VS2010).

[Gavino]

Are the older versions archived somewhere, LaTo?
Only the latest one appears to be available on your website.

[LaTo]

v2.85:
fixed bugs inside multi-threading code
removed user32 dependency
added AVX2 detection (for future opt)

[LaTo]

Are the older versions archived somewhere, LaTo?
Only the latest one appears to be available on your website.
I uploaded the old v2.62 version for those who need it (and v1.02 for AutoGain).
Partial support for Windows XP is a pity but I need VS2013 for C++11 features.
Anyway this is a really bad idea to keep an XP not-updated... So in the end this is a good thing :)

[Gavino]

I uploaded the old v2.62 version for those who need it (and v1.02 for AutoGain).
Thanks, LaTo.
Any chance you could put the last ICL-compiled versions up too?
I lost all my plugins in a recent disk crash and like to keep various versions around for reference.

[LaTo]

v2.90:
fixed possible freeze in MT code
added explicit error messages

[LaTo]

Thanks, LaTo.
Any chance you could put the last ICL-compiled versions up too?
I lost all my plugins in a recent disk crash and like to keep various versions around for reference.
Sorry I don't have these anymore (but these builds have no interest, new versions are considerably better)

[leeperry]

Hi LaTo, now that I finally moved to LCD displays(after decades of DLP & CRT), I'm trying this plugin for TV>PC conversion again and it still looks as good as it did before :)

But why did you remove the "smooth" argument? IIRC it drastically lowered CPU usage, I use it in realtime in ffdshow.

And what kind of dithering do you use again? Floyd-Steinberg IIRC?

:thanks:

[LaTo]

v2.95:
fixed minor things
tweaked multi-threading code

[SamKook]

Is there a way to get the same histogram as the ones in debug view to be displayed like avisynth own histogram function?
So basically only having one histogram to the right of the output video and not have the input video+histogram.
The options could still be displayed on the right of it since it's easy enough to crop them if not needed.

The dim graph on it is very useful for fading text and can't be achieved with avisynth histogram(as far as I could find), but the debug view is taking way too much screen space for my taste and makes working with other stuff open at the same time pretty hard.

[SamKook]

I seem to have found a bug in the latest version.

When using a crop at the same time as smoothCurve, there's an avisynth read error: "SmoothAdjust: Invalid memory alignment" when trying to play the script(which display no picture when paused) and if setmtmode is enabled, it crashes when trying to load the script.

I'm using SEt's release of AvisynthMT from 2013-09-28(but I also tried with the one from 2013-03-09 and the official alpha5 release with the same result) and the following script:

ffvideosource("D:\_1enc_\test_xvid.avi")

Crop(6, 0, -6, -0)

SmoothCurve(Ycurve="0-2;255-235", HQ=true)
I tried with an mp4 with h264 and also tried DGDecode_mpeg2source with a DVD source and it doesn't make a difference. Removing the HQ option also doesn't change anything.

If I comment either the crop or smoothcurve, it works perfectly fine.
I was previously using v2.00 which worked fine in this scenario so I'm not sure when the behavior started to occur since I didn't try any in between the 2.

[LaTo]

Add align=true in the Crop() call.

[SamKook]

Thanks, it works now.

The error message makes a lot more sense when you know crop has an align parameter.

Is there any particular reason why it's mandatory now?

[LaTo]

Thanks, it works now.

The error message makes a lot more sense when you know crop has an align parameter.

Is there any particular reason why it's mandatory now?

It's because of speed optimization (post-v2.62 versions run 1.5x faster)

[Gavino]

That's the first time I have seen a plugin insist on aligned crops being used. It's better than crashing with unaligned (as some have done), but normally you would expect this to be supported as it's 'legal' Avisynth input.

[LaTo]

That's the first time I have seen a plugin insist on aligned crops being used. It's better than crashing with unaligned (as some have done), but normally you would expect this to be supported as it's 'legal' Avisynth input.
Yes it was planned, but I am tired and I have to finish small other things prior to release the new version.
Using NewVideoFrame(vi, 16 or 32) and BitBlit on unaligned frame is a good practice?

I remember an old post where I read that chroma planes could be aligned at half the requested alignment and that values above 16 are silently ignored?!?

[ARDA]

That's the first time I have seen a plugin insist on aligned crops being used. It's better than crashing with
unaligned (as some have done), but normally you would expect this to be supported as it's 'legal' Avisynth input.


That concept was discussed here
http://forum.doom9.org/showthread.php?p=1648026#post1648026
and followed here
http://forum.doom9.org/showthread.php?p=1648644#post1648644


I remember an old post where I read that chroma planes could be aligned at half the requested alignment and that
values above 16 are silently ignored?!?

If I am not wrong, not anymore.

[leeperry]

Still thoroughly impressed by SmoothLevels(preset="tv2pc",HQ=true) in realtime :cool:

But I can barely run it on 720p24 with my Q9450@3.5Ghz, so is 1080p hopeless?

This would give me an excuse to buy a newer CPU, but apparently even a 4770K isn't clearly >2.25(1080p/720p) times faster than a 8*400 QX9770(slightly slower than my 8*438 3.5Ghz Q9450): http://www.anandtech.com/bench/product/48?vs=836

It's pretty striking how GPU's performance has drastically improved but not really CPU's apparently? And I'm not shelling out $1K(with the mobo and a beefier PSU) on a 6/8 cores CPU :D

humm: http://www.pcworld.com/article/2030005/why-moores-law-not-mobility-is-killing-the-pc.html
performance is increasing at just 10 percent per year for desktops

[HOB]

Hello LaTo
Thank you for giving me the opportunity to try out SmoothAdjust, I'm new to this aspect of video control and I've not been able to use SmoothAdjust often enough to feel conversant on the subject except at the most basic level, needless to say I'm enjoying learning about your effort and how to use it.

I came across a problem trying to update to the latest version, v2.95. My virus software, Norton from Symantec, flags the smoothadjust.dll file as a security risk. It sees a risk ONLY with the x86 files and not the x64 files. Norton detects a Cloud.7.F risk which make me wonder if that file is somehow accessing some form of the "cloud" in some way?

Here is a screen grab of the Norton Security History:

http://i43.tinypic.com/2z81dus.jpg

Are you using the "cloud" in some way or is this a "false positive" on Norton's part? In any event can you suggest a way to update?

Thanks again LaTo

[StainlessS]

I uploaded the 2.6 x86 dll to VirusTotal.com where was scanned by 49 antivirus products where 3 of them identified as suspicious.
(Norton not amongst the anitvirus products, presumably Norton no longer thought worthy).

These are results from those 3 AV products:-

AV-Product Identified As Date of AV DBase update

Bkav HW32.CDB.D512 20131210
CMC Trojan.Win32.VBKrypt!O 20131202
McAfee-GW-Edition Heuristic.BehavesLike.Win32.Suspicious-BAY.G 20131211


I think you can ignore Norton and above, but would suggest submitting false +ve to Norton.

can you suggest a way to update?

You could un-quarantine (but when you move dll it will likely fire another quarantine).

[HOB]

Thanks for the feedback StainlessS, I appreciate your effort in uploading the file to VirusTotal.com.

I'm inclined to un-quarantine the file myself. I'm NOT that familiar with the "cloud", other than I will NOT update my Photoshop CS6 to the CC version…EVER! LOL…they lost a LONG TIME customer. I thought that there might be some legitimate reason for LaTo to add some kind of cloud access to the DLL in question, which would eliminate it as a threat so I hope I'm able to get a response sometime in the future.

Norton has quarantined .exe files from more than a few of the programs I own, so I'm quite familiar on how 2 un-quarantine a file. ;-)

[StainlessS]

The term 'Cloud' could mean anything in the suspected malware name.

I do suggest that you submit/upload as false +ve to Norton so that they can examine it in detail and remove from next dbase update
and no longer bother you.

Some time ago, I posted a VB program on D9 which showed up as some kind of malware, it turned out to be a sequence of (about 8)
buttons on a dialog box that were all identical with exception of vertical position on the form, my antivirus interpreted this slightly
different but repeated data sequence as some kind of data factory, eg virus mutating code. Rearranging the button order placated
daft AV and halted the false +ve's. I'm guessing that Norton is just being a panic merchant and the weight of numbers from VirusTotal
gives a better indication.

EDIT: I also submitted to http://virusscan.jotti.org/en as well as https://www.virustotal.com/ and 3 AV products there out of about 29 ID'ed as suspicious.

[HOB]

Just submitted the file to Norton...I'll let you know the outcome...if any?

[LaTo]

SmoothAdjust uses nothing from the network at all... This is simply a false alarm from Norton, if you download the file from this thread you will be safe.

[HOB]

Thanks for your response LaTo, it's as I suspected a false alarm from Norton NOT a problem with your efforts.

[cybersharky]

Add align=true in the Crop() call.

Thanks, just had same issue today.

[cybersharky]

edit not needed

[ronnylov]

Hi!

I am trying to use SmoothAdjust on Linux with wine. With an old version 2.00 beta8 I had on my hard drive everything works.
With latest version v2.95 it does not work (virtualdub says unknown avisynth error opening frame or something like that).

Now I want to find out latest version that works but can I download older versions somewhere?
Maybre there are some windows system file needed for newer versions that are missing when I use wine on Linux?

EDIT: Found this on previous thread page.
I uploaded the old v2.62 version for those who need it (and v1.02 for AutoGain).
Partial support for Windows XP is a pity but I need VS2013 for C++11 features.
Anyway this is a really bad idea to keep an XP not-updated... So in the end this is a good thing
Any links to these files?

[LaTo]

v3.00:
dropped Avs v2.5.x support
added AVX2 code (10% faster)
modified plugin to be thread-safe (MT_NICE_FILTER)
Update :)

[LaTo]

Quoted from AutoAdjust's thread:

Thank you for your bug report, but unfortunately I can't do anything with so little information.

I need these:

- Windows version
- Processor/CPU model
- Exact Avisynth version
- Precise error message
- Crash where? At startup? In the clip? At the end?
- Entire used script
- Properties of the video, or better, a short sample


So this is the last time I write this, the next incomplete bug reports will be simply ignored.
(Nothing personal, but it is always the same thing and I don't have enough free time to explore hypothetical bugs)

:devil:

[TheSkiller]

Just wanted to note, SmoothAdjust now does load again on my Windows XP SP2 machine. :confused: :)
I didn't change anything. This is not new to 3.0 though, it started working again with version 2.90 if I remember correctly.

[LaTo]

Just wanted to note, SmoothAdjust now does load again on my Windows XP SP2 machine. :confused: :)
I didn't change anything. This is not new to 3.0 though, it started working again with version 2.90 if I remember correctly.

Yes the compiler doesn't support WinXP before SP3... I can't do anything, use the older version :)

[TheSkiller]

I'm not sure you understand me.^^
I'm currently using version 3.00 with Win XP SP2 no problems at all. It does load and work even though there's no SP3 installed which is great. :)

[LaTo]

I'm not sure you understand me.^^
I'm currently using version 3.00 with Win XP SP2 no problems at all. It does load and work even though there's no SP3 installed which is great. :)

It seems I was tired... :D
I don't know why it's working now, but that's great!

[killerteengohan]

This is a great filter and I really like it.

[Reel.Deel]

Hi LaTo, I was wondering how can I convert your SmoothYLevels function to work on 16-bit content? Change all 255's to 65535? But how about the other numbers (162.97466)?

function SmoothYlevels(clip clp,
\ int "input_low", float "gamma", int "input_high",
\ int "output_low", int "output_high",
\ string "mode", int "TVrange", bool "limiter", bool "show")
{
input_low = Default(input_low, 0 )
gamma = Default(gamma, 1.0 )
input_high = Default(input_high, 255 )
output_low = Default(output_low, 0 )
output_high = Default(output_high, 255 )
mode = Default(mode, "Y" )
TVrange = Default(TVrange, 0 )
limiter = Default(limiter, false)
show = Default(show, false)

exprY = "(((((Y-"+string(input_low)+")/("+string(input_high)+"-"+string(input_low)+"))^(1/"+string(gamma)+"))*("+string(output_high)+"-"+string(output_low)+"))+"+string(output_low)+")"
exprG = (gamma>1.0) ? "((("+string(exprY)+"*Y)+(Y*(255-Y)))/255)" : "((("+string(exprY)+"*(255-Y))+(Y*Y))/255)"
exprS = "((("+string(exprY)+"*(sin((Y/162.97466))*255))+(Y*(255-(sin((Y/162.97466))*255))))/255)"
exprC = "((("+string(exprY)+"*(255-(cos((Y/162.97466))*255)))+(Y*(cos((Y/162.97466))*255)))/255)"
expr = (mode == "G") ? exprG : (mode == "S") ? exprS : (mode == "C") ? exprC : exprY

return clp.SmoothCustom(Yexpr=expr,TVrange=TVrange,limiter=limiter,show=show)
}

[StainlessS]

Reel.Deel,
Quick answer, just leave that number as it is and try it out, LaTo should (I think) confirm.

EDIT:
OOps, Above is RUBBISH.
Perhaps 65535 should be 65280 (255 * 256), and 162.97466 should be 41721.51296 (162.97466 *256.0).

[Reel.Deel]

I tried just switching SmoothCustom to SmoothCustom16 and leaving the rest as is but with SmoothYLevels(gamma=1.1) the result is different (darker).

Edit: StainlessS: I had 65280 in my previous post but changed it to 65535 since I wasn't sure.

[StainlessS]

Prev post fixed, Not sure but I think 16 bit max is 255 *256 (ie $FF00).

[StainlessS]

Perhaps: (max is I think $FF00 in Stack16),

If max is 65280 (255*256 ie $FF00) then

65280 (255 * 256), and 162.97466 should be 41721.51296 (162.97466 *256.0).

If max is 65535 (255*257 ie $FFFF) then

65535 (255 * 257), and 162.97466 should be 41884.48762 (162.97466 *257.0).

[Reel.Deel]

Ok, due to this comment I decided to go with 65280 and 41721.51296 as suggested by StainlessS. Visually it looks identical to the original SmoothYLevels (http://forum.doom9.org/showpost.php?p=1619975&postcount=355). (I hope it's correct)
255 in 16 bit is 65280, so your conversion will never be the same as 8 bit.


function SmoothYlevels16(clip clp,
\ int "input_low", float "gamma", int "input_high",
\ int "output_low", int "output_high",
\ string "mode", int "TVrange", bool "limiter", bool "show")
{
input_low = Default(input_low, 0 )
gamma = Default(gamma, 1.0 )
input_high = Default(input_high, 65280 )
output_low = Default(output_low, 0 )
output_high = Default(output_high, 65280 )
mode = Default(mode, "Y" )
TVrange = Default(TVrange, 0 )
limiter = Default(limiter, false )
show = Default(show, false )

exprY = "(((((Y-"+string(input_low)+")/("+string(input_high)+"-"+string(input_low)+"))^(1/"+string(gamma)+"))*("+string(output_high)+"-"+string(output_low)+"))+"+string(output_low)+")"
exprG = (gamma>1.0) ? "((("+string(exprY)+"*Y)+(Y*(65280-Y)))/65280)" : "((("+string(exprY)+"*(65280-Y))+(Y*Y))/65280)"
exprS = "((("+string(exprY)+"*(sin((Y/41721.51296))*65280))+(Y*(65280-(sin((Y/41721.51296))*65280))))/65280)"
exprC = "((("+string(exprY)+"*(65280-(cos((Y/41721.51296))*65280)))+(Y*(cos((Y/41721.51296))*65280)))/65280)"
expr = (mode == "G") ? exprG : (mode == "S") ? exprS : (mode == "C") ? exprC : exprY

return clp.SmoothCustom16(Yexpr=expr,TVrange=TVrange,limiter=limiter,debug=show) # changed "show" to "debug" to be in compliance with the latest SmoothAdjust
}

[LaTo]

v3.20:
updated for Avs v2.6.0 final
fixed AVX2 crash with Win7 without SP1
Despite ongoing events in my country, life must go on...
This small update was already planned, so here it is!

[LouieChuckyMerry]

Hi LaTo, and thank you very much for SmoothAdjust :) . As I was poking through the ReadMe I came across, under IX. SMOOTHLEVELS - LIMITING SETTINGS :

protect [default: -1]
---------------------
-1 = protecting off
>=0 = black zone protection
---> don't apply conversion on pixels egal or below this value
(ex: with 16, the black areas like borders
and generic are untouched so they don't look washed out)


and was wondering what "egal" means (highlighted in blue above). I'm thinking that it should be "equal" but wanted to check. Thanks.

[LaTo]

Hi LaTo, and thank you very much for SmoothAdjust :) . As I was poking through the ReadMe I came across, under IX. SMOOTHLEVELS - LIMITING SETTINGS :

protect [default: -1]
---------------------
-1 = protecting off
>=0 = black zone protection
---> don't apply conversion on pixels egal or below this value
(ex: with 16, the black areas like borders
and generic are untouched so they don't look washed out)


and was wondering what "egal" means (highlighted in blue above). I'm thinking that it should be "equal" but wanted to check. Thanks.

égal = equal in french, oups :D

[LouieChuckyMerry]

Pas de problème, merci beaucoup ;) .

[burfadel]

How do I get the following, for example, to work using the Smoothtools option:
smoothtweak(hue1=1,hue2=1,saturation=1.05,lmode=1,limitstr=25)
smoothlevels(8,0.98,255,0,255,lmode=2,chroma=0,protect=2,ecenter=255)
smoothlevels(0,1.04,248,0,255,lmode=1,chroma=0,protect=2,ecenter=60)

It says the syntax is not correct. Now, yes I did specific the input_low etc stuff, no success.

For example, in the default.smt file if I use the example:
SmoothLevels(gamma=1.4,Lmode=1)
SmoothCurve(Ycurve="0-255;255-0")
it works

However, as soon as I add (building up to the example above):
SmoothLevels(input_low=8,gamma=1.4,Lmode=1)
SmoothCurve(Ycurve="0-255;255-0")
it doesn't work.

Therefore, if I have in the file, even just the first line of the code in question:
smoothlevels(input_low=8, gamma=0.98, input_high=255, output_low=0, output_high=255, lmode=2, chroma=0, protect=2, ecenter=255) which is supposedly correct according to the documentation, it doesn't work.

How do I get the three lines of code I used in the first example to work, in terms of syntax with the smoothtools command? Keeping in mind that naming the parameters according to syntax doesn't seem to work as in the line above.

[StainlessS]

Would be best if you give full failing script and error message with line numbers etc.

I was under the impression that latest v3.20 does not work on XP (according to first post), just tried getting
the function list (via RT_Stats included FSEL_Make_PluginFunctionList.AVS script, and it works
(at least for producing list, not tried functions in a script yet).

here, function list (LaTo tends not to make it easy to see types in function prototype, [EDIT: nor default values])



SmoothAdjust_ORDERED_Function_List v3.20


There follows a list of all function names together with CPP style argument specifiers that inform
Avisynth the argument types and optional names. Optional arguments have square brackets surrounding
their name as in [name] and are followed by a type specifier character that gives the type.
Unnamed arguments are not optional. eg "cc[arg1]b[arg2]i" would be two compulsory unnamed clip args,
followed by optional 'arg1' of type bool and optional 'arg2' of type int.

# Argument type specifier strings.
c - Video Clip
i - Integer number
f - Float number
s - String
b - boolean
. - Any type (dot)
# Array Specifiers
i* - Integer Array, zero or more
i+ - Integer Array, one or more
.* - Any type Array, zero or more
.+ - Any type Array, one or more
# Etc
###################################


SmoothCurve "c[Ycurve]s[Ucurve]s[Vcurve]s[mode]i[limiter]b[TVrange]i[interp]i[dither]i[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i"
"[screenH]i[scale]b"
SmoothCurve16 "c[Ycurve]s[Ucurve]s[Vcurve]s[mode]i[limiter]b[TVrange]i[interp]i[dither]i[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i"
"[screenH]i[scale]b"
SmoothCustom "c[Yexpr]s[Uexpr]s[Vexpr]s[limiter]b[TVrange]i[interp]i[dither]i[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i[screenH]i"
"[scale]b"
SmoothCustom16 "c[Yexpr]s[Uexpr]s[Vexpr]s[limiter]b[TVrange]i[interp]i[dither]i[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i[screenH]i"
"[scale]b"
SmoothLevels "c[input_low]i[gamma]f[input_high]i[output_low]i[output_high]i[chroma]i[limiter]i[TVrange]b[preset]s[Lmode]i[darkSTR]i"
"[brightSTR]i[Ecurve]i[Ecenter]i[protect]i[interp]i[dither]i[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i[screenH]i[scale]b"
SmoothLevels16 "c[input_low]i[gamma]f[input_high]i[output_low]i[output_high]i[chroma]i[limiter]i[TVrange]b[preset]s[Lmode]i[darkSTR]i"
"[brightSTR]i[Ecurve]i[Ecenter]i[protect]i[interp]i[dither]i[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i[screenH]i[scale]b"
SmoothTools "c[filename]s[interp]i[dither]i[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i[screenH]i[scale]b"
SmoothTools16 "c[filename]s[interp]i[dither]i[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i[screenH]i[scale]b"
SmoothTweak "c[brightness]i[contrast]f[saturation]f[hue1]i[hue2]i[limiter]b[TVrange]b[Lmode]i[limitSTR]i[Ecurve]i[interp]i[dither]i"
"[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i[screenH]i[scale]b"
SmoothTweak16 "c[brightness]i[contrast]f[saturation]f[hue1]i[hue2]i[limiter]b[TVrange]b[Lmode]i[limitSTR]i[Ecurve]i[interp]i[dither]i"
"[HQ]b[useMT]i[useOPT]i[debug]b[screenW]i[screenH]i[scale]b"

EDIT: Above edited for line wrap


avisource("F:\v\Cabaret.avi")
smoothtweak(hue1=1,hue2=1,saturation=1.05,lmode=1,limitstr=25)
smoothlevels(8,0.98,255,0,255,lmode=2,chroma=0,protect=2,ecenter=255)
smoothlevels(0,1.04,248,0,255,lmode=1,chroma=0,protect=2,ecenter=60)

Works just fine on Windows XP with current latest v3.20 [never used it before today because of XP+ only, note in first post])
Cabaret.avi is YV12, I'm on AVS v2.6 Standard, XP32SP3.

EDIT: What version plug you using ?
Also, you could make things easier for bug reports, to comment out (or remove) lines that do not contribute to the error
(at which line does the error occur, so people dont have to examine lines that are nothing to do with the problem).

EDIT: None of your failing snippits fail here.

[burfadel]

Running them in the script like your:
avisource("F:\v\Cabaret.avi")
smoothtweak(hue1=1,hue2=1,saturation=1.05,lmode=1,limitstr=25)
smoothlevels(8,0.98,255,0,255,lmode=2,chroma=0,protect=2,ecenter=255)
smoothlevels(0,1.04,248,0,255,lmode=1,chroma=0,protect=2,ecenter=60)

works perfectly fine. The issue I am having is with the smoothtools function, where you put the code in an external file (default.smt is the default), but you have to specify all the paramateres with their full names such that the second line (for example) becomes:
smoothlevels(input_low=8, gamma=0.98, input_high=255, output_low=0, output_high=255, lmode=2, chroma=0, protect=2, ecenter=255)

The reason why you would load them from the external file using smoothtools is that it does everything in one pass, according to the literature. Supposedly the result should be more accurate and also be faster. This is irrelevant if you run one line, but since there are three separate commands, running them as one function would be advantageous.

From the literature:

SmoothTools allows to use all the previous filters in one single pass.
The benefits are significant speedup, no rounding errors between each filters (internal 32-bits),
one pass smoothing/dithering (much better quality) and preset support (one file by settings).


filename [default: "default.smt"]
---------------------------------
File used for processing

---> SYNTAX:
-------
The file syntax is the same as avisynth but all parameters must be named.
Common settings between filters (smooth, dither, useMT, useOPT, ...) should not be used.
There is no limit to the number of filters in one file (but only one filter by line).
8-bits and 16-bits filters can not be mixed.

---> EXAMPLES:
---------
SmoothLevels(gamma=1.4,Lmode=1)
SmoothCurve(Ycurve="0-255;255-0")
OR
SmoothTweak16(saturation=1.6,Lmode=2)
SmoothCustom16(Yexpr="65535-Y")

The examples work! It's when you add the additional functions to smoothlevels (for example) where it doesnt.

[burfadel]

Nevermind, I worked it out! You have to have the commands in the correct order even if specified, and it is fully case sensitive. For instance, you have to type SmoothLevels not Smoothlevels, you have to type Lmode not lmode, limitSTR not limitstr etc. If it isn't exact smoothtools doesn't work.

[Logan9778]

Never mind. I figured it out.

[silverwing]

Tell me, please, are there any new versions of SmoothAdjust? The latest version of the plug-in is 3.20, almost three years ago. Thank you for attention.

[StainlessS]

Dont think so, LaTo has not (I think) been around for some time, and the source (like most LaTo source), was never published.

[kedautinh12]

link download died, anyone have alternative link?? thanks

[ChaosKing]

The link on the first page works for me

[kedautinh12]

The link on the first page works for me

Oh, now it work for me

[foobar2000]

I have a question, when do we add smoothlevels(), at the end of the script or before tfm or before crop and resize?

I add it or coloryuv at the end of script, hope it's fine.

[real.finder]

since SmoothAdjust is close source and original SmoothLevels Thread is closed

here a HBD update for the old SmoothLevels (now renamed as oSmoothLevels) https://github.com/realfinder/AVS-Stuff/raw/Community/avs%202.5%20and%20up/oSmoothLevels.avsi

try it with useGF=false for now

[Selur]

With debug enabled SmoothCurve gives an Access Violation with Avisynth 3.6.
-> any hope for an update?

[kedautinh12]

Can you use with 3.6.1 test 4??

[StainlessS]

How similar are oSmoothLevels results to Smoothadjust dll ?

[could it be used as source for CPP re-write]

[real.finder]

How similar are oSmoothLevels results to Smoothadjust dll ?

[could it be used as source for CPP re-write]

don't know, and didn't try it yet

anyway, I did another update to not use useGF by default in HBD and another changes that almost same as I did for MCTemporalDenoise (use GradFun2DB3 from my edit of GradFun2DBmod in avs26/avs+)

[StainlessS]

Thanks RF.

[Sharc]

For planar YUV input sources >8bit (e.g. using convertbits(12)) I am getting weird outputs with SmoothAdjust (SmoothTweak, SmoothLevels). Only the left half of the picture is affected and badly color distorted. The right half remains untouched. Using SmoothAdjust.dll version 3.20. Any explanation what could be wrong?

[kedautinh12]

Try use oSmoothLevels of real.finder replace
https://raw.githubusercontent.com/realfinder/AVS-Stuff/Community/avs%202.5%20and%20up/oSmoothLevels.avsi

[Sharc]

Yep, oSmoothLevels() works here for higher bitdepths. Thanks.
Is there also an "oSmoothTweak()" available?

[kedautinh12]

Try use internal function tweak() replace
http://avisynth.nl/index.php/Tweak

[Sharc]

The internal Tweak() is working, yes. It's just the SmoothTweak() which fails for higher bitdepths.

[Emulgator]

To use SmoothAdjust with 16 bit, just
vidcurve=SmoothCurve16(ConvertToStacked(vid), HQ=true, interp=100, Ycurve="0-0;15360-30720;65535-65535", Ucurve="0-0;65535-65535", Vcurve="0-0;65535-65535").ConvertFromStacked()

[Reel.Deel]

For planar YUV input sources >8bit (e.g. using convertbits(12)) I am getting weird outputs with SmoothAdjust (SmoothTweak, SmoothLevels). Only the left half of the picture is affected and badly color distorted. The right half remains untouched. Using SmoothAdjust.dll version 3.20. Any explanation what could be wrong?

SmoothAdjust does not support native HBD so the Stack-16 method must be used. Also all of the filter names end with 16, for example SmoothLevels16(...).


Source()
ConvertBits(16)
ConvertToStacked(16)
SmoothTweak16(saturation=1.6,Lmode=2)
ConvertFromStacked(16)

And as it states in the documentation, when working in 16 bits some parameters must be mapped to the [0-65535] range.

Edit: oops, I didn't see Emulgator's post, I started to reply some hours ago and had to leave :o

[Sharc]

Thanks Emulgator and Reel.Deel for the hints.

[Selur]

When using:
ClearAutoloadDirs()
SetFilterMTMode("DEFAULT_MT_MODE", MT_MULTI_INSTANCE)
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\LSMASHSource.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\dither.dll")
LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\SmoothAdjust.dll")
Import("F:\Hybrid\64bit\Avisynth\avisynthPlugins\mtmodes.avsi")
# loading source: C:\Users\Selur\Desktop\Tonight (with Emma Hewitt) (M).mov
# color sampling YUY2@10, matrix: bt709, scantyp: progressive, luminance scale: limited
LWLibavVideoSource("C:\Users\Selur\Desktop\Tonight (with Emma Hewitt) (M).mov",cache=false,format="YUV422P16", prefer_hw=0,repeat=true)
# current resolution: 1920x815
# cropping
Crop(0,1,0,0)# 1920x814
SmoothTweak16(brightness=25600)
# adjust color to RGB32 (color matrix: Rec709)
ConvertToRGB32(matrix="Rec709")
# setting output fps to 25.000fps
AssumeFPS(25,1)
PreFetch(16)
# output: color sampling RGB32@16, matrix: bt709, scantyp: progressive, luminance scale: limited
return last
I get:
SmoothAdjust: Width and height must be MOD2! (J:\tmp\tempPreviewAvisynthFile21_32_41_409.avs, line 13)
but I don't understand why, both 1920 and 814 are mod2.

Cu Selur

Ps.: I'm using Avisynth+ 3.7.3

[Rumbah]

I had a similar problem with MCTemporalDenoise, the problem was that although the error message said mod2, it worked only with mod 4.

[Selur]

Got, it

LoadPlugin("F:\Hybrid\64bit\Avisynth\avisynthPlugins\ConvertStacked.dll")
ConvertToStacked(16)
SmoothTweak16(brightness=25600)
ConvertFromStacked(16)


Cu Selur