We are happy to announce that OTB and Monteverdi have entered the 3.12 release candidate stage!

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

First of all, we would like to share with all of you the pride and excitement following the success of Pleiades launch on Soyouz which took place on saturday the 17th at 03:03 AM CET. To best prepare OTB for these up-coming images, the next OTB release will happen in late january, allowing to test it against real Pleiades images. Until then, we are starting a series of short posts in order to present one of the major changes of this new release : the new applications framework.

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

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 !

Watch the organic organization of an open source project  like OTB and how contributors modify and expand the source code!

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.

Some people can be talented in several domains. In addition to his good work with Orfeo ToolBox on a supervised method to enhance segmentation results for categories of objects of interest, our intern, Olivier Canévet, has proven many times to be a very good baker. When he started planning to bake an OTB cake, at first we did not think he was serious. But with the end of his internship coming, he showed up one morning with this :

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