Discuss Your CHDK Scripts[]

  • How to write them
  • Help in how to write them
  • Better ways to post or share them
  • Etc.

Dear Script Authors and those just learning. There's a new CHDK Forum with its own dedicated Script Writing and uBASIC section. That forum's design and capabilities make it far easier to discuss and help with the sometimes confusing nature of scripts and uBASIC. You are strongly encouraged to join that forum so that you may get assistance more rapidly and in a much easier to follow discussion format. Please read the first post in that "Script Writing and uBASIC" form titled A Resource Heads-Up for some basic information on how to paste your scripts and code into the board's own format. The new forum makes it easy and fast. I hope you can join us there!

UBASIC Documentation Should be on Wiki[]

Discussion boards are great for specific UBASIC scripts, or discussing shortcomings/bugs in the language, but the actual UBASIC language documentation component should be here on the Wiki. The language itself doesn't require discussion. It requires some organization, and a wiki can do just that. The UBASIC language should be organized into groups like, language syntax, environment variables, functions, operators. Take a hint from AutoIt's documentation (another language based off of BASIC). Learning by example is helpful, but having API documentation organized is a lot more. Not just to newcomers, but experienced scripters alike. Just something to ponder.NiX0n 13:44, 24 June 2009 (UTC)

Ultra Intervalometer Script[]

While posing my Ultra Intervalometer script just now, I started to wonder how it would work to use it for a single shot after a long delay, repeated endlessly. Since I was working off of the original sample scripts, I left in the test to never let the number of shots for each intervalometer sequence to be less than 2 (because that makes the simple intervalometer meaningless in that instance). But the more I think about it, since this script has the endless repeat thingy in it, should I change that to allow for single shots? Then you could set a delay to first shot and sequence it endlessly. Otherwise you'd have to use no delay, and crank up the number of shots really high to get an "endless" type of action.

I think I'll change that now. In the line "if c<2 then let c=5" to "if c<1 then let c=5".

I think it would make the script a little more flexible this way.

Yes? No? Let me know if I should change that back or not.

Also, I was thinking it would be good to have a count-down timer during the pause phase. But I wasn't sure how to go about implementing that in the :pause subroutine.

Would something like this work?

 for m=1 to n
 print "Interval Begins:", n/60; "min", @(n/60); "sec"
 sleep 1000
 next m

Someone help out here! :-) How do I use the "remainder" @ command in this stuff?

I can't believe I can't think this out, maybe I've been up too late.

[Update: I did some more research into how a "remainder" is calculated and used properly, so I fixed my count-down timer and added in a short tutorial about it in the "tutorial" page I put together, in the "math expressions section."]

Well, this works, but danged if I know how to divvy it up into minutes and seconds, this at least counts down by seconds:

 for m=1 to n
 print "Interval Begins:", n-m; "sec"
 sleep 1000
 next m

BUT, there's going to be a problem. If the delay time is longer than your Power Saving setting to shut off the display (MAX of 3 minutes on the S3 IS), then the camera shuts off the display before the intervalometer shots are reached. Still though, for shorter Delay to 1st Shot settings it's still usable. I'll add that into the notes about it, until further notice on a work-around for that.

Seems I screwed-up on how the total time is computed for each cycle too. My old nemesis has come back to haunt me. I could do calculus in high-school, but if I was given a simple distance=rate * time, I couldn't do it. It's because the concept of time does not exist in my mind. In my mind it's like always multiplying by zero. The script works fine as is, it's just those print displays aren't right. And that sleep 1000 command in the :pause subroutine would have to be tweaked so each for/next loop really is 1 second. I'd have to time it for 3 minutes and see how much the 1000 should be reduced.

> Someone help out here! :-) How do I use the "remainder" @ command in this stuff?
Why you do not use just the following:

 print "Interval Begins:", (n-m)/60; "min", (n-m)%60; "sec"

-- GrAnd 19:49, 13 May 2007 (UTC) --

Thanks GrAnde, I just now figured it out on my own by reading your other scripts. It's been over 40 years since I've been in math class. :-) I corrected my script and added in a short "%" tutorial for us OLD people. :-)

Nice, I like your Ultra Intervalometer Script! --Harvester 09:36, 14 May 2007 (UTC)
I wanted to post my "advanced self-timer" script now, but then I realised that this functionality already is in your ultra intervalometer. :) Perhaps you could mention somewhere that your script is in so far better as the in-camera self timer, as it does measure focus and exposure again and again right before every shot. I think this is much better for self portraits than the in-camera timer, which only does this once and only in the beginning (when you press the shutter button). And perhaps you could find a better name for parameter g? Perhaps "unlimited" instead of "repeat"? --Harvester 18:20, 14 May 2007 (UTC)
  • Good script, though it would be even better if it could somehow turn the screen off to save power by pressing display a few times. Perhaps this could be added? --May 28, 2007
Is that a camera model specific feature perhaps? On my S3 I really can't turn off the display other than to set the Power Saving feature to turn off the display after set durations. Otherwise I can only toggle between 2 EVF display modes, or if the LCD is open then use the [display] button to toggle that between 2 display modes, It will turn off and revert to the EVF after it's shown its 2 display modes.
If you know how to do it on your camera from script commands, you could always tag on an addendum to the script page of where to include an extra click command or two. Would that suffice?
It would be nice if there was a little command to call up which camera model the script was running on, to make them more universal. But with so many makes and models now supported, it might be best just to tweak the script for your individual camera. This "talk" page here could help in that regard, if you want to change it but don't know how, someone might come along and help. Keoeeit 03:50, 28 May 2007 (UTC)

Script Contests, Photo-Tutorials, Games?[]

Now that most of the quirks about the scripts have been fixed and all the commands have been documented, I just started to think of some new ways they could be used. For starters, I wonder how a "CHDK Script Contest" could be implemented? Like the most creative use of a script per month or something?

Or how about Photography Tutorials for beginners? The print statements telling them what to do to get better shots? I found out you can pause a script in mid-stream and restart it again right where it left off just by holding down the [Flash] + [Shortcut] buttons on my S3 IS. (Exit and re-enter <ALT> mode while a script is running.) So you could print some instructions, have them pause the script to make exposure settings, find a subject, etc. Then onto the next little task.

But what really brought this to mind just now is I was thinking if there could be any kinds of script games that could be played with the camera? Maybe something like....

print "You'll have 30 seconds"
print "to find something that"
print "moves fast enough to"
print "pan the camera."
print "5 shots will be taken"
print "Make sure the subject"
print "is in all frames."

pause 30000

(do the timer countdown, & shots)

print "Your next subject must"
print "be properly exposed"
print "at 1/1250th of a second"
print "at f/8.0. You have"
print "1 minute to find it!"

(set exposure and f/stop to take the next shot, 
if they can't find the right subject it won't 
turn out right)

print "How's your hand-held"
print "skills? The next shot"
print "will require a subject"
print "exposed for 1 full sec."


Or more things along that line. It could even be a contest of sorts. Everyone download the same script and share what shots they were able to get within the constraints/discipline of the script. Stuff like that. I see how some scripts could be a challenge to even a seasoned photographer.

Silly ideas? (I'm up late, drinking coffee, thinking too much. :-) )

A RND function would be fun. Let the camera fire off shots at random intervals all day, just to see what you get. :-)

GET_AV statement[]

You can see from "property case" 3 the AV-number (39) with different apertures and on the next page there is the TV number (40).

In uBASIC source code (platform/generic/shooting.c) there are tabels ApertureSize and ShutterSpeed. There are a couple of strange things in these tables (or my a710).

const ApertureSize aperture_sizes_table[] = {
   {  9, 288, "2.8", },   // 283, pc 39
   { 10, 320, "3.2", },
   { 11, 352, "3.5", },
   { 12, 384, "4.0", },
   { 13, 416, "4.5", },
   { 14, 448, "5.0", },
   { 15, 480, "5.6", },
   { 16, 512, "6.3", },
   { 17, 544, "7.1", },
   { 18, 576, "8.0", },

If I set the aperture to 2.8 I get the value 283, not 288. That's why my results differ from Harvester's. Maybe a710 has a slighty more powerful lense (2,78 vs 2,83)?

The TV has two strange things, why are values -10 and 29 missing? This deviates from the over-all trend of one step corresponding to 1/3 EV. A710is has a strange behaviour: I set the speed to 1/1600 when aperture is 5.6, then I change the aperture to 3.5 and the speed changes to 1/1500 (property value = 1008).

const ShutterSpeed shutter_speeds_table[] = {  // pc=40
   {-13, -384, "15", 15000000  },
   {-12, -352, "13", 13000000  },
   {-11, -320, "10", 10000000  },
   {-9, -288, "8", 8000000  },        // -10 missing
   {-8, -256, "6", 6000000  },
   {-7, -224, "5", 5000000  },
   {27, 864, "1/500",   2000 },
   {28, 896, "1/640",   1563 },
   {30, 928, "1/800",   1250 },    // 29 missing
   {31, 960, "1/1000",   1000 },
   {32, 992, "1/1250",    800 },  
// {xx, 1008, "1/1500"    667 },     1008, if aperture >4.0 then 1/1500 is the fastest.
   {33, 1021, "1/1600",    625 },
   {34, 1053, "1/2000",    500 },
   {35, 1084, "1/2500",    400 },

I have the following proposals:

1) remove the missing steps (-10 and 29) from the table so each step is 1/3 EV

2) if different camera's have different values, the tables should be moved to specific camera platform. If the only deviation is the 2.8 aperture, then it is enough if GET_AV with property case 39=283 returns 9. Even in my camera "set_AV 9" sets the aperture correctly to 2.8.

3) Maybe a more generic solution would be to use the actual property case values in the set_ and get_ statements, then 1/3 EV step correspond to 32. (I do not know why the fastest steps are not exactly equal to 32)

Any comments? -Stebu

IF / THEN / ELSE GOSUB = Parse Error?[]

I tried to shorten up this bit of code:

 if p>0 then gosub "pause"
 print "Shot 1 of", d
 if a=0 then shoot
 if a=1 then gosub "vid"
 if a=2 then gosub "vid"
 for n=2 to d
 sleep t*100
 print "Shot", n, "of", d
 if a=0 then shoot
 if a=1 then gosub "vid"
 if a=2 then gosub "vid"
 next n
 if j=1 then goto "interval" else end


 if p>0 then gosub "pause"
 print "Shot 1 of", d
 if a=0 then shoot else gosub "vid"
 for n=2 to d
 sleep t*100
 print "Shot", n, "of", d
 if a=0 then shoot else gosub "vid"
 next n
 if j=1 then goto "interval" else end

But I got a parse error on that if a=0 then shoot else gosub "vid" section. I take it that this isn't supposed to work? Or is this just a bug in the uBASIC section? Or it's just not allowed no matter what?

I also tried if a>0 then gosub "vid" else shoot because that syntax seemed to work with the if p>0 then gosub "pause"' line, But that didn't work either. I guess it just don't like the else with a gosub routine, or the shoot command, not sure which.

Keoeeit 10:13, 29 May 2007 (UTC)

UPPER CASE keywords = Parse Error?[]

A guy from the bulgarian forum complained about the multipurpose bracketing script - uBasic interpreter reported Unknown statement error. When I reviewed the script, everything looked correct. There were however two lines of the code, looking a bit suspicious. Actually two of the original lines were commented with REM and a short description was added at the end of these lines. My first though was that these two lines are too long and after removing them, the script worked Ok. But I was really surprised some minutes later, when I tryed to put back the two REMs where they were, but this time I used lowercase for the keyword rem - the script worked again. It seems that uBasic is case sensitive (at least its keywords are), which is strange for a language from the BASIC family :) But I do not remember if it is stated somewhere in the wiki that uBasic's keywords are case sensitive. If not - I would like to ask somebody with better skills in english to explain this in the appropriate article.

Zdravko 23:02, 09 June 2007 (UTC)

Lightning Script HELP![]

I was going over my lightning-photography scripts and wanted to add a 3rd option so that I could adjust the f/stop higher than what the camera automatically sets in Tv mode. But I ran into a snafu. The following script does just that, but it ONLY happens when I'm in M(anual) mode. There's no need for the script to change the f/stop in manual mode, since you'd be doing that anyway if you want. I wanted to have the script automatically set focus in Tv mode (if not in MF mode), but to override the auto-aperture value with the + X/3 f/stop setting. Those set_av and set_tv commands seem really touchy too. They need some pauses put near them when reading or setting the values. And I'm finding that you can never use them inside of (after) any press "shoot_half/full" commands at all or they never take. Just after click "shoot_half/full" commands or just before press "shoot_half/full" commands. It took about 3 hours of testing various combos of sleep statements and where to place the get_av/set_av commands before I could get to this point where it (almost) works, but again it only sets the aperture-value in M(anual) mode. There's no reason for it to do it in M(anual) mode. I wanted it to work in Tv mode. (I'll insert lots of rem comments to make it easier to follow if anyone wants to figure out why this isn't working like I want.) This is for S-series cameras btw.

rem Author ~Keoeeit~
@title S-Lightning Photos
@param a Duration Minutes
@default a 1
@param b Duration Seconds
@default b 0

rem input how may 1/3rd f-stop increases you want the exposures at
@param c f/stop + X/3
@default c 0

if t<1000 then let t=1000

rem c is never more than original f/stop + 9
if c<0 then c=0
if c>9 then c=9

print "Use Tv or M mode."
print "Use MF mode at inf."
sleep 2000

rem get original values for a reset
get_tv o
sleep 100
get_av p
sleep 100

rem put camera in continuous mode
press "timer"
sleep 200
release "timer"

rem half-shutter press to set focus (if not in MF) and get exposure settings
click "shoot_half"
sleep 1000
get_av f
sleep 100

rem add required 3rd f/stops to camera's auto-settings

rem aperture value can never be more than 18 (= f/8.0)
if f>18 then f=18

rem set shutter speed to 1", making sure that value 0 isn't 1/3200 second
set_tv 1
set_tv_rel -1
sleep 100

set_av f
sleep 100
press "shoot_full"
sleep t
release "shoot_full"
sleep 2000

rem reset camera back to original settings
press "timer"
sleep 200
release "timer"
sleep 500
press "timer"
sleep 200
release "timer"
sleep 500
set_tv o
sleep 100
set_av p
sleep 100

rem shutter and aperture won't go back to original values until after a half-shoot
click "shoot_half"


Anyone got any ideas how to make this better?

Keoeeit 16:25, 8 June 2007 (UTC)

June 29, 2007 -- Because they're only effective in Manual mode, I can't see how to put the get_av/set_av (and Tv) commands to decent, reliable use. Do you want to render a script (this, as well as the Ultra Intervalometer Version 2 script) which is relegated to use in just M mode? Even if you do want to (make shooting in M mode a prerequisite for the lightning script)... by bracketing in sets of 3, you'll immediately be diminishing the resulting number of "good" shots by a factor of 3. Really, until or unless the Av and Tv -related commands are usable across various mode settings, I think you'll be "making the script better" by excluding use of those commands.

OMNI-Bracket Script?[]

Going off the idea of my OMNI-Intervalometer script, who wants to be the first to write one for bracketing?

If I was doing it, it would include bracketing options for f/stop, shutter, ISO, and focus. Focus bracket should include an option to also do HDR images by f/stop, shutter, or ISO bracketing.

I'd also like to be able to input the depth of my subject and slice it up into as many focal-planes as needed. I could just make sure the camera is focused on the near-most portion of the subject, and then let it slice-up the subject. This would take out so much guess-work out of how many near and far brackets would be needed. Say it's a snail, and I estimate the snail + shell was about 5cm deep. I input Subject Depth 5cm, Number of Planes 10. (Inputting a subject depth would require quite a few variables, meters, decimeters, cm, and mm.) I could focus on the nearest antenna and the camera would divvy-up that ol' snail into 10 nice focal-plane shots. Would the focal-plane slices have to be computed on an exponential curve to be more accurate if using any zoom settings with macro-lenses? (to hit the congruent focal-planes of smallest circle-of-confusion) Also, if focus-bracketing and I select an HDR option of f/stop, shutter, or ISO, then 2 to 8(?) exposures for each plane too.

Anyone want to tackle this?

btw: are we limited to single-letter variables? I nearly ran out of them on the OMNI-Intervalometer script. After you take away the 10 for user-input, that's only 16 left! Keoeeit 08:33, 13 June 2007 (UTC)

Preliminary phase:

Well, I started working on it just now, and here's what I have so far. I can see how I'm going to have to use a get_zoom variable to work out the focus bracketing steps to cover in-focus planes too, but I've not even started to work on that section yet.

none of it tested, just brainstorming on paper so far

hmmm.. that ISO bracket part, with only 5 steps available, will need work

a work in progress

rem Author ~Keoeeit~
@title OMNI Bracket
@param a Av=0 Tv=1 ISO=2 Focus=3
@default a 0
@param b Av or Tv Step X/3
@default b 3
@param c # of Bracket Shots
@default c 3
@param d Subject Focal Depth (m)
@default d 0
@param e Subject Focal Depth (dm)
@default e 1
@param f Subject Focal Depth (cm)
@default f 0
@param g Subject Focal Depth (mm)
@default g 0

rem going to offer the option of dividing up your in-focus
rem focus-brackets in linear or exponential steps
rem so in Exp mode near-focus planes will be spaced closer
rem and far-focus planes spaced further. using
rem subject-depth divided by # of shots

@param h Focus Increment Lin=0 Exp=1
@default h 0

rem offering option to make exposure comensation + focus bracketing
rem for HDR macro-photos

@param i F-HDR Off=0 Av=1 Tv=2 ISO=3
@default i 0

rem param j probably not needed but allocated just in case
rem might end up using this variable to select if using
rem telextender, wide-angle, or +diopter closeup lenses
rem for focus bracketing step compensation. Where j could be
rem -2 for tel, -1 for wide, 0 off, or 1,2,...10 for +10 lenses

@param j # of Focal-HDR Brackets
@default j 3

if a<0 then a=0
if a>3 then a=3
if b<0 then b=0
if c<2 then c=2

rem have to set up a condition where +/- shots will
rem be used for Av & Tv modes and only + shots are
rem used for focus-bracketing modes. Not sure how
rem this will pan out for rounding out whole numbers

if a<2 then c=c/2

if d<0 then d=0
if d>60 then d=60
if e<0 then e=0
if e>10 then e=10
if f<0 then f=0
if f>10 then f=10
if g<0 then g=0
if g>10 then g=10
if h<0 then h=0
if h>1 then h=1
if i<0 then i=0
if i>3 then i=3
if j<2 then j=2

print "Camera in Manual Mode."
print "If F-bracket, focus on"
print "nearest in-focus plane."

sleep 2000

get_av k
get_tv l
get_iso m
get_focus n

if a=0 then gosub "avbrkt"
if a=1 then gosub "tvbrkt"
if a=2 then gosub "isobrkt"
if a=3 then gosub "fbrkt"


 if o-b*c<9 then o=9+b*c
 if o+b*c>18 then o=18-b*c
 gosub "avtvshot"
 set_av k

rem this tvbrkt section will need to be reworked to compensate for the
rem higher shutter speeds, where only certain f/stops are available
rem for each shutter speed.

 if o-b*c<-12 then o=-12+b*c
 if o+b*c>35 then o=35-b*c
 gosub "avtvshot"
 set_tv l

rem needs work, with only 5 steps available, should set the
rem upper and lower limits like for the other subroutines.
rem Well, this section is needing some serious reworking, for the
rem life of me I have a mental block and can't get it to properly
rem choose a set of 2 to 5 numbers (by number of shots) where the
rem pre-selected ISO pushes that set of numbers to one end or the other
rem I got close to making it work one time but it screwed up when 
rem # of shots was equal to ISO # (1-5) for some weird reason.

 if c>5 then c=5
 if o-c<1 then o=1
 if o+c>5 then o=5
  for z=1 to c
   print "Shot", z, "of", c
   set_iso o
  next z
 set_iso m


  for z=-c to c
   print "Shot", z+c+1, "of", c*2+1
   set_av q
  next z

Keoeeit 17:00, 14 June 2007 (UTC)

I see a problem I'm going to run into trying to use similar routines/options of both exposure and focus brackets. In that exposure is going to be +/- shots and focus is going to be linear starting from the beginning. This sets up a problem for variable C (# of shots). I could easily compensate for it by having the number of shots being divided by 2 before entering the Av and Tv bracketing routines, but I'm not sure how that's going to round out for integers on even and odd numbers. Perhaps I'll have to rethink how to approach the upcoming focus-bracketing section. And since the ISO bracketing only has 5 steps available, I was going to set it according to how many shots you took, with only 1 step allowed. So if you were on ISO 400 and chose 4 shots, it would kick back to ISO 100, then do 200, 400, 800. Or if on 100, then it would kick down to 80, and then do 100, 200, 300.

A quick ubasic_test with a for a=-5 to 5 loop, I guess it'll work just fine to use c/2

a= -5 a/2= -2
a= -4 a/2= -2
a= -3 a/2= -1
a= -2 a/2= -1
a= -1 a/2= 0
a= 0 a/2= 0
a= 1 a/2= 0
a= 2 a/2= 1
a= 3 a/2= 1
a= 4 a/2= 2
a= 5 a/2= 2

Just needs a usage note to alert the user that inputting 4 shots will give you +/- 2 shots plus original, and 5 shots gives you the same.

Keoeeit 20:03, 14 June 2007 (UTC)

Well, good thing I held off on working on this more (I ran into a major mental-block on the ISO bracketing for some reason, trying to fit such a narrow number of options in a narrow range just wasn't working!). With the new interactive commands (wait_click and is_key) I can make a print "option" sequence where the user can select the type of bracketing they want by scrolling through selections with the right/left keys and the set key to set the option as it's printed to their viewfinder. That'll save on using up lots of @param variables at times! Thanks GrAnd, that's going to be a neat option. As well as adding to the usefulness of scripts. I can foresee all sorts of Beginner Photography Tutorial scripts using that interactivity.

Keoeeit 11:57, 16 June 2007 (UTC)

(Russ) June 29, 2007 -- With due respect for your efforts, I believe your intended goal, or scope, for this script seems too inclusive. Yes, AFAIK, vars are limited to single-characer names. By stuffing everything into one script, not only will you pull your hair out trying to code around that limitation... you force the user to wade through all those myriad params in the setup screen. Separate task-oriented scripts will be more user-friendly, even if the specificity amounts to nothing more than embedding task-specific helptext/tips into an otherwise reduntant intervalometer or bracketing script.

Even for a general-use intervalometer, there's a lot of room for (need for) user handholding. I'm pasting sample code here to illustrate a number of coding conventions I've adopted for the CHDK scripts. Most of the comment lines would be removed from the final version; as-is, they reflect my train(s) of thought while drafting the script.

The first of several "coding conventions" is inclusion of plenty of helptext, ALONG WITH a param ("show helptext or not?") so that expert users don't need to wade through the verbose help each runtime. The second convention is coding with attention to what the user sees on the OSD throughout the script's execution. Don't leave the user wondering what they are supposed to do next, or wondering whether the script is "hung" -- use plenty of print statements. In the same vein, any time we're presenting less than a screenful (5 print lines, or 4lines+paused/click line), use BLANK print statements to scroll away previously-read text.

The suggestion of creating, and placing, a *.txt file matching each script on one's flash card was a "good idea, in theory" but I feel it shouldn't serve as an excuse for failing to provide runtime help.

The "countdown" gosub exemplifies a third convention. This handy block of code is suitable for nearly any script (an optional start delay to dampen camera shake is a welcome feature for most applications) and reusing the SAME onscreen countdown text across various scripts places the user on "comfortable, familiar ground". Toward this goal of providing a 'familiar' interface, across my various scripts an identical prompt ("paused --[ click SET ]--" precedes each wait_click occurence. (FWIW, I revised the verbiage half a dozen times before settling on this. Yes, it's misleading, in the sense that most any keypress would suffice, even a shutter half-press... but it is simple, and familiar.)

Next convention is attention to ease of input (params). I see from your script, above, that you've also been attending to this. Unless we've run out of vars, give 'em separate inputs for minutes+sec (or mm/cm/dm/m as in your script above) rather than requiring bouts of scrolling.

Another convention must be attention to error-checking (checking user-provided values). I'm not typing here in prioritized order but, coincidentally, attention to error-checking *would* be this far (#5 or so) down my list rather than at the top. When coding the scripts, we're too constrained (by var namespace etc) to go overboard on error-checking, I think. Even if a particular bad input value (negative integer etc) or combination of param values is going to CRASH the script... I can't lose much sleep over a silly-assed user entering "-40" (or zero) for "number of shots" etc.

I'm hopeful that future CHDK builds will provide us scripted access to stateful things, like "is_flash_enabled" (auto/yes/disabled) and "ModeDial_is_set_to" (M/Av/Tv/P/Auto/Movie/Other) and "get_focalMode" (normal/macro/manual)... but, in the meantime, I'm following a scripting convention of avoiding "click left, click down" etc. because the unpredictability of the cursor position results in unreliable script execution.

For anyone who intends to script simulated SET (function) menu keypresses, this "workaround" may be effective (for A6xx series, at least):

print "This script performs"
print "SET menu keypresses."
print "Jog the ModeDial NOW"
print "to force CURSOR reset"
print "paused --[ click SET ]--"

After a jog, pressing SET brings up the function menu with the cursor at the top row, lefthand side. Of course, nothing other than flash can be predictably set via simulated down/right click commands, due to the wrap-around nature of each interface line.

this is a work-in-progress (not a finalized script)

rem DIFFS (from ULTRAintervalometer)
rem no tenths-of-a-second count
rem I have a separate "shoot_bursts" script, geared for speed)
rem MIN 1sec interval (enforced within flashcycle sub)

@title Interval shooting
rem for A620 (should work with any A6xx cam)
rem EACH TEN SECONDS APART w 5sec startup delay

rem Not as fast as _continuous_ script
rem because METERING is performed prior to each shot
@param a ShotCount x1
@default a 0
@param b ShotCount x10
@default b 1
let z=b*10+a
if z<1 then let z=1

@param h Interval (seconds)
@default h 10
@param i Interval (minutes)
@default i 0
let v=i*60000+h*1000
if v<4000 then gosub "flashcycle"
rem HMMM use IF lessthan AND showhelp=1 ?

rem initial delay in case shoot is self_portraiture etc
@param c Start Delay (sec)
@default c 5
@param d Start Delay (min)
@default d 0

@param e Show helptext? (1=yes)
@default e 1
if e=1 then gosub "instruct"

rem default is 5s to handle camera shake (user can override)
let w=d*60+c
if w>0 then print w,"sec delayed start..."
if w>0 then gosub "countdown"

for n=1 to z
     print "Shot ", n, " _of_ ", z
     rem sleep NOT required after shoot (but it serves as a timer here)
     rem sleep v
     rem Instead of just sleep, let's print the count to screen
     gosub "untilnext"
next n
print " "

print "If AF assist is active,"
print "the LED provides"
print "a visual cue when"
print "each shot commences"
print "paused --[ click SET ]--"

for n=1 to w
let m=w-n+1
print "countdown: ", m, "secs"
sleep 940
next n
print " "
print " "
print " "
print " "
print " "

let w=v/1000
for n=1 to w
let m=w-n+1
print "next shot in: ", m, "secs"
sleep 930
next n
print " "
print " "
print " "
print " "
print " "

if v<1000 then let v=1000
print "NOTE:"
print "if FLASH is enabled, the"
print "chosen (short) interval"
print "may not succeed"
print "paused --[ click SET ]--"
print "TIP:"
print "reducing flash output"
print "('Erase' aka +/- button)"
print "will reduce recycle time"
print "paused --[ click SET ]--"

this is a work-in-progress (not a finalized script)


Tele-Super-Macro Mode Comments[]

I answered this question on my personal Wiki page, and thought the comments should be more public for those that might have some curiosity about this amazing "bug"/"feature"/"break-your-camera-maybe".

S3 IS super macro zoom hack

I have not had the courage to try this hack on my S3 IS, I am wondering how much the depth of field drops off when you zoom in in super macro mode. How much can you zoom in and still have focus? HighInBC 17:34, 16 June 2007 (UTC)

When I use manual focus set the closest: At widest-angle zoom I can focus on something as close as 2mm from the front surface of the lens, and when zoomed-in all the way (zoom step 128), I can focus at about 55cm, or about 22 inches. When manually focused to infinity, and zoomed-in all the way (step 128 zoom), I can focus on something about 3-4 meters away. The DOF becomes just as shallow as if using close-up filters in zoom mode or with a tel-extender + close-up filters. With that much focusing range this FAR surpasses any effects and features I can do with add-on lenses. Not to mention turning it into a fantastic portrait lens with a super-shallow DOF for tight face shots. When zoom is set to step 64 (halfway), I can focus on a ruler about 13cm (5 inches) from the lens and the FOV is about 2.2 inches. At zoom step 32 (1/4th zoom) FOV is about 4.5cm (1.5") about 2cm away from the front of the lens (one thumb width away).
SO ... this is am amazing feature. I just wish I felt safer putting my camera in that mode. I hate hearing those thudding and buzzing noises. I thought I'd risk it again to answer your question, because it got me curious what the ranges are with the lens "tricked" into acting this way. Once the lens is in this mode, it doesn't appear to make any disturbing noises anymore when focusing and zooming at any speed. It's just when it gets triggered into this mode does the camera make disturbing noises. The lens has reset safely every time I have turned the camera off and on again, but .... from the sounds the camera is making, it still sounds risky to use this!
Keoeeit 18:50, 16 June 2007 (UTC)

Deutschsprachige Skripte / German language scripts[]

Ich habe vier Skripte aus dem hier verfügbaren Fundus erweitert, für meine Belange optimiert und hinsichtlich der angezeigten Texte ins Deutsche übertragen. Näheres dazu sowie eine Download-Möglichkeit finden Sie in meinem Weblog unter

Viel Spaß und Erfolg bei eigenen Experimenten damit!

--zonebattler 07:34, 25 June 2007 (UTC)

Cable-Release Script (idea)[]

I just thought of something really wonderful. For the longest time I've been trying to figure out how to make a bracket to reach up and around to match that odd angle that the shutter-button is at, to put a cable release on it. I'd hate to have it look home-made, and then where would I put something that huge in my camera-bag? But then I realized ... with CHDK's new wait_click and is_key commands, I could assign ANY button to trip the shutter for an exposure (along with the shoot command). So ... how hard would it be to make a tiny 1-inch long L-bracket to go from the tripod socket to match up with the [DISP]lay button on the back of my S3 and then run a CHDK script waiting for a cable-release to press that? What a compact and easy solution!!

User Variable Zoom?[]

There are times that I'd like finer control over the zoom toggle. So I thought I might be able to control it through a script.

I can get it to set the zoom_rate. Though I wish there was a way that the number would increment continuously as I held in the UP or DOWN buttons. You have to press it every time to change it just one step.

But the real problem is trying to get the zoom to work right. If I press ZOOM_IN or ZOOM_OUT, the lens keeps zooming in or out until it reaches the end of its limit, then the camera usually shuts down.

Can someone figure out what's going wrong? Or how to improve this?

rem Vari-Zoom

@title Vari-Zoom
@param a Default Zoom Speed
@default a 75

print "Use zoom-in zoom-out"
print "as normal. Use up and"
print "down to set zoom-rate."
print "press [SET] to continue."
print "Zoom-Rate = ", a
is_key u "up"
if u=1 then a=a+1
is_key d "down"
if d=1 then a=a-1
if a>100 then a=100
if a<10 then a=10
set_zoom_speed a
if u=1 or d=1 then cls
if u=1 or d=1 then print "Zoom_Rate = ", a
is_key i "zoom_in"
if i=1 then press "zoom_in"
if i=0 then release "zoom_in"
is_key o "zoom_out"
if o=1 then press "zoom_out"
if o=0 then release "zoom_out"
goto "gozoom"

I put in these lines of code in the zooming section, hoping it would fix this, but no.

if i=0 then release "zoom_in"
if o=0 then release "zoom_out"
Hi! I think the problem might involve the wait_click immediately following the :gozoom label. Once you've hit the zoom_in, it looks like (physically) releasing the zoom is being ignored by wait_click, so the script will be waiting for the next "click" before it can possibly reach the line that releases zoom_in. If you (physically) release the zoom, then hit another button while the lens is still zooming, does that stop it?
- Pete.
Yes, it acts just as you predicted. Release zoom, press any other button, it stops the zoom. But unfortunately just before it stops, the zoom takes a short leap at full-speed in its direction of travel. As if the camera still has to add-in its own manual-zoom press along with it, outside of the script controlling the zoom. I wonder, if instead, this can be done with some kind of timed-counter triggered by the zoom-lever and the set_zoom command instead. That seems like a weird work-around for something that should be so straight-forward using the existing press/release commands. I've also tried click "zoom_in/out" commands but that didn't work in this wait_click loop. Do you have any ideas how to make this work? I don't know how the wait_click (timeout) command works, can a timeout be incorporated into that loop to make this work? And just what does the timeout number represent, milliseconds, seconds?
The number is milliseconds, I guess, because the other timing numbers seem to work in milliseconds. I'm hesitant to suggest a solution because a) I'm very new to CHDK - I only found this page because I'm reading up about the scripting! - and b) event loops are always trickier than one expects in programming :). Maybe something could be done with a short timeout on wait_click and use of the "no_key" key (or just not matching the is_key for zoom_in). If wait_key is new, then maybe someday we'll get a "wait_event" which would be triggered by a click OR a release - that would be the best fix, I think. On the other hand, I'm not sure why you're having the script press the zoom-in and zoom-out buttons while the user is doing the same.. Does the zoom speed set by the script only apply to zoom events triggered by the script, and not affect the speed of the zoom for physically triggered zooms? If yes, then I think you might have to use some other key to trigger the zoom, but if no then you might just want to set the zoom speed and let the user do the zooming...?
- Pete.
re: Making the script press the zoom-in/out -- because I wanted it to be able to use the same button for familiarity. Since the zoom-rocker switch (and all other controls, except the <ALT> toggle) are locked out from use when a script is normally running, I thought there wouldn't be a problem assigning the same buttons to the same function. But I'm glad you brought this up. I could just as easily use the UP and DOWN buttons for zoom in and out. That would circumvent the camera from detecting that the zoom lever was pressed. That's would be one part of the problem solved. It may solve others. Maybe with that combined a momentary right or left click to stop the zoom where I want it controling it that way may be just as easy. I'd only have to add that to any user notes. Since it supposed to have the ability to move the zoom at a very very slow rate if desired, that might be all that I need. As for zoom-speed X, I think it does only work for scripted zooming events, that command was originally added as part of the set_zoom, get_zoom features, so you could zoom to a particular zoom step at a desired rate. As for just setting the zoom speed, and then using the control manually after exiting the script, the zoom speed is only in effect while the script is running (or so it appears). And as I said, then manual use of zoom (and other controls) are not operative when in script mode. That's why I was trying to re-map the zoom control through the script. Thanks for the input though, the idea of assigning the zoom to other buttons might be a workable solution. I'll try it next time I'm in scripting & testing mood. (That's the main drawback to writing scripts, tweaking a line, putting it on an SD card, lock card, boot up the camera, nope that don't work, power-down camera, unlock card, put in card reader, tweak a new line, copy to card, ... and do it again and again. It can be tedious and I lose interest after enough repeated failures. :-) )

Motion Detection Script?[]

I tried the following script, and it should work, but it seems that the get_tv and get_av commands only work when they are manually changed? If anything in the image will cause a 1/3 stop change then the camera should automatically trip the shutter. The two print statements inside of the :check loop are there to let me see if they were changing or not. I added them after I found this wasn't working. This works if I pause the script (exit <ALT> mode), then change camera modes to something where the shutter or aperture will have to change (as in my Custom mode), but otherwise it just keeps printing 10/31 over and over again no matter how the light changes. I also put in the extra sleep commands because sometimes commands need a delay for them to work properly. The sleep commands didn't seem to help either.

rem Motion Detect

@title Motion Detect
@param a Checking Frequency (seconds)
@default a 1

print "Use Auto or P mode."
press "shoot_half"
sleep 500
get_av f
get_tv s
release "shoot_half"
sleep 500
press "shoot_half"
sleep 500
get_av f
get_tv s
print "AV=", f
print "TV=", s
if f<>x or s<>y then click "shoot_full"
if f<>x or s<>y then sleep 500
release "shoot_half"
sleep a*1000
goto "check"

Is there any way around this? Or could CHDK be changed so that the get_av and get_tv will read the settings the camera is automatically selecting instead of those that a person would set manually?

A suggestion

Looking at property cases using debug function in CHDK, it seems values 68 (Av) and 69 (Tv) could be used for this purpose. But I can find no way to get those.

Is there any way to use uBasic to get an arbitrary property case value?

Say I want to get the value of property case 69, can I do this without compiling a new version of CHDK?

If this is not possible currently, I would very much like such a function included in the next version of CHDK.

Perhaps a function like this in shooting.c (and other places), that read the property case value and returns it as an integer for use in the uBasic script:

int shooting_get_property_case(int id)

Then perhaps it could be used in a script like this:

press "half_shoot"
get_property_case 69 x
if x > 800 then
press "shoot"

or alternatively split it in two (first set id, and then get value)

press "half_shoot"
set_property_case_id 69
get_property_case_value x
if x > 800 then
press "shoot"

Comments anyone?

Error Message Canon A710

I loaded the following contributed script into my Canon A710 and I get an error message in the upper left hand corner:

UBASIC: 4 Parse err

What am I doing wrong?

It is loaded into the \CHDK\SCRIPTS directory exactly as below. I tried other scripts and get the same error message. Again, what am I doing wrong? I must be making some amateurish mistake.

@title Video with zoom

print "Half-press shoot button" print "to stop video recording" print ""

get_zoom z

click "shoot_full"

 is_key k "zoom_in"
   if k=1 then set_zoom_rel +1
 is_key k "zoom_out"
   if k=1 then set_zoom_rel -1
 is_key k "shoot_half"
   if k=1 then goto "end"

goto "loop"


click "shoot_full" sleep 2000 set_zoom z



Is there a way to have the camera start a script or enact another command when the battery voltage goes above max or below min, not just turn the camera off.

formulating an idea

.......... ANSWER ; ................. I´ve got the same problem... i think the solution is ".... then set_zoom_rel-1" dont leave a space inbetween the label and the variable.. as is said i had the same problem in uBasic... at the end i found out that the syntax has to be formatted the right way

modify "Lightning Detection"[]

I modify "Lightning Detection" script. I add "Shoot count" and "Detect Timeout". To seem works but I`m begginer and I`m not sure is everythings is OK.

@title Lightning Detection (Use MF mode at infinity)
@param a Columns
@default a 10
@param b Rows
@default b 10
@param c Shoot count
@default c 10
@param d Detect Timeout (secs)
@default d 30
@param e Measure Interval (msec)
@default e 0
@param f Threshold
@default f 10
@param i Start Delay (sec.)
@default i 1
if a<1 then let a=1
if b<1 then let b=1
if c<1 then c=1
if d<0 then let d=0
let d=d*1000
let i=i*1000
sleep i
for j=0 to 100000
let h=0
md_detect_motion a, b, 1, d, e, f, 0, h
if h>0 then goto "1"
next j
for n=1 to c
print "Shot", n, "of", c
next n

Intervalometer granularity[]

Hi, I'm using the OMNI intervalometer script and I find I can't get it to go faster than around 1 shot every 0.8 second or so. I need to get around 4-5 shots per second for the kind of project I'm doing (today I shot a timelapse film from the dashboard of my car... the results were only so-so). But no matter how low I set the OMNI parameters, I still hit this "wall". I guess the camera can only go so fast (it's an S3 IS), it's not a pro camera after all. I've tried the obvious things like turning off RAW, taking low-quality images only et cetera. Can it be done? Perhaps using bursts, etc. (which then would have a large collective write time at the end of the burst, which would put a "hole" in my film)? All comments welcome.

I don't think you can do much better. Have you tried the hi-speed continuous mode? A separate setting in the main menu enables it, then the continuous mode setting using the timer button has the camera take a picture as fast as it will go as long as the shutter is held down. I think I was getting about 1 shot per 0.6 sec. See the "A fast intervalometer" script in the user section. Faster than that and I think your only option is to use a video mode, like 640x480 at 15 fps. Also, I'm curious: what are you taking a time lapse of?

Thanks for the comments, I'll try that. I'm taking timelapse films of the kind of thing that was in Koyaanisqatsi, if you've ever seen that film. Traffic, trams, trains, people walking down the street and shadows slowly moving across buildings et cetera. It's a lot of fun to do. Next big project is to do a timelapse of the entire ring-motorway around Milan (where I live), with the camera on the car dashboard. This then creates problems when I stitch the pics together with Windows Movie Maker, it can only really handle a max of around 300 images before it collapses. The virtual memory needed goes off the scale. I plan to max out the memory on my laptop (2GB).

If you have all numbers in filenames in sequence then you should try VirtualDub, it can seek frames fast and drop out the frames you don't like with ease.
Have you tried a program called "JPGVideo" to convert a sequence of photos to a movie? Its freeware, and a bit spartan. (google it to find it) I haven't tried more than about 250 photos, but it might be worth a try to see if you go beyond Windows movie maker. The key I found for quality was selecting the right codex. BTW, I did see that movie (many times). The disadvantage of the high-speed mode is that all images are taken with the initial settings and exposure, be careful when photographing sequences where you expect the exposure to change. Also, you might want to experiment with neutral density filters to allow the exposure time to be longer, to get that blurry continuous motion. Good luck, and post some results!

Thanks for the tips! An update: I've discovered that in Manual and Tv (shutter-priority) modes, continuous shooting mode gives a speed that is a smidgeon over 2 shots per second. I may use shutter-priority, but I note you say that in high-speed mode the initial settings & exposure apply - are you sure? (I don't have the manual for my IS-3, it's in a different country at the moment.) BTW I'll post some results shortly.

Help with a basic script...[]

Hi y'all, For the background to this script, read the conversation above on "Intervalometer granularity". Basically, I want to get my IS-3 to take 2 shots per second, and I thought the following script would do the trick. (First I switched the camera to shutter priority and I also switched on continuous (hi) shooting.) Now, if I keep the shutter button pressed, I get 2 shots per second (approx 21 in 10 seconds, actually). But if I run this script, I get around 1 shot per second. Since I'm not an expert uBasic programmer, there's probably something fundamentally wrong with my wee script here. Anyone care to enlighten me? Thanks!!

  rem Author Colm
  @title Infinite shooting
  @param a 

  @default a 0
     print "Photo", a, "taken"
     goto "interval"

You just need to put in a sleep command in there to pause the routine for the required amount. But you also have to take into account the camera's own overhead for file-saving and operation time along with the pause. You'll have to tweak it until you think it's just right.
(Sorry, I misread your question, see my correction ** to this advice below. I'm leaving my original reply intact so you can see how to use a sleep command for timing loops.)
It might look something like this:
rem Author Colm
@title Infinite shooting
@param a 

@default a 0
   print "Photo", a, "taken"

   rem change this sleep command for the number of 1000ths of a second pause
   sleep 1500
   rem that's 1.5 seconds

   goto "interval"
That's the simplest way, there's a new get_day_seconds command in Fingalo's (and others'?) build that could also be used for accuracy but the modification would take many more lines than just a simple sleep command.
You might also like to join the brand new CHDK Forum dedicated just for CHDK, there's a dedicated Script Writing and uBASIC section. It's much easier to follow the process for each script and to properly embed code and stuff. MUCH easier than using this Wikia discussion format. It works like any other forum you might have used online.
Correction **, I just reread your request. You'll never be able to get a speed faster than the camera's own high-speed continuous mode by using individual shutter-press commands in a loop. The speed you obtained was the fastest possible by using a looped script. Unless you write that script to engage your camera's high-speed continuous mode and hold the shutter down. (For an example see the OMNI Intervalometer script to see how that was done on the S3 IS for burst shooting at intervalometer intervals.)
To be explicit, use the "press shoot_full" command to start the high-speed continuous command. Use the get_tick_counts command to time it. Something like:
rem set d = duration in msec you want to take shots for (so, 1000 = 1 sec)
press "shoot_full"
if t<d then goto "loop1"
release "shoot_full"

Thanks for your help. (Forgive the stupid question, but when you told me about the CHDK uBasic forum, did you mean I should take this discussion to the forum? Please let me know, and thanks.) I've arrived at the following script based on your help, but it still doesn't work. The camera just dies... I switch on continuous shooting mode before running the script. But when I run it it just says, ***SCRIPT STARTED*** and then nothing happens.... all help gratefully received, and thank you, again.

@title Infinite shooting
@param a 
@param b
@param c
@param d
rem set d = duration in msec you want to take shots for (so, 1000 = 1 sec)
@default d 10000
press "shoot_full"
  if c<d then goto "loop"
release "shoot_full"
A couple of things: you must be using Fingalo's build, which has the "get_tick_count" command; it's not in the standard CHDK GrAnd versions.
Can you have a "param a" without the arguments? (I don't recall using them that way; usually they are followed by a text description of what the variable is). And you don't really need them (param a thru d), as it doesn't look like the user is changing them at run time. My suggestion is to delete them (or, if you later intend to have user-settable variables, for now just "rem" them out).
[mr. anon butts in] I recall GrAnd saying that you don't need to define the first 3 variables a, b, and c, but there is a menu option to change them as a default in the Script Menu. If you change them there they will be used in your script. So if you change variable a to 5, then that value would be used for a the first time it is called. Like that. He did it to simplify some simple scripts so you didn't have to type in everything, or ... I suspect it was a handy left-over from some of the earliest versions.
[divalent again] I just wondered if the "@param a" needs the "label" after it. I don't know if its optional or not (having not ever used it without a label, which tells the user what it is.) But, it looks like his first script ran okay without a label for param a, so that's probably not the answer to his problem. BTW, mr anon: just a huge WOW! on those high shutter speed images!
A good debuging technique it to add 'print "got here 1"', and 'print "got here 2"', etc commands between each statement of the program to see where gets too before it crashes.
I think the reference about the discussion forum is to this site: New CHDK discussion forum. It's kind of new, but there is a forum devoted to Scripting.
good luck

HDR shutter speed changes[]

rem Original Authors: Keoeeit & Chuck rem Modified For Night HDR shooting, -Sam @title HDR Night Shot Shutter Speed Auto @param b Interval (Seconds) @default b 20 @param d Initial Delay (Seconds) @default d 3 @param g ISO (-1=hi,0=auto,1=80,..,5=800) @default g 1



print "Night HDR Exposure shooting."

sleep d*1000

goto "shot"

 print "Shot number", n 
 set_iso g
 sleep t 

if t < 180000 then goto "shot"

What i'm trying to do is increase in intervals of 20 seconds each time a shot is done.

for instance first pass will shoot at 0 second shutter, then 20 second, then 40 second and so on. I have an S3 IS. sleep t changes the time between shots. can someone give me a hand?