RGB input array limitations

[jlstevens]

Running:

x = np.linspace(0, 10, 500)
y = np.linspace(0, 10, 500)
xx, yy = np.meshgrid(x, y)
arr = np.sin(xx)*np.cos(yy)
hv.RGB(np.dstack([arr,arr,arr]))

Which is incorrect. The correct output is shown using:

x = np.linspace(0, 10, 500)
y = np.linspace(0, 10, 500)
xx, yy = np.meshgrid(x, y)
arr = (128 * (1+(np.sin(xx)*np.cos(yy)))).astype('int')
hv.RGB(np.dstack([arr+1,arr+1,arr+1]))

In other words, the data has to be in the form of integers between 1 and 255 (dimension ranges are ignored and won't work if in the same range but as floats).

[jbednar]

Hmm. I'm tempted to suggest that floats should be interpreted as being in the range 0.0 to 1.0 by default, but that could be a recipe for confusion, since "1" and "1.0" would then work so very differently. Ugh.

[philippjfr]

I'm tempted to suggest that floats should be interpreted as being in the range 0.0 to 1.0 by default

Apparently that is exactly what it does right now, since if you normalize the data it comes out right:

x = np.linspace(0, 10, 500)
y = np.linspace(0, 10, 500)
xx, yy = np.meshgrid(x, y)
arr = ((np.sin(xx)*np.cos(yy)))
arr = (arr-arr.min())
arr = arr/arr.max()
hv.RGB(np.dstack([arr, arr, arr]))

[jlstevens]

arr = 0.5+((np.sin(xx)*np.cos(yy)))/2.0

Also works but I still think it should respect dimension ranges when supplied.

[jlstevens]

I think our original intention was to use the normalization operations to handle this but now I say we discard those operations and just handle the RGB case as a plotting utility.

[philippjfr]

So our current bokeh RGB handling is definitely not quite correct, but changing it to use the dimension ranges would imo be very awkward to use. Therefore I say we make it consistent with the matplotlib backend and can then revisit what to do with dimension ranges at a later point, since it would be a significant change in behavior.