AI3D-382 · detection pass 11: the skirt that works — and the hard column that had to go

0. How to read the renders

Every 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) | BEFORE | AFTER. The BEFORE column always comes first; top row oblique, bottom row the same points top-down; every column is labelled in the image itself.

In sections 3–4 the removed points are drawn in white and drawn last, in both the BEFORE and AFTER panel, so kept paint can never occlude them — white in the BEFORE panel is exactly what disappears in the AFTER panel. White was chosen because sign-ish is magenta. Section 1 (the naive rule) predates that palette fix and simply shows paint before / after.

unmaskedtreemedium_vegetationsign-ish (sign / pole / delineator)guardrailotherremoved by the skirt

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

1. The lesson — what the naive skirt rule did to the crowns

“Unpaint everything below the lowest gap” destroys trees 99.83 % of removed points were crown or trunk

Source skirt/JUDGE.md (30 renders, all viewed) and skirt/skirt_rule.py. Its ceiling table said all 9 063 painted cells on 085 have a ≥ 0.75 m gap. That was read as “the premise holds”. It was the bug: inside a crown, the 0.25 m bins of a single 1 m column are sparse, so the lowest gap lands inside the crown and everything under it goes — trunk, lower crown, the lot.

Over the 475 completed sweep rows the minimum GT-tree loss was 133 402 of 156 209 (85.4 %). On 066 the applied rule removed 67 % of all tree paint. The trunk-column exception never rescued it: it protected 0–537 of 9 063 cells. 13 of 30 tiles were labelled wrong_tree_removed, carrying 27 790 512 of 27 837 510 removed points.

What actually fixed it (skirt/SPEC_skirt.md §1, each change measured on 085 GT):

change	knob	why it works	tree loss on 085
1. hard height cap	skirt_unpaint_max_elev_m = 2.0	A point above the cap can never be unpainted, whatever the profile says. Makes the worst case structurally bounded: a checkerboard hole at 8–18 m is no longer expressible.	133 402 → 586 (cell-only, cap 1.25)
2. 3×3-cell profile	skirt_unpaint_neighbourhood_cells = 1	The gap must be empty across a 3 × 3 m column, which is what “the crown really stops here” means. Crown-internal holes and trunk columns get filled in by neighbours.	3 118 (cell only) → 0 (3×3), same G / cap
3. minimum low-layer size	skirt_unpaint_min_layer_points = 200	The trunk / sapling guard the trunk-column detector failed to be: a trunk base contributes tens of points to a 1 m cell, a grass or bush skirt hundreds. Monotone: 50 → 172 lost, 100 → 47, 150 → 1, 200 → 0.	0
4. drop the trunk-column exception	—	With (2) + (3) it had nothing left to protect and every version tested cost recall. The safety net that looked essential was a symptom of the broken rule.	—

Generalisable: the sweep’s own summary statistic (“every cell has a gap”) was the failure signature, not the licence. It took a vision pass on 30 renders to see it — no scalar in the sweep table said “this is eating crowns”.

2. What changed in the code

Knob defaults as shipped: cell_m 1.0 · bin_m 0.25 · min_elev_m 0.3 · max_elev_m 2.0 · min_gap_m 1.0 · neighbourhood_cells 1 · min_layer_points 200 · max_instance_fraction 0.5 · profile_top_m 40.0. The safety invariant h < gap_floor ≤ max_elev_m is asserted in the unit tests and verified on real data with 0.30 m of headroom at worst.

3. What the skirt removes — tuning split (r9 → r11)

20 tiles, 89.5 % of all removed points inspected, 0 wrong-tree removals 100.00 % point-weighted correct

Six of the twenty, chosen for what they prove: the two largest regions, the guardrail case, the understory case, the trunk-safety case, and the worst-looking truth-trunk probe. Point-weighted split of the sample: 78.69 % road / kerb / guardrail / shoulder, 21.31 % shrub / grass, 0 % mixed, 0 % unclear, 0 % wrong_tree_removed.

Max removed height 1.699 / 0.992 / 1.526 / 1.437 m (018 / 060 / 066 / 085): the 2.0 m cap never binds, 0 points at or above 2.0 m, 0 points below 0.3 m. 52–87 % of removed points have no retained tree paint above 3 m in their own cell — detached verge / kerb / rail strips, not columns under a crown.

4. The gate renders — validation split (val_r9 → val_r11)

26 regions, 89.3 % of removed points inspected, 26/26 correct gate PASS

Segments 003 / 022 / 023 / 087 / 093 / 094, never tuned on, first look. No threshold was changed after opening them. Heights here are an independent proxy (RecordIndex 2 m-cell z-p5) because these segments have no cached DEM.

Crown safety, three independent ways: M1 (> 10 m) and M1b (4–10 m) are bit-identical val_r9 → val_r11; tree paint > 1 m falls by only 14 433 of the 583 552 removed points, i.e. 97.5 % of all removed paint is below 1 m AGL; and the crown silhouette above the removal is pixel-identical in every r9/r11 pair.

Honest note, not a blocker: on 022 and inside the woods on 003 / 087 the skirt removes genuine woody understorey, not only verge grass and guardrail. That is what the pass is for — that material is not tree — but it is why 022 loses 2.35 % against 094’s 0.23 %, and why one instance on 087 loses 46.4 % of its points (inside the 0.5 guard, detection row unchanged).

5. The 003 mast cases — why hard-column was reverted

The pass unpainted 0 points on all six validation segments revert

These are the exact cases the feature was designed for, held out of the tuning split on purpose since pass 10. hard_column_count = 0 on all 322 validation tree detections; on the tuning split the pass ever fired once, for 121 points.

Three independent default gates each veto the 003 lamp mast on their own: (1) it is tree instance 52 whose entire above-1 m paint is the mast, so inst_mrf = 0.0367 < min_instance_mrf 0.15 → skipped as “no foliage” and never reconsidered; (2) the cell has mrf = 0.0331 against a max_multi_return_fraction cap of 0.015; (3) the crown test reports crown_evidence = True because a real conifer stands within 3 m.

Nothing about the pass was unsafe — it simply does not work at its shipped defaults. It cost extra code, four CSV columns, one JSON field and a share of the runtime for zero measured benefit over 10 segments. A rule that could reach this mast has to start from the inst_mrf < 0.15 population the current gate throws away: a new design, not a retune. Also worth recording: the pass-10 max_bbox_m / grid-phase finding was never fixed, and all four bbox-fix commits touched only the now-deleted files — none of that work is live.

6. Results

6.1 085 human ground truth (1 872 942 pts, 100.000 % matched within 5 cm)

Removed GT points by class: tree 0 (0.00 %) · low_veg −11 483 (62.4 % of its r9 paint) · medium_veg −11 582 (13.5 %) · guardrail −4 148 (66.1 %) · road −3 540 (17.8 %) · c70 −122 · c76 0. Height band of every removed GT point: 0.3–1 m 30 657, 1–2 m 218, nothing else. lost_tree_bands {}. The offline model predicted precision 0.6101 and the detector measured 0.6084 — the ~2 % gap is a half-cell grid-phase shift (the detector keys cells on floor(xy − frame_origin), the offline sweep on floor(world_xy)) plus a DEM difference, and it is two-sided across segments, which is the signature of a phase shift rather than a rule mismatch.

6.2 Validation gate table (val_base | val_r9 | val_r11)

The single M3 move is 022 cell (−2922, −1994), 871 points: those points are tree-painted in val_r9 too — removing the low layer under them raised the cell’s remaining above-1 m mrf signature past the M3 test. No new contamination is created. Gate integrity: cfg/val_r11.json had hard-column enabled as well, but it reported instances_touched = 0 / points_unpainted = 0 / rejected = 0 on all six segments, so the skirt-only config that ships is exactly what was gated.

6.3 Per-segment removal, all 10 segments

* gate heights are the RecordIndex z-p5 proxy, not a DEM: 17 of 583 552 points read ≥ 2.0 m on it (max 2.45 m), which is proxy noise on sloped verges, not a cap violation — the detector’s own cap is enforced against its live ground model. 0 points added anywhere; 0 instances skipped anywhere. Detection layer identical on all 10 segments: 0 removed, 0 added, position and n_points bit-identical, no pre-existing JSON or CSV cell changed.

7. What did not improve, and what is still open

• Recall did not move, at all, anywhere. tp 156 209 on the 085 GT in base, r9 and r11; M1 / M1b / M2 bit-identical on both splits. This pass is purely a precision pass — every point it can touch is below 2 m.
• The mast / gantry recall problem is untouched and now has no code behind it. Two genuine masts plus a whole vineyard trellis run are tree-painted on the six unseen segments, and after the revert nothing in the codebase addresses them.
• Runtime went the wrong way: +27.9 % on the gate split, and the tuning-split stage cost (5.3–22.1 s) already misses the spec’s own < 10 s/segment budget on 066 and 085. The skirt is a third full record-streaming pass and it discards the returns channel it asks for.
• The fraction guard has never fired. max_instance_fraction = 0.5 is measured against the whole instance, so with a worst case of 46.4 % it did not trigger on any of the 10 segments. It is untested in production terms.
• Skipped rows are indistinguishable from zero-effect rows in the sense that both report 0/0; only the empty-vs-0 CSV distinction separates “the pass did not run” from “it ran and removed nothing”.
• Four commits carry a Co-authored-by: Cursor trailer injected by the Cursor CLI. HEAD was amended clean; the earlier ones cannot be fixed without a rebase, which house rules forbid. Needs a human decision.

8. Next

• Share one _collect_painted_points pass across hardblob / guardrail-mask / skirt. It is the single change that buys back most of the +27.9 %, and it is the same finding pass 10 raised for hard-column — now with a stage that actually ships.
• Decide the trailer question and then push. Branch feat/AI3D-382-returns-recall is 13 commits ahead of origin, working tree clean, not pushed; PR #10 is open.
• Do not promote skirt_unpaint_enabled to the packaged default. It is ON in configs/a1nr_returns_recommended.json only; the packaged default stays false so default outputs stay bit-identical, exactly as the three passes before it.
• If the mast class is wanted back, start from the population the old gate discarded (inst_mrf < 0.15, i.e. instances whose entire above-1 m paint is the column) and treat it as a new design with its own spec and its own gate. Do not retune the deleted knobs.
• Consider measuring the fraction guard against the touched cells rather than the whole instance, so it can actually protect a small instance; then re-run the tuning split, since it would change measured numbers.
• Artefacts: eval/r11_judgement.md, eval/val_r11_judgement.md, eval/r11_gt085.json, eval/r11_paint_diff.json, eval/val_r11_paint_diff.json, eval/val_r11_det_diff.json, skirt/SPEC_skirt.md, skirt/JUDGE.md, skirt/JUDGE_spec.md, analysis/r11_renders/, analysis/val_r11_renders/, cfg/r11_recommended.json.