RFCs open to vote

From OTBWiki
Jump to: navigation, search


[RFC-5] Move current Cookbook from Latex to reStructuredText (RST) format

RFC status

  • Submitted by Rashad Kanavath(CS-SI) on 30/07/2015
  • Votes pending

RFC content

OTB Cookbook is a great starting point for new users. It starts with introduction of OTB and Monteverdi followed build instructions for different platforms and contains a lot of fruitful recipes. It contains a documentation of all applications available in OTB. These resources are proven to be very helpful for users in the OTB community. Apart from these, they served as a quick start reference for new developers as well. The whole cookbook code is hosted in OTB-Documents repository and is written entirely in latex code.

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

This RFC propse to move the current cookbook from latex to rst(reStructuredText). Even though latex serves just the purpose, we think rst will be a more fit. It is an easy-to-read, what-you-see-is-what-you-get plaintext markup syntax and parser system as mentioned in their homepage. There is support for math equation inside rst which we think is all important when moving from latex. Transition from rst to latex, pdf, html and others are possible with sphinx tool.

  • Reading rst file can help understand the cookbook better than reading tex file.
  • Pages can be read directly on Github which comes with a rst rendering engine (with images), for example https://github.com/CS-SI/rstdocs/blob/master/Monteverdi.rst (good for contributors)
  • Small learning curve compared to Latex.
  • First step for a collaborative documentation via online tools for example (TODO : list some tools)
  • The html rendering is way more appealing than what provides the current latex2html
When will those changes be available (target release or date)

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

Proposed implementation is available here: https://github.com/CS-SI/rstdocs

First results is here: http://otbcb.readthedocs.org/en/latest/

[RFC-7] Better support of no data in Orfeo ToolBox

RFC status

  • Submitted by Julien Michel (01/09/2015 17:25)
  • Votes pending

RFC content

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

Currently, Orfeo ToolBox does not read, write and handle the no_data flags reported by gdal from various format (geotiff being the most obvious one). Some filters support setting this value by hand. This RFC has several components to improve this situation:

  • Read the no data flags if present, store them in the metadata dictionnary of the Image/VectorImage and write them back if possible
  • Also make NaN values to be considered as no data
  • Write filter an application that can build a no data mask from an image
  • Write filter and application that can switch the no-data value of an image
  • Support no data flag export in meta-data dictionnary fo filter producing no data values (resampling filters for instance)
  • Support no data flag in filters for which no data can affect the result (such as statistical estimation)

Open issues (no intended to be solved in this RFC):

  • No data flag handling in interpolators
  • Solution for general support of no data in all filters (may be out of reach for now)
When will those changes be available (target release or date)

These changes will be available for next release (OTB 5.2) I did some of the code, and the CS team under CNES contract is currently working on improving it. See feature branch: https://git.orfeo-toolbox.org/otb.git/shortlog/refs/heads/no_data_app

[RFC-8] Provide a regression mode for machine learning models

RFC status

  • Submitted by Guillaume Pasero (16/09/2015 14:43)
  • Votes Pending
  • Development done, need to split feature branch before vote

RFC content

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

Most of classifiers used in OTB (coming from OpenCV or LibSVM) also support a regression mode : predict a numeric output value instead of a class label. However this mode is not supported yet in OTB. The purpose of this RFC is to :

  • add regression support in machine learning models (classes deriving otb::MachineLearningModel)
  • support regression mode in existing classification filters
  • add 2 applications dedicated to regression training and prediction.
  • test regression models with arbitrary functions

During this RFC efforts will be made to factorize code between classification and regression mode so that maintenance and evolutions are easier.

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

These changes will be available for next release (OTB 5.2).

The code is developed by the CS team under CNES contract, with support from Jordi Inglada and Mathieu Fauvel.

See feature branch: https://git.orfeo-toolbox.org/otb.git/shortlog/refs/heads/regression-846

[RFC-9] Improve otb::DEMHandler interface to edit DEM-directory and Geoid-file

RFC status

  • Submitted by Stéphane ALBERT (CS-SI) on 17/09/2015
  • Development done on OTB and Monteverdi2 DEMHandler_clear feature-branches:
  1. http://git.orfeo-toolbox.org/otb.git/shortlog/refs/heads/DEMHandler_clear; and
  2. http://git.orfeo-toolbox.org/monteverdi2.git/shortlog/refs/heads/DEMHandler_clear
  • References:
  1. http://bugs.orfeo-toolbox.org/view.php?id=1070
  2. http://bugs.orfeo-toolbox.org/view.php?id=1071

RFC content

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

otb::DEMHandler is a singleton class which allow client code to the OTB library to ::OpenDEMDirectory() and/or ::OpenGeoidFile() but not to clear them, nor clear and setup again nor can it be deleted and set up again (because it is a singleton class). Currently the otb::DEMHandler can be used in programs which set it up once and run. But, higher level applications such as, for example, GUI applications and, in particular, Monteverdi2, need to set the otb::DEMHandler at initialization time and then allow the user to enable/edit the DEM-directory and Geoid-file.

When ::OpenDEMDirectory() is called, each file of the directory is loaded into the ossimElevManager as an ossimElevDatabase:

  1. Add a ::ClearDEMs() method to clear the ossimElevManager;
  2. Add a ::GetDEMCount() to return the number of ossimElevDatabases contained within the ossimElevManager so the client program can iterate through the DEMs;
  3. (optional) Rename method ::GetDEMDirectory( unsigned int ) method to GetDEM( unsigned int ).

When ::OpenGeoidFile() is called, an EGM96 Geoid-file is added once (and only once) into the ossimGeoidManager which can contain several ones but does not provide a clearing interface such as the ossimElevManager:

  1. Modifiy ::OpenGeoidFile() to return a boolean value informing whether the Geoid-file has been registered into the ossimGeoiManager (so, the client application can react to);
  2. Throw an exception when the Geoid-file has not been correctly loaded so the client program could display an error message.
When will those changes be available (target release or date)

Available on feature branch DEMHandler_clear (see http://git.orfeo-toolbox.org/otb.git/shortlog/refs/heads/DEMHandler_clear and http://git.orfeo-toolbox.org/monteverdi2.git/shortlog/refs/heads/DEMHandler_clear).

[RFC-10] Move OTB binary packages from SourceForge to GitHub

RFC status

  • Submitted by Sébastien Dinot (17/09/2015 15:15)
  • Votes Pending

RFC content

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

Early August, an OTB user has brought to our attention the following security alert:


Google had blacklisted our domain because of we were forwarding the users towards SourceForge to download few binary packages (those for MS-Windows). The hosting of binary packages by SourceForge is explained by historic reasons: at the beginning of the project, the team had at its disposal only mutualized services such SF. The habit stayed but today, we no longer need SF:

  1. We have our own servers and we self-host most of the services required by the project: we can host ourself the binary packages
  2. We can rely on the GitHub platform to provide these binary packages: https://help.github.com/articles/about-releases/

These two solutions avoid us to distribute malware within the OTB binaries. We prefer the second solution because GitHub provides a high-availability platform.

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

The first solution (self-hosting) is already used. The second solution (GitHub hosting) could be used for the next release.

[RFC-11] Build examples based on available modules in OTB installation

RFC status

  • Submitted by Rashad Kanavath(CS-SI) on 16/09/2015
  • Votes pending

RFC content

But by default, OTB sets alls OTB_USE_* cmake variable to OFF expect for 6S and SiftFast during CMake configure step. This was discussed in this otb-developer thread. This currently enforces a limit on building OTB Examples standalone or otherwise. No user can users can therefore build examples with a default OTB configuration. This RFC propose a change in Examples' CMake scripts to accept an OTB installation with current default configuration.

What changes will be made and why they will make a better Orfeo ToolBox
  • CMakeLists.txt files in Examples will be changed to check if a dependent module is loaded.
  • If an example is not build due to a dependent module not being loaded, its related test are also not build and or tested.

Open issues

  • Does not warn the user if an example is not built.
When will those changes be available (target release or date)

OTB 5.0

manits report: https://bugs.orfeo-toolbox.org/view.php?id=1065

git branch: https://git.orfeo-toolbox.org/otb.git/shortlog/refs/heads/mantis-1065

[RFC-12] CDash history cleaning

RFC status

  • Submitted by Sébastien Dinot (17/09/2015 15:55)
  • Votes Pending

RFC Content

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

Every day, the backup of the CDash database is growing up. The whole SQL dump weights 112 GB, the differential backup weights 130 MB and the backup takes more than 4h30. The availability of the whole services is affected by this operation. To another hand, we thinks that keep 8 years of history is not necessary. May be that only few months would be sufficient.

For example, Kitware has the following policy:

  • 6 months rolling history for ITK
  • 4 months rolling history for CMake
  • 4 months rolling history for VTK
  • 6 weeks rolling history for Paraview

Therefore, we propose to:

  1. Archive one time the current CDash history
  2. Remove results older than 6 months
  3. Use after a 6 months rolling history
When will those changes be available (target release or date)

As soon as the PSC give his agreement.


//REPLACE New RFC must be explained here //REPLACE