My experience with the cycle times using this script (OMNI Intervalometer) on a Canon S3:

Note: I got similar results using full 6M resolution and using the 640x480 image resolution. All my results were obtained in P mode, writing onto a 2Gb high speed card. (Indoors; at night; with no flash; aimed at my computer monitor.)

If I used a 0.5 interval time, I got about a bit less than a 2 sec cycle time. Presumably that reflects about 1.4 secs of processing time added to the specified delay of 0.5 sec. HOWEVER, this is with the image "review" time OFF (you find this on the first main menu when in shoot mode; this setting determines how long the shot you just took is displayed on the LCD or viewfinder before back to active shoot mode). If your image review time is not OFF, then that time is also added to cycle time.

Additionally, the very first parameter you enter "Script shoot Delay" (in 0.1 sec) also is added to the cycle time. (I'm not sure what this is for). It works fine at 0, and I don't see any reason to not leave it there (and, frankly, I don't know what prompted me to change it enough for me to see that it had an effect).

So, the approximate cycle time of the OMNI Intervalometer will be the sum of the following:

- 1.4 seconds (approx) of processing time for the image, plus

- the duration of the camera's image review time, plus

- the duration of the "Script shoot Delay" variable, plus

- the duration of the 3 interval variables (min, sec, 0.1 sec)

So about the fastest I could get it to go is ~1.9 sec when specifying a 0.5 sec interval.

BTW, I found a free quick-n-dirty program to assemble a sequence of images into a AVI. It's called JPGVideo (google it).

YMMV. Cheers, Divalent.

Speed Optimization? Edit

I found your results interesting. When first written using builds up to 119, the reason a 0.5 second time delay was set as a default is that the script could get shots less than 1 second apart. Less than 0.5 seconds had no effect or caused the script to error out from trying to run too fast, much more than that slowed it down. I think it was around 0.7 or 0.8 seconds where a slow-down started to occur so it was left at 0.5 seconds as a safe default between fastest and possible errors. I suspect as CHDK evolved and grew, it also slowed down a bit with so much extra code behind it. I just tested this script with having one of the newer motion-detection alpha-versions installed. The best I could get was one shot every 3 seconds. A huge hit to the speed. And this was with putting the camera in manual mode, turning off auto-white-balance, auto-focus, and disabling all of CHDK's OSD features (grid, histogram, zebra, DOF calc, etc.). Whenever testing for maximum obtainable speed for any script it's good to disable these.

Maybe a note should be added to run the script with nothing later than build 119 if fastesst obtainable speeds are required.

This is just like the very first RAW hack. I keep that handy in case I ever have the need for top RAW speeds. It can do a RAW frame every 1.2 seconds in hi-speed continuous mode. When CHDK was written on top of it (what started this whole thing), then the speed immediately dropped to one RAW frame every 1.4 seconds. I suspect it's much more than that now.

The caveat in v3 Edit

One caveat: While this script will account for shutter times whether you are using the camera's own settings or using the CHDK Override settings, it requires that you half-press the shutter once while NOT in <ALT> mode before actually running the script in <ALT> mode. This sets the get_tv96 variable that is read (by the script) for whatever shutter time is selected by any means. This was the only way available to detect the correct shutter time whether selected by CHDK Override or by the camera's own auto-modes. Using any of the other get_tv variables available would account for one but not the other, resulting in the wrong cycle times being calculated.
, Are you sure that if you shoot_half in the script it does not the same thing? (press shoot_half, wait ready to shoot, release shoot_half, read tv96) I thought that when you press keys in the script, they behave the same as outside alt-mode. Cyril42e 22:13, 12 June 2008 (UTC)

Ad blocker interference detected!

Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.