We build systems that look at an image and return a decision: pass or fail, a count, a grade, a line of text. What limits them is almost never compute. It is the supply of labeled examples, and whether the camera, the light and the focus hold still.
In short: Vision systems read defects, counts, condition and printed labels off images. The bottleneck is labeled examples and physical consistency — camera position, lighting, focus — rather than model choice. We treat the camera rig as part of the design and labeling as a phase with its own hours and its own price.
What the system gives back
A camera produces pixels. A useful system produces a decision that something downstream can act on: divert this unit, flag this asset, record this number. The four jobs below cover most of what gets asked for, and they differ more in how you collect examples than in how they are built.
Defect detection
Scratches, cracks, contamination, a missing component, a bad seal. Returns a pass or fail and marks where on the image the problem sits.
Counting
How many items are in frame, on the shelf, in the yard, or crossing a line over a period. Simple to state, sensitive to occlusion and overlap.
Condition assessment
Grading wear, corrosion, ripeness or damage severity against a scale your people already use, so the output slots into existing paperwork.
Reading labels
Serial numbers, batch codes, expiry dates, meter and gauge readings lifted off a surface and turned into text a system can store.
The scene matters more than the network
A model can only work with what reaches the sensor. If a hairline crack is invisible under flat overhead light, no architecture will find it, and every hour spent tuning is wasted. Angle the light across the surface instead and the same crack throws a shadow a simple model can catch. That is a lamp and a bracket, not a research program.
The same goes for consistency. A fixed camera at a fixed distance under fixed light gives you images that look alike, and a model trained on images that look alike is far smaller, faster and more reliable than one trained to cope with chaos. Every degree of variation you remove from the scene is variation the model no longer has to learn from examples you would otherwise have to collect and label. We look at the physical setup first because it is usually the cheapest place to buy accuracy.
Labeling is real work, so it gets its own line
Someone has to sit down and mark up thousands of images. Draw the box, name the class, decide whether that faint mark counts. It is slow and it needs subject knowledge, because a contractor who has never seen your product cannot tell a cosmetic blemish from a reject. Hiding this inside a model budget is how vision projects slip a quarter.
We quote it separately, with an estimate of images, hours and who does them. Before that, we ask your experts to agree the standard on real photographs. If two inspectors look at the same part and disagree, the labels will contain that disagreement, and the model will learn to be inconsistent in exactly the same way. Settling the definition is not admin. It sets the ceiling on everything measured afterward.
What breaks it later
Vision systems fail physically. Someone knocks the mount. A bulb is replaced with a cooler one. The lens picks up a film of dust. Packaging changes color, a new supplier ships a slightly different finish, and winter sun comes through a window that was not there in the training images. None of this shows up as an error message. Accuracy just sags.
So the deliverable includes a check that compares incoming frames to the images the model was trained on and raises a flag when they diverge, plus a small routine for capturing and reviewing rejected cases. That feeds ongoing monitoring and gives you a stock of fresh examples for the next round of training. Where images and readings need to reach other systems, that runs through your data integration layer rather than a script on one machine.
What we won’t do
We won’t start modeling before we have seen real images
Photos taken at a desk are not photos taken on the line. Until we have samples from the actual position, under the actual light, any estimate would be a guess wearing the clothes of a plan.
We won’t bury labeling inside the model budget
It is the largest and slowest part of most vision projects. It gets its own phase, its own hours and its own number, so the timeline you approve is the timeline you get.
We won’t accept a defect standard that changes per inspector
If two of your experts disagree about what counts as a reject, we pause and ask you to settle it on real images first. Otherwise the model learns the disagreement and everyone blames the model.
Can a camera actually see the thing you need?
Send a handful of images from the real position and a description of what counts as a pass. We will tell you what the scene needs before we tell you what the model needs.
For a well-lit, repeatable scene with one obvious defect type, a few hundred examples per class is often enough to prove the idea. Subtle defects, many classes or a variable scene push that into the thousands. We size it after looking at sample images from the real position, because the answer depends far more on the scene than on the subject.
Can you use the photos we already have?
Sometimes. An archive shot by different people at different angles is useful for a feasibility check and poor as training data. If the deployed camera will be fixed, a few hundred images from that exact position are worth more than tens of thousands of mixed ones.
Does it run on site or in the cloud?
Both work and the choice is practical. On-site processing suits low latency, a line that cannot depend on a connection, or images that are not allowed to leave the building. Cloud suits bursty volumes and cases where the images already travel. We size the hardware against the frame rate you actually need.
What usually breaks a working vision system?
Physical change rather than software. A bumped camera, a replaced bulb, a dirty lens, new packaging, seasonal daylight from a nearby window. Accuracy sags quietly, so we ship a check that compares incoming frames against the training images and warns you when the two drift apart.
