At its core,  \textbf{ICL is a C++ computer vision library}. During the design and development process, the following main goals took center stage: 
\begin{itemize}
\item Optimal Performace
\item Simple and easy to use C++-interface
\item Platform-Independence 
\item No compulsory software dependencies
\end{itemize}


\section{Optimal Performance\label{sec:optimal-performace}} 
Computer vision is an area in which even the processing power of modern multi-core CPU's can easily be exhausted. With this in mind we decided to provide data interfaces that allow algorithms to be implemented as efficient as possible. Three main aspects relating to this are discussed below:
\begin{enumerate}
\item \textbf{Providing the possibility of creating shallow data copies:}\\
When image data is obtained by external algorithms, modules or libraries, it should be possible to use this data (generally passed via pointers) directly without having to make a copy of it. There are two paradigms used for the storing and handling image data: \small{\textbf{i)}} Interleaved. Here, several image channels are mixed and image data is usually allocated as a single data block\footnote{RGB image data is stored in RGBRGBRGB... manner}. \small{\textbf{ii)}} Planar. In this case each channel is stored within an extra data block.\\
Of course, providing an image structure that is capable of working with both data formats natively would allow for optimal performance. However this entails a large amount of extra effort. Hence, we decided to support only planar data layout, which we have supplemented with some very efficient conversion functions (\inlinecode{planarToInterleaved} and \inlinecode{interleavedToPlanar} \iclheaderref{CC}{CC}).
\item \textbf{Providing low-level data access:}\\
In contrast to the above aspect, we also provide low level data access so that ICL-image data can be passed to external algorithms by pointer (if these algorithms are able to work with interleaved data -- otherwise the \inlinecode{planarToInterleaved}-function can be used).
\item \textbf{Native but optional support for SIMD instruction sets:}\\
Single Instruction Mutltiple Data (SIMD) Instructions, partitioned in so called \emph{processor instruction sets} (e.g. MMX, SSE1-4, AltiVec or 3DNow!) provide the possibility to apply a CPU-operation on a set of data elements simultaneously in a single CPU cycle. This means that data processing speed can be enhanced significantly if SIMD instructions are used. However, not all processors provide these instruction sets and their usage somewhat inconvenient.\\
Fortunately, Intel provides a \emph{performance library} called \textbf{Intel-IPP}\footnote{Intel-IPP is proprietary Software, but it can be used and downloaded  for free as long as software produces with it shall not be sold (see \hrefn{http://www.intel.com/cd/software/products/asmo-na/eng/340679.htm}).} (Intel Integrated Performance Primitives) that wraps most of the necessary SIMD instructions with an easy to use C-interface\footnote{Usage is still a bit complicated, but of course much better than using MMX/SSE instructions directly}. Furthermore, algorithms implemented in Intel-IPP make heavy use of multi-core optimization.

ICL is implemented as a wrapper of Intel-IPP, however the software dependency of Intel-IPP remains purely optional. This was achieved by providing C++-fallback implementations for nearly all Intel-IPP functions used\footnote{\emph{Nearly} in this case means, that there are some very special IPP-algorithms that were too hard to implement. However only a relatively few functions are not available if ICL is built without IPP support.}) all IPP-functions used. \\
Here is a short example for the performance of Intel-IPP. Once we tried to find a good implementation for the \inlinecode{ImgIterator}\iclclassref{Core}{ImgIterator}. We defined a benchmark task for the comparison of the iterator class and a simple pointer\footnote{which can also be used as an iterator}. The task was to find the minimum byte-valued pixel of a $1000\times{}1000$-pixel gray image. After some optimizations, we were able to reach the performance of the quiet optimized \inlinecode{std::min\_element} algorithm for the C++-STL\footnote{We compiled with compiler flags \inlinecode{-O4 -march=native -funroll-loops}}. Finding the minimum element using an \icode{ImgIterator}-instance takes about $2$ms (which is pretty fast). However, the corresponding IPP implementation is still about \textbf{20 times} faster.
\end{enumerate}

\section{Simple, easy to use and object orientated interfaces:}
Object-orientated programming (OOP) in C++ provides both high performance due to processor-close programming, as well as a high abstraction level, due to the inherent features of object orientation. In particular, inheritance and data/function encapsulation, as well as function- and class-\emph{templating} should be mentioned here. In contrast to the well known open computer vision library \emph{OpenCV}, we use C++ and therefore are able to provide a powerful image class named \inlinecode{Img} \iclclassref{Core}{Img}. To support different data types for image pixels (e.g. one needs byte-pixel-values as well as float-pixel values) without having a large amount of duplicated source code, the \inlinecode{Img}-class is implemented as a class template.\\
Furthermore, most other functionalities are implemented in a object orientated manner. For example, one can instantiate  \inlinecode{FileGrabber}- \iclclassref{IO}{FileGrabber}, \inlinecode{Filter} \iclclassref{Filter}{UnaryOp}- or \inlinecode{Converter} \iclclassref{CC}{Converter}- Objects that provide easy-to-use interfaces to \emph{grab} the next image, to apply a filter on an image or to convert an image.\\
To optimize performance, most image-manipulating functions are implemented in \emph{source-destination}-fashion: E.g. Filter-instances\footnote{As elucidated later on, the set of image filters is split into \emph{unary} \iclclassref{Filter}{UnaryOp}- and \emph{binary} \iclclassref{Filter}{BinaryOp}- operators)} offer an \inlinecode{apply}-function, that expects a source- as well as a destination-image as arguments. By this means, data handling can be performed by the user to avoid superfluous memory allocation during run-time. 


\section{Platform-Independence}
Platform independence is achieved by using C++, which can be compiled on all common platforms. Furthermore, ICL has no compulsory software dependencies. ICL has already been successfully compiled on Mac-OSX, Windows\footnote{We used Cygwin for the GNU-autotools make environment} and Linux. We use Linux as our development platform and therefore is currently the best supported. We only use compiler independent C++ (e.g. \inlinecode{#pragma} is not used) in combination with automake\footnote{www.gnu.org/software/automake/} and autoconf\footnote{www.gnu.org/software/autoconf/}.  

 
\section{No Compulsory Software Dependencies}
Even though there are currently more than 10 external software packages that can be included in order to extend ICL's functionality, we have made all dependencies purely optional. In most cases we provide fallback implementations (e.g. for many of the Intel IPP-functions that are used). However, for some specific classes, functions and packages, fallback implementations are not provided. In these cases, the build system is set up to ignore the corresponding source- and header-files. The presence of each external dependency \icode{XYZ} is indicated by a \icode{HAVE_XYZ} definition in the source code. 

\section{A Question of Granularity}
When developing a computer-vision library, one has to make a fundamental decision regarding the complexity of it's components. ICL provides \emph{building blocks} for the development of computer vision applications, but currently it does not provide high-level components like face-trackers or object-detectors. Rather, it supports low- and medium level structures and a large set of (highly optimized) basic algorithms.
We also plan to add more a high level components to the ICLAlgorithms package soon.\\
The development of high-level software components is externalized to the so called \emph{ICLProjects}, which are available in a dedicated svn repository. Only reliable projects will be integrated into the ICL-library. As most of these projects are subject of ongoing research, the ICLProjects repository is not public.

\todo{this chapter has been corrected completely by J.M.}