A4_5 line-width production run

2026-07-21 · AI3D-346 · technical report for the 3DAI team

Summary

Step 7 ran over all 143 segments of Abschnitt 4_5 on Battlebox with the new two-edge line-width measurement (branch ai3d-341-line-width). 1778 lane segments were fitted with zero errors; 99.4 % of widths came from the plateau fit (11 mask-integral fallbacks, 40 flagged). Dashed lines median 0.151 m, solid lines median 0.286 m — matching the 0.15 m Leitlinie / ~0.30 m Randlinie standards. The production XML run7_lanes_20260721-120038.xml carries a <Width> element on all 1710 exported Lines/Splines, with a geoshift identical to previous runs. 5323 control plots and width-scaled overlays on the step-4 and step-6b intensity rasters were generated. Measured width overhead: +5.8 % fit time (isolated A/B).

Width results

type	n	median	IQR	p5–p95	min–max	σ_w median
DASHED	1055	0.151 m	0.146–0.218	0.142–0.303	0.040–0.495	1.3 mm
SOLID	723	0.286 m	0.278–0.293	0.256–0.346	0.086–0.597	0.9 mm

The dashed population is bimodal: the main mode sits exactly on the 0.15 m Leitlinie; a genuine secondary population near 0.30 m corresponds to wide (Breitstrich-type) dashes on exit/entry lanes — that is real paint, not fit error. Solid edge lines cluster tightly at 0.28–0.29 m. Median per-edge blur is ≈1 cm; Jacobian σ_w is ≈1 mm (optimistic under spatial correlation, as documented in the design report).

width plateau fit — Typical solid line (segment_050): two-edge plateau fit, w = 0.29 m, independent edge blurs.

line end fit — Line-end control plot (segment_000): rising-edge erf fit on the inward arc-length histogram.

QA & flags

fit 1767 mask-integral 11 flagged 40 errors 0

11 mask-integral fallbacks (0.6 %): plateau fit rejected, average mask-width integration used instead (0.12–0.41 m). Several are very large curved solid clusters (up to 336k points). Note: rejected fits currently produce no control plot — only accepted fits plot; if fallback plots are wanted, that is a small follow-up.
7 narrow flags (<0.08 m): worn paint — the lateral profile is Gaussian rather than a plateau, so the edges collapse (example below). The flag correctly identifies unreliable widths.
33 wide flags (>0.35 m): mostly 0.35–0.42 m solid lines just above the band edge, plus true double lines merged into one cluster (0.52–0.60 m, example below). The 0.35 m upper flag bound may be slightly tight for this dataset's Randlinie; double lines arguably deserve their own detection.

Flagged narrow (segment_139, w = 0.04 m): worn dash, Gaussian profile, no plateau — flag fires correctly.

double line — Flagged wide (segment_134, w = 0.60 m): double-hump lateral distribution — two adjacent lines in one cluster.

All 5323 control plots (every accepted end + width fit, all 143 segments) are on Battlebox: /home/ai/ai3d346_linewidth/control_plots_full/. Control plots are off by default; future runs can enable them via the new opt-in histogram_dir config key in lane_segment_ends / lane_segment_width.

Overlays

The overlay renderer now draws each Line/Spline at its measured metric width (Value × pixels_per_meter) instead of a fixed 4 px stroke; flagged widths draw red. Rendered on both the step-4 road intensity tiles and the new step-6b cluster rasterizations (intensity channel — RGB cluster tiles are blank in this dataset, and the package default now uses intensity).

overlay on road raster — segment_050 on the step-4 intensity raster: dashes (yellow) and edge lines (magenta) drawn at measured width, road axis cyan.

overlay on cluster raster — Zoom on the step-6b cluster raster: the width-scaled dash stroke covers the cluster pixels (gray fringes visible at the ends where paint extends past the fitted axis span).

collage part — Collage part 2/5 (segments 29–57) over the cluster tiles.

XML

run7_lanes_20260721-120038.xml (17.8 MB) contains 1710 <Width> elements — one per exported Line and Spline:

<Width>
  <Value>0.12996</Value>
  <Sigma>0.02281</Sigma>
  <Status>fit</Status>
  <Flagged>false</Flagged>
</Width>

Value/Sigma are omitted when no width was measured (Status failed); the element is omitted entirely for segments without a measurement. Geoshift consistency: the new XML's <Geoshift> (725883.5409 / 5422097.8089 / 390.8318) is byte-identical to the previous production XML — the dataset's stored geoshift is loaded unchanged; none of the width changes touch coordinate frames.

Timing

measurement	result
Isolated A/B (width on/off, 47 clusters, quiet machine)	+5.8 % fit time (mean 178 ms/cluster)
Direct `measure_line_width` calls	median 44 ms, mean 87 ms
Heaviest mid-dataset clusters (315k–480k pts)	ends+width = 1–2 % of an 11–24 s fit
Full run wall clock vs 2026-07-20 baseline	106 → 151 min (+42 %) — contaminated

The +42 % wall-clock comparison is not attributable to the width code: the eval job ran concurrently on the same box for the first two hours and the control-plot generation for the last hour. The clean isolated numbers put the real overhead at ≈6 % (ends+width), shrinking to 1–2 % on the heavy middle segments where total time is dominated by the pre-existing solid-spline fitting. GPU offload was evaluated and is not worthwhile at ≤6 %. A further ~3 % is recoverable by sharing one axis frame between the ends and width fits.

Artifacts & code

what	where
XML with widths	`…/260416_Abschnitt_4_5/lane_points/run7_lanes_20260721-120038.xml` (D: drive, Battlebox)
Full run log	`/home/ai/ai3d346_linewidth/step7_full.log`
Per-cluster eval JSON	`/home/ai/ai3d346_linewidth/eval_full.json` (1778 rows)
Control plots (5323)	`/home/ai/ai3d346_linewidth/control_plots_full/`
6b cluster tiles	`…/lane_points/topdown_tiles_run6_clusters/`
Width overlays (cluster tiles)	`…/lane_points/topdown_tiles_run6_clusters_run7_overlay_int/` + `_collage/`
Width overlays (road tiles)	`…/lane_points/topdown_tiles_run7_overlay_width/` + `_collage/`

PR	content
modellinglines #8	axis frame, ends rewrite, width measurement, snapshot + info_dict export, control-plot tooling, opt-in `histogram_dir`
modellingexport #3	`<Width>` element on Line/Spline
visualizationoverlays #1	metric-width rendering, flagged color, geoshift frame hint (integrated Battlebox WIP), step6b intensity default, v0.3.0

Battlebox wiring: LaneFinder pyproject.toml points iolabs-point-cloud-visualization-overlays at the branch worktree /home/ai/ai3d346_linewidth/overlays-width (editable); modelling-lines/-export ran via PYTHONPATH shadowing of the branch checkouts. The overlays repo's main checkout on Battlebox still holds the (now-integrated) uncommitted WIP — it can be reset once PR #1 lands.

Known issues & next steps

First 6b overlay pass used the blank RGB tiles → topdown_tiles_run6_clusters_run7_overlay/ contains white-background images; superseded by …_overlay_int/. Safe to delete.
segment_033 run6_cluster_008.npz (308k pts) is dropped by the pre-existing "spline changed direction too much" gate — its paint is unmodelled. Separate ticket suggested.
Flag band upper bound 0.35 m catches ~30 legitimate-looking 0.35–0.42 m Randlinien — consider 0.40, or a separate double-line class for the 0.5–0.6 m cases.
Rejected width fits produce no control plot; plotting the histogram on rejection would make the 11 fallbacks reviewable.
Optional ~3 % speedup: share one axis frame between ends and width.
Deferred from the design: block-bootstrap σ_w, declaring iolabs-point-cloud-filtering-surface in pyproject.