[Detector Support]: Since update to version 0.13 Beta 1 seeing person everywhere

[madasus]

Describe the problem you are having

Since upgrading to version 0.13 Beta 1 many of my cameras are identifying the person object all over the place. Updates that in the previous version did not trigger an object detection are now triggering the person object over and over.

I've started to mask those areas of the cameras to prevent this but some of the items are moveable (like a cat toy it thinks is a person now). Do you have any suggestions for the best way to start to reduce these false positives?

Version

0.13.0 Beta 1

Frigate config file

database:
  path: /db/frigate.db

mqtt:
  host: 10.2.1.171
  user: mqtt
  password: XXX

ffmpeg:
#  hwaccel_args: -c:v h264_qsv
#  hwaccel_args: preset-intel-qsv-h264
  hwaccel_args: preset-vaapi

logger:
  # Optional: default log level (default: shown below)
  default: warning
  # Optional: module by module log level configuration
  logs:
    frigate.mqtt: error

detectors:
  coral:
    type: edgetpu
    device: usb

detect:
  max_disappeared: 500
  width: 1280
  # Optional: height of the frame for the input with the detect role (default: shown below)
  height: 720

timestamp_style:
  # Optional: Position of the timestamp (default: shown below)
  #           "tl" (top left), "tr" (top right), "bl" (bottom left), "br" (bottom right)
  position: "tl"
  # Optional: Format specifier conform to the Python package "datetime" (default: shown below)
  #           Additional Examples:
  #             german: "%d.%m.%Y %H:%M:%S"
  format: "%m/%d/%Y %H:%M:%S"
  # Optional: Color of font
  color:
    # All Required when color is specified (default: shown below)
    red: 255
    green: 255
    blue: 255
  # Optional: Line thickness of font (default: shown below)
  thickness: 1
  # Optional: Effect of lettering (default: shown below)
  #           None (No effect),
  #           "solid" (solid background in inverse color of font)
  #           "shadow" (shadow for font)
  effect: solid


birdseye:
  # Optional: Enable birdseye view (default: shown below)
  enabled: True
  # Optional: Width of the output resolution (default: shown below)
  width: 1280
  # Optional: Height of the output resolution (default: shown below)
  height: 720
  # Optional: Encoding quality of the mpeg1 feed (default: shown below)
  # 1 is the highest quality, and 31 is the lowest. Lower quality feeds utilize less CPU resources.
  quality: 8
  # Optional: Mode of the view. Available options are: objects, motion, and continuous
  #   objects - cameras are included if they have had a tracked object within the last 30 seconds
  #   motion - cameras are included if motion was detected in the last 30 seconds
  #   continuous - all cameras are included always
  mode: objects
  restream: true

objects:
  track:
    - person
    - cat


record:
  enabled: True
  events:
    retain:
      default: 10
      mode: active_objects
    pre_capture: 5
    post_capture: 15
    
  sync_on_startup: True
  expire_interval: 60

# Optional: Configuration for the jpg snapshots written to the clips directory for each event
# NOTE: Can be overridden at the camera level
snapshots:
  # Optional: Enable writing jpg snapshot to /media/frigate/clips (default: shown below)
  enabled: True
  # Optional: save a clean PNG copy of the snapshot image (default: shown below)
  clean_copy: True
  # Optional: print a timestamp on the snapshots (default: shown below)
  timestamp: False
  # Optional: draw bounding box on the snapshots (default: shown below)
  bounding_box: False
  # Optional: crop the snapshot (default: shown below)
  crop: False
  # Optional: height to resize the snapshot to (default: original size)
  height: 175
  # Optional: Restrict snapshots to objects that entered any of the listed zones (default: no required zones)
  required_zones: []
  # Optional: Camera override for retention settings (default: global values)
  retain:
    # Required: Default retention days (default: shown below)
    default: 10
    # Optional: Per object retention days
    objects:
      person: 15
  # Optional: quality of the encoded jpeg, 0-100 (default: shown below)
  quality: 70


ui:
  # Optional: Set the default live mode for cameras in the UI (default: shown below)
  live_mode: mse
  # Optional: Set a timezone to use in the UI (default: use browser local time)
  # timezone: America/Denver
  # Optional: Use an experimental recordings / camera view UI (default: shown below)
  use_experimental: False
  # Optional: Set the time format used.
  # Options are browser, 12hour, or 24hour (default: shown below)
  time_format: 12hour
  # Optional: Set the date style for a specified length.
  # Options are: full, long, medium, short
  # Examples:
  #    short: 2/11/23
  #    medium: Feb 11, 2023
  #    full: Saturday, February 11, 2023
  # (default: shown below).
  date_style: full
  # Optional: Set the time style for a specified length.
  # Options are: full, long, medium, short
  # Examples:
  #    short: 8:14 PM
  #    medium: 8:15:22 PM
  #    full: 8:15:22 PM Mountain Standard Time
  # (default: shown below).
  time_style: medium
  # Optional: Ability to manually override the date / time styling to use strftime format
  # https://www.gnu.org/software/libc/manual/html_node/Formatting-Calendar-Time.html
  # possible values are shown above (default: not set)
  strftime_fmt: "%Y/%m/%d %H:%M"

telemetry:
  # Optional: Enabled network interfaces for bandwidth stats monitoring (default: shown below)
  #network_interfaces:
  #  - eth
  #  - enp
  #  - eno
  #  - ens
  #  - wl
  #  - lo
  # Optional: Configure system stats
  stats:
    # Enable AMD GPU stats (default: shown below)
   # amd_gpu_stats: True
    # Enable Intel GPU stats (default: shown below)
    intel_gpu_stats: True
    # Enable network bandwidth stats monitoring for camera ffmpeg processes, go2rtc, and object detectors. (default: shown below)
    network_bandwidth: False
  # Optional: Enable the latest version outbound check (default: shown below)
  # NOTE: If you use the HomeAssistant integration, disabling this will prevent it from reporting new versions
  version_check: True

cameras:
#EXAMPLE CAMERA WITH MASK ADDED

  ch-garage: # <------ Name the camera
    ffmpeg:
      inputs:
        - path: rtsp://xxx:554/cam/realmonitor?channel=1&subtype=0 # <----- Update for your camera
          roles:
            - detect
    detect:
      enabled: True
    record:
      enabled: True
    objects:
      filters:
        person:
          mask:
            - 1280,720,629,720,842,503,969,336,1045,48,1280,46
      track:
        - person

docker-compose file or Docker CLI command

N/A

Relevant log output

None

Operating system

Other Linux

Install method

Docker Compose

Coral version

USB

Any other information that may be helpful

No response

[NickM-27]

There have been 0 changes to the model that would make things be detected as a false positive that weren't before.

Most likely this is a case of the default motion settings just being overly sensitive for your camera and you should tune them.

[madasus]

so getting the motion: xx to a lower setting will also reduce the detection of false positive objects?

can you confirm what the default motion value is in the latest beta?

"Default values have been changed for motion detection. If you have specific values set in your config, it is recommended to remove them and re-calibrate as necessary."

[NickM-27]

I don't know what you mean by default motion value. There are multiple settings for motion detection outlined in https://deploy-preview-6262--frigate-docs.netlify.app/configuration/

Suggestion would be to watch the debug live view with object and motion boxes enabled and adjust settings as needed.

[NickM-27]

You can follow #7850

[madasus]

"I don't know what you mean by default motion value"

I was looking to try and see what changed in the defaults from the previous version to the new version.

just to confirm my understanding. Even though I am talking about object detection here the motion detection sensitivity is still relevant correct? (i.e. it uses the motion first to determine that there is an object to identify)

[NickM-27]

yes, it uses motion to know where to look for objects. So if motion detection is overly sensitive then frigate will look for objects more often which can lead to false positives.

[madasus]

i'll have to keep fiddling - i moved the motion universally up to 50 (from 30) but still seeing some whacky person identifications that i wasn't seeing in the previous version

[NickM-27]

do you have an example of a person detection like that?

[madasus]

That is a person detection

[NickM-27]

seems like in that case a min_area filter should be used

[madasus]

in this part of the config for example?

objects:
  # Optional: list of objects to track from labelmap.txt (default: shown below)
  track:
    - person
  # Optional: mask to prevent all object types from being detected in certain areas (default: no mask)
  # Checks based on the bottom center of the bounding box of the object.
  # NOTE: This mask is COMBINED with the object type specific mask below
  mask: 0,0,1000,0,1000,200,0,200
  # Optional: filters to reduce false positives for specific object types
  filters:
    person:
      # Optional: minimum width*height of the bounding box for the detected object (default: 0)
      min_area: 5000

[NickM-27]

you'd likely want to do it for that particular camera only

[madasus]

ok - i'll have to play with the settings per camera and report back. I'm seeing similar false alerts on about half of my cameras which prompted the question of what might have changed between 0.12 and 0.13. I didn't see many false positives previously.

[RiderCrazy]

Hi
Same problem here since 0.13 beta 1 update. I've got this specific event once or twice every night.

[NickM-27]

Looks like the exact same advice above would apply

[robbo600]

I'm also experiencing this in previously masked locations, looks like something might have changed with the mask behavior?

Specific config below:

side:
ffmpeg:
inputs:
- path: rtsp://127.0.0.1:8554/side
input_args: preset-rtsp-restream
roles:
- record
- path: rtsp://127.0.0.1:8554/side-sub
input_args: preset-rtsp-restream
roles:
- detect
objects:
track:
- person
filters:
person:
mask:
- 1280,0,1280,720,1025,720,803,345,651,63,633,0

[NickM-27]

You aren't setting the detect resolution, and that has changed to now automatically detect your cameras resolution. You either need to redo your zones or you need to manually set the detect resolution to

detect:
  width: 1280
  height: 720

[madasus]

I created new masks (after i changed the detect resolution) but i'm still seeing false positives. i'll continue to tweak them to see if i can resolve. To confirm i'm doing this right - here is an example camera with a mask

  frontdoor:
    ffmpeg:
      inputs:
        - path: xxx
          roles:
            - detect
    detect:
      enabled: True
    record:
      enabled: True
    objects:
      filters:
        person:
          mask:
          - 914,345,696,344,681,0,911,0
      track:
        - person
        - cat
        - dog
        - car
        - bear

[NickM-27]

I think there is some confusion here, my previous reply was in response to the other user

[madasus]

Agreed - but it sounds like we might be experiencing a similar issue with false positives since the upgrade

I set the detect resolution globally

detect:
  max_disappeared: 500
  width: 1280
  # Optional: height of the frame for the input with the detect role (default: shown below)
  height: 720

[NickM-27]

Agreed - but it sounds like we might be experiencing a similar issue with false positives since the upgrade

right but look at the above screenshot, the mask is now outside the frame of the camera because the detect resolution was not being set. So they are entirely different circumstances

[madasus]

was confusing @robbo600 with @RiderCrazy

Agree Robbo has a different error. RiderCrazy appears to be seeing a similar increase in false positives to me.

[TimelessNL]

seems like in that case a min_area filter should be used

Is that really the solution? As the size of that bounding box could also be the size of a person that is walking on the grass (front yard) using the min_area filter like that would probably filter those as well.
I've also upgraded to 0.13 beta 1 last weekend and also noticed my false positive rate went up quite significantly, from <5 false positives a day to more than 40 on one camera. And that's how I found this discussion.

I will try #7850 to see if that may improve the situation. Are these settings new or have they been changed?

[madasus]

I have been gradually reducing the settings and then just letting it sit for a few hours - so far i haven't seen a major difference.

[benklop]

I have also seen a dramatic uptick in false positives on my interior and exterior cameras - both in objects being detected as persons that simply aren't (a plastic bag, a lamp shade, a series of lights on the neighbor's house), but also misidentification of my cat or dog as a person frequently.

Previous on 0.12 I had very few false positives.

I have not yet had the opportunity to try adjusting settings as suggested, but I will give it a try this weekend.

[NickM-27]

There were no changes to the models used, the only change in this area of detection is the minimum size of the region sent to object detection was reduced in hopes of making detection of smaller / further away objects better.

It seems the default models have a greatly increased false positive rate due to this so I have put up #7883 to revert this change

[madasus]

what would be the appropriate setting to put in the config to revert this back to the previous setting from 0.12 until the next version is released?

[NickM-27]

there is none, this is not configurable behavior

[madasus]

ah - thanks. Will watch for the next release.

[NickM-27]

anyone seeing this issue and running docker can change the docker image to ghcr.io/blakeblackshear/frigate:dev-c743dfd and run the latest which has reverted the change I mentioned

[madasus]

I just deployed - will report back if i am still having issues. Thanks

[NickM-27]

closing this as users have confirmed elsewhere that this has been reduced. Feel free to create a new issue if something else comes up

[shikharshrivastav1]

@NickM-27 Is this change present in 0.13.2 ? Or which version do I update to? thanks