Coordinates ordering issue

[jaideep11061982]

Describe the bug A clear and concise description of what the bug is. I tweak the order of box coordinates in dataset for target from xyxy to yxyx

sample1=sample.copy()
print(boxes)#yxyx
for box in boxes:
    cv2.rectangle(sample,
                  (box[1], box[0]),
                  (box[3], box[2]),
                  (220, 0, 0), 2)

#ax.set_axis_off()
ax.imshow(sample)

output

[[122  63 371 120]
 [162 365 392 444]]

When i check the models predictions for corresponding image it seem to be giving in the order xyxy

for box in result_boxes[1]:
    print(box)
    cv2.rectangle(sample1,
                      (int(box[0]), int(box[1])),
                      (int(box[2]), int(box[3])),
                      (220, 0, 0), 2)
plt.imshow(sample1,figure=(12,8))

[ 74.547134 116.86316  147.59622  340.9181  ]
[355.19867 136.82175 426.5904  372.49075]

I get this. Visually predicted and target look identical .

To Reproduce Steps to reproduce the behavior: 1. 2.

Expected behavior A clear and concise description of what you expected to happen. Why the order of model is different than what we pass in target.

Also fyi . My mAP even though for a sample image prediction look good never cross up 0.02 . m i getting confused with box orders ?

Screenshots If applicable, add screenshots to help explain your problem. predicted

Ground truth

Desktop (please complete the following information):

• OS: [e.g. Windows, Ubuntu 18.04]
• This repository version [e.g. pypi 0.3.1 or branch/commit ref]
• PyTorch version w/ CUDA/cuDNN [e.g. from conda list, 1.7.0 py3.8_cuda11.0.221_cudnn8.0.3_0]

Additional context Add any other context about the problem here.

[rwightman]

@jaideep11061982 The processed output from the model (after NMS) is XYXY, torchvision's NMS operates in XYXY so I convert from the model's YXYX. It's mentioned in a few places and you can search past issues, discussions. But not all that clear I guess.

The internal model and anchor / labelling code based on the original TF model layout (and for weight compatibility) is all YXYX so that is why the targets need to be YXYX. The evaluators also differ, COCO evaluator expects XYWH and the TF models based evaluators tha are used for Pascal and OpenImages expect YXYX. Conversions are all done correctly in the example COCO / Pascal / OpenImages datasets, train/validation scripts, and Evaluators.