Non-max-merging for Inference Slicer #1161
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR builds on top of @mario-dg PR #500, replacing it, fixing issues, adding non-max-merging to
Detections
and connecting to InferenceSlicer.There main stylistic complexity here is dealing with individual objects inside
Detections
.Here, the following changes are implemented:
Detections
now havewith_nmm
, which merges the detections based on their overlap.detections/core.py
exposes anOverlapFiltering
enum, which allows other methods to distinguish between the types. This enum is exposed globally in__init__.py
.InferenceSlicer
is the only class using it right now.NMS
is performed by default, and users may specifyoverlap_filtering
to pick which filtering type to use.Detections._set_at_index
mimicks the former__setitem__
, to be used internally. Only used in one location, so happy to refactor there.Optional
from InferenceSlicer'siou_threshold
arg.utils.py::batch_non_max_merge
. Ping me and I'll look into that.Type of change
Please delete options that are not relevant.
How has this change been tested, please provide a testcase or example of how you tested the change?
Tests:
Colab: https://colab.research.google.com/drive/1iiJ5oCl8dwwcefRgNXRdaFH6G9dVpf4P?usp=sharing
Any specific deployment considerations
One thing I couldn't figure out was the right way to access values of individual detected objects.
When a scalar was needed, I went with
self.xyxy[i]
. When an array was expected, I left theself[i].xyxy
calls. Feels a bit backwards, but most concise - is there a better way?Docs