3.4.3 Motion Detect Algorithm Problem

dcsmith796
edited December 2014 in SecuritySpy
I upgraded SecuritySpy from 3.4 to 3.4.3 today and have run into a strange problem.

One of my cameras, an M1011W, is mounted inside the house looking out of a window. Initially, the appearance of the reflection of the room in the window glass would trigger a motion event, but once the delay option for motion detection became available in SecuritySpy it worked perfectly (no trigger) with a 1s delay.

Now, in 3.4.3, turning on the overhead lights again causes a motion detect event, even with a 4s delay (set in the web interface, since it doesn't appear in the Camera Settings dialog box). When the light comes on, it does blow out the brightness, which then takes a few seconds to normalize. However, this cam also does continuous TL, and I checked previous TL videos where I turned the lights on. It takes the exact same amount of time to normalize, it just doesn't trigger an event when running version 3.4. In addition, when I turn the light off there is almost no adjustment time, yet it also triggers an event. I even tried turning down the motion detection sensitivity, but at the point where v3.4 would somewhat effectively detect motion (about 30%) it was still triggering.

Is there something else that I can adjust to correct this, or is this just an unavoidable consequence of the new algorithm? Other than this one thing, the new algorithm seems like a definite improvement.

Comments

  • Well, of course only after I posted that did it occur to me to go and turn the lights on and off while watching the Camera Settings box (so I could observe the motion detection bar during the event). When the lights were turned on or off, the progress bar would go to it's maximum level and "hang" there before s l o w l y receding, even with the sensitivity set to 1.

    So I deleted the device and recreated it. Seems to be working now. My apologies to anyone who read through that whole thing only for me to fix it myself.
  • This kind of thing is a result of the new motion detection algorithm. An improved feature of the new algorithm (specifically the "background estimation", which estimates what the background scene comprises as distinct from transient objects moving through it), gives much more reliable motion detection in normal circumstances compared to the old algorithm. With this feature, any object that moves into the scene and quickly stops moving (e.g. a car stopping at traffic lights) will be accurately detected, which wouldn't happen with the old algorithm.

    The new algoritm does actually have a feature that should ignore whole-frame changes to avoid the kind of thing that you describe, however the threshold for this is set quite high to avoid false-negative detections of real motion, so this apparenlty isn't helping in your case. I think what you describe is just an unfortunate side-effect of the improved new algorithm in a very particular case. In general if you want a camera looking outside, the camera itself should be ouside, to avoid the kind of thing you describe, and to also ensure you get good image quality.

    I'm not sure why removing the device and adding it again should improve the situation - the new setings you are using must be different in some way to make a difference. But hopefully by doing this you have come across some settings that work well for your situation.