diff -urN CImg-1-19.orig/CHANGES.txt CImg-1-19/CHANGES.txt --- CImg-1-19.orig/CHANGES.txt Tue Mar 6 15:17:06 2007 +++ CImg-1-19/CHANGES.txt Mon Mar 5 18:56:32 2007 @@ -13,10 +13,8 @@ *----------------------------- * New features : - - Added Rice noise distribution in 'CImg::noise()' (thanks to H.E Assemlal). - Added functions 'CImg::sharpen()' and 'CImg::get_sharpen()' that can enhance contrast in images, using nonlinear 2D/3D multi-valued shock filters. - - Added function 'CImgStats::is_empty()' to check is a stat object has been initialized or not. - Added function 'CImg::contains()' and 'CImgList::contains()' that can test if a pixel is present in an image. - Added new demo 'CImg-breakout' in 'examples/CImg_demo.cpp' (Arkanoid-style game in 64 lines of code!). diff -urN CImg-1-19.orig/CImg.h CImg-1-19/CImg.h --- CImg-1-19.orig/CImg.h Tue Mar 6 15:17:06 2007 +++ CImg-1-19/CImg.h Thu Mar 8 15:09:44 2007 @@ -35,6 +35,7 @@ # knowledge of the CeCILL-C license and that you accept its terms. # */ + #ifndef cimg_version #define cimg_version 1.19 @@ -17075,7 +17076,7 @@ if (endian_swap) cimg::endian_swap(buf.ptr(),sizev); res.set_vector_at(buf,x,y,z); } } - if (!file) cimg::fclose(file); + if (!file) cimg::fclose(nfile); return res; } @@ -20038,13 +20039,13 @@ #define cimg_load_cimg_case(Ts,Tss) \ if (!loaded && !cimg::strcasecmp(Ts,tmp2)) for (unsigned int l=0; l0) { \ - Tss *buf = new Tss[w*h*z*k]; cimg::fread(buf,w*h*z*k,nfile); \ + Tss *buf = new Tss[w*h*z*k]; cimg::fread(buf,w*h*z*k,file); \ if (endian) cimg::endian_swap(buf,w*h*z*k); \ - CImg idest(w,h,z,k); \ - cimg_foroff(idest,off) idest[off] = (T)(buf[off]); idest.swap(res[l]); \ + CImg idest(w,h,z,k); cimg_foroff(idest,off) \ + idest[off] = (T)(buf[off]); idest.swap(res[l]); \ delete[] buf; \ } \ loaded = true; \ @@ -21548,6 +21549,775 @@ #ifdef CreateWindowA #undef CreateWindowA #endif + +/* + #------------------------------------------------------------------------------------ + # + # + # Additional documentation for the generation of the reference page (using doxygen) + # + # + #------------------------------------------------------------------------------------ + */ + +/** + \mainpage + + This is the reference documentation of the CImg Library, + the C++ template image processing library. + This documentation have been generated using the tool doxygen. + It contains a detailed description of all classes and functions of the %CImg Library. + If you have downloaded the CImg package, you actually have a local copy of these pages in the + \c CImg/documentation/reference/ directory. + + Use the menu above to navigate through the documentation pages. + As a first step, you may look at the list of available modules. + + A complete PDF version of this reference documentation is + available here for off-line reading. + + You may be interested also in the + presentation slides presenting an overview + of the %CImg Library capabilities. + +**/ + +/** \addtogroup cimg_structure CImg Library Overview */ +/*@{*/ +/** + \page foo2 + + The CImg Library is an image processing library, designed for C++ programmers. + It provides useful classes and functions to load/save, display and process various types of images. + + \section s1 Library structure + + The %CImg Library consists in a single header file CImg.h providing a set of C++ template classes that + can be used in your own sources, to load/save, process and display images or list of images. + Very portable (Unix/X11,Windows, MacOS X, FreeBSD,..), efficient, simple to use, it's a pleasant toolkit + for coding image processing stuffs in C++. + + The header file CImg.h contains all the classes and functions that compose the library itself. + This is one originality of the %CImg Library. This particularly means that : + - No pre-compilation of the library is needed, since the compilation of the CImg functions is done at the same time as + the compilation of your own C++ code. + - No complex dependencies have to be handled : Just include the CImg.h file, and you get a working C++ image processing toolkit. + - The compilation is done on the fly : only CImg functionalities really used by your program are compiled and appear in the + compiled executable program. This leads to very compact code, without any unused stuffs. + - Class members and functions are inlined, leading to better performance during the program execution. + + The %CImg Library is structured as follows : + + - All library classes and functions are defined in the namespace \ref cimg_library. This namespace + encapsulates the library functionalities and avoid any class name collision that could happen with + other includes. Generally, one uses this namespace as a default namespace : + \code + #include "CImg.h" + using namespace cimg_library; + ... + \endcode + + - The namespace \ref cimg_library::cimg defines a set of \e low-level functions and variables used by the library. + Documented functions in this namespace can be safely used in your own program. But, \b never use the + \ref cimg_library::cimg namespace as a default namespace, since it contains functions whose names are already + defined in the standard C/C++ library. + + - The class \ref cimg_library::CImg represents images up to 4-dimensions wide, containing pixels of type \c T + (template parameter). This is actually the main class of the library. + + - The class \ref cimg_library::CImgList represents lists of cimg_library::CImg images. It can be used for instance + to store different frames of an image sequence. + + - The class \ref cimg_library::CImgDisplay is able to display images or image lists into graphical display windows. + As you may guess, the code of this class is highly system-dependent but this is transparent for the programmer, + as environment variables are automatically set by the CImg library (see also \ref cimg_environment). + + - The class \ref cimg_library::CImgStats represents image statistics. Use it to compute the + minimum, maximum, mean and variance of pixel values of images, as well as the corresponding min/max pixel location. + + - The class \ref cimg_library::CImgException (and its subclasses) are used by the library to throw exceptions + when errors occur. Those exceptions can be catched with a bloc try { ..} catch (CImgException) { .. }. + Subclasses define precisely the type of encountered errors. + + Knowing these five classes is \b enough to get benefit of the %CImg Library functionalities. + + + \section s2 CImg version of "Hello world". + + Below is a very simple code that creates a "Hello World" image. This shows you basically how a CImg program looks like. + + \code + #include "CImg.h" + using namespace cimg_library; + + int main() { + CImg img(640,400,1,3); // Define a 640x400 color image with 8 bits per color component. + img.fill(0); // Set pixel values to 0 (color : black) + unsigned char purple[3]={255,0,255}; // Define a purple color + img.draw_text("Hello World",100,100,purple); // Draw a purple "Hello world" at coordinates (100,100). + img.display("My first CImg code"); // Display the image in a display window. + return 0; + } + \endcode + + Which can be also written in a more compact way as : + + \code + #include "CImg.h" + using namespace cimg_library; + + int main() { + const unsigned char purple[3]={255,0,255}; + CImg(640,400,1,3,0).draw_text("Hello World",100,100,purple).display("My first CImg code"); + return 0; + } + \endcode + + Generally, you can write very small code that performs complex image processing tasks. The %CImg Library is very simple + to use and provide a lot of interesting algorithms for image manipulation. + + \section s3 How to compile ? + + The CImg library is a very light and user-friendly library : only standard system libraries are used. + It avoid to handle complex dependancies and problems with library compatibility. + The only thing you need is a (quite modern) C++ compiler : + + - Microsoft Visual C++ 6.0, Visual Studio.NET and Visual Express Edition : Use project files and solution files provided in the + %CImg Library package (directory 'compilation/') to see how it works. + - Intel ICL compiler : Use the following command to compile a CImg-based program with ICL : + \code + icl /Ox hello_world.cpp user32.lib gdi32.lib + \endcode + - g++ (MingW windows version) : Use the following command to compile a CImg-based program with g++, on Windows : + \code + g++ -o hello_word.exe hello_word.cpp -O2 -lgdi32 + \endcode + - g++ (Linux version) : Use the following command to compile a CImg-based program with g++, on Linux : + \code + g++ -o hello_word.exe hello_world.cpp -O2 -L/usr/X11R6/lib -lm -lpthread -lX11 + \endcode + - g++ (Solaris version) : Use the following command to compile a CImg-based program with g++, on Solaris : + \code + g++ -o hello_word.exe hello_world.cpp -O2 -lm -lpthread -R/usr/X11R6/lib -lrt -lnsl -lsocket + \endcode + - g++ (Mac OS X version) : Use the following command to compile a CImg-based program with g++, on Mac OS X : + \code + g++ -o hello_word.exe hello_world.cpp -O2 -lm -lpthread -L/usr/X11R6/lib -lm -lpthread -lX11 + \endcode + - Dev-Cpp : Use the project file provided in the CImg library package to see how it works. + + If you are using another compilers and encounter problems, please + write me since maintaining compatibility is one + of the priority of the %CImg Library. Nevertheless, old compilers that does not respect the C++ norm will not + support the %CImg Library. + + \section s4 What's next ? + + If you are ready to get more, and to start writing more serious programs + with CImg, you are invited to go to the \ref cimg_tutorial section. + +**/ +/*@}*/ + +/** \addtogroup cimg_faq FAQ : Frequently Asked Questions. */ +/*@{*/ +/** + \page foofaq + + \section sfaq1 FAQ : Frequently Asked Questions. + + TODO + +**/ +/*@}*/ + +/** \addtogroup cimg_environment Setting Environment Variables */ +/*@{*/ +/** + \page foo1 + + The CImg library is a multiplatform library, working on a wide variety of systems. + This implies the existence of some \e environment \e variables that must be correctly defined + depending on your current system. + Most of the time, the %CImg Library defines these variables automatically + (for popular systems). Anyway, if your system is not recognized, you will have to set the environment + variables by hand. Here is a quick explanations of environment variables.\n + + Setting the environment variables is done with the #define keyword. + This setting must be done before including the file CImg.h in your source code. + For instance, + defining the environment variable \c cimg_display_type would be done like this : + \code + #define cimg_display_type 0 + #include "CImg.h" + ... + \endcode + + Here are the different environment variables used by the %CImg Library : + + - \b \c cimg_OS : This variable defines the type of your Operating System. It can be set to \b 1 (\e Unix), + \b 2 (\e Windows), or \b 0 (\e Other \e configuration). + It should be actually auto-detected by the CImg library. If this is not the case (cimg_OS=0), you + will probably have to tune the environment variables described below. + + - \b \c cimg_display_type : This variable defines the type of graphical library used to + display images in windows. It can be set to 0 (no display library available), \b 1 (X11-based display) or + \b 2 (Windows-GDI display). + If you are running on a system without X11 or Windows-GDI ability, please set this variable to \c 0. + This will disable the display support, since the %CImg Library doesn't contain the necessary code to display + images on systems other than X11 or Windows GDI. + + - \b \c cimg_color_terminal : This variable tells the library if the system terminal has VT100 color capabilities. + It can be \e defined or \e not \e defined. Define this variable to get colored output on your terminal, + when using the %CImg Library. + + - \b \c cimg_debug : This variable defines the level of run-time debug messages that will be displayed by + the %CImg Library. It can be set to 0 (no debug messages), 1 (normal debug messages displayed on + standard error), 2 (normal debug messages displayed in modal windows, which is + the default value), or 3 (high debug messages). Note that setting this value to 3 may slow down your + program since more debug tests are made by the library (particularly to check if pixel access is made outside + image boundaries). See also CImgException to better understand how debug messages are working. + + - \b \c cimg_convert_path : This variables tells the library where the ImageMagick's \e convert tool is located. + Setting this variable should not be necessary if ImageMagick is installed on a standard directory, or + if \e convert is in your system PATH variable. This macro should be defined only if the ImageMagick's + \e convert tool is not found automatically, when trying to read compressed image format (GIF,PNG,...). + See also cimg_library::CImg::get_load_convert() and cimg_library::CImg::save_convert() for more informations. + + - \b \c cimg_temporary_path : This variable tells the library where it can find a directory to store + temporary files. Setting this variable should not be necessary if you are running on a standard system. + This macro should be defined only when troubles are encountered when trying to read + compressed image format (GIF,PNG,...). + See also cimg_library::CImg::get_load_convert() and cimg_library::CImg::save_convert() for more informations. + + - \b \c cimg_plugin : This variable tells the library to use a plugin file to add features to the CImg class. + Define it with the path of your plugin file, if you want to add member functions to the CImg class, + without having to modify directly the \c "CImg.h" file. An include of the plugin file is performed in the CImg + class. If \c cimg_plugin if not specified (default), no include is done. + + - \b \c cimglist_plugin : Same as \c cimg_plugin, but to add features to the CImgList class. + + - \b \c cimgdisplay_plugin : Same as \c cimg_plugin, but to add features to the CImgDisplay class. + + - \b \c cimgstats_plugin : Same as \c cimg_plugin, but to add features to the CImgStats class. + + All these compilation variables can be checked, using the function cimg_library::cimg::info(), which + displays a list of the different configuration variables and their values on the standard error output. +**/ +/*@}*/ + +/** \addtogroup cimg_tutorial Tutorial : Getting Started. */ +/*@{*/ +/** + \page foo3 + + Let's start to write our first program to get the idea. This will demonstrate how to load and create images, as well as handle image + display and mouse events. + Assume we want to load a color image lena.jpg, smooth it, display it in a windows, and enter an event loop so that clicking a + point in the image with the mouse will draw the intensity profiles of (R,G,B) of the corresponding image line (in another window). + Yes, that sounds quite complex for a first code, but don't worry, it will be very simple using the CImg library ! Well, just look + at the code below, it does the task : + + \code + #include "CImg.h" + using namespace cimg_library; + + int main() { + CImg image("lena.jpg"), visu(500,400,1,3,0); + const unsigned char red[3]={255,0,0}, green[3]={0,255,0}, blue[3]={0,0,255}; + image.blur(2.5); + CImgDisplay main_disp(image,"Click a point"), draw_disp(visu,"Intensity profile"); + while (!main_disp.is_closed && !draw_disp.is_closed) { + main_disp.wait(); + if (main_disp.button && main_disp.mouse_y>=0) { + const int y = main_disp.mouse_y; + visu.fill(0).draw_graph(image.get_crop(0,y,0,0,image.dimx()-1,y,0,0),red,0,256,0); + visu.draw_graph(image.get_crop(0,y,0,1,image.dimx()-1,y,0,1),green,0,256,0); + visu.draw_graph(image.get_crop(0,y,0,2,image.dimx()-1,y,0,2),blue,0,256,0).display(draw_disp); + } + } + return 0; + } + \endcode + + Here is a screenshot of the resulting program : + + + + And here is the detailled explanation of the source, line by line : + + \code #include "CImg.h" \endcode + Include the main and only header file of the CImg library. + \code using namespace cimg_library; \endcode + Use the library namespace to ease the declarations afterward. + \code int main() { \endcode + Definition of the main function. + \code CImg image("lena.jpg"), visu(500,400,1,3,0); \endcode + Creation of two instances of images of \c unsigned \c char pixels. + The first image \c image is initialized by reading an image file from the disk. + Here, lena.jpg must be in the same directory than the current program. + Note that you must also have installed the \e ImageMagick package in order to be able to read JPG images. + The second image \c visu is initialized as a black color image with dimension dx=500, dy=400, + dz=1 (here, it is a 2D image, not a 3D one), and dv=3 (each pixel has 3 'vector' channels R,G,B). + The last argument in the constructor defines the default value of the pixel values + (here \c 0, which means that \c visu will be initially black). + \code const unsigned char red[3]={255,0,0}, green[3]={0,255,0}, blue[3]={0,0,255}; \endcode + Definition of three different colors as array of unsigned char. This will be used to draw plots with different colors. + \code image.blur(2.5); \endcode + Blur the image, with a gaussian blur and a standard variation of 2.5. Note that most of the CImg functions have two versions : + one that acts in-place (which is the case of blur), and one that returns the result as a new image (the name of the function + begins then with get_ ). In this case, one could have also written image = image.get_blur(2.5); + (more expensive, since it needs an additional copy operation). + \code CImgDisplay main_disp(image,"Click a point"), draw_disp(visu,"Intensity profile"); \endcode + Creation of two display windows, one for the input image image, and one for the image visu which will be display intensity profiles. + By default, CImg displays handles events (mouse,keyboard,..). On Windows, there is a way to create fullscreen displays. + \code while (!main_disp.is_closed && !draw_disp.is_closed) { \endcode + Enter the event loop, the code will exit when one of the two display windows is closed. + \code main_disp.wait(); \endcode + Wait for an event (mouse, keyboard,..) in the display window \c main_disp. + \code if (main_disp.button && main_disp.mouse_y>=0) { \endcode + Test if the mouse button has been clicked on the image area. + One may distinguish between the 3 different mouse buttons, + but in this case it is not necessary + \code const int y = main_disp.mouse_y; \endcode + Get the image line y-coordinate that has been clicked. + \code visu.fill(0).draw_graph(image.get_crop(0,y,0,0,image.dimx()-1,y,0,0),red,0,256,0); \endcode + This line illustrates the pipeline property of most of the CImg class functions. The first function fill(0) simply sets + all pixel values with 0 (i.e. clear the image \c visu). The interesting thing is that it returns a reference to + \c visu and then, can be pipelined with the function \c draw_graph() which draws a plot in the image \c visu. + The plot data are given by another image (the first argument of \c draw_graph()). In this case, the given image is + the red-component of the line y of the original image, retrieved by the function \c get_crop() which returns a + sub-image of the image \c image. Remember that images coordinates are 4D (x,y,z,v) and for color images, + the R,G,B channels are respectively given by v=0, v=1 and v=2. + \code visu.draw_graph(image.get_crop(0,y,0,1,image.dimx()-1,y,0,1),green,0,256,0); \endcode + Plot the intensity profile for the green channel of the clicked line. + \code visu.draw_graph(image.get_crop(0,y,0,2,image.dimx()-1,y,0,2),blue,0,256,0).display(draw_disp); \endcode + Same thing for the blue channel. Note how the function (which return a reference to \c visu) is pipelined with the function + \c display() that just paints the image visu in the corresponding display window. + \code ...till the end \endcode + I don't think you need more explanations ! + + As you have noticed, the CImg library allows to write very small and intuitive code. Note also that this source will perfectly + work on Unix and Windows systems. Take also a look to the examples provided in the CImg package ( + directory \c examples/ ). It will show you how CImg-based code can be surprisingly small. + Moreover, there is surely one example close to what you want to do. + A good start will be to look at the file CImg_demo.cpp which contains small and various examples of what you can do + with the %CImg Library. All CImg classes are used in this source, and the code can be easily modified to see what happens. + +**/ +/*@}*/ + +/** \addtogroup cimg_drawing Using Drawing Functions. */ +/*@{*/ +/** + \page foo5 + + \section s5 Using Drawing Functions. + + This section tells more about drawing features in CImg images. + Drawing functions list can be found in the CImg functions list + (section \b Drawing Functions), + and are all defined on a common basis. Here are the important points to understand before using + drawing functions : + + - Drawing is performed on the instance image. Drawing functions parameters + are defined as \e const variables and return a reference to the current instance (*this), + so that drawing functions can be pipelined (see examples below). + Drawing is usually done in 2D color images but can be performed in 3D images with any vector-valued dimension, + and with any possible pixel type. + + - A color parameter is always needed to draw features in an image. The color must be defined as a C-style array + whose dimension is at least + +**/ +/*@}*/ + +/** \addtogroup cimg_loops Using Image Loops. */ +/*@{*/ +/** + \page foo_lo + The %CImg Library provides different macros that define useful iterative loops over an image. + Basically, it can be used to replace one or several for(..) instructions, but it also proposes + interesting extensions to classical loops. + Below is a list of all existing loop macros, classified in four different categories : + - \ref lo1 + - \ref lo4 + - \ref lo5 + - \ref lo6 + + \section lo1 Loops over the pixel buffer + + Loops over the pixel buffer are really basic loops that iterate a pointer on the pixel data buffer + of a \c cimg_library::CImg image. Two macros are defined for this purpose : + + - \b cimg_for(img,ptr,T) : + This macro loops over the pixel data buffer of the image \c img, using a pointer T* ptr, + starting from the end of the buffer (last pixel) till the beginning of the buffer (first pixel). + - \c img must be a (non empty) \c cimg_library::CImg image of pixels \c T. + - \c ptr is a pointer of type \c T*. + This kind of loop should not appear a lot in your own source code, since this is a low-level loop + and many functions of the CImg class may be used instead. Here is an example of use : + \code + CImg img(320,200); + cimg_for(img,ptr,float) { *ptr=0; } // Equivalent to 'img.fill(0);' + \endcode + + - \b cimg_foroff(img,off) : + This macro loops over the pixel data buffer of the image \c img, using an offset \c , + starting from the beginning of the buffer (first pixel, \c off=0) + till the end of the buffer (last pixel value, off = img.size()-1). + - \c img must be a (non empty) cimg_library::CImg image of pixels \c T. + - \c off is an inner-loop variable, only defined inside the scope of the loop. + + Here is an example of use : + \code + CImg img(320,200); + cimg_foroff(img,off) { img[off]=0; } // Equivalent to 'img.fill(0);' + \endcode + + \section lo4 Loops over image dimensions + + The following loops are probably the most used loops in image processing programs. + They allow to loop over the image along one or several dimensions, along a raster scan course. + Here is the list of such loop macros for a single dimension : + - \b cimg_forX(img,x) : equivalent to : for (int x=0; x. + - \b cimg_forY(img,y) : equivalent to : for (int y=0; y. + - \b cimg_forZ(img,z) : equivalent to : for (int z=0; z. + - \b cimg_forV(img,v) : equivalent to : for (int v=0; v. + + Combinations of these macros are also defined as other loop macros, allowing to loop directly over 2D, 3D or 4D images : + - \b cimg_forXY(img,x,y) : equivalent to : \c cimg_forY(img,y) \c cimg_forX(img,x). + - \b cimg_forXZ(img,x,z) : equivalent to : \c cimg_forZ(img,z) \c cimg_forX(img,x). + - \b cimg_forYZ(img,y,z) : equivalent to : \c cimg_forZ(img,z) \c cimg_forY(img,y). + - \b cimg_forXV(img,x,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forX(img,x). + - \b cimg_forYV(img,y,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forY(img,y). + - \b cimg_forZV(img,z,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forZ(img,z). + - \b cimg_forXYZ(img,x,y,z) : equivalent to : \c cimg_forZ(img,z) \c cimg_forXY(img,x,y). + - \b cimg_forXYV(img,x,y,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forXY(img,x,y). + - \b cimg_forXZV(img,x,z,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forXZ(img,x,z). + - \b cimg_forYZV(img,y,z,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forYZ(img,y,z). + - \b cimg_forXYZV(img,x,y,z,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forXYZ(img,x,y,z). + + - For all these loops, \c x,\c y,\c z and \c v are inner-defined variables only visible inside the scope of the loop. + They don't have to be defined before the call of the macro. + - \c img must be a (non empty) cimg_library::CImg image. + + Here is an example of use that creates an image with a smooth color gradient : + \code + CImg img(256,256,1,3); // Define a 256x256 color image + cimg_forXYV(img,x,y,v) { img(x,y,v) = (x+y)*(v+1)/6; } + img.display("Color gradient"); + \endcode + + \section lo5 Loops over interior regions and borders. + + Similar macros are also defined to loop only on the border of an image, or inside the image (excluding the border). + The border may be several pixel wide : + + - \b cimg_for_insideX(img,x,n) : Loop along the x-axis, except for pixels inside a border of \p n pixels wide. + - \b cimg_for_insideY(img,y,n) : Loop along the y-axis, except for pixels inside a border of \p n pixels wide. + - \b cimg_for_insideZ(img,z,n) : Loop along the z-axis, except for pixels inside a border of \p n pixels wide. + - \b cimg_for_insideV(img,v,n) : Loop along the v-axis, except for pixels inside a border of \p n pixels wide. + - \b cimg_for_insideXY(img,x,y,n) : Loop along the (x,y)-axes, excepted for pixels inside a border of \p n pixels wide. + - \b cimg_for_insideXYZ(img,x,y,z,n) : Loop along the (x,y,z)-axes, excepted for pixels inside a border of \p n pixels wide. + + And also : + + - \b cimg_for_borderX(img,x,n) : Loop along the x-axis, only for pixels inside a border of \p n pixels wide. + - \b cimg_for_borderY(img,y,n) : Loop along the y-axis, only for pixels inside a border of \p n pixels wide. + - \b cimg_for_borderZ(img,z,n) : Loop along the z-axis, only for pixels inside a border of \p n pixels wide. + - \b cimg_for_borderV(img,v,n) : Loop along the z-axis, only for pixels inside a border of \p n pixels wide. + - \b cimg_for_borderXY(img,x,y,n) : Loop along the (x,y)-axes, only for pixels inside a border of \p n pixels wide. + - \b cimg_for_borderXYZ(img,x,y,z,n) : Loop along the (x,y,z)-axes, only for pixels inside a border of \p n pixels wide. + + - For all these loops, \c x,\c y,\c z and \c v are inner-defined variables only visible inside the scope of the loop. + They don't have to be defined before the call of the macro. + - \c img must be a (non empty) cimg_library::CImg image. + - The constant \c n stands for the size of the border. + + Here is an example of use, to create a 2d grayscale image with two different intensity gradients : + \code + CImg<> img(256,256); + cimg_for_insideXY(img,x,y,50) img(x,y) = x+y; + cimg_for_borderXY(img,x,y,50) img(x,y) = x-y; + img.display(); + \endcode + + \section lo6 Loops using neighborhoods. + + Inside an image loop, it is often useful to get values of neighborhood pixels of the + current pixel at the loop location. + The %CImg Library provides a very smart and fast mechanism for this purpose, with the definition + of several loop macros that remember the neighborhood values of the pixels. + The use of these macros can highly optimize your code, and also simplify your program. + + \subsection lo7 Neighborhood-based loops for 2D images + + For 2D images, the neighborhood-based loop macros are : + + - \b cimg_for2x2(img,x,y,z,v,I) : Loop along the (x,y)-axes using a centered 2x2 neighborhood. + - \b cimg_for3x3(img,x,y,z,v,I) : Loop along the (x,y)-axes using a centered 3x3 neighborhood. + - \b cimg_for4x4(img,x,y,z,v,I) : Loop along the (x,y)-axes using a centered 4x4 neighborhood. + - \b cimg_for5x5(img,x,y,z,v,I) : Loop along the (x,y)-axes using a centered 5x5 neighborhood. + + For all these loops, \c x and \c y are inner-defined variables only visible inside the scope of the loop. + They don't have to be defined before the call of the macro. + \c img is a non empty CImg image. \c z and \c v are constants that define on which image slice and + vector channel the loop must apply (usually both 0 for grayscale 2D images). + Finally, \c I is the 2x2, 3x3, 4x4 or 5x5 neighborhood that will be updated with the correct pixel values + during the loop (see \ref lo9). + + \subsection lo8 Neighborhood-based loops for 3D images + + For 3D images, the neighborhood-based loop macros are : + + - \b cimg_for2x2x2(img,x,y,z,v,I) : Loop along the (x,y,z)-axes using a centered 2x2x2 neighborhood. + - \b cimg_for3x3x3(img,x,y,z,v,I) : Loop along the (x,y,z)-axes using a centered 3x3x3 neighborhood. + + For all these loops, \c x, \c y and \c z are inner-defined variables only visible inside the scope of the loop. + They don't have to be defined before the call of the macro. + \c img is a non empty CImg image. \c v is a constant that defines on which image channel + the loop must apply (usually 0 for grayscale 3D images). + Finally, \c I is the 2x2x2 or 3x3x3 neighborhood that will be updated with the correct pixel values + during the loop (see \ref lo9). + + \subsection lo9 Defining neighborhoods + + The CImg library defines a neighborhood as a set of named \e variables or \e references, declared + using specific CImg macros : + + - \b CImg_2x2(I,type) : Define a 2x2 neighborhood named \c I, of type \c type. + - \b CImg_3x3(I,type) : Define a 3x3 neighborhood named \c I, of type \c type. + - \b CImg_4x4(I,type) : Define a 4x4 neighborhood named \c I, of type \c type. + - \b CImg_5x5(I,type) : Define a 5x5 neighborhood named \c I, of type \c type. + - \b CImg_2x2x2(I,type) : Define a 2x2x2 neighborhood named \c I, of type \c type. + - \b CImg_3x3x3(I,type) : Define a 3x3x3 neighborhood named \c I, of type \c type. + + Actually, \c I is a \e generic \e name for the neighborhood. In fact, these macros declare + a \e set of new variables. + For instance, defining a 3x3 neighborhood \c CImg_3x3(I,float) declares 9 different float variables + \c Ipp,\c Icp,\c Inp,\c Ipc,\c Icc,\c Inc,\c Ipn,\c Icn,\c Inn which correspond to each pixel value of + a 3x3 neighborhood. + Variable indices are \c p,\c c or \c n, and stand respectively for \e 'previous', \e 'current' and \e 'next'. + First indice denotes the \c x-axis, second indice denotes the \c y-axis. + Then, the names of the variables are directly related to the position of the corresponding pixels + in the neighborhood. For 3D neighborhoods, a third indice denotes the \c z-axis. + Then, inside a neighborhood loop, you will have the following equivalence : + - Ipp = img(x-1,y-1) + - Icn = img(x,y+1) + - Inp = img(x+1,y-1) + - Inpc = img(x+1,y-1,z) + - Ippn = img(x-1,y-1,z+1) + - and so on... + + For bigger neighborhoods, such as 4x4 or 5x5 neighborhoods, two additionnal indices are introduced : + \c a (stands for \e 'after') and \c b (stands for \e 'before'), so that : + - Ibb = img(x-2,y-2) + - Ina = img(x+1,y+2) + - and so on... + + The value of a neighborhood pixel outside the image range (image border problem) is automatically set to the same + values than the nearest valid pixel in the image (this is also called the \e Neumann \e border \e condition). + + \subsection lo10 Neighborhood as a reference + It is also possible to define neighborhood variables as references to classical C-arrays or CImg images, instead of + allocating new variables. This is done by adding \c _ref to the macro names used for the neighborhood definition : + + - \b CImg_2x2x1_ref(I,type,tab) : Define a 2x2 neighborhood named \c I, of type \c type, as a reference to \c tab. + - \b CImg_3x3x1_ref(I,type,tab) : Define a 3x3 neighborhood named \c I, of type \c type, as a reference to \c tab. + - \b CImg_4x4x1_ref(I,type,tab) : Define a 4x4 neighborhood named \c I, of type \c type, as a reference to \c tab. + - \b CImg_5x5x1_ref(I,type,tab) : Define a 5x5 neighborhood named \c I, of type \c type, as a reference to \c tab. + - \b CImg_2x2x2_ref(I,type,tab) : Define a 2x2x2 neighborhood named \c I, of type \c type, as a reference to \c tab. + - \b CImg_3x3x3_ref(I,type,tab) : Define a 3x3x3 neighborhood named \c I, of type \c type, as a reference to \c tab. + + \c tab can be a one-dimensionnal C-style array, or a non empty \c CImg image. Both objects must have + same sizes as the considered neighborhoods. + + \subsection lo11 Example codes + More than a long discussion, the above example will demonstrate how to compute the gradient norm of a 3D volume + using the \c cimg_for3x3x3() loop macro : + + \code + CImg volume("IRM.hdr"); // Load an IRM volume from an Analyze7.5 file + CImg_3x3x3(I,float); // Define a 3x3x3 neighborhood + CImg gradnorm(volume); // Create an image with same size as 'volume' + cimg_for3x3x3(volume,x,y,z,0,I) { // Loop over the volume, using the neighborhood I + const float ix = 0.5f*(Incc-Ipcc); // Compute the derivative along the x-axis. + const float iy = 0.5f*(Icnc-Icpc); // Compute the derivative along the y-axis. + const float iz = 0.5f*(Iccn-Iccp); // Compute the derivative along the z-axis. + gradnorm(x,y,z) = std::sqrt(ix*ix+iy*iy+iz*iz); // Set the gradient norm in the destination image + } + gradnorm.display("Gradient norm"); + \endcode + + And the following example shows how to deal with neighborhood references to blur a color image by averaging + pixel values on a 5x5 neighborhood. + + \code + CImg src("image_color.jpg"), dest(src,false), neighbor(5,5); // Image definitions. + typedef unsigned char uchar; // Avoid space in the second parameter of the macro CImg_5x5x1 below. + CImg_5x5x1_ref(N,uchar,neighbor); // Define a 5x5 neighborhood as a reference to the 5x5 image neighbor. + cimg_forV(src,k) // Standard loop on color channels + cimg_for5x5(src,x,y,0,k,N) // 5x5 neighborhood loop. + dest(x,y,k) = neighbor.sum()/(5*5); // Averaging pixels to filter the color image. + CImgList visu(src,dest); + visu.display("Original + Filtered"); // Display both original and filtered image. + \endcode + + Note that in this example, we didn't use directly the variables Nbb,Nbp,..,Ncc,... since + there are only references to the neighborhood image \c neighbor. We rather used a member function of \c neighbor. + + As you can see, explaining the use of the CImg neighborhood macros is actually more difficult than using them ! + +**/ +/*@}*/ + +/** \addtogroup cimg_displays Using Display Windows. */ +/*@{*/ +/** + \page foo_di + + When opening a display window, you can choose the way the pixel values will be normalized + before being displayed on the screen. Screen displays only support color values between [0,255], + and some + + When displaying an image into the display window using CImgDisplay::display(), values of + the image pixels can be eventually linearly normalized between [0,255] for visualization purposes. + This may be useful for instance when displaying \p CImg images with pixel values + between [0,1]. + The normalization behavior depends on the value of \p normalize which can be either \p 0,\p 1 or \p 2 : + - \p 0 : No pixel normalization is performed when displaying an image. This is the fastest + process, but you must be sure your displayed image have pixel values inside the range [0,255]. + - \p 1 : Pixel value normalization is done for each new image display. Image pixels are + not modified themselves, only displayed pixels are normalized. + - \p 2 : Pixel value normalization is done for the first image display, then the + normalization parameters are kept and used for all the next image displays. + +**/ +/*@}*/ + +/** \addtogroup cimg_storage How pixel data are stored with CImg. */ +/*@{*/ +/** + \page foo_store + + TODO +**/ +/*@}*/ + +/** \addtogroup cimg_files_io Files IO in CImg. */ +/*@{*/ +/** + \page foo_fi + + The %CImg Library can NATIVELY handle the following file formats : + - RAW : consists in a very simple header (in ascii), then the image data. + - ASC (Ascii) + - HDR (Analyze 7.5) + - INR (Inrimage) + - PPM/PGM (Portable Pixmap) + - BMP (uncompressed) + - PAN (Pandore-5) + - DLM (Matlab ASCII) + + If ImageMagick is installed, The %CImg Library can save image in formats handled by ImageMagick : JPG, GIF, PNG, TIF,... + +**/ +/*@}*/ + +/** \addtogroup cimg_options Retrieving Command Line Arguments. */ +/*@{*/ +/** + \page foo_so + + The CImg library offers facilities to retrieve command line arguments in a console-based + program, as it is a commonly needed operation. + Three macros \c cimg_usage(), \c cimg_help() and \c cimg_option() are defined for this purpose. + Using these macros allows to easily retrieve options values from the command line. + Invoking the compiled executable with the option \c -h or \c --help will + automatically display the program usage, followed by the list of requested options. + + \section so1 The cimg_usage() macro + + The macro \c cimg_usage(usage) may be used to describe the program goal and usage. + It is generally inserted one time after the int main(int argc,char **argv) definition. + + \param usage : A string describing the program goal and usage. + \pre The function where \c cimg_usage() is used must have correctly defined \c argc and \c argv variables. + + \section so1_5 The cimg_help() macro + + The macro \c cimg_help(str) will display the string \c str only if the \c -help or \c --help option + are invoked when running the programm. + + \section so2 The cimg_option() macro + + The macro \c cimg_option(name,default,usage) may be used to retrieve an option value from the command line. + + \param name : The name of the option to be retrieved from the command line. + \param default : The default value returned by the macro if no options \p name has been specified when running the program. + \param usage : A brief explanation of the option. If \c usage==0, the option won't appear on the option list + when invoking the executable with options \c -h or \c --help (hidden option). + + \return \c cimg_option() returns an object that has the \e same \e type than the default value \c default. + The return value is equal to the one specified on the command line. If no such option have been specified, + the return value is equal to the default value \c default. + Warning, this can be confusing in some situations (look at the end of the next section). + \pre The function where \c cimg_option() is used must have correctly defined \c argc and \c argv variables. + + \section so3 Example of use + + The code below uses the macros \c cimg_usage() and \c cimg_option(). + It loads an image, smoothes it an quantifies it with a specified number of values. + \code + #include "CImg.h" + using namespace cimg_library; + int main(int argc,char **argv) { + cimg_usage("Retrieve command line arguments"); + const char* filename = cimg_option("-i","image.gif","Input image file"); + const char* output = cimg_option("-o",(char*)0,"Output image file"); + const double sigma = cimg_option("-s",1.0,"Standard variation of the gaussian smoothing"); + const int nblevels = cimg_option("-n",16,"Number of quantification levels"); + const bool hidden = cimg_option("-hidden",false,0); // This is a hidden option + + CImg img(filename); + img.blur(sigma).quantize(nblevels); + if (output) img.save(output); else img.display("Output image"); + if (hidden) std::fprintf(stderr,"You found me !\n"); + return 0; + } + \endcode + + Invoking the corresponding executable with test -h -hidden -n 20 -i foo.jpg will display : + \verbatim + ./test -h -hidden -n 20 -i foo.jpg + + test : Retrieve command line arguments (Oct 16 2004, 12:34:26) + + -i = foo.jpg : Input image file + -o = 0 : Output image file + -s = 1 : Standard variation of the gaussian smoothing + -n = 20 : Number of quantification levels + + You found me ! +\endverbatim + + \warning As the type of object returned by the macro \c cimg_option(option,default,usage) + is defined by the type of \c default, undesired casts may appear when writting code such as : + \code + const double sigma = cimg_option("-val",0,"A floating point value"); + \endcode + In this case, \c sigma will always be equal to an integer (since the default value \c 0 is an integer). + When passing a float value on the command line, a \e float \e to \e integer cast is then done, + truncating the given parameter to an integer value (this is surely not a desired behavior). + You must specify 0.0 as the default value in this case. + + \section so4 How to learn more about command line options ? + You should take a look at the examples examples/inrcast.cpp provided in the %CImg Library package. + This is a command line based image converter which intensively uses the \c cimg_option() and \c cimg_usage() + macros to retrieve command line parameters. +**/ +/*@}*/ #endif diff -urN CImg-1-19.orig/documentation/CImg.doxygen CImg-1-19/documentation/CImg.doxygen --- CImg-1-19.orig/documentation/CImg.doxygen Tue Mar 6 15:17:07 2007 +++ CImg-1-19/documentation/CImg.doxygen Mon Mar 5 18:56:33 2007 @@ -459,7 +459,7 @@ # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = ../CImg.h CImg_documentation.h +INPUT = ../CImg.h # If the value of the INPUT tag contains directories, you can use the # FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp diff -urN CImg-1-19.orig/documentation/CImg_documentation.doxygen CImg-1-19/documentation/CImg_documentation.doxygen --- CImg-1-19.orig/documentation/CImg_documentation.doxygen Tue Mar 6 15:17:07 2007 +++ CImg-1-19/documentation/CImg_documentation.doxygen Thu Jan 1 01:00:00 1970 @@ -1,1237 +0,0 @@ -# Doxyfile 1.4.5 - -# This file describes the settings to be used by the documentation system -# doxygen (www.doxygen.org) for a project -# -# All text after a hash (#) is considered a comment and will be ignored -# The format is: -# TAG = value [value, ...] -# For lists items can also be appended using: -# TAG += value [value, ...] -# Values that contain spaces should be placed between quotes (" ") - -#--------------------------------------------------------------------------- -# Project related configuration options -#--------------------------------------------------------------------------- - -# The PROJECT_NAME tag is a single word (or a sequence of words surrounded -# by quotes) that should identify the project. - -PROJECT_NAME = "The CImg Library" - -# The PROJECT_NUMBER tag can be used to enter a project or revision number. -# This could be handy for archiving the generated documentation or -# if some version control system is used. - -PROJECT_NUMBER = 1.1.9 - -# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) -# base path where the generated documentation will be put. -# If a relative path is entered, it will be relative to the location -# where doxygen was started. If left blank the current directory will be used. - -OUTPUT_DIRECTORY = - -# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create -# 4096 sub-directories (in 2 levels) under the output directory of each output -# format and will distribute the generated files over these directories. -# Enabling this option can be useful when feeding doxygen a huge amount of -# source files, where putting all generated files in the same directory would -# otherwise cause performance problems for the file system. - -CREATE_SUBDIRS = NO - -# The OUTPUT_LANGUAGE tag is used to specify the language in which all -# documentation generated by doxygen is written. Doxygen will use this -# information to generate all constant output in the proper language. -# The default language is English, other supported languages are: -# Brazilian, Catalan, Chinese, Chinese-Traditional, Croatian, Czech, Danish, -# Dutch, Finnish, French, German, Greek, Hungarian, Italian, Japanese, -# Japanese-en (Japanese with English messages), Korean, Korean-en, Norwegian, -# Polish, Portuguese, Romanian, Russian, Serbian, Slovak, Slovene, Spanish, -# Swedish, and Ukrainian. - -OUTPUT_LANGUAGE = English - -# This tag can be used to specify the encoding used in the generated output. -# The encoding is not always determined by the language that is chosen, -# but also whether or not the output is meant for Windows or non-Windows users. -# In case there is a difference, setting the USE_WINDOWS_ENCODING tag to YES -# forces the Windows encoding (this is the default for the Windows binary), -# whereas setting the tag to NO uses a Unix-style encoding (the default for -# all platforms other than Windows). - -USE_WINDOWS_ENCODING = NO - -# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will -# include brief member descriptions after the members that are listed in -# the file and class documentation (similar to JavaDoc). -# Set to NO to disable this. - -BRIEF_MEMBER_DESC = YES - -# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend -# the brief description of a member or function before the detailed description. -# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the -# brief descriptions will be completely suppressed. - -REPEAT_BRIEF = YES - -# This tag implements a quasi-intelligent brief description abbreviator -# that is used to form the text in various listings. Each string -# in this list, if found as the leading text of the brief description, will be -# stripped from the text and the result after processing the whole list, is -# used as the annotated text. Otherwise, the brief description is used as-is. -# If left blank, the following values are used ("$name" is automatically -# replaced with the name of the entity): "The $name class" "The $name widget" -# "The $name file" "is" "provides" "specifies" "contains" -# "represents" "a" "an" "the" - -ABBREVIATE_BRIEF = - -# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then -# Doxygen will generate a detailed section even if there is only a brief -# description. - -ALWAYS_DETAILED_SEC = NO - -# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all -# inherited members of a class in the documentation of that class as if those -# members were ordinary class members. Constructors, destructors and assignment -# operators of the base classes will not be shown. - -INLINE_INHERITED_MEMB = NO - -# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full -# path before files name in the file list and in the header files. If set -# to NO the shortest path that makes the file name unique will be used. - -FULL_PATH_NAMES = NO - -# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag -# can be used to strip a user-defined part of the path. Stripping is -# only done if one of the specified strings matches the left-hand part of -# the path. The tag can be used to show relative paths in the file list. -# If left blank the directory from which doxygen is run is used as the -# path to strip. - -STRIP_FROM_PATH = - -# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of -# the path mentioned in the documentation of a class, which tells -# the reader which header file to include in order to use a class. -# If left blank only the name of the header file containing the class -# definition is used. Otherwise one should specify the include paths that -# are normally passed to the compiler using the -I flag. - -STRIP_FROM_INC_PATH = - -# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter -# (but less readable) file names. This can be useful is your file systems -# doesn't support long names like on DOS, Mac, or CD-ROM. - -SHORT_NAMES = NO - -# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen -# will interpret the first line (until the first dot) of a JavaDoc-style -# comment as the brief description. If set to NO, the JavaDoc -# comments will behave just like the Qt-style comments (thus requiring an -# explicit @brief command for a brief description. - -JAVADOC_AUTOBRIEF = NO - -# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen -# treat a multi-line C++ special comment block (i.e. a block of //! or /// -# comments) as a brief description. This used to be the default behaviour. -# The new default is to treat a multi-line C++ comment block as a detailed -# description. Set this tag to YES if you prefer the old behaviour instead. - -MULTILINE_CPP_IS_BRIEF = YES - -# If the DETAILS_AT_TOP tag is set to YES then Doxygen -# will output the detailed description near the top, like JavaDoc. -# If set to NO, the detailed description appears after the member -# documentation. - -DETAILS_AT_TOP = NO - -# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented -# member inherits the documentation from any documented member that it -# re-implements. - -INHERIT_DOCS = YES - -# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce -# a new page for each member. If set to NO, the documentation of a member will -# be part of the file/class/namespace that contains it. - -SEPARATE_MEMBER_PAGES = NO - -# The TAB_SIZE tag can be used to set the number of spaces in a tab. -# Doxygen uses this value to replace tabs by spaces in code fragments. - -TAB_SIZE = 8 - -# This tag can be used to specify a number of aliases that acts -# as commands in the documentation. An alias has the form "name=value". -# For example adding "sideeffect=\par Side Effects:\n" will allow you to -# put the command \sideeffect (or @sideeffect) in the documentation, which -# will result in a user-defined paragraph with heading "Side Effects:". -# You can put \n's in the value part of an alias to insert newlines. - -ALIASES = - -# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C -# sources only. Doxygen will then generate output that is more tailored for C. -# For instance, some of the names that are used will be different. The list -# of all members will be omitted, etc. - -OPTIMIZE_OUTPUT_FOR_C = NO - -# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java -# sources only. Doxygen will then generate output that is more tailored for Java. -# For instance, namespaces will be presented as packages, qualified scopes -# will look different, etc. - -OPTIMIZE_OUTPUT_JAVA = NO - -# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want to -# include (a tag file for) the STL sources as input, then you should -# set this tag to YES in order to let doxygen match functions declarations and -# definitions whose arguments contain STL classes (e.g. func(std::string); v.s. -# func(std::string) {}). This also make the inheritance and collaboration -# diagrams that involve STL classes more complete and accurate. - -BUILTIN_STL_SUPPORT = NO - -# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC -# tag is set to YES, then doxygen will reuse the documentation of the first -# member in the group (if any) for the other members of the group. By default -# all members of a group must be documented explicitly. - -DISTRIBUTE_GROUP_DOC = NO - -# Set the SUBGROUPING tag to YES (the default) to allow class member groups of -# the same type (for instance a group of public functions) to be put as a -# subgroup of that type (e.g. under the Public Functions section). Set it to -# NO to prevent subgrouping. Alternatively, this can be done per class using -# the \nosubgrouping command. - -SUBGROUPING = NO - -#--------------------------------------------------------------------------- -# Build related configuration options -#--------------------------------------------------------------------------- - -# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in -# documentation are documented, even if no documentation was available. -# Private class members and static file members will be hidden unless -# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES - -EXTRACT_ALL = NO - -# If the EXTRACT_PRIVATE tag is set to YES all private members of a class -# will be included in the documentation. - -EXTRACT_PRIVATE = NO - -# If the EXTRACT_STATIC tag is set to YES all static members of a file -# will be included in the documentation. - -EXTRACT_STATIC = NO - -# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) -# defined locally in source files will be included in the documentation. -# If set to NO only classes defined in header files are included. - -EXTRACT_LOCAL_CLASSES = NO - -# This flag is only useful for Objective-C code. When set to YES local -# methods, which are defined in the implementation section but not in -# the interface are included in the documentation. -# If set to NO (the default) only methods in the interface are included. - -EXTRACT_LOCAL_METHODS = NO - -# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all -# undocumented members of documented classes, files or namespaces. -# If set to NO (the default) these members will be included in the -# various overviews, but no documentation section is generated. -# This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_MEMBERS = YES - -# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all -# undocumented classes that are normally visible in the class hierarchy. -# If set to NO (the default) these classes will be included in the various -# overviews. This option has no effect if EXTRACT_ALL is enabled. - -HIDE_UNDOC_CLASSES = YES - -# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all -# friend (class|struct|union) declarations. -# If set to NO (the default) these declarations will be included in the -# documentation. - -HIDE_FRIEND_COMPOUNDS = NO - -# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any -# documentation blocks found inside the body of a function. -# If set to NO (the default) these blocks will be appended to the -# function's detailed documentation block. - -HIDE_IN_BODY_DOCS = NO - -# The INTERNAL_DOCS tag determines if documentation -# that is typed after a \internal command is included. If the tag is set -# to NO (the default) then the documentation will be excluded. -# Set it to YES to include the internal documentation. - -INTERNAL_DOCS = NO - -# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate -# file names in lower-case letters. If set to YES upper-case letters are also -# allowed. This is useful if you have classes or files whose names only differ -# in case and if your file system supports case sensitive file names. Windows -# and Mac users are advised to set this option to NO. - -CASE_SENSE_NAMES = NO - -# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen -# will show members with their full class and namespace scopes in the -# documentation. If set to YES the scope will be hidden. - -HIDE_SCOPE_NAMES = YES - -# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen -# will put a list of the files that are included by a file in the documentation -# of that file. - -SHOW_INCLUDE_FILES = NO - -# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] -# is inserted in the documentation for inline members. - -INLINE_INFO = NO - -# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen -# will sort the (detailed) documentation of file and class members -# alphabetically by member name. If set to NO the members will appear in -# declaration order. - -SORT_MEMBER_DOCS = NO - -# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the -# brief documentation of file, namespace and class members alphabetically -# by member name. If set to NO (the default) the members will appear in -# declaration order. - -SORT_BRIEF_DOCS = NO - -# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be -# sorted by fully-qualified names, including namespaces. If set to -# NO (the default), the class list will be sorted only by class name, -# not including the namespace part. -# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. -# Note: This option applies only to the class list, not to the -# alphabetical list. - -SORT_BY_SCOPE_NAME = NO - -# The GENERATE_TODOLIST tag can be used to enable (YES) or -# disable (NO) the todo list. This list is created by putting \todo -# commands in the documentation. - -GENERATE_TODOLIST = NO - -# The GENERATE_TESTLIST tag can be used to enable (YES) or -# disable (NO) the test list. This list is created by putting \test -# commands in the documentation. - -GENERATE_TESTLIST = YES - -# The GENERATE_BUGLIST tag can be used to enable (YES) or -# disable (NO) the bug list. This list is created by putting \bug -# commands in the documentation. - -GENERATE_BUGLIST = NO - -# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or -# disable (NO) the deprecated list. This list is created by putting -# \deprecated commands in the documentation. - -GENERATE_DEPRECATEDLIST= NO - -# The ENABLED_SECTIONS tag can be used to enable conditional -# documentation sections, marked by \if sectionname ... \endif. - -ENABLED_SECTIONS = - -# The MAX_INITIALIZER_LINES tag determines the maximum number of lines -# the initial value of a variable or define consists of for it to appear in -# the documentation. If the initializer consists of more lines than specified -# here it will be hidden. Use a value of 0 to hide initializers completely. -# The appearance of the initializer of individual variables and defines in the -# documentation can be controlled using \showinitializer or \hideinitializer -# command in the documentation regardless of this setting. - -MAX_INITIALIZER_LINES = 100 - -# Set the SHOW_USED_FILES tag to NO to disable the list of files generated -# at the bottom of the documentation of classes and structs. If set to YES the -# list will mention the files that were used to generate the documentation. - -SHOW_USED_FILES = NO - -# If the sources in your project are distributed over multiple directories -# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy -# in the documentation. The default is YES. - -SHOW_DIRECTORIES = NO - -# The FILE_VERSION_FILTER tag can be used to specify a program or script that -# doxygen should invoke to get the current version for each file (typically from the -# version control system). Doxygen will invoke the program by executing (via -# popen()) the command , where is the value of -# the FILE_VERSION_FILTER tag, and is the name of an input file -# provided by doxygen. Whatever the program writes to standard output -# is used as the file version. See the manual for examples. - -FILE_VERSION_FILTER = - -#--------------------------------------------------------------------------- -# configuration options related to warning and progress messages -#--------------------------------------------------------------------------- - -# The QUIET tag can be used to turn on/off the messages that are generated -# by doxygen. Possible values are YES and NO. If left blank NO is used. - -QUIET = NO - -# The WARNINGS tag can be used to turn on/off the warning messages that are -# generated by doxygen. Possible values are YES and NO. If left blank -# NO is used. - -WARNINGS = YES - -# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings -# for undocumented members. If EXTRACT_ALL is set to YES then this flag will -# automatically be disabled. - -WARN_IF_UNDOCUMENTED = NO - -# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for -# potential errors in the documentation, such as not documenting some -# parameters in a documented function, or documenting parameters that -# don't exist or using markup commands wrongly. - -WARN_IF_DOC_ERROR = YES - -# This WARN_NO_PARAMDOC option can be abled to get warnings for -# functions that are documented, but have no documentation for their parameters -# or return value. If set to NO (the default) doxygen will only warn about -# wrong or incomplete parameter documentation, but not about the absence of -# documentation. - -WARN_NO_PARAMDOC = NO - -# The WARN_FORMAT tag determines the format of the warning messages that -# doxygen can produce. The string should contain the $file, $line, and $text -# tags, which will be replaced by the file and line number from which the -# warning originated and the warning text. Optionally the format may contain -# $version, which will be replaced by the version of the file (if it could -# be obtained via FILE_VERSION_FILTER) - -WARN_FORMAT = "$file:$line: $text" - -# The WARN_LOGFILE tag can be used to specify a file to which warning -# and error messages should be written. If left blank the output is written -# to stderr. - -WARN_LOGFILE = - -#--------------------------------------------------------------------------- -# configuration options related to the input files -#--------------------------------------------------------------------------- - -# The INPUT tag can be used to specify the files and/or directories that contain -# documented source files. You may enter file names like "myfile.cpp" or -# directories like "/usr/src/myproject". Separate the files or directories -# with spaces. - -INPUT = CImg_documentation.h - -# If the value of the INPUT tag contains directories, you can use the -# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank the following patterns are tested: -# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx -# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py - -FILE_PATTERNS = - -# The RECURSIVE tag can be used to turn specify whether or not subdirectories -# should be searched for input files as well. Possible values are YES and NO. -# If left blank NO is used. - -RECURSIVE = NO - -# The EXCLUDE tag can be used to specify files and/or directories that should -# excluded from the INPUT source files. This way you can easily exclude a -# subdirectory from a directory tree whose root is specified with the INPUT tag. - -EXCLUDE = - -# The EXCLUDE_SYMLINKS tag can be used select whether or not files or -# directories that are symbolic links (a Unix filesystem feature) are excluded -# from the input. - -EXCLUDE_SYMLINKS = NO - -# If the value of the INPUT tag contains directories, you can use the -# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude -# certain files from those directories. Note that the wildcards are matched -# against the file with absolute path, so to exclude all test directories -# for example use the pattern */test/* - -EXCLUDE_PATTERNS = - -# The EXAMPLE_PATH tag can be used to specify one or more files or -# directories that contain example code fragments that are included (see -# the \include command). - -EXAMPLE_PATH = - -# If the value of the EXAMPLE_PATH tag contains directories, you can use the -# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp -# and *.h) to filter out the source-files in the directories. If left -# blank all files are included. - -EXAMPLE_PATTERNS = - -# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be -# searched for input files to be used with the \include or \dontinclude -# commands irrespective of the value of the RECURSIVE tag. -# Possible values are YES and NO. If left blank NO is used. - -EXAMPLE_RECURSIVE = NO - -# The IMAGE_PATH tag can be used to specify one or more files or -# directories that contain image that are included in the documentation (see -# the \image command). - -IMAGE_PATH = - -# The INPUT_FILTER tag can be used to specify a program that doxygen should -# invoke to filter for each input file. Doxygen will invoke the filter program -# by executing (via popen()) the command , where -# is the value of the INPUT_FILTER tag, and is the name of an -# input file. Doxygen will then use the output that the filter program writes -# to standard output. If FILTER_PATTERNS is specified, this tag will be -# ignored. - -INPUT_FILTER = - -# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern -# basis. Doxygen will compare the file name with each pattern and apply the -# filter if there is a match. The filters are a list of the form: -# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further -# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER -# is applied to all files. - -FILTER_PATTERNS = - -# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using -# INPUT_FILTER) will be used to filter the input files when producing source -# files to browse (i.e. when SOURCE_BROWSER is set to YES). - -FILTER_SOURCE_FILES = NO - -#--------------------------------------------------------------------------- -# configuration options related to source browsing -#--------------------------------------------------------------------------- - -# If the SOURCE_BROWSER tag is set to YES then a list of source files will -# be generated. Documented entities will be cross-referenced with these sources. -# Note: To get rid of all source code in the generated output, make sure also -# VERBATIM_HEADERS is set to NO. - -SOURCE_BROWSER = NO - -# Setting the INLINE_SOURCES tag to YES will include the body -# of functions and classes directly in the documentation. - -INLINE_SOURCES = NO - -# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct -# doxygen to hide any special comment blocks from generated source code -# fragments. Normal C and C++ comments will always remain visible. - -STRIP_CODE_COMMENTS = YES - -# If the REFERENCED_BY_RELATION tag is set to YES (the default) -# then for each documented function all documented -# functions referencing it will be listed. - -REFERENCED_BY_RELATION = YES - -# If the REFERENCES_RELATION tag is set to YES (the default) -# then for each documented function all documented entities -# called/used by that function will be listed. - -REFERENCES_RELATION = YES - -# If the USE_HTAGS tag is set to YES then the references to source code -# will point to the HTML generated by the htags(1) tool instead of doxygen -# built-in source browser. The htags tool is part of GNU's global source -# tagging system (see http://www.gnu.org/software/global/global.html). You -# will need version 4.8.6 or higher. - -USE_HTAGS = NO - -# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen -# will generate a verbatim copy of the header file for each class for -# which an include is specified. Set to NO to disable this. - -VERBATIM_HEADERS = NO - -#--------------------------------------------------------------------------- -# configuration options related to the alphabetical class index -#--------------------------------------------------------------------------- - -# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index -# of all compounds will be generated. Enable this if the project -# contains a lot of classes, structs, unions or interfaces. - -ALPHABETICAL_INDEX = NO - -# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then -# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns -# in which this list will be split (can be a number in the range [1..20]) - -COLS_IN_ALPHA_INDEX = 5 - -# In case all classes in a project start with a common prefix, all -# classes will be put under the same header in the alphabetical index. -# The IGNORE_PREFIX tag can be used to specify one or more prefixes that -# should be ignored while generating the index headers. - -IGNORE_PREFIX = - -#--------------------------------------------------------------------------- -# configuration options related to the HTML output -#--------------------------------------------------------------------------- - -# If the GENERATE_HTML tag is set to YES (the default) Doxygen will -# generate HTML output. - -GENERATE_HTML = YES - -# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `html' will be used as the default path. - -HTML_OUTPUT = reference - -# The HTML_FILE_EXTENSION tag can be used to specify the file extension for -# each generated HTML page (for example: .htm,.php,.asp). If it is left blank -# doxygen will generate files with .html extension. - -HTML_FILE_EXTENSION = .html - -# The HTML_HEADER tag can be used to specify a personal HTML header for -# each generated HTML page. If it is left blank doxygen will generate a -# standard header. - -HTML_HEADER = head_reference.html - -# The HTML_FOOTER tag can be used to specify a personal HTML footer for -# each generated HTML page. If it is left blank doxygen will generate a -# standard footer. - -HTML_FOOTER = foot_reference.html - -# The HTML_STYLESHEET tag can be used to specify a user-defined cascading -# style sheet that is used by each HTML page. It can be used to -# fine-tune the look of the HTML output. If the tag is left blank doxygen -# will generate a default style sheet. Note that doxygen will try to copy -# the style sheet file to the HTML output directory, so don't put your own -# stylesheet in the HTML output directory as well, or it will be erased! - -HTML_STYLESHEET = - -# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes, -# files or namespaces will be aligned in HTML using tables. If set to -# NO a bullet list will be used. - -HTML_ALIGN_MEMBERS = YES - -# If the GENERATE_HTMLHELP tag is set to YES, additional index files -# will be generated that can be used as input for tools like the -# Microsoft HTML help workshop to generate a compressed HTML help file (.chm) -# of the generated HTML documentation. - -GENERATE_HTMLHELP = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can -# be used to specify the file name of the resulting .chm file. You -# can add a path in front of the file if the result should not be -# written to the html output directory. - -CHM_FILE = - -# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can -# be used to specify the location (absolute path including file name) of -# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run -# the HTML help compiler on the generated index.hhp. - -HHC_LOCATION = - -# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag -# controls if a separate .chi index file is generated (YES) or that -# it should be included in the master .chm file (NO). - -GENERATE_CHI = NO - -# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag -# controls whether a binary table of contents is generated (YES) or a -# normal table of contents (NO) in the .chm file. - -BINARY_TOC = NO - -# The TOC_EXPAND flag can be set to YES to add extra items for group members -# to the contents of the HTML help documentation and to the tree view. - -TOC_EXPAND = NO - -# The DISABLE_INDEX tag can be used to turn on/off the condensed index at -# top of each HTML page. The value NO (the default) enables the index and -# the value YES disables it. - -DISABLE_INDEX = NO - -# This tag can be used to set the number of enum values (range [1..20]) -# that doxygen will group on one line in the generated HTML documentation. - -ENUM_VALUES_PER_LINE = 4 - -# If the GENERATE_TREEVIEW tag is set to YES, a side panel will be -# generated containing a tree-like index structure (just like the one that -# is generated for HTML Help). For this to work a browser that supports -# JavaScript, DHTML, CSS and frames is required (for instance Mozilla 1.0+, -# Netscape 6.0+, Internet explorer 5.0+, or Konqueror). Windows users are -# probably better off using the HTML help feature. - -GENERATE_TREEVIEW = NO - -# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be -# used to set the initial width (in pixels) of the frame in which the tree -# is shown. - -TREEVIEW_WIDTH = 250 - -#--------------------------------------------------------------------------- -# configuration options related to the LaTeX output -#--------------------------------------------------------------------------- - -# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will -# generate Latex output. - -GENERATE_LATEX = YES - -# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `latex' will be used as the default path. - -LATEX_OUTPUT = latex - -# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be -# invoked. If left blank `latex' will be used as the default command name. - -LATEX_CMD_NAME = latex - -# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to -# generate index for LaTeX. If left blank `makeindex' will be used as the -# default command name. - -MAKEINDEX_CMD_NAME = makeindex - -# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact -# LaTeX documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_LATEX = YES - -# The PAPER_TYPE tag can be used to set the paper type that is used -# by the printer. Possible values are: a4, a4wide, letter, legal and -# executive. If left blank a4wide will be used. - -PAPER_TYPE = a4wide - -# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX -# packages that should be included in the LaTeX output. - -EXTRA_PACKAGES = - -# The LATEX_HEADER tag can be used to specify a personal LaTeX header for -# the generated latex document. The header should contain everything until -# the first chapter. If it is left blank doxygen will generate a -# standard header. Notice: only use this tag if you know what you are doing! - -LATEX_HEADER = - -# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated -# is prepared for conversion to pdf (using ps2pdf). The pdf file will -# contain links (just like the HTML output) instead of page references -# This makes the output suitable for online browsing using a pdf viewer. - -PDF_HYPERLINKS = NO - -# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of -# plain latex in the generated Makefile. Set this option to YES to get a -# higher quality PDF documentation. - -USE_PDFLATEX = YES - -# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. -# command to the generated LaTeX files. This will instruct LaTeX to keep -# running if errors occur, instead of asking the user for help. -# This option is also used when generating formulas in HTML. - -LATEX_BATCHMODE = NO - -# If LATEX_HIDE_INDICES is set to YES then doxygen will not -# include the index chapters (such as File Index, Compound Index, etc.) -# in the output. - -LATEX_HIDE_INDICES = YES - -#--------------------------------------------------------------------------- -# configuration options related to the RTF output -#--------------------------------------------------------------------------- - -# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output -# The RTF output is optimized for Word 97 and may not look very pretty with -# other RTF readers or editors. - -GENERATE_RTF = NO - -# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `rtf' will be used as the default path. - -RTF_OUTPUT = rtf - -# If the COMPACT_RTF tag is set to YES Doxygen generates more compact -# RTF documents. This may be useful for small projects and may help to -# save some trees in general. - -COMPACT_RTF = NO - -# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated -# will contain hyperlink fields. The RTF file will -# contain links (just like the HTML output) instead of page references. -# This makes the output suitable for online browsing using WORD or other -# programs which support those fields. -# Note: wordpad (write) and others do not support links. - -RTF_HYPERLINKS = NO - -# Load stylesheet definitions from file. Syntax is similar to doxygen's -# config file, i.e. a series of assignments. You only have to provide -# replacements, missing definitions are set to their default value. - -RTF_STYLESHEET_FILE = - -# Set optional variables used in the generation of an rtf document. -# Syntax is similar to doxygen's config file. - -RTF_EXTENSIONS_FILE = - -#--------------------------------------------------------------------------- -# configuration options related to the man page output -#--------------------------------------------------------------------------- - -# If the GENERATE_MAN tag is set to YES (the default) Doxygen will -# generate man pages - -GENERATE_MAN = NO - -# The MAN_OUTPUT tag is used to specify where the man pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `man' will be used as the default path. - -MAN_OUTPUT = man - -# The MAN_EXTENSION tag determines the extension that is added to -# the generated man pages (default is the subroutine's section .3) - -MAN_EXTENSION = .3 - -# If the MAN_LINKS tag is set to YES and Doxygen generates man output, -# then it will generate one additional man file for each entity -# documented in the real man page(s). These additional files -# only source the real man page, but without them the man command -# would be unable to find the correct page. The default is NO. - -MAN_LINKS = NO - -#--------------------------------------------------------------------------- -# configuration options related to the XML output -#--------------------------------------------------------------------------- - -# If the GENERATE_XML tag is set to YES Doxygen will -# generate an XML file that captures the structure of -# the code including all documentation. - -GENERATE_XML = NO - -# The XML_OUTPUT tag is used to specify where the XML pages will be put. -# If a relative path is entered the value of OUTPUT_DIRECTORY will be -# put in front of it. If left blank `xml' will be used as the default path. - -XML_OUTPUT = xml - -# The XML_SCHEMA tag can be used to specify an XML schema, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_SCHEMA = - -# The XML_DTD tag can be used to specify an XML DTD, -# which can be used by a validating XML parser to check the -# syntax of the XML files. - -XML_DTD = - -# If the XML_PROGRAMLISTING tag is set to YES Doxygen will -# dump the program listings (including syntax highlighting -# and cross-referencing information) to the XML output. Note that -# enabling this will significantly increase the size of the XML output. - -XML_PROGRAMLISTING = YES - -#--------------------------------------------------------------------------- -# configuration options for the AutoGen Definitions output -#--------------------------------------------------------------------------- - -# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will -# generate an AutoGen Definitions (see autogen.sf.net) file -# that captures the structure of the code including all -# documentation. Note that this feature is still experimental -# and incomplete at the moment. - -GENERATE_AUTOGEN_DEF = NO - -#--------------------------------------------------------------------------- -# configuration options related to the Perl module output -#--------------------------------------------------------------------------- - -# If the GENERATE_PERLMOD tag is set to YES Doxygen will -# generate a Perl module file that captures the structure of -# the code including all documentation. Note that this -# feature is still experimental and incomplete at the -# moment. - -GENERATE_PERLMOD = NO - -# If the PERLMOD_LATEX tag is set to YES Doxygen will generate -# the necessary Makefile rules, Perl scripts and LaTeX code to be able -# to generate PDF and DVI output from the Perl module output. - -PERLMOD_LATEX = NO - -# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be -# nicely formatted so it can be parsed by a human reader. This is useful -# if you want to understand what is going on. On the other hand, if this -# tag is set to NO the size of the Perl module output will be much smaller -# and Perl will parse it just the same. - -PERLMOD_PRETTY = YES - -# The names of the make variables in the generated doxyrules.make file -# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. -# This is useful so different doxyrules.make files included by the same -# Makefile don't overwrite each other's variables. - -PERLMOD_MAKEVAR_PREFIX = - -#--------------------------------------------------------------------------- -# Configuration options related to the preprocessor -#--------------------------------------------------------------------------- - -# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will -# evaluate all C-preprocessor directives found in the sources and include -# files. - -ENABLE_PREPROCESSING = YES - -# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro -# names in the source code. If set to NO (the default) only conditional -# compilation will be performed. Macro expansion can be done in a controlled -# way by setting EXPAND_ONLY_PREDEF to YES. - -MACRO_EXPANSION = NO - -# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES -# then the macro expansion is limited to the macros specified with the -# PREDEFINED and EXPAND_AS_DEFINED tags. - -EXPAND_ONLY_PREDEF = NO - -# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files -# in the INCLUDE_PATH (see below) will be search if a #include is found. - -SEARCH_INCLUDES = YES - -# The INCLUDE_PATH tag can be used to specify one or more directories that -# contain include files that are not input files but should be processed by -# the preprocessor. - -INCLUDE_PATH = - -# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard -# patterns (like *.h and *.hpp) to filter out the header-files in the -# directories. If left blank, the patterns specified with FILE_PATTERNS will -# be used. - -INCLUDE_FILE_PATTERNS = - -# The PREDEFINED tag can be used to specify one or more macro names that -# are defined before the preprocessor is started (similar to the -D option of -# gcc). The argument of the tag is a list of macros of the form: name -# or name=definition (no spaces). If the definition and the = are -# omitted =1 is assumed. To prevent a macro definition from being -# undefined via #undef or recursively expanded use the := operator -# instead of the = operator. - -PREDEFINED = - -# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then -# this tag can be used to specify a list of macro names that should be expanded. -# The macro definition that is found in the sources will be used. -# Use the PREDEFINED tag if you want to use a different macro definition. - -EXPAND_AS_DEFINED = - -# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then -# doxygen's preprocessor will remove all function-like macros that are alone -# on a line, have an all uppercase name, and do not end with a semicolon. Such -# function macros are typically used for boiler-plate code, and will confuse -# the parser if not removed. - -SKIP_FUNCTION_MACROS = YES - -#--------------------------------------------------------------------------- -# Configuration::additions related to external references -#--------------------------------------------------------------------------- - -# The TAGFILES option can be used to specify one or more tagfiles. -# Optionally an initial location of the external documentation -# can be added for each tagfile. The format of a tag file without -# this location is as follows: -# TAGFILES = file1 file2 ... -# Adding location for the tag files is done as follows: -# TAGFILES = file1=loc1 "file2 = loc2" ... -# where "loc1" and "loc2" can be relative or absolute paths or -# URLs. If a location is present for each tag, the installdox tool -# does not have to be run to correct the links. -# Note that each tag file must have a unique name -# (where the name does NOT include the path) -# If a tag file is not located in the directory in which doxygen -# is run, you must also specify the path to the tagfile here. - -TAGFILES = - -# When a file name is specified after GENERATE_TAGFILE, doxygen will create -# a tag file that is based on the input files it reads. - -GENERATE_TAGFILE = - -# If the ALLEXTERNALS tag is set to YES all external classes will be listed -# in the class index. If set to NO only the inherited external classes -# will be listed. - -ALLEXTERNALS = NO - -# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed -# in the modules index. If set to NO, only the current project's groups will -# be listed. - -EXTERNAL_GROUPS = YES - -# The PERL_PATH should be the absolute path and name of the perl script -# interpreter (i.e. the result of `which perl'). - -PERL_PATH = /usr/bin/perl - -#--------------------------------------------------------------------------- -# Configuration options related to the dot tool -#--------------------------------------------------------------------------- - -# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will -# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base -# or super classes. Setting the tag to NO turns the diagrams off. Note that -# this option is superseded by the HAVE_DOT option below. This is only a -# fallback. It is recommended to install and use dot, since it yields more -# powerful graphs. - -CLASS_DIAGRAMS = YES - -# If set to YES, the inheritance and collaboration graphs will hide -# inheritance and usage relations if the target is undocumented -# or is not a class. - -HIDE_UNDOC_RELATIONS = YES - -# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is -# available from the path. This tool is part of Graphviz, a graph visualization -# toolkit from AT&T and Lucent Bell Labs. The other options in this section -# have no effect if this option is set to NO (the default) - -HAVE_DOT = NO - -# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect inheritance relations. Setting this tag to YES will force the -# the CLASS_DIAGRAMS tag to NO. - -CLASS_GRAPH = YES - -# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for each documented class showing the direct and -# indirect implementation dependencies (inheritance, containment, and -# class references variables) of the class with other documented classes. - -COLLABORATION_GRAPH = YES - -# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen -# will generate a graph for groups, showing the direct groups dependencies - -GROUP_GRAPHS = YES - -# If the UML_LOOK tag is set to YES doxygen will generate inheritance and -# collaboration diagrams in a style similar to the OMG's Unified Modeling -# Language. - -UML_LOOK = NO - -# If set to YES, the inheritance and collaboration graphs will show the -# relations between templates and their instances. - -TEMPLATE_RELATIONS = NO - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT -# tags are set to YES then doxygen will generate a graph for each documented -# file showing the direct and indirect include dependencies of the file with -# other documented files. - -INCLUDE_GRAPH = YES - -# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and -# HAVE_DOT tags are set to YES then doxygen will generate a graph for each -# documented header file showing the documented files that directly or -# indirectly include this file. - -INCLUDED_BY_GRAPH = YES - -# If the CALL_GRAPH and HAVE_DOT tags are set to YES then doxygen will -# generate a call dependency graph for every global function or class method. -# Note that enabling this option will significantly increase the time of a run. -# So in most cases it will be better to enable call graphs for selected -# functions only using the \callgraph command. - -CALL_GRAPH = NO - -# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen -# will graphical hierarchy of all classes instead of a textual one. - -GRAPHICAL_HIERARCHY = YES - -# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES -# then doxygen will show the dependencies a directory has on other directories -# in a graphical way. The dependency relations are determined by the #include -# relations between the files in the directories. - -DIRECTORY_GRAPH = YES - -# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images -# generated by dot. Possible values are png, jpg, or gif -# If left blank png will be used. - -DOT_IMAGE_FORMAT = png - -# The tag DOT_PATH can be used to specify the path where the dot tool can be -# found. If left blank, it is assumed the dot tool can be found in the path. - -DOT_PATH = - -# The DOTFILE_DIRS tag can be used to specify one or more directories that -# contain dot files that are included in the documentation (see the -# \dotfile command). - -DOTFILE_DIRS = - -# The MAX_DOT_GRAPH_WIDTH tag can be used to set the maximum allowed width -# (in pixels) of the graphs generated by dot. If a graph becomes larger than -# this value, doxygen will try to truncate the graph, so that it fits within -# the specified constraint. Beware that most browsers cannot cope with very -# large images. - -MAX_DOT_GRAPH_WIDTH = 1024 - -# The MAX_DOT_GRAPH_HEIGHT tag can be used to set the maximum allows height -# (in pixels) of the graphs generated by dot. If a graph becomes larger than -# this value, doxygen will try to truncate the graph, so that it fits within -# the specified constraint. Beware that most browsers cannot cope with very -# large images. - -MAX_DOT_GRAPH_HEIGHT = 1024 - -# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the -# graphs generated by dot. A depth value of 3 means that only nodes reachable -# from the root by following a path via at most 3 edges will be shown. Nodes -# that lay further from the root node will be omitted. Note that setting this -# option to 1 or 2 may greatly reduce the computation time needed for large -# code bases. Also note that a graph may be further truncated if the graph's -# image dimensions are not sufficient to fit the graph (see MAX_DOT_GRAPH_WIDTH -# and MAX_DOT_GRAPH_HEIGHT). If 0 is used for the depth value (the default), -# the graph is not depth-constrained. - -MAX_DOT_GRAPH_DEPTH = 0 - -# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent -# background. This is disabled by default, which results in a white background. -# Warning: Depending on the platform used, enabling this option may lead to -# badly anti-aliased labels on the edges of a graph (i.e. they become hard to -# read). - -DOT_TRANSPARENT = NO - -# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output -# files in one run (i.e. multiple -o and -T options on the command line). This -# makes dot run faster, but since only newer versions of dot (>1.8.10) -# support this, this feature is disabled by default. - -DOT_MULTI_TARGETS = NO - -# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will -# generate a legend page explaining the meaning of the various boxes and -# arrows in the dot generated graphs. - -GENERATE_LEGEND = YES - -# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will -# remove the intermediate dot files that are used to generate -# the various graphs. - -DOT_CLEANUP = YES - -#--------------------------------------------------------------------------- -# Configuration::additions related to the search engine -#--------------------------------------------------------------------------- - -# The SEARCHENGINE tag specifies whether or not a search engine should be -# used. If set to NO the values of all tags below this one will be ignored. - -SEARCHENGINE = NO diff -urN CImg-1-19.orig/documentation/CImg_documentation.h CImg-1-19/documentation/CImg_documentation.h --- CImg-1-19.orig/documentation/CImg_documentation.h Tue Mar 6 15:17:07 2007 +++ CImg-1-19/documentation/CImg_documentation.h Thu Jan 1 01:00:00 1970 @@ -1,895 +0,0 @@ -/*------------------------------------------------------------------------ -# -# File : CImg_documentation.h -# -# Description : Extra documentation file for the CImg Library. -# Used by doxygen to generate the reference documentation. -# ( http://cimg.sourceforge.net ) -# -# Copyright : David Tschumperle -# ( http://www.greyc.ensicaen.fr/~dtschump/ ) -# -# --------------------------------------------------------------------------*/ - -/*----------------------------------- - - Main reference documentation page - - -------------------------------------*/ - -/** - \mainpage - - This is the reference documentation of the CImg Library, - the C++ template image processing library. - This documentation have been generated using the tool doxygen. - It contains a detailed description of all classes and functions of the %CImg Library. - If you have downloaded the CImg package, you actually have a local copy of these pages in the - \c CImg/documentation/reference/ directory. - - Use the menu above to navigate through the documentation pages. - As a first step, you may look at the list of available modules. - - A complete PDF version of this reference documentation is - available here for off-line reading. - - You may be interested also in the - presentation slides presenting an overview - of the %CImg Library capabilities. - -**/ - -/*----------------------------------- - - CImg Library overview - - -------------------------------------*/ - -/** \addtogroup cimg_structure CImg Library Overview */ -/*@{*/ -/** - \page foo2 - - The CImg Library is an image processing library, designed for C++ programmers. - It provides useful classes and functions to load/save, display and process various types of images. - - \section s1 Library structure - - The %CImg Library consists in a single header file CImg.h providing a set of C++ template classes that - can be used in your own sources, to load/save, process and display images or list of images. - Very portable (Unix/X11,Windows, MacOS X, FreeBSD,..), efficient, simple to use, it's a pleasant toolkit - for coding image processing stuffs in C++. - - The header file CImg.h contains all the classes and functions that compose the library itself. - This is one originality of the %CImg Library. This particularly means that : - - No pre-compilation of the library is needed, since the compilation of the CImg functions is done at the same time as - the compilation of your own C++ code. - - No complex dependencies have to be handled : Just include the CImg.h file, and you get a working C++ image processing toolkit. - - The compilation is done on the fly : only CImg functionalities really used by your program are compiled and appear in the - compiled executable program. This leads to very compact code, without any unused stuffs. - - Class members and functions are inlined, leading to better performance during the program execution. - - The %CImg Library is structured as follows : - - - All library classes and functions are defined in the namespace \ref cimg_library. This namespace - encapsulates the library functionalities and avoid any class name collision that could happen with - other includes. Generally, one uses this namespace as a default namespace : - \code - #include "CImg.h" - using namespace cimg_library; - ... - \endcode - - - The namespace \ref cimg_library::cimg defines a set of \e low-level functions and variables used by the library. - Documented functions in this namespace can be safely used in your own program. But, \b never use the - \ref cimg_library::cimg namespace as a default namespace, since it contains functions whose names are already - defined in the standard C/C++ library. - - - The class \ref cimg_library::CImg represents images up to 4-dimensions wide, containing pixels of type \c T - (template parameter). This is actually the main class of the library. - - - The class \ref cimg_library::CImgList represents lists of cimg_library::CImg images. It can be used for instance - to store different frames of an image sequence. - - - The class \ref cimg_library::CImgDisplay is able to display images or image lists into graphical display windows. - As you may guess, the code of this class is highly system-dependent but this is transparent for the programmer, - as environment variables are automatically set by the CImg library (see also \ref cimg_environment). - - - The class \ref cimg_library::CImgStats represents image statistics. Use it to compute the - minimum, maximum, mean and variance of pixel values of images, as well as the corresponding min/max pixel location. - - - The class \ref cimg_library::CImgException (and its subclasses) are used by the library to throw exceptions - when errors occur. Those exceptions can be catched with a bloc try { ..} catch (CImgException) { .. }. - Subclasses define precisely the type of encountered errors. - - Knowing these five classes is \b enough to get benefit of the %CImg Library functionalities. - - - \section s2 CImg version of "Hello world". - - Below is a very simple code that creates a "Hello World" image. This shows you basically how a CImg program looks like. - - \code - #include "CImg.h" - using namespace cimg_library; - - int main() { - CImg img(640,400,1,3); // Define a 640x400 color image with 8 bits per color component. - img.fill(0); // Set pixel values to 0 (color : black) - unsigned char purple[3]={255,0,255}; // Define a purple color - img.draw_text("Hello World",100,100,purple); // Draw a purple "Hello world" at coordinates (100,100). - img.display("My first CImg code"); // Display the image in a display window. - return 0; - } - \endcode - - Which can be also written in a more compact way as : - - \code - #include "CImg.h" - using namespace cimg_library; - - int main() { - const unsigned char purple[3]={255,0,255}; - CImg(640,400,1,3,0).draw_text("Hello World",100,100,purple).display("My first CImg code"); - return 0; - } - \endcode - - Generally, you can write very small code that performs complex image processing tasks. The %CImg Library is very simple - to use and provide a lot of interesting algorithms for image manipulation. - - \section s3 How to compile ? - - The CImg library is a very light and user-friendly library : only standard system libraries are used. - It avoid to handle complex dependancies and problems with library compatibility. - The only thing you need is a (quite modern) C++ compiler : - - - Microsoft Visual C++ 6.0, Visual Studio.NET and Visual Express Edition : Use project files and solution files provided in the - %CImg Library package (directory 'compilation/') to see how it works. - - Intel ICL compiler : Use the following command to compile a CImg-based program with ICL : - \code - icl /Ox hello_world.cpp user32.lib gdi32.lib - \endcode - - g++ (MingW windows version) : Use the following command to compile a CImg-based program with g++, on Windows : - \code - g++ -o hello_word.exe hello_word.cpp -O2 -lgdi32 - \endcode - - g++ (Linux version) : Use the following command to compile a CImg-based program with g++, on Linux : - \code - g++ -o hello_word.exe hello_world.cpp -O2 -L/usr/X11R6/lib -lm -lpthread -lX11 - \endcode - - g++ (Solaris version) : Use the following command to compile a CImg-based program with g++, on Solaris : - \code - g++ -o hello_word.exe hello_world.cpp -O2 -lm -lpthread -R/usr/X11R6/lib -lrt -lnsl -lsocket - \endcode - - g++ (Mac OS X version) : Use the following command to compile a CImg-based program with g++, on Mac OS X : - \code - g++ -o hello_word.exe hello_world.cpp -O2 -lm -lpthread -L/usr/X11R6/lib -lm -lpthread -lX11 - \endcode - - Dev-Cpp : Use the project file provided in the CImg library package to see how it works. - - If you are using another compilers and encounter problems, please - write me since maintaining compatibility is one - of the priority of the %CImg Library. Nevertheless, old compilers that does not respect the C++ norm will not - support the %CImg Library. - - \section s4 What's next ? - - If you are ready to get more, and to start writing more serious programs - with CImg, you are invited to go to the \ref cimg_tutorial section. - -**/ -/*@}*/ - -/*----------------------------------- - - FAQ : Frequently Asked Questions - - -------------------------------------*/ - -/** \addtogroup cimg_faq FAQ : Frequently Asked Questions. */ -/*@{*/ -/** - \page foofaq - - \section ssf0 FAQ Summary - -
    -
  1. General information and availability -
      -
    1. What is the CImg Library ? -
    2. How to use CImg in my own C++ program ? -
    -
  2. C++ aspects -
- - \section sf1 1. General information and availability - - \subsection ssf11 1.1. What is the CImg Library ? - - The CImg Library is an open-source C++ toolkit for image processing. - It basically consists in a single header file - CImg.h - providing a set of C++ classes and functions that can be used in your own sources, - to load/save, process and display images. - It's a very simple and pleasant toolkit for coding image processing stuffs in C++. - - \subsection ssf12 1.2 What is the level of C++ knowledge needed to use CImg ? - - The CImg 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 CImg 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. - - \subsection ssf12 1.2 What are the platform and compilers supported ? - - CImg has been designed with portability in mind. It has been tested on different architectures and compilers, - and should also work on any decent OS having a recent C++ compiler. - Before each release, the CImg Library is compiled under these different configurations : - \li PC Linux 32 bits, with g++. - \li PC Windows 32 bits, with Visual C++ 6.0. - \li PC Windows 32 bits, with Visual C++ Express Edition. - \li Sun SPARC Solaris 32 bits, with g++. - \li Mac PPC with OS X and g++. - - We also know that somebody succeded in compiling it on FreeBSD also. As the library relies only on very - standard and cross-platform includes, this should not be a problem to make it working on other architectures. - Moreover, the CImg compilation is quite flexible meaning that you can decide whether you want to use extra-libraries - (adding features to CImg) or not (see \ref cimg_environment). - - \subsection ssf2 1.2 How to use CImg in my own C++ program ? - - Basically, you need to add these two lines in your C++ source code, in order - to be able to work with CImg images : - \code - #include "CImg.h" - using namespace cimg_library; - \endcode - - \section sf2 2. C++ aspects - - TODO - -**/ -/*@}*/ - -/*----------------------------------- - - Setting Environment Variables - - -------------------------------------*/ - -/** \addtogroup cimg_environment Setting Environment Variables */ -/*@{*/ -/** - \page foo1 - - The CImg library is a multiplatform library, working on a wide variety of systems. - This implies the existence of some \e environment \e variables that must be correctly defined - depending on your current system. - Most of the time, the %CImg Library defines these variables automatically - (for popular systems). Anyway, if your system is not recognized, you will have to set the environment - variables by hand. Here is a quick explanations of environment variables.\n - - Setting the environment variables is done with the #define keyword. - This setting must be done before including the file CImg.h in your source code. - For instance, - defining the environment variable \c cimg_display_type would be done like this : - \code - #define cimg_display_type 0 - #include "CImg.h" - ... - \endcode - - Here are the different environment variables used by the %CImg Library : - - - \b \c cimg_OS : This variable defines the type of your Operating System. It can be set to \b 1 (\e Unix), - \b 2 (\e Windows), or \b 0 (\e Other \e configuration). - It should be actually auto-detected by the CImg library. If this is not the case (cimg_OS=0), you - will probably have to tune the environment variables described below. - - - \b \c cimg_display_type : This variable defines the type of graphical library used to - display images in windows. It can be set to 0 (no display library available), \b 1 (X11-based display) or - \b 2 (Windows-GDI display). - If you are running on a system without X11 or Windows-GDI ability, please set this variable to \c 0. - This will disable the display support, since the %CImg Library doesn't contain the necessary code to display - images on systems other than X11 or Windows GDI. - - - \b \c cimg_color_terminal : This variable tells the library if the system terminal has VT100 color capabilities. - It can be \e defined or \e not \e defined. Define this variable to get colored output on your terminal, - when using the %CImg Library. - - - \b \c cimg_debug : This variable defines the level of run-time debug messages that will be displayed by - the %CImg Library. It can be set to 0 (no debug messages), 1 (normal debug messages displayed on - standard error), 2 (normal debug messages displayed in modal windows, which is - the default value), or 3 (high debug messages). Note that setting this value to 3 may slow down your - program since more debug tests are made by the library (particularly to check if pixel access is made outside - image boundaries). See also CImgException to better understand how debug messages are working. - - - \b \c cimg_convert_path : This variables tells the library where the ImageMagick's \e convert tool is located. - Setting this variable should not be necessary if ImageMagick is installed on a standard directory, or - if \e convert is in your system PATH variable. This macro should be defined only if the ImageMagick's - \e convert tool is not found automatically, when trying to read compressed image format (GIF,PNG,...). - See also cimg_library::CImg::get_load_convert() and cimg_library::CImg::save_convert() for more informations. - - - \b \c cimg_temporary_path : This variable tells the library where it can find a directory to store - temporary files. Setting this variable should not be necessary if you are running on a standard system. - This macro should be defined only when troubles are encountered when trying to read - compressed image format (GIF,PNG,...). - See also cimg_library::CImg::get_load_convert() and cimg_library::CImg::save_convert() for more informations. - - - \b \c cimg_plugin : This variable tells the library to use a plugin file to add features to the CImg class. - Define it with the path of your plugin file, if you want to add member functions to the CImg class, - without having to modify directly the \c "CImg.h" file. An include of the plugin file is performed in the CImg - class. If \c cimg_plugin if not specified (default), no include is done. - - - \b \c cimglist_plugin : Same as \c cimg_plugin, but to add features to the CImgList class. - - - \b \c cimgdisplay_plugin : Same as \c cimg_plugin, but to add features to the CImgDisplay class. - - - \b \c cimgstats_plugin : Same as \c cimg_plugin, but to add features to the CImgStats class. - - All these compilation variables can be checked, using the function cimg_library::cimg::info(), which - displays a list of the different configuration variables and their values on the standard error output. -**/ -/*@}*/ - -/*----------------------------------- - - Tutorial : Getting started - - -------------------------------------*/ - -/** \addtogroup cimg_tutorial Tutorial : Getting Started. */ -/*@{*/ -/** - \page foo3 - - Let's start to write our first program to get the idea. This will demonstrate how to load and create images, as well as handle image - display and mouse events. - Assume we want to load a color image lena.jpg, smooth it, display it in a windows, and enter an event loop so that clicking a - point in the image with the mouse will draw the intensity profiles of (R,G,B) of the corresponding image line (in another window). - Yes, that sounds quite complex for a first code, but don't worry, it will be very simple using the CImg library ! Well, just look - at the code below, it does the task : - - \code - #include "CImg.h" - using namespace cimg_library; - - int main() { - CImg image("lena.jpg"), visu(500,400,1,3,0); - const unsigned char red[3]={255,0,0}, green[3]={0,255,0}, blue[3]={0,0,255}; - image.blur(2.5); - CImgDisplay main_disp(image,"Click a point"), draw_disp(visu,"Intensity profile"); - while (!main_disp.is_closed && !draw_disp.is_closed) { - main_disp.wait(); - if (main_disp.button && main_disp.mouse_y>=0) { - const int y = main_disp.mouse_y; - visu.fill(0).draw_graph(image.get_crop(0,y,0,0,image.dimx()-1,y,0,0),red,0,256,0); - visu.draw_graph(image.get_crop(0,y,0,1,image.dimx()-1,y,0,1),green,0,256,0); - visu.draw_graph(image.get_crop(0,y,0,2,image.dimx()-1,y,0,2),blue,0,256,0).display(draw_disp); - } - } - return 0; - } - \endcode - - Here is a screenshot of the resulting program : - - - - And here is the detailled explanation of the source, line by line : - - \code #include "CImg.h" \endcode - Include the main and only header file of the CImg library. - \code using namespace cimg_library; \endcode - Use the library namespace to ease the declarations afterward. - \code int main() { \endcode - Definition of the main function. - \code CImg image("lena.jpg"), visu(500,400,1,3,0); \endcode - Creation of two instances of images of \c unsigned \c char pixels. - The first image \c image is initialized by reading an image file from the disk. - Here, lena.jpg must be in the same directory than the current program. - Note that you must also have installed the \e ImageMagick package in order to be able to read JPG images. - The second image \c visu is initialized as a black color image with dimension dx=500, dy=400, - dz=1 (here, it is a 2D image, not a 3D one), and dv=3 (each pixel has 3 'vector' channels R,G,B). - The last argument in the constructor defines the default value of the pixel values - (here \c 0, which means that \c visu will be initially black). - \code const unsigned char red[3]={255,0,0}, green[3]={0,255,0}, blue[3]={0,0,255}; \endcode - Definition of three different colors as array of unsigned char. This will be used to draw plots with different colors. - \code image.blur(2.5); \endcode - Blur the image, with a gaussian blur and a standard variation of 2.5. Note that most of the CImg functions have two versions : - one that acts in-place (which is the case of blur), and one that returns the result as a new image (the name of the function - begins then with get_ ). In this case, one could have also written image = image.get_blur(2.5); - (more expensive, since it needs an additional copy operation). - \code CImgDisplay main_disp(image,"Click a point"), draw_disp(visu,"Intensity profile"); \endcode - Creation of two display windows, one for the input image image, and one for the image visu which will be display intensity profiles. - By default, CImg displays handles events (mouse,keyboard,..). On Windows, there is a way to create fullscreen displays. - \code while (!main_disp.is_closed && !draw_disp.is_closed) { \endcode - Enter the event loop, the code will exit when one of the two display windows is closed. - \code main_disp.wait(); \endcode - Wait for an event (mouse, keyboard,..) in the display window \c main_disp. - \code if (main_disp.button && main_disp.mouse_y>=0) { \endcode - Test if the mouse button has been clicked on the image area. - One may distinguish between the 3 different mouse buttons, - but in this case it is not necessary - \code const int y = main_disp.mouse_y; \endcode - Get the image line y-coordinate that has been clicked. - \code visu.fill(0).draw_graph(image.get_crop(0,y,0,0,image.dimx()-1,y,0,0),red,0,256,0); \endcode - This line illustrates the pipeline property of most of the CImg class functions. The first function fill(0) simply sets - all pixel values with 0 (i.e. clear the image \c visu). The interesting thing is that it returns a reference to - \c visu and then, can be pipelined with the function \c draw_graph() which draws a plot in the image \c visu. - The plot data are given by another image (the first argument of \c draw_graph()). In this case, the given image is - the red-component of the line y of the original image, retrieved by the function \c get_crop() which returns a - sub-image of the image \c image. Remember that images coordinates are 4D (x,y,z,v) and for color images, - the R,G,B channels are respectively given by v=0, v=1 and v=2. - \code visu.draw_graph(image.get_crop(0,y,0,1,image.dimx()-1,y,0,1),green,0,256,0); \endcode - Plot the intensity profile for the green channel of the clicked line. - \code visu.draw_graph(image.get_crop(0,y,0,2,image.dimx()-1,y,0,2),blue,0,256,0).display(draw_disp); \endcode - Same thing for the blue channel. Note how the function (which return a reference to \c visu) is pipelined with the function - \c display() that just paints the image visu in the corresponding display window. - \code ...till the end \endcode - I don't think you need more explanations ! - - As you have noticed, the CImg library allows to write very small and intuitive code. Note also that this source will perfectly - work on Unix and Windows systems. Take also a look to the examples provided in the CImg package ( - directory \c examples/ ). It will show you how CImg-based code can be surprisingly small. - Moreover, there is surely one example close to what you want to do. - A good start will be to look at the file CImg_demo.cpp which contains small and various examples of what you can do - with the %CImg Library. All CImg classes are used in this source, and the code can be easily modified to see what happens. - -**/ -/*@}*/ - -/*----------------------------------- - - Using drawing functions - - -------------------------------------*/ - -/** \addtogroup cimg_drawing Using Drawing Functions. */ -/*@{*/ -/** - \page foo5 - - \section s5 Using Drawing Functions. - - This section tells more about drawing features in CImg images. - Drawing functions list can be found in the CImg functions list - (section \b Drawing Functions), - and are all defined on a common basis. Here are the important points to understand before using - drawing functions : - - - Drawing is performed on the instance image. Drawing functions parameters - are defined as \e const variables and return a reference to the current instance (*this), - so that drawing functions can be pipelined (see examples below). - Drawing is usually done in 2D color images but can be performed in 3D images with any vector-valued dimension, - and with any possible pixel type. - - - A color parameter is always needed to draw features in an image. The color must be defined as a C-style array - whose dimension is at least - -**/ -/*@}*/ - -/*----------------------------------- - - Using image loops - - -------------------------------------*/ - -/** \addtogroup cimg_loops Using Image Loops. */ -/*@{*/ -/** - \page foo_lo - The %CImg Library provides different macros that define useful iterative loops over an image. - Basically, it can be used to replace one or several for(..) instructions, but it also proposes - interesting extensions to classical loops. - Below is a list of all existing loop macros, classified in four different categories : - - \ref lo1 - - \ref lo4 - - \ref lo5 - - \ref lo6 - - \section lo1 Loops over the pixel buffer - - Loops over the pixel buffer are really basic loops that iterate a pointer on the pixel data buffer - of a \c cimg_library::CImg image. Two macros are defined for this purpose : - - - \b cimg_for(img,ptr,T) : - This macro loops over the pixel data buffer of the image \c img, using a pointer T* ptr, - starting from the end of the buffer (last pixel) till the beginning of the buffer (first pixel). - - \c img must be a (non empty) \c cimg_library::CImg image of pixels \c T. - - \c ptr is a pointer of type \c T*. - This kind of loop should not appear a lot in your own source code, since this is a low-level loop - and many functions of the CImg class may be used instead. Here is an example of use : - \code - CImg img(320,200); - cimg_for(img,ptr,float) { *ptr=0; } // Equivalent to 'img.fill(0);' - \endcode - - - \b cimg_foroff(img,off) : - This macro loops over the pixel data buffer of the image \c img, using an offset \c , - starting from the beginning of the buffer (first pixel, \c off=0) - till the end of the buffer (last pixel value, off = img.size()-1). - - \c img must be a (non empty) cimg_library::CImg image of pixels \c T. - - \c off is an inner-loop variable, only defined inside the scope of the loop. - - Here is an example of use : - \code - CImg img(320,200); - cimg_foroff(img,off) { img[off]=0; } // Equivalent to 'img.fill(0);' - \endcode - - \section lo4 Loops over image dimensions - - The following loops are probably the most used loops in image processing programs. - They allow to loop over the image along one or several dimensions, along a raster scan course. - Here is the list of such loop macros for a single dimension : - - \b cimg_forX(img,x) : equivalent to : for (int x=0; x. - - \b cimg_forY(img,y) : equivalent to : for (int y=0; y. - - \b cimg_forZ(img,z) : equivalent to : for (int z=0; z. - - \b cimg_forV(img,v) : equivalent to : for (int v=0; v. - - Combinations of these macros are also defined as other loop macros, allowing to loop directly over 2D, 3D or 4D images : - - \b cimg_forXY(img,x,y) : equivalent to : \c cimg_forY(img,y) \c cimg_forX(img,x). - - \b cimg_forXZ(img,x,z) : equivalent to : \c cimg_forZ(img,z) \c cimg_forX(img,x). - - \b cimg_forYZ(img,y,z) : equivalent to : \c cimg_forZ(img,z) \c cimg_forY(img,y). - - \b cimg_forXV(img,x,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forX(img,x). - - \b cimg_forYV(img,y,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forY(img,y). - - \b cimg_forZV(img,z,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forZ(img,z). - - \b cimg_forXYZ(img,x,y,z) : equivalent to : \c cimg_forZ(img,z) \c cimg_forXY(img,x,y). - - \b cimg_forXYV(img,x,y,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forXY(img,x,y). - - \b cimg_forXZV(img,x,z,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forXZ(img,x,z). - - \b cimg_forYZV(img,y,z,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forYZ(img,y,z). - - \b cimg_forXYZV(img,x,y,z,v) : equivalent to : \c cimg_forV(img,v) \c cimg_forXYZ(img,x,y,z). - - - For all these loops, \c x,\c y,\c z and \c v are inner-defined variables only visible inside the scope of the loop. - They don't have to be defined before the call of the macro. - - \c img must be a (non empty) cimg_library::CImg image. - - Here is an example of use that creates an image with a smooth color gradient : - \code - CImg img(256,256,1,3); // Define a 256x256 color image - cimg_forXYV(img,x,y,v) { img(x,y,v) = (x+y)*(v+1)/6; } - img.display("Color gradient"); - \endcode - - \section lo5 Loops over interior regions and borders. - - Similar macros are also defined to loop only on the border of an image, or inside the image (excluding the border). - The border may be several pixel wide : - - - \b cimg_for_insideX(img,x,n) : Loop along the x-axis, except for pixels inside a border of \p n pixels wide. - - \b cimg_for_insideY(img,y,n) : Loop along the y-axis, except for pixels inside a border of \p n pixels wide. - - \b cimg_for_insideZ(img,z,n) : Loop along the z-axis, except for pixels inside a border of \p n pixels wide. - - \b cimg_for_insideV(img,v,n) : Loop along the v-axis, except for pixels inside a border of \p n pixels wide. - - \b cimg_for_insideXY(img,x,y,n) : Loop along the (x,y)-axes, excepted for pixels inside a border of \p n pixels wide. - - \b cimg_for_insideXYZ(img,x,y,z,n) : Loop along the (x,y,z)-axes, excepted for pixels inside a border of \p n pixels wide. - - And also : - - - \b cimg_for_borderX(img,x,n) : Loop along the x-axis, only for pixels inside a border of \p n pixels wide. - - \b cimg_for_borderY(img,y,n) : Loop along the y-axis, only for pixels inside a border of \p n pixels wide. - - \b cimg_for_borderZ(img,z,n) : Loop along the z-axis, only for pixels inside a border of \p n pixels wide. - - \b cimg_for_borderV(img,v,n) : Loop along the z-axis, only for pixels inside a border of \p n pixels wide. - - \b cimg_for_borderXY(img,x,y,n) : Loop along the (x,y)-axes, only for pixels inside a border of \p n pixels wide. - - \b cimg_for_borderXYZ(img,x,y,z,n) : Loop along the (x,y,z)-axes, only for pixels inside a border of \p n pixels wide. - - - For all these loops, \c x,\c y,\c z and \c v are inner-defined variables only visible inside the scope of the loop. - They don't have to be defined before the call of the macro. - - \c img must be a (non empty) cimg_library::CImg image. - - The constant \c n stands for the size of the border. - - Here is an example of use, to create a 2d grayscale image with two different intensity gradients : - \code - CImg<> img(256,256); - cimg_for_insideXY(img,x,y,50) img(x,y) = x+y; - cimg_for_borderXY(img,x,y,50) img(x,y) = x-y; - img.display(); - \endcode - - \section lo6 Loops using neighborhoods. - - Inside an image loop, it is often useful to get values of neighborhood pixels of the - current pixel at the loop location. - The %CImg Library provides a very smart and fast mechanism for this purpose, with the definition - of several loop macros that remember the neighborhood values of the pixels. - The use of these macros can highly optimize your code, and also simplify your program. - - \subsection lo7 Neighborhood-based loops for 2D images - - For 2D images, the neighborhood-based loop macros are : - - - \b cimg_for2x2(img,x,y,z,v,I) : Loop along the (x,y)-axes using a centered 2x2 neighborhood. - - \b cimg_for3x3(img,x,y,z,v,I) : Loop along the (x,y)-axes using a centered 3x3 neighborhood. - - \b cimg_for4x4(img,x,y,z,v,I) : Loop along the (x,y)-axes using a centered 4x4 neighborhood. - - \b cimg_for5x5(img,x,y,z,v,I) : Loop along the (x,y)-axes using a centered 5x5 neighborhood. - - For all these loops, \c x and \c y are inner-defined variables only visible inside the scope of the loop. - They don't have to be defined before the call of the macro. - \c img is a non empty CImg image. \c z and \c v are constants that define on which image slice and - vector channel the loop must apply (usually both 0 for grayscale 2D images). - Finally, \c I is the 2x2, 3x3, 4x4 or 5x5 neighborhood that will be updated with the correct pixel values - during the loop (see \ref lo9). - - \subsection lo8 Neighborhood-based loops for 3D images - - For 3D images, the neighborhood-based loop macros are : - - - \b cimg_for2x2x2(img,x,y,z,v,I) : Loop along the (x,y,z)-axes using a centered 2x2x2 neighborhood. - - \b cimg_for3x3x3(img,x,y,z,v,I) : Loop along the (x,y,z)-axes using a centered 3x3x3 neighborhood. - - For all these loops, \c x, \c y and \c z are inner-defined variables only visible inside the scope of the loop. - They don't have to be defined before the call of the macro. - \c img is a non empty CImg image. \c v is a constant that defines on which image channel - the loop must apply (usually 0 for grayscale 3D images). - Finally, \c I is the 2x2x2 or 3x3x3 neighborhood that will be updated with the correct pixel values - during the loop (see \ref lo9). - - \subsection lo9 Defining neighborhoods - - The CImg library defines a neighborhood as a set of named \e variables or \e references, declared - using specific CImg macros : - - - \b CImg_2x2(I,type) : Define a 2x2 neighborhood named \c I, of type \c type. - - \b CImg_3x3(I,type) : Define a 3x3 neighborhood named \c I, of type \c type. - - \b CImg_4x4(I,type) : Define a 4x4 neighborhood named \c I, of type \c