Motion Detection - time for a second look ? - page 4 - 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
  • 36195 Views
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #30 on: 03 / February / 2013, 13:05:43 »
Advertisements
Quote from: philmoz on 02 / February / 2013, 23:44:37
I've added detection for viewport_buffers and active_viewport_buffer to the DryOS sig finder.
I have one camera that will work with this (A1200) so I decided to try it out.  Added some debugs to display to the LCD using the code at the bottom of main.c.

The first thing I found out is that the current version of  vid_get_viewport_live_fb() for the A1200 always returns 0 .   Bad porting job - the MD code just defaults to vid_get_viewport_fb().

So I added some code to the spytask to scan RAM from 0x1000 to 0x3000 looking for the address returned by vid_get_viewport_fb() and found the three locations.  That's pretty much what the A2200 code comments told me to expect.  Added another debug and found that only one of those three seemed to change in with shooting mode active.

Success - I have a new vid_get_viewport_live_fb() for the A1200 1.00c   :

Code: [Select]
void *vid_get_viewport_live_fb() {              // lifted from a2200 1.00b
    return (void*)(void*)(*(int*)(0x20F8)); // Possible addresses (20F8, 214C, 28C0)
}
Not so good for the 1.00b version though as I don't have the camera so don't have an easy way to find the right value for that camera.  I'll ping some of the beta testers and see if they will run some custom code for me I guess.

My next test was to compare my new vid_get_viewport_live_fb() to the value the new sigfinder and G12 based code finds.   Both routines turn out to rotate through the same four buffer addresses in shooting mode.  So far so good.

However,  the address returned by each routine at the same point in time is different.  I added a debug to simply subtract the two values and display the result in real time.   I get the seven difference values you would expect ( all multiples of 0x3f480 - I assume that's the buffer size).  This indicates random sync differences between the two routines I think ( unless the buffer addresses change while I'm calculating the difference between them - seems unlikely).

So I have now have two ways to find vid_get_viewport_live_fb() but they return different results (same buffer list - different buffer at any point in time).    Not sure where to go next with this - just go for empirical testing and see which one comes out faster?

Update :   just realized I should be able to modify the MD code to use both routines and then see which one is quicker to pick up on a change.  Having reyalp's "flash the autofocus LED to trigger the test" might be something to look at now ....
« Last Edit: 03 / February / 2013, 13:15:16 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #31 on: 03 / February / 2013, 17:00:43 »
Quote from: waterwingz on 03 / February / 2013, 13:05:43
Quote from: philmoz on 02 / February / 2013, 23:44:37
I've added detection for viewport_buffers and active_viewport_buffer to the DryOS sig finder.
I have one camera that will work with this (A1200) so I decided to try it out.  Added some debugs to display to the LCD using the code at the bottom of main.c.

The first thing I found out is that the current version of  vid_get_viewport_live_fb() for the A1200 always returns 0 .   Bad porting job - the MD code just defaults to vid_get_viewport_fb().

So I added some code to the spytask to scan RAM from 0x1000 to 0x3000 looking for the address returned by vid_get_viewport_fb() and found the three locations.  That's pretty much what the A2200 code comments told me to expect.  Added another debug and found that only one of those three seemed to change in with shooting mode active.

Success - I have a new vid_get_viewport_live_fb() for the A1200 1.00c   :

Code: [Select]
void *vid_get_viewport_live_fb() {              // lifted from a2200 1.00b
    return (void*)(void*)(*(int*)(0x20F8)); // Possible addresses (20F8, 214C, 28C0)
}
Not so good for the 1.00b version though as I don't have the camera so don't have an easy way to find the right value for that camera.  I'll ping some of the beta testers and see if they will run some custom code for me I guess.

My next test was to compare my new vid_get_viewport_live_fb() to the value the new sigfinder and G12 based code finds.   Both routines turn out to rotate through the same four buffer addresses in shooting mode.  So far so good.

However,  the address returned by each routine at the same point in time is different.  I added a debug to simply subtract the two values and display the result in real time.   I get the seven difference values you would expect ( all multiples of 0x3f480 - I assume that's the buffer size).  This indicates random sync differences between the two routines I think ( unless the buffer addresses change while I'm calculating the difference between them - seems unlikely).

So I have now have two ways to find vid_get_viewport_live_fb() but they return different results (same buffer list - different buffer at any point in time).    Not sure where to go next with this - just go for empirical testing and see which one comes out faster?

Update :   just realized I should be able to modify the MD code to use both routines and then see which one is quicker to pick up on a change.  Having reyalp's "flash the autofocus LED to trigger the test" might be something to look at now ....


Look forward to seeing the results - using the AF led is an interesting idea, might allow you to calculate the MD detect time without actually needing to record an image (using test mode).

A tip if you need to save values in the module code (e.g. store a get_tick_count() value in the MD code) that you want to use in the core code (display in spytask). I find the easiest way to do this is add entries to the end of the camera_info structure. Both the module and core code can access these without needing to add stuff to the module exporlist.

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 #32 on: 03 / February / 2013, 17:15:35 »
Quote from: philmoz on 03 / February / 2013, 17:00:43
Look forward to seeing the results - using the AF led is an interesting idea, might allow you to calculate the MD detect time without actually needing to record an image (using test mode).
Experimenting now.  Converted the motion_detector struct to a four element array so that I work with all four buffers.  Its possible that the fastest detection might actually involve being one buffer behind the vid_get_viewport_live_fb() pointer.  Of coarse I suppose I need to validate the order in which the buffers are used too.   So much to learn ...

Quote
A tip if you need to save values in the module code (e.g. store a get_tick_count() value in the MD code) that you want to use in the core code (display in spytask). I find the easiest way to do this is add entries to the end of the camera_info structure. Both the module and core code can access these without needing to add stuff to the module exporlist.
Thanks for the tip - it will come in handy.  I'm currently doing it the lazy way though - draw_txt_string()'s embedded in the md_detect_motion() function.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #33 on: 03 / February / 2013, 17:31:18 »
Quote from: waterwingz on 03 / February / 2013, 17:15:35
Quote from: philmoz on 03 / February / 2013, 17:00:43
Look forward to seeing the results - using the AF led is an interesting idea, might allow you to calculate the MD detect time without actually needing to record an image (using test mode).
Experimenting now.  Converted the motion_detector struct to a four element array so that I work with all four buffers.  Its possible that the fastest detection might actually involve being one buffer behind the vid_get_viewport_live_fb() pointer.  Of coarse I suppose I need to validate the order in which the buffers are used too.   So much to learn ...

The code I used in my camera versions is to use active_viewport_buffer - 1 - assuming that's the most recently filled buffer not the one currently being filled.

Although looking at the code now I see I'm also anding the result with 3, assuming there's only four buffers. Not sure how valid that assumption is.

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 #34 on: 03 / February / 2013, 17:40:17 »
Quote from: philmoz on 03 / February / 2013, 17:31:18
The code I used in my camera versions is to use active_viewport_buffer - 1 - assuming that's the most recently filled buffer not the one currently being filled.
Notice that.  But it got me wondering if the buffers are used sequentially and if so in a 0,1,2,3 order or 3,2,1,0 order ? The fact that the "old buffer pointer method"  and the "new sigfinder & G12 code" method don't track together makes me wonder too.

Also, how often does the buffer change ?   I'll try tracking both buffer pointers into a RAM log from the kbd task and see what I learn.

Quote
Although looking at the code now I see I'm also anding the result with 3, assuming there's only four buffers. Not sure how valid that assumption is.
Watching the values stored in 0x20F8 gives me four different buffer addresses.  I get the same addresses with the new sig finder & G12 code.   So for the A1200 at least, it seems to be a good assumption.

« Last Edit: 03 / February / 2013, 19:00:00 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline JackDaniel Davis

  • *
  • 1
Re: Motion Detection - time for a second look ?
« Reply #35 on: 03 / February / 2013, 23:21:51 »
Let me apologize beforehand if this is not posted in the correct place....

I was looking at the parameters for Motion Detection...does the "c" mean that I can program a color brightness so it would (for instance) ignore red and photo motion of a blue object? The reasson I ask is that I want to be able to "frame" my aerial photographs and thought if the settings were color specific i could put colored lamps or pieces of colored cloth on the ground to get the compositon I was seeking.

also

Can the rows and columns be masked so that only 'right to left' movement will be photographed and 'left to right' will be ignored? Thbis is just a random question and I do not have a specific use for it ... but it might be useful for recording the flow of traffic at different times of rush hour to spot anomalies.

Let me know if this belongs in another area. I am just learning this navigation..<G>

Thanks

JackDaniel

..
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: Motion Detection - time for a second look ?
« Reply #36 on: 04 / February / 2013, 09:12:07 »
Quote from: JackDaniel Davis on 03 / February / 2013, 23:21:51
Let me apologize beforehand if this is not posted in the correct place....
This is as good a place as any.  Things are pretty informal on this forum - the only request is not to post the same question in multiple threads.

Quote
I was looking at the parameters for Motion Detection...does the "c" mean that I can program a color brightness so it would (for instance) ignore red and photo motion of a blue object? The reasson I ask is that I want to be able to "frame" my aerial photographs and thought if the settings were color specific i could put colored lamps or pieces of colored cloth on the ground to get the compositon I was seeking.
The motion detection code in CHDK is not very sophisticated (especially compared to things like the face tracking mechanism built-in to some cameras).  It basically looks for changes in average brightness on the camera's LCD display.  It can subdivide the screen area into a grid - allowing you to ignore some parts of the display and you can specify what brightness measure is used  ( Y, U, V, R, G B ).     For your application,  you might be able to make your "targets" large enough to cause a change in the Blue channel but I would bet you might have trouble getting a big enough shift relative to normal variation.  Don't forget that there will be blue content in everything the camera sees - and its not a "sharp" bandpass filter.

Quote
Can the rows and columns be masked so that only 'right to left' movement will be photographed and 'left to right' will be ignored? Thbis is just a random question and I do not have a specific use for it ... but it might be useful for recording the flow of traffic at different times of rush hour to spot anomalies.
You can write a script that waits for motion and then checks which cell(s) the motion occurred in.  It would then wait for more motion and detect what cell(s) that occurred in.  With some sort of clever algorithm you might be able to detect the average direction of the motion.  But again, I'm not sure how well it would work - you can't really track an individual object through a cell.

I guess the short answer is "Try it and see" for both questions.  But don't count on it working very well.  Sorry.


Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #37 on: 05 / February / 2013, 02:54:47 »
There is a performance hit when displaying the cell difference value in MD.

Timings on my G1X:
10x10 grid - grid display takes <10ms, cell diff takes 30ms.
20x20 grid - grid display takes 10-20ms, cell diff takes 130ms.

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 philmoz

  • *****
  • 3450
    • Photos
Re: Motion Detection - time for a second look ?
« Reply #38 on: 05 / February / 2013, 05:29:52 »
I've created a patch (attached) that adds a test mode for the MD code using the AF assist LED.
This patch is for the trunk (1.2) version. It's experimental so no guarantees it will work on other cameras.

The primary goal here is to help find the best code for vid_get_viewport_live_fb.

To use this you will need to:
- define CAM_AF_LED in platform_camera.h. This is the 'led' parameter value to camera_set_led that controls the AF assist LED.
- enable the OPT_MD_AF_LED_TUNING value in buildconf.inc (or localbuildconf.inc)
- do a full rebuild of CHDK.

When enable this runs extra code in the MD action stack that:
- turns on the AF led 1 second after the MD starts
- times how long after the led is turned on to when the MD triggers
- displays values on the screen (see the code in main.c). The important one is the last value on the 3rd line which is the tick count from the AF led on to the detect trigger.

It's best to run this with:
- the MD detect in test mode ('parameters' value to md_init_motion_detector set to 0) which will stop the code from taking any images (you should also disable any shoot commands in the MD script)
- the MD grid & cell display turned off (stops annoying flickering).

Test results on some of my cams (with my current code in vid_get_viewport_live_fb):
G12 - avg 50ms detect time (varies from 40 - 60ms, with occasional 70ms)
G1X - avg 30ms detect time (varies from 20 - 40ms, with occational 10ms)

I've tried other variations of vid_get_viewport_live_fb; but these are the best results I can get so far.

Edit: I've attached a test script to use with this - MD_Tune.bas. I stripped fudgeys fast MD detect script down to just the code needed for MD test mode; but you can still modify the other parameters to test different combinations.

Phil.
« Last Edit: 05 / February / 2013, 05:52:55 by philmoz »
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 #39 on: 05 / February / 2013, 08:39:25 »
Quote from: philmoz on 05 / February / 2013, 02:54:47
There is a performance hit when displaying the cell difference value in MD.
Timings on my G1X:
10x10 grid - grid display takes <10ms, cell diff takes 30ms.
20x20 grid - grid display takes 10-20ms, cell diff takes 130ms.
Does this slow dow the actual motion detection though? 

As the display is usually showing "0", I can think of some obvious ways (using a little memory) to only update when a value has changed.   Not sure its worth it though - when I get around to updating the wiki (per my first post in this thread) on tuning I'll  make a note of the perfomance hit.

Also, using debug statements and counters, I've convinced myself that the four buffers on my A1200 are used sequentially in ascending order ( 0,1,2,3 ).  The two methods of finding the buffer address both do this and they run at the same speed.  However,  they tend to go in and out of phase a bit - suggesting that they are being advanced by different tasks.

 I need to go back and look again but when I stopped work last night my first pass estimate was that each buffer is held for about 100 mSec.  That doesn't seem right as it would suggest the fastest average detection time would be about 50 mSec on average. 

Quote from: philmoz on 05 / February / 2013, 05:29:52
I've created a patch (attached) that adds a test mode for the MD code using the AF assist LED.
This patch is for the trunk (1.2) version. It's experimental so no guarantees it will work on other cameras.
Nice!  I'll have a go at it tonight.

Update : just noticed that your measured 50 mSec average response time for your G12 matches my predicted average response time.  That might just be luck - I need to do some more modelling to understand what's happening here.
« Last Edit: 05 / February / 2013, 10:33:28 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 2 3 [4] 5 6 7 8 9   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal