OTB Development Team
OTB provides:
Many of these functionalities are provided by ITK and have been tested and documented for the use with remote sensing data.
You can get more information on OTB on the web at http://www.orfeo-toolbox.org.
The PLEIADES optic component is composed of two "small satellites" (mass of one ton) offering a spatial resolution at nadir of 0.7 m and a field of view of 20 km. Their great agility enables a daily access all over the world, essentially for defense and civil security applications, and a coverage capacity necessary for the cartography kind of applications at scales better than those accessible to SPOT family satellites. Moreover, PLEIADES will have stereoscopic acquisition capacity to meet the fine cartography needs, notably in urban regions, and to bring more information when used with aerial photography.
The ORFEO "targeted" acquisition capacities made it a system particularly adapted to defense or civil security missions, as well as critical geophysical phenomena survey such as volcanic eruptions, which require a priority use of the system resources.
With respect to the constraints of the franco-italian agreement, cooperations have been set up for the PLEIADES optical component with Sweden, Belgium, Spain and Austria.
The creation of a preparatory program is needed because of :
This program was initiated by CNES mid-2003 and will last until mid 2011. It consists in two parts, between which it is necessary to keep a strong interaction:
This Accompaniment Program uses simulated data (acquired during airborne campaigns) and satellite images quite similar to Pleiades (as QuickBird and Ikonos), used in a communal way on a set of special sites. The validation of specified products and services will be realized with those simulated data
Apart from the initial cooperation with Italy, the ORFEO Accompaniment Program enlarged to Belgium, with integration of Belgian experts in the different WG as well as a participation to the methodological part.
You can get the current development version, as our repository is public, using Mercurial (available at http://www.selenic.com/mercurial). Be aware that, even if the golden rule is what is commited will compile, this is not always the case. Changes are usually more than ten per day.
The first time, you can get the source code using:
hg clone http://hg.orfeo-toolbox.org/OTB
Then you can build OTB as usual using this directory as the source (refer to build instructions).
Later if you want to update your source, from the OTB source directory, just do:
hg pull -u
A simple make in your OTB binary directory will be enough to update the library (recompiling only the necessary stuff).
We assume that you will install everything on a directory called INSTALL_DIR, which usually is /usr/local, /home/jordi/local or whatever you want. Make sure that you have downloaded the source code for:
Important note: on some Linux distributions (eg. Debian, Ubuntu, Fedora), you should use the official packages for CMake, GDAL and Fltk (including the development packages). Once you have installed these packages, you can skip to step 4.
cd INSTALL_DIR
gunzip gdal.1.5.2.tar.gz
tar xvf gdal.1.5.2.tar
cd gdal.1.5.2
./configure --prefix=INSTALL_DIR
make
make install
It seems to be a bug in the GDAL install procedure: if you are installing it without root privileges, even if your INSTALL_DIR is a directory for which you have the write permissions, GDAL tries to copy the python bindings together with the Python site packages, which are usually somewhere in /usr/lib.
Actually, since this is the last step in the GDAL install procedure, when you get the error message, the GDAL libs and header files are already installed, so you can safely ignore the error.
The -without-python option passed to the configure step avoids this. However, some users may want to have Python bindings, so recommending this option for the install may not be OK for everybody.
cd INSTALL_DIR
gunzip cmake-2.6.0.tar.gz
tar xvf cmake-2.6.0.tar
cd cmake-2.6.0
./configure --prefix=INSTALL_DIR
make
make install
In order to properly use cmake, add INSTALL_DIR/bin to
your path with export PATH=$PATH:INSTALL_DIR/bin or
something similar.
cd INSTALL_DIR
bunzip2 fltk-1.1.9-source.tar.bz2 OR
gunzip fltk-1.1.9-source.tar.gz
tar xvf fltk-1.1.9-source.tar
mkdir Fltk-binary
cd Fltk-binary
ccmake ../fltk-1.1.9
--> follow the CMake instructions, in particular:
--> set CMAKE_INSTALL_PREFIX to INSTALL_DIR within CMake
--> set BUILD_EXAMPLES to ON within CMake
--> generate the configuration with 'g'
make
make install
--> check that the examples located in
INSTALL_DIR/Fltk-binary/bin work, in particular, the fractals
example which makes use of the OpenGL library needed by OTB.
You can also choose to use the FLTK version we included in the source of OTB, in this case, everything will be compile at the same time. To do that, you will have to set the option OTB_USE_EXTERNAL_FLTK to OFF
cd INSTALL_DIR
gunzip OrfeoToolbox-3.4.0.tgz
tar xvf OrfeoToolbox-3.4.0.tar
mkdir OTB-Binary
cd OTB-Binary
ccmake ../OrfeoToolbox-3.4.0
--> follow the CMake instructions, in particular:
--> set BUILD_EXAMPLES to ON within CMake
--> set BUILD_SHARED_LIBS to ON within CMake
--> set BUILD_TESTING to OFF within CMake
--> set CMAKE_INSTALL_PREFIX to INSTALL_DIR within CMake
--> set GDAL_INCLUDE_DIRS to INSTALL_DIR/include within CMake
--> set GDAL_LIBRARY_DIRS to INSTALL_DIR/lib within CMake
--> set OTB_USE_EXTERNAL_ITK to OFF within CMake
--> set FLTK_DIR to INSTALL_DIR/Fltk-Binary within CMake OR
if you do not have FLTK, you can use the OTB internal FLTK setting
OTB_USE_EXTERNAL_ITK to OFF. If you don't have FLTK and don't want to use
the internal one, press 't' to change to advanced mode and set OTB_USE_VISU to OFF
--> generate the configuration with 'g'
make -j 2
If you want a faster compilation and don't want the compilation of the examples, you can set BUILD_EXAMPLES to OFF. Some platforms apparently have more difficulties with shared libraries, if you experience any problem with that, you can set BUILD_SHARED_LIBS to OFF but the built size might reach 1 GB.
After these steps, you have the source of OTB in INSTALL_DIR/OrfeoToolbox-3.0.0 and the compiled binaries and libraries in INSTALL_DIR/OTB-Binary. Keeping the sources is important as most programs you will designed will need an access to the .txx files during compilation. However, the binaries directory knows were its sources are and you will need to point only to the INSTALL_DIR/OTB-Binary when the cmake for your program will ask you where the OTB is.
If you want to put OTB in a standard location, you can proceed with:
make install
but this is only optional.
First give the path where the source code is and where to build the binaries.
Then press the "Configure" button and choose the generator for your project. For example, Visual Studio 9 2008.
Select the option "Advanced View".
Then set the option USE_EXTERNAL_FLTK to OFF. (or uncheck the button).
Select the value Release for the option CMAKE_CONFIGURATION_TYPES
Press the "Configure" button and you will be asked to set the following variables :
GDAL_INCLUDE_DIR = "C:/OSGeo4W/apps/gdal-16/include"
GDAL_LIBRARY_DIR = "C:/OSGeo4W/apps/gdal-16/lib/gdal_i.lib"
OGR_INCLUDE_DIR = "C:/OSGeo4W/apps/gdal-16/include"
CURL_INCLUDE_DIR = "C:/OSGeo4W/include/curl"
CURL_LIBRARY = "C:/OSGeo4W/lib/libcurl_imp.lib"
TIFF_INCLUDE_DIRS = "C:/OSGeo4W/include"
TIFF_LIBRARY = "C:/OSGeo4W/lib/libtiff_i.lib"
GEOTIFF_INCLUDE_DIRS = "C:/OSGeo4W/include"
GEOTIFF_LIBRARY = "C:/OSGeo4W/lib/geotiff_i.lib"
JPEG_INCLUDE_DIR = "C:/OSGeo4W/include"
JPEG_INCLUDE_DIRS = "C:/OSGeo4W/include "
JPEG_LIBRARY = "C:/OSGeo4W/lib/jpeg_i.lib"
PNG_PNG_INCLUDE_DIR = "C:/OSGeo4W/include"
PNG_LIBRARY = "C:/OSGeo4W/lib/libpng13.lib"
ZLIB_INCLUDE_DIR = "C:/OSGeo4W/include"
ZLIB_LIBRARY = "C:/OSGeo4W/lib/zlib.lib"
Microsoft Visual Studio 2010 is currently not supported.
To compile GDAL, at configure step, use these options :
./configure --prefix=INSTALL_DIR --with-png=internal --with-libtiff=internal --with-jpeg=internalThen the usual make and make install.
See Linux part for details (same procedure).
That should be all! Otherwise, subscribe to otb-users@googlegroups.com and you will get some help.
See http://www.gnu.org/software/tar/manual/tar.html#Checksumming for details on the bug characterization.
The solution is to use the GNU tar command if it is available on your system (gtar).
Put OTB_USE_VISU to OFF to avoid these problems.
Some bugs can appear while compiling GDAL with JPEG2000 files : disable this format to solve the problem.
To compile GDAL, at configure step, use these options :
export CFLAGS="-O2 -W -arch i386 " export CXXFLAGS="-O2 -W -arch i386 " export LDFLAGS="-arch i386" ./configure --prefix=INSTALL_DIR --with-png=internal --with-libtiff=internal --with-geotiff=internal --with-jpeg=internal
Then the usual make and make install.
Follow the Unix/Linux instructions. In particular set the following variables :
CMAKE_OSX_ARCHITECTURES = i386
GDAL_INCLUDE_DIR
GDAL_LIBRARY_DIR
OTB_USE_LIBLAS = OFF
Then the usual make and make install.
It seems to be fine with the more recent release of Open Solaris.
OTB presents a large set of features and it is not always easy to start using it. After the installation, you can proceed to the tutorials (in the Software Guide). This should give you a quick overview of the possibilities of OTB and will teach you how to build your own programs.
The maximum physical space a user can allocate depends on her platform. Therefore, image allocation in OTB is restricted by image dimension, size, pixel type and number of bands.
Fortunately, thanks to the streaming mechanism implemented within
OTB's pipeline (actually ITK's), this limitation can be bypassed. The
use of the
http://www.orfeo-toolbox.org/doxygen/classotb_1_1StreamingImageFileWriter.htmlotb::StreamingImageFileWriter at the end of the pipeline,
or the
http://www.orfeo-toolbox.org/doxygen/classitk_1_1StreamingImageFilter.htmlitk::StreamingImageFilter at any point of the pipeline will
seamlessly break the large, problematic data into small pieces whose
allocation is possible. These pieces are processed one afther the
other, so that there is not allocation problem anymore. We are often working with
images of
pixels.
For the streaming to work, all the filters in the pipeline must be streaming capable (this is the case for most of the filters in OTB). The output image format also need to be streamable (not PNG or JPEG, but TIFF or ENVI, for instance).
To tune the size of the streaming pieces, the OTB has two CMake variables. The first is named OTB_STREAM_IMAGE_SIZE_TO_ACTIVATE_STREAMING. It represents the minimum size of the image in bytes for which streaming may be helpful. The second, OTB_STREAM_MAX_SIZE_BUFFER_FOR_STREAMING, specifies the maximum size in bytes a streaming piece should have. It can be used to compute the optimal number of pieces to break the input data into.
These two parameters have been used in the OTB-Applications/Utils/ applications. Take this as an example of how they can be used. They can also be tuned by the user to match her specific needs.
First, you can send an email to otb@cnes.fr or the the user mailing list (otb-users@googlegroups.com) to let us know what functionality you would like to introduce in OTB. If the functionality seems important for the OTB users, we will then discuss on how to retrieve your code, make the necessary adaptions, check with you that the results are correct and finally include it in the next release.
You can also run the nightly tests so we have a wider range of plateforms to detect bugs earlier. Look at section 8.
Besides the satisfaction of contributing to an open source project, we will include the references to relevant papers in the software guide. Having algorithms published in the form of reproducible research helps science move faster and encourages people who needs your algorithms to use them.
You will also benefit from the strengths of OTB: multiplatform, streaming and threading, etc.
All functionalities which are useful for remote sensing data are of interest. As OTB is a library, it should be generic algorithms: change, detection, fusion, object detection, segmentation, interpolation, etc.
More specific applications can be contributed to the OTB-Applications package.
OTB is an ever changing library, it is quite active and have scores of changes per day from different people. It would be a headache to make sure that the brand new improvement that you introduced didn't break anything, if we didn't have automated tests. You also have to take into account differences in OS, compilers, options, versions of external libraries, etc. By running the tests and submitting it to the dashboard, you will help us detect problems and fix them early.
For each class, at minimum there is a test which tries to instantiate it and another one which uses the class. The output of each test (image, text file, binary file) is controlled against a baseline to make sure that the result hasn't changed.
All these test are available in the directory Testing and are also good examples on how to use the different classes.
There is more than 1000 tests for OTB and about 100 for the OTB-Applications and it takes from 20 minutes to 3 hours to run all the test, mainly depending on your compilation options (Release mode does make a difference) and of course your hardware.
To run the tests, you first have to make sure that you set the option BUILD_TESTING to ON before building the library. If you want to modify it, just rerun ccmake, change the option, then make.
For some of the tests, you also need the test data and the baselines (see 8.3).
Once OTB is built with the tests, you just have to go to the binary directory where you built OTB and run ctest -N to have a list of all the tests. Just using ctest will run all the tests. To select a subset, you can do ctest -R Kml to run all tests related to kml files or ctest -I 1,10 to run tests from 1 to 10.
If you have a problem at the compilation, you can skip this step first. Data used for the tests are also versioned using Mercurial (see 3.3).
You can get the base doing:
hg clone http://hg.orfeo-toolbox.org/OTB-Data
This is about 1 GB of data, so it will take a while, but you have to do it only once, as after, a simple
hg pull -u
will update you to the latest version of the repository.
You can also easily synchronize the directory you retrieve between different computers on your network, so you don't have to get it several times from the main server. Check out Mercurial capabilities.
Once you know how to run the tests, you can also help us to detect the bugs or configuration problems specific to your configuration. As mentionned before, the possible combinations between OS, compiler, options, external libraries version is too big to be tested completely, but the more the better.
You just have to launch ctest with the -D Experimental switch. Hence:
ctest -D Experimental -A CMakeCache.txt
And you will be able to see the result at
http://dash.orfeo-toolbox.org/Dashboard/index.php?project=OTB.
If you are interested in setting up a nightly test (automatically launched every night), please contact us and we will give you the details.
The first version was 1.0.0 in July 2006. Version 1.2.0, 1.4.0 and 1.6.0 were released in between. The 2.0.0 major version was released in December 2007. The 2.2.0, 2.4.0 and 2.6.0 in June, July and November 2008 respectively. The 2.8.0 came out in January 2009, the 3.0.0 in May 2009 and the 3.2.0 in January 2010. The current one is 3.4.0.
Nevertheless, the main milestones for the OTB development are the following: