Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow min/max area filters to be configurable based on location #2330

Open
fl42 opened this issue Nov 26, 2021 · 12 comments
Open

Allow min/max area filters to be configurable based on location #2330

fl42 opened this issue Nov 26, 2021 · 12 comments
Labels
enhancement New feature or request pinned

Comments

@fl42
Copy link

fl42 commented Nov 26, 2021

Describe the problem you are having

Hello,

I'm trying to filter out false positives using min_area/max_area.
However the numerical values of min_area/max_area depend if the person is near or away from the camera.
Therefore I'm using zones:

zones:
      near:
        coordinates: ...
        filters:
          person:
            min_area: 90000
            max_area: 400000
        away:
          coordinates: ...
          filters:
            person:
              max_area: 130000

This works as expected (#1738)

However I'm still receiving events for detection labeled as person without any zone on MQTT events topic.
I may filter them out using Home Assistant (i.e., ensuring that there is a zone), but this adds increased complexity (cameras with zones, cameras without zone, etc.)

I'm already using the required_zones parameter:

record:
      enabled: true
      retain_days: 0
      events:
        objects:
          - person
        required_zones:
          - near
          - away
mqtt:
      required_zones:
        - near
        - away

IMO using required_zones in mqtt should prevent any MQTT message (including events) if the detection is not in the required_zones.
What is your opinion?
Is there another way to achieve the same goal?

Thanks for your hard work for this project!

Version

0.10.0-c1155af

Frigate config file

See relevant parts above

Relevant log output

N/A

FFprobe output from your camera

N/A

Frigate stats

N/A

Operating system

Other Linux

Install method

Docker Compose

Coral version

PCIe

Network connection

Wired

Camera make and model

N/A

Any other information that may be helpful

No response

@blakeblackshear
Copy link
Owner

The required zones under mqtt only prevent the snapshot topics from being published for the event.

@ozett
Copy link

ozett commented Nov 26, 2021

setting min/max 1) at cam 2) at zone and 3) at object
would be nice ..

😄 #2282 because an elephant is bigger than a mouse,
but as same as small when the elephant is far away
and this mouse sits directly before the cam .. 😄

@fl42
Copy link
Author

fl42 commented Nov 26, 2021

You can already define a min/max by cam/zone/label
But the issue (well this is a feature at the moment) is that events are still published (they are not considered as detection false positives but as zone false positives)
The purpose of min_area/max_area is to detect false positive, isn't it? Then why publishing events that don't match this criteria?
EDIT: the workaround is to create at least one zone per camera (even if the zone is the whole image) then filter out events without zone, but this is not straightforward

@blakeblackshear
Copy link
Owner

Zone filters restrict when a zone is listed for an event and don't impact whether or not the object is considered a false positive. Object filters (camera level) will filter out objects as false positives for the camera.

If you have 3 zones defined and they are all listed as required zones for snapshots and record, the events that don't enter any of the zones are just discarded at the end because it doesn't have any of the required zones, not because it is considered a false positive. Frigate still detects it and tracks it actively as a true positive until the event is over.

Zones aren't meant to be used as a tool to identify false positives. They are a tool to determine when an object has entered an area of interest.

I'm not suggesting this is as clear as it should be. Just explaining how it works today.

@blakeblackshear
Copy link
Owner

Whether or not an object is a false positive is not based on a single frame. It's a computed value based on the median of the last 10 scores as it is being tracked. Once it crosses the threshold, it is considered a true positive no matter where it goes. In this paradigm, you can't simply look at a single frame where the object is in a zone. There does need to be a way to adjust object filters based on the position of the object, but that's totally different than what the current zone filters are meant for. Long term, I hope to be able to infer appropriate sizes based on past detections.

@fl42
Copy link
Author

fl42 commented Nov 26, 2021

Thanks for the explanation
Then the question is: how to filter false positives using min_area/max_area considering that the size of the objects depends on their distance from the camera?

Maybe there is no solution at the moment, in which case what would be the best solution in your opinion? I can try to implement it.

@fl42
Copy link
Author

fl42 commented Nov 26, 2021

It's a computed value based on the median of the last 10 scores as it is being tracked

This is a good way to reduce FP. But I still have FP and min_area/max_area look quite effective to filter out them
But I got the point, zones were not designed for that

@blakeblackshear
Copy link
Owner

The best workaround at the moment is to define zones with filters and then ensure they are all listed in required_zones. This won't have any impact on the events mqtt topic, so you will have to use a condition to check for at least one zone in entered_zones.

@blakeblackshear
Copy link
Owner

The object filters are incorporated into the processing pipeline much further upstream during object detection. This is where you would want to filter false positives based on location and size, but it has no awareness of zones at that stage. Zone filters are applied to much later in processing.

@blakeblackshear blakeblackshear pinned this issue Nov 26, 2021
@blakeblackshear blakeblackshear added enhancement New feature or request pinned and removed support triage labels Nov 26, 2021
@blakeblackshear blakeblackshear changed the title [Support]: Simplify false positive filtering using min_area/max_area by zones Allow min/max area filters to be configurable based on location Nov 26, 2021
@blakeblackshear blakeblackshear unpinned this issue Nov 26, 2021
@ozett
Copy link

ozett commented Nov 27, 2021

feels like still i good enhancement if it would be possible
to define min/max as a general default for every object-kategorie.

a min/max definition would improve the reliability of the inference results of a certain AI model used, if one could exclude false-detected objecttypes through human correction basically illogical sizes of certain objectstypes.

of course best on camera level, because these have specific resolutions = frame sizes.

If one could use this filtering mechanism via min/max-definitions also on a later stage.
deeper within the usual zones, one could catch also further some few special FP in some concrete zone situations.

As a first start, a basic human definition of logical min/max values per object would help to exclude false positives due to illogical sizes for small objects (and vice versa).

(an AI model with image segmentation would also help. probably not due to TF-Lite, but one could define min/max areas for specific contours and object shapes. Maybe an idea for a distant future of frigate...)

@blakeblackshear
Copy link
Owner

You already can define min/max values per object type for each camera.

@ozett
Copy link

ozett commented Nov 27, 2021

You already can define min/max values per object type for each camera.

sure, you're right. i had overlooked that not quite in mind anymore, although i use that of course.

my original problem with the false positives still persists, like with the thread-starter, that to minimize fPs for the same object type in the foreground and in the background of the same camera, i need two different size definitions.

i could maybe use two zones for that, but that's not really what they are for and it wouldn't be the way designed for this problem, i guess .... 💁‍♂️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pinned
Projects
None yet
Development

No branches or pull requests

3 participants