Computer vision project
How an industrial computer vision project works
From first contact to ongoing operation. This page describes the full path, what we need from you at each stage, and where projects usually stall.
No commitment. The diagnosis conversation takes about 30 minutes.
The stages of a project
The order matters: each stage exists so the next one isn't done blind.
-
Diagnosis
About 30 minutes to understand the line, what stays invisible today and which outcome justifies the project. We leave with a hypothesis of what must be detected, measured or recorded.
-
Image collection
We use images you already have or capture them on the floor. What matters here is variation across shifts, lighting, dirt and rare cases — not the ideal scenario.
-
Feasibility proof
A slice of the problem is tested against real data to answer one simple question: is the pattern distinguishable in the image? A negative result here saves the rest of the project.
-
Hardware definition
Only after feasibility do we choose cameras, lenses, lighting and where processing runs. Many plants reuse part of the existing infrastructure.
-
Model training
The model is trained on annotated data from your operation, with classes defined alongside people who know the process. Class ambiguity gets resolved here, not later.
-
Validation
Comparison against current inspection, under production conditions. We agree on what counts as an acceptable false positive and an unacceptable false negative — they carry different costs.
-
Integration
Events start feeding MES, ERP or SCADA over an API, or a dedicated dashboard when no system exists to receive them.
-
Operation
The system runs on the line, producing alerts, visual evidence and indicators. At this stage the goal is for the team to trust what the screen shows.
-
Maintenance
A new product, a new supplier or a lighting change alters what the camera sees. Models in production are monitored and readjusted when the scenario shifts.
What we need from you
The part of the work we cannot do on our own.
-
Access to the process
A visit, a video or enough photographs to understand the line in real operation.
-
A success criterion
What must be detected, and what happens today when it goes unnoticed.
-
Someone who knows the process
Defining classes and resolving ambiguity takes people who work with the product every day.
-
Room for variation
Images from different shifts, batches and conditions are worth more than many identical ones.
Where projects usually stall
The four most frequent reasons, and why the stages above are ordered the way they are.
-
The pattern isn't distinguishable
If the defect doesn't appear consistently in the capture, no model fixes it. That is what the feasibility proof tests first.
-
Criteria that shift midway
When the definition of a defect changes at every review, the dataset loses consistency and the model learns noise.
-
No rare cases
Defects that happen rarely tend to be the expensive ones. Without examples of them, there is nothing to learn.
-
Nowhere for the alert to go
A detected event nobody receives changes nothing on the line. Integration has to be decided early.
Frequently asked questions about the project
What usually comes up before the first conversation.
How long does a full project take?
It depends on complexity and image availability. The timeline is estimated in the proposal, after diagnosis and feasibility analysis — estimating before that would be guesswork.
Can we start small?
Yes. The usual path is a proof of concept at one point on the line, with narrow scope, before any hardware investment.
Do we need a data team?
No. We handle collection, annotation, training and validation. What we need from your side is knowledge of the process.
What if feasibility comes back negative?
We say so and explain why. A feasibility report costs far less than a project that doesn't deliver.
Talk to our team
Let's understand your challenge
Prefer to book the diagnosis conversation? Use the scheduling link. Or fill in the form — our technical team replies.