Delta Filter¶

Class: DeltaFilterBlockV1

Source: inference.core.workflows.core_steps.flow_control.delta_filter.v1.DeltaFilterBlockV1

Trigger workflow execution only when an input value changes from its previous state, enabling change detection, avoiding redundant processing when values remain constant, and optimizing system efficiency by executing downstream steps only on state transitions.

How This Block Works¶

This block monitors a value and only continues workflow execution when that value changes compared to its previous state. The block:

Takes an image (for video metadata context) and a value to monitor as input
Extracts video metadata from the image to identify the video stream (video_identifier)
Retrieves the previously cached value for this video identifier from an internal cache
Compares the current input value against the cached previous value
If the value has changed (current value ≠ previous value):
Updates the cache with the new value for this video identifier
Continues execution to the specified next_steps blocks, allowing downstream processing
If the value has not changed (current value == previous value):
Terminates the current workflow branch, preventing redundant downstream execution
Returns flow control directives that either continue to next steps or terminate the branch

The block maintains separate cached values for each video stream (identified by video_identifier), allowing it to track value changes independently across multiple video sources. This per-video tracking ensures that the filter resets appropriately when switching between different video streams. The block supports monitoring any value type (numbers, strings, detection counts, etc.), making it versatile for detecting changes in counters, metrics, detection results, or any other workflow data. By only triggering downstream blocks when values actually change, the Delta Filter prevents unnecessary processing when values remain constant, which is especially useful in video workflows where many frames may have the same detection count or metric value.

Common Use Cases¶

Change Detection for Counters: Trigger actions only when counter values change (e.g., execute data logging when line counter count_in changes from 5 to 6, skip processing when count remains at 6), avoiding redundant writes or updates when values are stable
State Transition Monitoring: Detect transitions in system states or detection results and trigger workflows only on state changes (e.g., execute notification when detection class changes from "empty" to "occupied", skip when state remains "occupied"), preventing repeated actions for the same state
Conditional Data Logging: Write to databases, CSV files, or external systems only when values change (e.g., log count changes to OPC or PLC systems, skip logging when counts are unchanged), reducing storage and network overhead
Event-Based Notifications: Send alerts or notifications only when values transition (e.g., trigger email notification when zone count changes, avoid spam when count remains constant), ensuring notifications represent meaningful changes rather than repeated states
Optimized Processing Pipelines: Reduce computational load in video workflows by skipping downstream processing when monitored values haven't changed (e.g., skip expensive analysis when detection count is unchanged across frames), improving overall workflow efficiency
Multi-Stream Change Tracking: Monitor value changes independently across multiple video streams (e.g., track zone counts separately for different camera feeds), with automatic per-video caching ensuring correct change detection for each stream

Connecting to Other Blocks¶

This block monitors values and controls workflow execution flow, and can be connected:

After counting or metric blocks (e.g., Line Counter, Time in Zone, Velocity, Detection Filter) to detect when counts, metrics, or aggregated values change and conditionally trigger downstream processing based on value transitions
After detection blocks (e.g., Object Detection, Classification, Keypoint Detection) to monitor detection results, class changes, or confidence metrics and execute actions only when detection outcomes change from previous frames
After data processing blocks (e.g., Property Definition, Expression, Delta Filter) to track computed values or processed metrics and trigger workflows only when these computed values transition, avoiding redundant processing
Before data storage blocks (e.g., Local File Sink, CSV Formatter, Roboflow Dataset Upload, Webhook Sink) to conditionally log or store data only when monitored values change, preventing duplicate entries or unnecessary writes when values remain constant
Before notification blocks (e.g., Email Notification, Slack Notification, Twilio SMS Notification) to trigger alerts only when meaningful changes occur (e.g., count changes, state transitions), avoiding notification spam when values are stable
In video processing workflows where per-frame values may remain constant for many frames, using the block to efficiently detect changes and trigger expensive downstream operations only when necessary, optimizing resource usage

Type identifier¶

Use the following identifier in step "type" field: roboflow_core/delta_filter@v1to add the block as as step in your workflow.

Properties¶

Name	Type	Description	Refs
`name`	`str`	Enter a unique identifier for this step..	❌

The Refs column marks possibility to parametrise the property with dynamic values available in workflow runtime. See Bindings for more info.

Available Connections¶

Compatible Blocks

Check what blocks you can connect to Delta Filter in version v1.

Input and Output Bindings¶

The available connections depend on its binding kinds. Check what binding kinds Delta Filter in version v1 has.

Bindings

input
- image (image): not available.
- value (*): Value to monitor for changes. Can be any data type (numbers, strings, detection counts, metrics, etc.) from workflow inputs or step outputs. The workflow branch continues to next_steps only when this value differs from the previously cached value for the current video stream. If the value remains the same, the branch terminates to avoid redundant processing. Example: Monitor a line counter count ($steps.line_counter.count_in) and trigger actions only when the count changes..
- next_steps (step): List of workflow steps to execute when the monitored value changes from its previous state. These steps receive control flow only when a change is detected, allowing conditional downstream processing. If the value hasn't changed, these steps will not execute as the branch terminates. Each step selector references a block in the workflow that should execute on value transitions..
output

Example JSON definition of step Delta Filter in version v1

{
    "name": "<your_step_name_here>",
    "type": "roboflow_core/delta_filter@v1",
    "image": "<block_does_not_provide_example>",
    "value": "$steps.line_counter.count_in",
    "next_steps": "$steps.write_to_csv"
}