Monteverdi

From OTBWiki
Jump to: navigation, search

The goal is to develop a friendly interface and easy to use for non-specialists. The list of basic features is as follows:

  1. Import raster and vector formats / optical and radar
  2. Display of raster and vector layers and basic functionality associated with it: dynamic adjustment, color composition, navigation tools: zoom, filters
  3. Tools for displaying radar and radar-based filters (speckle)
  4. Classification
  5. Management of common map projections and on the fly re-projection of imported data
  6. Registration: image / photo, image / map, optical / radar
  7. Registration using external data (OpenStreetMap, GPS points, etc..)
  8. Export of corrected data

Would also be desirable:

  1. basic spatial analysis (simple queries)
  2. digitization of polygons on screen;
  3. Link with Landsat, C-BERS, SRTM catalogs and other free data for easy import.

The interface should be scalable and allow the addition of new features. An interface with a free GIS like QGIS would be useful. Documentation is also required. The software should allow easy translation of the interface (internationalization). An interface with GoogleEarth OpenStreetMap (or other media) could be interesting.

Todo list

Modules features

  1. Complex data reading including modulus and phase (in Reader module)
  2. Image display dynamic adjustment (in Viewer Module)
  3. Complex intensity and log-intensity (in SAR Module)
  4. Map reprojection module (in MapProjection module)
  5. Homologous points and co-registration module (in HomologousPointExtractionModule)
  6. Caching, including behind the scene caching (in Caching module)
  7. Minor refactoring of supervised classification module (in SupervisedClassificationModule)

Global features

  1. Proper data naming in the main interface
  2. Validation of each module (including GUI consistency)
  3. Testing for each modules and for the main application
  4. Threading

More

  1. Orthorectif module should accept image (I mean otb::Image) as well
  2. Forbid to plug two threaded task to the same pipeline branch
  3. Problem with Supervised Classification : closing the scroll view also remove the image into the full view
  4. Help menu is empty
  5. The other writing module (MVC) should be threaded as well
  6. The quicklook generation from the viewer module should be threaded (and cached ?)
  7. A module for automatic superimposition of two arbitrary images would be nice
  8. It would be nice to have the same band-decomposition for other outputs than reader module
  9. A split module to convert otb::VectorImage to a set of otb::Image would be nice (could help solving 1 and 8)
  10. A concatenate module to convert several otb::Image to an otb::VectorImage would be nice (could help solving 1 and 8)

Open specifications

  1. Even if at first we will not implement a plugin system, each feature should be implemented with a standard interface and be as independant as possible from the main application. Therefore, we need to model carrefully data and processing chains.
  2. From this point of view, the Monteverdi application can be seen as an application managing processing chains:
    1. The user can create a new chain of some type (orthorectification, classification),
    2. The user can select data from the output of existing chains to as the input to a new chain (including reading chains),
    3. The user can manage the list of existing chains and visualize (or write to disk) the outputs of each chain.
    4. A chain should warn/alert the user if he did not select suitable data as input (ie: a classification chain expect a labeled image, and the user did provide a double precision image),


Look & feel

A possible look & feel for this application is the following:

  1. A menubar with the standard *file* menu (import and export data), plus processing menus (Classification, Geometry, Registration),
  2. On the left, a list of open chains: reading chains, orthorectification chains, classification chains ... Each chain can be expanded to see which output data it produces.
  3. The remaining of the apps is a workspace containing subwindows (subwindows can be detached from the main window):
    1. Viewer subwindows,
    2. Processing chains setup windows,
    3. Tools windows.

Packages

Simple installers will be provided. CPack will be used as much as possible. The following platforms will be dealt with:

  1. Windows XP
  2. Mac OS X (Intel only)
  3. Linux "deb" (i386 and amd64)
    1. Debian Lenny
    2. Debian testing
    3. Ubuntu 9.04

Note: for clean deb packages, a separate package should contain the otb library (libotb) and most dependencies should be configured as external (including gdal).

Live CD

A Monteverdi Live CD is planned. It will contain the Monteverdi application and at least QGIS and eventually other remote sensing applications.

Emmanuel: Develop our own or include Monteverdi on the GIS live DVD ? http://www.arramagong.com/Arramagong/home.html

Improve the Monteverdi architecture

Remarks, suggestions, todo list to improve the architecture in Monteverdi (Module Class).

Polymorphism in the Module class

Problem

The writer module has 2 entries in its Input map (inputimagedataset and inputvectordataset). Could be better to have one entry InputDataSet in the map with multiple types. Possible solutions : The input map needs to accept multiple types for input (or output).

Solution

The InputDataDescriptor is now allowed to have multiple supported types. The DataType field can contain 1 or more type key separated by the ',' character. A IsTypeCompatible(const std::string&) const method has been provided in order to check easily types compatibility.

The module base class has now a new method AddTypeToInputDescriptor<typename T>(const std::string & key) allowing to add more supported types to a single input.

The writer module has been impacted by this evolution and has now a single input supporting multiple types.

Store the input type in the Module class

It is not possible to know during callbacks of the GUI which input was instantiate during the assignInputdataKey().

Example in the writer module: in the AssignInputByKey we instantiate the image file writer (m_FPVWriter) for example.After that during the callback function "OpenDataSet", we do not have the information on which Writer filter we need to instantiate...

  • Store a list of "input parameters type", store a list of pointers to datawrappers?Do this in the Module Class or in class which inherate from it?Problem with multiple inputs/outputs?

Pipeline Persistence

For now it is not possible to know which and how modules are plugged together. This would be a valuable information for pipeline rendering for instance. The DataWrapper class may be extended with the source module information.

How to ensure data and datatype string coherence

Problem

For now, data types are identify with strings like "Floating_Point_VectorImage". It is up to each module to know what is the OTB type (including template parameters) corresponding to this type. This may cause problems:

  1. Modules may not call the same way the same type of data
  2. Modules may call the same way different types of data

One solution would be to use the RTTI information. But this seems to work only with recent gcc, and we do not now how it will behave in other environements.

We should at least provide to module developpers a header (like otbMonteverdiCommonTypes.h) defining each type (with typedef) and associating a type name.

Solution

A new class called the TypeManager is now responsible for registering and providing type names at an application-wise level (using the Singleton pattern). Type name are registered in a map using

typeid(T).name()

as the key.

Modules are not allowed to name type themselves anymore. They automatically request the name of the type to the TypeManager. Some methods which were previously taking the type name as an argument now accept the type as a template parameter.

Improve the Monteverdi GUI

Input Dataset window

The input window is not resizable...

The Viewer

  • Color composition
  • Ajust the dynamic
  • View multiple vector layer

Feedback

  1. What does "Data Set" mean when we open the application. One is already open? Solution: display the number of data set available.
  2. Visu is a basic appli -> in the left menu (or fle menu).
  3. Click & drop for input image selection is the first reflex.
  4. A little window still open when the application is closed.
  5. Contextual menu.
  6. Set the image size in the viewer.
  7. When close the visu window, should close the setup one too (cf. Otmane answer).
  8. Strange characters in type for classified image" (cf Manu's mail).
  9. For the instanciation when you chose the input, we also also do: Instance label near the input text area (instead of the label) and the label below.

Stephane FeedBacks

  1. Internationalisation : Monteverdi dispo en français (menu dynamique en français)
  2. Viewer: l'IHM permettant de modifier l'histogramme dynamiquement n'est pas fonctionnel dans le cas d'image panchromatique
  3. Viewer: Bug IHM sur l'onglet Pixel description (à confirmer) ==> Not a bug :
  4. SVM: le bouton validation n'est jamais activé. C'est normal? ==> OUI , boutons exclusif
  5. ENH: Avoir un Extract ROI ou on saisie des lat/long et pas des coordonnées pixel
  6. ENH: pouvoir faire un zoom simple sur une image ( *n)
  7. Pan Sharpening: est-ce que les 2 images doivent être de même taille?
  8. reprojected: entrée image fixe panchro; moving image: XS 4 fois plus petite
  9. Viewer: multiple image in the same viewer
  10. KMeans: pouvoir exporter l'image de label
  11. Change detection: le bouton display n'affiche rien et le erase last point ne fonctionne pas quand l'utilisateur dessine un polygone croisé (à confirmer : CONFIRME)
  12. Feature Extraction: bug affichage Feature Extraction qd on selectionne un sous menu NDVI, on ne peut pas ajouter ensuite un filtre de niveau supérieur dans l'arborescence
  13. SVM: be able to open result vector datas.


Roadmap to Monteverdi Beta

  1. crash of the change detection module

...