Colormaps and widgets vs pipeline sources

[dcthomp (David Thompson)]

Hi all,

I’m working on a custom 3-D widget and don’t understand how to make it display data using a colormap that PV users can edit.

1. The interactive widget inherits pqInteractivePropertyWidget and has proxy that owns a vtkWidgetRepresentation. Is there a way for it to use (and allow users to edit) a colormap? It appears that only pqPipelineSource objects are expected to have a pqDataRepresentation and that is the only place I see lookup tables being set.

2. Is there a way to fetch a colormap from the pqColorMapEditor instance? It doesn’t look like the editor panel provides a way to examine colormaps, so I don’t see a way for the widget to either request a lookup table from the panel nor ask the panel to present a colormap to users for editing. Is the only solution to have my widget create a pqPipelineSource and representation so the colormap editor can run?

[utkarsh.ayachit (Utkarsh Ayachit (Kitware))]

I am not entire sure I follow what you’re asking but here are a few things to note:

(I am assuming by color map you mean a proxy for color transfer function. The following assumes that.)

*pqColorMapEditor is simply a “view”. It should the active representations color map. Hence it’s not the place to go looking for color maps.

• ParaView keeps color maps associated with array names. vtkSMTransferFunctionManager may by used to get existing color maps or create new ones.
• You can always create your own color map proxy and pass it to the VTK object / proxy of interest. There’s nothing that prohibits you from doing that.

[dcthomp (David Thompson)]

Thanks @utkarsh.ayachit . That helps, but the pqColorMapEditor view seems to only show transfer functions for active representations (i.e., pqDataRepresentation subclasses), but interactive widgets cannot ever be an active representation as I understand it. Would you

1. Add methods to the existing view so widgets can ask it to display/edit their transfer function? This might be problematic because the control to switch to a widget’s colormap could feel hidden to users (it would be a button in the property panel, not something in the toolbar or colormap editor panel).
2. Copy the pqColorMapEditor view logic into a Qt widget in the property-panel? This is problematic because it duplicates code and user interface.
3. Have the widget create & manage a pqPipelineSource that can have a pqDataRepresenction and thus allow use of the existing colormap panel? That might be problematic because when a widget is active, the active pipeline object is unset (so the colormap editor panel resets itself).
4. Something else?

[utkarsh.ayachit (Utkarsh Ayachit (Kitware))]

pqColorMapEditor is intended to be a dock panel – specifically designed to handle active color map. It internally simply uses pqProxyWidget for the LUT proxy. So you can create your own pqProxyWidget for the appropriate LUT proxy. Take a look at the code in pqColorMapEditor…it’s primarily just plumbing things together for the purpose it’s designed for. You can similarly do the appropriate plumbing in your custom QWidget (or whatever) subclass.

[dcthomp (David Thompson)]

@utkarsh.ayachit Thanks! I am able to get by using the existing panel by having users switch SMTK’s representation to use the scalar array whose transfer function they want to edit and using the vtkSMTransferFunctionManager to configure the widget with the proper transfer function.