-
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
BUG: Fix wrong Subset unit when created in 2D spectrum viewer #3201
Conversation
@@ -134,6 +137,25 @@ def test_2d_1d_parser(specviz2d_helper, mos_spectrum2d, spectrum1d): | |||
specviz2d_helper.load_data(spectrum_2d=mos_spectrum2d, spectrum_1d=spectrum1d) | |||
assert specviz2d_helper.app.data_collection.labels == ['Spectrum 2D', 'Spectrum 1D'] | |||
|
|||
spec2d_viewer = specviz2d_helper.app.get_viewer("spectrum-2d-viewer") | |||
assert spec2d_viewer.figure.axes[0].label == "x: pixels" # -0.5, 14.5 | |||
spec2d_viewer.apply_roi(XRangeROI(10, 12)) |
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.
Could have used the API from #3104 but since it is not merged yet, I didn't.
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.
#3104 is now merged but the API is not yet public. Should I keep this as-is or should I use the helper.plugins['Subset Tools']._obj.import_region(...)
syntax here?
assert len(subsets) == 2 | ||
s1 = subsets["Subset 1"] | ||
s2 = subsets["Subset 2"] | ||
assert s1.lower.unit == s1.upper.unit == u.pix |
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 confirmed that this line throws exception on main
without this patch, but passes with this patch. Exception on main
:
> assert s1.lower.unit == s1.upper.unit == u.pix
E assert Unit("Angstrom") == Unit("pix")
E + where Unit("Angstrom") = <Quantity 12. Angstrom>.unit
E + where <Quantity 12. Angstrom> = Spectral Region, 1 sub-regions:\n (10.0 Angstrom, 12.0 Angstrom) .upper
E + and Unit("pix") = u.pix
and fixed an ambiguous specviz2d test, maybe
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3201 +/- ##
==========================================
- Coverage 88.46% 88.44% -0.02%
==========================================
Files 125 125
Lines 18668 18676 +8
==========================================
+ Hits 16514 16518 +4
- Misses 2154 2158 +4 ☔ 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.
Seems like it's giving the expected results in my testing, other configs appear to still work. LGTM, thanks.
@kecnry , I think I addressed your comment. |
viewer = self.get_viewer(self._jdaviz_helper._default_spectrum_viewer_reference_name) | ||
data = viewer.data() | ||
if data and len(data) > 0 and isinstance(data[0], Spectrum1D): | ||
units = data[0].spectral_axis.unit |
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.
what does data[0]
assume? That that is the full cube extracted spectrum? If that is the assumption, maybe we need to be more explicit and request it by label instead? What if that has been unloaded from the viewer?
I still wish this could be generalized, but I see how its difficult since data
in the else is the glue component, but data
in the if
is a Spectrum1D (or other translated object). Although the else in the else then uses a handler to convert to a Spectrum1D anyways. 🤔
If all we need here are the units of the x-axis of the spectrum viewer... can we just access the display units? Or do we need the native units of the "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.
I don't know the answers. This block is really for Cubeviz and I am trying to patch Specviz2D. Do I really have to fix Cubeviz too?
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.
Fair, ignore my first line of questions then since those do apply to the old code. But I think if we can have a general block here that applies to cubeviz and specviz2d, that would be easier to maintain than if-statements, right? There is even a TODO comment immediately above suggesting switching to display units - so maybe we can simplify this all down to one line once @gibsongreen enables display units across all configs?
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.
(or maybe it makes sense to get this in like this now and either roll that into @gibsongreen's WIP or as a tech-debt follow-up after that makes it in as well?)
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.
ok, we have decided to revisit this after unit conversion is enabled across all configs and merge the logic as-is until then. 🐱
Actually I am not going to backport this because it is unlikely the backport will be clean due to unit conversion stuff. |
Thanks, all! |
Description
This pull request is to address wrong Subset unit when it is extracted from Subset created in Specviz2d on the 2D spectrum viewer. Glue itself does not attach unit natively to Subset, so that means Jdaviz made wrong assumptions in the extraction code. Bug ticket blamed it to the Export plugin but the actual bug has nothing to do with the Export plugin, thought the plugin did expose the bug when user extracted Subset that way but you don't need the plugin to reproduce the bug.
Change 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.