AI3D-382 · detection pass 9: unpaint the seg3d guardrail mask — the rails finally go, and no tree moves

0. How to read the renders

Each comparison render is one spot in the raw no-scan-angle-filter cloud, left to right: true RGB | number_of_returns (grey = 1, orange = 2, red = ≥ 3) | r8 (the BEFORE reference) | r9. The BEFORE column always comes first; top row oblique, bottom row the same points top-down; each column is labelled in the image itself. The last two figures are pass-8 diagnosis panels reproduced for context, captioned individually.

unmaskedtreemedium_vegetationsign-ish (sign / pole / delineator)guardrailother

Click any image for full resolution; ← / → (or swipe) step through the images of that card only; Esc closes.

1. What changed

2. The renders

The rails go — and the trees beside them do not move GT class 66 −75.7 %

Two 085 rail blobs, r8 against r9. In both the removed material is the w-beam itself: a continuous green line down the beam in r8, a broken residual in r9. The residual is where the seg3d model’s own mask stops, not where our rule stops.

085 painted GT, guardrail (66): 25 772 → 6 276 · hard FP 46 519 → 26 965 · tp 156 209 → 156 209. Unpaint bands: 0.3–1 m 23 052, 1–2 m 2, > 2 m 0.

The honest cost: a hedge that grows through the rail 3 500 GT bush/grass points

Any bush growing through a guardrail has its rail-embedded points inside the seg3d guardrail mask, so they get unpainted with the beam. This is structural, not a bug — and it is bounded: the hedge is still detected and still painted, it just loses the sliver at the beam.

085 GT low_veg −2 530 + medium_veg −970 = 3 500 points, 0.6 % of the segment’s veg paint. Also 55 road + 3 c70 points, and 44 points in the 066 1–2 m band (top of a w-beam post cluster, not crown).

Nothing happened to the crowns 0 GT-tree points, M1 / M1b / M2 / M3 identical

The truth crown is the visual check on the metric: r8 and r9 are the same image. The canopy metrics agree to 5 decimal places, and above-1 m tree paint on 018+060 moves by 272 points out of 10.15 M (0.0027 %).

M1 hi 0.83264 · M1b mid 0.898 · M2 foliage 0.90608 · M3 9 cells / 28 556 pts (top-cell list cell-for-cell identical) · M4 6 signs / 56 delineators / 93 trees / 0 GHOST · M6 truth spots 12/12, recall 1.000, 0 FP — every one identical to r8.

Why the rails were there in the first place context, from the pass-8 diagnosis

Two panels from the pass-8 diagnosis that explain the shape of the problem this pass attacks: the paint above 2 m was already perfect, and the offending rail/road points live inside mega-instances that also hold real trees, so no per-cluster rejection could ever reach them. Only a point-level mask could.

Residual after r9 on 085: 19 892 road (71) + 6 276 guardrail (66). The road is not in the mask; the rail residual is the part the seg3d guardrail model misses (no guardrail_top_rail class on 085).

3. Results

085 human GT (1 872 942 annotated points, 100.000 % matched @ 5 cm)

Unpainted r8 → r9 by class: {guardrail 19 496, low_veg 2 530, medium_veg 970, road 55, c70 3}; newly painted: {}. Bands: 0.3–1 m 23 052, 1–2 m 2, > 2 m 0, tree lost 0. nr≥2 share of painted GT 0.5685 → 0.6037.

Per segment — the new guardrail mask unpaint block, detections and runtime

Every touched instance is a tree; no detection dropped anywhere, and per-detection n_points / position lists compare equal r8 vs r9 on all four. hard_blob_unpaint blocks are identical to r8 (independent hook, runs first). Max runtime 414 s = 6.9 min against the 20 min/segment budget; the +26 s on 066 is mask load + point matching over 8 instances. returns stripper, canopy extension, hard-blob unpaint, Tree path and reject_rescue summary blocks are byte-identical; clusters.csv and rail_halfposts.csv md5 SAME on all four; 0 ERROR / Traceback / Exception in any log.

066 streak window x∈[685,706] y∈[317,338] — 3 387 256 raw points in both roots

4. Progress across all passes

085 human GT — base to r9

Recall has never moved, and that is expected. The 085 annotation stops at the height a human could label reliably — canopy points above 10 m are effectively invisible to this GT, so the whole canopy-extension programme (which is where the recall work happened) is unmeasurable here. It is measured by the canopy metrics below.

018 / 060 canopy metrics — base to now

Read the two tables together: the canopy metrics are the recall story (a tree used to be detected but painted only to 10 m; now it is painted to its top), the 085 GT is the precision story (the paint used to include the rail and the deck; now it mostly does not).

5. Next

• Validation-split sanity run — in progress. Segments 003 / 022 / 023 / 087 / 093 / 094, none of which was ever used for tuning, plus an old-data parity check so we know the shipped config does not regress the dataset the detector was originally built on. Base and r9 runs are going now.
• Then a final summary page and handoff — the recommended new-data config is already committed (2a06eb1); what remains is the write-up and the PR.
• Open items that need a human decision, not more tuning:
  • Do attached shrubs and grass count as tree? They are 67 % of the remaining GT “false positives” on 085 — the difference between precision 0.543 and veg-tolerant 0.853. The product definition currently says yes; if it says no, that is a different detector.
  • Mega-instance splitting — the remaining 19 892 road + 6 276 rail points sit inside the two instances that hold every true positive. This is seg3d’s domain, not a paint rule.
  • Tree vs hedge separation — cannot be validated without labels; we have no ground truth that distinguishes them.
  • return_number export — not needed for now; number_of_returns alone carries the whole multi-return signal this work used.