Visualisation refactoring

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.
• For now, the visualisation classes derive from OpenGl windows. Pushing the previous point a little further, we could consider that a visualisation filter is a ProcessObject with images as inputs and OpenGl displays as outputs. This would mean creating DataObjects corresponding to the OpenGl windows.
• 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. => this involves also a more global reflexion on lookup table in OTB in general

• Decomposing the viewer into its element is necessary separation between the three windows, the histograms and the pixel location and value have to be respected. Some applications may need the scroll only (eg orthorectification), or the zoom... However, as quite often, the three windows are needed, it would be easier to have a ready to use component with the interaction between windows ready.
• pixel location and value may not be tight to one viewer: when several window are displayed, only one pixlocation should be displayed. It will be easier with a MVC model.
• Where to put object drawing? Are drawing polygons, lines, etc similar on the viewer and directly on an image to save? Could this be factorized?