Wikia

CHDK Wiki

Talk:UBASIC/TutorialScratchpad

565pages on
this wiki

Back to page | < Talk:UBASIC

Revision as of 21:21, February 26, 2012 by SkepticaLee (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Help: talk pages, talk page guidelines


Av&Tv Commands Edit

These are very handy commands!
Now if we only could read out in "M" mode what the cam thinks are the best settings for Av and Tv, we could make a script where the right values are automatically set for us. Since discovering CHDK I use "M" mode so much because fixed aperture and time values are great if you use the histogram to get the optimal exposure. But it really bugs me that I have to try so much to get the right exposure, because the cam only gives me a value from -2 to +2, but not the correct exposure right away. --Harvester 19:26, 17 May 2007 (UTC)

Not sure if you are still interested in getting your original problem solved, but one possibility (it's somewhat manual), is to have the script tell the user to switch to P=mode. Using prop_case you can detect when that occurs (property 0), then do a press "shoot_half", wait till 205 goes to 1, and then read the Av and Tv. Then tell the user you got it, and to return to M mode (script checks prop 0 to confirm) and then proceed. Divalent Oct 24, 07.
Nice to see you guys finding those values for the these commands found in the source code (I'm still not sure about the MOD and CALL ones though, no reply to my questions about them on the main uBASIC talk page). I put the first list of values you people found in a table, because I couldn't see it properly formatted in my browswer. Then I checked into more Wiki formatting commands (found another nice total list here How to edit a page, and couldn't get the monospace (typewriter/tt) fonts working on my browser. Come to find out I had replaced that font in my settings. Oooops. Now the pre-formatted text shows up just fine. Should I undo the table I made or just leave it in case others can't display a monospace font properly?
Keoeeit 00:21, 18 May 2007 (UTC)
MOD is just the name of reminder (%). CALL is not used at all. -- GrAnd 07:52, 19 May 2007 (UTC)
Regarding the table: I think both formats are okay. Perhaps I like the shorter format a little bit more and you can copy&paste it better into a text file, so I changed it back (if it is okay for you). --Harvester 08:17, 19 May 2007 (UTC)
re: MOD & CALL, thanks GrAnd. I kind of thought that's what the MOD was for but wasn't sure. I'll try to not add any "call" commands to my scripts too. :-) Then again ... a print "Call 1-800-BUY-CHDK" as a subliminal ad in every 15th intervalometer shot might work. :-)
re: Table, yep, looks much nicer. The more I saw that blunder the more I saw the blunder by trying a table to fix a font problem on my end. If nothing else, I learned lots of cool stuff about making tables in Wiki-speak. :-)

Manual focus button on S3 IS Edit

Any chance of the manual focus button on the S3 IS getting a command? It is very hard to keep the camera absolutely still while holding down the MF button. 207.216.12.82 18:51, 18 May 2007 (UTC)

I see this functionality has been added through the addition of the press/release option and the mf button. Thank you, that was fast. I will credit your software when user. HighInBC 00:35, 9 June 2007 (UTC) (was 207.216.12.82)

Operations order Edit

Keoeeit, you said:

Normally we assume that operations such as * and / will be performed before any + and - operations. This is not the case in this uBASIC. You will have to be careful on what order you put your math operations.

Do you have the example in which you got the incorrect result? I've tested a lot of variants of combinations of math operations and as for me they work absolutely correctly.
FYI... Order of operations
--GrAnd 12:18, 19 May 2007 (UTC)

Well, I don't have any examples anymore. You fixed what was causing the problem. :-) I was having a rough time trying to sort out a way to get those math expressions to work in a Print statement. And that's what lead to my belief that there was a problem with the math operation hierarchy. And yes, I realized after I wrote which came first + - or * / that I had them backwards, but wasn't quite sure. Math class was over 30 years ago. I've devoted those brain-cells to new things since then. :-) (Or lost them along the way, which always raises an interesting question, how can the brain know when it has brain-damage? Paradox. :-) )
I'll check the tutorial math section and remove that portion that warns of math operation disorder now. And I could simplify my intervalometer script now too, now that the print + math commands is fixed. I really should add in a complete "total time =" command figuring in shutter-speed too, now that the get_tv values are known, but it might be a tight fit to get that all under 2K with a shutter-speed table. I wonder if there's a simple way to compute shutter speed directly from the tv value?
What might be handy is if we start a bank of commonly used subroutines that anyone could just dump into a program, shutter-speeds computed from get_tv might be a good one for that. Ex: my count-down timer subroutine in the Ultra-Intervalometer script might come in handy for others. Keoeeit 14:53, 20 May 2007 (UTC)

Logic Expressions Edit

I'd like to add a section in the tutorial on how to use the &, |, and ^ (and, or, xor) commands, but I'm not quite sure I could do it properly. (My BASIC being pretty rusty.)

But for the sake of argument, can these commands be used in situations like:

if a=1 & b=1 then gosub "both_must_be_true"
if a=1 | b=1 then gosub "any_are_true"
if a=1 ^ b=1 then gosub "only_one_is_true"

And can these be used in more elaborate truth conditions, such as:

if a=1 & (b=3 | c=2) ^ d=1 then z=3 & y=5 else gosub "subroutine"

???

And do these also have an operation hierarchy? (priority of operation)

Keoeeit 14:52, 20 May 2007 (UTC)

These operations (and, or, xor) are not logic. They are binary. --GrAnd 15:09, 20 May 2007 (UTC)

IAQ - Infrequently Asked Questions  :-) Edit

Is there (or will there be) any way that a script could detect which camera model it is being ran on? I'd like to modify the Ultra Intervalometer script to have one more toggle so it would engage single-frame shooting or video mode (now that the S cameras have those commands), but it would be nice if when that is engaged it would go to the proper subroutine per camera model to engage video mode.

With something like:

if i=1 then gosub "axvideo" else shoot
if j=1 then gosub "sxvideo" else shoot

Then again, if there's no way to detect camera model, there could be one user-value set as 0, 1, or 2, for single-frame, A-series Video, or S-series Video, or would that be too confusing for the end user?

I wonder if one more subroutine to trigger the camera's own timer would be overkill and redundant? So many possibilities to play with now! (Plus the discipline of trying to keep it all under 2K.) Keoeeit 06:19, 27 May 2007 (UTC)

How about putting the scripts in Categories like: Generic, A-series specific, S-series specific? (btw: thank you for checking the whole wiki for the new changes. Good work!) --Harvester 09:06, 27 May 2007 (UTC)
re: Categories by camera series -- Not sure how that would pan out in the future, with so many cameras supported, each having their own unique interface, etc. Hard to say what would be the best tack to take on it. Not a lot of people are submitting new scripting code either (yet), so I don't know if putting them by series on their own Wiki pages or what, would be the best route. I think this is one of those "time will tell" thingies. I'll eventually add in the video toggle for the Ultra Intervalometer script, but the more I thought about, I realized I'm limited to 10 user definable variables too. (single letters at that, I'm running out of variables) I already used up 7 of them. :-) Now add in a Video toggle and I have to add script to set the duration for video too. There's 2 more user variables. 10 shot to hell already. Then I thought, I'd really like if if you had the option to take a full-frame shot before or after each video sequence as a documenting mode, as yet another option. Ooops, that's 11 variables. I'll think of sumpin! :-)
re: the S-series <ALT> button edits, I think I found them all, but if you spot one I missed feel free to change it. Keoeeit 04:07, 28 May 2007 (UTC)

Super quick question I couldn't find an answer to: how do you go back to the default script? Should I create a blank script with no functionality? Hope this is the best place to post this... --24.89.200.199 19:30, 12 September 2007 (UTC)

Camera Operation Commands Edit

I think the section "Camera Operation Commands" could need some differentiation, like this:

  • commands (shoot, click, press, release)
  • the other "thing" behind the command... the buttons... you know what I mean (left, right, menu, display etc.) --Harvester 14:43, 2 June 2007 (UTC)
Let me know if doing it the way I did was clear enough, if not and something seems confusing, or I shouldn't have used those button graphics in the opening section, feel free to clean it up. My theory is always provide too much information than too little and let the receiver filter out what they need, rather than letting them guess on what wasn't said. As for the commands, some of the buttons should never need to use the press/release sequences (like erase, menu, set, etc.), even though press and release can be used with them (I presume). Since I'm not familiar with cameras other than the S3, I don't know what creative ways some might find for using them. So I prefaced them all with the click/press/release options. I now await the influx of amazing new scripts that everyone is going to share. (ya think? :-) ) Last night I got home late from a 16 hour fishing trip on my mountain bike, and rode the last 8 miles home in the dark on muddy dirt roads in pouring rain (4-lb bass on ice in saddle-bag), so the best I could do when I discovered the new press/release commands last night was update the "Focus Bracketing" script and test it on the S3, worked fantastic! (then I passed out and woke up 9 hours later) You have an A-series camera, correct? Can you modify or test that script and either add a confirmation note or add an A-series script if the one that I have up does not work on A-series? Keoeeit 18:57, 2 June 2007 (UTC)

Dark-frame Subtraction not ALWAYS at <=1.3 seconds! Edit

I found out something interesting tonight, and I wasn't sure where to post this, but it could influence a lot of scripts that might already be or will be written.

I was fooling around trying to find out the best ways to implement some button commands on my S3 IS, which meant I was really putting the camera through its paces with all sorts of things. At one point one of my scripts goofed up using a press "zoom_in" ... shoot sequence when I found out it was far far better to use a sleep delay with a press/release zoom_in command than a click "zoom_in" command. The interesting thing was that I actually got one photo to take a shot DURING a zoom, creating an honest-to-goshes zoom-blur image! I couldn't replicate this in a stand-alone script, but this is beside the point..

Anyway, I later went to go put some tweaks on the Lightning Photography script for the S3 IS, trying to make it even nicer, having it use a press "mf" / sleep-x / release "mf" command to set the camera to infinity focus. After a few times of running that script i noticed that my 1-second frame rate got SLOWWWWW... and I was getting the typical "busy" in the view-finder for a dark-frame subtraction taking place. Uh oh, I thought maybe I found the very first occurrence of CHDK goofing up my firmware. It was doing dark-frame subtractions all the way up to 1/6th of a second! Only when I put it to 1/8th of a second would the dark-frame routine cease.

I went to go find another SD card without CHDK on it, I even removed the little button battery to reset my camera's firmware. Then I was able to get 1/6th seconds without a dark-frame. I thought, awwww $#|T, I bet I busted something, oh well, the rest of everything works just fine. Then I got the idea of something ... I opened up the LCD display on the back and felt the back of the camera, it was VERY warm from all I was doing with it. I wondered .... could Canon be so smart as to increase the dark-frame subtraction as more thermal energy was causing more noise???

I let the camera set a while to cool down. I have my no-dark-frame-subtraction back again at 1-second shutter speeds. Too much heat from over-use (or leaving it in a warm place) will cause your dark-frame routine to kick in at higher shutter speeds! I wonder, if you put your camera in the fridge for a bit if you could get dark-frame-free exposures at shutter speeds even lower than 1.3 seconds? I may test this. What a boon that would be to astrophotography in the winter months! (I wonder how cold the camera would have to be to have no dark-frame subtraction at 15 seconds. :-) )

So, I didn't know where to post this anecdote and findings. I discovered a lot about the script commands as well as the dark-frame routines tonight. Perhaps someone can say this in a more concise way and post it where others might see it. Maybe put in a note that if running lengthy scripts where you need no dark-frame-subtraction to kick-in, to open up your LCD panel on the back (un-lit) so the camera body can keep cooler.

p.s. I found it's much better to use a press/sleep-x/release "timer" sequence than a click "timer" command. Less chance of the command not getting implemented while the camera is busy setting exposure and stuff. So those press/release commands are going to come in more handy than I first thought. The press "zoom_in/out", sleep-x, release "zoom_in/out" is another good way to use them, MUCH faster than a for/click "zoom_in"/next loops! Keoeeit 11:54, 6 June 2007 (UTC)

Yes. I heard that Canon uses thermistor to measure sensor temperature to make a desision on dark-frame substraction. This mechanism exists in my A610 as well (the minimum Tv is the same - 1/6th). In the same time if Tv >= 1.3s the dark-frame substraction is always performed. So, you can't avoid the dark-frame substraction at 15 seconds even if you put your camera into a freezing room. :) --GrAnd 13:36, 6 June 2007 (UTC)
Ah, thanks for confirming what I observed and the further info on it. This will save me from putting my camera in the deep-freeze in a desperate attempt to get rid of the dark-frame routine. Or tying a block of dry-ice on top of the camera. :-) You would think they could mention this in the manuals or something. It was a bit disconcerting at first. If I notice a good place to mention it in the main Wiki scripting info I'll do that since it's not documented elsewhere. I notice you just updated CHDK, I have to go grab my copy and check it out. Thanks-again for the info! (AND CHDK!!) :-) Keoeeit 21:50, 6 June 2007 (UTC)
Very interesting, thanks for the S3 IS info. HighInBC 14:10, 11 June 2007 (UTC)

Deterministic ISO settings Edit

Is there a reliable method to set the ISO to a deterministic value?

I want to initialize as many settings as I can to specific values in the beginning of my script. The only way I've found to set the iso value is by click'ing the 'ISO' button, and since it rolls over, you can only set it relative to the initial value. (for instance, if the ISO began at 100, if you click 5 times, you get back to 100 (100->200->400->800->80->100...)) But I haven't found a way to guarantee I have it set to 80.

Poking around in the source code, there are tables defined for the shutter speeds, aperture and ISO values. There are set_tv and set_av to set the shutter and aperture, but no equivalent for setting ISO. Is a 'set_iso' operation possible/in the works?

An alternate possible approach would be to use some sort of 'reset' operation to reset everything to some known default value, and then go through and set everything to the desired settings.

Any suggestions?

CHDK is great! Thanks!

there is now a set_iso command

Get_Focus X? Edit

This request is now obsolete due to Build 125. :-) but I'll leave it in for the info about the S3's [SET] button + MF feature, someone might make use of that some day.

GrAnd? I read somewhere that it is easy for you to read the manual focus position but not set it. Would it be possible for you to implement a simple get_focus command. With this I can see all kinds of ways where a near-exact focus distance could be set. For example, in the S3 IS camera it could be done with:

rem set manual focus to nearest possible on S3 IS

press "mf"
press "down"
rem 8 seconds is needed for full manual focus travel at highest zoom setting
sleep 8000
release "down"

rem Going to set manual focus to 1256 mm

:coarsefocus
 get_focus x
 if x>1200 goto "finefocus"

 rem increment the manual focus a bit each time it loops

 press "up"
 sleep 10
 release "up"
 goto "coarsefocus"

rem Fine-focus routine

:finefocus
 get_focus x
 if x>1255 then goto "shootpic"
 click "set"
 sleep 100
 goto "finefocus"

:shootpic
 whatever code you want after focus is very very close

The sleep commands would have to be tested, but as long as you can detect what the focus position is, then it's possible to stop the manual focus position where it needs to be. In the S3 IS in MF mode you can press the [SET] button for fine-tuning manual focus, and it always works from near to far (in micro-increments) until it locks on something with high contrast. This is how you could emulate a fine-focus mode. Keoeeit 19:26, 11 June 2007 (UTC)

Consolidate the original Syntax & Tutorial Pages? Edit

When this all started out, and GrAnd put together the preliminary pages for us to get this rolling, I started this "Tutorial Scratchpad" page (because I didn't know what I was doing yet/still :-) ) with the idea that sections of this scratchpad page could be eventually copied and pasted to GrAnd's original uBASIC Syntax page. Well, it seems that it just got easier and easier to add on to this one by me and everyone else. I still like the way GrAnd described some things so I thought his page should always stay. But I think it's getting to that point where his original page should be consolidated into this one (or vice-versa), and the final page renamed to, perhaps, just "Script Tutorial", or "CHDK uBASIC Scripting" or something like that, or ... I don't know, whatever would be the most correct title to use. And would this require putting it all in a new Wiki page with the right path-name in it? Or can a Wiki page/path be renamed?

So, would anyone like to take a stab at how to do all this? I'm wondering if GrAnd's page could be put in as a header section where the "Starting Out" info was put. His shorter summation of the commands available with the the rest of the tutorial following. As well as taking his script examples and peppering them in places where they might be the most applicable.

Comments? Suggestions? Is this needed or not? Anyone want to step up to the plate and do it? :-) Keoeeit 16:37, 12 June 2007 (UTC)

set_zoom problem Edit

This is odd, because it was working before. I would use the script:

set_zoom_speed 50
set_zoom 61
end

to set the zoom to a specific point for a shot I wanted. It worked, several times.

Now when I do it, the camera goes to the correct zoom level and automatically stops. I read about how this can happen with a zoom speed of 5 or less. But I tried 100, 50, and 10 with the same results.

Could there be another explanation to the behaviour? It would be my HDR mosaic photography if I could instantly set my ISO, Av, zoom, and focus. But I just can't get past the zoom setting. HighInBC 22:35, 30 June 2007 (UTC)

BATTERY VOLTAGE Edit

Can I use a command to read the battery volage and then perform another command depending on the voltage or voltage change?

This has been added by Microfunguy's SDM, and Fingaolo's special builds. See the Scripting Tutorial in the Camera Commands, Special Builds sections.

Motion Detection Version? Edit

I asked some questions about it in another spot in this Wiki. I'm not sure if it will be seen there so posting a link to that question here: Motion Detection, add to the Tutorial?

Situation resolved. :-)

Access to Real time clock? Edit

Is there a function to retrieve the internal real time clock value?

In attempting to deal with the timing of intervalometer scripts, it seems like so many factors can affect the overall interval time. The sleep function used to space the interval needs to at least estimate what the those other things are (exposure time, time to set focus, time to determine exposure, writing to card, dark frame subtraction time, etc).

All of this guesswork and mode- and conditions-specific variability could be ignored if the script could fetch the RT clock value, and just shoot at the appropriate time.

If there is not such a function, could I get it onto the wish list? Something that returns an integer equal to the time of day (in msec, or whatever units the camera uses).

Thanks, Divalent

Fingalo has a build (currently just a special secret build) that incorporates this feature. format is x=get_tick_count, where value returned is time in msec (since camera bootup). (hopefully it will get into general circulation)

ERASE COMMAND, and other problems Edit

hi, if recently, 3 days ago, came across CHDK....... and i love it . thats why i decide to give an comment here.... most of the scripts wont work if u not put the cam in a certain situation(condition).... one of the most common faults i found is the use of the erase command... if this is used and in the config the raw shots are enabled the cam is getting totally confused and crashes... HOW to prevent this ... what makes me suspioues that I couldnt find any hints nor comment about this in the scripts descriptions... the next problem i discovered is that some of the scripts are using divisions where the result is NOT an integer that even hangs up the cam even...As far as i understand uBasic its needed INTEGERS to work proper... the fact of this problems and none descriptions of the unknown cam settings where its been used make the most scripts non usable and a newbie like me gets puzzelt quite a bit... overall i think the idea of the script is a good way which needs to be adjusted a little bit to make the program even more unique then it is allready.dont get me wrong I love it....it is awsome except this small matters ...... is there any solution or chance to corect this... like reading the parameters out of the cam and let it run into an error trap.. like its used in MBasic or other basics .... something like on error goto... i havent enough knowlege yet but i guess the cam gives out some errorcodes in the memory or firmware ........ any suggestion....... many greatings from germany ... hells_bells27

I've never noticed this integer-only problem that you seem to be having, and I've written and tested many scripts using divisions that result in non-integer values. The non-integer values from any calculations are always rounded to integers whenever they are used in any resulting variables for camera commands and print statements. Perhaps you are just copying the scripts wrong? People using Mac computers frequently have this problem. Or those that use anything other than the simplest of text editors. This is the first time I have every heard of anyone thinking this might be a problem, i.e. integer/non-integers in scripts. I've also never ran into an erasing files causing crashes. You might have to explain in detail exactly what you are doing that causes this so that others might be able to duplicate it. Be sure to also state what camera and build of CHDK you are using. That can make a huge difference.

I have found the problem.... it is depending on the script delay parameter... i have tested with my A630... if the script delay is below 4 msec. then i have this obove described problems... so i set it now to 6 just to make sure its running on all of my SD.Cards well.... thanks for your answer.... btw. if u set it up to 6 msec. u dont need the sleep command as much as usually... this saves a lots of processing time... kind regards HB

Property Case values. A working exploration sectionEdit

Some inital tests related to the property case values.

Recent updates!!!

property 181 tells you what operation mode you are in: playback or record. (Q is, what can you do with that information? Need a button to "click" that controls the mode selector. Then you can erase images) Actually, Property 181 is 3 if you are in record mode and are using the EVF, but it switches to 1 if you enter playback mode. However, if you are using the LCD, then 181 is either 1 or 0, depending on whether you are have turned on the histogram. If you are using the LCD, then 181 is not affected by entering playback mode. So 181 essentially is telling whether you are using the EVF or the LCD. See also 238 (histogram indicator).

Alain has discovered several EXTREMELY useful applications of 2 properties (see the table and the discussion of those items below). In brief:

- #67 can be checked to determine whether the camera has locked in the focus (and then you can activate MF to hold it).

:- #205 can be used to determine whether the camera is ready to take another shot. This should significantly speed up scripts. (No more "sleep" commands to space shots apart!) . Now I'm not so sure of these things. See the DpReview CHDK discussion tread for additional observations. We're still trying to figure this out. [Divalent]

This section is for exploring the values stored in these variables and the effect of changing them to different numbers. Please help out and add info from more camera's and more properties! You can find an a more extended list here: this page of Property Case IDs

You MUST use either Fingalo's CHDK build or 'StereoData Maker' available here .(An example-script is provided with SDM that cycles through the white-balance settings using set_prop command).

I used the script I posted in the user scripts page to test some of the property case values. (You can find that script here: Property-Case Value Tester) I tested these on an S3, mostly in P-mode.
There is another script for testing prop-ids: check this out!
Here's what I've found so far:

For the following "properties" here are the values I obtained:

N 0  Shooting mode dial -------> See comments below**
Y 2,3,4 sharp, sat, contrast---> Custom MyColors. See details below
N 6  Drive mode ---------------> 0 - single, 1 = continuous, 2 = timer
N 8  Hi-speed continuous-------> 1=OFF (!), 0=ON (!)
? 9  Metering mode ------------> 0=eval 2=center, 1= spot 
? 10 Spot AE Point ------------> 0=center, 1=auto focus point 
? 11 Macro --------------------> 0,1,5 for norm, macro, and super 
N 12 Manual Focus  ------------> 1 = manual, 0 = auto 
? 13 Auto Focus mode-----------> 0=single, 1 = continuous
N 14 Selftimer delay ----------> time in msecs 
? 15 Flash adjust mode --------> 0=Auto, 1=Manual (see 28&29)
Y 16 Flash mode ---------------> 2 if flash closed. Otherwise, 0=auto, 1=ON 
? 18 Red eye mode -------------> 0=OFF, 1=ON
? 19 Flash slow sync ----------> 0=OFF, 1=ON
Y 20 Flash Sync Curtain -------> 0 = first, 1 = second
Y 21 ISO value ----------------> 0=auto, 1=ISO-HI, or actual ISO: 80,100,etc 
Y 23 Image quality ------------> 0,1,2 from best to worst 
Y 24 Image resolution ---------> 0,1,2,4,8 for L,M1,M2,S,W 
Y 25 EV correction ------------> plus or minus 32 for each 1/3 stop (in other
                                 words -32 for -1/3 stop, -64 for -2/3 stop,
                                 -96 for -1 full stop, etc, and positive 
                                 values for over exposure settings) 
Y 26 EV correction ------------> (same as #25) 
? 28 Auto Flash intensity -----> same as 25: + or - 96 unit/stop.  (see #15)
? 29 Manual flash intensity ---> units 0,1,2 (2=full intensity?) (see #15)
Y 32 Exposure bracket range----> (Same units as 25: 96 =  +/- 1 stop)
Y 34 Focus bracket range-------> 2=Smallest, 1=Medium, 0=largest
N 36 Bracket mode--------------> 0=NONE, 1 = exposure, 2 = focus (see below)
? 58 Digital zoom enable ------> 0=OFF, 1 = ON
? 63 Auto focus assist beam ---> 0=OFF, 1 = ON
* 67 Focus ok -----------------> green rectangle = 1, otherwise 0 when in photo mode
? 74 AE lock ------------------> 1=ON, 0=OFF
* 126 Video Frame rate---------> Units of fps (e.g. 30) *beware of changing!
? 127,128 Video resolution-----> 2,1 for 640x480; 1,0 for 320x240
N 177 intervalometer #of shots-> Actual number (but effect of changing)
N 181 EVF or LCD --------------> 3=EVF, 0 or 1 if LCD (0 if histogram on)
N 205 shoot in progress -------> set to one during shoot operation (while camera is busy) (see below)
Y 206 MyColors" mode ----------> 0=OFF, 1-11 for various (see details below)
Y 207,208,209,210 -------------> Custom MyColors, see details below
? 218 Custom timer continuous--> # of shots to be taken
? 219 Self Timer setting-------> 0=2 sec, 1=10 sec, 2=custom continuous
N 238 Histogram on ------------> 0=OFF, 1=ON


-----
Note: the Y,N,*, and ? to the left of each item indicate whether changing
the value of that property actually has an effect.  ?="unknown", N= "No"
Y= "Yes", and * = read below.

Some comments and usage suggestions on some of these:

  1. Property 126, video frame rate: changing this to a non-standard value did not work, and locked up the camera. For now, avoid. [I tried changing the Video fps to 10, and it behaved strangely (time counter went really fast) when I started a video, and then the camera crashed when I stopped the video. The video was not saved on my memory card. I also tried 60 fps at 640x480 mode, and the thing went haywire. I'd hold off on expecting to get extended capabilities by changing this parameter. Beware!] I did not try changing to a standard number (e.g., from 15 to 30), so don't know if that is possible.
  2. Property 6, drive mode: changing this value has no effect. It only tells you that state of this setting. However, since (at least on an S3) this button can be pushed, you can use this property to tell you the current state, which then allows you to use button pushes to set it reliably to the setting you want.
  3. Property 12: manual focus. Changing this has no effect. But again, this property allows you to determine the state, so that button pushes will allow you to change it.
  4. Property 14: changing the Selftimer delay here does NOT alter the actual time delay. Use this only to get the time (use button pushes to alter).
  5. Property 16, Flash mode: [revised with new info] in any mode (P,M,Tv,Av) setting this value to "2" essentially turns the flash off. In P mode (on the S3) you can force a flash even if in flash-auto mode (value 0) by setting this to 1. (of course, all of this is moot if the flash is down). [Note: on the s3, if you are in AV, Tv, or M mode the flash is controlled only by whether the flash is raised (it will flash if up). I.e., there is no "auto-flash" setting. In P mode, the "auto-flash" mode is active.]
  6. Property 28 & 29: for all modes except M, property 28 can be used to adjust the flash intensity +/- several stops if you are in auto mode. Note: in all but M mode, the camera is making a decision how strong the flash will be based on the image. This property adjustment allows you to go +/- that amount. The built-in camera range is +/- 2 stops. I haven't tested what happens if you go beyond that range. Also note that if you set the main menu flash adjustment setting to "manual", or if you are in M mode, then the flash intensity is instead control by property 29, in units of 0,1,2 (where I think 2 is the full flash capability). Property 15 contains the flash adjustment mode.
  7. Properties 25 & 26, Exposure compensation. Setting these will extend the range of an S3 exposure compensation to beyond the normal 2 stop limit. The most I tried is + and - 4 stops (using 382 and -382). Alain found (in an A640) that you need to set both to do a reliable EV change (He said "I just did the test and found interesting and strange things: - setting only #25 does nothing: every picture is shot as if there was 0 EV offset. - setting only #26 works fine for all negative EV corrections (-1, -2/3, -1/3) but does nothing for the positive ones, which stay as EV 0 ... ==> setting both 25 and 26 is needed." -ALAIN)
  8. Property 32, the bracket exposure range, it does work using 4 stops (i.e., setting exposure bracketing in the menu, then set #32 to 384, then either manually setting continuous mode or setting #6 to "continuous" mode, then press the shutter and you get a 3 shots -4, 0, +4)
  9. Property 36, the bracket mode. It does not appear that changing this property by set_prop will have any effect. You apparently have to do this manually or with button clicks. The values 0,1,2 correspond to none, exposure, and focus. However, for the focus bracket, it is ONLY active (it only reports "2") if you are also in manual focus, otherwise it reports "0" (and you only get a single shot).
  10. Property 34 sets the focus bracket range, and changing this does, in fact, alter the bracket range. However, the fact that "0" is the high end on the focus range means it may not be possible to extend it beyond the current maximum range (I did not try using -1 !).
  11. Properties 21 (ISO), 23 (image compression), and 24 (image size/resolution), changing these to valid values for this camera seemed to work fine (I didn't try all, and didn't try non-standard values). Note: there already exists a get_ and set_iso command in GrAnd's standard CHDK build, so access via this property # is not really needed.
  12. property 67 reports if the focus is Good. (0=no, 1=OK). Use to determine if the camera has locked in on the focus. This is useful as feedback to let you know you can proceed with a shot (or to lock in the focus setting by enter MF mode). This is better than using a sleep command to allow focus time. Thanks to Alain for this. (can we find an "EV OK" property?
  13. property 177 is 0 if you have not activated the intervalometer mode. Otherwise, this contains the number of images in the sequence. Changing this number has no effect: the number of images shot is whatever is on the menu screen.
  14. property 205: this is a tough one to figure out. It is set to 1 during the shoot operation (if activated by a "shoot_full"), then it is released to 0. It can be a good complement to "shoot_full". After a shoot_full, it is necessary to wait until 205 is set to 1 and wait again it comes back to 0. (click "shoot_full" do get_prop 205 w until w=1 do get_prop 205 w until w<>1). Note: 205 is apparently also set whenever the camera has determined the correct exposure. It is not affected at all if the shutter is activated by the "shoot" command. Thus, at times it appears like an indication that the camera has determined the exposure settings, but it also varies if the shutter is activated by the "shoot_full" command. So, things are a bit muddy here.
  15. Property 0, shooting mode dial position. Changing this property to another number did NOT change the mode of the camera. The values I read for the mode positions Auto,P,Tv,Av,M were -32768, -32764, -32765, -32766,-32767. The other positions also had different values (C=-32764 (same as P!), Movie = 2590 (so it's NOT a byte!), Stitch assist -32246, SCN = 16395, Sport=-32761, Night=-32754, Landscape = -32756, Portrait=-32755). In Hex, these numbers are FFFF8000, FFFF8004, FFFF8003, FFFF8002, and FFFF8001.


"My color" controls

Property 206 controls the mode of the "my colors" setting. Here are the options for this property:

 0 = OFF               6 = lighter skin tone
 1 = Vivid             7 = darker skin tone
 2 = neutral           8 = vivid red 
 3 = B&W               9 = vivid green
 4 = septia           10 = vivid Blue
 5 = positive film    11 = Custom

If you set "custom" (value 11 in 206), then the values in the following properties set the "Custom MyColors" attributes:

 2 Sharpness           207 Red
 3 Saturation          208 Blue  
 4 Contrast            209 Green  
                       210 Skin Tone  (+=darker)

All the above properties (2,3,4,207-210) have the same range: 254,255,0,1,2 from less to more (skin tone I believe is darker with higher numbers). NOTE: these property values are actually byte values, but I believe the current (oct 16, 2007) version of get_prop is returning a 4 byte word. 255 and 254 are actually -1 and -2 in the byte format.

I tested by changing the colors, and at first thought it had no effect, as measured through my EVF, but as soon as I did a half press of the shutter, the image jumped to reflect the new setting.

Note: these values are static (i.e., they don't reset or change if you change the mode to something other than "Custom"), so it does not appear that you can use these as enhancements to one of the other pre-set modes. In other words, these custom values only have force if you are in custom mode.


I didn't try to change 9,11,12,or 14.

====> I tried to change manual focus on my A640, '#12' set to 1. The result is not good : it does change the play back value to MF when reviewing the file on the screen but when the picure is shot, the focus is active (noise in the lens) and the output is a sharp picture ... Alain
Alain, from what you say it sounds like this is also just an "informational" property. BTW, can you do this with button pushes? I think you'd want to anyway because putting it in MF mode locks the current position, which rarely is what you want. (Something like: press "shoot_half" {pause} click MF, release "shoot_half")
====> If u go MF and press the shutter half, then the AF still is going to focus.

You can turn this off in the canons camera menu under "safe MF" (worked in A590)...Toby

===> I played with property 67 (focus set) which is nice for script using the manual focus :
p = 0
do 
 p = p +1
 get_prop 67 j
 if p = 100 then 
   print "focus impossible"
   goto "lend"
 endif
until j = 1
print "focus OK"
:lend
end
This property does not change when the rectangle switches from white to yellow (no focus)then we need to test it with a time-out. When green rectangle appears, property is set to 1. - Alain
Alain, excellent! To follow up, I tested this by running my "propcase" script and looking at 67. If I hit the hot-key to jump out of CHDK temporarily, then manually held the shutter button half way until it focused, then (still holding shutter half way) hit the hot-key to jump back into CHDK, then releasing the shutter, it showed that 67 changed to 1 (this is on an S3; note: to update the propcase display of a the currently viewed property, you have to hit some button (any button) when you return to CHDK). Further it remained set at 1 if I entered MF mode after doing the half shutter press to lock focus. BUT (and this is good) it was not set to 1 if I didn't hit half shutter, but just entered MF mode. And it did not get set to 1 if I held the camera too close to something so that it was unable to lock in a focus.
- In summary: it really does seem to be a setting that says the focus is GOOD. This is very useful for scripts that do the half-shutter press to lock focus, as it allows you to test this property for a 1 before proceeding. The alternative was to do a sleep for some time, but that meant: 1) you couldn't be sure, and 2) you probably wasted time by always having the sleep interval long enough to be effective in all cases.
- Now, can we find the equivalent property for the "exposure OK"? (it occurs to me that this camera function would vary alot depending on the metering mode (spot being fastest, center = medium, and evaluative being slowest) with the complexity of the scene being an additional factor).

Divalent, using this focus set property with shoot_half function is really nice. Have a look to my ultra fast bracketing for A640 ... I've added, on your idea, a test of property #205 to avoid leaving "shoot_full" in open loop.#205 is set to 1 during shoot operations (while camera is busy), for the script to work properly, it is necessary to to wait 205 set to 1 and wait again it comes back to 0. Note also that on A640 there is not a MF button we have to click down to switch to MF while half shooting ... With this script, I take 5 pictures in 5 seconds, which is perfect now. The user can either select P, AV or Tv and the script does the job ! Note that 205 is a bit tricky with the flash (no picture is taken if flash is set) therefore, I've added a test on the flash mode and switch it off if it was set ... In the samle idea, 205 works fine in P, Tv and Av but gives erratic results in AUTO or M, the values of mode are tested in the script. I've also added a loop to retry focus if it fails on first try.

@title HDR bracketing
@param a delta en 1/3
@default a 3
@param b (nb images-1)/2
@default b 2
rem test input consistency
if b<1 then b=1 
if a<1 then a=1
if a>6 then a=6
if b >6 then b = 6
rem get the dial mode 
rem if <> P, Tv, Av exit
get_prop 0 i
if i = -32764 then goto "ok"
if i = -32765 then goto "ok"
if i = -32766 then goto "ok"
print "P, Tv ou Av ..."
goto "lend"
:ok
rem test if flash set
get_prop 16 f
if f = 2 then goto "ok2"
print "flash OFF ..."
set_prop 16 2
:ok2
rem get Exp compensation value
get_prop 25 i
rem  nb steps diaph computation
a=a*32
rem start EV computation
s=i-b*a 
b=b*2 
:ok3
rem try to focus
press "shoot_half"
rem wait for focus (prop 67)
p = 0
do
 p = p +1
 get_prop 67 j
 if p = 100 then 
   print "focus impossible"
   release "shoot_half"
   goto "ok3"
 endif
until j = 1
rem switch to manual focus
sleep 500
click "down"
sleep 500
release "shoot_half"
sleep 300
rem data take loop based on prop 205
rem initial set of 25 & 26 for the first shot
set_prop 25 s
set_prop 26 s
for n=0 to b
 click "shoot_full"
 do
  get_prop 205 w
 until w=1
 s=s+a
 set_prop 25 s
 set_prop 26 s
 do
  get_prop 205 w
 until w<>1 
next n 
rem switch back to auto focus
sleep 1000
click "down"
rem reset initial values for EV and flash
set_prop 25 i
set_prop 26 i
set_prop 16 f
sleep 300
:lend
end


Suggestions for some other things to try or to look for:

- a property that reports that the exposure settings have been determined (i.e., exposure has been locked; an analogous property to the one for focus at #67) (Note: it may be that this is 205!)

- any property that has a '?' in front of it above could use some testing to see if changing this property has an effect.

- additional camera model data (The A640 has many different property # assignments; for example, #286 controls color balance (vs #206 on an S3 and others)

- a property that would increase the number of images taken in a bracket series from 3 to 5 (7? 9?). I found only one property set to 3 (#181), and changing it to 5 did not affect number of shots in a bracket. I'm not hopeful on this, particularly since the built-in intervalometer ignores changes to #177.

- a property that tells you the current position in the FUNC menu hierarchy. Currently you can access many of the items in the FUNC (at least with an S3) by doing the click ERASE (which is FUNC on an S3), then up/down/left/right etc clicks to go to particular items. Unfortunately, when you exit the FUNC menu and then return, the "cursor" is in the same place you left it at. So you can't reliably change a FUNC menu item unless you know where it will be when you first activate that control. (After exhaustive search, I am thoroughly convinced this is not there).

- A huge reward has been offered to anyone finding the Image Review time control. :) (After exhaustive search, I am thoroughly convinced it is not there, and Alain states that he was similarly unsuccessful )

A comment about the state of the camera when using these. For property values that are effective in altering the behavior of the camera, if you change a value and then exit the CHDK mode (using the shortcut button) the camera will take images using the changed values. However, the camera displays (and the menus) did not show these changed settings/values. Rather, they show the original setting/values before they were changed. Turning the camera off, then back on, did restore the settings to back to their original values (before changes) so that they reflected what the camera display said they were. (also, it appears that entering display mode, or changing the mode dial (P/AV/TV/M) has the same resetting effect.)

So, if you change these items in a script, it is probably a good idea to change them back before exiting, or your camera will be confused.


(Note: I've trimmed the comments some since the information asked for or gotten is now up above. Commenters are encouraged to trim further. Use the page history feature to see what was there as of Oct 15, 2007)


-Divalent

Most excellent testing and sleuthing there Divalent!! Thanks!! This information will be extremely valuable to add to the pages. You might want to go ahead and add them to the set/get_prop section now. With a note of what camera model you have found them to be correct on at this time.
This is the same way that people who were testing the various set/get_av/tv values were found for different cameras (see that section, examples still intact there). One person posting theirs encouraged other camera-model owners to test theirs. Some discrepancies were found and it resulted in some minor changes to the look-up tables in CHDK so all cameras would have the same values.
...I still wonder if non-standard resolution and frame-rates might not be available hidden in the secrets of these cameras. Hmm... I wonder if a prop_id will be found for audio-recording settings too. Or maybe even the sound-memo length (as was asked as a request recently). So much to discover yet. :-)
[mr. anon]
I've only tested 10 and 60 fps, resulting in crashes. I'm not in a mood to try more, but if anyone else wants to try 50 or 27 go ahead.
(Regarding why there are 2 EV compensation settings 25&26) I'm not sure either why there might be 2. But when writing scripts I did find an interesting aspect to the Av and Tv values. It appears that the one being detected and the one you set are two very different things. I can't remember the exact situation in what caused this, I found it when trying to write the Lightning Photography scripts. Using the set_av/tv commands. When I saw that the Prop_ID values listed the Av/Tv as "coming Av", and "coming Tv", it sort of reinforced what I sensed was going on. Maybe these 2 values are used similarly? One for manual settings, the other for auto-detected settings? Just a vague guess. As far as their use, it wasn't clear from your list if the numbers -32 to +32 are used to set 1/3rd stop or what, or if the full range of numbers is -96 to +96. And if that's the case, can they be extended to change the stop by 2 or more for HDR frames? How far can those numbers actually span? [mr.anon]
Do you know what that exposure bracket range is for? I'm now wondering if that's set by a quick script if it will increase the manually selectable range on-screen. ... [mr. anon]
The exposure bracket range selectes the range overwhich your 3-shot exposure sequence will shoot. Camera limits it to +/- 2 stops (beyond any Ex comp value you set (so you can get below 2 stops OR above 2 stops if you adjust both). If you set the ex bracket property value to 4 stops, the menu selector still shows the original value (and you don't see an extended range). My experience with iso, exp comp, IQ, etc, is that what the camera display menus show you after you change something is what it was before you change it, not what you changed it to. There seems to be another storage place in the camera for what is displayed. Also, I'll note that if you change into display mode, or manually change the mode dial (P,Av,Tv,M) then everything gets reset to the original values (I wonder if changing mode property 0 also does this "reset"?).
re: exp. brkt. range, now that's sweet! Seeing as how the built-in exposure bracketing is much faster than any done by script ... this could provide for some excellent new, FAST, and short EV scripts!! People that do HDR sequences often claim needing 2+ or more stops per exposure, some HDR blending software even requires it for best results. I'm now wondering if that will effect the range of the Focus Bracketing steps too, or if there's another Prop ID for that. As that sorely needs more range on it, that's what pressed me so much to find some decent focus bracketing methods. Dearly needed for macro photography. When I first got my camera it was even difficult to tell if there was any difference between the 3 focus-bracketing images created by the camera (yes, when set at the maximum +/- range for it).
a suggested script for extended range and more images: set exp comp to -1.5 stops, do a EV bracket of over a 1 stop range (getting 3 quick), then set exp comp to +1.5 stops, and do another quick EV bracket of 1 stop; Result is 6 images 1 stop apart from -2.5 to +2.5
I'm afraid to ask what happens with the focus/exp-brackets set. :-) I know they can come in handy in scripts though. With a focus bracket script, and setting the camera to exp. bracket, it'll take 3 shots per focus step, really handy. I hope you or me or someone stumbles on the focus-bracket Prop-ID. I've since added what you found so far to the Script-Writer's List so at least it'll be partly available so far on the main page. It needs more updating though, I left out some one of Fingalo's easier ways to use USB remote. Those findings for #32 and #36 are great! I'm also thrilled with what you found about flash compensation. Who'd have thought you could set the flash output by 96 levels. There's some major precision buried in these cameras! This has me wondering now, about turning flash to such short (dim) durations as to stop really fast objects (would have to be near subjects), or its usefulness for macro-flash modes ...

A640 : I tried to use the 32 and 36 properties expecting that the firmware in A640 would have a hidden functionnality for bracketing ==> it fails to work ... a pitty. As the #25 and #26 properties are working fine too on A640, I'm hunting the "review time" property. For this I've written this little script which only acts on the display menu (hit menu, goes up 3 times, press left, hits menu again) then it compares the value of a property to its previous value and prints it if they are different. So far I've run this script from #0 to #300 and didn't find any change but #100 and #101. I've noticed that #100 seems to be affected by the changes in menus or button press but I'm not sure. I'll go on running this script on upper values of properties and keep you informed. Here is the script :

@title cherche
@param a propid
@default a 0
@param b value
@default b 0

for a = 98 to 300
	sleep 500
	click "menu"
	for s = 1 to 4
		sleep 500
		click "up"
	next s
	sleep 500
	click "left"
	sleep 500
	click "menu"
	sleep 500
	get_prop a b
	n = b
	click "menu"
	for s = 1 to 4
		sleep 500
		click "up"
	next s
	sleep 500
	click "right"
	sleep 500
	click "menu"
	sleep 500
	get_prop a b 
	if n <> b then print a, b, n
next a
end

Alain

Alain, I've searched hard and am convinced the review time is not there. I wrote a simple script that wrote every value to a file, and I had it go thru 1-260 6 times consecutively for each setting (while I pointed the camera at different scenes to make the exposure/focus ones vary). I looked at variables that 1) did not change within a set for a particular condition (helps eliminate those that vary all the time) and then 2) compared to a similar set after changing some function. I'd bet alot that review is just not there. I also came up empty trying to find the "cursor" position in the FUNC menu. (a lot of things you want to change are in the FUNC menu, but right now the only way to change them is to "Click" the buttons (like your script does), but if you don't know where the cursor starts out at, you are pretty much lost.)
BTW, I've determined that you can't activate a bracket function on an S3, (which has both focus and EV bracket) merely by changing 36. Apparently #36 is just telling you what it's set at; if you change it, it does what it would have done anyway. So, getting a camera that doesn't have these functions to do it in one command (as opposed to a script) will require a lower level attack on the native firmware (if the functions are in there).

Divalent, You were right my script didn't find anything from property #1 to #999 for the "review time" it was hunting. I give up this way !


Divalent, there was in interesting question in the forum about restarting video when time or length ended. That post is HERE. I suggested he watch this thread to see if there's any prop-ID that might be used. Perhaps you could offer better advice than I did.

Lightning Photography with Motion Detection? Edit

I asked about this in the page where the Lightning Photo samples are being posted. Please refer to Lightning Photography Discussion page if interested in helping finding the best way to do this. I would like to add the best script possible to the scripts section once all the bugs are worked out too.

I asked there because it seemed like the place where the most who were interested in that subject might find more information about this aspect of using CHDK.

uBasic timing. One line (only!) executed every 10 msec? Edit

I was playing with Fingalo's CHDK build v. 106 that has a get_tick_count function (I think written by Mike McCade) that returns a time in milliseconds. In testing it, it revealed (I think) that a uBasic script will execute one, and only one, script command every 10 milliseconds.

Heres the situation: with the following script:

 a = get_tick_count
 b = get_tick_count
 print "counts were", a, b

a and b are always (ALWAYS) 10 milliseconds apart. (they both also always (always) end in a 0 (e.g, 25670, never 25671, etc))

That got me to testing further: if I put 3 other commands between the get_tick_counts in there, like this:

 a = get_tick_count
    b=b+27    <---|
    c=c+a     <---|---note: these 3 don't do anything other than make uBasic execute a command
    d=d*23    <---|
 b = get_tick_count

Now a and b are now always 40 msec apart (never 30, never 50).

And even REM statements take a 10 msec chunk!

 a = get_tick_count
    goto "jumper" 
    rem
    :jumper
 b = get_tick_count  (a->b is 20 msec, so "goto" = 1 command (regardless of what it hops over)
    rem blank line
 c = get_tick_count  (b->c is 20 msec, so REM = 1 command (10 msec!)
    rem executed line below
     d=d*73
 d = get_tick_count  (c->d is 30 msec, REM + multiplication = 2 commands

It looks like uBasic executes one, and only one, command every 10 msec (on the "0"). (moreover, it looks like uBasic is called on an interrupt that trips every 10 msec, so that's why the tick_count always ends in 0). And even REM statements count as a command! (On the bright side, a blank line does not count. so space those lines with blanks, not blank REMs!)

(NOTE: when the camera is taking a photograph, there are times when things can run slower. So the information here should be taken as best case.)

Script writers developing timing-sensitive scripts should keep this in mind.

Comments?

-Divalent

I think this is true of any programming, and something to always keep in mind. The difference between bloatware that requires a new computer every year, or efficient programming that still runs on a computer from 5 years ago. I recall from my BASIC programming days that code is reinterpreted from beginning to end with every result required (thought that may have been just the OS and CPU I was running on at the time?). This is why I find it important to keep rem statements to a minimum, and to find more efficient ways to create loops, counters, etc. Include a few rem statements between your test lines, see if that too doesn't increase the time required. I have also found that the earlier and smaller builds of CHDK are faster than later ones. I keep them handy in sub-folders on my SD card for intervalometer scripts where I might require the fastest speeds possible between frames. I also keep the original RAW hack file because that is the fastest of all if only needing RAW images and no CHDK interface. I haven't tested it yet but I think the in-camera copy commands can replace the *.fir and *.bin files from my backup subfolders of earlier builds when really needed. Just as long as I don't move a version of CHDK to the root of the card that doesn't include the move/copy commands so I can "upgrade" back again when needed. :)
Well, that was my first initial impression as well. But I think I am describing something more than just slow because its an interpreted language. The clock is dead accurate in that you can use the time between two fetches of the tick_clock and the difference is *exactly* equal to 10 msec times the number of uBasic lines executed. I followed up and tested REM statements, (see above) and even they count! (and a GOTO is only one, even if it's hopping over valid lines of code) This is WAY too slow (and far too accurate) to be considered 'normal' processing time.
The conclusion is unmistakable, uBasic is allowed to execute only one line of code each 10 msec. That might make sense for a device whose primary purpose is to be a camera and image processing unit; to only give parasitic processes a limited time slice. But it is far larger a penalty than I thought existed.
Interesting findings. I think I should make a note of this at the top of the tutorial page, as a reminder to those writing scripts to be efficient in their coding. Considering, as you say, this is a CAMERA!, I don't think we should be asking for major pentium dual-core CPU miracles here. I'd be happy if all it did was push the shutter button for me from a simple 3 line looped timer where I could change just one variable. :-)
Undoubtedly uBasic works by executing a line of code, then relinquishing the CPU back to the camera, and then doing a new line when the camera calls it again (10 msec later). (I say this not having actually looked at the uBasic code, so I could be wrong). This probably is very rational, particularly when a function is time consuming, so that the camera can continue to do it's business. In that regard, it may be possible to push it a little bit. One way would be to change the uBasic code so that (for example) it gets called every 5 msec. If this is not possible, perhaps some functions can be coded so that they let uBasic do two things in one time slice (for example, where the function is merely to read and return a system variable, it quickly does so and then makes uBasic do another line; whereas if the function is a more time consuming task, it doesn't do this.) I can now see the utility of functions that combine tasks, like the set_focus_rel, which does in 10 msec what a get_focus x, x=x+change, set_focus x would need 30 msec for. Thus, there may be stratgies for speeding things up, yet let the camera maintain itself.
It looks like this 10 milliseconds per line limitation doesn't apply to Velo's lua implementation. Using the collaborative CHDK build I wrote the same script in uBasic and lua to test how long it took each to run a loop which just assigns a value to a variable 1000 times. The lua script took about a quarter of a second whilst the uBasic script took around twenty seconds:
              uBasic...
                    a = get_tick_count
                    for s = 1 to 1000
                      c = s
                    next s
                    b = get_tick_count
                    print "total time = ", b-a, " ticks"
                    end

              lua...
                    a = get_tick_count()
                    for s = 1,1000 do
                      c = s
                    end
                    b = get_tick_count()
                    print("total time = " .. b-a .. " ticks")
-Almbon- 20:39, 29 July 2008 (UTC)

Old version: The "print_screen" CommandEdit

Stored here for documentation purpose - this old description is wrong for Allbest, GrAnd, Fingalo & ( all ? ) other builds...

Whatever the script prints on the mini-console screen is also written to file '/CHDK/SCRIPTS/PR_SCREEN.TXT'.

First call is either,

print_screen 0 The text is appended to the last file. If the file was there already, the text is written at the end and the older text is not removed.

print_screen 1 The text is written to "A/CHDK/BOOKS/PS00000.TXT". The new text overwrites any existing text in the file if there was any .

print_screen N The text is written to the next file number. The file number cycles between 0 and N-1. If the resulting file number is 5, then the text is written to file "A/CHDK/BOOKS/PS00005.TXT". The file number of the last written file is kept in file "A/CHDK/BOOKS/PS_COUNT.TXT". Delete the file to reset the counter.

print_screen 0 turns off writing to the file and print_screen 1 turns it back on.

Example:

@title printscreen test 

@param a None 
@default a 0 

@param c mode: 0-append, 1-replace, other-modulo c 
@default c 1 

print_screen c 
print "START "c 
print_screen 0 
print "Not written to file" 
print_screen 1 
print "This should be written to the file." 
print "a="a 
print_screen 0 
end

auto-zoom to certain focal length...Edit

(auto-zoom to certain focal length & set focus to certain distance, & set ISO/aperture/shutter speed in video mode?)


hi guys... I recently made a 35mm-lens-adapter for my S3 IS, & I find it very troublesome having to fine-tune the focal length & focus distance everytime I want to use the adapter, though I have absolute zero knowledge/background in programming... but I'm not here asking for spoon-feed, just would like to know if that is possible, I mean like, load a script & the camera auto-zoom to certain focal length & set focus to certain distance?... if that's possible I'm willing to learn & research from scratch


another question is, is it even remotely possible to set desired ISO, aperture & shutter speed on the fly in video? I'm sorry if I sounded too greedy = P


million thanks in advance

Automating a direct print to a PictBridge printer Edit

Hi, newbie here with CHDK. Must say, it's a bit overwhelming at first glance, and I'm an IT Director with over 20 years of programming experience... I'm finding it kinda hard to find my way around...

So, I'm just checking to see if this is possible before I dive in and spend alot of time on this.

I'd like to write a script with CHDK to automate an inexpensive camera (not picky, just simple and cheap, please feel free to recommend one) so that when the shutter release is triggered, it automatically sends the picture over USB to a PictBridge compatible printer, with no additional menu selections needed.

Is this possible? Im assuming it would simply be a matter of macro'ing the buttons and correct timing.

Also, i'd like to remote trigger the shutter from a custom external pushbutton, but I'm probably going to have to hotwire it since the USB will be plugged into the Pictbridge printer at the time. Or, can it be used over a USB hub?

Thanks for any info,

Mike

Around Wikia's network

Random Wiki