AI3D-382 · detection pass 10: hard-column unpaint — precision-perfect, tree-safe, and its target class is not on this split

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) | r9 (the BEFORE reference) | r10. The BEFORE column always comes first; top row oblique, bottom row the same points top-down; each column is labelled in the image itself. Two figures in section 2 and one in section 3 are r9 truth-probe zooms reproduced for identification, 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

One new optional stage, hard-column unpaint: it reconsiders exactly the blobs hardblob deliberately keeps (≤ 4 cells, plan bbox ≤ 1.5 m — the trunk exception) and unpaints them only when the column is hard (low multi-return fraction), tall (≥ 4 m span) and has no crown above it. The two passes never contend for the same cells.

2. The one hit — 121 points on 085

The whole effect of the pass on the tuning split, in one spot correct removal

seg 085 · centroid (2293.42, 1232.39) · npts 121 · cells 2 · bbox 0.62 × 0.47 m · h 1.00 → 5.81 m (span 4.81 m) · mrf 0.0083 · instance 0 (tree, vegetation_rf). There is no second event to sample — this is event 1 of 1.

121 points removed, of which 17 have a GT twin — all class 76, all in the 1–2 m band. The 69 painted points that remain at the spot are all in the 0.3–1 m band, below hard_column_min_elev_m = 1.0: unreachable by construction, not a partial failure.

3. The trunks that stayed — the three most marginal ones

Every truth trunk keeps 100.000 % of its paint 7/7 at 0.000 %

Shown are the three trunks with the smallest margin against each of the three separating gates, plus the second 085 candidate for context. If the rule were going to damage a tree anywhere on this split, it would be in these four crops.

Margins that held: column mrf 0.021 vs cap 0.015 (1.4x), top gap 1.50 m vs gate 0.75 m (2x), crown_multi 187 vs floor 40 (4.7x). Nothing was unpainted above 5.81 m anywhere on any segment.

4. The “misses” that are not misses

All 5 gantry_or_gate sites on the tuning split are canopy recall unmeasurable here

These are the sites where a gantry column ought to be, taken from the run’s own gantry_or_gate detections. Look at the RGB and number_of_returns panels: every one is a tree. This is the evidence behind “the target class does not exist on this split”.

site	seg	tree paint within 1.5 m (r9 = r10)	lost	mrf(h≥1 m) within 2.5 m	min 1 m-cell mrf	min 0.3 m-cell mrf
gantry_841	018	6 127	0	0.361	0.2323	0.0652 (span 1.13 m)
gantry_217	066	7 859	0	0.391	0.2561	0.1081
gantry_103	085	1 667	0	0.909	0.7400	0.6000
gantry_893	085	782	0	0.864	0.7159	0.5312
gantry_191	085	168 (all 0.3–1 m)	0	0.115	no cell ≥ 25 pts at any cell size

No cell at any of these sites clears the hard-cell test at any cell size (1.0 / 0.5 / 0.3 m) even with the mrf cap relaxed to 0.10. The tree paint at these sites is multi-return foliage, not steel.

5. Results

5.1 Truth hit table — painted tree points within 1.5 m of each candidate

7/7 trunks untouched (far under the 2 % tolerance); 1/1 non-tree column unpainted. Truth labels: masts/TRUTH.md — 7 trunk, 1 other_structure, 0 mast, 0 gantry_column.

5.2 085 human GT (1 872 942 points, 100.000 % matched within 5 cm)

Painted GT by class: tree 156 209 → 156 209 (0), medium_veg 86 032 → 86 032, road 19 892 → 19 892, low_veg 18 416 → 18 416, guardrail 6 276 → 6 276, c76 571 → 554 (−17), c70 226 → 226. GT-tree loss target (~0): PASS, exactly 0.

5.3 det_diff r10 vs r9 (TOL 1 m)

No pre-existing key changes value on any detection in any segment. The only JSON difference is three append-only keys (hard_column_count, hard_column_unpainted_points, hard_column_max_span_m) on tree-path trees only (41 / 52 / 64 / 4 rows). tree_clusters.csv: same row counts (95 / 120 / 100 / 37), no shared column changes, four new append-only columns. clusters.csv and rail_halfposts.csv md5 SAME on all four. Pre-existing convention, not new: the 085 tree that lost 121 painted points keeps its old n_points — unpaint passes edit the mask, not the detection record.

5.4 Points unpainted per segment

5.5 canopy_eval 018 + 060 — every metric +0

This is not “within noise” — it is provable: point_masks.npz is byte-identical on both segments, so nothing could have moved.

5.6 Runtime

The +137…+199 s is mostly machine contention: stages whose code did not change are themselves 1.7–2.9x slower in the r10 run. Corrected by the hard-blob factor the new pass costs ~6–19 s per segment (2–5 % of runtime) — about what hardblob costs, because it repeats the same collect + cell-bin work over the same instances. Worst segment 603 s = 10.1 min, inside the 20 min/segment budget.

6. Review of 74f7406..c2ba65b

Scope: hardcolumn.py, the detect.py hook, the config model, the packaged JSON, README, 27 tests. 1 839 pytest passed, ruff and format clean.

7. Next

• The validation-split gate is still pending for this feature, and it must not be tuned on. Segments 003 / 022 / 023 / 087 / 093 / 094 were deliberately not looked at, rendered or tuned on in this round. The lamp-mast and gantry-column cases the pass exists for are the 003 panels in the before/after gallery — those are gate cases, not tuning cases.
• Decide ON/OFF at the gate, not here. Ship the code merged with hard_column_unpaint_enabled = false exactly as it is now; do not promote the r10 config to “recommended” on tuning evidence that amounts to 121 points and 17 GT points.
• Resolve the bbox / grid-phase finding before the gate run, because it changes what the gate measures. Either fix the convention ((max − min) · cell_m, or raise max_bbox_m to 2.0) or accept single-cell-only behaviour explicitly — but re-run the tuning split afterwards, since every number on this page assumes the current rule.
• If the gate shows the pass still misses the 003 masts, the first thing to measure there is the painted cell mrf at the mast. This split says foliage overlap keeps it well above 0.015 whenever the column sits inside a crown — that, not the crown gates, is the likely blocker. The crown gates have 2x–4.7x margin against the trunk truth and should stay put.
• Do not spend the mrf cap. Relaxing 0.015 → 0.10 (6.7x) adds zero mast candidates and pulls all 7 truth trunks into the candidate set, where only the crown gates keep them.
• Artefacts: eval/r10_judgement.md, eval/r10_paint_diff.json, eval/r10_gt085.json, eval/r10_det_diff.json, eval/r10_gantry_cells.json, eval/r10_canopy.md, analysis/r10_renders/, spec masts/SPEC_hard_column.md, truth masts/TRUTH.md.