Computer vision development services

We build computer vision systems that detect, classify, segment and read what is in images and video, and we treat data collection, labeling and deployment as part of the job rather than an afterthought.

What we build

  • Visual inspection. Detecting defects, missing parts or misplacement on a line or in photographs, with thresholds tuned to the cost of a false alarm versus a miss.
  • Object detection and counting. Locating and counting items in images or video streams, such as stock, vehicles or equipment.
  • Classification and tagging. Sorting image collections, moderating uploads and enriching catalogs with attributes.
  • Segmentation. Pixel-level outlines for measurement, medical or industrial imagery, and mapping uses.
  • Document and OCR pipelines. Reading text and layout from scans and photos, extracting fields, and handing uncertain cases to a reviewer.
  • Video analysis. Frame sampling, tracking and event detection with attention to throughput and storage.

Models that read text from documents often pair with language models; see NLP and LLM applications for that half of the problem.

How an engagement runs

  1. Understand the setting. Cameras, lighting, angles, volume, latency needs and where the model has to run: a server, a phone or an edge device.
  2. Review and collect data. We look at what images exist, how representative they are, and what is missing, especially rare cases and bad conditions.
  3. Label with a guideline. A written labeling guide, a sample labeled together, and a review loop on disagreements. Label quality caps model quality.
  4. Train from a strong baseline. Fine-tune a pretrained model, measure per-class and per-condition performance, and add data where it fails.
  5. Test under real conditions. Held-out images from different days, sites or devices, because a model that works on its own training set proves little.
  6. Deploy and monitor. Export, optimize for the target hardware, serve behind an API or on-device, and sample production images to spot drift.

Privacy and responsibility

Images frequently contain people, faces, license plates or documents. We recommend collecting only what the task needs, blurring or cropping where possible, setting retention periods for raw images, and keeping a record of where images come from. Facial recognition and biometric identification carry specific legal restrictions in many places, and we do not take on work whose purpose is covert surveillance. For the general approach to mapping personal data in a system, see data mapping and discovery. This is general information, not legal advice.

Typical stack

  • Python, PyTorch and torchvision; OpenCV and Pillow for image handling.
  • Pretrained detection, segmentation and classification backbones, fine-tuned on your data.
  • OCR engines and layout models for documents, with validation rules around the output.
  • ONNX or similar formats for portable export; GPU inference servers or on-device runtimes for serving.
  • FastAPI, Docker, object storage and GitHub Actions around the model.

Deliverables

  • A labeling guideline and the labeled dataset, in an open format you keep.
  • Training and evaluation code with results broken out by class and condition.
  • A deployable model and service, with performance measured on the target hardware.
  • A monitoring plan that samples production images for review.
  • Documentation and a handover session for your team.

Common pitfalls we plan around

Vision projects tend to stall for predictable reasons, so we design around them from the start.

  • Training data that does not match deployment. Studio-quality photos teach a model little about a dusty camera at an awkward angle. We collect samples from the real setting early, even if there are only a few hundred.
  • Inconsistent labels. Two annotators drawing a box differently on the same defect quietly lower the ceiling on accuracy. A guideline with worked examples and a periodic agreement check keeps this under control.
  • Rare classes. The cases that matter most are often the least frequent. We evaluate each class separately and, where needed, collect or synthesize more examples of the rare ones.
  • Hidden latency. Decoding video, resizing and post-processing can cost more than the model itself. We measure the whole path on the target hardware, not just the network.
  • Silent drift. New products, seasonal light or a replaced camera shift the input distribution. Sampling production images for human review catches this before it matters.

None of this is exotic, but it is where most of the effort goes, and it is why we describe the work in terms of data and deployment as much as modelling.

Frequently asked questions

How many images do we need?

It depends on the task and on how varied the conditions are. Fine-tuning a pretrained model often needs far fewer images than training from scratch. We assess a sample before suggesting a number, and we do not guess.

Can it run on a device with no internet?

Often yes, with a model sized and optimized for that hardware. Accuracy and speed trade off, and we test on the real device.

Who does the labeling?

Either your team with our tooling and guidance, or a labeling vendor under a guideline we write. We review a sample either way.

What if the lighting or camera changes?

Performance can drop. We evaluate across conditions, augment training data accordingly, and set up monitoring so a change is noticed.

Request a quote

Tell us what the camera sees, what you need to detect, and where the model has to run.

Request a quote

See all services, or machine learning for the wider approach to training and evaluation.