Inconsistent representation of box in torchvision.ops

Feature suggestion

When checking the how the new operations in the torchvision 0.11 work, I found an inconsistency between different function.

import torchvision.ops as tops
import torch
import torch.nn as nn

a = torch.zeros(1, 1, 8, 8)
a[..., :4, 4:] = 1
bbox = tops.masks_to_boxes((a==1)[0].float()) 
area = tops.box_area(bbox) # the returned area is 9 which should be 16

new_box = tops.box_convert(bbox, 'xyxy', 'xywh') # which returns [4, 4, 3, 3] => expected output [4, 4, 4, 4]

Suggest a potential alternative/fix

This is not actually an error but could cause confusion.

I suggest to make the box representations between different function more consistent.

[fmassa]

We should return area / sizes as x2 - x1, and not x2 - x1 + 1 as it was previously done in early versions of other libraries (like Detectron).

This was a deliberate decision, and as @rbgirshick pointed out in the past

Anyone interested in this issue should read http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf. I believe that this provides the correct framework for thinking about continuous geometric entities (e.g., boxes, polygons, etc) and discrete rasterized entities (e.g., bit masks, feature maps, etc.).

[NicolasHug]

Thanks.

Then I’m not sure this 0 vs 1 indexing discussion is relevant to what we’re concerned with here. Python is 0-based and we’re following that too.

The problem we have here is the relation between x1 - x0 and y1 - y0, and how it plays out in the area calculation, and other conversions. Those concerns are valid whether one uses 0 or 1-based indexing, but I don’t think we should worry about supporting 1-based indexing.