Motion Detection - time for a second look ? - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2 3 4 5 6 ... 9   Go Down

Motion Detection - time for a second look ?

  • 81 Replies
  • 36105 Views
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Motion Detection - time for a second look ?
« on: 25 / January / 2013, 23:12:42 »
Advertisements
Its been a while since there has been much conversation here around the CHDK motion detection feature.  However, there have been periodic postings related to the response speed and to the difficulty of tuning the various MD parameters.  So maybe its time for a new discussion about :
  • What effect does the setting each of the md_detect_motion() parameters have on speed and reliability?
  • What's the best way to tune the various parameters?
  • Is there a better motion detection algorithm that could be used? (i.e. one less affected by ambient lighting changes)
  • Can we do a better job making sure a port is using the optimal buffer configuration?
I'll start this off with a couple of follow-up posts to report on the work I've done on testing the best threshold_value setting ( parameter f in most documentation ).   

Note :  the best MD documentation is probably here : http://chdk.wikia.com/wiki/Motion_Detect_Plus  &  http://chdk.wikia.com/wiki/Motion_Detection .
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #1 on: 25 / January / 2013, 23:18:14 »
First off,  I've written a script to display on screen the change seen by the CHDK motion detect code.  The intention is to allow you to monitor how much change the code is seeing in each cell as it observes motion.  That way you can determine a good "sensitivity-factor" for you scene and lighting conditions.

The screen displayed with this script looks something like this - the numbers in green are the change reading for each cell, updated every 5 seconds :



The script has some usage limitation due to the way MD is implemented.  Each call to md_detect_motion() clears the LCD screen,  making a smooth realtime display impossible to implement. And there is no way to update the displayed value while the md_detect_motion() call is waiting.  Still,  it does let you see what the camera is seeing in luminance changes in each detection cells in semi-realtime.

Code: (Lua) [Select]
--[[
@title Motion Tester
@param f Trigger Threshold
@default f 900
@param a Columns
@default a 3
@param b Rows
@default b 3
]]

p=20        -- Trigger Delay (mSec)
c=1         -- measure mode (Y,U,V R,G,B) U=0, Y=1, V=2, R=3, G=4, B=5
d=2000      -- timeout (mSec)
e=400       -- comparison interval (msec) - less than 100 will slow down other CHDK functions
g=1         -- draw grid (0=no, 1=yes)   
h=0         -- not used in LUA
i=0         -- region masking mode: 0=no regions, 1=include, 2=exclude
j=0         --      first column
k=0         --      first row
l=0         --      last column
m=0         --      last row
n=0         -- optional parameters  (1=shoot immediate)
o=1         -- pixel step

screenwidth=360
screenheight=240
colsize=screenwidth/a
rowsize=screenheight/b

if ( get_mode() == false ) then
    set_record(1)
    while ( get_mode() == false ) do
        sleep(100)
    end
end
sleep(2000)
repeat
    for row=1,b do
       for col=1,a do
          draw_string( (col-1)*colsize+colsize/4, (row-1)*rowsize+rowsize/4, " Start.. ", 258, 263)
       end
    end
    sleep(1000)
    zones = md_detect_motion( a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p)
    for row=1,b do
       for col=1,a do
           x = md_get_cell_diff(col,row)
           draw_string( (col-1)*colsize+colsize/4, (row-1)*rowsize+rowsize/4, " "..math.abs(x).."   ", 258, 263)
       end
    end
    sleep(5000)
until (false)

I have a better implementation of this done by modifying the actual CHDK motion_detect.c code that I'll post next.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #2 on: 25 / January / 2013, 23:48:25 »
And finally,  I put together a small patch file for CHDK's built-in motion detection code.   In simple terms, it does the same thing as the script I posted above - except its built into the CHDK code itself.   There are a couple of advantages to this approach.

First of all,  the displayed values being used by the md_detect_motion() code are continuously displayed while the routine is processing/waiting.   This give a continuous update of changes in the cell luminescence levels rather than snapshots at discrete intervals like the script above.   

Secondly,  the display code is activated by changing the draw grid or "g" parameter to the md_detect_motion() function from a 0 (off) or 1 (grid) to a 2 (grid plus luminance change display).   So with a simple one line change,  existing scripts can easily add a "tuning" capability.

Finally,  the script I posted above needs to be tweaked for different LCD resolutions.  The patch file for the CHDK code does not require that.



I'll submit for inclusion to the dev & stable trunk at some point but any feedback prior to that would be appreciated.

Here's a simple script to exercise this function :

Code: (Lua) [Select]
--[[
@title Motion Tester
@param f Trigger Threshold
@default f 900
@param a Columns
@default a 4
@param b Rows
@default b 3
]]

p=20        -- Trigger Delay (mSec)
c=1         -- measure mode (Y,U,V R,G,B) U=0, Y=1, V=2, R=3, G=4, B=5
d=60000      -- timeout (mSec)
e=400       -- comparison interval (msec) - less than 100 will slow down other CHDK functions
g=2         -- draw grid (0=no, 1=yes)   
h=0         -- not used in LUA
i=0         -- region masking mode: 0=no regions, 1=include, 2=exclude
j=0         --      first column
k=0         --      first row
l=0         --      last column
m=0         --      last row
n=0         -- optional parameters  (1=shoot immediate)
o=1         -- pixel step

if ( get_mode() == false ) then
    set_record(1)
    while ( get_mode() == false ) do
        sleep(100)
    end
end

repeat
    zones = md_detect_motion( a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p)
until (false)


UPDATE :  modified patch files so that demo motion scripts have grid_mode set to "2" by default.
« Last Edit: 26 / January / 2013, 09:38:52 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #3 on: 26 / January / 2013, 12:19:29 »
I've started looking at adaptive algorithms for sensitivity adjustment.   Has anybody seen anything posted related to this ?

So far, the only CHDK related attempt I have found is this  AdaptiveMD  script.  While the script is clean and well written, its pretty old.  In fact its hard coded with propcase values for a DigicII camera and uses keyboard presses that will not be right for most cameras.

Looking at the adaptive part of the script, and using some spreadsheet modelling to explore how it works,  it seems that the script basically just adjusts the detection threshold as the camera adjusts the shutter speed.   This seems to assume the aperature and ISO stay locked - although the script does not explicitly do that for you.  There is a bit of code that also seems to slowly decrease the threshold if no motion is detected but its hard to see how effective that is (i.e. what if there is really no motion?).

For constant lighting conditions (i.e. Tv not changing) the detection threshold will converge to the following values using its simple first order averaging algorithm :

Exposure times shorter than 1/40 second lock the threshold value at 14 and exposure times longer than 1/4 second locks at 37.

So an update to this script would seem to call for just using the get_bv() function to determine scene luminance and then adding a small look-up table of threshold values for a range of bv values. 

Other ideas?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline andrewhazelden

  • **
  • 93
    • Andrew Hazelden's Blog
Re: Motion Detection - time for a second look ?
« Reply #4 on: 26 / January / 2013, 16:53:23 »
This is a great thread Waterwingz! I think it's really cool that you made a script for visualizing the CHDK motion detection settings.
Logged
Canon SD780IS
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #5 on: 26 / January / 2013, 16:58:37 »
Quote from: andrewhazelden on 26 / January / 2013, 16:53:23
This is a great thread Waterwingz! I think it's really cool that you made a script for visualizing the CHDK motion detection settings.
Thanks Andrew.  The patch to make it part of the actual md code actually works a lot better - but it has not been added to the svn yet.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14125
Re: Motion Detection - time for a second look ?
« Reply #6 on: 26 / January / 2013, 18:12:55 »
Thanks for starting this, definitely seems like a worthwhile project. My weekend looks like it will be mostly taken up by other stuff, but I'll try to play with the patch provide some more specific comments later. In the meantime, here's some random stream of consciousness...
Quote from: waterwingz on 25 / January / 2013, 23:48:25
Can we do a better job making sure a port is using the optimal buffer configuration?
One thing I've wanted to do for a long time is an MD self test: Basically, start MD, record tick count, turn on the AF led, record tick count when MD triggers. This will be subject to the 10ms resolution of tick count, but otherwise should be very consistent and comparable across cameras. The main difficulty is that the LED functions are not very consistent across cameras. Adding CHDK platform independent LED code (so you could say something like set_led(LED_AF) is another thing on my list... This should be available in the C code and script, and have some way of determining which values are valid.

Another thing semi-related to MD: Using native face detect on cameras that support it, see
http://chdk.setepontos.com/index.php?topic=8243.msg86889#msg86889

There are also some propcases that update continuously (even outside of halfshoot) depending on the scene (196 in propset 2 for example), which might be used to make a form of MD that just works on overall scene brightness and could potentially be faster than screen reading.
Quote
I'll submit for inclusion to the dev & stable trunk at some point but any feedback prior to that would be appreciated.
FWIW, this is stretching the definition of bug fix, so I'd prefer this only only go in the trunk (at least initially). That said, posting a 1.1 patch is good for people who want to try it without getting the rest of the trunk baggage.


Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #7 on: 26 / January / 2013, 18:39:08 »
Quote from: reyalp on 26 / January / 2013, 18:12:55
Quote from: waterwingz on 25 / January / 2013, 23:48:25
Can we do a better job making sure a port is using the optimal buffer configuration?
One thing I've wanted to do for a long time is an MD self test: Basically, start MD, record tick count, turn on the AF led, record tick count when MD triggers. This will be subject to the 10ms resolution of tick count, but otherwise should be very consistent and comparable across cameras.
That could be really useful but how does it beat the CRT/LCD target tests ? They all seem to work in the 10mSec resolution range. 

Meanwhile,  re-reading philmoz's posts of trial & error to find the fastest buffers has left me with the nagging idea that there must be a better way to do this. 

Quote
Another thing semi-related to MD: Using native face detect on cameras that support it, see http://chdk.setepontos.com/index.php?topic=8243.msg86889#msg86889
I guess the question is how this could be hacked to simply detect a "significant" change rather than a face, given that it appear to run all the time.

Quote
There are also some propcases that update continuously (even outside of halfshoot) depending on the scene (196 in propset 2 for example), which might be used to make a form of MD that just works on overall scene brightness and could potentially be faster than screen reading.
This would be equivalent to setting the grid to a 1:1 then ?  Probably okay in some scenerios.

Quote
Quote
I'll submit for inclusion to the dev & stable trunk at some point but any feedback prior to that would be appreciated.
FWIW, this is stretching the definition of bug fix, so I'd prefer this only only go in the trunk (at least initially). That said, posting a 1.1 patch is good for people who want to try it without getting the rest of the trunk baggage.
Understood. As I seems to be spending a bit of time each week on wikia cleanup / improvements,  I was thinking of this in terms of updating the MD docs.  No problem adding a note about the "feature" only being in the dev trunk but it reminds me a lot of those things you see that start with something like (since version 0.8.3 / changeset #593)
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14125
Re: Motion Detection - time for a second look ?
« Reply #8 on: 26 / January / 2013, 18:46:56 »
Quote from: waterwingz on 26 / January / 2013, 18:39:08
That could be really useful but how does it beat the CRT/LCD target tests ? They all seem to work in the 10mSec resolution range. 
Completely self contained, and not confused/limited by screen refresh issues, doesn't require analyzing the resulting images. In fact, you don't have to shoot, just log the difference.

This would let you do a statistically significant number of tests, which would make it much easier to verify MD improvements and characterize the response time of different settings.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14125
Re: Motion Detection - time for a second look ?
« Reply #9 on: 26 / January / 2013, 18:59:55 »
Quote from: waterwingz on 26 / January / 2013, 18:39:08
I guess the question is how this could be hacked to simply detect a "significant" change rather than a face, given that it appear to run all the time.
I don't think it can, I expect Digic hardware does the face detection stuff.... but face specific md or triggering could be useful in some cases. Exposing the number/position of faces to script would also be neat.
Quote
This would be equivalent to setting the grid to a 1:1 then ?  Probably okay in some scenerios.
Right. Not clear this would be faster than screen reading with a high step size.

Both of these are in the "possibly interesting areas to explore" category, rather than direct improvements to the current MD.
Logged
Don't forget what the H stands for.
Pages: [1] 2 3 4 5 6 ... 9   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal