AI Development · Computer Vision
We turn video into verifiable events under the rules of your process. We read your regulations, map the edge cases and build the system: detection, classification, segmentation and tracking, scene geometry, a state machine and an event model. It runs on your hardware; the decision stays with your expert.
Discuss your use caseAn applied computer vision system is a chain: cameras and data, object detection and classification, tracking, mapping to site coordinates, a state machine for every object and an event model on top of the rules. Quality is decided not by detector scores but by how the system behaves in edge cases. That is why we start with your regulations and process, not with a model.
We start with the customer's documents, not with a model: regulations, procedures, rulebooks and how the process actually runs. We formalise what counts as an event or a violation, at which moment, and with which exceptions.
From the rules, disputed incidents of past periods and expert experience we collect the situations where a rule fires in a non-obvious way. The result is a coverage matrix: what the system decides on its own, what it flags with a caveat, what it leaves to a human.
Resolution, frame rate, exposure, viewing angles, clock synchronisation across sources, real pipeline latency. For each event we pick the sources that can actually see it — sometimes adding a camera or a sensor is more honest than training a model to guess.
We fine-tune detectors to your classes and add a role classifier, refine boundaries with segmentation or keypoints, and keep object identity across frames and cameras.
For fixed cameras we compute a homography and map object positions onto a metric 2D plan of the site. Objects above the ground plane get other viewpoints, sensor data or an honest uncertainty interval.
Every object — and the process as a whole — moves through phases, and the allowed number of objects and order of actions depend on the current state. An unknown state stays unknown; it is never silently replaced by the most likely one.
An event is derived from states and rules, not from a single frame. For each event the system assembles a card: the moment, a key frame, synchronised replays of the relevant views, and a confidence level — or an explicit “insufficient data”.
People, vehicles, parts, defects. A role classifier on top of the detector when the question is not “is it a person” but “who are they in this process”.
Precise contours and regions: object boundaries, contact points, defect area, cells in a microscope image.
Object trajectories, counts in zones and at gates, enforcing an allowed number of objects while they rotate in and out.
Line and zone crossings, order of actions, limit breaches — through a state machine and an event model.
Telemetry, embedded sensors, tags — used as the primary signal where the camera is unreliable, and as labels for training.
Counting and classifying objects in images: microscopy, quality inspection, inventory.
A model that performs well on typical frames fails where the event is rare, fast, partly occluded, or where the rule allows an exception. This is how we deal with it.
A held-out test set that never enters training. Acceptance metrics are agreed with you per event class: share of events found, false alarms per hour, misses, share of “insufficient data” results, notification latency and replay preparation time. Every figure comes with its capture conditions.
Where an error is costly, the system finds the incident, shows replays from the right cameras and proposes a conclusion. The decision stays with your expert, and their review flows back into the labels.
Inference runs on your hardware: a GPU server on site or an edge device next to the cameras. Video does not go to the cloud. Models are optimised for the hardware; for CPU-only scenarios we choose the architecture up front.
No customer or project names — only the class of problem and the approach.
A system that assists experts who review disputed incidents on video. The customer's rulebook is formalised into a state machine and an event model; for every incident found, the system prepares a card with synchronised replays and a confidence level. Processing on site, connection to signal copies, sensor data as an extra source. Stage: pilot development — a prototype on historical recordings, acceptance criteria being agreed with the customer.
Our own health-tech project: detection and classification of blood cells in video of a blood drop captured by a device of our own design. About 95% agreement with manual counting on a validation set of 121 frames, roughly 30,000 cells, 45% of them checked by hand. Two working prototypes; no production device yet.
Our lead computer vision engineer has 10+ years in the field: video analytics in healthcare and industry, action recognition, edge inference next to the cameras, image quality assessment.
We read your regulations and process, audit cameras, recordings and sensors, and agree an edge-case matrix and acceptance criteria. We tell you honestly what your cameras can and cannot see.
First a prototype on historical recordings, where every error can be reproduced and models compared. Then a run in arrival order of data and a live pilot. Acceptance against the criteria agreed after discovery.
Deployment on your hardware, quality monitoring, retraining on incidents reviewed by your experts. Each new model version is compared with the previous one on the same validation set.
Enterprise LLM systems, RAG and AI agents are covered on Enterprise AI development.
Computer vision is the field: models that find, classify and track objects in images and video. Machine vision usually means industrial inspection on a production line. Video analytics is the applied output on camera streams: events, counts, alerts. We build all three depending on the problem.
Not necessarily. We start by auditing your existing cameras and recordings: resolution, frame rate, viewing angles. If an event cannot be reliably seen from the current cameras, we say so before the pilot and recommend which camera to add and where.
It depends on the number of classes and how rare the events are. Your existing recordings are usually enough: we fine-tune proven detectors and label edge cases first. For rare events we use targeted candidate search and, where justified, synthetic data.
On a held-out test set that never enters training, per event class: share of events found, false alarms per hour, misses, share of “insufficient data” results, notification latency. Every figure is stated together with capture conditions — without them a percentage says nothing.
Yes. Inference runs on your hardware — a GPU server on site or an edge device next to the cameras. Video never leaves your perimeter.
Images of people can be personal data under the GDPR. We design processing to run on site, without biometric identification unless the task requires it, and keep only what is needed to review events.
No. Where an error is costly, the system finds the incident, shows the replay and proposes a conclusion; the decision stays with a qualified person, and their review flows back into training.
