Smartmask Patch

Introduction

Today motion provides a static mask to turn off sensitivity in certain areas. This is very usefull to mask a street with cars passing by all day long etc...

But imagine a scenario with large bushes and big trees where all the leaves are moving in the wind also triggering motion from time to time even with despeckle turned on. Of course you can also define a static mask here, but what if the bushes are growing during spring and summer? Well, you have to adapt the mask from time to time. What if the camera position moves slightly? What if someone grows new plants in your garden? You always have to setup a new static mask.

The Solution

The answer to this problem is smartmask. A dynamic, self-learing mask.
Smartmask will disable sensitivity in areas with frequent motion (like trees in the wind). Sensitivity is turned on again after some time of no more motion in this area. The built mask is a bit larger at the borders than the actual motion was. This way smartmask works more reliable when sudden moves occur under windy conditions.

The attached patch is only a beta version that has not yet been tested by many people! It needs some more testing before it can be used in a production environment.

Configuration

A new config option has been introduced: smart_mask_speed - it will tune slugginess of the mask.
It accepts values from 0 (turned off) to 10 (fast). Fast means here that the mask is built quick, but it is also not staying very long with no more motion. Slow means that it takes a while until the mask is built but it also stays longer. I am using smart_mask_speed 5 - works quite well so far.
This setting is independent from the framerate. The attack and decay time is constant over all available framerates.

When smartmask is enabled and motion is also configured to either write motion-images or motion-mpegs, the current smartmask is copied as an overlay into the black/white motion-pictures/mpegs in red colour. That way you can easily adjust smart_mask_speed.

Your Feedback Is Required

I invite all of you to test this patch and to report back how it behaves. I need your experience in order to be able to fine-tune the feature.

The attached version is only for 3.1.18_snap6. I have removed all previous versions on purpose because they were no longer up-to-date.

Just 'zcat smartmask-3.1.18_snap6.diff.gz | patch -p1' against a virgin 3.1.18_snap6 and have fun!

Discussion and Comments

Looks like the Makefile doen't check for dependancy of the header files.
So I had already built motion and then I patched it and so everything didn't get recompiled. So it would cause an error in /var/log/messages kernel: quickcam: Control URB error -2 and cause a segv to happen. So there are 2 ways to fix this. One would be to instruct people to do a make clean. The other would be to fix the Makefile to check to see if things need to be recompiled.
Other suggestions would be to also patch the motion-dist.conf to include a comment about smart_mask_speed option and also have it in the file and set to 0 or also just comment it out. Also what is the number in the corner that gets added to the text_changes? The line:
sprintf(tmp, "%d, %d", diffs, cnt->lastrate);//jw
fails to get added to motion.c and I added it manually. So this is the line that adds the lastrate in the corner, but what is it?

Jerry, I always do a 'make clean all' when applying a patch to motion. Maybe we can implement Per's Auto-Depedency stuff some day to make it easier.

Regarding 'motion.dist.conf': I will add smart_mask_speed with the next patch version. Thank you for this hint - I simply forgot it.

The 'number' beside the changed pixels in the upper right corner is the framerate that motion is actually capturing. It may be a bit lower than what is selected in the configuration file - depending on the load on your machine.
I have added this number to see how the framerate behaves to get an idea if I can use it for the timing of smartmask. I can now say that I will use it and the number will disappear again also with the next patch version.

Well this seems to work pretty well. I turned off my mask and the first day I set it to 5 and I would get some leaves blowing some. And then I decided to set it to 8 since that was the number in the corner. And today I would say I only got a couple of frames that didn't have motion in them and I would say that it was caused by light changes. But there is an interesting thing that happens when I get sudden light changes. The green output_motion pictures have the timestamp in them as well as the text_changes. So I wonder if there is a bug someplace in the code. It only happens with sudden light changes or maybe missed frames.

Well it snowed today. It doesn't seem do deal with snow very well since it is so random I would say. I am not sure how to turn on the mask output files. I would like to see what they look like. And maybe I went the wrong way, I read the comments again and it looks like a smaller number makes the mask stay longer?

I have uploaded a small patch - fixed_mask.diff.gz. This patch displays also the fixed mask a red overlay in the motion images.

Another nice feature: If you define a mask file, that doesn't exist, motion will automatically generate an empty (white) mask with correct width and height for you. You can simply edit this file without having to care about image size.

I moved the patch to a new patch topic FixedMaskFileOnMotionImagesPatch because it is easier for me to remember the patches from each other this way. It is for my benefit and not because of the principle. Thank you for this very nice new feature. GREAT idea to auto generate a new empty mask file. -- KennethLavrsen - 23 Apr 2005