Computer Vision Development

Most computer vision projects succeed or fail on the images, not the model architecture. Before training anything we collect samples from the actual cameras, lines or document sources the system will see in use - including the awkward cases: blurred frames, partial occlusion, unusual products, damaged documents and night shifts. A model trained on clean stock photos or a single week of footage rarely survives contact with production.

Labelling needs written rules. What counts as a scratch versus a reflection? Where exactly does a bounding box end when an object is half hidden? We draft a labelling guide with examples, measure agreement between annotators on a shared sample, and fix the guide where people disagree. Model-assisted labelling - where a draft model proposes boxes or masks and humans correct them - speeds this up considerably once a first version exists. Rare defects are the hardest part, so we track class balance and, where it helps, add targeted collection or carefully validated synthetic images rather than assuming more data of the common kind will fix it.

The task shapes the model. Image classification answers what is in this picture; object detection answers what and where, with boxes; segmentation outlines exact pixels, which matters for measuring defect area or separating overlapping items; tracking follows objects across video frames for counting and dwell time. OCR pipelines combine text detection, recognition and layout understanding to turn scans into structured fields.

Vision-language models add a newer option: they can describe images, answer questions about them and read complex documents with little or no task-specific training. They are excellent for prototyping, low-volume review and messy document layouts, but they are usually slower and costlier per image than a compact, purpose-trained detector, and harder to bound in behaviour. A common pattern is to prototype with a general model, then train a smaller specialised model once the task and labels are clear.

Cloud inference is simpler to update and scales easily for batch work such as document processing. Edge inference - on a camera, an industrial PC or a small accelerator beside the line - suits cases where latency must be low, bandwidth is limited, connectivity is unreliable or images should not leave the site for privacy reasons. Edge models are typically compressed through quantisation or pruning and converted to an optimised runtime, and every optimisation step is re-validated, because accuracy can shift after conversion. Hybrid designs are common: decide at the edge, send only flagged frames to the cloud for review and retraining.

Physical setup often matters more than the algorithm. Consistent lighting, a fixed camera angle, adequate resolution for the smallest defect and a shutter speed fast enough for moving parts can turn an unreliable system into a dependable one. We review the capture setup early and recommend changes before tuning the model to compensate for glare or motion blur.

Accuracy is measured on a held-out set that reflects real conditions, using metrics that match the business cost: precision when false alarms stop a line, recall when a missed defect reaches a customer, per-class results rather than a single average. After launch we log confidence scores, sample predictions for human review, and watch for drift caused by new products, seasonal light or a camera being bumped - then feed corrected examples back into retraining.