Automatic White Balance (AWB) script function(s)

[martin53]

EDIT: attached script version 27th October 2013 This one may be called more than once from a script, e.g. to compare settings :)
EDIT: script version 13th November a bit faster and hopefully no more AviSynth string heap issue - but has severe bugs in AWB algorithm, please don't use at this time. Update to come soon.
EDIT: script version 1st December Finalized White Patch (Max RGB) algorithm. Also:
+ uses arrays instead of global vars: full non linear access with 100% reproduceable output
+ multi instance capable
+ unprecedented plugin check

I'll concentrate on a new approach now (after I learned so much about things that are not what they seem in consumer cameras YUV or RGB values)

——————
Original Post

I'd like to announce a script function or maybe script function set for automatic white balance for real world footage, similar to the known function in digital cameras.

Some widely used algorithms implement theories of J. von Kries on the ability of the human visual system to recognize the color of objects under biased illumination, called "color constancy".
They are known as "Gray World", "Max-RGB" and "Shades of Gray".

Maybe I failed in finding an already existing plugin for AviSynth or VirtualDub that implements a useful automatic white balance (I do not count ColorYUV(autowhite=true) as useful). They may be not too fast since they use the runtime environment. But they show once again the power of AviSynth scripting when one refuses to write in C (as I do up to now). Here are the first appetizers, and comments are welcome.

Needs AviSynth V2.6 and dither, GRunt, mt_masktools and RT_Stats plugins.

--> see attached GrayWorldSimple.txt, Max-RGB_Simple.txt, ShadesOfGraySimple.txt

[StainlessS]

Have not tried as yet, but shall.
I have real expectations of this, hope you live up to them.

EDIT: Was the MYStats thing of any use ?

[martin53]

...have real expectations of this, hope you live up to them.
Same for me! To be honest, the underlying concepts of the three algorithms are quite ungarnished. But there was or is plenty of research on the topic, and this is what publicly evolved from it. To repeat myself: the concepts are not my inventions.

Was the MYStats thing of any use ?
I am convinced it will! I first tried it on itself on some clips and found that it seemed to work well. The list of challenges on my mind contains averaging over a group of frames, which in turn demands scene detection, an automatic mode which evaluates several algorithms and chooses/balances between them, and, maybe most important, masking of a color range that is valid at all for potential color temperature shift, i.e. lies along the temperature curve and is not a colorful object. I expect much from this to reduce misled corrections.

Up to now, I had to cope with color bleeding, banding etc. from the bad resolution of 8 bits in the neccessary YUV-RGB-YUV processing. Research on how to define the interesting color range will come next.

You can see from the examples that there is a lack of full featured statistics functions for RGB as there is for YUV for the task. I found workarounds though, so that's not a job stopper.

[StainlessS]

lack of full featured statistics functions for RGB as there is for YUV

Give me time and I'll do similar funcs for RGB

[martin53]

If you like to do it for fun, go ahead. For the white balance task, it will evolve which statistic functions will be needed.
Among them are, as far as I can judge today, masked versions for AverageChromaU and AverageChromaV. The mask should be taken from the Y plane of the mask clip, but the U and V planes of the main clip be evaluated.

Also, for the "Shades of Gray" algorithm, average functions that do not average the first power of samples, but an arbitrary power are useful.
To date the clip is prepared with 16 bit bitdepth and the samples taken to the power of 6 with Dither_lut8() and then dithered down to 8 bit resolution before measuring. But of course that's a workaround.

[martin53]

I am just wondering about color conversion documentation.
The AviSynth v2.6 doc in Advanced Topics / ColorSpace Conversions looks very reasonable. The constants Kr, Kg and Kb are taken from the standard, and the following equations derived from that.
But at second sight, the (v - 128 = ...) and (u - 128 = ...) equations have factors of 0.5, which seems arbitrary.

The web page http://en.wikipedia.org/wiki/YUV defines Wr=Kr, Wg=Kg and Wb=Kg, but furthermore Umax=0.436 and Vmax=0.615. This of course leads to different RGB->YUV and YUV->RGB transformations.

My question is: who is right, and are the AviSynth V2.6 colorspace conversion routines trustable?

[Gavino]

The AviSynth v2.6 doc in Advanced Topics / ColorSpace Conversions looks very reasonable. The constants Kr, Kg and Kb are taken from the standard, and the following equations derived from that.
But at second sight, the (v - 128 = ...) and (u - 128 = ...) equations have factors of 0.5, which seems arbitrary.

The web page http://en.wikipedia.org/wiki/YUV defines Wr=Kr, Wg=Kg and Wb=Kg, but furthermore Umax=0.436 and Vmax=0.615. This of course leads to different RGB->YUV and YUV->RGB transformations.
The difference is simply an arbitrary scale factor in U and V.
The Avisynth wiki page gives the formula to derive U and V in the range [-1, 1], while the Wikipedia article uses the range [-Umax, Umax] and [-Vmax, Vmax].

But when doing RGB<->YUV conversions on 8-bit inputs, you have to rescale anyway to fit the range [16, 240] or [0, 255] (depending on the matrix used). The Avisynth conversion routines do this correctly.

[martin53]

The Avisynth wiki page gives the formula to derive U and V in the range [-1, 1]
Thank you for answering, Gavino.
Alas, I intentionally asked for the lowercase letters u and v because I need the constants outside the builtin conversion routines.
Reading on in the Wikipedia article, I found now that I confused Y'UV with Y'CbCr anyway, and instead of calculating
U = -0.147 * R - 0.289 * G + 0.436 * B
which would only be valid for an analog device, for a digital device it must be
Cb = -0.169 * R - 0.331 * G + 0.499 * B + 128

I take 0.499 as 0.5, and so indeed the two formulas match. -0.169 comes from 0.5*Kr/(1-Kb) while the analog -0.147 comes from 0.436*Kr/(1-Kb) and so on, and it is confirmed that in AviSynth, the u and v scale factors are 0.5
(which btw. makes sense, because Y's [0,1] range is 1 wide while U,V's [-1,1] range has a width of 2. The [0,255] scaled variables share a range ot the same width, so a downscaling with 0.5 for u and v is obvious from that)

[martin53]

As an ancillary product, here is a script to change the 'color temperature' of a clip by a fixed offset.
It uses physically correct values to correct RGB and tries not to change the overall luminance. If that clamps RGB, you may enter a gain factor < 1.0 to make the clip darker with less clamping.

-> see 1st post

EDIT: function is part of complete script in 1st post

[martin53]

More advanced versions of the simple estimators drafted above will restrict estimation to colors in the picture that might be biased grey.
Below is a mask generator that I have used lately and that will find its way into later versions of the AWB function itself.

It can be fed with this test clip, to show the functionality.

Luma statistics functions give much better results if their input is restricted to these pixels, i.e. the MYStats functions with this mask give much better results than the standard functions.

I'll be offline for several days from now.

function testClipYUV() {
c = BlankClip(240,640,480,"YV12")
c.mt_lutspa(yexpr="128", uexpr="x 255 *", vexpr="y 255 *", chroma="process")
}


Mask generator
function GrayGamutMask(clip c) {
#
# Function to create a mask that is only white for clip pixels within a defined color and luminance range.
# Expects clip in YUV format
# Returns mask clip in YV24 format
#
# Author doom9.org/martin53
# Version 1.0
# Date June 18, 2013
# Uses plugins GRunT, MaskTools v2.0a48
# Tested with Avisynth V2.6
#
# Changes n.a.
#
TOL_UP = 0.9
TOL_DN = -0.4
U_DN = 128-15 # -50 mired, i.e. color temperature change from D65 to 4900K warm day or 7800K to 5600K flash
V_UP = 128+7 # -50 mired, i.e. color temperature change from D65 to 4900K warm day or 7800K to 5600K flash
U_UP = 128+15 # 50 mired, i.e. color temperature change from 4900K light to D65
V_DN = 128-7 # 50 mired, i.e. color temperature change from 4900K light to D65
YMIN = 100
YMAX = 235 - 1
c24 = c.ConvertToYV24()
#Make a mask according to experimentally found U and V change over color temperature
#mt_lutxy is fed with the U and V components. x stands for the U component, y for the V component.
expr = mt_polish("(x-128)/15+(y-128)/7 <= "+string(TOL_UP)
\+" & (x-128)/15+(y-128)/7 >= "+string(TOL_DN)
\+" & x <= "+string(U_UP)
\+" & y >= "+string(V_DN)
\+" & x >= "+string(U_DN)
\+" & y <= "+string(V_UP)
\+" ? 255 : 0")
exprX = mt_polish("(x-128)/15+(y-128)/7 <= "+string(TOL_UP*2)
\+" & (x-128)/15+(y-128)/7 >= "+string(TOL_DN*2)
\+" & x <= "+string(U_UP*2)
\+" & y >= "+string(V_DN*2)
\+" & x >= "+string(U_DN*2)
\+" & y <= "+string(V_UP*2)
\+" ? 255 : 0")
#subtitle(expr)
mChroma1 = mt_lutxy(c24.UToY(), c24.VToY(), expr=expr, chroma="128")
#Choose this mask if it is not all black, otherwise choose fallback mask with doubled tolerance values
mChroma = GConditionalFilter(mChroma1, mChroma1, mt_lutxy(c24.UToY(), c24.VToY(), expr=exprX, chroma="128"), "AverageLuma()>0")
#Complete the mask with minimum and maximum luma restrictions.
#mt_lutxy is fed with the Y component and the previous mask. x stands for Y (luma), y for the previous mask.
expr = mt_polish("y > 0"+" & x >= "+string(YMIN)+" & x <= "+string(YMAX)+" ? 255 : 0")
#subtitle(expr)
mLuma = mt_lutxy(c24, mChroma, expr=expr, chroma="128")
#Choose mask mLuma if it is not all black, else choose fallback mask mChroma
GConditionalFilter(mLuma, mLuma, mChroma, "AverageLuma()>0")
#Choose this mask if it is not all black, else choose fallback all white mask
GConditionalFilter(last, last, BlankClip(c24, color_yuv=$f08080), "AverageLuma()>0")
#debug
#GScriptClip("""RT_Debug("Mask",string(AverageLuma())) last""") #"
}


Usage e.g.
TestClipYUV()
merge(last, GrayGamutMask().ConvertToYV12(), weight=0.1)

[Navarre66]

I'm trying to use MaxRGB1, but I keep getting the error: Script error: ScriptClip does not have a named argument "args"
Apparently inferring it doesn't like the args="RGBinYUV"

I'm using AviSynth 2.6.0 Alpha4 because I get problems with dither.avsi if I use AviSynth 2.5.8 or SEt's version of Avisynth 2.6.

:thanks:

[Gavino]

I keep getting the error:
Script error: ScriptClip does not have a named argument "args"
Apparently inferring it doesn't like the args="RGBinYUV"
You need to install the GRunT (http://forum.doom9.org/showthread.php?t=139337) plugin (which - among other things - extends ScriptClip with the 'args' parameter).

[Navarre66]

You need to install the GRunT (http://forum.doom9.org/showthread.php?t=139337) plugin (which - among other things - extends ScriptClip with the 'args' parameter).

Thanks. That did the trick.
:thanks:

[martin53]

Script is now attached to 1st post. Please read abstract before you try it.
Comments welcome.

[martin53]

This is a call for comments on expectations what an AWB script should serve for.

After I fiddled so much with my lots of images & scenes, I learned that it is not that difficult to average RGB in an image, but that slight adjustments of scenes require a script to restrict itself, while the correction of images taken with sunlight setting in bulb illuminated environment, or very shadowy environment, require strong impact.

So I may optimize it to do subtle enhancements, but sacrifice the ability to always return the same result, no matter how extreme the user may bias the input in advance. For that purpose, I shifted the 'correlated color temperature' of the input clip by +-1000°C, and the output does not stay the same, how I earlier defined the goal for myself. Personally I feel now that it is important to retain the original mood of scenes in most cases, so the color of the result just seems 'right' in an unobstrusive way, i.e. just eliminate annoying color bias e.g. from incandescent light, but not overdo compensation. That might require manual pre-balancing in some cases, however. A script for manual pre-shifting of the correlated color temperature is provided in this thread.

[yup]

Hi martin53!
I find Your script useful, thanks for Your time. My source mainly VHS capture indoor shooting with color distortion (a lot of yellow see https://www.dropbox.com/s/wyc1o6ygvxbuv8a/samplevhs.avi).
AVISource("tape1.avi")
AssumeTFF()
ConvertToYV12(interlaced=true)
Crop(16,12,-16,-12)
s=SeparateFields()
s.AutoGain(adjust_mode=1).ShadesOfGray1()
# OR s.AutoGain(adjust_mode=1).GrayWorld1()
StackVertical(s,last)
#AssumeFieldBased().Weave()
work fine shift yellow to blue color and video look good (I know real color because have photo and slide from this place), but script
AVISource("tape1.avi")
AssumeTFF()
ConvertToYV12(interlaced=true)
Crop(16,12,-16,-12)
s=SeparateFields()
s.AutoGain(adjust_mode=1).AWB()
StackVertical(s,last)
#AssumeFieldBased().Weave()
give more yellow than at source. At other source script give unstable output atr preview in VirtualDub.
Please advice parameter set for AWB for my source..
yup.

[martin53]

yup,
downloaded the example.
What codec should I use to decode lagarith LAGS video (W7 x86)? my (I admit, probably outdated) AviSource/ffdshow are helpless. VLC plays, but with *heavy* blue flicker.

(Forgive my ignorance, I of course know how to run google, but at the moment don't like to spend time learning about lagarith)

EDIT:[ don't bother, XMediaRecode->HuffYUV worked.

I checked with the current script on my HD. One problem is the date stamp. The "10/" shows good white. I will add xm and ym to the parameters list to allow masking of a rectangle, please have a bit patience.
In between, you might mask that rectangle with a Overlay() line.

But aside from automatic balancing, I found ShiftCCT(5600) quite appealing in this case.

If you allow, I'll use the short sequence as additional test case. It is interesting because if flickers more than my other test clips.
]/EDIT

[StainlessS]

M53, pretty sure I've found a bug in RT_Stats RT_RGBChanxxx filters, suspend usage for a few hours, I'll do a fix.
Found it when doing MRGBChanStats() plug.

Lagarith pretty common codec for AVI YV12
http://www.videohelp.com/tools/Lagarith-Lossless-Video-Codec
Just install it, not much to learn.


But being overtaken by UT_Video (RGB,YUY2,YV12)
http://www.videohelp.com/tools/Ut-Video-Codec-Suite
I hardly ever use Lagarith or HuffYUV now.
Just install it, not much to learn.

[yup]

martin53!

I try code
AVISource("tape1.avi")
AssumeTFF()
ConvertToYV12(interlaced=true)
Crop(16,12,-16,-12)
s=SeparateFields()
s.AutoGain(adjust_mode=1).ShiftCCT(5600)
StackVertical(s,last)
And see good result. Please confirm need I use Autogain before Your AWB functions?
yup.

[martin53]

Please confirm need I use Autogain before Your AWB functions?
I was not aware of any influence between the two. When I first checked some minutes ago, the clip with AutoGain was automatically balanced in a much better way than before, but then when I compared histograms I did not find an effect of Autogain on any single pixel of a frame - and I looked very closely, with a difference amplifier. And I can not reproduce the mentioned effect now.

At the moment, I can not identify any difference. Please describe the effect you observe with/-out it.

[yup]

Hi martin53!

Your script good work for me with small adjustments. One problem it is speed on my 4 core 2 thereaded CPU (8 virtual core) I see only speed near 8-10 fps for SD (720x576). Main reason is dither plugin or Stainless plugin? How can increase speed using MT. I find work version only with SetMTMode(5) before call Your script. May be can use avstp? How?
yup.

[martin53]

yup,
thank you that you use the script!
How can increase speed
You are absolutely welcome to help finding ways. The version I published yesterday is again optimized for function, not for speed. I will optimize a few things, e.g. parallelise the statistics with StainlessS' plugins and remove steps that can be avoided. Currently, the script needs up to three runtime environments; One might be obsolete and I will check how far the other two can be combined.
It was already a great help that the MYStats plugin was made and extended after I had asked for it, and I do of course hope that I can get more help of that kind in the future.

But especially when it comes to MT, I was out of luck every time I tried until now. You and everyone else are invited to understand the script - I commented every step with some short statements - and contribute speed optimizations.

[StainlessS]

Further to PM, What is RGBBalancedShift ?

I'm guessin that Gavino could sort the prob, bUt I cannot

The big G is such a wonderful individual. :)
.

[StainlessS]

OK. I tell a lot of porkies,
BUT, I think Gavino would be the first person to say that He is the one for predictions.

[martin53]

Further to PM, What is RGBBalancedShift ?

It is in the package in 1st post. In short, it does a RGBAdjust with normalized factors so the luma stays same.

In full it is more complicated to avoid clipping, be able to deal with YUV & RGB, be called from in-/outside RTE, reduce color banding ...

Gavino responded to the bug thread in the developer forum. Very kind!

[Wilbert]

Why do you turn these scripts not into a plugin?

[martin53]

Why do you turn these scripts not into a plugin?
for two reasons.

* I like prototyping in script language, and all users have a full chance to see what happens inside - and maybe improve it.

* I avoided to set up a plugin development environment till now. I am not unexperienced in C programming, but not accommodated to C++. And from reading some developer threads, I am a bit scared.

I also have the ulterior motive that one of the experienced plugin developers can't refuse to try it.

But to warn you: One part of the script is kinda 'academic' and easy to transer to C. But the fuzzy logic to deal with many real world illuminations is more a sort of to play with and gather experience than copy and compile. Let me just mention three situations I still struggle with:
- Frames showing sky and/or water only. These are blue but need to be distinguished from a scenery that suffers from a too high color temperature
- Closeups of face/body, vegetation, rock/gravel. These may be very biased towards different colours and should not be greyed out
- Clips that were taken at tungsten light typically still show white as the brightest colour because very bright orange can't be coded into the clip, or the sensor is saturated. It is neccessary to overdo the correction only for this situation and to the appropriate amount.

The three basic approaches I cited at thread start do not cope with such challenges. The script modifies 'Shades of Gray' with some additional rules and modified parameters, with an adaptive colour-local approach etc.

[StainlessS]

Dont be a scaredy cat M53. :eek:

Hope you've seen this thread in devs (Avisynth CPP Interface for C Programmers):
http://forum.doom9.org/showthread.php?t=163082

Once you've got the standard interface worked out, you can more of less forget CPP and just code C.

(Is easier than the C interface).

[yup]

Hi martin53!
I try Your last script and find small bug :).
1. Your define variable show after first use.
reduce = Default(reduce, show?1:3) # reduction factor for the stats clips
only after 6 lines I see
show = Default(show, false)
2. I get error at line
s = replace(replace(s, "--", "+"), "+-", "-")
I install Grunt, GScript, Mystats, RT_Stats.
Please advice.
yup.

[martin53]

yup,

reduce = Default(reduce, show?1:3) # reduction Please advice.

Please change to
reduce = 1
I learned that it is better not to scale down the analysis frame, in order to leave the RGB relations of single bright pixels unchanged.

I also did a lot more of research, but was still not satisfied with the latest results, so I took a break and did not publish more recent test versions.
The hardest problem with my test clips is that with outdoor scenes, Max-RGB (also called white patch) is the best algorithm. But with indoor scenes, cameras over-expose lamps and show them as full white, while the scene itself is too warm. So, a means to detect this fundamental defect of the scene is needed - in order to switch between algorithms accordingly - and I could not yet find useful and reliable clip properties for that.

[yup]

martin53

2. I get error at line 691
s = replace(replace(s, "--", "+"), "+-", "-")
I install Grunt, GScript, Mystats, RT_Stats.
Please advice.
yup.
At Your script exist code starting from line 689
s = "((x<128+"+D_POS+" ? (y<128+"+D_POS+" ? 1 : (0.43*((128-x-0.37+"+D_POS+")^1.08) + 0.38*(exp((128-x-0.37+"+D_POS+")*0.08)-1))/(y-128-"+D_POS+")-1) : ( y>127+"+D_POS+" ? 0 : 1-(x-128+0.18-"+D_POS+")^0.8/(128-y+"+D_POS+")) > 0) & (x<128+"+D_NEG+" ? (y<128+"+D_NEG+" ? 0 : 1-(0.43*((128-x-0.37+"+D_NEG+")^1.08) + 0.38*(exp((128-x-0.37+"+D_NEG+")*0.08)-1))/(y-128-"+D_NEG+")) : ( y>127+"+D_NEG+" ? 1 : (x-128+0.18-"+D_NEG+")^0.8/(128-y+"+D_NEG+")-1) > 0) & y-x<="+minTempUV+" & y-x>="+maxTempUV+") ? 255 : 0"
s = replace(replace(s, "--", "+"), "+-", "-")
s = mt_polish(s)

When i load script in VirtualDub I get error related to replace function. Which plugin have replace function?
yup.

[martin53]

Oops, I didn't notice this lacks in the script, it is part of my standard function library.
Replace() is a shortcut for StrReplace:
Function StrReplace(string s,string find,string replace) # Repeated, string replacements
# Original:- http://forum.doom9.org/showthread.php?t=147846&highlight=gscript By Vampiredom, Gavino, IanB
#{i=s.FindStr(find)return(i==0?s: s.LeftStr(i-1)+replace+s.MidStr(Strlen(find)+i).StrReplace(find,replace))}
# Converted to use RT_Stats RT_StrAddStr() to avoid 2.58/2.6a3 string concatenation bug:-
{i=s.FindStr(find) return(i==0?s:RT_StrAddStr(s.LeftStr(i-1),RT_StrAddStr(replace,s.MidStr(Strlen(find)+i)).StrReplace(find,replace)))}
#=====================================================================================================================
Function Replace(string s,string find,string replace) { StrReplace(s, find, replace) }

[StainlessS]

m53, suggest convert to use rt_strreplace, is plugin, faster & no un-freeable temp strings created.

EDIT: Also can replace

s = replace(replace(s, "--", "+"), "+-", "-")

with

s = RT_StrReplaceMulti(s, "--"+Chr(10)+"+-" , "+"+Chr(10)+"-" )

but the Chr(10) separated multiline strings might best be constructed outside of ScriptClip/GScript rather than at each iteration.

[yup]

Hi martin53!
After introduce show before first call and add replace function I get
Subtitle at frame
ScriptClip: Function did not return a video clip! (Was an int)
my script simple
AVISource("selbuild.avi")
s=AssumeTFF().Crop(16,12,-16,-12).ConvertToYV12(interlaced=true).SeparateFields().SelectEven()
AWB(s)
StackVertical(last,s)
Please explain.
yup.

[Boulder]

Got the same error after making those small corrections needed to open the script. I'd like to give the function a shot on some VHS stuff I need to process :)

[StainlessS]

After introduce show before first call and add replace function I get
Subtitle at frame
ScriptClip: Function did not return a video clip! (Was an int)


Check error reported in DebugView(Google) during catch(err).

@m53,

Suggestions:-

Drop MYStats, convert all to RT_Stats latest funcs.

Wrap Default(floatarg,floatnum) ---> Float(Default(floatarg,floatnum))
# If user supplied function arg as int var (Gavino Tip, avoid unintended int calcs).

Convert eg cR.MYPNorm() ---> RT_RgbChanStats(flgs=req_funcs,chan=-1)
# where same funcs called for R,G,and B channels, avoid conv to Y8 and multiple individual channel individual func calls.
# Guess that you are already doing that.

Convert eg Subtitle("#") ---> RT_Subtitle("#")
# faster but perhaps not necessary nor as pretty

Also see prev post.

[Boulder]

DebugView shows this: [2896] RT_Debug: ScriptClip 3 ######## MYPlaneMin: Mask clip dissimilar dimensions.

[StainlessS]

M53, is there any reason you chose height >= 600 as rec709 switch as opposed to eg height > 576 ?

It is better than using RT_Stats default Width>720, shall change RT to same as yours.

EDIT:
The fault reported by Yup and Boulder, resides here:-

cu = cYUV.UToY
cv = cYUV.VToY

Umin = MYPlaneMin(cu, cYUV, MaskMin=UVRANGE_CHECK_YMIN, MaskMax=255)


The debugview message "MYPlaneMin: Mask clip dissimilar dimensions." is issued by MYPlaneMin, (Throws the error)
cu and cv are quarter size (w/2,h/2) of mask when YV12.
If YV24 supplied to func then does not throw error but returns YV12 instead.

[martin53]

First, my apologies to all I did not answer earlier.
StainlessS, thanks for the suggestion. I copied the 600 threshold for the matrix somewhere, don't remember where. The future version on my HD is already mxRec = clp.width<=720?"Rec601":"Rec709". I agree that it is of advantage to be in line.

Luckily, I just read your post, because I was on the way to implement MYStats instead of MRGBStats because I hadn't seen that RT_Stats now includes all functions I need. Thanks you assembled everything together.

As for the bugs with the published script - it is difficult to keep up at the moment, because several things happened in parallel: the xxxStats functions grew better and were merged, I debugged the script and made it more robust, and I improved the algorithm. I can impossibly publish todays working version - it would cause too many questions and errors.

The most annoying and challenging issue is that consumer cameras depict warm white lamps as RGB=fully white, although the scene itself is balanced towards yellow. I.e. the white is heavily biased and unsuitable for AWB purposes. This has heavy impact because in almost every situation, the 'max RGB' alias 'White Patch' algorithm is the one which meets expectations best. In the meantime, I prepared three sets of reference clips with 'difficult' footage - and alas, the algorithm still produces inacceptable output with some scenes.

My proposal is that I'll concentrate on switching over to RT_Stats and provide a version that runs, and then continue with the improvements of the algorithm. Please have a few days more patience! Thanks!

EDIT: RT_Stats issue, see RT_Stats thread

[martin53]

M53, is there any reason you chose height >= 600 as rec709 switch as opposed to eg height > 576 ?

Firesledge (aka Cretindesalpes) in dither.html:
When the parameter is not defined, ITU-R BT.601 and ITU-R BT.709 are automatically selected depending on the clip definition (considered as HD if ≥ 600 lines).
:confused:
For me, width>720 is a reasonable distinguishing mark for HD. I paid homage to Cretindesalpes' greater experience.

[martin53]

OK everyone,
a running version is attached to 1st post. Don't blame me for any flaws please, work in progress.

[StainlessS]

M53, have changed 709 switch to > 600, is the better choice. RT_ updated, hope it works for you.

[yup]

Hi martin53 :thanks:
Last version work properly. I see improvements for my VHS capture source.
I see some speed up.
yup.

[StainlessS]

from AWB

# Calculate statistics from RGB clip
# a) Average of Maximum for White Patch (global color evaluation)
MRGBChanStats(cRGB, mask=cGamutMask, delta=delta, Chan=-1, flgs=$12, prefix="fRGB_", MaskMin=fGY_yMax-1)
if (RT_VarExist("fRGB_Ave_0") && RT_VarExist("fRGB_Ave_1") && RT_VarExist("fRGB_Ave_2")) {


From later EDIT to MRgbChanStats, to make same as MYStats docs
EDIT: Returns 0 if no pixels found in search area of mask within MaskMin and MaskMax.

Should use result of MRgbChanstats, testing for non 0 instead of RT_VarExist().

To be more specific, if no valid pixels found in masked area returns 0, the relevant channel pixel counts are set to 0
and no other global variables are altered in any way, ie will not be nullified nor deleted, if those variables already existed
before call, will remain in previous state.

Also note, I think we got crossed wires somewhere, I said I would alter RT_ 709 switch to be same as yours, based on height >= 600,
have now made that change in RT_Stats (also done but not released in RoboCrop, MYStats and one or two other places).
You have now changed yours to match my previous RT_stats, ie switched on width > 720.
ALL CHANGE PLEASE. :)
I shall keep same as you previously had it based on height >= 600, if its good enough for FireSledge (Cretindesalpes) its good
enough for me.

[martin53]

OK, fine with everything,
was confused a bit with the handling of variables and posted a question in the RT_Stats thread.
When existing variables are unaltered in the case of pixelcount==0, I need to set them to a neutral value in advance. Say I use chan=-1 then I can not know in advance whether all three channels will return data - although I'd think if one channel does, all channels should.
My observation was that when I initialize variables before I call RT_RgbChanStats, the function does not change them.
I observed some non-credibly low averages with real world footage, but was retarded with my tests by the variables thing.
Maybe I confused the system with local over global variables. Will check that.
However, the whole thing is a bit tricky to master, I think, for newbies, and maybe it should be redesigned a bit.

Will change back to height >= 600, no problem :)

[StainlessS]

Will answer in RT_Stats thread. EDIT: Here:-http://forum.doom9.org/showthread.php?p=1648305#post1648305

[SamKook]

Why not use width >= 900 to detect HD(which is what I personally use in some of my scripts)?
I don't have any concrete example in mind, but with some anamorphic 720p movies, I'm fairly certain that the height could drop below 600px, but the width should never drop much below 960px(4:3) for any HD sources and SD ones shouldn't be much over 854px(resized 16:9).

I mostly work with NTSC sources so maybe PAL ones would make my reasoning wrong though.

[yup]

Hi martin53!

I try last script version. Source was 50Hz after QTGMC.
SetMemoryMax(1024)
global MeGUI_darx=4
global MeGUI_dary=3
AVISource("chapter13f.avi")#.Trim(0,10000)
AssumeTFF()
AutoGain(adjust_mode=1)
AWB()
unsharp(varY=310,varC=155,strength=0.15,U=3,V=3)
SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
AddBorders(16,12,16,12)
https://www.dropbox.com/s/i1tpg7o7wskks6s/encawb.mp4
From 1:30 min encoded only 28 min, ant at medium file changing color balance, see file at Dropbox.
May be problem related to Global variables?
yup.

[martin53]

Only had time for a glimpse at your clip, but saw the sudden change at 8:39. Is the color after this time the original clip color? If so, the script is performing well up to this point, i feel :)
Before I answer your post, please allow me a note about the date stamp you use in this and the former example clip. Since the date stamp is created digitally, it is not part of the scene and might misguide the AWB estimation. You may supply a mask to the AWB script. The mask should be black in the area of the date stamp, then this area is excluded from the estimation.
Regarding your problem with the script and a longer clip, I share your suspicion about the variables. I was told that string memory is not cleaned up until script destruction, and therefore I minimise sring usage in RTE functions. Still, I don't know if this is also true with the GRunT plugin and local variable scope. And I have the suspicion that maybe the RTE script itself is a new string for every frame :(
I plan to rewrite the script as a plugin, but that will not happen in very near future. I saw that ultim is committedly working on AviSynth+. You might ask him if he's willing to implement string garbage collection during script serve stage (not possible with strict realtime requirements of course, but no problem with non-realtime processing scripts, and a great help).

As a short time workaround, I can only propose you split clips into parts of about 30', and join them after processing. It's what I do with the FSubstitute() script, which is even more complicated+long+demanding.
EDIT: For non-dynamic illuminant color situations, as your examples seem to me, I also suggest you use the ShiftCCT() script instead of AWB(). AWB() is able to adjust R, G, B independently, ShiftCCT() can only adjust along the temperature of a planckian radiator, and requires you to enter the originating color. But often, the result may still be pleasing.

[StainlessS]

ask him if he's willing to implement string garbage collection

Not sure if this could be possible, plugin writers call env->SaveString() to safely return a string (at least they are
supposed to) and the string is said to be a safe place to (EDIT: later) store whatever a plugin writer wishes, so long as he does
not overwrite outside of the original saved string boundaries. Would be hard not to break things without an entirely
differently defined new env->TempString() or whatever it might be called, perhaps free'ed on function exit.
(EDIT: Memory not re-usable by plugin writer, with memory total ownership passed to Avisynth.)