Motion Detection too slow? - page 17 - Script Writing - CHDK Forum supplierdeeply

Motion Detection too slow?

  • 253 Replies
  • 170451 Views
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Motion Detection too slow?
« Reply #160 on: 11 / February / 2008, 13:34:16 »
Advertisements
with y'all optimizing the MD routines, do you think something like face detection will ever work? i guess so. not exactly face detection, but for example one could check for a specific range of color (caucasian white/pink skintone for example). or you can decide whether to have surveillance on either the brown dog or the white cat. hm, does that make sense to you? sounds possible.

Re: Motion Detection too slow?
« Reply #161 on: 11 / February / 2008, 16:36:11 »
To come back to the issues with digital zoom. Correcting the lib.c in platform/name/sub/ver to
Code: [Select]
        // for IXUS70_SD1000
static const long vp_h_tbl[] = {230, 195, 155, 121, 99, 77, 59}; // to platform/name/main.c
#define PROPCASE_DIGITAL_ZOOM 95        // to include/platform.h
        //

long vid_get_viewport_height() {
        long v;
        if ((mode_get()&MODE_MASK) == MODE_PLAY) return 240;
        else {
                get_property_case(PROPCASE_DIGITAL_ZOOM, &v, sizeof(v));
                return vp_h_tbl[v];
             }
}
solves the problem. Note that the table of viewport sizes I gave earlier was incorrect, it should be as follows

zf   width height
3.0  720  230
3.6  720  195
4.5  720  155
5.8  720  121
7.2  720   99
9.0  720   77
12.  720   55

Also a long standing bug in md_detect_motion.c surfaced when using this modification, due to the
small viewport/detector cell ratio. The code as it stands makes a rounding error, which is visible when
drawing the rectangles, so for certain combinations of row/columns the right and lower border are not
completely covered. This is relatively harmless. However, as soon as the resolution of
viewport and OSD are different, rounding is done in different ways and causes significant errors
in the alignment of OSD and viewport data. Can be corrected easily by increasing the resolution,
as follows in md_detect_motion()
Code: [Select]
...
      [color=red] int mdc;[/color]
...
        [color=red]mdc=MOTION_DETECTOR_CELLS;[/color]
        x_step=vp_w[color=red]*mdc[/color]/motion_detector.columns;
        y_step=vp_h[color=red]*mdc[/color]/motion_detector.rows;
...
            for(x=col*x_step[color=red]/mdc[/color];x<(col+1)*x_step[color=red]/mdc[/color];x+=motion_detector.pixels_step){
                for(y=row*y_step[color=red]/mdc[/color];y<(row+1)*y_step[color=red]/mdc[/color];y+=motion_detector.pixels_step){
...
The corresponding changes to md_draw_grid() are left as an exercise. Perhaps someone can put
these changes in the code base (together with the changes related to the immediate shoot option).

To come back to the topic, is the variability in the timings of motion detection not partly caused
by the scheduling algorithm (e.g., the gui seems to be redrawn every so often, which takes time,
and perhaps can be avoided, would improve the worst case behavior).

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Motion Detection too slow?
« Reply #162 on: 11 / February / 2008, 16:59:05 »
with y'all optimizing the MD routines, do you think something like face detection will ever work? i guess so. not exactly face detection, but for example one could check for a specific range of color (caucasian white/pink skintone for example). or you can decide whether to have surveillance on either the brown dog or the white cat. hm, does that make sense to you? sounds possible.

Well... especially if lighting doesn't change I'm sure it's possible to do at least some simple tasks like determining whether it's you or your dog drinking from the toilet.  :haha Telling two similar people apart is obviously harder, as well as identifying a person, especially when lighting, facial expressions, haircuts etc. will change.

But it could be neat to have MD do the kind of face detection which detects that something resembling a human face has appeared in the picture and then shoots before they turn away. Faces have distinct symmetrical features and I can imagine there being lightweight algorithms available for finding them since this is a really important task in modern video surveillance at public places.

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Motion Detection too slow?
« Reply #163 on: 11 / February / 2008, 17:37:07 »
The corresponding changes to md_draw_grid() are left as an exercise. Perhaps someone can put
these changes in the code base (together with the changes related to the immediate shoot option).

Indeed. But maybe the immediate shoot option should be slightly extended first, to allow continuous shoot and custom shot preview length in immediate mode. I fiddled with this yesterday (tested on a570is) by adding a new option to md_motion_detect's "parameters" (n) input to select whether the shutter should be clicked (press+release) or only pressed on immediate shoot.

This is to make it possible for a script to make use of continuous shooting modes and longer shoot preview for MD while  reacting as fast as possibles and till keeping compatibility with old scripts.

-- ----------

In trunk (297), bits from 2^0 to 2^2 were in use, I added the next one i.e. 2^3=8. The bit 2^0=1 is immediate shoot as always. This means that after my modification:

parameters=0: no immediate shoot (just like before)
parameters=1: immediate shoot is complete, with shutter press and release (just like before)
parameters=8: no immediate shoot (just like before)
parameters=9: immediate shoot is shutter press only (new behavior, script must release shutter)

Changes compared to trunk 297 were:

new function in kbd.c:
Code: [Select]
void md_kbd_sched_immediate_shoot(int no_release)
{
    kbd_int_stack_ptr-=1;// REMOVE MD ITEM
 
    // stack operations are reversed!
    if (!no_release)  // only release shutter if allowed
    {
      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
    kbd_key_press(KEY_SHOOT_FULL); // not a stack operation... pressing right now
}

add function prototype to motion_detector.c:
Code: [Select]
void md_kbd_sched_immediate_shoot();

change motion_detector.c:
Code: [Select]
enum {
    MD_DO_IMMEDIATE_SHOOT=1,
    MD_MAKE_DEBUG_LOG_FILE=2,
    MD_MAKE_RAM_DUMP_FILE=4,
    MD_NO_SHUTTER_RELEASE_ON_SHOOT=8
};

and
Code: [Select]
if( ( motion_detector.parameters&MD_DO_IMMEDIATE_SHOOT ) !=0){
    // shoot:
    md_kbd_sched_immediate_shoot(motion_detector.parameters&MD_NO_SHUTTER_RELEASE_ON_SHOOT);
}


edit: Btw, I tested the MD response time with the same setup I used before, and this didn't slow it down. Actually, quite the contrary as from 64 shots in 4 sets I didn't get anything slower than 141 ms +- 3ms. Average response was 105 ms (I think it was previously 110 ms). Fastest was still 81 ms +- 3 ms, but variations were smaller.

It's highly likely that this had something to do with CHDK settings I can't remember changing (I know I added more stuff to DoF calc before these new measurements, for instance) and not the code.
« Last Edit: 11 / February / 2008, 18:38:01 by fudgey »


Re: Motion Detection too slow?
« Reply #164 on: 11 / February / 2008, 19:11:05 »
Deleted
« Last Edit: 22 / April / 2008, 10:34:51 by Barney Fife »
[acseven/admin commented out: please refrain from more direct offensive language to any user. FW complaints to me] I felt it imperative to withdraw my TOTAL participation. Nobody has my permission, nor the right, to reinstate MY posts. Make-do with my quoted text in others' replies only. Bye

*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Motion Detection too slow?
« Reply #165 on: 11 / February / 2008, 19:16:50 »
hats off to you there :)
i guess this *could* be thrown into a new suggestion thread

Re: Motion Detection too slow?
« Reply #166 on: 11 / February / 2008, 19:23:20 »
Deleted
« Last Edit: 22 / April / 2008, 10:35:19 by Barney Fife »
[acseven/admin commented out: please refrain from more direct offensive language to any user. FW complaints to me] I felt it imperative to withdraw my TOTAL participation. Nobody has my permission, nor the right, to reinstate MY posts. Make-do with my quoted text in others' replies only. Bye

Re: Motion Detection too slow?
« Reply #167 on: 03 / March / 2008, 10:42:28 »
I see all these changes/bug fixes your doing, is there a place I can download the script without hunting though all the pages try to get bits and pieces or this script


Also does this one suffer from the same thing the motion decect script I have does?  Where sometimes it will start taking pictures for no reason even if nothing is moving.  Having me to turn off and turn back on the camera for it to stop before i load the script again.


*

Offline mx3

  • ****
  • 372
Re: Motion Detection too slow?
« Reply #168 on: 03 / March / 2008, 10:47:41 »
I see all these changes/bug fixes your doing, is there a place I can download the script without hunting though all the pages try to get bits and pieces or this script
Completed and Working Scripts ?
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Motion Detection too slow?
« Reply #169 on: 03 / March / 2008, 12:00:19 »
Also does this one suffer from the same thing the motion decect script I have does?  Where sometimes it will start taking pictures for no reason even if nothing is moving.  Having me to turn off and turn back on the camera for it to stop before i load the script again.

If you set your motion detect threshold is too small (sensitive), your camera's noise will cause it to trigger, especially when shooting at dark. Thus, you can get any MD script to shoot spuriously. Also, if you set too low trigger delay, motion detect may end up in a loop shooting until you interrupt the script (or turn off the camera).

A lot of what was discussed in this thread was to optimize speed of detection from motion happening to shutter being open, but the "trigger delay loop" problem was also solved to a great extent (by Anonymous). This may be what you mean. If a MD script you find has a pair of "get_prop 206 p" (for Digic III) or "get_prop 205 p" (for Digic II) commands in them, there's a good chance the script was designed to be more immune to trigger delay loops.

I wasn't aware any MD script would require turning the camera on/off; just interrupting the script by a full-shutter press should be enough, shouldn't it?

 

Related Topics