Accessing Motion Detection Actual Values?

waterwingz

12109

Re: Accessing Motion Detection Actual Values?

« Reply #20 on: 11 / February / 2013, 08:33:33 »

Advertisements

Quote from: Davo on 11 / February / 2013, 07:06:10

Weird thing - the AFL problem seems to have cleared itself.

Thinking about what srsa_4c posted, were you doing the test yesterday in different lighting conditions?

Quote from: Davo on 11 / February / 2013, 07:06:10

Testing is going well on the new function but it sometimes seems to hang instead of recognising the original scene levels. I am going to add a log file to capture the readouts to see where the problem is.

There may be times when it does not get back to the original scene level. You'll probably want some sort of timer to reset the baselline every so often. And another timer to unhang things if its stuck waiting for a return to baseline that never happens.

Logged

Ported : A1200 SD940 G10 Powershot N G16

Davo

Re: Accessing Motion Detection Actual Values?

« Reply #21 on: 11 / February / 2013, 14:55:45 »

Quote

Thinking about what srsa_4c posted, were you doing the test yesterday in different lighting conditions?

No. I tried all sorts of different light levels to get it to replicate but the zebra now seems sound as a bell. It did clear up after I had connected to chdkptp and got chdk to work as per a previous post.

Anyhoos, I had a good day testing the md_get_cell_abs(col,row) function and my test script is attached. It does nothing but sound the shutter when motion is detected (trigger) and beeps when the scene returns to its original state (release). It also has a timeout in case the scene doesen't return to original levels. At every event, it writes a table of original, trigger and release levels to a log file in your current capture folder. I found it to be very accurate when detecting even small birds and it only timed out a few times. Thanx mucho for this.

You can set the usual md parameters as well as the timeout duration and the 'release' threshhold level. Use this threshold to filter out scene noise. For example, a value of 15 means that all cells must return to within +/- 15 of their original levels for release to be called.

I am going to play some more with this to see why it sometimes times out but I think md_get_cell_abs(col,row) is pretty near working as is.

Dave

mdbeep.lua (3.65 kB - downloaded 36 times.)

Logged

Davo

Re: Accessing Motion Detection Actual Values?

« Reply #22 on: 12 / February / 2013, 10:21:56 »

Quote

@Davo
I compiled a version with shortcuts modified, please use REC button to enable/disable ZEBRA.

EDIT
A new version with vid_get_viewport_live_fb() implementation using viewport_buffers[] and active_viewport_buffer in attachment.

Nafraf - Sorry for the delay - big building project in garden.

I tried to install these 2 builds but I got the same problem I had with Waterwingz's build. I format a card, copy the files across, insert unlocked card in camera and start with the play button. However, the firmware update option don't show in the Canon menus. Do I need a PS.FI2 file on the card like before? If so, which one should I use?

By the by, do these builds have the md_get_cell_abs(col,row) function?

Dave

ps Zebra is still AOK with AFL off and on.

Logged

nafraf

1308

Re: Accessing Motion Detection Actual Values?

« Reply #23 on: 12 / February / 2013, 11:58:20 »

Quote from: Davo on 12 / February / 2013, 10:21:56

Nafraf - Sorry for the delay - big building project in garden.

I tried to install these 2 builds but I got the same problem I had with Waterwingz's build. I format a card, copy the files across, insert unlocked card in camera and start with the play button. However, the firmware update option don't show in the Canon menus. Do I need a PS.FI2 file on the card like before? If so, which one should I use?

Firmware update method does not work with the files that I posted. You have to use Bootable sd card method

Quote

By the by, do these builds have the md_get_cell_abs(col,row) function?

No, those build does not have md_get_cell_abs() function. Those build are modified version of trunk code. I only modified shortcuts to help you to reproduce zebra problem and modified vid_get_viewport_live_fb() function trying to solve it. But now seems that you don't have more problems with zebra.

If you want, we can continue shortcut problem discussion in a810 porting thread. SnowLeopard started the discussion and created a patch, but it was not submitted to official svn.

Logged

waterwingz

12109

Re: Accessing Motion Detection Actual Values?

« Reply #24 on: 12 / February / 2013, 13:56:49 »

Quote from: Davo on 12 / February / 2013, 10:21:56

I tried to install these 2 builds but I got the same problem I had with Waterwingz's build. I format a card, copy the files across, insert unlocked card in camera and start with the play button. However, the firmware update option don't show in the Canon menus. Do I need a PS.FI2 file on the card like before? If so, which one should I use?

I keep meaning to tell you that you do not need to format the card every time you load a new CHDK release to it. Once you have a card formatted to be bootable, you only need to unzip the CHDK distribution files to the card when you get a new version (preserving the folder structure in the zip file). This is even true if you use the card in other CHDK supported cameras - just load the correct CHDK version..

Logged

Ported : A1200 SD940 G10 Powershot N G16

Davo

Re: Accessing Motion Detection Actual Values?

« Reply #25 on: 16 / February / 2013, 06:48:33 »

Apologies for silence - just back from trip. I managed to do a dry run test before I went on a window bird feeder and it went really well. There were only a few cases when the scene did not return to original. When I inspected the numbers, i looked like 1 or 2 cells had not dropped back within the release threshold. Maybe this was due to changing light levels or maybe even an insect in the background?

One thing I have noticed is that even in steady indoor light conditions I need to use a release threshold of 5 for reliable detection of the release condition. This is while the cell differences during the detection mode are showing mostly zeros with a few 1s. Maybe the LCD settles at a slightly different exposure after every trigger event?

My next plan is to change the test script to take a foto of the original, trigger and release or timed out scene to see where the difference is.

Personally, I think the mod is good enough to use for scripting as is. However, I will run this next test to see where it breaks down. Maybe I just need to use a higher release threshold?

Dave

Logged

waterwingz

12109

Re: Accessing Motion Detection Actual Values?

« Reply #26 on: 16 / February / 2013, 09:57:13 »

Quote from: Davo on 16 / February / 2013, 06:48:33

Maybe this was due to changing light levels or maybe even an insect in the background?
Maybe the LCD settles at a slightly different exposure after every trigger event?

Keep in mind that motion detection works with the camera's LCD buffer - not the actual photo sensor. The camera makes its own decision about how bright to make the display based on what it sees on the sensor. So its quite possible the display luminance will be changed between shots. It also seem to take a few hundred milliseconds for the display to "settle" after a shot - hence the recommendation to set the "p" parameter to something like 500.

Quote

My next plan is to change the test script to take a foto of the original, trigger and release or timed out scene to see where the difference is. Personally, I think the mod is good enough to use for scripting as is. However, I will run this next test to see where it breaks down. Maybe I just need to use a higher release threshold?

I'll post the patch and see if philmoz or reyalp are okay with it.

Update : while preparing the patch file, I renamed the function to md_get_cell_val(). Seems to make more sense that way as U & V values are signed.

« Last Edit: 16 / February / 2013, 11:07:20 by waterwingz »

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3356

Re: Accessing Motion Detection Actual Values?

« Reply #27 on: 16 / February / 2013, 17:32:13 »

Quote from: waterwingz on 16 / February / 2013, 09:57:13

Quote from: Davo on 16 / February / 2013, 06:48:33
Maybe this was due to changing light levels or maybe even an insect in the background?
Maybe the LCD settles at a slightly different exposure after every trigger event?
Keep in mind that motion detection works with the camera's LCD buffer - not the actual photo sensor. The camera makes its own decision about how bright to make the display based on what it sees on the sensor. So its quite possible the display luminance will be changed between shots. It also seem to take a few hundred milliseconds for the display to "settle" after a shot - hence the recommendation to set the "p" parameter to something like 500.

Quote
My next plan is to change the test script to take a foto of the original, trigger and release or timed out scene to see where the difference is. Personally, I think the mod is good enough to use for scripting as is. However, I will run this next test to see where it breaks down. Maybe I just need to use a higher release threshold?
I'll post the patch and see if philmoz or reyalp are okay with it.

Update : while preparing the patch file, I renamed the function to md_get_cell_val(). Seems to make more sense that way as U & V values are signed.

Had a look at the patch and there is one potential issue I can see.

The trunk MD code scales the cell sizes to use all of the available screen - previously it used the same size for each cell so some values for 'rows' and 'columns' would result in unused areas at the left and bottom.

The result is that for some combinations of rows, columns and 'pixel step' the number of 'points' in each cell can vary. E.G. columns = 11, pixel_step = 3 - some cells will sample 10 points horizontally in each cell and some will get 11.

The following changes to md_detect_motion should fix it by always using the same width & height for each cell.

Code: [Select]

...
        int y_end = y_start + ((vp_h / motion_detector.rows) * vp_bw);
...

...
                int x_end = x_start + ((vp_w / motion_detector.columns) * 3);
...

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

12109

Re: Accessing Motion Detection Actual Values?

« Reply #28 on: 16 / February / 2013, 17:50:41 »

Quote from: philmoz on 16 / February / 2013, 17:32:13

Had a look at the patch and there is one potential issue I can see.

The trunk MD code scales the cell sizes to use all of the available screen - previously it used the same size for each cell so some values for 'rows' and 'columns' would result in unused areas at the left and bottom.

The result is that for some combinations of rows, columns and 'pixel step' the number of 'points' in each cell can vary. E.G. columns = 11, pixel_step = 3 - some cells will sample 10 points horizontally in each cell and some will get 11.
[=

Thanks Phil. I was actually thinking about that today - the part on line 601 of motion_detect.c where it says :

Code: [Select]

motion_detector.points = points ;fits into the category of "nasty hack". I only did that to avoid adding another array (of points values) to the struct.

I have actually modified that line to only run for in cell[0,0] on the assumption that the last cell value might be a little different depending on scaling. But if your solution gets the same row & column widths in each cell then I like that better. Although the last row / cell can't always be the same width/height as the others can it?

Logged

Ported : A1200 SD940 G10 Powershot N G16

philmoz

3356

Re: Accessing Motion Detection Actual Values?

« Reply #29 on: 16 / February / 2013, 18:08:44 »

Quote from: waterwingz on 16 / February / 2013, 17:50:41

Quote from: philmoz on 16 / February / 2013, 17:32:13
Had a look at the patch and there is one potential issue I can see.

The trunk MD code scales the cell sizes to use all of the available screen - previously it used the same size for each cell so some values for 'rows' and 'columns' would result in unused areas at the left and bottom.

The result is that for some combinations of rows, columns and 'pixel step' the number of 'points' in each cell can vary. E.G. columns = 11, pixel_step = 3 - some cells will sample 10 points horizontally in each cell and some will get 11.
[=
Thanks Phil. I was actually thinking about that today - the part on line 601 of motion_detect.c where it says :

Code: [Select]
motion_detector.points = points ;fits into the category of "nasty hack". I only did that to avoid adding another array (of points values) to the struct.

I have actually modified that line to only run for in cell[0,0] on the assumption that the last cell value might be a little different depending on scaling. But if your solution gets the same row & column widths in each cell then I like that better. Although the last row / cell can't always be the same width/height as the others can it?

The change should make all the cell sizes the same for detection (should probably make the same change to the grid display as well). The difference is only going to be one pixel variation between cells.

The start positions are still scaled to spread the cells evenly across the whole screen.

Phil.

Edit: I've fixed the motion detect to make all cells sample the same number of points (revision 2578).

« Last Edit: 16 / February / 2013, 22:33:32 by philmoz »

Logged