A smarter Reference Frame
Description of Patch
As dicussed a while ago, Motion needs a redesign of the reference frame implementation in order to properly be able to locate moving objects. I have developed a patch that addresses this problem by excluding moving objects from the background, so that the whole object appears as 'motion' all the time it is present on the scene. Motion is still able to detect it even when it stops for a while. This patch was strongly inspired by the SAKBOT project (http://imagelab.ing.unimo.it/imagelab/research_description.asp?arg=traficon
During the work on this subject, I had to modify 'smartmask' slightly. It will no longer be possible to make 'blind' areas by moving around for a while, because smartmask does not activate mask pixels during frames with motion. Another feature that needed improvement was the 'noise_tune' algorithm. The new reference frame is slight behaving different and so noise_tune algo had to be adapted as well. I can only test with BTTV cams, so testers with other types of cams are welcome.
The fact that moving objects can become static (like a parked car) can easily lead to deadlocks when we exclude them from the ref frame forever. The solution is to declare them static after a while and copy them into the background. The algo remembers these objects for another while, so that we can properly treat them when they start moving again after a while (like a person who walks in, stops for a while and then moves on).
At this early stage of testing, there are 3 variables that are worth playing with:
- in_timer: time in seconds after that an object is declared static
- out_timer: ... an object is discarded 'from memory'
- correction_factor: percentage relative to 'noise' that triggers the memory of an object (actually pixel-based).
These variables are config options until we have agreed on fixed values and before the patch is released. I recommend to start testing with the predefined values.
Finally: Be careful please! With the new ref frame, motion will most probably detect a larger amount of motion frames due to the fact that even very slow or intermittend motion is detected as continous motion flow until the in_timer accepts an object as background.
I am running this code on my production system and it works fine for me. Please give it a try and share your experience here.
Installation of Patch
Download the patch file. If it is packed as a gz or tar.gz unpack it first. Then copy it to the motion source directory and issue the command (assuming the patch file is called filename_of_patch_file.diff)
patch < filename_of_patch_file.diff
Then re-build Motion and test the patch.
Change History of Patch
I have tested it with good result. It detects motion more accurate than before. I had to turn off noise_tune as it tune it to become to sensitive. The other thing I noticed is that my outdoor cameras now is more sensitive to when clouds come in over the sun. Before it was possible to remove most of them with minimum_motion_frames, but it isn't anymore. I guess that it is for the change in light before and after the cloud comes in.
To summerise I think it works better than before, more accurate detection. The issues I have just now should be possible to solve with some tuning of the algos.
- 09 Oct 2007
I have the same results also. I also changed the noise tune to fixed value. But it is sometimes hard to be sure because weather changes day by day so I was not sure.
I have been running with locate on and this is for sure also more accurate meaning that a tracking feature will also be more accurate.
Joerg, check in your code on SVN. Then we can continue tuning on the noise tune and lightswitch algos.
- 11 Oct 2007
Thank you for testing. I have done some modifications that I would like to test one more day before I check it in. But I will upload the latest patch here in a minute.
- 11 Oct 2007
Patch committed into SVN r229.
- 12 Oct 2007
The patch is itegrated into SVN, but I will share some thoughts with you.
I'm still fixing things: The new algo needs to consider feedback from cnt->imgs.out - this is under study. Another issue that could be supressed with 'minimum_motion_frames 2' in the past is reinforced with the new algo: fast passing clouds on sunny days and camera brightness changes. I will take care of that soon. I'm thinking of a little magic in the main loop like: if - at the beginning of an event - the number of motion pixels is constant and the center of motion doesn't move -> supress it.
- 14 Oct 2007
I'm currently working on this brightness-change-supress-thingie. I call it micro-lightswitch. I'm going to check it in so that everybody can check if it really improves this kind of misbehaviour. It should also help, when light is beeing switched on or off, but the area that changes illumination is way too small to trigger the regular lightswitch option.
- 24 Oct 2007
A new version of the reference frame algo has just been commited into SVN. It is working well in my environment but it still has some minor limitations:
Under some conditions of very low light and objects that have very low contrast compared to the background, some pixels keep 'locked' when the object has already moved away from that place. They get accepted as background after a while, but they should not normally be declared as motion. I'm still doing lab tests on that.
Some general recommendations when using the new code: It works best with framerates from 2 to 5. Anything above 7 doesn't work very well - but it didn't with the old code either. When running motion with outdoor cams or very noisy equipment, I recommend using the despeckle feature. It makes detection more robust and loacting objects more accurate. The new 'micro-lightswitch' feature is always on and may cause trouble with higher framerates as well, but it's working like a charme at 2 - 5 fps.
Development is at a stage where I can recommend testing. It should perform at least as good as the old code did.
- 04 Nov 2007
...Seems that this patch is not fully implemented or not fully tested... For confirmation read here : http://www.lavrsen.dk/foswiki/bin/view/Motion/BugReport2009x07x12x162445
and see attached avi files...
- 15 Jul 2009