Bird Regional Exclusions & False Positive Management

[josefdlange]

There must be a database, somewhere, that indicates known geographic range for certain species. Consequently, it may be possible to use the current location coordinates to automatically generate an exclusion list of species that are not expected to be found at the given location. This would combat some false positives!

Speaking of false positives, it would be nice to have a button somewhere on a recording entry's UI (where you see the spectrogram and identification name etc) to indicate "This is a false positive". I often get Common Loons that are, in fact police sirens. While political opinions on police being loons may or may not be valid, this bird identification is not.

[mcguirepr89]

There must be a database, somewhere, that indicates known geographic range for certain species. Consequently, it may be possible to use the current location coordinates to automatically generate an exclusion list of species that are not expected to be found at the given location. This would combat some false positives!

Hi, @josefdlange thanks for those thoughts -- there have been many discussions (as well as one open issue) for just this. You might be able to start tinkering with this idea using the tool from the new model's repo, species.py command to perform the inverse of your suggestion.

Speaking of false positives, it would be nice to have a button somewhere on a recording entry's UI (where you see the spectrogram and identification name etc) to indicate "This is a false positive". I often get Common Loons that are, in fact police sirens. While political opinions on police being loons may or may not be valid, this bird identification is not.

This is actively in development for BirdNET-Pi and can be tested out on my system for now: https://virginia.birdnetpi.com -- go to the "Species Stats" and once you select a specific species, you'll be able to annotate individual detections as true or false positives and commit that information to the database. There are still some UI features that need to be put together for this tool and new data field to be more usable and available in other parts of the UI.

If you're interested in helping with that development, you're welcome to check out that branch and get started with these commands:

update_birdnet.sh -b verification

My best,
Patrick

[ehpersonal38]

I've been leveraging species.py from BirdNET-Analyzer on my own machine. My setup was something like:

1. git clone https://github.com/kahst/BirdNET-Analyzer
2. Edit BirdNET-Analyzer/species.py

Add to the imports:
import datetime
Then at the top of the script, underneath the imports:
dayofweek = datetime.datetime.today().isocalendar()[1]

Then go down to each parser.add_argument line. Change:
--o's default to: default='/home/pi/BirdNET-Pi/include_species_list.txt'
--lat/--lon's default to: your lat and lon
--week's default to: default=dayofweek

3. Put this in crontab, change your BirdNET-Analyzer path to the correct one

1 * * * 1  /home/pi/BirdNET-Pi/birdnet/bin/python3 /home/pi/BirdNET-Pi/BIRDNET_ANALYZER/BirdNET-Analyzer/species.py

Viola. Your BirdNET-Pi's include_species_list.txt will automatically be updated from the new model's geographical data. This means that your BirdNET-Pi analysis will only detect these species. Let me know if you have any questions.

[josefdlange]

Sorry I missed the open issue and discussions in question -- I did a cursory search but perhaps it's difficult to narrow search terms that find what I was looking for.

I will investigate generating the species list as recommended by both you @mcguirepr89 and @ehpersonal38 -- great ideas. Might throw together a small script to merge the output of the species.py output with any existing lines in the file, if the command does not by default append-only. @mcguirepr89 for my understanding, is there a vision of BirdNET-Analyzer already included in the BirdNET-Pi installation, and @ehpersonal38 is just cloning a newer version, or is it typically not present within the BirdNET-Pi installation?

I'm thinking of how to compose a button inside settings that on-demand (instead of in cron) does what @ehpersonal38 is doing -- I'd be excited and happy to offer a Pull Request to that end if the pieces are there or can be assembled in some future version.

I will also look at the verification branch and see how I might get some UX updates in. It's summertime so there's a lot of outdoors hobby stuff I'm involved with, but as fall and winter approach I'll need more indoor hobbies to spend time on 😄

[ehpersonal38]

Might throw together a small script to merge the output of the species.py output with any existing lines in the file

You can change the 'w' to an 'a' in this line to append:
with open(cfg.OUTPUT_PATH, 'w') as f:

It will get pretty messy though if you don't delete duplicates.

I'm thinking of how to compose a button inside settings that on-demand (instead of in cron)

Yeah you could do something with php to shell_exec() the species.py like how I do in the cron - I don't think this would be something we'd want to implement in a PR though, because:

1. The BirdNET-Analyzer library is several hundred MBs and isn't included by default with BirdNET-Pi
2. Once BirdNET-Pi switches over to the new model in a few months/years we'll have this entire functionality by default.

[DougWelch]

Folks, I'd like to suggest an alternative to false positive identifications. Rather than addressing them on a detection by detection basis - what about a list of frequent "distractors" for identified species? Many of us have found that sirens trigger Eastern Screech Owl detections. Here are some others that I have noted: 3 kHz backup alarm -> Northern Saw-whet Owl Coyotes -> Red-throated or Common Loon Cicadas -> Worm-eating Warbler People -> Yellow-breasted Chat Dog barks -> Barred Owl Chipmunks -> Crossbills Children playing -> Trumpeter or Tundra Swan ... Each person/site could maintain an optional list of their own common "distractors" and optionally choose to have that displayed as a subtitle of spectrograms. Consequently, no detection-by-detection table column would be needed. Cheers, Doug

…

On 6/13/22 14:24, ehpersonal38 wrote: Might throw together a small script to merge the output of the species.py output with any existing lines in the file You can change the 'w' to an 'a' in this line to append: |with open(cfg.OUTPUT_PATH, 'w') as f:| It will get pretty messy though if you don't delete duplicates. I'm thinking of how to compose a button inside settings that on-demand (instead of in cron) Yeah you could do something with php to |shell_exec()| the species.py like how I do in the cron - I don't think this would be something we'd want to implement in a PR though, because: 1. The BirdNET-Analyzer library is several hundred MBs and isn't included by default with BirdNET-Pi 2. Once BirdNET-Pi switches over to the new model in a few months/years we'll have this entire functionality by default. — Reply to this email directly, view it on GitHub <#374 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYGKVU5NUGZVMQ3BDBV3ADVO54F5ANCNFSM5YU6HAWA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mcguirepr89]

Hi, Doug -- I appreciate your thoughtfulness around this, though one of the main reasons to have verification per-detection is that this would allow us to use the data for retraining especially against high-scoring false positives and low-scoring true positives. I wanted you to have more insight into the reason this change is designed the way it is.

[DougWelch]

Hi Patrick, Like many incredibly useful creations - there will be different use cases for BirdNET-Pi. Yes - for users wanting to provide feedback to improve the model, per-detection correction is the way to go. I suspect that BirdNET-Pi will attract a significant population of users/installers whose intentions are "in the present" and are keen for their installations to not be misleading repeatedly when displaying detections. Public outreach uses fall in this category. My comment was to just suggest an option for that community of users. Cheers, Doug

…

On 6/13/22 18:20, Patrick McGuire wrote: Hi, Doug -- I appreciate your thoughtfulness around this, though one of the main reasons to have verification per-detection is that this would allow us to use the data for retraining especially against high-scoring false positives and low-scoring true positives. I wanted you to have more insight into the reason this change is designed the way it is. — Reply to this email directly, view it on GitHub <#374 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAYGKVT7PQ3SLC54K2Z3BFDVO6X2HANCNFSM5YU6HAWA>. You are receiving this because you commented.Message ID: ***@***.***>