deep-anpr
deep-anpr copied to clipboard
matthewearl
Generated weights.npz file doesn't work for the first image mentioned in the author's blog
Dear All,
I ran train.py successfully to generate the weights.npz, it takes quite long time on my GTX1080 GPU. I kept train.py running over a night.
Then I ran detect.py with the generated weights.npz, it works for the second image (https://commons.wikimedia.org/wiki/File:Proton_Saga_EV_at_the_RAC_Future_Car_Challenge_2011,_U.K.jpg) mentioned in the author's blog,
but the first image (https://commons.wikimedia.org/wiki/File:Google_Street_View_Car_near_Howden,_UK_2.JPG) doesn't work, the detect.py program didn't recognize any characters from the image.
Does anyone meet the same problem? although I debugged into the program for almost a day, but I did't figure out the reason.
Thanks.
How much time do you detect the plate with your GTX 1080? Concerning your problem I will not be able to help you because I work on plates FR and therefore I test on other images. thank you,
Hi novsub,
it takes more than a minute to detect with plate, since I have only one GPU, I thought it takes so long because the system spent some time to switch from the graphics device to GPU calculation, correct my if I'm wrong. BTW, how long does it take for your system?
Best Regards,
I think maybe the reason for the program didn't work very well on certain images is: train too long time to get overfitting. I'll try to train it, let's say, 3 hours on my GTX1080 when I have time several days later, I'll get back here with the result when I finish the test.
About me, it takes 6 seconds for an image of 70 297 Bytes ... For me, it's not good ... Do you have some solutions ? Thank's
Yeah, sliding window really slow down the detect process. Have you ever try the only branch of this project? which the owner mentioned building a neural network to predict the window first, to avoid the large overlaps due to sliding window. I had a little try of that branch, it doesn't work, I think the owner didn't finish the branch. But it would be a good approach to speed up the detect process. what do you think?
Yes I tried the second branch but could not do the apprenticeship (I had errors also) I tried the detection with the file wieght.npz already generated by the main branch. I got the same results, too slow .. The problem comes from detection I agree, I'm thinking about a solution to optimize it but I do not know too much .. If I found something, I tell you
Looking into the detect.py, with the second image used by the owner, it scaled the image into around 5 different-size images at first; then for each of these images, it generates large number of sliding windows; that's really time-consuming to post-process these windows.
Optimization has to be done on sliding window process. from my point of view, I'll restrict the area of characters at application level, then avoid the sliding window.
let me know if any solution from your side, I'll keep working on it from my side, and get you known if any progress.
I agree with you, I try to make the second branch work anyway because I think that to greatly improve the detection. When I run gen.py I have this mistake :
Traceback (most recent call last):
File "./gen.py", line 405, in
Do you have some ideas ?
I found my error, from now on the train.py :
Traceback (most recent call last):
File "./train.py", line 253, in
I installed the second branch in my GPU computer, which is not on my hand right now. Therefore I can't repeat your errors today.
In my mind, the error I met is due to the number of parameters of function definition and the function call don't match. I can't remember the function name right now.
But I remember that font file needs to be put in the project folder rather than sub-folder /font, and all of the testing images needs to be copied into sub-folder /test.
Indeed, I continue to try to operate this branch because a solution seems optimal in case of good operation. Thank you
Nice to know that you are focusing on the second branch. I'm also very interesting on it. Let's see if we can get some progress on it.
I'll on trip tomorrow, may spend more time on it afterwards.
I ran the train.py for 3 and half hours today in my GTX1080, which generated a new weights.npz file. It works for the second image, but unfortunately didn't work for the first image either.
not sure why so far ~
In the second branch, I have always the problem in the train.py ! I will always not be able to help you because I work on french plates, but I'm conviced the second branch can helps us :)
Yeah, the second branch needs to be modified anyway. hopefully it's not too hard.
I try to migrate this project to recognize the tire number, rather than car license plate, and figured out there is major difference in testing images and training images generation between tire number and CLP recently.
Therefore, I'll spend more time on evaluate the whole solution, may have less time working on the second branch in current time~
I also meet the same question with a 4 GPU server, it takes 10 seconds to detect.
Hi novsub,
Sorry I'm working on the mobile side of the tire number recognize project in these 2 months, just get chance to check this issue today.
Based on my current understanding of the deep-anpr solution, I highly recommend to find the plate area first, which will speed up the entire process very much. The easiest method to find the plate area is using Hough Transform to find the 4 lines of plate area, or using neural network to find these lines.
Then using deep-anpr solution to recognize the characters and numbers on the plate, or using some OCR engine to recognize them.
After then, the performance should match your requirement.
Excuse me,can I ask a question?
i don't no i take the image do the which python file when i run train.py there was a
Traceback (most recent call last):
File "train.py", line 266, in
please have anyone answer my question,thanks everybody
