Feature request: correlate motion contours with detected objects before triggering recordings

[quentinreytinas]

Hi,

I would like to suggest an improvement to how motion detection and object detection can be combined for event recording.

Current behavior:

I use MOG2 motion detection together with YOLO object detection, with scan_on_motion_only: true and require_motion: true on some object labels such as car.

This works well in principle, but there is one common false-positive case:

• moving tree shadows trigger MOG2 motion somewhere in the frame
• YOLO detects a parked car elsewhere in the frame
• since motion is currently detected globally, the parked car can trigger an event recording
• however, the car itself did not move

From what I understand, require_motion currently means “there is motion somewhere in the frame”, not “there is motion overlapping this detected object”.

Proposed improvement:

It would be very useful to have an option to require spatial correlation between the detected object and the motion detector result before starting an event recording.

For example, per label:

labels:
  - label: car
    trigger_event_recording: true
    require_motion: true
    require_motion_overlap: true
    motion_overlap_threshold: 0.1

Possible behavior:

compute the object bounding box
compute the MOG2/background-subtractor motion contours or bounding boxes
only allow the object to trigger recording if the object box overlaps a motion contour / motion bounding box
optionally allow a configurable margin around the object bbox
optionally expose an overlap threshold
This would help with parked cars, parked bikes, garden furniture, etc., where unrelated motion such as shadows, leaves, rain, or reflections should not validate a static object.

Why this matters
For outdoor cameras, motion caused by shadows or trees is very common. Masking is not always possible because the parked object can be in different places. Disabling the object label entirely is also not ideal, because moving cars should still be recorded.

A spatial “motion near/inside the object” condition would make require_motion much more useful for this type of setup.

Feature request: show live motion tuning values in the camera fine-tuning UI
It would also be very helpful if the camera fine-tuning page could show live motion detector debug values directly in the UI.

For example:

current max_area
configured area threshold
number of detected contours
largest contour bounding box
whether motion is currently considered active
maybe a small recent history graph
optionally an overlay of motion contours on the camera frame
This would make it much easier to tune area, threshold, history, and learning_rate without having to watch container logs.

Example useful debug output:

text

camera=driveway
motion=clear
max_area=0.00064
threshold=0.4
contours=1
largest_bbox=(0.897, 0.54, 0.937, 0.577)
Having these values visible directly in the fine-tuning camera window would make motion tuning much more practical, especially for outdoor cameras with changing light, shadows, rain, and vegetation.

Thanks for considering this.

[roflcoopter]

These are all great suggestions!

Stationary objects are a problem in Viseron for sure, and this would alleviate some of them, as well as improving the UX.
Object tracking could also be a way forward to reduce the problem of stationary objects.

Will consider this for implementation soon as i feel its a good improvement.

[john-]

It would be great if this can be decoupled from motion detection.

For object tracking, would the approach be to track the bounding boxes and associated classes and use that to determine whether something is stationary or moving? e.g. center of a "person" bounding box is not appreciably changing between detections therefore object is stationary?

[roflcoopter]

Yes exactly. Today the only way to tackle stationary objects is to use require_motion: true, but as outlined here that can cause false detections of lets say a car on a driveway when a tree triggers motion.

With object tracking we could determine that the car never left and not trigger a new recording, while using a lot less resources than pure object detection.

[mvanhorn]

Opened #1402 implementing this as a per-label require_motion_overlap option (with a configurable motion_overlap_threshold): an object only triggers/keeps a recording when its bounding box overlaps a motion contour, instead of motion existing anywhere in the frame. Defaults to off, so existing require_motion behavior is unchanged.