Machine vision · industry and research

Machine vision on the images you actually have

A vision model usually looks good in the demo because the images it learned from were clean and consistent. A camera on the line or a satellite overhead sees something else, and the same model starts making mistakes on day one. I work on the images you really have and take the system to the point where your team uses it every day.

Send a technical brief →

The problem

Where a model falls over after the demo

Most vision projects get stuck in the same three places. All three can be seen before the work starts, and all three cost far more if nobody accounts for them until the end.

Real images do not look like training images

Training images are usually taken in the right light from the right angle. On the floor the light changes between morning and evening, the lens slowly collects dust, and the part you need to inspect passes the camera slightly crooked. Nobody sees these differences in a demo, and they are what pulls accuracy down from the first day.

A model does not learn only the part. The background colour, the shadow of a worker's hand and even the position of the camera become cues. If every image came from one line in one week, the model has learned that week and that line, and what it knows stops being useful when the light changes or the camera mount moves.

So before anything else I ask for images from different shifts and from the worst days of your operation. If a model holds up on those, its results can be relied on.

An inspection camera over a conveyor, drawn three times — **Figure 1** The same camera and part in morning light, evening light and through a dusty lens

The labelling budget is usually a guess

Labelling is expensive because someone who knows the work has to look at every image, and that person has a job of their own. Until a model has been tried on part of your data, nobody knows how many examples are really needed.

Two people also rarely see a defect the same way. One passes a fine scratch and the other rejects it. If that line is not drawn before labelling starts, the model learns from data that contradicts itself, and a better architecture cannot make up for it.

The model has to run somewhere

What worked on a powerful GPU server may not fit on the computer beside the line, or next to software the plant has run for years. Speed is part of the same sum: a model that answers late is no use to the line, however accurate it is.

After handover, if nobody on your team knows where and why the model goes wrong, the system gets abandoned the first time a camera is replaced.

How I work

Where the work starts and where it ends

The work starts with your own images, and it is finished when your team can keep the system running without me.

First we find out which mistake is expensive

I take a sample of your real images and sit down with someone who knows the work. A defect the model misses and a good part it wrongly rejects do not cost the same, and a single accuracy figure should not hide that.

On a safety-related part, a defect that gets through can end in a recall, and rejecting a few good parts is an acceptable price. On a thin-margin product the sum runs the other way, and every good part thrown away comes straight out of the profit. I set the model's decision threshold on that basis.

The output of this stage is a written criterion we agree on before any model is built, and the pilot is measured against it.

A balance scale with a cracked part on one pan and a sound part on the other — **Figure 2** A missed defect and a wrongly rejected part do not cost the same

I start with the simplest model

I begin with proven detection and segmentation models, and build a custom architecture only when the data shows the standard one has hit its ceiling. The target hardware is part of that choice from the start.

Then I go through the errors one by one. Most of the time the cause is lighting, labels or too few examples of one kind of defect, and fixing the data is faster and cheaper than a bigger model.

The output goes into daily work

Results go into the software, database or dashboard your team already uses, so nobody has to open a new screen to see them.

At handover your team gets the accuracy on real data, the common failure cases and the way to retrain, in writing. We also keep the images the model is unsure about, because those are the best data for the next round of training.

Selected work

Some of the work behind this page

These are projects and filings I worked on myself, with their details on the public record.

WIPO PCT · WO 2020/217082

From photographs to an editable 3D file

This filing describes a system that builds a 3D file from photographs. SSD finds the object, a capture rig photographs it under four lights from three directions, the surface is reconstructed from normal vectors and DCGAN generates the textures.

Photographing under several lights gives information a single image does not have, because shadows and highlights show which way the surface faces at each point. The resulting file can be opened and edited in 3D software.

Under 30 secondsfrom photograph to file
15 claimsin the filing
2 Chinese filingscite it

An object in a capture rig, next to its 3D mesh — **Figure 3** Concept illustration: photographing an object under several lights and building its 3D file

IEEE GRSL · 2025

Separating flooded areas in radar images

SAR radar sees through cloud and darkness, but it records surface reflection instead of colour and is full of speckle noise, so a model built for ordinary photographs does poorly on it. Enhanced-HisSegNet separates flooded areas in these images using learnable histogram layers and an active contour model.

RaderonLab AirQ brings active fires from FIRMS, vegetation from Sentinel and air quality onto one map, from an analyst's desktop application to a mobile app for ordinary users.

A satellite above a river valley and a radar image of the same area — **Figure 4** Concept illustration: separating the flooded area in a radar image

Two more of my WIPO PCT filings are in this field: automatic 3D reconstruction of buildings and compounds through machine scanning and deep learning, and machine vision to reduce the risk of animals entering refineries.

Projects I have built

GAN 2D-to-3D

WIPO PCT WO 2020/217082.

Creating editable 3D models from real objects is slow and expensive. This turns ordinary photos into editable 3D files in under 30 seconds (patented).
Project details →
RaderonLab AirQ Platform

Satellite air-quality, vegetation and active-fire monitoring.

Air-quality, wildfire and vegetation data live in separate satellite feeds, each with its own format and tooling. This platform pulls FIRMS, Sentinel and AirQ into one analyst desktop and a consumer-grade mobile app.
Project details →
Satellite Imagery Viewer

Sentinel Hub imagery in a desktop viewer.

Analysts needed fast desktop access to Sentinel imagery without juggling browser tools and APIs. This puts Copernicus layers in a single native viewer.
Project details →

Questions I hear often

How much data do you need?

It depends on the problem. A few hundred labelled images are usually enough to tell whether the approach will work, and the pilot measures exactly that on your own data.

Can the model run on our own hardware?

Yes, if it has to. I choose the model from the start for where it will run, whether that is an on-premise server, a computer beside the line or a cloud service.

Does our data leave the company?

It does not have to. I can work on your infrastructure, and we sign an NDA before I see any data.

How does an engagement start?

You send a short technical brief and I reply in writing on whether I can help. If I can, we start with a pilot from $600.

Have a vision problem?

We start with a pilot from $600 on part of your own images. Write a few lines about the images you have and the result you need, and I will give you the scope and the final price in writing.