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

waterwingz

12139

Re: Motion Detection - time for a second look ?

« Reply #10 on: 26 / January / 2013, 19:01:52 »

Advertisements

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

FWIW .. there is seems to be an interesting long standing race condition in this code, somewhere between where md_draw_grid() is called from from gui_script_draw() and where md_init_motion_detector() is called from a script.

You can see occasional "red grid box" flashes with really high comparison numbers the first time md_draw_grid() updates after md_detect_motion() is called from a script. I added an interlock flag called motion_detector->previous_now_valid to sync things and that got rid of 95% of the "flashes". But not all.

The values displayed suggest that the motion_detector->prev[ i ] buffer has not either not been rotated or does not yet contain luminance diff values from the first pass through the code.

Not really sure why this happens but I'm thinking its an asynchronous race between the screen update and the md script execution. Another possability might be flt module loading but it doesn't seem likely.

Either way, its only slightly annoying. The display code is accessing the right buffer - the data there is just not ready yet. And its been working that way a long time - its just more obvious now. Although, it does cause me to think about reports of continuous shooting if the initial delay value (p) is zero ....

Afterthought : simple fix would be to skip any update where the difference value is greater than 256. I resisted the temptation. Also, I suspect this is a timing issue related to the use of the action stack to implement the motion detect function.

« Last Edit: 27 / January / 2013, 13:34:15 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12139

Re: Motion Detection - time for a second look ?

« Reply #11 on: 26 / January / 2013, 19:05:20 »

Quote from: reyalp on 26 / January / 2013, 18:46:56

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.

Sold !

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12139

Re: Motion Detection - time for a second look ?

« Reply #12 on: 27 / January / 2013, 12:55:58 »

I found some more motion detect ideas in a patch file posted by Lebeau almost two years ago :
http://chdk.setepontos.com/index.php?topic=650.msg60887#msg60887

This was a huge patch, with a lot of white space and bracketing format changes, also covering several changes unrelated to motion detection. So I dug out the motion detect part (attached) and would like to comment here.

Lebeau listed his changes as follow - comments after each change are mine.

= speed optimization - there were many code changes but its not clear if there were any measurable MD performance increases from these. So given the risk of introducing new bugs, I'll ignored these.

= add "wait-stability" option which, at startup, delay motion detection until 25% of user threshold is reached - this seems like a good idea to overcome the issue where the MD returns immediately when its called. However, its not hard to think of a situation (outdoors) where the background changes never get down to 25% of the user threshold.

= launch an immediate shoot as soon as a detection cell is encounter, returning the cell index location as return value - the current code processes all cells and returns if more than one has changed by more than the current threshold. This change returns after the first cell outside the threshold is detected. Seems like a good idea but some testing to determine how much difference this actually makes would be required as it means a subsequent call to md_get_cell_diff() would not allow you to check any cells that had not been processed yet.

= on immediate shooting, md_get_cell_diff() return the diff value of the triggering cell - this is probably not desireable (see previous change)

Lebeau did not mention it in his notes but he also appeared to try to patch the display scaling used by the MD code. I have not seen any complaints about this in the forum so I'm not sure how much a problem this actually is. Probably camera dependent ?

Conclusion
Having studies this, my initial suggestion would not be to set a 25% initial limit as suggested. A better mechanism might be to measure the variability in each cell when MD is started (for the specified initial delay time maybe?) and then set a kind of deadband for each cell. Subsequent changes in luminance outside of that deadband by a trigger-threshold value would then indicate detected motion. Some sort of gain factor based on overall scene luminance to scale the trigger_threshold might make sense too.

md_changes_lebeau.diff (38.56 kB - downloaded 34 times.)

Logged

Ported : A1200 SD940 G10 Powershot N G16

Microfunguy

4037

Re: Motion Detection - time for a second look ?

« Reply #13 on: 28 / January / 2013, 16:33:05 »

Deleted.

Was using old CHDK data that defined viewport width as 720.

« Last Edit: 28 / January / 2013, 21:19:24 by Microfunguy »

Logged

waterwingz

12139

Re: Motion Detection - time for a second look ?

« Reply #14 on: 29 / January / 2013, 00:02:37 »

Quote from: waterwingz on 26 / January / 2013, 19:01:52

FWIW .. there is seems to be an interesting long standing race condition in this code, somewhere between where md_draw_grid() is called from from gui_script_draw() and where md_init_motion_detector() is called from a script.

Found and fixed this. New patch file for dev trunk attached.

This technically also fixes a bug in the 1.1.0 version where the grid boxes would occasionally flash "red" even though no motion had been detected. It did not cause a false trigger. If that that make it a bug fix that can be added to the stable branch I'll submit a patch for that too.

md_detect_1-2-0_r2.patch (2.85 kB - downloaded 37 times.)

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: Motion Detection - time for a second look ?

« Reply #15 on: 29 / January / 2013, 03:31:48 »

Quote from: waterwingz on 29 / January / 2013, 00:02:37

Quote from: waterwingz on 26 / January / 2013, 19:01:52
FWIW .. there is seems to be an interesting long standing race condition in this code, somewhere between where md_draw_grid() is called from from gui_script_draw() and where md_init_motion_detector() is called from a script.
Found and fixed this. New patch file for dev trunk attached.

This technically also fixes a bug in the 1.1.0 version where the grid boxes would occasionally flash "red" even though no motion had been detected. It did not cause a false trigger. If that that make it a bug fix that can be added to the stable branch I'll submit a patch for that too.

Nice, I wonder why no one ever thought to do this before

A couple of suggestions.
- make the draw_grid value a bit mask so you can enable/disable the grid & difference display independently (0 = both off, 1 = grid on, 2 = diff display on, 3 = both on). To make this still obey the clipping rules set 'do_draw_rect = motion_detector->draw_grid' in the earlier clipping code and use do_draw_rect to test both cases.
- I tried the difference display in the upper left corner and found it less obtrusive. If you draw this first then draw the grid on top you can push the text very close to the grid edges.
- sprintf(mdbuff,"%-3d",tmp2) is more efficient as it will only ever display 3 characters (instead of 5 is the tmp2 value is 3 chars long).

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

12139

Re: Motion Detection - time for a second look ?

« Reply #16 on: 29 / January / 2013, 08:52:07 »

@philmoz : glad you liked it. Your comments are great - my thoughts below.

Quote from: philmoz on 29 / January / 2013, 03:31:48

- make the draw_grid value a bit mask so you can enable/disable the grid & difference display independently (0 = both off, 1 = grid on, 2 = diff display on, 3 = both on).

As an old assembler programmer, this was my first instinct too. But then I couldn't see anyone wanting the difference values without the grid around them to show where they were measured. But I guess its a personal style choice and doesn't cost much so I'll add it in. Thanks.

Quote

To make this still obey the clipping rules set 'do_draw_rect = motion_detector->draw_grid' in the earlier clipping code and use do_draw_rect to test both cases.

My last task before submitting for inclusion in the autobuild is to check how well it draws in various display aspect modes. I didn't change anything and I don't know that anything is wrong there but it seemed to be what lebeau was going after in part of his patch. Maybe that all went away when you cleaned up the display related code - I'll test and see.

I did test out to 32x32 (max grid size) and it worked, although the display was completely unusable. I think 9x9 might be the most you can usable try.

Quote

I tried the difference display in the upper left corner and found it less obtrusive. If you draw this first then draw the grid on top you can push the text very close to the grid edges.

Thanks for that. I originally had it left justified in the middle of the box and while I personally liked that better, I decided to put it in the middle of the box assuming most people would like that bettter. I like the upper left even better so I think I'll exercise authors prerogative and submit it that way.

Quote

sprintf(mdbuff,"%-3d",tmp2) is more efficient as it will only ever display 3 characters (instead of 5 is the tmp2 value is 3 chars long).

The "%d " was put there when I was still getting huge numbers intially. Now that I "fixed" that, "%-3d" is cleaner.

« Last Edit: 29 / January / 2013, 09:19:57 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3450

Re: Motion Detection - time for a second look ?

« Reply #17 on: 29 / January / 2013, 15:28:18 »

One other thing I noticed is that the zebra and histogram code both treat the U & V values as signed chars (which I believe is correct); but the MD code doesn't.

This could make the calculations using U & V wrong (e.g. a change from 0 to -1 would be recorded as a diff of 255, and 127 to -128 as a diff of 1).

It could also mean the RGB calculations are wrong 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)

waterwingz

12139

Re: Motion Detection - time for a second look ?

« Reply #18 on: 29 / January / 2013, 20:17:13 »

Good catch !

Quote from: philmoz on 29 / January / 2013, 15:28:18

One other thing I noticed is that the zebra and histogram code both treat the U & V values as signed chars (which I believe is correct); but the MD code doesn't. This could make the calculations using U & V wrong (e.g. a change from 0 to -1 would be recorded as a diff of 255, and 127 to -128 as a diff of 1).

A little googling tells me that U&V are typically signed. U is positive for red and negative for green. V is positive for blue and negative for yellow. So based on your observation about zebra & histogram it seems that the Canon LCD buffer works this way too. And looking at the Lebeau patch posted above, he recoded on that assumption too.

Quote

It could also mean the RGB calculations are wrong as well.

As RGB is derived from the YUV values by CHDK I guess they will be a problem too.

Having said that, I suspect the 99% of people who have played with the MD function in CHDK never get past setting it in straight luminance mode (i.e. Y only).

I'll puzzle out the unsigned to signed conversion, add some debugs and test how the MD code (before and after) responds when looking at monocolor images ( red green blue & yellow ).

« Last Edit: 29 / January / 2013, 20:58:33 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

waterwingz

12139

Re: Motion Detection - time for a second look ?

« Reply #19 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.

ROMLOG-MD_crash_1.LOG (3.46 kB - downloaded 32 times.)

Logged

Ported : A1200 SD940 G10 Powershot N G16