CLIEncoders · AI & Agents
Computer vision development
Vision projects succeed or fail on things that have nothing to do with the model: lighting, camera placement, and whether the defect you care about is visible at all.
Fix the optics before the model
A well-lit, consistently framed image makes an easy problem out of a hard one. Controlled lighting, a fixed camera position, the right lens and sometimes a polarising filter routinely deliver more accuracy improvement than any amount of model work.
So the first visit is about the physical setup. We would rather spend your budget on a lighting rig that makes the defect obvious than on training a model to see through a reflection that did not need to be there.
What we build
Object detection and counting, defect and anomaly detection for inspection, OCR and document capture including forms and licence plates, presence and occupancy sensing, and measurement from images where calibration allows it.
Classical computer vision still deserves consideration and often wins: for a fixed camera measuring a known part against a known background, thresholding and contour analysis in OpenCV can be more accurate, far faster and dramatically easier to debug than a neural network. We pick based on the problem rather than on what sounds more advanced.
Running at the edge
Most vision belongs near the camera. Sending video to the cloud costs bandwidth, adds latency, and stops working when the link does — and for many deployments the images should not leave the site at all.
We deploy to Jetson and embedded platforms, converting with ONNX and optimising with TensorRT or TensorFlow Lite, and size the hardware against your real frame rate and resolution rather than a benchmark figure.
Questions
What people ask before starting
How accurate will it be?
Not answerable before seeing your images, and precision and recall need separating anyway — missing a defect and falsely flagging a good part have very different costs, and you can trade one against the other. We establish that trade-off with you, then report both against a held-out test set rather than quoting a single accuracy number.
How many images do you need for training?
Often a few hundred well-chosen examples per class is enough to start, especially when fine-tuning a pretrained detector. The critical part is coverage of real variation — every lighting condition, angle and defect type you expect in production. A thousand images all taken on the same bright afternoon is a smaller dataset than it looks.
Can it detect defects it has never seen?
Sometimes, using anomaly detection — training on good parts only and flagging anything statistically unusual. This works well for products with consistent appearance and is the right approach when defects are rare or unpredictable. It gives you 'this is not normal' rather than 'this is a crack', which for a human-review workflow is frequently enough.
Does the video have to leave our site?
No, and usually it should not. Edge deployment keeps images local, sending only results and optionally cropped evidence images. That is cheaper on bandwidth, keeps working through an internet outage, and sidesteps most of the privacy question — which matters a great deal when cameras are pointed anywhere near people.
Related
Where this usually connects
Tell us what you are building
One technical call is usually enough to tell you whether this is straightforward, genuinely hard, or the wrong approach entirely. We would rather say so early than quote for the wrong thing.
Start the conversation