This is a great opportunity to discover OTB, ask questions (even tricky ones) or have a “real” conversation with the OTB developers !

See you in Frascati,

Julien

Since a few months, he is rewriting Sextante (initially in Java for gvSIG) as a new QGIS Python plugin. Sextante provides access to a huge number of processing modules, and acts as a geoprocessing environment that can be used to call native and third-party algorithms from QGIS.

With the help of Victor, the meeting has been quite productive and we now have a first working version of the OTB Sextante algorithm provider. This completes the list of already available algorithms : GRASS, Saga, GDAL, mmqgis, fTools…

And I was not the only one interested in using Sextante. An OGR algorithm provider is on the way, and the developer of the WPS client plugin has also expressed interest in porting it to Sextante too. You can expect the list of available back-ends to grow regularly in the near future.

Regarding the functionnalities, Sextante shows up as a toolbar in the QGIS desktop GUI, and allows to process QGIS raster and vector layers by clicking on a processing module entry. It automatically handles the potential I/O conversions needed for some backend (like GRASS and SAGA), and loads the results as new QGIS layers. It tracks down your history of launched modules, logs, etc… It can also be called from Python in a headless environment (ok… who said “QGIS WPS server” ?).

The killer feature is the Modeler, providing a simple yet effective way of creating pipeline of Sextante modules to build up new higher level Sextante modules. This makes it very easy to interface Orfeo Toolbox with all the other geoprocessing environments available in Sextante.

Here are a few screenshots to give you an overview of Sextante :

Many thanks to Victor for providing Sextante in QGIS !

Seeing so much interest in Sextante from the QGIS community, and provided Victor will be working on the plugin full time until next year, we can hope for a beautiful future for the Sextante QGIS plugin !

Julien

In 2011, the third course was given in Antananarivo by Stéphane May from CNES,. All the slides, presentations and technical courses updated especially for this last session are now available here.

Please visit the Success stories page to find out all materials available about the ORFEO ToolBox library and related projects!

Stay tuned!

Manuel

In order to get a good picture of the OTB community, we proposed a survey to our user between the end of June and October 2011. This post is a (late) report of the results we had, thanks to your answers.

General information about the survey

We had a total of 62 answers to the survey. Not many questions were mandatory so I will try to avoid to give statistics using percentages for answers and prefer to give the number of answers.
This article does not claim to provide a complete and general summary. We are aware that it can be dangerous to draw too many conclusions from opinions poll.
This article is more at an introduction to the results which are completely available here.

Who answered the survey?

Before trying to investigate and give conclusions about the survey, let’s first analyze who took time to answer it!

People who answered are mostly engineers and scientists (18 and 22) working in institutional organizations (23) and equally in labs (15) or private companies (17).  But there are also people working in NGO, students, which shows the diversity of people who use the library. Though OTB was developed in the frame of the Methodological Part of the ORFEO Accompaniment Program to prepare, accompany and promote the use and the exploitation of the images derived from Pleiades (PHR) and Cosmo-Skymed (CSK) satellites, interestingly most people are not involved in this program. They found out about the library through the web or thanks to co-workers or public presentation in conferences for example, rather than from the ORFEO program. Obviously they use the ORFEO ToolBox but they also use a lot of other tools (Open Source or proprietary one) in their daily work. Another interesting point to notice is that the amount of people using Linux system to do image processing with OTB is equal to the amount of Windows users (41 and 41).

How do you access OTB?

First, although OTB has celebrated its fifth birthday earlier this year, 39 of them use the library for less than 1 to 3 years (26 use it for less that one year). Note that 31 are building OTB and derived tools themselves to use it. Building projects from source does not seem to be a problem for about half of them. Note also that 11 people (21%) use binary packages (Ubuntu/OpenSuse/CentOS/ArchLinux). We should surely maintain the effort in this frame and continue to facilitate the accessibility to the library by providing these packages for Windows, MacOS X and Linux systems.

The OTB/Monteverdi tipping point

33 access the OTB through the library and 30 through Monteverdi. That’s clearly an important information given by the survey.  We see here that Monteverdi is an important way to access OTB (as important as the library itself). Obviously without the library, Monteverdi would not exist, but we see that GUI applications are an entry point for the OTB. Command line applications are also largely used by end-users and I think that it will continue to increase in the future thanks to the new OTB applications framework available in release 3.12, which allows to access OTB functionalities in a number of different languages and context (in QT standalone application, in Quantum GIS plugins, in Python, in Clojure….) Clearly OTB have to continue in these 3 directions and we have to be aware that GUI applications have become an important entry point for a majority of OTB users.

Why do you use OTB for?

Even if 32 people use OTB with HR data (Spot like) and 28 with VHR optical images, we can see a great diversity of remote sensing data use with OTB which clearly show that OTB is useful in a lot of context (hyperspectral, SAR, lidar…). The diversity in the data processed by OTB users is confirmed by the diversity of OTB algorithms in use. 31 users use feature extraction algorithms, the best score, which is reassuring because it is one of the main reason why OTB was developed, but lots of other functionalities are also largely used. The survey shows that there is a great deal of interest of the RS community in having a tool providing a wide range of functionalities through a common and generic interface.

Why OTB sucks ?

The title is intentionally provocative to illustrate the fact that in this kind of survey, questions related to critics are really interesting and provide relevant advises on how to improve the software together. 12 answers put the emphasis on the complexity of the design due to the genericity of the library, that’s surely related to the well-known steep learning curve associated to OTB. Using the library though C++ classes requires knowledge in C++ design pattern and template metaprogramming. But it’s worth it!

Moreover, access to OTB is made more and more easier through different languages, interfaces …

The second answer is about the incomplete validation of some algorithms. OTB contributors works a lot to maintain a high quality and using test driven developments technics and continuous integration. But this process is only as good as what we do with it, and this shows that there is room for improvement. Validating an algorithm might be a complex task per se, but the high level design can make this even more difficult : multiple plateforms, different streaming and threading behaviours related to the available hardware … And on top of it, different data fed to the algorithm in different context of uses! A faulty design or incomplete definition of some functionnality from the very start of it might also be a cause : design and validation qualtiy are often related. But all softwares have bugs, and we find extremely helpful that whenever you encouter an undesired behaviour, suspicious result or bug, you file it to the OTB bug-tracker : open-source software is about improving things together, and anyone can help !

We received interesting remarks also on the documentation. Even if the software guide is more than 700 pages long, users are pointing the fact that knowing the complexity of OTB design, the doxygen documentation of classes is sometimes incomplete or unclear and that it lacks of examples for some filters. One respondent made the suggestion that code example should be included for every class in the doxygen: that’s a very useful suggestion (and we actually already have these examples with the tests, we’ll have to link them to the doxygen). This subject is also pointed out when you said (23) that the main difficulty with OTB is to find relevant information in the documentation.

Is it the Monteverdi partition “audible”?

You clearly explain that Monteverdi lacks a better GUI and also a better ergonomy! The best example is the number of mouse clic need to get an image opened and displayed.  According to your comments, the software has a great potential but also suffers from a lack of stability.

Lost in OTB?

When working with Open Source software, an important point is to have access to a minimum of informations to solve problems that will obviously arise. You said that the development team and the community is very useful (many thanks for us !). Error messages given by the library are in most cases usually helpful for you (14+21). Moreover doxygen and software guide are equal sources of informations (16 and 17).

These sources of information (Software Guide and doxygen) are very important but in most cases not really relevant speaking of the Monteverdi documentation and that’s a bad point. To improve this, the OTB development team initiated in 2011 a guide dedicated to non-developers : the OTB CookBook. This guide is composed of a brief tour of OTB applications and Monteverdi, followed by a set of recipes to perform usual remote sensing tasks with both tools. Starting OTB 3.14, it also contains the reference documentation for all OTB applications.

OTB : Give me a break? Stop or encore?

OTB provides a wide variety of functionalities taking often advantages of dedicated Open Source libraries inside it (GDAL, OSSIM, OpenJPEG, libSVM…). But there are still new algorithms which could be included in the library. We do not give the entire wish-list here, but there are multiples demands for :new classification methods, multi-source analysis, QT viewer… The diversity of data that you manage combined with the diversity of algorithms that you want to use put the emphasize on the need for software interoperability combined with a full access to the software which enable users to tailor/control their processes.

“Found all the remote sensing image processing functionality that I needed (together with the ITK libraries)”

For example, the accessibility of OTB through GIS software like Quantum GIS is a common ask (27 people), and we all agree that we need to continue to work jointly with the amazing QGis community to build the bridge between the 2 softwares.

OTB is all about you, thank you again to all the people who take time to answer the survey.

For those who are interested, all the results (anonymous) and detailed statistics are available here.

Keep in touch!

OTB  Team

CNES is proud to announce the release of Orfeo ToolBox 3.12, codename Πλειάδες.

After its sucessful launch on the 17th of December 2011, and while still in its comissing phase, Pleiades is already sending us beautiful images. This new release, and especially the JPEG2000 support part, has been tested against real Pleiades images kindly provided by the comisioning team.

There are exciting new stuff in all corners of the library. Some of the notable changes in this release are:

You can find the source (OTB and Monteverdi) and binary packages (Monteverdi form Mac OS X and Windows) here.

Some of the notable changes in this release are:

• Large JPEG2000 file (Pleiades-like) support and Pleiades metadata handling in OTB (more information here)
• Efficient JPEG2000 visualisation and ROI decompression tools in Monteverdi
• Revamp of otb applications in a generic and scalable framework (more information here) : launch applications from Command-Line, from an auto-generated QT GUI, from python, from within QGis …
• Lots of new algorithms : Dimensionality Reduction (ICA, PCA, MNF, MAF …), change detection (MAD), Hyperspectral Unmixing, elevation map from stereo data, compare segmentation with a ground truth (Hoover) …
• And various bug fixes.

There are a lot more new things coming with this release ! For more information, please read the complete release note available here.

As usual, Release Candidate are made to be tested and stressed, so do not hesitate to give it a try and report whatever you find suspicious on the users list, or directly on the BugTracker.

Also note that a teaser of what can be done with OTB is now available here !

Happy Testing!

Manuel, for the OTB team

History

Until now, there was an OTB-Applications package built on top of the library, which provided command-line tools, Qt and FLTK based GUIs, and Qgis C++ plugins. This package was not very popular among our users : it was lacking of documentation, missed really useful auto-generated GUIs and did not provide an interface to interpreted languages. These applications were barely more than a serie of mains decorated with an argument parser. However, these applications were providing a lot of image manipulation utilities and high-level processing chains like ortho-rectification, classification or segmentation. Being too obscure, they simply did not get the attention they deserved.

Six month ago, we started a side project called OTB-Wrapper, which was designed as a sand-box to experiment with all the possible enhancements to make the applications really useful. After a while, we came up with a complete solution and implemented it directly into the OTB library. All applications from the OTB-Applications package have then been migrated to this new framework, also directly into the OTB library.

The new framework in a nutshell

So, what does this new framework provide to the users ? A lot of things ! See :

• Each application is now compiled into a single tiny shared-library,
• Writing new applications in an external project is as simple as inheriting the base class and calling a CMake macro,
• These applications shared libraries are loaded dynamically as plugins of several generic access points :
• Directly from C++
• From an interpreted or compiled higher level language like Python through the SWIG interface,
• From a command-line launcher, like the old applications,
• From a nice auto-generated Qt GUI,
• From QGis through seamless OTB plugins.

The general philosophy of this new framework is to have to write the processing only once, and then use it from whatever environment, programming language or software you want through one of these access points.

Success !

Even before the official release, success is already showing up :

• A simple python script allows to generate documentation for all the applications,
• A simple python script allows to generate applications file descriptors for integration in external tools like the KEO system from ESA,
• A simple python script allows to perform batched processing chaining several applications,
• Qt GUIs are really nice to use, with a lot of useful features like automatic parameters estimation (for instance, the ortho-rectification application provides you with the best-fit parameters for your image),
• The python interface allows nice integration within QGis,
• And the command-line interface is more robust and easier to use.

Learn more in next posts

If you want to give this a try, clone a the OTB mercurial repository and activate the BUILD_APPLICATIONS flag. You are ready to go ! In the following posts, we will focus on key features that makes this new framework so exciting. But for now, it is time for us to wish you all a merry christmas !

Julien, on behalf of the OTB team

With the Pleiades launch a few weeks ahead, there has been a lot of ongoing work from the OTB team to prepare for these new data. Since a lot of discussions happened off the list, either with phone meetings, or on other mailing lists (we will see later on why), and since we now have a comprehensive knowledge of what the support of Pleiades images in OTB will be, it is about time we explain it to users and developers.

Reminder on Pleiades images

We will start with a reminder : Pleiades images will be available in Jpeg2000 format allowing a high compression rate, tiled in 2048×2048 pixels, so a standard Pleiades image will contain a few hundreds of tiles. A typical Pleiades image size is 40 000 x 40 000 pixels (corresponding to a 20 km by 20 km area), and one of the standard product is a pan-sharpened one, which is a merge of the high resolution panchromatic and lower resolution multispectral imagery to create a single high resolution color image. These images would be very heavy without Jpeg2000 compression : for instance, if the Jpeg2000 file weights 1.7 Go, the decompressed file weights 7.3 Go. To decode those JPEG2000 files, there are a few commercial libraries, the most popular beeing Kakadu. There is also some open-source alternatives, among which OpenJPEG seems to be the most advanced. Of course, for Pleiades support in OTB, we need an open-source solution, even if GDAL can be compiled with a driver based on Kakadu (has to be the commercial version, not the trial one available for free under restrictions of use).

Open-source JPEG 2000 implementation

Back in 2007, the OTB people here at CNES already spotted OpenJPEG as the best open-source bet for JPEG2000 support in OTB. Since the library was missing some important features (like partial decoding and MCT support), they set-up a CNES contract with the CS Company in order to add these features to OpenJPEG. But when this contract was over, the new features were not integrated in OpenJPEG trunk but left on a side branch (the so-called v2), because nobody in OpenJPEG community had in-dept knowledge of what had been done in this new version. The development of the trunk went on with bug-fixes and enhancements, while the v2 branch did not evolve. In the meantime, we started a driver in OTB based on the v2 OpenJPEG version, but this was not a sustainable option, because the v2 was barely maintained. Thanks to its more advanced functionnalities, the v2 branch of OpenJPEG also received interest from other FOSS projects in need for advanced decoding capabilities, and got integrated in at least ITK, GDCM and GDAL.

Four months ago, we agreed with the OpenJPEG community that we needed to get the v2 merged with the OpenJPEG trunk. Mickaël Savinaud from the CS OTB team got involved into OpenJPEG development to get the merge between v2 and trunk done, and we now have a full-featured version of OpenJPEG in trunk thanks to his great work and to the support of the OpenJPEG community.

Now, it is time to face the truth : even with this new version, in terms of decoding performances, this state-of-the-art open-source software is way worse than Kakadu : decoding one tile is way slower than with Kakadu, and one tile of 2048×2048 pixels is the atomic unit for decoding (i.e. if you need one pixel, you will still need to first decode the whole tile).

We looked into optimization : reducing file seeking, implementing some macroscopic code optimisation (mainly avoiding pessimisation) of the Tier1 part which is clearly identify as the performances bottleneck (see figure below with profiling reports using kcachegrind). We made some clear progress, but the JPEG2000 standard is complex, and without knowledge of the big picture, we could not gain a lot.

KCachegrind representation of time percentage per functions

What does it mean for Pleiades data ?

It means that simply decoding a full Pleiades image at full resolution will take about 20 minutes on a decent i5 CPU with 4 Go of RAM, while the same image in standard TIF format would have taken 8 minutes and Kakadu takes only 4 minutes. Any OTB processing pipeline streaming the whole image will be limited by this decompression time. And we are not even talking of sub-sampling or estimating statistics at some point in the pipeline.

Of course, we could tell our users to buy a Kakadu licence and compile GDAL with the Kakadu driver enabled, but we can not even tell them how much it will cost, and this is clearly in contradiction with the open-source philosophy of OTB. Still, this remains an option to get high performances JPEG2000 support in OTB, but you are on your own if you choose this solution.

Now, what will it be possible to do using Pleiades data with the open-source solution OpenJPEG in OTB ?

• On OTB side: No specific handling will be added. It is the responsibility of the developer to know that the JPEG2000 driver is not as fast as the other drivers. The developer has the possibility to easily select the appropriate resolution and accordingly set the size streamed region (to reduce the number of decoding operations).  Of course, metadata related to geometric and radiometric calibration will be supported through OSSIM. Moreover, we will support the GMLJP2 box included in the Pleiades to support geo-information in case of ortho-image products.

• On applications side:

• We will provide an application able to convert a Pleiades image, either full or extract, from any JPEG2000 resolution, into another file format (like TIF for instance). Of course, one will need a lot of disk space to handle the decompressed data. Please note that this is not fully supported by Kakadu trial version, which decodes a maximum of 3 channels (and which use is restricted by the way),

• All applications will support Pleiades images, but it will be highly recommended to first decompress the image to disk for reasonable performances and if more than one processing is to be executed on the image,

• On Monteverdi side:

• Pleiades images will open in a dedicated new type of data in Monteverdi interface, and the user will be able to select the resolution level for decoding,

• The viewer module will accept this new type of data and we will be able to efficiently navigate within Pleiades images : fast quicklook computation due to JPEG2000 capabilities, instant navigation into a 4 tiles squared area thanks to caching, and quick-enough refresh when moving outside this cached area thanks to parallel tiles decoding. We expect the navigation experience to be quite good !

• The extract ROI module will accept this new type of data and allow to select an extract of the image using the fast quicklook ability. Caching (which will decompress image to disk in TIF format) will be recommended (this behaviour might be extended to other modules later).

• The writer module will accept this new type of data for conversion purposes.

• All other modules will not accept this new type of data : to use them, the user will first have to use the extract ROI module which will produce a plain image type accepted by all modules. Caching will be recommended for this purpose.

Closing Thoughts

We can hope that the widening use of JPEG2000 in spatial imagery will encourage the improvement of open-source JPEG2000 libraries performances. When and if this becomes available, you will be able to use those datasets in OTB seamlessly, as any other image.

Until then, we can look at the bright side :

OTB will provide an open-source and free access to Pleiades data for those not owning a commercial image processing software  (please note that Gdal is looking into the new OpenJPEG version and might also support Pleiades through it in a near future).

OTB will provide an efficient solution for Pleiades data decompression and visualization. 

Last, the whole set of OTB processing remains fully available, at the expense of extra decoding time or once your Pleiades data have been decompressed to disk.

This has also been a great experience of collaboration between open-source projects towards a common goal. We would like to thank again the members of the OpenJPEG community, as well as the OTB Team at CS for their great work !

This video was generated with the open source software version control visualization tool Gource.

It shows modifications  in : OTB, OTB-Applications, Monteverdi, OTB-Documents, OTB-Qgis-plugins and OTB-Wrapping source code repositories.

It took him no less than 7 hours in two days to do it, including building the cake pan out of carton pieces. It is needless to say it took us far less time to eat it once cut, and we can assure you that this cake was as tasty as beautiful !

Cheers !

Julien Michel