Allow for multiple color scales for row_side_colors and col_side_colors

[khughitt]

Currently, data plotted as side colors all share the same color scale. This becomes problematic when data on very different scales are plotted side-by-side, e.g. age and gender. In this case, the contrast between binary or logical variables becomes very poor.

A couple possible solutions would be to either:

1. Allow the user to provide alternative color scales (one per variable plotted), or,
2. Use a separate color scale for binary/logical variables

The first approach is the most flexible, but would require a little more manual effort on the user's end.

The second one has the potential benefit of improving some plots of this nature automatically, but is much less flexible and would not resolve scale issues for numeric variables on different scales.

[alanocallaghan]

At the moment, you can manually supply a named vector of colours, and set these to be whatever you like for the different factors.

heatmaply(mtcars, 
    row_side_colors = mtcars[, c("cyl", "vs"), drop=FALSE], 
    ## colors are just gplots::bluered(5)
    row_side_palette = c("0" = "#0000FF", "1" = "#8080FF",  "4" = "#FFFFFF", "6" = "#FF8080", "8" = "#FF0000"),
    plot_method = "plotly")

The support for numeric values in side colours is "not great" in that they are automatically converted to factors (as shown above). The colour palettes then map the unique values to the supplied colour palette.

In order to support numerics, I have to refactor a lot of the code which generates the plots and stitches them together.

I am aware of these issues but it will require a bit of thought before implementing.

Thanks

[khughitt]

@alanocallaghan Thanks for the quick response and suggestions!

It would certainly be great to have improved support for numeric fields, but if it would require a significant amount of effort, as seems to be the case, then I would consider this a low priority request (unless many other users ask for the same thing).

The issue also arises in cases with all logical/factor data, whenever there is a factor field with many levels.

In the meantime, in case anyone else is facing a similar dilemma, a semi-workaround is plot all binary variables as col_side_colors and other factor variables as row_side_colors (or vice-versa), e.g.:

# "metadata" is some data.frame with one field per column
binary_vars <- sapply(metadata, function(x) { length(unique(x)) }) == 2

heatmaply(mat, 
          row_side_colors=metadata[,binary_vars],
          col_side_colors=metadata[,!binary_vars])

[alanocallaghan]

It's certainly on the to-do list. The idea I have is rather than having a single "row_side" (or "col_side") plot, we can have an arbitrary number of them, all with independent colour mapping, legend positioning, etc. I want to get the design of that process right because it could be quite unpleasant if not done well.

Anyway I will keep this issue updated if I make any progress

[fboehm]

I really like the idea of having a collection of row_side plots, each with its own colour mapping, for annotating the heatmap. I want to implement this. Can you point me to the code pieces that I would need to refactor? What are your current thoughts on the most effective designs for such a refactoring?

[alanocallaghan]

Hey @fboehm sorry for the delay in getting back to you. I've done some initial work in the multi_side_color_plot branch, principally refactoring the function plotly_side_color_plot to produce a list of plots rather than a single plot. This function handles side colors when plot_method="plotly". I think it's a little easier to work with this one case for now, and we can do similar edits for the plot_method="ggplot" equivalent later.

The most tricky bit of logic that will need changing now is stitching the plots together in here. The logic here assumes at most a 3v3 grid of plots, while in principal this change allows an arbitrary number of plots. I think the logic to handle this can be similar but I would need to sit down and think about it for a while. Feel free to poke around and make suggestions but I don't yet have any great ideas I'm afraid.

There will also be some minor edits to how arguments are handled etc but that should be much more straightforward.

[fboehm]

Thank you, @alanocallaghan! I'll check out the code that you've written and see how I might contribute. Thanks again!

[talgalili]

Are there plans to introduce this to heatmaply?
If not, can we close this issue?

[alanocallaghan]

Yeah, this is being worked on atm so don't close.