From 5a422aba704c375a307a902bafe658342e209906 Mon Sep 17 00:00:00 2001 From: scuri Date: Fri, 17 Oct 2008 06:10:15 +0000 Subject: First commit - moving from LuaForge to SourceForge --- html/en/.cvsignore | 1 + html/en/capture.html | 40 +++++ html/en/capture_guide.html | 81 ++++++++++ html/en/capture_samples.html | 34 ++++ html/en/copyright.html | 45 ++++++ html/en/cvs.html | 22 +++ html/en/download.html | 30 ++++ html/en/download_tips.html | 363 +++++++++++++++++++++++++++++++++++++++++++ html/en/guide.html | 282 +++++++++++++++++++++++++++++++++ html/en/history.html | 347 +++++++++++++++++++++++++++++++++++++++++ html/en/home.html | 28 ++++ html/en/imaging.gif | Bin 0 -> 11352 bytes html/en/imlua.html | 124 +++++++++++++++ html/en/libjasper.txt | 51 ++++++ html/en/libjpeg.txt | 48 ++++++ html/en/liblzf.txt | 30 ++++ html/en/libpng.txt | 109 +++++++++++++ html/en/libtiff.txt | 21 +++ html/en/paking.gif | Bin 0 -> 4352 bytes html/en/proc_guide.html | 144 +++++++++++++++++ html/en/proc_samples.html | 142 +++++++++++++++++ html/en/processing.html | 35 +++++ html/en/prod.html | 132 ++++++++++++++++ html/en/rep_guide.html | 139 +++++++++++++++++ html/en/rep_samples.html | 71 +++++++++ html/en/representation.html | 138 ++++++++++++++++ html/en/samples.html | 163 +++++++++++++++++++ html/en/storage.html | 72 +++++++++ html/en/storage_guide.html | 311 ++++++++++++++++++++++++++++++++++++ html/en/storage_samples.html | 79 ++++++++++ html/en/to_do.html | 60 +++++++ html/en/toolkits.html | 244 +++++++++++++++++++++++++++++ html/en/topdown.gif | Bin 0 -> 9045 bytes html/en/zlib.txt | 33 ++++ 34 files changed, 3419 insertions(+) create mode 100644 html/en/.cvsignore create mode 100644 html/en/capture.html create mode 100644 html/en/capture_guide.html create mode 100644 html/en/capture_samples.html create mode 100644 html/en/copyright.html create mode 100644 html/en/cvs.html create mode 100644 html/en/download.html create mode 100644 html/en/download_tips.html create mode 100644 html/en/guide.html create mode 100644 html/en/history.html create mode 100644 html/en/home.html create mode 100644 html/en/imaging.gif create mode 100644 html/en/imlua.html create mode 100644 html/en/libjasper.txt create mode 100644 html/en/libjpeg.txt create mode 100644 html/en/liblzf.txt create mode 100644 html/en/libpng.txt create mode 100644 html/en/libtiff.txt create mode 100644 html/en/paking.gif create mode 100644 html/en/proc_guide.html create mode 100644 html/en/proc_samples.html create mode 100644 html/en/processing.html create mode 100644 html/en/prod.html create mode 100644 html/en/rep_guide.html create mode 100644 html/en/rep_samples.html create mode 100644 html/en/representation.html create mode 100644 html/en/samples.html create mode 100644 html/en/storage.html create mode 100644 html/en/storage_guide.html create mode 100644 html/en/storage_samples.html create mode 100644 html/en/to_do.html create mode 100644 html/en/toolkits.html create mode 100644 html/en/topdown.gif create mode 100644 html/en/zlib.txt (limited to 'html/en') diff --git a/html/en/.cvsignore b/html/en/.cvsignore new file mode 100644 index 0000000..a761032 --- /dev/null +++ b/html/en/.cvsignore @@ -0,0 +1 @@ +doxygen \ No newline at end of file diff --git a/html/en/capture.html b/html/en/capture.html new file mode 100644 index 0000000..896b65b --- /dev/null +++ b/html/en/capture.html @@ -0,0 +1,40 @@ + + + + + +Capture + + + + + +

Image Capture Overview

+ +

The capture support is designed for live video, it is not for passive + digital cameras that only transfer the already taken pictures. Are valid: USB + cameras (like most Webcams), Firewire (IEEE 1394) cameras, and analog video + capture boards, including TV Tuners. These are called devices.

+

The capture functions allows you to:

+ +

You can list the installed devices and once you connect to a specific + device you can control its parameters. Each connected device captures data + frames continuously when in Live state otherwise it stays in standby. You can + connect to more than one device at the same time.

+

Once connected the user can retrieve frames from the device any time. This + can be done with one function call, or inside a closed loop for several + frames, or inside an idle function to periodically update the screen. The user + is not notified when a new frame is available, but every time the user + retrieve a frame, if successful, it is a new frame, old frames are discarded + when a new frame arrives.

+

Currently it is implemented only in Microsoft Windows.

+ + + + + diff --git a/html/en/capture_guide.html b/html/en/capture_guide.html new file mode 100644 index 0000000..b3f84c3 --- /dev/null +++ b/html/en/capture_guide.html @@ -0,0 +1,81 @@ + + + + + + +Capture Guide + + + + + +

Capture Guide

+

Using

+ +

You can list the installed capture devices using:

+ +
int imVideoCaptureDeviceCount(void)
+const char* imVideoCaptureDeviceDesc(int device)
+ +

If a device was removed or added in run time, you must update the list + calling:

+ +
int imVideoCaptureReloadDevices(void)
+ +

To handle devices you must create a imVideoCapture structure + using the function imVideoCaptureCreate. With this handle you can + manage any of the available devices, but only one device. The handle must be + destroyed with imVideoCaptureDestroy.

+

If you want to access two or more devices at the same time you must create + two different structures, but be aware that this usually work for high quality + devices like Firewire and USB 2.0. Webcams that use USB1.x can be used if + connected to different USB 2.0 controllers.

+

The next thing is to connect to a specific device, because all the other + remaining functions depends on this connection. Just call imVideoCaptureConnect with one of the available capture device numbers.

+

You control when a device start processing frames using imVideoCaptureLive. Once live the frames can be captured using + imVideoCaptureFrame. Or you can use imVideoCaptureOneFrame, + it will start capturing, returns the captured frame and stop capturing.

+

But before capturing a frame you may want to configure the device. You can + do it using Attributes, or at least in Windows you can do it using the + configuration dialogs with a call to imVideoCaptureShowDialog.

+

A very simple sequence of operations to capture just one frame from the + first device available:

+ +
imVideoCapture* vc = imVideoCaptureCreate(); 
+if (!imVideoCaptureConnect(vc, 0))
+  return;
+
+int width, height;
+imVideoCaptureGetImageSize(vc, &width, &height);
+
+// initializes the data pointer
+void* data = malloc(width*height*3);
+
+imVideoCaptureOneFrame(vc, data, IM_RGB);
+imVideoCaptureDestroy(vc);
+ +

The capture library is completely independent from the other libraries. It + just uses the same description of the data buffer used in imFileReadImageData.

+ +

Building

+ +

You should include the <im_capture.h> header and link with the + "im_capture.lib" library. This library is independent of all IM libraries.

+

To link with the capture library in Windows using Visual C you will need + the file "strmiids.lib". To link it + using Dev-C++ or Mingw 3 you will need the "im_capture.dll".

+

To compile the capture source code you will need the Direct X 9 SDK. Notice + that since Direct X uses COM, CoInitialize(NULL) is called when the devices + are enumerated.

+

For more information on Direct X capture, i.e. Direct Show see:

+ +

+ + http://msdn.microsoft.com/library/en-us/directx9_c/directX/htm/directshow.asp

+ + + + + + diff --git a/html/en/capture_samples.html b/html/en/capture_samples.html new file mode 100644 index 0000000..dcf795e --- /dev/null +++ b/html/en/capture_samples.html @@ -0,0 +1,34 @@ + + + + + + +Capture Samples + + + + + +

Capture Samples

+

Capture and GLUT

+ +

This application uses GLUT and OpenGL to create a window with a canvas and + draw the image into that canvas. But the image is obtained from a capture + device. The image can be processed before display and a sequence of captured + images can be saved in an AVI file during capture.

+

You can view the source code here: + glut_capture.c

+ +

Capture and IUP

+ +

This application uses IUP and OpenGL to create a window with two canvases + and draw a video capture image into one canvas. A processed image can be + displayed in the second canvas. It can also process frames from a video file.

+

You can download the source code and some compiler projects here: + iupglcap.zip

+ + + + + diff --git a/html/en/copyright.html b/html/en/copyright.html new file mode 100644 index 0000000..83354bd --- /dev/null +++ b/html/en/copyright.html @@ -0,0 +1,45 @@ + + + + +Tecgraf Library License + + + + +
+

Tecgraf Library License

+

The Tecgraf products under this license are: IUP, +CD and IM.

+ +

All the products under this license are free software: they can be used for both academic and commercial purposes at +absolutely no cost. There are no paperwork, no royalties, no GNU-like "copyleft" restrictions, +either. Just download and use it. They are licensed under the terms of the +MIT license reproduced below, and so are compatible +with GPL and also qualifies as +Open Source software. They are not in the public domain, +PUC-Rio keeps their copyright. The legal details are below.

+

The spirit of this license is that you are free to use the libraries for any purpose at no cost without having to ask +us. The only requirement is that if you do use them, then you should give us credit by including the copyright notice +below somewhere in your product or its documentation. A nice, but optional, way to give us further credit is to include +a Tecgraf logo and a link to our site in a web page for your product.

+

The libraries are designed, implemented and maintained by a team at Tecgraf/PUC-Rio in Brazil. The implementation is not derived +from licensed software. The library was developed by request of Petrobras. Petrobras permits Tecgraf to distribute the +library under the conditions here presented.

+
+

Copyright © 1994-2008 Tecgraf, PUC-Rio.

+

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated +documentation files (the "Software"), to deal in the Software without restriction, including without limitation the +rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit +persons to whom the Software is furnished to do so, subject to the following conditions:

+

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the +Software.

+

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE +WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR +COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR +OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

+
+ + + + diff --git a/html/en/cvs.html b/html/en/cvs.html new file mode 100644 index 0000000..753d871 --- /dev/null +++ b/html/en/cvs.html @@ -0,0 +1,22 @@ + + + + +CVS + + + + +

CVS

+

The CVS files are in the IM LuaForge site available at:

+

+http://luaforge.net/scm/?group_id=86  +

+

Current version can be obtained from module "im".

+

To checkout use:

+ +
CVSROOT=:pserver:anonymous@cvs.luaforge.net:/cvsroot/imtoolkit
+ + + + diff --git a/html/en/download.html b/html/en/download.html new file mode 100644 index 0000000..c509826 --- /dev/null +++ b/html/en/download.html @@ -0,0 +1,30 @@ + + + + +Download + + + + + + +

Download

+ +

The main download site is the LuaForge site available at:

+ +

+ http://luaforge.net/project/showfiles.php?group_id=86

+ +

Before downloading any precompiled binaries, you should read before the + Tecgraf Library Download Tips.

+

Some other files are available directly at the IM download folder:

+ +

+ http://www.tecgraf.puc-rio.br/im/download/

+ + + + + + diff --git a/html/en/download_tips.html b/html/en/download_tips.html new file mode 100644 index 0000000..b999eae --- /dev/null +++ b/html/en/download_tips.html @@ -0,0 +1,363 @@ + + + +Library Download Tips + + + + + + +

Tecgraf/PUC-Rio Library Download Tips

+

All the libraries were build using Tecmake. Please use it if you intend to recompile the sources. +Tecmake + can be found at +http://www.tecgraf.puc-rio.br/tecmake.

+

The IM files can be downloaded at +http://luaforge.net/project/showfiles.php?group_id=86.
+ The CD files can be downloaded at +http://luaforge.net/project/showfiles.php?group_id=88.
+ The IUP files can be downloaded at +http://luaforge.net/project/showfiles.php?group_id=89.
+ The Lua files can be downloaded at +http://luaforge.net/project/showfiles.php?group_id=110.

+

Build Configuration

+

Libraries and executables were built using speed optimization. In UNIX the dynamic libraries were NOT built with + the -fpic parameter. In MacOS X the dynamic libraries are in bundle format. The source code along with the + "config.mak" files for Tecmake are also available.

+

The DLLs were built using the cdecl calling convention. This should be +a problem for Visual Basic users.

+

In Visual C++ we use the single thread C Run Time Library for static libraries and the multi thread C RTL for DLLs. + Because this is the default in Visual Studio for new projects. In Visual C++ 8 both use the multi thread C RTL.

+

Packaging

+

The package files available for download are named according to the platform where they were build.

+

In UNIX all strings are based in the result of the command "uname -a". The package name is a concatenation of the + platform uname, the system major version number and the system +minor version number. Some times a + suffix must be added to complement the name. The default compiler is gcc, if the native compiler is used the name + receive the suffix "cc". Binaries for 64-bits receive the suffix: "_64". In Linux when gcc is changed for the same + uname in a new platform the major version number of the compiler is added as a suffix: "g3" for gcc 3 and "g4" for gcc + 4.

+

In Windows the platform name is the compiler and its major version number. +

+

All library packages contains binaries for the specified platform and includes. Packages with "_bin" suffix + contains executables only.

+

The package name is a general reference for the platform. If you have the same platform it will work fine, but it + may also work in similar platforms.

+

Here are some examples of packages:

+

iup2_4_AIX43_64_bin.tar.gz = IUP 2.4 64-bits Executables for AIX version 4.3
+iup2_4_Linux26g4_lib.tar.gz = IUP 2.4 32-bits Libraries and Includes for Linux with Kernel version 2.6 built with + gcc 4.
+iup2_4_Win32_vc7_lib.tar.gz = IUP 2.4 32-bits Libraries and Includes for Windows to use with Visual C++ 7.
+iup2_4_Docs_html.tar.gz = IUP 2.4 documentation files in HTML format (the web site files can be browsed + locally).
+iup2_4_Win32_bin.tar.gz = IUP 2.4 32-bits Executables for Windows.

+

The documentation files are in HTML format. They do not include the CHM and PDF versions. These two files are + provided only as a separate download, but they all have the same documentation.

+

Installation

+

For any platform we recommend you to create a folder to contain the third party libraries you download. Then just + unpack the packages you download in that folder. The packages already contains a directory structure that separates + each library or toolkit. For example:

+
\mylibs\
+        iup\
+            bin\
+            html\
+            include\
+            lib\Linux26
+            lib\vc7
+            src
+        cd\
+        im\
+        lua5\
+

This structure will also made the process of building from sources more simple, since the projects and makefiles + will assume this structure .

+

Usage

+

For makefiles use:

+
1) "-I/mylibs/iup/include" to find include files
+2) "-L/mylibs/iup/lib/Linux26" to find library files
+3) "-liup" to specify the library files
+

For IDEs the configuration involves the same 3 steps above, but each IDE has a different dialog. The IUP toolkit + has a Guide for some IDEs:

+

Open Watcom - http://www.tecgraf.puc-rio.br/iup/en/guide/owc.html +
+ Dev-C++ - http://www.tecgraf.puc-rio.br/iup/en/guide/dev-cpp.html +
+ Borland C++ BuilderX - +http://www.tecgraf.puc-rio.br/iup/en/guide/cppbx.html
+ Microsoft Visual C++ (Visual Studio 2003) - +http://www.tecgraf.puc-rio.br/iup/en/guide/msvc.html
+ Microsoft Visual C++ (Visual Studio 2005) - +http://www.tecgraf.puc-rio.br/iup/en/guide/msvc8.html
+Eclipse for C++ - + +http://www.tecgraf.puc-rio.br/iup/en/guide/eclipse.html +

+

Available Platforms

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
AIX43 IBM AIX 4.3 (ppc) / gcc 2.95 / Motif 2.1 +
AIX43cc IBM AIX 4.3 (ppc) / cc 4.4 / Motif 2.1
AIX43_64 IBM AIX 4.3 (ppc) (64 bits libraries) / cc 4.4 / Motif 2.1
IRIX65 SGI IRIX 6.5 (mips) / gcc 3.0 / Motif 2.1 +
IRIX6465 SGI IRIX 6.5 (mips) / gcc 3.3 / Motif 1.2
IRIX6465cc SGI IRIX 6.5 (mips) / cc MIPSpro 7.4 / Motif 1.2 +
IRIX6465_64 SGI IRIX 6.5 (mips) (64 bits libraries) / cc MIPSpro 7.4 / Motif 1.2
Linux24 Red Hat 7.3 (x86) / Kernel 2.4 / gcc 2.95 / Open Motif 2.1 +
Linux24g3 CentOS 3.9 (x86) / Kernel 2.4 / gcc 3.2 / Open Motif 2.2 + 3
Linux24g3_64   Red Hat E.L. WS 3 (x64)  (64 bits libraries) / Kernel 2.4 / gcc 3.2 / Open Motif + 2.2 3
Linux26 CentOS 4.5 (x86) / Kernel 2.6 / gcc 3.4 / Open Motif 2.2 + 3
Linux26_64 CentOS 4.5 (x64) / Kernel 2.6 / gcc 3.4 / Open Motif 2.2 + 3
Linux26g4 Ubuntu 6.06 (x86) / Kernel 2.6 / gcc 4.0 / Open Motif + 2.2 3
Linux26g4_64 Ubuntu 6.10 (x64) / Kernel 2.6 / gcc 4.1 / + OpenMotif 2.2 3
Linux26g4ppc Ubuntu 7.10 (ppc) / Kernel 2.6 / gcc 4.1 / Open Motif 2.2 + 3
Linux26_ia64 Red Hat E.L. AS 4 (ia64) / Kernel 2.6 / gcc 3.4 / + Open Motif 2.2 3
SunOS57 Sun Solaris 7 (sparc) / gcc 2.95 / Motif 2.1 +
SunOS57cc Sun Solaris 7 (sparc) / cc 5.2 (Sun WorkShop 6 update 1) / Motif 2.1 +
SunOS57_64 Sun Solaris 7 (sparc) (64 bits libraries) / cc 5.2 (Sun WorkShop 6 update 1) / Motif 2.1 +
SunOS58 Sun Solaris 8 (sparc) / gcc 3.4 / Motif 2.1 +
SunOS58cc Sun Solaris 8 (sparc) / Sun WorkShop 6 update 2 C++ 5.3 / Motif 2.1 +
SunOS58_64 Sun Solaris 8 (sparc) / Sun WorkShop 6 update 2 C++ 5.3 / Motif 2.1 +
SunOS510x86 Sun Solaris 10 (x86) / gcc 3.3 / Motif 2.1 +
FreeBSD54 Free BSD 5.4 (x86) / gcc 3.4 / Open Motif 2.2 + 3
HP-UXB11 HP-UX 11 (9000) / HP ANSI C++ B3910B / Motif 2.1
Darwin811 Mac OS X 10.4.11 (ppc) / Darwin Kernel Version 8.11 / gcc 4.0 / + Open Motif 2.1
Darwin811x86 Mac OS X 10.4.11 (x86) / Darwin Kernel Version 8.11 / gcc 4.0 / + Open Motif 2.1
Win32_vc6 Microsoft Visual C++ 6 (static RTL/single thread)
Win32_vc7 Microsoft Visual C++ 7.1 (.NET 2003) (static RTL/single thread)
+  Also compatible with Microsoft Visual C++ Toolkit 2003 -
+  http://msdn.microsoft.com/visualc/vctoolkit2003/ + ¹
Win32_vc8 Microsoft Visual C++ 8.0 (2005) (static RTL/multithread)
+  Also compatible with Microsoft Visual C++ 2005 Express Edition -
+  http://msdn.microsoft.com/vstudio/express/visualc/ + ¹
Win32_vc9 Microsoft Visual C++ 9.0 (2008) (static RTL/multithread)
+  Also compatible with Microsoft Visual C++ 2008 Express Edition -
+  http://msdn.microsoft.com/vstudio/express/visualc/ + ¹
Win32_dll built using vc6, creates dependency with MSVCRT.DLL
+  (either other libraries or new applications).
Win32_dll7 built using vc7, creates dependency with MSVCR71.DLL
+  (either other libraries or new applications).
Win32_dll8 built using vc8, creates dependency with MSVCR80.DLL
+  (either other libraries or new applications).
Win32_dll9 built using vc9, creates dependency with MSVCR90.DLL
+  (either other libraries or new applications).
Win64_vc8  Same as Win32_vc8 but for 64-bits + systems using x64 standard.
Win64_vc9  Same as Win32_vc9 but for 64-bits + systems using x64 standard.
Win64_dll8  Same as Win32_dll8 but for 64-bits + systems using x64 standard.
Win64_dll9  Same as Win32_dll9 but for 64-bits + systems using x64 standard.
Win32_gcc3 Cygwin gcc 3.4  (Depends on Cygwin DLL 1.5) - + http://www.cygwin.com/ + ¹
Win32_cygw15 Same as Win32_gcc3, but using the Cygwin Posix + system
Win32_mingw3 MingW gcc 3.4 - + http://www.mingw.org/ + ¹
+  Also compatible with Dev-C++ - + http://www.bloodshed.net/devcpp.html + ¹
Win32_mingw4 MingW gcc 4.x (unofficial) - + http://www.develer.com/oss/GccWinBinaries + ¹
Win32_owc1 Open Watcom 1.5 - + http://www.openwatcom.org/
Win32_bc56 Borland C++ BuilderX 1.0 / Borland C++ 5.6 Compiler - +
+  http://www.borland.com/products/downloads/download_cbuilderx.html + ¹,²
+  (the C++ BuilderX IDE can also be configured to use mingw3 or gcc3 versions.) +
Win32_bin Executables only for Windows NT/2000/XP
Win64_bin Same as Win32_bin but for 64-bits systems + using the x64 standard
Win32_cygw15_bin Executables only for Windows NT/2000/XP, but + using the Cygwin Posix system
+ +

¹ - Notice that all the Windows + compilers with links here are free to download and use.
+ ² - Recently Borland removed the C++ Builder X + from download. But if you bought a book that has the CD of the compiler, then + it is still free to use.
+ 3 - OpenMotif 2.2 is classified as + 'experimental' by the Open Group.

+ + + + + \ No newline at end of file diff --git a/html/en/guide.html b/html/en/guide.html new file mode 100644 index 0000000..c4ea993 --- /dev/null +++ b/html/en/guide.html @@ -0,0 +1,282 @@ + + + + + + +Guide + + + + + + +

Guide

+

Getting Started

+ +

It is important to understand that IM is based in 4 concepts: Image Representation, Image Storage, + Image Processing and Image Capture. The following picture illustrates the relation between theses concepts.

+

+

IM does not have support for Image Visualization, because we think this is a task for a graphics library + like OpenGL, Windows GDI or CD + - Canvas Draw.

+

Image Representation describes the image model and its details. Which color systems are going to be used, + which data types, how the data is organized in memory, and how other image characteristics are accessed.

+

Image Storage describers the file format model and how images are obtained or saved. Image Capture + describes the access to a capture device and obtaining an image from it. Image Processing describes the image + processing operations.

+

There are infinite ways to implement these concepts. There is no common definition in the literature, but there is + a standard called Programmer's Imaging Kernel System (PIKS) published at the ISO/IEC 12087. PIKS is a very complete + and also complex standard, very hard to implement. There are only a few implementations available, and the one that I + know is commercial software, Pixel Soft of William Pratt + http://www.pixelsoft.com/, also author of several books on the subject.

+

But we want something easier to implement and understand. The free available libraries that we found where + sometimes close to what we want, sometimes very far. So we developed our own.

+

The documentation contains Overview, Guide, Samples and Reference sections for each one of the IM + concepts.

+

The Guide is where you are going to find the explanation about the concepts and decisions made during the + library design. It is the best place to understand how things works.

+

The Reference contains pure essential information for function and structure usage. But there is no + information on how to put the functions to work together. It is generated automatically from the source code using + Doxygen, this means also that the include files (*.h) are very well commented.

+ +

Building Applications

+ +

Inside you code you should at least include the <im.h> header and link with the "im.lib/libim.a/libim.so" library. + This library contains all the Image Representation functions and all the Image Storage functions (with + the exception of the external formats: AVI, JP2 and WMV).

+

Each external format or processing usually needs a <im_xx.h> file and a "im_xx.lib/libim_xx.a/libim_xx.so" file.

+

Even if your applicattion is only in C, you must link with a C++ capable linker. Using Tecmake set "LINKER := g++" + in your "config.mak" when compiling with gcc (UNIX and Windows).

+

The download files list includes the Tecgraf/PUC-Rio Library Download Tips + document, with a description of all the available binaries.

+ +

Building the Library

+ +

In the Downloads you will ne able to find pre-compiled binaries for many +platforms, all those binaries were built using Tecmake. Tecmake is a command line multi compiler build tool +based on GNU make, available at + http://www.tecgraf.puc-rio.br/tecmake. Tecmake is + used by all the Tecgraf libraries and many applications.

+

In UNIX, you do not need to install Tecmake, a compact version of Tecmake for +UNIX is already included in the source code package. Just type "make" in the +command line on the "src" folder and all libraries and executables will be +build. +

+

In Windows, the easiest way to build everything is to install the Tecmake tool into your system. It is easy and helps a lot. + The Tecmake configuration files (*.mak) available at the "src" folder are very easy to understand also. +Also there are files named +make_uname.bat that build the libraries using Tecmake. To build for Windows using + Visual C 7.0 (2005) for example, just execute "make_uname vc7" , or the +DLLs with Visual C++ 9 (2008) type "make_uname dll9". The Visual +Studio workspaces with the respective projects available in the source package +is for debugging purposes only.

+

Make sure you have all the dependencies for the library you want installed, +see the documentation bellow.

+

If you are going to build all the libraries, +the makefiles and projects expect the following directory tree:

+
\mylibs\
+        im\
+        lua5.1\
+

Libraries Dependencies

+
im -> libjpeg (included)
+   -> libpng  (included)
+   -> libtiff (included)
+   -> zlib    (included)
+   -> liblzf  (included)
+   -> libexif (included)
+im_jp2 -> im
+       -> libJasper (included)
+im_avi -> im
+       -> vfw32 (system - Windows)
+im_wmv -> im
+       -> wmvcore (system - Windows)
+im_ecw -> im
+       -> NCSEcw (system)
+im_capture -> strmiids (system - Windows)
+im_process -> im
+im_fftw -> im
+        -> fftw (included)
+imlua51 -> im
+        -> lua5.1
+imlua_capture51 -> imlua51
+                -> im_capture
+imlua_fftw51 -> imlua51
+             -> im_fftw
+imlua_process51 -> imlua51
+                -> im_process
+

As a general rule (excluding system dependencies and included third party +libraries): IM has NO external dependencies, and IMLua depends on Lua.

+ +

CD Compatibility

+ +

IM version 2 was designed to perfectly work with the CD + - Canvas Draw toolkit. Version 3 has many more options and only for a subset of the images called Bitmaps can be + used with the CD functions. Theses images have data type IM_BYTE, and color mode + IM_RGB, IM_GRAY, + IM_MAP or IM_BINARY. They can not have the flags IM_TOPDOWN and + IM_PACKED. + But it can have the flag IM_ALPHA for IM_RGB images.

+

You can convert an image to a bitmap version of it using the function imConvertToBitmap, see + Image Representation / Conversion.

+

Function cdCanvasGetImageRGB captures an image from the active canvas. Functions + cdCanvasPutImageRect* draw a client image on the active canvas. These + functions allow reducing or increasing the image when drawing.

+

For applications in systems with only 256 colors available, we recommend the use of function + cdCanvasPalette before drawing the image, to improve its quality.

+

When using the imImage structure the macro + imcdCanvasPutImage can be used. It is defined as:

+
+ +
#define imcdCanvasPutImage(_canvas, _image, _x, _y, _w, _h, _xmin, _xmax, _ymin, _ymax)     \
+  {                                                                         \
+    if (_image->color_space == IM_RGB)                                      \
+    {                                                                       \
+      if (image->has_alpha)                                                 \
+        cdCanvasPutImageRectRGBA(_canvas, _image->width, _image->height,    \
+                          (unsigned char*)_image->data[0],                  \
+                          (unsigned char*)_image->data[1],                  \
+                          (unsigned char*)_image->data[2],                  \
+                          (unsigned char*)_image->data[3],                  \
+                          _x, _y, _w, _h, _xmin, _xmax, _ymin, _ymax);      \
+      else                                                                  \
+        cdCanvasPutImageRectRGB(_canvas, _image->width, _image->height,     \
+                          (unsigned char*)_image->data[0],                  \
+                          (unsigned char*)_image->data[1],                  \
+                          (unsigned char*)_image->data[2],                  \
+                          _x, _y, _w, _h, _xmin, _xmax, _ymin, _ymax);      \
+    }                                                                       \
+    else                                                                    \
+      cdCanvasPutImageRectMap(_canvas, _image->width, _image->height,       \
+                        (unsigned char*)_image->data[0], _image->palette,   \
+                        _x, _y, _w, _h, _xmin, _xmax, _ymin, _ymax);        \
+  }
+ +
+

CD Library is the Tecgraf 2D graphics library available at + http://www.tecgraf.puc-rio.br/cd.

+ +

OpenGL Compatibility

+ +

The function glDrawPixels accepts several data types and color modes. Here are the format and + type mapping for OpenGL usage:

+ +
           IM             <->  OpenGL
+
        color_mode             format
+IM_RGB|IM_ALPHA|IM_PACKED  = GL_RGBA               
+IM_RGB|IM_PACKED           = GL_RGB
+IM_GRAY                    = GL_LUMINANCE
+IM_GRAY|IM_ALPHA|IM_PACKED = GL_LUMINANCE_ALPHA
+
        data_type              type
+IM_BYTE                    = GL_UNSIGNED_BYTE
+IM_BINARY                  = GL_BITMAP
+IM_USHORT                  = GL_UNSIGNED_SHORT
+IM_INT                     = GL_INT
+IM_FLOAT                   = GL_FLOAT
+ +

There is no mapping for non IM_PACKED images so if you use unpacked planes (ex: you use the + imImage structure) then you have to convert one data into another, the function + imConvertPacking + does this, so you just have to keep an extra buffer for the display image and call this function only when your + original image has changed. See Image + Representation / Conversion. For example:

+ +
imConvertPacking(image->data[0], gl_data, image->width, image->height, image->depth, image->data_type, 0);
+glPixelStorei(GL_UNPACK_ALIGNMENT, 1); /* data alignment must be 1 */
+
+glDrawPixels(image->width, image->height, GL_RGB, GL_UNSIGNED_BYTE, (GLvoid*)gl_data);
+ +

When loading color image data you can use the function imConvertMapToRGB to convert in-place IM_MAP image data into + IM_RGB after loading it from file. For example:

+ +
if (imColorSpace(color_mode) == IM_MAP)
+{
+  long palette[256];
+  int palette_count, packed = 1; /* OpenGL uses packed RGB */
+  imFileGetPalette(ifile, palette, &palette_count);
+  imConvertMapToRGB(gl_data, width*height, depth, packed, palette, palette_count);
+}
+ +

If you just want to save your OpenGL buffer then you can use:

+ +
glPixelStorei(GL_PACK_ALIGNMENT, 1); /* data alignment must be 1 */
+glReadPixels(x, y, width, height, GL_RGB, GL_UNSIGNED_BYTE, (GLvoid*)gl_data);
+
+ifile = imFileNew(filename, format, &error);
+error = imFileWriteImageInfo(ifile, width, height, IM_RGB|IM_PACKED, IM_BYTE);
+error = imFileWriteImageData(ifile, gl_data);
+imFileClose(ifile); 
+ +

You can also put glReadPixels and imFileWriteImageInfo/imFileWriteImageData + inside a loop to create an animation.

+ +

IM 2.x Compatibility

+ +

In version 3.0 the library was completely rewritten. And we changed the main API to allow more powerful features. + But the old API is still available for backward compatibility. Version 3 is also binary compatible with version 2.

+

The only change that must be updated in old applications if they where recompiled is some error code definitions. + If you use them in a case there will cause a compiler error because IM_ERR_READ and + IM_ERR_WRITE + are now defined as IM_ERR_ACCESS both.

+ +

Migrating OLD Code

+ +

The old API is very inefficient because the file is opened and close three times, for: + imFileInfo, + imImageInfo and imLoadRGB/imLoadMap. There is no room for attributes, so we use + the callbacks. And we can not load sequences of images. For these reasons we change the API.

+

If you would like to migrate your code using the old API the most important thing to change is the memory + allocation. For RGB images instead of allocating 3 separate pointers you should allocate only one pointer with room + for all three planes. If you still want to keep the three pointers, just do green = red + width*height + and blue = red + 2*width*height.

+

Also you should change your callbacks usage for attributes access using imFileGetAttribute and + imFileSetAttribute. IM_RESOLUTION_CB is replaced by the attributes "XResolution", "YResolution", + "ResolutionUnit". IM_GIF_TRANSPARENT_COLOR_CB is replaced by "TransparencyIndex" + and IM_TIF_IMAGE_DESCRIPTION_CB by "Description".

+

Except IM_COUNTER_CB that is not an attribute, still works with a callback, but now we implement a + counter system for all the library including loading, saving and processing. The user just use the + imCounterSetCallback (like before) to register it counter callback, now there are a few more parameters and a + user data pointer. See Utilities / Counter. +

+

The function calls to imImageInfo and imLoadRGB/imLoadMap will be replaced + by a sequence of function calls to imFileOpen/imFileNew,  + imFileReadImageInfo/imFileWriteImageInfo, + imFileReadImageData/imFileWriteImageData and imFileClose. See + Image Storage.

+ +

Names Convention

+ +

To improve the readability of the code we use a very simple naming convention:

+ + +

C x C++ Usage

+ +

The library main API is in C. We adopt this because of the many C programmers out there. Some of the API is also + available in C++ for those addicted to classes.

+

Internally C++ is used to implement the format driver base architecture. A virtual base class that every drivers + inherits from. This made a lot of things easier to the driver development. But we keep it simple, no multiple + inheritance, no exception handling, no complicated classes.

+

But because we need several data types C++ templates were inevitable used (since we do not like long macros + everywhere). But they are used only for processing functions, not classes.

+ + + + + diff --git a/html/en/history.html b/html/en/history.html new file mode 100644 index 0000000..a030602 --- /dev/null +++ b/html/en/history.html @@ -0,0 +1,347 @@ + + + + +History + + + + + + + +

History of Changes

+

Version 3.4 (14/Oct/2008)

+ +

Version 3.3 (26/Nov/2007)

+ +

Version 3.2 (24/Nov/2006)

+ +

Version 3.1 (12/Dez/2005)

+ +

Version 3.0.3 (14/Oct/2004)

+ +

Version 3.0.2 (25/Aug/2004)

+ +

- New: utility functions imPaletteHighContrast, + imImageLoadImage and + imImageLoadBitmap.
+ - New: operation imProcessNormalizeComponents.
+ - Changed: name imProcessGaussianConvolve to + imProcessGaussianConvolveRep. New: + operation imProcessGaussianConvolve that uses a float kernel. + New: utility functions + imGaussianStdDev2Repetitions and imGaussianStdDev2KernelSize.
+ - Changed: name imProcessDiffOfGaussianConvolve to + imProcessDiffOfGaussianConvolveRep. + New: operation imProcessDiffOfGaussianConvolve that uses a float kernel.
+ - Changed: IM_GAMUT_BRIGHTCONT + parameters to the interval [-100,100]. Fixed: + IM_GAMUT_EXPAND and IM_GAMUT_BRIGHTCONT normalization.
+ - Changed: logical operations, flag IM_BIT_NOT + replaced by operation imProcessBitwiseNot.
+ - Changed: imImageSetAttribute count can be -1 for zero terminated data.
+ - Fixed: operations imProcessBitwiseNot and + imProcessNegative for IM_BINARY images.
+ - Fixed: the color_mode_flags parameter interpretation by + imFileReadImageData. +
+ - Fixed: imProcessEqualizeHistogram and + imProcessExpandHistogram for + color images.
+ - Fixed: imProcessMultipleStdDev.
+ - Fixed: imProcessDifusionErrThreshold for + IM_GRAY images.
+ - Fixed: "KRN" format, internal format is topdown.
+ - Fixed: initialization of TGA image_count.

+ +

Version 3.0.1 (22/Apr/2004)

+ +

- Improved compatibility with the old version, it was missing the load of Map images with + imLoadRGB.
+ - The FFTW code was from version 2.1.3, not from 2.1.5 as suposed, it was updated. The FFT functions were condensed in + only one file with an "#ifdef" for FFTW version 2 and 3. The FFT functions also were renamed to remove the "W" that + belongs only to the FFTW library.
+ - The SetAttribute functions now accept NULL in data to remove the attribute.
+ - New: imProcessCrossCorrelation and imProcessAutoCorrelation functions.
+ - The imCalcGrayHistogram function now can calculate the histogram of + IM_MAP + and IM_BINARY images.

+ +

Version 3.0 (April 2004)

+ +

A major rewrite of the library. Everything changed, check the manual, but backward compatibility is kept for old + applications. A new API more flexible, new formats, support for attributes and video, image capture and image + processing. New: color spaces and data types. The library now got a professional look for scientific applications.

+ +

Version 2.6 (May 2002)

+ +

Correction of bug in resolution reading and writing for format JPEG.

+ +

Version 2.5 (August 2001)

+ +

Correction of bug in the default GIF compression. Two new callbacks: transparency color index for GIF files and + image description for TIFF files.

+ +

Version 2.4 (February 2000)

+ +

Change in the treatment of LZW compression in formats TIFF and GIF. Now compression is no longer the default.

+ +

Version 2.3 (June 1998)

+ +

Close function of the access driver for files in memory corrected. JPEG library updated to 6b. Correction of a + problem with the reading of some JPEG files.

+ +

Version 2.2 (November 1997)

+ +

The definition of the counter callback was changed to inform, in a parameter, the type of access being performed, + either reading or writing. Type imCallback defined to make type casting easier when using function + imRegisterCallback. Correction of a problem with the makefile in UNIX, which was generating link + errors in some platforms.

+ +

Version 2.1 (October 1997)

+ +

Correction of a problem with internal memory liberation when reading Map images in TIFF files. Conversion RGB to + Map is now made using the algorithm implemented by LibJPEG. The algorithm of imResize was + improved for cases in which the size is being reduced instead of increased. Correction of a problem with functions + imImageInfo and imFileFormat: when the provided file was not in a format recognized + by IM, there was an error in format TGA which caused these functions to access an invalid memory area.

+ +

Version 2.0 (September 1997)

+ +

The library was virtually rewritten to implement a new structure which allowed greater flexibility, simplifying the + addition of new formats. Formats TGA, PCL, JPEG and LED + were added to the list of supported formats, and new functions were added: imMap2RGB, + imRGB2Gray, imMap2Gray, imResize, imStretch.

+ +

Version 1.1 (June 1996)

+ +

Small corrections to increase portability. Changes in return codes. Identifiers were created to return codes and + predefined parameters. Online manual concluded.

+ +

Version 1.0 (October 1995)

+ + + + \ No newline at end of file diff --git a/html/en/home.html b/html/en/home.html new file mode 100644 index 0000000..bd5efe4 --- /dev/null +++ b/html/en/home.html @@ -0,0 +1,28 @@ + + + + + +Home + + + + +
IM
+
Image Representation, Storage, Capture and Processing
+
Version 3.4
+
+

IM is a toolkit for Digital Imaging. IM is based on 4 concepts: Image Representation, Storage, Processing + and Capture. The main goal of the library is to provide a simple API and abstraction of images for scientific + applications.

+

The most popular file formats are supported: TIFF, BMP, PNG, JPEG, GIF and AVI. Image representation includes + scientific data types. About a hundred Image Processing operations are available.

+

This work was developed at Tecgraf/PUC-Rio by means of the partnership with PETROBRAS/CENPES.

+

Project Management:

+

Antonio Escaño Scuri

+

Tecgraf - Computer Graphics Technology Group, PUC-Rio, Brazil
+http://www.tecgraf.puc-rio.br/im

+ + + + diff --git a/html/en/imaging.gif b/html/en/imaging.gif new file mode 100644 index 0000000..4878803 Binary files /dev/null and b/html/en/imaging.gif differ diff --git a/html/en/imlua.html b/html/en/imlua.html new file mode 100644 index 0000000..63ebd05 --- /dev/null +++ b/html/en/imlua.html @@ -0,0 +1,124 @@ + + + + + + +Lua Binding + + + + + +

Lua Binding Guide

+

Overview

+ +

ImLua was developed to make all functionalities of the + IM library available to Lua programmers. To use the ImLua + bindings, your executable must be linked with the "imlua" library, and you must call the initialization function + imlua_open declared in the header file + imlua.h, + as seen in the example below:

+ +
+
+ + + + + + + +
+

in Lua 5

+
#include <lua.h>
+#include <lualib.h>
+#include <lauxlib.h>
+#include <imlua.h>
+
void main(void)
+{
+  lua_State *L = lua_open();
+
+  luaopen_string(L);
+  luaopen_math(L);
+  luaopen_io(L);  
+
+  imlua_open(L);
+
+  lua_dofile("myprog.lua");
+  
+  lua_close(L);
+}
+
+
+
+ +

The imlua_open function registers all IM functions and constants + your Lua program will need. The use of the ImLua functions in Lua is generally identical to their equivalents in C. + Nevertheless, there are several exceptions due to differences between the two languages. Notice that, as opposed to C, + in which the flags are combined with the bitwise operator OR, in Lua the flags are added arithmetically.

+

The other secondary libraries also have their initialization functions declared in + imlua.h + and each one have a separate library to be linked with the application. See IM Lua + 5 Binding reference.

+

The ImLua dynamic libraries are also compatible with the Lua 5 "loadlib" function. + Here is an example on how to dynamically load IM + in Lua 5.1:

+
local imlua_open = package.loadlib("imlua51.dll", "imlua_open")
+imlua_open()
+

Lua 5.1 "require" can be used for all the +ImLua +libraries. You can use require"imlua" and so on, but the LUA_CPATH +must also contains the following:

+ +
"./lib?51.so;"    [in UNIX]
+
+".\\?51.dll;"     [in Windows]
+

The LuaBinaries distribution already includes these modifications on the +default search path.

+

The simplest form require"im" +and so on, can not be used because there are IM dynamic libraries with names +that will conflict with the names used by require during search.

+

Function Names and Definitions

+ +

In Lua, because of the name space "im" all the functions and definitions have their names prefix changed. The + general rule is quite simple:

+ +
imXxx  -> im.Xxx
+IM_XXX -> im.XXX
+imFileXXX(ifile,... -> ifile:XXX(...
+imImageXXX(image,... -> image:XXX(...
+ + +

Modifications to the API

+ +

New functions (without equivalents in C) were implemented to create and + destroy objects that do not exist in C. For instance functions were developed + to create and destroy images, files, viceo capture and palette. All the + metatables have the "tostring" method implemented to help debuging.

+ +

Some functions were modified to receive those objects as parameters.

+

Also the functions which receive values by reference in C were modified. Generally, the values of + parameters that would have their values modified are now returned by the function in the same order.

+

In C there is no parameter checking in the processing functions, but in Lua +all parameters are checked and a Lua error is emitted when check fails.

+ + +

Garbage Collection

+ +

All the objects are garbage collected by the Lua garbage collector.

+ +

Integration with CDLua

+ +

In CDLua there is an additional library providing simple functions to map the + imImage + structure to the cdBitmap structure. And some facilities to + draw an image in a CD canvas. See also the CD documentation and + the IM Lua 5 Binding reference.

+

Color values and palettes can be created and used transparently in both libraries. Palettes and color values are + 100% compatible between CD and IM.

+ + + + + \ No newline at end of file diff --git a/html/en/libjasper.txt b/html/en/libjasper.txt new file mode 100644 index 0000000..f817ef4 --- /dev/null +++ b/html/en/libjasper.txt @@ -0,0 +1,51 @@ +JasPer License Version 2.0 + +Copyright (c) 2001-2006 Michael David Adams +Copyright (c) 1999-2000 Image Power, Inc. +Copyright (c) 1999-2000 The University of British Columbia + +All rights reserved. + +Permission is hereby granted, free of charge, to any person (the +"User") obtaining a copy of this software and associated documentation +files (the "Software"), to deal in the Software without restriction, +including without limitation the rights to use, copy, modify, merge, +publish, distribute, and/or sell copies of the Software, and to permit +persons to whom the Software is furnished to do so, subject to the +following conditions: + +1. The above copyright notices and this permission notice (which +includes the disclaimer below) shall be included in all copies or +substantial portions of the Software. + +2. The name of a copyright holder shall not be used to endorse or +promote products derived from the Software without specific prior +written permission. + +THIS DISCLAIMER OF WARRANTY CONSTITUTES AN ESSENTIAL PART OF THIS +LICENSE. NO USE OF THE SOFTWARE IS AUTHORIZED HEREUNDER EXCEPT UNDER +THIS DISCLAIMER. THE SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS +"AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A +PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO +EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL +INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING +FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, +NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION +WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. NO ASSURANCES ARE +PROVIDED BY THE COPYRIGHT HOLDERS THAT THE SOFTWARE DOES NOT INFRINGE +THE PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS OF ANY OTHER ENTITY. +EACH COPYRIGHT HOLDER DISCLAIMS ANY LIABILITY TO THE USER FOR CLAIMS +BROUGHT BY ANY OTHER ENTITY BASED ON INFRINGEMENT OF INTELLECTUAL +PROPERTY RIGHTS OR OTHERWISE. AS A CONDITION TO EXERCISING THE RIGHTS +GRANTED HEREUNDER, EACH USER HEREBY ASSUMES SOLE RESPONSIBILITY TO SECURE +ANY OTHER INTELLECTUAL PROPERTY RIGHTS NEEDED, IF ANY. THE SOFTWARE +IS NOT FAULT-TOLERANT AND IS NOT INTENDED FOR USE IN MISSION-CRITICAL +SYSTEMS, SUCH AS THOSE USED IN THE OPERATION OF NUCLEAR FACILITIES, +AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL +SYSTEMS, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH +THE FAILURE OF THE SOFTWARE OR SYSTEM COULD LEAD DIRECTLY TO DEATH, +PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE ("HIGH +RISK ACTIVITIES"). THE COPYRIGHT HOLDERS SPECIFICALLY DISCLAIM ANY +EXPRESS OR IMPLIED WARRANTY OF FITNESS FOR HIGH RISK ACTIVITIES. + diff --git a/html/en/libjpeg.txt b/html/en/libjpeg.txt new file mode 100644 index 0000000..3937918 --- /dev/null +++ b/html/en/libjpeg.txt @@ -0,0 +1,48 @@ +LEGAL ISSUES +============ + +In plain English: + +1. We don't promise that this software works. (But if you find any bugs, + please let us know!) +2. You can use this software for whatever you want. You don't have to pay us. +3. You may not pretend that you wrote this software. If you use it in a + program, you must acknowledge somewhere in your documentation that + you've used the IJG code. + +In legalese: + +The authors make NO WARRANTY or representation, either express or implied, +with respect to this software, its quality, accuracy, merchantability, or +fitness for a particular purpose. This software is provided "AS IS", and you, +its user, assume the entire risk as to its quality and accuracy. + +This software is copyright (C) 1991-1998, Thomas G. Lane. +All Rights Reserved except as specified below. + +Permission is hereby granted to use, copy, modify, and distribute this +software (or portions thereof) for any purpose, without fee, subject to these +conditions: +(1) If any part of the source code for this software is distributed, then this +README file must be included, with this copyright and no-warranty notice +unaltered; and any additions, deletions, or changes to the original files +must be clearly indicated in accompanying documentation. +(2) If only executable code is distributed, then the accompanying +documentation must state that "this software is based in part on the work of +the Independent JPEG Group". +(3) Permission for use of this software is granted only if the user accepts +full responsibility for any undesirable consequences; the authors accept +NO LIABILITY for damages of any kind. + +These conditions apply to any software derived from or based on the IJG code, +not just to the unmodified library. If you use our work, you ought to +acknowledge us. + +Permission is NOT granted for the use of any IJG author's name or company name +in advertising or publicity relating to this software or products derived from +it. This software may be referred to only as "the Independent JPEG Group's +software". + +We specifically permit and encourage the use of this software as the basis of +commercial products, provided that all warranty or liability claims are +assumed by the product vendor. diff --git a/html/en/liblzf.txt b/html/en/liblzf.txt new file mode 100644 index 0000000..00ec071 --- /dev/null +++ b/html/en/liblzf.txt @@ -0,0 +1,30 @@ +Copyright (c) 2000-2005 Marc Alexander Lehmann + +Redistribution and use in source and binary forms, with or without modifica- +tion, are permitted provided that the following conditions are met: + + 1. Redistributions of source code must retain the above copyright notice, + this list of conditions and the following disclaimer. + + 2. Redistributions in binary form must reproduce the above copyright + notice, this list of conditions and the following disclaimer in the + documentation and/or other materials provided with the distribution. + + 3. The name of the author may not be used to endorse or promote products + derived from this software without specific prior written permission. + +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED +WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MER- +CHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO +EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPE- +CIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, +PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; +OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, +WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTH- +ERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED +OF THE POSSIBILITY OF SUCH DAMAGE. + +Alternatively, the following files carry an additional notice that +explicitly allows relicensing under the GPLv2: lzf.c lzf.h lzfP.h lzf_c.c +lzf_d.c + diff --git a/html/en/libpng.txt b/html/en/libpng.txt new file mode 100644 index 0000000..2640ec9 --- /dev/null +++ b/html/en/libpng.txt @@ -0,0 +1,109 @@ + +This copy of the libpng notices is provided for your convenience. In case of +any discrepancy between this copy and the notices in the file png.h that is +included in the libpng distribution, the latter shall prevail. + +COPYRIGHT NOTICE, DISCLAIMER, and LICENSE: + +If you modify libpng you may insert additional notices immediately following +this sentence. + +libpng versions 1.2.6, August 15, 2004, through 1.2.22, October 13, 2007, are +Copyright (c) 2004, 2006-2007 Glenn Randers-Pehrson, and are +distributed according to the same disclaimer and license as libpng-1.2.5 +with the following individual added to the list of Contributing Authors + + Cosmin Truta + +libpng versions 1.0.7, July 1, 2000, through 1.2.5 - October 3, 2002, are +Copyright (c) 2000-2002 Glenn Randers-Pehrson, and are +distributed according to the same disclaimer and license as libpng-1.0.6 +with the following individuals added to the list of Contributing Authors + + Simon-Pierre Cadieux + Eric S. Raymond + Gilles Vollant + +and with the following additions to the disclaimer: + + There is no warranty against interference with your enjoyment of the + library or against infringement. There is no warranty that our + efforts or the library will fulfill any of your particular purposes + or needs. This library is provided with all faults, and the entire + risk of satisfactory quality, performance, accuracy, and effort is with + the user. + +libpng versions 0.97, January 1998, through 1.0.6, March 20, 2000, are +Copyright (c) 1998, 1999 Glenn Randers-Pehrson, and are +distributed according to the same disclaimer and license as libpng-0.96, +with the following individuals added to the list of Contributing Authors: + + Tom Lane + Glenn Randers-Pehrson + Willem van Schaik + +libpng versions 0.89, June 1996, through 0.96, May 1997, are +Copyright (c) 1996, 1997 Andreas Dilger +Distributed according to the same disclaimer and license as libpng-0.88, +with the following individuals added to the list of Contributing Authors: + + John Bowler + Kevin Bracey + Sam Bushell + Magnus Holmgren + Greg Roelofs + Tom Tanner + +libpng versions 0.5, May 1995, through 0.88, January 1996, are +Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc. + +For the purposes of this copyright and license, "Contributing Authors" +is defined as the following set of individuals: + + Andreas Dilger + Dave Martindale + Guy Eric Schalnat + Paul Schmidt + Tim Wegner + +The PNG Reference Library is supplied "AS IS". The Contributing Authors +and Group 42, Inc. disclaim all warranties, expressed or implied, +including, without limitation, the warranties of merchantability and of +fitness for any purpose. The Contributing Authors and Group 42, Inc. +assume no liability for direct, indirect, incidental, special, exemplary, +or consequential damages, which may result from the use of the PNG +Reference Library, even if advised of the possibility of such damage. + +Permission is hereby granted to use, copy, modify, and distribute this +source code, or portions hereof, for any purpose, without fee, subject +to the following restrictions: + +1. The origin of this source code must not be misrepresented. + +2. Altered versions must be plainly marked as such and must not + be misrepresented as being the original source. + +3. This Copyright notice may not be removed or altered from any + source or altered source distribution. + +The Contributing Authors and Group 42, Inc. specifically permit, without +fee, and encourage the use of this source code as a component to +supporting the PNG file format in commercial products. If you use this +source code in a product, acknowledgment is not required but would be +appreciated. + + +A "png_get_copyright" function is available, for convenient use in "about" +boxes and the like: + + printf("%s",png_get_copyright(NULL)); + +Also, the PNG logo (in PNG format, of course) is supplied in the +files "pngbar.png" and "pngbar.jpg (88x31) and "pngnow.png" (98x31). + +Libpng is OSI Certified Open Source Software. OSI Certified Open Source is a +certification mark of the Open Source Initiative. + +Glenn Randers-Pehrson +glennrp at users.sourceforge.net +October 13, 2007 diff --git a/html/en/libtiff.txt b/html/en/libtiff.txt new file mode 100644 index 0000000..8282186 --- /dev/null +++ b/html/en/libtiff.txt @@ -0,0 +1,21 @@ +Copyright (c) 1988-1997 Sam Leffler +Copyright (c) 1991-1997 Silicon Graphics, Inc. + +Permission to use, copy, modify, distribute, and sell this software and +its documentation for any purpose is hereby granted without fee, provided +that (i) the above copyright notices and this permission notice appear in +all copies of the software and related documentation, and (ii) the names of +Sam Leffler and Silicon Graphics may not be used in any advertising or +publicity relating to the software without the specific, prior written +permission of Sam Leffler and Silicon Graphics. + +THE SOFTWARE IS PROVIDED "AS-IS" AND WITHOUT WARRANTY OF ANY KIND, +EXPRESS, IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY +WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +IN NO EVENT SHALL SAM LEFFLER OR SILICON GRAPHICS BE LIABLE FOR +ANY SPECIAL, INCIDENTAL, INDIRECT OR CONSEQUENTIAL DAMAGES OF ANY KIND, +OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER OR NOT ADVISED OF THE POSSIBILITY OF DAMAGE, AND ON ANY THEORY OF +LIABILITY, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE +OF THIS SOFTWARE. diff --git a/html/en/paking.gif b/html/en/paking.gif new file mode 100644 index 0000000..a3893b0 Binary files /dev/null and b/html/en/paking.gif differ diff --git a/html/en/proc_guide.html b/html/en/proc_guide.html new file mode 100644 index 0000000..5226702 --- /dev/null +++ b/html/en/proc_guide.html @@ -0,0 +1,144 @@ + + + + + + +Processing Guide + + + + + +

Image Processing Guide

+

Using

+ +

You should include one or more headers: <im_process_ana.h>, + <im_process_glo.h>, <im_process_loc.h> and <im_process_pon.h>. And you must + link with the "im_process.a/im_process.lib" library.

+

The processing operations are very simple to use. Usually you just have to + call the respective function. But you will have to ensure yourself that the + image parameters for the input and output data are correct. Here is an + example:

+ +
void imProcessFlip(const imImage* src_image, imImage* dst_image);
+ +

The processing operations are exclusive for the imImage structure. + This makes the implementation cleaner and much easier to process color images + since the planes are separated. But remmber that you can always use the + imImageInit function to initializes an imImage structure with + your own buffer.

+

The image data of the output image is assumed to be zero before any +operation. This is always true after creating a new image, but if you are +reusing an image for several operation use imImageClear to zero +the image data between operations. 

+ +

New Operations

+ +

An operation complexity is directly affected by the number of data types it + will operate.

+

If it is only one, than it is as simple as:

+ +
void DoProc(imbyte* data, int width, int height)
+{
+  for (int y = 0; y < height; y++)
+  {
+    for (int x = 0; x < width; x++)
+    {
+      // Do something
+      int offset = y * width + x;
+
+      data[offset] = 0;
+    }
+  }
+}
+
+void SampleProc(imImage* image)
+{
+  // a loop for all the color planes
+  for (int d = 0; d < image->depth; d++)
+  {
+    // Notice that the same operation may be used to process each color component
+    DoProc((imbyte*)image->data[d], image->width, image->height);
+  }
+}
+ +

Or if you want to use templates to allow a more number of types:

+ +
template <class T> 
+void DoProc2(const T* src_data, T* dst_data, int count)
+{
+  for (int i = 0; i < count; i++)
+  {
+    src_data[i] = dst_data[i];
+    
+    // or a more low level approach
+    
+    *src_data++ = *dst_data++;
+  }
+}
+
+// This is a sample that do not depends on the spatial distribution of the data.
+// It uses data[0], the pointer where all depths depends on.
+
+void SampleProc2(const imImage* src_image, imImage* dst_image)
+{
+  int total_count = src_image->count * src_image->depth; 
+  switch(src_image->data_type)
+  {
+  case IM_BYTE:
+    DoProc((imbyte*)src_image->data[0], (imbyte*)dst_image->data[0], total_count);
+    break; 
+  case IM_USHORT:
+    DoProc((imushort*)src_image->data[0], (imushort*)dst_image->data[0], total_count);
+    break; 
+  case IM_INT: 
+    DoProc((int*)src_image->data[0], (int*)dst_image->data[0], total_count);
+    break; 
+  case IM_FLOAT: 
+    DoProc((float*)src_image->data[0], (float*)dst_image->data[0], total_count);
+    break; 
+  case IM_CFLOAT: 
+    DoProc((imcfloat*)src_image->data[0], (imcfloat*)dst_image->data[0], total_count);
+    break;
+  }
+}
+ +

The first sample can be implemented in C, but the second sample can not, it + must be in C++. Check the manual and the source code for many operations + already available.

+ +

Counters

+ +

To add support for the counter callback to a new operation is very simple. + The following code shows how:

+ +
int counter = imCounterBegin("Process Test 1");
+imCounterTotal(counter, count_steps, "Processing");
+
+for (int i = 0; i < count_steps; i++)
+{
+  // Do something
+
+
+  if (!imCounterInc(counter))
+    return IM_ERR_COUNTER;
+}
+
+imCounterEnd(counter);
+ +

Every time you call imCounterTotal between a imCounterBegin/imCounterEnd for the same counter means + that you are starting a count at that counter. So one operation can be + composed by many sub-operations and still have a counter to display progress. + For example, each call to the imFileReadImageData starts a new + count for the same counter.

+

A nice thing to do when counting is not to display too small progress. To + accomplish that in the implementation of the counter callback consider a + minimum delay from one display to another.

+

See + Utilities / Counter.

+ + + + + diff --git a/html/en/proc_samples.html b/html/en/proc_samples.html new file mode 100644 index 0000000..e51ff37 --- /dev/null +++ b/html/en/proc_samples.html @@ -0,0 +1,142 @@ + + + + + + +Processing Samples + + + + + +

Image Processing Samples

+

Fourier Transform

+ +

This is another command line application that process an image in the + Fourier Frequency Domain. In this domain the image is a map of the spatial + frequencies of the original image. It depends on the IM main library and on + the IM_FFTW library. The FFTW is a very fast Fourier transform, but is + contaminated by the GPL license, so everything must be also GPL. To use it in + a commercial application you must contact the MIT and pay for a commercial + license.

+

Se also + + Reference / Image Processing / Domain Transform Operations.

+

You can view the source code here: + proc_fourier.cpp

+ +

Hough Lines

+ +

The Hough transform can be used to detect lines in an image. But it results + are highly dependent on other operations done before and after the transform. + Here you can see a small pseudo code that ilustrates a possible sequence of + operations to detect lines using the hough transform.

+

First the canny operator will isolate the borders, the threshold will mark + the candidate pixels. After the transform the local maximum are isolated to + detect the line parameters of the lines that have many pixels from the + cadidate ones. The last operation will just draw the detected lines over the + original gray scale image.

+ +
imProcessCanny(in,out,stddev)
+imProcessHysteresisThreshold(in,out,low,high)
+
+imProcessHoughLines(in,out)
+imProcessLocalMaxThreshold(in,out,size,min)
+
+imProcessHoughLinesDraw(in1,in2,out)
+ +

Or a more complete sequence using another approach:

+ +
gray = imImageCreate(width, height, IM_GRAY, IM_BYTE);
+binary = imImageCreate(width, height, IM_BINARY, IM_BYTE);
+binary2 = imImageClone(binary);
+
+rhomax = sqrt(width*width +height*height)/2;
+hough_height=2*rhomax+1;
+hough = imImageCreate(180, hough_height, IM_GRAY, IM_INT);
+hough_binary = imImageCreate(180, hough_height, IM_BINARY, IM_BYTE);
+
+imConvertColorSpace(rgb, gray);
+
+// very important step, the quality of the detected lines are highly dependent on
+// the quality of the binary image
+// Using a simple threshold like in here maybe not a good solution for your image
+imProcessPercentThreshold(gray, binary, percent=50); 
+
+// eliminates unwanted objects, depending on the quality of the threshold
+// this step can be skiped
+imProcessBinMorphClose(binary, binary2, 3, 1); 
+imProcessPrune(binary2, binary, 4, size=100, 0);
+
+// Is there any holes in the objects?
+// Holes also have borders...
+imProcessFillHoles(binary, binary2, 4);
+
+// leave only the object borders
+imProcessPerimeterLine(binary2, binary);  
+
+// here you should have near only the lines you want to detect.
+// if there are more or less lines that you want redo the previous steps
+
+imProcessHoughLines(binary, hough);
+imProcessLocalMaxThreshold(hough, hough_binary, 7, 100);
+
+// this is optional, it will draw the results
+imProcessHoughLinesDraw(gray,hough_binary,draw_hough); 
+ +

In the result of imProcessLocalMaxThreshold there will be several white + pixels. They represent the detected lines. Defining:

+ +
Y = a * X + b
+cos(theta) * X + sin(theta) * Y = rho
+
+where:
+  X = x - width/2
+  Y = y - height/2
+
+because the origin of the transform is in the center of the image
+ +

Each coordinate in the transform has values in the intervals:

+ +
theta = 0 .. 179  (horizontal coordinate of the hough space)
+rho = -rhomax .. rhomax    (vertical coordinate of the hough space, 
+                            vertically centered in the image)
+
+where:
+    rhomax = sqrt(width*width + height*height) /2            (width and height of the original image)
+ +

For each (xi, yi) point found in the result image:

+ +
theta = xi;
+rho = yi - rhomax;
+
+then:
+
+a = -cos(theta)/sin(theta);
+b = (rho + (width/2)*cos(theta) + (height/2)*sin(theta))/sin(theta);
+ +

The complex formula for "b" came from the fact that we have to shift the + result to the image origin at (0,0).

+ +

Image Analysis

+ +

The following pseudo code ilustrates the sequence of operations to measure + regions. This is also called Blob Analysis.

+

First the regions are isolated from background using a threshold. Then + regions too small or too large are eliminated and the holes are filled in this + example. After the regions are found we can start measuring properties of the + regions like area and perimeter.

+ +
imProcessSliceThreshold(in, out, level1, level2)
+imProcessPrune(in, out, connect, size1, size2)
+imProcessFillHoles(in, out, connect)
+imAnalyzeFindRegions(in, out, connect)
+imAnalyzeMeasureArea(in, area)
+imAnalyzeMeasurePerimeter(in, perim)
+ + + + + + \ No newline at end of file diff --git a/html/en/processing.html b/html/en/processing.html new file mode 100644 index 0000000..cbfc7b5 --- /dev/null +++ b/html/en/processing.html @@ -0,0 +1,35 @@ + + + + + +Processing + + + + + +

Image Processing Overview

+ +

We use the simpliest model possible, a function with input data, output + data and control parameters.

+

The operations have usually one or more input images, and one or more + output images.  We avoid implementing in-place operations, but many + operations can use the same data for input and output. The data type, color + mode and size of the images depends on the operation. Sometimes the operations + can change the data type to increase the precision of the results, but + normally only a few operations will change the size (resize and geometric) and + color mode (color conversion). All of these details are described in each + function documentation, check before using them.

+

There is no ROI (Region Of Interest) management, but you can + imProcessCrop, imProcess*, + then imProcessInsert the result in the original image.

+

The image data of the output image is assumed to be zero before any +operation. This is always true after creating a new image, but if you are +reusing an image for several operation use imImageClear to zero +the image data between operations.

+ + + + + diff --git a/html/en/prod.html b/html/en/prod.html new file mode 100644 index 0000000..ee385dc --- /dev/null +++ b/html/en/prod.html @@ -0,0 +1,132 @@ + + + + +IM + + + + + + + + +

Overview

+ +

IM is a toolkit for Digital Imaging. IM is based on 4 concepts: Image Representation, Storage, Processing and + Capture. Image Visualization is a task that it is left for a graphics library.

+

It provides support for image capture, several image file formats and many image processing operations. The most + popular file formats are supported: TIFF, BMP, PNG, JPEG, GIF and AVI.

+

Image representation includes scientific data types (like IEEE floating point data) and attributes (or metadata + like GeoTIFF and Exif tags). Animation, video and volumes are supported as image sequences, but there is no digital + audio support.

+

The main goal of the library is to provide a simple API and abstraction of images for scientific applications.

+

The toolkit API is written in C. The core library source code is implemented in C++ and it is very portable, it can + be compiled in Windows and UNIX with no modifications. New image processing operations can be implemented in C or in + C++.

+

IM is free software, can be used for public and commercial applications.

+

IM has been used in Tecgraf for many theses and dissertations. Check the Publications in Tecgraf's web site + http://www.tecgraf.puc-rio.br/.

+ +

Availability

+ +

The library is available for several compilers:

+ +

The library is available for several operating systems:

+ + +

Support

+ +

The official support mechanism is by e-mail, using + im@tecgraf.puc-rio.br. + Before sending your message:

+ +

After all of the above have been checked, report the problem, including in your message: function, element, + format, platform, and compiler.

+

We host IM support features at LuaForge. It provides us + Lists, News, CVS and Files. The IM page at LuaForge is available at: + http://luaforge.net/projects/imtoolkit/.

+ +

The discussion list is available at: + + http://lists.luaforge.net/mailman/listinfo/imtoolkit-users.
+ Source code, pre-compiled binaries and samples can be downloaded at: + http://luaforge.net/frs/?group_id=86.
+ The CVS can be browsed at: http://luaforge.net/scm/?group_id=86.

+ +

If you want us to develop a specific feature for the toolkit, Tecgraf is available for partnerships and + cooperation. Please contact tcg@tecgraf.puc-rio.br.

+

Lua documentation and resources can be found at http://www.lua.org/.

+ +

Credits

+ +

This work was developed at Tecgraf by means of the partnership with PETROBRAS/CENPES.

+

Library Author:

+ +

Thanks to the people that worked and contributed to the library:

+ +

We also thank the developers of the third party libraries:

+ +

The IM toolkit distribution includes the some third party libraries that are not developed by Tecgraf. Their + license are also free and have the same freedom as the Tecgraf Library + License. You can read the respective licenses in the files: zlib.txt, + libpng.txt, libjpeg.txt, libtiff.txt, + libjasper.txt, liblzf.txt.

+

IM is registered at the National Institute of Intellectual Property in Brazil +(INPI) under the number 07570-6, and so it is protected against illegal use. See +the Tecgraf Library License for further usage +information and Copyright.

+ +

Documentation

+ +

This toolkit is available at http://www.tecgraf.puc-rio.br/im

+

The full documentation can be downloaded from the Download Files. The documentation is also available in Adobe Acrobat and Windows HTML Help formats.

+

The HTML navigation uses the WebBook tool, available at + http://www.tecgraf.puc-rio.br/webbook.

+

The library Reference documentation is generated by Doxygen ( + http://www.stack.nl/~dimitri/doxygen/ ).

+ +

Publications

+ + + + + diff --git a/html/en/rep_guide.html b/html/en/rep_guide.html new file mode 100644 index 0000000..0dfd939 --- /dev/null +++ b/html/en/rep_guide.html @@ -0,0 +1,139 @@ + + + + + + +Representation Guide + + + + + +

Image Representation Guide

+

Raw Data Buffer

+ +

To create a raw image buffer you can simply use the utility function:

+ +
+
int width, height, color_mode, data_type;
+int size = imImageDataSize(width, height, color_mode, data_type);
+void* buffer = malloc(size);
+
+ +
+

So if the data type is IM_FLOAT, we could write:

+
+ +
float* idata = (float*)buffer;
+ +
+
+

Then to locate the pixel at line y, column x, component d simply write: +

+
+ +
float value;
+if (is_packed) 
+value = idata[y*width*depth + x*depth + d]
+else
+value = idata[d*width*height + y*width + x]
+ +
+
+

But notice that this code will return values at different pixel locations for top down and bottom up + orientations.

+ +
+

imImage

+
+ +
+

To use the imImage structure you must include the <im_image.h> header.

+
+

To create an imImage structure you can do it in several ways:

+ +
+ + +
int width, height, color_space, data_type, palette_count;
+long *palette;
+void* buffer
+
+imImage* image;
+
+image = imImageCreate(width, height, color_space, data_type) 
+image = imImageInit(width, height, color_space, data_type, buffer, palette, palette_count) 
+image = imImageDuplicate(image) 
+image = imImageClone(image) 
+ +

The imImageInit function allow you to initialize an imImage structure with an user allocated + buffer. This is very useful if you use your own image structure and wants to temporally use the image processing + functions of the library.

+

To destroy the imImage structure simply call imImageDestroy(image). If you do "data[0] + = NULL" before calling the destroy function then the raw data buffer will not be destroyed.

+ +
+ +
+

The imImage data buffer is allocated like the raw data buffer. +

+
+

The separated color components are arranged one after another, but we access the data through an + array of pointers each one starting at the beginning of each color component. So + image->data[0] + contains a pointer to all the data, and image->data[1] is a short cut to the second component and so + on. With this you can use image->data[0] as a starting point for all the data, or use it as the first + component.

+ +
+ + +
count = width*height;
+unsigned char* idata = (unsigned char*)image->data[0];
+for (int i = 0; i < count; i++)
+{
+  idata[i] = 255;
+}
+ +

or

+ +
for (int d = 0; d < image->depth; d++)
+{
+  unsigned char* idata = (unsigned char*)image->data[d];
+
+  for (int y = 0; y < height; y++)
+  {
+    for (int x = 0; x < width; x++)
+    {
+      int offset = y * width + x; 
+
+      idata[offset] = 255;
+    }
+  }
+}
+ + +
+
+ +

The imImage structure contains all the image information obtained from a file, because it + also has support for alpha, attributes and the palette. The palette can be used for + IM_MAP images and + for pseudo color of IM_GRAY images.

+ +
+ +
+

An important subset of images is what we call a Bitmap image. It is an image that can be + directly used into the graphics display. For Bitmap images the color space must be + IM_RGB, IM_MAP, + IM_GRAY or IM_BINARY, and the data type must be IM_BYTE.

+
+

The conversion between image data types, color spaces and the conversion to bitmap are defined only + for the imImage structure.

+ + + + + diff --git a/html/en/rep_samples.html b/html/en/rep_samples.html new file mode 100644 index 0000000..5c729a8 --- /dev/null +++ b/html/en/rep_samples.html @@ -0,0 +1,71 @@ + + + + + + +Representation Samples + + + + + +

Image Representation Samples

+

See the Representation Guide for simple image +representation +samples.

+

Information

+ +

This is a command line application that displays information obtained from + a file using the IM I/O functions, basically imFile functions. It + depends only on the IM main library.

+

Here is an output sample:

+ +
IM Info
+  File Name:
+    exif_test.tif
+  File Size: 9.00 Mb
+  Format: TIFF - Tagged Image File Format
+  Compression: NONE
+  Image Count: 1
+  Image #0
+    Width: 2048
+    Height: 1536
+    Color Space: RGB
+      Has Alpha: No
+      Is Packed: Yes
+      Is Top Down: Yes
+    Data Type: byte
+    Data Size: 9.00 Mb
+    Attributes:
+      YResolution: 72.00
+      XResolution: 72.00
+      DateTime: 2004:01:14 11:30:11
+      Make: SONY
+      ResolutionUnit: DPI
+      Model: CD MAVICA
+      Photometric: 2
+ +

You can view the source code here: + im_info.cpp

+ +

View Using IUP and CD

+ +

This application uses IUP and CD to create a window with a canvas and draw + the image into that canvas. It is a very simple application, no zoom nor + scrollbar management. The image is obtained from a file using the IM I/O + functions, but using the imImage structure to make the implementation + easier.

+

For more about IUP see + + http://www.tecgraf.puc-rio.br/iup and more about CD see + + http://www.tecgraf.puc-rio.br/cd.

+

You can view the source code here: + im_view.c, or download it with some makefiles + im_view.zip.

+ + + + + diff --git a/html/en/representation.html b/html/en/representation.html new file mode 100644 index 0000000..1ae5394 --- /dev/null +++ b/html/en/representation.html @@ -0,0 +1,138 @@ + + + + + +Representation + + + + + +

Image Representation Overview

+

Width and Height

+ +

In the IM library images are 2D matrices of pixels defining width and height. Stacks, Animations, + Videos and Volumes are represented as a sequence of individual images.

+ +

Color Space

+ +

The pixels can have one of several color spaces:

+ +

IM_MAP is a subset of the IM_RGB color space. It can have a maximum of 256 colors. Each + value is an index into a RGB palette.

+

IM_GRAY usually means luma (nonlinear Luminance), but it can represent any other intensity value that + is not necessarily related to color.

+

IM_BINARY is a subset of the IM_GRAY color space, and it has only 2 colors black and + white. Each value can be 0 or 1. But for pratical reasons we use one byte to store it.

+

The other color spaces are standard CIE color spaces, except CMYK that does not have a clear definition without + other parameters to complement it.

+ +

Data Type

+ +

There are several numeric representations for the color component, or several data types:

+ +

There is no bit type, binary images use 1 byte (waist space but keep processing simple).

+ +

Color Mode Flags

+ +

To avoid defining another image parameter we also use a parameter called color_mode that it is composed by + the color_space plus some flags, i.e. color_mode = color_space + flags. The flags are binary + combined with the color space, for example color_mode = IM_RGB | IM_XXX. And several flags can be combined in the same + color_mode.

+

There are 3 flags:

+ +

When a flag is absent the opposite definition is assumed. For simplicity we define some macros that help handling + the color mode:

+ +

Color Components Packaging (IM_PACKED or unpacked)

+ +

The number of components of the color space defines the depth of the image. The color components can be packed + sequentially in one plane (like rgbrgbrgb...) or separated in several planes (like rrr...ggg...bbb...). Packed color + components are normally used by graphics systems. We allow these two options because many users define their own + image structure that can have a packed or an separated organization. The following picture illustrates the + difference between the two options:

+ +


+ (flag not defined)                 + IM_PACKED

+

Separated and Packed RGB Components

+

Alpha Channel (IM_ALPHA or no alpha)

+ +

An extra component, the alpha channel, may be present. The number of components is then increased by one. + Its organization follows the rules of packed and unpacked components.

+ +

Orientation (IM_TOPDOWN or bottom up)

+ +

Image orientation can be bottom up to top with the origin at the bottom left corner, or top down to bottom with + the origin at the top left corner.

+ +

+

IM_TOPDOWN               + (flag not defined)

+

Top Down and Bottom Up Orientations

+

Examples

+ +

IM_RGB | IM_ALPHA - rgb color space with an alpha channel, bottom up orientation and + separated components
+ IM_GRAY | IM_TOPDOWN - gray color space with no alpha channel and top down orientation
+ IM_RGB | IM_ALPHA | IM_PACKED - rgb color space with an alpha channel, bottom + up orientation and packed components

+ + +

Raw Data Buffer

+ +

So these four parameters define our raw image data: width, height, color_mode and data_type. + The raw data buffer is always byte aligned and each component is stored sequentially in the buffer following the + specified packing.

+

For example, if a RGB image is 4x4 pixels it will have the following organization in memory:

+ +
RRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGBBBBBBBBBBBBBBBB - for non packed components
+0   1   2   3   0   1   2   3   0   1   2   3
+
RGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGBRGB - for packed components
+0           1           2           3
+ +

In bold we visualy marked some lines of data.

+ +
+

imImage

+ +

We could restrict the data organization by eliminating the extra flags, but several users requested these features + in the library. So we keep them but restricted to raw data buffers.

+

For the high level image processing functions we created a structure called imImage that eliminates the + extra flags and assume bottom up orientation and separated components. Alpha channel is supported as an + extra component.

+

The imImage structure is defined using four image parameters: width, height, color_space + and data_type. It is an open structure in C where you can access all the parameters. In addition to the 4 + creation parameters there are many auxiliary parameters like depth, count, line_size, + plane_size and size.

+ + + + + diff --git a/html/en/samples.html b/html/en/samples.html new file mode 100644 index 0000000..b659a25 --- /dev/null +++ b/html/en/samples.html @@ -0,0 +1,163 @@ + + + + + + +Samples + + + + + +

Complete Samples

+

im_info

+ +

This is a command line application that displays information obtained from a file using the IM I/O functions, + basically imFile functions. It depends only on the IM main library.

+

Here is an output sample:

+ +
IM Info
+  File Name:
+    exif_test.tif
+  File Size: 9.00 Mb
+  Format: TIFF - Tagged Image File Format
+  Compression: NONE
+  Image Count: 1
+  Image #0
+    Width: 2048
+    Height: 1536
+    Color Space: RGB
+      Has Alpha: No
+      Is Packed: Yes
+      Is Top Down: Yes
+    Data Type: byte
+    Data Size: 9.00 Mb
+    Attributes:
+      YResolution: 72.00
+      XResolution: 72.00
+      DateTime: 2004:01:14 11:30:11
+      Make: SONY
+      ResolutionUnit: DPI
+      Model: CD MAVICA
+      Photometric: 2
+ +

You can view the source code here: im_info.cpp

+ +

im_copy

+ +

This is a command line application that copies all the information from one file to another using the IM I/O + functions. It depends only on the IM main library. It is usefull for testing the drivers.

+

You can view the source code here: im_copy.cpp

+ +

proc_fourier

+ +

This is another command line application that process an image in the Fourier Frequency Domain. In this domain the + image is a map of the spatial frequencies of the original image. It depends on the IM main library and on the IM_FFTW + library. The FFTW is a very fast Fourier transform, but is contaminated by the GPL license, so everything must be also + GPL. To use it in a commercial application you must contact the MIT and pay for a commercial license.

+

Se also Reference / Image Processing / Domain + Transform Operations.

+

You can view the source code here: proc_fourier.cpp

+ +

im_view

+ +

This application uses IUP and CD to create a window with a canvas and draw the image into that canvas. It is a very + simple application, no zoom nor scrollbar management. The image is obtained from a file using the IM I/O functions, + but using the imImage structure to make the implementation easier.

+

For more IUP http://www.tecgraf.puc-rio.br/iup and + more CD http://www.tecgraf.puc-rio.br/cd

+

You can view the source code here im_view.c, or download it with some makefiles + im_view.zip.

+ +

glut_capture

+ +

This application uses GLUT and OpenGL to create a window with a canvas and draw the image into that canvas. But the + image is obtained from a capture device. The image can be processed before display and a sequence of captured images + can be saved in an AVI file during capture.

+

You can view the source code here: glut_capture.c

+ +

iupglcap

+ +

This application uses IUP and OpenGL to create a window with two canvases and draw a video capture image into one + canvas. A processed image can be displayed in the second canvas. It can also process frames from a video file. It is + very usefull for Computer Vision courses..

+

You can download the source code and projects for Visual C++, Borland C++ Builder X and Dev-Cpp, here: + iupglcap.zip  You will need to download IUP, CD and IM libraries for the + compiler you use

+ +

IMLAB

+ +

If you want to see a more complex application with all the IM features explored the IMLAB is a complete example. It + displays each image in an individual image with zoom and pan capabilities. All the IM processing operations are + available together with some extra operations.

+

For more IMLAB go to + http://www.tecgraf.puc-rio.br/~scuri/imlab.

+ +

Lua Samples

+ +

To retreive information from an image file:

+ +
require"imlua"
+local ifile, error = im.FileOpen(file_name)
+local format, compression, image_count = ifile:GetInfo()
+local format_desc = im.FormatInfo(format)
+for i = 1, image_count do
+   local width, height, color_mode, data_type, error = ifile:ReadImageInfo(i)
+end
+ifile:Close()    
+ +

To edit pixels in an image and save the changes:

+ +
require"imlua"
+
+local image = im.FileImageLoad(filename)
+
+local r = image[0]
+local g = image[1]
+local b = image[2]
+
+for row = 0, image:Height() - 1, 10 do
+	for column = 0, image:Width() - 1, 10 do
+		r[row][column] = 0
+		g[row][column] = 0
+		b[row][column] = 0
+	end
+end
+
+image:Save("edit.bmp", "BMP")
+ +

To render noise:

+ +
require"imlua"
+require"imlua_process"
+local image = im.ImageCreate(500, 500, im.RGB, im.BYTE)
+im.ProcessRenderRandomNoise(image) 
+image:Save("noise.tif", "TIFF") 
+ +

To render using the CD library:

+ +
require"imlua"
+require"cdlua"
+require"imlua_cd"
+
+local image = im.ImageCreate(500, 500, im.RGB, im.BYTE)
+local canvas = image:cdCreateCanvas()  -- Creates a CD_IMAGERGB canvas
+
+canvas:Activate()  
+canvas:Clear()
+canvas:Font("Times", cd.BOLD, 24)
+canvas:Text(100, 100, "Test")
+canvas:Line(0,0,100,100)
+canvas:KillCanvas(canvas)
+
+image:Save("new.bmp", "BMP")  
+ +

Check the file samples_imlua5.tar.gz + or samples_imlua5.zip for several samples in Lua. For + some of them you will need also the CD and the IUP libraries.

+ + + + + diff --git a/html/en/storage.html b/html/en/storage.html new file mode 100644 index 0000000..138d539 --- /dev/null +++ b/html/en/storage.html @@ -0,0 +1,72 @@ + + + + + +Storage + + + + + +

Storage Overview

+ +

Essentially all the file formats save the same image data. There is no such + thing like a GIF image, instead we have a color indexed image that can be + saved in a file with a GIF format, or a TIFF format, etc. However the + compression encoding can be lossy and degrade the original image. The point is + file formats and image data are two different things.

+

A file format is a file organization of the image data and its attributes. + The IM library model considers all the file formats under the same model, + including image, video, animation, stacks and volume file formats. When there + is more than one image each one is treated as an independent frame. Each frame + can have its own parameters and set of attributes.

+

The abstract model we use has the following structure:

+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + +
Format Identifier
Compression
Image Count
+ Image Information:
+ parameters, attributes, palette
Image Data
Image Information:
+ parameters, attributes, palette
Image Data
...
+
+
+

The compression is usually the same for all the images in the file, but it + can be changed after loading an image. For tradicional file formats image + count is always 1. Image information must always be loaded or saved before + image data.

+

We consider only formats that starts with a signature so we can recognize + the format without using its file extension. If there is more than one driver + that handles the same signature the first registered driver will open the + file. Since the internal drivers are automatically registered all the external + drivers can be loaded first if no imFile function has been called. In + this way you can also control which external driver goes first.

+ + + + + diff --git a/html/en/storage_guide.html b/html/en/storage_guide.html new file mode 100644 index 0000000..e225ae5 --- /dev/null +++ b/html/en/storage_guide.html @@ -0,0 +1,311 @@ + + + + + + +Storage Guide + + + + + +

Storage Guide

+

Reading

+ +

When reading the file extension is not relevant to determine the file + format, but it is used to speed up the process of finding the correct format. + With few exceptions the format drivers that access multiple images can read + them in any sequence you want.

+

During the read process the original data can be converted to some options + of user data. Not all conversions are available. You can convert any data to a + bitmap version of it, and you can select any of the color mode flags + IM_ALPHA, IM_PACKED and IM_TOPDOWN, + regardless of the file original configuration.

+

Remember that even if all the images in the file have the same parameters + you still have to call imFileReadImageInfo before calling imFileReadImageData.

+

In the following example all the images in the file are loaded.

+ +
char format[10], compression[10];
+int error, image_count;
+int width, height, color_mode, data_type;
+void* data;
+
+imFile* ifile = imFileOpen("test.tif", &error);
+if (error != IM_ERR_NONE) 
+  // handle the error
+
+imFileGetInfo(ifile, format, compression, &image_count);
+
+for (i = 0; i < image_count, i++)
+{
+  error = imFileReadImageInfo(ifile, i, &width, &height, &color_mode, &data_type);
+  if (error != IM_ERR_NONE) 
+    // handle the error
+
+  // prepare data
+
+  error = imFileReadImageData(ifile, data, 0, -1); // no bitmap convertion, use original color mode flags
+  if (error != IM_ERR_NONE) 
+    // handle the error
+
+  // store data somewhere
+}
+
+imFileClose(ifile); 
+ +

A more simple code loads only the first image in the file:

+ +
imFile* ifile = imFileOpen(file_name, &error);
+
+imFileReadImageInfo(ifile, 0, &width, &height, &color_mode, &data_type);
+
+imFileReadImageData(ifile, data, 0, -1);
+
+imFileClose(ifile); 
+ +

If you are using the imImage structure it is easier:

+ +
imFile* ifile = imFileOpen(file_name, &error);
+ 
+imImage* image = imFileLoadImage(ifile, 0, &error);
+
// or use imFileLoadBitmap to force a bitmap conversion
+
+imFileClose(ifile);
+ +

Or the simplest version:

+ +
imImage* image = imFileImageLoad(file_name, 0, &error);
+ + +

Writing

+ +

When writing there is no color space or data type conversion. Only color + mode flags can be different: IM_ALPHA, IM_PACKED and + IM_TOPDOWN. You just have to describe your data and the imFileWriteImageData will handle the color mode flag differences.

+

Of course you still have to check the error codes because, not all color + spaces and data types are supported by each format.

+

When saving a sequence of images you must provide each image in the order + that they will be in the file. For a video or animation start from frame 0 and + go on, you can not jump or change the frame order. Also when saving videos you + should not forget to save the numbers of frames per second in the attribute + "FPS", the default value is 15.

+

For all the formats it is not necessary to set the compression, each driver + will choose a default compression. But you may set it using the function imFileSetInfo.

+

To save several images to the same file:

+ +
int error, width, height;
+void *data;
+
+imFile* ifile = imFileNew("test.tif", "TIFF", &error);
+if (error != IM_ERR_NONE) 
+  // handle the error
+
+for (i = 0; i < image_count, i++)
+{
+  error = imFileWriteImageInfo(ifile, width, height, IM_RGB, IM_BYTE);
+  if (error != IM_ERR_NONE) 
+    // handle the error
+
+  error = imFileWriteImageData(ifile, data);
+  if (error != IM_ERR_NONE) 
+    // handle the error
+}
+
+imFileClose(ifile); 
+ +

But remember that not all file formats supports several images. To save + just one image is more simple:

+ +
imFile* ifile = imFileNew(file_name, format, &error);
+
+error = imFileWriteImageInfo(ifile, width, height, color_mode, data_type);
+
+error = imFileWriteImageData(ifile, data);
+
+imFileClose(ifile); 
+ +

If you are using the imImage structure it is easier:

+ +
imFile* ifile = imFileNew(file_name, format, &error);
+
+error = imFileSaveImage(ifile, image);
+
+imFileClose(ifile);
+ +

Or the simplest version:

+ +
error = imFileImageSave(file_name, format, image);
+ + +

Error Messages

+ +

Here is a sample error message display using IUP and IM error codes:

+ +
static void imIupErrorMessage(int error, int interactive)
+{
+  char* lang = IupGetLanguage();
+  char *msg, *title;
+  if (strcmp(lang, "ENGLISH")==0)
+  {
+    title = "Error";
+    switch (error)
+    {
+    case IM_ERR_OPEN:
+      msg = "Error Opening File.";
+      break;
+    case IM_ERR_MEM:
+      msg = "Insuficient memory.";
+      break;
+    case IM_ERR_ACCESS:
+      msg = "Error Accessing File.";
+      break;
+    case IM_ERR_DATA:
+      msg = "Image type not Suported.";
+      break;
+    case IM_ERR_FORMAT:
+      msg = "Invalid Format.";
+      break;
+    case IM_ERR_COMPRESS:
+      msg = "Invalid or unsupported compression.";
+      break;
+    default:
+      msg = "Unknown Error.";
+    }
+  }
+  else
+  {
+    title = "Erro";
+    switch (error)
+    {
+    case IM_ERR_OPEN:
+      msg = "Erro Abrindo Arquivo.";
+      break;
+    case IM_ERR_MEM:
+      msg = "Memória Insuficiente.";
+      break;
+    case IM_ERR_ACCESS:
+      msg = "Erro Acessando Arquivo.";
+      break;
+    case IM_ERR_DATA:
+      msg = "Tipo de Imagem não Suportado.";
+      break;
+    case IM_ERR_FORMAT:
+      msg = "Formato Inválido.";
+      break;
+    case IM_ERR_COMPRESS:
+      msg = "Compressão Inválida ou não Suportada.";
+      break;
+    default:
+      msg = "Erro Desconhecido.";
+    }
+  }
+
+  if (interactive)
+    IupMessage(title, msg);
+  else
+    printf("%s: %s", title, msg);
+}
+
+ + +

About File Formats

+ +

TIFF is still the most complete format available. It could be better if + Adobe releases the revision 7, but it is on stand by. TIFF supports all the IM + image representation concepts. In fact we were partially inspired by the TIFF + specification. My suggestion is whenever possible use TIFF.

+

But TIFF may not be the ideal format for many situations. The W3C standards + include only JPEG, GIF and PNG for Web browsers. JPEG forces the image to be + RGB or Gray with a lossy compressed. GIF forces the image to be MAP with LZW + compression. PNG forces the image to be RGB, MAP, Gray or Binary, with Deflate + compression. So these characteristics are necessary to force small values for + faster downloads.

+

JPEG is to be used for photographic content, PNG should be used for the + remaining cases, but GIF is still the best to do simple animated images.

+

Except for some specific cases where a format is needed for compatibility, + the other formats are less important. TGA, PCX, RAS, SGI and BMP have almost + the same utility.

+

JP2 must be used for JPEG-2000 compression, would be nice if a new TIFF + specification includes this standard.

+

Since PNM has a textual header it is very simple to teach for students so + they can actually "see" the header. It is also a format easy to share images, + but it does not do much more than that.

+

The TIFF and the GIF format also have support for multiple images. This + does not necessarily defines an animation, pyramid nor a volume, but some + times they are used in these ways.

+

GIF became very popular to build animations for the Web, and since the LZW + patent expired Unisys realized that charging the usage isn't going to work and + so they did not renew it. LZW is fully supported at IM.

+

IM also supports video formats like AVI and WMV as external libraries. In + these cases the frames are also loaded as a sequence of individual images. + Sound is not supported.

+

TIFF, JPEG and PNG have an extensive list of attributes, most of them are + listed in the documentation, but some custom attributes may come up when + reading an image from file.

+ +

New File Formats

+ +

Again the easiest way is to look at the source code of an already + implemented format. The RAS, BMP, TGA and SGI formats are very simple to + follow.

+

Basically you have to implement a class that inherits from imFormat + and implement its virtual methods. You can use the imBinFile functions + for I/O or use an external SDK.

+

For more information see + File + Format SDK.

+ +

Memory I/O and Others

+ +

For the majority of the formats, with the exception of the ones that use + external SDKs, the I/O is done by the imBinFile module.

+

This module can be configured to access other types of media by + implementing a driver. There are some predefined drivers see + Reference + / Utilities / Binary File Access.

+

One very useful is the Memory Buffer where you can read and write a + file in memory. The activation is very simple, it needs to happen just before + the imFileOpen/imFileNew functions. But the file name must be a + pointer to an imBinMemoryFileName structure instead of a string. + Se the example bellow:

+ +
int old_mode = imBinFileSetCurrentModule(IM_MEMFILE);
+
+imBinMemoryFileName MemFileName; // This structure must exists 
+    while the file remains open.
+ MemFileName.buffer = NULL; // Let the library initializes the buffer,
+                           + // but it must be freed the the application, free(MemFileName.buffer) + MemFileName.size = 1024; // The initial size
+ MemFileName.reallocate = 1.5; // The reallocation will increase 50% the + buffer.
+                              + // This is used only when writing with a variable buffer.
+                              + // Use 0 to fix the buffer size. + +int error;
+ imFile* ifile = imFileNew((const char*)&MemFileName, "GIF", &error); + +imBinFileSetCurrentModule(old_mode); // The mode needs to be active + only for the imFileOpen/imFileNew call. + +if (error != IM_ERR_NONE) ....
+ +

Another driver interesting is the Subfile where you can read and + write from a file that is already open. This is very important for formats + that can have an embedded format inside. In this module the file_name + is a pointer to an imBinFile  + structure from any other module that uses the imBinFile functions. The + imBinFileSize will return the full file size, but the imBinFileSeekTo and + imBinFileTell functions will + compensate the position when the subfile was open.

+

Using imBinFileSetCurrentModule(IM_SUBFILE) just like the example above will + allow you to open a subfile using the imFileOpen/imFileNew + functions.

+ + + + + diff --git a/html/en/storage_samples.html b/html/en/storage_samples.html new file mode 100644 index 0000000..d4f5c41 --- /dev/null +++ b/html/en/storage_samples.html @@ -0,0 +1,79 @@ + + + + + + +Storage Samples + + + + + +

More Storage Samples

+

See the Storage Guide for simple storage +samples.

+

Information

+ +

This is a command line application that displays information obtained from + a file using the IM I/O functions, basically imFile functions. It + depends only on the IM main library.

+

Here is an output sample:

+ +
IM Info
+  File Name:
+    exif_test.tif
+  File Size: 9.00 Mb
+  Format: TIFF - Tagged Image File Format
+  Compression: NONE
+  Image Count: 1
+  Image #0
+    Width: 2048
+    Height: 1536
+    Color Space: RGB
+      Has Alpha: No
+      Is Packed: Yes
+      Is Top Down: Yes
+    Data Type: byte
+    Data Size: 9.00 Mb
+    Attributes:
+      YResolution: 72.00
+      XResolution: 72.00
+      DateTime: 2004:01:14 11:30:11
+      Make: SONY
+      ResolutionUnit: DPI
+      Model: CD MAVICA
+      Photometric: 2
+ +

You can view the source code here: + im_info.cpp

+ +

Copy

+ +

This is a command line application that copies all the information from one + file to another using the IM I/O functions. It depends only on the IM main + library. It is usefull for testing the drivers.

+

You can view the source code here: + im_copy.cpp

+ + +

Load Bitmap from Resource File

+

In Windows if you have a bitmap stored in a resource file, like this:

+ +
bitmap_test BITMAP bitmap_test.bmp
+
+

The you could retreive it using the following code:

+
#include <windows.h>
+#include <im.h>
+#include <im_dib.h>
+
+HBITMAP hBmp = LoadBitmap(hInstance, "bitmap_test");
+imDib* dib = imDibFromHBitmap(hBmp, NULL);
+imImage* image imDibToImage(dib);
+imDibDestroy(dib);
+
+ + + + + diff --git a/html/en/to_do.html b/html/en/to_do.html new file mode 100644 index 0000000..c9de95e --- /dev/null +++ b/html/en/to_do.html @@ -0,0 +1,60 @@ + + + + +To Do + + + + + + + + +

To Do

+

General

+ +

For the Processing library:

+ +

Our plans for the future include:

+ +
+

Suggestions? im@tecgraf.puc-rio.br

+

 

+ + + + \ No newline at end of file diff --git a/html/en/toolkits.html b/html/en/toolkits.html new file mode 100644 index 0000000..1f0c8f5 --- /dev/null +++ b/html/en/toolkits.html @@ -0,0 +1,244 @@ + + + + +Other Toolkits + + + + + + + +

Comparing IM with Other Imaging Toolkits

+ +

Still today there is a need for something easier to code and understand in + Imaging. The available free libraries are sometimes close, sometimes very far + from “easier”. IM is an unexplored solution and proposed as a simple and clean + one. It is another Imaging tool with a different approach to the many + possibilities in the area. Its organization was designed so it can be used for + teaching Imaging concepts. We invite you to try it.

+

First we list some libraries mainly target for storage, then some + scientific libraries, and then a small comparsion of IM and those libraries.

+
+

Here are some free storage libraries:

+

Imlib2

+ +

Last Update 2003-09 / Version 1.1.0
+ + http://www.enlightenment.org/pages/imlib2.html
+ Language C
+ Documentation is terrible. Depends on the X-Windows System libraries.
+ It is designed for display/rendering performance.

+ +

Corona

+ +

Last Update 2003-09 / Version 1.0.2
+ + http://corona.sourceforge.net/
+ Language C++
+ Very simple library. Only a few formats. Only bitmap images, no video.

+ +

PaintLib

+ +

Last Update 2004-04 / Version 2.61
+ + http://www.paintlib.de/paintlib/
+ Language C++
+ A very simple library.
+ Has an interesting ActiveX component. Only bitmap images, no video.

+ +

NetPBM

+ +

Last Update 2004-07 / Version 10.23
+ + http://netpbm.sourceforge.net/
+ Language C
+ A traditional library that starts at the Pbmplus package more than 10 years + ago.
+ Very stable, it has support for the PNM format family and many processing + operations.
+  Only bitmap images, no video.

+ +

DevIL ***

+ +

Last Update 2004-06 / Version 1.6.7
+ + http://openil.sourceforge.net/
+ Language C (Has also a C++ Wrapper)
+ Called initially OpenIL. Supports many formats and have a very interesting + API, that works very similar the OpenGL API (that's why the original name). + Also supports the display in several graphics systems. Has several data + types as OpenGL has.

+ +

FreeImage ***

+ +

Last Update 2004-07 / Version 3.4.0
+ + http://freeimage.sourceforge.net/
+ Language C (Has also a C++ Wrapper)
+ Supports many formats. Many data types, but only RGB and subclasses (gray, + map, etc).
+ Very well written, stable and simple to use.

+ +

ImageMagick and GraphicsMagick ***

+ +

Last Update 2004-07 / Version 6.0.3 || Last Update 2004-04 / Version + 1.0.6
+ + http://www.imagemagick.org/ || + + http://www.graphicsmagick.org/
+ Language C (Has also a C++ Wrapper)
+ The two libraries are listed together because GraphicsMagick is totally and + explicitly based on ImageMagick version 5.5.2.
+ They have very similar or identical APIs but the development process is + completely different. GraphicsMagick propose a more organized development + process (a more precise comparison requires detailed knowledge about the two + libraries).
+ These are very complete libraries. They support lots of file formats, + several color spaces, but use only the byte data type.
+ They use a big image structure with everything inside. Image creation may + involve about 40 parameters.

+ +
+

And here are some free scientific libraries:

+

TINA

+ +

Last Update 2002-03 / Version 4.0.2
+ http://www.niac.man.ac.uk/Tina +
+ Language C
+ Very UNIX oriented. Lots of functions for Computer Vision. Developed by a + researcher of the University of Manchester.

+ +

XITE

+ +

Last Update 2002-09 / Version 3.44
+ + http://www.ifi.uio.no/forskning/grupper/dsb/Software/Xite/
+ Language C
+ Very UNIX oriented, but compiles fine in Windows. Several separated command + line routines, it is a package not a library. But inspired several aspects + of the IM library. Seems to be not updated anymore. Developed by a + researcher of the University of Oslo.

+ +

VIGRA

+ +

Last Update 2004-09 / Version 1.3.0
+ + http://kogs-www.informatik.uni-hamburg.de/~koethe/vigra/ 
+ Language C++
+ STL based. Many operators. Developed by a researcher of the University of + Hamburg.

+ +

Wild Magic

+ +

Last Update 2004-09 / Version 2.4
+ http://www.magic-software.com/ +
+ Language C++
+ Game development oriented, very rich in mathematics. Developed by Magic + Software, Inc.

+ +

VIPS

+ +

Last Update 2004-09 / Version 7.10.2
+ http://www.vips.ecs.soton.ac.uk/
+ Language C/C++
+ Support for very large images. Powerful macro laguage. Good implementation. + Many functions. Developed by researchers at the University of Southampton + and The National Gallery in the UK.

+ +

MegaWave2

+ +

Last Update 2004-06 / Version 2.3
+ + http://www.cmla.ens-cachan.fr/Cmla/Megawave/
+ Language C
+ Very UNIX oriented. Good implementation. Many functions. C preprocessor. + Developed by French researchers at l'École Normale Supérieure de Cachan.

+ +

JAI

+ +

Last Update 2003-07 / Version 1.1.2
+ + http://java.sun.com/products/java-media/jai/index.jsp
+ Language Java
+ It is becoming more and more popular. Java is slow than C/C++ but the + performance of the image processing operations is very acceptable. Also it + has several C optimized functions. Developed by the Sun Corporation.

+ +

OpenCV ***

+ +

Last Update 2004-08 / Version 4.0
+ + http://sourceforge.net/projects/opencvlibrary/
+ Language C/C++
+ Only a few formats but lots of image processing operations. One of the most + interesting libraries available. It is more than an Imaging library, it is + designed for Computer Vision. Developed by Intel Russian researchers.

+ +

VTK ***

+ +

Last Update 2004-03 / Version 4.2
+ http://www.vtk.org/
+ Language C++
+ Another very important library. Very huge. Much more than Imaging, includes + also 3D Computer Graphics and Visualization. Has a book about the library. + Developed by Kitware Inc.

+ +
+

IM

+ +

Last Update 2004-08 / Version 3.0.2
+ http://www.tecgraf.puc-rio.br/im
+ Language C/C++
+ Support for several data types, i.e. scientific images and different + color spaces. Support for input and output of image sequences. Support for + generic image attributes (metadata), which includes several standard TIFF + tags, GeoTIFF tags and Exif tags. Image storage and capture data can be + accessed using an image structure or with raw data. Internal implementation + in C++ but with a simple C API. Code is portable for Windows and UNIX. Many + image processing operations.

+ +
+

Comparsion

+

The idea behind IM was to create a toolkit that was not so complex as + OpenCV, neither so big as VTK, but that can be used as a solid base to the + development of thesis and dissertations, as for commercial applications.

+

As the academic environment is very heterogeneous the IM project choose + some directives:

+ +

Considering these directives there are only a few similar toolkits. Making + some exceptions the following should be mentioned:

+ +

Today OpenCV and VTK are the most professional and complete choices of free + libraries that are similar to IM. But they are more complicated than IM. For + instance VTK it is very large, it has about 700 C++ classes.

+

Although OpenCV has many resources, its code is very hard to reuse. The + simplicity of the IM code, mainly the image processing routines, make it a + good reference to be reused by other applications extracting only the code + needed with little changes. And can be used as an complement to learn image + processing algorithms and techniques.

+
+

This page was last updated in Sep 2004.

+ + + + + diff --git a/html/en/topdown.gif b/html/en/topdown.gif new file mode 100644 index 0000000..b0fa44f Binary files /dev/null and b/html/en/topdown.gif differ diff --git a/html/en/zlib.txt b/html/en/zlib.txt new file mode 100644 index 0000000..6447ba6 --- /dev/null +++ b/html/en/zlib.txt @@ -0,0 +1,33 @@ +Copyright notice: + + (C) 1995-2004 Jean-loup Gailly and Mark Adler + + This software is provided 'as-is', without any express or implied + warranty. In no event will the authors be held liable for any damages + arising from the use of this software. + + Permission is granted to anyone to use this software for any purpose, + including commercial applications, and to alter it and redistribute it + freely, subject to the following restrictions: + + 1. The origin of this software must not be misrepresented; you must not + claim that you wrote the original software. If you use this software + in a product, an acknowledgment in the product documentation would be + appreciated but is not required. + 2. Altered source versions must be plainly marked as such, and must not be + misrepresented as being the original software. + 3. This notice may not be removed or altered from any source distribution. + + Jean-loup Gailly Mark Adler + jloup@gzip.org madler@alumni.caltech.edu + +If you use the zlib library in a product, we would appreciate *not* +receiving lengthy legal documents to sign. The sources are provided +for free but without warranty of any kind. The library has been +entirely written by Jean-loup Gailly and Mark Adler; it does not +include third-party code. + +If you redistribute modified sources, we would appreciate that you include +in the file ChangeLog history information documenting your changes. Please +read the FAQ for more information on the distribution of modified source +versions. -- cgit v1.2.3