ubasic set_av/sv/tv* commands

fudgey

1705
a570is

« on: 18 / May / 2008, 12:53:20 »

Advertisements

Hi,

I experimented around a bit and had to look into the source to find out what's going on. Looks like the ubasic commands set_av96 and set_av96_direct (probably set_av too but I can't seem to find it now... where in the source tree are ubasic command strings tied to functions?) pass "SET_LATER" in the function calls, while bracketing features use "SET_NOW".

I'm assuming this has something to do with the camera resetting the propcases back the where it thinks they belong when shooting starts? However, that SET_NOW seems to effectively stop these commands from having any effect on the resulting image if the commands are given while shoot_half is pressed.

What I wanted to do (and looks like achieved using get_prop and set_prop instead of the set_?v* commands) was to fool the camera to use an overexposed LCD view during fast react motion detect (correct me if I'm wrong, but there is direct way to do this?) by

1) press "shoot_half", let the camera calculate exposure and store av, tv, sv in variables
2) release "shoot_half"
3) increase exposure compensation by 2 Ev
4) press "shoot_half", let the camera calculate exposure
5) set av, tv, sv to the original values and reset exposure compensation to its original value.

Now, I have an overexposed view on the LCD but the image will be correctly exposed.

This works if I use (Digic III example)
get_prop 23 A
get_prop 262 T
get_prop 247 S
and similar set_prop's for storing and setting the exposure.

If I use get_?v96 and set_?v96, the resulting image is overexposed.

If I use get_?v96 and set_?v96_direct, the camera crashes. This was a part of a large script which did have other crashing problems too, possibly due to goto choking on it's size (see http://chdk.setepontos.com/index.php/topic,1413.0.html).

Now, the question is... should we have another set of set_av/tv/sv commands which pass SET_NOW instead of SET_LATER, or should we modify those ubasic commands a bit so that they'll pass SET_NOW if shoot_half or shoot_full is currently pressed and SET_LATER if it isn't?

Logged

Jucifer

251
[A710IS]

Re: ubasic set_av/sv/tv* commands

« Reply #1 on: 19 / May / 2008, 08:58:23 »

I'd modify.

Logged

forum search // google // autobuilds

fbonomi

469
A570IS SD1100/Ixus80

Re: ubasic set_av/sv/tv* commands

« Reply #2 on: 19 / May / 2008, 11:58:11 »

fudgey, are you sure things are like you say they are?

(i.e. set_av* don't work when shoot_half is pressed?)

I mean, those commands, are at the moment quite buggy, (I was going to examine them better because I have problems too) but I am afraid there are deeper problems.

I am sure there are with set_tv*...

EDIT: I found out the reason of this particular bug, see here
For example, try running the "official" set_tv96_tst1.bas (from trunk\script)

Code: [Select]

@title Tv TEST

for a=1 to 4

if a = 1 then d = 0
if a = 2 then d = -320
if a = 3 then d = 320
if a = 4 then d = 576
rem if a = 4 then d = 2000

if a = 1 then print d, " t=1"
if a = 2 then print d, " T=10"
if a = 3 then print d, " t=1/10"
if a = 4 then print d, " t=1/...."

set_tv96_direct d

shoot

next a

end

(rem introduced by me)

The first set_tv97_direct has no effect.

In other cases, doing set_sv96direct and then set_tv96_direct would make the set_tv96_direct useless.

I kind-of-solved it placing some sleep here and there, but occasionally there are stiil "dead" shots.

Quote

where in the source tree are ubasic command strings tied to functions

I think you are searching for this:
Tokenizer.c, line 132:
{"set_av", TOKENIZER_SET_USER_AV_BY_ID}, //FOR COMPATIBILITY

As per your specific question, I'd rather have new instructions. I am already very doubtful they behave reliably, and if we complicate their behaviour we will make them difficoult to debug.

« Last Edit: 19 / May / 2008, 12:32:29 by fbonomi »

Logged

fbonomi

469
A570IS SD1100/Ixus80

Re: ubasic set_av/sv/tv* commands

« Reply #3 on: 19 / May / 2008, 12:18:02 »

Just to clarify....

Tokenizer.h defines some enumerated constants:

Code: [Select]

typedef enum {
  TOKENIZER_ERROR,
  TOKENIZER_ENDOFINPUT,
  TOKENIZER_NUMBER,
  ...
  TOKENIZER_SET_AV96_DIRECT,
  TOKENIZER_SET_AV96,

These constants are matched to the strings in tokenizer.c (line 57):

Code: [Select]

static const struct keyword_token keywords[] = {
  {"<>",          			  TOKENIZER_NE},
...
  {"set_av",                  TOKENIZER_SET_USER_AV_BY_ID}, //FOR COMPATIBILITY
...
  {"set_user_av_by_id",       TOKENIZER_SET_USER_AV_BY_ID},
  {"set_user_av96",           TOKENIZER_SET_USER_AV96},

The constants are then matched to function in ubasic.c (line 1564)

Code: [Select]

  switch(token) {

  case TOKENIZER_PRINT_SCREEN:
    print_screen_statement();
    break;
  case TOKENIZER_PRINT:
  ....
   case TOKENIZER_SET_USER_AV96:
    set_user_av96_statement();
    break;

But probably you had already found out most of this by yourself :-)

Logged

fbonomi

469
A570IS SD1100/Ixus80

Re: ubasic set_av/sv/tv* commands

« Reply #4 on: 19 / May / 2008, 12:31:05 »

Sorry for all these posts. The example of bug I posted before is caused by another problem.

"set_tv96_direct 0" has NEVER effect!

shhoting.c, line 1073

Code: [Select]

if ((state_kbd_script_run) && (photo_param_put_off.tv96)) {
  shooting_set_tv96_direct(photo_param_put_off.tv96, SET_NOW);	
  photo_param_put_off.tv96=0;
 }

setting the value to 0 means "do nothing" :-)

but anyway, there are other bugs, more difficoult to replicate. I will study them better as they make my scripts unusable... See for example the problem met by pfalangie here:
Timelapse with variable shutter speed

INTERESTING POINT THAT MIGHT EFFECT YOU:
The same holds for setting av too

Code: [Select]

 if ((state_kbd_script_run) && (photo_param_put_off.av96)) {
  shooting_set_av96_direct(photo_param_put_off.av96, SET_NOW);
  photo_param_put_off.av96=0;
  }

This means that "set_av96 0" will never work.

If this is your case, a simple workaround could be doing "set_av96 1" instead of "set_av96 0" (very similar result but at least you bypass this bug)

« Last Edit: 19 / May / 2008, 12:36:37 by fbonomi »

Logged

fudgey

1705
a570is

Re: ubasic set_av/sv/tv* commands

« Reply #5 on: 19 / May / 2008, 14:47:24 »

Thanks fbonomi,

Yes, I think "SET_LATER" will stop these functions from setting the propcases during half_press. But I've only verified this in one script, which probably was faulty in other ways as well during that time as well. I really should test this in a more controlled environment with a series of scripts that have nothing else in them. In any case changing set_av96, set_tv96 and set_sv96 during half_press to the equivalent set_prop's, my script suddenly worked the way I wanted it to work.

About that &&0 bug: In platform/*/shooting.c shutter_speeds_table the id and prop_id fields are both 0 for Tv=1s on all supported cameras. Aperture setting functions are (luckily) not affected, because none of the supported cameras have prop_id of 0 for any aperture in aperture_sizes_table. For the sv (ISO) functions, Auto ISO mode is always id=0, prop_id=0 so they are affected (but not in M mode) if there's a similar AND check (I looked at trunk 395).

As for other bugs, I haven't used these functions much but it's probably clear that not everything that doesn't work is a bug...as far as I can understand, these functions are basically model independent wrappers for set_prop, some of which may delay the set_prop to a later time (the mechanism of which I haven't even tried to dig into, i.e. the difference between SET_NOW and SET_LATER).

So, before anything can be classified as a bug, one must first test with the equivalent set_prop to see what their camera does. The way the cameras respond to commands is weird sometimes, that's something we have to adapt to because we are sort of running a parasite to the original host firmwire

Logged

fbonomi

469
A570IS SD1100/Ixus80

Re: ubasic set_av/sv/tv* commands

« Reply #6 on: 19 / May / 2008, 16:42:11 »

I have not tried setting the prop values manually, actually... I will give it a test later.

Anyway, I think it's a bug because the camera completely fails setting the Tv value.

This is the fragment of code that shoots:

Code: [Select]

sleep 100
set_sv96 L
set_tv96_direct M
sleep 100
shoot
sleep 100

the scritps logs the parameters for each shot; for example, these are the info for three shots in the sequence.
(for each shot I gve the Tv96 value that I requested and the actual exposure that I got, as read from the EXIF info)

shot 1138
Requested Tv96: 26 (0.82 sec.)
Actual exposure: 1 s.

shot 1139
Requested Tv96: 34 (0.78 sec.)
Actual exposure: 15 sec.

shot 1140
Requested Tv96: 36 (0.77 sec.)
Actual exposure: 1 s.

Shots 1138 and 1140 gave the results that I was expecting (shutter time of 0.82 being rounded to 1 in the EXIF info)

In shot 1139, the set_tv96_direct failed and the camera defaulted to the exposure time that was set in manual mode (15 seconds)

I would like to test the set_prop method... but I am getting crazy now, as the camera has started hanging even on extremely simple scripts.... I don't know why! :-(

Logged