CHDK Wiki
Register
HighInBC (talk | contribs)
Line 110: Line 110:
   
 
::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!!) :-) [[User:Keoeeit|Keoeeit]] 21:50, 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!!) :-) [[User:Keoeeit|Keoeeit]] 21:50, 6 June 2007 (UTC)
  +
  +
:::Very interesting, thanks for the S3 IS info. [[User:HighInBC|HighInBC]] 14:10, 11 June 2007 (UTC)

Revision as of 14:10, 11 June 2007

Help: talk pages, talk page guidelines


Av&Tv Commands

That are very handy commands, thanks for finding out!
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 it sets the right values automatically for us. Since the 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 tells me "-2" till "+2", but not the correct exposure right away. --Harvester 19:26, 17 May 2007 (UTC)

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

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

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

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  :-)

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)

Camera Operation Commands

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!

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)