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

Motion Detection - time for a second look ?

  • 81 Replies
  • 36196 Views
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #20 on: 30 / January / 2013, 02:16:37 »
Advertisements
Quote from: waterwingz on 30 / January / 2013, 00:23:31
I can now confirm that the RGB values don't come out correctly when the U & V values are treated as unsigned.   In particular,  the G value almost never moves much above zero.  Treating U &V as signed gives much more reasonable values for RG&B.

I've also started to notice the camera crashing while running MD testing.  Not sure if I'm overloading the display with all my updates?  ROMlog attached.


Can you add the camera model and version plus the main.dump for the build.

Phil
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #21 on: 30 / January / 2013, 06:07:13 »
Quote from: philmoz on 30 / January / 2013, 02:16:37
Can you add the camera model and version plus the main.dump for the build.
A1200 1.00c  (my sacrificial testing camera)

Update :
  • The dump I posted above was with my debugs to print  YUV & RGB to the screen continually wih draw_string().  I was able to get a second crash right away - dumps look identical  (crash1.zip)
  • I removed the debugs and rebuilt with the patch file I posted most recently.  Still crashes eventually (crash2.zip) but dump is different than above.
  • I've noted that with a larger grid (eg 9x9),  I'm still getting the "red flashing boxes & numbers" that I thought I had fixed.  That means that the motion_detector->curr and motion_detector->prev pointers are being swapped while the boxes are being draw. Just less often due to the interlock I added with the second patch file.   
    I'm assuming that md_draw_grid() is occasionally getting preempted and md_detect_motion() gets to run - changing the buffer that md_draw_grid() was using.   So I moved the interlock into the inner display loop to right before the actual draw_rect & draw_string calls and that seems to kill the flashing (again). I'm unable to get it to crash any more either. 
Worrysome.

(Note : these are from the dev 1.2 trunk so I assume the file you need is main.bin.dump ?)
« Last Edit: 30 / January / 2013, 11:39:06 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #22 on: 30 / January / 2013, 16:25:42 »
I get occasional crashes when the MD script ends, which appear to be a timing problem between unloading the module and the grid draw code. Will look into it.

Took a closer look at the MD code and all I can say is - yikes!

The u,v,r,g & b detect will only work if the viewport width is evenly divisible by the number of columns (my fault, a bad optimisation done last year). This may be the cause of some of the phantom detects.

The curr,prev,buff1,buff2 & points stuff is overkill and not needed. All it needs is the prev array of ints and a diff array of unsigned chars for the draw grid routine.  I've tested this and will post updated code tonight. This also uses 7k less memory.

Finally the motion_detector memory doesn't need to be malloced anymore. This was done to save memory if MD was not being used; but since the whole thing is a module now this isn't required.

Phil.

Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: Motion Detection - time for a second look ?
« Reply #23 on: 30 / January / 2013, 17:00:16 »
Quote from: philmoz on 30 / January / 2013, 16:25:42
yikes!

The u,v,r,g & b detect will only work if the viewport width is evenly divisible by the number of columns

Glad you mention that.
I was looking at the code yesterday and wondered what happened with seven columns !
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #24 on: 30 / January / 2013, 18:38:31 »
Quote from: philmoz on 30 / January / 2013, 16:25:42
The curr,prev,buff1,buff2 & points stuff is overkill and not needed. All it needs is the prev array of ints and a diff array of unsigned chars for the draw grid routine.  I've tested this and will post updated code tonight. This also uses 7k less memory.
One thing I wanted to try next was to add a "range" variable per grid cell - something to use for storage of a measured "baseline" variation in each cell.  Not sure how well it will work but the idea would be to take several readings when first called to determine how much variation is in the background scene and then only trigger when a cell deviated more than that variation (plus the sensitivity value).  I guess it could be an added detection mode enabled by a parameter in the function call.


Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #25 on: 31 / January / 2013, 04:28:15 »
Quote from: waterwingz on 30 / January / 2013, 18:38:31
Quote from: philmoz on 30 / January / 2013, 16:25:42
The curr,prev,buff1,buff2 & points stuff is overkill and not needed. All it needs is the prev array of ints and a diff array of unsigned chars for the draw grid routine.  I've tested this and will post updated code tonight. This also uses 7k less memory.
One thing I wanted to try next was to add a "range" variable per grid cell - something to use for storage of a measured "baseline" variation in each cell.  Not sure how well it will work but the idea would be to take several readings when first called to determine how much variation is in the background scene and then only trigger when a cell deviated more than that variation (plus the sensitivity value).  I guess it could be an added detection mode enabled by a parameter in the function call.


Attached is a re-work of the motion_detector code (trunk version). This include the cell difference display in the top left corner of each cell.

It works more reliably in my testing and so far I haven't had any crashes (touch wood).

I'll commit this if there are no problems found.

With this it would be quite easy to convert the 'motion_detector.diff' array into a ring buffer so you could store the differences from the last N frames. This might allow the values to be averaged out or other calculations done.

I'm also thinking of limiting the rows and columns values to a max of 16x16 which would reduce the maximum value needed for MOTION_DETECTOR_CELLS (currently 1024). This would save more memory and allow more frame difference buffers to be stored.

Any thoughts.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #26 on: 31 / January / 2013, 08:17:03 »
Quote from: philmoz on 31 / January / 2013, 04:28:15
Quote from: waterwingz on 30 / January / 2013, 18:38:31
Attached is a re-work of the motion_detector code (trunk version). This include the cell difference display in the top left corner of each cell. It works more reliably in my testing and so far I haven't had any crashes (touch wood).
Thanks for the help - I'll look tonight ( 12 hrs from now).
Loaded and tested.  Can't seem to break it.
« Last Edit: 31 / January / 2013, 20:48:46 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #27 on: 01 / February / 2013, 04:42:41 »
Quote from: waterwingz on 31 / January / 2013, 08:17:03
Quote from: philmoz on 31 / January / 2013, 04:28:15
Quote from: waterwingz on 30 / January / 2013, 18:38:31
Attached is a re-work of the motion_detector code (trunk version). This include the cell difference display in the top left corner of each cell. It works more reliably in my testing and so far I haven't had any crashes (touch wood).
Thanks for the help - I'll look tonight ( 12 hrs from now).
Loaded and tested.  Can't seem to break it.


Added to trunk, I'll back port to release-1.1 as well.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #28 on: 01 / February / 2013, 08:00:29 »
Quote from: philmoz on 01 / February / 2013, 04:42:41
Added to trunk, I'll back port to release-1.1 as well.
In the second patch file I posted (above) I modified the two small demonstration scripts (motion.lua & motion.bas) to use :

Code: [Select]
g=3         -- draw grid (0=none, 1=grid only, 2=changes, 3=both) Can you make that change too ?

TIA

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #29 on: 02 / February / 2013, 23:44:37 »
I've added detection for viewport_buffers and active_viewport_buffer to the DryOS sig finder.
Currently only works for versions R43, R45, R47, R49 and R50.

The code in vid_get_viewport_live_fb needs to be modified to use these (see G12 for sample).
For cameras that already implement something else in vid_get_viewport_live_fb it should be tested to see which version produces the best MD speed results.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
Pages: 1 2 [3] 4 5 6 7 8 9   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal