Full ALPR Database System for Blue Iris!

[algertc]

Rules engine preview.

This has the added benefit that the flagged feature might actually become useful with this.

Take these conditions with a grain of salt. Not done. The times seen (24h) one, for ex, will be more granular. Open to any suggestions though.

 

[VideoDad]

Rules engine preview.

View attachment 240445View attachment 240446

This has the added benefit that the flagged feature might actually become useful with this.

Take these conditions with a grain of salt. Not done. The times seen (24h) one, for ex, will be more granular. Open to any suggestions though.

This looks pretty neat and can't wait (I mean I can wait, but I don't want to).

Is this in the new architecture application you're working on? I'm also hoping there will be a way to run both the old and new versions concurrently (I assume with separate databases and separate ports but hopefully identical calls), at least until we've assured feature parity, plus it would probably help with debugging while keeping the production system going in the meantime.

Edit: I imagine the flagging or tagging feature could be useful for finding items to be reviewed.

 

[algertc]

@VideoDad Glad to hear it - I was thinking about you when I posted that haha.

Yes, it will all be part of the same update. You could always make a copy of your directory and then spin up a duplicate on another port to run the upgrade on.

I have both my database dump as well as some from others that I haven’t gotten to yet (thanks all for sending). There are a bunch of tests for almost every functionality now that will run every time an update is made to try to ensure that everything functions as it should.

I’d be surprised if any of the existing features stopped working properly. The main thing that is slightly iffy is the whole database migration. My tests will ensure that it succeeds on all the dumps I have, but since people have run some commands altering their databases, I can’t be completely positive it will work without issue. That being said, I did add a check first to verify that your current schema is as the code expects and can take the migration. If for some reason it were different and couldn’t upgrade, it should just tell you it can’t do it. It won’t try anyways and then break it.

Another note about this automation functionality - I still don’t love the “redirect”/rewrite to correct plate functionality that several requested, but since it’s an easy thing to add here now, I will add an edit plate number action to the automations. I like this because it doesn’t require me to explicitly build in and support that workaround, but still offers a solution for those who wanted it. If you now want to create an “automation” on your system that happens to try to correct misreads automatically, nothing will stop you from doing that.


I’m still not finished. Didn’t make as much progress as I wanted yesterday. Claude Opus has been really hit or miss for me lately. One day it works incredibly well - the next it’s like it’s a completely different model. All with the same prompts.

Ended up having to do a lot of the automations stuff manually because of this, so I didn’t get to much else.

The outstanding items as of now that I still want to add are the following:

• Stolen car check
• Decide how to do the embeddings for semantic search
• Backfilling detections from blue iris for new installs
• Back up/export data
• Add that crazy data table I shared before as an advanced mode to allow for a more “power user” level viewing and search for the live feed.
• A system monitoring page. My BI randomly dies every once in a while and it often takes me a bit to notice. I want to add simple health checks for BI and CPAI so that I can get a notification if they ever go down. Additionally this page will show load stats for the computer as well as graph the inference time for the AI to show if performance starts degrading or other trends.

Should be a nice big update for the first time in a while. I’ve built up a pretty horrendous track record for time estimates here, but just bear with me while I find time for this please


Any other suggestions welcome

 

[VideoDad]

@VideoDad Glad to hear it - I was thinking about you when I posted that haha.

Yes, it will all be part of the same update. You could always make a copy of your directory and then spin up a duplicate on another port to run the upgrade on.

I have both my database dump as well as some from others that I haven’t gotten to yet (thanks all for sending). There are a bunch of tests for almost every functionality now that will run every time an update is made to try to ensure that everything functions as it should.

I’d be surprised if any of the existing features stopped working properly. The main thing that is slightly iffy is the whole database migration. My tests will ensure that it succeeds on all the dumps I have, but since people have run some commands altering their databases, I can’t be completely positive it will work without issue. That being said, I did add a check first to verify that your current schema is as the code expects and can take the migration. If for some reason it were different and couldn’t upgrade, it should just tell you it can’t do it. It won’t try anyways and then break it.

Another note about this automation functionality - I still don’t love the “redirect”/rewrite to correct plate functionality that several requested, but since it’s an easy thing to add here now, I will add an edit plate number action to the automations. I like this because it doesn’t require me to explicitly build in and support that workaround, but still offers a solution for those who wanted it. If you now want to create an “automation” on your system that happens to try to correct misreads automatically, nothing will stop you from doing that.


I’m still not finished. Didn’t make as much progress as I wanted yesterday. Claude Opus has been really hit or miss for me lately. One day it works incredibly well - the next it’s like it’s a completely different model. All with the same prompts.

Ended up having to do a lot of the automations stuff manually because of this, so I didn’t get to much else.

The outstanding items as of now that I still want to add are the following:

• Stolen car check
• Decide how to do the embeddings for semantic search
• Backfilling detections from blue iris for new installs
• Back up/export data
• Add that crazy data table I shared before as an advanced mode to allow for a more “power user” level viewing and search for the live feed.
• A system monitoring page. My BI randomly dies every once in a while and it often takes me a bit to notice. I want to add simple health checks for BI and CPAI so that I can get a notification if they ever go down. Additionally this page will show load stats for the computer as well as graph the inference time for the AI to show if performance starts degrading or other trends.

Should be a nice big update for the first time in a while. I’ve built up a pretty horrendous track record for time estimates here, but just bear with me while I find time for this please


Any other suggestions welcome

I really hope you'll reconsider and add a table of common misreads to each known plate and add the ability to autocorrect the plates.

The main use case I have is not an error with the recognition. I have few neighbors who have license plate frames that cover the bottom of the letters. Think E looking like F, or I looking like T. The front plates do not have this issue because the frame isn't there or is smaller. So when the front-facing camera captures the plate it sees the correct letter (E or I) but the rear-facing camera sees F or T. No amount of tweaking the OCR algorithm would fix this 100%

When manually correcting the plate (constantly) it would be really nice to be able to have the option to add the bad detection to the misread table. Then when the misread plate is detected in the future, it is autocorrected. People that don't want this feature could just not add it to the misread plate table.

Alternatively, if you want to require it be done via rules, it would be really nice if the ability to create such an "autocorrect rule" could still be an option we could choose during manual correction (just like the choices for correcting all plates and deleting the plate). So instead of it being a table of misreads tied the correct plate, it would be an autogenerated rule.

I'm just saying this autocorrect is a feature that multiple people have requested to save a lot of regular manual correction. Anything that could eliminate that tedium would be a welcome feature.

I still think the misread table would be an easier, cleaner implementation but I could live with the rule implementation as long it could be (optionally) created during the manual correction.

Think about it...

 

[PeteJ]

I really hope you'll reconsider and add a table of common misreads to each known plate and add the ability to autocorrect the plates.

The main use case I have is not an error with the recognition. I have few neighbors who have license plate frames that cover the bottom of the letters. Think E looking like F, or I looking like T. The front plates do not have this issue because the frame isn't there or is smaller. So when the front-facing camera captures the plate it sees the correct letter (E or I) but the rear-facing camera sees F or T. No amount of tweaking the OCR algorithm would fix this 100%

When manually correcting the plate (constantly) it would be really nice to be able to have the option to add the bad detection to the misread table. Then when the misread plate is detected in the future, it is autocorrected. People that don't want this feature could just not add it to the misread plate table.

Alternatively, if you want to require it be done via rules, it would be really nice if the ability to create such an "autocorrect rule" could still be an option we could choose during manual correction (just like the choices for correcting all plates and deleting the plate). So instead of it being a table of misreads tied the correct plate, it would be an autogenerated rule.

I'm just saying this autocorrect is a feature that multiple people have requested to save a lot of regular manual correction. Anything that could eliminate that tedium would be a welcome feature.

I still think the misread table would be an easier, cleaner implementation but I could live with the rule implementation as long it could be (optionally) created during the manual correction.

Think about it...

I think you and I have the same kind of neighbors. Mine also likes to go skiing and never wash their truck's plate. I would also love to have this feature, for the same reasons.

 

[th182]

I concur that using an automation would work for correcting so long as there is there is an easy way to create one during the correct plate process. One of the neighbors has a hitch ball that obstructs a letter on the rear plate but is not an issue on the front. So auto correcting that rear plate would be helpful!

Would it also be beneficial to somehow flag auto-corrected plates? That way when looking at the live feed you know that one was corrected for the rare case that an auto-correct might be wrong?

It would also be beneficial to list multiple plates for one vehicle so all those reads show under stats as one “plate” metric. New cars in my state get a temp plate for up to 45 days before their true plate is issued. And every 10 years or so the state issues a new plate for the vehicle that has a different alphanumeric.

As it is now, once a cars permanent plate is issued, I either have to live with it being in the database two ways, or go in and correct the temp tag to the new plate. Or I’ll see a new car frequenting our street only to figure out one of the neighbors just got new plates.

Just spitting out ideas to see the groups thoughts!


Sent from my iPhone using Tapatalk

 

[VideoDad]

One thing you could do is to find one instance of the old (retired) plate in the plates read table and treat it as a correction to the new plate. Toggle the setting for doing all plate reads and they'll now all point to the new plate.

So if it was 7OLD777 and is now 8NEW888, then all the previous reads would become 8NEW888. The total counts and last seen, etc. should be consolidated under the new plate.

 

[prsmith777]

I really hope you'll reconsider and add a table of common misreads to each known plate and add the ability to autocorrect the plates.

The main use case I have is not an error with the recognition. I have few neighbors who have license plate frames that cover the bottom of the letters. Think E looking like F, or I looking like T. The front plates do not have this issue because the frame isn't there or is smaller. So when the front-facing camera captures the plate it sees the correct letter (E or I) but the rear-facing camera sees F or T. No amount of tweaking the OCR algorithm would fix this 100%

When manually correcting the plate (constantly) it would be really nice to be able to have the option to add the bad detection to the misread table. Then when the misread plate is detected in the future, it is autocorrected. People that don't want this feature could just not add it to the misread plate table.

Alternatively, if you want to require it be done via rules, it would be really nice if the ability to create such an "autocorrect rule" could still be an option we could choose during manual correction (just like the choices for correcting all plates and deleting the plate). So instead of it being a table of misreads tied the correct plate, it would be an autogenerated rule.

I'm just saying this autocorrect is a feature that multiple people have requested to save a lot of regular manual correction. Anything that could eliminate that tedium would be a welcome feature.

I still think the misread table would be an easier, cleaner implementation but I could live with the rule implementation as long it could be (optionally) created during the manual correction.

Think about it...

I also would like to request this.

 

[th182]

One thing you could do is to find one instance of the old (retired) plate in the plates read table and treat it as a correction to the new plate. Toggle the setting for doing all plate reads and they'll now all point to the new plate.

So if it was 7OLD777 and is now 8NEW888, then all the previous reads would become 8NEW888. The total counts and last seen, etc. should be consolidated under the new plate.

This is how I’ve done it a few times now. Feels “wrong” when looking at an entry under the old plate and seeing the new plate listed although I know why I changed it. I figured someone smarter than I might have an idea for an official functionality for this


Sent from my iPhone using Tapatalk