Paarvai Systems is an independent engineering practice for teams building cameras that see. We work on both halves of the problem — the optics, sensor and image pipeline that produce the pixels, and the vision models that have to make sense of them on device.
Independent · Founder-led · On site and remote
We work as an engineering consultant to product teams — embedded in your programme for a defined scope, or on a retainer through a build. The hardware and the product stay yours.
Early-stage feasibility for a new device: what the scene actually demands, what a given sensor and lens can deliver, where the compute and power budget lands, and which requirements are going to fight each other.
Shortlisting and bench-testing sensor and lens candidates against your real use case rather than a datasheet — resolution and MTF, low-light behaviour, rolling shutter, field of view, distortion and mounting tolerance.
ISP tuning end to end — black level, demosaic, denoise, sharpening, tone curve, colour matrix, auto exposure and white balance — tuned for how the image will actually be judged, by a viewer or by a model.
Detection, tracking, segmentation and pose models chosen, trained and evaluated on footage from your own camera in your own conditions — because a model that scores well on a public benchmark often does not survive your sensor.
The application layer around the model: capture-to-display pipeline, auto-framing and subject-following behaviour, multi-model scheduling, and the latency, memory and thermal budget it all has to live inside.
Repeatable image-quality measurement so you can tell whether a change helped — chart and lighting setup, scripted capture, scored metrics, and written acceptance criteria your team keeps and runs without us.
Silicon choice belongs to the product, not to habit. We work across both mainstream edge AI stacks — NVIDIA's Jetson and CUDA tooling, and Intel's Core Ultra and OpenVINO — and where the decision is still open, we run the same pipeline on both before it gets locked in.
| Devices | Jetson AGX Thor and the Jetson Orin family |
|---|---|
| Desk-side | DGX Spark and RTX workstations for training and evaluation |
| Runtime | CUDA, TensorRT, DeepStream |
| Camera in | MIPI CSI multi-camera, on-SoC ISP |
| Suits | Highest on-device throughput, several models at once, mature vision tooling |
| Devices | Core Ultra processors for the edge — CPU, Arc integrated GPU and NPU on one part |
|---|---|
| Desk-side | Same x86 target as the device, so there is no separate porting step |
| Runtime | OpenVINO toolkit, Open Edge Platform |
| Camera in | USB video class, GigE Vision, MIPI |
| Suits | Lower power and bill of materials, simpler thermals, standard x86 tooling |
Choosing between the two is a real engineering decision, not a preference: throughput, power envelope, unit cost, thermal design and how much of your team already knows the toolchain all pull in different directions. Where a programme has not yet committed, we benchmark your model and your pipeline on both and put the numbers in front of you. We also work with conventional embedded Linux, USB video class and GigE Vision camera stacks where a project calls for it.
The order matters more than it looks. Tuning an image pipeline before the sensor and lens are settled, or training a model before there is representative footage, is how camera programmes lose months.
What the camera has to see, in what light, at what distance and frame rate — written down as measurable targets alongside the power, thermal and cost constraints.
Sensor and lens candidates on the bench under controlled lighting, with reference footage captured from each so decisions rest on your own images.
ISP tuning and model development run together against that footage, so image-quality choices are judged by what they do to detection accuracy, not only by eye.
Ported to the target board and measured where it counts — end-to-end latency, sustained frame rate, memory headroom, power draw and thermal behaviour over a long run.
A repeatable test rig, scored acceptance criteria, tuning parameters and written rationale — so your team can carry the work forward without us.
Camera teams usually have one or the other. The failures we get called in for almost always live in the gap between them — a model blamed for a problem that started at the sensor, or an image tuned beautifully for a human eye and badly for a network.
A background spanning neural-engine engineering at an AI startup and professional motion-picture camera systems. Optics and inference are not two vendors here; they are one conversation.
Every claim is tested against images from your camera in your conditions. Public benchmark numbers are a starting point, never the evidence.
If the sensor cannot deliver what the feature needs, you hear it in week one rather than after tape-out. An honest no is the cheapest deliverable we have.
No reseller margin, no sensor or module supplier relationships to protect. The recommendation is the one the measurements support.
Test rigs, capture scripts and scoring are handed over as part of the work, so image quality stays a number your team can track instead of an argument.
The person who scopes the work is the person who does it. Small by design, which means a limited number of engagements at a time and full attention on each.
Hardware startups and product groups where the camera is the product, or close to it — typically at the point where a prototype has to become something manufacturable that behaves consistently.
பார்வை — paarvai — means sight, or vision.
The name is literal. The practice exists because two fields that ought to be one have drifted apart: the people who know how a photograph is made, and the people who know how a network reads one. A cinema camera department spends its life on exposure, colour and what a lens does to a face. A machine-learning team spends its life on architectures, data and loss curves. When a product needs both, the seam between them is where the schedule goes.
Paarvai Systems is a sole proprietorship based in Tamil Nadu, India, founded in 2026 and drawing on a background spanning neural-engine engineering at an AI startup and professional motion-picture camera systems. We work with product teams as an engineering consultant — the hardware, the IP and the roadmap remain theirs.
Current work is on edge AI camera devices across the NVIDIA and Intel edge platforms. If you are early enough that the sensor and the silicon are not yet chosen, that is the best time to talk.
Tell us what the camera has to do and what is currently in the way. You will get an honest read on feasibility and on what it would take — including if the answer is that you do not need us.