Movement detection, in graphs

Earlier, we decided to take into account the ratio of height and width when detecting the blob types. If the height's greater than the width, then it's most likely a person. Likewise, if the width's greater than the height, then the movement is most likely from a car. We've also decided to "merge" blobs--that is, take smaller blobs near each other and combine them.

Here is a graph of the movement detected from one of the AP&M videos:



(person, walking from the right hand side of the video to the left)



(car driving from the right to the left)

In both cases, the system detected the correct type of movement. However, the system tends to get confused often. It seems like the amount of white in the differencing might be too low to detect more than small blobs. We're correcting for this for the time being by assuming that each blob is 20x20 for the purpose of tracking (the original sizes are still used for type detection). We'll continue gathering data to determine the accuracy of our algorithm.

Improved object tracking

So it turns out that L*a*b* image differencing was implemented improperly. Among other things, the limited precision of the default OpenCV types made objects appear when they shouldn't. As a result, it looked like RGB differencing performed better. I made the necessary changes to fix the tracker, resulting in this video.

In particular, the L*a*b* image differencing now takes the absolute difference of all three channels, adds them together and then smooths the result using a 7x7 Gaussian kernel. The tracking now performs slightly better than the RGB version, but judging from the results, blob merging will actually be needed after all. From what it looks like, the white blobs that appear in the difference video aren't strong enough to be detected as contiguous blobs. Thresholding, using OpenCV, results in either lots of unintended noise or nothing at all. Reducing the blob detection threshold further than we already have (it's now 25, down from 100) should produce better results.

Also, Daniel and I went out to AP&M to perform foreshortening calculations and data collection. We were able to take video from both Glen Tesler's office and from the bridge between both sections of AP&M. This resulted in the following videos:

AP&M
AP&M (2)
AP&M (3)
AP&M (4)
AP&M (5)
AP&M (6)

[The videos that are only a second or so long are intended as snapshots of Daniel on the lawn in front of AP&M]

Blob tracking

We've converted our video diffing application to use L*a*b* (as opposed to RGB). The funny thing about this is that, at least with the video I used to test, last frame minus current worked better than first minus current. It might be due to the simplicity of the video, though. We've also implemented blob tracking. Here's the links to some sample output:

Original video
Video run through our application

We're going to work on optimization over this week, and implementing blob merging and foreshadowing correction (features that are not in the current version).

for capture

i captured some video to use for foreshortening calculating. the laptop and camera were on the 5th floor bridge of ap&m. ryan underwood watched the laptop while i went down and held up a green sign. there was a bit of wind, so the sign was hard to keep in a constant state.
i captured in ppm using this line:
ffmpeg -an -s 960x720 -vcodec ppm -f image2pipe foreshortening1.ppm
and converted the result to mp4 for viewing using this line:
ffmpeg -vcodec ppm -f image2pipe -i foreshortening1.ppm -vcodec mpeg4 foreshortening1.mp4
unfortunately the resulting video has skips in it and cuts off before the entire walk is done. it seems to have enough information to be usable. using this video we can count the number of pixels representing the poster and get a ratio for each y-line.
we should also be able to calculate this ratio if we know the height and distances and use 3d projection. i expect getting that information will be just as hard and more error prone.

here's the first video
and the second.

Ground truth and algorithms

On Saturday, Daniel and I worked on a couple of really important algorithms:

1. An algorithm to combine blobs that are very close together/closely related--this is necessary to work around the poor performance of OpenCV's blob detection functionality in poor lighting conditions.
   
2. An algorithm to track blobs across frames, assuming that algorithm 1 was run on each frame. This is so we can see the trajectory of people blobs towards different cars.

Speaking of people and car blobs, I also took some additional video on Saturday from the AP&M building (looking at the Faculty Club lot). Using Nick True's labeling program, I labeled several frames from that video. They're below:

groundtruth1.png
groundtruth2.png
groundtruth3.png

(car blobs are red, people blobs are green)

From the looks of things, car blobs and people blobs are extremely similar in size, at least from that vantage point. Simply looking at the size of each won't be enough, unless the sizes of each blob are clearly distinguishable. Perhaps we can track each blob and use its rate of movement to determine which category a particular blob belongs to.

Also, OpenCV's blob detection library seems slow for real-time use (70-90ms per frame according to gprof). For the time being, we won't worry about detecting in real-time.