MinCostMatching may return incorrect result with infinite edges

[jvlmdr]

Note: This bug did not seem to change the results for any tracker on the MOT17 train set.

There is a small bug that can cause MinCostMatching() to return the wrong solution when there are infinite-cost edges. Minimum working example:

MinCostMatching([inf 4 2; 1 inf inf; 5 inf inf])

Expected result: (* could be 0 or 1)

   0   0   1
   1   0   0
   0   *   0

Actual result:

   0   1   0
   1   0   0
   0   0   1

From what I've seen, this bug only occurs when the optimal solution is not a perfect matching (i.e. in the example above, the largest matching contains 2 edges, not 3). It seems like it can be fixed by either avoiding the use of infinite-cost edges or by modifying this line: https://github.com/dendorferpatrick/MOTChallengeEvalKit/blob/3c7a1d66884043c1cb50253673898248c3c35b17/matlab_devkit/utils/MinCostMatching.cpp#L155 to be:

alldist[i][j] = min(INF, distMatrix[j*nOfRows + i]);

Alternatively, one could change the comparison to use < INF instead of != INF: https://github.com/dendorferpatrick/MOTChallengeEvalKit/blob/3c7a1d66884043c1cb50253673898248c3c35b17/matlab_devkit/utils/MinCostMatching.cpp#L165

This issue does not affect clearMOTMex() since it is aware of INF when it constructs the cost matrix.

It could affect IDmeasures.m, but perhaps it has no impact in practice because a perfect matching always exists.

If MinCostMatching() is used instead of Hungarian() in preprocessResult.m, then it is important to consider.