6 posts tagged with "Computer Vision"

That clip up top: sixty point candidates, back to back, sliced automatically out of a 24-minute highlights reel. Almost every one opens on a serve.

Everything still missing from the chart — the serve, the ending, the point score — is missing for the same boring reason: the pipeline has only ever seen one 16-second clip that starts and ends mid-rally. cv-01 called clip sourcing "its own pipeline step" and then I spent four posts avoiding it. This session was the bill coming due.

It also delivered the project's best plot twist so far, but that's at the bottom.

That clip up top: both players boxed and tracked, FOREHAND or BACKHAND called at every swing in the striker's color, their feet moving live on the court diagram — and along the bottom, the match notation typing itself.

M2 ended with a proto-chart that was honest about its ignorance: ??2?1?1?2?2?2???. Every question mark is an M3 requirement, and the biggest one — shot type — needs to know where the players are. That's M0's unfinished business finally coming due: the ball got tracked back in week one, and the players got waved at.

M3 won't fit in one session. This was the first: player tracking, and the first two letters of the charting alphabet.

That clip up top: the pipeline calling HIT and BOUNCE in real time, with every event pinned onto the court diagram as it happens.

M1 ended with a caveat that was really an assignment: the homography maps the ground plane, the ball is airborne most of the rally, and the mapped positions are only true at the moments the ball touches the court. So — find those moments. M2 is hit and bounce detection, and the kickoff post's premise ("every discontinuity is a hit or a bounce") finally meets the data.

The detector ended up right thirteen times out of thirteen. It got there by being wrong twice, and both failures taught me more physics than the successes did.

That clip up top: the M0 ball box on the broadcast frame, and its position drawing itself onto a real court diagram in meters — live, frame by frame.

M0 left me with a ball track in pixel coordinates, and pixel coordinates mean nothing. "The ball is at (622, 462)" tells you nothing about whether that's a winner down the line or a ball kid's pocket. M1 is the conversion: find the court in the frame, compute the homography, turn pixels into meters.

I expected geometry homework. Here's the twist: the milestone I was braced for turned out to need zero manual input and zero API calls. Tracking a ball — the "solved" problem — needed a human to click on it. Finding the court needed nothing but numpy.

That clip up top is SAM 3 riding the game ball through a full broadcast rally — the box is the model's output, not mine.

The kickoff post ended on a question: can SAM 3 actually hold onto a tennis ball at broadcast speed? Short answer: yes — with a catch. Getting there took four runs, two dead ends, and one undocumented response format.