Motion Detection too slow? - page 10 - Script Writing - CHDK Forum

Motion Detection too slow?

  • 253 Replies
  • 168737 Views
*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: Motion Detection too slow?
« Reply #90 on: 06 / February / 2008, 02:33:20 »
Advertisements
I can get the source I downloaded to compile and it seems to run ok, but the internal shoot function will not run. I'm stuck.

Two things.
1st. If your non-changed compiled version does not work with internal shoot function thats could mean your compilation environment is broken/not correct.
2nd. There is a minor bug in sources related to call of internal shoot from md. The md incorrectly pops up one extra command from command stack. So, the workaround is to add some additional command to stack:
Code: [Select]
void kbd_sched_md_shoot()
{
// WARNING stack program flow is reversed

    KBD_STACK_PUSH(KEY_SHOOT_FULL);
    KBD_STACK_PUSH(SCRIPT_RELEASE);

    kbd_sched_delay(20);

    KBD_STACK_PUSH(KEY_SHOOT_FULL);
    KBD_STACK_PUSH(SCRIPT_PRESS);

    KBD_STACK_PUSH(SCRIPT_PR_WAIT_SAVE); //workaround: this command will be erroneously popped up from the stack by md
}

I've checked - thats minimal sequence does work for me.
CHDK Developer.

Re: Motion Detection too slow?
« Reply #91 on: 06 / February / 2008, 04:42:17 »
Right now - yes. Because  the internal shoot command uses "shoot" command, not "click 'shoot_full'". The "shoot" command does a lot of others actions before it clicks 'shoot_full'.
This still does not make sense to me. When "shoot_full" is read from a script, it runs an internal command. Just replace the "shoot" with what "shoot_full" does and it should be all fine and dandy. Where is the problem? If I could damn compile this source so it works I'd try it myself. But no one will will help me with the source. What I have from http://malbe.nm.ru/chdk/ compiles and runs on my A610, but the "immediate shoot" option will not work. And that's without any changes to the source.

Re: Motion Detection too slow?
« Reply #92 on: 06 / February / 2008, 04:46:09 »
Sorry I just read your post GrAnd. Still don't know what you mean. Are you saying the binaries available from http://malbe.nm.ru/chdk/ are different to what's created from the source located on the same site?

*

Offline mx3

  • ****
  • 372
Re: Motion Detection too slow?
« Reply #93 on: 06 / February / 2008, 04:52:43 »
try this.

immediate shot is implemented (no more to improve there)
also 100msecs->30msecs patch
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler


*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: Motion Detection too slow?
« Reply #94 on: 06 / February / 2008, 05:08:38 »
Are you saying the binaries available from http://malbe.nm.ru/chdk/ are different to what's created from the source located on the same site?
Maybe... I do not know. I use the latest sources from the repository.
CHDK Developer.

Re: Motion Detection too slow?
« Reply #95 on: 06 / February / 2008, 05:35:09 »
Maybe... I do not know. I use the latest sources from the repository.
I can't find anything at the repository containing the MD code. Please help me.

mx3, the firmware you posted doesn't really make a difference. The biggest difference comes from trying the different scripts. Version 5 of Barneys script allows me to get as low as 1 second delay without going into continuous shooting. Version 9 I need at least 3 seconds.

mx3, where do I get that source code please? Exact links would be very helpful.

*

Offline GrAnd

  • ****
  • 916
  • [A610, S3IS]
    • CHDK
Re: Motion Detection too slow?
« Reply #96 on: 06 / February / 2008, 05:37:02 »
Maybe... I do not know. I use the latest sources from the repository.
I can't find anything at the repository containing the MD code. Please help me.

Hmm... https://tools.assembla.com/chdk/browser/trunk/core/motion_detector.c
CHDK Developer.

Re: Motion Detection too slow?
« Reply #97 on: 06 / February / 2008, 05:43:26 »
Well I'm very embarrased. I never knew the MD routine and other changes had been added to the main trunk so never looked there. 3 days wasted for my own stupidity. Sorry.


*

Offline mx3

  • ****
  • 372
Re: Motion Detection too slow?
« Reply #98 on: 06 / February / 2008, 05:46:32 »
mx3, the firmware you posted doesn't really make a difference. The biggest difference comes from trying the different scripts. Version 5 of Barneys script allows me to get as low as 1 second delay without going into continuous shooting. Version 9 I need at least 3 seconds.
why do you mention initial delay?
we are speaking about decreasing interval between detection and shoot.
do we?
My customesed version supposed to decrease this time but not initial delay

mx3, where do I get that source code please? Exact links would be very helpful.
http://tools.assembla.com/svn/chdk/trunk for SVN client ( I'm using tortoiseSVN )
http://tools.assembla.com/chdk/browser/trunk there is a link at the bottom of  page (download as zip)


my changes where

kbd.c

void md_kbd_sched_immediate_shoot(){
 kbd_int_stack_ptr-=1;// REMOVE MD ITEM

// reversed
   kbd_sched_release(KEY_SHOOT_FULL);
   kbd_sched_delay(20);
  KBD_STACK_PUSH(SCRIPT_MOTION_DETECTOR); // it will removed right after exit from this function

// not a stack operation... pressing right now
   kbd_key_press(KEY_SHOOT_FULL);

}


motion_detector.c

void md_kbd_sched_immediate_shoot();


         if( ( motion_detector.parameters&MD_DO_IMMEDIATE_SHOOT ) !=0){
            //make shoot
//            kbd_sched_shoot();
            md_kbd_sched_immediate_shoot();
         }

and platform/a610/sub/100e/lib.c

void *vid_get_viewport_live_fb()
{
//    return (void*)0x10670d50;
   void **fb=(void **)0x52EC;
return fb[ *((unsigned char*)0x52FC) ];
}



skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

Re: Motion Detection too slow?
« Reply #99 on: 06 / February / 2008, 06:09:11 »
Tested the framebuffer mod on an IXUS70/SD1000 1.01a, using 1.01b from trunk-r285.

Address is 6FBC, so code in platform/ixus70_sd1000/sub/101b/lib.c reads

void *vid_get_viewport_live_fb()
{
    void **fb=(void **)0x6F8C;
    return fb[ *((unsigned char*)0x6F9C) ];
}

It gives consistent results, but they are not faster, more to the slower end of the spectrum.

From other posts I learn that the framebuffer when shoof(half) is pressed is not
gotten from viewport_live_fb but from viewport_fb, and that function is not changed.
Note that in the script used shoot_half is pressed when the MD routine is called.

Furthermore, there is an error in motion_detector.c,
it dumps a frame buffer of incorrect size (360x240), it should be (360x230),
apparently it uses the size of the OSD buffer (360x240), not of the viewport buffer.

W.r.t. viewport buffer size the following remark.
For the IXUS70 the size of this buffer depends on the digital zoom,
in the following way, with zf = zoomfactor,  mem_size is memory size,
digital zoom starts after optical zoom 3x.

zf   mem_size  widthxheight
1.0  ox3CA50   360x230
3.0     3CA50   360x230
3.6     336A8   300x234
4.5     28DE8   232.5x240
5.8     1FE78    182.5x240
7.2     1A1A8    148.5x240
9.0     144D8    120x231
12.       F8E8     90x236

The width and heigth are just guesses to match the size of the buffer,
and I do not understand 4.5/5.8/7.2 with those halves.

This implies that adressing of the pixels is done incorrectly
by the motion_detector.c code when digital zoon is used.

 

Related Topics