Fix Cost Matrix containing NaN Values in ByteTrack

[rolson24]

Description

This change fixes issue #458. The object tracker was not able to handle detections that had a bounding box area of zero. I fixed this by filtering out the bounding boxes that have an area of zero in update_with_tensors().

Type of change

Please delete options that are not relevant.

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] This change requires a documentation update

How has this change been tested, please provide a testcase or example of how you tested the change?

I tested this change by deliberately sending boxes with an area of 0 into the tracker. The tracker was able to handle this by simply ignoring those detections. Colab notebook with test code.

[LinasKo]

Hi @rolson24 :wave:

Well done isolating the error and finding the root cause!

What prompted me to dig for other solutions was the removal of class_id, boxes, etc. The algorithm downstream should be able to handle whatever comes its way, and more broadly - we had issues with similar approaches before.

There is a more concise solution, in fact. In detection/utils.py, there's a function box_iou_batch. Inside it, unsafe division is causing all of these NaN values. I reckon, instead of returning, it should first do ious = np.nan_to_num(ious).

Would you have some time to update it? :wink:

Also, are the test in the Colab the same as in https://github.com/roboflow/supervision/pull/1077?

[LinasKo]

I've added the NaN conversion at the point IOUs are calculcated.

The same Colab as provided showcases the fix.

[SkalskiP]

Hi, @rolson24 and @LinasKo! Thanks a lot! 🙏🏻 @rolson24 The work you did to find the source of the problem was crucial. However, I think the solution proposed by @LinasKo is more advantageous. I am surprised that our IoU calculation code did not account for the possibility of a box having zero area.