Motion Detection - time for a second look ? - page 5 - General Discussion and Assistance

philmoz

3450

Re: Motion Detection - time for a second look ?

« Reply #40 on: 05 / February / 2013, 14:09:10 »

Advertisements

Quote from: waterwingz 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.

It doesn't affect actual MD detection on my cameras; but it does slow down the display refresh rate if you use many cells. This means you might not actually see the value displayed for the cells that trigger as it doesn't refresh in time.

In my patch I also calculate and display the time spent in the md_draw_grid and md_detect_motion code, along with the time between calls to each function (first two lines on screen).

On my cameras the time between calls to md_detect_motion is always 10 meaning it is being called each cycle of the keyboard task loop (it takes <10ms to execute each time).

Unless I've got this code wrong somewhere this would also prove that the camera is doing pre-emptive task switching (at least on my cameras) - md_draw_grid doesn't sleep while it's generating the display.

Not displaying the '0' cell differences might be a good idea, as it would then focus on the changing areas.

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)

waterwingz

12138

Re: Motion Detection - time for a second look ?

« Reply #41 on: 05 / February / 2013, 14:34:56 »

Quote from: philmoz on 05 / February / 2013, 14:09:10

Unless I've got this code wrong somewhere this would also prove that the camera is doing pre-emptive task switching (at least on my cameras) - md_draw_grid doesn't sleep while it's generating the display.

I came to the same conclusion with the USB remote sync code on my G10. That sits in a tight loop waiting for the 5V to go away and yet the little task I added to blink the LED on the power button keeps running. Which also explains some of the variability in sync accuracy.

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: Motion Detection - time for a second look ?

« Reply #42 on: 05 / February / 2013, 16:42:01 »

Another idea that occurred me on the train this morning.

What about a detection method that averaged the Y values from each of the 4 viewport buffers, at each sampled location, instead of just using what we hope is the 'most recent' buffer?

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)

waterwingz

12138

Re: Motion Detection - time for a second look ?

« Reply #43 on: 05 / February / 2013, 16:52:21 »

Quote from: philmoz on 05 / February / 2013, 16:42:01

What about a detection method that averaged the Y values from each of the 4 viewport buffers, at each sampled location, instead of just using what we hope is the 'most recent' buffer?

I had a similar thought on the weekend - just check all four buffers. Wasn't sure what that would do the the processing load and memory needed though.

I assume you meant to get separate averages per grid box per buffer and check each for a change ? Not to average all four buffers and then check for a change?

« Last Edit: 05 / February / 2013, 16:54:06 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: Motion Detection - time for a second look ?

« Reply #44 on: 05 / February / 2013, 17:07:12 »

Quote from: waterwingz on 05 / February / 2013, 16:52:21

Quote from: philmoz on 05 / February / 2013, 16:42:01
What about a detection method that averaged the Y values from each of the 4 viewport buffers, at each sampled location, instead of just using what we hope is the 'most recent' buffer?
I had a similar thought on the weekend - just check all four buffers. Wasn't sure what that would do the the processing load and memory needed though.

I assume you meant to get separate averages per grid box per buffer and check each for a change ? Not to average all four buffers and then check for a change?

I was thinking of just averaging all four buffers into one value each cycle so no additional memory would be required. Additional processing time would be required - need to test it to see how bad it would be (probably similar to calculating R or B).

Quote from: waterwingz on 05 / February / 2013, 08:39:25

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.

The SX30 and SX40 produce similar results to the G12.
Not sure why the G1X is faster - probably has something to do with the refresh rate of the viewport data from the sensor.

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)

srsa_4c

4451

Re: Motion Detection - time for a second look ?

« Reply #45 on: 05 / February / 2013, 17:21:12 »

Quote from: philmoz on 05 / February / 2013, 16:42:01

4 viewport buffers

Just a note: the buffer count used to be 3, even in earlier DIGIC 4 cameras. CHDK doesn't currently know the number of buffers.

Logged

waterwingz

12138

Re: Motion Detection - time for a second look ?

« Reply #46 on: 05 / February / 2013, 17:21:53 »

Quote from: philmoz on 05 / February / 2013, 17:07:12

I was thinking of just averaging all four buffers into one value each cycle so no additional memory would be required. Additional processing time would be required - need to test it to see how bad it would be (probably similar to calculating R or B).

I think I'd gladly trade off the maximum number of grid cells (so as to lower the memory footprint) in exchange for checking all four buffers independently.

I realize now that's what I was doing anyway with the timing tests mentioned in my previous post ( http://chdk.setepontos.com/index.php?topic=9366.msg96601#msg96601).

Quote

Not sure why the G1X is faster - probably has something to do with the refresh rate of the viewport data from the sensor.

That would be my guess too.

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12138

Re: Motion Detection - time for a second look ?

« Reply #47 on: 05 / February / 2013, 17:22:49 »

Quote from: srsa_4c on 05 / February / 2013, 17:21:12

Just a note: the buffer count used to be 3, even in earlier DIGIC 4 cameras. CHDK doesn't currently know the number of buffers.

Thanks for that. I was using my A1200 for testing but intended to go back and look at the G10 and SD940 when I had a minute.

Depending on what comes out of this discussion, as I mentioned in my first post of this thread, we need to document better how to implement this.

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12138

Re: Motion Detection - time for a second look ?

« Reply #48 on: 05 / February / 2013, 19:34:49 »

Testing results for A1200 using philmoz AF LED timing code.

1) As currently in the autobuild with incorrect *vid_get_viewport_live_fb() function - values all over the map from 20 msec to 160 msec.

2) With fixed "classic" version of *vid_get_viewport_live_fb() - 70 - 80 msec on average.

3) Using new sigfinder and G12 code - 30 msec average ( readings from 20 msec to 60 msec but mostly 30 msec).

New sigfinder and G12 code with different index offsets (average readings) :
viewport_buffers[(active_viewport_buffer-0)&3] = 160 msec
viewport_buffers[(active_viewport_buffer-1)&3] = 30 msec
viewport_buffers[(active_viewport_buffer-2)&3] = 70 msec
viewport_buffers[(active_viewport_buffer-3)&3] = 110 msec

Results 2 & 3 confirm my observation from yesterday that the two versions of *vid_get_viewport_live_fb() seem to run 180 degrees out of phase.

Incidentally, I found this old forum thread interesting : Those 100ms lightning motion detection models, which are they?

Update :

G10 - most common response time =30msec, 20 & 40 msec are next most common, occasional readings of 10 and 50 mSec.
IXUS120_SD940 - consistent 50 mSec response time, occasional 40 mSec and 60 mSec values.

« Last Edit: 07 / February / 2013, 00:06:37 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: Motion Detection - time for a second look ?

« Reply #49 on: 06 / February / 2013, 07:18:08 »

Quote from: waterwingz on 05 / February / 2013, 19:34:49

Incidentally, I found this old forum thread interesting : Those 100ms lightning motion detection models, which are they?

I was thinking about this - one of the problems with current cameras is the relatively long delay after the full shutter press to the actual shutter activation.

To close the gap I wonder if we could put a hook in wait_until_remote_button_is_released to wait for the motion detector instead of the remote trigger?

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)