RFCs implemented in OTB 5.0

From OTBWiki
Revision as of 08:48, 11 September 2015 by Julien (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

[RFC-1] Remove our internal patched version of libSVM and the classes using the modified libSVM API

RFC status

  • Submitted by Julien Michel (18/03/2015 13:04)
  • Accepted by PSC +3 / 0 (19/03/2015 14:13)
  • Merged in Orfeo ToolBox 4.4.5 (23/03/2015 15:24)

RFC content

What changes will be made and why they will make a better Orfeo ToolBox

For now we have an internal version of libSVM, which is patched to add the generic kernel capability, and add a few more functions (to clone a SVM model struct for instance).

However :

  • The generic kernel capability is not widely used (for instance it is not reported in classification applications), and its code is not very clean (doubtful operations on memory allocation with LibSVM struct ...)
  • The patches prevent us to follow new libSVM releases and benefit from libSVM packages on target systems,
  • For OTB 5.0, we now have a policy of "as few embedded third party as possible" and the generic kernel patches are the only reason why we can not use an external libSVM.

I therefore propose :

  • To remove completely the internal LibSVM version in Modules/ThirdParty/LibSVM and to do a plain cmake find_package() instead,
  • To remove all code and tests relying on the patched libSVM API. This means generic kernel classes and a few calls in SVMModel that need to be reworked,
  • To create a remote module on a git repository containing the patched libSVM and the removed classes and tests, so that they will still be available if really needed by someone.
When will those changes be available (target release or date)

These changes will be available for next release (OTB 5.0)

[RFC-2] Edison : remove our internal version

RFC status

  • Submitted by Guillaume Pasero (24/03/2015 15:53)
  • Accepted by PSC +3 / 0 (07/04/2015 10:44)
  • Merged in Orfeo ToolBox 4.4.5 (16/04/2015 16:50)

RFC content

What changes will be made and why they will make a better Orfeo ToolBox

Edison is the original mean-shift implementation in OTB. It doesn't support streaming by itself, and it is now redundant with a pure OTB large scale mean-shift implementation. A first step has been made to cut mandatory dependencies to Edison (here). The next one is to remove this third party from sources.

The following actions are foreseen:

  • Remove modules 'Edison' and 'EdisonMeanShift'
  • Remove deprecated code in other modules to use Edison
  • Replace in Monteverdi1 the features using Edison (in some cases they may be removed)
When will those changes be available (target release or date)

These changes will be available for next release (OTB 5.0)

Who will be developing the proposed changes

An OTB developer (CS team) familiar with this issue. There is an associated task on Jira (OTB-776).

[RFC-3] OpenJPEG : remove internal version

RFC status

  • Submitted by Guillaume Pasero (25/03/2015 10:06)
  • Accepted by PSC +3 / 0 (08/04/2015 16:22)
  • Merged in OTB 4.5.0

RFC content

What changes will be made and why they will make a better Orfeo ToolBox

OpenJPEG is used in OTB to read jpeg2000 images. It is integrated in a specific otb::ImageIO. Originally, a non official release of OpenJPEG has been used and is compiled inside OTB. These sources are planned to be removed from OTB. Instead, an external OpenJPEG (last official release) will be used, using a 2.0 API. The following actions are foreseen:

  • remove OpenJPEG sources from 'Modules/ThirdParty/OpenJPEG', use a find_package() instead
  • refactor otb::JPEG2000ImageIO to support the new API of OpenJPEG

Note : the driver otb::JPEG2000ImageIO is used when GDAL doesn't have a compatible JPEG2000 driver. If GDAL is built with a compatible JPEG2000 driver (OpenJPEG, Kakadu, ...), OTB will read J2K images using the otb::GDALImageIO driver.

When will those changes be available (target release or date)

These changes will be available for next release (OTB 5.0)

Who will be developing the proposed changes

An OTB developer (CS team) familiar with this issue. Mickael Savinaud has done some work on the refactoring. There is an associated task on Jira (OTB-778).


[RFC-4] Start release process for OTB 5.0.0

RFC status

  • Submitted by Manuel Grizonnet (21/05/2015 11:38)
  • Accepted by PSC +3 / 0 (21/05/2015 12:16)
  • Release process completed (01/06/2015)

RFC content

What changes will be made and why they will make a better Orfeo ToolBox

For a few months now we have been working on big changes for OTB (modularization and superbuild, third party ). I propose today to start the release process and prepare an OTB 5.0.0 release candidate for review and test.

I've initiated a new "How to release" todo list on the wiki for otbv5 :

http://wiki.orfeo-toolbox.org/index.php/How_to_Release_OTB_5

When will those changes be available (target release or date)

I propose to start the release process for the release candidate today and continue the release process next week.

Who will be developing the proposed changes

I propose to coordinate those activities.