Bokeh server: dynamically determine static/ location from which to serve images (etc)

Hello,

We’re building an image viewer/browser with Bokeh server. Currently, when a user selects one or more points in a scatter plot, using a Python callback:

• the corresponding images are loaded into NumPy arrays from the file paths

• then these are displayed in a separate canvas using image_rgb

This turns out to not be super-performant, and I thought it’s probably wasteful to decompress on the server. I don’t know what Bokeh is doing in the background but I imagine either re-compressing to transfer to the browser, or transferring the uncompressed data. Either of these approaches is pretty wasteful, so I presume that image_url would be faster. I’ve read the previous post on the topic [1] where Bryan posted some very specific advice about how to structure the app directory:

• make a “directory” style app

• make a “static” subdirectoy in the app directory

• put all your pngs, etc in the “static” subdirectoy

• then anything in the static directory is available at the relative
  URL “myappname/static” (substitute whatever your actual app name is for
  “myappname”)

And, further dashing my hopes and dreams:

Just to be clear, it’s never going to be possible to load files from
arbitrary filesystem locations like “C:/foo/bar.png”, only from the application-specific “static” directory.

Now, please correct my logic if I’m wrong, but I presume that there is an asterisk to the above statement: Bokeh must somehow be serving up that directory, and it should be possible to make it serve some other arbitrary directory (tree), rather than one specifically named “static” in a specific part of the filesystem. So I have two questions:

1. How is Bokeh serving up the static directory? Can you point me to the right part of the Bokeh codebase? We are calling the Bokeh server manually [2], so we need to figure this out anyway, even if serving from static/.

2. Alternatively, is there a more effective way to send the jpg from the server to the “Image” object, rather than decompressing on the server?

Thanks,

Juan.

… [1] Redirecting to Google Groups

… [2] https://github.com/microscopium/microscopium/blob/0236e53fc0e8eaf10b0dd5f33d14fa6d1ce002fe/microscopium/bokeh_app.py#L184-L191

Hi,

Top level static routes (i.e. that serve BokehJS) are configured here:

  https://github.com/bokeh/bokeh/blob/master/bokeh/server/urls.py

Per-app static routes are configured here, based on app.static_path (if present):

  https://github.com/bokeh/bokeh/blob/master/bokeh/server/tornado.py#L253-L260

Bokeh is a Tornado application, and those are all Tornado views. If you run the Bokeh server programmatically you can certainly add any additional Tornado view you need, including additional StaticHandler instances.

FWIW I am interested in Image glyphs that could send PNGs/JPGs to the client as-is, without needing to first convert them to RGBA arrays. I don't know when we might have the resources to do that, but I am happy to offer guidance to anyone that would like to work on it sooner.

Thanks,

Bryan

Hi Bryan!

Top level static routes (i.e. that serve BokehJS) are configured here:

  https://github.com/bokeh/bokeh/blob/master/bokeh/server/urls.py

Per-app static routes are configured here, based on app.static_path (if
present):

  https://github.com/bokeh/bokeh/blob/master/bokeh/server/tornado.py#L253-L260

Bokeh is a Tornado application, and those are all Tornado views. If you
run the Bokeh server programmatically you can certainly add any
additional Tornado view you need, including additional StaticHandler
instances.

Cool! This should get us going!

FWIW I am interested in Image glyphs that could send PNGs/JPGs to the
client as-is, without needing to first convert them to RGBA arrays. I
don't know when we might have the resources to do that, but I am happy
to offer guidance to anyone that would like to work on it sooner.

I might be interested for sure. It seems wasteful to decompress before sending, even locally, right?

Back when our app was pure javascript reading in images from a database, the images were base64-encoded jpegs. It seemed to work pretty well. Would b64-encoding the raw bytes from disk be the right approach here? Where do things get transmitted from Python to js (and back) in Bokeh? I haven't got that clear in my head despite various dives into the source code.

=P

Juan.

Hi @Bryan I’d like to revisit this, preferably with some guidance from people familiar with the Bokeh innards. As mentioned above I haven’t yet grokked the architecture of Bokeh.

We’re presenting microscopium at SciPy so that would be a good time for us. Both Genevieve Buckley and I are staying till Tuesday after the sprints. Last time I asked you weren’t planning on attending, but perhaps someone else from the team will be there? OR, we could schedule a chat/video session before then. We’re in Melbourne, Australia so late afternoon in Portland would work.

Thanks!

Right I don’t live in Texas anymore, so it’s not convenient to make Scipy like it used to be. AFAIK there aren’t any other Bokeh core devs attending Scipy. I expect Jim Bednar (Pyviz/Holoviews) may be there but I don’t know for certain. I am in PST now, and am generally available before 9am and after 5pm PST if you want to have a call next week sometime.

Ah, cool, thank you for that! I’m available (all times PST) Monday after 5pm, Wednesday 5pm-6:30pm, and Thursday after 5pm. You can reach me at juan.nunez-iglesias@monash.edu to arrange a medium. Thank you again!

Hi Bryan! We missed you at SciPy! =) Matt Rocklin gave us a nice template for the short-term image_url fix:

Putting it here in case anyone else finds this thread. We didn’t make any progress on the direct piping of jpgs/pngs from disk to the glyph, but it remains an interesting topic to explore in the future.