Openalpr: C# binding stops recognizing plates

[jovargas]

Hi @matthill !!

As described in #349 I'm facing something similar when using C# bindings and I'm opening this issue because the author closed it without clarifying the source of the problem.

The library works fine for a while, but after several recognitions the response from OpenALPR is zero plates found, even when there is a valid plate on sent image. It only works again if I restart the application.

No exception is thrown, no memory leak takes place (checked with .NetProfiler) and there is no program crash. Just happens that no more plates are recognized by OpenALPR.

Versions 2.3.0 and 2.4.0 were used and the problem is present with both.

So, assuming there is no error in OpenALPR native instance, is there any known bad practice in programming that could lead to that problem?

Any clue about it?

Thanks!!

[jovargas]

The followings are debug snapshots taken at working and not working moments.
The method in focus is AlprResponse Recognize(System.Drawing.Image image) wich is inside Alpr.cs file from the new C# binding.

This one was taken at the moment of successful recognition. In the watcher we can see that the image size in json string matches the sent image as well as the clone sizes

Now in this one, that it was taken at the unsuccessful recognition, it is clear that the image size in json string doesn't match the sent image size and there are no valid results.

What about the openalpr_recognize_rawimage method at line 199?? I mean, if the compiler gets to that line, that means the native instance is loaded and initialized, right?

What could be happening that leads the native code to return an "empty" result?

UPDATE
There is one more detail:
Everytime the problem starts (always indeed), the epoch time in json string is 9713958912, wich corresponds to Sun, 28 Oct 2277 01:55:12 GMT and that's probably because the results object at the line 101 in alpr_c.cpp (std::string json_string = alpr::Alpr::toJson(results);) is empty and the results.epoch_time was loaded with "dirt".

The reasons to have an empty AlprResults object is a thrown exception when manipulating cv::Mat in alpr_impl.cpp at one of the AlprImpl::recognize overloads:

But the problem source still unknown and now I also got OpenCV as suspected.

This is very frustrating since there's no way to debug unmanaged resources from C#.
I will really appreciate any suggestion.

[matthill]

That is interesting. You've confirmed that OpenCV is throwing an exception and we're returning the empty results? After running another image through OpenALPR it fails? I would not expect subsequent OpenALPR recognition attempts to be impacted by a caught exception from a previous request.

Is it possible to write your image to disk on the failure cases so you can confirm it is a valid image? I'm wondering if whatever process you are using to pull the images starts sending bad image data to the library.

[jovargas]

• No, I can't catch any native code exception from C# level. That kind of exception is one of the reasons to get empty results. Can't say that's actually happening, I just traced the code to get a possible problem source, and the fact is there is an empty result coming from libopenalprc.dll but have no idea why. Did you checked the json string values in the images above? Are they telling us something I can't see?

• Yes, it fails after running another image through OpenALPR.

• Good idea, I'll do that (save image to disk) just to make sure it is a valid frame. I'm using a 3rd party Image Debugger for Visual Studio, and I can see through it that the sent frame is valid. Even the clone made by AlprNet is loaded successfully on Image Debugger. I'm also showing in a picture box a copy of the frame sent to OpenALPR (wich is perfectly loaded). Anyway, I'll do the test.

• I'm using the Aforge Framework to load and replay a video file and I'm performing a visual trigger to send frames to OpenALPR. Nothing heavy at all: playing at 4fps and almost one frame per minute sent to OpenALPR.

This is driving me crazy since there is no behavoir pattern. The number of recognitions and the time from the start to the problem have random values.

Thanks again for your support, Matt!!

[jovargas]

I did the save-to-disk test. All the image files are valid.

[jovargas]

Problem solved!!

There was a classic thread syncronization mistake in my code. I was using a simple Task.Run() for each OpenALPR recognize() and there is a moment where new threads start before the previous had completed. So, I was facing a race condition.

I started to use the async and await approach, combined with Task.Run() (suggested by Microsoft as the best combination for asynchronous programming) and voilà, working like a beauty!!

Well, I hope this could help others in future.

Thank you very much for your help, @matthill !!

[matthill]

That's awesome news :) Great work troubleshooting, and thank you for following up with the answer.

Hopefully OpenALPR can be fully threadsafe in the future. Right now Tesseract prevents that from being possible, so you need a separate OpenALPR object for each thread. But I've been considering dropping Tesseract for something else.

[jovargas]

Yeap, I've read that about Tesseract, but even that way OpenALPR still a great project!!

Can't wait to see what's next :)

[kamilck13]

Hi,
I have this same problem. Can you explain it:

I started to use the async and await approach, combined with Task.Run()

I'm run recognize plates in backgroundWorker and never start two instances.

PS: Sorry, if my english is no good.

[jovargas]

It would be hard to explain with my code, so, here you have some tips about async / await usage: https://www.dotnetperls.com/async

BackgroundWorker's DoWork method starts a new thread. Just make sure you are not calling the same OpenALPR instance from different threads (because of Tesseract issue).