POC: Speed tests for uncertainties in Specviz

[bmorris3]

Description

In #2039, @javerbukh commented that viewing spectra with uncertainties seemed a bit laggy (https://github.com/spacetelescope/jdaviz/pull/2039#issuecomment-1462720975). I did a tiny bit of recon to figure out if there's a simple fix.

Currently uncertainties in Specviz are plotted as a filled ±one-sigma region. This PR implements an alternative uncertainty plotting method.

There's a mark in bqplot called OHLC for making plots which look like this: https://github.com/bqplot/bqplot/issues/622#issuecomment-371568092. There are four vertical length properties that can be set on this type of marker: "Open, High, Low, and Close". If you call OHLC(x, y, format='hl'), it will generate vertical bars at each data point, spanning from "high" to "low" values given as a 2D vector y. This workaround might be the closest bqplot method to matplotlib's errorbar method.

Speed testing

The plot below shows the full runtime for loading a spectrum with uncertainties into Specviz and show()ing it, for spectra of different lengths:

For reasons I don't yet understand, the shading implementation via bqplot.marks.Lines on main doesn't slow down much at all with more observations. The OHLC implementation appears to be up to 20% faster for very large spectra, but it's not clear based on JWST observations if we ever need to support that case.

Questions for discussion

1. Do we want a (possibly insignificantly) faster implementation (in the most common JWST use-cases)?
2. Do we think the vertical errorbars are more distracting than shading? (Personally I think vertical errorbars are messier, but I'm also accustomed to looking at errorbars that way, so the messiness isn't troubling to me.)

Change log entry

• [ ] Is a change log needed? If yes, is it added to CHANGES.rst? If you want to avoid merge conflicts, list the proposed change log here for review and add to CHANGES.rst before merge. If no, maintainer should add a no-changelog-entry-needed label.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

• [ ] Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
• [ ] Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
• [ ] Do the proposed changes follow the STScI Style Guides?
• [ ] Are tests added/updated as required? If so, do they follow the STScI Style Guides?
• [ ] Are docs added/updated as required? If so, do they follow the STScI Style Guides?
• [ ] Did the CI pass? If not, are the failures related?
• [ ] Is a milestone set? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone.
• [ ] After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

[pllim]

So OHLC is actually slower at 1000 data points?

[bmorris3]

So OHLC is actually slower at 1000 data points?

Either (1) it's a tiny bit slower, or perhaps more likely, (2) that's the margin of error on the speed measurement. 🤷🏻

[pllim]

So, is this worth pursuing or should we close without merge?

[bmorris3]

@pllim Doesn't matter much to me. Maybe we should ask @Jenneh for a UI perspective? (Though I strongly suspect the shaded uncertainty will be the winner, and that will leave us in the same situation again.)

[pllim]

@camipacifici , what do you think of the discussions above? Thanks!

[camipacifici]

Would it be an option to give the user a choice for how they want their uncertainties plotted?

[bmorris3]

@camipacifici I think that's an option. We code this in SpecvizProfileView._plot_uncertainties (here), which uses the LineUncertainties class to draw uncertainties. Currently LineUncertainties wraps bqplot.marks.Lines. We can add another wrapper for the OHLC-based alternative (already implemented in this PR), and add a toggle button (in Plot Options?) that switches between the options.

[camipacifici]

Sounds like a plan. I will create a ticket on our side and see when it can get prioritized. Thank you!