-
Notifications
You must be signed in to change notification settings - Fork 0
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
WIP: Fix blockers #22
Conversation
self.state.y_max | ||
] | ||
|
||
y_corners, x_corners = self._get_real_xy( |
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.
BTW I thought this was clever but unfortunately, _get_real_xy
was never meant to be vectorized. I dunno why but passing in scalar x/y in gives different output than passing in lists. Passing in scalars is what we have been using in main and the results are correct.
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 have to make a lot of changes here because I think there was a misunderstanding on the subtleties. And also some of the tests no longer make sense now that you always have a fake GWCS with no bounding box as reference.
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 results should have changed from main. The fact that you changed the results in your branch was a red flag. I managed to adjust the test inputs that do not result in results changing.
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## wcs-only-layers #22 +/- ##
==================================================
Coverage ? 90.09%
==================================================
Files ? 160
Lines ? 19852
Branches ? 0
==================================================
Hits ? 17885
Misses ? 1967
Partials ? 0 ☔ View full report in Codecov by Sentry. |
More safeguards fix multi viewer linked pan/zoom (or breaking it, not sure) Fix CI mainly by using more conventional ways to adjust the tests take give back same result as main, so also undo the result changes. Deleted unnecessary functions. Better change log, add basic doc. It bothers me that there is no user doc at all. I will add some basic info here. Better doc is already a future ticket. I do not need get_bottom_layer is needed GWCS is also BaseHighLevelWCS, no need to check separately. imviz.link_data API should error out sooner when subsets need to be cleared first. Remove unnecessary check for viewer.data() especially since that might waste memory. More code simplification. And clarify behavior more in doc. Docstring nitpick Nope did not work out as I hoped I think I fixed aper phot
This comment was marked as resolved.
This comment was marked as resolved.
because there is GUI
Calls to |
Do not assume data_collection[0] is always real data.
Fix linking in batch mode. Apply isort on some messy imports.
@bmorris3 , I think I addressed your two concerns from today. Are you okay with the remaining changes? |
This comment was marked as resolved.
This comment was marked as resolved.
now due to circular call from/to Orientation plugin. In the future, this can be moved to the plugin entirely. Make imviz.link_data call plugin API directly for consistency.
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 looks good, thank you! One question below.
jdaviz/configs/imviz/helper.py
Outdated
from jdaviz.configs.imviz.plugins.orientation.orientation import link_type_msg_to_trait | ||
plg = self.plugins["Orientation"] | ||
plg._obj.linking_in_progress = True | ||
plg.link_type = link_type_msg_to_trait[link_type] | ||
plg._obj.wcs_use_fallback = wcs_fallback_scheme == 'pixels' | ||
plg.wcs_use_affine = wcs_use_affine | ||
plg._obj.linking_in_progress = False | ||
plg._obj._update_link() |
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'm not sure I understand this change. orientation._update_link
calls orientation._link_image_data
which calls link_image_data
. So it looks like this is a longer and less clear way of doing a similar thing?
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 could not get link_image_data
to work properly on its own when switching from pixel to WCS the first time. The viewer got stuck displaying the fake layer even though visibility is set properly when I check the viewer state. I think there is some magic the plugin is doing that the API alone isn't, and it is very hard to trace with the circular callbacks and async event handling. In the end, I convinced myself that this way makes the most sense to make imviz.link_data(link_type="wcs")
to work properly again as advertised in the notebook.
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.
Can/should we deprecate imviz.link_data
and schedule consolidating the logic (not necessarily 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.
I was able to reproduce the behavior you're referring to, where the WCS-only layer is visible when calling link_image_data
, by reverting the highlighted lines above. I'm a bit concerned that this does not work in this PR, but it does work in the main PR – what caused the change in this PR? Investigating a bit.
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.
Can/should we deprecate
imviz.link_data
That would need PO inputs. I think Erik loved the link_data
API and it is widely advertised. So to ask him to now run several lines instead of one line in the API might be a non-starter. Regardless, it can be a future ticket and does not block Brett's work.
this does not work in this PR, but it does work in the main PR
Oh, no. Did I try to fix one thing but broke another thing. If you can find out what, would be great. I went down several rabbit holes last night and then gave up. It bothers me that the plugin calls link_image_data
but then link_image_data
has a hook to call the plugin back. I think we should get rid of link_image_data
. I almost did it here but then the diff would be horrible, so I didn't.
Co-authored-by: Brett M. Morris <[email protected]>
What I had to do to make the API work again for this fake WCS layer but I don't love this. Probably have to special case everything just for Imviz so the old API behavior would still work for Cubeviz and Mosviz image viewers.
TODO
🐱