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

-Here is the CHANGELOG :
- -*-----------------------------
-*-----------------------------
-* Changes from 1.1.8 to 1.1.9
-*-----------------------------
-*-----------------------------
-
-* New features :
- - Added functions 'CImg::sharpen()' and 'CImg::get_sharpen()' that can enhance contrast in images, - using nonlinear 2D/3D multi-valued shock filters.
- - 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!).
- - Functions 'CImgDisplay::hide_mouse()' and 'CImgDisplay::show_mouse()' have been added, allowing to - hide/show the cursor when it is over a display window.
- - Functions 'CImg::[get_]structure_tensorXY[Z]()' have been added, allowing to compute the 2D or - 3D structure tensor field from an image.
- - Function 'CImgDisplay::set_mouse()' is now working on Windows.
- - Added load/save functions to deal directly with std::FILE structures.
- - Added members 'CImgDisplay::keys[256]' and 'CImgDisplay::buttons[256]' allowing to get the latest 256 keys - or mouse buttons modifications done on the display window.
- - Added function 'CImgDisplay::is_typed()' to test if a certain combination of key has been typed - on the display window.
- - Added keyboard shortcut 'CTRL+S' in 'CImg::display_object3d()' to be able to save snapshot of current 3d view.
-
-* Optimizations / Modifications :
- - Recoded the greycstoration plug-in as the file 'plugins/greycstoration.h'. The command line version - 'examples/greycstoration.cpp' has been greatly improved, including tiled-mode and less memory consumption.
- The use of GREYCstoration is now more easy, the code is more factorized.
-
-* Bug corrections :
- - Plugin 'plugins/cimgmatlab.h' has been corrected.
- - -

- - - -
-
CImg 1.1.8 Released (2007/01/26, 11:06am)
The CImg 1.1.8 package have been released. I guess this is a more bug-free version than the 1.1.7. @@ -190,7 +145,7 @@
CImg 1.1.7 in progress... (2006/10/24, 10:21am)
-Preparing the next CImg release 1.1.7, I've added a new small and cool effect in the example file examples/CImg_demo.cpp. +Preparing the next CImg release 1.1.7, I've added a new small and cool effect in the example file examples/CImg_demo.cpp. It roughly applies the wave equation on a height map on which a color image is mapped. This height map is deforming itself according to falling particles, and all is displayed as a 3D gouraud rotating object.
But the best of all, is that all fits in about 60 lines of code !

@@ -282,14 +237,14 @@
- + diff -urN CImg-1-19.orig/documentation/reference/group__cimg__faq.html CImg-1-19/documentation/reference/group__cimg__faq.html --- CImg-1-19.orig/documentation/reference/group__cimg__faq.html Tue Mar 6 15:19:49 2007 +++ CImg-1-19/documentation/reference/group__cimg__faq.html Mon Mar 5 18:59:09 2007 @@ -83,41 +83,8 @@

FAQ : Frequently Asked Questions.

-

-FAQ Summary

-
    -
  1. -General information and availability
      -
    1. -What is the CImg Library ?
      2. -
    2. -How to use CImg in my own C++ program ?
      3. -
    -
    2. -
  2. -C++ aspects
    3. -
-

-1. General information and availability

-

-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++.

-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.

-1.2 What is the level of C++ knowledge needed to use CImg ?

-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 :
    -
  • PC Linux 32 bits, with g++.
    • -
  • PC Windows 32 bits, with Visual C++ 6.0.
    • -
  • PC Windows 32 bits, with Visual C++ Express Edition.
    • -
  • Sun SPARC Solaris 32 bits, with g++.
    • -
  • 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 Setting Environment Variables).

-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 : 
  #include "CImg.h"
-  using namespace cimg_library;
-

-2. C++ aspects

+

+FAQ : Frequently Asked Questions.

TODO diff -urN CImg-1-19.orig/examples/Makefile CImg-1-19/examples/Makefile --- CImg-1-19.orig/examples/Makefile Tue Mar 6 15:17:07 2007 +++ CImg-1-19/examples/Makefile Mon Mar 5 18:56:32 2007 @@ -39,7 +39,7 @@ # Uncomment to perform strict CImg compilation # (Do not try to preserve compatibility with older CImg versions) -CIMG_STRICT_FLAGS = -Dcimg_strict +CIMG_STRICT_FLAG = -Dcimg_strict # Uncomment to enable the use of the X11 library. # (X11 is used by CImg to handle display windows) @@ -68,7 +68,7 @@ # Uncomment to enable faster Discrete Fourier Transform computation, using the FFTW3 library #CIMG_FFTW3_FLAGS = -Dcimg_use_fftw3 -lfftw3 -EXTRA_FLAGS = $(CIMG_X11_FLAGS) $(CIMG_STRICT_FLAGS) $(CIMG_XSHM_FLAGS) $(CIMG_XRANDR_FLAGS) $(CIMG_PNG_FLAGS) $(CIMG_JPEG_FLAGS) $(CIMG_TIFF_FLAGS) $(CIMG_MAGICK_FLAGS) $(CIMG_FFTW3_FLAGS) +EXTRA_FLAGS = $(CIMG_STRICT_FLAG) $(CIMG_XSHM_FLAGS) $(CIMG_XRANDR_FLAGS) $(CIMG_PNG_FLAGS) $(CIMG_JPEG_FLAGS) $(CIMG_TIFF_FLAGS) $(CIMG_MAGICK_FLAGS) $(CIMG_FFTW3_FLAGS) # Compilation rules .cpp: diff -urN CImg-1-19.orig/examples/greycstoration.cpp CImg-1-19/examples/greycstoration.cpp --- CImg-1-19.orig/examples/greycstoration.cpp Tue Mar 6 15:17:06 2007 +++ CImg-1-19/examples/greycstoration.cpp Mon Mar 5 18:56:32 2007 @@ -50,13 +50,10 @@ ------------------------------------------------------------------------------*/ #define greycstoration_version 2.5 -#if defined(sun) || defined(__sun) || defined(linux) || defined(__linux) \ - || defined(__linux__) || defined(__CYGWIN__) || defined(BSD) || defined(__FreeBSD__) \ - || defined(__OPENBSD__) || defined(__MACOSX__) || defined(__APPLE__) || defined(sgi) \ - || defined(__sgi) +#define cimg_plugin "plugins/greycstoration.h" +#if cimg_OS!=2 #include #endif -#define cimg_plugin "plugins/greycstoration.h" #include "../CImg.h" using namespace cimg_library; // The undef below is necessary when using a non-standard compiler. @@ -125,8 +122,8 @@ cimg_help("\n + Global algorithm parameters\n ---------------------------"); const float amplitude = cimg_option("-dt",restore?60.0f:(inpaint?20.0f:20.0f),"Regularization strength per iteration (>=0)"); unsigned int nb_iter = cimg_option("-iter", restore?1:(inpaint?1000:3),"Number of iterations (>0)"); - const float sharpness = cimg_option("-p", restore?0.75f:(inpaint?0.3f:0.2f),"Contour preservation (>=0)"); - const float anisotropy = cimg_option("-a", restore?0.15f:(inpaint?1.0f:0.9f),"Smoothing anisotropy (0<=a<=1)"); + const float sharpness = cimg_option("-p", restore?0.7f:(inpaint?0.3f:0.2f),"Contour preservation (>=0)"); + const float anisotropy = cimg_option("-a", restore?0.3f:(inpaint?1.0f:0.9f),"Smoothing anisotropy (0<=a<=1)"); const float alpha = cimg_option("-alpha",restore?0.6f:(inpaint?0.8f:0.1f),"Noise scale (>=0)"); const float sigma = cimg_option("-sigma",restore?1.1f:(inpaint?2.0f:1.5f),"Geometry regularity (>=0)"); const bool fast_approx = cimg_option("-fast", true,"Enable fast approximation (true or false)");