Motion Detection too slow?

[mx3]

mx3, I'm still trying to understand the CHDK sources. But it seems the 'immediate shoot' option uses the kbd_sched_shoot function. Looking at that function it seems to wait for the flash etc. Is that the "normal" shoot function? In other words, can this be changed to the "shoot_full" equivalent and that will speed it up?

immediate shoot option right now uses equivalent of "shot" ( and it is not best variant as you know now)
I have planned this option not knowing about shoot_full ( I have been novice to CHDK myself)
only thing I have thought about this option - to speedup process for 10 msecs



of course implementation is not the best

[Barney Fife]

Deleted

[A570is]

Hi Barney Fife,

I think you are right 

I have just tested another modification for objects where you have not to focuse every time (for example lightnings) and put the press "shoot_half" outside the loop:

Code:

...
snip
x=30000
press "shoot_half"
while 1
 t=0
 md_detect_motion a, b, i, x, d, c, 1, t, h, 1, 1, a, f, 0, g, e
 if t then click "shoot_full"
wend
end

The time between the shots is very short now and you get every lightning 

[Barney Fife]

Deleted

[jonnythe]

Well I just changed the source code from calling the kbd_sched_shoot to calling kbd_sched_press( KEY_SHOOT_FULL ) but it doesn't take a shot at all. Really having trouble understanding this source code. Guess I'll have to ask at the development forum.

[jonnythe]

Barney, would changing the test program to do something like this be better :



It seems to stand out more on my monitor. The top white "bar" shrinks toward the right showing shutter open time, while the bottom bar grows towards the right showing shutter close time. In that example the blue bars are 50ms apart. I expected this method to have better accuracy but it's still 25ms or so out. All to do with refresh rate etc. I haven't added the timing scale yet as we have a thunderstorm right now and I'm trying to get my A610 into action for some samples.

[fudgey]

fudgey, what sort of monitor do you have? Could you send me a sample shot which shows the lines not being shown correctly so I can understand the problem?

Sure, see below for a cropped example. It's a laptop LCD screen, running Vista (unfortunately). Note that I can actually see (without the camera) that the motion is quite jerky. In the 60 Hz video it looks like it works fairly well for a couple of lines in a row, then gets stuck displaying a line, then skips the next one entirely and draws the third one while the first one is still bright.

[A570is]

Hi Barney Five,

believe me it works I have it tested before I have posted.

Perhaps one could do all (focuse, choose f-stop and aparture and so on) before starting a script and no need of press "shoot_half" (not tested yet)

[anonymous]

If you want to get rid of the trigger delay you can test if the shoot_full is finished,
and if that is insufficient you can test for the # of cells (normally denoted by t)
that are triggered, as in the AdaptiveMD script on the CHDK Wiki.

The best way, of course, is waiting for a ``viewport ready'' signal,
but that is not found, or perhaps not available, as far as I know.

[Barney Fife]

Deleted

[mx3]

jonnythe

I have two RAM dumps of 610 1.00f

it seems you can use this array to speedup detection time
[0x000052EC] : 105F1370
[0x000052F0] : 10670D50
[0x000052F4] : 106F0730

if your version is 1.00f you can try following changes
void *vid_get_viewport_live_fb(){
   void **fb=(void **)0x52EC;
return fb[ *((unsigned char*)0x52FC) ];
}

if it works it must speedup detection time from 100 msecs to 30 :-)

[GrAnd]

This post is mostly for mx3.

Theoretically, there is a room for improvement of shooting process. Currently, any scheduled command takes 10ms (one kbd interval). But some commands are short and do not require passing of control to original firmware. So, the improvements can be made in 'kbd.c' (I did not check):

Code:

87 void kbd_sched_shoot()
88 {
89 // WARNING stack program flow is reversed
90
91     kbd_sched_delay(conf.script_shoot_delay*100);// XXX FIXME find out how to wait to jpeg save finished
92
93     KBD_STACK_PUSH(SCRIPT_WAIT_SAVE);
94
95     KBD_STACK_PUSH(KEY_SHOOT_FULL);
96     KBD_STACK_PUSH(SCRIPT_RELEASE);
97
98     kbd_sched_delay(20);
99
100     KBD_STACK_PUSH(KEY_SHOOT_FULL);
101     KBD_STACK_PUSH(SCRIPT_PRESS);
102
103     KBD_STACK_PUSH(SCRIPT_WAIT_FLASH);       [color=red]//At least 10ms. Waits for flash is ready. Theoretically can be 0.[/color]
104     KBD_STACK_PUSH(SCRIPT_WAIT_EXPHIST);     [color=red]//50 or 60 ms. Does not needed at all.[/color]
105     KBD_STACK_PUSH(SCRIPT_PR_WAIT_EXPHIST);  [color=red]//At least 10ms. Maybe more? Waits for "shooting_in_progress" state. Theoretically can be 0.[/color]
106
107     kbd_sched_delay(10);
108
109     KBD_STACK_PUSH(KEY_SHOOT_HALF);
110     KBD_STACK_PUSH(SCRIPT_PRESS);
111
112     KBD_STACK_PUSH(SCRIPT_PR_WAIT_SAVE);    [color=red]//Stops calculating of histogram 10ms -> can be 0. The histogram data is not used for shooting at all.[/color]
113
114 }
..........................................
147 void process_script()
148 {
149     long t;
150
[color=red]    cont:[/color]
151     // process stack operations
152     if (kbd_int_stack_ptr){
153         switch (KBD_STACK_PREV(1)){
154
155         case SCRIPT_MOTION_DETECTOR:
156                         if(md_detect_motion()==0){
157                                 kbd_int_stack_ptr-=1;
158                         }
159                         return;
160
161         case SCRIPT_PRESS:
162             kbd_key_press(KBD_STACK_PREV(2));
163             kbd_int_stack_ptr-=2; // pop op.
164             return;
165         case SCRIPT_RELEASE:
166             kbd_key_release(KBD_STACK_PREV(2));
167             kbd_int_stack_ptr-=2; // pop op.
168             return;
169         case SCRIPT_SLEEP:
170             t = get_tick_count();
171             // FIXME take care if overflow occurs
172             if (delay_target_ticks == 0){
173                 /* setup timer */
174                 delay_target_ticks = t+KBD_STACK_PREV(2);
175             } else {
176                 if (delay_target_ticks <= t){
177                     delay_target_ticks = 0;
178                     kbd_int_stack_ptr-=2; // pop sleep op.
179                 }
180             }
181             return;
182         case SCRIPT_PR_WAIT_SAVE:
183             state_shooting_progress = SHOOTING_PROGRESS_NONE;
184             state_expos_recalculated = 0;
[color=red]185             histogram_stop();                                            //Do we need this?[/color]
186
187             kbd_int_stack_ptr-=1; // pop op.
[color=red]188             return;                                                      //Can be replaced by "goto cont"     (-10ms)[/color]
189         case SCRIPT_WAIT_SAVE:{
190             if (state_shooting_progress == SHOOTING_PROGRESS_DONE)
191                 kbd_int_stack_ptr-=1; // pop op.
192             return;
193         }
194         case SCRIPT_WAIT_FLASH:{
195             if (shooting_is_flash_ready()) [color=red]{[/color]
196                 kbd_int_stack_ptr-=1; // pop op.
[color=red]                        goto cont;                                           // (-10ms)
                    }[/color]
197             return;
198         }
199         case SCRIPT_WAIT_EXPHIST:{                                    [color=red] //The call of this sched command can be removed from the function above    (-50ms)[/color]
200             if (state_expos_recalculated) {
201                 kbd_int_stack_ptr-=1; // pop op.
202                 state_expos_under = under_exposed;
203                 state_expos_over = over_exposed;
204             }
205             return;
206         }
207         case SCRIPT_PR_WAIT_EXPHIST: {
208             if (shooting_in_progress()) {
209                 state_expos_recalculated = 0;
[color=red]210                 histogram_restart();                                          //Again. Do we need this?[/color]
211                 kbd_int_stack_ptr-=1; // pop op.
[color=red]                        goto cont;                                                    // (-10ms)[/color]
212             }
213             return;
214         }
215         case SCRIPT_WAIT_CLICK: {
...

[jonnythe]

Damn it. I have 1.00e

I don't know enough about the firmware yet to get this info for my model. I'm a little busy today and am working on a zillion projects at the same time. Really need some time management skills

GrAnd, I tried implementing those changes yesterday by copying the kbd_sched_shoot function to one that is called only by the motion detection routine, and removing the unneeded lines. But it still didn't take a shot. The firmware builds fine but I must be doing something wrong since my c programming isn't up to scratch.

[GrAnd]

Damn it. I have 1.00e

For the 1.00e the addresses are the same. I've looked through CHDK MemoryBrowser.

[mx3]

Damn it. I have 1.00e

I'm a bit lazy so I don't use IDA to find out addresses

1) you have to make two RAM dumps (one dark (close lenses by hand), second bright)
2) change find_diffs.bat to use your files
3) run it
you will get file where will be 3 lines with "bytes: 3F480" string
such way you will determine addresses of frame buffers
4) nexzt step - find out array with these addresses
change zzz.bat and run it
you will get file with references to these frame buffers ( bellow file is for 1.00f)
[0x000052EC] : 105F1370
[0x000052F0] : 10670D50
[0x000052F4] : 106F0730
[0x000069A0] : 10670D50
[0x000069A4] : 10670D50
[0x00006A28] : 105F1370
[0x000AC600] : 10670D50
[0x00304008] : 106F0730
[0x003140E0] : 10670D50
[0x003140E4] : 10670D50

52EC and next 2 are nearby
this is array I mentioned
+0x10 - index variable - use it to get item from this array