Custom Computer Vision UK: What a Build Really Involves

Custom computer vision UK projects, whether for automated inspection, defect detection or measurement from images, succeed or fail on the images and the labels rather than on the model. The algorithms are largely a solved and commoditised problem. What is not solved is whether your camera sees the defect, whether anyone has recorded which images contain it, and whether the lighting on your line stays consistent enough for any of it to hold. Those questions are answerable in weeks, and they should be answered before a build is commissioned.

What these systems actually do well

Four patterns cover most industrial and scientific work. Detection: is a defect, object or feature present, and where. Classification: which of a known set of conditions is this. Measurement: dimensions, counts, areas and positions derived from images, often more repeatably than a person. And change detection: comparing an asset now against the same asset previously, which is the basis of much inspection work.

All four are mature. A capable team can stand up a working prototype on good data quickly, which is exactly why the interesting risk sits elsewhere.

Where projects actually fail

The image data, in three specific ways. First, the defect may not be visible in the images you have: a hairline crack at the resolution and angle your existing camera provides may simply not be there to find, and no model recovers information the sensor never captured. Second, labels are usually missing. Supervised vision needs examples marked up by someone who knows what they are looking at, and most operations have thousands of images and almost no annotations, so labelling becomes a real line in the budget rather than an afterthought. Third, conditions drift. A model trained under summer daylight through a factory window will behave differently in November, and a system that saw only one production variant will meet the second one in the field.

The good news is that all three are testable cheaply and up front. This is the same data-first discipline we apply across industrial work, described in starting industrial AI with the data you already have.

The feasibility test, before any build

Gather a few hundred representative images including the awkward cases, have a domain expert label them, and train a baseline. Two things come out. A measured accuracy figure on your own material, which is the only number worth planning against. And a clear statement of what the sensing setup cannot see, which frequently identifies a cheap fix such as a different angle, better lighting or a higher-resolution camera. It is common for a feasibility study to conclude that a modest hardware change matters more than any modelling choice, and that conclusion costs a fraction of a build.

Judge the result on the pair of numbers that matter operationally: how many genuine defects it catches, and how often it raises a false alarm. A system that catches everything while stopping the line hourly will be switched off within a fortnight.

What a production build involves

Beyond the model: image capture and storage at line rates, handling the cases the system is unsure about, an interface where an inspector confirms or corrects a call, feeding those corrections back so the system improves, and monitoring for the day accuracy quietly drops because something upstream changed. In regulated settings, add the audit trail showing what was decided and on what evidence.

Our high-voltage circuit breaker work is a fair illustration of the general principle in a related domain: the value came from understanding which signal carried the diagnostic information, not from a larger model. Where the outcome is a capability inside your existing operation rather than a standalone tool, that is our AI Service Build work, and the broader context sits on our industrial operations page.