Capture only the images you need

Cameras produce more frames than most applications need, and most consecutive frames are nearly identical. Instead of capturing every frame and sorting through them later, you can have the machine decide which frames are worth keeping. Frames that don’t match are never written to disk, so they cost no storage, bandwidth, or cloud storage.

The filtered-camera registry module does this by running an ML vision model on each frame and gating capture on the result. It wraps an existing camera and a vision service so data capture sees a pre-filtered stream.

If the module doesn’t fit your needs, you can build a custom filter module instead. For other ways to reduce how much your machine captures and syncs, see Capture and sync overview.

How it works

The filtered camera sits between a raw camera and the data manager:

1. A raw camera component (for example, a USB webcam) provides the image stream.
2. A vision service runs an ML classifier or detector against each image and returns classifications or detections with confidence scores.
3. A filtered-camera component wraps the camera and the vision service. It continuously pulls frames from the camera into an in-memory ring buffer, asks the vision service to score each frame, and marks a frame as “interesting” when a classification or detection passes a confidence threshold you configure.
4. Data capture is configured on the filtered-camera component, not on the raw camera. Because the filtered camera is itself a camera component, the data manager captures from it the same way it would from any other camera. Only frames that passed the filter are ever written to disk.
5. The normal sync pipeline uploads the captured files to the cloud.

The raw camera’s image stream is unchanged: the CONTROL tab, other services, and anything else on the machine still see every frame. Only the filtered camera, and therefore only data capture, sees the filtered subset.

Optionally, you can configure a pre-trigger buffer with window_seconds_before and a post-trigger buffer with window_seconds_after. When a frame triggers the filter, the module includes the buffered frames from those windows alongside the trigger frame. Use this when you need context leading up to or after an event.

Prerequisites

• A configured camera component on your machine. See Configure a camera if you need to set one up.
• The data management service configured. See Start data capture for instructions.

Use a filtered camera

{
  "camera": "camera-1",
  "vision_services": [
    {
      "vision": "vision-1",
      "objects": {
        "Person": 0.8
      }
    }
  ],
  "window_seconds_before": 0,
  "window_seconds_after": 0
}

Advanced: build a custom filter module

For filtering needs that go beyond what the filtered-camera module provides, you can write your own module. Common examples:

• A sensor wrapper that only reports readings above a threshold (for example, temperature above 50 degrees C)
• A camera filter with custom logic specific to your application
• A filter that combines data from multiple sensors before deciding what to capture

The pattern is: write a module that wraps an existing component, evaluates its data against your criteria, and only returns data worth capturing. Configure data capture on the wrapper component instead of the raw component.

See Write a module for the general module development guide. The key technique is accessing the source component through the dependencies parameter in your module’s constructor.

Troubleshooting

What’s next

• Capture on demand: start and stop capture on several components at once. You can list a filtered camera as one of its resources.
• Query data: write SQL and MQL queries against your filtered data.
• Create a dataset: use filtered captures to build cleaner training datasets for ML models.