-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: buggy 1D/2D spectrum viewer x-axis links #852
Conversation
Codecov Report
@@ Coverage Diff @@
## main #852 +/- ##
==========================================
+ Coverage 68.29% 68.53% +0.23%
==========================================
Files 65 65
Lines 4741 4777 +36
==========================================
+ Hits 3238 3274 +36
Misses 1503 1503
Continue to review full report at Codecov.
|
Hmm.. I see now that my workaround for the flipped data does not work as expected. |
This is probably what you're talking about in regards to the flipped data, but for what it's worth I now see the the 1D spectrum with an ascending wavelength axis on row click, however the 2D spectrum is still in descending order. This means that if the user interacts with the 1D spectrum first, the 2D spectrum will flip to match it, but if the user interacts with the 2D spectrum first, the 1D spectrum will flip back to descending wavelength to match the 2D one. So this almost works, just needs a tweak to the initial loading of the 2D spectrum I think. Other than that, this PR looks great. The pan/zoom warning behaves much better now. |
Indeed. I think I can flip the 1d x-axis on row click. |
You mean 2D right? 😆 |
jdaviz/configs/mosviz/helper.py
Outdated
self.app.hub.broadcast(msg) | ||
|
||
def _is_world_flipped(self): | ||
spec1d = self.app.get_viewer('table-viewer')._selected_data["spectrum-viewer"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This causes KeyError.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's failing in the tests because the test is lazy and doesn't populate the 1D spectrum viewer for the 2D test, I think. Not sure if that's a realistic use case...I would assume we always have a 1D spectrum if we have a 2D in Mosviz.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix the test or make this fail silently? Prefer the former...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missed this conversation, I changed the code to guard for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mosviz should support loading just one type of spectrum, as we can infer from the existence of methods such as load_1d_spectra
.
84bc44b
to
ad4d502
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't grok the internals but here is a general review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, this is a huge improvement on the current performance. Thanks!
Does this need a rebase so this can be tested on top of #733 ? |
I've rebased on #733, and some tests now produce errors. |
Re: Errors -- We won't see it here until you push out the rebased branch... 😬 |
I was trying to see if I could quickly fix it 😃, but will push it now. |
7888b66
to
0f3f8dd
Compare
Hmm looks like everything is passing... |
@@ -78,11 +77,11 @@ def place_slit_overlay(self, *args, **kwargs): | |||
self.remove_slit_overlay() | |||
|
|||
# Get data from relevant viewers | |||
image_data = self.app.get_viewer("image-viewer").data() | |||
image_data = self.app.get_viewer("image-viewer").state.reference_data |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. This is from a different PR!
jdaviz/configs/mosviz/helper.py
Outdated
# Warn the user if they've panned far enough away from the data | ||
# that the viewers will desync | ||
# Note: Because of the flipped data workaround, idx_min can be > idx_max | ||
if not (0 <= idx_min < len(world) and 0 <= idx_max < len(world)): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It bothers me a bit that len(world)
is calculated twice in the same line, but I am being too nitpicky, perhaps...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't mind changing that.
Strange... Also, I see some changes after the rebase that shouldn't be there. I see now that's because the merge target is main. |
Will rebase on main, since 733 is merged |
0f3f8dd
to
a7759e6
Compare
a7759e6
to
ca1e58c
Compare
History and code look good now. Thanks! |
That sounded like an approval to me. Merging! |
Fixes #802
Description
This pull request is to address ...
Fixes #
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.
trivial
label.CHANGES.rst
?