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. \\
\todo{correct from here on...}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}
\todo{correct from here!}

\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 reached by using C++, which is compilable on all common platforms. Furthermore, ICL has no compulsory software dependencies. Yet, ICL has successfully been compiled on Mac-OSX, Windows\footnote{We used Cygwin for the GNU-autotools make environment} and Linux. The latter one is our development platform, so Linux is currently supported best. We use only compiler independent C++ (e.g. no \inlinecode{#pragma}s) in combination with automake\footnote{www.gnu.org/software/automake/} and autoconf\footnote{www.gnu.org/software/autoconf/}.  

 
\section{No Compulsory Software Dependencies}
Although, there are currently more the 10 external software packages, that can be included to extend ICL's complexity, we made all dependencies purely optional. In some cases we provide fallback implementations e.g. for many of the used Intel IPP-functions. Otherwise some classes, functions or packages are just not available if a dependent software package is not available.

\section{A Question of Granularity}
When developing a computer-vision library, one has to make a fundamental decision regarding the components complexity. 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 plan to add also high level package that will provide such modules, but currently there are no such packages.