I've seen many posts here where people are looking to do different types of motion detection inside the excellent ZM framework. I myself would like to replace ZM's motion detection algorihtm with Motion Templates from OpenCV. Unfortunately it is difficult to change ZM's motion detection because the implementation is very wrapped up with the mechanics of Monitors and Zones. In this post I propose a refactoring of ZM's motion detection out of Monitors and Zones, thus allowing pluggable motion detections. ZM maintainers, is this something you are interested in? For myself I can just hack it in. I believe this feature is of broader interest, though, and I am motivated to do a complete job (including config db and php changes) if the ZM maintainers are interested in rolling it in.
Here is an overview of my proprosal: The basic idea is to give ZM a pluggable motion detection system. One would specify a motion detection algorithm for each monitor when configuring the system. The existing motion detector would be the default algorithm. At runtime zma would use this configuration information to load the chosen motion detector implementation from a DLL (.so). This architecture allows new motion detectors to be added to binary builds after distribution.
To implement this, we'd refactor motion detection out of the Monitor and Zone classes into a new MotionDetector class. The MotionDetector class has a per-frame member function for doing per-frame processing, a per-Zone member function for detecting within the given zone, and a post-frame cleanup function. The per-Zone function would take both the zone and a per-Zone set of arguments from the configuration, preserving the current per-Zone algorthm tweaking capability. This would likely be a single option string stored in the config DB rather than the seperate algorithm specific fields there today. This impelementation is sufficient to support the current algorithm. The MotionDetection class would handle all of the DLL mechanics, and could be replaced with a hardcodded (rather than dynamically loaded) implementation.
I've prototyped most of this in the 1.24.1 code base, and need to decide where to stop. If it it just for me, I'll not bother with the dynamic loading and changing the config DB for example, the algorithm choice would be done at link time and be the same for all monitors. If the ZM maintainers want it, then I'll do the full job. Of course I'll be happy to provide diffs for those who care if not.
Please provide feedback.
-- Jack
Refactoring ZM's Motion Detection: A Proposal
Making ZM more dynamic is certainly a good thing there are several places it would be nice if things were more modular but you have to keep in mind its more than just ZMA that has to deal with zones. You also have the web frontend that has to configure it, the stats logger which logs statistics about zones. So plugin zones have to consider this which also makes the frontend and DB a bit more complex.
A more modular ZM is also wanted for additional sources (than video/jpegs) so maybe this could be a good start for other places, but most likely would result in some larger change sets which may conflict with other items.
A more modular ZM is also wanted for additional sources (than video/jpegs) so maybe this could be a good start for other places, but most likely would result in some larger change sets which may conflict with other items.