A vision model that scored well on a public dataset often stumbles on your own floor, under glare, at night or with a camera mounted too high. Agnotic Technologies builds computer vision for your cameras and images: the right task, labels from your sites and inference where it has to run.
Trusted by global innovators
Computer vision services and solutions are the engineering work that turns camera feeds and images into decisions software can act on: choosing the vision task, labeling data from the client's own sites, training and testing a model, and running it at the edge or in the cloud. Agnotic Technologies builds this for product and operations teams.
The model is the smaller part of the job. Most of the effort goes into deciding what the camera must see, collecting images that look like the real site on a bad day, and sending the output to the system where someone acts on it.
This page covers general computer vision development. Counting stock from shelf and rack images has its own page, linked below, and medical imaging work such as DICOM pipelines is handled as a separate healthcare service.
Decision table
Picking the task first decides the labeling effort, the model family and where it can run. Agnotic Technologies works through this table on the scoping call.
| Task | What it answers | Labels it needs | Typical field failure | Edge or cloud |
|---|---|---|---|---|
| Image classification | Is this image an example of a known class, such as damaged or intact? | One label per image | A new product package or background the model never saw | Suits the edge: small models and one answer per frame |
| Object detection | Which objects are in the frame, and where? | A box and a class for every object of interest | Occlusion, when people, pallets or other objects hide part of the target | Edge for live alerts, cloud for batch review of recorded video |
| Segmentation | Which exact pixels belong to each object or region? | Pixel masks, the slowest labels to produce | Glare and reflections that blur the edges of a region | Often cloud, or an edge device with a GPU, since the models are heavier |
| OCR and code reading | What text, serial number or code is printed here? | Text transcriptions, often with word boxes | Motion blur, curved labels and worn print | Either; edge when the result must arrive before the item moves on |
| Tracking | Is this the same object as in the last frame, and where did it go? | Boxes linked across frames with an ID | Lost IDs when objects cross paths or leave and re-enter the frame | Edge, since frames must be processed in order with little delay |
| Pose and keypoints | How is this body, hand or machine part positioned? | Points on joints or landmarks | Night shift lighting and unusual camera angles | Edge for live feedback, cloud for later analysis |
Many products chain two tasks, for example detection to find a label and OCR to read it. Each task is tested on its own before the pair is tested end to end.
Data collection and labeling
Public datasets rarely look like your floor. The training and test sets come from the cameras the model will actually use.
We record the mount height, angle, resolution, frame rate and lighting of each camera, and flag any that cannot see the target clearly before a single image is labeled.
Images are collected across shifts, seasons and product changes, so the set includes glare, low light, clutter and the busy hour, not only a clear afternoon.
A short guide with pictures shows exactly what counts as each class, how to box a partly hidden object and when to mark an image as unusable.
Labelers work from the guide, a second reviewer checks a sample, and disagreements are used to tighten the guide rather than settled by a vote.
At least one camera or site stays out of training entirely, so the test score shows how the model behaves somewhere it has not seen.
Inference targets
One trained model can be exported to ONNX and run on different hardware. The choice depends on delay, bandwidth, privacy and the number of cameras.
Example: A smart camera or a small accelerator board beside a conveyor.
Approach: The smallest model that meets the accuracy target, compressed if needed, with only results sent upstream so raw video never leaves the device.
Example: One industrial PC serving several cameras in a warehouse, plant or store.
Approach: The ONNX model served on the gateway's GPU or CPU, results buffered when the network drops and updates pushed from a central model registry.
Example: A field worker photographing equipment, parts or labels.
Approach: An on-device model for instant feedback, with the image uploaded later for a heavier cloud check when the result matters.
Example: Recorded video reviewed overnight, or images uploaded from many sites.
Approach: Larger models on cloud GPUs that scale with the queue, with images encrypted in transit and deleted on the retention schedule you set.
Failure points and retraining triggers
Most field failures are changes in what the camera sees, not bugs in the code. Each one has a signal we monitor and a trigger for new labels or retraining.
Challenge
Glare from windows or wet floors at certain hours
Agnotic approach
Test images are grouped by time of day, and a drop in confidence at fixed hours triggers a lighting fix or new labeled images from those hours.
Challenge
New product packaging or a new uniform
Agnotic approach
Unfamiliar items are sent to review instead of forced into a known class, and the label set is updated before the new item becomes common.
Challenge
A camera knocked, moved or refocused
Agnotic approach
Each camera's view is compared with a reference frame every day, and a shift raises a maintenance ticket before its results are trusted again.
Challenge
Occlusion by people, forklifts or stacked goods
Agnotic approach
Results carry a visibility score, and low-visibility frames are skipped or retried on the next frame instead of reported as missing.
Challenge
Night shift lighting and infrared switching
Agnotic approach
Night images are labeled as their own group and tested separately, because a day-only score hides night errors.
Challenge
Slow drift as the site changes
Agnotic approach
People review sampled frames each week, and retraining starts when the reviewed error rate passes the threshold your team set.
Most vision projects are not about people, but people walk through the frame anyway. We design for that from the first camera survey.
Detecting that a person is present is a different system from recognizing who they are. We build presence detection by default and face recognition only for a purpose your legal team has approved.
Where people are not the subject, faces and bodies are blurred or cropped on the device before images are stored or sent for labeling.
Biometric privacy rules differ by state and country. Your counsel confirms the notice, consent and retention rules for each site, and the software enforces them per site.
Raw video, labeled images and results each have their own retention period, encrypted storage and role-based access, with every export logged.
Where it applies
Computer vision services and solutions for startups and established operations follow the same method. The task and the inference target change.
Items on shelves and racks counted from images, with adjustments proposed to the inventory system.
Defects, missing parts or wrong assembly spotted on a line, with an inspector confirming each flag.
Missing protective equipment or people in restricted zones detected on job sites and plants.
Printed text, serial plates and codes read from photos taken by staff in the field.
Trucks, trailers and containers detected at gates and docks and matched to bookings.
Computer vision built into a product sold to many customers, with each customer's models and data kept apart.
Scope drivers
We size the work on a scoping call rather than quote a price. These factors move effort the most.
Classification labels are the quickest to produce; segmentation masks take the most work per image.
Each new site brings new angles and lighting that need their own images and tests.
Labeled images from your own cameras shorten the work; starting from raw footage adds a labeling phase.
Embedded boards need model compression and device testing that cloud inference does not.
Sending results to a WMS, MES, ticketing tool or mobile app adds one integration per system.
Sites with staff or the public in view add on-device blurring, consent records and stricter retention.
Standards and tooling
We choose open formats so a model can move between training tools and devices without a rewrite.
Three stages, starting with one camera view and one question.
We pick one camera view and one question, agree what a correct answer looks like and check whether the camera can actually see it.
Labeled data from your site, a trained model, a held-out site test and results flowing to one system your team reviews.
More cameras, sites and tasks, with weekly sampled review and retraining when the field error rate moves.
Short facts behind our model export and risk choices, each linked to its primary source.
ONNX is an open format built to represent machine learning models. It defines a common set of operators and a common file format so that models can be used with a variety of frameworks, tools, runtimes and compilers.
Source: ONNX (Open Neural Network Exchange)ONNX Runtime works with hardware acceleration libraries through its Execution Providers framework, so developers can deploy ONNX models in the cloud and at the edge and use the compute of each platform.
Source: ONNX Runtime documentation, Execution ProvidersThe NIST AI Risk Management Framework, released on 26 January 2023, is intended for voluntary use to improve the ability to build trustworthiness into the design, development, use and evaluation of AI products, services and systems.
Source: NIST AI Risk Management FrameworkNIST published Face Recognition Vendor Test Part 3: Demographic Effects (NISTIR 8280) on 19 December 2019, its report on demographic effects in face recognition algorithms.
Source: NIST, NISTIR 8280
