Color controls

[jsoules]

This PR institutes a couple of big changes to how the color scales are handled for the 1d and 2d decoded-position visualizations.

For the 1D visualization, see https://figurl.org/f?v=gs://figurl/franklab-views-dev2a&d=sha1://5ce6bd6dfce3932d2bde1a79b2a51ef39fab8e14&label=03f1-acausal-posterior&s=%7B%7D

For the 2D visualization, see https://www.figurl.org/f?v=gs://figurl/franklab-views-dev2a&d=sha1://7251ae9794d4dfd783fabd9b84826c86b1982f74&label=2D%20Decode%20Example&s=%7B%7D

(The latter is a composite view, so not the greatest sample, but it was a recent one I could find. Note that these choices should be synced between 1d and 2d views when both are present on the screen, and there is logic to suppress display of the color controls in composite views when multiple components might want to display a color control, but this hasn't been tested.)

The user-facing changes are as follows:

• 1D decode timeseries and 2D decode animation views now have a dropdown (where the user can select one of several supported color scales) and a slider (which sets the upper bound for the dynamic range of the color scale on a 1-255 scale). Anything above that bound will be flattened to the color scale max, and the full 256 discrete colors on the color scale will be used to represent values in the range from 0 to the selection.
• For the 2D decode specifically:
  • The track background is now the 0-value on the color scale (previously it had been its own color)
  • The observed position dot and "peak decoded position" dot are now colored with colors chosen to contrast with the selected color scale. (Each of the color scales has its own primary and secondary contrast colors; the primary contrast color is also the color used for the "observed position" line for the 1D decode.) These are decent but require some compromises--the secondary color in particular may not have ideal contrast with certain parts of the midrange of the color scales.
  • The 2D animation observed- and decoded-position dots have been set to have a radius of half the diagonal of a track bin, rather than the previous value (a flat 10 pixels), which tended to make them huge when the animation was displayed at a smaller scale.

Under the hood, many more extensive changes have been made:

• Color selection is handled as its own utility and set of hooks.
• I have implemented a "Style settings" context. Presently its only members are the ones used to govern the color scales, but this could be used to expose more styling to user controls in the future. (If so, it should almost certainly be moved to a more basic level of the Figurl library suite.) The context stores the settings (chosen color scale and range max) rather than the complete set of colors that fall out; the meaning of the settings is handled by memoized hooks, and it's best not to cram too much context data in.
• Added a ColorControls element that displays the slider and dropdown. It also has a stylesheet that defines a mouseover tooltip style, which is used for an explanatory note for the slider.
• DecodedLinearPositionDrawing.ts has been updated to invalidate the offscreen canvas cache when the style settings are updated.
• DecodedLinearPositionPlotView.tsx has been updated to check the global style state for the color scheme, and to allow the color-scheme controls to live next to the "display observed position overlay" checkbox.
• In the 2D Decoded Animation views:
  • Did some reworking of the way the draw callbacks get configured, so that color data doesn't need to be computed and included with each timestep.
  • Moved color-scale definitions out of the Decoded Position Layer and have it pulling from the global state and hooks for the bin colors and secondary-contrast color (for the peak decoded position dot).
  • Updated the observed-position layer to add configurability for its draw function and make it use the global-state primary-contrast color for the observed position dot.
  • Added radius computation function, color controls, and global-style-state integration to TrackPositionAnimationView.tsx.

I also added a package or two for UI components (slider).

Outstanding:

It'd probably be a good idea to add support for writing the current style settings to the URL query string, but I haven't actually implemented this yet.

[jsoules]

If accepted, will address or resolve SpikeSortingView issues #77, #128, #151.

[magland]

Looks great!

To be more intuitive, I think the dynamic range control should be inverted so that moving to the right corresponds to increasing the brightness.

If two or more views exist in the same layout with the color/dynamic range options be synchronized? I think the user would want and expect that. Not sure how much of a difficulty that poses.

[jsoules]

Thanks! I agree it feels a little counterintuitive; I'm not sure that the slider component supports flipping the direction though. They do support inverting the track (so that it'd be the stuff to the right of the control that is highlighted); I'm not sure this is much better.

I may be able to invert the sort or something. I'll see if I can manipulate the data so that it sorts the way we'd like.

Regarding multiple views, while I don't have a view prepared that would test this, the intention is that they would be synchronized. (That's why I made the style settings a context rather than something local to the component.) We should check this out.

[jsoules]

Added a commit that uses a right-to-left theme so the max slider value goes on the left side. Hopefully this is more intuitive?

[magland]

I'm going to merge it. @jsoules could you then publish to npm from the main branch? Then I'll deploy the new spikesortingview-10