Computer vision · July 2026 edition

Reading the ice

A stone detector can tell you where to look. A useful curling product has to explain what you are looking at.

The scene is the product

Curling is a good reminder that recognising objects and understanding a situation are different jobs. A broadcast frame can contain stones on the active sheet, stones waiting at the back, players, brooms, score graphics and a neighbouring game. A detector that confidently finds every circular object has not necessarily made the scene easier to understand. It may simply have created a more colourful version of the original confusion.

The useful questions are spatial. Which stones belong to this end? Which is closest to the button? Is a stone sitting behind a guard? Has a draw become buried? Answering them requires a common representation of the playing area, the visible objects and the uncertainty around them. That representation is the foundation of the product, rather than an optional layer added after model training.

My work brought together a Rust scene engine, a trained clean-view classifier and a visual explanation layer. The engine handles deterministic geometry and scene rules; learned components help interpret the image. Keeping those responsibilities separate makes the output easier to test. If a house outline is misplaced, I want to inspect the calibration. If a player is mistaken for part of a stone, I want to inspect the visual evidence.

This is also a product-design choice. The reader should be able to move from a compelling demonstration to the representation underneath it. A graphic is more useful when someone can ask why a stone was included, where a distance came from and what the system cannot see. That is the standard I used to connect the technical work to the public demo.

Give the pixels a playing field

The house provides a strong geometric reference. Its concentric rings, centre and known proportions constrain the projection from the broadcast image into a useful local coordinate system. In a camera view those circles become ellipses, and distances in pixels change across the picture. Measuring directly from the screen would make the same physical gap mean different things in different parts of the image.

The scene engine therefore combines the projected house with active-sheet bounds and a physical scale. Stone locations become positions relative to the playing area, rather than unrelated boxes. It also keeps track of things that should not count as stones in play: graphics, people, brooms and objects outside the active region. Those exclusions matter as much as the positive detections when the intended output is a coherent state.

Occlusion is especially important. A player crossing the house does not make a stone cease to exist, but a single frame may no longer support a precise location. The clean-view classifier gives the pipeline a way to distinguish a useful observation from a compromised one. The wider design can then treat an obscured view differently instead of forcing every frame to provide an equally confident answer.

I kept the geometry inspectable in the overlay. Ring projections and stone centres are visible because a convincing tactical sentence can conceal a bad spatial assumption. When the overlay is wrong, the failure should be apparent before it reaches an editor or an end user. That turns a demonstration into a practical debugging surface as well as a communication tool.

Schematic showing a broadcast frame passing through view qualification, house geometry, stone state and a tactical explanation.
A schematic of the scene pipeline. Geometry, perception and explanation have separate responsibilities and can be inspected independently.

From a position to a story

The 62-second sequence below follows three shots through a tactical presentation: a hit-and-roll, a draw that becomes buried and a freeze whose result changes the cover around the stones. The point is to show how spatial state can support an explanation of play. A reader should see the connection between the broadcast frame, the marked positions and the resulting description without needing to understand the model implementation.

Recorded tactical demonstration, approximately 62 seconds. Overlays identify the shot, projected house and selected stones. The displayed win-probability graphic is a demo model output; the perception audit below does not validate its forecasting accuracy.

Watch and share the curling demo on its dedicated video page.

There is an important distinction between the intended shot and the observed result. An audible call may describe a plan; the final geometry describes what happened. A useful editorial system can retain both without quietly treating intention as outcome. The same distinction appears in other sports, where commentary, a scoreboard and the visible action may update at different times.

The demo also shows why an interface needs careful boundaries. Distance labels depend on the scene calibration. Tactical descriptions depend on the positions and their interpretation. A forecast graphic is another model again. They may appear together on screen, but validating the perception layer does not automatically validate a downstream probability. I want each part to carry the evidence appropriate to its own job.

For a public portfolio, a short recorded sequence is valuable because it preserves a specific, reviewable example. This silent web edition includes visual captions. It is not a connection to an operational service, and it cannot change underneath the article. Viewers can replay the same moment, challenge the explanation and compare it with the described limitations.

Agreement is useful. It is not ground truth.

The retained automated-reference audit covers 218 frames drawn from 23 games. It compares the scene output with a separately constructed silver reference: an automated cross-model annotation process, rather than independently adjudicated human labels. That makes it useful for finding disagreements and measuring consistency, while leaving open the possibility that both systems share an error.

Across those frames, the reference contains 1,073 stones and the pipeline predicts 1,076. All 1,073 reference stones are matched, with three additional pipeline detections and no unmatched reference stones. The resulting location F1 is 99.86%. Exact frame-state agreement is 215 out of 218 frames, or 98.62%. Those figures describe this audit population and its matching rule, not a universal accuracy rate for curling broadcasts.

Automated-reference audit: 215 of 218 frames have exact state agreement, with three frames containing additional pipeline detections.
Exact state agreement against the automated silver reference. The chart starts at zero and retains the three disagreements; it is not a human-ground-truth benchmark.
Retained silver-reference audit
MeasureObserved value
Frames / games218 / 23
Reference stones / predictions1,073 / 1,076
Matched / extra / missed1,073 / 3 / 0
Exact frame states215 / 218
Location matching tolerance0.08 house radii, about 14.63 cm

The tolerance belongs beside the result because matching rules define what success means. A stone can be matched within that tolerance without its centre being precise enough for every possible tactical application. Likewise, correct colour on matched stones does not establish complete scene understanding. Keeping the counts, tolerance and reference type visible makes the headline statistic easier to interpret and harder to overextend.

Make the hard parts visible

The most useful product work happened at the boundaries. I needed a representation the scene engine could validate, an overlay a human could challenge and evaluation receipts that did not hide disagreement. Those requirements shaped the architecture more effectively than a request to produce a high score on its own.

A deterministic engine is helpful here because its behaviour can be explained directly. Bounds, coordinate transformations and state checks can have ordinary regression tests. Learned perception still matters, but it sits inside a system where errors can be located. That makes iteration more directed: improve the classifier when view qualification is weak, inspect calibration when the house drifts, and review references when the apparent error is in the annotation.

The leadership lesson is about sequencing. Start by deciding what a useful output must let someone do. Then define the representation, the checks and the evidence needed to support that use. Model selection becomes part of a delivery plan with explicit interfaces, rather than an open-ended competition for a prettier overlay.

This approach also keeps the public story concrete. The contribution is not merely that computer vision was applied to another sport. It is the combination of a physical model, a perception pipeline and a reviewable experience, with each layer contributing something identifiable to the result.

The next useful test

The next step is independent human review of the disputed scenes and a broader evaluation across difficult camera views. It should include more occlusion, clutter, unusual framing and transitions, with the development data kept separate from the final assessment. The three remaining automated-reference disagreements are a good starting point for investigation, not a reason to assume the rest of the output is beyond question.

Temporal evaluation is another distinct task. A strong static scene should support tracking through a shot, but continuity through camera cuts and temporary obstruction needs its own evidence. The future product should show when a state was observed, when it was carried forward and when the view no longer supports an assertion.

For now, the result is a working visual explanation of curling scenes and a measured automated-reference audit. Together they make the project inspectable: a viewer can watch the idea, understand its structure and see the remaining work. That is a stronger foundation for a sports product than a confident graphic with no way to ask what sits underneath it.

Evidence: retained July tactical demo and silver-reference v6 audit, reviewed for this September publication. Public aggregates are available in the article evidence file. Model weights, image archives and operational endpoints are not published.