search

TinyShark / ALPR-Database

Fully-Featured Automated License Plate Recognition Database for Blue Iris + CodeProject AI Server
MIT License
0 stars 0 forks source link

Curious about your changes #1

Open algertc opened 2 days ago

algertc commented 2 days ago

Hi TinyShark,

I couldn't find your account on Ipcamtalk or reddit, so contacting you through an issue here :)

I was checking out your fork and saw all the websocket stuff. I'm curious what you're developing. Are you trying to get real-time data into another system? I'd be happy to help out if there's some functionality missing for you.

Are you familiar with Nextjs? I see you added a custom server setup and websocket in a client component - this will likely cause some headaches with Next.js's serverless architecture. All the server-side stuff was probably kind of overkill for this project - I definitely could have taken a more basic approach, but if you're coming from a different background, Next.js handles client/server stuff pretty differently and can be confusing. Websockets actually won't work here since there is no persistent connection.

It seems to me like you might be trying to do some automation with HomeAssistant? In this case, you could get everything you need with a single webhook that sends data to your HA and lets you control all the logic from HA itself, rather than having to change the code and redeploy every time you want to make a change. This is the standard solution for this use case and would save a ton of hassle while also majorly simplifying your HA setup and being much more reliable.

If not HomeAssistant (I'm very curious what it is if not - Please do share...), I would think that most automation platforms / apps you would want to use this data in would have some sort of webhook capability, but if you can't accept webhook requests for whatever reason, you will probably want to use NextJS server-side events which will let you push data from the ALPR database to your client system without having to expose an endpoint.

Let me know what you're trying to build - I'm curious about your use case and would be happy to lend a hand if you would like. I'm not personally a HA user, but I know how popular it is and would definitely be interested in improving support for external automation. Thanks for your interest in the project! :)

TinyShark commented 14 hours ago

Hi Algertc! I replied to you on ipcamtalk but didn't see this.

Completely new to next.js and only a small amount of html/css/js/python knowledge.

I was checking out your fork and saw all the websocket stuff. I'm curious what you're developing. Are you trying to get real-time data into another system? I'd be happy to help out if there's some functionality missing for you.

I was creating a websocket so that the 'Live Feed' page would update when a new plate was received via the API. So 'Live Feed' could be left open and new plates would be added to the table without having to refresh the page.

I did get it to work but there is perhaps a more elegant solution within Next.js that can be used for real-time front end. I will look into it.

It seems to me like you might be trying to do some automation with HomeAssistant? In this case, you could get everything you need with a single webhook that sends data to your HA and lets you control all the logic from HA itself, rather than having to change the code and redeploy every time you want to make a change. This is the standard solution for this use case and would save a ton of hassle while also majorly simplifying your HA setup and being much more reliable.

Yes using webhooks is probably the better solution. The reason why I initially thought of API endpoints is so that I could add/delete and modify known plates from home assistant. I am testing ALPR for gate entry, and would be good to manage the permitted/known plates from home assistant.

Having fuzzy search on known_plate queries was because I often get OCR misreads. Ideally I'd like to implement some normalisation/modification of plates for common misreads within the dashboard so that certain misreads would not be counted as unique plates. I see you added the edit button to correct the plate read which is cool and a much simpler solution. Perhaps we could define rules within the UI to do this automatically.

What I was thinking is a button to add known plates via ui (I already added that).

Then in the modal we can add actual known plate number. (PLATE NUMBER)

Then underneath add ‘common misreads’. Similar to how tags are done? Or multiple input boxes etc

All of which will be grouped and used as a single known plate and used for dasboardmetrics/notifications/webhooks.

all plates, misreads included, would still be added as normal to the db.

Quite a bit more complex but would think result in a cleaner experience in the UI. I will have a go at doing this.

algertc commented 12 hours ago

Getting the live feed page to auto-revalidate when plates are received is super easy; no need for any websockets. I can do it or show you if you like.

Yes using webhooks is probably the better solution. The reason why I initially thought of API endpoints is so that I could add/delete and modify known plates from home assistant

Are you wanting to do this automatically or something? What is the use case in where in HA would u plug them in? If it's a UI why not just use the iframe?

Having fuzzy search on known_plate queries was because I often get OCR misreads. Ideally I'd like to implement some normalisation/modification of plates for common misreads within the dashboard so that certain misreads would not be counted as unique plates. I see you added the edit button to correct the plate read which is cool and a much simpler solution. Perhaps we could define rules within the UI to do this automatically.

It would definitely be nice if it could accurately fix misreads. While enabling some sort of fuzzy matching or additional AI for checks against a small bunch of known plates (for automation for ex) could probably work decently well, getting misreads to not be counted as unique plates at all is quite a tricky task. Even if just for checking against known plates there's just so much potential for error.

For the gate access use case, I would think that getting misreads in the first place should be pretty easy to improve just with camera aim and settings. Narrow shooting lane/ choke point, slow speed, etc. You can also collect images to train a custom ALPR model with your own images on top of the base one right from the codeproject dashboard. This is probably a better solution, at least as a first step. I'm curious what your reads are looking like - if you don't mind sharing, maybe you could PM a few cam images on IPCT?

If the gate would have more than a handful of plates that are supposed to open it, like for non-home use, I would probably recommend additional computer vision that will compare the overall image with much better success and keeping recognition logic to its own system, as opposed to just checking the text with what is already imprecise by definition.

What I was thinking is a button to add known plates via ui (I already added that).

Do you mean like without reading it first? Yes this would be good.