Request for Comments-33: Rethink Monteverdi's layer stack

From OTBWiki
Jump to: navigation, search

Status

  • Author: Victor Poughon
  • Submitted on 20.06.2016
  • Open for comments

Content

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

In my experience with Monteverdi so far (both learning and teaching it) the most confusing aspect of it has been the layer stack.

From what I understand, the layer stack has three different concepts for the "current image":

  1. The image highlighted with a light blue rectangle (or light gray if the layer stack is not in focus): The layer stack buttons and "effect" drop down menu will apply to this image, color dynamics, etc.)
  2. The reference image: This is the image whose geometry is used as the reference for projecting other images
  3. The image on top of the stack. This is the image currently visible in the main image view
  • This leads to user confusion. In particular, setting the effect has no immediate visual feedback.
  • Each layer can have it own effect. But looking at available effects they all apply to either one or two image, never more. What's the point of having an effect assigned to a hidden image?
  • The layer stack buttons are a bit cryptic. Which does what? It's hard to tell without hovering and waiting for the tool-tip.

To address those issues, I propose the following changes.

A single layer effect

Remove each layer's effect, and replace with a single, application wide effect which always applies the top image, or the (top ; second-from-top) pair if it's a binary operator.

With a single effect:

  • Using the effect drop down menu gives immediate visual feedback
  • Rotating the stack is more useful because it would also rotate through pairs of images when an effect is selected
  • More horizontal space in the widget
Drag and drop in layer stack

Allow to drag and drop layer stack items to change their order.

Replace layer stack buttons with a contextual menu

Remove all layer stack buttons and move them to a contextual (i.e. right click) menu, except for maybe apply color dynamics parameters which could go in the dynamic color settings widget (this saves vertical space in widget)

  • Use as reference projection
  • Move (sub-items: top, up, down and bottom)
  • Delete (sub-items: this layer, all layers except this one, all layers)

Also allow drag and drop to re-order the layer stack items.

This makes the items functions explicit and saves vertical space in the widget.

Remove pixel peaking

Remove the pixel peaking feature entirely from the layer stack. Pixel values and coordinates are already visible in the status bar so it is redundant. Additionally, it can be added later in a dedicated "spectral profile" widget, which will also handle more (draw a graph of the spectral profile, etc.)

This has a number of advantages:

  • Fixes bug 1228
  • Saves horizontal space in the widget
  • It scales to multi spectral and complex data
Swap Ctrl and Ctrl+scroll wheel shortcuts

Currently, using the scroll wheel changes the order of layers, but confusingly does not change the selected image! So if trying to use an effect didn't work before, it still won't work! Additionally, rotating the layer stack is a much less common operation than zooming. In my opinion, this is a much needed change. It will follow QGIS convention, and most users intuition that zooming is done with the scroll wheel.

Better default widget layout

Monteverdi's default layout of widgets is poorly suited to small screens (laptop for example). With the above changes, the layer stack is left with only three columns. The new default layout could put the layer stack in a vertical stack with the rest, to enable using most of the window's vertical space for the main image view.

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

Those changes can be available for release x.y.

Who will be developing the proposed changes?

Community

Comments

Interesting feedback on mantis: https://bugs.orfeo-toolbox.org/view.php?id=1229


Support

List here community members that support this RFComments.

Corresponding Requests for Changes

List here links to corresponding Requests for Changes if any.