CHDK Wiki
Line 58: Line 58:
   
 
Suggested format: "get_image_res x" and "set_image_res x"
 
Suggested format: "get_image_res x" and "set_image_res x"
  +
  +
:This is already available in Fingalo's builds, see this section of the tutorial page [[UBASIC/TutorialScratchpad#Fingalo.27s_Builds_2|Special Builds]]. And check out the tutorial discussion page as Divalent has already mapped out most of the values for the set_prop command.
   
 
== ability to get & set exposure compensation ==
 
== ability to get & set exposure compensation ==

Revision as of 22:37, 14 October 2007

Help: talk pages, talk page guidelines


This page is specifically for suggestions related to CHDK uBasic, either suggested new or modified uBasic script commands, or for sugggested CHDK-specific implimentations of the uBasic language.

The idea is to separate out these requests from other issues found in the (now overwhelming and somewhat stale) general suggestion page.

I've seeded this with some of my requests ( :) ), and I also reviewed the general suggestions page and carried over any such suggestions that others have posted. (If they were your suggestions, please feel free to edit them if I didn't quite make it clear what you wanted, and *please* delete them if you no longer desire those extensions).

If you'd like to post a *NEW* uBasic-specific suggestion, click the post a new comment button at the top of this page.

If you want to modify or comment on an *EXISTING* suggestion posted here, use the "EDIT" link next to that specific suggestion.

The ability to read the system time in a Script

I'd like the ability to get the system time. This would be extremely useful in the creation of an intervalometer script that remains accurate regardless of conditions. Moreover, it likely will be useful for other applications that either require precise timing or require knowledge of the time some event occurred (e.g., applications using the motion-detection version).

Currently intervalometer scripts use a sleep time, which doesn't account for the processing time for focusing, setting exposure, the exposure time, dark frame subtraction, etc., all of which can change from shot to shot (and at least in an S3 in P mode, is on the order of 1.5 secs under optimum conditions).

A suggested format: "get_sys_time x", where "x" returns as the time in whatever units the camera uses (msec, 0.1 msec, whatever!)

[This probably would be easy to implement, since it appears that there already is a C routine that deals with this variable.]

   UPDATE: I implemented this for my own use before I saw this page.
   Here is a patch file (to the grand branch, 2007-08-13) that implements
   'get_day_seconds x' - call it to put seconds elapsed since midnight
   into x.  README
   (That seems to be the best time resolution easily available...)
   Enjoy!  -- nickname-for-michael at-sign mcca dot be.
Mike: Very good! For intervalometer use this is great, since there likely no need to get any finer timing than that. However, could this easily be extended millisecond time resolution? I'm thinking that with the apparent ability of the motion detect version to respond in about 10 msec, it might be more generally useful if time could be resolved in msec. (The sleep function uses 1 msec resolution, so the program must be using a system variable that holds the time in those units) Thanks. -divalent [BTW, I saw your Hawaii t-lapse. Very Cool]
   Here you go - a revised patch. README.
   This adds 'get_tick_count x' to put the ms since camera startup
   into x.  By the way, here's that Hawaii sunset, for anyone interested. :) - Mike

ability to turn on/off darkframe subtraction

The ability to turn on/off darkframe subtraction in a script.

Suggested format: set_DF_off and set_DF_on.

  Update: Actually, since CHDK has this as a 3-state parameter
  (AUTO, OFF, or ON) it would probably be better have the command format
  be "set_df_sub x", where x is either 0,1,2 for AUTO, OFF, or ON.
  (and so the complimentary "get_df_sub" would be useful).

[This also likely would be easy to impliment, since CHDK already controls this function via the menu.]

ability to get & set image resolution

The ability to get and set the image resolution state. Like some other parameters (e.g., ISO) the ability to "press" buttons lets you change this setting, but only if you know what state it is in at the start.

Suggested format: "get_image_res x" and "set_image_res x"

This is already available in Fingalo's builds, see this section of the tutorial page Special Builds. And check out the tutorial discussion page as Divalent has already mapped out most of the values for the set_prop command.

ability to get & set exposure compensation

ability to set (and get) the exposure compensation (+/-)? [Question: are all Canon cameras like the S3, where your ability to adjust is in 1/3 stop units over the range of -2 to +2?]

Note: currently one can set the exposure compensation, and reset it back, using the press button commands only if you know the initial setting. (You can set it to anything regardless of the initial setting using the button press command by first driving it down to -2 by doing 12 button presses (which will put it in a known state regardless of where it starts at, but in that situation, you won't be able to return it to where it was).

Suggested format "get_ex_comp x" and "set_ex_comp x", where x=0 is normal, and +/- 1 is up or down 1/3 stop, +/1 = 2/3 stop, etc. (i.e., the range of the variable x will be from -6 to +6, corresponding to -2 to +2 stops)

ability to set sharpness, saturation & contrast.

ability to set Sharpness, Saturation and Contrast in a script.

Similar to parameters like Exposure compensation, ISO, etc. The format of such commands would probably best be similar (e/g/. "get/set_contrast x")

(suggested by another user previously in the general suggestion page)

ability to read the battery voltage

ability to read the battery voltage (or % battery remaining?)

This was suggested by another user in the general suggestion page.

Suggested format: "get_battery_volts x" where x is the voltage in mV (although for most purposes the %battery remaining parameter that CHDK already calculates for the battery display would probably be sufficient)

Update: The StereoData Maker version has this function:

get_bat_volts (x1000)

Ability to delete images

[This was suggested by another user in the general suggestion page.]

A set of extensions that would allow file deletion. As the person who requested this points out, unless you can enter playback mode, the "erase" button doesn't work for that function. He/she suggested having either a command to switch between recording to playback modes, or a delete command with a variable that would specify deletion of the most recent image.

Suggested format: "fdel x" where x = 0 to delete the most recent image, and -1,-2,etc to delete previous images) or a prior image (variable = 1 for immediately preceeding image, etc)

IF//THEN//ELSE//ENDIF

[This was suggested by another user in the general suggestion page.]

IF//THEN//ELSE//ENDIF would allow a more convienent and more transparent way to code some proceedures. The currently IF/THEN/ELSE construct does not permit more than one basic command for the THEN and ELSE alternatives. If more than one command is needed, you typically will have to use gosubs to subroutines as the THEN/ELSE alternatives, which has the disadvantage of moving those lines of code elsewhere in the program file.

Special script-exit routine?

Currently, when a script is terminated by the user by pressing the Shutter button, the camera just stops. Would it be possible for uBasic to instead jump to a special subroutine in the script?

Ideally, the script should have the ability to restore any camera settings that were changed by the script (Iso, exposure compensation, image resolution, etc). And if script terminates on its own (due to time or completion of its tasks) this is easily done in the script.

However, the user can also terminate a script by hitting the shutter button, and in that case the script is unable to restore anything.

One way this might be implimented is to have the routine that detects the shutter button first check to see if there is a special label in the script with an unusual name (such as ":terminate_restore_and_end") and if there is one, then instead of doing what it now does, it instead jumps to that location so that the commands that follow it are executed. [If there is no such label, then it does what it just does what it does now to terminate the program.]

Script-writers can then include such a routine (with that exact name) as a standard exit routine in all scripts.

Commands to control the LEDs

Microfunguy, a poster at DPReview, created uBasic commands to control the camera LED's for the StereoData Maker version. Other posters noted that these functions would be generally useful.

"I have created some script commands to control the camera LED's :-

 af_led_on 
 blue_led_on 
 yellow_led_on 
 green_led_on 
 amber_led_on

"

There are complimentary commands to turn them off: e.g., af_led_off

Command: shoot_df or just dark_frame

A command to shoot/record a dark-frame only. Very useful for lengthy intervalometer sessions for lightning and astrophotography. Where dark-frame subtraction would normally be turned off to decrease lags between frames, but still needed for manual dark-frame subtraction in post-processing. Scripts could call this command at a set interval or set number of exposures to make sure you can reduce sensor noise on your own without having to disturb the camera, as what would happen when you cap the lens manually every so often for a required dark-frame.

Ability to turn ON and OFF raw image acquisition

Okay, my problem is that I don't use raw images, but somehow I occassionally activate it inadvertantly (perhaps because its the first option you get in the CHDK menu and so its easy to change accidentally with a stray button push).

Anyway, I do a lot of intervalometer scripts taking sometimes hundreds of shots in a sequence (and then I do it all again) and I typically will use 640 x 480 to limit space (and since I assemble them into movies, 640x480 is fine). Unfortunately, if you accidentally activate RAW mode, you can't take very many photos before you run out of room. (It happened today, for the 3rd time in 3 weeks. Okay, so I'm an idiot!) :)

So *my* reasons for wanting this is be sure my intervalometer sessions don't inadvertantly use RAW. However, other folks may want to activate RAW mode (and be sure that they did) and I suppose there might be situations where you might want to switch during the script (not that I can think of any such situations at the moment; any help, folks?).

OTOH, since it is a setting that CHDK currently can change via the menu, it should be pretty easy impliment.

Suggested format: "raw_off" and "raw_on"

[The irony that I want a script command to be sure I can defeat the main raison detre for the CHDK hack is not lost on me.  :) ]

Fingalo has done this as well! See his build (link on front page)

A feature choosing GUI build-maker.

I just tried following the convoluted and confusing discussions at dpreview. I gave up trying to even find the download links for which camera let alone which build has the features I need and want. I can understand the pride everyone is taking in their builds of CHDK, but quite frankly I have zero use for the stereo-data-maker routines. In fact they only slow down CHDK to make some of my favorite features severely crippled. Not to mention making any scripts written for the SDM version TOTALLY incompatible with any of the more standard versions of CHDK. What a mess.

Can anyone make a simple windows GUI interface where you can just load up the latest source file additions that you want, then make a list of selection boxes of the uBASIC features and CHDK features you want, and it will automatically compile them for you for your make and model of camera?

I want the new uBASIC commands that Fingalo has provided, but he left out the LED commands that I need. I want the motion detection option, but I have zero use for all that stereo data maker stuff. Maybe there should just be a Wiki page where we can all vote on the features we want, but more importantly the features we DON'T want that would only slow down CHDK. Then someone could provide builds based on those.

Due to the build-makers this is turning into a huge mess that I don't even want to help with anymore on these Wiki pages.