Slightly corrupted images when using `datashade` with bokeh backend (but not with plotly)

With the following setup:

import numpy as np
import pandas as pd
import holoviews as hv
from holoviews.operation.datashader import datashade

N = 10
x = np.linspace(0, 1000, N)
y = np.sin(x / 30)
df = pd.DataFrame(dict(x=x,y=y))

When I do:

hv.extension('bokeh')
opts = hv.opts.RGB(width=900, height=400)
img = datashade(hv.Path(df, kdims=['x','y']), width=900, height=400)
img.opts(opts)
img

I see a line with artifacts. This is some sort of bug (see below). I’ve stepped through a lot of the code in holoviews/plotting/bokeh/element and other files, for example. Unfortunately it seems too complex for me to debug. But, I’m thinking there is some bug in the downstream processing, since the output images that come directly from datashader look perfect (see below)

Any help would be much appreciated. As it is, this is unfortunately not usable quality, it is too visually distracting.

When I instead use the plotly backend but everything else the same:

hv.extension('plotly')
opts = hv.opts.RGB(width=900, height=400)
img = datashade(hv.Path(df, kdims=['x','y']), width=900, height=400)
img.opts(opts)
img

The line has no artifacts:

Finally, I can confirm that this is not an issue with datashader image generation itself. When I do:

cvs = ds.Canvas(x_range=[0, 1000], y_range=[-1,1], 
         plot_height=400, plot_width=900)
agg = cvs.line(df, 'x', 'y', agg=ds.any())
tf.shade(agg)

I see a perfectly rendered line plot:

Thanks in advance!

I can reproduce using HoloViews 1.17.0a3 and 1.17.1:

On my screen the artifacts aren’t quite as obvious, but they are still there.

Please file an issue at Issues · holoviz/holoviews · GitHub , as this looks to me like a regression; it should be re-rendering the datashader image into the final viewport at exact resolution, but my guess is that it’s not taking the space for the axes into account any more.

In the meantime, you can try line_width=3, pixel_ratio=3 to avoid getting broken lines by rendering into a higher resolution, but that’s just a workaround.

1 Like

Thanks @jbednar for taking a look! I’ve filed it here.