Motion Detection - time for a second look ? - page 3 - General Discussion and Assistance - CHDK Forum

Motion Detection - time for a second look ?

  • 81 Replies
  • 25652 Views
*

Offline philmoz

  • *****
  • 3377
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #20 on: 30 / January / 2013, 02:16:37 »
Advertisements
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
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)

Re: Motion Detection - time for a second look ?
« Reply #21 on: 30 / January / 2013, 06:07:13 »
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 »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3377
    • 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.

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)

Re: Motion Detection - time for a second look ?
« Reply #23 on: 30 / January / 2013, 17:00:16 »
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 !


Re: Motion Detection - time for a second look ?
« Reply #24 on: 30 / January / 2013, 18:38:31 »
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.


Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3377
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #25 on: 31 / January / 2013, 04:28:15 »
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.
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)

Re: Motion Detection - time for a second look ?
« Reply #26 on: 31 / January / 2013, 08:17:03 »
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 »
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3377
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #27 on: 01 / February / 2013, 04:42:41 »
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.
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)


Re: Motion Detection - time for a second look ?
« Reply #28 on: 01 / February / 2013, 08:00:29 »
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

Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline philmoz

  • *****
  • 3377
    • 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.
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)

 

Related Topics