The problem: #51 can measure a gap but cannot attribute it
The supervised-YOLO baseline (#51) exists to answer "is the contribution the dataset or the keypoint architecture?" It will produce a number. What it will not produce is an explanation, because RampNet and YOLO differ along three axes simultaneously:
| axis |
RampNet |
YOLO baseline |
already tracked? |
| backbone |
ConvNeXt-V2 base (FCMAE, IN22k→IN1k @384) |
CSP/ELAN (yolo11) or yolo26 |
#20, but as a performance experiment |
| output representation |
single-channel keypoint heatmap, peaks → points |
boxes, centers → points at eval |
#83, but as a capability extension |
| training budget |
1 epoch / ~9,379 steps, constant lr 1e-5, no schedule |
60 epochs / ~2.25M steps, warmup + decay |
#84, correctly framed as an ablation |
That is roughly a 240× step asymmetry, plus two architectural differences, all varying at once.
So if the #51 evaluation shows RampNet ahead, the paper is fine — it won despite giving the baseline ~240× the optimization. But if YOLO closes the gap or wins, we cannot say why, and the two candidate explanations have opposite implications:
This issue exists so that gap-attribution is a planned experiment rather than a scramble during rebuttal.
Why this is not #20, #83, or #84
Each of those owns one leg, framed for its own purpose. None of them frames the confound, and none states which experiment to run given a #51 outcome. Concretely:
Decision rule (do not run any of this speculatively)
Nothing here should start until the #51 benchmark evaluation has produced a number. As of filing, no YOLO checkpoint has been scored on any benchmark bundle — so we are at zero signal, and the correct next action is the evaluation, not more training.
RampNet's bar at the same operating point (F1 @ conf 0.25, radius 0.022, from analysis_out/op/low_floor_sweep.csv):
| split |
RampNet F1 @0.25 |
manual_gold |
0.899 |
| POOLED 7 US splits |
0.840 |
Then:
Every YOLO number will be a lower bound (three arms are one-epoch models; see #51), which biases toward the second branch — so treat a large apparent gap with suspicion until the arms are trained out.
Ranked candidates, if the gap survives
1. Backbone swap inside RampNet's own pipeline — highest value. Keep the keypoint head, the heatmap contract, the loss, and the eval path exactly as they are; swap ConvNeXt-V2 for a backbone in YOLO's weight class. This is the only candidate that isolates a single axis, and it reuses the entire existing train/eval path.
Implementation note: BACKBONE_NAME is a module-level constant (rampnet/model.py:4), not a constructor argument, and KeypointModel.__init__ slices nn.Sequential(*list(backbone.children())[:-2]) (model.py:32) — a layout assumption that holds for ConvNeXt/ResNet but not for ViT-style models. The class docstring also warns that the state-dict key layout must not move or every released checkpoint breaks strict loading. So this needs a new optional parameter defaulting to current behavior, not an edit to the constant. That constraint is shared with #20 and should be implemented once.
2. RT-DETR — cheap, lower value. Ultralytics ships it, so it is the same data.yaml, the same launcher, and near-zero integration. Tests "YOLO specifically, or one-stage detectors generally?" It does not break the confound, so it is confirmation rather than explanation.
Not worth it: anything requiring a new pipeline (Mask R-CNN, standalone DETR variants). High cost, and answers no question the first two do not.
Capacity note
If an arm is ever wanted in parallel: pano epochs run ~2–3 h, comfortably under the 8.24 h ckpt slice ceiling, so a pano-geometry arm runs free on ckpt-g2 without touching the lab gpu-l40s (committed to the y26_tiles fork, then the y11x_tiles restart). Tiles arms cannot — that ceiling is exactly why the tiles arms stalled and why one was forked. So RT-DETR-pano is the only zero-cost, zero-disruption option here.
Status
Filed as a planned followup, not started. Nothing in this issue has been run, and per the repo's convention that omissions are stated rather than implied: as of filing there is no committed RampNet-vs-YOLO comparison on any shared metric, and the YOLO side exists only as internal Ultralytics val-split mAP against auto-generated labels — which is not comparable to any RampNet benchmark number (different metric, different label source, different split).
Related: #51 (the comparison), #84 (training-budget leg — run first), #20 (backbone mechanism), #83 (output-representation leg), #90 / #70 (baseline tuning that affects how much of any gap is real).
🤖 Generated with Claude Code (claude-opus-5[1m])
The problem: #51 can measure a gap but cannot attribute it
The supervised-YOLO baseline (#51) exists to answer "is the contribution the dataset or the keypoint architecture?" It will produce a number. What it will not produce is an explanation, because RampNet and YOLO differ along three axes simultaneously:
That is roughly a 240× step asymmetry, plus two architectural differences, all varying at once.
So if the #51 evaluation shows RampNet ahead, the paper is fine — it won despite giving the baseline ~240× the optimization. But if YOLO closes the gap or wins, we cannot say why, and the two candidate explanations have opposite implications:
This issue exists so that gap-attribution is a planned experiment rather than a scramble during rebuttal.
Why this is not #20, #83, or #84
Each of those owns one leg, framed for its own purpose. None of them frames the confound, and none states which experiment to run given a #51 outcome. Concretely:
Decision rule (do not run any of this speculatively)
Nothing here should start until the #51 benchmark evaluation has produced a number. As of filing, no YOLO checkpoint has been scored on any benchmark bundle — so we are at zero signal, and the correct next action is the evaluation, not more training.
RampNet's bar at the same operating point (F1 @ conf 0.25, radius 0.022, from
analysis_out/op/low_floor_sweep.csv):manual_goldThen:
Every YOLO number will be a lower bound (three arms are one-epoch models; see #51), which biases toward the second branch — so treat a large apparent gap with suspicion until the arms are trained out.
Ranked candidates, if the gap survives
1. Backbone swap inside RampNet's own pipeline — highest value. Keep the keypoint head, the heatmap contract, the loss, and the eval path exactly as they are; swap ConvNeXt-V2 for a backbone in YOLO's weight class. This is the only candidate that isolates a single axis, and it reuses the entire existing train/eval path.
Implementation note:
BACKBONE_NAMEis a module-level constant (rampnet/model.py:4), not a constructor argument, andKeypointModel.__init__slicesnn.Sequential(*list(backbone.children())[:-2])(model.py:32) — a layout assumption that holds for ConvNeXt/ResNet but not for ViT-style models. The class docstring also warns that the state-dict key layout must not move or every released checkpoint breaks strict loading. So this needs a new optional parameter defaulting to current behavior, not an edit to the constant. That constraint is shared with #20 and should be implemented once.2. RT-DETR — cheap, lower value. Ultralytics ships it, so it is the same
data.yaml, the same launcher, and near-zero integration. Tests "YOLO specifically, or one-stage detectors generally?" It does not break the confound, so it is confirmation rather than explanation.Not worth it: anything requiring a new pipeline (Mask R-CNN, standalone DETR variants). High cost, and answers no question the first two do not.
Capacity note
If an arm is ever wanted in parallel: pano epochs run ~2–3 h, comfortably under the 8.24 h ckpt slice ceiling, so a pano-geometry arm runs free on
ckpt-g2without touching the labgpu-l40s(committed to they26_tilesfork, then the y11x_tiles restart). Tiles arms cannot — that ceiling is exactly why the tiles arms stalled and why one was forked. So RT-DETR-pano is the only zero-cost, zero-disruption option here.Status
Filed as a planned followup, not started. Nothing in this issue has been run, and per the repo's convention that omissions are stated rather than implied: as of filing there is no committed RampNet-vs-YOLO comparison on any shared metric, and the YOLO side exists only as internal Ultralytics val-split mAP against auto-generated labels — which is not comparable to any RampNet benchmark number (different metric, different label source, different split).
Related: #51 (the comparison), #84 (training-budget leg — run first), #20 (backbone mechanism), #83 (output-representation leg), #90 / #70 (baseline tuning that affects how much of any gap is real).
🤖 Generated with Claude Code (claude-opus-5[1m])