Closed LorenzoFerriniCodes closed 2 years ago
Hi @LorenzoFerriniCodes, we're really glad someone found those comments haha.
To address your issue, can I first check if you're feeding DeepSort.update_tracks
with raw_detections
that has BB values in [left, top, width, height] format?
I checked, and in fact the problem was on my side. I have been totally fooled by the xyxy2xywh() method from YOLOv5 utilities, which I assumed to be transforming [x_tl, y_tl, x_br, y_br] to [x_tl, y_tl, w, h] bounding boxes, while it is actually transforming [x_tl, y_tl, x_br, y_br] to [x_mid, y_mid, w, h] bounding boxes. I will take this as a lesson on always checking what methods actually do, and not trusting my semantic guesses ahah. Thanks for the quick answer @levan92!
No worries! :)
I am currently using this package to implement DeepSORT tracking over YOLOv5 inferred bounding boxes, and I've found myself struggling a little bit with the results of the Track.to_* methods. I can undertstand, from the comments ("returns LIES", lol) that the Track.to_ltbr() method shouldn't be used, as the result is not what one would expect from its name. However, I have also some problems with the Track.to_tlwh(): the first two values returned don't seem to be the top left x and y coordinates, but more the centre of the box. In fact, visualizing the results obtained, the tracking actually matches the object in the image when the top left corner of the cv rectangle method is set according to my assumptions, while using the values returned by the Track.to_tlwh() without any further computation is not properly working. Is it possible that the method is not actually returnin what one would expect? Or am I misunderstanding something?
Thanks for the work you're doing providing us such a useful tool :)