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.

[LaTo]

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.

External MT with AutoGain is not a good idea, simply because it need the full video frame to do statistics computation.
And moreover, it is not stable and a bit borked. Always use internal MT when provided by plugin's author.

[LaTo]

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

[yup]

LaTo!
:thanks:
Now work fine with Set build.
yup.

[yup]

Hi Lato!
I am testing new version with Avsmeter.
script without MT
AVISource("cap1.avi").Trim(10000,11000)
AssumeTFF()
ConvertToYV12(interlaced=true)
b=nnedi3(field=-2)
b.AutoGain(b.Crop(16,12,-16,-12),adjust_mode=1)
AVSMeter log
Active MT Mode: 0

Number of frames: 2002
Length (hhh:mm:ss.ms): 000:00:40.040
Frame width: 720
Frame height: 576
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 2002 (0 - 2001)
FPS (min | max | average): 4.35 | 433.48 | 146.10
CPU usage (average): 60%
Thread count: 44
Physical Memory usage (peak): 171 MB
Virtual Memory usage (peak): 172 MB
Time (elapsed): 000:00:13.703

Script with MT mode
SetMTMode(3,8)
AVISource("cap1.avi").Trim(10000,11000)
SetMTMode(2,8)
AssumeTFF()
ConvertToYV12(interlaced=true)
b=nnedi3(field=-2)
b.AutoGain(b.Crop(16,12,-16,-12),adjust_mode=1,threads_count=1)
AVSMeter log
Active MT Mode: 2

Number of frames: 2002
Length (hhh:mm:ss.ms): 000:00:40.040
Frame width: 720
Frame height: 576
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 2002 (0 - 2001)
FPS (min | max | average): 33.12 | 870.27 | 139.33
CPU usage (average): 93%
Thread count: 152
Physical Memory usage (peak): 588 MB
Virtual Memory usage (peak): 599 MB
Time (elapsed): 000:00:14.368
We can see that in both mode CPU using practically the same. For short chain filter all work fine.
Interesting thing if using autogain after complex filter like QTGMC
script
SetMemoryMax(3072)
SetMTMode(3,8)
AVISource("cap1.avi").Trim(10000,11000)
SetMTMode(2,8)
AssumeTFF()
ConvertToYV12(interlaced=true)
QTGMC()
AutoGain(adjust_mode=1, threads_count=1,temporal_radius=X)
for X=0
AVSMeter log
Active MT Mode: 2

Number of frames: 2002
Length (hhh:mm:ss.ms): 000:00:40.040
Frame width: 720
Frame height: 576
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 2002 (0 - 2001)
FPS (min | max | average): 5.05 | 383151.02 | 40.73
CPU usage (average): 69%
Thread count: 90
Physical Memory usage (peak): 646 MB
Virtual Memory usage (peak): 683 MB
Time (elapsed): 000:00:49.147
for X=1
Active MT Mode: 2

Number of frames: 2002
Length (hhh:mm:ss.ms): 000:00:40.040
Frame width: 720
Frame height: 576
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 2002 (0 - 2001)
FPS (min | max | average): 4.96 | 287363.25 | 34.43
CPU usage (average): 49%
Thread count: 94
Physical Memory usage (peak): 642 MB
Virtual Memory usage (peak): 683 MB
Time (elapsed): 000:00:58.142
for X=2
Active MT Mode: 2

Number of frames: 2002
Length (hhh:mm:ss.ms): 000:00:40.040
Frame width: 720
Frame height: 576
Framerate: 50.000 (50/1)
Colorspace: YV12

Frames processed: 2002 (0 - 2001)
FPS (min | max | average): 4.84 | 156743.59 | 22.68
CPU usage (average): 26%
Thread count: 92
Physical Memory usage (peak): 639 MB
Virtual Memory usage (peak): 683 MB
Time (elapsed): 000:01:28.263
We can see how fps decrease with increasing temporal_radius.
For default setting temporal_radius=20 speed drastically drop to 1.5 fps.
yup.

[cretindesalpes]

QTGMC is not exactly a lightweight filter. I guess you’re facing a cache issue and for some reason the frames requested from the QTGMC filter graph are recalculated again and again instead of being cleverly stored in cache.

[yup]

I guess you’re facing a cache issue and for some reason the frames requested from the QTGMC filter graph are recalculated again and again instead of being cleverly stored in cache.
This issue solved in last IanB build? And we need waiting from SeT?
Please precise.
yup.

[yup]

Hi all!
I change order for filters
SetMemoryMax(3072)
SetMTMode(3,8)
AVISource("cap1.avi").Trim(10000,11000)
SetMTMode(2,8)
AssumeTFF()
ConvertToYV12(interlaced=true)
SeparateFields()
AutoGain(adjust_mode=1, threads_count=1,temporal_radius=20)
Weave()
QTGMC()
#AutoGain(adjust_mode=1, threads_count=1,temporal_radius=3)
And now all work with full speed.
yup.

[nhope]

I have a lot of footage from Sony cameras where the blacks are at about 20 and the whites are at 255. I would like an "auto" way to get the blacks to 16 and the whites to 235 for general footage with a high dynamic range.

Using AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00) as suggested previously, the blacks come out at about 16, which is where I want them, but I can't find a setting to roll the whites off to 235. The highlights remain at or close to 255 so they clip and a little detail is lost. Is there a setting that can roll off the white to 235 or should I look at a different filter? This is probably similar to what PDyksma and Dogway were asking, but I want to be sure.

[LaTo]

I have a lot of footage from Sony cameras where the blacks are at about 20 and the whites are at 255. I would like an "auto" way to get the blacks to 16 and the whites to 235 for general footage with a high dynamic range.

Using AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00) as suggested previously, the blacks come out at about 16, which is where I want them, but I can't find a setting to roll the whites off to 235. The highlights remain at or close to 255 so they clip and a little detail is lost. Is there a setting that can roll off the white to 235 or should I look at a different filter? This is probably similar to what PDyksma and Dogway were asking, but I want to be sure.

I will add another option later for this (AutoGain doesn't allow to compress range).

[LaTo]

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

[LaTo]

I have a lot of footage from Sony cameras where the blacks are at about 20 and the whites are at 255. I would like an "auto" way to get the blacks to 16 and the whites to 235 for general footage with a high dynamic range.

Using AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00) as suggested previously, the blacks come out at about 16, which is where I want them, but I can't find a setting to roll the whites off to 235. The highlights remain at or close to 255 so they clip and a little detail is lost. Is there a setting that can roll off the white to 235 or should I look at a different filter? This is probably similar to what PDyksma and Dogway were asking, but I want to be sure.
Try "AutoGain(input_tv=false)" :)

[nhope]

Thanks for the update LaTo.

I have been testing with real footage, then by inputting a 20-255 gradient to simulate my typical footage, using AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00,input_tv=false,output_tv=true)

Unfortunately the output is stretched to 0-255 rather than adjusted to 16-235. Same if I try input_tv=true. If I set output_tv=false then there is more clipping, as expected.

[LaTo]

Thanks for the update LaTo.

I have been testing with real footage, then by inputting a 20-255 gradient to simulate my typical footage, using AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00,input_tv=false,output_tv=true)

Unfortunately the output is stretched to 0-255 rather than adjusted to 16-235. Same if I try input_tv=true. If I set output_tv=false then there is more clipping, as expected.

It works on my test clip, can you provide a short sample?

[nhope]

Uncompressed 320x240 avi gradient, 20-255: https://dl.dropboxusercontent.com/u/21489814/uncompressed-20-255.avi

And my script is:

AviSource("e:\uncompressed-20-255.avi")
ConvertToYV12()
AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00,input_tv=false,output_tv=true)

The output is a 0-255 gradient. I can provide real-life footage, or screengrabs of scopes if it helps.

[LaTo]

All is working as expected on my side, I used this script:

src = AviSource("uncompressed-20-255.avi")
src_ok = src.ConvertToYV12(matrix="pc.601")

src_tv = src.ConvertToYV12().Histogram(mode="levels").subtitle("""ConvertToYV12()\nWRONG (PC->TV conv)""",lsp=10)
src_full = src.ConvertToYV12(matrix="pc.601").Histogram(mode="levels").subtitle("""ConvertToYV12(matrix="pc.601")\nRIGHT (20-255 gradient)""",lsp=10)

tv_tv = src_ok.AutoGain(dark_exclude=0.00,bright_exclude=0.00,input_tv=true,output_tv=true).Histogram(mode="levels").subtitle("input_tv=true & output_tv=true")
tv_full = src_ok.AutoGain(dark_exclude=0.00,bright_exclude=0.00,input_tv=true,output_tv=false).Histogram(mode="levels").subtitle("input_tv=true & output_tv=false")
full_tv = src_ok.AutoGain(dark_exclude=0.00,bright_exclude=0.00,input_tv=false,output_tv=true).Histogram(mode="levels").subtitle("input_tv=false & output_tv=true")
full_full = src_ok.AutoGain(dark_exclude=0.00,bright_exclude=0.00,input_tv=false,output_tv=false).Histogram(mode="levels").subtitle("input_tv=false & output_tv=false")

stackhorizontal(stackvertical(src_tv,src_full,tv_tv),stackvertical(tv_full,full_tv,full_full))

And the result:

http://imageshack.us/a/img703/4717/34ad.th.png (http://imageshack.us/a/img703/4717/34ad.png)
(Click to enlarge)

NB: you should use ConvertToYV12(matrix="pc.601") instead of ConvertToYV12() to keep the full range of the gradient

[nhope]

Thanks LaTo.

I get the same result in the AviSynth histograms as you if I use your script. Now I have to figure out why the output .avi decodes to 0-255 in Vegas Pro.

I had actually tried pc.601 already, as well as rec601, and it didn't make a difference in the luminance range, which is to be expected because Autogain is doing its job. rec601 gives the right result for most of my other work (frameserving from Vegas Pro to QTGMC, MDegrain etc.) when I render to a lossless avi in VirtualDub.

So, if I use this...

AviSource("e:\uncompressed-20-255.avi")
ConvertToYV12(matrix="pc.601")
AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00,input_tv=false,output_tv=true)
Histogram(mode="levels")

...then the histogram looks like your correct 16-235 one, middle right. So then I remove the last line and render out to uncompressed AutoGained.avi in VirtualDub, then run the output through this script:

AviSource("e:\AutoGained.avi")
ConvertToYV12(matrix="rec601")
Histogram(mode="levels")

That gives the 16-235 histogram again. If I use pc.601 in that last script then the histogram shows 0-255. If I open it in Vegas Pro, the histogram shows 0-255. Any idea what I'm doing wrong? Maybe a VirtualDub-related issue?

[LaTo]

No idea, it seems there is a TV->PC conversion somewhere... Maybe there is an option to choice between TV or PC range when importing a video?!?

[poisondeathray]

@nhope - How do you have vegas setup ? and the scopes set up ? studio RGB ? what "lossless" format are you using ?

It's likely an vegas issue with studio RGB vs. computer RGB , and how it handles different input formats . Most "lossless AVI" compression in YV12 aren't treated as YV12 in vegas (so they aren't really "lossless" in vegas)

For example, lagarith in yv12 mode is treated as computer RGB (and gets computer RGB 0-255 treatment, instead of studio RGB treatment)

e.g
I've included 2 files in this 7zip file . Both are the same levels if you use histogram("levels") in avisynth, but vegas treats the lagarith file as computer RGB
http://www.mediafire.com/?8bk71rqwehp5dnn




AviSource("uncompressed-20-255.avi")
ConvertToYV12(matrix="pc.601")
AutoGain(adjust_mode=1,dark_exclude=0.00,bright_exclude=0.00,input_tv=false,output_tv=true)




VDUB_IYUV.avi is uncompressed with "IYUV" fourcc

VDUB_LAGS_YV12.avi is lagarith in YV12 mode


Certain versions of vegas even treat different uncompressed fourcc's differently . This has been discussed in another thread here @ Doom9

[nhope]

Thanks very much poisondeathray. I'm using Vegas Pro 10.0e and I see the difference in your 2 files.

In the Vegas Preview Device preferences I have "Use color management" checked, "Use Studio RGB (16-235)" checked, and "sRGB Color Space Profile.icm" selected.

In the scopes I have "Studio RGB (16 to 235)" checked so that I'm seeing 16-235 as 0-100 on the waveform. I have "7.5 IRE Setup" unchecked.

My typical workflow is to edit/correct my source DV, HDV etc. on the timeline, frameserve RGB24 with Debugmode Framrserver, ConvertToYV12 then QTGMC etc. in AviSynth, render out a lossless intermediate in VirtualDub with the "Ut Video Codec RGB (ULRG) VCM x86 codec", and put that back on the Vegas Pro timeline for further work (titles, transitions etc.) before a final render to MeGUI for x264 or CinemaCraft Basic for MPEG-2.

I only render RGB out of VirtualDub because I know Vegas Pro works in RGB internally, so I don't want an extra conversion. I've found UT Video Codec (with "optimize for decoding speed" checked) more zippy on the timeline than Lagarith. I found Lagarith RGB has the same levels output in Vegas as UT RGB, and I also tested AutoGain with uncompressed avi output.

Nearly all my AviSynth scripts have this choice of line near the top of them, established basically through trial and error, depending on what I'm rendering to...

...
#ConvertToYV12(interlaced=true, matrix="PC.709") #For frameserved RGB to x264 in MeGUI
ConvertToYV12(interlaced=true, matrix="Rec601") #For frameserved RGB to Ut Video Codec or Lagarith in Vdub
...

Not quite sure how to adjust my workflow to take advantage of AutoGain.

[poisondeathray]

This is more of a Vegas issue and not an AutoGain issue, and I don't wan't to "pollute" this thread

Vegas has a lot of "quirks" (most NLE's do ). If you haven't already, read Glenn Chan's articles about vegas, levels, color etc... how it handles different formats

The general rule is Vegas handles most native camera formats (AVCHD, DV, XDCAM, HDV) as YUV and give it studio RGB treatment. So your normal workflow is fine. Most other formats, including "lossless" YUV codecs get computer RGB treatment.

Using "lossless" YV12 intermediates in vegas becomes a problem when you have superbrights or superdarks . They get clipped in vegas, unless you adjust for them beforehand, or use a format which vegas treats as "studio RGB"

You can think of "Computer RGB" in vegas is as using avisynth's "rec" matrices. Y' 16-235 gets "mapped" to RGB 0,0,0 -255,255,255 in 8bit mode . So both ends are clipped

You can think of "Studio RGB" in vegas as using avisynth "PC" matrices . Y' 0-255 gets "mapped" to RGB 0,0,0-255,255,255 in 8bit mode . The full range is preserved
(*not quite, it's slightly different, and there is actually an avisynth studio RGB function by trevlac )
http://forum.doom9.org/showthread.php?p=639432#post639432

Notice that your frameserving to MeGUI uses the "PC" matrix in stead of the normal "Rec" matrix. The reason is you're using studio RGB in vegas you need to do the reverse of what was done . (The correct matrix would actually be the studio RGB function)

You've already discovered if you convert to RGB with avisynth before, and use a RGB intermediate for everything, then the results are predictable. The reason is all these levels problems can be traced back to vegas' handling of studio RGB vs. computer RGB - and that only has to do with YUV<=> RGB conversion . So if you're in RGB the entire workflow while in vegas , then there will be no issues. Use avisynth to control the conversions. Even some export formats are done differently in vegas depending on what you choose (sometimes you need to temporarily add a computerRGB to studioRGB filter - either for render or for preview - because vegas "expects" certain formats to be in studio or computer RGB)


Not quite sure how to adjust my workflow to take advantage of AutoGain.


If using AutoGain before importing to vegas, you would have to use a format that vegas treats as Studio RGB . No lossless codecs that I know of. Certain uncompressed fourcc's "IYUV" get studio RGB in most versions of vegas. However, uncompressed "YV12" doesn't in certain versions of vegas. So you have to be careful and do some testing. Cineform (not lossles, but visually lossless) does get Studio RGB treatment . Either that or convert to RGB beforehand using avisynth so you can control it (matrix used, interlaced vs. progressive) . It doesn't really make sense IMO to use AutoGain after exporting from vegas

[nhope]

Thank you poisondeathray for your explanation, which I am getting my head around. I need to read Glenn's articles again, draw myself some diagrams, and make myself a spreadsheet of codec behaviour in Vegas.

As it stands, I don't think I'd want to AutoGain footage before getting it onto the Vegas timeline for the first time, as I think that would limit my color correction latitude. In my existing workflow I color-correct and conform my levels to 16-235 all in a single instance of Color Curves in Vegas Pro (sometimes with a Secondary Color Corrector afterwards), and that works well although it's fiddly and labour-intensive (which is why I investigated AutoGain).

I'll leave my Vegas issues out of the thread now. Apologies LaTo for the derailment.

As a suggestion, it would be very interesting for someone to tackle a filter that combines AutoGain with Automatic White Balance (http://forum.doom9.org/showthread.php?t=168062).

[LaTo]

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

[LaTo]

v1.90:
changed name of plugin & parameters
added color balance
added C version
fixed regression from v1.75 (bug at scenechange)
Gain & balance adjustments are off by default (NOP filter).
You need to enable them yourself: AutoAdjust(auto_gain=true, auto_balance=true).

Auto balance is very basic but several people have requested this so... :)

Please feel free to report any bugs, there is a lot of changes in this version.

[alexx7777]

Please tell me which parameter you want to adjust for the effect of Auto Levels, so it was like a Autolevels.
Tried to change various settings autoadjust, but values ​​vary in the level of the entire length of the video. There is none like after autolevel. Source video 16-235. After applying

AutoAdjust (auto_balance = true, gain_mode = 1, auto_gain = true,,dark_limit = 10, bright_limit = 10, gamma_limit = 10, chroma_process = 100, balance_str = 1)
Then check the command Coloryuv (analyze = true), Los Minimum and Maximum change.
Please tell me what to change to a constant value Los minimum and maximum? Then check the command Coloryuv (analyze = true), Los Minimum and Maximum change. Sometimes a maximum number of 236 to 241, a minimum of changes from 15 to 19. Please tell me what to change to a constant value of 16 and 235, as after Autolevels - ? http://www.thebattles.net/video/autolevels.html


Try for one video filter
AutoAdjust(gain_mode=1,auto_gain=true,balance_str=1,dark_limit=10,bright_limit=10,gamma_limit=10,chroma_process=100,avg_safety=1,auto_balance=true,chroma_limit=1.05,cache_size =60,high_quality=true,scd_threshold=16, temporal_radius=30)
http://www.youtube.com/watch?v=esGDIj7SeFU&feature=youtu.be
Such result has turned out, what parameters you can fix to Loose Minimum=15, max=235 throughout the video?

[LaTo]

Please tell me which parameter you want to adjust for the effect of Auto Levels, so it was like a Autolevels.
Tried to change various settings autoadjust, but values ​​vary in the level of the entire length of the video. There is none like after autolevel. Source video 16-235. After applying

AutoAdjust (auto_balance = true, gain_mode = 1, auto_gain = true,,dark_limit = 10, bright_limit = 10, gamma_limit = 10, chroma_process = 100, balance_str = 1)
Then check the command Coloryuv (analyze = true), Los Minimum and Maximum change.
Please tell me what to change to a constant value Los minimum and maximum? Then check the command Coloryuv (analyze = true), Los Minimum and Maximum change. Sometimes a maximum number of 236 to 241, a minimum of changes from 15 to 19. Please tell me what to change to a constant value of 16 and 235, as after Autolevels - ? http://www.thebattles.net/video/autolevels.html


Try for one video filter
AutoAdjust(gain_mode=1,auto_gain=true,balance_str=1,dark_limit=10,bright_limit=10,gamma_limit=10,chroma_process=100,avg_safety=1,auto_balance=true,chroma_limit=1.05,cache_size =60,high_quality=true,scd_threshold=16, temporal_radius=30)
http://www.youtube.com/watch?v=esGDIj7SeFU&feature=youtu.be
Such result has turned out, what parameters you can fix to Loose Minimum=15, max=235 throughout the video?

I did not understand everything, but basically you want to get 16 & 235 minima/maxima in the whole clip?!?
You can't get always 16/235 unless you turn off the temporal averaging...

But you can change the filter to be less smart.
Try:
AutoGain(auto_gain=true, gain_mode=1, dark_limit=10, bright_limit=10, avg_safety=1, input_tv=false, output_tv=true)
Limiter() # Clipping will be negligible or use temporal_radius=0

[alexx7777]

Thank You for the answer. Tried AutoAdjust(auto_gain=true, gain_mode=1, dark_limit=10, bright_limit=10, avg_safety=1, input_tv=true, output_tv=true,temporal_radius=0).
Without "Limiter()". Result - http://www.youtube.com/watch?v=ybaRdA6Yryk&feature=youtu.be. Please tell me what setting should be changed to "Loose minimum" equal to 16. Source Pal video, image compression Format H.264 (MPEG-4.AVC) 1920 x 1080 50i TFF. input_tv=true - must be true for this video?

[LaTo]

Try with dark_ignore=0, bright_ignore=0.

But why not clamp these values or leave them like that?
Disabling features of auto_gain will result in a less stable result.

[cybersharky]

I've been playing with:
AutoAdjust(auto_balance=true, auto_gain=true, input_tv=true, output_tv=false,
high_quality=true, gain_mode=1,dark_limit=10, bright_limit=10)

To see what settings to use to encode Stargate SG1 Season 5, but some parts still appear too bright.

https://dl.dropboxusercontent.com/u/47490038/VTS_01_1020572.png
https://dl.dropboxusercontent.com/u/47490038/VTS_01_1030231.png
https://dl.dropboxusercontent.com/u/47490038/VTS_01_1035736.png

[LaTo]

I've been playing with:
AutoAdjust(auto_balance=true, auto_gain=true, input_tv=true, output_tv=false,
high_quality=true, gain_mode=1,dark_limit=10, bright_limit=10)

To see what settings to use to encode Stargate SG1 Season 5, but some parts still appear too bright.

https://dl.dropboxusercontent.com/u/47490038/VTS_01_1020572.png
https://dl.dropboxusercontent.com/u/47490038/VTS_01_1030231.png
https://dl.dropboxusercontent.com/u/47490038/VTS_01_1035736.png

Remove "dark_limit=10, bright_limit=10", this isn't safe... Something between 1.0 and 2.0 is a good value.

[alexx7777]

cybersharky
Have you tried - "output_tv=true"?

[alexx7777]

Lato

Thank you, I can't find in the description of the Transformed parameters such - "dark_ignore=0, bright_ignore=0".

[cybersharky]

cybersharky
Have you tried - "output_tv=true"?

Yes, but I don't want tv range output.

[cybersharky]

Lato

Thank you, I can't find in the description of the Transformed parameters such - "dark_ignore=0, bright_ignore=0".

You mean this:
dark_exclude [default: 0.50]
----------------------------
Amount of excluded darkest pixels in "mimimum" calculation (in percentile of pixels)
0.0 = no excluded pixels
1.0 = 1% of excluded pixels

bright_exclude [default: 0.50]
------------------------------
Amount of excluded brightest pixels in "maximum" calculation (in percentile of pixels)
0.0 = no excluded pixels
1.0 = 1% of excluded pixels

[alexx7777]

cybersharky
Thank You, with these parameters also can't reach the goal. I will continue to try.

[alexx7777]

AutoAdjust будет работать с setmtmode (x) - . То, что x-это лучше?
Setmtmode(5)
DirectShowSource("video")
Setmtmode(x)
SeparateFields()
AutoAdjust()
Weave()

[list]

This plugin is fantastic!
It's only weakness is it's too slow and not open source. But anyway, it's awesone. Thaks bro! :)
PD: Why is auto_gain=false by default? It took me a lot of time until notice that and made it work.

[LaTo]

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
Update :)

[list]

Update :)
Great plugin. Keep it up!

[elraffa]

I have a problem with V2..show up "Runtime error 203 at OBDE6650".. I use madvr

[LaTo]

I have a problem with V2..show up "Runtime error 203 at OBDE6650".. I use madvr
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, 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)

[elraffa]

I´m sorry, I didnt know that..
Here are the info:

- windows 7x64 sp1
- cpu: i5 3550; motherboard: gigabyte GA-Z77-DS3H; videocard: asus gtx 770; RAM: 4gb
- avisynth v2.6.0 Alpha 5 [130918]
- crash when I open any movie at the start
- when I copy x64 autoadjust.dll to plugin avisynth folder, I get this error "script error: there is no function named autoadjust (ffdshow_filter_avisynth_script, line 6)"
when I copy x86 autoadjust.dll to avisynth folder, sometimes I get window error: Runtime error 203 at OBDE6650...or I get "potplayer has stopped working" with this problem signature:

Problem signature:
Problem Event Name: APPCRASH
Application Name: sumire.exe
Application Version: 0.0.0.0
Application Timestamp: 531403b4
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7601.18229
Fault Module Timestamp: 51fb1116
Exception Code: 0eedfade
Exception Offset: 0000c41f
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 11274
Additional Information 1: 1d41
Additional Information 2: 1d412bcc3dc1d3659ec976513c927dfe
Additional Information 3: a6cb
Additional Information 4: a6cb4f8277dbb35903acd632935d9db3

- I use potplayer with madvr, lav filters and ffdshow (rev4515_20130612_clsid) raw video filter with only avisynth section enabled. My script is in ffdshow is:

SetMemoryMax(1024)
SetMTMode(3,4)
ffdshow_source()
SetMTMode(2)
FineSharp(sstr=1.5)
AutoAdjust(auto_gain=true, auto_balance=true, balance_str=1.0)
SmoothTweak(saturation=1.5, useMT=0, useOPT=1)
Tweak(sat=0.9, startHue=90, endHue=180, maxSat=150, interp=32, dither=true) # Desaturate Red
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

I tried disabling finesharp, smoothtweak and tweak but I get the same errors. With autoadjust v1.90 this didnt happen

- properties of the video:
Format : Matroska
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 6 frames
Bit rate : 3 019 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.137

I hope you can solve my problem..thanks

[LaTo]

I´m sorry, I didnt know that..
Here are the info:

- windows 7x64 sp1
- cpu: i5 3550; motherboard: gigabyte GA-Z77-DS3H; videocard: asus gtx 770; RAM: 4gb
- avisynth v2.6.0 Alpha 5 [130918]
- crash when I open any movie at the start
- when I copy x64 autoadjust.dll to plugin avisynth folder, I get this error "script error: there is no function named autoadjust (ffdshow_filter_avisynth_script, line 6)"
when I copy x86 autoadjust.dll to avisynth folder, sometimes I get window error: Runtime error 203 at OBDE6650...or I get "potplayer has stopped working" with this problem signature:

Problem signature:
Problem Event Name: APPCRASH
Application Name: sumire.exe
Application Version: 0.0.0.0
Application Timestamp: 531403b4
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7601.18229
Fault Module Timestamp: 51fb1116
Exception Code: 0eedfade
Exception Offset: 0000c41f
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 11274
Additional Information 1: 1d41
Additional Information 2: 1d412bcc3dc1d3659ec976513c927dfe
Additional Information 3: a6cb
Additional Information 4: a6cb4f8277dbb35903acd632935d9db3

- I use potplayer with madvr, lav filters and ffdshow (rev4515_20130612_clsid) raw video filter with only avisynth section enabled. My script is in ffdshow is:

SetMemoryMax(1024)
SetMTMode(3,4)
ffdshow_source()
SetMTMode(2)
FineSharp(sstr=1.5)
AutoAdjust(auto_gain=true, auto_balance=true, balance_str=1.0)
SmoothTweak(saturation=1.5, useMT=0, useOPT=1)
Tweak(sat=0.9, startHue=90, endHue=180, maxSat=150, interp=32, dither=true) # Desaturate Red
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

I tried disabling finesharp, smoothtweak and tweak but I get the same errors. With autoadjust v1.90 this didnt happen

- properties of the video:
Format : Matroska
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 6 frames
Bit rate : 3 019 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.137

I hope you can solve my problem..thanks
Thanks for these informations!

Is this still crashing when you remove all the MT stuff?
What MT build are you using?

[elraffa]

Excuse my ignorance...what is MT?

[LaTo]

Excuse my ignorance...what is MT?
MT = Multi-Threading

You seems to use it because of your script:
SetMemoryMax(1024)
SetMTMode(3,4)
ffdshow_source()
SetMTMode(2)
FineSharp(sstr=1.5)
AutoAdjust(auto_gain=true, auto_balance=true, balance_str=1.0)
SmoothTweak(saturation=1.5, useMT=0, useOPT=1)
Tweak(sat=0.9, startHue=90, endHue=180, maxSat=150, interp=32, dither=true) # Desaturate Red
SetMTMode(1)
GetMTMode(false) > 0 ? distributor() : last

Can you try this one:
ffdshow_source()
FineSharp(sstr=1.5)
AutoAdjust(auto_gain=true, auto_balance=true, balance_str=1.0)
SmoothTweak(saturation=1.5, useMT=0, useOPT=1)
Tweak(sat=0.9, startHue=90, endHue=180, maxSat=150, interp=32, dither=true) # Desaturate Red

[elraffa]

Can you try this one:
ffdshow_source()
FineSharp(sstr=1.5)
AutoAdjust(auto_gain=true, auto_balance=true, balance_str=1.0)
SmoothTweak(saturation=1.5, useMT=0, useOPT=1)
Tweak(sat=0.9, startHue=90, endHue=180, maxSat=150, interp=32, dither=true) # Desaturate Red

Thanks..I tried that script and now I can play the movie but sometimes it plays fine (without dropped frames) and sometimes it has dropped frames (and gpu usage down to 0%)

[LaTo]

Thanks..I tried that script and now I can play the movie but sometimes it plays fine (without dropped frames) and sometimes it has dropped frames (and gpu usage down to 0%)
Sorry I can't reproduce the crash right now...

Is this working? :
SetMemoryMax(1024)
SetMTMode(5,4)
ffdshow_source()
SetMTMode(1,4)
AutoAdjust(auto_gain=true, auto_balance=true, balance_str=1.0)
GetMTMode(false) > 0 ? distributor() : last

Are other AvsMT users experiencing this problem?


edit: Ok I reproduced the crash, i will investigate...

[yup]

Hi Lato!


Are other AvsMT users experiencing this problem?



I am also have problem with last version autoAdjust, my script crash, before work without problem.
yup.

[LaTo]

I found the problem, it's the combination of ffdshow_source() and AvisynthMT which crash the process.

In fact ffdshow_source() always returns num_frames=10810800 which corresponds to 100hours of video at 30fps.

AutoAdjust create an array at startup using the num_frames number.
For example, a 2h clip at 30fps need a 5MB array, this is acceptable.
But for a 100hours clip, it's 5*50=250MB... this is a lot.

Now add the use of AvsMT in multi-instance mode (2 or more).
For 4 threads, it's 4*250MB=1000MB.
For 8 threads, it's 8*250MB=2000MB.
The 2GB limit is reached and Avisynth crash entirely... Previous version was not crashing, because it needed a little less memory (it was already nearly at the limit).

So in the end, uses AutoAdjust with SetMTMode(1,x): it will be faster and it will not crash.
Later I will try to optimize memory usage for this special case with dynamic data.

Please, tell me if this solves the problem :)

[yup]

Hi Lato!

You are right script work if before AutoAdjust use SetMTMode(1). I am tested clip near 2 hours and avisorce.

yup.

[elraffa]

Is this working? :
SetMemoryMax(1024)
SetMTMode(5,4)
ffdshow_source()
SetMTMode(1,4)
AutoAdjust(auto_gain=true, auto_balance=true, balance_str=1.0)
GetMTMode(false) > 0 ? distributor() : last


with this last script, avisynth doesn't crash anymore...thanks lato :)

[Overdrive80]

Hi all, my question is how I get similars results than using AWB bit with this filter. Thanks.

[hydra3333]

For various reasons I'm stuck using TSP's 2.5.7.

I looked for the latest patched version of AutoAdjust (v1.90?) which is likely compatible with 2.5.7 but couldn't find the download.

LaTo, pretty please can you make it available ? (and the same for smoothadjust)

[hydra3333]

I believe that's AutoAdjust v1.02 rather than the last AutoAdjust v1.90.
I also checked LaTo's download folder where the .7z's come from and 1.90 isn't there.

[Motenai Yoda]

I have some freeze on video at some sc with 2.0, also some frames show freezed chroma
:rolleyes:

[LaTo]

I have some freeze on video at some sc with 2.0, also some frames show freezed chroma
:rolleyes:

... Oups ...

I have a problem with V2..show up "Runtime error 203 at OBDE6650".. I use madvr
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, 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)

[LemMotlow]

I believe that's AutoAdjust v1.02 rather than the last AutoAdjust v1.90.
I also checked LaTo's download folder where the .7z's come from and 1.90 isn't there.Looks like we're all stuck with 1.02. I believe 1.90 was posted this past December for about 15 minutes (last seen early January 2014).

[hydra3333]

Oh dear.

[Motenai Yoda]

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
- w8.1 update 1 x86-64
- i7 920 d0
- lastest Set's 2.6
- no error message
- no crash
- dss2(source)
AutoAdjust(auto_gain=true,high_quality=true,gain_mode=1,avg_safety=1.0,auto_balance=true,temporal_radius=-1)
- m2ts of shingeki no kyojin op (I'm trying with this 'cause has a lot of brightness fluctuations)

with lossless as source it doesn't freeze, maybe a non linear frame request?

I've tryed to put RequestLinear before, but it give me error
http://thumbnails112.imagebam.com/33217/c13a77332164806.jpg (http://www.imagebam.com/image/c13a77332164806)

[Groucho2004]

AutoAdjust(auto_gain=true,high_quality=true,gain_mode=1,avg_safety=1.0,auto_balance=true,temporal_radius=-1)
That's your entire script? No SetMTMode? No loading of plugins?

[SamKook]

He also has: dss2(source)

"latest" isn't what I'd call an exact avisynth version though

[Motenai Yoda]

@groucho no but for those that I use most often I put them into autoload folder.

@samkook 2013.09.28 is more accurate? :confused:

also I notice that with output_tv=true it doesn't clip to 16/235-16/240 too.

original
http://www.mediafire.com/download/8rqrt0gw1bs227b/Opening_01_SNK2.split.1.m2ts
filtered
https://www.mediafire.com/?xh2h60p9oxrosne

[LaTo]

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

[LaTo]

I looked for the latest patched version of AutoAdjust (v1.90?)
LaTo, pretty please can you make it available ? (and the same for smoothadjust)
Sorry I do not have these binaries anymore.

AutoAdjust(auto_gain=true,high_quality=true,gain_mode=1,avg_safety=1.0,auto_balance=true,temporal_radius=-1)
Try without temporal_radius=-1 please and report here (and try the new v2.20 too).
This setting should never be used in realtime viewing but only in encoding. It's like "temporal_radius=infinite", so if your scene is 99999 frames long it will request all the 99999 frames at scenechange...

also I notice that with output_tv=true it doesn't clip to 16/235-16/240 too.
input_tv/output_tv are only used as 'control points',
if you want clipping you should use Limiter() after AutoGain().

[LaTo]

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

Update :)


edit: Motenai Yoda> try this new version, your sample helped me to fix this issue, thanks for report!

[videoFred]

Hello,

I'm using AutoAdjust with AvsPmod.

But first: what an awesome filter is this! Finaly we have a good working autolevels and autowhite filter.
I'm using it all the time now and it does miracles with old 8mm film capturings.

Second: AvsPmod is great too! Finaly we can use sliders for setting filter parameters!

But I have an annoying problem, let me explain:

I have made AvsPmod sliders to create variables:
autoad_gamma = [<"autoadjust gamma limit", 1.0, 2.0, 1.5>]
autoad_dark = [<"autoadjust dark limit", 1.0, 2.0, 1.3>]
autoad_bright = [<"autoadjust bright limit", 1.0, 2.0, 1.1>]
autoad_pixels = [<"autoad exclude pixels", 0.0, 1.0, 0.1>]
autoad_chroma = [<"chroma process", 0, 200, 200>]
autoad_wb = [<"autoadjust white balance", 0.0, 1.0, 0.9>]
autoad_mode = [<"0= contrast 1 =levels", 0, 1, 1>]

Then I'm using these variables to set the parameters in AutoAdjust:
clip2 = clip1.AutoAdjust(auto_gain=true,dark_limit=autoad_dark,bright_limit=autoad_bright,gamma_limit=autoad_gamma,dark_exclude=autoad_pixels,bright_exclude=autoad_pixels,
gain_mode=autoad_mode,chroma_process=autoad_chroma,input_tv=false, output_tv=false,auto_balance= true, chroma_limit = 2.0, balance_str= autoad_wb, high_quality=true,debug_view=true)

Everything works like a charm except for one parameter: the white balance (balance_str). Sometimes I do not see the effect of this parameter in the AvsPmod preview. However, when I change the slider (autoad_wb), the script is updated immediately like it should be. It can be loaded in VDub and everything is fine. Only the AvsPmod preview is -sometimes- not updating. Strange enough, the updating works fine for all other parameters.

If I do not change any values with the sliders at all, and just use the refresh preview shortcut in AvsPmod (f5), then sometimes the white balance is gone, then again back, completely random.

Where do I have to find the solution for this problem? Is this an AvsPmod issue or an AutoAdjust issue? A Memory buffer not resetting or something?

Anyhow, I have posted this on both the AvsPmod and the AutoAdjust thread.

Thank you all in advance for having a look at this annoying problem and many greetings from Belgium,

Fred.

[vdcrim]

If I do not change any values with the sliders at all, and just use the refresh preview shortcut in AvsPmod (f5), then sometimes the white balance is gone, then again back, completely random.
It seems that something causes the balance to be nondeterministic. Reloading repeatedly the script in VirtualDub (F2) shows the same result. In fact it also happens if the script is only evaluated once:
"""Get a specific pixel from a planar YCbCr clip

Requires python 2 and avisynth.py from AvsPmod
https://github.com/AvsPmod/AvsPmod/raw/master/avisynth.py
"""


x, y = 480, 160
frame_number = 0

script = ur"""
FFVideoSource("C:\whatever.ext")
AutoAdjust(auto_balance=true, chroma_limit=2.0, balance_str=1.0)
"""


# ------------------------------------------------------------------------------


import avisynth

if not script:
with open('test.avs') as file:
script = file.read().decode('mbcs')

env = avisynth.AVS_ScriptEnvironment(3)
clip = env.invoke('Eval', [script, 'Title'])
vi = clip.get_video_info()
frame = clip.get_frame(frame_number)
pitchY = frame.get_pitch()
pitchUV = frame.get_pitch(avisynth.avs.AVS_PLANAR_U)
ptrY = frame.get_read_ptr()
ptrU = frame.get_read_ptr(avisynth.avs.AVS_PLANAR_U)
ptrV = frame.get_read_ptr(avisynth.avs.AVS_PLANAR_V)
indexY = x + y * pitchY
x = x >> vi.get_plane_width_subsampling(avisynth.avs.AVS_PLANAR_U)
y = y >> vi.get_plane_height_subsampling(avisynth.avs.AVS_PLANAR_U)
indexU = indexV = x + y * pitchUV
print ptrY[indexY], ptrU[indexU], ptrV[indexV]
del frame
del clip
del env

Run the python script above enough number of times and you'll get different values:
import subprocess

colors = set()
for i in range(100):
colors.add(subprocess.check_output(['python27', '-O', 'get_pixel.py']).strip())
for color in sorted(colors):
print color

Different preview for the same frame and script can happen if there's temporal filters on it that make use of metrics calculated on the previous frames (e.g. HDRAGC), but that should only happen when navigating the timeline. The current issue also occurs for a single requested frame though, so it must be a different thing.

[LaTo]

Hi!

I can't reproduce the bug, but I think I found the problem...

Can you try this test build?:
-> Here (http://latoninf.free.fr/d9/AA/AutoAdjust-TestBuild.7z)

Thanks for report!

[videoFred]

Hi!

I can't reproduce the bug, but I think I found the problem...

Can you try this test build?:


Thank you for the fast feedback and I'm going to test it right now, and I will report back later.

Fred.

[videoFred]

Problem solved! Thank you very much for the update LaTo!

A few before/after examples: old super-8 film from 1968.
(hehe.. that little boy is my brother... he's 54 now)

[/URL]

[URL="http://www.super-8.be/Doom/VideoFred_Autoadjust_AvspMod_002.jpg"]http://http://www.super-8.be/Doom/VideoFred_Autoadjust_AvspMod_002.jpg (http://www.super-8.be/Doom/VideoFred_Autoadjust_AvspMod_001.jpg)

http://http://www.super-8.be/Doom/VideoFred_Autoadjust_AvspMod_003.jpg (http://www.super-8.be/Doom/VideoFred_Autoadjust_AvspMod_003.jpg)

As you can see, I do some color corrections first, then I apply AutoAdjust.
And for the final step, I use some minor red/blue adjustments.

many greetings,
Fred.

[johnmeyer]

Problem solved! Thank you very much for the update LaTo!

A few before/after examples: old super-8 film from 1968.
(hehe.. that little boy is my brother... he's 54 now)

<snip>

As you can see, I do some color corrections first, then I apply AutoAdjust.
And for the final step, I use some minor red/blue adjustments.Fred,

Any chance you will post, in one of your 8mm restoration threads, the updates to your script that use AutoAdjust? I was very impressed by the color grading you achieved, especially the greens. I have found it very difficult to get decent greens from my film transfers.

[videoFred]

Fred,

Any chance you will post, in one of your 8mm restoration threads, the updates to your script that use AutoAdjust? I was very impressed by the color grading you achieved, especially the greens. I have found it very difficult to get decent greens from my film transfers.

Hi John,

I will send you a PM

many greetings,
Fred.

[LaTo]

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

Hope all problems are fixed :)

[JK1974]

@videoFred: I would be also interested in you updated scripts. I never had bigger success with former color adjustment plugins, so an easier-to-use solution combined with your scripts would be fantastic.

[videoFred]

@videoFred: I would be also interested in you updated scripts. I never had bigger success with former color adjustment plugins, so an easier-to-use solution combined with your scripts would be fantastic.

The updated script will be tested now by Johnmeyer. After his feedback, I will make it available for everyone.

Fred.

[GillesH]

Hello,

I confirm that AutoAdjust is a great tool.

I take this exchange between Fred, John and Lato for, everyone, thank them.
With their kindly offered ideas on this forum, we have improved our old movies.

And favour to them, and other designers of this forum, my friend Roland and I were able to develop software film restoration.
Of course, this software is completely free and uses, so, some of the ideas of our friends Fred, John, Lato and others ..
This freeware is called FILM9.

This is not the place of the promotion, but if you want to take a look, there is the demonstration here: http://vimeo.com/86192634
All links are provided with the demo.

Very humbly, it is our pleasure to share our contribution.

Thank you again and sorry for my "google english" !!!!
Gilles

[videoFred]

This freeware is called FILM9.

Hi Gilles,

Film9 is a very nice project! I will take a closer look at it.

many greetings,
Fred.

[johnmeyer]

I've been side-tracked by other projects, but still intend to test Fred's updated script.

[asarian]

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 *

My, AutoAdjust is real sweet! ;) Thx!

[asarian]

"With AvisynthMT, SetMtMode(1) must be called before AutoAdjust."

Why SetMtMode(1) per se? SetMtMode(3), which I usually use, no good?!

[Groucho2004]

"With AvisynthMT, SetMtMode(1) must be called before AutoAdjust."

Why SetMtMode(1) per se? SetMtMode(3), which I usually use, no good?!
I explained this to you before (http://forum.doom9.org/showthread.php?p=1691329#post1691329) - mode 3 is for source filters. I suggest you read SEt's comments in the AVSMT thread.

[asarian]

I explained this to you before (http://forum.doom9.org/showthread.php?p=1691329#post1691329) - mode 3 is for source filters. I suggest you read SEt's comments in the AVSMT thread.

And as I explained in that thread, MTMode(1) simply isn't stable enough for the things I do. Nor MTMode(2), for that matter. I may not understand all the math behind it, but, after years of experimenting, the following incantation simply works for me:

SetMemoryMax(768)

SetMTMode(5,4)

FFVideoSource("f:\jobs\whatever.mkv")

SetMTMode(3)

the rest of the filters

MTMode(3) may be slightly slower, but anything below it, and things simply start crashing.

Now, there may be one or two filters out there that could, stand-alone, run stable with MTMode(1), but in the togetherness of what I usually do (lots of temporal denoising), MTMode(3) is the only mode for me that is guaranteed not to crash my job.

And I've read as much about MT AviSynth as I could find, but still found no reason AutoAdjust *must* work within MTMode(1) per se. Hence my question.

[feisty2]

like I said, slow temporal denoise filters are almost all based on mvtools2 (mdegrain/mcompensate+external denoisers)
but mvtools2 is already mt internally, you don't need and actually can't use these SetMTMode stuff, remove them all
the script will run faster

[SamKook]

Nothings stopping you from doing multiple SetMTmode calls in your script after the original one, you can switch it to 1 before autoadjust and set it back to 3 after.
Not sure what that will do for speed though since I never needed to actually do that.

But I must admit it's the first time I see a filter that requires a better MT mode to work, that just seem odd.

[feisty2]

But I must admit it's the first time I see a filter that requires a better MT mode to work, that just seem odd.

He's using filters that involve mvtools2, mvtools2 is freaking buggy, just bugs are hidden when calling it by default (single thread usage), and bugs pop out when calling it with unnecessary external mt functions.

[feisty2]

if you do wanna use SetMTMode on mvtools2, set all "mt" parameters false first which are true by default
and see which mt mode works correctly

[asarian]

like I said, slow temporal denoise filters are almost all based on mvtools2 (mdegrain/mcompensate+external denoisers)
but mvtools2 is already mt internally, you don't need and actually can't use these SetMTMode stuff, remove them all
the script will run faster

I've tried that before, of course. :) Removed all MT stuff. Most of the scripts you wrote for me earlier, for example, actually hang in there for quite a while, but then crash after all, after a while. Usuallly with some CACHE_EXCEPTION type of error. And cache-handling is precisely one of the things MTMode(3) improves on greatly. With MTMode(3) my jobs are simply guaranteed not to crash.

One thing I can still try is to remove the MT dll altogether (and put the 2.6 AviSynth one back in its stead again). For instance, I saw that AutoAdjust() is MT aware, even when no MT stuff is used in the script at all, and stops using AS internal threading altogether when it detects an MT AviSynth. So, it may be that other filters are seeing it too, and revert to single-threading (and then crash).

MTMode(3) scripts still run at 100% CPU utilization here, btw: all 12 logical cores (i7 980X) are fully occupied. The speed penalty of MTMode(3) is largely usurped, as it were, by x264 using up the idle time. Only when the script output is so ridiculously low, x264 simply won't have enough material to work with any more to use 100% CPU. But that rarely ever happens.

N.B. It's actually mostly MCTemporalDenoise that needs the MTMode(3) for some reason.

[asarian]

if you do wanna use SetMTMode on mvtools2, set all "mt" parameters false first which are true by default
and see which mt mode works correctly

Yes, LOL, that was akin to what I was thinking of myself (to just put back the non-MT dll). But yes, I saw there's actually commands to disable MT from within the script itself. So I will try that. Thx. :)

[LaTo]

"With AvisynthMT, SetMtMode(1) must be called before AutoAdjust."

Why SetMtMode(1) per se? SetMtMode(3), which I usually use, no good?!

AutoAdjust is a heavy temporal filter (it requests a lot of frames, temporal radius is 20 by default).
MtMode=1 was recommended (but not mandatory) in v2.00 because of this (http://forum.doom9.org/showthread.php?p=1674105#post1674105).

Now it is less significant, but if you do not use MtMode=1 AutoAdjust will be slower and will use more memory because:
- identical calculations will be performed in each instance
- identical data will be stored in each instance
- avisynth's cache will be more stressed
- frames will not be requested in linear order

MtMode=1 is not a mandatory, but it works and is better... So why don't use it? :D

[asarian]

AutoAdjust is a heavy temporal filter (it requests a lot of frames, temporal radius is 20 by default).
MtMode=1 was recommended (but not mandatory) in v2.00 because of this (http://forum.doom9.org/showthread.php?p=1674105#post1674105).

Now it is less significant, but if you do not use MtMode=1 AutoAdjust will be slower and will use more memory because:
- identical calculations will be performed in each instance
- identical data will be stored in each instance
- avisynth's cache will be more stressed
- frames will not be requested in linear order

MtMode=1 is not a mandatory, but it works and is better... So why don't use it? :D

Thx for the explanation! :) As soon as this process is done (just another 6 hours), I will try and rerun it with Mode 1. I will let you know what it does.



SetMemoryMax(1024)
SetMTMode(5,4)
ffdshow_source()
SetMTMode(1,4)
AutoAdjust(auto_gain=true, auto_balance=true, balance_str=1.0)
GetMTMode(false) > 0 ? distributor() : last


Not sure the '4' in SetMTMode(1,4) has any effect there, really; but it looks like you're saying you can just use Mode 1 for your filter alone, which is good. :)

[czerro]

Edit: Going to retest something as a possible Avisynth+ build incompatibility, please disregard.

[LaTo]

Edit: Going to retest something as a possible Avisynth+ build incompatibility, please disregard.

Don't hesitate to report back if you find an incompatibility or a bug!

[papcom]

I would like to study more on th Autoadjust Plugin but I cannot get it to work. Can some give me an example of a simple workin script, with the plugin load and the avi-video load etc. This would help me to understand the basics. Thank You.

[cybersharky]

I would like to study more on th Autoadjust Plugin but I cannot get it to work. Can some give me an example of a simple workin script, with the plugin load and the avi-video load etc. This would help me to understand the basics. Thank You.

:script:

[papcom]

@cybershrky - I have no script (at least no working)... thats why I am looking for a basic sample ! (video in, adjust, video out)

[LaTo]

@cybershrky - I have no script (at least no working)... thats why I am looking for a basic sample ! (video in, adjust, video out)
Basic settings are good enough with most clean sources:
AutoAdjust(auto_gain=true, auto_balance=true, debug_view=true)

[Groucho2004]

film= AVISource("c:\intensitytest8mm.avi")
ConvertToYV12(film)
SetMemoryMax(1024)
SetMTMode(3,2)
AutoAdjust(auto_gain=true, auto_balance=true, debug_view=true)
The "SetMTMode()" statement is useless. You have to put the statement before the source filter (mode 3 or 5) and then use mode 2 (maybe 3) before the filtering. Read the documentation.

[papcom]

Read the documentation.
which doc do you mean?

[Groucho2004]

which doc do you mean?
AVS MT (http://forum.doom9.org/showthread.php?t=148782)

[papcom]

@groucho2004 - thx , I got it.

[papcom]

Basic settings are good enough with most clean sources:
AutoAdjust(auto_gain=true, auto_balance=true, debug_view=true)
I've experimented with different Auto Adjust scripts (auto_gain and auto_balance also in combination with smooth_level instead of auto_level)... Great results as long as the videosource is not extremely off the track. When I work on "dirty" out of color sources I often get stuck because of my loss of knowledge. Perhaps someone can recommend good settings for correcting wrong-colored material.

[videoFred]

Can you show us an example of bad colors?

Sometimes changing hue with tweak() before using autoadjust autowhite works remarkable well.

Fred.

[papcom]

Can you show us an example of bad colors? Fred.

@VideoFred - Here we go... false Colors from an old 8mm movie:

[leoenc]

Is it possible to use AutoAdjust to limit the chroma and black levels of 10-bit video?
According to bt.709 specs we need to keep the Y within 64-940 and UV at 64-960, and black has to be limited at 64.

[alexx7777]

Prompt please, before use should be divided into fields interlaced video?
SeparateFields - necessary or not?

[qwerty1983]

Could someone provide me with some help?

1) When i use high_bitdepth=true
avisource("myvideo.avi")
AutoAdjust(auto_gain=true, dark_limit=1.5, bright_limit=1.25, auto_balance=false, high_bitdepth=true, high_quality=true)i get some 'psychedelic stuff' at the bottom half of the picture. What am i doing wrong?

2) Can i exclude some parts of the picture from the calculations this filter does? I don't know if i expressed it correctly. I want to exclude tv-station-logos, black borders, subtitles etc. Is this done by using some kind of mask? And another thing is the levels adjustment not to affect these logos,subtitles etc

[foxyshadis]

Could someone provide me with some help?

1) When i use high_bitdepth=true
avisource("myvideo.avi")
AutoAdjust(auto_gain=true, dark_limit=1.5, bright_limit=1.25, auto_balance=false, high_bitdepth=true, high_quality=true)i get some 'psychedelic stuff' at the bottom half of the picture. What am i doing wrong?

2) Can i exclude some parts of the picture from the calculations this filter does? I don't know if i expressed it correctly. I want to exclude tv-station-logos, black borders, subtitles etc. Is this done by using some kind of mask? And another thing is the levels adjustment not to affect these logos,subtitles etc

1. You have to use the Dither (http://forum.doom9.org/showpost.php?p=1386559) plugin to convert it back into 8-bit or feed it into your encoder as a high-bit source. The Dither documentation describes this process better.

2. You can create a mask and apply it with:

original=last
adjusted=AutoAdjust(auto_gain=true, dark_limit=1.5, bright_limit=1.25, auto_balance=false, high_bitdepth=true, high_quality=true)
mt_merge(adjusted,original,your_mask,chroma="copy")

The hard part is making the mask. It would have to be all black except white for what you want to keep. You need to either manually make it or find a way to generate it; either way is a bit of a pain.

[qwerty1983]

1. You have to use the Dither (http://forum.doom9.org/showpost.php?p=1386559) plugin to convert it back into 8-bit or feed it into your encoder as a high-bit source. The Dither documentation describes this process better.
foxyshadis thank you for the answer.
In other filters like qtgmc i use the lsb=true parameter and i have no problem. With autoadjust i'm stuck. I try using ditherpost() but i get a half picture.

edit : Ok, thank you Reel.Deel (post below)

[Reel.Deel]

In other filters like qtgmc i use the lsb=true parameter and i have no problem. With autoadjust i'm stuck. I try using ditherpost() but i get a half picture.

When AutoAdjust(high_bitdepth=true) it expects a 16-bit stacked input clip (output will be stack16 too), when high_bitdepth=false, input and output clips are normal 8-bit (internal processing is still done in 32-bit float but it's dithered back down to 8 bit). The reason QTGMC works (Dogway's mod v3.33d) is because it only accepts regular 8-bit clips, when lsb=true some of the MVTools2 processing is done in 16-bits and internally dithered back down to 8-bits.

So you can do something like this:
Dither_convert_8_to_16() # not needed if the input clip is already stack16
AutoAdjust(high_bitdepth=true)
# additional 16-bit processing
DitherPost()

If you're only using AutoAdjust and no other 16-bit filters then there's probably not much benefit in using high_bitdepth=true.

[LaTo]

2) Can i exclude some parts of the picture from the calculations this filter does? I don't know if i expressed it correctly. I want to exclude tv-station-logos, black borders, subtitles etc. Is this done by using some kind of mask? And another thing is the levels adjustment not to affect these logos,subtitles etc
"external_clip" may be useful for your problem.

From the readme:
external_clip [default: none]
-----------------------------
Use external analyze clip to retrieve clip's statistics
--> EXAMPLE: black borders need to be cropped before analyze of the clip
" src = last
crp = src.crop(xx,xx,xx,xx)
AutoAdjust(src, external_clip = crp) "

[alexx7777]

If video is interlaced, you need to break into the field?
DirectShowSource("interlaced video")
SeparateFields()
AutoAdjust()
Weave()
Or can without a team "SeparateFields()"?
DirectShowSource("interlaced video")
AutoAdjust()

[papcom]

Is it possible to increase Color Saturation in combination with AutoAdjust (Auto_Balance/Auto_Gain)?

[Selur]

Using:
SetMemoryMax(768)
SetMTMode(5,16) # change MT mode
LoadCPlugin("G:\Hybrid\avisynthPlugins\ffms2.dll")
LoadPlugin("G:\Hybrid\avisynthPlugins\AutoAdjust.dll")
# loading source: F:\TestClips&Co\test.avi
Source = FFVideoSource("F:\TESTCL~1\test.avi",cachefile="H:\Temp\367553385avi_0197468a3716844ade54f3f30f60eeda_491.ffindex",fpsnum=25)
SourceFiltered = Source
# color modifications
SetMTMode(2) # change MT mode
SourceFiltered = SourceFiltered.AutoAdjust(dark_limit=10,bright_limit=10,output_tv=false,high_quality=true)
StackHorizontal(Source, SourceFiltered)
return last
and the latest version, I see no effect of the filter at all,...
Did I miss something?

[Reel.Deel]

Read the Readme :)
IIRC you have to set auto_gain=true or auto_balance=true, not sure if the 2nd name is correct but it's in the readme.

[Selur]

@Real.Deel: Thanks that worked fine! :D

[markanini]

I need settings for an analysis pass for later later input to into Smoothadjust.

[metaspirit]

It would be nice if you could get the autoadjust settings for any given frame allowing you to input the settings manually and apply this over the whole clip.

The main problem for me is that when running with auto if there is a scene where there is a large bright light in the background and something blocks the light there is a jump/flicker in the level until the light is shown again like if a car or someone is moving past it.

Maybe there is a setting that can change the sensitivity scene change threshold does not seem to help with this there doesn't seem to be a setting that would help with this.

Otherwise autoadjust is perfect.

[LaTo]

v2.60:
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!

[Overdrive80]

Thanks LaTo. All are with us!!!

[STJAM]

Thanks LaTo for this wonderful plugin I use it quite often.
Is their any plans on porting this to Vapoursynth 64 bit?

[bebs]

Actually this plugin work now in Vapoursynth r30

http://forum.doom9.org/showthread.php?p=1751966#post1751966

[Myrsloik]

Actually this plugin work now in Vapoursynth r30

http://forum.doom9.org/showthread.php?p=1751966#post1751966

Porting is never a bad thing... especially not if it's ported to linux as well.

[Mixxen Mach]

Hi
AVSPmod lists "AutoAdjust" in red letters: Apparently that means a Function Definition is needed.
I don't know very much about that. AutoAdjust isn't listed in the Import Wiki and I don't otherwise know where to look for a function definition.
Please explain how to get AutoAdjust's function definition in a form that can be imported into AVSPmod so that I can use it.

Thanks - MM

[LaTo]

Hi
AVSPmod lists "AutoAdjust" in red letters: Apparently that means a Function Definition is needed.
I don't know very much about that. AutoAdjust isn't listed in the Import Wiki and I don't otherwise know where to look for a function definition.
Please explain how to get AutoAdjust's function definition in a form that can be imported into AVSPmod so that I can use it.

Thanks - MM

AutoAdjust_AutoAdjust(
clip,
[clip "external_clip"],
bool "auto_gain"=False,
float "dark_limit"=1.5 (1.0 to 10.0),
float "bright_limit"=1.5 (1.0 to 10.0),
float "gamma_limit"=1.25 (1.0 to 10.0),
[float "dark_exclude"=0.5 (0.0 to 10.0)],
[float "bright_exclude"=0.5 (0.0 to 10.0)],
[int "gain_mode"=0 (0 to 1)],
int "chroma_process"=100 (0 to 200),
[float "avg_safety"=0.25 (0.0 to 1.0)],
[bool "input_tv"=True],
[bool "output_tv"=True],
bool "auto_balance"=False,
float "chroma_limit"=1.05 (1.0 to 2.0),
float "balance_str"=0.75 (0.0 to 1.0),
[int "scd_threshold"=12 (0 to 100)],
[int "temporal_radius"=20 (0 to 60)],
string "change_status"="",
[bool "use_interp"=True],
[bool "use_dither"=True],
bool "high_quality"=False,
bool "high_bitdepth"=False,
[int "threads_count"=0 (0 to 16)],
[int "asm_opt"=0 (0 to 3)],
bool "debug_view"=False
)
Ask Avspmod's developer to add it (this replace the old AutoGain plugin definition).

[Mixxen Mach]

[QUOTE=LaTo;1754485][CODE] [snip]

Thank you for your help LaTo.

MM

[Magik Mark]

Hey Lato,

Thank you for this great filter. I just need to be clarified. I use avisynth+ through staxrip. Does it mean multi threading if off? How do I turn it on? I'm a newbie in filtering

My Xeon CPU can do 28 threads. Is it possible to accommodate this?

[VICDBZ]

Hello. I'm looking for the autogain filter for avishynt but the download is out of line... Can someone please reupload it? Thanks!

[FranceBB]

By the way, I confirm that AutoAdjust v2.60 works under XP SP4 x86 (no need to use the former v1.02, as stated in the first page).

p.s long live to XP! ;)

[asarian]

Here's to still hoping we'll ever see AutoAdjust ported to VapourSynth! :)

[mpxman]

Hello

Could there be a support for YUY2 interleaved format? That would be important for me.

Does Autoadjust work for interlaced video without problems?

[Reel.Deel]

Hello

Could there be a support for YUY2 interleaved format? That would be important for me.

Does Autoadjust work for interlaced video without problems?

Use YV16, YUY2↔YV16 conversion is fast and lossless. As for interlaced input, I think it should work as is without any problems, but to be safe you can always process it with SeperateFields().AutoAdjust().Weave().

[mpxman]

Use YV16, YUY2↔YV16 conversion is fast and lossless. As for interlaced input, I think it should work as is without any problems, but to be safe you can always process it with SeperateFields().AutoAdjust().Weave().

Thanks. About the coversion. Do I have to select interlaced=true or false when converting YUY2↔YV16? Both formats are 4:2:2. My source can be interlaced or progressive. It would be simpler if there was no interlaced parameter.

Assuming that AutoAdjust works for interlaced and progressive video.

clip=clip.ConvertToYV16.AutoAdjust().ConvertToYUY2

[Reel.Deel]

Thanks. About the coversion. Do I have to select interlaced=true or false when converting YUY2↔YV16? Both formats are 4:2:2. My source can be interlaced or progressive. It would be simpler if there was no interlaced parameter.

Assuming that AutoAdjust works for interlaced and progressive video.

clip=clip.ConvertToYV16.AutoAdjust().ConvertToYUY2

Converting YUY2 to YV16 (and vice versa) simply changes the internal memory layout. The interlaced parameter does not do anything since there's no resampling taking place.

[mpxman]

Converting YUY2 to YV16 (and vice versa) simply changes the internal memory layout. The interlaced parameter does not do anything since there's no resampling taking place.

Thanks. After AudoAdjust I filter which work in YV12 and YUY2. I need many YUY2<->YV16 conversions.

[StainlessS]

Interlaced only affects conversions to and from YV12.

[STJAM]

It seems VapourSynth has outpaced AutoAdjust. I haven't been able to use post r32. VSEdit will evaluate a script and open a preview window but will not advance to a frame or finish processing. Vspipe.exe will also lock up with no error or warning.

[Myrsloik]

It seems VapourSynth has outpaced AutoAdjust. I haven't been able to use post r32. VSEdit will evaluate a script and open a preview window but will not advance to a frame or finish processing. Vspipe.exe will also lock up with no error or warning.

Outpaced? What? Give me a sample script that fails and I'll investigate.

[STJAM]

Outpaced is probably not the best word.

import vapoursynth as vs
import sys
import havsfunc_r24 as hf
core = vs.get_core(accept_lowercase = True)
core.std.LoadPlugin(path=r'C:\VapourSynth\vapoursynth-mvtools-v17-win64\libmvtools.dll')
core.avs.LoadPlugin(path=r'C:\Filters\Levels and Chroma\AutoAdjust-v2.60\x64\AutoAdjust.dll')
core.std.LoadPlugin(path=r'C:\VapourSynth\d2vsource_beta7\64bit\d2vsource.dll')
clp = core.d2v.Source(input=r'F:\Video_track1_eng.mpg.d2v')
clp = core.vivtc.vfm(clp,order=1,field=1, mode=1)
clp = core.vivtc.VDecimate(clp)
clp = core.std.CropRel(clp,0,0,58,62)
clp = core.avs.AutoAdjust(c1=clp,auto_gain=True,dark_limit=1.05, bright_limit=1.05, gamma_limit=1.00,dark_exclude=0.5, bright_exclude=0.5, gain_mode=1, chroma_process=100, avg_safety=0.25,input_tv=True, output_tv=True,auto_balance=True,chroma_limit=1.05, balance_str=0.33, scd_threshold=12, temporal_radius=20, use_interp=True, use_dither=True, high_quality=False, high_bitdepth=False, threads_count=0, asm_opt=0, debug_view=False)
clp = core.resize.Spline36(clp, format=vs.YUV420P16)
clp = hf.SMDegrain(input=clp, prefilter=1, thSADC=180, RefineMotion=True, truemotion=False, Str=1.2, contrasharp=50)
clp = core.resize.Spline36(clip=clp, width=720, height=304, format=vs.YUV420P8, dither_type="error_diffusion")
clp = core.std.AssumeFPS(clip = clp, fpsnum=24000, fpsden=1001)
clp.set_output()

[der_groschi]

First of all, thanks LaTo for this awesome plugin, it's really become one of those tools i couldn't live without anymore.

I'm using it in a way that might be somewhat different from it's intended use.
Particularly, i use to combat the issue of highly inconsistent black levels i find on most DVD and bluray releases of older asian movies.

So i usually run it after dialing in the overall levels via SmoothAdjust as good as possible without clipping. Then i run AutoAdjust with auto_gain=true, gain_mode=1, with no gamma correction at all and a rather conservative dark_limit value; just enough to get the levels right for most scenes.

Now i always run into the problem of AutoAdjust being rather reluctant of changing very dark scenes, where muddy black levels are bothering me the most.
For brightly lit scenes a rather conservative dark_limit setting of 1.25 usually is sufficent, but for overall very dark scenes, i often have to crank it way up to 2.0 or even higher to get the black levels close to zero.

Is there any way to change this behavior, to allow AutoAdjust to change levels of very dark scenes by the same amount as it does brighter ones?

Or does anybody have an idea for a workaround?
I know this might not be exactly what this filter was originally made for, but finding a way to make it work this way would make my life a lot easier.

[ChaosKing]

I have some problems with the high_bitdepth option. Maybe I'm just using it wrong. The documentations says it should be a stacked video output but the lower half of the video is just missing. So if I put DitherPost() or Dither_out() at the end, I get only half the image.
I'm using Avisynth+, also tested in Vapoursynth, same result with high bitdepth.

Are someone using the high bitdepth option?

This is how it looks http://imgur.com/a/nNd6f

[mustysmell]

Hello LaTo.

My name is Marco and I am new to the forum. Maybe you can help me with my problem with AutoAdjust 2.60.

All relevant data can be found at the end of the posting.

I am using the latest version of AviSynth + on a Debin 8 system under Wine. The Debian was patched just a few days ago. All packages are up to date.

With my script I edit only SD material from VHS tapes. All filters used work under the named system, with the exception of your AutoAdjust 2.60 filter.

What I noticed during my troubleshooting that differ the dll files of the filters. Here's an example what I mean:

me @ me: ~ / .wine64 / drive_c / AviSynth + / plugins64 + $ file AutoAdjust.dll
AutoAdjust.dll: MS-DOS executable, MZ for MS-DOS

me @ me: ~ / .wine64 / drive_c / AviSynth + / plugins64 + $ file dfttest_1941_avx2.dll
dfttest_1941_avx2.dll: PE32 + executable (DLL) (GUI) x86-64, for MS Windows

dfttest can be loaded and used without problems.

When I copy AutoAdjust into the plugins64 or plugins64 + folder I get along with it

WINEARCH = win64 WINEPREFIX = ~ / .wine64 wine64 AVSMeter64.exe -avsinfo

following issue:

VersionString: AviSynth+ 0.1 (r2508, MT, x86_64)
VersionNumber: 2.60000
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\windows\system32\avisynth.DLL
Avisynth.dll time stamp: 2017-06-29, 09:09:33 (UTC)
PluginDir+ (HKLM, x64): C:\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\AviSynth+\plugins64


[CPP 2.5 / 64 Bit plugins]
C:\AviSynth+\plugins64\AddGrainC.dll [1.7.1.0]
C:\AviSynth+\plugins64\avstp.dll [1.0.3.0]
C:\AviSynth+\plugins64\dither.dll
C:\AviSynth+\plugins64\EEDI2.dll [0.9.2.0]
C:\AviSynth+\plugins64\flash3kyuu_deband.dll
C:\AviSynth+\plugins64\TDeinterlace.dll [1.1.0.0]

[CPP 2.6 / 64 Bit plugins]
C:\AviSynth+\plugins64+\aWarpSharp.dll
C:\AviSynth+\plugins64+\CNR2_x64.dll
C:\AviSynth+\plugins64+\ConvertStacked.dll
C:\AviSynth+\plugins64+\DePan.dll [2.13.1.3]
C:\AviSynth+\plugins64+\DePanEstimate.dll [2.10.0.2]
C:\AviSynth+\plugins64+\dfttest_1941_avx2.dll [1.9.4.1]
C:\AviSynth+\plugins64+\DirectShowSource.dll
C:\AviSynth+\plugins64+\eedi3.dll [0.9.2.1]
C:\AviSynth+\plugins64+\ffms2.dll
C:\AviSynth+\plugins64+\fft3dfilter.dll [2.4.0.0]
C:\AviSynth+\plugins64+\ImageSeq.dll
C:\AviSynth+\plugins64+\KNLMeansCL.dll
C:\AviSynth+\plugins64+\masktools2.dll [2.2.10.0]
C:\AviSynth+\plugins64+\mvtools2.dll [2.7.23.0]
C:\AviSynth+\plugins64+\nnedi3_IntelW7_C2_AVX2.dll [0.9.4.47]
C:\AviSynth+\plugins64+\PlanarTools.dll
C:\AviSynth+\plugins64+\RgTools.dll [0.96.0.0]
C:\AviSynth+\plugins64+\SangNom2.dll
C:\AviSynth+\plugins64+\Shibatch.dll
C:\AviSynth+\plugins64+\TCannyMod_avx2.dll
C:\AviSynth+\plugins64+\TEMmod_x64.dll
C:\AviSynth+\plugins64+\TimeStretch.dll
C:\AviSynth+\plugins64+\VDubFilter.dll
C:\AviSynth+\plugins64+\yadifmod2_avx2.dll
C:\AviSynth+\plugins64\AutoAdjust.dll [2.6.0.0]


[Plugin errors/warnings]
______________________________________________________________________________

Cannot load file 'C:/AviSynth+/plugins64/AutoAdjust.dll'. Platform
returned code 998:
Kein Zugriff auf Speicherort. ==> No access to location


Here are some data about the system:

me @ me: ~ / .wine64 / drive_c / AviSynth + / plugins64 + $ uname -a
Linux mustysmell 3.16.0-4-amd64 # 1 SMP Debian 3.16.43-2 + deb8u5
(2017-09-19) x86_64 GNU / Linux

me @ me: ~ / .wine64 / drive_c / AviSynth + / plugins64 + $ WINEARCH = win64
WINEPREFIX = ~ / .wine64 wine64 --version
wine-2.0 (Debian 2.0-3 ~ bpo8 + 1)

Do you have any idea where the problem could be? I would be grateful for every tip.

If any information is missing, I will deliver it as soon as possible.

And in this way, many thanks for this ingenious filter!

Best regards,

Marco

[Groucho2004]

Do you have any idea where the problem could be? I would be grateful for every tip.One peculiar thing about the 64 bit DLL is that it references "Kernel32" as import library (without ".DLL" extension). That also causes Dependency Walker to throw an error.
The 32 bit plugin does not have that problem.

Since the source code is not published there's nothing anyone can do about it except the author.

Anyway, using the 64 bit autoadjust() in a script seems to work fine.

[mustysmell]

@Groucho2004

Thanks for the quick response and the information. I'm not a programmer. But I suspect that when compiling the source code parameters would need to be adjusted to make the dll work under the Debian / Wine / Avisynth + combination.
If I copy the dll into the appropriate directory and call the function with the default parameters, there is the following error message with avspmod:

Can not load file 'C: /AviSynth+/plugins64/AutoAdjust.dll'. Platform returned code 998:
No access to location.

Even if I load the filter manually with LoadPlugin, the same error message.

I hope for one thing that LaTo reads my posts, and that someone has an idea if and how a dll can be converted. Namely of

(MS-DOS executable, MZ for MS-DOS)

after

(PE32 + executable (DLL) (GUI) x86-64, for MS Windows)

Are there comparable 64 bit filters that can do the same?

Best regards,
Marco

[Groucho2004]

Are there comparable 64 bit filters that can do the same?
Here (http://avisynth.nl/index.php/AutoAdjust#Levels_and_Chroma) is a selection. If there's one that suits your needs, you can look here (http://avisynth.nl/index.php/AviSynth%2B_x64_plugins) if there's a 64 bit version.

[Groucho2004]

I'm not a programmer. But I suspect that when compiling the source code parameters would need to be adjusted to make the dll work under the Debian / Wine / Avisynth + combination.
I'm not sure but the problem might be that the author uses the MPress packer for his DLLs.

[mustysmell]

Hello Groucho2004.

Thanks for the hint. I'll take a closer look. A first search showed that it is probably possible to unpack a file packed with MPress again. But does not seem to be quite trivial;) As it seems, I need a Windows PC for it. I will report.
Greeting,
Marco

[mustysmell]

Hello.

I wanted to give a short update.

At the turn of the year, I installed a new video server. Intended only to work with AviSynth and everything that goes with it.

Here are the most important data:

Hardware - AMD Ryzen 7 1800X Eight-Core Processor (@ 3.85GHz), 16GB RAM
Debian Buster
Kernel - 4.14.13-1 (2018-01-14) x86_64 GNU / Linux
Wine Version - wine-3.1 (Debian 3.1-1)
AviSynth - AviSynth + 0.1 (r2580, MT, x86_64)

All used filter DLLs are installed in the latest 64 bit versions.

AutoAdjust works great with this configuration. And also very fast. Together with Xaa and awarpsharp2 I reach about 20fps.


Thank you LaTo for this really ingenious filter!

Greeting,
Marco

[kentafilo]

As first think, sorry for my bad english.
I just wanna ask you how using this plugin some frames are completely green.
I've a bluray ,and if i let a resolution of 1920 x1080 it's all ok, but if i set on 1400 x1080 ( 240,0,-240,0 of crop ) some frames are green.
Thanks in advance

[StainlessS]

Post your exact script.

[kentafilo]

DirectShowSource2("D:\NEW.avi")
autoadjust( bright_limit=1.15,scd_threshold=16, dark_exclude=0.75,temporal_radius=30,input_tv=false,output_tv=true,auto_balance=false,balance_str=1.00,auto_gain=true,high_quality=true,gain_mode=1)

If i change temporal_radius from 30 to 28, frames is ok
Why ?

[ChaosKing]

Maybe DDS2 ist not always frame accurate? Try FFMS2. Or it's a bug...
And why don't you just use Avisource?

[Stereodude]

First of all, thanks LaTo for this awesome plugin, it's really become one of those tools i couldn't live without anymore.

I'm using it in a way that might be somewhat different from it's intended use.
Particularly, i use to combat the issue of highly inconsistent black levels i find on most DVD and bluray releases of older asian movies.

So i usually run it after dialing in the overall levels via SmoothAdjust as good as possible without clipping. Then i run AutoAdjust with auto_gain=true, gain_mode=1, with no gamma correction at all and a rather conservative dark_limit value; just enough to get the levels right for most scenes.

Now i always run into the problem of AutoAdjust being rather reluctant of changing very dark scenes, where muddy black levels are bothering me the most.
For brightly lit scenes a rather conservative dark_limit setting of 1.25 usually is sufficent, but for overall very dark scenes, i often have to crank it way up to 2.0 or even higher to get the black levels close to zero.

Is there any way to change this behavior, to allow AutoAdjust to change levels of very dark scenes by the same amount as it does brighter ones?

Or does anybody have an idea for a workaround?
I know this might not be exactly what this filter was originally made for, but finding a way to make it work this way would make my life a lot easier.
I realize I'm replying to you years late, but for anyone else who might come across this I found the same issue when more or less doing the same thing you're doing. Trying to fix poorly mastered DVDs with inconsistent and too high black levels. I found a few things helpful.

1) Filter the input: Use the external_clip function to feed in a slightly cropped and blurred version of the source to eliminate compression artifact ringing with unexpected/unintended dark and bright pixels. Crop off a few rows of pixels from each of the four sides before the blur to prevent any issues with cameras that leave a row of black or lower luminance pixels on one of the edges.

2) Exclude very few pixels. I use 0.01 to 0.001 for excludes.

3) Pre-process. As you noted autoadjust will not make dramatic changes to dark video with limited dynamic range. I stick a histogram of the source and output on the side of the video to see how the YUV levels look and watch through it. When I note a murky scene where AutoAdjust did not pull it down sufficiently or excessively stretched it out I add that frame range to my pre-processing in RGBAdjust.

So ahead of using AutoAdjust I do this:
ScriptClip(source_16b, "
RGBAdjust(rb=((xyx_l)*256), gb=((xyx_l)*256), bb=((xyx_l)*256), r=(1-(xyx_g)/256), g=(1-(xyx_g)/256), b=(1-(xyx_g)/256))
")
ConditionalReader("gain.txt", "xyx_g", false)
ConditionalReader("levels.txt", "xyx_l", false)
(working in 16-bits with AVIsynth+)

So in the levels.txt file (and probably gain.txt too) I will have something like:
Type float
Default 0.0

R 2379 2515 -10.0

R 3261 3301 -10.0

R 7476 7564 -10.0

4) Don't try to expand the whites with AutoAdjust. If you want to stretch them across whole large regions do it RGBAdjust (using gain) in front of AutoAdjust. AutoAdjust will squish excessive whites down to 235 even with bright_limit=1.0 (input_tv=false, output_tv=true). So as long as you don't boost them past 255 into clipping AutoAdjust will fix them.

Conversely it will do the inverse on the black end. If the blacks are too dark it will raise them up (with those options). So you can apply a broad general manual correction across an entire clip getting things in the general ballpark and let AutoAdjust take care of the scene by scene tweaking rather than relying on it to do all the correction.

[HappyLee]

First of all, I love this filter (or actually almost all the filters by LaTo). Recently I'm switching to AviSynth+ MT-r2772 (latest version), but when I use AutoAdjust, the first frame is always loaded incorrectly (heavy contrast and saturation), even if the script is as simple as this:
AutoAdjust(auto_gain=true)
Trim(1000,2000)

If it only happens on the very first frame, then it wouldn't be a big problem, but there was one time I was making a test clip encode using x265, and the encoded file has heavy flicker, like lots of frames having been loaded incorrectly, and that made me panic. I'm wondering if anyone has met the same problem, and how it could be fixed without switching back to AviSynth previous versions. Thanks. :)

Edit: Yes I've noticed there are other problems as well, not just the first frame. So could someone please help me confirm it or think of ideas to fix it. Thanks in advance!

[StainlessS]

I think that I have noticed lately same type thing on first 1 or 2 frames using AutoAdjust (by frustrum [EDIT: Actually by LaTo, got mixed up with AutoLevels] , I think), also in some white balance scripts.
Dont think it used to happen about 6 months ago [possibly longer].

EDIT: Also, I think if you try trim off offending frames, it still affects the first few frames after trimming.

[HappyLee]

I think that I have noticed lately same type thing on first 1 or 2 frames using AutoAdjust (by frustrum, I think), also in some white balance scripts.
Dont think it used to happen about 6 months ago [possibly longer].
Thank you for confirming it. So it might be a glitch of the latest builds of AviSynth+? I guess switching back to AviSynth 2.6 could be the only solution for now?

[StainlessS]

Does the problem remain as in above edit, ie after trim off original offending frames ?
(might be a clue for somebody. I dont have Avs installed at the moment.)

EDIT: My mistake[got names mixed up], I thought I had tried AUTOLEVELS by Theodor Anschütz and Frustrum, but it was actually AutoAdjust by LaTo. (same plugin as you, so is confirmed for AutoAdjust).

EDIT: I have posted before about trim() not working as it used to, perhaps this is related.

EDIT: If you try [at and of script] trim off 1st couple of frames and problem remains, then try following the trim with DelayAudio(0.0), if this fixes problem,
then is the same problem as in above edit non functioning trim problem. [this prob really need be fixed, else we shall have no end of similar problems with scripts that used to work]

[pinterf]

One reason can be that the plugin assumes linear frame access, which is not necessarily true. Do the other glitches appear around scene changes?

[HappyLee]

Trimming at the end of the script won't solve the problem.

And yes, pinterf. I detected similar glitches (flicker) around scene chances during the preview, and there was one time my encoded file by x265 also has heavy flicker caused by AutoAdjust.

[StainlessS]

Trimming at the end of the script won't solve the problem.
That would imply that you did not try trim (or you would have said it does not solve the problem).
[EDIT: Trim() at end of script should not affect either frames before or after trimming, except those frames trimmed out will not be returned in the output clip (that is, when trim works correctly which is currently in question).]

But does it remove the bad frames when and if you do try it ? (or are they still there just at the new first frames)
and also what happens if adding DelayAudio(0.0) to end of script [DelayAudio is known to force trim to work as expected].

[HappyLee]

Of course I've tried Trim. I even added Trim in my previous post (test script):
*Original video here*
AutoAdjust(auto_gain=true)
Trim(1000,2000)

For the encoded file, frame 1000 of the original video would be broken. If I use Trim(2000,3000), frame 2000 would be broken. Broken frames happen not just the very first frame of the previous script, but the first frame the whole script is loaded.

This can probably be fixed by ConditionalFilter, but as I said, there might be bigger problems (more glitches) than the broken first frames.

[Treaties Of Warp]

For me this filter becomes more unstable in Avisynth when more filters are run with AutoAdjust, even if AutoAdjust is the first filter in the script. I was getting really weird and constant flashing in my output. When I disabled AutoAdjust, it went away. When I ran only AutoAdjust, the problem also went away. When I added LimitedSharpenFasterMod, then the flashing appeared, but only in the first few seconds of output. I didn't test further yet because I don't have time but I had some other filter or filters that were making the flashing constant. Maybe internal caching issue? Any way to disable it?

[Lirk]

Is it possible to use Autoadjust as Autolevels filter?

[Stereodude]

How does AutoAdjust know what color space to operate in when doing chroma processing? There's no flagging for rec601/rec709/etc. in the function call.

Also I presume development of this is dead? Otherwise I have a feature request. RGB based limiting. Instead of strictly looking at Y, looking at the RGB channels to figure out how far to expand the Y levels so that none of the color channels get clipped.

[StainlessS]

How does AutoAdjust know what color space to operate in when doing chroma processing? There's no flagging for rec601/rec709/etc. in the function call.
There is no levels range indication in Levels() filter either, and levels limits range [Y=0->255, U:V=0->255, if no coring] and [Y=16->235, U:V=16->240 if coring].

LaTo aint been around for a while, but did pop up some time ago when someone posted a request, so who knows, maybe he's watching.
[There is no source available]

this may not be exactly how Levels is implemented, but at least very nearly the same.


if (vi.IsYUV()) {
for (int i=0; i<256; ++i) {
float p;
if (coring)
p = ((i-16)*(255.0f/219.0f) - in_min) / divisor;
else
p = float(i - in_min) / divisor; // range 0.0 -> 1.0 of input range

p = pow(min(max(p, 0.0f), 1.0f), gamma); // gamma
p = p * (out_max - out_min) + out_min; // output range with out_min offset
int pp;

if (coring)
pp = int(p*(219.0f/255.0f)+16.5f);
else
pp = int(p+0.5f); // round to nearest luma level

map[i] = min(max(pp, (coring) ? 16 : 0), (coring) ? 235 : 255);

int q = ((i-128) * (out_max-out_min) + (divisor>>1)) / divisor + 128;
mapchroma[i] = min(max(q, (coring) ? 16 : 0), (coring) ? 240 : 255);
}
} else if (vi.IsRGB()) {
for (int i=0; i<256; ++i) {
float p = float(i - in_min) / divisor;
p = pow(min(max(p, 0.0f), 1.0f), gamma);
p = p * (out_max - out_min) + out_min;
int z=int(p+0.5f);
map[i] = (z < 0) ? 0 : (z>255) ? 255 : z;
}
}


EDIT:
If coring set, then Levels assumes is TV range [but then after removal of 16 offset and scaling, weirdly assumes that arg input/output ranges are full range 0->255, probably to
ensure that gamma is affected properley when offset added back, but this makes it bloody awkard/hazardous to use anything other than 0,255 as either input or output range args when coring=true.
Eg if you supply coring=true, out range =16,235, then output range would be compressed TWICE ... Me dont like coring!
With Coring=true, should only use it to apply Gamma, anything else is dangerous unless you sort of backwards pre-calculate what the result will be, real awkward].

EDIT:
Backward pre-calc from AutoLevels source [for pre-calc input_min/input_max, output_min/output_max where coring=true].

double inv_coring_func(double y) { return y * (219.0/255.0) + 16.0; } // ssS: Changed (255.0/219.0) to (219.0/255.0)

EDIT: Actually, above was wrong in earlier AutoLevels (v0.6 and earlier), as noted in the comment.

[Stereodude]

There is no levels range indication in Levels() filter either, and levels limits range [Y=0->255, U:V=0->255, if no coring] and [Y=16->235, U:V=16->240 if coring].

LaTo aint been around for a while, but did pop up some time ago when someone posted a request, so who knows, maybe he's watching.
[There is no source available]
Well, I can't even be certain that AutoAdjust does any conversion internally to RGB. I presume it does for it's chroma processing, but that's a guess. I suppose as long as it uses the same matrix for both conversions it probably doesn't make a big difference at least for 601/709.

Ideally I would like a mode to prevent clipping of any of the RGB color channels (even if chroma processing is not enabled). Currently it looks like it only considers Y which can cause an individual R,G, or B color channel to fall above or below the limits resulting in color channel clipping.

[StainlessS]

I dont know what it does, but as it is quite a lot slower than autoLevels [with simple AutoAdjust(autogain=true)], I suppose it must be doing a lot of something, perhaps there is YUV->RGB->YUV conversion.
Would be nice if LaTo provided source.

[Stereodude]

This is my best guess [can produce weirdish numbers, eg -18.63]
Best guess of what?

[StainlessS]

StereoDude,
Have deleted previous rubbish altogether, I'm quite sure that coring massager thing in AutoLevels is totally borked, and needs an alternative massage
so that when calling equivalent to Levels, we pre-compensate input_low and input_high so that we can get required result.
[problem due to coring messing things up so that required input_low/high dont do as required].
I can do it, but not today, time for the pub in a minute.
[I guess I could just add an arg to AutoLevels Levels() equivalent to skip coring on the input, and only core the output [EDIT, nah, that would not really work ideally]
[as we will want to give explicit/measured input_low & high, however I would still like to be able to do that with the Levels() filter so will probably
persist until we got it working without the coring skip].


If you would like to have a play, here a graf drawing whotsit (EDIT: Levels Simulator) [needs V.C Mohan Grid Filter, but can comment out that line if you wish]


Function LevelsSim(Int In_min,Float Gamma,Int In_max,Int Out_min,Int Out_max,Bool Coring,Int i,Int ret) {
Gamma=Min(Max(Gamma,0.1),10.0)
divisor = (in_max==in_min) ? 1.0 : Float(in_max - in_min)
R0=(coring)
\ ? ((i-16)*(255.0/219.0)-in_min) / divisor
\ : float(i - in_min) / divisor
G = pow(Min(Max(R0,0.0),1.0),1.0/Gamma)
R1 = G * float(out_max - out_min) + out_min
R2 = (coring)
\ ? min(max(Round(R1*(219.0/255.0)+16),16),235)
\ : min(max(Round(R1),0),255)
r =Select(ret,Round(R0*255.0),R1.Int,R2.Int) # Function Return R0, R1, or R2, depends upon Ret arg : *** NOTE *** R0=0.0->1.0, WILL BE SCALED TO 0->255 for graf
#RT_DebugF("%d] = %.2f",i,r)
return r
}

K=BlankClip(width=256,height=256,Length=1,Color=$808080)

Ret=2 # return type (type=0 is multiplied by 255, originally 0.0->1.0)
Gamma=1.5
##############
In_min=0
In_max=255
Out_min=16
Out_max=235
Coring=false
Color=$00FF00
Point=K.BlankClip(width=3,height=3,Color=Color)
for(x=0,255) {
y = LevelsSim(in_min,Gamma,in_max,Out_min,Out_max,Coring,x,Ret)
K=K.Overlay(Point,x=x-1,y=y-1,Opacity=0.3)
}


In_min=0
In_max=255
Out_min=0
Out_max=255
Coring=true
Color=$FF0000
Point=K.BlankClip(width=3,height=3,Color=Color)
for(x=0,255) {
y = LevelsSim(in_min,Gamma,in_max,Out_min,Out_max,Coring,x,Ret)
K=K.Overlay(Point,x=x-1,y=y-1,Opacity=0.3)
}

K.grid # V.C Mohan Grid
FlipVertical

Is arranged so that you can get results of the Levels() code at 3 different stages in the Levels function.
Graf looks like this
https://i.postimg.cc/90dh1BkS/q-00.jpg (https://postimages.org/)

https://i.postimg.cc/d05DjJCd/S7009754-00.jpg (https://postimages.org/)

[Micheal813]

I'm using AutoAdjust to tweak levels for VHS Captures. I've noticed that it doesn't necessarily give the same output even when using the same video and settings. The videos are compressed with Lagarith and I'm using AviSynth Plus.

Example:

Source=AviSource("Test.avi").AssumeTFF()
crp = Source.crop(8,8,-8,-8)

AutoAdjust(Source, external_clip = crp, high_quality=true, auto_gain=true, dark_limit=2.0, bright_limit=2.0, dark_exclude=.05, bright_exclude=.05, gain_mode=1, input_tv=True, output_tv=true, auto_balance=true)

I load the script into VirtualDub, select Fast Recompress, Lagarith, and then save the video. I reload the script without making any changes to the Test.avi or script and then save the video again. The second video may or may not be the exact same as the 1st. I base this on the file size and using a file comparison tool.

Is this normal?

Also, is it ok to use multi-threading (Prefetch()) with AutoAdjust? What would the correct MT mode be?

[StainlessS]

Did you use Prefetch() when doing the AVI file saves ? [it ever happen without Prefetch ?]

(I'm guessin difference down to Prefetch, in some way, I've no idea hjow the multi-threading stufff works)

[Micheal813]

Did you use Prefetch() when doing the AVI file saves ? [it ever happen without Prefetch ?]

(I'm guessin difference down to Prefetch, in some way, I've no idea hjow the multi-threading stufff works)


I did not use Prefetch.

[poisondeathray]

It could be the "randomness" introduced by the dithering algorithm. The same can be said for MCTD . Each run is not necessarily bit identical


AutoAdjust have a smoothing & dithering algorithm to avoid banding issue.


use_dither [default: true]

[StainlessS]

Nice appraisal PDR, dither did not even cross my mind.
For RandomSource(), was suggested by IanB and another, that random frames should always be repeatable (perhaps repeatable only if some arg set),
perhaps AutoAdjust() is not random repeatable, or just defaults to non-repeatable if some arg is defaulted.

EDIT: Does not seem to be any control over dither (I assume use_dither is a bool. EDIT: Yes is bool, PDR says so above)

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 )

[guest]

I'm having a strange problem trying to use AutoAdjust in Ripbot264, certain commands in the script will preview a half screen of just a swirled up colourful "mess", but the weirdest thing, on a script that actually works (graphically), I have to remove the audio track for the filter to process.

Any suggestions ??

[Treaties Of Warp]

Is there any kind of equivalent filter to this on 64 bit (either AviSynth 64 or VapourSynth)?

I continue to have problems with this when it's run with other filters. It produces very noticeable color flashes in some cases. Almost like the "temporal radius" is "resetting" or something. Sometimes I can get it to be stable for about 20 - 30 minutes of video, then it starts the color flashing thing. (Almost reminds me of VHS Macrovision.)

When AutoAdjust works it works great, and there's just nothing else like it. But when it does this color flashing thing it can be a nightmare to try to solve.

[ChaosKing]

Maybe try cutting the video in some parts with trim (scenechange!) and apply AutoAdjust to each section.

[Mounir]

Is there any kind of equivalent filter to this on 64 bit (either AviSynth 64 or VapourSynth)?

When AutoAdjust works it works great, and there's just nothing else like it. But when it does this color flashing thing it can be a nightmare to try to solve.

Have you tried to lower the number of temporal frames (20 by default that's a lot !) try 5 or lower
temporal_radius=5

[Treaties Of Warp]

I did realize there was a AviSynth64 port of AutoAdjust included with Selur Hybrid. Not sure who authored it, but it has the same date as the 32 bit one.

Still looking for a way to port this over to VapourSynth. It has its own dll so I'm guessing this will probably never happen.

AviSynth x86 is way too slow for 4K. VapourSynth works great for 4K. AviSynth64 seems fine, but if working in VapourSynth, using AutoAdjust requires additional workflow and hard drive space. (Encode in AviSynth64 first to lossless file, then encode with additional filters etc. in VapourSynth.)

I did try playing with temporal radius. I got extremely poor results with any setting other than 20. :( Not sure what's up with that!

[Selur]

I did realize there was a AviSynth64 port of AutoAdjust included with Selur Hybrid. Not sure who authored it, but it has the same date as the 32 bit one.
Download in the first post here includes a 32bit and 64bit Avisynth AutoAdjust build.
Still looking for a way to port this over to VapourSynth.
Yup, a Vapoursynth version of AutoAdjust would be nice.

---
As a side note:
When in Windows you could use Avisynth64Bit Filters in Vapoursynth (even in Hybrid when using a custom section).
Using:
core.avs.LoadPlugin("I:/Hybrid/64bit/Avisynth/avisynthPlugins/AutoAdjust.dll")
clip = clip.avs.AutoAdjust(auto_gain=True)
would create something like:
# Imports
import vapoursynth as vs
# getting Vapoursynth core
core = vs.core
# Loading Plugins
core.std.LoadPlugin(path="I:/Hybrid/64bit/vsfilters/SourceFilter/FFMS2/ffms2.dll")
# defining beforeDeCross-function - START
def beforeDeCross(clip):
core.avs.LoadPlugin("I:/Hybrid/64bit/Avisynth/avisynthPlugins/AutoAdjust.dll")
clip = clip.avs.AutoAdjust(auto_gain=True)
return clip
# defining beforeDeCross-function - END

# source: 'G:\TestClips&Co\test.avi'
# current color space: YUV420P8, bit depth: 8, resolution: 640x352, fps: 25, color matrix: 470bg, yuv luminance scale: limited, scanorder: progressive
# Loading source using FFMS2
clip = core.ffms2.Source(source="G:/TestClips&Co/test.avi",cachefile="E:/Temp/avi_9dec25d3f707eb4813d42334c7f1a8d6_853323747.ffindex",format=vs.YUV420P8,alpha=False)
# making sure input color matrix is set as 470bg
clip = core.resize.Point(clip, matrix_in_s="470bg",range_s="limited")
# making sure frame rate is set to 25
clip = core.std.AssumeFPS(clip=clip, fpsnum=25, fpsden=1)
# Setting color range to TV (limited) range.
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)
clip = beforeDeCross(clip)
# adjusting output color from: YUV420P8 to YUV420P10 for x265Model (i420@8)
clip = core.resize.Bicubic(clip=clip, format=vs.YUV420P10, range_s="limited")
# set output frame rate to 25.000fps
clip = core.std.AssumeFPS(clip=clip, fpsnum=25, fpsden=1)
# Output
clip.set_output()
which works fine here.

Cu Selur

[ChaosKing]

I used AutoAdjust for many encodes in VS. Only HBD mode is broken (also in avisynth I think), everything else works great in VapourSynth.

[Selur]

Still a native Vapoursynth version would be cool.

[real.finder]

LaTo last post was in 2016, and all his plugins close source so the hope for any update is so far...

maybe someone can use AutoLevels as a base and remake it? since don't know if it even possible to reverse engineering it or even get the source from LaTo

[Stereodude]

Ideally I would like a mode to prevent clipping of any of the RGB color channels (even if chroma processing is not enabled). Currently it looks like it only considers Y which can cause an individual R,G, or B color channel to fall above or below the limits resulting in color channel clipping.
So I figured out how to make AutoAdjust do this well enough for some of my uses. As I mentioned earlier in the thread I use it to fix poorly mastered/graded DVDs/Blu-rays where the black levels are elevated. Where AutoAdjust doesn't give a very good result is where someone took some artistic intent to shift the blacks toward a color. AutoAdjust works based on the Y channel and then one of the colors (RGB) can get crushed. I've been using the external clip argument with a blurred and slightly cropped version of the video to eliminate sharpening artifacts from messing up the calculations. I realized I could also use the Extract_ command in AVIsynth+ on the external clip so that all the decisions level adjustments are based on the channel that's being crushed. It works well as long as the intentional color shift is consistent and the video is pretty dark (has a lot of consistent black).

Example script snippet where the red channel was getting crushed due to a black balance color shift:
alt=source_16b.crop(4,4,-4,-6).ConvertToRGB64(matrix="PC.601").ExtractR.ConvertToYUV420(matrix="PC.601").FastBlur(2.0).ConvertToStacked()

source_16b.ConvertToStacked()
AutoAdjust(external_clip = alt, auto_gain=true, gain_mode=1, dark_limit=2.50, bright_limit=1.00, dark_exclude=0.01, bright_exclude=0.01, gamma_limit=1.00, auto_balance=false, chroma_limit=1.00, high_bitdepth=true, high_quality=true, use_dither=false, debug_view=false, input_tv=false, output_tv=true)
ConvertFromStacked(bits=16)