CHDK Wiki
Register
 
(29 intermediate revisions by 8 users not shown)
Line 25: Line 25:
 
A suggested format: "get_sys_time x", where "x" returns as the time in whatever units the camera uses (msec, 0.1 msec, whatever!)
 
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 impliment, since it appears that there already is a C routine that deals with this variable.]
+
[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.
  +
[http://bostoncoop.net/~mike/CHDK_get_day_seconds.patch 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. [http://bostoncoop.net/~mike/README_CHDK_get_day_seconds.txt 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 - [http://bostoncoop.net/~mike/CHDK_new_time_commands.patch a revised patch]. [http://bostoncoop.net/~mike/README_CHDK_new_time_commands.txt README].
  +
This adds 'get_tick_count x' to put the ms since camera startup
  +
into x. By the way, [http://www.archive.org/details/HaleakalaSunset here's that Hawaii sunset], for anyone interested. :) - Mike
   
 
== ability to turn on/off darkframe subtraction ==
 
== ability to turn on/off darkframe subtraction ==
Line 45: 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]] using the set_prop command. See this section at the Scripting Tutorial Discussion page [[Talk:UBASIC/TutorialScratchpad#Property_Case_values._A_working_exploration_section|<u>'''here'''</u>]].
   
 
== ability to get & set exposure compensation ==
 
== ability to get & set exposure compensation ==
Line 53: Line 68:
   
 
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)
 
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)
  +
  +
:This is already available in Fingalo's builds, see this section of the tutorial page [[UBASIC/TutorialScratchpad#Fingalo.27s_Builds_2|Special Builds]]. You can use the set_prop command in his builds. See this section at the Scripting Tutorial Discussion page [[Talk:UBASIC/TutorialScratchpad#Property_Case_values._A_working_exploration_section|<u>'''here'''</u>]]. (But now that I'm reading these suggestions it might actually be nicer to have them with more descriptive labels. than just a property-value ID numbers.)
   
 
== ability to set sharpness, saturation & contrast. ==
 
== ability to set sharpness, saturation & contrast. ==
Line 61: Line 78:
   
 
(suggested by another user previously in the general suggestion page)
 
(suggested by another user previously in the general suggestion page)
  +
  +
:These are reachable through Fingalo's builds with the set_prop command. See this section at the Scripting Tutorial Discussion page [[Talk:UBASIC/TutorialScratchpad#Property_Case_values._A_working_exploration_section|<u>'''here'''</u>]]. The information to change these parameters is there.
   
 
== ability to read the battery voltage ==
 
== ability to read the battery voltage ==
Line 73: Line 92:
   
 
get_bat_volts (x1000)
 
get_bat_volts (x1000)
  +
  +
Also available in Fingaolo's build as '''get_vbatt"
  +
  +
See: [[UBASIC/TutorialScratchpad#Special_Build_Commands_2|Scripting Tutorial, Special Builds]] for these and more additions to these two great versions of CHDK.
   
 
== Ability to delete images ==
 
== Ability to delete images ==
Line 87: Line 110:
   
 
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.
 
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.
  +
  +
:See [[UBASIC/TutorialScratchpad#Special_Build_Commands|Special Builds]] in the scripting tutorial.
   
 
== Special script-exit routine? ==
 
== Special script-exit routine? ==
Line 99: Line 124:
   
 
Script-writers can then include such a routine (with that exact name) as a standard exit routine in all scripts.
 
Script-writers can then include such a routine (with that exact name) as a standard exit routine in all scripts.
  +
  +
:Would be nice to have, but that's part of the responsibility of the script author, to clean up the mess they made before leaving their script. :-) I worry about too many functions being added to CHDK itself, because the more that is added to CHDK only slows down its performance for high-speed shooting and response times. My 2-bits on the subject.
  +
:If you study some of the more complex scripts you'll see that initial camera settings are read into variables, those variables are then used at the end to set things back to the way things were. Or if any options are selected through menu clicks, then those menu clicks are applied in reverse on exiting. These are normal script authoring responsibilities.
  +
::Yes, but the problem is that if the script is terminated by hitting the shutter button before its natural end, everything is left in the state the script set it to. I'm assuming the script *would* have a "clean-up/restore" routine, but the issue is to ensure it *always* gets executed regardless of how the script ends. (maybe the easier solution is to not use the shutter to prematurely terminate, but instead have a script-detected special button, like flash on an S3).
  +
:::'''[soapbox]''' No, that wouldn't do. I used that button to enter and exit <ALT> mode. If you exit <ALT> mode with the toggle for it while a script is running then it doesn't just end a script, it puts the script into a pause mode, so you can change things to camera settings, review photos, do whatever you want. Then enter the <ALT> mode to pick up in the script right where you left off. I still feel that it's my responsibility as a script writer to put things back they way they were before the script ran. And if I exit a script prematurely then I am making that conscious decision to take responsibility for having to reset my camera features manually to where I want them to be. If you accidently or intentionally unplug your computer do you expect it to pick up where you left off? I don't, in fact I never even use that feature in computers (hibernation modes), I can't stand the time delays and hard-drive space those resume-failsafes take up. Bloated overhead. I'm of the mindset that if I don't use CHDK scripts right then it's my fault. Though, I must admit, with the complexities of that new set_prop command a "reset" could have its value.
  +
:::I am reminded of the editing program PhotoLine 32 (bear with in my explanation). This is an amazing editing program and just this year I found out that you can, with the right knowledge, configure it to the depth where you can almost rewrite the whole GUI interface just by using its various configuration files! (Not unlike Opera browser.) Woah, amazing! BUT, you <u>must</u> know what you are doing, and how to do it. It's not easy. If you don't do it right you can break things! This keeps the casual user from goofing things up. Only smarter people will go in there to change things, the complexity becomes a self-protection feature. Making things "user friendly" is not always a good thing. Look what happened to the internet when the flood-gates were opened up to anyone with a computer? My analogy, if you make the set_prop command too easy to use with a simple reset_props command, then royal idiots are going to be writing scripts using that mode, breaking things and then complaining why it didn't work and can we all help them fix what they broke, etc.. It might be best to reserve the set_prop feature for those that know what they are doing by not making it too easy for them to reset things. Programming can go beyond programming, sometimes you have to take into account the very aspects of humans first. That's why I vote against it, not only the programming overhead that would slow down CHDK even more. (You should compare speeds with earlier versions like build 119, or even earlier. You'll be amazed.) The motion detect feature already was a huge hit to script execution speed. How much slower do you want to make CHDK by adding features that aren't really needed? It's a balancing act. I'm the kind that values speed efficiency and eloquence in programming every time over easy and pretty. I wonder too, where is CHDK taking memory from? The camera's buffer right? Every time more code is added it detracts from the use of that for taking pictures as well as slowing down the camera. There's a reason Canon put in that much buffer memory by those that demand better performance. As a wildlife photographer who frequently uses burst modes I use up all of the buffer on nearly every bird-in-flight shot attempt. It's the same reason I buy the highest speed SD cards so it won't slow down needed features. There's lots going on in this CHDK balancing act. Adding even more CHDK script commands can ruin the reason I bought the camera in the first place. There's lots of reasons I'd vote against this feature, and urge CHDK authors to not pursue it, unless it can be done in a way that won't make things worse. '''[/soapbox]'''
   
 
== Commands to control the LEDs ==
 
== Commands to control the LEDs ==
Line 113: Line 144:
   
 
There are complimentary commands to turn them off: e.g., af_led_off
 
There are complimentary commands to turn them off: e.g., af_led_off
  +
  +
:See the [[UBASIC/TutorialScratchpad#Special_Build_Commands_2|Scripting Tutorial - Special Builds]] section.
   
 
== Command: shoot_df or just dark_frame ==
 
== Command: shoot_df or just dark_frame ==
Line 132: Line 165:
 
[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. :) ]
 
[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. ==
 
  +
  +
== Command to open/close shutter ==
  +
  +
Right now it seems that images can be taken only using the "shoot" command which opens and then closes the shutter. It would be nice to be able to open and close the shutter manually. The application that I have in mind is with a remote trigger; I'd like to be able to leave the shutter open for a while and then close it when the remote trigger button is pressed. Is this possible?
   
  +
Thanks,
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.
 
   
  +
Vinay
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.
 
   
  +
[[Special:Contributions/128.119.50.107|128.119.50.107]] 18:41, April 21, 2011 (UTC)
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.
 

Latest revision as of 18:41, 21 April 2011

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 using the set_prop command. See this section at the Scripting Tutorial Discussion page here.

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)

This is already available in Fingalo's builds, see this section of the tutorial page Special Builds. You can use the set_prop command in his builds. See this section at the Scripting Tutorial Discussion page here. (But now that I'm reading these suggestions it might actually be nicer to have them with more descriptive labels. than just a property-value ID numbers.)

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)

These are reachable through Fingalo's builds with the set_prop command. See this section at the Scripting Tutorial Discussion page here. The information to change these parameters is there.

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)

Also available in Fingaolo's build as get_vbatt"

See: Scripting Tutorial, Special Builds for these and more additions to these two great versions of CHDK.

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.

See Special Builds in the scripting tutorial.

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.

Would be nice to have, but that's part of the responsibility of the script author, to clean up the mess they made before leaving their script. :-) I worry about too many functions being added to CHDK itself, because the more that is added to CHDK only slows down its performance for high-speed shooting and response times. My 2-bits on the subject.
If you study some of the more complex scripts you'll see that initial camera settings are read into variables, those variables are then used at the end to set things back to the way things were. Or if any options are selected through menu clicks, then those menu clicks are applied in reverse on exiting. These are normal script authoring responsibilities.
Yes, but the problem is that if the script is terminated by hitting the shutter button before its natural end, everything is left in the state the script set it to. I'm assuming the script *would* have a "clean-up/restore" routine, but the issue is to ensure it *always* gets executed regardless of how the script ends. (maybe the easier solution is to not use the shutter to prematurely terminate, but instead have a script-detected special button, like flash on an S3).
[soapbox] No, that wouldn't do. I used that button to enter and exit <ALT> mode. If you exit <ALT> mode with the toggle for it while a script is running then it doesn't just end a script, it puts the script into a pause mode, so you can change things to camera settings, review photos, do whatever you want. Then enter the <ALT> mode to pick up in the script right where you left off. I still feel that it's my responsibility as a script writer to put things back they way they were before the script ran. And if I exit a script prematurely then I am making that conscious decision to take responsibility for having to reset my camera features manually to where I want them to be. If you accidently or intentionally unplug your computer do you expect it to pick up where you left off? I don't, in fact I never even use that feature in computers (hibernation modes), I can't stand the time delays and hard-drive space those resume-failsafes take up. Bloated overhead. I'm of the mindset that if I don't use CHDK scripts right then it's my fault. Though, I must admit, with the complexities of that new set_prop command a "reset" could have its value.
I am reminded of the editing program PhotoLine 32 (bear with in my explanation). This is an amazing editing program and just this year I found out that you can, with the right knowledge, configure it to the depth where you can almost rewrite the whole GUI interface just by using its various configuration files! (Not unlike Opera browser.) Woah, amazing! BUT, you must know what you are doing, and how to do it. It's not easy. If you don't do it right you can break things! This keeps the casual user from goofing things up. Only smarter people will go in there to change things, the complexity becomes a self-protection feature. Making things "user friendly" is not always a good thing. Look what happened to the internet when the flood-gates were opened up to anyone with a computer? My analogy, if you make the set_prop command too easy to use with a simple reset_props command, then royal idiots are going to be writing scripts using that mode, breaking things and then complaining why it didn't work and can we all help them fix what they broke, etc.. It might be best to reserve the set_prop feature for those that know what they are doing by not making it too easy for them to reset things. Programming can go beyond programming, sometimes you have to take into account the very aspects of humans first. That's why I vote against it, not only the programming overhead that would slow down CHDK even more. (You should compare speeds with earlier versions like build 119, or even earlier. You'll be amazed.) The motion detect feature already was a huge hit to script execution speed. How much slower do you want to make CHDK by adding features that aren't really needed? It's a balancing act. I'm the kind that values speed efficiency and eloquence in programming every time over easy and pretty. I wonder too, where is CHDK taking memory from? The camera's buffer right? Every time more code is added it detracts from the use of that for taking pictures as well as slowing down the camera. There's a reason Canon put in that much buffer memory by those that demand better performance. As a wildlife photographer who frequently uses burst modes I use up all of the buffer on nearly every bird-in-flight shot attempt. It's the same reason I buy the highest speed SD cards so it won't slow down needed features. There's lots going on in this CHDK balancing act. Adding even more CHDK script commands can ruin the reason I bought the camera in the first place. There's lots of reasons I'd vote against this feature, and urge CHDK authors to not pursue it, unless it can be done in a way that won't make things worse. [/soapbox]

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

See the Scripting Tutorial - Special Builds section.

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)

Command to open/close shutter

Right now it seems that images can be taken only using the "shoot" command which opens and then closes the shutter. It would be nice to be able to open and close the shutter manually. The application that I have in mind is with a remote trigger; I'd like to be able to leave the shutter open for a while and then close it when the remote trigger button is pressed. Is this possible?

Thanks,

Vinay


128.119.50.107 18:41, April 21, 2011 (UTC)