Timelapse with variable shutter speed

fbonomi

fpfalangie, maybe I have found a workaorund to your bug...

In the script you used, insert a "SLEEP 100" between set_sv96 and set_tv96_direct, i.e change

sleep 100
set_sv96 Y
set_tv96_direct X
sleep 100

into

sleep 100
set_sv96 Y
sleep 100
set_tv96_direct X
sleep 100

Jucifer

I'll add this to my build, if you have nothing against it. I'd like to do a couple of changes, though: change the command name to get_exp_info (or get_histo_info or get_histo_range) and use the [x=]get_... syntax

fbonomi

Jucifer, I DON'T KNOW!

It's not yet ready for a "delivery" build, but most of all it is quite obtrusive to the standard working of the camera:
1) building the histogram takes quite some time, and slows the camera after shooting
2) saving the histogram data files clutters the folder

Even myself, I am using two cards: a standard one with this feature (just for night-time lapses) and a normal one for all the rest.

So at least you should add an option in the menus to enable/disable this feature. You are probably better than me at this, I have never studied the menu and configuration system.

I would also like to activate the "spot metering feature", but that's really secondary (minor feature that can be added later)

fbonomi

and you are absolutely right about the function name, it should be something like get_histo_range().
The other names were a leftover from test I was doing..

fbonomi

Thinking about it, what I said:

So at least you should add an option in the menus to enable/disable this feature. You are probably better than me at this, I have never studied the menu and configuration system.

is silly. It's much better to have an uBasic command that enables/disalbes this feature.

I will implement it and pass it to you.

Otherwise, where are the sources to your build?

I can integrate it there and pass you the diff

Aged

This suggestion for smoothing is a modification of the BoxCar average (moving average) technique.

Boxcar (American locomotive ?)- Idea, obtain total weight of N carriages then add the weight of the N+1 and subtract the weight of the first. -> add N+2 subtract 2, etc This average smooths both increasing and decreasing carriage weights.

Suggested modification
Subtract the average instead of the first one. This saves remembering each value

Application (larger N gives more smoothing. Say N=4)
initialize Let sum of 4 get_tv values = T
Use
Ave = T/4 (strictly T1/4 and ignore remainder)
T2 = T1 + get_tv - Ave, where T1 is the existing T value and T2 will be its replacement.

fbonomi

Aged, I didn't know this tweak, it might be interesting because of the smoothing it introduces and of its simplicity (coding a FIFO buffer without arrays is .... yuk!)

Aged

fbonomi
SMA - Simple Moving Average
Ref: [url]http://en.wikipedia.org/wiki/Moving_average[/url]
Often used for smoothing stock market trends.

fbonomi

Yes, that I know 😀

All those are implementatinos that require a FIFO buffer, and in effects what I implemented is a almost-exponential movign average.

The tweak I have not experimented is subtracting the average instead of subtracting the "exiting" element.

There are some problems, anyway:
1) I think it introduces a "drifting" effect
2) It makes weighing impossible

Jucifer

fbonomi
It's much better to have an uBasic command that enables/disalbes this feature.

How about this:

core/raw.c, raw_savefile():
if (state_kbd_script_run && shot_histogram_enabled) build_shot_histogram;
(or something similar)

core/kbd.c, script_start():
shot_histogram_enabled = 0;

and of course a uBASIC command to set shot_histogram_enabled.

(Already working on these...)

Otherwise, where are the sources to your build?

Now I've been asked this twice in two days. :]
Only patches, "official" ones attached to the first post on my thread.

fbonomi

So you are not distributing the source?
That makes it impossible for me to use your build, I keep fiddling with the C source...

Now I've been asked this twice in two days. :]

Maybe that's a hint 😀

I have nothing personal with that but you are going against GPL: if you distribute the compiled form, you have to distribute the source code too.

whim

....
but you are going against GPL: if you distribute the compiled form, you have to distribute the source code too

Beg to differ on that: base source code (in trunk) + Juci diffs = his source code -> full GPL compliance
IMHO the only thing one can complain about is the size of the diff, which makes it quite a bit of work to
apply manually 😁

wim

wontolla

@fbonomi

Jucifer's patch is actually the code. It's a text file (.diff extension) formatted to show only the differences between his code and the trunk. That way a developer doesn't need to upload ALL the code and is easier for you to integrate someone else's work with your own.

You can use TortoiseSVN to apply Jucifer's patch automatically. Although some changes have to be made by a human.

Jucifer

And better check those files not yet in the trunk when merging...

I can distribute also the source zipped. What files does it really need? *.c *.h *.S *.inc *.sh *.txt *.ld ?akefile (using 7-zip to archive, don't want to include all the crap...)

whim

Yay, that would be cool Juci 😁 Since most of the diff is taken up by the lua stuff, and all these new files need lots of
'+' removed. Don't sweat it though, programmers should program, not do admin/housekeeping 🤣

keep up the good work,

wim

fbonomi

I apologize, I didn't see the link to the diff, just the links to the posts on the board.
Sorry for that, jucifer!

Jucifer

...so there's this in core/raw.c, raw_savefile():
if (state_kbd_script_run && shot_histogram_enabled) build_shot_histogram();

shot_histogram_enabled is set with scripting command shot_histo_update (was initially shot_histo_enable, but the last shot histogram is available anyhow, so... Any ideas how to name it? Or other ideas?)

Have to do a bit testing & cleaning up before publishing anything. Maybe tomorrow evening. First some sleep, then some work. Then more CHDK. :]

Me a programmer? Nah. :] (I really can't code anything "new"... :I)

fbonomi

Jucifer
but the last shot histogram is available anyhow

??
I can't understand.. What do you mean?
The last histogram is not available... The RAW data is there, but the histogram hasn't been built, as it is built (if enabled) just after the shot.

So, if you do

shot_histo_update
get_histo_range 100 800 a

you wont'get data

You have to do

shot_histo_update
shoot
get_histo_range 100 800 a

But maybe I mis-understood you!

Jucifer

if you first do

shoot
a=get_histo_range 100 800

a will be 0
then

shot_histo_update 1
shoot
a=get_histo_range 100 800

a is "something", let's call it 14
then

shot_histo_update 0
shoot
a=get_histo_range 100 800

and a is still 14
(data in shot_histogram[] is changed only, when shooting from a script and shot_histo_update 1 was used before shooting)
if shot histogram (updating) isn't enabled, is emptying shot_histogram[] necessary? it'll just take time... (only a bit, but still)

P.S.
(note to self)

I'll change the scripting command back to shot_histo_enable.
If it's not set, get_histo_range returns -1.
I think this could make sense.

fbonomi

This is the first (decent) result of a night-long time-lapse, including sunset and dawn.

2020 shots, from 19:30 to 06:45, with exposures ranging from 1/2000", 160 ISO to 20", 1500 ISO.

Here is the video: Night-long time-lapse 1

Better in MPEG1 format (abt 20MB): Night-long time-lapse 1

and below is the graph of the movie:

There are evident problems:
- flickers in brightness around frames 650 and 1350 (we are at the very end of the sensors' reliability) and 1200 (moving averages method is not good for this sort of smoothing)
- around frame 700, the exposure is kept constant for a while. (In the movie, you get a short period of pitch black sky). In that moment the "over-exposure protection" was somehow triggered. I have to study exactly why.

In the graph you can see a strong change of luminositiy starting at frame 900. You can't see it in the movie, but the moon rises and lightens up the clouds. The camera therefore correctly starts decreasing exposure to compensate..

Around second 13, there is a spooky figure in the frame: it's a bird that was probably curious about my shiny blinking camera..

Overall, an interesting result and I am quite satisfied.

« Previous Page Next Page »