Fixed merge conflict.

docs/report.tex

@@ -570,19 +570,6 @@ expectations. \\
 Note: Both tests were executed using an AMD Phenom II X4 955 CPU processor,
 running at 3.2 GHz.
 
-This is not spectacular considering the amount of calculating power this CPU
-can offer, but it is still fairly reasonable. Of course, this program is
-written in Python, and is therefore not nearly as optimized as would be
-possible when written in a low-level language.
-
-Another performance gain is by using one of the other two neighbourhoods.
-Since these have 8 points instead of 12 points, this increases performance
-drastically, but at the cost of accuracy. With the (8,5)-neighbourhood
-we only need 81ms seconds to identify a character. However, the accuracy
-drops to $89\%$. When using the (8,3)-neighbourhood, the speedwise performance
-remains the same, but accuracy drops even further, so that neighbourhood
-is not advisable to use.
-
 \section{Discussion}
 
 There are a few points open for improvement. These are the following.
@@ -604,44 +591,56 @@ radius, you look over a larger distance, so the blurry part of the edge is
 skipped. By not using more points, there is no penalty in the time needed to
 calculate this larger pattern, so there is an accuracy advantage `for free'.
 
-\subsection{Context Information}
-
-We don't do assumption when a letter is recognized. For instance Dutch licence
-plates exist of three blocks, two digits or two characters. Or for the new
-licence plates there are three blocks, two digits followed by three characters,
-followed by one or two digits. The assumption we can do is when there is have a
-case when one digit is most likely to follow by a second digit and not a
-character. Maybe these assumption can help in future research to achieve a
-higher accuracy rate.
-
-\subsection{Speed up}
-
-A possibility to improve the performance speedwise would be to separate the
-creation of the Gaussian kernel and the convolution. This way, the kernel can
-be cached, which is a big improvement. At this moment, we calculate this kernel
-every time a blur is applied to a character. This was done so we could use a
-standard Python function, but we realised too late that there is performance
-loss due to this.
-
-Another performance loss was introduced by checking for each pixel if it is
-in the image. This induces one function call and four conditional checks
-per pixel, which costs performance. A faster method would be to first set a
-border of black pixels around the image, so the inImage function is now done
-implicitly because it simply finds a black pixel if it falls outside the
-original image borders.
+\subsection{Context information}
+
+Unlike existing commercial license plate recognition software, our
+implementation makes no use of context information. For instance, Dutch early
+license plates consist of three blocks, one of two digits and two of two
+letters. More recent Dutch plates also consist of three blocks, two digits
+followed by three characters, followed by one or two digits. \\
+This information could be used in an extension of our code to increase
+accuracy.
+
+\subsection{Potential speedup}
+
+One way of gaining time-wise performance is making a smart choice of local
+binary pattern. For instance, the (8,3)-neighbourhood has a good performance,
+but low accuracy. The (12,8)-neighbourhood yields a high accuracy, but has a
+relatively poor performance. As an in-between solution, the (8,5)-neighbourhood
+can be used. This has the same time-wise performance as (8,3), but a higher
+accuracy. The challenge is to find a combination of (number of points,
+neighbourhood size) that suits both accuracy and runtime demands.
+
+Another possibility to improve the performance speed-wise would be to separate
+the creation of the Gaussian kernel and the convolution. This way, the kernel
+will not have to be created for each feature vector. This seems to be a trivial
+optimization, but due to lack of time we have not been able to implement it.
+
+Using Python profiling, we learned that a significant percentage of the
+execution time is spent in the functions that create the LBP of a pixel. These
+functions currently call the \texttt{LocalBinaryPatternizer.is\_pixel\_darker}
+function for each comparison, which is expensive in terms of efficiency. The
+functions also call \texttt{inImage}, which (obviously) checks if a pixel is
+inside the image. This can be avoided by adding a border around the image with
+the width of half the neighbourhood size minus one (for example, $\frac{5 -
+1}{2} = 2$ pixels in a $5x5$ neighbourhood). When creating the feature vector,
+this border should not be iterated over.
 
 \section{Conclusion}
 
-In the end it turns out that using Local Binary Patterns is a promising
-technique for License Plate Recognition. It seems to be relatively indifferent
-for the amount of dirt on license plates and different fonts on these plates.
+It turns out that using Local Binary Patterns is a promising technique for
+license plate recognition. It seems to be relatively indifferent of the amount
+of dirt on license plates, which means that it is robust. \\
+Also, different fonts are recognized quite well, which means that it is well
+suited for international use (at country borders, for example).
 
-The performance speed wise is fairly good, when using a fast machine. However,
-this is written in Python, which means it is not as efficient as it could be
-when using a low-level languages.
+Time-wise performance turns out to be better than one would expect from a large
+Python program. This gives high hopes for performance in any future
+implementation written in a C-like language.
 
-We believe that with further experimentation and development, LBP's can
-absolutely be used as a good license plate recognition method.
+Given both of the statements above, we believe that with further
+experimentation and development, LBP's is absolutely a valid method to be used
+in license plate recognition.
 
 \section{Reflection}
 
@@ -653,46 +652,47 @@ were and whether we were able to find a proper solution for them.
 
 \subsubsection*{Dataset}
 
-We did experience a number of problems with the provided dataset. A number of
-these are problems to be expected in a real world problem, but which make
-development harder. Others are more elemental problems.
+We have encountered a number of problems with the provided dataset. A number of
+these are to be expected in the real world, but they do make development
+harder. Others are more elementary problems.
 
-The first problem was that the dataset contains a lot of license plates which
+The first problem is that the dataset contains a lot of license plates which
 are problematic to read, due to excessive amounts of dirt on them. Of course,
 this is something you would encounter in the real situation, but it made it
 hard for us to see whether there was a coding error or just a bad example.
-aucla
-Another problem was that there were license plates of several countries in
+
+Another problem is that there were license plates of several countries in
 the dataset. Each of these countries has it own font, which also makes it
 hard to identify these plates, unless there are a lot of these plates in the
 learning set.
 
 A problem that is more elemental is that some of the characters in the dataset
-are not properly classified. This is of course very problematic, both for
-training the SVM as for checking the performance. This meant we had to check
-each character whether its description was correct.
+are not properly classified. This is obviously very problematic, because it
+means that we had to manually verify the value of each character.
 
-As final note, we would like to state that an, in our eyes, unrealistic amount
-of characters has a bad quality, with a lot of dirt, or crooked plates
-etcetera. Our own experience is that the average license plate is less hard to
+As final note, we would like to state that a seemingly unrealistic amount
+of characters has a poor quality, with a lot of dirt, or crooked plates
+etc.. Our own experience is that the average license plate is less hard to
 read. The local binary pattern method has proven to work on this set, and as
 such has proven that it performs good in worst-case scenarios, but we would
-like to see how it performs on a more realistic dataset.
+like to see how it performs on a dataset with a larger amount of readable,
+higher-resolution characters.
 
-\subsubsection*{SVM}
+\subsubsection*{\texttt{libsvm}}
 
-We also had trouble with the SVM for Python. The standard Python SVM, libsvm,
-had a poor documentation. There was no explanation what so ever on which
-parameter had to be what. This made it a lot harder for us to see what went
-wrong in the program.
+We also had trouble with the SVM for Python. The standard Python SVM,
+\texttt{libsvm}, had a poor documentation. There was no documentation
+whatsoever for a number of functions. This did not improve efficiency during
+the process of development.
 
 \subsection{Workload distribution}
 
-The first two weeks were team based. Basically the LBP algorithm could be
-implemented in the first hour, while some talked and someone did the typing.
-Some additional 'basics' where created in similar fashion. This ensured that
-every team member was up-to-date and could start figuring out which part of the
-implementation was most suited to be done by one individually or in a pair.
+The first two weeks were very team based. Basically, the LBP algorithm day
+implemented in the first day, as result of a collective effort. Some
+additional `basic' functions and classes were created in similar fashion. This
+ensured that every team member was up-to-date and could start figuring out
+which part of the implementation was most suited to be done by one individually
+or in a pair.
 
 \subsubsection*{Work distribution}