Skip to content

Artificial Intelligence

Computer Vision

We build vision systems that read images and video — and we are honest that the hard part is the edge cases, the labelling and the day the model is wrong.

Overview

This is the delivery service for computer vision: teaching software to interpret images and video, and putting the result somewhere it does real work. That covers classifying an image, detecting and locating objects within it, segmenting a scene pixel by pixel, reading text off a document or a label with OCR, analysing faces or attributes, inspecting a part for defects, and pulling structure out of a video stream. The common thread is that the input is pixels and the output is a decision, a count, a measurement or a piece of extracted data that another system can act on.

The uncomfortable truth about this work is that a demo on clean images tells you almost nothing about how the system behaves in the real world. A model that scores well on a tidy test set will still meet lighting it has never seen, an angle the camera was not mounted for, an object half-hidden behind another, and the rare class that barely appeared in training. Those edge cases are where vision projects quietly fail, and handling them is most of the engineering. So is the labelled data underneath: good annotation is a real, recurring cost that people consistently underestimate, and no amount of model cleverness compensates for a training set that does not represent what the camera will actually see.

We build across the pipeline — data collection and annotation, model training or fine-tuning (usually starting from a pre-trained model rather than from scratch), evaluation, and deployment to the cloud or to the edge, on the camera or device itself, where latency and bandwidth rule out a round trip to a server. And we are blunt about two things from the outset: accuracy is never one hundred per cent, so any consequential decision needs a human fallback rather than blind trust; and if your images contain people, the privacy and regulatory constraints are serious and have to shape the design, not be bolted on before launch.

Who it’s for — Teams with a real visual task — inspecting parts, reading documents, counting or tracking objects, monitoring a space — who want it built by engineers who understand that the demo is the easy ten per cent and the edge cases are the other ninety.

What you get

  • A defined vision problem framed against real conditions — the classes, the acceptable error rate, and the decision the output feeds — before any model is trained
  • A data and annotation strategy: what to collect, how to label it consistently, and an honest estimate of the labelling cost and effort involved
  • A trained or fine-tuned model — classification, detection, segmentation, OCR or video analytics — built on an appropriate pre-trained backbone rather than reinvented from nothing
  • An evaluation harness that measures the model on the failure cases that matter, not just an aggregate accuracy figure that hides the edge cases
  • A deployment target chosen deliberately — cloud inference or on-device edge — with the latency, bandwidth and cost trade-offs made explicit
  • A human-in-the-loop fallback for any decision where being wrong is costly, so an uncertain prediction escalates instead of acting silently
  • A privacy and data-handling design where people are in frame — consent, retention, minimisation and the biometric-data sensitivities — plus monitoring and a handover so your team can operate the system

What Computer Vision does for you

  • Consistency a human cannot sustain

    A person inspecting parts or reading documents for eight hours is inconsistent by the afternoon, disagrees with the person on the next shift, and cannot be everywhere at once. A well-built vision model applies the same criteria to every frame at any hour, which is often the real win — not that it is smarter than a skilled human on any single image, but that it never gets tired, distracted or bored, and it scales to a volume no team could.

  • Value pulled out of images you already have

    Most organisations sit on far more visual data than they use — inspection photos, scanned documents, CCTV, product imagery, footage from cameras already installed. The information is there; extracting it by hand is the bottleneck. Vision turns that backlog from something you store into something you can count, search, measure and decide on, without adding the headcount that manual extraction would demand.

  • The hard trade-offs made on purpose

    The expensive mistakes in vision are made early: underestimating the annotation cost, deploying to the cloud when the use case needed the edge, trusting a model with a decision that should have had a human fallback, or ignoring the privacy exposure of putting people in frame. Getting these right before you build is worth far more than any model tweak afterwards, and it is where a senior-led engagement quietly saves you from a project that looks fine in the demo and fails on the floor.

Why teams choose us for Computer Vision

  • You have a genuine visual task and want it built by engineers who will tell you honestly whether it is tractable with the data you have, rather than promising a demo-grade result and leaving you to discover the edge cases in production.
  • You need the model to run somewhere specific — on a camera, a device, an edge box, or in the cloud — and you want that decision made on latency, bandwidth, cost and privacy, not on whichever deployment path was easiest to stand up.
  • Your images involve people, and you want the privacy, consent and biometric-data sensitivities designed in from the first decision — because getting this wrong is not a bug, it is a regulatory and reputational problem.
  • You understand that accuracy is never perfect and you want a system designed around that truth — with confidence thresholds, a human fallback on the decisions that matter, and honest measurement — rather than a black box sold as infallible.

What Computer Vision includes

The concrete pieces of work this covers — scoped to what your problem actually needs.

  • Image classification and attribute analysis

    Assigning an image, or a region of it, to one of a set of categories — is this part good or defective, which product is this, what condition is this asset in — and reading attributes off a subject. We fine-tune a pre-trained backbone on your classes, and we pay particular attention to the imbalanced case, where the class you most care about (the rare defect, the unusual event) is the one with the fewest training examples and the one a naive model quietly learns to ignore.

  • Object detection and tracking

    Finding and locating things within an image — drawing the box, saying what and where — and following them across frames in video. This underpins counting, presence detection, and spatial analysis: how many items on the shelf, is a person in a restricted zone, which pallet went where. Detection is harder than classification because the model must also localise, and it degrades fast on small, distant, overlapping or partially-hidden objects, which is exactly where the real-world footage differs from the demo set.

  • Semantic and instance segmentation

    Classifying an image pixel by pixel — every pixel labelled as road, part, background, or a specific instance of an object — when a bounding box is too coarse for the task. Segmentation is what you reach for when you need the precise shape or area of something: the exact extent of a defect, the boundary of a region, the outline of an item. It is more expensive to annotate than boxes, and we are honest about that cost up front because pixel-level labelling is where annotation budgets are most often blown.

  • OCR and document understanding

    Reading text off images — printed and, harder, handwritten — and going beyond raw characters to understand a document’s structure: which value belongs to which field, where the table is, what this form is. This is how you turn a scanned invoice, form or label into structured data another system can use. Modern OCR handles clean printed text well; the difficulty is poor scans, unusual layouts, handwriting and multi-language content, so we build validation and a human-review path for the cases the model is unsure about rather than trusting every extraction blindly.

  • Quality inspection and defect detection

    Spotting defects, damage or deviations on a production line or in inspection imagery — scratches, cracks, missing components, contamination, misalignment. The defining challenge is that defects are rare and varied: you often have thousands of images of good parts and only a handful of each fault, which turns this into an imbalanced-data and sometimes an anomaly-detection problem rather than a straightforward classifier. We design for that reality, and we design the human fallback so a borderline call goes to a person rather than a false accept slipping through.

  • Video analytics and edge deployment

    Analysing video streams in motion — counting, tracking, dwell time, movement patterns, event detection — and, where it matters, running that inference on the edge: on the camera, a device, or a small box beside it, rather than streaming every frame to the cloud. Edge deployment is what you need when latency has to be low, bandwidth is limited or costly, connectivity is unreliable, or privacy means the footage should never leave the site. It forces a real engineering trade: a model small and fast enough to run on constrained hardware, balanced against the accuracy you give up to get there.

Where it fits

  • Automated inspection on a manufacturing line

    Detecting defective parts, missing components or surface flaws as items pass a camera, flagging or diverting the suspect ones for a human to confirm. The engineering centres on the imbalanced-data problem — abundant good parts, scarce examples of each defect — on running fast enough to keep pace with the line, often on edge hardware, and on tuning the threshold so the system catches real faults without rejecting so many good parts that operators stop trusting it. The goal is consistent inspection at line speed, with a person in the loop on the borderline calls, not an unattended black box making final rejections alone.

  • Reading documents and forms at scale

    Turning a backlog of scanned invoices, forms, identity documents or delivery notes into structured data — OCR to read the text, document understanding to map values to the right fields, and validation to catch the extractions the model is unsure about. The hard cases are poor scans, handwriting, and layouts the model has not seen, so we build a confidence threshold and a human-review queue for the uncertain ones rather than pushing every reading straight through. Where identity documents or personal data are involved, the retention and consent design is part of the build, not an afterthought.

  • Retail and logistics counting and tracking

    Using cameras to count stock on shelves, detect out-of-stocks, track pallets and items through a warehouse, or analyse how people move through a space. Detection and tracking across frames do the work, and the real-world difficulty is the usual one: occlusion, crowding, lighting that shifts through the day, and small or distant objects. Where the footage involves customers or staff, we design for privacy from the start — often analysing and discarding rather than storing, and never treating people-in-frame as an ordinary data source.

  • Monitoring a space or process safely

    Watching a video feed for specific conditions — a person in a restricted or hazardous zone, personal protective equipment missing, an object left where it should not be, an event that needs a human alerted. This is an assistive system, not an autonomous one: it raises attention for a person to act on, because the cost of a false negative in a safety context is too high to hand to a model that is never one hundred per cent right. Edge deployment often matters here for latency and for keeping footage on-site, and the privacy and regulatory considerations of monitoring people are front and centre.

How we approach Computer Vision

We start from the decision the vision system feeds and the cost of getting it wrong, not from the model architecture. A system that flags a suspect part for a human to check can tolerate a very different error profile from one that automatically rejects it, and that distinction changes everything downstream — how much data you need, how hard you push accuracy, and whether a human sits in the loop. So the first work is framing the problem honestly against the real conditions the camera will face: the lighting, the angles, the occlusion, the rare cases, and the classes that genuinely matter versus the ones that are easy to score well on and irrelevant in practice.

From there we treat the labelled data as the foundation it is. We almost always fine-tune a pre-trained model rather than training from scratch, because a backbone that already understands edges, textures and shapes needs far less of your data to specialise on your task — but it still needs enough well-annotated examples of your actual conditions, including the failure cases, to be trustworthy. We build the evaluation set to probe those cases deliberately, so a change to the model is measured against the situations that break it rather than the easy ones it already handles.

How the engagement runs

We open with the problem and the data, not the model. The first questions are what decision the system feeds, what it costs to be wrong, and what the camera or source actually sees in practice — the lighting, the angles, the occlusion, the rare cases, the classes that genuinely matter. That framing fixes how hard we have to push accuracy, whether a human belongs in the loop, and how much and what kind of data we need. Then we look honestly at the data you have and the data you need, and we cost the annotation — because labelling is a real, recurring line item that people routinely underestimate, and pretending otherwise sets the project up to disappoint.

From there we build iteratively: fine-tune a pre-trained model on your task, evaluate it against a test set built to probe the failure cases rather than flatter the model, and improve deliberately — more data where the errors cluster, better annotation where the labels are inconsistent, a different threshold where the trade-off is wrong. You see the model measured on the cases that matter, not a single accuracy number. Once it is good enough for the decision it feeds, we deploy it to the chosen target — cloud or edge — wire in the human fallback and the monitoring, and hand over a system your team can understand and operate.

How we architect it

A vision system is a pipeline, and we design each stage deliberately: capture and preprocessing (the resize, normalisation and augmentation that make a model robust to lighting and orientation), the model itself (usually a fine-tuned pre-trained backbone), post-processing that turns raw predictions into a usable output, and the confidence handling that decides when to act, when to escalate to a human, and when to abstain. The stages are kept separate so each can be measured and improved on its own, rather than welded into one opaque step that either works or does not with no way to see why.

The central architectural decision is cloud versus edge, and it is a genuine trade with no free answer. Cloud inference gives you the largest, most accurate models, easy updates and elastic scale, at the cost of a network round trip, bandwidth for every frame, ongoing compute cost, and sending your images off-site. Edge inference — on the camera, the device, or a small box beside it — gives you low latency, works without reliable connectivity, keeps footage on-site for privacy, and avoids streaming costs, but it forces a smaller, faster model onto constrained hardware and you pay for that in accuracy. We make this call on your latency budget, your bandwidth, your privacy constraints and your cost model, and sometimes the answer is a hybrid: a light model on the edge that triggers a heavier one in the cloud only when it needs to.

Security and privacy

When a vision system looks at people, privacy is not a feature to add later — it is a constraint that shapes the whole design, and getting it wrong is a regulatory and reputational failure rather than a bug. Images of identifiable people are personal data under the UK GDPR, and facial or other biometric identifiers are a special category with a higher bar for lawful processing. That means the lawful basis and any consent have to be settled before the camera goes up, not after; it means data minimisation is a design principle — capturing only what the task needs, analysing and discarding rather than hoarding footage where the use case allows, and keeping retention short and justified; and it means the sensitivity of biometric processing is taken seriously rather than treated as ordinary analytics. We design these constraints in from the first decision, because a system that works technically but cannot lawfully be operated has failed.

Alongside privacy, we take the model’s own robustness seriously. Vision models can be fooled — small, deliberate perturbations to an image, or physical adversarial patterns in the real world, can push a model to a confident wrong answer — and the exposure is real for any system where being wrong has a cost or an incentive to game it. We treat model outputs as fallible rather than authoritative, which is exactly why a human fallback sits on the decisions that matter: a confidence threshold that escalates the uncertain and the anomalous instead of acting on it blindly. We handle the training data and the model as assets to protect, keep the data-handling auditable, and design the system so that no single wrong prediction, adversarial or merely unlucky, can quietly cause harm without a human in a position to catch it.

Signs it’s time

  • A manual visual task — inspecting parts, checking labels, reading forms, counting stock — is slow, inconsistent between people, or simply does not scale with your volume
  • You are drowning in images or video that contain useful information nobody has time to extract by hand, and the value is trapped in the pixels
  • A prototype or proof-of-concept looked convincing on sample images but falls apart on real footage from the actual site, camera or conditions
  • You need inference on a device or camera in real time — a production line, a vehicle, a remote location — where sending every frame to the cloud is too slow, too expensive, or impossible

Our working method

The organising principle is that real-world vision is hard for reasons that have little to do with the model, so we spend our effort where the difficulty actually lives: framing the problem against real conditions, getting representative labelled data including the failure cases, evaluating honestly, and designing for the fact that the model will sometimes be wrong. We almost always fine-tune a pre-trained model rather than training from scratch, because it needs far less of your data and gets there faster — but we are candid that fine-tuning still needs enough well-annotated examples of your actual conditions to be trustworthy, and that the annotation is a cost to plan for, not wish away.

We refuse to sell a demo as a finished system. A model that scores well on a clean test set has proven almost nothing about the site, the camera and the conditions it will meet, so our measurement targets the edge cases deliberately and we say plainly when a task is not yet tractable with the data on hand. And because accuracy is never perfect, we design the human fallback as core architecture, not a disclaimer — a confidence threshold that escalates the uncertain, so a consequential decision is never left entirely to a model that is right most of the time but not always. We would rather tell you a use case needs a person in the loop than pretend it is safe to automate outright.

Technologies we build it with

Chosen per problem, not per fashion — this is the stack we most often reach for on this work.

How we deliver

  1. 01

    Discover

    We map the system, the constraints and the business it serves — including the parts nobody documented.

    Architecture brief

  2. 02

    Architect

    Decisions get made, written down and defended before a line of production code exists.

    Decision records

  3. 03

    Build

    Short cycles against working software. You see progress in the product, not in a status deck.

    Shipping increments

  4. 04

    Operate

    Monitoring, incident response and iteration. The system is alive, so the engagement is too.

    Runbooks & SLOs

What changes

  • A task actually automated

    A visual job that was manual, slow or inconsistent turned into a system that runs at your volume, with its accuracy measured honestly and a human fallback where it counts.

  • Robust to the real world

    A model evaluated against the lighting, angles, occlusion and rare cases that break naive demos — not one tuned to a tidy test set that flatters it.

  • Deployed where it needs to run

    Inference placed deliberately in the cloud or on the edge device, with the latency, bandwidth, cost and privacy trade-offs made on your constraints.

Industries we serve

Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.

How pricing works

  • A discovery and feasibility engagement first, where the task is genuinely uncertain — assessing the data you have, the annotation you need, and whether the problem is tractable to the accuracy the decision requires — priced by the assessment, so you are not committing to a build before anyone knows it will work.
  • Fixed-scope build for a well-defined vision task with a clear decision and a known deployment target, quoted once the problem, the data strategy and the cloud-or-edge choice are understood.
  • Monthly senior engagement for evolving vision work, where the model needs ongoing retraining as conditions drift, new classes appear, or the deployment expands — vision models are not build-once, and the data they meet changes over time.
  • A note on annotation: labelling is a real, separate cost driver — sometimes the largest one — and we scope and cost it explicitly rather than burying it, because pretending it is free is how vision budgets blow up.

Typical timeline

  1. 01

    Framing and feasibility

    One to two weeks defining the decision the system feeds, the acceptable error rate, the real conditions the camera faces, and an honest read on the data you have versus the data and annotation you need — enough to say whether the task is tractable before committing to a build.

  2. 02

    Data and annotation

    A variable phase, sized to the task, collecting or organising representative data and labelling it consistently — including the rare and failure cases. This is often the longest and most underestimated stage, which is why we scope and cost it explicitly rather than assuming the data is ready.

  3. 03

    Model training and honest evaluation

    Fine-tuning a pre-trained model on your task and measuring it against a test set built to probe the failure cases, improving deliberately where the errors cluster, until it is good enough for the decision it feeds rather than good enough for a demo.

  4. 04

    Deployment, fallback and handover

    Deploying to the chosen target — cloud or edge — wiring in the confidence thresholds and the human fallback on decisions that matter, adding monitoring for the drift that vision models suffer as conditions change, and handing over a system your team can operate and retrain.

Why teams choose us for Computer Vision

  • Senior engineers only

    Vision is easy to demo and hard to ship, and the gap between the two is full of judgement calls — how much data, which failures matter, cloud or edge, where a human belongs in the loop. The people building your system have taken vision models past the demo into production and watched the edge cases bite. No juniors learning on your project that the clean test set was lying.

  • We operate what we build

    We run the vision systems we ship, so the parts that only surface after launch — the model drifting as the season or the lighting changes, the confidence threshold that needs tuning, the monitoring that catches a silent failure — are designed in from the start rather than discovered when the accuracy quietly degrades in the field.

  • Honest about what vision can and cannot do

    Accuracy is never one hundred per cent, annotation is a real cost, and some tasks are not tractable with the data on hand. We will tell you these things before you commit, design a human fallback where the decision demands one, and talk you out of automating something that should keep a person in the loop — rather than sell you a black box and let you find the limits in production.

  • Privacy taken seriously where people are in frame

    When your images contain people, we treat the GDPR, consent and biometric-data constraints as design inputs from the first decision, not paperwork to finish before launch. A vision system that works technically but cannot lawfully or responsibly be operated is a failure, and we build so that yours is neither.

How to engage us

Three ways to work with us on this — chosen to fit the problem, not our margin.

Related services

Part of AI Development. Other work we do alongside this.

Common questions

How much data do we need, and how much does labelling really cost?

Less than you might fear for the model, more than you might hope for the labelling. Because we fine-tune a pre-trained model rather than training from scratch, the backbone already understands edges, textures and shapes, so you need far fewer examples than a from-nothing approach would demand. But you still need enough well-annotated images of your actual conditions — including the rare and failure cases — and that annotation is a real, recurring cost that people consistently underestimate. Pixel-level segmentation labelling costs far more than simple classification labels. We scope and cost the annotation explicitly during framing, because pretending it is free is the single most common way vision projects blow their budget.

Should the model run in the cloud or on the device at the edge?

It depends on your latency, bandwidth, connectivity, cost and privacy, and it is a genuine trade with no free answer. The cloud gives you the largest, most accurate models, easy updates and elastic scale, but every frame makes a network round trip, you pay bandwidth and compute for it, and your images leave the site. The edge — running on the camera, the device or a box beside it — gives you low latency, works without reliable connectivity, keeps footage on-site for privacy, and avoids streaming costs, but it forces a smaller, faster model onto constrained hardware and you give up some accuracy for it. Sometimes the right answer is a hybrid: a light model on the edge that only calls a heavier cloud model when it needs to. We make this call on your constraints, not on which was easiest to build.

Our proof-of-concept worked on sample images but failed on real footage. Why?

Because a clean sample set and the real world are very different problems, and this is the most common way vision projects come unstuck. A model tuned on tidy images has not met the lighting that shifts through the day, the camera angle it was not trained for, the object half-hidden behind another, or the rare class that barely appeared in training — and those edge cases are where naive models fail. The fix is not usually a cleverer model; it is representative data from the actual conditions, an evaluation set built to probe the failure cases rather than flatter the model, and deliberate improvement where the errors cluster. This is exactly the work a demo skips and a production system cannot.

Can we trust it to make decisions automatically, without a person checking?

For anything where being wrong is costly, no — and we design around that rather than pretend otherwise. Vision accuracy is never one hundred per cent; there is always some rate of false positives and false negatives, and pushing one down tends to push the other up. So for consequential decisions we build a confidence threshold and a human fallback: the model handles the clear cases at volume, and the uncertain or anomalous ones escalate to a person instead of being acted on blindly. For low-stakes, high-volume work — sorting, tagging, first-pass filtering — full automation is often fine. The right answer depends on what a mistake costs, and we will tell you honestly which side of that line your use case falls on.

Our images contain people — what do we need to consider legally?

Quite a lot, and it has to shape the design from the start rather than be bolted on before launch. Images of identifiable people are personal data under the UK GDPR, and facial or other biometric identifiers are a special category with a higher bar for lawful processing, so the lawful basis and any consent need to be settled before the camera goes up. Data minimisation matters — capturing only what the task needs, analysing and discarding rather than storing footage where the use case allows, keeping retention short and justified — as does being transparent about what is being processed and why. We treat these as design inputs, not afterthoughts, because a system that works technically but cannot lawfully or responsibly be operated has failed regardless of its accuracy.

Let’s talk about Computer Vision.

Tell us what you’re building or fixing. A senior engineer reads every enquiry and replies within a business day.

Prefer to book a call?Or email support@yarqat.com

Two fields required. We reply to real enquiries — no list, no sequence.