Automatic White Balance (AWB) script function(s)

[martin53]

Originally Posted by StainlessS

Not sure if this could be possible

Maybe it's a bit useless conversation here, I don't see fundamental problems.
The main problem seems to come from the fact that AviSynth just allocates string heap as ScriptClip("") & friends functions are evaluated again and again (those taking a string as a script), see Gavino's response

string memory in Avisynth is orthogonal to the scope of variables and, as you say, is not released until script destruction.

I don't want to be unfair of course, this is what I understood so far.

[StainlessS]

Perhaps strings created internally by Avisynth could be cleaned up, but the env->SaveString() thing is defined as
a possible permanent storage area for plugins, so would have to remain as is.(I think).
EDIT: ie any strings returned by external plugins. Perhaps new env->TempString() (or whatever)
could return total ownership to Avisynth and so be cleaned up, older plugins returning strings via env->SaveString() not so.
Internal/TempString would need some kind of secret indicator that it is clean-upable.
EDIT: SaveString() would best be deprecated. [Except for OnExit() type functions, where permanence is required]

If this came about, think I would seriously consider dropping all support for v2.58.

[martin53]

Well, if I understand the Filter SDK example right,

     fnpluginnew = new char[string_len];
     
     strcpy(fnpluginnew, fnplugin.AsString());
     strcat(fnpluginnew, " ");
     strcat(fnpluginnew, name);
     
     env->SetGlobalVar("$PluginFunctions$", AVSValue(env->SaveString(fnpluginnew, string_len)));
     
     // Since fnpluginnew has now been saved it can safely be deleted.
     
     delete[] fnpluginnew;

env->SaveString() releases the plugin from the duty to release the memory when the plugin destructor is called. I could not identify companion functions like env->ReplaceString(), env->ReleaseString() and env->GetString(), so the meaning of this 'write only memory' is unclear to me at the moment , but it seems obvious, and the Filter SDK notes this, env->SaveString() is not meant to be called again and again for the same string,

But you must still remember that these strings are not deallocated until the filter is unloaded. So in general if you don't want your filter to be allocating more memory on each load, try avoiding using non-const strings.

but instead env->ReplaceString() would come in here °?°

[StainlessS]

try avoiding using non-const strings

This refers to the "$PluginFunctions$", if GlobalVar name is string literal, then no need to save anywhere, its always in the
same place in memory, and SetGlobalVar will set it to point at that location in mem.
If GlobalVar name is NOT string literal(non-const), and GlobalVar name does NOT already exist, then also need to SaveString for the
GlobalVar name too, if already exist then SetGlobalVar will re-use the original existing name string. (no point in saving)

The SaveString thing just allows plugin to pass string to Avisynth, so that Avisynth will make a copy of the string (using
the Avisynth memory allocators rather than plugin dll allocator, would be problematic/impossible for Avisynth to deallocate memory
allocated via a plugin dll compiled using different compiler, and/or not in avisynth memory lists), and that it is up to Avisynth
to delete that memory at closedown.

EDIT: Somewhere in SDK or other docs, it is said that plugin can re-use SaveString'ed memory area as it exists until closure,
so long as does not overwrite original saved memory boundaries, so could cause problems to RARE (mainly OnExit) plugin if they rely
on that memory being later available if it has been 'cleaned up'.

EDIT: Also applies to local vars, not specific to Global.

EDIT: If you use a fixed name Global/Local var as a return, then as for above "$PluginFunctions$" as it does not change,
however if using an eg user supplied prefix to create unique variable names then must save unless that unique name already
exists as a variable.

[martin53]

yup,
I had been concentrating on variables and stability, and today found at least one severe bug in the adjustment formulas itself.

Please wait for a few more days, I'll fix it. Then the algorithm will still be not perfect, but I hope it can meet average expectations then.

Good news is: I implemented RT_Stats arrays and the script now allows full nonlinear access. This is to say: you may navigate to every frame you want; the script will go backward to the next scene change, calculate all frames from there up to the current frame once, and store the RGB adjustment factors. Then, if you navigate to one of the already evaluated frames, it is directly adjusted with the factors from the stored array. Hooray!

[StainlessS]

Just thought I'de give a BUMP here to say that new version AWB posted today by Martin53 (1st post).

[udobroemme]

I'm not able to run the script. I'm getting the following error:



My script:

ffvideosource("xyz.avi",threads=1)
awb()

I've tried also different source filters and different avi sources without luck.

I'm using the latest avisynth MT version and the plugin versions listed at the end of the script.

[StainlessS]

Line in red is error producing line (line 386) [I THINK]:

            # Calculate basic determination data from YUV clip
            flags = RT_YStats(cYUV, mask=cGamutMask, delta=delta, threshold=MINMAX_THRESH, flgs=$02, prefix="fGY_", MaskMin=18, MaskMax=255)
            if (flags != $02) { eval_error = true }
            flags = RT_YStats(cU,   mask=cGamutMask, delta=delta, threshold=MINMAX_THRESH, flgs=$17, prefix="fGU_", MaskMin=18, MaskMax=255)
            iMinLuma = max( RT_VarExist("fgY_yMax") ? fGY_yMax : 18, iMinLuma)
            RT_ArraySet(iBright%%%, iMinLuma, current_frame+delta)
            flags = RT_YStats(cV,   mask=cGamutMask, delta=delta, threshold=MINMAX_THRESH, flgs=$17, prefix="fGV_", MaskMin=18, MaskMax=255).BitAnd(flags)
            if (flags != $17) { eval_error = true }

Perhaps try Info and Show args to provide Martin53 with some additional hints.

I am leaving home now and will be away from home machine until tomorrow.

EDIT: Could also insert eg below lines immediately before error line just to see what they are (in debugview)

  RT_DebugF("eval_error=%s",string(eval_error)) 
  RT_DebugF("iMinLuma=%s",string(iMinLuma))

[martin53]

Originally Posted by udobroemme

ffvideosource("xyz.avi",threads=1)
awb()

Please recheck with AviSource(). On my machine, ffvideosource produced exceptions in AvsPmod - but I use V2.6 alpha 5, no MT dll. Changed to AviSource() ran fine.
Also, please try without MT.
If that does not reveal the cause, please post the RT_DebugF() output lines.

[udobroemme]

I've now tried it with regular avisynth 2.6 alpha 5 and also with avisource and always get the above mentioned error.
Even if I call awb(info=1) to get debug output, nothing changes.

If I go to a frame that's not the first after a scene change, I get the following:

[martin53]

EDIT: you write that you still get the above mentioned error, and the new one on top of it. The only cause I can imagine at the moment is that there is some incompatibility between your RT_Stats and your AviSynth, because I really have no idea how both things - a non-int variable plus the invalid array index should happen at a time, regardless of source filter or footage, so persistently on your system. You say you checked several AviSynth versions. I'm sure you also checked that you installed RT_Stats26.dll and don't also have a RT_Stats.dll?

Because the GScript() string starts at line 285, line 70 of it is line 355 of the file. It seems GScript returns the line where the while loop closes. That would mean the exception comes from inside the while loop, and there are several RT_ArrayGet() functions inside. It looks like a negative sum current_frame+delta appears but I can not figure out where.

Please insert the two red lines into the script, they will be line 348 and line 350 afterwards, and run DebugView.

				bSceneStart = (current_frame == 0 || fSC > ThSc)
				RT_DebugF("AWB%%% Seeking scene start,      current_frame:%d, delta:%d", current_frame, delta)
				while (!bSceneStart && !RT_ArrayGet(bDone%%%, max(current_frame+delta-1,0)) && !RT_ArrayGet(bDone%%%, current_frame+delta)) {
					RT_DebugF("AWB%%% Seeking scene start loop, current_frame:%d, delta:%d", current_frame, delta)
					if (!RT_ArrayGet(bDone%%%, current_frame+delta)) {
						fSC = RT_LumaSceneChange(cYUV, cYUV, delta=delta, delta2=delta-1)
						bSceneStart = (current_frame+delta == 0 || fSC > ThSc) ? true : false

The output should read like this (frame 20 is not the 1st after a scene change in my example clip). AWB goes backward to a scene change or clip start and then goes forward compensating frame after frame.

[5620] RT_DebugF: AWB1 Seeking scene start,      current_frame:20, delta:0
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:0
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-1
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-2
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-3
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-4
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-5
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-6
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-7
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-8
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-9
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-10
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-11
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-12
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-13
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-14
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-15
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-16
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-17
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-18
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-19
[5620] RT_DebugF: AWB1 Seeking scene start loop, current_frame:20, delta:-20
[5620] RT_DebugF: AWB1 #0 iMaskMin: 234
[5620] RT_DebugF: AWB1 #1 iMaskMin: 234

[udobroemme]

Thanks for Debugview, I didn't know that tool so far. It spits out the following:

[4204] CallCmd: Constructor IN
[4204] CallCmd: CallCmd: v1.02 - 01 Jan 2012 - by StainlessS
[4204] CallCmd: Command for Frames = ''
[4204] CallCmd: Close Command (Destructor) = 'CMD /C del C:\Users\Boeschi\AppData\Local\Temp\bDone1_20131207_103711_430.tmp'
[4204] CallCmd: FRAMES: About to Parse Frames String
[4204] CallCmd: Doing command on 0 Frames
[4204] CallCmd: Constructor OUT
[4204] CallCmd: Constructor IN
[4204] CallCmd: CallCmd: v1.02 - 01 Jan 2012 - by StainlessS
[4204] CallCmd: Command for Frames = ''
[4204] CallCmd: Close Command (Destructor) = 'CMD /C del C:\Users\Boeschi\AppData\Local\Temp\fRGB1_20131207_103711_430.tmp'
[4204] CallCmd: FRAMES: About to Parse Frames String
[4204] CallCmd: Doing command on 0 Frames
[4204] CallCmd: Constructor OUT
[4204] CallCmd: Constructor IN
[4204] CallCmd: CallCmd: v1.02 - 01 Jan 2012 - by StainlessS
[4204] CallCmd: Command for Frames = ''
[4204] CallCmd: Close Command (Destructor) = 'CMD /C del C:\Users\Boeschi\AppData\Local\Temp\iBright1_20131207_103711_430.tmp'
[4204] CallCmd: FRAMES: About to Parse Frames String
[4204] CallCmd: Doing command on 0 Frames
[4204] CallCmd: Constructor OUT
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:0, delta:0
[4204] RT_DebugF: AWB1 #0 ________ New scene init________fSC=0.0
[4204] RT_DebugF: AWB1 #0 delta 0 R:1.000 G:1.000 B:1.000
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:1, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:2, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:3, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:4, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:5, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:6, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:7, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:8, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:9, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:10, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:11, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:12, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:13, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:14, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:15, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:16, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:17, delta:0
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:18, delta:0

Btw.: I use the latest script from 12.01. and the inserted lines are at 337 and 339, not at 348 and 350 like you mentioned.

[martin53]

Originally Posted by udobroemme

Debugview spits out the following
...
latest script from 12.01. inserted lines are at 337 and 339

Sorry about the different line numbers, seems I inserted something above - maybe the assertion that no RT_Stats.dll exists, nothing of importance, I'm sure.

It looks like you navigated from frame #0 forward. Frame #0 is a scene start and results in no color adjustment. Then each frame finds its predecessor already done and can start from there

while (!bSceneStart && !RT_ArrayGet(bDone%%%, max(current_frame+delta-1,0)) && !RT_ArrayGet(bDone%%%, current_frame+delta)) {

Info=2 makes AWB verbose in the DebugView output.
Complete output for one frame might look like

[1656] RT_DebugF: ______________________
[1656] RT_DebugF: AWB1 #0 Check point 1
[1656] RT_DebugF: AWB1 Seeking Scene start,      current_frame:0, delta:0
[1656] RT_DebugF: AWB1 #0 ________ New scene init________fSC=0.0
[1656] RT_DebugF: AWB1 #0 delta 0 R:1.000 G:1.000 B:1.000
[1656] RT_DebugF: AWB1 #0 Umin:77.0 UMax:130.0 Uave:-14.9 Vmin:127.0 VMax:176.0 Vave:12.5
[1656] RT_DebugF: AWB1 #0 Ymax:233.0  Red:-20.9
[1656] RT_DebugF: AWB1 #0 Luma:233.0 UVarea:2597.0 UVavg:-27.4
[1656] RT_DebugF: AWB1 #0 iMaskMin: 232
[1656] RT_DebugF: AWB1 #0 Rmax:249.0 Gmax:234.0 Bmax:210.0
[1656] RT_DebugF: AWB1 #0 Red:263.3 Grn:221.5 Blu:167.9
[1656] RT_DebugF: AWB1 #0 After Temp check R:0.857 G:1.006 B:1.343
[1656] RT_DebugF: AWB1 #0 Factors R:0.857  G:1.006  B:1.343
[1656] RT_DebugF: AWB1 #0 Check point 2

(Instance- and Frame # always precede the information in case you have multiple instances in the graph or as part of temporal processing)
If check point 2 (ScriptClip end) is not reached, it is of interest where the script is terminated; a string search for the output lines above can narrow down the line.

According to RT_Stats.txt line 1991, RT_ArrayAlloc() initializes the arrays. I rely on that, so there is no script level initialization loop. The RT_Array... functions open a new dimension in scripting ( in both meanings of the word ) but they are quite new. I'm really curious what we'll find in the end.

[udobroemme]

With info=2 I get the following output:

[4204] RT_DebugF: AWB1 #0 Check point 1
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:0, delta:0
[4204] RT_DebugF: AWB1 #0 ________ New scene init________fSC=0.0
[4204] RT_DebugF: AWB1 #0 delta 0 R:1.000 G:1.000 B:1.000
[4204] RT_DebugF: ______________________
[4204] RT_DebugF: AWB1 #1 Check point 1
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:1, delta:0
[4204] RT_DebugF: ______________________
[4204] RT_DebugF: AWB1 #2 Check point 1
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:2, delta:0
[4204] RT_DebugF: ______________________
[4204] RT_DebugF: AWB1 #3 Check point 1
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:3, delta:0
[...]
[4204] RT_DebugF: AWB1 #62 Check point 1
[4204] RT_DebugF: AWB1 Seeking scene start,      current_frame:62, delta:0
[4204] RT_DebugF: AWB1 #62 ________ New scene init________fSC=36.3
[4204] RT_DebugF: AWB1 #62 delta 0 R:1.000 G:1.000 B:1.000
[4204] RT_DebugF: ______________________

At frame #62 there's the next scene change. The script seems to terminate right after the start and starts a new instance for the next frame.

[martin53]

Please add the red characters to line 366, 372 and 386 (you can remove the two additional RT_DebugF lines we inserted, we'll probably not need them any more)

RT_ArraySet(iBright%%%, round(iMinLuma), current_frame+delta)

[udobroemme]

That did the trick for the first frame after a scene change, but the others are still not ok:

[2448] RT_DebugF: ______________________
[2448] RT_DebugF: AWB1 #0 Check point 1
[2448] RT_DebugF: AWB1 #0 ________ New scene init________fSC=0.0
[2448] RT_DebugF: AWB1 #0 delta 0 R:1.000 G:1.000 B:1.000
[2448] RT_DebugF: AWB1 #0 Umin:128.0 UMax:128.0 Uave:-0.0 Vmin:128.0 VMax:128.0 Vave:0.0
[2448] RT_DebugF: AWB1 #0 Ymax:19.0  Red:-0.0
[2448] RT_DebugF: AWB1 #0 Luma:19.0 UVarea:0.0 UVavg:-0.0
[2448] RT_DebugF: AWB1 #0 Color range small. U:128.0 V:128.0
[2448] RT_DebugF: AWB1 #0 Red:235.0 Grn:235.0 Blu:235.0
[2448] RT_DebugF: AWB1 #0 After Temp check R:1.000 G:1.000 B:1.000
[2448] RT_DebugF: AWB1 #0 Factors R:1.000  G:1.000  B:1.000
[2448] RT_Debug: RGB, locus, intersect after process 25 24 29   2.3   0.1   1.7  -1.0
[2448] RT_DebugF: AWB1 #0 Check point 2
[2448] RT_DebugF: ______________________
[2448] RT_DebugF: AWB1 #1 Check point 1
[2448] RT_DebugF: ______________________
[2448] RT_DebugF: AWB1 #2 Check point 1
[2448] RT_DebugF: ______________________
[2448] RT_DebugF: AWB1 #3 Check point 1
[2448] RT_DebugF: ______________________
[...]
[2448] RT_DebugF: AWB1 #62 Check point 1
[2448] RT_DebugF: AWB1 #62 ________ New scene init________fSC=36.3
[2448] RT_DebugF: AWB1 #62 delta 0 R:1.000 G:1.000 B:1.000
[2448] RT_DebugF: AWB1 #62 Umin:130.0 UMax:134.0 Uave:4.2 Vmin:130.0 VMax:134.0 Vave:4.4
[2448] RT_DebugF: AWB1 #62 Ymax:221.0  Red:-2.0
[2448] RT_DebugF: AWB1 #62 Luma:221.0 UVarea:16.0 UVavg:-0.2
[2448] RT_DebugF: AWB1 #62 Color range small. U:130.0 V:128.0
[2448] RT_DebugF: AWB1 #62 Red:235.0 Grn:233.9 Blu:238.5
[2448] RT_DebugF: AWB1 #62 After Temp check R:1.000 G:1.001 B:0.995
[2448] RT_DebugF: AWB1 #62 Factors R:1.000  G:1.001  B:0.995
[2448] RT_Debug: RGB, locus, intersect after process 251 217 231   1.3  15.9  -5.8   3.3
[2448] RT_DebugF: AWB1 #62 Check point 2
[2448] RT_DebugF: ______________________

[martin53]

General AviSynth syntax states that a literal assignment 'iMinLuma = 1' makes iMinLuma an integer variable.

BlankClip()
i = int(1)
IsInt(i) ? Subtitle("i has type integer") : last
IsFloat(i) ? Subtitle("i has type float",y=20) : last

This displays both texts on my system. If i is set to e.g. 1.1, it displays only the float text, and if i is a string, it displays none of the texts.

It is a vague idea, but maybe one of your plugins affects the way RT_Stats gets/interprets the variable types. I never heard about something like this though. I'll PM StainlessS about the question and could you please move all your other plugins to a different folder temporarily for a check?

EDIT: You can test the round(...) statement in every RT_ArrayGet() function around the 2nd parameter. It might help with your system, but I don't understand why it should be neccessary in general, and it would bloat the code and slow the script down a bit.

[Gavino]

IsFloat() returns true for ints as well as for floats.
In effect, it really means 'is numeric'.

http://avisynth.nl/index.php/Interna...lean_functions

IsFloat(2) = true # ints are considered to be floats by this function

[udobroemme]

Originally Posted by martin53

EDIT: You can test the round(...) statement in every RT_ArrayGet() function around the 2nd parameter. It might help with your system, but I don't understand why it should be neccessary in general, and it would bloat the code and slow the script down a bit.

That did it. It works now. I don't mind about a little slowdown.
Thank you very much for all your efforts and of course for the script.

[Gavino]

Originally Posted by martin53

General AviSynth syntax states that a literal assignment 'iMinLuma = 1' makes iMinLuma an integer variable.

I don't think it actually does say that.
Variables don't have types, only values do.
In particular, if you later assign a float value to iMinLuma, the variable will then hold that float value; it is not truncated or rounded to an integer.