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

[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 ?)