Hdr Agc 1.8.7 - 10.09.2006

[paviko]

HDR AGC version 1.8.7

More info and download at my homepage (http://strony.aster.pl/paviko/)

-----
MODERATOR Note: This link is dead. Use this one:

https://web.archive.org/web/20131018094707/http://strony.aster.pl/paviko/hdragc.htm
-----

High Dynamic Range Automatic Gain Control - this plugin increase dynamic range of video clips (enhance shadows). It's "simply" gaining (brightening) dark areas of image without causing blow of highlights and is doing it by simulating the work of our eyes. Amount of gain is calculated automatically but you can also influence on it by parameters.

This plugin support YV12 and YUY2 color sprace.
Usage:
AVISource(...)
SeparateFields() # if content is interlaced
HDRAGC()
Weave() # if content is interlaced

MOST IMPORTANT PARAMETERS:
coef_gain (default 1.0) - increase parameter to get brighter image, decrease to limit auto brightening
coef_sat (1.0) - incerease to bring more saturation


TODO for 2.0 version
- MMX, SSE, SSE2 optimization


Tips:
1. I'd like to have brigther results.
Try increasing coef_gain and/or min_gain
2. Image lacks colours saturation after brightening
Try increasing coef_sat parameter
3. I would like to operate only in luma (without changing chrominance channels)
Set max_sat to 1.0
4. When I set coef_sat lower that 1.0, bright area of image are loosing saturation
Set min_sat to 1.0 (default value id 0.0)
5. Bright areas of image are too much gained
Try corrector parameter - recommended values are (0.8 - 1.0), the lower value then less gain is applied to brighter part of image
6. Gained parts have too much noise
Try increasing reducer parameter. Default value is 0.5, max is 2.0

[morsa]

Wow. I always like this kind of things!!!!!

[videoFred]

Congratulations!

This filter looks very, very promising.
Could this be a real auto-levels filter at last?
Is it possible to add an auto-gamma setting too?

Fred.

[Mug Funky]

kickass! this could really help with the Zion scenes in the matrix trilogy (baaad lighting ratio right thurr).

not sure if it'll help on some grainy-as-hell and dark DV footage i have, but i don't expect anything to save that.

i think i'll wait for some optimization - i'm running a 5 year old machine, so every cycle is sacred.

[edit] i can see this becoming very useful for avisynth 3, if it ends up supporting 16bpc video - HDR is best suited to more-than-8-bits.

hehe. i'm a bit of an HDR fan - i've even got one of those mirror-ball light-probe things, though i hardly use it anymore (it's warped at the seam...).

[paviko]

@videoFred
Is it possible to add an auto-gamma setting too?
Why would you like to auto control gamma?
Gamma is causing some contrast loss, that's why HDR technics were invented to overcome this.
But maybe it can be usefull. Could you describe in more detail how you imagine the gamma control? Of course the best would be image examples showing diffrent situations ;)

@Mug Funky
this could really help with the Zion scenes in the matrix trilogy (baaad lighting ratio right thurr) This plugin works best with low compressed input like DV stream, where lots of details are preserved in dark areas. I don't know if MPEG2 isn't too lossly compression (depends on how the film was compressed). The more compressed input then less gain would be possible without artefacts.

not sure if it'll help on some grainy-as-hell and dark DV footage i have
I've done this plugin for my home DV shoots (birthdays, etc.) :) Of course without good denoiser (fortunately we've got here the best ones: MVTools, FFT3D) we can't do much. But today mainstream camcorders (eg. Pana GS-120, Sony HC-85, Canon Optura) easily handle gain as much as 3.0 times.
Those examples posted by me are from Panasonic GS200, Sony PC350 and Sony PC85.

i can see this becoming very useful for avisynth 3, if it ends up supporting 16bpc video - HDR is best suited to more-than-8-bits.
Yes but when we will be able to touch devices recording in 16-bit format ;)

Regards

[Backwoods]

http://img235.echo.cx/img235/4666/wall05fe.jpg

HDRAGC(max_gain=1.5)

Awesome filter.

[AVIL]

Felicitations. This is an superb filter.

I've done a benchmark with virtualdub's filter "MSU Smart Brightness & Contrast" and the result is favourable to your filter. Your image has no halos, better contrast and less pixelation in dark areas.

Only one doubt. I've tried with different values (from 16 to 255) for avg_lum but with no visual changes at all. ¿Do this parameter depend on others?

I often process VHS captures (YUY2 colorspace). I can accept promote to RGB. The return to YUY2 is almost lossless. The return from YV12 isn`t lossless. Despite the evolution to YV12 ¿It will be possible to preserve RGB processing in future releases?.

Thanks.

[videoFred]

Originally posted by paviko
@videoFred

Why would you like to auto control gamma?
Gamma is causing some contrast loss, that's why HDR technics were invented to overcome this.
But maybe it can be usefull. Could you describe in more detail how you imagine the gamma control? Of course the best would be image examples showing diffrent situations ;)



I did a very first test on some very dark files and the result was even better if I increased the gamma with VDub. But this was a very first and promising test on some divX files. At home, I have tons of huge 1024x768 Huffyuv files, and a fast computer. I do some more testing, and report the results here, but I need at least a week for this. ;)

Fred.

[Didée]

paviko, this is very nice work. A little sluggish ;) , but results are really impressing!

It reminded me of the fact that in one of my postponed scripting projects, there is some code gathering dust for half a year now, that tries to do something rather similar. (Namely: the "contrast booster" feature of "LimitedSharpen-EX".)

The principle of operation is less sophisticated and precise (general limitations of AviSynth scripting). In exchange, it runs somewhat faster than HDRAGC() ... 10 times, or more.

Result when feeding the "lowlight" JPEG from above as input, via imagereader:

http://img199.echo.cx/img199/300/lsharpenexconenh1mw.th.jpg (http://img199.echo.cx/my.php?image=lsharpenexconenh1mw.jpg)

If someone is interested in the (unfinished) AVS code, drop a line here. Basically, an ultra-wide gaussian blur is done, then the difference to the original is square-rooted, and fed into a modified multiplication/hardlight routine.

(Should I think about writing PDF whitepapers ...) ;)

[joshbm]

Didee I am interested. I am also interested in LimitedSharpen-EX ;-).

[paviko]

Thank you all for your replies.

@AVIL
Only one doubt. I've tried with different values (from 16 to 255) for avg_lum but with no visual changes at all. ¿Do this parameter depend on others?
Thank you for reporting this. It's a bug, avg_lum parameter is partially reversed in code now, so it's definitaly not working as it's supossed to work.
¿It will be possible to preserve RGB processing in future releases?. RGB32 will be always supported in this plug-in. Gaining in RGB space is not causing loss of saturation. I haven't tried yet solving equation for YUV colour format, so I don't know if the plug-in will work the same in YUV, but it will be faster. It's also possible that YUY2 version will be added too.

@videoFred
Thanks, waiting for your reports :)

@Didée
it runs somewhat faster than HDRAGC() ... 10 times, or moreI'm planning to optimize these filter, don't know exactly how much faster it will run. Probably the ultra-wide gaussian you are using is highly optimized by avisynth developer team. In my plug-in the most computational task is calculating average brigthness with inclusion of simulating human eye reaction (should I believe what is written in this article ? ;) ) - it's like reading one frame of video 150 times.
If someone is interested in the (unfinished) AVS code, drop a line here. Basically, an ultra-wide gaussian blur is done, then the difference to the original is square-rooted, and fed into a modified multiplication/hardlight routine.
Yes please post it Didée, I'm especially interested in your "modified multiplication/hardlight routine" :)
Should I think about writing PDF whitepapers ... Definately yes :)

Regards

[tsp]

paviko: I took a look at you code and did a little profiling on it. it seems if it's this loop that's taking about 75% of the time:

for (h=0; h < src_height;h++) { // Loop from bottom line to top line.
for (w = 0; w < src_width/4; w++) { // and from leftmost pixel to rightmost one.
int miny = h - circle;
if (miny < 0)
miny = 0;
int maxy = h + circle;
if (maxy > src_height - 1)
maxy = src_height - 1;
int minx = w - circle;
if (minx < 0)
minx = 0;
int maxx = w + circle;
if (maxx > src_width / 4 - 1)
maxx = src_width / 4 - 1;
y_local[h][w] = 0.0f;
float w_sum = 0.0f;
for (int y = miny; y <= maxy; y++)
for (int x = minx; x <= maxx; x++){
if (circleMat[w - x + circle][h - y + circle]){
float weight = weights[y_lum[y][x]][y_lum[h][w]];
w_sum += weight;
y_local[h][w] += weight * y_lum[y][x];
}
}
y_local[h][w] /= w_sum;
}
}

I changed it to this and gained about 25% speed increase:

for (h=0; h < src_height;h++) { // Loop from bottom line to top line.
int miny = h - circle;
if (miny < 0)
miny = 0;
int maxy = h + circle;
if (maxy > src_height - 1)
maxy = src_height - 1;

for (w = 0; w < src_width/4; w++) { // and from leftmost pixel to rightmost one.

int minx = w - circle;
if (minx < 0)
minx = 0;
int maxx = w + circle;
if (maxx > src_width / 4 - 1)
maxx = src_width / 4 - 1;
//y_local[h][w] = 0.0f;
float y_local_h_w=0.0f;
float w_sum = 0.0f;
int y_lum_hw=y_lum[h][w];
for (int y = miny; y <= maxy; y++)
for (int x = minx; x <= maxx; x++){
if (circleMat[w - x + circle][h - y + circle]){
int y_lum_xy=y_lum[y][x];
float weight = weights[y_lum_xy][y_lum_hw];

w_sum += weight;
y_local_h_w += weight * y_lum_xy;

}
}
y_local[h][w] = y_local_h_w/w_sum;
}
}


Else a very nice filter.

[Yuri]

Unfortunately, I only get a green screen when I load this filter through VDub. Why so? What am I doing wrong?

[Backwoods]

Do you have "ConvertToRGB32()" before the filter's functions?

[Yuri]

Now it works!
Thank you, Backwoods.

[Bordo32]

@paviko, very nice and promising filter :cool:

Just a thought, if by using AVISource(...) DV codec opens avi file in YUY2 space, the next line ConvertToRGB32() will expand luma from 16-235 range to 0-255. All details below 16 and above 235 will be lost. We know that most of miniDV cams have overshoots in luma up to 255.
Would it be better use:
ConvertToRGB(matrix="PC.601") and have a full luma range?

It might be stupid question, but I am just curious, is this filter is interlaced aware, does not require those SeparateFields() Weave() type of things?

[Wilbert]

Would it be better use:
ConvertToRGB(matrix="PC.601") and have a full luma range?
Yes, you can try that. Best is to compare both and see what you like best.

It might be stupid question, but I am just curious, is this filter is interlaced aware, does not require those SeparateFields() Weave() type of things?
Nope, because the avi is opened as YUY2 (you only need it if source or target is YV12).

[paviko]

@backwoods
I've looked closer to your frame grab and I'd like to have you camcorder :eek: It's perfectly keeping colour information in dark areas. Is it a professional camcorder? The best result with such a good devices can be obtained when max_sat parameter is set to 1.0. Otherwise colours can be boosted too much.

@tsp
Thank you very much for your help, it definately should be like you posted.

@Bordo32
the next line ConvertToRGB32() will expand luma from 16-235 range to 0-255I've never thought about this, because I've instaled DV codec that is using 0-255 range. I think that ConvertToRBG will leave 16-235 range unchanged but not sure and for now can't check it. Of course you should listen to Wilbert ;)
Thanks for pointing it, I'll addres the issue with the range 16-235 when YUY2 support will be added.
It might be stupid question, but I am just curious, is this filter is interlaced aware, does not require those SeparateFields() Weave() type of things? It's your second ;) perfect question. It's best to do separatefields() and then weave() for interlaced. But also without it only in special cases some artefact can appear. Maybe it's good to add interlaced mode to filter, or do you prefer doing it yourself with separatefields() and weave() ?

Regards

[Backwoods]

Originally posted by paviko
@backwoods
I've looked closer to your frame grab and I'd like to have you camcorder :eek: It's perfectly keeping colour information in dark areas. Is it a professional camcorder? The best result with such a good devices can be obtained when max_sat parameter is set to 1.0. Otherwise colours can be boosted too much.

Ah yes, I didn't notice that max_sat was 2.0 by default. Putting it around 1.5/6 gives a nice result. And the camera I was using is a Sony HDR-FX1, nice camera.


It's your second ;) perfect question. It's best to do separatefields() and then weave() for interlaced. But also without it only in special cases some artefact can appear. Maybe it's good to add interlaced mode to filter, or do you prefer doing it yourself with separatefields() and weave() ?

I would just put a note in saying to use SeparateFields() and Weave() for interlaced people. Considering those people are going to be doing other effects also, which should be done inbetween S() and W(). Unless it's easy enough to code interlaced material handling.

[Wilbert]

It might be stupid question, but I am just curious, is this filter is interlaced aware, does not require those SeparateFields() Weave() type of things?
Nope, because the avi is opened as YUY2 (you only need it if source or target is YV12).
Oops :) I completely misunderstood your question.

[paviko]

New, small update to version 0.1.1.

1. New parameter "circle" allows to increase speed 4 times with some little quality loss. Default value is 7, but you can go as low as 3.
2. Fixed bug with avg_lum (thanks to AVIL)
3. C optimization (thanks to tsp)
4. Other new parameters: coef_gain and min_sat.

@Backwoods
I was using is a Sony HDR-FX1, nice camera.
You're lucky :)

Regards

[Bordo32]

@paviko, about the 0-255 range, my point is that even your DV codec uses 0-255 range, and assuming it opens avi in YUY2 range (not such Panasonic -RGB only type codec), ConvertToRGB expands YUY2 luma from 16-235 to RGB 0-255 values. In this scenario all details above 235 luma will be lost. This is the common miniDV cam problem, even Sony HDR-FX1 which has a "zebra" function. Using cams with no "zebra" (such Sony HC-85) complicates situation even more.
By using ConvertToRGB(matrix="PC.601") you convert YUY2 from 0-255 to RGB 0-255 range (not 16-235 to 0-255) preserving all overshoot values above 235. Now you retain the original full luma range. If HDR AGC filter could do all the work in 0-255 range and finally keep (reduce) RGB values to 16-235 range would be perfect solution.
My final target is DVDR, so my next step is frameserving *.avs to video editor (Vegas for example, which works correctly with full RGB range) editing and encoding to mpeg2.


I'll addres the issue with the range 16-235 when YUY2 support will be added.

I would say it is nothing to do with the YUY2 support, luma already might be out of 16-235 luma range, right from original YV12 color space avi file (assuming it is taken from miniDV cam.).
It would be perfect if you could address all full RGB range and interlaced material handling related issues.

Thanks.

[Backwoods]

Originally posted by paviko
1. New parameter "circle" allows to increase speed 4 times with some little quality loss. Default value is 7, but you can go as low as 3.

What type of quality loss? Loss of color/contrast/detail?

Of course I will test this new version all day tomorrow, great stuff.

[paviko]

@Bordo32
ConvertToRGB expands YUY2 luma from 16-235 to RGB 0-255 values. In this scenario all details above 235 luma will be lost If luma is only in range 16 to 235, then there is no information between 235 and 255 so expanding to 0-255 will only give more contrast (image doesn't look washed out). But maybe you mean that displaying it on TV will cause details loss? I can't find what's happening when encoding clip to MPEG2 :(

@Backwoods
What type of quality loss? Loss of color/contrast/detail?
It's a loss of contrast for small details - small details are less distinguish from background by decresing circle value (hmm it should rather be named radius by me, not circle ;) )

Version 0.1.2 alpha
I've found some low-light clips that behaves strangly. They have luma in range 0-80 and only gain to 0-150 with very plastic look. In new version I've changed lightness distribution routine to fix this problem. Now midtones also have higher contrast.
New value for auto control of saturation - coef_sat can be 0.0 which means that max_sat will be applied to pixels that get max_gain, other pixels get saturation respectivaly to their gain.
Calculated gain is independent of avg_lum parameter, so changing avg_lum won't change drastically gain for dark areas.

Link to HDR AGC 0.1.2 (http://www.klient.neostrada.pl/HDRAGC0.1.2.zip)

Regards

[guada 2]

I appreciate this beautiful work. :)
But a question challenges me.

The human eye is able to observe the chromatic apects of its environment. With this optimization would not be it not worrying to raise the question of this filter about zones of shades and dark of a realistic scene.

Nevertheless on the strategic level of defense (thorough war/investigations), this filter will be a considerable investment.

[trolltuning]

Can anyone do slightly better with this dark source?
http://members.atlantic.net/~andypo/go/compar~1.jpg
By the way this is a great plugin and maybe an unfair test.
(originally DV footage)
I tested this with the following script:

Avisource("D:\capture\Swdark.avi")
ConverttoRGB32()
#HDRAGC(avg_lum= 1000,max_gain =3.8, min_gain=2.8, coef_gain=1.0)
HDRAGC(max_gain =5.8, min_gain=4.8, coef_gain=2.5,max_sat=1.6)

and compared with the original:
vid1=Avisource("D:\capture\Swdark.avi")
vid2=Avisource("D:\avis\Hadrag1.avi")
vid2=vid2.converttoRGB32
stackhorizontal(vid1,vid2)
reduceby2()

[Mug Funky]

If luma is only in range 16 to 235, then there is no information between 235 and 255 so expanding to 0-255 will only give more contrast (image doesn't look washed out). But maybe you mean that displaying it on TV will cause details loss? I can't find what's happening when encoding clip to MPEG2

true in theory, but in practice a lot (i mean a LOT) of DV cameras will capture outside the 16-235 range - not so much in the black end, but certainly in the super-white end.

it would be nice to have this extra bit of detail, as it's often the difference between "hot" and "overexposed".

[edit]

FWIW, pinnacle's old DV25 codec will decode DV to rgb24 and keep the luminance how it was captured, at the cost of slow speed (it's old) and slight blurring (i don't know where that comes from, probably the rgb conversion).

[paviko]

@guada 2
The human eye is able to observe the chromatic apects of its environment. With this optimization would not be it not worrying to raise the question of this filter about zones of shades and dark of a realistic scene.
Can I read somewhere about "zones of shades and dark of realistic scene" or maybe you can explain it in more detail? Currently in plug-in saturation can be controled so some aspects of chromatic information is processed.

@trolltuning
Can anyone do slightly better with this dark source?
What would you like to improve?
If you want it to be more bright then simply use:
HDRAGC(max_gain = 12.0)
If it's too bright lower max_gain.
If you want to play with colours you need to white balance the scene (remove probably the yellow) and increase the max_sat value to the level you like:
HDRAGC(max_gain = 12.0, max_sat = 3.0, coef_sat = 0.0)
Probably with colours can't be done much - too dark scene for camcorder to keep them.

@Mug Funky
in practice a lot (i mean a LOT) of DV cameras will capture outside the 16-235 range - not so much in the black end, but certainly in the super-white end.
it would be nice to have this extra bit of detail, as it's often the difference between "hot" and "overexposed".

So how it would be the best to procces it. Doing ConvertToRGB(matrix="PC.601") will preserve those ranges as I assume and now allready HDR AGC will expand all information to 0-255 (so if it was allready beyond 235 in YUY2 then it won't be lost). Or maybe it should be better to keep everything in 16-235 range by HDR AGC even squeeze these additional information that was beyond range orginally?

Regards

[Bordo32]

@paviko,
Or maybe it should be better to keep everything in 16-235 range by HDR AGC even squeeze these additional information that was beyond range orginally?

This would be good approach.
Or HDR AGC my work in 0-255 RGB range and RGB values
might be reduced to 16-235 after all work is done.

[morsa]

I guess for such a dark scene, only way will be to have the colorization filter E-male is trying to develop :)

[Backwoods]

Originally posted by morsa
I guess for such a dark scene, only way will be to have the colorization filter E-male is trying to develop :)

which is that?

[videoFred]

Paviko,

*EDIT: I changed my opinion about the saturation, see my other posting below.*

I did many tests, this weekend.
It appears to me your first version is better...
The second one gives too much saturation.

But this is a problem with the first one, too.
There is too much saturation, and I can not reduce this with max_sat=1. Also, colors are a little unnatural.

However, this amazing filter still looks very promising to me.
I already can use it. I reduce saturation and adjust contrast a little afterwards.

On German broadcast, I saw a film and I am almost sure they used the same principles as you do (maybe in the camera?). Contrast was very equal, colors where very vivid. Awesome!

I sure hope you have time to develop it further!:thanks:
Together with Fizicks depan plugin, your plugin could be my favorite!
You are almost there, we just need some more fine-tuning.
Maybe you could make saturation more adjustable?

EDIT: But I was thinking... I'm not a colorspace-codec expert.
Could the saturation problem be caused by the Huffyuv codec I use?
I'm gonna do some more tests with the Panasonic DV codec.
Maybe it is not a saturation, but colorspace issue, right?

Any other people who are testing this filter?

Fred.

[paviko]

It appears to me your first version is better...
The second one gives too much saturation.

But this is a problem with the first one, too.
There is too much saturation, and I can not reduce this with max_sat=1. Also, colors are a little unnatural.
Strange that max_sat=1 brings more saturation, because with value 1 it turns off completely any saturation code. Maybe you mean brightness. In second version overall brightness was a bit higher for the same settings. The best ofcourse would be if you could post pre and post images. It will help also in tuning.

I sure hope you have time to develop it further! Not much time but I'll develop it further slowly. Now I'm thinking of completely diffrent algorithm of HDR which is matematically beautyfull ;) It needs a lot of time to implement, because I'll have to probably code myself partial differential poisson equation solver. Using available tools I've found, one frame will take 360 GB !!! of memory :eek

Maybe you could make saturation more adjustable?
Have you tried coef_sat setting to 0.0 and then playing with max_sat starting from 1.0 ?

I'm not a colorspace-codec expert.
Could the saturation problem be caused by the Huffyuv codec I use?
I have no idea about Huffyuv :confused: but rather it can't cause bad things I think.

Regards

[Fizick]

paviko,
Sorry, but i still did not try your plugin.
But do you take into acount the temporal variations?
Some time ago i made Deflicker plugin for brigthness and contrast temporal stabilizing.
What do you think about it? May be some combination is possible?

[videoFred]

Originally posted by paviko
Strange that max_sat=1 brings more saturation, because with value 1 it turns off completely any saturation code. Maybe you mean brightness. In second version overall brightness was a bit higher for the same settings. The best ofcourse would be if you could post pre and post images. It will help also in tuning.



Thank you for the answers!
I did more testing, your colors are OK! Also on version 2.
I can play with the sigma parameter also, I was forgatten to use this parameter :confused:
Now, together with max_gain, min_gain, avg_lum I can do miracles with this filter.

And no, it has nothing to do with the used codec or colorspace.
As soon as possible, I post some results.

Aaaahhh! I would like to run this filter on several hundred files in batch, without the need to do settings for each individual file!
Am I dreaming? Would this be possible? :confused:


Fred.

[E-Male]

Originally posted by Backwoods
which is that?
no public release, yet
i'm done porting Ming Yang's code, but i'm still working on interfaces

also i daubt this will help much here
AFAIK the algo needs 'good' luma to correctly spread the colors

[Backwoods]

Originally posted by videoFred
Aaaahhh! I would like to run this filter on several hundred files in batch, without the need to do settings for each individual file!
Am I dreaming? Would this be possible? :confused:

How are your files named? You can load them into AVISynth with ImageSource and then use ImageWriter if you wanted them as images again (or just export them as images from VirtualDub).

[videoFred]

Originally posted by Backwoods
How are your files named? You can load them into AVISynth with ImageSource and then use ImageWriter if you wanted them as images again (or just export them as images from VirtualDub).

No,no!

I mean AVI files, not stills.


Fred.

[videoFred]

Originally posted by Fizick
paviko,
Sorry, but i still did not try your plugin.
But do you take into acount the temporal variations?


Hi Fizick,

You realy should try it, because I understood you also are working with old 8mm film, right? Then you know how difficult it is to capture high contrast scenes. Almost always the whites are overexposed. Not on the original, but on the digital capturing.

The very best way to deal with this is double capturing: then you have a bright and a dark clip of the same scene. With overlay() and a mask, I put them together again, and then I realy see everything that is on the film. But this all takes a lot of time.

Another method is: if you expose on the highlights while capturing, you end up with a very dark picture, but with correct highlights. But there is still much information in the dark parts, and this filter makes this visible. Yes, as far as I can see, it deals also very well with temporal variations.

Btw: Your 15/25fps script works very well! It gives very smooth pannig! Awesome to see how it realigns every frame. I use it all the time for panning scenes.:cool:

Fred.

[Backwoods]

Originally posted by videoFred
No,no!

I mean AVI files, not stills.


Fred.

You can either use SegmentedAVISource (which I'm sure you know of already), if not, there is a Java based program that would create a script for every AVI in a DIR. Where do you find it? I forget, it was posted ages ago.

[videoFred]

Originally posted by Backwoods
You can either use SegmentedAVISource (which I'm sure you know of already), if not, there is a Java based program that would create a script for every AVI in a DIR. Where do you find it? I forget, it was posted ages ago.

Hello Backwoods again!

Thank you for your suggestions, but I must make myself more clear.
Here we go: as you know, I transfer old 8mm films. I use a 1024x768 machine vision camera for this, and capture with Huffyuv. Framerate of these files is 15fps. But even a short 3min. reel of 8mm film contains several, very different scenes. Thus I capture these scenes as seperate AVI's, max.1000 frames.

With the HDR filter, each scene needs other filter settings, it makes no sence if I edit them in batch with the same filter settings.

More specific, the avg_lum setting is the most important for me. Sometimes I need avg_lum=20, sometimes avg_lum=120. The other settings could remain the same.

Would it be possible to analise the luma of a specific scene, store this into a variable, and then correct avg_lum according to this variable? For the entire scene, not frame-by-frame, because then I could create flickering, right?

Fred.

[videoFred]

OK,

Time to show you an example:

http://users.telenet.be/ho-slotcars/testmap/videoFred_steam3_divX.avi

This 1976 Super-8 scene was original captured frame-by-frame with my modified projector. No hotspot, no flickering with this system. Then, I stabilised it with Fizicks depan plugin. Then, I converted framerate 15/25 using Fizicks script, again with the depan plugin. Watch the borders, you see how depan works. Then, I used Paviko's HDR filter to bring up more details and to improve colors. At home, I have more spectacular examples of the HDR filter, but this one gives you already a good idea.

Please remember 8mm filmframes are in fact just tiny 6x4mm pictures! Regular 8mm film was the 'mother' of all home filmsystems. Then, in 1965, Kodak launched Super-8 and Fuji Single-8 (the best).

Fred.

[tsp]

videoFred: the below script will calculate the average Luma for a clip and output it to a file. You can use this value as a reference for the setting (load it using conditionalread maybe)

sourcefile="c:\src"
s=AVISource(sourcefile+".avi").converttoyv12()
global fc=Framecount(s)-1
global avgl=0
s.frameevaluate("avgl=avgl+AverageLuma()")
last.writefileif(sourcefile + ".txt","current_frame==fc","avgl/(fc+1)")

[videoFred]

Originally posted by tsp
videoFred: the below script will calculate the average Luma for a clip and output it to a file. You can use this value as a reference for the setting (load it using conditionalread maybe)


Thank you... But I don't have expierence with scripts like this. Is this some kind of autodetection of AVI-files at line 2? Or do I have to specify my AVI file, like in common scripts? If so, where?

Fred.:confused:

[tsp]

no it you will have to specify it at line one just without the .avi extension.
The part sourcefile+".avi" just means take the variable sourcefile (in this case c:\src) and add .avi to the end. (so "c:\src"+".avi" = "c:\src.avi"
it's mainly done like this so the textfile that contains the average luma has the same name as the avifile (sourcefile + ".txt" = "c:\src" + ".txt" = "c:\src.txt")

[videoFred]

Originally posted by tsp
no it you will have to specify it at line one just without the .avi extension.


I understand now, Yes it works fine! But to have the average luma in the textfile, I must let the entire clip run in VDmod. How can we automize this?

Also, now I know the average luma of the clip,I must have a value to compare with.. Maybe 255? I mean, if I have a very dark clip with an average luma of 54, then 255-54= 201 then this is the avg_lum compensation for the HDR filter, right?

EDIT: it appears to me the average value of TSP's script IS the ideal avg_lum value for the HDR filter.. I tested it with several clips, but I am not 100% sure..must do more tests.

Fred.

[tsp]

Originally posted by videoFred
I understand now, Yes it works fine! But to have the average luma in the textfile, I must let the entire clip run in VDmod. How can we automize this?

Also, now I know the average luma of the clip,I must have a value to compare with.. Maybe 255? I mean, if I have a very dark clip with an average luma of 54, then 255-54= 201 then this is the avg_lum compensation for the HDR filter, right?

EDIT: it appears to me the average value of TSP's script IS the ideal avg_lum value for the HDR filter.. I tested it with several clips, but I am not 100% sure..must do more tests.

Fred.

you can do it in 2 passes with these two avs script:
pass1.avs

sourcefile="c:\src"
s=AVISource(sourcefile+".avi").converttoyv12().assumefps(200)
global fc=Framecount(s)-1
global avgl=0
s.frameevaluate("avgl=avgl+AverageLuma()")
last.writefileif(sourcefile + "_avgluma.avs","current_frame==fc",""" "AvgLuma=" ""","Round(avgl/(fc+1))")

pass2.avs

sourcefile="c:\src"
s=AVISource(sourcefile+".avi").converttorgb32()
import(sourcefile+"_avgluma.avs")
s.HDRAGC(avg_lum=AvgLuma)


finaly create a virtualdub script with extension .vcf
with this content

VirtualDub.Open("pass1.avs",0,0);
VirtualDub.Preview();
VirtualDub.Close();
VirtualDub.Open("pass2.avs",0,0);
//#VirtualDub.SetCompression() you will have to figure out the options for SetCompression
VirtualDub.SaveAVI("final.avi");
VirtualDub.Close();

start virtualdubmod chose run script... from the file menu and select the above script. That's it.
If you want to encode more files just change the avs filename to pass1_1 pass1_2 etc and repeat the virtualdub script. I don't know much about the virtualdub script language so please ask another

[Backwoods]

Originally posted by videoFred
Hello Backwoods again!

Thank you for your suggestions, but I must make myself more clear.


Ha, well that is what started this whole mess.

Originally posted by videoFred
Please remember 8mm filmframes are in fact just tiny 6x4mm pictures! Regular 8mm film was the 'mother' of all home filmsystems. Then, in 1965, Kodak launched Super-8 and Fuji Single-8 (the best).

I'm well aware, we talked through PM before and I do plenty of transfers myself.

Let us know how tsp's method works out for you. Sounds like it should be what you're looking for.

[videoFred]

Backwoods, it works fine! You must try it, too!

@TSP:thanks:
------------

It works even better, if I use the avgluma parameter to set the sigma of the HDRAGC filter also, and if I increase the avgluma with factor 1.2.

Loadplugin("HDRAGC.dll")
sourcefile="d:\analyse\11"
import(sourcefile+"_avgluma.avs")
s=AVISource(sourcefile+".avi").converttorgb32().bicubicresize(500,380)
luma2=round(avgluma*1.2)
sigm=(1.2+(avgluma/100))
clip1=s.HDRAGC(avg_lum=Luma2,min_gain=5,max_gain=15,sigma=sigm,max_sat=1,circle=3)

clip2=converttoYUY2(s)
clip3=converttoYUY2(clip1)
clip4=colorYUV(clip3,autowhite=true)

stackhorizontal(clip2,clip4)

Yes, I know color is too blue on this example, but it has been recoded several times etc.

http://users.telenet.be/ho-slotcars/testmap/02_besken.jpg

[paviko]

@Fizick
But do you take into acount the temporal variations?
Some time ago i made Deflicker plugin for brigthness and contrast temporal stabilizing.
What do you think about it? May be some combination is possible?
This plugin alone doesn't cause brightness flickering. There is one parameter avg_window that is using temporal averaging, but it's not meant to remove flickering that is in video from start. When it's set to 1 (as default, so no averaging) it can possibly even slightly reduce flickering if it's present.
Your Deflicker plugin is working very well. Hmm, probably it not difficult to include your code, so combination is possible :)

@videoFred
Aaaahhh! I would like to run this filter on several hundred files in batch, without the need to do settings for each individual file!
Am I dreaming? Would this be possible?
If the content of the clips differs a lot (I mean if it's captured with diffrent devices) then probably it's not possible. By automatic is set only gain and it's based on avg_lum parameter. For my camcorder I've got only one setting for every light situation.
But we can try, post examples when you need to change a lot parameters (before and after processing, so I can know what you would like to achive).
Sometimes I need avg_lum=20, sometimes avg_lum=120. The other settings could remain the same. By lowering avg_lum you influence gain calculation and force to not change bright areas, maybe better would be using coef_gain parameter (lower it instead lowering avg_lum)
Would it be possible to analise the luma of a specific scene, store this into a variable, and then correct avg_lum according to this variable?
Instead doing it by hand (these analises) it would be better to implement it to the plugin. Examples please ;), so maybe some pattern can be discovered.
Maybe 255? I mean, if I have a very dark clip with an average luma of 54, then 255-54= 201 then this is the avg_lum compensation for the HDR filter, right?
Default value for avg_lum is 128. It has been choosen because when you look for clips taken in prefect light condition the average luminance is around 128. HDRAGC is trying to increase average brightness of the clip to match avg_lum parameter. Corectness to these parameter should be mostly small in the range of 100-150. These are my observation. But maybe your device is completely different.

Regards