On Sunday 08 March 2009 11:50:22 Stefan Krastanov wrote: > I believe I got it now. And yes - my first idea is senseless. But still I > don't understand that correction - it's like if there is older correction > done, you are changing the formula to (min_stable_yavg / current_yavg)^2 = > min_stable_exposure / current > exposure. Why the square? And why are you aiming at min_stable_yavg or > max_stable_yavg instead at the value exactly in between.
It is not square, current_yavg is not constant. Here's quick example what koef means: 1. yavg = 10, min_yavg = 10, min_stable_yavg = 20, koef = 1, exposure = 5. Algo will change exposure value to 10, to get yavg == 20 (We're trying to get values not on edges because we want to get yavg into stable region, not on edge of stable region) 2. Last time we performed exposure increasing, but yavg == 40 instead of 20, and max_yavg = 35, so we're out of region because we made too large step. In _this_ case algo will re-calculate koef. It's actually your "b" constant :) Btw, maybe there's error somewhere in calculations, I'll check later. > And I see one int i, that I think is not used anywhere, but that's not > important. > > I propose to take exposure=a+b*yavg. The only difference is that "a" there. > But "a" will probably be near zero (zero luminosity - zero exposure) so > maybe a better Idea is exposure=a+b*yavg+c*yavg^2. I will try both of them > but I would like to know what are those a,b,c calculated so if I use > UDIA_INFO will I get few of them on dmesg (I'm just copying from the switch > few lines up.) or will I crash something. Talk is cheap. Show me the code (c) Linus Torvalds :) Btw, don't forget about calibration - you should calculate your "a" and "b" values dynamically, because yavg(exposure) dependency is different on different sensors. With UDIA_INFO of course you'll get what you want printed on dmesg > Regards > Stefan Krastanov Regards Vasily
signature.asc
Description: This is a digitally signed message part.
