The 360 seam is unsealed end to end: RampNet finds under half the ramps on it, Stage 1 double-labels them, and the scorer can see neither

[jonfroehlich]

The 360° seam is unsealed end to end. Four layers of the same defect, each one hiding the next:

Stage 1's peak extraction does not wrap → seam ramps get double-labelled in the published training data → the model is trained on defective supervision at the seam → the model finds less than half the ramps that sit on it → and the scorer cannot see any of this, because the matcher does not wrap either and manual_gold's GT double-marks the same ramps in the same place.

Every number below is derived from committed caches and committed labels, or from the published HF dataset's label columns. No new imagery, no GPU. Reproduction snippets are at the bottom.

This grew out of #130, which covers the scoring-side half (the 11 double-marked GT pairs and the non-wrapping matcher). #130 stays as-is and remains the fix ticket for the scorer. This issue is the whole chain, including two things #130 does not contain: a measured detection deficit in the model, and the same defect in the published Stage 1 dataset.

---

0. What is measured and what is not

Stated up front, because the interesting claims here are of different strengths and a reviewer should not have to reverse-engineer which is which.

Measured, with the confounds controlled:

• The model's recall inside ~4° of the seam is about half what it is elsewhere (§2).
• The published Stage 1 training dataset contains seam-crossing duplicate label pairs far above chance (§3).
• Which code paths wrap and which do not (§4) — read off the source.

Hypothesis, not yet tested:

• That the recall deficit is caused by receptive-field truncation at the image border. The evidence is consistent with it (the deficit is confined to a narrow border strip and is flat everywhere else) but the causal test has not been run. §7 is that test.
• That defective Stage 1 supervision at the seam contributes to the deficit. Plausible, untested, and separable from the above.
• The "dropout" mode in §3 — seam ramps getting no label rather than two. Suggested by the azimuth histogram, but inside natural variation. Not established.

Explicitly not claimed: that any conclusion in the model comparison, the YOLO baseline, or the operating-point work changes. The aggregate effect is about 0.17 recall points. The reason to care is that it is systematic, permanent, at a known location, and it sits in a published dataset.

---

1. Why this was invisible

The four layers cancel. In manual_gold, a seam ramp is labelled twice — once per edge. The model, if it fires at all, emits one detection. The non-wrapping matcher scores that as one TP and one unclaimable FN. Fix the GT alone and the answer depends on which duplicate you delete; fix the matcher alone and nothing moves, because the near-side duplicate always gives the detection something to claim. The two only become well-defined together, which is the argument in #130.

And the deficit itself was hidden a second way: scripts/gt_gallery.py, the point-adjudication viewer every verdict split was reviewed in, clamps its crop window instead of wrapping it (left = int(min(max(px - half, 0), sx - CROP_SIZE)), line 237). A seam ramp's two halves land in separate 512 px crops taken 3,584 px apart. A reviewer had no way to see them as one object. The nine verdict-reviewed splits hold only 4 GT points within 11 px of the seam, against 18 in the independently-labelled manual_gold — consistent with reviewers under-marking exactly the region the viewer renders badly.

---

2. Finding 1 — the model loses about half the ramps on the seam

RampNet at the deployed 0.30, pooled over all ten benchmark splits, GT binned by distance to the nearest seam edge.

Three corrections applied first, so this measures the model and not our own bugs:

1. The matcher wraps. Otherwise a detection on one side of the seam cannot claim a GT point on the other.
2. Seam-crossing duplicate GT pairs are merged (second member dropped). Only seam-crossing pairs — genuinely adjacent ramps away from the seam are left in place, which is the conservative choice: merging them too would strip hard cases out of the baseline and inflate the deficit.
3. Range is controlled by direct standardization on cy. Seam-band GT sits at systematically lower cy (further away) than the rest of the pano, and recall falls off with range independently of anything to do with the seam. exp below is what a population with this band's own range profile would score at baseline rates.

distance from seam	GT	found	observed recall	expected (range-standardized)	Δ	z
0–11 px (≤3.9° of azimuth)	25	8	0.3200	0.7757	−0.4557	−5.67
11–22 px	65	49	0.7538	0.7650	−0.0111	−0.22
22–45 px	270	213	0.7889	0.7714	+0.0175	+0.71
45–90 px	729	602	0.8258	0.8168	+0.0090	+0.65

The deficit is confined entirely to the innermost band. Every other band is flat (|z| < 1). That shape is the point: a broad gradient would suggest range or occlusion; a sharp step at the border is what an edge artifact looks like.

The circularity objection, and the split that answers it

GT on the nine verdict splits is built from model detections a reviewer judged, plus misses the reviewer added. Recall measured against it is therefore partly definitional. manual_gold is not — its GT comes from the independent 1,000-pano YOLO labelling pass, which never saw model output. Split by provenance:

GT provenance	band	GT	found	obs recall	exp recall	Δ	z
manual_gold (independent)	0–11 px	19	7	0.3684	0.8488	−0.4804	−5.88
manual_gold	11–22 px	23	17	0.7391	0.8051	−0.0660	−0.82
nine verdict splits	0–11 px	4	1	0.2500	0.7406	−0.4906	−2.29

Same magnitude both ways, and it is strongest on the independent GT. The verdict splits agree in direction and size but carry almost no weight at n=4.

Note also which way the remaining bias runs: if reviewers under-marked seam ramps through the clamping viewer, those ramps are absent from GT and cannot be counted as misses. That inflates measured seam recall. The deficit is measured against a bias that works to hide it.

Size of the prize

About 25 GT points of 6,549 sit in the affected band, and roughly 11 of them are lost — ~0.17 recall points in aggregate. Small. It is worth fixing anyway because it is not noise: it is a fixed, reproducible blind spot at a known azimuth in every panorama the model has ever run on, and it is one of the few error sources here with a deterministic fix rather than a data-collection fix.

---

3. Finding 2 — the published Stage 1 dataset double-labels seam ramps

stage_one/dataset_generation/download_dataset.py builds a combined 4096×2048 equirectangular heatmap by projecting each per-azimuth crop-model heatmap back with perspective_to_equirectangular (line 57), then extracts labels with:

peak_coords_raw = peak_local_max(
    combined_heatmap,
    min_distance=min_peak_distance,   # 40
    threshold_abs=threshold_abs_value,
    exclude_border=False,
)

peak_local_max treats column 0 and column 4095 as maximally distant. On a cyclic image they are adjacent. So a ramp on the seam can emit a peak on each edge, and min_distance=40 will never suppress one against the other. That is the code that generated projectsidewalk/rampnet-dataset.

Scanning the published parquet label columns directly — curb_ramp_points_normalized is 0.003 MB per row group against 203 MB for image, so column projection makes this a ~12 MB read rather than 463 GB:

	panos	labels	seam-crossing label pairs within R	expected under uniform-azimuth null	enrichment
first 8 of 384 files	1,344	5,312	60	3.08	19.5×
first 144 of 384 files	40,209	156,027	1,543	88.1	17.5×

p ≈ 0 at both sample sizes. The full 384-file scan is running; final numbers will be posted as a comment on this issue and this table updated.

That is roughly 1% of the training labels being two marks on one physical ramp — each one becoming two Gaussian targets 40+ px apart in the Stage 2 training objective.

The unproven half. The azimuth histogram also shows the two seam-adjacent bins low (0.66× and 0.69× of the mean), which would be the opposite failure — a split response falling under threshold_abs and producing no label at all. But interior bins range 24–133 against a mean of 83, so that deficit sits inside natural azimuth variation. GT azimuth is genuinely non-uniform in this data (χ² = 193 on 15 df in the benchmark GT — US grid cities put roads at predictable bearings relative to north), so a histogram dip is not evidence on its own. Doubling is established. Dropout is not.

---

4. Finding 3 — the audit: every site that touches cyclic pano geometry

Must wrap, currently does not:

site	what it is	measured cost today
rampnet/metrics.py:35	greedy_match — the shared matching core every evaluator uses	0 (masked by the duplicate GT)
rampnet/detection_eval.py:224	ignore-point fallback, its own inline distance	0
scripts/gt_gallery.py:237	the point-adjudication viewer	this is what hid the 11
scripts/analysis/operating_point_curve.py:642	op-curve crop renderer, clamps	seam items render off-centre
scripts/analysis/size_analysis.py:128	crop box with no clamp at all — PIL silently pads	seam crops partly black
stage_two/evaluate.py:78, stage_two/demo.py:110, scripts/analysis/threshold_sweep.py:97	peak_local_max on the pano heatmap	0 observed duplicate peaks, see below
stage_one/dataset_generation/download_dataset.py:64	the label generator — §3	~1% of published training labels

On the extraction row: across all committed caches at the 0.05 floor there are 0 seam-crossing prediction pairs against 1.58 expected, so there is no evidence the model currently double-peaks at the seam. But P(observe 0 | null) = 0.21, so that is underpowered — "no measured cost", not "proven absent". It also cannot be cleanly tested while the model under-detects there at all.

Already correct, no change needed: scripts/analysis/miss_taxonomy.py:120, scripts/analysis/silent_activation.py (all three sites — heat[row][col % W], nearest_peak, null_azimuths), scripts/model_comparison/equirect_tiling.py:167 (dedup_points), scripts/analysis/crop_window_eval.py:1013, scripts/box_gallery.py:211, and scripts/analysis/miss_gallery.py (reprojects through equirect_tiling.View, so it is structurally immune).

Worth noting that equirect_tiling.dedup_points has had the correct wrapping distance all along. The repo already contains the right code; the scorer just does not call it.

---

5. The trap in the fix: one caller must NOT wrap

stage_one/crop_model/ps_and_manual_model/evaluate.py:206 calls the same match_predictions with scale_x=341/4. That is crop space (1024×352 crops), where x is genuinely not cyclic. An unconditional wrap would silently corrupt the crop model's numbers.

So the fix is an explicit wrap_x parameter that pano callers opt into, not a blanket change:

caller	space	wrap
rampnet/detection_eval.py::score_pano	pano	yes
stage_two/evaluate.py:231 (scale_x=heatmap_w)	pano	yes
stage_one/dataset_evaluation/evaluate.py:132 (PANO_SCALE_X)	pano	yes
stage_one/crop_model/ps_and_manual_model/evaluate.py:202 (scale_x=341/4)	crop	no

This needs a regression test pinning the crop path as not wrapping, or a future consistency cleanup re-breaks it.

---

6. How to seal it

Three independent layers. The order matters because the first is the measuring instrument for the other two.

Layer 1 — scoring. Wrapped matching plus wrapped GT dedup (#130). Changes nothing user-facing; it is what makes layers 2 and 3 measurable at all.

Layer 2 — extraction. Wrapped NMS: merge peaks across the seam in peaks_to_dets / extract_peaks_from_heatmap, and in the Stage 1 label generator. Cheap, no retrain, kills the doubling including in any regenerated training data. Does not fix truncated context.

Layer 3 — the model. This is the actual seal. The convolutions pad the left and right borders with zeros, so a ramp on the seam is processed with half its context replaced by nothing. Three options, in cost order:

option	retrain?	cost	notes
Circular input pre-padding — wrap-pad the 4096-wide input by m columns from the opposite edge, run, crop the heatmap back	no	~2m/4096 (m=256 → +12.5% inference)	no weight change, no architecture change; the published checkpoint works as-is
Roll-by-180° TTA — run twice, second pass on a rolled pano, combine	no	2×	complete context everywhere; also the diagnostic, see §7
Circular padding in the convs, then retrain	yes	a training run	correct by construction; the RampNet 2.0 answer

This is not the flip-TTA that #78 measured and rejected. That was generic augmentation with no target and it lost on 4 of 5 US splits. This is aimed at a specific measured defect at a known location, and it has to be measured on its own terms rather than inheriting #78's result.

---

7. The decisive experiment

Roll-by-180° is both a candidate fix and the causal test, which is why it is worth running first.

Take the panoramas holding the ~25 seam-band GT points, roll each by half its width, re-run the published checkpoint, roll the heatmap back, and score the same GT.

• The lost ramps come back → context truncation confirmed, and circular pre-padding is the cheap production fix.
• They do not → the range standardization in §2 missed a confound, and the deficit needs a different explanation before anyone builds on it.

Minutes on one GPU, against panoramas already in benchmark/*/panos. Nothing downstream should be built on §2 until this has run.

---

8. What this touches

• The published dataset. projectsidewalk/rampnet-dataset carries the duplicate labels. Fixing means either regenerating with wrapped extraction or shipping a documented erratum.
• The paper. An amendment covering the Stage 1 label defect and the seam recall deficit. Aggregate effect on the headline numbers is small (~0.17 recall points), but the dataset defect is a property of a published artifact and should be on the record.
• RampNet 2.0. Everything downstream inherits this unless it is fixed at layer 2 and 3 — the multi-view work in Multi-capture / multi-view fusion for per-ramp recall: correspondence, agreement-as-arbiter, 3D (RampNet 2.0) #48 especially, where each capture's blind spot sits at a different world azimuth. That is an opportunity as much as a hazard, but only if the fusion code knows the blind spot exists.
• manual_gold's row wherever it is quoted, including the RampNet-vs-YOLO comparison in Train a supervised YOLO baseline (YOLO11 / YOLO26) on the RampNet dataset — isolate architecture vs. data #51.

---

9. Plan

• rampnet/geometry.py — one wrapping distance and one wrapping crop box, no rampnet imports so both metrics and detection_eval can use it
• Fix the six sites in §4; wrap_x explicit per §5
• Regression test pinning the crop path as not wrapping
• Seam fixture test per site: GT at x=0.999, prediction at x=0.001, must score 1 TP
• Commit the §2 measurement as a script so −0.4557 is re-derivable
• scripts/analysis/seam_review.py — blind adjudication deck for the 360 seam, in the scoring code: 11 double-marked ramps in manual_gold, and a matcher that does not wrap #130 GT pairs, with matched controls
• Run the §7 roll diagnostic
• Full Stage 1 scan result posted here, and a decision on regeneration vs erratum
• Guard at GT ingest: surface within-radius wrapped pairs for a human decision, never auto-merge (see §10)

---

10. What I would most like challenged

Listed because they are the weakest links, not as a formality.

1. n = 25 in the affected band. z = −5.67 is decisive against the null, but it is 25 points. Is direct standardization on cy adequate, or does the seam band differ on something else — occlusion, vehicle position, hood/nadir proximity — that cy does not capture?
2. cy as a range proxy. It is the vertical position in the pano, which is monotone in range on flat ground. Flat-ground distance carries a ~11% range-proportional scale error, not just scatter — multi-view self-consistency measures it and DA3 can anchor it #101 measured a ~11% range-proportional scale error on exactly that assumption. Does that matter here?
3. Is the innermost band contaminated by anything I did not control? The seam duplicates are handled. Anything else that co-occurs with x≈0?
4. The dedup direction. I drop the second member of a seam pair. With a wrapping matcher this should not matter (that is the argument in 360 seam, in the scoring code: 11 double-marked ramps in manual_gold, and a matcher that does not wrap #130) — worth confirming independently.
5. §3's dropout claim is unproven and I have said so. If someone can think of a way to separate a real label deficit from azimuth non-uniformity in the published dataset, that would settle it.
6. The auto-merge question. 360 seam, in the scoring code: 11 double-marked ramps in manual_gold, and a matcher that does not wrap #130's guard proposal was to merge GT points within the wrapped radius. Measuring the base rate says do not: manual_gold holds 234 within-radius GT pairs away from the seam, 87 of them with near-identical cy at the horizon — genuinely adjacent far-field ramps. The uniform-azimuth null predicts 3.16 of the 11 seam pairs arise by chance. So roughly 3 of the 11 may be real pairs, and auto-merge would silently delete real ramps in the direction that flatters our recall. Hence the blind adjudication deck rather than a code rule. Is that the right call?
7. The nine-splits zero is weak. 0 seam pairs observed against 2.15 expected is P = 0.117 — consistent with 360 pano seam: curb ramps split across the left/right edge get double-counted in GT scoring #43's reviewer rule having worked, but not a demonstration of it. It should not be cited as one.

---

Reproduction — §2, the recall deficit (committed caches only; no GPU, no network, no imagery)

import os, sys, math
sys.path.insert(0, "."); sys.path.insert(0, "scripts/analysis")
from operating_point_curve import CACHE_DIR, read_cache
from miss_decomposition import ALL_SPLITS
SX, SY = 1024, 512
R = 0.022 * SX
RSQ = R * R

def wrapped_match(preds, gt):
    claimed = [False] * len(gt); hit = set()
    for px, py in preds:
        bk, bd = -1, RSQ
        for k, (gx, gy) in enumerate(gt):
            dx = abs(px - gx) * SX
            dx = min(dx, SX - dx)
            d = dx * dx + ((py - gy) * SY) ** 2
            if d < RSQ and not claimed[k] and d < bd:
                bd, bk = d, k
        if bk >= 0:
            claimed[bk] = True; hit.add(bk)
    return hit

def dedup_seam_only(gt):
    """Drop the second member of a pair that duplicates ACROSS THE SEAM only."""
    keep = []
    for g in gt:
        dup = False
        for k in keep:
            dx = abs(g[0] - k[0]) * SX
            if dx <= SX / 2:
                continue
            if (SX - dx) ** 2 + ((g[1] - k[1]) * SY) ** 2 < RSQ:
                dup = True; break
        if not dup:
            keep.append(g)
    return keep

CY = [(0.0, 0.53), (0.53, 0.55), (0.55, 0.57), (0.57, 0.60), (0.60, 1.01)]
strat = lambda cy: next((j for j, (lo, hi) in enumerate(CY) if lo <= cy < hi), len(CY) - 1)

rows = []
for c in dict.fromkeys(ALL_SPLITS):
    p = os.path.join(CACHE_DIR, f"{c}.json")
    if not os.path.exists(p):
        continue
    for r in read_cache(p)[0]:
        gt = dedup_seam_only(list(r["gt"].gt_points))
        preds = [(q[0], q[1]) for q in
                 sorted([q for q in r["preds"] if q[2] >= 0.30], key=lambda q: -q[2])]
        hit = wrapped_match(preds, gt)
        for i, g in enumerate(gt):
            rows.append((min(g[0], 1 - g[0]) * SX, g[1], i in hit))

base = [[0, 0] for _ in CY]
for d, cy, f in rows:
    if d >= 4 * R:
        s = strat(cy); base[s][1] += 1; base[s][0] += f
br = [(b[0] / b[1] if b[1] else 0.0) for b in base]

for lo, hi, lbl in [(0, R/2, "0-11 px"), (R/2, R, "11-22 px"),
                    (R, 2*R, "22-45 px"), (2*R, 4*R, "45-90 px")]:
    sel = [t for t in rows if lo <= t[0] < hi]
    n = len(sel); obs = sum(1 for t in sel if t[2])
    exp = sum(br[strat(t[1])] for t in sel)
    var = sum(br[strat(t[1])] * (1 - br[strat(t[1])]) for t in sel)
    print(f"{lbl:10} n={n:4} obs={obs:4} exp={exp:6.1f} "
          f"delta={obs/n - exp/n:+.4f} z={(obs - exp)/math.sqrt(var):+.2f}")

Reproduction — §3, the Stage 1 dataset scan (network; reads ~12 MB of label columns, not the images)

import pyarrow.parquet as pq
from huggingface_hub import HfApi

REPO = "projectsidewalk/rampnet-dataset"
SX, SY = 1024, 512
R = 0.022 * SX
COLS = ["pano_id", "curb_ramp_points_normalized"]

files = sorted(f for f in HfApi().list_repo_files(REPO, repo_type="dataset")
               if f.endswith(".parquet"))

obs = 0
exp = 0.0
for fp in files:                       # column projection: image bytes are never fetched
    t = pq.ParquetFile(f"hf://datasets/{REPO}/{fp}").read(columns=COLS)
    for pts in t.column("curb_ramp_points_normalized").to_pylist():
        pts = [(float(p[0]), float(p[1])) for p in (pts or [])]
        for a in range(len(pts)):
            for b in range(a + 1, len(pts)):
                dx = abs(pts[a][0] - pts[b][0]) * SX
                wdx = min(dx, SX - dx)
                dy = abs(pts[a][1] - pts[b][1]) * SY
                if (wdx * wdx + dy * dy) ** 0.5 < R:
                    exp += wdx / SX               # uniform-azimuth null
                    if dx > SX / 2:
                        obs += 1                  # seam-crossing == candidate duplicate
print(obs, exp, obs / exp)

Refs #130 (the scoring-side fix), #43 (the reviewer rule and the GT viewer), #51 (the baseline comparison that reads manual_gold), #46 (where this surfaced), #48 (multi-view, which inherits the blind spot), #78 (flip-TTA, which this is not), #101 (the range-proxy caveat in §10).

🤖 Generated with Claude Code (claude-opus-5[1m])

[jonfroehlich]

§3 final: the full Stage 1 scan, all 384 parquet files

The interim figures in §3 are superseded. The whole published dataset was scanned — every split, label columns only.

	value
panoramas	214,385
labels	849,904
panoramas by split	train 150,066 / val 42,878 / test 21,441
within-radius label pairs (all)	44,026
seam-crossing label pairs	8,361
expected under the uniform-azimuth null	485.0
enrichment	17.24× (z ≈ 358σ, normal approximation)
share of all labels	0.98%

Separation of the seam pairs, in matcher units: min 0.25 px, p25 5.25, median 9.85, p75 14.77, max 22.51 (capped at the match radius by construction). A median of 9.85 px is 3.5° of azimuth — not a plausible physical spacing for two distinct ramps at typical range.

So roughly one percent of the labels RampNet was trained on are a second mark on a ramp already labelled, each becoming its own Gaussian target in the Stage 2 objective. The train split carries 150,066 of the 214,385 panoramas, so the great majority of these were in the training signal rather than only in eval.

The dropout mode: upgraded from "not established", not yet settled

§3 flagged a possible second failure — a seam ramp whose split response falls under threshold_abs and gets no label. At 8 files that was inside natural variation and I said so. At full scale it is much stronger:

azimuth bin (64 bins, mean 13,280)	labels	ratio to mean
bin 0 (touches the seam)	8,084	0.609×
bin 63 (touches the seam)	7,951	0.599×
interior bins 8–55	min 3,779 · p25 12,593 · median 14,180 · p75 15,055 · max 19,095	—

Only 4 of 48 interior bins sit at or below both seam bins.

And the direction matters: the doubling mode adds labels near the seam, so it inflates exactly these two bins. A 40% deficit measured on the raw histogram is therefore a floor on the true dropout — remove the 8,361 duplicates and the seam bins fall further.

I am not calling it established yet, for the reason given in §3: azimuth is genuinely non-uniform in this data (interior bins span 3,779–19,095), so a histogram dip is weak evidence on its own. A second scan is running that records the duplicate-removed histogram alongside the raw one, which separates the two modes cleanly. That result will be posted here.

Note on the reproduction snippet

The §3 snippet is correct as published. The scan script itself had one bug, in reporting only: the exact Poisson tail overflows at λ=485 with k=8,361 (seam_exp ** k). The scan had already completed and written its JSON before that line ran, so no measurement was affected — but anyone re-running it should use a normal approximation for the tail, as the table above does.

Both scan scripts will be committed with the rest of the work, so these numbers are re-derivable rather than a memory.

🤖 Generated with Claude Code (claude-opus-5[1m])

[jonfroehlich]

Doubling confirmed independently of the null — and one retraction

§3's enrichment figure rests on a uniform-azimuth null, and §10.5 asked whether that null is trustworthy given that azimuth is demonstrably non-uniform in this data. It now doesn't have to be. There is a second, structural test that uses no null at all.

Retraction first. I tried to settle this by pairing each label with its government ramp record through curb_ramp_coords — if two labels trace to the same gov record, they are provably one ramp. That test is invalid and its result should be ignored: curb_ramp_points_normalized and curb_ramp_coords are not index-parallel arrays. Only 65% of rows even have equal lengths, and projecting coord i to its expected azimuth gives a median residual of 0.315 normalized — 113° — against point i. I was comparing unrelated entries. (Anyone re-running this: do not index-pair those two columns.)

What does work is the length relationship itself, which needs no correspondence. If one physical ramp is being labelled twice, a pano with a seam-crossing pair should carry exactly one more label than it has government records. Over 24 parquet files, 4,032 panoramas:

n_points − n_coords	panos with a seam pair (n=164)	panos without (n=3,868)
−2	4.3%	8.4%
−1	7.3%	16.4%
0	20.7%	58.1%
+1	46.3%	8.8%
+2	13.4%	1.7%
mean	+0.591	−0.408

Difference of means: +1.000. Exactly one excess label per seam-crossing pair. Share of panos carrying more labels than government records: 64.0% with a seam pair against 11.0% without (z = +14.0).

That is what one ramp labelled twice looks like, measured without reference to any azimuth model. The 17.24× enrichment and this +1.000 offset are two independent routes to the same conclusion, so §3's doubling claim no longer depends on §10.5 being resolved in its favour.

Note the baseline is negative (−0.408): a typical panorama carries fewer labels than it has government records, which is ordinary Stage 1 yield. The seam panos invert that.

This sharpens the correction decision (§8)

The two failure modes are not equally fixable, and the difference is large enough to drive the decision:

• Doubling is fixable in place. The published parquet carries points, not heatmaps — the schema is image, pano_id, record_creation_time, curb_ramp_points_normalized, pano_coord, curb_ramp_coords, pano_azimuth. Merging seam-crossing duplicate pairs is a pure transformation of a published column: no Stage 1 re-run, no imagery re-fetch, no dependency on the GSV endpoints. ~8,361 labels removed from 849,904.
• Dropout is not fixable in place. Recovering a label that was never extracted means re-running peak_local_max on the combined heatmaps, and those were never retained — the dataset stores the points that survived extraction. That requires full Stage 1 regeneration, which is the expensive path and depends on a fetch path that has already broken once.

So if the duplicate-removed histogram scan confirms dropout as well, the two halves of the correction land in very different cost brackets and can be decided separately. Doubling can be corrected regardless of what happens with dropout.

🤖 Generated with Claude Code (claude-opus-5[1m])

[jonfroehlich]

§7 result: border truncation confirmed by double dissociation

The roll test has run, both directions. §2's mechanism is no longer a hypothesis.

Rolling a panorama by half its width moves seam ramps to the centre and centre ramps to the seam, so the mechanism predicts a crossover rather than a uniform lift. Both halves were run — panoramas selected for seam-band ground truth, then separately for centre-band ground truth, since the centre band is only ~2% of the azimuth range and yields almost nothing when riding along on the seam selection.

selected for	band	n GT	original	rolled	change
seam	seam	25	0.3200	0.8400	+0.5200
seam	elsewhere	110	0.9091	0.9091	+0.0000
centre	centre	58	0.7241	0.2931	−0.4310
centre	elsewhere	223	0.8027	0.7982	−0.0045

• Ramps on the seam are recovered when the roll moves them to the centre: +0.52.
• Ramps at the centre are destroyed when the roll moves them onto the seam: −0.43.
• Everything else is unmoved in both runs: +0.0000 and −0.0045.

The symmetry is the result. Whatever sits on the seam scores ~0.30; whatever sits away from it scores ~0.80–0.90. The rolled centre recall (0.293) lands on the original seam recall (0.320), and the rolled seam recall (0.840) lands in the ordinary range. Position relative to the seam determines detection, not any property of the ramps themselves.

That closes the alternatives §10 asked about. It is not range (the roll changes no ramp's distance), not occlusion, not "seam ramps are unusual", and not "rolling helps everything" — the elsewhere bands are flat to within half a point in both runs, and a uniform effect cannot make one band rise 0.52 while another falls 0.43.

Checks

• The inference path reproduces the committed op_cache detections exactly on the matched GT: 109/109 in the seam run, 222/222 in the centre run. This is the same model, preprocessing and peak extraction that produced the caches, so the original-pass column is not a re-derivation with different settings.
• Scoring is The 360 seam is unsealed end to end: RampNet finds under half the ramps on it, Stage 1 double-labels them, and the scorer can see neither #132's throughout: wrapping matcher, seam-crossing duplicate GT merged, min_distance=10, threshold 0.30.

What this settles, and what it does not

Settled: the model cannot see across the seam, and that is what §2 measured. Layer 3 of §6 is a real defect with a known cause.

Not settled: which fix to adopt. The roll is 2× inference. Circular input pre-padding should be equivalent at ~12.5% for m=256 and needs no retrain, but "should be" is exactly the kind of claim this issue keeps disproving — it has to be measured against this same benchmark before it is adopted. The diagnostic script takes the roll as a baseline to compare against.

Also not settled: whether the defective Stage 1 supervision at the seam caused the model's blindness, or merely accompanies it. The two are separable — a model retrained on wrap-corrected labels answers it — and that is RampNet 2.0 work, not a 1.0 correction.

Committed as scripts/analysis/seam_roll_diagnostic.py; results in analysis_out/seam_roll_diagnostic.json and analysis_out/seam_roll_diagnostic_centre.json. It needs a GPU and the benchmark panoramas, so it is not part of the CPU-only default test run.

🤖 Generated with Claude Code (claude-opus-5[1m])

[jonfroehlich]

§3 dropout: now established. Stage 1 loses ~72% of labels in the bin touching the seam

§3 named a second failure mode — a seam ramp whose split response falls under threshold_abs and gets no label at all — and declined to claim it, because the raw azimuth histogram's dip sat inside natural variation. §10.5 asked for a way to separate a real deficit from azimuth non-uniformity.

The separation is the duplicate-removed histogram. The doubling mode adds labels to exactly the bins the dropout mode empties, so the two are superimposed in the raw counts. Removing the 8,062 seam duplicates isolates the underlying density.

	bin 0	bin 63
raw	8,084 (0.609× mean)	7,951 (0.599× mean)
seam-deduped	4,145 (0.315×)	3,855 (0.293×)

Interior bins at or below both seam bins: 1 of 48 (it was 4 of 48 raw).

And the shape settles it. Folding the deduped histogram around the seam:

bins from the seam (5.625° each)	labels	× interior median
0	8,000	0.283
1	11,637	0.411
2	23,400	0.827
3	31,690	1.120
4	33,830	1.195
5	32,847	1.161
6	31,245	1.104
7	29,871	1.056
8	29,018	1.025

A monotone recovery from 0.283× to baseline, saturating by ~3 bins (~17°), anchored exactly at the seam. Azimuth non-uniformity is real in this data, but it does not produce a smooth ramp that starts at the seam and levels off — that is what an edge effect looks like, and it is the same argument the sharp band in §2 rests on.

So Stage 1's label generator loses roughly 72% of the labels it should produce in the 5.6° touching the seam, ~59% in the next, ~17% in the next.

One caveat, stated because it is visible in the numbers. The two sides recover at different rates (bin 2 = 8,472 against bin 61 = 14,928). Each side is individually monotone, but the folded profile mixes the edge effect with real geographic structure, so the rate of recovery should not be read as precise. The deficit at the seam itself, and its monotone direction, are not sensitive to this.

Scale

labels, raw	849,904
labels after seam-dedup	841,842
duplicates removed	8,062
panoramas with ≥1 seam pair	7,987 (3.7%)
duplicates by split	train 5,664 · val 1,598 · test 800

The recovery distance here (~17°) is much wider than the ~4° band in §2. Different mechanism, different footprint: Stage 1 extracts on a 4096-wide equirectangular composite built from 90°-FOV projections at min_distance=40, so its edge artifact is not expected to have the model's receptive-field scale. Worth noting rather than reconciling — they are two defects from one root cause, not one defect measured twice.

Consequence for §10

§10.5 is closed: dropout is established, by the duplicate-removed histogram rather than by the null. Both failure modes in §3 are now measured.

This does not change §8's asymmetry — dropout still cannot be corrected in place. Recovering a label that was never extracted needs the combined heatmaps, which the published dataset does not carry (it stores surviving points). Doubling remains a pure column transformation. If anything the asymmetry now matters more, because the dropout half is the larger effect and the one that cannot be fixed without regenerating Stage 1.

🤖 Generated with Claude Code (claude-opus-5[1m])

[jonfroehlich]

RETRACTION: §2 and §7 are wrong. The model is not blind at the seam — our extractor is.

I checked the model before I checked the instrument, in a repo whose own rule says do it the other way round. §2's recall deficit and §7's double dissociation are artifacts of the peak extractor that built the committed caches, not properties of RampNet.

What actually happened

scripts/analysis/threshold_sweep.py::peaks_to_dets called

peak_local_max(np.clip(h, 0, 1), min_distance=md, threshold_abs=thr)

without exclude_border. skimage defaults it to True, which discards every peak within min_distance of the array edge. On a 1024-wide panorama heatmap with min_distance=10 that is a 3.5° blind strip on each side of the 360 seam — exactly the band §2 measured.

operating_point_curve.py:487 calls ts.peaks_to_dets to build every committed op_cache. stage_two/evaluate.py:78 passes exclude_border=False explicitly, so production was never affected — only our cached analysis detections.

The measurement that settles it

For all 25 seam-band GT points, running the published checkpoint and reading the heatmap directly:

seam-band GT (n=25)	recall
cached extractor (exclude_border defaulted True)	0.4400
exclude_border=False (production setting)	0.9600
heatmap already ≥ 0.30 at the ramp	24 / 25

The model responds at 24 of 25 of these ramps, with activations of 0.45–0.99. It sees them fine. Seam recall at the production setting (0.96) is in line with the rest of the panorama, not below it.

Why the dissociation looked so convincing

Because exclude_border produces exactly that pattern, and my diagnostic used the same peaks() helper for both arms:

• rolling moves a seam ramp to mid-array, where the extractor stops discarding it → looks like recovery (+0.52)
• rolling moves a centre ramp to the array edge, where the extractor starts discarding it → looks like destruction (−0.43)
• everything else is far from both edges → unmoved

A crossover was the right test for the hypothesis I had. It could not distinguish that hypothesis from a border-dependent extractor, because both live at the same place. The control I needed was not another band — it was reading the heatmap, which is upstream of extraction entirely.

What survives, unchanged

None of these involve our peak extraction:

• 360 seam, in the scoring code: 11 double-marked ramps in manual_gold, and a matcher that does not wrap #130's ground-truth double-marking. From committed manual_labels text files. 11 seam pairs, 3 more just outside the radius, the base-rate and enrichment work, and the conclusion that ~3 of the 11 may be genuine pairs so auto-merge is unsafe.
• The Stage 1 dataset defects. 8,361 seam-crossing duplicate pairs at 17.24×, the +1.000 excess-labels-per-seam-pano offset, and the dropout profile. All computed from published parquet label columns.
• The audit (§4). The matcher not wrapping, score_pano's ignore fallback, gt_gallery.py clamping its crop window. Still real, still fixed in eccadda.
• §5. Crop space must not wrap.

What is new, and is a real defect

Every committed op_cache is missing RampNet detections within 3.5° of the seam. That is a genuine data defect in our analysis artifacts, it silently depresses RampNet's measured recall, and it has been there for every analysis built on those caches. It is smaller than what I claimed the model's problem was, and it is ours rather than the model's — but it is real and the caches should be regenerated.

Fixed in peaks_to_dets, with tests/test_geometry.py::test_peaks_to_dets_keeps_peaks_next_to_the_seam pinning it against the production setting.

Consequences for the rest of this issue

• §2, §7, and the two comments reporting them are retracted. The "~0.17 aggregate recall points" figure went with them.
• §6 layer 3 is withdrawn. There is no evidence the model needs circular padding, roll-TTA, or a retrain for the seam. That whole branch was built on §2.
• §10.1–10.3 are moot — they asked whether §2's controls were adequate. They were not, but not for any of the reasons listed there.
• §8 is unaffected: the Stage 1 dataset correction question stands on the dataset measurements, which are independent.

The remaining live work is the scoring fixes (eccadda), the #130 adjudication, the Stage 1 generator fix, and regenerating the caches.

Note for the reviewer

The error was found by building the gallery in this thread's next comment: its hit/miss disagreed with the diagnostic on 2 of 3 panoramas, and chasing that disagreement rather than tuning the render is what surfaced it. A rendering that contradicts your measurement is data. I would not have caught this from the numbers alone — they were internally consistent, survived a double dissociation, and were strongest on the split with independent ground truth, which is exactly the profile of a result that looks solid.

🤖 Generated with Claude Code (claude-opus-5[1m])

[jonfroehlich]

RETRACTION 2: the Stage 1 "dropout" mode is also wrong. Doubling stands.

I claimed Stage 1 loses ~72% of labels in the 5.6 deg touching the seam, on the strength of a monotone density recovery "anchored exactly at the seam". I did not run the obvious control: the same profile at an azimuth with no seam.

bins from centre	at the seam (x=0)	at the anti-seam (x=0.5, no seam)
0	0.283x	0.278x
1	0.411x	0.413x
2	0.827x	0.849x
3	1.120x	1.123x
4	1.195x	1.175x

Identical. The full 64-bin profile has exactly two minima, at x=0 and x=0.5 — 180 deg apart. That is the along-street axis, not the seam: x=0 is north and the panoramas' own heading is removed, so the dip sits straight ahead of and straight behind the vehicle, where ramps are distant and sparse, while the peaks sit to the sides where ramps are close. One of those dips happens to coincide with the seam. The other cannot.

So the deficit is real geography, and my "anchored exactly at the seam" reading was anchored at the vehicle heading.

Doubling is unaffected and still stands, on two independent lines of evidence that do not use the azimuth null:

• 8,361 seam-crossing duplicate label pairs against 485 expected (17.24x)
• panoramas with a seam pair carry exactly +1.000 more labels than they have government ramp records (z = +14.0)

And the mechanism is now confirmed by reading the generator rather than inferring it. rampnet/gsv.py::perspective_to_equirectangular inverse-maps over every equirectangular pixel, so it wraps correctly and a seam ramp's response lands properly split across both edges. download_dataset.py then calls peak_local_max(min_distance=40, exclude_border=False) on that composite — exclude_border is correct here, but min_distance cannot suppress across the seam, so the two fragments are ~4,085 columns apart in array coordinates and both survive as labels. One ramp, two labels.

Net position on #132 after both retractions

claim	status
Model is blind at the seam (S2, S7)	RETRACTED — our exclude_border bug
Stage 1 dropout (S3, second mode)	RETRACTED — along-street geometry, not the seam
Stage 1 doubling (S3, first mode)	stands — ~1% of labels, two independent lines, mechanism read from the code
#130 ground-truth double-marks	stands — 11 pairs, ~3 possibly genuine, needs adjudication
op_cache missing seam detections	stands — ours, fixed in f4c71c8, caches need regenerating
Matcher / ignore-fallback / gt_gallery not wrapping	stands — fixed in eccadda, moves nothing today

The honest summary is that this is a much smaller finding than it looked: one real defect in Stage 1 label generation affecting about 1% of training labels, one small ground-truth defect, and one bug of ours in analysis tooling. There is no model defect and no benchmark-data defect.