Improvements to colormaps / color ranges

In light of some the recent discussions regarding colormaps, I’d like to make the following proposals (I’ll go into more detail after the list):

  1. Support “centering” a colormap around a value (e.g. 0.0)
    • Support “balanced” color range: [ -\max(|\mathrm{values}|), \max(\mathrm{values}) ]
    • A “clipped” color range: [\min(\mathrm{values}), \max(\mathrm{values})]
  2. Colormaps, in particular diverging colormaps, should “recognize” their central value as a loci for centering

Additional information

Using the proposed FAST colormap, the default coloring when you open a file / switch variables results in a white “band” at numbers that have no real importance. Consider the following example:

The white band draws attention to some value around -0.01 – not a special number at all, and also makes the positive vertical displacement appear as large as the negative vertical displacement – even though the negative displacement is ~10x larger than the positive displacement. In short, the colormap is lying to me.

Consider instead the following colormaps:

Centered, balanced

Taking the same FAST colormap, but centering it on 0.0 and then “balancing” the range to have equal negative and positive range on the colorbar. Sure, it doesn’t look as “pretty” as the other colormap, but it doesn’t completely lie to me – one could argue that the range of the colorbar might suggest a maximum positive displacement that’s incorrect. In practice I’d probably only use this with the “Data Range Labels” option.

Centered, clipped

I’ve had to “hack” this image together, but the coloring should be equivalent to the balanced colormap above. The only difference should be that now the colorbar is “clipped” to the data range. This is especially relevant for visualizing variables that are restricted to \mathbb{R}^+, such as von Mises stress, velocity/displacement magnitude, etc. No lying at all.

While I can, as a user, manually set these colorbars as soon as I change the variable I’m plotting, or go to the next timestep, I have to redo all this work all over again. What I’d like to be able to do is set some persistent option(s) that “lock” my colormap / data range to one of these approaches.

To support this, I would propose that it would make sense to add a locus to the colormap datastructure to be used as the center of the colormap. In the image below, I’ve used a \square to specify this point

One thought for maintaining the “persistency” of the data-range / colormap is to modify the Custom Range popup to something like:

image

Note that here I’ve included further examples like Positive only which here is forcing the minimum to be 0.0. Obviously a non-zero positive number would work too, so some iteration of this idea would probably be good, but I wanted to start the discussion.

Thoughts?

2 Likes

This is one approach to the more general problem of “how should ParaView help users edit colormaps with large numbers of setpoints?”

I like all the functionality you’ve discussed. However, ParaView should also provide some histogram-guided scaling tools (e.g., snapping the central color to the median or the mean as well as to zero, the min, or the max).

1 Like

I’m excited about the new FAST colormap becoming default in the next version of ParaView (5.14). However, I might make the request that, since it’s unlikely that any of the items discussed in this post would make it for 5.14, we might add FAST Positive and FAST Negative colormaps as Linear presets?

Do you mean a FAST colormap that goes from blue to red and another one that goes from red to blue? In that case, there is already an invert transfer function button image in the transfer function editor to flip any transfer function quickly.

No, I mean one that goes blue-to-white, and another that goes white-to-red.

As an example, consider the below simulation of a door lock hinge assembly. Below is a plot of equivalent plastic strain which, by definition, only contains values [0, +inf]:

I’d rather show this as a linear colormap from white->red (here using the Reds colormap, inverted):

If we had a FAST Positive or FAST Reds (and equivalent for the blues) then I can guarantee that my contour plots will look consistent between plotting values constrained to either all-negative (e.g., \Delta T in a dissipative thermal simulation with no internal heat source) or all-positive (e.g., \sigma_{\text{Mises}}), and a plot of values that are not constrained/limited to one side of the reals (e.g., \sigma_{xy} )

Here, btw, is what this looks like with FAST Reds that I created manually:

I know how to create colormaps manually (here’s a video I recorded to make the above colormap), but it’d be nice to not have to do this on every computer at my organization / every time I get a new computer / every new server / etc.

@Kenneth_Moreland – I put up a MR with my proposal for these two colormaps: https://gitlab.kitware.com/paraview/paraview/-/merge_requests/7070

I’m OK adding more colormaps to ParaView. However, I’m very strongly against adding additional maps to the defaults page, as I believe the referenced merge request does. We have been managing the defaults for a decade, trying very hard to keep the number of maps to a limited number of suggested maps. I’ll add this comment into the merge request also.

Note that I didn’t add them to the Defaults page – I mention in the MR message that I couldn’t interact with the selection dialog, so couldn’t otherwise “prove” what the colormaps look like in ParaView, so I temporarily added them (without committing) so I could take a screenshot with them.

These sound good to me. I have no problem with adding more premade color maps to ParaView, and these sound reasonable.

Verified the Fast (Reds) and Fast (Blues) colormaps in today’s nightly release:

1 Like