Two tracking jobs, not one camera trick
Hawk-Eye describes ball tracking and player tracking as related optical-tracking applications, but they do not produce the same kind of evidence. A ball system is concerned with locating a small, fast object and modelling its movement. A player system must recognise a person-shaped subject, estimate body points and keep useful associations as people cross or overlap. Treating both outputs as one generic ‘Hawk-Eye view’ can make a graphic seem to answer a question it was never designed to answer.
That distinction also matters across sports. Hawk-Eye’s provider pages list ball tracking, player tracking and biomechanics among its data capabilities, while its officiating page presents ball movement and rotation separately from SkeleTRACK. A product catalogue is not proof that every event, venue or cricket review uses every capability. For a wider introduction to how cameras become sports data, see computer vision in sports.
Step one: finding the ball in each 2D image
The starting point for optical ball tracking is image detection. In Sony’s engineering interview, Hawk-Eye describes 2D vision processing that finds the centre of the ball in an image. This is a frame-by-frame observation in a camera’s own view, rather than a finished three-dimensional flight path. The system must distinguish the ball from field markings, bodies, equipment, shadows and motion blur.
An individual camera view can be helpful, but it has limits: it flattens depth and may lose sight of the ball behind a player or object. The provider describes ball tracking as focusing on movement and rotation; that does not mean every image alone reveals every property, or that a broadcast shot is a measurement system.
Calibrated angles turn observations into a 3D position
A multi-camera arrangement can add depth when its camera views are calibrated to a shared spatial model. When more than one view observes the ball, the corresponding 2D detections can be triangulated to estimate a three-dimensional location. Sony’s interview characterises this as 3D triangulation and modelling the ball’s flight over time.
Calibration is the bridge between pixels and a common coordinate system: it accounts for where each camera is positioned and how it sees the playing area. The estimated locations arrive as a sequence, not a single magical answer. The resulting time series can describe a path through space, subject to the available observations and the model’s handling of gaps or partial views. The example configurations discussed by Sony are examples, not a universal camera count or a claim about any named match.
From a measured path to a projected trajectory
Once the system has a succession of estimated ball positions, it can model the trajectory across time. That supports a rendered ball-path graphic and, in uses that require it, a projection of continuing flight. A projection is a modelled extension based on the detected path and its assumptions; it should not be confused with an additional camera observation.
This is why the smooth arc on screen is easier to read than a sequence of raw camera frames. It can communicate where the model places the ball at successive moments and how the flight is expected to continue. In cricket, that visualisation may appear alongside a review workflow, but it does not establish that player tracking is active, nor does it settle the governing rule by itself. The separate DRS timer in cricket guide explains why technology output and review procedure are different layers.
Player tracking starts with bodies, joints and identity
Player tracking has a different target. Instead of finding one compact ball, it can estimate a human skeleton: a set of body landmarks connected in a pose. Hawk-Eye says its SkeleTRACK product tracks 29 skeletal points on each player in real time in supported sports. That type of output can support biomechanical and movement analysis, alongside player and ball data.
Useful player tracking also has an identity problem. A system needs to associate observations of the same player over time, even as players run close together, turn away or briefly block one another from a camera. Skeletal landmarks can describe pose, while identity association helps keep a timeline attached to the right person. Neither should be inferred from a ball path alone. Tracking identities through crowded play explores that harder association task without assuming it is solved in every clip or sport.
SMART replay is a separate synchronized video product
A ball trajectory graphic is not the same thing as Hawk-Eye’s SMART video review. The provider describes SMART as synchronized capture and playback of video and audio, with multi-angle playback control for officials. Sony likewise describes synchronized footage from multiple angles as a separate main technology alongside ball tracking.
SMART can help reviewers line up camera views around the same moment and inspect them independently. It is a replay and evidence-navigation workflow, not a promise that the replay system has generated a 3D ball trajectory or a skeletal player model. Conversely, a tracking output does not itself decide which video angle an official should review or what a competition’s protocol permits. For the broader analysis layer that may sit beside video, read AI video analysis in sports.
What a ball-path graphic cannot prove
A ball-path visualisation is evidence of a particular tracking model’s reconstruction and, where shown, projection. By itself it cannot prove an off-camera touch, a bat contact, a player’s intent, an identity, or the legal interpretation of an incident. It also cannot show that every relevant instant was visible to the cameras; occlusion and ambiguous images remain practical limits.
The responsible question is therefore narrower: what was detected, reconstructed or projected, and what decision rule is allowed to use it? Separate evidence types can complement each other—synchronized replay for visible contact, ball tracking for flight, and skeletal data for supported player analysis—but none should be promoted into a universal account of a play. This is a provider-specific explanation of stated Hawk-Eye capabilities, not a report that any particular match used them.
Reading the output with the right scope
A credible explanation labels the system, sport and task before drawing a conclusion. Ask whether the display is a camera replay, a reconstructed ball path, a projected trajectory, a skeletal-data view or a combination. Then ask whether the relevant product was actually available and whether the sport’s rules allow that output to inform a decision. Those questions prevent a familiar-looking graphic from being mistaken for automatic proof.
Keeping those systems distinct makes the technology more understandable—and makes its limits clearer.