Thankyou for this. I’ll add some comments to the Python code in the VTK Examples. Much appreciated.
1 Like
Just a couple of notes on the proposed update to the default colormap.
The first goal was to get a map out for comments, which are coming in. Once we have sufficient feedback I will be going in and tweaking the specifics of the colormap. I notice several comments about the transition I the center. I agree, it is not ideal. The issue is that it becomes a trade-off between having a focal point at the center (if one uses a quick transition into more saturation) or smoothing that transition but loosing detail in that region because the lighter hues carry less information. Know we have looked at a couple dozen options and will be honing before it is final based on your comments. Thanks
Hi everyone.
As per @Francesca and @Kenneth_Moreland , we are going to tweek the Fast map slightly. This change will be in 5.12.0-RC2. We are adding two more control points, which helps smooth the transitional center, and adds nicer colors 1/4 and 3/4 down the map, at least to my eye. As per analysis tools, this map has better discriminatory power. This map also appears to have more discriminatory power for color blind folks (tested visually by me using the color-blindness.com color blind simulator, not by analysis tools).
Here is a comparison of the old and new Fast color maps:
Finally, here is the git feature request to update the map: https://gitlab.kitware.com/paraview/paraview/-/issues/22392
As a side issue, we really need a better way to manage movement of control points for all maps that have numerous control points, including our new default. @Kenneth_Moreland suggested making this a feature of the color map editor. It is written up here: https://gitlab.kitware.com/paraview/paraview/-/issues/22379.
Alan
1 Like
I’ve been using Fast as my default colormap in 5.12.0-RC#. One thing I have noticed is that the NaN color is set to black. I don’t think that is a good color for NaN as it does not make it distinct nor noticeable enough.
I’m not sure if this is intentional or the color was just left out. Cool to Warm sets the NaN color to yellow. Maybe this is not the best choice for Fast because it has some yellow in the middle. Maybe we could use a different color that is bright but distinct from the hues being used, such as magenta.
It was not intentional.
I would suggest a saturated lime green, something like RGB 0 255 0.
Francescs
Why green? In US and European culture, green is usually associated with the good or “go ahead” state. A NaN usually represents the opposite of that. Also, I expect many users will be used to colormaps where green just means middle value and won’t raise alerts.
I suggested magenta (perhaps a light version like #ff80ff). I find it a more jarring color, possibly because it has a weird hue that is not represented by a mono-wavelength light. It is also not typically used in colormaps, so users are less likely to ignore it if swapping between colors or tools.
Hmmm … I didn’t realize that NaN came with the colormap.
I would very strongly suggest yellow. That has been the NaN color for a few decades on the default Cool to Warm.
The problem with yellow is that fast also has yellow in it. It becomes less obvious the value is yellow and not the middle value. This confusion would likely be compounded if the user didn’t realize that NaN got its own color or just was not expecting NaNs.
1 Like
As long as the shade of yellow is distinct from anything that can be produced by the Fast colormap, it seems like that could work.
Magenta (as long as it was perceptually distinct from ParaView’s selection color) would also be fine. So would something orangey, as that is also associated with caution in many cultures…
The yellow in Fast is not very saturated, so it would be easy to distinguish between any of the Fast colors and the typical intense yellow (i.e. #ffff00)… if you know what to look for.
Anecdotally, I’m thinking back to a session where I was sitting with an engineer looking at detailed CFD output and noticed specks of yellow in the rendering. Even though we were using a cool-warm map with no yellow, there wasn’t supposed to be a NaNs, so I originally wrote it off as some weird color mixing. But that didn’t make sense so we looked further and found that the Gradient filter was in fact generating some NaN values. If we were using Fast, I worry I would have just wrote it off as a bright part of the surface.
1 Like
I think yellow is a good choice.
I say we go with that.
Francesca
I think this kind of oversight would be addressed by the color legend (in the render-view) including the NaN (and above and below) colors as swatches.
It certainly does contrast well. I also worry, like @Kenneth_Moreland, that it could be confusing to people used to traffic lights.
As we can’t use shades of gray (those are for above and below range), and we currently have dark blue, blue, light blue, white(ish), yellow, orange, red and dark red, I think green is a great color for NaN. It isn’t in the color map. I agree ken, Green means things to many cultures, but I think for clarity, green is the best color. We want something that will stand out. It does. Note, having to do with traffic signs, we use red and yellow without concern, even though that has meaning in traffic signs. Should we throw red and yellow out?
I think we should go with Green.
Alan
As a user, I think as long as its a garish shade of green that would be sufficiently “noisy” to me that it would stand out as something important - especially since the FAST colormap is a bit softer in its shades:
Here’s yellow:
fast_nans.pvsm (574.1 KB)
1 Like
Of the three here, I would go with the green.
A fully saturated yellow would also work.
Greg,
I don’t know what color map you are using (well, I think I do), but it isn’t fast…