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 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