report.tex 34 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744
  1. \documentclass[a4paper]{article}
  2. \usepackage{amsmath}
  3. \usepackage{hyperref}
  4. \usepackage{graphicx}
  5. \usepackage{float}
  6. \title{Using local binary patterns to read license plates in photographs}
  7. % Paragraph indentation
  8. \setlength{\parindent}{0pt}
  9. \setlength{\parskip}{1ex plus 0.5ex minus 0.2ex}
  10. \begin{document}
  11. \maketitle
  12. \section*{Project members}
  13. Gijs van der Voort \\
  14. Richard Torenvliet \\
  15. Jayke Meijer \\
  16. Tadde\"us Kroes\\
  17. Fabi\"en Tesselaar
  18. \tableofcontents
  19. \pagebreak
  20. \setcounter{secnumdepth}{1}
  21. \section{Problem description}
  22. License plates are used for uniquely identifying motorized vehicles and are
  23. made to be read by humans from great distances and in all kinds of weather
  24. conditions.
  25. Reading license plates with a computer is much more difficult. Our dataset
  26. contains photographs of license plates from various angles and distances. This
  27. means that not only do we have to implement a method to read the actual
  28. characters, but given the location of the license plate and each individual
  29. character, we must make sure we transform each character to a standard form.
  30. Determining what character we are looking at will be done by using Local Binary
  31. Patterns. The main goal of our research is finding out how effective LBP's are
  32. in classifying characters on a license plate.
  33. In short our program must be able to do the following:
  34. \begin{enumerate}
  35. \item Extract characters using the location points in the xml file.
  36. \item Reduce noise where possible to ensure maximum readability.
  37. \item Transform a character to a normal form.
  38. \item Create a local binary pattern histogram vector.
  39. \item Recognize the character value of a vector using a classifier.
  40. \item Determine the performance of the classifier with a given test set.
  41. \end{enumerate}
  42. \section{Language of choice}
  43. The actual purpose of this project is to check if LBP is capable of recognizing
  44. license plate characters. Since the LBP algorithm is fairly simple to
  45. implement, it should have a good performance in comparison to other license
  46. plate recognition implementations if implemented in C. However, we decided to
  47. focus on functionality rather than speed. Therefore, we picked Python. We felt
  48. Python would not restrict us as much in assigning tasks to each member of the
  49. group. In addition, when using the correct modules to handle images, Python can
  50. be decent in speed.
  51. \section{Theory}
  52. Now we know what our program has to be capable of, we can start with the
  53. defining the problems we have and how we are planning to solve these.
  54. \subsection{Extracting a character and resizing it}
  55. We need to extract a character from a photo made of a car. We do not have to
  56. find where in this image the characters are, since this is provided in an XML
  57. file with our dataset.
  58. Once we have extracted the points from this XML file, we need to get this
  59. character from the image. For the nature of the Local Binary Pattern algorithm,
  60. we want a margin around the character. However, the points stored in the XML
  61. file are chosen in such a fashion, that the character would be cut out exactly.
  62. Therefore, we choose to take points that are slightly outside of the given
  63. points.
  64. When we have the points we want, we use a perspective transformation to get
  65. an exact image of the character.
  66. The final step is to resize this image in such a fashion, that the stroke
  67. of the character is more or less equal in each image. We do this by setting
  68. the height to a standard size, since each character has the same height on a
  69. license plate. We retain the height-width ratio, so we do not end up with
  70. characters that are different than other examples of the same character,
  71. because the image got stretched, which would of course be a bad thing for
  72. the classification.
  73. \subsection{Transformation}
  74. A simple perspective transformation will be sufficient to transform and resize
  75. the characters to a normalized format. The corner positions of characters in
  76. the dataset are provided together with the dataset.
  77. \subsection{Reducing noise}
  78. Small amounts of noise will probably be suppressed by usage of a Gaussian
  79. filter. A real problem occurs in very dirty license plates, where branches and
  80. dirt over a letter could radically change the local binary pattern. A question
  81. we can ask ourselves here, is whether we want to concentrate ourselves on these
  82. exceptional cases. By law, license plates have to be readable. However, the
  83. provided dataset showed that this does not mean they always are. We will have
  84. to see how the algorithm performs on these plates, however we have good hopes
  85. that our method will get a good score on dirty plates, as long as a big enough
  86. part of the license plate remains readable.
  87. \subsection{Local binary patterns}
  88. Once we have separate digits and characters, we intent to use Local Binary
  89. Patterns (Ojala, Pietikäinen \& Harwood, 1994) to determine what character or
  90. digit we are dealing with. Local Binary Patterns are a way to classify a
  91. texture based on the distribution of edge directions in the image. Since
  92. letters on a license plate consist mainly of straight lines and simple curves,
  93. LBP should be suited to identify these.
  94. \subsubsection{LBP Algorithm}
  95. The LBP algorithm that we implemented can use a variety of neighbourhoods,
  96. including the same square pattern that is introduced by Ojala et al (1994), and
  97. a circular form as presented by Wikipedia.
  98. \begin{enumerate}
  99. \item Determine the size of the square where the local patterns are being
  100. registered. For explanation purposes let the square be 3 x 3. \\
  101. \item The grayscale value of the center pixel is used as threshold. Every value
  102. of the pixel around the center pixel is evaluated. If it's value is greater
  103. than the threshold it will be become a one, otherwise it will be a zero.
  104. \begin{figure}[H]
  105. \center
  106. \includegraphics[scale=0.5]{lbp.png}
  107. \caption{LBP 3 x 3 (Pietik\"ainen, Hadid, Zhao \& Ahonen (2011))}
  108. \end{figure}
  109. The pattern will be an 8-bit integer. This is accomplished by shifting the
  110. boolean value of each comparison one to seven places to the left.
  111. This results in the following mathematical expression:
  112. Let I($x_i, y_i$) be a grayscale Image and $g_n$ the value of the pixel $(x_i,
  113. y_i)$. Also let $s(g_i, g_c)$ (see below) with $g_c$ being the value of the
  114. center pixel and $g_i$ the grayscale value of the pixel to be evaluated.
  115. $$
  116. s(g_i, g_c) = \left \{
  117. \begin{array}{l l}
  118. 1 & \quad \text{if $g_i$ $\geq$ $g_c$}\\
  119. 0 & \quad \text{if $g_i$ $<$ $g_c$}\\
  120. \end{array} \right.
  121. $$
  122. $$LBP_{n, g_c = (x_c, y_c)} = \sum\limits_{i=0}^{n-1} s(g_i, g_c) \cdot 2^i$$
  123. The outcome of this operations will be a binary pattern. Note that the
  124. mathematical expression has the same effect as the bit shifting operation that
  125. we defined earlier.
  126. \item Given this pattern for each pixel, the next step is to divide the image
  127. into cells.
  128. \item Compute a histogram for each cell.
  129. \begin{figure}[H]
  130. \center
  131. \includegraphics[scale=0.7]{cells.png}
  132. \caption{Divide into cells (Pietik\"ainen et all (2011))}
  133. \end{figure}
  134. \item Consider every histogram a vector element and concatenate all histograms.
  135. The concatenation is the feature vector of the image.
  136. \item Feed these vectors to a support vector machine. The SVM will ``learn''
  137. which vectors to associate with a character.
  138. \end{enumerate}
  139. To our knowledge, LBP has yet not been used in this manner before. Therefore,
  140. it will be the first thing to implement, to see if it lives up to the
  141. expectations. When the proof of concept is there, it can be used in a final,
  142. more efficient program.
  143. Later we will show that taking a histogram over the entire image (basically
  144. working with just one cell) gives us the best results.
  145. \subsection{Matching the database}
  146. Given the LBP of a character, a Support Vector Machine can be used to classify
  147. the character to a character in a learning set. The SVM uses the concatenation
  148. of the histograms of all cells in an image as a feature vector (in the case we
  149. check the entire image no concatenation has to be done of course. The SVM can
  150. be trained with a subset of the given dataset called the ``learning set''. Once
  151. trained, the entire classifier can be saved as a Pickle object\footnote{See
  152. \url{http://docs.python.org/library/pickle.html}} for later usage.
  153. In our case the support vector machine uses a radial gauss kernel function. The
  154. SVM finds a seperating hyperplane with minimum margins.
  155. \section{Implementation}
  156. In this section we will describe our implementation in more detail, explaining
  157. the choices we made in the process. We spent a lot of attention on structuring
  158. the code in such a fashion that it can easily be extended.
  159. \subsection{Character retrieval}
  160. In order to retrieve the characters from the entire image, we need to
  161. perform a perspective transformation. However, to do this, we need to know the
  162. coordinates of the four corners of each character. For our dataset, this is
  163. stored in XML files. So, the first step is to read these XML files.
  164. \paragraph*{XML reader}
  165. The XML reader will return a `license plate' object when given an XML file. The
  166. licence plate holds a list of, up to six, NormalizedImage characters and from
  167. which country the plate is from. The reader is currently assuming the XML file
  168. and image name are corresponding, since this was the case for the given
  169. dataset. This can easily be adjusted if required.
  170. To parse the XML file, the minidom module is used. So the XML file can be
  171. treated as a tree, where one can search for certain nodes. In each XML
  172. file it is possible that multiple versions exist, so the first thing the reader
  173. will do is retrieve the current and most up-to-date version of the plate. The
  174. reader will only get results from this version.
  175. Now we are only interested in the individual characters so we can skip the
  176. location of the entire license plate. Each character has
  177. a single character value, indicating what someone thought what the letter or
  178. digit was and four coordinates to create a bounding box. If less then four
  179. points have been set the character will not be saved. Else, to make things not
  180. to complicated, a Character class is used. It acts as an associative list, but
  181. it gives some extra freedom when using the data.
  182. When four points have been gathered the data from the actual image is being
  183. requested. For each corner a small margin is added (around 3 pixels) so that no
  184. features will be lost and minimum amounts of new features will be introduced by
  185. noise in the margin.
  186. In the next section you can read more about the perspective transformation that
  187. is being done. After the transformation the character can be saved: Converted
  188. to grayscale, but nothing further. This was used to create a learning set. If
  189. it does not need to be saved as an actual image it will be converted to a
  190. NormalizedImage. When these actions have been completed for each character the
  191. license plate is usable in the rest of the code.
  192. \paragraph*{Perspective transformation}
  193. Once we retrieved the corner points of the character, we feed those to a
  194. module that extracts the (warped) character from the original image, and
  195. creates a new image where the character is cut out, and is transformed to a
  196. rectangle.
  197. \subsection{Noise reduction}
  198. The image contains a lot of noise, both from camera errors due to dark noise
  199. etc., as from dirt on the license plate. In this case, noise therefore means
  200. any unwanted difference in color from the surrounding pixels.
  201. \paragraph*{Camera noise and small amounts of dirt}
  202. The dirt on the license plate can be of different sizes. We can reduce the
  203. smaller amounts of dirt in the same way as we reduce normal noise, by applying
  204. a Gaussian blur to the image. This is the next step in our program.
  205. The Gaussian filter we use comes from the \texttt{scipy.ndimage} module. We use
  206. this function instead of our own function, because the standard functions are
  207. most likely more optimized then our own implementation, and speed is an
  208. important factor in this application.
  209. \paragraph*{Larger amounts of dirt}
  210. Larger amounts of dirt are not going to be resolved by using a Gaussian filter.
  211. We rely on one of the characteristics of the Local Binary Pattern, only looking
  212. at the difference between two pixels, to take care of these problems. \\
  213. Because there will probably always be a difference between the characters and
  214. the dirt, and the fact that the characters are very black, the shape of the
  215. characters will still be conserved in the LBP, even if there is dirt
  216. surrounding the character.
  217. \subsection{Creating Local Binary Patterns and feature vector}
  218. Every pixel is a center pixel and it is also a value to evaluate but not at the
  219. same time. Every pixel is evaluated as shown in the explanation
  220. of the LBP algorithm. There are several neighbourhoods we can evaluate. We have
  221. tried the following neighbourhoods:
  222. \begin{figure}[H]
  223. \center
  224. \includegraphics[scale=0.5]{neighbourhoods.png}
  225. \caption{Tested neighbourhoods}
  226. \label{fig:tested-neighbourhoods}
  227. \end{figure}
  228. We name these neighbourhoods respectively (8,3)-, (8,5)- and
  229. (12,5)-neighbourhoods, after the number of points we use and the diameter
  230. of the `circle´ on which these points lay.
  231. We chose these neighbourhoods to prevent having to use interpolation, which
  232. would add a computational step, thus making the code execute slower. In the
  233. next section we will describe what the best neighbourhood was.
  234. Take an example where the full square can be evaluated, so none of the
  235. neighbours are out of bounds. The first to be checked is the pixel in the left
  236. bottom corner in the square 3 x 3, with coordinate $(x - 1, y - 1)$ with $g_c$
  237. as center pixel that has coordinates $(x, y)$. If the grayscale value of the
  238. neighbour in the left corner is greater than the grayscale
  239. value of the center pixel than return true. Bit-shift the first bit with 7. The
  240. outcome is now 1000000. The second neighbour will be bit-shifted with 6, and so
  241. on. Until we are at 0. The result is a binary pattern of the local point just
  242. evaluated.
  243. Now only the edge pixels are a problem, but a simple check if the location of
  244. the neighbour is still in the image can resolve this. We simply state that the
  245. pixel has a lower value then the center pixel if it is outside the image
  246. bounds.
  247. \paragraph*{Histogram and Feature Vector}
  248. After all the Local Binary Patterns are created for every pixel, this pattern
  249. is divided into cells. The feature vector is the vector of concatenated
  250. histograms. These histograms are created for cells. These cells are created by
  251. dividing the \textbf{pattern} in to cells and create a histogram of that. So
  252. multiple cells are related to one histogram. All the histograms are
  253. concatenated and fed to the SVM that will be discussed in the next section,
  254. Classification. We did however find out that the use of several cells was not
  255. increasing our performance, so we only have one histogram to feed to the SVM.
  256. \subsection{Classification}
  257. For the classification, we use a standard Python Support Vector Machine,
  258. \texttt{libsvm}. This is an often used SVM, and should allow us to simply feed
  259. data from the LBP and Feature Vector steps into the SVM and receive results.
  260. Usage a SVM can be divided in two steps. First, the SVM has to be trained
  261. before it can be used to classify data. The training step takes a lot of time,
  262. but luckily \texttt{libsvm} offers us an opportunity to save a trained SVM.
  263. This means that the SVM only has to be created once, and can be saved for later
  264. usage.
  265. We have decided only to include a character in the system if the SVM can be
  266. trained with 70 examples. This is done automatically, by splitting the data set
  267. in a learning set and a test set, where the first 70 occurrences of a character
  268. are added to the learning set, and all the following are added to the test set.
  269. Therefore, if there are not enough examples, all available occurrences end up
  270. in the learning set, and non of these characters end up in the test set. Thus,
  271. they do not decrease our score. If such a character would be offered to the
  272. system (which it will not be in out own test program), the SVM will recognize
  273. it as good as possible because all occurrences are in the learning set.
  274. \subsection{Supporting Scripts}
  275. To be able to use the code efficiently, we wrote a number of scripts. This
  276. section describes the purpose and usage of each script.
  277. \subsection*{\texttt{create\_characters.py}}
  278. \subsection*{\texttt{create\_classifier.py}}
  279. \subsection*{\texttt{find\_svm\_params.py}}
  280. \subsection*{\texttt{generate\_learning\_set.py}}
  281. \subsection*{\texttt{load\_learning\_set.py}}
  282. \subsection*{\texttt{run\_classifier.py}}
  283. \section{Finding parameters}
  284. Now that we have a functioning system, we need to tune it to work properly for
  285. license plates. This means we need to find the parameters. Throughout the
  286. program we have a number of parameters for which no standard choice is
  287. available. These parameters are:
  288. \begin{tabular}{l|l}
  289. Parameter & Description \\
  290. \hline
  291. $\sigma$ & The size of the Gaussian blur. \\
  292. \emph{cell size} & The size of a cell for which a histogram of LBP's
  293. will be generated. \\
  294. \emph{Neighbourhood}& The neighbourhood to use for creating the LBP. \\
  295. $\gamma$ & Parameter for the Radial kernel used in the SVM. \\
  296. $c$ & The soft margin of the SVM. Allows how much training
  297. errors are accepted. \\
  298. \end{tabular}
  299. For each of these parameters, we will describe how we searched for a good
  300. value, and what value we decided on.
  301. \subsection{Parameter $\sigma$}
  302. The first parameter to decide on, is the $\sigma$ used in the Gaussian blur. To
  303. find this parameter, we tested a few values, by trying them and checking the
  304. results. It turned out that the best value was $\sigma = 1.4$.
  305. Theoretically, this can be explained as follows. The filter has width of
  306. $6 * \sigma = 6 * 1.4 = 8.4$ pixels. The width of a `stroke' in a character is,
  307. after our resize operations, around 8 pixels. This means, our filter `matches'
  308. the smallest detail size we want to be able to see, so everything that is
  309. smaller is properly suppressed, yet it retains the details we do want to keep,
  310. being everything that is part of the character.
  311. \subsection{Parameter \emph{cell size}}
  312. The cell size of the Local Binary Patterns determines over what region a
  313. histogram is made. The trade-off here is that a bigger cell size makes the
  314. classification less affected by relative movement of a character compared to
  315. those in the learning set, since the important structure will be more likely to
  316. remain in the same cell. However, if the cell size is too big, there will not
  317. be enough cells to properly describe the different areas of the character, and
  318. the feature vectors will not have enough elements.
  319. In order to find this parameter, we used a trial-and-error technique on a few
  320. cell sizes. During this testing, we discovered that a lot better score was
  321. reached when we take the histogram over the entire image, so with a single
  322. cell. Therefore, we decided to work without cells.
  323. A reason we can think of why using one cell works best is that the size of a
  324. single character on a license plate in the provided dataset is very small.
  325. That means that when dividing it into cells, these cells become simply too
  326. small to have a really representative histogram. Therefore, the
  327. concatenated histograms are then a list of only very small numbers, which
  328. are not significant enough to allow for reliable classification.
  329. \subsection{Parameter \emph{Neighbourhood}}
  330. We tested the classifier with the patterns given in figure
  331. \ref{fig:tested-neighbourhoods}. We found that the best results were reached
  332. with the following neighbourhood, which we will call the (12,5)-neighbourhood,
  333. since it has 12 points in a area with a diameter of 5.
  334. \begin{figure}[H]
  335. \center
  336. \includegraphics[scale=0.5]{12-5neighbourhood.png}
  337. \caption{(12,5)-neighbourhood}
  338. \end{figure}
  339. \subsection{Parameters $\gamma$ \& $c$}
  340. The parameters $\gamma$ and $c$ are used for the SVM. $c$ is a standard
  341. parameter for each type of SVM, called the `soft margin'. This determines the
  342. amount of overlap that is allowed between two SVM-classes (which, in this case,
  343. are characters). Below, we will illustrate that the optimal value for $c$ is
  344. 32, which means that there is an overlap between classes. This can be explained
  345. by the fact that some characters are very similar to eachother. For instance, a
  346. `Z' is similar to a `7' and a `B' is similar to an `R'.
  347. $\gamma$ is a variable that determines the shape of the radial kernel, and as
  348. such determines how strongly the vector space of the SVM is transformed by the
  349. kernel function.
  350. To find the optimal combination of values for these variables, we have
  351. performed a so-called grid-search. A grid-search takes exponentially growing
  352. sequences for each parameter, and tests a classifier for each combination of
  353. values. The combination with the highest score is the optimal solution, which
  354. will be used in the final classifier.
  355. The results of our grid-search are displayed in the following table. The values
  356. in the table are rounded percentages, for better readability.
  357. \begin{tabular}{|r|r r r r r r r r r r|}
  358. \hline
  359. c $\gamma$ & $2^{-15}$ & $2^{-13}$ & $2^{-11}$ & $2^{-9}$ & $2^{-7}$ &
  360. $2^{-5}$ & $2^{-3}$ & $2^{-1}$ & $2^{1}$ & $2^{3}$\\
  361. \hline
  362. $2^{-5}$ & 61 & 61 & 61 & 61 & 62 &
  363. 63 & 67 & 74 & 59 & 24\\
  364. $2^{-3}$ & 61 & 61 & 61 & 61 & 62 &
  365. 63 & 70 & 78 & 60 & 24\\
  366. $2^{-1}$ & 61 & 61 & 61 & 61 & 62 &
  367. 70 & 83 & 88 & 78 & 27\\
  368. $2^{1}$ & 61 & 61 & 61 & 61 & 70 &
  369. 84 & 90 & 92 & 86 & 45\\
  370. $2^{3}$ & 61 & 61 & 61 & 70 & 84 &
  371. 90 & 93 & 93 & 86 & 45\\
  372. $2^{5}$ & 61 & 61 & 70 & 84 & 90 &
  373. 92 & 93 & 93 & 86 & 45\\
  374. $2^{7}$ & 61 & 70 & 84 & 90 & 92 &
  375. 93 & 93 & 93 & 86 & 45\\
  376. $2^{9}$ & 70 & 84 & 90 & 92 & 92 &
  377. 93 & 93 & 93 & 86 & 45\\
  378. $2^{11}$ & 84 & 90 & 92 & 92 & 92 &
  379. 92 & 93 & 93 & 86 & 45\\
  380. $2^{13}$ & 90 & 92 & 92 & 92 & 92 &
  381. 92 & 93 & 93 & 86 & 45\\
  382. $2^{15}$ & 92 & 92 & 92 & 92 & 92 &
  383. 92 & 93 & 93 & 86 & 45\\
  384. \hline
  385. \end{tabular} \\
  386. The grid-search shows that the best values for these parameters are $c = 2^5 =
  387. 32$ and $\gamma = 2^{-3} = 0.125$.
  388. \section{Results}
  389. \subsection{Accuracy}
  390. The main goal of this project is to find out if LBP is a suitable algorithm to
  391. classify license plate characters.
  392. Of course, it is vital that the recognition of a license plate is correct,
  393. almost correct is not good enough here. Therefore, the highest possible score
  394. must be reached.
  395. According to Wikipedia \cite{wikiplate}, commercial license plate recognition
  396. that are currently on the market software score about $90\%$ to $94\%$, under
  397. optimal conditions and with modern equipment.
  398. Our program scores an average of $93\%$. However, this is for a single
  399. character. That means that a full license plate should theoretically
  400. get a score of $0.93^6 = 0.647$, so $64.7\%$. That is not particularly
  401. good compared to the commercial ones. However, our focus was on getting
  402. good scores per character. For us, $93\%$ is a very satisfying result.
  403. Possibilities for improvement of this score would be more extensive
  404. grid-searches, finding more exact values for $c$ and $\gamma$, more tests
  405. for finding $\sigma$ and more experiments on the size and shape of the
  406. neighbourhoods.
  407. \subsubsection*{Faulty classified characters}
  408. As we do not have a $100\%$ score, it is interesting to see what characters are
  409. classified wrong. These characters are shown in appendix \ref{faucla}. Most of
  410. these errors are easily explained. For example, some 0's are classified as
  411. 'D', some 1's are classified as 'T' and some 'F's are classified as 'E'.
  412. Of course, these are not as interesting as some of the weird matches. For
  413. example, a 'P' is classified as 7. However, if we look more closely, the 'P' is
  414. standing diagonal, possibly because the datapoints where not very exact in the
  415. XML file. This creates a large diagonal line in the image, which explains why
  416. this can be classified as a 7. The same has happened with a 'T', which is also
  417. marked as 7.
  418. Other strange matches include a 'Z' as a 9, but this character has a lot of
  419. noise surrounding it, which makes classification harder, and a 3 that is
  420. classified as 9, where the exact opposite is the case. This plate has no noise,
  421. due to which the background is a large area of equal color. This might cause
  422. the classification to focus more on this than on the actual character.
  423. \subsection{Speed}
  424. Recognizing license plates is something that has to be done fast, since there
  425. can be a lot of cars passing a camera in a short time, especially on a highway.
  426. Therefore, we measured how well our program performed in terms of speed. We
  427. measure the time used to normalize a character, create its feature vector and
  428. classify it using a given classifier. The time needed to train the classifier
  429. needs not to be measured, because that can be done `offline'.
  430. We ran performance tests for the (8,3)- and (12,5)-patterns, with Gaussian blur
  431. scales of $1.0$ and $1.4$ respectively on the same set of characters. Because
  432. $1.5$ times an many pixel comparisons have to be executed (12 vs. 8), we
  433. suspected an increase of at least $0.5$ times the time for the first test to be
  434. the outcome of the second test. `At least', because the classification step
  435. will also be slower due to the increased size of the feature vectors
  436. ($\frac{2^{12}}{2^8} = 2^4 = 16$ times as slow). The tests resulted in $81ms$
  437. and $137ms$ per character. $\frac{137}{81} = 1.7$, which agrees with our
  438. expectations. \\
  439. Note: Both tests were executed using an AMD Phenom II X4 955 CPU processor,
  440. running at 3.2 GHz.
  441. \section{Discussion}
  442. There are a few points open for improvement. These are the following.
  443. \subsection{Other Local Binary Patterns}
  444. We had some good results but of course there are more things to explore.
  445. For instance we did a research on three different patterns. There are more
  446. patterns to try. For instance we only tried (8,3)-, (8,5)- and
  447. (12,5)-neighbourhoods. What might be done is to test which pattern gives the
  448. best result, for a wider range of neighbourhoods. We haven proven that the size
  449. and number of points do influence the performance of the classifier, so further
  450. research would be in place.
  451. The expectation is that using a larger diameter pattern, but with the same
  452. amount of points is worth trying. The theory behind that is that when using a
  453. Gaussian blur to reduce noise, the edges are blurred as well. By taking larger
  454. radius, you look over a larger distance, so the blurry part of the edge is
  455. skipped. By not using more points, there is no penalty in the time needed to
  456. calculate this larger pattern, so there is an accuracy advantage `for free'.
  457. \subsection{Context information}
  458. Unlike existing commercial license plate recognition software, our
  459. implementation makes no use of context information. For instance, Dutch early
  460. license plates consist of three blocks, one of two digits and two of two
  461. letters. More recent Dutch plates also consist of three blocks, two digits
  462. followed by three characters, followed by one or two digits. \\
  463. This information could be used in an extension of our code to increase
  464. accuracy.
  465. \subsection{Potential speedup}
  466. One way of gaining time-wise performance is making a smart choice of local
  467. binary pattern. For instance, the (8,3)-neighbourhood has a good performance,
  468. but low accuracy. The (12,8)-neighbourhood yields a high accuracy, but has a
  469. relatively poor performance. As an in-between solution, the (8,5)-neighbourhood
  470. can be used. This has the same time-wise performance as (8,3), but a higher
  471. accuracy. The challenge is to find a combination of (number of points,
  472. neighbourhood size) that suits both accuracy and runtime demands.
  473. Another possibility to improve the performance speed-wise would be to separate
  474. the creation of the Gaussian kernel and the convolution. This way, the kernel
  475. will not have to be created for each feature vector. This seems to be a trivial
  476. optimization, but due to lack of time we have not been able to implement it.
  477. Using Python profiling, we learned that a significant percentage of the
  478. execution time is spent in the functions that create the LBP of a pixel. These
  479. functions currently call the \texttt{LocalBinaryPatternizer.is\_pixel\_darker}
  480. function for each comparison, which is expensive in terms of efficiency. The
  481. functions also call \texttt{inImage}, which (obviously) checks if a pixel is
  482. inside the image. This can be avoided by adding a border around the image with
  483. the width of half the neighbourhood size minus one (for example, $\frac{5 -
  484. 1}{2} = 2$ pixels in a $5x5$ neighbourhood). When creating the feature vector,
  485. this border should not be iterated over.
  486. \section{Conclusion}
  487. It turns out that using Local Binary Patterns is a promising technique for
  488. license plate recognition. It seems to be relatively indifferent of the amount
  489. of dirt on license plates, which means that it is robust. \\
  490. Also, different fonts are recognized quite well, which means that it is well
  491. suited for international use (at country borders, for example).
  492. Time-wise performance turns out to be better than one would expect from a large
  493. Python program. This gives high hopes for performance in any future
  494. implementation written in a C-like language.
  495. Given both of the statements above, we believe that with further
  496. experimentation and development, LBP's is absolutely a valid method to be used
  497. in license plate recognition.
  498. \section{Reflection}
  499. \subsection{Difficulties}
  500. During the implementation and testing of the program, we did encounter a
  501. number of difficulties. In this section we will state what these difficulties
  502. were and whether we were able to find a proper solution for them.
  503. \subsubsection*{Dataset}
  504. We have encountered a number of problems with the provided dataset. A number of
  505. these are to be expected in the real world, but they do make development
  506. harder. Others are more elementary problems.
  507. The first problem is that the dataset contains a lot of license plates which
  508. are problematic to read, due to excessive amounts of dirt on them. Of course,
  509. this is something you would encounter in the real situation, but it made it
  510. hard for us to see whether there was a coding error or just a bad example.
  511. Another problem is that there were license plates of several countries in
  512. the dataset. Each of these countries has it own font, which also makes it
  513. hard to identify these plates, unless there are a lot of these plates in the
  514. learning set.
  515. A problem that is more elemental is that some of the characters in the dataset
  516. are not properly classified. This is obviously very problematic, because it
  517. means that we had to manually verify the value of each character.
  518. As final note, we would like to state that a seemingly unrealistic amount
  519. of characters has a poor quality, with a lot of dirt, or crooked plates
  520. etc.. Our own experience is that the average license plate is less hard to
  521. read. The local binary pattern method has proven to work on this set, and as
  522. such has proven that it performs good in worst-case scenarios, but we would
  523. like to see how it performs on a dataset with a larger amount of readable,
  524. higher-resolution characters.
  525. \subsubsection*{\texttt{libsvm}}
  526. We also had trouble with the SVM for Python. The standard Python SVM,
  527. \texttt{libsvm}, had a poor documentation. There was no documentation
  528. whatsoever for a number of functions. This did not improve efficiency during
  529. the process of development.
  530. \subsection{Workload distribution}
  531. The first two weeks were very team based. Basically, the LBP algorithm day
  532. implemented in the first day, as result of a collective effort. Some
  533. additional `basic' functions and classes were created in similar fashion. This
  534. ensured that every team member was up-to-date and could start figuring out
  535. which part of the implementation was most suited to be done by one individually
  536. or in a pair.
  537. \subsubsection*{Who did what}
  538. Gijs created the basic classes we could use and helped everyone by keeping
  539. track of what was required to be finished and whom was working on what.
  540. Tadde\"us and Jayke were mostly working on the SVM and all kinds of tests
  541. whether the histograms were matching, and what parameters had to be used.
  542. Fabi\"en created the functions to read and parse the given xml files with
  543. information about the license plates. Upon completion all kinds of learning
  544. and data sets could be created. Richard helped out wherever anyone needed a
  545. helping hand, and was always available when someone had doubts about what they
  546. where doing or needed to ask something. He also wrote an image cropper that
  547. automatically exactly cuts out a character, which eventually turned out to be
  548. obsolete.
  549. \subsubsection*{How it went}
  550. Sometimes one cannot hear the alarm bell and wake up properly. This however was
  551. not a big problem as no one was afraid of staying at Science Park a bit longer
  552. to help out. Further communication usually went through e-mails and replies
  553. were instantaneous! A crew to remember.
  554. \appendix
  555. \section{Faulty classified characters}
  556. \label{faucla}
  557. \begin{figure}[H]
  558. \hspace{-2cm}
  559. \includegraphics[scale=0.5]{faulty.png}
  560. \caption{Faulty classificatied characters}
  561. \end{figure}
  562. \begin{thebibliography}{9}
  563. \bibitem{lbp1}
  564. Matti Pietik\"ainen, Guoyin Zhao, Abdenour hadid,
  565. Timo Ahonen.
  566. \emph{Computational Imaging and Vision}.
  567. Springer-Verlag, London,
  568. 1st Edition,
  569. 2011.
  570. \bibitem{wikiplate}
  571. \emph{Automatic number-plate recognition}. (2011, December 17). \\
  572. Wikipedia.
  573. Retrieved from
  574. \url{http://en.wikipedia.org/wiki/Automatic_number_plate_recognitiona}
  575. \end{thebibliography}
  576. \end{document}