Platforms & Verticals
Inspection, counting, tracking and safety monitoring that hold up in real warehouse lighting — not in the conditions the benchmark was measured in.
Computer vision demos are easy and computer vision deployments are hard, and the distance between them is almost entirely about conditions. A defect detector trained on clean, evenly lit sample images achieves an impressive number and then fails on the line, where the light changes through the day, the conveyor vibrates, the part sits at a slightly different angle each time, and the defects that actually matter are the rare ones nobody photographed. We build vision systems for the second situation. ZenMagix works on visual inspection and quality control, counting and inventory verification, object tracking, safety and compliance monitoring, and document and label reading, for manufacturers, warehouse operators and logistics firms in India and abroad. Two commitments shape how we work. First, we assess feasibility on your images from your site before quoting a build, because published accuracy figures on public datasets tell you nothing about your parts under your lighting. Second, we report accuracy as separate false-positive and false-negative rates rather than a single headline number, since in most industrial applications those two errors have wildly different costs and a combined figure hides the one you care about.
Models fail on the variation nobody captured: changing light, part orientation, camera drift, seasonal dust, a new supplier's slightly different component. Controlling the imaging conditions matters more than improving the model.
The single highest-return intervention in an industrial vision project is usually not a better architecture. It is fixing the imaging. Consistent, controlled lighting — often a simple enclosure and a dedicated light source rather than the building's overheads — eliminates more error than months of model work, and it eliminates it permanently rather than probabilistically. Mechanical fixturing that presents the part in roughly the same orientation does the same.
Cameras rigidly mounted so they do not drift over months of vibration. These are boring, cheap and decisive. Then there is the variation you cannot remove, and it has to be present in the training data or the model will meet it for the first time in production. Light changes from morning to evening if any daylight reaches the line. Dust accumulates on the lens between cleanings. A supplier changes a component's surface finish slightly and every image shifts.
A new operator loads parts differently. We collect across shifts, across weeks and across suppliers, and where a condition cannot be waited for we synthesise it deliberately. The rare-defect problem deserves separate mention because it defeats naive approaches. If a defect occurs in one part per two thousand, a model that predicts pass every time is 99.95 per cent accurate and completely useless. This is why we never report a single accuracy number, why the evaluation set is constructed to over-represent defects, and why anomaly detection — modelling what normal looks like and flagging deviation — often beats classification when there are not enough defect examples to learn from.
False positives waste operator time; false negatives ship a defect. These have different costs in every business, and the threshold should be set by that arithmetic rather than by a default.
Every vision system trades one error against the other, and the correct balance is a business decision that engineers should not make alone. If a missed defect reaches a customer in a safety-critical product, you accept a high false-positive rate and the manual re-checking that comes with it. If the part is low-value and the line is fast, an operator pulled aside for every false alarm costs more than the occasional escape, and the threshold moves the other way.
We make this explicit before deployment: what does each error cost you, in money and in operator trust, and where does that put the threshold. Operator trust deserves emphasis because it is the mechanism by which good systems die. A system that cries wolf gets ignored, then overridden, then bypassed, and within a month it is a light nobody looks at. We would rather ship at a threshold operators believe and tighten it once they trust the system than launch at maximum sensitivity and lose the floor.
Confidence-banded routing helps a great deal here: clear passes flow through, clear failures are rejected, and only the uncertain middle goes to a human. That band is usually a small fraction of volume, which is what makes the economics work, and it also produces exactly the labelled examples the model most needs — the ones it found hard. Feeding those back is what turns a deployed system into an improving one rather than one that slowly decays as conditions drift.
Most industrial vision has to run on site: latency, bandwidth and privacy all point the same way. That constrains model size and makes deployment and monitoring genuinely harder.
Cloud inference is simpler in every respect except the ones that matter industrially. A reject decision on a moving line has a latency budget measured in tens of milliseconds, which a round trip cannot meet. A dozen cameras streaming continuously to the cloud is a bandwidth bill nobody approved. And in many facilities, footage of the floor is either commercially sensitive or contains identifiable people, which makes off-site processing a compliance question under the DPDP Act rather than an architectural preference.
So the model runs on site, on an industrial PC or an embedded accelerator, and that changes the engineering. Model size and precision are constrained by the hardware, so quantisation and pruning become part of the work rather than an optimisation afterthought. Deployment is harder because devices sit on segmented industrial networks that may be intermittently reachable, so update infrastructure needs the same A/B and rollback discipline as any field-deployed system.
Monitoring is harder still: you cannot watch a model's behaviour if it runs behind an air gap, so the system must summarise its own health locally — prediction distributions, confidence trends, image quality metrics — and report those upward even when raw footage never leaves. Drift is the specific thing to watch for. When a camera slowly fogs, a light dims, or a supplier's material changes, accuracy degrades gradually and nobody notices until a batch escapes. Automated drift detection on the input distribution catches this early, and it is the monitoring that most deployments lack.
Safety monitoring and workplace analytics involve identifiable people. We build to minimise what is captured and retained, and we do not build systems whose purpose is individual worker surveillance.
A large share of industrial vision requests involve people in frame — checking protective equipment is worn, detecting entry into a hazardous zone, monitoring for falls. These are legitimate safety applications and we build them, with specific constraints. Wherever the task allows, detection happens without identification: a system can confirm a helmet is present without knowing who is wearing it, and that design choice removes most of the privacy exposure at no cost to the safety outcome.
Retention is minimised — an event record and a short clip rather than continuous archived footage. Processing happens on site. Under India's DPDP Act, and under GDPR where European staff are involved, you need a lawful basis, notice to the people being recorded, purpose limitation and a defined retention period; workplace agreements and local law may add more. We will help you construct that, and we will build the technical controls that make the claims true rather than aspirational.
What we decline is individual worker productivity surveillance — systems whose purpose is to score named employees on pace or attention. Our objection is partly ethical and partly practical: these systems corrode trust on a floor, and a workforce that resents a camera finds ways to defeat it, so the data becomes unreliable as well as unpleasant. We say this at the start rather than after a scoping call, because it is a line rather than a negotiating position.
What you get
A paid, time-boxed evaluation using images captured at your site under real conditions, producing measured false-positive and false-negative rates, an imaging recommendation, and an honest read on whether the task is viable at your required accuracy.
Camera selection, lens and working distance, lighting design and enclosure, fixturing recommendations and mounting specification. This is usually where the largest accuracy gains come from and it is done before any model work begins.
Detection, classification, segmentation, counting, tracking or anomaly models trained on data collected across shifts, weeks and suppliers, reported as separate false-positive and false-negative rates with the confidence threshold set by your cost arithmetic.
Quantised models running on industrial PCs or embedded accelerators, integrated with your PLC, MES or WMS, with A/B partitioned updates, rollback on failed health checks and staged rollout across sites.
Local health summarisation, input-distribution drift detection to catch fogging lenses and changing materials early, a review queue for uncertain cases, and a retraining pipeline fed by human decisions on exactly the cases the model found hard.
How we work
Three to four weeks capturing images at your site under actual conditions and measuring what is achievable. We quote a build only after this, and a recommendation that the task is not viable at your required accuracy is a legitimate and reasonably common outcome.
Lighting, fixturing, camera selection and mounting before any model work. Controlling the conditions typically removes more error than model improvements can, and it removes it permanently rather than probabilistically.
Model development with data collected across the real variation, then an explicit conversation about what each error type costs you. The threshold is a business decision and we will not set it unilaterally.
The system runs alongside existing inspection without acting, so its decisions can be compared against reality for a few weeks. Only then does it gate anything. Drift monitoring and the retraining loop are live from the first day of shadow running.
Every phase ends at a decision point you can stop at — see how that works across fixed-scope projects, embedded pods and retainers.
Stack
Questions
We will not answer that before assessing your images, because published figures on public datasets say nothing about your parts under your lighting. After a three to four week feasibility assessment we report measured false-positive and false-negative rates separately, since those two errors almost never cost you the same.
It varies enormously with the task. Anomaly detection on a consistent product can work from a few hundred normal images and very few defects. A multi-class detector across varied products needs thousands, spread across shifts, suppliers and lighting conditions. The feasibility assessment tells you which situation you are in.
Yes, and that is our default for industrial deployments. Inference runs on site for latency, bandwidth and privacy reasons. The system summarises its own health locally and reports upward when a connection is available, so monitoring does not depend on continuous connectivity.
The model degrades, usually gradually, which is why input-distribution drift detection matters more than most teams expect. The retraining loop is built in from the start: uncertain cases go to human review, those decisions become training data, and the model is updated on a schedule you control.
Yes, and we build it to detect without identifying wherever the task allows — confirming a helmet is present does not require knowing who is wearing it. Event records and short clips rather than continuous footage, processed on site, with a documented lawful basis and defined retention under the DPDP Act.
No. Systems whose purpose is scoring named employees on pace or attention are outside what we take on. Beyond the ethical objection, they corrode trust on a floor and a workforce that resents a camera finds ways to defeat it, which makes the data unreliable as well.
Questions about cost, timelines, IP ownership and data residency are answered on the general FAQ, and how this practice came out of blockchain infrastructure explains why we build the way we do.
Related
ROS, SLAM, sensor fusion and fleet management. Software, not hardware.
Custom LMS and adaptive learning platforms that scale past the off-the-shelf ceiling.
AI-powered web applications: streaming interfaces, in-app retrieval, cost control and evals in CI.
See also: put perception on a moving platform with robotics software development · connect inspection results into operations with AI workflow automation · handle the image and event pipeline with data engineering for AI
Tell us what you are trying to build. We will tell you honestly whether we are the right team for it, and what it would realistically take.
