Computer vision · Custom models
A model built foryour images.
A custom computer vision model is a neural network trained on a particular company's images and categories, for a task that generic models do not handle well enough. We take care of the whole journey: defining the task, collecting and labelling the data, training and evaluation, optimising for the hardware it will run on, deployment and retraining when conditions change.
Events
- —Batch 3 labelled · team-approved
- —1 uncertain label sent back
- —Training · iteration 18 of 50
- —Export ONNX → TensorRT for edge
It is a long way from a successful demo to a model that works in production
A model that looks good on a few test images can behave quite differently on the camera in the plant, at night or after the packaging supplier changes. And without consistently labelled data, a separate test set and a retraining plan, nobody really knows how well it works.
- Generic models do not know the objects, defects or categories specific to your business
- The data exists, but it is unlabelled, disorganised or not representative of real conditions
- A prototype runs on a laptop with a GPU but is too slow or too large for the equipment in the field
- After launch, nobody tracks whether accuracy drops when the lighting, camera or products change
Who it is for
- Companies with a specific visual task, for example a defect, a part or a condition, that off-the-shelf models do not recognise
- IT or product teams building their own application that need a vision component delivered as a model or an API
- Businesses that already have a prototype or an older model and want to take it into production, optimise it or retrain it
- Organisations that want the model to run locally, on an edge device or on their own servers, without depending on an external service
Step by step
How a custom model comes to life, step by step
The five steps on the animation follow a model from the first images to the approved version: the raw images, labelling, training on your classes, the rule that decides whether the model is ready and the team that approves it.
Events
Events
- —Batch 3 labelled · team-approved
Events
- —Batch 3 labelled · team-approved
- —1 uncertain label sent back
Events
- —Batch 3 labelled · team-approved
- —1 uncertain label sent back
- —Training · iteration 18 of 50
- —Export ONNX → TensorRT for edge
Events
- —Batch 3 labelled · team-approved
- —1 uncertain label sent back
- —Training · iteration 18 of 50
- —Export ONNX → TensorRT for edge
Step 1 of 5
The real images
We start from images or video from the place where the model will work, with the camera, lighting and angle found there. We extract frames at intervals so we do not collect hundreds of near-identical images, and we deliberately look for the rare cases: night, backlighting, unusual products. A small but varied set helps more than a large, repetitive one.
Technical options and when each fits
Fine-tuning an existing model
A pre-trained model is fine-tuned on your images. It is the usual starting point because it needs less data and less time; it fits when your objects resemble what general models already know.
Classification, detection or segmentation
Classification gives a single category for an image or a crop and is enough when the object is already centred, for example on a belt. Detection finds and counts several objects in the frame, while segmentation traces the exact outline, which is needed when shape or surface area matters.
Running on the edge or on a server
On an edge device, the model is made smaller and optimised, and the images never leave the site. On a local server or in the cloud, larger models can be used and several cameras or applications can be served through the same API.
What you receive at hand-over
- The trained model, exported for your hardware and delivered as an API, a container or an edge component
- The versioned dataset, with the labels, the labelling guide and the test set kept separate
- An evaluation report on your images, by class and condition, including the speed measured on the target hardware
- The process for collecting uncertain or wrong cases from production, ready for retraining
- Model documentation: data used, known limitations, component licences and the retraining steps
- Typically, a hand-over session with the team that integrates and maintains the model
No strings attached: tell us what the cameras should see and we'll tell you honestly whether it can be done.
Let's talkWhat developing a custom model covers
- 01
Defining the task and classes
We decide whether classification, detection, segmentation or text reading is needed and which categories matter, with clear rules for telling them apart.
- 02
Collecting and organising data
We gather representative images from real working conditions, including rare and difficult cases, and organise them in versions.
- 03
Labelling and quality control
We label together with the people who know the domain, with a labelling guide and cross-checks on samples.
- 04
Training and evaluation
We adapt a suitable architecture and test it on a separate set the model has not seen, with results presented by class and condition.
- 05
Optimisation for the hardware
We export the model to formats such as ONNX or TensorRT and make it smaller, for example through quantisation, so it runs on the chosen hardware.
- 06
Deployment and retraining
We deliver the model as an API, a container or an edge component and set up the process by which mistaken cases become new training data.
How it works
The life cycle of a custom model
The steps marked in yellow are approved by a person.
- Input
- Human in the loop
- AI
- Action
- Result
- 01
Input
Real images
Images or video from your site, captured in normal working conditions.
- 02
Human in the loop
Labelling and validation
People who know the domain mark the examples and check the labels.
- 03
AI
Model training
The model learns from the labelled data, starting from an architecture suited to the task.
- 04
Action
Evaluation and optimisation
We test on unseen data, then export and optimise for the target hardware.
- 05
Action
Deployment and monitoring
The model runs in your application, and uncertain cases are collected for analysis.
- 06
Result
Model in production
A documented, measured model ready for retraining.
What a custom model needs
- Real images or video footage from your site, with the usual variation in lighting, angle and products
- Time from people who know the domain, to define the classes and validate the labels
- Examples of rare or difficult cases, which matter most and occur least often
- Information about the hardware the model will run on: edge device, local server or cloud, and the speed requirements
- Clear rules on the right to use the images, access to them and how long they are kept
- GPU training resources, provided by us or within your infrastructure
Possible integrations
- PyTorch
- ONNX and ONNX Runtime
- NVIDIA TensorRT
- Intel OpenVINO
- NVIDIA Jetson edge devices
- CVAT or Label Studio for labelling
- MLflow for experiment tracking
- Docker containers
- Cloud storage, for example Amazon S3 or Azure Blob Storage
- REST API
- PyTorch
- ONNX and ONNX Runtime
- NVIDIA TensorRT
- Intel OpenVINO
- NVIDIA Jetson edge devices
- CVAT or Label Studio for labelling
- MLflow for experiment tracking
- Docker containers
- Cloud storage, for example Amazon S3 or Azure Blob Storage
- REST API
Each integration's compatibility is checked during the analysis phase, for the systems and versions you use.
Control and transparency
What stays with people
- Defining the classes and the criteria for an example belonging to one or another
- Validating the labels in the training and test sets, because labelling errors carry over into the model
- Deciding whether the results on the test set are good enough for production use
- Approving each new version of the model before it replaces the one in use
Limits and operating conditions
- A model is only as good as the data it learns from; little, unrepresentative or inconsistently labelled data leads to poor results
- The model only recognises what it saw in training; new products, cameras or conditions may need new data and retraining
- Optimising for less powerful hardware can reduce accuracy; the trade-off between speed and accuracy is measured and discussed openly
- Some architectures and pre-trained models have licences that restrict commercial use; we check them before choosing
How we evaluate a custom model
We agree the indicators together before launch and track them afterwards. The values depend on the process, the data and the volume.
- Precision and recall by class
- Measured on a separate, independently labelled test set, at the confidence threshold used in production
- mAP or IoU, depending on the task
- The standard metrics for detection and segmentation, reported for each class, not just as an average
- Speed on the target hardware
- Processing time per image and frames per second, measured on the real hardware after optimisation
- Stability over time
- Production samples checked regularly by the team, to notice quality dropping when conditions change
How we develop a custom model, in 4 steps
- 01
We analyse the task and the data
We clarify what needs to be recognised, what data exists and whether an existing model is enough, before proposing a new one.
- 02
We build the dataset
We collect and label representative images, with a labelling guide and a test set kept separate.
- 03
We train, test and optimise
We compare model variants, discuss openly where they make mistakes and optimise the chosen one for the target hardware.
- 04
We deploy and maintain
We integrate the model into your application, monitor quality over time and retrain with new data when needed.
Use cases
The scenarios below are conceptual examples, designed to illustrate realistic applications. They are not implementations delivered by WEB-AZ.
- Agriculture
Sorting fruit by quality
A model trained on images from the packing line tells good fruit apart from bruised or blemished fruit, and uncertain cases are taken out for a manual check.
Conceptual example - Manufacturing
A prototype moved to an edge device
A model developed in-house only runs on a server with a GPU. We export it, optimise it for an edge device next to the line and measure how much the accuracy changes.
Conceptual example - Recycling
Recognising material types on the belt
On the sorting belt, the model tells apart PET, cardboard and metal, and the operator sees on a screen what the system has classified and corrects mistakes, which become new training data.
Conceptual example
Useful guides
Before you decide, read
Frequently asked questions
What is a custom computer vision model?
It is an artificial intelligence model trained on a particular company's images and categories, for a specific visual task such as recognising a defect, a part or a type of material. Unlike generic models, it learns exactly what matters in your process and is tested on images from your real conditions.
When is a custom model worth it instead of an off-the-shelf one?
When your objects, defects or categories do not exist in generic models or are confused with one another. We first check whether an existing model, perhaps lightly fine-tuned, is enough, because that saves time and cost. We propose a new model only when tests show it is needed.
How many images are needed?
There is no fixed number. It depends on how many classes there are, how similar they are to each other and how varied the real conditions are. We start with a small set, measure the results and expand collection where the model makes mistakes.
What hardware can the model run on?
On an edge device such as NVIDIA Jetson, on a local server with or without a GPU, or in the cloud, depending on volume, the speed needed and data requirements. We optimise the model for the chosen hardware and measure the speed directly on it.
Who owns the model and the data?
Ownership of the trained model, the data and the labels is set out in the contract before the project starts. We also discuss openly the licences of the components used, because some pre-trained models have restrictions on commercial use.
What happens after delivery?
Conditions change over time: lighting, cameras, products. We monitor quality on production samples, collect the cases where the model makes mistakes and retrain when the data shows it is needed, with each new version approved before it replaces the old one.
Can’t find the answer? Write to us and we’ll reply directly.
Do you have a visual task no model handles well?
Send us a few real images and describe what the model should recognise. We will tell you whether the task suits computer vision, what data would be needed and whether an existing model could be a starting point.
Related solutions
- Object detectionModels that recognise the objects that matter to your process in images and pass them on as structured data.
- Industrial visual inspectionCameras on the production line flag parts with visible defects, and the operator confirms every rejection.
- Edge AI for computer visionVideo analysis on devices installed on site: fast response, less network load and images that never leave the building.