# Color Map Editor Reorganization
**URL:** https://discourse.paraview.org/t/color-map-editor-reorganization/9494
**Category:** Development
**Created:** [April 21, 2022, 7:54pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494 "2022-04-21T19:54:01Z")
**Posts on this page:** 16
**Page:** 1
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [April 21, 2022, 7:54pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/1 "2022-04-21T19:54:01Z")
The Color Map Editor dock in ParaView is both awesome and cluttered at the same time. We’ve all played around with the color/opacity transfer function editor to achieve flashy volume renders. This post is to discuss the organization of property groups and parameters within the editor dock.
There is a checkbox to use the separate array for the opacity transfer function. It is in the Properties Panel → Display → Volume Rendering. It would be convenient for all things related to the color map to be in the color map editor.
What bugs me most is that the ‘Enable Opacity Mapping For Surfaces’ checkbox appears twice in advanced settings.
Within the opacity function editor, it’d be nice to have a checkered background rather than a plain white background. That editor is useless when opacity mapping for surfaces is disabled and the active representation is not a volume. IMO, it should be hidden or at least disabled.
We can also move around some of the checkboxes and rename the group headers to a shorter meaningful name. For example
1. “Mapping Data” → “Transfer Functions”
2. “Color Mapping Parameters” → “Mapping Parameters”
Please mention any suggestions you have for improving the organization of color map editor here.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [April 22, 2022, 7:29am UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/2 "2022-04-22T07:29:08Z")
Nice ideas !
> [@jaswantp](#):
>
> Within the opacity function editor, it’d be nice to have a checkered background rather than a plain white background. That editor is useless when opacity mapping for surfaces is disabled and the active representation is not a volume. IMO, it should be hidden or at least disabled.
Keep in mind an histogram can be shown in the background, which can be usefull. Also, the “range” handle are easier to grab there.
---
### Author:  [@timothee.chabat](https://discourse.paraview.org/u/timothee.chabat)
#### Post date: [April 22, 2022, 8:45am UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/3 "2022-04-22T08:45:56Z")
> [@jaswantp](#):
>
> There is a checkbox to use the separate array for the opacity transfer function. It is in the Properties Panel → Display → Volume Rendering. It would be convenient for all things related to the color map to be in the color map editor.
imo it makes sense to keep this property located in the Display Properties. However we may want to improve the feedback on which array the transfer functions are attached to (maybe something like a label **Opacity Transfer Function [MyOpacityArray]** and **Color Transfer Function [MyColorArray]** positioned above each editor ?)
> [@jaswantp](#):
>
> Within the opacity function editor, it’d be nice to have a checkered background rather than a plain white background. That editor is useless when opacity mapping for surfaces is disabled and the active representation is not a volume. IMO, it should be hidden or at least disabled.
+100 for that. Though as @mwestphal mentioned we may want to display it when using the data histogram option (maybe hiding the line widget when no opacity editing is possible ?)
> [@jaswantp](#):
>
> 1. “Mapping Data” → “Transfer Functions”
> 2. “Color Mapping Parameters” → “Mapping Parameters”
+1
Some other improvements I had in mind at some point :
- Put the “Mapping Data” (or “Transfer Functions” 🙂 ) section first
- improve the display of the opacity editor when range is too small (for example when visualizing the ‘Normals’ attribute of the Sphere Source)
- It’d be nice to have an option to “zoom out” in the transfer functions editor when the ranges are not the same than the data ranges. This would allows to visualize where our custom range fits into the data range. Also in this case we could display the `Below Range Color` and `Above Range Color` when zooming out.
- Change the name of the section “Annotations” when toggling on/off the `Interpret Values As Categories` option. This section have a different interpretation according to the mode, but no feedback is given to the user.
---
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [April 22, 2022, 12:49pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/4 "2022-04-22T12:49:34Z")
@mwestphal you bring up a valid point about the histogram. In this case, what we can do is keep the range handles enabled and disable the line widget and control points. Otherwise, it gives a false impression that editing the opacity transfer function for surfaces is supposed to affect the representation.
Thanks for the cool suggestions 🙂 @timothee.chabat I’ll keep those in mind when reorganizing.
---
### Author:  [@wascott](https://discourse.paraview.org/u/wascott)
#### Post date: [April 26, 2022, 1:31am UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/5 "2022-04-26T01:31:57Z")
+1
The biggest complaint I have over the Color Map Editor is that there are two advanced buttons. I never remember which is which, thus have to turn both on to figure out what they do. Somehow, this would be nice to have cleaned up.
---
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [April 26, 2022, 1:48pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/6 "2022-04-26T13:48:41Z")
@wascott thanks for pointing that out. One is for configuring annotations on the legend and the other advanced button next to the transfer function editor is mostly to view lookup tables. I agree that is confusing!
---
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [June 13, 2022, 2:21pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/7 "2022-06-13T14:21:39Z")
Here’s a rough UI schematic of the new color map editor. Let me know what you think.
It accommodates the array names and components above the opacity (color) editor widgets. This makes it easier to configure color maps for volume rendering. Also made sure there’s only one ‘Advanced’ button.
I took some liberty in renaming the group headers to make them concise.
Edit 1: Mention that contents in green translucent box will be replaced by 2D t.f editor.
---
### Author:  [@timothee.chabat](https://discourse.paraview.org/u/timothee.chabat)
#### Post date: [June 13, 2022, 3:24pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/8 "2022-06-13T15:24:10Z")
Hey- nice design ! Here are a few thoughts :
- In interpolated mode put the color TF editor before the opacity TF editor ?
- Put the first 3 checkboxes after the last TF editor ? So that the most commonly used widgets (the color TF editor and the presets) are first
- instead of putting the 2D TF editor at the checkbox location, hide the opactiy and color TF editors and replace them with the 2D TF editor ? Like it’s currently done
- collapse the opacity TF editor when repr is not volume && Enable opacity is unchecked && histogram is unchecked ? Ideally we could even hide all opacity-related properties and change the title when the only thing we want is the histogram.
Otherwise I’m excited to see these changes integrated 🙂
---
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [June 13, 2022, 3:36pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/9 "2022-06-13T15:36:12Z")
Hi @timothee.chabat
Thanks for your input. I’ll consider them in the redesign.
> [@timothee.chabat](#):
>
> instead of putting the 2D TF editor at the checkbox location, hide the opactiy and color TF editors and replace them with the 2D TF editor ? Like it’s currently done
Sorry if that diagram wasn’t clear. This is exactly what it does! All contents in the translucent green boxes will be hidden/replaced by the 2D TF editor.
---
### Author:  [@mwestphal](https://discourse.paraview.org/u/mwestphal)
#### Post date: [June 14, 2022, 6:30am UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/10 "2022-06-14T06:30:07Z")
Looks good to me. I’d be happy to review and test this change.
---
### Author:  [@Sankhesh\_Jhaveri](https://discourse.paraview.org/u/Sankhesh_Jhaveri)
#### Post date: [June 17, 2022, 1:23pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/11 "2022-06-17T13:23:26Z")
Hi @jaswantp
Nice - this is much needed.
My 2c:
1. When the 2D transfer function is being edited, the display data histogram checkbox should not be available to the user. The 2D transfer editor enforces the need for a histogram.
2. I don’t like the idea of visually separating the opacity editor with the color editor with some checkboxes in between like below:
3. In general, the idea of hiding big areas of the UI when a certain checkbox is unchecked, reorganizes/resizes all the elements of the dialog - not the best UX :(. How about leaving some of the UI elements disabled (grayed-out) in-place. This would not cause big resizes when the user is fiddling with settings and it helps subconsciously when looking for a setting which is hidden.
4. Having the ability to change the active scalars from the color opacity editor itself is definitely nice. However, I am not sure how you’d achieve that without some complicated logic. Currently the whole editor gets replaced when the active scalars/separate opacity array/2D transfer mode changes. When the change is being propogated by the editor itself, it would be like a child widget replacing its parent widget (and in turn, itself) from the dialog. Am I overthinking this?
5. Any thoughts on an alternate toolbox for the many toolbuttons at the right hand side of the opacity editor?
---
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [June 18, 2022, 3:40pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/12 "2022-06-18T15:40:35Z")
> [@Sankhesh\_Jhaveri](#):
>
> When the 2D transfer function is being edited, the display data histogram checkbox should not be available to the user. The 2D transfer editor enforces the need for a histogram
Yep, it will be hidden.
The visual appeal of keeping the opacity and color editors together is a valid point. Although, it is convenient to separate them out to make place for the active color/opacity array combo boxes.
> In general, the idea of hiding big areas of the UI when a certain checkbox is unchecked, reorganizes/resizes all the elements of the dialog - not the best UX :(.
Right, this behavior is present in all auto-generated widgets coming from `pqProxyWidget`. For example, in the properties panel, if you check the Use 2D transfer functions checkbox, the reordering of widgets is insane. But, we do not have to worry about that for color opacity editor widget since ordering of UI elements is set in stone (it already uses a desinger .ui file). So, hiding something would not rearrange the ui elements. See the short video at the end.
> [@Sankhesh\_Jhaveri](#):
>
> However, I am not sure how you’d achieve that without some complicated logic. Currently the whole editor gets replaced when the active scalars/separate opacity array/2D transfer mode changes. When the change is being propogated by the editor itself, it would be like a child widget replacing its parent widget (and in turn, itself) from the dialog. Am I overthinking this?
There is some flexibility in how we go about doing it. This is the remaining task at the moment. For one, when swithcing from active-scalars to 2D transfer function mode, the logic is to hide some widgets and show the 2D t.f editor. As you’re aware, most of this logic is in `void pqColorOpacityEditorWidget::show2DHistogram(bool show)`. While we’re doing that, it’s possible to hide the color combo box.
> [@Sankhesh\_Jhaveri](#):
>
> Any thoughts on an alternate toolbox for the many toolbuttons at the right hand side of the opacity editor?
1. Advanced button no longer necessary.
2. Set Box color will only be visible when editing 2D transfer function.
Here’s the current status. The hiding of unused widgets seems good to me. Those disabled, yet visible checkboxes/sliders in current ParaView demand extra vertical real estate. If they’re useless in the 2D t.f context, better hide them IMO. It keeps the UI minimal.
---
### Author:  [@jaswantp](https://discourse.paraview.org/u/jaswantp)
#### Post date: [June 23, 2022, 2:54pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/13 "2022-06-23T14:54:44Z")
As @Sankhesh_Jhaveri pointed out, its not easy to place the color/opacity array combo boxes inside the color opacity editor widget. Here is a redesign that adjusts for that.
@cory.quammen thoughts?
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [June 23, 2022, 3:13pm UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/14 "2022-06-23T15:13:56Z")
Looks good to me.
---
### Author:  [@cory.quammen](https://discourse.paraview.org/u/cory.quammen)
#### Post date: [February 27, 2023, 1:45am UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/15 "2023-02-27T01:45:51Z")
Following up, this reorganization is about to be merged: [https://gitlab.kitware.com/paraview/paraview/-/merge\_requests/5794](https://gitlab.kitware.com/paraview/paraview/-/merge_requests/5794)
---
### Author:  [@DMelenberg](https://discourse.paraview.org/u/DMelenberg)
#### Post date: [May 16, 2023, 9:48am UTC](https://discourse.paraview.org/t/color-map-editor-reorganization/9494/16 "2023-05-16T09:48:02Z")
Also very desirable would be a way to rescale the editor window so that you can work very precisely in certain Value ranges. The whole range of gradient magnitude above 100 for example is obsolete in this dataset.
So you could better capture all the details that lie in certain areas.
Another thing that comes to mind would be a support for non-rectangular shapes.