Repository: bokeh/bokeh

Issue:
Displaying custom data on hover for RGBA image
It would be nice to be possible to show some sort of information on RGBA images using Bokeh (https://stackoverflow.com/questions/54753032/hover-image-rgba-bokeh/54753614#54753614).
For instance, I'm working on a project in which we provide an RGBA image where the alpha represents some sort of confidence. We would like, when hovering an image pixel, to be able to show this confidence (in this case, the `rgba[:,:,3]` value). 


Discussion:
cc @jlstevens I don't recall what the obstacles to this were, offhand. 
For my purposes, I'd like to be able to see the full RGBA tuple, or any particular channel, or (ideally) any other column of data sharing the same shape.  E.g. if I had data that was turned into RGBA by datashader, it would be nice to hover over and see the original data value.  Currently I can do that by overlaying an invisible (alpha=0) copy of the Image, but that's awkward.  
Some random thought:

* Probably good to add some new special fields: `$red`, `$green`, `$blue` `$alpha` Obviously these would only be useful or apply to hovers of `ImageRGBA`  (or possibly also `Image`)

* I think linking to data shader or other data is possible in the same way as with `Image`? I.e. if you have another column `foo` with some other data (per-pixel) then the hover tool would drill down and display `@foo` gives you the same per-pixel hover that `Image` does. Or are you asking for something else?

* Another possible usage: coupled with `CustomJSHover` a per-pixel extra data column that had some external id, etc. could use that to query some other API to get lots of additional information per-pixel without having to dump everything in the CDS (useful obviously only if there is an API available)
- The new special fields sound reasonable to me.   Seems like @alpha could apply to any glyph?  

- The datashader support is maybe something we could do in HoloViews; we transform the dataset (which is not in the browser) into an array and then to an RGBA (which is always passed to the browser); we could maybe make the array available (optionally) as a column so that it would be available for hover.  That's related to things @jlstevens is already working on, so I'll leave that up to him.

- Yes, being easily able to query (after a delay, presumably) to find out what to display in the hover would be very useful.

@jlstevens any interest/availability to make a quick stab at this?
I'm currently working on more advanced colormapping models but I am happy to come back to this when I get a chance...

Resolving patch:
diff --git a/examples/plotting/file/image.py b/examples/plotting/file/image.py
--- a/examples/plotting/file/image.py
+++ b/examples/plotting/file/image.py
@@ -8,8 +8,8 @@
 xx, yy = np.meshgrid(x, y)
 d = np.sin(xx)*np.cos(yy)
 
-p = figure(x_range=(0, 10), y_range=(0, 10),
-           tooltips=[("x", "$x"), ("y", "$y"), ("value", "@image")])
+p = figure(tooltips=[("x", "$x"), ("y", "$y"), ("value", "@image")])
+p.x_range.range_padding = p.y_range.range_padding = 0
 
 # must give a vector of image data for image parameter
 p.image(image=[d], x=0, y=0, dw=10, dh=10, palette="Spectral11")
diff --git a/examples/plotting/file/image_rgba.py b/examples/plotting/file/image_rgba.py
--- a/examples/plotting/file/image_rgba.py
+++ b/examples/plotting/file/image_rgba.py
@@ -14,7 +14,8 @@
         view[i, j, 2] = int(j/N*255)
         view[i, j, 3] = 255
 
-p = figure(x_range=(0,10), y_range=(0,10))
+p = figure(tooltips=[("x", "$x"), ("y", "$y"), ("value", "@image")])
+p.x_range.range_padding = p.y_range.range_padding = 0
 
 # must give a vector of images
 p.image_rgba(image=[img], x=0, y=0, dw=10, dh=10)


Test patch: