Blue Iris and CodeProject.AI ALPR
- Thread starter MikeLud1
- Start date
You might need to post your issue on CodeProject.AI forum. I do not use Linux and Chris for CodeProject.AI worked on support for Linux. I am not sure if he had GPU working in Linux, maybe that is why he had it disabled. Sorry I could not help.
CodeProject.AI Discussions - CodeProject
www.codeproject.com
You might need to post your issue on CodeProject.AI forum. I do not use Linux and Chris for CodeProject.AI worked on support for Linux. I am not sure if he had GPU working in Linux, maybe that is why he had it disabled. Sorry I could not help.
CodeProject.AI Discussions - CodeProject
Thank you for the effort. I’ll try over there.
I just installed a GeForce GTX 1650 graphics card on my Blue Iris server, the latest NVidia drivers, CUDA 12.3.2, CUDNN 9.0.0, and then I uninstalled, wiped, and reinstalled CodeProject.AI (version 2.6.5) and the ALPR module.
All of the modules are now using the GPU. However, I have a problem with the ALPR module. Whenever Blue Iris sends data to ALPR, OR whenever I upload an image for analysis through the CPAI Explorer, ALPR crashes and restarts:
(As you can see, Object Detection works with the GPU just fine.)
When I disable GPU for ALPR, it works just fine. But when GPU is enabled, it crashes consistently without being able to complete a single analysis.
Any ideas?
All of the modules are now using the GPU. However, I have a problem with the ALPR module. Whenever Blue Iris sends data to ALPR, OR whenever I upload an image for analysis through the CPAI Explorer, ALPR crashes and restarts:
(As you can see, Object Detection works with the GPU just fine.)
When I disable GPU for ALPR, it works just fine. But when GPU is enabled, it crashes consistently without being able to complete a single analysis.
Any ideas?
Last edited:
It could be because your GPU is old and you are using CUDA 12.3.2. Try using CUDA 11.8 and cuDNN for CUDA 11.x
Yes, because the modules need to be configured for the new CUDA version.
This is normal, I use the Object Detection module to find the license plate in the image
Thanks!
With the GPU, the times have gotten shorter but I'm still seeing multi-second analysis roundtrip times. Is this normal? Here's one example:
Code:
[
{
"api":"alpr",
"found":{
"success":true,
"processMs":668,
"inferenceMs":598,
"predictions":[
{
"confidence":0.97005695104599,
"label":"Plate: 9EVG363",
"plate":"9EVG363",
"x_min":58,
"y_min":75,
"x_max":186,
"y_max":159}
]
,
"message":"Found Plate: 9EVG363",
"moduleId":"ALPR",
"moduleName":"License Plate Reader",
"code":200,
"command":"alpr",
"requestId":"e980fd40-3b35-49a5-b813-f4c497043a99",
"inferenceDevice":"GPU",
"analysisRoundTripMs":3304,
"processedBy":"localhost",
"timestampUTC":"Sun,
03 Mar 2024 19:35:06 GMT"}
}
]
The reason you might be seeing slow times is maybe other cameras are using AI at the same time. Try running the below test to see what times you are getting.
Is anyone aware of a way to control the degree of parallelism when running with BlueIris? Does anyone know what the default is? In searching the codeproject.com forums, I found reference to the "parallelism" setting through the API, so I looked in the appsettings.json, but didn’t see anything with a default value.
I am asking because I have several CPU cores on my computer and although I'm using my GPU with DirectML for the object detection, the alpr module is using the CPU. The "Benchmark" explorer with CodeProject only lets me pick modules OTHER than alpr to test, but please tell me if there is a way to similarly benchmark the alpr. I’m curious to see how well it scales and if I can make better use of the CPU that I do have, in part to decide whether it’s acceptable to have BlueIris test more images at 100ms intervals versus fewer images at 200ms intervals.
I am asking because I have several CPU cores on my computer and although I'm using my GPU with DirectML for the object detection, the alpr module is using the CPU. The "Benchmark" explorer with CodeProject only lets me pick modules OTHER than alpr to test, but please tell me if there is a way to similarly benchmark the alpr. I’m curious to see how well it scales and if I can make better use of the CPU that I do have, in part to decide whether it’s acceptable to have BlueIris test more images at 100ms intervals versus fewer images at 200ms intervals.
The speed looks on the slow side, what speed were you getting with just CPU. You may also want to try Object Detection (YOLOv5 .NET) module instead of the Object Detection (YOLOv5 6.2) module. The Object Detection (YOLOv5 .NET) module will also use your Nvidia GPU.
Hi Mike, I ran the same picture through ALPR CPU and GPU, as well as ALPR GPU + YOLOv5 .NET. Each configuration was exercised 5 times, and here are the average times in MS:
| CPU | GPU | GPU + YOLOv5 .NET | |
| Roundtrip | 905 | 696 | 675 |
| Processing | 508 | 312 | 320 |
| Inference | 411 | 224 | 238 |
Now, times are much higher in Blue Iris .dat files, especially roundtrip times. Is this because multiple frames are analyzed in parallel?
Last edited:
Here's a possible Blue Iris/ALPR bug:
Blue iris records the first captured number, but in this case, the whole plate has NOT yet come into the picture. As a result, the captured plate number is wrong:
In fact, there's another "1" at the end of the plate.
I can tune Blue Iris, but the fact is that cars come and go at various speeds and it's hard to get a setting that works optimally in all scenarios.
Blue iris records the first captured number, but in this case, the whole plate has NOT yet come into the picture. As a result, the captured plate number is wrong:
In fact, there's another "1" at the end of the plate.
I can tune Blue Iris, but the fact is that cars come and go at various speeds and it's hard to get a setting that works optimally in all scenarios.
Last edited:
What you can try is a zone crossing so the camera triggers when the vehicle is in the middle of the FOV.
I just learned something that I haven't seen shared before, so in an attempt to be proactively constructive . . .
For anyone doing ALPR at night, especially with a cloned camera, check your camera's watchdog settings and make sure you have unchecked the "Interpret monochrome video as a loss of signal."
As everyone here should know, at night your image is going to be almost entirely black whenever you don't have a vehicle in the image. Recently Blue Iris was improved such that the all-black (monochrome) video was showing up as signal loss events. When this happens on the "clone master", the problem propagates to the cloned camera as well. Blue Iris will eventually recover the signal, but will then lose it again. Fortunately I defined "Status alerts" to email me errors from my BI logs. If you are not getting alerts from your logs, you likely wouldn't even realize this is happening, but you may be missing a lot of events.
In the course of trying to debug this, I also learned that the bitrate of your alpr camera at night drops significantly (by 10-100x to 5-15kB/s) because the video compression works REALLY well when almost every pixel is black. That makes sense, but at first I thought I really did lose the signal, but I was just seeing great compression.
For anyone doing ALPR at night, especially with a cloned camera, check your camera's watchdog settings and make sure you have unchecked the "Interpret monochrome video as a loss of signal."
As everyone here should know, at night your image is going to be almost entirely black whenever you don't have a vehicle in the image. Recently Blue Iris was improved such that the all-black (monochrome) video was showing up as signal loss events. When this happens on the "clone master", the problem propagates to the cloned camera as well. Blue Iris will eventually recover the signal, but will then lose it again. Fortunately I defined "Status alerts" to email me errors from my BI logs. If you are not getting alerts from your logs, you likely wouldn't even realize this is happening, but you may be missing a lot of events.
In the course of trying to debug this, I also learned that the bitrate of your alpr camera at night drops significantly (by 10-100x to 5-15kB/s) because the video compression works REALLY well when almost every pixel is black. That makes sense, but at first I thought I really did lose the signal, but I was just seeing great compression.