[Bug] Lower boundary of clipping needs to be -1

[JiaminRen]

💀 Bug

Environment

Please provide some information about the used environment.

How was nnDetection installed [docker | source]:

Environment Information:

[paste here]

If necessary, please provide the used run command with all overwrites:

[paste here]

[JiaminRen]

nnDetection/nndet/io/transforms/instances.py

Line 126 in 3416b80

box = [_mins[-dim] - 1, _mins[(-dim) + 1] - 1, _maxs[-dim] + 1, _maxs[(-dim) + 1] + 1]

Plus one and minus one may exceed the image boundary.

[mibaumgartner]

Hi @JiaminRen ,

the transformation intends to provide a generic bounding box representation and no special handling of image borders is done here on purpose, i.e. if the object starts at index 0 of the image, the network is expected to output a bounding box starting at -1 (the same principle applies to the other image borders as well).

Clipping to 0 would introduce an ambiguity because objects starting at index 1 and at index 0 would be mapped to a bounding box starting at 0. Removing +-1 is also difficult since this could lead to objects with 0 sizes. As a result, we used the above rule without clipping or any other modification.

There is an inconsistency in the detection postprocessing which I'll fix after the first release was tagged. The detection network outputs are currently clipped at 0 during inference, which needs to be corrected to -1. The performance difference should be rather small though.

(the corresponding line of code for the 3D case)

nnDetection/nndet/core/boxes/clip.py

Lines 95 to 100 in 3416b80

	boxes[..., 0::6].clamp_(min=0, max=s0)
	boxes[..., 1::6].clamp_(min=0, max=s1)
	boxes[..., 2::6].clamp_(min=0, max=s0)
	boxes[..., 3::6].clamp_(min=0, max=s1)
	boxes[..., 4::6].clamp_(min=0, max=s2)
	boxes[..., 5::6].clamp_(min=0, max=s2)

Best,
Michael

[github-actions]

This issue is stale because it has been open for 30 days with no activity.