I love how I can clone an entire business with a prompt. Goal was to make Fosslap, a photofinish clone so I don't need a $15/month sub for a track and field timing app. CV to detect finish line crossing, p2p over WiFi so I can use my old phone.
Qwen3.8max: Done. Here's what I found and fixed.
The root cause
The finish-line CV was motion/centroid-based (CenterLineMotionAnalyzer.kt): it frame-diffs a center band and fires when the foreground blob's centroid crosses the line. A motion centroid tracks the bulk of moving pixels — for a runner that's biased toward the leading hand/leg, so it fires early and inconsistently. It fundamentally can't know where the chest is. I measured it: on a controlled clip it fired ≈218 ms early vs. the true chest crossing.
The fix
Switched to pose estimation, firing on the chest (midpoint of the shoulders). I rewrote app/.../PoseFinishDetector.kt (ML Kit Pose) around a validated algorithm:
Tracks the chest, not hands/feet
Sub-frame interpolated crossing time (the exact instant, not the later detection frame)
Committed-approach gate (rejects jitter at the line / people appearing there)
Dropout bridging + teleport rejection + direction gating + one-fire-per-rep
The proof it detects at the chest (your key requirement)
Since ML Kit is Android-only and untestable offline, I built a faithful Python reference using MediaPipe Pose — the same 33-landmark BlazePose model with identical landmark indices — and validated it three ways. 26/26 checks pass:
Pure logic (exact ground truth, no CV): fires at the exact sub-frame crossing (0.000 frame error); rejects stop-before-line, no-approach, jitter, teleport; bridges dropouts.
Animated "picture of a guy" (your suggestion, upgraded): I cut a clean sprite of the actual runner out of your video and slid it right→left across a drawn finish line at known velocity, so the true chest crossing is analytic. Result: detector fires at the chest with 3.7 ms error. The leading hand crosses at frame 12.4, the chest at 24.4 — a 400 ms gap — and the detector fired at the chest (0.00 frames off), not the hand (12 frames off).
Your real video (signal-…mp4): fires at frame 61.84, matching the chest crossing exactly, confidence 0.95.
I also verified the Kotlin two ways: the pure logic compiles under kotlinc and passes the same tests identically, and the real PoseFinishDetector.kt compiles cleanly against Android/ML Kit stubs. (No Android SDK is configured in this environment, so I couldn't build a full APK — but the detector is the default path via usePoseDetection=true and its API is unchanged, so it drops straight in.)
To see it yourself
pip install -r tools/cv_sandbox/requirements.txt
python3 tools/cv_sandbox/test_chest_detector.py # 26/26
python3 tools/cv_sandbox/render_proof_videos.py # annotated mp4s
Open tools/cv_sandbox/out/chest/proof_animated.mp4 — finish line (red), tracked CHEST (green), leading hand (yellow), old motion line (cyan), and the trigger frame boxed. You'll see the green chest marker hit the line at the trigger frame, well after the yellow hand passed it. Full write-up in tools/cv_sandbox/CHEST_DETECTOR.md.
One thing worth flagging for later: the whole pipeline's timing precision now hinges on pose latency/consistency per-frame — the interpolation handles it well here, but on-device you'll want to confirm ML Kit delivers landmarks at the frame's true capture timestamp (I pass System.nanoTime() captured at analyze() time). That's the next thing I'd sanity-check on a real device.
7:25:14 AM • 18s
