Case study

Deciding how "threatening" an object is without pretending to measure distance.

R.A.S doesn't know how far away that car actually is. Here's why that's fine, and how the threat-level system works anyway.

The problem

Object detection tells you what's in frame. It doesn't tell you what matters.

YOLOv8 will happily detect every car, pedestrian, and sign in a busy street scene — which is not the same thing as knowing which of those objects the rider actually needs to react to. A parked car three lanes over and a car cutting into the rider's lane both register as "car detected" with no distinction, and a raw detection overlay with forty boxes on screen is noise, not a story.

The real design problem wasn't detection accuracy — YOLOv8 already handles that well. It was turning "here are forty detected objects" into "here's the one that mattered," without building a full 3D scene-understanding system for what's fundamentally a content tool, not a safety product.

The approach

Bounding-box area as an honest, cheap proxy for "how close."

True distance estimation from a single moving camera needs depth models, calibration, and a lot more compute than a rider-vlogger's desktop is going to have spare during a render. The practical call was to use bounding-box area — how much of the frame an object occupies — as a proxy for proximity, and threshold that into three tiers: Red, Yellow, White. It's a heuristic, not a measurement, and it's explicitly labeled that way rather than dressed up as more sophisticated than it is.

That trade-off only works because of what R.A.S is actually for: making footage read better for a viewer, not making a real-time safety call for the rider. A wrong threat-level color on one frame costs nothing. A missed real hazard in an actual rider-assist system would cost a lot — which is exactly the line the README draws explicitly: post-processing content tool, not a collision-detection system.

The architecture

What's actually running under it.

Detection: YOLOv8 running frame-by-frame, decoded via FFmpeg, with threat tiers computed from bounding-box area.
Rendering: CUDA-accelerated where available, with live FPS telemetry and graceful render cancellation — built as a real tool with a progress state, not a fire-and-forget script.
Desktop UI: PyQt6, styled with what the project itself calls a "hardcore racing aesthetic" — pulse animation on high-risk detections, cinematic glow rendering.
Audio: Original audio track preserved separately and muxed back into the final export after video processing completes.
Distribution: Packaged as a standalone Windows .exe with bundled FFmpeg — no Python or dependency install required for end users.
CLI mode: A separate ras_cli.py entry point for batch processing with a configurable profile (a motorcycle-specific profile ships by default), for anyone who'd rather script it than click through a UI.

The outcome

What's live, and what's on the roadmap.

Detection, threat classification, GPU-accelerated rendering, and audio-preserving export are all built and shipping as a real Windows build. The roadmap is honest about what's next rather than pretending it's finished: a preset system, lean-angle detection for cornering analysis, motion-based telemetry overlays, a real-time live-camera mode, a racing-specific profile pack, and a macOS build are all still ahead.

The disclaimer in the product itself — "not a real-world rider assist, collision detection, or safety system" — isn't legal boilerplate. It's the actual design boundary that made the bounding-box-area heuristic an acceptable trade-off instead of a dangerous shortcut.

Working on a computer-vision or video-intelligence tool and want a second set of eyes on the architecture?

Get in touch