SmoothLevels [depreciated version, see SmoothAdjust]

[LaTo]

#########################################################################################
### ###
### function Smooth Levels : SmoothLevels() ###
### ###
### v1.02 by "LaTo INV." ###
### ###
### 28 January 2009 ###
### ###
#########################################################################################
###
###
### /!\ Needed filters : Masktools (v2.0a35), Removegrain (v1.0PR), GradFun2db (v1.0).
### --------------------
###
###
### USAGE: SmoothLevels(input_low, gamma, input_high, output_low, output_high,
### chroma, limiter,
### Lmode, DarkSTR, BrightSTR, Ecenter, protect, Ecurve,
### Smode, Mfactor, RGmode, useGF,
### show, screenW, screenH, preset)
###
###
###
### +---------+
### | GENERAL |
### +---------+
###
### Levels options:
### ---------------
### input_low, gamma, input_high, output_low, output_high [default: 0, 1.0, 255, 0, 255]
###
### chroma [default: 50]
### ---------------------
### 0 = no chroma processing (similar as Ylevels)
### xx = intermediary
### 100 = normal chroma processing (similar as Levels)
###
### limiter [default: 0]
### --------------------
### 0 = no limiter (similar as Ylevels)
### 1 = input limiter
### 2 = output limiter (similar as Levels: coring=false)
### 3 = input & output limiter (similar as Levels: coring=true)
###
###
###
### +----------+
### | LIMITING |
### +----------+
###
### Lmode [default: 0]
### ------------------
### 0 = no limit
### 1 = limit conversion on dark & bright areas (apply conversion @0% at luma=0 & @100% at luma=Ecenter & @0% at luma=255)
### 2 = limit conversion on dark areas (apply conversion @0% at luma=0 & @100% at luma=255)
### 3 = limit conversion on bright areas (apply conversion @100% at luma=0 & @0% at luma=255)
###
### DarkSTR [default: 100]
### ----------------------
### Strength for limiting: the higher, the more conversion are reduced on dark areas (for Lmode=1&2)
###
### BrightSTR [default: 100]
### ------------------------
### Strength for limiting: the higher, the more conversion are reduced on bright areas (for Lmode=1&3)
###
### Ecenter [default: 128]
### ----------------------
### Center of expression for Lmode=1
###
### protect [default: -1]
### ---------------------
### -1 = protect off
### >=0 = pure black 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)
###
### Ecurve [default: 0]
### -------------------
### Curve used for limit & protect:
### 0 = use sine curve
### 1 = use linear curve
###
###
###
### +-----------+
### | SMOOTHING |
### +-----------+
###
### Smode [default: -2]
### -------------------
### 2 = smooth on, maxdiff must be < to "255/Mfactor"
### 1 = smooth on, maxdiff must be < to "128/Mfactor"
### 0 = smooth off
### -1 = smooth on if maxdiff < "128/Mfactor", else off
### -2 = smooth on if maxdiff < "255/Mfactor", else off
###
### Mfactor [default: 2]
### --------------------
### The higher, the more precise but the less maxdiff alowed:
### maxdiff=128/Mfactor for Smode1&-1 and maxdiff=255/Mfactor for Smode2&-2
###
### RGmode [default: 12]
### --------------------
### In strength order: + 19 > 12 >> 20 > 11 -
###
### useGF [default: true]
### ---------------------
### Use gradfun2db on top of removegrain: prevent posterize when doing levels conversion
###
###
###
### +--------+
### | OTHERS |
### +--------+
###
### show [default: false]
### ---------------------
### Show the debug clip
###
### screenW [default: 1280]
### -----------------------
### Screen horizontal resolution for debug clip
###
### screenH [default: 1024]
### ----------------------
### Screen vertical resolution for debug clip
###
### preset:
### -------
### pc2tv = "PC -> TV" conversion
### tv2pc = "TV -> PC" conversion
###
###
#########################################################################################


Old scripted version : SmoothLevels v1.02 (http://latoninf.free.fr/d9/SL/SmoothLevels.v1.02.avsi)

-->See SmoothAdjust (http://forum.doom9.org/showthread.php?t=154971) for up-to-date version!



Comparaison SmoothLevels <-> Levels:

Source (http://latoninf.free.fr/d9/SL/SRC.png)

SmoothLevels(preset="tv2pc",chroma=2) (http://latoninf.free.fr/d9/SL/SM.png)

Levels(16,1.0,235,0,255,coring=false) (http://latoninf.free.fr/d9/SL/LVL.png)


_

[rfmmars]

I am running into two problems, first if color is set to 1 or 2 any ajustments to levels will create a bright green or redish-pink screen.

Second is I can't get "mode" to work, error on "y","s" or"g"



Ulevels(chroma=0,mode=y,protect=true,input_low=[<"Low brt (0)", 0, 150, 31>],Gamma=[<"Gamma (1)", .2, 3.00, 1.11>],Input_high=[<"Brt High (255)", 0, 255, 210>],output_low=[<"Output Low Val (0)", 0, 100, 29>],output_high=[<"Output Hi Val(255)", 0, 255, 218>])#,1.0,123,0,200)

Richard
photorecall.net

[LaTo]

For mode:
Ulevels(mode="Y")
and not:
Ulevels(mode=Y)

For the chroma error, maybe an old version of Masktools or Removegrain. (no problem on my pc)

RemoveGrain1.0 prerelease: http://home.arcor.de/kassandro/RemoveGrain/RemoveGrain.rar

MT MaskTools 2.0a32: http://manao4.free.fr/masktools-v2.0a32.zip

:)

[Blue_MiSfit]

Looks nice! Thanks for your efforts!

[rfmmars]

For mode:
Ulevels(mode="Y")
and not:
Ulevels(mode=Y)

For the chroma error, maybe an old version of Masktools or Removegrain. (no problem on my pc)

RemoveGrain1.0 prelease: http://home.arcor.de/kassandro/RemoveGrain/RemoveGrain.rar

MT MaskTools 2.0a35: http://manao4.free.fr/masktools-v2.0a32.zip

:)

Ok I will try those versions you posted, many thanks!

EDIT: Yes that did it, NO only the Mode works.

Richard

[rfmmars]

The mode works but the color problems remains, first I though it was fixed but I had the color mode set to "0"

I will try it on another computer.

Richard

[LaTo]

any others feedback??? :confused:

[rfmmars]

I have installed it on another computer, a AMD 3.2 gig and if I select "Color mode" 1 or 2, any adjustment to the input or output sliders, it causes a color shift. It can be balanced out but I don't think that's how it should work. Gamma causes no change in color.

Next I am going to install it to a Intel MT machine to see what happens.

You might want to post in detail more on how and what its does.

Thanks,

Richard

[45tripp]

i get the same as richard

[lexor]

I am on AMD single core and I got the 2 filters linked by LaTo in his second post. While I don't see any color 1/2 settings, but since Richard bolded chroma, I'm assuming he's talking about chroma=1/2, both of those work flawlessly for me. And I like the colour correction quality much better than FFDshow's built in Levels, new King!

Also Richard maybe you should try with a simpler line? I use ulevels(chroma=2, preset="tv2pc") does that work for you or are you getting artifacts?

[rfmmars]

I am on AMD single core and I got the 2 filters linked by LaTo in his second post. While I don't see any color 1/2 settings, but since Richard bolded chroma, I'm assuming he's talking about chroma=1/2, both of those work flawlessly for me. And I like the colour correction quality much better than FFDshow's built in Levels, new King!

Also Richard maybe you should try with a simpler line? I use ulevels(chroma=2, preset="tv2pc") does that work for you or are you getting artifacts?

Yes the presets work but that is of no use for me. I deal with faded, color shifted old 8mm and 16mm films so I need to adjust the levels without changing the chroma.

http://img145.imageshack.us/img145/7290/ulevelsyn0.th.jpg (http://img145.imageshack.us/my.php?image=ulevelsyn0.jpg)

So something needs to be fixed or its of little use to me.

Richard

[Didée]

The color shifting is no mystery. Regarding chroma, the function scales chroma values linearily from to [out(put)_low,out(put)_high]. To keep colors neutral, both the input/output pairs have to be symmetric to 128.
The point is that these (chroma) values are directly derived from the luma-targetting parameters. Hence, if the in/out/low/high values for luma happen to be symmetric to 128, then you get correct colors. If they aren't, then you get a color shift.

Since you probably don't ever want any kind of color shifting from a *levels* function (if you need that, you'd use something else), a suggestion:
Use (output_high - output_low) / (input_high - input_low) as scaling factor cF, then use "x 128 - cF * 128 +" for the chroma channels. Gives the same effect if luma in/out.. points are symmetric, and a [I]reasonable effect if they aren't.

Introducing completely independent chroma parameters is another option.

[fibbingbear]

II. First example (levels) :


Original 16-235
...

ColorYUV(mode="pc->tv").ColorYUV(mode="tv->pc")
...

ULevels(preset="pc2tv").ULevels(preset="tv2pc")
...


Maybe I'm not understanding something, but if the original is 16-235, wouldn't you want to go tv->pc and then pc->tv? You have pc->tv->pc.

I know that you meant it as an example that ULevels does a better job of preserving the original if you do the inverse, but it wouldn't the example work better if it was based on a real transformation you might do?

I admit, I don't understand a lot about levels stuff, so correct me if I'm wrong.

Also, why is half-croma preferred? I'd think that you'd want full chroma... explain why this isn't the case :)

[LaTo]

The color shifting is no mystery. Regarding chroma, the function scales chroma values linearily from to [out(put)_low,out(put)_high]. To keep colors neutral, both the input/output pairs have to be symmetric to 128.
The point is that these (chroma) values are directly derived from the luma-targetting parameters. Hence, if the in/out/low/high values for luma happen to be symmetric to 128, then you get correct colors. If they aren't, then you get a color shift.

Since you probably don't ever want any kind of color shifting from a *levels* function (if you need that, you'd use something else), a suggestion:
Use (output_high - output_low) / (input_high - input_low) as scaling factor cF, then use "x 128 - cF * 128 +" for the chroma channels. Gives the same effect if luma in/out.. points are symmetric, and a [I]reasonable effect if they aren't.

Introducing completely independent chroma parameters is another option.

Yes, I saw the issue yesterday but I haven't time to update... But thanks for the report, I will post a fix when I can... (use chroma=0 for the moment)

[LaTo]

The chroma expression was on my todo list, but I forgot to change it because I made my tests with symmetric input/output... I'm tired :D

So, the new version 8.05d fix the chroma shift!

[LaTo]

Also, why is half-croma preferred? I'd think that you'd want full chroma... explain why this isn't the case :)

"Avisynth Levels" process the chroma with the "same factor" as the chroma, so it will change a lot the color saturation.
--> it's chroma=2

"Didée Ylevels" doesn't process the chroma at all.
--> it's chroma=0

I think that a balance of the two method is a good compromise: change the chroma less (division by 2) than the luma to preserve a bit the color saturation.
--> it's chroma=1

[rfmmars]

This is much better, thanks!

Richard

[cyberbeing]

chroma=2 is broken with the new version. chroma=1 works fine.
http://img300.imageshack.us/img300/6606/snapshot20080515013818zk8.th.jpg (http://img300.imageshack.us/img300/6606/snapshot20080515013818zk8.jpg)

Also, could you please explain the difference between the three modes?

[Didée]

May I offer a fix ...


Delete: ( it's a) probably wrong, and b) superfluous due to the following fix)
in_low = (chroma == 2) ? round(input_low/2) : round(input_low/4)
in_high = (chroma == 2) ? round(input_high/2) : round((input_high+(255-input_high)/2)/2)
out_low = (chroma == 2) ? round(output_low/2) : round(input_low/4)
out_high = (chroma == 2) ? round(output_high/2) : round((output_high+(255-output_high)/2)/2)


Replace:
### CHROMA
exprC = "x 128 - 0 < 0 x 128 - abs "+string(in_low)+" - "+string( .... # etc., veeery long line ...
exprC = ( chroma == 0 ) ? "x" : exprC

with
### CHROMA
scaleC = (float(output_high)-output_low)/(input_high-input_low)
scaleC = chroma==2 ? scaleC : (scaleC+1.0)/2
exprC = "x 128 - "+string(scaleC)+" * 128 +"
exprC = ( chroma == 0 ) ? "x" : exprC

That's what I had suggested somewhere above, and surprise, it works as supposed.

[lexor]

mode="S" seems broken, Y and G identical picture (or close enough to be identical), and S is much worse. You know how if you don't use any levels the whole picture looks like it has this grayish overlay, if mode S is active that overlay isn't removed, it just gets slightly reduced. Also protect=true only seems to work with mode S, and is broken for Y and G (by broken I mean solid black parts of the picture are replaced with weird gray)

This like works fine: Ulevels(mode="Y", chroma=1, smooth=0, preset="tv2pc")
This one looks too gray: Ulevels(mode="S", chroma=1, smooth=0, preset="tv2pc")
This one has black replaced: Ulevels(mode="Y", chroma=1, smooth=0, protect=true, preset="tv2pc")

[LaTo]

May I offer a fix ...
That's what I had suggested somewhere above, and surprise, it works as supposed.
Thanks for this fix... First post updated!

But I don't understand this:
Delete: [i]( it's a) probably wrong[I]
why is it wrong?

Also, could you please explain the difference between the three modes?
Look at the "Didée Ylevels" thread

mode="S" seems broken, Y and G identical picture (or close enough to be identical), and S is much worse
It's normal!
"The most-faced problem is: video appears "too dark" on PC monitors. YlevelsG() and YlevelsS() apply the given levels conversion by 100% @ Luma==0, by 0% @ Luma=255, and accordingly in-between."


Also protect=true only seems to work with mode S, and is broken for Y and G (by broken I mean solid black parts of the picture are replaced with weird gray)
Protect=true work well when tweaking gamma in mode S... It's worse when tweaking levels... Try before using it!

[Didée]

why is it wrong?
Because it seems wrong. Frankly, I don't really understand what you were doing there ... but at least the end result gave proof that something was wrong.
Let me kick the ball back to you: can you, for example, explain why in the case of chroma=2, i.e. "full" chroma processing, you were dividing all input/output/low/high's by 2 to get the chroma control points? That makes no sense to me in case you want to use those chroma control points directly, and it makes no sense to me in case you want to use the division (out/in) as a factor. It's not correct in both cases, and same goes for the alteration in case chroma=1. I'm too lazy to do the math for you with a ladder of case examples, you can figure it on your own.
(My suggested way of chroma calculations is IMHO rather easy to follow, that's enough. No need to get knots in the brain :p )

It might get fun to dive into the "pixel adaptive smoothing" stuff ... I've not had the mood yet to analyze that one, but requiring a 3D table (mt_Lutxyz) seems to be pretty heavy for a bit of level adjustment. ;)

[lexor]

It's normal!
"The most-faced problem is: video appears "too dark" on PC monitors. YlevelsG() and YlevelsS() apply the given levels conversion by 100% @ Luma==0, by 0% @ Luma=255, and accordingly in-between."

The reason I thought it was broken is that on cartoon or anime (non CG) source mode S is almost identical to no ulevels, while Y and G produce similar effect to one another. S seemed to me to be doing too much of a different thing.

[LaTo]

It might get fun to dive into the "pixel adaptive smoothing" stuff ... I've not had the mood yet to analyze that one, but requiring a 3D table (mt_Lutxyz) seems to be pretty heavy for a bit of level adjustment. ;)
Yes, a lot, but I haven't find another way to do it :confused:, maybe you can improve this!

[LaTo]

New version:
8.05f: no more mt_lutxyz for smooth=-3 (speed up +++)

[LaTo]

New version:

9.00a: (see readme for details)
- cosmetic change
- speed optimization
- /!\ mode ---> Lmode & smooth ---> Smode
- smooth setting
- new Smode (-1,-2,-3)

[ankurs]

^
can we please have a detail readme.txt ? explaining in detail , i know the .avs has itself but still its a bit confusing . . like one MOmonster has with his R_pack , your work is much appreciated :)

[pitch.fr]

looks nice, thanks!

is there any improvements over doing ConvertToRGB32(matrix="rec709") or doing level conversions when going RGB32 in ffdshow ?

I remember Didée saying that regular TV>PC conversion was far from optimal, as far as "most perfect" levels conversion was concerned.

[LaTo]

^
can we please have a detail readme.txt ? explaining in detail , i know the .avs has itself but still its a bit confusing . . like one MOmonster has with his R_pack , your work is much appreciated :)
What is a bit confusing?

[buzzqw]

ok, very dumb question: should this filter replace colormatrix ? :o

thanks!

BHH

[LaTo]

ok, very dumb question: should this filter replace colormatrix ? :o

thanks!

BHH

No.

It's a filter like Levels() or Ylevels()...

[pitch.fr]

ok, very dumb question: should this filter replace colormatrix ? :o
Ulevels() does levels conversions that are not mathematically accurate, but much more pleasing to the eye.......besides it lowers the gamma curve in dark areas, which increases the contrast :eek:

ffdshow TV>PC :

http://thumbnails9.imagebam.com/1015/0954ae10145746.gif (http://www.imagebam.com/image/0954ae10145746)http://thumbnails9.imagebam.com/1015/c31f9c10145748.gif (http://www.imagebam.com/image/c31f9c10145748)http://thumbnails9.imagebam.com/1015/68644910145750.gif (http://www.imagebam.com/image/68644910145750)
http://thumbnails8.imagebam.com/991/f1ffe19905831.gif (http://www.imagebam.com/image/f1ffe19905831)http://thumbnails8.imagebam.com/991/0b3b449905833.gif (http://www.imagebam.com/image/0b3b449905833)http://thumbnails8.imagebam.com/991/fa99c29905835.gif (http://www.imagebam.com/image/fa99c29905835)

ULevels(preset="tv2pc") :

http://thumbnails9.imagebam.com/1015/c5507110145747.gif (http://www.imagebam.com/image/c5507110145747)http://thumbnails9.imagebam.com/1015/c4554710145749.gif (http://www.imagebam.com/image/c4554710145749)http://thumbnails9.imagebam.com/1015/1965d810145751.gif (http://www.imagebam.com/image/1965d810145751)
http://thumbnails8.imagebam.com/991/b61b119905830.gif (http://www.imagebam.com/image/b61b119905830)http://thumbnails8.imagebam.com/991/9b2ef49905832.gif (http://www.imagebam.com/image/9b2ef49905832)http://thumbnails8.imagebam.com/991/3b5c889905834.gif (http://www.imagebam.com/image/3b5c889905834)

[LaTo]

v1.0alpha:

changed name Ulevels() --> SmoothLevels()
*big* bugfix with limiter>0
changed smooth --> RGmode
added useGF, useful to prevent posterize
changed all Smode code, deleted unuseful mode and added new one
deleted SS parameter
added Mfactor parameter
some cosmetic change & speed up
updated the documentation

:)

[pitch.fr]

w00t :)

when I try the tv2pc preset, I get a msg saying VDUB doesn't know what "color_gray" is on line 206...running MT 0.7/Avisynth 2.5.7 :(

would be great if it used less CPU power than the former version :)

EDIT : I've replaced it by "color=$808080" and that looks OK :D

[LaTo]

w00t :)

when I try the tv2pc preset, I get a msg saying VDUB doesn't know what "color_gray" is on line 206...running MT 0.7/Avisynth 2.5.7 :(

would be great if it used less CPU power than the former version :)

EDIT : I've replaced it by "color=$808080" and that looks OK :D
Maybe a bug in MT 0.7, because it's working on my avisynth 2.5.7... I have updated the script ;)


but now it's asking for gradfun2db, I really don't wanna have deband processed....is that mandatory ?

Install gradfun2db or add useGF=false to the cmdline...

[pitch.fr]

OK I have, I'm still sleepy :D

some benchmarks in VDUB on a Q6600 :

MT("""SmoothLevels(preset="tv2pc")""",4)
=212 fps

MT("""ULevels(preset="tv2pc")""",4)
=240

prolly the deband thingie is killing the speed..gonna disable it :)

is it OK to replace color_gray by "color=$808080" ? or is it YUV ?

[LaTo]

is it OK to replace color_gray by "color=$808080" ?
It's ok, I have updated the script...

[pitch.fr]

I see you've changed the Smode/Chroma mode/protect etc etc, gonna have to compare....but I trust your judgement anyhow :)

OK w/o gradfun2db :

MT("""SmoothLevels(preset="tv2pc")""",4)
=283 fps

AWESOME :eek:

[pitch.fr]

Ulevels tv2pc :

http://pix.nofrag.com/1/5/f/e4da49460c26735c6ad5fb212d97ctt.jpg (http://pix.nofrag.com/1/5/f/e4da49460c26735c6ad5fb212d97c.html)

SmoothLevels tv2pc :

http://pix.nofrag.com/b/b/9/c4c8ba2fdacba1a6a1da12e388d78tt.jpg (http://pix.nofrag.com/b/b/9/c4c8ba2fdacba1a6a1da12e388d78.html)

the main reason I use your script in ffdshow for is to get darker reds(they look orangey in SMPTE-C), and increase the contrast.

it seems a tad better now http://forum.slysoft.com/images/smilies/agreed.gif

my full LSF/Ulevels/GrainF/AviShader/ConvertToRGB32 is gone from 36.2fps to 37..so thank you for that http://forum.slysoft.com/images/smilies/rock.gif

[Wilbert]

why does Didee tell me BT601 is 16-235 luma, and BT709 is 0-255 ?!
Item 6.10 of the Recommendation ITU-R BT.709-5 (page 12) says that the range is limited to 16-235.

[Didée]

Let me add that I did not "tell" that. Case of overinterpretation ... I showed (http://forum.doom9.org/showthread.php?p=1191586#post1191586) two code sniplets that handle luma ranges for masking, one for 16-235 range, one for 0-255 range, and happened to place the string "BT.709" beneath string "0-255" in a small #codecomment. (Assuming that if you encounter a 0-255 source, it'll probably be BT.709...)
http://img394.imageshack.us/img394/5461/oldcodeqh2.th.png (http://img394.imageshack.us/my.php?image=oldcodeqh2.png)http://img394.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)
Tried to avoid "but what-if-" nagging by showing both possibilities, got nagging I would have made a claim. Oh well.

Guilty for incautious wording. Changed to PC/TV range.

[LaTo]

v1.0beta1:
changed chroma parameter (more precise)
cosmetic changes

:)

[ankurs]

source :

http://i33.tinypic.com/k9uv5g.png

agc + smoothlevels(pc2tv) (final script doing everything necessary ie deinterlacing , denoising and a lot of other stuff ) :

http://i34.tinypic.com/90dmag.png

p.s : did the a.r correction as i deemed appropriate for the testing , also screens taken using print screen so sorry if the pixels are off ( yeah i know prtscrn+paint+crop+save as .png sucks ) but what to do no other option :(

input please ?

to my eyes smoothlevels aka ulevels seems to darken the picture a bit up ? used chroma=0 , will test more and post results :)

edit : i know they're annoying(the lines,but thats how the source is ) ( perhaps about time i updated my sharpening arsenal , giving lsfmod a shot in a bit , will post results :) )

[LaTo]

input please ?
:confused:

[ankurs]

meant to ask is everything fine ? should i change anything ?

[Adub]

If it looks good to your eyes, then it's fine. Asking everyone else for their own opinions will only cause you to filter the video to how they want it. If it looks good enough for you to watch, then what does anyone else's opinion matter?

[ankurs]

If it looks good to your eyes, then it's fine. Asking everyone else for their own opinions will only cause you to filter the video to how they want it. If it looks good enough for you to watch, then what does anyone else's opinion matter?

well thats what i do always , but additional input helps me fix my mistakes many a LOT of times :) :p

[Tagert]

the blocking in the first pic is gone in the second one, so it looks gorgeous to me :)

[Adub]

Your filtering is fine, so don't worry about it. It's about as good as it's going to get.

[LaTo]

v1.0beta2:
changed Lmode parameter (added Ecenter & strength)
updated the documentation + cosmetic


Update inspired from my little script LimitedGamma (http://forum.doom9.org/showthread.php?p=1214807#post1214807)...
Now it doesn't use anymore the same synthax as YlevelsS&G, I have made 6 new expression with ajustable strength and some tweak ;)