http://www.youtube.com/watch?v=MQah7sksQaw#wsI did another time lapse with the sx260 and g1x last night in the rain. I tried Saran (plastic) Rap and tape to protect the cameras from the rain. That worked pretty well, but some water still got on the lens. I put on one of those butterfly lens hoods on the G1X and that kept most of the water out. You can see me putting it on in the video.
The G1X did about 3,500 shots until the battery died. There was a sudden increase in brightness near the end, which I also noticed in my last test video (not uploaded). That could be in the script, or a bug in set_sv96(..). I'll figure that one out later.
The sx260 halted with an unspecified Lua error at about 1500 shots, giving only the "SCRIPT TERMINATED" message. This has happened before on both cameras while writing a log file, but this time I wasn't writing a log, so it must be related to something else.
Both cameras were in continuous mode, slowed down by the delay right before shutter open, set with set_shot_interval. The sx260 was set to 2000 msec, and the g1x 1500 msec. I have a possible answer, and solution:
My current get_shot_ready() function returns false until the shot meters and histogram are ready, and then returns true only once per shot. In continuous mode, you wait for get_shot_ready(), read the shot meters, set the exposure, and go back to waiting for get_shot_ready(). The problem is that get_shot_ready() has a timeout, which defaults to 100 msec. Normally, that's plenty of time, but occasionally, it starts timing out. I think the problem may be related to the script reading the shot meters while they're being computed for the next shot.
I realized that there's no need for a timeout in get_shot_ready(). It always returns immediately, so the script can implement a timeout if it wants to.
In continuous mode, the camera keeps shooting all the time. set_shot_interval(..) slows it down, but the shots can come fast and furious. The camera keeps up as well as possible by buffering shots. I think this is what the 2 raw buffers are for.
I think you can still set Sv96 and Tv96 during the delay in capt_seq_hook_set_nr(), but I'll have to test that more. It's taking awhile to figure out all these complications, but once I do, I should be able to keep up and meter exposure in continuous mode reliably at 2 shots per second or more.
====
I've also done some experiments with the histogram using a step size of 1, which samples the entire raw buffer. It takes about 16 seconds to do this, using get_raw_pixel(x,y). I just discovered that it only takes 1.5 seconds to go through (trash) the entire raw buffer using the raw buffer base address. A little in-line assembly code might even speed it up a little more.
I'm actually more interested in hot pixel removal in the raw buffer for long exposure night shots. It looks like 1.5 seconds is the minimum time it could take, which would be a big improvement over taking a dark frame every shot that doubles the time for each shot. Looks like another project for the future.
My latest shoot() bug idea got shot down in tests by skrytlen. I'll try to hold off until I can reproduce the bug on a camera that I can test myself.
Here's the test video I did last night from Skinner Butte in Eugene, Oregon, named after the city founder, Eugne Skinner. The highest spot in the background, towards the left, is Spencer's Butte, which is about 2,000 feet (600m) high. A lot of my other time lapse videos are taken from there.
[url=http://I did another time lapse with the sx260 and g1x last night in the rain. I tried Saran (plastic) Rap and tape to protect the cameras from the rain. That worked pretty well, but some water still got on the lens. I put on one of those butterfly lens hoods on the G1X and that kept most of the water out. You can see me putting it on in the video.
The G1X did about 3,500 shots until the battery died. There was a sudden increase in brightness near the end, which I also noticed in my last test video (not uploaded). That could be in the script, or a bug in set_sv96(..). I'll figure that one out later.
The sx260 halted with an unspecified Lua error at about 1500 shots, giving only the "SCRIPT TERMINATED" message. This has happened before on both cameras while writing a log file, but this time I wasn't writing a log, so it must be related to something else.
Both cameras were in continuous mode, slowed down by the delay right before shutter open, set with set_shot_interval. The sx260 was set to 2000 msec, and the g1x 1500 msec. I have a possible answer, and solution:
My current get_shot_ready() function returns false until the shot meters and histogram are ready, and then returns true only once per shot. In continuous mode, you wait for get_shot_ready(), read the shot meters, set the exposure, and go back to waiting for get_shot_ready(). The problem is that get_shot_ready() has a timeout, which defaults to 100 msec. Normally, that's plenty of time, but occasionally, it starts timing out. I think the problem may be related to the script reading the shot meters while they're being computed for the next shot.
I realized that there's no need for a timeout in get_shot_ready(). It always returns immediately, so the script can implement a timeout if it wants to.
In continuous mode, the camera keeps shooting all the time. set_shot_interval(..) slows it down, but the shots can come fast and furious. The camera keeps up as well as possible by buffering shots. I think this is what the 2 raw buffers are for.
I think you can still set Sv96 and Tv96 during the delay in capt_seq_hook_set_nr(), but I'll have to test that more. On thing that's taking so long is figuring out all these complications, but once I do, I should be able to keep up and meter exposure in continuous mode reliably at 2 shots per second or more.
====
I've also done some experiments with the histogram using a step size of 1, which samples the entire raw buffer. It takes about 16 seconds to do this, using get_raw_pixel(x,y). I just discovered that it only takes 1.5 seconds to trash the entire raw buffer using the raw buffer base address. A little in-line assembly code might even speed it up a little more.
I'm actually more interested in hot pixel removal in the raw buffer for long exposure night shots. It looks like 1.5 seconds is the minimum time it could take, which would be a big improvement over taking a dark frame every shot that doubles the time for each shot. Looks like another project for the future.
My latest shoot() bug idea got shot down in tests by skrytlen. I'll try to hold off until I can reproduce the bug on a camera that I can test myself.
Here's the test video I did last night from Skinner Butte in Eugene, Oregon, named after the city founder, Eugne Skinner. The highest spot in the background, towards the left, is Spencer's Butte, which is about 2,000 feet (600m) high. A lot of my other time lapse videos are taken from there.
