diff -urN CImg-1-19.orig/CHANGES.txt CImg-1-19/CHANGES.txt --- CImg-1-19.orig/CHANGES.txt Mon Mar 5 18:56:32 2007 +++ CImg-1-19/CHANGES.txt Tue Mar 6 15:17:06 2007 @@ -13,8 +13,10 @@ *----------------------------- * 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 Mon Mar 5 18:56:32 2007 +++ CImg-1-19/CImg.h Tue Mar 6 15:17:06 2007 @@ -35,7 +35,6 @@ # knowledge of the CeCILL-C license and that you accept its terms. # */ - #ifndef cimg_version #define cimg_version 1.19 @@ -20039,13 +20038,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,file); \ + Tss *buf = new Tss[w*h*z*k]; cimg::fread(buf,w*h*z*k,nfile); \ 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; \ @@ -21549,775 +21548,6 @@ #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 Mon Mar 5 18:56:33 2007 +++ CImg-1-19/documentation/CImg.doxygen Tue Mar 6 15:17:07 2007 @@ -459,7 +459,7 @@ # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = ../CImg.h +INPUT = ../CImg.h 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 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 Thu Jan 1 01:00:00 1970 +++ CImg-1-19/documentation/CImg_documentation.doxygen Tue Mar 6 15:17:07 2007 @@ -0,0 +1,1237 @@ +# 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 Thu Jan 1 01:00:00 1970 +++ CImg-1-19/documentation/CImg_documentation.h Tue Mar 6 15:17:07 2007 @@ -0,0 +1,895 @@ +/*------------------------------------------------------------------------ +# +# 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 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