Optimize Bokeh's storage of ROI contour points
Optimize Bokeh's storage of ROI contour points

This attempts to leverage a new feature in Bokeh 0.12.4 to serialize the
patches in a more compact way. Namely it tries to leverage support for
`base64` encoding of NumPy arrays. Previously this encoding did not
happen as `int64` was not a supported type for use with encoding and
that is the default type for all integers.

However, we almost certainly don't need this level of precision when
specifying the pixels in often 512x512 or somewhat larger images. In
fact, we can basically guarantee that we won't need anything more than
`uint16`. In some cases, we might even be able to get away with `uint8`.
Not to mention they will never be signed. So there is no need to keep
them as `int64`.

Here we leverage this information by determining the longest dimension
of the image and find the NumPy type, which will be sufficient for
storing a value at the maximum extent of that dimension. Such a type
will necessarily fit all of the contour point values. Therefore it is a
trivial matter to go about converting them to NumPy arrays of this type
before creating the plot. Once we have done this, we can see that they
are properly stored as `base64`.

As Bokeh already converts NumPy arrays to lists and integers to human
readable integers in JSON when looking at earlier version of Bokeh, this
strategy works fine on Bokeh versions before 0.12.4 (e.g. 0.12.3), but
does not result in any kind of optimization for those cases. Thus we can
make this change now without waiting for the new version of Bokeh to be
released and installed. However, if a copy of Bokeh 0.12.4 is installed
and available, one immediately benefits from this optimization for ROI
storage in the Bokeh plots.

nanshe-org/nanshe_workflow,DudLab/nanshe_workflow