search

remydubois / lsnms

Large Scale Non maximum Suppression. This project implements a O(nlog(n)) approach for non max suppression, useful for object detection ran on very large images such as satellite or histology, when the number of instances to prune becomes very large.
63 stars 5 forks source link

RTree query area can not be > 0 if bboxes are not pixel coordinates #29

Closed yellowchocobo closed 6 months ago

yellowchocobo commented 6 months ago

Hi,

First of all, thanks for this great repository and for sharing it publicly. I work with satellite images and deep learning, and the non-maximum suppression step is often the bottleneck during predictions in many of my used cases (especially in applications with many detections over large images). So the LSNMS is helping me a lot :)

When I am using nms fron lsnms, it usually works well, but I run into a specific case where, for some reason, it does not filter out overlapping boxes. I am attaching a csv file containing the bounding boxes and scores of this specific case. I am running it with iou_threshold of 0.20. Using the torchvision implementation of NMS (see https://pytorch.org/vision/0.16/_modules/torchvision/ops/boxes.html#nms) returns 40954 of the original 48483 bounding boxes. When I use LSNMS, it does not filter out anything, despite some of the boxes overlapping. I tried to normalize my bounding boxes, but it did not help. I also tried to change the leaf size, but again it does not lead to any differences. I will keep digging from my side, but do you know what could be the problem? Thank you so much for your help.

Please find enclosed a csv file containing the scores and boxes.: overlaping_bboxes.csv

yellowchocobo commented 6 months ago

Using wbc with the same parameters returns the correct number of bounding boxes.

remydubois commented 6 months ago

Hey, thanks for the report and kind words.

I found the bug but won’t have time to fix it properly before end of week. If you are in a hurry you can:

  1. Multiply your array of bboxes by a large number (like 1.e5)
  2. Or: patch locally by cloning this repo, modifying this line and changing 1.0 to 0.0, then pip installing the local version

Option 2 should be the most durable way to fix your bug but i want to make sure it does not hurt performances before shipping a patched version publicly.

Note: this value of 1.0 is the minimal overlap area to consider when comparing boxes (and discarding some of them). The current 1.0 value comes from a misinterpretation from myself in which object detector should always fire bboxes of at least 1 pixel area ! I assume your bboxes coordinates are not in pixels but maybe real world coordinates.

yellowchocobo commented 6 months ago

Thank you so much for your quick reply, explanation and suggestions how to fix the problem. You are right, I am using world coordinates for the bounding box values. I will go for the option (2). Thank you so much again. All the best!

remydubois commented 6 months ago

Hey @yellowchocobo, version 0.4.4 available on pypi should fix your issue. Feel free to reopen if not !

yellowchocobo commented 6 months ago

Merci!