Feature Request: Compare current frame to earlier reference frame

Description

I am currently capturing 10fps (to try and get smooth video). I had a look at the output of motion that shows the changed pixels. Even though a large object is moving in front of the camera, the number of changed pixels remains low because the program only sees changes at the edge of the object. It would be better if the current frame was compared to a reference frame from a few seconds ago (or X number of frames ago). That way, if a car moved through the frame, the program would see the entire car as changed pixels, rather than the small amount of changes at the edges.

Right now, I have to choose between two options that aren't very good:

1. Use a low threshold to make sure I detect objects (which causes a lot of false detections).

2. Use a high threshold and miss a lot of events.

I would image you would have a config option (let's say refdelay) which would represent the delay (in seconds or frames) between the reference frame and the current frame.

There could be 3 methods of implementation:

1. You would have to keep (in memory) every frame for the past X (seconds or frames) so that you can always go back X (seconds or frames) from the current frame for a comparison. This may have implications with memory space though.

2. You could simply hold ONE reference frame every so often, Let's say the refdelay is 3 seconds. You would hold the first rame as a reference, and then compare all subsequent frames (in the next 3 seconds) to the reference frame. This uses less memory. The disadvantage is that the first few frames don't have the advantage of a large delay from the reference frame.

3. You could do a hybrid of the above two methods. Instead of storing every frame, you could store a few frames between the reference frame and the current frame. Let's say the refdelay is 3 seconds. You could store a frame every second (store 3 frames). You should always be able to find a reference frame that is 2 to 3 seconds old.

-- WaltDoern - 17 Apr 2008

Follow up

Comments

Good point Walt,

I suffer from the same problem. Setting the threshold to detect a person walking across the camera many metres away can give 'false' events when trees blow etc. (I'm not using any masks etc to minimise this effect). I think most Motion systems don't have continual motion occurring, so updates to the reference frame would be made often enough.

You might consider using a reference frame that is only updated when there is no motion (ie. not in an event). That way, changes in light level (day/night etc) and weather conditions would be handled.

Number of changed pixels could then be calculated with reference to the reference frame. I don't know how smartmask etc would interact with this idea.

Interesting, though. Simon.

-- SimonW - 29 Apr 2008

---

What version of Motion do you use? In reasent version there is a different way to calculate the ref. frame than older ones. Look at http://www.lavrsen.dk/twiki/bin/view/Motion/SmarterReferenceFramePatch.

-- DagErlandsson - 29 Apr 2008

---

I'm using version 3.2.9. Thanks for pointing to that patch. I'm having trouble deciphering the patch page to determine if 3.2.9 has it installed. I checked the source code that I have for 3.2.9 and it appears not to have that code so I'll give it a try.

I'm also having a bit of trouble deciphering what the patch does. It kinda looks like what I am seeking. It does look complicated though. My thought is that you simply grab a reference frame less often (ie a few seconds between each reference frame). It's a long enough time that you should be able to detect an entire object when it move past the camera, rather then detecting the edges of the object. The time is also short enough that things like the weather or clouds won't change in a few seconds. I'm leaning toward a simple method so as to reduce cpu because even with 10fps, I drop a lot of frames.

-- WaltDoern - 30 Apr 2008

---

There are some issues that the "complicated" patch tries to solve. The most important is, if you move into the room it detects that you are there. If you then grab a ref. frame while you are in the room and you move out, it detects motion as there is a difference between the ref. frame (where you are in) and current frame (where you not are). It is this situation the patch solves. Pixels that are detcted as "motion" is not updating the ref. frame right away, it waits a while. If you during this time move out you are never put into the ref. frame. This results in the things you are requesting, that it detects motion better as moving objects aren't put into the ref. frame.

-- DagErlandsson - 30 Apr 2008

---