Colormap

[abkfenris]

Could be worth including default color map (or maps) for standards. cc @kthyng

[abkfenris]

Should this be a language/package mapping?

colormaps:
  python:
    matplotlib:
      - cmocean.thermal
      - matplotlib.virdis
    hvplot:
      - ...
  r:
    ggplot:
      - ...

[abkfenris]

Or might we want to make it so that the colormaps could have explanations (that are programmatically readable) as to why you might want to use one over another?

colormaps:
  python:
    matplotlib:
      - import: cmocean.thermal
        reason: A sequential colormap designed to represent temperature with cooler values transitioning to warmer ones
      - import: matplotlib.virdis
      - import: matplotlib.jet
        reason: Some folks just want to see the world burn
    hvplot:
      - ...
  r:
    ggplot:
      - ...

[abkfenris]

Chatting it through with @aallyn about how R uses colormaps, we might want to make it more generic, so that we can specify function arguments as well.

Example from Andrew:

I tend to go here (https://colorbrewer2.org/#type=sequential&scheme=BuGn&n=3) and pick some and specify with scale_color_manual or scale_fill_manual. There are also built in functions (scale_fill_viridis) that use pre-built ones

library(ggplot2)
library(viridis)
# Use built-in volcano dataset (matrix of elevations)
volcano_df <- as.data.frame(as.table(volcano))
ggplot(volcano_df, aes(Var1, Var2, fill = Freq)) +
  geom_tile() +
  scale_fill_viridis(option = "viridis") +
  coord_equal() +
  theme_minimal() +
  labs(fill = "Elevation")

viridis library

How R's cmocean calls colormaps:

library(cmocean)
plot_cm <- function(name, n=256) {
    z <- matrix(seq(0, 1, length.out=n))
    image(z, col=cmocean(name)(n), axes=FALSE)
    mtext(name, 3, adj=0)
}

struct ColorMap {
  /// string that plotting library can call, or importable function
  import: Option<String>,
  /// Why might you want to or not want to use this
  reason: Option<String>,
  /// keyword arguments to pass to imported function, or parent plotting library
  kwargs: HashMap<String, StringIntFloatBoolEnum>,
} 

[abkfenris]

Chatted some with @adamkemberling this morning about R. It got me thinking if there is a way that we could generalize some colormaps even further.

Could say https://github.com/matplotlib/cmocean/blob/main/cmocean/rgb/thermal-rgb.txt be baked into the knowledge definition (or in a separate structure that is referenced) in addition to library specific ? Then language specific bindings could convert the generic colormaps into usable structures in each language.

This might really want to be it's own Rust library and language specific bindings.

[adamkemberling]

This is my understanding of what is happening in the most general sense with the different palette libraries in R, regardless of their implementation for different plotting approaches (i.e. base R plotting, ggplot2).

1. There is some series of hex codes or RGB values stored as some object within the package which corresponds to specific and discrete color combinations for any given color palette:

Most palette packages have some sort of function that takes a string input for the name of a palette and returns color values associated with that palette.

In the viridis package they are buried inside viridis::viridis.map, its help file stating: "A data set containing the RGB values of the color maps included in the package." These are stored as a table with columns for the viridis palette option & the R, G, & B values. (Looks like cmocean does basically the same thing)

Another way to achieve the same thing, which is how we did it in the gmRi package is to manually list hex codes for each palette.

Regardless, there is a palette and some fixed set of associated color values which are in essence the skeleton of the palette. This is foundational across the board.

2. From these discrete skeletons: Either these exact values are used when plotting a few discrete values, or a continuous color ramp is generated by interpolating between these values.

In R the most common way the interpolation is done (buried in the different color palette packages) is with a function like grDevices::colorRamp() or grDevices::colorRampPalette() which come with base R.

3. These new values are connected to the data values when plotting with additional arguments like the limits and breaks of the color scale. Until this point it is 100% generic. This is where the plotting implementation diverges to match different plotting libraries.

For base R plots you pass the palette to col = viridis(n = 8), in ggplot you can pass them in directly using the more generic color gradient functions ex. scale_color_gradientn(colors = viridis(n = 8)) or scale_fill_gradientn(colors = viridis(n = 8)).

What does this mean?

All we need to achieve general purpose palettes is either:
Recreate or extract the color values associated with the palette's were choosing

OR

Point to the functions which generate these values

After that, additional arguments are for the plotting libraries and not about the color ramps.