type tracking improved 2

able to better track the type using tug-of-war. when the object at the head of the worm is classified as a car, the tug-of-war is pushed 0.5 positive. when the object is a person, it's pulled -1. the overall type of the worm is car if the cars are winning, person if the people are winning. this works because people tend to jump classification a lot, and cars tend to stay classified as cars. another approach would be to change the ratio for dividing people vs. car classification. we suspect this will become more important when the foreshortening calibration calculation is actually used in classification. -ation -ation -ation.

type tracking improved

type history is implemented. the type of a worm can change during the video, but it's still recognized as the same worm. the final type of the worm is the average over the history of the worm. this doesn't work very well. everything ends up being categorized as a car. viewing the types updated frame-by-frame it doesn't appear this way though. further investigation is necessary.

the indicator box sometimes lags behind the moving blob. the blob joining might not be updating the blobs correctly. we haven't been able to find the documentation for the CopyEdges() function in OpenCV, but that's probably where the problem is.

worm tracking

worm tracking has been slightly improved. objects are tracked across the screen and not broken up into many smaller objects. there is even a part where two objects overlap, but they keep the correct object ID.
classification has not improved yet. the code has been written for foreshortening calculation. we are running tests to see the best threshold for the adjusted size.
unfortunately, we still have no way of posting the videos.

time to refine

we shot more footage over the weekend and ran our algorithm on it. this time we were in regents parking lot. the first set of videos was unusable because there were some branches in the way. we relocated and took a second set of videos which looked fine.
after running our current code on the second set, we found that the algorithm is currently making the assumption that car size would be the same. we had avoided using size in determining the type of a blob, but getting the blob in the first place relied on it being a particular size. because of this, we created some goals and compromises:

1. better classification
1. using object size with correction for foreshortening
2. better object tracking
1. be more forgiving when an objects class changes, call it the same object
2. keep a history of the objects class at each frame and use that to update the overall class
3. video will be shot from AP&M only until algorithm can be generalized
   

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).