In my first attempt at this experiment I actually wrote some code that looped through every pixel in the current snapshot (“now”) and checked for changes in the brightness of the pixel since the last snapshot (“before”). If the change in brightness of that pixel was greater than a constant tolerance value, then you can assume that there was movement in that pixel. The tolerance value is determined by trial and error, a value around 10 worked best in my experiments:
//color of the current pixel in the current snapshot
nl=Math.sqrt(nr*nr + ng*ng + nb*nb)
//color of the same pixel in the previous snapshot
bl=Math.sqrt(br*br + bg*bg + bb*bb);
//difference in brightness between now and before
//there was a change in this pixel
The results were satisfactory and it did actually work to some extent (see the old-webcam SWF file below), although speed was a big problem—the larger the dimensions of the video stream the more pixels I had to check. Even a small Video object (100 pixels wide, 100 pixels high) resulted in a large ActionScript loop that looped 10,000 times to check every pixel at a regular interval. Script timeout errors were common and the program appeared to lag.
To view this content, you need the latest version of the Macromedia Flash Player.
Download the free Macromedia Flash Player now.
So, my algorithm added size restrictions to the video feed from the webcam because I had to reduce the size of the ActionScript loop; 10,000 iterations is slow and unacceptable, so back to the drawing board I go. I decided that maybe I can speed up the loop if I only check the brightness of every ten pixels in the bitmap, and it worked. However, the effect lost accuracy and didn’t detect all movement in the webcam. It was time for another solution that didn’t involve checking the brightness of pixels.