# Camera planning guide for video analytics Ayonix Video Analytics · Version 1.0 · Reviewed 11 September 2026 Author: Gabriel Bamola, Chief Marketing Officer · Technical review: Dr Sadi Vural, Founder and CEO --- ## Why this guide exists Most video analytics deployments that disappoint do so for a reason that was visible before anything was purchased: the cameras could not support the rule they were asked to carry. Software configuration cannot recover pixels that were never captured. This guide is a method for establishing, per camera, whether a given analytic is achievable from that view — before a rollout is committed to. ## 1. Pixel on target decides more than anything else The single strongest predictor of whether a people- or vehicle-based analytic will work is how many pixels the object occupies at the furthest point where the rule must operate. **Target:** a person occupying at least 8–10% of frame height at the furthest point of interest, for classification-based rules. **How to measure it, rather than estimate it:** 1. Have someone stand at the furthest point where detection must work. 2. Capture a frame from the actual stream the analytics will consume — not the live view in a client, which may be a different stream. 3. Measure the person's height in pixels and divide by the frame height. 4. Record the result against that camera. A camera rendering a person at 4% of frame height at the required range will not support reliable people-based rules, regardless of configuration. That is a camera decision, not a software one. ## 2. Viewing angle | Analytic type | Preferred angle | Why | | ------------------ | ------------------------------------------------------------ | ------------------------------------------------------------------------------------ | | Doorway counting | Overhead or steeply angled | People occlude each other at shallow angles, and that is the dominant counting error | | Queue measurement | Elevated, covering the full queue extent | A view sized for the typical queue fails at the peak, which is when it matters | | Heatmap | High and close to vertical | Perspective distortion over-weights the foreground | | Perimeter | 15°–45° downward | Enough depth separation without collapsing distant objects | | Density estimation | Elevated over the whole region | A near-horizontal view cannot separate depth and over-estimates density | | ANPR | Shallow angle to the plate, both horizontally and vertically | Large angles distort characters and reading collapses | ## 3. Frame rate and stream settings Verify what the stream _delivers_, not what the camera is _configured_ for. - **10–15 fps minimum** for tracking-based rules; higher where objects move fast. - **Keyframe interval** short enough that decoding recovers quickly after packet loss. - **Bitrate** high enough that motion does not dissolve into compression artefacts — aggressive bitrate limiting destroys exactly the detail analytics depends on. - **Secondary streams** are often too low-resolution for rules that need pixel-on-target at range. Check rather than assume. ## 4. Lighting Assess the **worst** realistic condition, not the best. A threshold tuned on a sunny afternoon will fail on the first wet night. - Is there usable illumination or IR at the full required range, at night? - Does a bright window, sky or glazed frontage silhouette the foreground? - Do vehicle headlights bloom across the frame? - Does lighting change substantially across the hours the rule is active? ## 5. Mounting stability A camera that moves produces apparent motion across the entire frame and is a leading cause of nuisance events. - Check behaviour in wind, particularly on masts and poles. - Check for vibration from passing plant, doors or machinery. - After any camera is moved, every rule depending on its geometry must be re-verified. ## 6. Lens and housing condition Mundane and frequently decisive. - Spiders and webs across the lens - Condensation inside the housing - Dirt, salt or agricultural spray on the dome - Focus drift — verify sharpness at the working distance rather than assuming it ## 7. Per-camera assessment sheet Record one row per camera. The outcome column is the deliverable. | Field | Value | | -------------------------------------- | -------------------------- | | Camera ID and location | | | Intended analytic(s) | | | Furthest point of interest | | | Measured pixel-on-target at that point | | | Mounting height | | | Downward angle | | | Delivered frame rate (measured) | | | Resolution and codec | | | Worst-case lighting condition | | | Night illumination adequate at range? | | | Mounting stability | | | Occlusion sources | | | Lens/housing condition | | | **Outcome** | Pass / Re-aim / Unsuitable | | Remediation required | | ## 8. What to do with the results - **Pass** — proceed to rule configuration. - **Re-aim** — usually the cheapest intervention available. Re-aiming or a lens change resolves a large proportion of marginal cameras. - **Unsuitable** — do not configure a rule on it. A rule on an unsuitable camera produces noise that erodes operator trust in the whole system, including the cameras that work. Being told which cameras fail, before anything is signed, is the difference between a deployment that works and one that quietly disappoints. --- Questions: infojp@ayonix.com · https://videoanalytics.ayonix.com