Computer vision is changing how machines perceive and interpret the visual world. Oblytech’s Computer Vision Applications help your organization use this technology, building intelligent solutions that analyze images and videos, extract meaningful insights, and automate tasks that traditionally required human vision.
Computer vision systems can identify and classify objects, people, scenes, and activities within images and videos. This can be used for applications such as:
Extract text from images and documents, converting it into machine-readable format for analysis, data entry, or archiving.
Computer vision systems can analyze visual data to extract valuable insights and detect anomalies, such as:
Our expertise extends to 3D computer vision, enabling applications like:
A camera that watches a process is only useful if the image answers a question someone is paid to answer. On a production line the question might be whether a part is within tolerance before it leaves the station. In a warehouse it might be which pallet is in a bay and whether it is damaged. In a clinic it might be whether an image shows a finding that a clinician should look at first. Each of those questions has a different tolerance for error, a different speed requirement and a different person who acts on the result. Computer vision projects go wrong when the team starts with the model and only later asks what the output is for.
This page is for the operations, quality or engineering lead who has a visual inspection, counting or monitoring problem and is deciding whether a vision system is the right response. It explains how to match the task to the technique, what determines whether a pilot can succeed, and what a buyer should ask before committing to a build.
Vision work splits into a handful of task types that behave very differently in practice. Choosing the right one before any data is collected prevents a common mistake, which is to label images for a task that the business does not actually need solved.
| Task type | What the system outputs | Where it typically struggles | Questions to answer first |
|---|---|---|---|
| Classification | One label for the whole image, such as good or faulty | Faults that are small or appear in unexpected places | Is a single label enough for the decision? |
| Detection and localization | Where an object or defect sits within the frame | Crowded scenes, overlapping items and unusual angles | Does someone need to know where, not only whether? |
| Tracking | Where a specific object is over a sequence of frames | Occlusion, lighting changes and identity swaps | How long must an item be followed, and what follows the track? |
| Measurement | A dimension, count or angle derived from the image | Calibration drift and inconsistent camera positioning | What tolerance does the measurement have to meet? |
| Text reading | Characters extracted from a label, plate or document | Glare, curvature, low contrast and worn print | What happens to a character the system cannot read? |
Measurement is frequently underrated. A system that reports a dimension with a known uncertainty can support a quality decision that a yes-or-no classifier cannot, but it demands fixed geometry and regular calibration, which many sites do not maintain on their own.
Much of the effort in a successful vision pilot happens before the model is trained. The image set has to represent the conditions the system will meet in production, including the shifts, seasons and equipment states that people tend to forget. A set captured on a calm afternoon will produce a model that fails at the first change of lighting. Camera position matters for the same reason: a camera that moves by a few centimetres after a maintenance visit can change the apparent size of every object in the frame.
Defects deserve particular attention. Faults are rare by definition, so a collection drawn from normal running will contain very few examples of the thing the system exists to catch. Teams often respond by collecting staged defects, which can teach the model to recognize the staging rather than the fault. The better approach is to collect real faults as they occur, record the conditions around each one, and be honest about how few examples a pilot can rely on.
Whether analysis runs at the camera, on a local server or in a central environment is a design choice with consequences for latency, bandwidth, resilience and data handling. A line that must stop a machine within a fraction of a second cannot depend on a round trip to a distant service. A site with unreliable connectivity needs local processing that keeps working when the network does not. Central processing is easier to update and monitor, but it moves images, which may contain people, off site.
The choice should be made against the consequence of a delay or a failure, not against the fashion of the moment. Ask the vendor or delivery team what the system does when the connection drops, how the model is updated on devices that are not always online, and where each image is stored and for how long.
Some computer vision applications touch identity, such as recognizing a face for access or matching a person across cameras. These uses often count as biometric or otherwise sensitive data under data-protection rules, and they can require a documented legal basis, a clear notice to the people affected and limits on retention before any pilot begins. Sector regulation and data-protection obligations apply in addition to the technical design, and they can rule out an approach that works perfectly well. Involve legal and privacy colleagues before the first image is captured, not when the prototype is ready to show.
The same caution applies to monitoring that people may experience as surveillance. Where a camera watches workers or customers, the purpose should be stated narrowly, the data kept only as long as the purpose needs, and the people affected should know what is being measured and why.
An overall accuracy figure is rarely the right measure. A system that looks strong on average may still miss the one defect class that causes the most harm. Define the error types and their costs before evaluation starts. A missed defect that reaches a customer, a false alarm that stops a line for an hour and a damaged item that a person must check manually are different events with different owners, and they should be counted separately.
Evaluation should also include conditions the system was not trained on, such as a new supplier’s packaging or a seasonal change in light. Record how the system behaves when it is uncertain, and decide in advance what the process does with uncertain results. The evaluation and quality assurance page covers checking AI outputs against intended use and acceptance conditions.
The right design depends on where the camera sits. A manufacturing buyer will focus on tolerance, line speed and retraining after a change of product. A logistics operator will care about identification under poor lighting and at high throughput, and about how exceptions are handed to people. A healthcare provider will be most concerned with clinical responsibility and with keeping any diagnostic support clearly separate from the decision a clinician makes. Ask every provider how their approach would change in your setting, and treat a provider who gives the same answer for every sector with caution.
Enough to represent the conditions and the defect types the system must handle, which is usually more than the team expects and less than a large-scale collection would suggest. The honest answer depends on how often the target condition occurs, and a pilot should state how thin its defect examples are.
Often, but its resolution, mounting, frame rate and lens need checking against the task. A camera chosen for surveillance may be unsuitable for measurement, and a camera that moves between shifts will undermine any model trained on fixed geometry.
The process should send the item to a person, and the design should record the decision. An uncertain result that is silently accepted is a common route to a costly miss.
A useful first conversation describes the decision the camera supports, the error costs, the lighting and mounting conditions, and any legal constraints that apply to the images. That description is enough to judge whether a pilot is worth running and what it would have to prove. The data readiness page is about checking information sources before building on AI, and the governance and risk controls page is about approved use, data access and human oversight. Discuss your computer vision requirement with us once you can describe the decision and the conditions the images will be captured under.
Contact Oblytech to talk through your needs and discover how our Computer Vision Applications can change how your business runs.
Most computer vision applications answer one of three questions: is this item acceptable, where is this thing, or how many are there. Choose the question first, because it sets the task type, the camera setup and who acts on the output. An inspection station that asks whether a seal is present is a classification problem with a clear reject action. A dock that counts pallets leaving a bay is a counting problem, and a miscount matters only when someone reconciles it against the system of record. If you cannot name the person who acts on the answer, the application is not ready for a pilot yet.
A first pilot should cover one station, one product family and one decision. Run it in five steps. First, record the manual decision across a full production cycle without changing it. Second, list the faults people reject and the ones they pass, because that list defines what the system must catch. Third, capture images under the lighting, speed and shift conditions the station normally runs at, then test the set with a data readiness check. Fourth, train on one period of images and test on a later one, so the test reflects drift rather than the same afternoon. Fifth, run the system beside the human for a fixed period and study every disagreement, not the headline score.
Stalled pilots usually fail in the same few ways:
Once the disagreements are understood, scaling depends on whether the second station shares the first station’s conditions. If lighting, product mix or camera mount differs, treat it as a new pilot. Before production use, settle the AI evaluation and quality checks, since they define what counts as a pass.
Computer vision applications are the right choice when a camera must recognise visual content that varies too much for a fixed rule to describe. Many inspection and counting tasks look like vision problems but are solved by a fixed sensor, a brightness threshold or a code reader. If the part always sits in the same place, under the same light, and the defect shows up as one measurable change, a simple method is usually cheaper, easier to maintain and easier to explain to the operator.
A practical test has three parts. First, ask whether the target looks the same every time it appears. A bottle cap in a fixed holder usually does; a mixed pallet of cartons with printed labels usually does not. Second, ask whether the failure can be written as a rule a technician could follow by hand. A missing seal that shows as a gap of known width fits that test. Third, ask how much variation the rule must absorb. If the answer is a lot, the system needs to learn from images rather than from thresholds.
The common mistake is to skip the simple option. Teams often commission a model for a station that a backlit sensor could have handled, then spend time collecting images to match a problem that was never variable. Run the cheap check first against the same images. If it misses faults that a person catches, that gap becomes the specification for the vision work.
A fixed rule that works on the first day can quietly fail when packaging changes, a supplier switches material, or a camera is bumped during cleaning. Whichever approach is chosen, record the images it misclassifies, because those records show when a rule has drifted and when a learned model needs new examples.
Before you commit budget, write down the decision the output feeds, the cost of a missed fault and the cost of a false stop. Those two numbers decide whether a simpler method meets the need. If you have several candidate stations, shortlist the problems worth pursuing before choosing a method, and put a money value on each fault type so the comparison uses real numbers.
Most computer vision work starts with digital images and some image processing to clean them up. Image segmentation then separates the part you care about from the background, which is how quality control checks on an assembly line can spot a defect from its visual features.
Computer vision applications are software systems that read images or video and turn what they show into a result a process can act on. That result is a decision, a count, a measurement or an alert. A camera that records a loading bay keeps pixels for someone to review later. A computer vision application decides, for each image or frame, whether a pallet is damaged or how many cartons crossed the door, and it passes that decision on.
In most implementations the application is a chain of five parts. A camera or scanner captures the image under some lighting. Preprocessing crops, resizes and corrects the picture for a consistent model input. A trained model produces a score or label. A threshold or rule turns that score into a decision for this process. The result then goes to the system where people already work, such as a quality log, a warehouse system or a ticket queue.
| Question | Recording video | Computer vision application |
|---|---|---|
| What is kept? | Footage for later viewing | A result for each image or frame, with the image that produced it |
| Who acts on it? | Someone who searches the footage after an event | A process step or named person, triggered when the result arrives |
| When does the answer exist? | Only when a person looks | As soon as the image is processed |
| What happens when it is wrong? | Nobody knows until someone reviews the footage | A well designed rule sends uncertain cases to a person |
The action row is where many projects stall. A model that writes scores into a dashboard with no owner gives the business a report nobody acts on. Before model work starts, write down the action each result triggers, who receives it and how long they have to respond. Scoping may be the first job of an AI consulting and implementation engagement. If a result cannot change what someone does in the next shift, the system produces reports rather than control.
Could a person describe the decision in one sentence and make it from the same image alone? If so, the task is a candidate. If the decision depends on context the camera cannot see, the application covers only part of it. Building and training the model itself is covered by machine learning development, and the AI and ML services overview places vision work among the other options.
A packaged computer vision product is the right starting point when the task matches what the vendor built it to do, the camera and lighting sit where the product expects them, and the output goes into a tool you already run. A custom application makes more sense when the decision depends on your own images, your own defect types or a process the product was never designed around. Deciding which of those two situations applies to you is the first step in choosing.
Start by checking the product’s assumptions against your site. Ask which camera models, mounting heights and frame rates it was tested with, what lighting it needs, and whether it was trained on images like yours. A product trained on clean packaging will struggle with a supplier’s new label. Ask for results on your own sample images, not on the demonstration set.
Packaged products usually take one of three forms: a fixed smart camera that runs one inspection program, a software licence that analyses video from cameras you already own, or a hosted service that receives images and returns a label. Each carries different costs. A fixed unit is simple to install but hard to change when the product mix changes. Licensed software depends on your camera hardware and network. A hosted service moves images off site, which brings its own data handling questions.
Whichever route you take, the pilot test is the same. Run the product beside the current manual check for the same period you would test any other system, and compare the results on your own images. A product that looks accurate on a vendor’s sample set can still miss the defect your line cares about. If the product cannot send uncertain items to a person, treat that as a serious gap and ask the vendor how it is handled.
Scope and integration boundaries are covered in the AI integration and tool boundaries page. For the adoption side of a rollout, including who owns the output of a vision system, see AI adoption and change enablement.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.