Turn any fixed camera into a research and monitoring instrument, without writing code.

CV-Scope is open-source software for studies with fixed cameras. You draw gates, zones and routes over the picture; it tracks people and vehicles anonymously and records every crossing, visit and route choice as data you can check against the video and export.

Get started How it works Source

Counts

Routes	Route A 2 Route B 1
Entrance	forward 2 reverse 1
Exit Left	forward 4 reverse 0
Exit Right	forward 0 reverse 3
Centre floor	in 7 out 7 now 0

Events 27

00:02.3 Zone entry Centre floor #1
00:03.2 Crossing Entrance reverse #1
00:04.5 Zone exit Centre floor after 2.2 s #1
00:05.4 Crossing Exit Right reverse #1
00:05.4 Route Route B #1
00:16.1 Crossing Entrance forward #3
00:16.3 Zone entry Centre floor #3
00:16.4 Zone entry Centre floor #2
00:17.1 Zone exit Centre floor after 0.7 s #2
00:18.3 Zone exit Centre floor after 1.9 s #3
00:18.6 Crossing Exit Left forward #2
00:19.4 Crossing Exit Left forward #3
00:19.4 Route Route A #3
00:29.4 Zone entry Centre floor #6
00:29.8 Zone entry Centre floor #4
00:30.3 Zone entry Centre floor #5
00:30.8 Zone exit Centre floor after 0.5 s #5
00:31.0 Zone exit Centre floor after 1.3 s #4
00:31.8 Zone exit Centre floor after 2.4 s #6
00:32.2 Crossing Exit Left forward #4
00:32.3 Crossing Exit Right reverse #5
00:33.2 Crossing Exit Right reverse #6
00:43.8 Crossing Entrance forward #7
00:44.3 Zone entry Centre floor #7
00:45.3 Zone exit Centre floor after 0.9 s #7
00:45.8 Crossing Exit Left forward #7
00:45.8 Route Route A #7

A stored CV-Scope run, redrawn in the browser: 7 anonymous tracks and 27 events from YOLO11m on cuda:0 with ByteTrack (mean track life 59.6 frames), over the people-detection.mp4 sample clip (Intel IoT DevKit sample videos, CC BY 4.0). Trails are the ground points CV-Scope samples about ten times a second.

One study, from camera to evidence

Every step is a page of the application. The screenshots come from the repository and show the same corridor study as the replay above.

Step 1: Connect a camera or a video

Add a video file, a USB webcam or an RTSP or HTTP stream, with a connection test, rotation, crop and reconnection per camera. On first launch a setup wizard checks the machine and recommends a detector.

Cameras page with a video file registered as CAM-01, its snapshot, resolution, frame rate and connection settings — A camera can be a video file, a USB webcam or an RTSP or HTTP stream.

Step 2: Draw the scene

Put lines, gates, zones, routes, checkpoints, ignore areas and calibration points directly on the frame. Geometry is stored relative to the frame, and a scene version that a run has used is frozen, so earlier results keep their exact geometry.

Scene Builder with Entrance, Exit Left and Exit Right gates, a Centre floor zone and two routes drawn over a corridor video frame — The Scene Builder: gates, a zone and two routes drawn over the corridor sample clip.

Step 3: Configure the experiment

An experiment fixes the scene version, the objects to track, the detector, the tracker and the rules, with research and condition notes. Rules read like “when a person crosses Entrance, then crosses Exit Left within 20 s, record it as Route A”.

Experiment page with name, research notes, condition notes, camera, scene version, objects to track, detector, preset and tracker — An experiment pins the scene version, the objects, the detector, the tracker and the rules, with notes on its conditions.

Step 4: Run it

Each camera runs in its own worker process. Tracks, counters and events reach the browser over a WebSocket while the run is in progress; a recorded video is processed as fast as the machine allows.

Guide 19: Choose and benchmark the detector and tracker

Live page with one active run: detector, pipeline rate, progress, counters per gate and zone, and the newest stored events — The Live page: every running camera with its detector, pipeline rate, counters and newest events.

Step 5: Analyse

Route shares and decision times, crossings by direction and class, zone visits and occupancy, time series, heatmaps, and experiments compared side by side. The analysis pages describe observed movement and say so.

Run analysis summary: 27 events, 7 anonymous tracks, route distribution with Route A 66.7 percent and Route B 33.3 percent, and behavioural measurements — Run analysis: route distribution, decision time and the note that these are observed movements, not evidence of causes.

Step 6: Verify

Replay the run with its geometry and trajectories over the video. Mark events correct or wrong, log the ones it missed and enter manual counts: precision, recall and counting error come only from those verdicts.

Video review of run 1: two people in the corridor with their stored trajectories, the gates and zone drawn over the video and a list of 27 events — Video review: the recording with the scene, the stored trajectories and the events, each one a click away.

Step 7: Export

Filter every stored event and export it as CSV, JSON or Parquet, or send events to other systems as they happen, through webhooks and the REST API.

Data page with filters and a table of stored events: timestamp, media time, run, anonymous track, class, event, scene object, direction, route, duration, speed and confidence — Every stored event with its anonymous track id, filterable and exportable as CSV, JSON or Parquet.

Studies you can reproduce

Each example is drawn from a real run on public footage, with the scene and settings from the guides. The detector that produced it is named, so you can repeat the run and compare.

Route choice

Which way do people go after the entrance?

An entrance gate, two exit gates and two routes over a corridor. Every person who passes the entrance is recorded as one route, or as Unknown, Abandoned or Lost track.

Route A 2
Route B 1

3 people passed the entrance gate; 3 completed a route, with a mean decision time of 1.03 s.

Counting by class

How many people, bicycles and cars cross each line?

Two lines over a car park seen from above, tracking three classes at once. A cyclist counts as a person and as a bicycle, and the guide explains how to count them apart.

West edge 3 crossings

person 1

bicycle 0

car 2

East edge 5 crossings

person 3

bicycle 2

car 0

Occupancy and dwell

How long do people stay, and how many at once?

A zone over the corridor floor records entries, exits, visit lengths and how many people were inside at every moment.

0123

0 s10 s20 s30 s40 s

Centre floor: 7 completed visits, the longest 2.4 s, mean 1.4 s; at most 3 people inside at once; occupied for 7.4 s of the 49.7 s clip.

Across cameras

Where did a person go between cameras?

Eight synchronised cameras of the public MEVA dataset around a school building, placed on a site plan, with sightings joined into journeys and every move scored.

G300 North walkway
G419 Entrance stairs
G420 Entrance doors
G423 Upper hallway

Visitor A: 3 moves; the first confirmed by the door sensor. The identity comes from a reviewer’s annotation, not face recognition, and CV-Scope labels it that way.

All examples, including a junction turn-count setup

What it can do today

Grouped by the question you are asking. Each line is implemented in the current source; the links go to the documentation and to guides you can follow with the sample videos.

Design the study

A canvas editor over the camera picture instead of code.

Select, pan, line, gate, zone, route, checkpoint, ignore-area and calibration tools, with undo, redo, lock, hide and JSON import and export.
Scenes are versioned: once a run has used a version, saving creates the next one.
Calibrate with four ground points or one known distance to report metres instead of frame widths.

Observe movement

Detection and tracking turned into crossings, visits and routes.

Detectors from the YOLO11, YOLOv8 and RT-DETR families, torchvision models, or your own ONNX export.
ByteTrack by default; BoT-SORT with camera-motion compensation and optional appearance matching.
Crossings with direction, zone entries, exits, occupancy and dwell, and route outcomes, including Unknown, Abandoned and Lost track.

Ask more complex questions

Rules and relationships built from menus, with the evidence kept.

Sequence rules with time windows and “remains for” dwell rules, each able to record an event or call a webhook.
A relationship engine forms time-bounded facts such as approached, associated with or parked in, each with a confidence and its supporting observations.
Correlated events combine several facts; a language model never creates one.

Work across a site

Cameras placed in a location model, sightings joined into journeys.

A location tree of sites, buildings, floors and areas, with camera links, travel times and one-way passages; GPS is optional.
Moves between cameras are scored by identity, timing, topology and sensors, and shown as journeys, a time-aware graph and a site view.
Identity-based moves need a recognition module or a manual annotation; linking anonymous tracks by timing is opt-in and never above “possible”.

Measure rather than guess

Numbers come from your machine, your footage or your verdicts.

A local benchmark reports preprocessing, detector and tracker time, pipeline rate, memory and GPU memory.
Published mAP values are shown as upstream references only; no local speed appears before a benchmark.
Manual evaluation yields precision, recall and counting error from your verdicts; experiments can be compared after changing one condition.

Run on your hardware

CPU-only machines work; an NVIDIA GPU makes it faster.

Hardware discovery covers CPU, memory, GPU, VRAM, CUDA, ROCm, Apple silicon (Metal) and the installed inference runtimes.
Tiered recommendations (Fast, Balanced, High accuracy, CPU) are labelled estimates until a benchmark has run.
AUTO picks a runtime with a recorded fallback chain; a CUDA out-of-memory error falls back to the CPU for the rest of the run.

Inspect the data

Every result is a stored event you can filter, replay and export.

Events carry the run, anonymous track, class, scene object, direction, route, duration, speed and confidence.
Sampled trajectories drive heatmaps and the video review; storing them can be switched off.
Live cameras can record clips around events, whole visits or the whole run. Recording is off unless an experiment turns it on.

Extend and integrate

An API-first backend with small, documented interfaces.

The web interface runs on the same REST API and WebSockets you can call yourself; webhooks post the event record, never images.
The cvscope command line runs the server, migrations, hardware discovery, model installs and benchmarks.
New detectors, trackers and video sources plug in behind the Detector, Tracker and FrameSource interfaces.

Optional modules

Core, optional model

Anomaly Assistant

Learns the normal picture of a room, stall or vault and reports objects that appear, disappear or move, presence where an area should be empty, and a covered camera. Computer vision decides; a vision language model (local or a cloud provider you choose) may describe or confirm.

Licensed

Recognition modules

Face recognition of deliberately enrolled people and vehicle-plate reading, locked unless a signed licence is installed. Encrypted templates, roles and an audit trail; ordinary events carry only opaque ids.

Off by default

Video recording

An experiment can keep clips around events, one clip per visit, or the whole run of a live camera, with retention in days and optional overlays.

Where every number comes from

A result in CV-Scope has one of four origins, and the interface keeps them apart. A researcher should always be able to say which one produced a figure.

Measured

Every run

Detector, tracker, your scene geometry and the rule engine

Each count is a stored event: an anonymous track, a media time and the scene object or rule that produced it. The spatial and rule engines apply your geometry and rules the same way every time, and the video review shows each event where it happened.
Verified

When you review a run

Your verdicts on events, the missed events you log, your manual counts

Precision, recall and counting error are computed only from those verdicts. CV-Scope does not estimate accuracy; catalogue mAP values are the upstream projects’ published figures, shown for comparison.
Described

Optional

A vision language model, local or from a provider you choose

In the Anomaly Assistant a model can describe what computer vision found, or confirm it before it is raised in zones set that way. It finds nothing by itself, never creates a relationship or a number, and receives aliases, never names.
Identified

Licensed, locked by default

Face recognition of enrolled people, plate reading

Only with a signed licence. Ordinary events keep an opaque id; names and plates stay in separate, access-controlled tables. An identity entered by a reviewer is labelled as a manual annotation, never as recognition.

One stored event

Track 3 of the corridor run, as the API returns it (excerpt). It chose Route A at 19.42 s of the clip; the person before it had chosen Route B.

{
  "event_type": "route",
  "route": "Route A",
  "track_id": 3,
  "object_class": "person",
  "object_name": "Exit Left",
  "media_time_s": 19.42,
  "duration_s": 3.33,
  "avg_speed": 0.196,
  "speed_unit": "frame/s",
  "confidence": 0.89,
  "context": {
    "decision_time_s": 0.25,
    "previous_route": "Route B",
    "occupancy_at_decision": 0
  }
}

Speeds are in frame widths per second because this scene is not calibrated. With calibration they are metres per second, and the event says which.

Local first: Everything runs on your computer and binds to 127.0.0.1. Nothing leaves it unless you connect a cloud model provider yourself.
Anonymous tracks: Track ids restart in every run and cannot be linked across runs or cameras in the open-source core.
No video by default: Live frames are processed in memory and discarded. Recording happens only when an experiment turns it on.
Observations, not causes: Analysis pages describe what moved where. They say that correlations are not evidence of intent.
Labelled honestly: Estimates are marked as estimates, and anything not implemented is labelled in the interface instead of simulated.

What is stored, and for how long How the licensed modules are locked The Anomaly Assistant and its model providers

Not a detector with a user interface

Detection is one stage of seven. The value is in what happens after it: anonymous tracking, your geometry, a rule engine that never guesses a route, and data that analysis can only read. Switch to the engineering view to see the modules and process boundaries.

How a result is made Engineering view

1
Camera or video

A video file, USB webcam, or RTSP or HTTP stream.
2
Detection

A detector finds people, vehicles and other objects in each frame.
3
Tracking

Detections become anonymous tracks that restart with every run.
4
Your scene

Lines, gates, zones and routes turn movement into interactions.
5
Rules

Crossings, visits, dwell, routes and sequences are decided per track.
6
Events

One stored record per observation, with its track, time and rule.
7
Analysis

Summaries, video review, evaluation, exports and the API.

Worker process, one per running camera

Frame source
vision/sources/

Files, USB cameras and RTSP or HTTP streams behind a FrameSource interface, with reconnection.

Knows nothing about detection.
Preprocessing
vision/preprocessing.py

Rotation, crop, preview resizing and JPEG encoding for the browser.
Detector
vision/detectors/

Ultralytics, ONNX Runtime or torchvision provider, chosen with the hardware probe and a recorded fallback chain (vision/inference/).

Knows nothing about lines, zones or routes.
Tracker
vision/trackers/

ByteTrack or BoT-SORT: anonymous, session-scoped ids in tentative, tracked, lost and removed states.
Entity resolver Licensed
recognition/runtime.py

Only with a licence: says whether a track is an enrolled person or a registered plate. The core sees an interface, never recognition code.
Spatial engine
spatial/engine.py

Geometry only: crossings with direction, zone presence and dwell, sampled ground points, calibrated distances.

Does not decide what an interaction means.
Rule engine
rules/engine.py

Per-track state machines for lines, zones, route groups, sequences and dwell rules. A track without complete evidence is never forced into a route.
Relationship engine Optional
relationships/engine.py

Observations, time-bounded relationships and correlated events, each with a confidence and its evidence.

Imports no detector, tracker or recognition model.

API process

Supervisor and storage
storage/writer.py

Drains the worker queues and writes events, track summaries and trajectories in batches to SQLite or PostgreSQL; restarts crashed live workers.
Cross-camera correlation Optional
crosscam/

Joins identity sightings on different cameras into scored transitions, on a background thread.
Analytics and interfaces
analytics/

Analytics only read stored rows. The REST API, WebSockets, webhooks and the cvscope command line sit on top.

Never re-runs detection to answer a question.

Paths are relative to backend/pathscope/ and link to the synced commit. A GPU or decoder crash stays inside its worker process; the API keeps running.

Architecture in detail Developer guide Data model

Runs on the computer you have

On first launch CV-Scope inspects the CPU, memory, GPU and inference runtimes and recommends detectors for that machine. The recommendation is labelled an estimate until you benchmark on your own footage.

Detector	Device	Detector time per frame, median	p95	Tracker
YOLO11n	GPU (RTX 4070 SUPER)	7.1 ms	10.1 ms	0.11 ms
YOLO11m	GPU (RTX 4070 SUPER)	8.0 ms	10.4 ms	0.08 ms
YOLO11n	CPU (Intel i7-14700KF)	18.6 ms	27.2 ms	0.11 ms
YOLO11m	CPU (Intel i7-14700KF)	81.3 ms	101.3 ms	0.11 ms

Measured with cvscope benchmark <model> --device <device> --video samples/videos/people-detection.mp4 on 29 September 2026: Windows 11, Intel(R) Core(TM) i7-14700KF (20 cores / 28 threads), 31.8 GB, NVIDIA GeForce RTX 4070 SUPER (12.0 GB). 120 frames of the corridor sample at 640 px, ByteTrack. One machine, one clip: run the same command on yours before choosing a detector.

Hardware page listing the operating system, CPU, memory, an NVIDIA RTX 4070 SUPER, CUDA availability and recommended detectors per tier — Hardware discovery on the development machine. Recommendations are labelled as estimated from the hardware until a benchmark has run.

Model manager with the detector catalog: parameters, size, minimum VRAM, CPU and GPU suitability, reference mAP, licence and install state — The model manager. Reference mAP figures are the published upstream values; the licence of every model is shown.

Open source, and clear about licences

The code, the documentation and the guides are public. The documentation on this site is rendered from the repository at commit eaf904a, committed 30 September 2026.

ajm2004/CV-Scope

Every pull request passes a repository guard, the backend tests, the frontend checks and a dependency review, then a code owner’s review.

CV-Scope: Apache License 2.0.
Ultralytics detectors: YOLO11, YOLOv8 and RT-DETR code and weights are AGPL-3.0 and installed as an optional extra. Research and internal use are fine; distributing a product built on them needs AGPL compliance or a licence from Ultralytics.
torchvision detectors: BSD-3-Clause, usable without those obligations.
Recognition models: Listed with their own licences; two InsightFace models are for non-commercial research only.
Sample footage: Intel IoT DevKit sample videos and MEVA, both CC BY 4.0, credited where they appear.

Licence guidance in the documentation

Try it on the sample videos

The latest release is CV-Scope v0.1.0. Or run from the repository:

Linux and macOS Windows Docker

            
                git clone https://github.com/ajm2004/CV-Scope.git
                
              
                cd CV-Scope
                
              
                bash scripts/setup.sh
                # .venv, PyTorch, frontend, database, samples
              
                bash scripts/dev.sh
                # API and interface

Needs Python 3.11 or newer and Node 20 or newer; an NVIDIA GPU is optional. Then open http://localhost:5173: the first-run wizard checks the machine, recommends a detector and opens the Scene Builder.

            
                git clone https://github.com/ajm2004/CV-Scope.git
                
              
                cd CV-Scope
                
              
                powershell -ExecutionPolicy Bypass -File scripts\setup.ps1
                
              
                powershell -ExecutionPolicy Bypass -File scripts\dev.ps1

Needs Python 3.11 or newer, Node 20 or newer and Git. Then open http://localhost:5173.

            
                docker compose up
                # CPU image
              
                docker compose --profile gpu up cvscope-gpu
                # NVIDIA image; needs the NVIDIA Container Toolkit

Run from a clone of the repository, then open http://localhost:8420. Data lives in the cvscope-data volume.

Install and downloadRequirements, platforms and releases
Your first experimentA route-choice study step by step
GuidesFrom a first count to a full study