AutoAdjust [v2.60 - Update 2015/11/15]

[LaTo]

+---------------------------------------------------------------------------------+
| |
| Automatic adjustement plugin: AutoAdjust() |
| |
| v2.60 by "LaTo INV." |
| |
| 15 November 2015 |
| |
+---------------------------------------------------------------------------------+



I. DESCRIPTION
II. DISCLAIMER
III. INSTALLATION
IV. REQUIREMENTS
V. MULTITHREADING
VI. USAGE
VII. GENERAL SETTINGS
VIII. AUTOGAIN SETTINGS
IX. AUTOBALANCE SETTINGS
X. CHANGELOG



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

AutoAdjust is an automatic adjustement filter. It calculates statistics of clip,
stabilizes them temporally and uses them to adjust luminance gain & color balance.

AutoAdjust have a smoothing & dithering algorithm to avoid banding issue.
Calculations are made in 32bits float to avoid rounding errors and
are internally multithreaded and SSE2/AVX2 optimized.

For manual adjustments, see all plugins in "SmoothAdjust" package.



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=167573",
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 much 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 AutoAdjust 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 :
===================
AutoAdjust 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).

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



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

AutoAdjust ( [clip], external_clip,
auto_gain,
dark_limit, bright_limit, gamma_limit,
dark_exclude, bright_exclude,
gain_mode, chroma_process, avg_safety,
input_tv, output_tv,
auto_balance,
chroma_limit, balance_str,
scd_threshold, temporal_radius, change_status,
use_interp, use_dither,
high_quality, high_bitdepth,
threads_count, asm_opt,
debug_view )



Last version (2015/11/15): AutoAdjust v2.60 (http://latoninf.free.fr/d9/AA/AutoAdjust-v2.60.7z)

Old version (for Avs2.5 or WinXP or Wine): AutoAdjust v1.02 (http://latoninf.free.fr/d9/AA/AutoAdjust-v1.02.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)


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

v2.50:
fixed crash with external_clip
fixed chroma processing bug
removed temporal_radius=-1
reintroduced internal caching

v2.40:
optimized frame access & frame cache
fixed potential freeze with very slow source filter

v2.20:
optimized memory usage with very long clip
fixed crash with ffdshow_source() and external MT

v2.00:
dropped Avs v2.5.x support
added AVX2 code (40% faster)
modified plugin to be thread-safe (MT_NICE_FILTER)
removed internal caching
added frame cache hints
improved debug_view

v1.90:
changed name of plugin & parameters
added color balance
added C version
fixed regression from v1.75 (bug at scenechange)

v1.75:
added avg_safety parameter
fixed a minor bug in temporal averaging
tweaked multi-threading code

v1.60:
split 'tv_range' into 'input_tv' & 'output_tv'
fixed possible freeze in MT code
added explicit error messages

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

v1.40:
used new C++11 features
rewritten multi-threading (native)
speed optimization (10% faster)
exception-safe code
added a high quality interpolation mode
improved core algorithm
fixed various little things

v1.02:
fixed minor things & bugs
dropped ICL builds support

v1.00:
first stable release


_

[LaTo]

Screenshot of AutoAdjust(debug_view=true):

http://latoninf.free.fr/d9/AA/AutoAdjust_DebugView_thumb.png (http://latoninf.free.fr/d9/AA/AutoAdjust_DebugView.png)
* Click the image to enlarge *

[LaTo]

Early alpha development discussion is available on the SmoothAdjust's thread (http://forum.doom9.org/showthread.php?p=1619337#post1619337), development and support will now continue here...

[LaTo]

/* Post from 01 april 2013 on SmoothAdjust's thread */


New AutoGain update: AutoGain-beta1 (http://latoninf.free.fr/d9/AutoGain-beta1.7z).

Big update, any inputs is appreciated ;)

[LaTo]

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

More robust scenechange detector, less fail on fade in/out :)

[LaTo]

New update: AutoGain-beta3 (http://latoninf.free.fr/d9/AutoGain-beta3.7z).

The plugin seems pretty mature now... One thing to add to be complete is a debug view, but later :D

[Reel.Deel]

Hey LaTo, thanks for adding 16 bit support. :)
The overall results are indeed very pleasing.
I was testing it out and I noticed something odd. When I use 8 bit the histogram looks smooth but with 16 bit the histogram looks posterized (hope that's the right term).
Here's the comparison (http://screenshotcomparison.com/comparison/17099). I use all default settings.

One thing to add to be complete is a debug view, but later :D
Like AutoLevels, maybe you can also add a scene change indicator to the debug view? I had another idea but seems you got rid of the bright/dark_ignore parameters.:p

[LaTo]

I was testing it out and I noticed something odd. When I use 8 bit the histogram looks smooth but with 16 bit the histogram looks posterized (hope that's the right term).
Here's the comparison (http://screenshotcomparison.com/comparison/17099). I use all default settings.
Yes I already fixed this in next version.

Like AutoLevels, maybe you can also add a scene change indicator to the debug view?
Yes it's planed :)

I had another idea but seems you got rid of the bright/dark_ignore parameters.:p
Yes I want to keep the plugin as simple as possible, so I removed some parameters... But if people prefers an hardcore filter with a lot of parameters, I can add at least 5 new one ^^

Maybe I should expose more parameters, and split them in "basic settings" and "advanced settings"... Don't know what is best.

Also I will have a look at AutoLevels plugin, maybe I can pick some ideas from this one.

Anyways, all ideas are welcome... So I want to hear your idea even if it's not realizable :)

[Reel.Deel]

Yes I already fixed this in next version.
...
Yes it's planed :)
Awesome.

Maybe I should expose more parameters, and split them in "basic settings" and "advanced settings".
Speaking for myself only, I generally stick to the basic settings, but I do appreciate the fact that the advance settings are there when I do need to use them. So yes, I would vote for basic and advanced settings.

Also I will have a look at AutoLevels plugin, maybe I can pick some ideas from this one.
Well, you're in luck, the AutoLevels readme does include a small to do list. :)
Also, frustum posted (http://forum.doom9.org/showthread.php?p=1586617#post1586617) some interesting ideas regarding some of the shortcomings of AutoLevels. A little more information on that very topic can be found on his website (http://www.thebattles.net/video/autolevels_comparison.html).

Anyways, all ideas are welcome... So I want to hear your idea even if it's not realizable :)
Just a thought, and it's a debug view idea if anything...
For the bright/dark ignore parameters do something like ShowLevels (http://www.geocities.com/siwalters_uk/showlevels.html)plugin, where the ignored bright/dark pixels would get painted a certain color.
For instance, purple is for bright_ignore and green for dark_ignore. Example (http://screenshotcomparison.com/comparison/17393) and exaggerated example (http://screenshotcomparison.com/comparison/17394). Just in case this is not a good idea, please take it easy on me. ;)

[LaTo]

New version: AutoGain-beta5 (http://latoninf.free.fr/d9/AutoGain-beta5.7z)

Now with debug view :cool:

[LaTo]

Well, you're in luck, the AutoLevels readme does include a small to do list. :)
Also, frustum posted (http://forum.doom9.org/showthread.php?p=1586617#post1586617) some interesting ideas regarding some of the shortcomings of AutoLevels. A little more information on that very topic can be found on his website (http://www.thebattles.net/video/autolevels_comparison.html).
I've read all these, IMO only 2 things are interesting for AutoGain:
- chroma processing, but it's already on my todo list
- frameOverrides string in AutoLevels


Just a thought, and it's a debug view idea if anything...
For the bright/dark ignore parameters do something like ShowLevels (http://www.geocities.com/siwalters_uk/showlevels.html)plugin, where the ignored bright/dark pixels would get painted a certain color.
For instance, purple is for bright_ignore and green for dark_ignore. Example (http://screenshotcomparison.com/comparison/17393) and exaggerated example (http://screenshotcomparison.com/comparison/17394). Just in case this is not a good idea, please take it easy on me. ;)
Yes, could be useful... Will see later which parameters need to be exposed or not :)


No report from Didée since 2 weeks... Maybe in vacations :D

[Forensic]

LaTo. This could be an extremely important asset for video forensic work. Over the next few days I will be testing it with several high-profile, low-resolution nighttime surveillance videos and report back my findings. Thank you for creating this tool.

[yup]

Hi Lato!
I try alpha version and see only autogain.
How replace internal ColorYUV call?
ColorYUV(autogain=true, autowhite=true)
may be
Autogain().ColorYUV(autowhite=true)?
Please advice.
yup.

[PDyksma]

Hello LaTo

Thanks for your efforts to create a REAL autolevels plugin.
All the ones I tried till now suffered from crunching the whites...:(
Also (f.i. the Avisynth one) they do not "obey" the requested outputlevels without clipping.

I'm a noob on scripting but is it not possible to do the following:

- get the brightest pixel in a frame and map it to, let's say 235
- get the darkest pixel and map it to 16
- interpolate the rest in between
- add some averaging to avoid "pumping"

The result should be as attached luminance waveform

[LaTo]

Hi Lato!
I try alpha version and see only autogain.
How replace internal ColorYUV call?
ColorYUV(autogain=true, autowhite=true)
may be
Autogain().ColorYUV(autowhite=true)?
Please advice.
yup.
IMO, I don't see how autowhite can produce good results... I should look at the source code to see how it works but I think this is an unsafe filter.

However, Autogain().ColorYUV(autowhite=true) will produce the same effect as before (I think).

Hello LaTo

Thanks for your efforts to create a REAL autolevels plugin.
All the ones I tried till now suffered from crunching the whites...:(
Also (f.i. the Avisynth one) they do not "obey" the requested outputlevels without clipping.

I'm a noob on scripting but is it not possible to do the following:

- get the brightest pixel in a frame and map it to, let's say 235
- get the darkest pixel and map it to 16
- interpolate the rest in between
- add some averaging to avoid "pumping"

The result should be as attached luminance waveform
If I all understand correctly, you simply need this:
AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00)

:)

[PDyksma]

If I all understand correctly, you simply need this:
AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00)
:)

I do not know what these parameters would do...:D

Well, I had some old 8mm films laser-scanned. The results are very good but I had a camera in 1978 with a miserable auto-exposure.
So, in a lot of scenes the luminance is shifting back and forth and difficult to correct manually. That's the reason I tried some autolevel-filters. But all suffer from doing nothing in some (dark) scenes and/or blowing up the lights in other. Also, they do not "obey" my given output-levels (0-255, 16-235 or wathever). So I need something to produce a nice equal (given) lumi-level like the screenshot in my previous post and without clipping.
Your autogain filter already comes near to that but with mode=1 I have to put some "brake" on the video (adding a small 4px white border) to reduce the gain-effect on the whites. This gives me a reasonable result so far:

gained-gained.addborders(4,0,0,0,$FFFFFF)
gained=gained.autogain(adjust_mode=1,bright_limit=100.0,dark_limit=1.5)
gained=gained.crop(4,0,-0,-0)

[LaTo]

I do not know what these parameters would do...:D
Hum... sorry my fault, these are not in AutoGain for now... It's in beta6 :D

[LaTo]

New AutoGain: AutoGain-beta6 (http://latoninf.free.fr/d9/AutoGain-beta6.7z)

Any reports/tests are welcome :)

[Forensic]

I applied your filter on several low resolution, high noise, under lit videos. Your filter improved luminosity without amplifying the noise. Outstanding work LaTo!

[LaTo]

I applied your filter on several low resolution, high noise, under lit videos. Your filter improved luminosity without amplifying the noise. Outstanding work LaTo!
Thanks for testing!

I do not know what these parameters would do...:D

[...]

Also, they do not "obey" my given output-levels (0-255, 16-235 or wathever). So I need something to produce a nice equal (given) lumi-level like the screenshot in my previous post and without clipping.
Your autogain filter already comes near to that but with mode=1 I have to put some "brake" on the video (adding a small 4px white border) to reduce the gain-effect on the whites
You can now try AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00) ;)

[LaTo]

Update Here: AutoGain-beta7 (http://latoninf.free.fr/d9/AutoGain-beta7.7z)

I consider the core robust and stable now, so for next release I will only fix bugs reported by users and some little things.

[Reel.Deel]

Hi LaTo, I was wondering if you changed the defaults after Beta5 or something internally? By looking at the readme's I see that the defaults are still the same. But, beta5 compared to 6 and 7 behave differently.
Here's the comparison (http://screenshotcomparison.com/comparison/18457/picture:0), I used all defaults and for beta 6 and 7 I used chroma_process=0. I like beta5 better. :)

Also, do you think it would be worthwhile to have U=xx, V=xx parameters instead of chroma_process=xx? I've come across footage where one of the chroma channels seems to be more "saturated" than the other.
Maybe independent parameters can aid those types of situations.

One last thing, AutoGain works fine with 8bit YV16/24 and with 16bit YV12 but with 16bit YV16/24 I get some weird artifacts which seems to only affect the MSB/top half. Here's an example (http://screenshotcomparison.com/comparison/18461) after dithering to 8bit.


Kudos on the debug view. It looks very good! :cool:
Thanks again for all your awesome work!

[LaTo]

Hi LaTo, I was wondering if you changed the defaults after Beta5 or something internally? By looking at the readme's I see that the defaults are still the same. But, beta5 compared to 6 and 7 behave differently.
Here's the comparison (http://screenshotcomparison.com/comparison/18457/picture:0), I used all defaults and for beta 6 and 7 I used chroma_process=0. I like beta5 better. :)

Also, do you think it would be worthwhile to have U=xx, V=xx parameters instead of chroma_process=xx? I've come across footage where one of the chroma channels seems to be more "saturated" than the other.
Maybe independent parameters can aid those types of situations.

One last thing, AutoGain works fine with 8bit YV16/24 and with 16bit YV12 but with 16bit YV16/24 I get some weird artifacts which seems to only affect the MSB/top half. Here's an example (http://screenshotcomparison.com/comparison/18461) after dithering to 8bit.


Kudos on the debug view. It looks very good! :cool:
Thanks again for all your awesome work!

I made a mistake with dark_exclude/bright_exclude, default should be "0.5" and not "0.05"... I will change it in next version, for now use "dark_exclude=0.5,bright_exclude=0.5".

And for 16bits / YV24, this seems a chroma bug (maybe I forgot a shift somewhere... :D)

[steptoe]

If I click that link, or any other to try and download autogain beta's I just get the '404 error' and had done in the past


Ignore that, must have been in the process of updating it while I was typing this. Just tried searching for another link came back to this one, beta 8 was available like 2 minutes later

Thanks

[LaTo]

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

[LaTo]

If I click that link, or any other to try and download autogain beta's I just get the '404 error'

Yeah, I was updating :D

[ganymede]

Your plugins makes wonders on dark scenes with footage from my Canon DSLR. Thank you very much LaTo !

[PDyksma]

LaTo:

Just want to say THANK YOU!

This is the first "autolevel" filter that works for me.
I had some difficult laser-scanned super8's which had varying levels and never succeeded in getting them right.
With your Autogain plugin the result is just amazingly good!

Thanks again!

[Motenai Yoda]

just a question, how dark_exclude/bright_exclude works?
by percentile of excluded pixel or percentile of dynamic range?
also can be added a parameter that control how heavy and light correctons weighs?
ie if i want that light corrections remains unthouched, and lighting heavy corrections, or viceversa, lighting light corrections and leave heavy corrections unthouched.
I think to an "S" function that, for positive values relieve light corrections and, for negative values relieve heavy corrections (or increase lights ones).

[LaTo]

just a question, how dark_exclude/bright_exclude works?
by percentile of excluded pixel or percentile of dynamic range?
By percentile of excluded pixel

also can be added a parameter that control how heavy and light correctons weighs?
ie if i want that light corrections remains unthouched, and lighting heavy corrections, or viceversa, lighting light corrections and leave heavy corrections unthouched.
I think to an "S" function that, for positive values relieve light corrections and, for negative values relieve heavy corrections (or increase lights ones).
You can do that in an avisynth script with lut/mask/merge, but for general purpose I don't see the point to remove small corrections and leave big corrections untouched.
A sort of color vibrance's effect but on luminance?

[LaTo]

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

[Motenai Yoda]

You can do that in an avisynth script with lut/mask/merge, but for general purpose I don't see the point to remove small corrections and leave big corrections untouched.
A sort of color vibrance's effect but on luminance?

maybe I did not explain well,
I mean correction by frame, not by pixel.
I notice you have added some limits, in a similar way, when gain of contrast is huge, or small, for some stuff, like night scenes or dark/light scenes (ie a corrected night scene maybe will look like a day scene), may don't require a heavy correction, so in other stuff can be preferable don't touch so much good scenes.

[Dogway]

I get different results with high_bitdepth =true and without.
temporal_radius = -1 crashes on me
How to limit change to 235? is it a guesswork with bright_limit?

[LaTo]

maybe I did not explain well,
I mean correction by frame, not by pixel.
I notice you have added some limits, in a similar way, when gain of contrast is huge, or small, for some stuff, like night scenes or dark/light scenes (ie a corrected night scene maybe will look like a day scene), may don't require a heavy correction, so in other stuff can be preferable don't touch so much good scenes.

Or maybe I am tired, or maybe the italian->english->french translation is failing :D
Sorry but I still do not understand what you want more than dark/bright/gamma_limit... These will limit changes on low contrast scene (like night scene).
Please explain a bit more :)


I get different results with high_bitdepth =true and without.
Yes very small variations are possible, but that is just +/- 1-2 pixels differences.
Do you experience more changes?

temporal_radius = -1 crashes on me
No crash on my side...
But, with all due respect, you have 835 posts on doom9.org and your crash report is sooo small... Really, I can not do anything with that.

So as with the newbies:
- precise error message
- crash at startup or later or at the end
- avisynth version
- entire script used
- properties of the video
- a sample if possible

How to limit change to 235? is it a guesswork with bright_limit?
You can not because of the averaging system, you will always have values ​​above or below 16/235.
Add Limiter() after AutoGain if you do not want these.

[Dogway]

I'm using Avisynth 2.6a3 MT.
It's more than 2 values, have a look (http://screenshotcomparison.com/comparison/19517).
Now I have 836 posts...
After giving it an unusual 10 seconds of settling it seems to be working... it seems..., can report further if you are not so annoyed.

Limiter() despite the name doesn't limit range, it actually kills it. So from your indirect take of the answer all I can read is "yes sir, guesswork". Thanks

[LaTo]

I'm using Avisynth 2.6a4 MT.
It's more than 2 values, have a look (http://screenshotcomparison.com/comparison/19517).
Now I have 836 posts...
After giving it an unusual 10 seconds of settling it seems to be working... it seems..., can report further if you are not so annoyed.

Limiter() despite the name doesn't limit range, it actually kills it. So from your indirect take of the answer all I can read is "yes sir, guesswork". Thanks
Honestly there was no animosity from me in my answer, all reports are welcome... But how could I find a bug with so little information.
With all the time spent on the forum, you should be somewhat familiar with bug report.
Anyway, in the end you still do not give me all the information requested...

And for Limiter(), yes there is no solution unless you want to use "AutoGain(dark_exclude=0,bright_exclude=0,temporal_radius=0)" which is nearly as stupid as "ColorYUV(autogain=true)".
So the answer was the correct one, it's not my fault if you not like it...

Thank you anyway, there is effectively a bug with gamma processing in 16 bits... Just need to spot it.

[Dogway]

with bright_limit as default, I went to the brightiest spot (many values compressed at 255) and lowered parameter up to 1.1 where (most) range was within 16-235.
I still don't know exactly how the filter works, but if there's no way to estimate lost range it's as useful as overdenoising. You are "gaining" partly, there's a range you are actually losing.

[LaTo]

with bright_limit as default, I went to the brightiest spot (many values compressed at 255) and lowered parameter up to 1.1 where (most) range was within 16-235.
I still don't know exactly how the filter works, but if there's no way to estimate lost range it's as useful as overdenoising. You are "gaining" partly, there's a range you are actually losing.

As I already said previously:
And for Limiter(), yes there is no solution unless you want to use "AutoGain(dark_exclude=0,bright_exclude=0,temporal_radius=0)"
Set "dark_exclude=0, bright_exclude=0", to eliminate 99% of your problem.
But this will have some outside range values, use "temporal_radius=0" if you want but it will be jerky.

And I still do not have screenshot or sample or script or ..., so I talk without seeing anything...

[LaTo]

v1.00:
first stable version

Finally :D

[Reel.Deel]

Hi LaTo, congratulations on your advancement. :)

One odd thing though, the 2.6 version worked since beta8 but it does not with v1.00. I tried both MSVC and ICL, x86 only and the same error.

VirtualDub Error
---------------------------
Avisynth open failure:
Avisynth: access violation at 0x00000000 in C:\Documents and Settings\VirtualDub\VirtualDub.exe,
attempting to read from 0x00000000
(C:\AutoGain\Test.avs, line 6)


Here's the script:
LoadPlugin("AutoGain.dll")

# NTSC DVD Source
DGSource("X:\test.dgi")

AutoGain()

I'm using SEt's 2.6.0.3 MT 2012.05.16 (http://forum.doom9.org/showthread.php?t=148782). I have not tried it with the official or MT 2.6.0.4. Unfortunately I have to go to work right now :(. When I get some time I will try it out and report back.

[LaTo]

Hi LaTo, congratulations on your advancement. :)

One odd thing though, the 2.6 version worked since beta8 but it does not with v1.00. I tried both MSVC and ICL, x86 only and the same error.


Here's the script:
LoadPlugin("AutoGain.dll")

# NTSC DVD Source
DGSource("X:\test.dgi")

AutoGain()

I'm using SEt's 2.6.0.3 MT 2012.05.16 (http://forum.doom9.org/showthread.php?t=148782). I have not tried it with the official or MT 2.6.0.4. Unfortunately I have to go to work right now :(. When I get some time I will try it out and report back.
Hi!

AutoGain now uses the new interface from alpha4, so it will not work anymore with older versions.

[LaTo]

Hi LaTo, congratulations on your advancement. :)

One odd thing though, the 2.6 version worked since beta8 but it does not with v1.00. I tried both MSVC and ICL, x86 only and the same error.


Here's the script:
LoadPlugin("AutoGain.dll")

# NTSC DVD Source
DGSource("X:\test.dgi")

AutoGain()

I'm using SEt's 2.6.0.3 MT 2012.05.16 (http://forum.doom9.org/showthread.php?t=148782). I have not tried it with the official or MT 2.6.0.4. Unfortunately I have to go to work right now :(. When I get some time I will try it out and report back.

So finally, does it work?

I am waiting after this answer to do the same update for SmoothAdjust... :)

[Reel.Deel]

So finally, does it work?

I am waiting after this answer to do the same update for SmoothAdjust... :)

Whoops had no idea you where waiting on my answer, I assumed you had tried it with Avisynth alpha 4. Sorry. :o
But yes it works correctly with the SEt's latest MT alpha 4.

[LaTo]

Whoops had no idea you where waiting on my answer, I assumed you had tried it with Avisynth alpha 4. Sorry. :o
But yes it works correctly with the SEt's latest MT alpha 4.

Np that's great, so I will update SmoothAdjust ;)

[LaTo]

Is "Avisynth 2.6 alpha4" a mandatory for AutoGain?

Given that I was asked the question elsewhere, I will answer here too: yes and no :)

You can use the builds inside "avs-2.5.x" for Avisynth 2.5.8 without problem, but if you use builds inside "avs-2.6.x" you need at least the new 2.6 alpha4 version.

[LaTo]

New version:
v1.02:
fixed minor things & bugs
dropped ICL builds support

[yup]

LaTo!
Last version very good and fast. I note this great work at fade in and out (source VHS capture).
Only one problem this slow down my script
see http://forum.doom9.org/showthread.php?p=1623465#post1623465
I replace
ColorYUV(autogain=true, autowhite=true)
to
AutoGain(adjust_mode=1).ColorYUV(autogain=false, autowhite=true)
and speed drop from 8 fps to 2 fps.
I am add threads_count=1 the same issue.
When I tryt autogain separately speed will be O'k.
Please advice.
yup.

[LaTo]

LaTo!
Last version very good and fast. I note this great work at fade in and out (source VHS capture).
Only one problem this slow down my script
see http://forum.doom9.org/showthread.php?p=1623465#post1623465
I replace
ColorYUV(autogain=true, autowhite=true)
to
AutoGain(adjust_mode=1).ColorYUV(autogain=false, autowhite=true)
and speed drop from 8 fps to 2 fps.
I am add threads_count=1 the same issue.
When I tryt autogain separately speed will be O'k.
Please advice.
yup.
AutoGain is slower than ColorYUV... but not that much (4 times slower here), try increasing cache_size because you're using a lot of temporal filters.

[LaTo]

v1.40:
used new C++11 features
rewritten multi-threading (native)
speed optimization (10% faster)
exception-safe code
added a high quality interpolation mode
improved core algorithm
fixed various little things

Big update :)

Please feel free to report any bugs and problems...

[yup]

Hi Lato!

Thanks for update. I try new release.
Script1
SetMemoryMax(3072)
AVISource("cap1.avi")
AssumeTFF()
ConverttoYV12(interlaced=true)
Crop(16,12,-16,-12)
s=nnedi(field=-2,threads=0)
s.AutoGain(adjust_mode=1,threads_count=0,cache_size=60)
Stackvertical(last,s)
give speed rendering 30-70 fps.
Script 2
SetMemoryMax(3072)
setMTMode(3)
AVISource("cap1.avi")
setMTMode(2)
AssumeTFF()
ConverttoYV12(interlaced=true)
Crop(16,12,-16,-12)
s=nnedi(field=-2,threads=1)
s.AutoGain(adjust_mode=1,threads_count=1,cache_size=60)
Stackvertical(last,s)
give speed rendering 8-20 fps.
Aisynth 2.6 Set last version.
Strange behavior.
I try plugin from tritical with the same approach and do not see big difference in fps.
I try change cache_size up to 480 without success.
yup.