[raus7n]

Summary

Speeds up the Metropolis2D detection eval by computing the IoU between each prediction and GT box once per image, instead of once per threshold.

This was originally NVIDIA/cosmos#313. I moved it here as asked.

Motivation

The eval checks matches at 10 IoU thresholds (0.50 to 0.95), but it recalculated the same prediction/GT IoUs from scratch for every one of them. So with N predictions, M GT boxes and T thresholds, it was doing about T × N × M IoU calculations when N × M is enough.

Changes

• Work out all the prediction/GT IoUs once per image.
• Reuse those values when matching at each threshold.
• Everything else stays the same: sorting by confidence, greedy matching, how GT boxes get marked as matched, and the AP/mAP calculation.

With 10 thresholds, that's roughly 10x fewer IoU calculations.

Review feedback

@sylvesterkaczmarek pointed out on the old PR that storing the IoUs as float32 could round a value sitting right at a threshold to the other side. I've switched the cache to a plain Python list, so it compares exactly what compute_2d_iou returns and nothing gets rounded.

Validation

• python -m py_compile .agents/skills/evaluation/cosmos3/reasoner/vlmevalkit/vlmeval/dataset/metropolis2d/detection_2d_dataset.py
• git diff --check

Testing

The matching logic itself hasn't changed. It just reads IoUs from the cache instead of recomputing them. Syntax check passes.
cc @yaoxu-crypto

[sylvesterkaczmarek]

Thanks for carrying this over to cosmos-framework and addressing the precision concern from #313. I checked the new diff: the nested Python-list cache preserves the scalar values returned by compute_2d_iou without float32 conversion, and the confidence-order and per-threshold greedy matching remain unchanged. That resolves my earlier review concern. A focused near-threshold regression would be useful, but I don't see a blocker on this point.