Time Selector (adapted version of cubeviz's slice) plugin

[kecnry]

This PR implements a modified version of cubeviz's slice plugin into lcviz for TPF support.

NOTE: this PR requires the following upstream PRs and therefore an update to the jdaviz pin, and until then the RTD build and tests are expected to fail:

• Generalize units in slice plugin jdaviz#2706
• allow downstream apps or config-specific override to docs description jdaviz#2709
• slice: refactor plugin to decouple from cube jdaviz#2715

Now that these are all accepted and merged into jdaviz, this PR should be tested against jdaviz main (3.9).

And the following upstream draft PR was created for this, but is no longer used within this PR, so is not necessary:

• Context-aware plugin relevancy jdaviz#2711 (no longer used for the slice plugin - probably will be used once the photometric extraction plugin exists, though)

This will then also bump #82 to require the necessary pin of jdaviz (likely 3.9).

Example usage:

from lightkurve import search_lightcurve, search_targetpixelfile
from lcviz import LCviz

lc = search_lightcurve("HAT-P-11", mission="Kepler", cadence="long", quarter=10).download() #.flatten()
tpf = search_targetpixelfile("HAT-P-11", mission="Kepler", cadence="long", quarter=10).download()


lcviz = LCviz()
lcviz.load_data(lc)
lcviz.load_data(tpf)

po = lcviz.plugins['Plot Options']
po.viewer = 'image'
po.image_colormap = 'Gray'
po.stretch_function = 'Arcsinh'
po.stretch_vmin = 0
po.stretch_vmax = 20000

lcviz.show()

Screen.Recording.2024-03-04.at.12.17.29.PM.mov

Screen.Recording.2024-03-06.at.3.24.34.PM.mov

[bmorris3]

It looks like the default selected tool is slice, even for light curves without TPFs. If you press Home, it keeps slice activated:

Is that intentional?

[bmorris3]

If the loaded data is a TPF, we agreed that the time selector should snap to slice, which looks good.

I load a light curve (not a TPF) into the demo notebook, the slicing logic doesn't appear to be applied. When I hover on an in-transit cadence in flux-vs-time until the correct cadence is highlighted, and click it with the Slice tool active, I never get an in-transit slice in the ephemeris viewer:

lcviz-slice-snap.mov

I assume this is because my mouse clicks are >1 transit duration from the center of the in-transit exposure, but that's hard to tell.

Let's ensure that snap to slice is active for LCs.

[kecnry]

I think what you're describing (if I followed it correctly) is a little more subtle (and quite a bit more complicated) than snapping vs not snapping. There are a few coupled things going on here:

1. snap-to-slice currently means snap to the slice in a cube, not a data point in the viewer with the indicator. Snapping is enabled here by default, but when there is no cube, then it is effectively ignored. I don't think we want to change this to "snap to data point in the indicator viewer", because then that can result in an annoying experience when a cube is loaded but sampled at different times than the light curve. The main point of snapping is so that the indicator exactly matches the image shown. We could have a separate option for "snap to point"... or when there is no cube loaded, snap-to-slice could then actually snap to data points (that feels inconsistent to me though and might be confusing logic).
2. even if you had a cube loaded, I don't think it would behave as you're expecting because the slice tool works only considers the slice (x) axis, whereas the mouseover display is doing nearest on the screen (in xy). You'll notice in your video that the indicator did move to your cursor, but not the orange rectangle. So should the mousover behavior change so that it feels more consistent with the slice tool? Or does this different behavior make sense because they're different tools? And if we want to make any changes, should those be isolated to lcviz or be made upstream?

[kecnry]

It looks like the default selected tool is slice, even for light curves without TPFs. If you press Home, it keeps slice activated. Is that intentional?

Yes, I couldn't see any reason for it not to be the default since there currently was no other default. Do you disagree with that?

[kecnry]

This now supports dragging the indicator in the phase-viewer (by computing a delta time from a delta phase and setting the time in the same cycle).

Screen.Recording.2024-03-06.at.3.24.34.PM.mov

[kecnry]

Ok, we're merging this as is into the feature branch and then will consider the points above as we flesh out the rest of the functionality. Thanks for the feedback!