What's new about OTB? Rotating Header Image

Wind of changes

Happy new year to everyone! We are considering a few important changes regarding Orfeo ToolBox. We believe these changes will have a very positive impact on our open source software, however we would like to ensure that you (the Orfeo ToolBox community!) are fine with them. We therefore set up a dedicated page on our wiki (also note the ongoing wiki cleanup), so as to gather your feedback. If you would like to make a comment or suggestions, please write it on the wiki page in the appropriate discussion section. Hereafter are the three major changes we envision.

Changing license to Apache v2.0

For quite some time now we have been considering a change of license for OTB, to adopt the Apache v2.0 licence. The rational for this change is as follows :

Copyleft is a very good protection for open-source software in general, since it ensures that it will remain open, but in our remote sensing world it can also lesser the dissemination of our software. Many time we heard of situations were OTB was considered by institutions or private companies for their projects and has been wiped off the table because they (or their clients or partners) wanted to distribute the resulting software under different terms. Sometimes, costly ad-hoc technical designs are used so as to include OTB in the project while distributing it under those required terms. We could argue that this is a matter of convincing everyone that copyleft is not harmful and that OTB is worth the price, but in the mean time OTB get less audience than deserved … From a practical point of view it could do no harm to simply change the license to a more permissive one. This might help to develop OTB usage and eventually get more people involved in contributions.

Setting up a proper Contributor License Agreement

Why ? Because we see and welcome more and more contributions from our users. Without any other agreement, those contributions are implicitly made with the same license (i.e. CeCILL v2) while copyright is retained by the contributor. With an increasing number of contributions, the project might become a ship impossible to stir, for instance in the event of a necessary change of license to an up-to-date one (yes licenses have bugs too !), we would require to ask the permission of every contributor (for now still possible … but it might turn impossible if one of them simply vanishes). What does the CLA state ? There are actually two options : asking for a copyright transfer, in which case the project owner will own all copyright and thus will be able to take future actions for it, or asking for the appropriate authorizations to take those actions while retaining copyright for the contributor. We prefer the second option, because there is no reason why anyone contributing should give away her copyright. What we would like to ask is for the right to relicense the whole software (including contributions) into an equivalent or more permissive license (this will guarantee that the code remains OSS), if the PSC of the projects decides to. A CLA of course requires paperwork and signature (and in case of corporate contributions, the company should sign it too), but again it is worth the price, as it will also convince potential users that the software is free of copyright infringements. Here are the individual and company CLA of ASF for instance. We would like to apply it to any significant contribution (i.e. not for typos or very small patches).

Setting up a Project Steering Committee

Until now, the project has been informally stirred by people at CNES (Manuel, me, and Jordi or Emmanuel before us). Of course, we are always discussing technical details and orientations with the dev team at CS as well as with the otb-developers list, but with the increasing interest and contributors, we think it is time to set-up an official steering committee, with publicly identified people, rules and decisions. We would like this steering committee to be open to any participant, and new members would be accepted by existing ones following those public rules.

Coming soon: new powerful raster calculator in OTB

We are happy to announce a brand new band raster calculator in OTB. This band math is implemented in a new filter (otbBandMathXImageFilter) and this feature is also available through in a new OTB application otbBandMathX.

The letter X indicates that now the filter relies on the muparserx library, which has allowed the introduction of new functionalities, which are listed below:

Batch mode

If the same mathematical operation must be performed on every band of an input image, it is now possible to do it with a unique formula. For example, the addition of two images im1 and im2 is simply performed by simple addition:

im1 + im2

instead of (the old fashioned way):


This is possible since muparserX has capabilities to represent vectors and perform mathematical operations on them. Here, a pixel from a multi-band image is then represented as a muparserX vector: im1 (for image 1), with im1 = (im1b1, im1b2, …).

Note that it is still possible to access the pixel of a particular band from a given input image; for instance the variable im1b1 represents a pixel from first band of first input image.

Pixel neighborhoods access

muparserX is also able to process matrices, which allows the representation of neighborhoods of pixels. Such neighborhoods can be represented by simply providing nxm along with the image and band, e.g.:

gFig. 1 : Naming convention for accessing pixel neighborhoods.

A lot of useful operators come with these variables: it is possible to get the mean value of a neighborhood, as well as its median/variance/min/max values. For instance, with the expression below, we can perform a simple high-pass filter:

im1 - mean(im1b1N5x5, im1b2N5x5, im1b3N5x5, im1b4N5x5)

In the expression above, the operator mean is used with 4 neighborhoods as inputs, which means that it will produce a vector of four components. If first input image (represented by the variable im1) is made of four bands, then the expression is consistent:


Fig. 2 : High pass filter with new raster calculator

Use of global statistics

It is also possible to have access to global statistics of input images. For example, the variable im1b1Mean allows getting the mean value of band 1 from first input image. Min/max/sum/variance values are also available and use “behind the scene” OTB filters which allow to perform those computation on huge images using streaming and multi-threading.

Fine multi-expressions management

If many expressions must be interpreted, the user has the choice of:

  • Produce as many output images as there are expressions
  • Concatenate the results of the expressions into bands of a single output image

In the first case, you have to call the method SetExpression each time a new expression must be processed. In the second one, you just have to separate expressions by semicolons when calling the same method. Of course, these two solutions can be mixed together. For instance:

//producing 1st output image
//by concatenating the results of two expressions
Filter->SetExpression(“im1 + im2 ; vabs(im1-im2)”);
//producing 2nd output image
Filter->SetExpression(“im1 - mean(im1b1N5x5, im1b2N5x5, im1b3N5x5, im1b4N5x5)”);

Note that historically, OTB applications are only able to produce a single output; so the BandMathX application is a little bit more limited than the filter itself for now, which can produce multiple output images.

Constants and expressions saving capabilities

You can save constant or expression definitions in a text file, and import them into the application (or the filter) later, e.g.:

#F expo 1.1
#M kernel { 0.1 , 0.2 , 0.3; 0.4 , 0.5 , 0.6; 0.7 , 0.8 , 0.9; 1 , 1.1 , 1.2; 1.3 , 1.4 , 1.5}
#E dotpr(kernel,im1b1N3x5,im1b2N3x5) ; im2b1^expo

Here, we can see the definitions of a constant, a matrix and finally an expression.

Learn more

All of this is already available in the development version of OTB and Monteverdi2. There are also other useful information and examples that can be found in the cookbook and in the new BandMathX application documentation.

We hope you will enjoy these new features and the new application.

Don’t hesitate to test and give feedback on the otb-users mailing list!

OTB 4.2 and Monteverdi2 0.8 are out!

We are pleased to announce the final release of OTB 4.2, codename “The answer to life the universe and everything, as well as final release of Monteverdi2 0.8!

On the OTB side, among the novelties of this release, one can find :

  • A major speed-up in Haralick textures calculation, which may be 10 times faster in some cases,
  • An enhancement of the optical calibration framework, now allowing calibration parameters to be either read from metadata or fully set by hand. One can now calibrate images even when OTB does not support or find the metadata (for instance Spot4 or LandSat-8). This release also includes major improvement of atmospheric corrections for Pleiades images,
  • RPC coefficients for sensor modeling can now be read and written from/to GeoTIFF RPC tags,
  • JPEG2000 images can now be read using a Gdal driver (OpenJPEG, Kakadu, ECW) if available,
  • Numerous bugfixes in code and docs from community after the last release 4.0.

On Monteverdi2 side, there are two major improvements :

  • The rendering engine has been changed to use Ice, which allows for better rendering performances and fancy visualization stuff,
  • The data manager now allows to create and manage groups of data to organize them,
Monteverdi2 now uses the Ice rendering engine, which allows for nice features like local contrast enhancement (right mouse clic)

Monteverdi2 now uses the Ice rendering engine, which allows for nice features like local contrast enhancement (right mouse click)

When disbelief suspension abruptly ended (aka half a corner still hurts)

For this release announcement, we would like to do a bit of story-telling with something that kept us (especially Guillaume, Manuel and myself) awake at night all summer …

It all started with Gdal versus ITK coordinate convention. One of our colleague pointed out that for Gdal, coordinates refer to the upper-left corner of the first pixel, while in ITK, coordinates refer to the center of the pixel. Of course we were happily transferring the origin read from Gdal to images in ITK, resulting in half a pixel shift, which was “magically” right again when writing images to disk most of the time (note for later: always make the same mistake twice). We fixed this by converting between conventions in Gdal driver when reading and writing … And then things started to get worst.

Indeed, we found that pan-sharpening with sensor model based registration tests of DigitalGlobe sensors (QuickBird, WorldView-2 …) were failing with a very tiny misalignment between the panchromatic image and the XS image …  Not to mention that we never achieved good pansharpening quality with sensor model based registration for Pléiades, but somehow this half pixel shift improved it a bit.  After more investigation, including a discussion with Fabio Pacifici from Digitalglobe and another with the engineer in charge of RPC estimation in Pléiades ground segment, it appears that though not really specified in the product user guides, convention used by Pléiades for RPC sensor models is that (1,1) is the coordinate of the center of the upper-left pixel … while DigitalGlobe RPC sensor models assume (0,0) for the center of the same pixel. At this point, none of these conventions were consistent with what we got from our image reader anymore, which now reads the coordinate of the center of the upper-left pixel as (0.5,0.5) pixel if no other geo-information can be found be Gdal.

All this has been quite a nightmare to investigate : remember we are talking of half-pixel shift (often 25 cm with our images), which is far bellow sensor-model accuracy anyway (actually only P and XS co-registration was able to show some evidences of something wrong). Anyway, we fixed everything and we get now a more accurate and consistent OTB, with answers to some previously unexplained behavior (for instance for Pléiades pan-sharpening).  Meanwhile, this small shift broke nearly 400 tests which needed update …

To sum up, conventions now in OTB 4.2 are:

  • OTB uses pixel centered convention (like in ITK) : the origin of an image is located at the center of its pixel position (0,0). This points also corresponds to the continuous index (0., 0.),
  • The geotransform read from GDAL is translated so that the geolocation of the image is the same using OTB convention or GDAL convention (origin attached to top-left corner of the first pixel),
  • If the image has a projection, its OTB physical space corresponds to its ground coordinates,
  • If the image has no projection, it is assumed to be in sensor geometry. Its OTB physical space corresponds to the sensor focal plane : physical point (0., 0.) corresponds to the top-left corner of the first pixel (this would be also the case for an image without geotransform),
  • OSSIM uses pixel centered convention, but in OTB filters, image positions are given to OSSIM expressed in physical space. Filters are in charge to convert the default origin in OTB (0.5, 0.5) into the expected index position of the first pixel in OSSIM (0, 0). This adaptation is done for direct and inverse localization, and also for GCP coordinates,
  • The Pléiades sensor model contributed to OSSIM plugins has been updated to adopt the same convention as other sensor models.

What can you expect with OTB 4.2 :

  • Slightly better geo-location accuracy with geo-referenced raster for instance when comparing to a vector layer,
  • Slightly better geo-location when ortho-rectifying raw Pléiades images (almost unnoticeable),
  • Better pan-sharpening of Pléiades data using sensor model registration,
  • Very good pansharpening of Pléiades data using the dedicated Pléiades mode for registration, which takes advantage of the fact that P and XS in Pléiades products are already registered.

Business as usual

The complete Release Notes can be found here, and you can see that no less than 2 bugs have been fixed with respect to the RC, as well as 3 bugs on the Monteverdi2 side. Thanks again to all the contributors for the great work and to all the users for their feedbacks after the release candidate! (especially to Catherine Kern from ICube laboratory for her validation of Pléiades optical calibration)

As usual, sources (OTB, Monteverdi2) and binary packages (Monteverdi2 for Mac OS X and Windows) can be downloaded here. For Linux users, new version will be soon available for update through your favorite package manager software.

Note that we have a new type of package for our Windows users, available on Sourceforge: it is a self-contained complete archive containing all binary tools for OTB, including Applications, Ice and Monteverdi2. Nothing needs to be installed, just unzip it somewhere on your computer and you can get started! This feature is still a bit experimental, so please let us no if you run into any trouble with it.

We welcome your feedback and request, and encourage you to join the OTB community and mailing list.

 OTB Dev Team

Finally, OTB 4.0

What is a major version? Generally is means a significant jump in functionality. With the next version OTB 4.0 will imply the addition of new high level functionality bringing the compatibility with ITKv4.

There was 3 major releases in the history of OTB:

  • Version 1.0 (Fri Jun 30 14:10:37 2006) : core system, I/O and basic filtering
  • Version 2.0 (Fri Dec 14 15:48:40 2007) : geometric and radiometric corrections
  • Version 3.0 (Fri May 15 17:40:44 2009) : supervised learning, change detection

Almost five years later (and lots of other releases!) let us now introduce the new OTB version 4.0.

3bf0dfa82e3e (and a few commits later…)

Here we are, the new major version of OTB (called 4.0) is out!

3bf0dfa82e3e: this number is the result of months of hard work for the OTB development team, it is the changeset which sums up a part of this work and merge a bunch of patches which makes OTB compatible with the last major version of  ITK (called ITKv4).

As you know OTB is mainly based on ITK(Insight Toolkit), as ITK is used as the core element of OTB and most of OTB classes inherit from ITK classes. Moreover the software development procedure of OTB is strongly inspired from ITK’s (Extreme Programming, test-based coding, Generic Programming, documentation generation, etc.).

When  ITK moved to a new major version in 2012 it was obvious that OTB should catch up with this new version at some point.

The new ITK: prepare the next 10 years

The Insight Toolkit (ITK) is an open-source, cross-platform system that provides an extensive suite of software tools for image analysis. ITK went through a refactoring process in 2011 with major changes to software organization. The main goals of the refactoring process were:

  • Revise
  • Simplify
  • Accelerate
  • Improve DICOM support

This is a major version which improve the library in all parts:


Moreover ITK developers took into account the importance of helping people during this transition and set up lot of great tools to help people mitigate the effect of the migration (Gerrit, dynamic migration guide, starter kit,etc):


All this tools really helped the OTB team to make this transition smoother and we want to thank Insight ToolKit developers for that.

Since the first 4.0 version in late 2011, ITK went through regular releases which continuously improved the library. The project is still really active and the last stable version of ITK, with which OTB is now compatible, is the 4.5.0 released in December 2013. The ITK source code is now available on GitHub:


If you want to learn more about the power of ITK, go check the wiki which provides lots of useful resources and documentation about the project:


What’s new in OTB 4.0 ?

Compatibility with ITKv4 (a better compatibility)

As said, the main goal of this release is to make OTB compatible with the new generation of ITK, which implied changes in OTB classes. Moreover OTB was previously using an internal patched version of ITK 3.20 which would have make the migration to new version of ITK painful and uncertain. This is not the case anymore, as OTB 4.0 can be built using an external, un-patched version of ITK. While this is now the default behaviour on most systems, we maintained the internal version of ITK in OTB (CMake option OTB_USE_EXTERNAL_ITK=OFF) which allows you to compile OTB without having to install or build ITK on you own.

Clean up

We took advantage of this major change in OTB to make some code clean up. Our main objective was to reduce the number of dependencies of the library and focus on functions which make OTB a useful library for remote sensing image processing. What was done:

  • Remove PQXX dependency and related classes,
  • Remove LibLAS dependency and related classes,
  • Remove FLTK dependency in OTB and move all visualization classes related to FLTK in Monteverdi, where they are available for client code,
  • Remove GETTEXT dependency and related classes,
  • Remove codes related to ITK Insight Journal.

Why switching to OTB 4.0 ?

Because you must switch to ITKv4 :)

If you’re asking yourself why switching to ITKv4 API is a good idea, have a look to this page which list all the major new features included in this version:


Even if there are some major changes in the library, this migration should not imply a lot of modifications to OTB users as :

  • Many deprecated classes are still available,
  • Their are few changes regarding OTB API as most changes have been made inside OTB filters,
  • It does not impact OTB applications or Monteverdi.

Where to start?

We tried our best to mitigate the impact of this migration and we are sure that this new version will help to work with a larger community for OTB and make the library more useful and powerful for many different applications.

To help OTB users during this transition, we set up a page on the wiki which is a complete list of all modifications of API related to this migration:


It should help you migrate your code from OTB 3.X to OTB 4.0.

We are looking forward for your feedback. Don’t hesitate to contact us on the mailing list if you’re facing issue regarding this migration.

And now?

We are currently working on a new version of Monteverdi2 which will include a new and fast visualization framework based on the OpenGl rendering API ice.

OTB development team


OTB 3.20 and Monteverdi2 0.6 are out!

We are pleased to announce the final release of OTB 3.20, codename “… (and one more for the road)”, as well as final release of Monteverdi2 0.6!

As announced during the release candidate process, there are some exciting new stuff in this release:

  • Large scale Mean Shift: A new set of applications to run Mean-Shift segmentation on arbitrary large rasters called LSMS. LSMS is a segmentation workflow which allows to perform tile-wise segmentation of very large images with theoretical guarantees of getting identical results to those without tiling.
  • A method for Running the application from XML files. You can now save the state of all the parameters of an application in an XML file and run the application again with the same set of parameters, overriding just the one you want.
  • Support for DEM as GeoTIFF. This was a long overdue feature, asked many times on the mailing list by users : instead of only SRTM tiles in HGT format, OTB now supports elevation from any georeferenced GeoTIFF file.

Regarding Monteverdi2, there is one major novelty, the histogram widget, as well as a lot of small enhancements and bug fixes.

The new histogram widget in Monteverdi2

The new histogram widget in Monteverdi2

The complete Release Notes can be found here, and you can see that no less than 26 bugs have been fixed with respect to the RC, as well as 16 bugs on the Monteverdi2 side. Thanks again to all the contributors for the great work and to all the users for their feedbacks after the release candidate!

As usual, sources (OTB, Monteverdi, OTB-Wrapping) and binary packages (Monteverdi for Mac OS X and Windows) can be downloaded here. For Linux users, new version will be soon available for update through your favorite package manager software.

We welcome your feedback and request, and encourage you to join the OTB community and mailing list.

There are big changes coming in the next days : the team has been working very hard to migrate to ITK 4.0, and we are now ready to move on! It means that the trunk will now build with either internal (but clean of internal patches) ITK 4.x or against an external ITK 4.x all the same. You will therefore benefit from all the ITK 4.xx fixes and novelties. We tried our best to make this migration backward compatible, but for a few features this was simply not possible at all. We will provide a migration guide to help you patch your codes accordingly.

OTB Dev’Team