Timelapse with variable shutter speed

[fbonomi]

EDIT: this thread has information about the development of the script, and different tests I made.

If you just want the script and its instructions, please go here

You might be interesed in the new version of the script: Night-time time-lapse

This is a timelapse of the moon setting, made with a shutter speed of 50 secs and continuous mode.

Moonset

This time-lapse has a fixed shutter speed: just after the moon has set, the dawn breaks and after a few seconds everything is naturally over-exposed.

To solve these kind of problems, I was thinking to try to implement some "adaptative manual mode": you start with a shutter of X, but the camera reacts to changes in light changing shutter speed accordingly.

That must be quite different form a manual mode, of course: it must change the shutter speed gradually (max x% from previous shot) and slowly (it must ignore sudden spikes of light).

My plan:
1) add a ubasic command to get histogram values
2) do a Ubasic script that reads those vaues and changes shutter accordingly

At the moment I have implemented the ubasic get_histo_value command:
get_histo_value h i v
    h=which histogram you want to read (0-4, selecting R, G, B, RGB or Y histogram)
    i=which position of the histogram you want to read (0-127)
    v=variable where the result is placed

Then, I have done a few concept test with ubasic reacting to light changes. It somehow works, but the road is still very long :-)
(and doing an ubasic script that properly exposes the pic is by no means easy!!)

So I would like to ask if someone here sees a simpler, therefore better, way to achieve similar results, i.e. making timelapses in situation where light changes are huge

On a strongly related point... When in manual mode you press half-shoot, the camera tells you if you  are over- or under- exposing (the number that quicly appears saying for example "-2" if you are 2 steps too dark)

How is that function called?

Does anyone know if that number is readable in the properties?

This feature would give a much easier approach than mine :-)

[mx3]

NOTE:
there seems to be a problem with histogram data.
they are to be displayed on LCD.
it seems camera makes pixels level adjustments so these data do not represent real picture from sensor.

Auto-Exposure Method for Night-time Photography

[Jucifer]

Would using get_bv96, get_sv96 etc. be out of the question? (if auto-exposure is accurate, get_bv96 + get_sv96 = get_av96 + get_tv96)

Code:

press "shoot_half"
sleep 1000
get_bv96 B
get_sv96 S
get_av96 A
get_tv96 T
print B+S
print A+T
sleep 1000
release "shoot_half"

[fbonomi]

NOTE:
there seems to be a problem with histogram data.
they are to be displayed on LCD.
it seems camera makes pixels level adjustments so these data do not represent real picture from sensor.

Are you saying that framebuffer data itself are not reliable ?
Even during half_shoot ?

Auto-Exposure Method for Night-time Photography

thanks for the pointer. The md_get_cell_diff statement can be really useful.

can you please confirm if I understand correctly:

1) md_get_cell_diff is called after a detection
2) if no detection was made (i.e. we had a timeout) calling "md_get_cell_diff 1, 1, a" will put in a the average luminosity of the framebuffer

is it correct?

thanks!

[fbonomi]

Would using get_bv96, get_sv96 etc. be out of the question? (if auto-exposure is accurate, get_bv96 + get_sv96 = get_av96 + get_tv96)

Mmmh, will have to investigate that too.
Thanks

[mx3]

Are you saying that framebuffer data itself are not reliable ?
Even during half_shoot ?

I'm not sure. I'm not expert in this.
I'm not a mature photographer also :-)

lets do experiment.
move camera from bright area into dark.
what do you see?
LCD shows dark picture atfirst then after a moment it begin to brighten
actually I don't know how it is achieved - either by software processing or hardware adjustments.

I just checked this behavior  in manual mode with fixed aperture and ISO.
I clearly see some changes on LCD.

can it be done by hardware?

I'm not sure why half_shoot would change something.

IMHO: something (software processing) is done with framebuffer before displaying on LCD.
I would be glad if I'm wrong

can you please confirm if I understand correctly:

1) md_get_cell_diff is called after a detection
2) if no detection was made (i.e. we had a timeout) calling "md_get_cell_diff 1, 1, a" will put in a the average luminosity of the framebuffer
is it correct?

correct
just set threshold to big value(255?) - this way you will get absolute value of luminosity

[Barney Fife]

Deleted

[fbonomi]

Yes, could a mod please move this thread to the "script writing" section?

[fbonomi]

First tests and results.

The result is not too bad, you can see it here:
Sunset test 3

Quite short sequence (from 20:30 to 21:19) with exposures ranging from Tv -128 to -576 (2.5" to 60")

Algorithm is:
- Tv_step is 16 (minimum size of Tv change)
- start with current Tv
- Camera measures exposition
- Delta = current Tv-ideal Tv
- if Delta > Tv_step then we should change Tv
- BUT there is resistance to Tv change: wait for 5 consecutive signficant Deltas before actually increasing Tv.
- after this, keep increasing one Tv step per frame until Delta says so

(script below)

There are obvious problems in the result, but the overall effect is promising.

Problem 1: Lens flare. My fault, but I had to leave the camera unattended, I was afraid it would rain, so I had to leave it just under the lamp!

Problem 2: "bumps" in luminosity. In certain frames, it seems the exposure goes down and then up again. Believe me, it is not so!
This is caused by steps (actually aliasing) in the change of luminosity, due to the rough slowdown mechanism and to hi Tv_step.

See below for graph of Tv versus frames, where the problem is evident

I need to set up a better Tv-changing mechanism, probably with a second-order delta (derivative) so that the changes are slowed (to avoid reaction to sudden and insignificant "bumps" in luminosity) and at the same time smoothed (start slowly) but reactive (capable of changing fast when needed)

[fbonomi]

On the positive side, I quite like the change from "light sky with dark building" to "light building with dark sky".

The light was always on, but the change in exposition makes it look like a "fade" in.

When the problems are fixed, such an effect should be really nice on a town, where you would see the lights turn on and slowly gain luminosity. Also, the cars' trails woudl increase in brightness AND length...

This is the script (VERY rough, not for production :-)

Code:

@title Adaptative Manual
rem fbonomi 22/04/2008 v. 0.5

print_screen 1

print "Adaptative Manual"

rem picture counter
p=1

rem Tv_step: step of change
s=16

rem slowdown factor (how many consecutive deltas with same sign before actually changing Tv?)
d=4

rem q will count up to (or down to) d
q=0

rem start Tv
get_tv96 T

sleep 3000
:loop
set_tv96_direct T
print "###SHOOT", p, T
shoot
p=p+1
gosub "measure"
sleep 1000

rem D has delta from correct settings
rem if abs(D)<s then exposure is about ok
rem otherwise change exposure
if D<-s then goto "longer"
if D>s then goto "shorter"

print "Exposure Ok", T
q=0
goto "loop"

:longer
rem change to a longer shutter speed
 print "Should increase ", q
 
 rem check if slowdown factor is ok
 if q<0 then q=0
 q=q+1
 if q<d then goto "loop"
 
 rem check for legal range
 if T<-576 then goto "loop"

 T = T-s
 print "Increased to ",T
 set_tv96_direct T
 
 rem q=0
goto "loop"

:shorter
rem change to a shorter shutter speed
 print "Should decrease ", q
 
 rem check if slowdown factor is ok
 if q>0 then q=0
 q=q-1
 if q>(-d) then goto "loop"
 
 rem check for legal range
 if T>1200 then goto "loop"
 
 T=T+s
 print "Decreased to ",T
 set_tv96_direct T
 
 rem q=0
goto "loop"


:measure
rem measure delta from current settings and optima exposure
rem returns result in D
rem uses B S A T
rem press "shoot_half"
sleep 500
get_bv96 B
get_sv96 S
get_av96 A
set_tv96_direct T
rem print B,S,B+S
rem print A,T,A+T
D = B+S-A-T
rem print "delta: ",D
rem release "shoot_half"
return

The measuring routine comes from the idea of Jucifer above, with two differences:
1) press "shoot_half" was removed because probably un-necessary
2) get_tv96 T was also removed because it proved unreliable.
There are quite a few bugs/unreliabilites  in set_tv96_direct -> get_tv96. Maybe it's just my fault, and I haven't understood how to use it!

I resorted to measuring get_tv96 only once(at the beginning of run) and then always relying on my T variable, holding the Tv that I wanted to be set.

Variable q is increased/decreased when a sgnificant delta is found, but actual Tv changes take place only after abs(q)>=4

Now working on smoother changing mechanism and measurment logging mechanism, so that once I collect the measurements for a sunset I can emulate the sequence again without waiting for the next sunset :-)

[wontolla]

I can't watch the timelapse!

the playing bar moves for a fiew seconds but the screen remains black.

Is it me? I have flash player installed 

[fbonomi]

you are not missing a lot :-)
I will now check better.

[fbonomi]

Try here:
http://francescobonomi.it/video/test3_lo.mpg  (551k)
http://francescobonomi.it/video/test3_hi.mpg (1.7M)

[wontolla]

Darn!, both show the QuickTime icon with an interrogation symbol.

Don't worry fbonomi, I bet it's my computer. I just reinstaled it. Let's see if someone else can play it.

Judging by the graphic your scipt seems to work. I'll try it next time the friking weather gives a truce.

[fbonomi]

I have changed the encoding...
Can you please try again?