Difference between revisions of "Visualisation refactoring"

From OTBWiki
Jump to: navigation, search
 
Line 2: Line 2:
  
 
* '''Visualisation classes should act like other filters:''' First plug the inputs and tune some parameters, and then do a single call to the Update() methods. Changing the input or parameters and calling Update() again should update everything without any restriction.
 
* '''Visualisation classes should act like other filters:''' First plug the inputs and tune some parameters, and then do a single call to the Update() methods. Changing the input or parameters and calling Update() again should update everything without any restriction.
 +
* '''Normalization should be done using already existing OTB filters''' within some internal or external pipeline.
 +
* '''Quicklook generation should be done using already existing OTB filters''' within some internal or external pipeline.
 +
* '''It should be possible to display overlays (images and vector data) through a lookup table.'''

Revision as of 11:47, 3 December 2008

This page is intended to define the behaviour and features that the refactored visualisation classes should handle. Items are listed without any priority assesment.

  • Visualisation classes should act like other filters: First plug the inputs and tune some parameters, and then do a single call to the Update() methods. Changing the input or parameters and calling Update() again should update everything without any restriction.
  • Normalization should be done using already existing OTB filters within some internal or external pipeline.
  • Quicklook generation should be done using already existing OTB filters within some internal or external pipeline.
  • It should be possible to display overlays (images and vector data) through a lookup table.