Difference between revisions of "Visualisation refactoring"
From OTBWiki
| 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.
