Sophie

Sophie

distrib > Mageia > 5 > i586 > by-pkgid > 65f8aa69c4b85eb2463f24ce9ff49b95 > files > 306

cimg-devel-1.5.9-3.mga5.i586.rpm

\hypertarget{group__cimg__faq}{\section{F\+A\+Q \+: Frequently Asked Questions.}
\label{group__cimg__faq}\index{F\+A\+Q \+: Frequently Asked Questions.@{F\+A\+Q \+: Frequently Asked Questions.}}
}
\hypertarget{group__cimg__faq_ssf0}{}\subsection{F\+A\+Q Summary}\label{group__cimg__faq_ssf0}

\begin{DoxyItemize}
\item \href{#sf1}{\tt General information and availability}
\begin{DoxyItemize}
\item \href{#ssf11}{\tt What is the C\+Img Library ?}
\item \href{#ssf12}{\tt What platforms are supported ?}
\item \href{#ssf13}{\tt How is C\+Img distributed ?}
\item \href{#ssf14}{\tt What kind of people are concerned by C\+Img ?}
\item \href{#ssf15}{\tt What are the specificities of the Ce\+C\+I\+L\+L license ?}
\item \href{#ssf16}{\tt Who is behind C\+Img ?}
\end{DoxyItemize}
\item \href{#sf2}{\tt C++ related questions}
\begin{DoxyItemize}
\item \href{#ssf21}{\tt What is the level of C++ knowledge needed to use C\+Img ?}
\item \href{#ssf22}{\tt How to use C\+Img in my own C++ program ?}
\item \href{#ssf23}{\tt Why is C\+Img entirely contained in a single header file ?}
\end{DoxyItemize}
\item \href{#sf3}{\tt Other resources}
\begin{DoxyItemize}
\item \href{#ssf31}{\tt Translations}
\end{DoxyItemize}
\end{DoxyItemize}\hypertarget{group__cimg__faq_sf1}{}\subsection{1. General information and availability}\label{group__cimg__faq_sf1}
\hypertarget{group__cimg__faq_ssf11}{}\subsubsection{1.\+1. What is the C\+Img Library ?}\label{group__cimg__faq_ssf11}
The C\+Img Library is an {\itshape open-\/source C++ toolkit for image processing}.~\newline
 It mainly consists in a (big) single header file \href{http://cimg.cvs.sourceforge.net/cimg/CImg/CImg.h?view=markup}{\tt C\+Img.\+h} providing a set of C++ classes and functions that can be used in your own sources, to load/save, manage/process and display generic images. It's actually a very simple and pleasant toolkit for coding image processing stuffs in C++ \+: Just include the header file {\ttfamily C\+Img.\+h}, and you are ready to handle images in your C++ programs.\hypertarget{group__cimg__faq_ssf12}{}\subsubsection{1.\+2. What platforms are supported ?}\label{group__cimg__faq_ssf12}
C\+Img has been designed with {\itshape portability} in mind. It is regularly tested on different architectures and compilers, and should also work on any decent O\+S having a decent C++ compiler. Before each release, the C\+Img Library is compiled under these different configurations \+: \begin{DoxyItemize}
\item P\+C Linux 32 bits, with g++. \item P\+C Windows 32 bits, with Visual C++ 6.\+0. \item P\+C Windows 32 bits, with Visual C++ Express Edition. \item Sun S\+P\+A\+R\+C Solaris 32 bits, with g++. \item Mac P\+P\+C with O\+S X and g++.\end{DoxyItemize}
C\+Img has a minimal number of dependencies. In its minimal version, it can be compiled only with standard C++ headers. Anyway, it has interesting extension capabilities and can use external libraries to perform specific tasks more efficiently (Fourier Transform computation using F\+F\+T\+W for instance).\hypertarget{group__cimg__faq_ssf13}{}\subsubsection{1.\+3. How is C\+Img distributed ?}\label{group__cimg__faq_ssf13}
The C\+Img Library is freely distributed as a complete .zip compressed package, hosted at the \href{http://sourceforge.net/project/showfiles.php?group_id=96492}{\tt Sourceforge servers}.~\newline
The package is distributed under the \href{http://www.cecill.info}{\tt Ce\+C\+I\+L\+L license}.

This package contains \+:
\begin{DoxyItemize}
\item The main library file \href{http://cimg.cvs.sourceforge.net/cimg/CImg/CImg.h?view=markup}{\tt C\+Img.\+h} (C++ header file).
\item Several C++ source code showing \href{http://cimg.cvs.sourceforge.net/cimg/CImg/examples/}{\tt examples of using C\+Img}.
\item A complete library documentation, in \href{index.html}{\tt H\+T\+M\+L} and \href{../CImg_reference.pdf}{\tt P\+D\+F} formats.
\item Additional \href{http://cimg.cvs.sourceforge.net/cimg/CImg/plugins/}{\tt library plug-\/ins} that can be used to extend library capabilities for specific uses.
\end{DoxyItemize}

The C\+Img Library is a quite lightweight library which is easy to maintain (due to its particular structure), and thus has a fast rythm of release. A new version of the C\+Img package is released approximately every three months.\hypertarget{group__cimg__faq_ssf14}{}\subsubsection{1.\+4. What kind of people are concerned by C\+Img ?}\label{group__cimg__faq_ssf14}
The C\+Img library is an {\itshape image processing} library, primarily intended for computer scientists or students working in the fields of image processing or computer vision, and knowing bases of C++. As the library is handy and really easy to use, it can be also used by any programmer needing occasional tools for dealing with images in C++, since there are no standard library yet for this purpose.\hypertarget{group__cimg__faq_ssf15}{}\subsubsection{1.\+5. What are the specificities of the Ce\+C\+I\+L\+L license ?}\label{group__cimg__faq_ssf15}
The \href{http://www.cecill.info}{\tt Ce\+C\+I\+L\+L license} governs the use of the C\+Img Library. This is an {\itshape open-\/source} license which gives you rights to access, use, modify and redistribute the source code, under certains conditions. There are two different variants of the Ce\+C\+I\+L\+L license used in C\+Img (namely \href{http://www.cecill.info/licences/Licence_CeCILL_V2-en.html}{\tt Ce\+C\+I\+L\+L} and \href{http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html}{\tt Ce\+C\+I\+L\+L-\/\+C}, all open-\/source), corresponding to different constraints on the source files \+:
\begin{DoxyItemize}
\item The \href{http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html}{\tt Ce\+C\+I\+L\+L-\/\+C} license is the most permissive one, close to the {\itshape G\+N\+U L\+G\+P\+L license}, and {\itshape applies {\bfseries only} on the main library file \href{http://cimg.cvs.sourceforge.net/cimg/CImg/CImg.h?view=markup}{\tt C\+Img.\+h}}. Basically, this license allows to use \href{http://cimg.cvs.sourceforge.net/cimg/CImg/CImg.h?view=markup}{\tt C\+Img.\+h} in a closed-\/source product without forcing you to redistribute the entire software source code. Anyway, if one modifies the \href{http://cimg.cvs.sourceforge.net/cimg/CImg/CImg.h?view=markup}{\tt C\+Img.\+h} source file, one has to redistribute the modified version of the file that must be governed by the same \href{http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html}{\tt Ce\+C\+I\+L\+L-\/\+C} license.
\item The \href{http://www.cecill.info/licences/Licence_CeCILL_V2-en.html}{\tt Ce\+C\+I\+L\+L} license applies to all other files (source examples, plug-\/ins and documentation) of the C\+Img Library package, and is close (even {\itshape compatible}) with the {\itshape G\+N\+U G\+P\+L license}. It {\itshape does not allow} the use of these files in closed-\/source products.
\end{DoxyItemize}

You are invited to read the complete descriptions of the the \href{http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html}{\tt Ce\+C\+I\+L\+L-\/\+C} and \href{http://www.cecill.info/licences/Licence_CeCILL_V2-en.html}{\tt Ce\+C\+I\+L\+L} licenses before releasing a software based on the C\+Img Library.\hypertarget{group__cimg__faq_ssf16}{}\subsubsection{1.\+6. Who is behind C\+Img ?}\label{group__cimg__faq_ssf16}
C\+Img has been started by \href{http://tschumperle.users.greyc.fr/}{\tt David Tschumperle} at the beginning of his Ph\+D thesis, in October 1999. He is still the main coordinator of the project. Since the first release at Sourceforge, a growing number of contributors has appeared. Due to the very simple and compact form of the library, submitting a contribution is quite easy and can be fastly integrated into the supported releases. List of contributors can be found on the front page.\hypertarget{group__cimg__faq_sf2}{}\subsection{2. C++ related questions}\label{group__cimg__faq_sf2}
\hypertarget{group__cimg__faq_ssf21}{}\subsubsection{2.\+1 What is the level of C++ knowledge needed to use C\+Img ?}\label{group__cimg__faq_ssf21}
The C\+Img Library has been designed using C++ templates and object-\/oriented programming techniques, but in a very accessible level. There are only public classes without any derivation (just like C structures) and there is at most one template parameter for each C\+Img class (defining the pixel type of the images). The design is simple but clean, making the library accessible even for non professional C++ programmers, while proposing strong extension capabilities for C++ experts.\hypertarget{group__cimg__faq_ssf22}{}\subsubsection{2.\+2 How to use C\+Img in my own C++ program ?}\label{group__cimg__faq_ssf22}
Basically, you need to add these two lines in your C++ source code, in order to be able to work with C\+Img images \+: 
\begin{DoxyCode}
\textcolor{preprocessor}{#include "CImg.h"}
\textcolor{keyword}{using namespace }\hyperlink{namespacecimg__library}{cimg\_library};
\end{DoxyCode}
\hypertarget{group__cimg__faq_ssf23}{}\subsubsection{2.\+3 Why is C\+Img entirely contained in a single header file ?}\label{group__cimg__faq_ssf23}
People are often surprised to see that the complete code of the library is contained in a single (big) C++ header file \href{http://cimg.cvs.sourceforge.net/cimg/CImg/CImg.h?view=markup}{\tt C\+Img.\+h}. There are good practical and technical reasons to do that. Some arguments are listed below to justify this approach, so (I hope) you won't think this is a awkwardly C++ design of the C\+Img library \+:~\newline

\begin{DoxyItemize}
\item First, the library is based on {\itshape template datatypes} (images with generic pixel type), meaning that the programmer is free to decide what type of image he instanciates in his code. Even if there are roughly a limited number of fully supported types (basically, the \char`\"{}atomic\char`\"{} types of C++ \+: {\itshape unsigned char, int, float, ...}), this is {\itshape not imaginable} to pre-\/compile the library classes and functions for {\itshape all possible atomic datatypes}, since many functions and methods can have two or three arguments having different template parameters. This really means {\itshape a huge number} of possible combinations. The size of the object binary file generated to cover all possible cases would be just {\itshape colossal}. Is the S\+T\+L library a pre-\/compiled one ? No, C\+Img neither. C\+Img is not using a classical {\itshape .cpp} and {\itshape .h} mechanism, just like the S\+T\+L. Architectures of C++ {\itshape template-\/based} libraries are somewhat special in this sense. This is a proven technical fact.
\item Second, why C\+Img does not have several header files, just like the S\+T\+L does (one for each class for instance) ? This would be possible of course. There are only 4 classes in C\+Img, the two most important being {\itshape C\+Img$<$\+T$>$} and {\itshape C\+Img\+List$<$\+T$>$} representing respectively an image and a collection of images. But contrary to the S\+T\+L library, these two C\+Img classes are strongly {\itshape inter-\/dependent}. All C\+Img algorithms are actually not defined as separate functions acting on containers (as the S\+T\+L does with his header $<$algorithm$>$), but are directly methods of the image and image collection classes. This inter-\/dependence practically means that you will undoubtly need these two main classes at the same time if you are using C\+Img. If they were defined in separate header files, you would be forced to include both of them. What is the gain then ? No gain.~\newline
Concerning the two other classes \+: You can disable the third most important class {\itshape C\+Img\+Display} of the C\+Img library, by setting the compilation macro {\itshape cimg\+\_\+display} to 0, avoiding thus to compile this class if you don't use display capabilities of C\+Img in your code. But to be honest, this is a quite small class and doing this doesn't save much compilation time. The last and fourth class is {\itshape C\+Img\+Exception}, which is only few lines long and is obviously required in almost all methods of C\+Img. Including this one is {\itshape mandatory}.~\newline
As a consequence, having a single header file instead of several ones is just a way for you to avoid including all of them, without any consequences on compilation time. This is both good technical and practical reasons to do like this.
\item Third, having a single header file has plenty of advantages \+: Simplicity for the user, and for the developers (maintenance is in fact easier). Look at the {\ttfamily C\+Img.\+h} file, it looks like a mess at a first glance, but it is in fact very well organized and structured. Finding pieces of code in C\+Img functions or methods is particularly easy and fast. Also, how about the fact that library installation problems just disappear ? Just bring {\ttfamily C\+Img.\+h} with you, put it in your source directory, and the library is ready to go !
\end{DoxyItemize}

I admit the compilation time of C\+Img-\/based programs can be sometime long, but don't think that it is due to the fact that you are using a single header file. Using several header files wouldn't arrange anything since you would need all of them. Having a pre-\/compiled library object would be the only solution to speed up compilation time, but it is not possible at all, due to the too much generic nature of the library.\hypertarget{group__cimg__faq_sf3}{}\subsection{3. Other resources}\label{group__cimg__faq_sf3}
\hypertarget{group__cimg__faq_ssf31}{}\subsubsection{3.\+1 Translations}\label{group__cimg__faq_ssf31}
This F\+A\+Q has been translated to \href{http://science.webhostinggeeks.com/cimg-biblioteka}{\tt Serbo-\/\+Croatian} language by \href{http://webhostinggeeks.com/}{\tt Web Geeks }.