A couple of questions about bbox module functions

Hi guys,

during the bbox module refactoring, I have encountered a couple of weird things and I wanted to make sure that everything is how it suppose to be:

1. bbox width and height arithmetic seem to be inclusive (adding +1 to the difference of coordinates): https://github.com/kornia/kornia/blob/1e0ccad60611f5e47d4eddbf950f120c30020dd9/kornia/geometry/bbox.py#L105-L107 So when we have this example: https://github.com/kornia/kornia/blob/1e0ccad60611f5e47d4eddbf950f120c30020dd9/kornia/geometry/bbox.py#L90-L95 the width and height is 2 pixels: https://github.com/kornia/kornia/blob/1e0ccad60611f5e47d4eddbf950f120c30020dd9/kornia/geometry/bbox.py#L102 Is it a standard procedure? It is the first time I see something like this - examples of other works for both 2D and 3D that are taking just a plain arithmetic difference without adding 1 to it. Two examples: EfficientDet in 2D: https://github.com/xuannianz/EfficientDet/blob/030fb7e10ab69a297c7723120c2d1be856a852c0/generators/coco.py#L152 and OpenPCDet in 3D: https://github.com/open-mmlab/OpenPCDet/blob/26a16123cf820e29ed565f4ad53964c66f3ea030/pcdet/utils/box_utils.py#L28
2. The convention of coordinates used in the bbox module assumes the order x, y, z, but the return values in infer_bbox_shape are reversed: height, width in 2D and depth, height, width in 3D. Is there any particular reason why the order is reversed? https://github.com/kornia/kornia/blob/1e0ccad60611f5e47d4eddbf950f120c30020dd9/kornia/geometry/bbox.py#L105-L107
3. bbox_to_mask and bbox_to_mask3d have inconsistent arguments: bbox_to_mask(boxes: torch.Tensor, width: int, height: int) and bbox_to_mask3d(boxes: torch.Tensor, size: Tuple[int, int, int]) accordingly. Can I make them more consistent? For example: bbox_to_mask(boxes: torch.Tensor, size: Tuple[int, int]) and bbox_to_mask3d(boxes: torch.Tensor, size: Tuple[int, int, int])?

I have analyzed the commit history and I believe @shijianjian wrote most of the bbox functionalities. @shijianjian , can you take a look at the points above and let me your thoughts?

[dkoguciuk]

Thanks @hal-314 for letting us know about the Detectron2 convention, we will probably adapt it to Kornia. I think I can now start working on the first work in progress version for the updated bbox module. I will keep you posted @shijianjian 🚀

[shijianjian]

Hi @dkoguciuk,

1. I did not do much background research on how other libs did during the time of development. While, as we are dealing with corners than (x, y, h, w), (x, y, x, y), I think this inclusion can be more intuitive as we actually expect the point to be included while write it. Since our bbox format is a bit irregular due to the need by grid_sample, I think what we need is the good conversion from formats like (x, y, h, w), (x, y, x, y) to corner bbox.
2. This only meant to match torch conventions like BCHW and BCDHW.
3. Yes, please do so.

Plus, for bbox module, I think we are now in a good condition for handling most common cases. I would propose to go further down to other modalities like the rotated bbox 2d and 3d as mentioned in slack. Also, some bbox computations like this to attrack more advanced users. Please take these random ideas into consideration. 😃