How Does Cricket Ball-Tracking Predict Where the Ball Would Have Gone?
Learn how Hawk-Eye-style cricket ball tracking uses multiple cameras, 3D reconstruction and trajectory modelling to predict whether an LBW delivery would have hit the stumps.
A bowler delivers an inswinger.
The ball pitches, moves back toward the batter and strikes the front pad.
The umpire says not out.
The fielding team reviews.
A few seconds later, television viewers see a computer-generated path continue through the batter's leg and into the stumps.
But the real ball never travelled that final part of the journey.
So how can technology show where it would have gone?
The answer is not that a computer simply looks at the final few centimetres of movement and draws a convenient curve toward the wicket.
Modern cricket ball tracking is a measurement-and-modelling system.
Multiple cameras observe the delivery from different positions. Because the cameras are calibrated against the geometry of the pitch, the system can turn two-dimensional video observations into a sequence of three-dimensional ball positions. From those measured positions, software reconstructs the actual flight and bounce of the delivery. When the ball is stopped by the batter's pad, the system extends the established trajectory to estimate where it would have passed the wicket.
ICC playing conditions use approved ball-tracking technology during LBW reviews to report three things:
- where the ball pitched,
- where it first struck the batter,
- whether its projected path would have hit the wicket.
The ICC currently lists Hawk-Eye and VirtualEye as approved ball-tracking technologies for DRS.
The coloured path you see on screen is therefore partly measurement and partly prediction.
Understanding where one ends and the other begins explains almost everything about how ball tracking works.
The System Starts With Several Views of the Same Ball
A television camera gives you a flat image.
It can tell you that the cricket ball appears at a particular pixel on the screen.
But one camera alone has an important problem:
How far away is the ball?
Imagine looking at a photograph of a cricket pitch.
A small object near the camera and a larger object far away can occupy the same apparent position in the image.
A second viewpoint provides the missing information.
Ball-tracking systems use multiple calibrated cameras placed around the ground so that the same delivery can be observed from different angles.
An early patent describing the technology that became associated with Hawk-Eye specified multiple cameras in fixed positions and noted that the ball's 3D position could be established when information from at least two cameras was available. Additional cameras provided redundancy when a player blocked one view.
The exact modern camera configuration can vary by venue, competition and technology provider, but the underlying geometric idea remains the same:
one camera gives a line of sight
another camera gives another line of sight
their relationship helps locate the ball in three-dimensional space.
The Cameras Must Know Exactly Where They Are
Suppose two cameras see the same ball.
That is still not enough unless the system knows how those cameras relate to the pitch.
Before tracking can be accurate, the cameras have to be calibrated.
The software needs a model of the playing area containing known reference points such as:
- the pitch,
- creases,
- wickets,
- camera positions,
- camera orientation,
- lens characteristics.
Once that geometry is known, a particular pixel in a camera image can be converted into a direction through the real-world playing area.
Do the same thing with another camera and the system can estimate the point in space where those observations correspond.
This general technique is closely related to triangulation and multi-camera 3D reconstruction.
It is the same broad principle that allows two human eyes to perceive depth.
Step 1: Find the Ball in Each Video Frame
A cricket ball is small, fast and often difficult to isolate.
During one delivery, the video may also contain:
- the bowler,
- the batter,
- the bat,
- the wicketkeeper,
- fielders,
- pitch markings,
- shadows,
- spectators,
- advertising.
The tracking software has to identify which image feature is actually the ball.
Older descriptions of the Hawk-Eye approach note that the system did not rely simply on ball colour, because cricket balls can be red, white or pink and can appear differently under changing light.
Instead, ball identification can use information such as:
- position in previous frames,
- expected direction of travel,
- size and motion,
- agreement between different cameras.
Modern computer-vision methods can be more sophisticated, but the fundamental requirement remains the same:
find the ball reliably in a sequence of images.
A single frame is not enough.
The useful information comes from watching its position change over time.
Step 2: Convert Those 2D Observations Into 3D Positions
Suppose Camera A identifies the ball at one point in its image.
Camera B sees the same ball from another angle.
Because both cameras are calibrated, the processor can estimate the ball's position relative to the pitch.
Instead of:
pixel x = 842, pixel y = 316
the system now has something conceptually closer to:
this far along the pitch
this far to the off side
this high above the surface.
Repeat that process across successive video frames and you get a series of 3D points.
Imagine them as invisible dots hanging in space:
● ● ● ● ● ● ●
Connect those dots in time order and the shape of the delivery begins to appear.
This measured 3D track is the foundation of everything that comes later.
The Technology Tracks What Actually Happened Before It Predicts Anything
This distinction matters.
Before the ball reaches the pad, the system has actual observations.
It can reconstruct:
- the ball's initial flight,
- where it pitched,
- how its direction changed after bouncing,
- its path from the pitch toward the batter.
Those sections are based on video measurements.
If the delivery swings before pitching, the cameras observe that movement.
If it turns after pitching, the post-bounce observations contain that change.
The system does not need to guess that the ball spun because it was bowled by a leg-spinner.
It sees the resulting trajectory.
That is an important reason the bounce matters.
The path after the bounce provides real evidence of what the ball was doing after interacting with that particular patch of pitch.
What Happens When the Pad Blocks the Ball?
The cameras can track the ball until the moment it is intercepted by the batter.
After that, there are no more ball positions to measure because the ball has changed path or stopped.
This is where prediction begins.
The software now has a set of measured positions leading up to impact.
It fits a mathematical trajectory to those observations and extends that trajectory forward.
Conceptually:
measured positions
↓
estimate velocity and direction
↓
fit the path that best describes the observed motion
↓
extend that path beyond impact
↓
compare it with the wicket
The result is the familiar projected line continuing through the pad.
A patent describing ball tracking for cricket states that the established 3D trajectory can be used to predict the ball's future flight and map that predicted path against features such as the stumps for LBW decisions.
This is extrapolation: using an established trend to estimate what comes next.
Is It Just a Straight-Line Extrapolation?
Not normally.
A cricket ball's trajectory is not one straight line from bowler to wicket.
Before pitching, gravity, aerodynamic forces and the ball's initial velocity shape its flight.
At the bounce, the trajectory can change abruptly.
After pitching, the ball may continue with:
- sideways movement,
- upward or downward motion,
- a changing relationship between horizontal and vertical velocity.
The important post-bounce prediction is based on the measured segment after the ball has pitched, where that information is available.
The system is effectively asking:
Given the motion we have just measured after this bounce, where does this continuing trajectory intersect the plane of the wicket?
The exact internal algorithms used by commercial providers are proprietary and can evolve, so it is misleading to describe DRS as relying on one simple public formula.
But the core logic is clear:
observe → reconstruct → fit → extrapolate.
Why Does the Television Graphic Look So Smooth?
The cameras generate discrete observations.
A television graphic shows a continuous line.
That smooth curve is a visual representation of the fitted trajectory.
Think of plotting several points on graph paper.
The real measurements might be:
● ● ● ● ●
A mathematical model estimates the smooth path that best represents those points:
──── curved trajectory ────
The graphic can then be rendered from a convenient virtual camera angle.
That is why viewers can see the delivery from:
- side-on,
- front-on,
- directly above,
- a 3D perspective.
The displayed replay is not simply footage from one stadium camera.
It is a computer visualization constructed from tracked spatial data.
Why Do We Need Ball Tracking for LBW?
An LBW decision contains several separate questions.
Under current ICC DRS procedures, approved ball tracking provides three key pieces of information.
1. PITCHING
Where did the ball bounce?
The technology classifies whether the centre of the ball pitched:
- in line,
- outside off stump,
- outside leg stump.
A delivery pitching outside leg cannot result in LBW.
2. IMPACT
Where did the ball first strike the batter?
This is compared with the defined Impact Zone.
Whether impact needs to be in line also depends on whether the batter made a genuine attempt to play the ball.
3. WICKET
Would the projected ball have hit the wicket?
This is the part most people think of when they say “ball tracking.”
The software extends the measured trajectory to the plane of the stumps and checks where the ball would pass relative to the ICC's defined Wicket Zone.
A correct LBW review therefore involves more than asking whether the coloured line touches a stump.
What Does “Umpire's Call” Actually Mean?
Ball tracking produces a spatial result.
Cricket's rules then determine how that result is used.
Under the ICC's current World Test Championship 2025–2027 playing conditions, Umpire's Call applies to marginal ball-tracking outcomes involving the Impact Zone or Wicket Zone.
For the wicket decision, the categories are:
Hitting — the projected ball is hitting the wicket and the centre of the ball lies inside the Wicket Zone.
Umpire's Call — the projected ball is hitting the wicket, but the centre of the ball is not inside the Wicket Zone.
Missing — the projected ball misses the wicket.
So Umpire's Call is not the computer saying:
“I have no idea.”
Nor is the graphic a probability meter saying there is a particular percentage chance that the ball hits the stump.
It is a rule-defined category for a marginal result in which the on-field umpire's original decision is retained.
The review is also not counted as unsuccessful when the decision remains unchanged solely because of Umpire's Call.
Why Not Let the Computer Decide Every Marginal Case?
Every measurement system has finite precision.
The ball occupies only a certain number of pixels in each camera frame.
Camera calibration has finite precision.
Image timing has finite resolution.
The ball can be partly obscured.
The mathematical trajectory is fitted to measured data rather than obtained from an infinitely precise description of reality.
The ICC therefore uses a rules framework that preserves the on-field decision in defined marginal cases.
That should not be confused with saying that the technology is useless near the boundary.
It means cricket has deliberately chosen a threshold for when the evidence is strong enough to overturn the original decision.
Does Ball Tracking “Know” How Much the Ball Would Have Spun?
Not in the way a commentator might.
The system does not need to reason:
This bowler normally turns the ball five degrees, so I will add five degrees.
It measures the ball's actual post-bounce trajectory before impact.
If the delivery turned sharply, those observed positions reflect that turn.
If it skidded on, the measured path reflects that too.
The projection is therefore based on the delivery that actually occurred, not merely on the bowler's historical average.
However, the farther the system must extrapolate beyond the final measured point, the more important the established trajectory becomes.
This is one reason current ICC playing conditions include special provisions for unusually long projection distances.
What Happens If the Ball Hits the Batter Without Pitching?
This produces an interesting edge case.
Suppose a full toss hits the pad.
In many cases, ball tracking can extend the measured flight directly toward the wicket.
But the ICC also considers the unusual situation in which the technology indicates that the ball would have pitched before reaching the wicket even though the batter intercepted it first.
The current World Test Championship playing conditions state that there is no information from that delivery that would allow the technology to accurately predict the ball's height after that hypothetical future bounce.
That makes sense.
The bounce never happened.
The system cannot observe how the ball would have reacted to a patch of pitch it never touched.
In that situation, the ICC instructs ball tracking to project the pre-interception line according to the relevant LBW law rather than inventing a hypothetical post-bounce height.
This is an excellent example of the boundary between:
what technology can measure
and
what cricket's rules must define.
Why Are Multiple Cameras So Important?
A batsman or bowler can briefly block one camera.
The ball can cross a visually complicated background.
A single viewpoint can make depth difficult to estimate.
Multiple cameras provide:
- different viewing angles,
- redundancy,
- stronger 3D positioning,
- more observations across the ball's flight.
The original ball-tracking patent proposed at least four cameras partly so that tracking could continue when one view was obscured.
Current professional systems use sophisticated multi-camera setups and substantial computation because a cricket ball can travel quickly across a large field while occupying only a tiny part of each image.
This is much harder than drawing the television graphic makes it look.
Is the Prediction the Same as a Weather Forecast?
Not really.
A weather forecast predicts a complicated future system that has not yet happened.
Cricket ball tracking has a much narrower task.
Most of the relevant event has already happened.
The technology has measured the ball:
- leaving the bowler,
- travelling through the air,
- often pitching,
- travelling after the bounce,
- reaching the batter.
It usually needs to project only the short remaining part between impact and the wicket.
A better analogy is extending a line or curve whose recent direction has already been carefully measured.
There is still uncertainty.
But it is a constrained physical extrapolation, not a free-form prediction.
What the Television Replay Is Really Showing You
The familiar DRS graphic can be mentally divided into two sections.
Before impact: reconstruction
This is based on where the cameras observed the ball.
After impact: projection
This is the mathematical continuation of the measured trajectory to the wicket.
The computer then compares that projection with the geometric definitions used by cricket's laws and playing conditions.
Conceptually:
Cameras record the ball
↓
Software identifies it in each frame
↓
Multiple views reconstruct 3D positions
↓
A trajectory is fitted through those measured positions
↓
Pitching and impact are located
↓
The path is projected beyond the pad
↓
The projected ball is compared with the wicket
↓
DRS reports Hitting, Umpire's Call or Missing
That is how a ball that physically stopped at a batter's leg can appear to continue into the stumps on television.
There is no camera seeing through the pad.
There is no hidden sensor inside the cricket ball.
And there is no computer simply deciding what “looks right.”
The system takes several real observations of a fast-moving ball, reconstructs its path in three-dimensional space and uses that measured motion to answer a narrowly defined question:
If the pad had not been there, where would this delivery have gone next?
