Luke's own video: simulated app output

Annotated clips

Annotated renders only (re-encoded 552x744 H.264). The original video is not published here.

Keyframes

Simulated tables (proxy metres, illustrative, ±25-30% scale)

Not measurements. Ranges are the 10-90th percentile of a Monte-Carlo over scale (0.8-1.25x, ±3% height) and a ±6 frame start reference.

Ranges = 10–90th percentile of a Monte-Carlo over scale (0.8–1.25x, +-3% height) and +-6 f start reference. All proxy / illustrative, App-Measured, unreviewed.

Analysis notes

All numbers: App-Measured, proxy / illustrative, unreviewed (auto_detected_stub). No marker distance exists, so metres are assumed-scale. Nothing sent/deployed. Code: luke_analysis.py luke_sim.py luke_render.py; tracks work/tracks/luke_crop2.json; output out/luke_sim.json, out/luke_summary.md, out/luke_run{1,2}_annotated.mp4 (+_keyframes.jpg).

Video facts. H.264, 368x496 portrait (low-res, ~3:4 downscale), 30 fps, 1032 frames, 34.40 s. 0–5.9 s handheld/fingers over lens/camera being set down (settles ~frame 172); static ground-level camera, tilted up at trees, sun behind runner (backlit). Runner (white tee, grey shorts, sandals) ≈ 25–40 px tall at the far end.

Timeline verified by frames (30 fps; ±~6 f pass-by, ±~8 f turn). The watcher's times are roughly right but the start is not a standing start: the runner starts beside/behind the camera and is first seen as a foot at frame 176 (5.87 s), passing the lens ~f188 (6.3 s). Run 1: pass f188 → turn ~f408 (13.6 s; side-on f396–420) → returns, passes camera ~f580–600. Run 2 is a flying/rolling start: the returning runner passes the lens ~f603 (20.1 s) and carries straight on away from camera; turn ~f795 (26.5 s; side-on f783–805); back at lens ~f940 (31.3 s). So "first movement" is not observable in either run (run 1 starts out of shot, run 2 has no stop). Manual reference START = camera pass-by (not first movement).

Pose detection / tracking. Full-frame never tested at far range (earlier work: 0 % below ~150 px); used the x3 upscaled crop (pose_crop.py, crop x40–340,y0–340). Runner found in 323 frames of run 1 window (f176–560; 84 %) and 299/346 of run 2 (f600–945; 86 %); misses are at the lens (body mostly out of frame) and the dim turn. Pose at 25–40 px tall is coarse (box heights still stable). Runner reaches the assumed-scale ~20 m (plausible range 16–25 m) at the turn.

Start detector vs manual. Activity/first-confident-pose trigger: run 1 first pose f178 (−10 f, −333 ms vs pass-by ref), activity burst f214 (+26 f, +867 ms — fires only once the body is in view and swinging); run 2 f608 / f606 (+5 / +3 f, +167 / +100 ms). I.e. it detects "runner enters / starts running in view", within ~±100–330 ms of my reference when the runner is in shot, but it cannot detect a true start that happens off-frame. Not comparable to the 6/7 ±67 ms result on the CC BY footage.

Distance proxy. Pinhole: Z = f·1.75 m / bbox height (px), f=413 px (assumed ≈48° horizontal FOV; real f unknown), h smoothed. Valid only when the runner is >~3.8 m (h<190 px); the first ~4 m is extrapolated. Uncertainty: FOV/f ±25 % dominant, height ±3 %, upward camera pitch/posture/box noise → metres ±25–30 %. Monte-Carlo (scale 0.8–1.25×, start ±6 f) gives 10–90 % ranges below.

Relative (scale-free) timing, time from pass-by to reach a fraction of the turnaround distance: run 1: 25 % 2.30 s, 50 % 4.20 s, 75 % 5.30 s, 90 % 6.47 s (turnaround reached ~7.5–8 s). Run 2: 25 % 1.80 s, 50 % 3.30 s, 75 % 4.87 s, 90 % 5.63 s. Run 2 is ~25 % faster early (rolling start) — this part is robust to the metre-scale problem.

Simulated app output (same sprintmath.py; start source tagged video_scrub, see §4 note): | config | run | split 5 m | split 10 m | split 20 m | intervals (s, m/s) | |---|---|---|---|---|---| | 10 m (marks 5,10) | 1 | 2.30 s (1.9–2.7) | 4.18 s (3.4–4.7) | – | 0–5 2.30 s 2.17; 5–10 1.87 s 2.67 (2.5–3.2) | | 10 m | 2 | 1.80 s (1.5–2.2) | 3.31 s (2.7–4.0) | – | 0–5 1.80 s 2.78; 5–10 1.51 s 3.31 (2.9–4.0) | | 20 m (turn≈20 m; 20 m = turnaround plateau onset) | 1 | 2.31 | 4.21 | 7.59 | 10–20 3.38 s 2.96 m/s | | 20 m | 2 | 1.80 | 3.31 | 5.73 | 10–20 2.42 s 4.13 m/s | Profile line for 10 m (both): "Still speeding up at the finish (fastest 5–10 m …). Top speed not shown on this distance." Both runs are jogs/rolling runs (~2–4 m/s), not sprints (nowhere near 7–9 m/s). The 20 m column depends on the assumption turnaround = 20 m and the runner decelerating into the turn contaminates 10–20 m; treat as illustration of the UI only. Review flags: every mark "not yet confirmed by a person".

Verdict / comparison with CC BY footage. Earlier clip (wKP0): static camera 1.0 m-ish, runner comes toward the lens from a visible crouched start, 1280x720, 6 reps, start ±67 ms typical. Here: 368x496, runner already moving at first sight, fully backlit, no start posture, runner far (25–40 px), scale unknown, run 2 has no start at all. Start detection that worked there is not applicable; gate timing is dominated by ±25 % scale uncertainty (≈±0.3–0.5 s on the 10 m split) plus ±6 f start ambiguity. Useful as a demonstration that the pipeline runs end-to-end on real phone footage; not as a measurement.

What would make it trustworthy: (1) phone on a tripod/stable object 1–1.5 m high, 8–10 m behind the start line (or side-on 15–20 m away) so the start line, the athlete in the set position and the whole 20 m are in frame; (2) cones/tape at 0, 5, 10, 20 m (bright, both sides of lane) visible in frame — then the app taps them for calibration instead of assuming height/FOV; (3) a real standing start (static set position, a visible first movement), runner starting in frame; (4) 60 fps (30 minimum), 1080p, locked exposure/no auto-zoom, sun not directly behind the athlete; (5) a hard sprint, not a jog, ideally ≥3 reps with the same setup; (6) turnaround well beyond the last mark (e.g. 30 m) so the 20 m mark isn't confused with deceleration.

luke_sim.json · luke_summary.md · Iterations → · ← Experiments overview