OpenTLD crashes with bounding boxes drawn successively over time

[mmhorii]

I'm running OpenTLD on a Windows 7 PC, using MS Visual Studio 2005. I can consistently crash the program if I draw bounding boxes repeatedly over a sequence of images (the target is difficult to track in the images, so the tracker cannot lock onto the target).

When the crash occurs, a window indicates that opentld.exe has stopped working. Going into the debugger, Visual Studio displays an error window with a message like this: "Unhandled exception at 0x0041f859 in opentld.exe: 0xC0000005: Access violation reading location 0x38251454." The Visual Studio debugging window indicates that the error has stopped in the EnsembleClassifier::calcConfidence method, when trying to execute the line: "conf += posteriors[i * numIndices + featureVector[i]];"

A little further investigation shows that when the crash occurs, the posteriors[] array only has memory allocated for one float, and the featureVector[] array only has memory allocated for one int. It appears that these arrays are not being initialized and properly sized, and do not contain the expected content.

[mmhorii]

Confirmed that right before crash occurs, in EnsembleClassifier::calcConfidence method, featureVector[0] is a large negative number, e.g. -842150451, as though featureVector has not been initialized. What would cause this?

[mmhorii]

Going back further into the call stack, In TLD::initialLearning(), the call to detectorCascade->ensembleClassifier->learn( ) passes in &detectionResult->featureVectors as one of its arguments. Just before the crash, I see that detectionResult->featureVectors[0] is a large negative number, i.e., it's not being initialized. What part of the code is responsible for calculating the featureVectors elements that are stored in the detectionResult object? Curiouser and curiouser...

[mmhorii]

Continuing my investigation, in TLD::initialLearning, I looked at all feature vectors that are in the detectionResult->featureVectors array. Inspection of these feature vectors that are indexed by "positiveIndices.at( ).first" pre-crash shows that some of the feature vectors have valid data in them, while other feature vectors have invalid (i.e., -842150451) values.

As an experiment, I made the following modifications to the tld::initialLearning code:

1. Determined the number of iterations (numIterations) based on how many valid feature vectors there were.
2. Changed the for-loop that calls the detectorCascade->ensembleClassifier->learn method to a while loop that keeps looping until "numIterations" feature vectors are processed.

These modifications seem to have fixed the crashing problem, but they unfortunately don't address the root cause, namely, why aren't all the feature vectors being calculated?

[mmhorii]

I believe there's a problem with the detector cascade logic, in the DetectorCascade::detect() method. As an example of what can go wrong, suppose the variance filter rejects a subwindow. In this case, the code continues to the next for-loop iteration without running the subsequent filters (ensemble classifier and template matcher), and as a result, no feature vector is calculated. Then, later in the code when the confidence value associated with this feature vector is computed, crash!

Now, in TLD::initialLearning(), after calling detectorCascade->detect(), the algorithm figures out the overlaps for the positive and negative patches, and sorts the positive indices based on their overlap values. However, this part of the code does not check, for a given positive index, if the variance filter rejected the associated subwindow, and so it may be the case that the ensemble classifier was not run (and therefore no feature vector calculated).