Night-time time-lapse

PhyrePhoX

2254
make RAW not WAR

Re: Night-time time-lapse

« Reply #20 on: 22 / August / 2008, 03:34:24 »

Advertisements

suggestion: add another option in the script: zoom paramater ?

Logged

Flickr*
www.PhyreWorX.de
CHDK News @ Twitter

fbonomi

469
A570IS SD1100/Ixus80

Re: Night-time time-lapse

« Reply #21 on: 22 / August / 2008, 05:55:27 »

Fudgey: VERY odd behaviour!

1) starting over/under exposed
Actually, that's expected: the script does not calculate an ablosute exposure, but rather adjusts from last shot.

It starts with an exposure of 1 second, then adjusts to correct exposure. This should usually happen within 7-8 frames.

I guess an easy change would be to measure the first shot to an absolute exposure (at least in the day I get a reliable reading), so the initial "fade from white/black" could be eliminated.

2) Zoom
I have never tried zoomed timelapses.
I thought the zooming position of the lens wasn't precise enough to achieve a constant factor of zoom.

3) Focus
In the test I did yesterday, with a power adaptor and display on, focus is fine all the time (from 23:20 to 07:29, 740 shots).
see it here: night time test 16

So I don't know whay yours shouldn't be properly focused: at first, I doubted if inserting the AV cable would disable MF but a quick check says it doesn't. Could it be the zoom?

4) sporadic dark frames
Did you have the same problem with the previous (uBasic) version of the script?
Other people had, and the problem was solved by placing some short delays before and after set_sv and set_tv96_direct. There is some bug in CHDK that sometimes make those commands fail, but a pause helps...
You could check the EXIF of the underexposed frames, to see what is wrong, (ISO or shutter)...
Usually the underexposed frames have all the same exposure (or ISO), namely the exposure (or ISO) that was manually set in the camera when you started the script
I would suggest increasing the sleep() values before and after set_sv96 and set_tv_96_direct...

4) Crash
As with the same 491 build your camera crashed and mine didn't, I think there must be some problem in the memory management in your camera (a slight problem in porting the firmware that causes a memory leak???).
These kind of problem are a real hassle, because it could mean you can't have ANY script running for very long time (I mean hours and maybe days)

I will be away for a few days, then I will try to compile in Lua a memory monitor to see where we are losing memory.

« Last Edit: 22 / August / 2008, 06:33:50 by fbonomi »

Logged

fudgey

1705
a570is

Re: Night-time time-lapse

« Reply #22 on: 22 / August / 2008, 07:11:09 »

Quote from: fbonomi on 22 / August / 2008, 05:55:27

2) Zoom
I have never tried zoomed timelapses.
I thought the zooming position of the lens wasn't precise enough to achieve a constant factor of zoom.

Hm? Why would zoom precision matter if I start the camera, zoom in a bit, start the script, end the script hours later, shut down the camera and go home? It doesn't travel when zoom is not being adjusted, does it?

Quote from: fbonomi on 22 / August / 2008, 05:55:27

4) sporadic dark frames
Did you have the same problem with the previous (uBasic) version of the script?
Other people had, and the problem was solved by placing some short delays before and after set_sv and set_tv96_direct. There is some bug in CHDK that sometimes make those commands fail, but a pause helps...
You could check the EXIF of the underexposed frames, to see what is wrong, (ISO or shutter)...
Usually the underexposed frames have all the same exposure (or ISO), namely the exposure (or ISO) that was manually set in the camera when you started the script
I would suggest increasing the sleep() values before and after set_sv96 and set_tv_96_direct...

I never tried the ubasic version, I think. But yes, these dark frames fell back to ISO 100 from ISO800 as you describe.
And it's probably not a bug in CHDK... those are sort of low level commands and we can't expect that the camera allows us to successfully change everything at every instant in time... in any case I only use propcases to change those parameters in my scripts because I don't have a clear grasp on what each of the functions do. I did a bunch of tests with propcases but never got around to studying the script commands using them.

I'll have to try to add some delays.

Quote from: fbonomi on 22 / August / 2008, 05:55:27

4) Crash
As with the same 491 build your camera crashed and mine didn't, I think there must be some problem in the memory management in your camera (a slight problem in porting the firmware that causes a memory leak???).
These kind of problem are a real hassle, because it could mean you can't have ANY script running for very long time (I mean hours and maybe days)

On my trunk build I've run a timelapse for about 6 hours without problems once and motion detector for about 3 to 4 hours many many times without crashing.

Not longer than that since I haven't tried external PSUs yet.

Logged

fbonomi

469
A570IS SD1100/Ixus80

Re: Night-time time-lapse

« Reply #23 on: 22 / August / 2008, 08:23:49 »

Quote

It doesn't travel when zoom is not being adjusted, does it?

It's probably completely unrelated, but a while ago I noticed that half-pressing while zoomed produces a little zom-like movement (the image enlarges and reduces a bit). I guess the focusing mechanism enalrges the image a bit.

Doing the same wothout zooming does not produce the same effect.

So, without doing any other test I supposed that the exact magnification generated by a specific zoom step was subject to slight variations...

But again, it was just an idea I didn't investigate any more.

Quote

in any case I only use propcases to change those parameters in my scripts

mmhh.. that's na idea I have never tried...

Quote

On my trunk build I've run a timelapse for about 6 hours without problems once and motion detector for about 3 to 4 hours many many times without crashing.

All in uBasic or something in Lua too?

Logged

fudgey

1705
a570is

Re: Night-time time-lapse

« Reply #24 on: 23 / August / 2008, 04:28:33 »

Quote from: fbonomi on 22 / August / 2008, 08:23:49

It's probably completely unrelated, but a while ago I noticed that half-pressing while zoomed produces a little zom-like movement (the image enlarges and reduces a bit). I guess the focusing mechanism enalrges the image a bit.

Doing the same wothout zooming does not produce the same effect.

So, without doing any other test I supposed that the exact magnification generated by a specific zoom step was subject to slight variations...

Someone who knows about camera optics would know better, but from the sounds and live view image of my camera I'd guess that the focus mechanism travels more when zoomed in (my camera clearly focuses faster at wide angle, the motor sounds back and forth are a lot shorter). Zoom probably magnifies this movement further. At zoom 1.1x I can already sometimes see this zoom-back-and-forth-while-focusing effect when pointing the camera to a straight outline of a door and aligning it with aa grid line. At full 4x zoom it's clear on any scene that has any sort of shapes.

But when doing a timelapse in manual focus, the camera won't focus (unless maybe if that fine-tune-the-MF feature of Canon is enabled? Didn't try.), so this is not a problem.... unless the camera has trouble staying in MF mode when zoomed in an running the script with a video plug attached.

Quote from: fbonomi on 22 / August / 2008, 08:23:49

All in uBasic or something in Lua too?

Just uBASIC, there's no Lua in trunk

Logged

fudgey

1705
a570is

Re: Night-time time-lapse

« Reply #25 on: 26 / August / 2008, 17:04:18 »

I increased the delays as suggested (code snippet below). The script ran without a glitch for about 490 frames (3 hours) while it got dark outside until the batteries drained. I didn't zoom in this time, I didn't plug anything in the video jack and I used manual focus without CHDK overrides.

Code: [Select]

  sleep(300)
  -- change ISO
  set_sv96(shoot_sv)
  sleep(300)
  -- change exposure 
  set_tv96_direct(shoot_tv)
  sleep(300)

Logged

vostok

31

Re: Night-time time-lapse

« Reply #26 on: 28 / August / 2008, 04:20:46 »

Quote from: fudgey on 23 / August / 2008, 04:28:33

Someone who knows about camera optics would know better, but from the sounds and live view image of my camera I'd guess that the focus mechanism travels more when zoomed in (my camera clearly focuses faster at wide angle, the motor sounds back and forth are a lot shorter). Zoom probably magnifies this movement further. At zoom 1.1x I can already sometimes see this zoom-back-and-forth-while-focusing effect when pointing the camera to a straight outline of a door and aligning it with aa grid line. At full 4x zoom it's clear on any scene that has any sort of shapes.

I don't know if this is relative at all, but maybe you're seeing the lens focal length changing just because of focusing. SLR optics for instance are marketed with a focal length that applies when the lens is focused to infinity, and even that might not always be that accurate.

Especially on some internal focus lenses (ie. the physical length of the lens does not change when focusing) the focal length changes quite much when changing the focusing distance. Point and shoot optics also have internal focusing.

This may or may not explain your observations.

Logged

fudgey

1705
a570is

Re: Night-time time-lapse

« Reply #27 on: 10 / September / 2008, 14:08:21 »

Tried the script again, now it stopped to not enough memory at frame 157 about 40 minutes from the start. Zoom 1x, manual focus, manual wb. So those settings don't seem to have an effect on the crash.

Logged

reyalp

14000

Re: Night-time time-lapse

« Reply #28 on: 20 / September / 2008, 01:46:24 »

collectgarbage("count") returns how much memory (in kb) lua thinks it is using. Logging this in the main loop of the script would let you know if gc was out of control for some reason.

This seems quite unlikely, but it's easy check. If it does turn out to be a problem, you can tune the collector options or force a collection cycle Lua 5.1 Reference Manual

One note on the script:
Each of the printing concatenated strings creates a new unique string for each output line, with associated allocation and garbage collection. I'd suggest using

Code: [Select]

print("blah", num, "blah") over

Code: [Select]

print("blah" .. num .. "blah") The first version copies each value directly to output* while the second creates a new string containing the entire line and copies that to output. In a loop where num constantly changes, you can see how this would end up with a lot of unneeded work.

* actually, looking at print it does a lua tostring() on the number which allocates a new string (unlike file:write), but still a smaller and less likely to be unique string. Thanks to changes made to make it go to the chdk console, print may also fail catastrophically if the final string is longer than 127 chars

edit:
As of SVN 525, print doesn't use tostring for numbers, and truncates lines > 127 chars

« Last Edit: 25 / September / 2008, 00:23:09 by reyalp »

Logged

Don't forget what the H stands for.

fbonomi

469
A570IS SD1100/Ixus80

Re: Night-time time-lapse

« Reply #29 on: 20 / September / 2008, 02:45:48 »

ohh, that's useful
I will give it a look.
Yes, the string fragmentation could be a problem...
Yes, the tostring() might be a problem, but anyway concatenating like I was doing was much worst, as it does a LOT of tostring() followed by a concatenation.

Logged