report.tex 28 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623
  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. Raichard 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 Extracting characters using the location points in the xml file.
  36. \item Reduce noise where possible to ensure maximum readability.
  37. \item Transforming a character to a normal form.
  38. \item Creating a local binary pattern histogram vector.
  39. \item Matching the found vector with a learning set.
  40. \item And finally it has to check results with a real data 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. We knew the LBP implementation would be pretty
  45. simple. Thus an advantage had to be its speed compared with other license plate
  46. recognition implementations, but the uncertainty of whether we could get some
  47. results made us pick Python. We felt Python would not restrict us as much in
  48. assigning tasks to each member of the group. In addition, when using the
  49. correct modules to handle images, Python can be decent in speed.
  50. \section{Theory}
  51. Now we know what our program has to be capable of, we can start with the
  52. defining what problems we have and how we want to solve these.
  53. \subsection{Extracting a letter and resizing it}
  54. Rewrite this section once we have implemented this properly.
  55. \subsection{Transformation}
  56. A simple perspective transformation will be sufficient to transform and resize
  57. the characters to a normalized format. The corner positions of characters in
  58. the dataset are supplied together with the dataset.
  59. \subsection{Reducing noise}
  60. Small amounts of noise will probably be suppressed by usage of a Gaussian
  61. filter. A real problem occurs in very dirty license plates, where branches and
  62. dirt over a letter could radically change the local binary pattern. A question
  63. we can ask ourselves here, is whether we want to concentrate ourselves on these
  64. exceptional cases. By law, license plates have to be readable. However, the
  65. provided dataset showed that this does not mean they always are. We will have
  66. to see how the algorithm performs on these plates, however we have good hopes
  67. that our method will get a good score on dirty plates, as long as a big enough
  68. part of the license plate remains readable.
  69. \subsection{Local binary patterns}
  70. Once we have separate digits and characters, we intent to use Local Binary
  71. Patterns (Ojala, Pietikäinen \& Harwood, 1994) to determine what character
  72. or digit we are dealing with. Local Binary
  73. Patterns are a way to classify a texture based on the distribution of edge
  74. directions in the image. Since letters on a license plate consist mainly of
  75. straight lines and simple curves, LBP should be suited to identify these.
  76. \subsubsection{LBP Algorithm}
  77. The LBP algorithm that we implemented can use a variety of neighbourhoods,
  78. including the same square pattern that is introduced by Ojala et al (1994),
  79. and a circular form as presented by Wikipedia.
  80. \begin{itemize}
  81. \item Determine the size of the square where the local patterns are being
  82. registered. For explanation purposes let the square be 3 x 3. \\
  83. \item The grayscale value of the middle pixel is used as threshold. Every
  84. value of the pixel around the middle pixel is evaluated. If it's value is
  85. greater than the threshold it will be become a one else a zero.
  86. \begin{figure}[H]
  87. \center
  88. \includegraphics[scale=0.5]{lbp.png}
  89. \caption{LBP 3 x 3 (Pietik\"ainen, Hadid, Zhao \& Ahonen (2011))}
  90. \end{figure}
  91. Notice that the pattern will be come of the form 01001110. This is done when a
  92. the value of the evaluated pixel is greater than the threshold, shift the bit
  93. by the n(with i=i$_{th}$ pixel evaluated, starting with $i=0$).
  94. This results in a mathematical expression:
  95. Let I($x_i, y_i$) an Image with grayscale values and $g_n$ the grayscale value
  96. of the pixel $(x_i, y_i)$. Also let $s(g_i, g_c)$ (see below) with $g_c$ =
  97. grayscale value of the center pixel and $g_i$ the grayscale value of the pixel
  98. to be evaluated.
  99. $$
  100. s(g_i, g_c) = \left\{
  101. \begin{array}{l l}
  102. 1 & \quad \text{if $g_i$ $\geq$ $g_c$}\\
  103. 0 & \quad \text{if $g_i$ $<$ $g_c$}\\
  104. \end{array} \right.
  105. $$
  106. $$LBP_{n, g_c = (x_c, y_c)} = \sum\limits_{i=0}^{n-1} s(g_i, g_c)^{2i} $$
  107. The outcome of this operations will be a binary pattern.
  108. \item Given this pattern, the next step is to divide the pattern in cells. The
  109. amount of cells depends on the quality of the result, so trial and error is in
  110. order. Starting with dividing the pattern in to cells of size 16.
  111. \item Compute a histogram for each cell.
  112. \begin{figure}[H]
  113. \center
  114. \includegraphics[scale=0.7]{cells.png}
  115. \caption{Divide in cells(Pietik\"ainen et all (2011))}
  116. \end{figure}
  117. \item Consider every histogram as a vector element and concatenate these. The
  118. result is a feature vector of the image.
  119. \item Feed these vectors to a support vector machine. This will ''learn'' which
  120. vector indicates what vector is which character.
  121. \end{itemize}
  122. To our knowledge, LBP has yet not been used in this manner before. Therefore,
  123. it will be the first thing to implement, to see if it lives up to the
  124. expectations. When the proof of concept is there, it can be used in a final
  125. program.
  126. Later we will show that taking a histogram over the entire image (basically
  127. working with just one cell) gives us the best results.
  128. \subsection{Matching the database}
  129. Given the LBP of a character, a Support Vector Machine can be used to classify
  130. the character to a character in a learning set. The SVM uses a concatenation
  131. of each cell in an image as a feature vector (in the case we check the entire
  132. image no concatenation has to be done of course. The SVM can be trained with a
  133. subset of the given dataset called the ''Learning set''. Once trained, the
  134. entire classifier can be saved as a Pickle object\footnote{See
  135. \url{http://docs.python.org/library/pickle.html}} for later usage.
  136. In our case the support vector machine uses a radial gauss kernel function. The
  137. SVM finds a seperating hyperplane with minimum margins.
  138. \section{Implementation}
  139. In this section we will describe our implementations in more detail, explaining
  140. choices we made.
  141. \subsection{Character retrieval}
  142. In order to retrieve the characters from the entire image, we need to
  143. perform a perspective transformation. However, to do this, we need to know the
  144. coordinates of the four corners of each character. For our dataset, this is
  145. stored in XML files. So, the first step is to read these XML files.
  146. \paragraph*{XML reader}
  147. The XML reader will return a 'license plate' object when given an XML file. The
  148. licence plate holds a list of, up to six, NormalizedImage characters and from
  149. which country the plate is from. The reader is currently assuming the XML file
  150. and image name are corresponding, since this was the case for the given
  151. dataset. This can easily be adjusted if required.
  152. To parse the XML file, the minidom module is used. So the XML file can be
  153. treated as a tree, where one can search for certain nodes. In each XML
  154. file it is possible that multiple versions exist, so the first thing the reader
  155. will do is retrieve the current and most up-to-date version of the plate. The
  156. reader will only get results from this version.
  157. Now we are only interested in the individual characters so we can skip the
  158. location of the entire license plate. Each character has
  159. a single character value, indicating what someone thought what the letter or
  160. digit was and four coordinates to create a bounding box. If less then four
  161. points have been set the character will not be saved. Else, to make things not
  162. to complicated, a Character class is used. It acts as an associative list, but
  163. it gives some extra freedom when using the data.
  164. When four points have been gathered the data from the actual image is being
  165. requested. For each corner a small margin is added (around 3 pixels) so that no
  166. features will be lost and minimum amounts of new features will be introduced by
  167. noise in the margin.
  168. In the next section you can read more about the perspective transformation that
  169. is being done. After the transformation the character can be saved: Converted
  170. to grayscale, but nothing further. This was used to create a learning set. If
  171. it does not need to be saved as an actual image it will be converted to a
  172. NormalizedImage. When these actions have been completed for each character the
  173. license plate is usable in the rest of the code.
  174. \paragraph*{Perspective transformation}
  175. Once we retrieved the corner points of the character, we feed those to a
  176. module that extracts the (warped) character from the original image, and
  177. creates a new image where the character is cut out, and is transformed to a
  178. rectangle.
  179. \subsection{Noise reduction}
  180. The image contains a lot of noise, both from camera errors due to dark noise
  181. etc., as from dirt on the license plate. In this case, noise therefore means
  182. any unwanted difference in color from the surrounding pixels.
  183. \paragraph*{Camera noise and small amounts of dirt}
  184. The dirt on the license plate can be of different sizes. We can reduce the
  185. smaller amounts of dirt in the same way as we reduce normal noise, by applying
  186. a Gaussian blur to the image. This is the next step in our program.\\
  187. \\
  188. The Gaussian filter we use comes from the \texttt{scipy.ndimage} module. We use
  189. this function instead of our own function, because the standard functions are
  190. most likely more optimized then our own implementation, and speed is an
  191. important factor in this application.
  192. \paragraph*{Larger amounts of dirt}
  193. Larger amounts of dirt are not going to be resolved by using a Gaussian filter.
  194. We rely on one of the characteristics of the Local Binary Pattern, only looking
  195. at the difference between two pixels, to take care of these problems.\\
  196. Because there will probably always be a difference between the characters and
  197. the dirt, and the fact that the characters are very black, the shape of the
  198. characters will still be conserved in the LBP, even if there is dirt
  199. surrounding the character.
  200. \subsection{Creating Local Binary Patterns and feature vector}
  201. Every pixel is a center pixel and it is also a value to evaluate but not at the
  202. same time. Every pixel is evaluated as shown in the explanation
  203. of the LBP algorithm. There are several neighbourhoods we can evaluate. We have
  204. tried the following neighbourhoods:
  205. \begin{figure}[H]
  206. \center
  207. \includegraphics[scale=0.5]{neighbourhoods.png}
  208. \caption{Tested neighbourhoods}
  209. \end{figure}
  210. We name these neighbourhoods respectively (8,3)-, (8,5)- and
  211. (12,5)-neighbourhoods, after the number of points we use and the diameter
  212. of the `circle´ on which these points lay.\\
  213. \\
  214. We chose these neighbourhoods to prevent having to use interpolation, which
  215. would add a computational step, thus making the code execute slower. In the
  216. next section we will describe what the best neighbourhood was.
  217. Take an example where the full square can be evaluated, so none of the
  218. neighbours are out of bounds. The first to be checked is the pixel in the left
  219. bottom corner in the square 3 x 3, with coordinate $(x - 1, y - 1)$ with $g_c$
  220. as center pixel that has coordinates $(x, y)$. If the grayscale value of the
  221. neighbour in the left corner is greater than the grayscale
  222. value of the center pixel than return true. Bit-shift the first bit with 7. The
  223. outcome is now 1000000. The second neighbour will be bit-shifted with 6, and so
  224. on. Until we are at 0. The result is a binary pattern of the local point just
  225. evaluated.
  226. Now only the edge pixels are a problem, but a simple check if the location of
  227. the neighbour is still in the image can resolve this. We simply state that the
  228. pixel has a lower value then the center pixel if it is outside the image
  229. bounds.
  230. \paragraph*{Histogram and Feature Vector}
  231. After all the Local Binary Patterns are created for every pixel, this pattern
  232. is divided into cells. The feature vector is the vector of concatenated
  233. histograms. These histograms are created for cells. These cells are created by
  234. dividing the \textbf{pattern} in to cells and create a histogram of that. So
  235. multiple cells are related to one histogram. All the histograms are
  236. concatenated and fed to the SVM that will be discussed in the next section,
  237. Classification. We did however find out that the use of several cells was not
  238. increasing our performance, so we only have one histogram to feed to the SVM.
  239. \subsection{Classification}
  240. For the classification, we use a standard Python Support Vector Machine,
  241. \texttt{libsvm}. This is a often used SVM, and should allow us to simply feed
  242. the data from the LBP and Feature Vector steps into the SVM and receive
  243. results.\\
  244. \\
  245. Using a SVM has two steps. First you have to train the SVM, and then you can
  246. use it to classify data. The training step takes a lot of time, so luckily
  247. \texttt{libsvm} offers us an opportunity to save a trained SVM. This means,
  248. you do not have to train the SVM every time.\\
  249. \\
  250. We have decided to only include a character in the system if the SVM can be
  251. trained with at least 70 examples. This is done automatically, by splitting
  252. the data set in a trainingset and a testset, where the first 70 examples of
  253. a character are added to the trainingset, and all the following examples are
  254. added to the testset. Therefore, if there are not enough examples, all
  255. available examples end up in the trainingset, and non of these characters
  256. end up in the testset, thus they do not decrease our score. However, if this
  257. character later does get offered to the system, the training is as good as
  258. possible, since it is trained with all available characters.
  259. \subsection{Supporting Scripts}
  260. In order to work with the code, we wrote a number of scripts. Each of these
  261. scripts is named here and a description is given on what the script does.
  262. \subsection*{\texttt{find\_svm\_params.py}}
  263. \subsection*{\texttt{LearningSetGenerator.py}}
  264. \subsection*{\texttt{load\_characters.py}}
  265. \subsection*{\texttt{load\_learning\_set.py}}
  266. \subsection*{\texttt{run\_classifier.py}}
  267. \section{Finding parameters}
  268. Now that we have a functioning system, we need to tune it to work properly for
  269. license plates. This means we need to find the parameters. Throughout the
  270. program we have a number of parameters for which no standard choice is
  271. available. These parameters are:\\
  272. \\
  273. \begin{tabular}{l|l}
  274. Parameter & Description\\
  275. \hline
  276. $\sigma$ & The size of the Gaussian blur.\\
  277. \emph{cell size} & The size of a cell for which a histogram of LBP's
  278. will be generated.\\
  279. \emph{Neighbourhood}& The neighbourhood to use for creating the LBP.\\
  280. $\gamma$ & Parameter for the Radial kernel used in the SVM.\\
  281. $c$ & The soft margin of the SVM. Allows how much training
  282. errors are accepted.\\
  283. \end{tabular}\\
  284. \\
  285. For each of these parameters, we will describe how we searched for a good
  286. value, and what value we decided on.
  287. \subsection{Parameter $\sigma$}
  288. The first parameter to decide on, is the $\sigma$ used in the Gaussian blur. To
  289. find this parameter, we tested a few values, by trying them and checking the
  290. results. It turned out that the best value was $\sigma = 1.4$.\\
  291. \\
  292. Theoretically, this can be explained as follows. The filter has width of
  293. $6 * \sigma = 6 * 1.4 = 8.4$ pixels. The width of a `stroke' in a character is,
  294. after our resize operations, around 8 pixels. This means, our filter `matches'
  295. the smallest detail size we want to be able to see, so everything that is
  296. smaller is properly suppressed, yet it retains the details we do want to keep,
  297. being everything that is part of the character.
  298. \subsection{Parameter \emph{cell size}}
  299. The cell size of the Local Binary Patterns determines over what region a
  300. histogram is made. The trade-off here is that a bigger cell size makes the
  301. classification less affected by relative movement of a character compared to
  302. those in the learning set, since the important structure will be more likely to
  303. remain in the same cell. However, if the cell size is too big, there will not
  304. be enough cells to properly describe the different areas of the character, and
  305. the feature vectors will not have enough elements.\\
  306. \\
  307. In order to find this parameter, we used a trial-and-error technique on a few
  308. cell sizes. During this testing, we discovered that a lot better score was
  309. reached when we take the histogram over the entire image, so with a single
  310. cell. Therefore, we decided to work without cells.\\
  311. \\
  312. A reason we can think of why using one cell works best is that the size of a
  313. single character on a license plate in the provided dataset is very small.
  314. That means that when dividing it into cells, these cells become simply too
  315. small to have a really representative histogram. Therefore, the
  316. concatenated histograms are then a list of only very small numbers, which
  317. are not significant enough to allow for reliable classification.
  318. \subsection{Parameter \emph{Neighbourhood}}
  319. The neighbourhood to use can only be determined through testing. We did a test
  320. with each of these neighbourhoods, and we found that the best results were
  321. reached with the following neighbourhood, which we will call the
  322. (12,5)-neighbourhood, since it has 12 points in a area with a diameter of 5.
  323. \begin{figure}[H]
  324. \center
  325. \includegraphics[scale=0.5]{12-5neighbourhood.png}
  326. \caption{(12,5)-neighbourhood}
  327. \end{figure}
  328. \subsection{Parameters $\gamma$ \& $c$}
  329. The parameters $\gamma$ and $c$ are used for the SVM. $c$ is a standard
  330. parameter for each type of SVM, called the 'soft margin'. This indicates how
  331. exact each element in the learning set should be taken. A large soft margin
  332. means that an element in the learning set that accidentally has a completely
  333. different feature vector than expected, due to noise for example, is not taken
  334. into account. If the soft margin is very small, then almost all vectors will be
  335. taken into account, unless they differ extreme amounts.\\
  336. $\gamma$ is a variable that determines the size of the radial kernel, and as
  337. such determines how steep the difference between two classes can be.\\
  338. \\
  339. Since these parameters both influence the SVM, we need to find the best
  340. combination of values. To do this, we perform a so-called grid-search. A
  341. grid-search takes exponentially growing sequences for each parameter, and
  342. checks for each combination of values what the score is. The combination with
  343. the highest score is then used as our parameters, and the entire SVM will be
  344. trained using those parameters.\\
  345. \\
  346. The results of this grid-search are shown in the following table. The values
  347. in the table are rounded percentages, for easy displaying.
  348. \begin{tabular}{|r|r r r r r r r r r r|}
  349. \hline
  350. c $\gamma$ & $2^{-15}$ & $2^{-13}$ & $2^{-11}$ & $2^{-9}$ & $2^{-7}$ &
  351. $2^{-5}$ & $2^{-3}$ & $2^{-1}$ & $2^{1}$ & $2^{3}$\\
  352. \hline
  353. $2^{-5}$ & 61 & 61 & 61 & 61 & 62 &
  354. 63 & 67 & 74 & 59 & 24\\
  355. $2^{-3}$ & 61 & 61 & 61 & 61 & 62 &
  356. 63 & 70 & 78 & 60 & 24\\
  357. $2^{-1}$ & 61 & 61 & 61 & 61 & 62 &
  358. 70 & 83 & 88 & 78 & 27\\
  359. $2^{1}$ & 61 & 61 & 61 & 61 & 70 &
  360. 84 & 90 & 92 & 86 & 45\\
  361. $2^{3}$ & 61 & 61 & 61 & 70 & 84 &
  362. 90 & 93 & 93 & 86 & 45\\
  363. $2^{5}$ & 61 & 61 & 70 & 84 & 90 &
  364. 92 & 93 & 93 & 86 & 45\\
  365. $2^{7}$ & 61 & 70 & 84 & 90 & 92 &
  366. 93 & 93 & 93 & 86 & 45\\
  367. $2^{9}$ & 70 & 84 & 90 & 92 & 92 &
  368. 93 & 93 & 93 & 86 & 45\\
  369. $2^{11}$ & 84 & 90 & 92 & 92 & 92 &
  370. 92 & 93 & 93 & 86 & 45\\
  371. $2^{13}$ & 90 & 92 & 92 & 92 & 92 &
  372. 92 & 93 & 93 & 86 & 45\\
  373. $2^{15}$ & 92 & 92 & 92 & 92 & 92 &
  374. 92 & 93 & 93 & 86 & 45\\
  375. \hline
  376. \end{tabular}
  377. We found that the best values for these parameters are $c = 32$ and
  378. $\gamma = 0.125$.
  379. \section{Results}
  380. The goal was to find out two things with this research: The speed of the
  381. classification and the accuracy. In this section we will show our findings.
  382. \subsection{Accuracy}
  383. Of course, it is vital that the recognition of a license plate is correct,
  384. almost correct is not good enough here. Therefore, we have to get the highest
  385. accuracy score we possibly can.\\
  386. \\ According to Wikipedia
  387. \footnote{
  388. \url{http://en.wikipedia.org/wiki/Automatic_number_plate_recognition}},
  389. commercial license plate recognition software score about $90\%$ to $94\%$,
  390. under optimal conditions and with modern equipment.\\
  391. \\
  392. Our program scores an average of $93\%$. However, this is for a single
  393. character. That means that a full license plate should theoretically
  394. get a score of $0.93^6 = 0.647$, so $64.7\%$. That is not particularly
  395. good compared to the commercial ones. However, our focus was on getting
  396. good scores per character, and $93\%$ seems to be a fairly good result.\\
  397. \\
  398. Possibilities for improvement of this score would be more extensive
  399. grid-searches, finding more exact values for $c$ and $\gamma$, more tests
  400. for finding $\sigma$ and more experiments on the size and shape of the
  401. neighbourhoods.
  402. \subsection{Speed}
  403. Recognizing license plates is something that has to be done fast, since there
  404. can be a lot of cars passing a camera in a short time, especially on a highway.
  405. Therefore, we measured how well our program performed in terms of speed. We
  406. measure the time used to classify a license plate, not the training of the
  407. dataset, since that can be done offline, and speed is not a primary necessity
  408. there.\\
  409. \\
  410. The speed of a classification turned out to be reasonably good. We time between
  411. the moment a character has been 'cut out' of the image, so we have a exact
  412. image of a character, to the moment where the SVM tells us what character it
  413. is. This time is on average $65$ ms. That means that this
  414. technique (tested on an AMD Phenom II X4 955 CPU running at 3.2 GHz)
  415. can identify 15 characters per second.\\
  416. \\
  417. This is not spectacular considering the amount of calculating power this CPU
  418. can offer, but it is still fairly reasonable. Of course, this program is
  419. written in Python, and is therefore not nearly as optimized as would be
  420. possible when written in a low-level language.\\
  421. \\
  422. Another performance gain is by using one of the other two neighbourhoods.
  423. Since these have 8 points instead of 12 points, this increases performance
  424. drastically, but at the cost of accuracy. With the (8,5)-neighbourhood
  425. we only need 1.6 ms seconds to identify a character. However, the accuracy
  426. drops to $89\%$. When using the (8,3)-neighbourhood, the speedwise performance
  427. remains the same, but accuracy drops even further, so that neighbourhood
  428. is not advisable to use.
  429. \section{Conclusion}
  430. In the end it turns out that using Local Binary Patterns is a promising
  431. technique for License Plate Recognition. It seems to be relatively indifferent
  432. for the amount of dirt on license plates and different fonts on these plates.\\
  433. \\
  434. The performance speed wise is fairly good, when using a fast machine. However,
  435. this is written in Python, which means it is not as efficient as it could be
  436. when using a low-level languages.
  437. \\
  438. We believe that with further experimentation and development, LBP's can
  439. absolutely be used as a good license plate recognition method.
  440. \section{Reflection}
  441. \subsection{Difficulties}
  442. During the implementation and testing of the program, we did encounter a
  443. number of difficulties. In this section we will state what these difficulties
  444. were and whether we were able to find a proper solution for them.
  445. \subsubsection*{Dataset}
  446. We did experience a number of problems with the provided dataset. A number of
  447. these are problems to be expected in a real world problem, but which make
  448. development harder. Others are more elemental problems.\\
  449. The first problem was that the dataset contains a lot of license plates which
  450. are problematic to read, due to excessive amounts of dirt on them. Of course,
  451. this is something you would encounter in the real situation, but it made it
  452. hard for us to see whether there was a coding error or just a bad example.\\
  453. Another problem was that there were license plates of several countries in
  454. the dataset. Each of these countries has it own font, which also makes it
  455. hard to identify these plates, unless there are a lot of these plates in the
  456. learning set.\\
  457. A problem that is more elemental is that some of the characters in the dataset
  458. are not properly classified. This is of course very problematic, both for
  459. training the SVM as for checking the performance. This meant we had to check
  460. each character whether its description was correct.
  461. \subsubsection*{SVM}
  462. We also had trouble with the SVM for Python. The standard Python SVM, libsvm,
  463. had a poor documentation. There was no explanation what so ever on which
  464. parameter had to be what. This made it a lot harder for us to see what went
  465. wrong in the program.
  466. \subsection{Workload distribution}
  467. The first two weeks were team based. Basically the LBP algorithm could be
  468. implemented in the first hour, while some talked and someone did the typing.
  469. Some additional 'basics' where created in similar fashion. This ensured that
  470. every team member was up-to-date and could start figuring out which part of the
  471. implementation was most suited to be done by one individually or in a pair.
  472. \subsubsection*{Who did what}
  473. Gijs created the basic classes we could use and helped everyone by keeping
  474. track of what was required to be finished and whom was working on what.
  475. Tadde\"us and Jayke were mostly working on the SVM and all kinds of tests
  476. whether the histograms were matching, and what parameters had to be used.
  477. Fabi\"en created the functions to read and parse the given xml files with
  478. information about the license plates. Upon completion all kinds of learning
  479. and data sets could be created. Richard helped out wherever anyone needed a
  480. helping hand, and was always available when someone had doubts about what they
  481. where doing or needed to ask something. He also wrote an image cropper that
  482. automatically exactly cuts out a character, which eventually turned out to be
  483. obsolete.
  484. \subsubsection*{How it went}
  485. Sometimes one cannot hear the alarm bell and wake up properly. This however was
  486. not a big problem as no one was afraid of staying at Science Park a bit longer
  487. to help out. Further communication usually went through e-mails and replies
  488. were instantaneous! A crew to remember.
  489. \section{Discussion}
  490. \begin{thebibliography}{9}
  491. \bibitem{lbp1}
  492. Matti Pietik\"ainen, Guoyin Zhao, Abdenour hadid,
  493. Timo Ahonen.
  494. \emph{Computational Imaging and Vision}.
  495. Springer-Verlag, London,
  496. 1nd Edition,
  497. 2011.
  498. \end{thebibliography}
  499. \appendix
  500. \section{Faulty Classifications}
  501. \begin{figure}[H]
  502. \center
  503. \includegraphics[scale=0.5]{faulty.png}
  504. \caption{Faulty classifications of characters}
  505. \end{figure}
  506. \end{document}