Better motion detection?

[mor]

Hi.

This image was impressive!

I presume, some more advanced functions like object removal and placement detections could be developed with this approach? Because you already have the ongoing "state" of the background, and can detect whether something was added or removed?

Maybe. Not 100% sure what you're looking for here. It will already detect an object being removed (that counts as 'motion'). Is that what you meant?

[agoodm]

I would like to try this, but would like to see some more information,

Specifically regarding some step by step instructions for applying the patches, then submitting the results/debugging stuffs back to you so you can analyse and improve things.

Also will this work with mocord, I am also using cameras connected to a analogue BT878 capture board, recorded at 352x288 and at 1 fps - will this pose a problem?

[overly]

Here's my experiment with the motion patch.

CAM:



Delta:



As you can see I have a lot of noise motion from the tree shadows in the afternoon hours.

It ran about 4-5 hours and seemed to be getting false triggers, but less so than the standard motion detection. When I got home the box seemed to have locked up and had to use the power switch to bring it back (no remote SSH or local shell login possible).

I examined the log and found that it never really settles out and that my averages are somewhat higher than the numbers others report.

mor, any suggestions for fine tuning? I had considered increasing the threshold value in the code up from 2.5. I really need to dig into the code to understand better how it works and what to tweak. Maybe tonight when I get home.

A little info on my setup. I have a Bluecherry PV-149 4-port capture card and one Topica TP-936WIR-30C camera configured to capture at 10 fps. I have two zones setup - one for the sidewalk and another for the yard area, because I had to reduce sensitivity in the yard area due to the shadows.

Here's a snip of my log:

Code: Select all

May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 3.960525, pixels 322 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 6.320946, pixels 349 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 6.843143, pixels 421 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 7.592459, pixels 426 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 7.825874, pixels 442 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 8.020421, pixels 411 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 8.232079, pixels 394 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 7.386624, pixels 403 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 7.260729, pixels 441 (-1, -1, -1)]
May 19 22:32:48 mythbox zma_m1[3265]: INF [Average 5.270748, pixels 413 (-1, -1, -1)]
May 19 22:32:49 mythbox zma_m1[3265]: INF [Average 5.161253, pixels 336 (-1, -1, -1)]
May 19 22:32:49 mythbox zma_m1[3265]: INF [Average 4.065164, pixels 351 (-1, -1, -1)]
May 19 22:32:49 mythbox zma_m1[3265]: INF [Average 3.897654, pixels 332 (-1, -1, -1)]
May 19 22:32:49 mythbox zma_m1[3265]: INF [Average 2.750268, pixels 299 (-1, -1, -1)]
May 19 22:32:49 mythbox zma_m1[3265]: INF [Front_Door: 712 - Gone into alert state]
May 19 22:32:50 mythbox zma_m1[3265]: INF [Average 2.836850, pixels 252 (-1, -1, -1)]
May 19 22:32:50 mythbox zma_m1[3265]: INF [Front_Door: 719 - Gone back into alarm state]
May 19 22:32:50 mythbox zma_m1[3265]: INF [Average 3.098925, pixels 302 (-1, -1, -1)]
May 19 22:32:50 mythbox zma_m1[3265]: INF [Front_Door: 721 - Gone into alert state]
May 19 22:32:52 mythbox zma_m1[3265]: INF [Average 2.870692, pixels 608 (-2, -2, -2)]
May 19 22:32:52 mythbox zma_m1[3265]: INF [Front_Door: 746 - Gone back into alarm state]
May 19 22:32:52 mythbox zma_m1[3265]: INF [Average 3.353837, pixels 615 (-2, -2, -2)]
May 19 22:32:53 mythbox zma_m1[3265]: INF [Average 3.770747, pixels 709 (-2, -2, -2)]
May 19 22:32:53 mythbox zma_m1[3265]: INF [Average 4.901636, pixels 1071 (-2, -2, -2)]

[mor]

Probably the first value to look at is to increase the Blend percentage. At 10fps you could try 3 or even 4%?


Note that it doesn't log values under 2.5. I

I also set the 'minimum number of frames to alarm' to 10 to avoid the intermittent spikes.

Re locking up: That's a new one on me. My box has never locked up. Only thing I can think of is that it ran out of memory? but the extra memory usage is pretty small.

Or does your camera regularly lose signal?

[overly]

Probably the first value to look at is to increase the Blend percentage. At 10fps you could try 3 or even 4%?


Note that it doesn't log values under 2.5. I

I also set the 'minimum number of frames to alarm' to 10 to avoid the intermittent spikes.

Re locking up: That's a new one on me. My box has never locked up. Only thing I can think of is that it ran out of memory? but the extra memory usage is pretty small.

Or does your camera regularly lose signal?

Are you referring to 'Reference Image Blend %ge' in the monitor config (mine is currently 2), or a value in the source code?

Where is 'minimum number of frames to alarm'? Are you referring to 'Alarm Frame Count' in the monitor config?

Thanks for your input. I've been poking through the source code and your patch but my eyes are still glazed over at the moment.

I'm not really all that concerned about the crash. I don't believe my camera ever loses signal. Here's the log where I believe things started to go wrong...

Code: Select all

May 19 15:46:18 mythbox kernel: Mem-info:
May 19 15:46:18 mythbox kernel: Free swap:            0kB
May 19 15:46:18 mythbox kernel: 245488 pages of RAM
May 19 15:46:18 mythbox kernel: 16112 pages of HIGHMEM
May 19 15:46:18 mythbox kernel: 4898 reserved pages
May 19 15:46:18 mythbox kernel: 2539 pages shared
May 19 15:46:18 mythbox kernel: 7 pages swap cached
May 19 15:46:18 mythbox kernel: 0 pages dirty
May 19 15:46:18 mythbox kernel: 0 pages writeback
May 19 15:46:18 mythbox kernel: 8996 pages mapped
May 19 15:46:18 mythbox kernel: 13187 pages slab
May 19 15:46:18 mythbox kernel: 2228 pages pagetables
May 19 15:46:19 mythbox zmdc[2477]: INF ['zmc -d /dev/video2' crashed, signal 8] 
May 19 15:46:19 mythbox zmdc[2477]: INF [Starting pending process, zmc -d /dev/video2] 
May 19 15:46:19 mythbox zmdc[3355]: INF ['zmc -d /dev/video2' started at 08/05/19 15:46:19] 
May 19 15:46:19 mythbox zmdc[2477]: INF ['zmc -d /dev/video2' starting at 08/05/19 15:46:19, pid = 3355] 
May 19 15:46:35 mythbox zmwatch[2522]: INF [Restarting capture daemon for Driveway, time since last capture 38 seconds (1211226392-121
1226354)] 
M

The kernel mem info repeats again and again as well as zmc being restarted. It looks as though it ran out of memory as you suggested.

[mor]

Are you referring to 'Reference Image Blend %ge' in the monitor config (mine is currently 2), or a value in the source code?

Where is 'minimum number of frames to alarm'? Are you referring to 'Alarm Frame Count' in the monitor config?

Yes and yes.

For 10fps, 2% may be on the low side. If I get time tonight, I'd try and break out some of the other parameters so you can more easily adjust them.

[overly]

I did some experimentation yesterday. I've been poking through the code and understand better what settings have an impact and which are ignored. For example only the alarmed pixel mode is evaluated, average pixel and blobs are ignored. I haven't figured out yet if "Min/Max Pixel Threshold" in the zone config still has any relevance. mor, can you comment?

I changed my fps to match what it was originally coded for - 15 fps. I was still getting false triggers so I increased Ref Image Blend to 4, 5, and eventually up to 12. I also changed Alarm Frame Count to 10. It still seemed extra sensitive and I noticed the pixel average in the log seldom stabilized below 2.5 while the shadows were active. So I increased the hard-coded pixel average limit from 2.5 up to 4.0 and it seemed to help.

I let it run overnight that way and found the box had locked up when I checked it this morning. I went back through the ZM debug logs in /tmp and found it got garbled up - probably about the time the box crashed.

Code: Select all

05/21/08 21:17:20.677149 zma_m1[24590].DB5-zm_zone.cpp/189 [Got 4 alarmed pixels, need 6845 -> 17113, avg pixel diff 0.032538]
05/21/08 21:17:20.765641 zma_m1[24590].DB4-zm_monitor.cpp/931 [RI:22, WI: 23, PF = 1, RM = 99, Step = 1]
05/21/08 21:17:20.769079 zma_m1[24590].DB3-zm_monitor.cpp/2355 [Checking active zone Sidewalk]
05/21/08 21:17:20.769240 zma_m1[24590].DB4-zm_zone.cpp/151 [Checking alarms for zone 9/Sidewalk in lines 112 -> 359]
05/21/08 21:17:20.769251 zma_m1[24590].DB5-zm_zone.cpp/153 [Checking for alarmed pixels]
05/21/08 21:17:20.769522 zma_m1[24590].DB5-zm_zone.cpp/187 [Average 0.039007, pixel_count 43376, alarm pixels 3]
05/21/08 21:17:20.769534 zma_m1[24590].DB<8E><94>¹P^X<96>þ^QµÃ

[moOd]

I've also discovered that average pixel and blobs are ignored, even after applying the latest patch by mor released on this forum.

My settings are working pretty well now. The only thing I'm getting false triggers from is all sudden changes my camera does to compensate lightning. Pretty annoying, but I can live with it..

I have about 1.5 - 2.5 fps feed
Ref Blend = 14
Alarm Frame Cnt = 10
Pixel Avg = 4.5

My camera view looks like this:

[overly]

I've also discovered that average pixel and blobs are ignored, even after applying the latest patch by mor released on this forum.

My settings are working pretty well now. The only thing I'm getting false triggers from is all sudden changes my camera does to compensate lightning. Pretty annoying, but I can live with it..

I have about 1.5 - 2.5 fps feed
Ref Blend = 14
Alarm Frame Cnt = 10
Pixel Avg = 4.5

Do you know what average pixel value you get when the camera adjusts to a lighting change? If significantly large enough with respect to the normal motion events perhaps you could add an upper threshold to ignore it.

Something like this:

Code: Select all

	if ( (pixel_avg > 4.50) && (pixel_avg < 20) ) {
        ...
        ...
        return( true );
        }

[moOd]

Ah, thanks! That's true.. I will try setting an upper limit.

[overly]

I've been working on some similar changes. I changed it so instead of hard-coded values it uses the Min/Max Alarm pixel values from the Zone config when comparing the average pixel value.

I have it running now for a while to see how it works. I can tweak the limits easily now rather than rebuilding the source.

[mor]

I've also discovered that average pixel and blobs are ignored, even after applying the latest patch by mor released on this forum.

My settings are working pretty well now. The only thing I'm getting false triggers from is all sudden changes my camera does to compensate lightning. Pretty annoying, but I can live with it..

The light changed should be compensated. Could you post some of the log lines around when the lighting changes? (You should see "(-8, -8, -8)" or similar values gradually decaying to zero. This is essentially the offset in the lighting values.

[moOd]

The light changed should be compensated. Could you post some of the log lines around when the lighting changes? (You should see "(-8, -8, -8)" or similar values gradually decaying to zero. This is essentially the offset in the lighting values.

Yes, I can see those values directly after a lightning change. They usually start at -12, -12, -12 or similar, and start decaying to zero.. but still, it detects that lightning change as an alarm and pix avg also shoots relatively high at that moment.

I can try to catch a lightning-change event tomorrow and post some jpgs of it here with the belonging logfile, if that's ok?

[cordel]

I think that by object removal/placement detection, SyRenity meant:
For a museum an alarm could be generated if a painting was removed for more than X amount of time, but not if someone simply walks past it and obscures it.
For an airport, an alarm could be generated it a suitcase (bomb) was added and left stationary for more than X amount of time.

This would be nice but I'm afraid we are a long way from this ability, even with what is being done in this thread, there would be much work to get to that point.

Also, with a motion detection algorithm that adapts to lighting conditions, could someone gradually overexpose a camera by using a flashlight (with variable intensity) without an event being generated?

Yes someone could gradually over expose the camera with out triggering an alarm as the system only sees pixels changing and not actual objects it has no way to know what specifically is valid or not except what fits the criteria for the zones.

[mor]

There's an updated patch at http://www.dgmo.org/zoneminder-1.23.3-motion-3.diff

The changes are:
#1. Use a multiplicative light level model. This basically means that if the image average values change by 5%, then the reference image values are also scaled 5%. (Previously, it use to use an additive model. I.e. if the ref values changed by 7, then the ref image had 7 subtracted by each pixel).

This seems to fit in better with what my cameras do; I'd be interested in feedback from others.

#2. The noise model was changed from multiplicative to additive. I.e. we subtract the noise mask rather than dividing by it.

#3. The noise mask was made stronger (see NOISE_SCALE is now 8 ).

#4. The diff values are now divided by 2 before being clamped to 8 bits. This gives a bit more resolution in the changes.

#5. The threshold value has been changed to 4.5 (from 2.5)

Most of these should be re-cast as options. I've just run short of time. One possible side effect is that the noise mask will train a little slower, but it should be more effective when it is trained.