-
Notifications
You must be signed in to change notification settings - Fork 74
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
image viewer zoom-level/center #2649
Conversation
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.
You might wanna wait. I redid some of the math to account for Brett's rotation work on his branch.
I think that should be pretty easy to migrate here, no? |
Yes. But you will have conflicts. |
a9c4418
to
37e50f6
Compare
60b249b
to
5bc43a6
Compare
jdaviz/core/astrowidgets_api.py
Outdated
|
||
with delay_callback(self.state, 'x_min', 'x_max'): | ||
self.state.x_min = new_x_min - 0.5 | ||
self.state.x_max = new_x_max - 0.5 |
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.
@pllim should this be + 0.5
instead (assuming the 0.5 is to account for the margin added around the data)? Otherwise, where is this coming from?
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 quite remember either and #744 has no record of it. I think it has something to do with user input being pixel center but viewer wants pixel corner. Not 100% sure.
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 was sure I worked out the math properly though using API + mouse cursor info. Does it not work anymore?
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 was seeing wandering when changing the zoom-level and switching to +
seemed to fix it, but maybe introduced that somewhere else. I'll go back to main and see if I can trigger the same there or not. Either way, doesn't seem to be the culprit for the failing test.
Just focusing on the first failure I see, looks like centering failed. You have
|
Try run the test case interactively on a notebook. Does it work there? |
Some of the failures here I have a hacky workaround locally, I just need to figure out the right way to do it, but there are a few others that still remain after that as well. |
20f8d44
to
121fc7a
Compare
@@ -31,9 +32,12 @@ class CubevizImageView(JdavizViewerMixin, BqplotImageView): | |||
] | |||
|
|||
default_class = None | |||
_state_cls = FreezableBqplotImageViewerState |
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 is was the reason for the cubeviz test failure - this forces cubeviz to use Imviz's reset_limits
which behaves differently, even after accounting for different pixel components. We may eventually want to update reset_limits
and/or the tests so that the image viewers in cubeviz and Imviz behave consistently when resetting limits, but that is out of scope here.
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.
By Imviz's reset limits, do you mean this?
jdaviz/jdaviz/core/astrowidgets_api.py
Lines 195 to 198 in 00954e1
# Zoom on X and Y will auto-adjust. | |
if val == 'fit': | |
self.state.reset_limits() | |
return |
I farmed it back out to glue-jupyter. Nothing fancy there.
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.
No, I meant FreezableBqplotImageViewerState.reset_limits()
which overrides glue's BqplotImageViewerState.reset_limits()
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 like you implemented this 2 years ago in #1897
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 know, and that so far has not been enabled in cubeviz.
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.
And then that particular line was changed from a different logic by me later in #1928
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 think there is any point to make Imviz and Cubeviz consistent. Imviz has WCS linking to worry about, Cubeviz does not.
pixel_id_x = [comp for comp in pixel_ids if comp.label.endswith('[x]')][0] | ||
pixel_id_y = [comp for comp in pixel_ids if comp.label.endswith('[y]')][0] | ||
|
||
x_max = max(x_max, layer.layer.data[pixel_ids[1]].max() + 0.5) | ||
y_max = max(y_max, layer.layer.data[pixel_ids[0]].max() + 0.5) | ||
x_max = max(x_max, layer.layer.data[pixel_id_x].max() + 0.5) | ||
y_max = max(y_max, layer.layer.data[pixel_id_y].max() + 0.5) |
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 technically isn't necessary, but will help future-proof if we ever do enable this custom reset_limits
for any cube 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.
But now it depends on the label name. Is the label always guaranteed to have x/y in the name?
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.
that seems to be more general/reliable than assuming the first and second index 🤷♂️ I can revert for now though and deal with this if/when we try to make the image viewers in configs more consistent.
dc2678d
to
5a4cdeb
Compare
This is the only error I am seeing:
|
That is the mosviz error I am still working on addressing. If you remove the if-statement within |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #2649 +/- ##
==========================================
+ Coverage 90.81% 90.83% +0.02%
==========================================
Files 162 163 +1
Lines 20962 21502 +540
==========================================
+ Hits 19036 19532 +496
- Misses 1926 1970 +44 ☔ View full report in Codecov by Sentry. |
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.
Zooming and centering work as expected, even when viewers are linked. Plot options also handles different combinations of multiselect well, even when an image and spectrum viewer are selected. Nice work!
a5b2ce7
to
5468fb1
Compare
@javerbukh - since your approval, this has been updated to expose zoom-radius instead of zoom-level (with different translation logic), but the UI remains essentially unchanged. Feel free to dismiss your review though if you see anything in the latest two commits that you think warrants a fresh look. |
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.
Something is amiss in Imviz w/o WCS linking. Changing zoom radius in the plugin causes jumping in the viewer, and does not change the zoom radius.
Screen.Recording.2024-02-02.at.09.45.20.mov
When linked by WCS, zoom radius step size of "1" (degree?) is too big to be useful, and should be restricted to positive values. In some other Plot Options context (stretch histogram maybe?), we adjust the up/down arrow step size depending on the content of the viewer. I think we need that here. Also, we need some kind of unit on the zoom center (x, y) and radius. When WCS-linked, it's degrees for x and y, and maybe also radius. I'd suggest that zoom radius should be displayed in units of arcsec/arcmin. Screen.Recording.2024-02-02.at.09.48.22.mov |
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.
Since changes to Astrowidgets API so far is minimal, I do not have concern on the design. When you have made more progress, the user docs definitely would need to be updated. Also does not hurt to update the example notebook(s) to demonstrate this new way of zooming.
Thanks!
* NOTE: widget will not respect step until upstream PR is merged/pinned, but can be accessed (for testing purposes) with plot_options._obj.zoom_step
a5e853c
to
89d3bc0
Compare
I think the zoom radius was working, it just isn't obvious with the stepsize. Dynamic step-size is now implemented, but you'll need glue-viz/glue-jupyter#417 in order to see it in action (without that upstream PR, the stepsize will fallback on 1). Jumping is as fixed as I can get it 😬
Re step size: see response above. Re negative radius: limiting the value through glue is difficult, so I now just gracefully handle a negative radius 🤷♂️
For now I just expose these as degrees to avoid unit-conversion. I can see the argument for making zoom-radius a "finer" unit, but suspect we'll want to just adhere to display units if/when we implement them for the spatial direction on images. |
dbb3e33
to
e6c2fc5
Compare
e6c2fc5
to
e380a96
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.
Re-checked the code and tested the functionality and all still looks good. Others have mentioned the jumping but I can understand that that may not be fixable at the moment. As long as we have a ticket to track that this should be good to merge, thanks!
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.
tested it again, looks good to me
Description
This pull request moves the logic for translating between zoom limits (in x and y) and zoom level/center from the astrowidgets API into the viewer state and builds on #2604 to allow accessing and modifying these from the plot options plugin.
Screen.Recording.2024-01-11.at.12.51.20.PM.mov
NOTE: dynamic step size requires upstream support glue-viz/glue-jupyter#417
TODO:
zoom_level
andzoom_center
before any change to limitsChange log entry
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, maintainershould 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.
trivial
label.