Frame difference is arguably the simplest form of background subtraction. The current frame is simply subtracted from the previous frame, and if the difference in pixel values for a given pixel is greater than a threshold Ts, the pixel is considered part of the foreground.
Figure 2 shows the frame difference method applied to the test video. Non-black pixels are foreground pixels.
Figure 2. Frame difference output
As can be seen, a major (perhaps fatal) flaw of this method is that for objects with uniformly distributed intensity values (such as the side of a car), the interior pixels are interpreted as part of the background. Another problem is that objects must be continuously moving. If an object stays still for more than a frame period (1/fps), it becomes part of the background.
This method does have two major advantages. One obvious advantage is the modest computational load. Another is that the background model is highly adaptive. Since the background is based solely on the previous frame, it can adapt to changes in the background faster than any other method (at 1/fps to be precise). As we'll see later on, the frame difference method subtracts out extraneous background noise (such as waving trees), much better than the more complex approximate median and mixture of Gaussians methods.
A challenge with this method is determining the threshold value. (This is also a problem for the other methods.) The threshold is typically found empirically, which can be tricky. This is where MATLAB's powerful visualization tools come in handy.
Instead of running the m-file for a series of values and examining the output (a possibly time-consuming exercise), I decided to whip up a simple MATLAB gui (m-file). As shown in Figure 3, the GUI allows you to change the threshold value and see the resulting output. Using the GUI, I was able to quickly zero in on the threshold that gave the best looking output.
For this example, a GUI probably didn't save too much time. But when more variables are involved (as is the case with other methods), doing quick and dirty optimization with a GUI (at least for a first order approximation) can save considerable time. In addition, a GUI can be a good way to "visually debug". In my personal experience, looking at what's happening to the pixels can often tell you where your code is malfunctioning quicker than looking through the code
If you'd like to experiment further with the frame difference method, the m-file can be found here.