Support additional color maps

[ngehlenborg]

I believe the library that we are using for color maps supports more than we have implemented at the moment. We should consider adding the full set.

[ilan-gold]

I think we already support the full range but neither of our demos were coded to use it:

https://github.com/hubmapconsortium/vitessce-image-viewer/blob/d8a0e54a2d732dab81802c9d5cc0e7e892627cc6/src/layers/XRLayer/xr-layer-fragment-colormap.webgl2.glsl#L7-L50

[keller-mark]

This paper presents "cividis" which they say is the optimal colormap for imaging mass spectrometry, accounting for color vision deficiency https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0199239 This was "generated by optimizing the viridis colormap"

A list of the 256 colors in cividis is in a supplementary file https://journals.plos.org/plosone/article/file?id=10.1371/journal.pone.0199239.s002&type=supplementary

[kylebarron]

FYI: It looks like you're hardcoding colormap values in shaders via glslify imports. It's not hard to use a texture as a colormap if you want more flexibility.

E.g.:

// Apply colormap texture given value
// Since the texture only varies in the x direction, setting v to 0.5 as a
// constant is fine
// Assumes the input range of value is -1 to 1
vec4 colormap_apply(sampler2D colormap, float value) {
  vec2 uv = vec2(0.5 * value + 0.5, 0.5);
  return texture2D(colormap, uv);
}

And then I converted all the Matplotlib colormaps to PNG files that are 256 pixels wide (doc with name mappings). So I can use any input PNG as a colormap at runtime.

[ilan-gold]

@kylebarron thanks for sharing - I noticed while working on the pre-print that this way you mentioned was more common but didn't really have hard evidence for it. I'm in favor of updating to do this, especially given the flexibility it would afford us considering what @keller-mark posted recently about a new map.

[manzt]

This would be great to implement.