Vision models trained on your images and deployed where the camera is.
There's already a camera on the line and an inspector checking every part, and still nobody agrees on what a defect is. We write that definition down first, then label a few hundred images to it.
Computer vision lets software interpret images and video for tasks such as detecting defects, counting objects, reading documents and gauges, and monitoring safety zones.
Cohash builds vision systems from data labeling through training to deployment in the cloud or on edge devices. We check model licenses before you ship, since some popular detectors are AGPL-3.0, and we manage camera and device identities like any other workload.
you probably need this if
Inspectors check parts by eye and two shifts reject different things.
Analog gauges are read and written down by hand on a round.
A vision proof of concept was built on a model whose license wouldn't allow you to ship it.
From the first call to a setup your own team can run.
Here's what usually prompts a call about your Computer Vision, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · computer vision3 open
openInspectors check parts by eye and two shifts reject different things.
recurringAnalog gauges are read and written down by hand on a round.
blockedA vision proof of concept was built on a model whose license wouldn't allow you to ship it.
exposure
Defect definition and labelingDetection, segmentation and…Document and gauge readingEdge deploymentModel license reviewDevice identity and image security
startrehearsehandover
Define and sample
Label and baseline
Validate on site
Deploy and monitor
we are here
ready to hand over
We knew performance for each shift and variant before go-live.
We documented and settled the product's licensing, and made a license check a standard…
Labeling guide and labeled dataset
Evaluation report by condition, shift and product variant
chapter 01 · where it hurts
Why teams reach out
Inspectors check parts by eye and two shifts reject different things.
Analog gauges are read and written down by hand on a round.
A vision proof of concept was built on a model whose license wouldn't allow you to ship it.
chapter 02 · what we change
How we solve it
Defect definition and labeling
Detection, segmentation and classification
Document and gauge reading
Edge deployment
Model license review
Device identity and image security
chapter 03 · how it runs
Our approach
Define and sample
Label and baseline
Validate on site
Deploy and monitor
chapter 04 · where you end up
What changes
We knew performance for each shift and variant before go-live.
We documented and settled the product's licensing, and made a license check a standard step when models are chosen.
Labeling guide and labeled dataset
Evaluation report by condition, shift and product variant
what we do
Where we spend the hours
6 areas of work, each one done by an engineer who has run it in production.
First a labeling guide, agreed with your quality team. Then example images for every class, and a review step so the same scratch gets the same label from two different labelers.
The model type has to fit the question: classification for pass or fail, detection for where and how many, and segmentation when the size or shape of a defect matters.
We use OCR for labels, serial plates and forms, and read analog gauges and displays where replacing the instrument isn't practical.
Export the model to ONNX, quantize it, then test speed and accuracy on the hardware it'll actually run on. And plan how models get updated in the field before you need to.
Check the license before you ship. Ultralytics YOLO is offered under AGPL-3.0 or a paid Enterprise License, so we confirm the terms for every model and training library that goes into a product.
We give each camera and edge device a certificate-based identity, encrypt images in transit, and limit and log access to stored footage.
capability 01 / 06in production
Defect definition and labeling
First a labeling guide, agreed with your quality team. Then example images for every class, and a review step so the same scratch gets the same label from two different labelers.
The model type has to fit the question: classification for pass or fail, detection for where and how many, and segmentation when the size or shape of a defect matters.
Export the model to ONNX, quantize it, then test speed and accuracy on the hardware it'll actually run on. And plan how models get updated in the field before you need to.
Check the license before you ship. Ultralytics YOLO is offered under AGPL-3.0 or a paid Enterprise License, so we confirm the terms for every model and training library that goes into a product.
We pieced these together from Computer Vision situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
A defect model that passed in the lab and fails on night shift
composite · not a client story
Beforethe situation
A surface defect model trained on day-shift images passed acceptance in the lab. On the line it rejects far too many good parts at night, when the lighting changes and the camera runs a different exposure setting.
What we dothe work
We collect and label images from every shift, camera and product variant, and report accuracy per condition instead of one figure. Lighting and exposure are fixed at the station where possible. The model is retrained on the wider set and checked on site against the inspector's calls across a full production week.
Afterwhere you end up
We knew performance for each shift and variant before go-live. Inspectors now review the parts the model's unsure about, not every part.
case file 02
A commercial product built on YOLO weights and an unread license
composite · not a client story
Beforethe situation
The inspection product is commercial, and it's built on Ultralytics YOLO code and weights. Those come under AGPL-3.0 or a paid Enterprise License. Legal only learned this in a customer's procurement review.
What we dothe work
Every model, weight file and library in the product goes on a list with its license. We then price the Enterprise License against retraining on a permissively licensed detector, measuring accuracy and latency on the same test set. Counsel decides.
Afterwhere you end up
We documented and settled the product's licensing, and made a license check a standard step when models are chosen.
How a vision model runs on the line and improves over time
We set up cameras with their own certificate identities feeding an edge device that runs a quantized model on site. Results go to the line and the quality system. Hard images go back to the cloud for labeling and retraining.
Edge inferenceONNX · quantized model → Line control · pass or fail→ Quality records · defect record→ Labeling · hard cases
02 · Plant systems
Line controlPLC · reject gate
Quality recordsMES · QMS
03 · Cloud training
Labelingguide · reviewer check → Training and registry · dataset
Training and registryDatabricks · MLflow → Edge inference · signed model update
License reviewAGPL-3.0 · Apache-2.0 · commercial → Training and registry · approved models
Read the diagram as text
Cameras → Edge inference: mTLS stream
Edge inference → Line control: pass or fail
Edge inference → Quality records: defect record
Edge inference → Labeling: hard cases
Labeling → Training and registry: dataset
License review → Training and registry: approved models
Training and registry → Edge inference: signed model update
how it runs
A typical engagement
We don't start a step until the last one has produced something you can check.
step 01
Define and sample
Agree the decision the system supports and what counts as each defect or object. Then collect images in the real lighting, on the real line.
step 02
Label and baseline
We labeled a dataset, trained a first model and scored it on held-out images from days and shifts it hadn't seen.
step 03
Validate on site
We run the model in shadow mode alongside the human inspectors until agreement reaches the target.
step 04
Deploy and monitor
Once it's in production we watch for drift in image conditions, and the hard cases go back for relabeling.
you keep
What you're left with
We write these for your Computer Vision setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
guide01
Labeling guide and labeled dataset
yours to keep
report02
Evaluation report by condition, shift and product variant
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
00:0006:0012:0018:0000:00
roles we staff
Computer vision engineer
Machine learning engineer (PyTorch)
Data labeling lead
MLOps engineer
Edge inference engineer
due diligence · computer vision
Questions to ask any partner, including us.
Put these to anyone bidding on your Computer Vision work. The ones who've done it answer differently from the ones who've read about it.
Q1
Who writes the defect definition, and who breaks ties on borderline parts?
Vague definitions mean two labelers tag the same scratch two ways, and the model learns the disagreement. Write the labeling guide down and name someone to settle edge cases.
Q2
Will accuracy be reported per shift, camera and product variant?
One headline accuracy figure can hide a model that falls apart at night. Break the results out by condition. Then you know where to add data and where to fix the lights.
Q3
After inference, how long are line images kept and who can open them?
Frames from the line can capture faces and proprietary parts. Agree retention, access and blurring before the first camera goes live.
Q4
How do the cameras and edge boxes authenticate to the backend?
Cameras on default passwords or shared keys make an easy way onto the plant network. Give every device its own identity and credential.
Q5
When a new product variant launches, what is the retraining plan?
Vision models do badly on parts they haven't seen. Have the relabel-and-retrain process in place before the first new variant reaches the line.
01How many images do we need?
Usually a few hundred labeled images per class for a first model. It depends how varied the defects and conditions are, and rare defects need targeted collection, sometimes synthetic examples.
02Should the model run at the edge or in the cloud?
Edge if you need millisecond decisions, have limited bandwidth or can't send images off site. Cloud if latency is relaxed and you'd like simpler updates. A lot of systems do both: they decide at the edge and retrain in the cloud.
03Can we use YOLO models in a commercial product?
Ultralytics says its YOLO code and models are available under AGPL-3.0, which requires open-sourcing your project, or under a paid Enterprise License. Other detectors carry permissive licenses. We check before you build on one, and your counsel should confirm.
04What about privacy when cameras capture people?
Keep capture and retention to a minimum. Blur faces where people aren't what you're inspecting, and limit who can view the footage. Legal should confirm notice and consent requirements for each site.
05Could a hosted vision-language model replace training our own detector?
For some jobs, yes. Claude or OpenAI's multimodal models can read documents, gauges and labels with very little training data, which is fine for low-volume checks. On a fast line, a trained detector running at the edge usually wins on speed and on cost per image.
related
Often paired with
Projects on Computer Vision usually end up touching one of these, so they're worth a look.
