Bokeh colorbars #861

philippjfr · 2016-09-13T23:58:24Z

Since version 0.12.2 bokeh finally support colorbars and client-side colormapping for all kinds of glyphs. This PR adds a ColorbarPlot mixin class which handles the creation of a Colorbar and a ColorMapper. Additionally it replaces the manual colormapping that was previously done in Python for various plot types. I have also moved the toolbar to the top so it does not overlap with a colorbar by default and because it is more consistent.

To Do:

Test each changed Element in more detail
Implement color_mapper range updating
Update HeatMapPlot in Make HeatMap more general #849 once this has been merged.
Add some unit tests to ensure colorbars get instantiated correctly

Examples:

Different colorbar_positions:

Log colormapping on points:

QuadMesh:

Polygons (more sensible on a Choropleth):

jbednar · 2016-09-14T01:46:17Z

Looks great!

jlstevens · 2016-09-14T13:10:27Z

I agree it looks great! The only thing that is bothering me slightly is that I would expect a black frame around the colorbars, especially if you consider colormaps ending in white (like the last two examples shown above).

philippjfr · 2016-09-14T13:11:34Z

The only thing that is bothering me slightly is that I would expect a black frame around the colorbars, especially if you consider colormaps ending in white (like the last two examples shown above).

I agree, it's a design choice the bokeh team decided on but I think enabling a black border makes sense.

jlstevens · 2016-09-14T17:19:50Z

holoviews/plotting/bokeh/element.py

-        cbar_opts = self.colorbar_specs[self.colorbar_position]
+        cbar_opts = dict(self.colorbar_specs[self.colorbar_position],
+                         bar_line_color='black', label_standoff=8,
+                         major_tick_line_color='black')


Great! Glad there is an option for this...

Allows avoiding overlap with legends, colorbars and titles

philippjfr · 2016-09-14T21:31:38Z

Ready for review.

jbednar · 2016-09-14T21:33:17Z

Are there issues on the Bokeh site already where I can go to request that there be a tiny, tiny, black outline (since colorbars starting or ending in white really are not uncommon, e.g. grayscale), and to plead to have the plot not change shape when a colorbar is added? Both of those are quite important for usability!

jbednar · 2016-09-14T21:35:47Z

Doesn't moving the toolbar to the top conflict with the title now? I thought that's why the tools moved to the right.

philippjfr · 2016-09-14T21:39:19Z

Are there issues on the Bokeh site already where I can go to request that there be a tiny, tiny, black outline (since colorbars starting or ending in white really are not uncommon, e.g. grayscale)

I've added black outlines by default in holoviews.

and to plead to have the plot not change shape when a colorbar is added?

No way to do this although I could approximate the percentage of the width of the colorbar and offset, not sure I want to go down that route though.

Doesn't moving the toolbar to the top conflict with the title now? I thought that's why the tools moved to the right.

Yes, sorry should have updated my description, the toolbar location is now configurable with the toolbar plot option which accepts ['above', 'below', 'left', 'right', None]. Should I change above and below to top and bottom for consistency?

jlstevens · 2016-09-14T21:40:41Z

holoviews/plotting/bokeh/element.py

+
+    def _get_colormapper(self, dim, element, ranges, style):
+        low, high = ranges.get(dim.name)
+        palette = mplcmap_to_palette(style.pop('cmap', 'viridis'))


Not sure I am happy about hard coding 'viridis' as a default, especially as it is a matplotlib colormap (unless bokeh now has viridis?).

Bokeh does now have viridis.

Matplotlib has hardcoded defaults, which is viridis now and bokeh does have viridis now as well.

Personally, I like that viridis is perceptually uniform, but I don't actually like it overall, because it has no intuitive ordering. Hot is clearly ordered in a way that people can appreciate at first glance, as are cool colormaps (black->blue->white), but viridis just has to be memorized. In that sense it's as bad as jet (but only that sense).

Plus that would be a (very slight) change to the current defaults. Probably few people besides me could tell the difference, though.

And we would have to come up with a name for it! :-)

Definitely good suggestions though and something we should consider doing for 1.7.

Mpl's hot definitely has regions where it plateaus and conveys little information about changes in value:

It looks good to me up until it turns yellow, then it's got a huge yellow stretch with little change as intensity varies. It wouldn't be hard to do a better job, and I'd be happy to do that.

Looks like mpl's hot came from matlab originally? http://ab-initio.mit.edu/wiki/index.php/Color_tables_in_h5topng

And we would have to come up with a name for it!

Mpl has hot, afmhot, and gist_heat, so ours could be hhot. :-)

jlstevens · 2016-09-14T21:42:48Z

holoviews/plotting/bokeh/element.py

+                                            "left", "right", None],
+                                   doc="""
+        The toolbar location, must be one of 'above', 'below',
+        'left', 'right', None.""")


I assume None can be a sensible choice even if the user has added tools (e.g to temporarily hide the toolbar). Otherwise, adding tools with toolbar=None could issue a warning...

It's just a convenient way to disable the toolbar altogether. I could either disable it, or warn tools or warn for tools and default_tools.

I think being able to disable the toolbar without issuing warnings could be convenient so I am happy to leave it as it is.

jbednar · 2016-09-14T21:45:06Z

above and below could be top and bottom; sure.

jlstevens · 2016-09-14T21:45:47Z

holoviews/plotting/bokeh/chart.py

+            mapper = self._get_colormapper(cdim, element, ranges, style)
+            data[cdim.name] = [] if empty else element.dimension_values(cdim)
+            mapping['color'] = {'field': cdim.name,
+                                'transform': mapper}



Looks much cleaner!

jlstevens · 2016-09-14T21:46:38Z

holoviews/plotting/bokeh/chart.py

@@ -128,6 +119,8 @@ def _init_glyph(self, plot, mapping, properties):
        else:
            plot_method = self._plot_methods.get('batched' if self.batched else 'single')
            renderer = getattr(plot, plot_method)(**dict(properties, **mapping))
+        if self.colorbar and 'color_mapper' in self.handles:
+            self._draw_colorbar(plot, self.handles['color_mapper'])
        return renderer, renderer.glyph


When could you request a colorbar but not have a color_mapper available?

They might have enabled colorbar by default but not set a color_index.

Ok, makes sense, thanks.

jlstevens · 2016-09-14T21:49:51Z

holoviews/plotting/bokeh/element.py

+        cmapper = colormapper(palette, low=low, high=high)
+        if 'color_mapper' not in self.handles:
+            self.handles['color_mapper'] = cmapper
+        return cmapper


I can see the logic of returning cmapper but this function could also just be called for the side-effect of adding 'color_mapper' to the handles. I had to check the code here to make sure it is indeed the same thing...

Yes, there's some annoyances I have with this, ideally the handles would be set elsewhere but since it is now called from get_data, which is the main method the user has to implement and is duplicated everywhere I didn't want to move it out. The other thing is only the first colormapper that's created is actually used while the rest are simply used to update the existing colormapper. I'll leave it up to you if you think I should find a cleaner solution otherwise I'll make sure to leave a comment.

jlstevens · 2016-09-14T21:52:23Z

holoviews/plotting/bokeh/raster.py

                    'widths': ws.flat, 'heights': hs.flat}

-        return (data, {'x': x, 'y': y, 'fill_color': 'color',
+        return (data, {'x': x, 'y': y,
+                       'fill_color': {'field': z, 'transform': cmapper},
                       'height': 'heights', 'width': 'widths'})


Here you call it cmapper but in other places you sometimes call it mapper. I would prefer to use the former consistently....

jlstevens · 2016-09-14T21:59:22Z

holoviews/plotting/bokeh/element.py

+            return
+
+        opts = dict(cbar_opts['opts'], bar_line_color='black',
+                    label_standoff=8, major_tick_line_color='black')


I wouldn't necessarily make these parameters but maybe they could be specified as a dictionary in the class attributes. Alternatively, you could just make them into the default for colorbar_opts which might make more sense...

When you add them to the colorbar_opts they all get overridden when the user supplies new options and bar_line_color='black' just looks silly without major_tick_line_color='black', so I wanted them to behave like defaults. Happy to make them into a class attribute though.

A class attribute would be good in that case.

jlstevens · 2016-09-14T22:03:04Z

holoviews/plotting/bokeh/raster.py

-            self.handles['color_mapper'] = cmap
+        val_dim = [d for d in element.vdims][0]
+        properties['color_mapper'] = self._get_colormapper(val_dim, element, ranges,
+                                                           properties)
        return properties


I'm just wondering why in this case self._get_colormapper is used to add the color mapper to the properties (in _glyph_properties) but is added to the data in get_data everywhere else...

The image glyph accepts a colormapper directly while in other cases it is used as a transform that maps color to a particular column.

Thanks for the explanation!

jlstevens · 2016-09-14T23:02:26Z

Tests are passing and I understand this PR is complete. Merging.

jbednar · 2016-09-19T15:37:14Z

The colorbars above are squishing the plots when they are added, which is an issue I just filed for bokeh: bokeh/bokeh#5186

philippjfr added 8 commits September 14, 2016 00:33

Implemented ColorbarPlot and LegendPlot baseclasses in bokeh

72ca81b

Added client side colormapping for PointPlot

14048bd

Added client side colormapping for SideHistogramPlot

3e383f8

Added client side colormapping for PolygonPlot

883e185

Added colorbars for RasterPlot

ac35b2f

Added client-side colormapping for QuadMeshPlot

da511ff

Added client side colormapping for SpikesPlot

59b9473

Moved toolbar on top to avoid clashes with colorbar

84a0dc4

philippjfr added type: feature A major new feature tag: backend: bokeh tag: component: plotting status: WIP in progress labels Sep 13, 2016

philippjfr added 3 commits September 14, 2016 17:37

Added client side colormapping for HeatmapPlot

dee556f

Handled updating of colormapping ranges

f2884e1

Added colorbar border by default

8f00b04

jlstevens reviewed Sep 14, 2016
View reviewed changes

philippjfr added 5 commits September 14, 2016 18:52

Made toolbar position customizable

af0b2dd

Allows avoiding overlap with legends, colorbars and titles

Cleaned up ColorbarPlot and added docstring

122a3ba

Defined default colormap

b219c23

Added colormapping unit tests

8a83577

Added colormapper to update handles of ColorbarPlot

65c0d21

philippjfr removed the status: WIP label Sep 14, 2016

jlstevens reviewed Sep 14, 2016

View reviewed changes

Fixed setting of colorbar border

c211f2a

jlstevens reviewed Sep 14, 2016

View reviewed changes

philippjfr added 4 commits September 14, 2016 23:31

Allowed updating the colormapper palette

f520bff

Made colorbar defaults a class attribute

c35d6b2

Renamed mapper to cmapper

80899e6

Added comment about colormapper instances

9e2f1b6

jlstevens merged commit 96be6a7 into master Sep 14, 2016

jlstevens removed the in progress label Sep 14, 2016

jbednar deleted the bokeh_colorbars branch September 15, 2016 00:46

Bokeh colorbars #861

Bokeh colorbars #861

Conversation

philippjfr commented Sep 13, 2016 • edited by jlstevens Loading

jbednar commented Sep 14, 2016

jlstevens commented Sep 14, 2016

philippjfr commented Sep 14, 2016

Choose a reason for hiding this comment

philippjfr commented Sep 14, 2016

jbednar commented Sep 14, 2016

jbednar commented Sep 14, 2016

philippjfr commented Sep 14, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbednar Sep 14, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jbednar commented Sep 14, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jlstevens Sep 14, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jlstevens commented Sep 14, 2016

jbednar commented Sep 19, 2016

philippjfr commented Sep 13, 2016 •

edited by jlstevens

Loading

jbednar Sep 14, 2016 •

edited

Loading

jlstevens Sep 14, 2016 •

edited

Loading