-
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
Add Spectral Extraction plugin for Cubeviz #2039
Conversation
CI note: |
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.
Just a few comments as I was skimming the diff.... its nice to see that this will be quite lightweight on our end if/when the astropy implementation makes it in! 🎉 🤞
# by default we want to use ignore_masked_data=True in nddata: | ||
if "ignore_masked_data" not in kwargs: | ||
kwargs["ignore_masked_data"] = True | ||
# by default we want to propagate uncertainties: | ||
if "propagate_uncertainties" not in kwargs: | ||
kwargs["propagate_uncertainties"] = True |
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.
would these be worth exposing as switches in the UI or are they meant to be advanced use-cases only for the API (in which case maybe they should be explicitly defined in the method, or are you expecting a bunch of other kwargs and need to keep it flexible)?
# by default we want to use ignore_masked_data=True in nddata: | |
if "ignore_masked_data" not in kwargs: | |
kwargs["ignore_masked_data"] = True | |
# by default we want to propagate uncertainties: | |
if "propagate_uncertainties" not in kwargs: | |
kwargs["propagate_uncertainties"] = True | |
# by default we want to use ignore_masked_data=True in nddata: | |
kwargs.setdefault("ignore_masked_data", True) | |
# by default we want to propagate uncertainties: | |
kwargs.setdefault("propagate_uncertainties", True) |
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 a good question. The implications of the two options are a bit complex (see astropy/astropy#14175 (comment)) so I'm torn between adding toggles for flexibility and leaving these subtleties in the astropy docs for more advanced users. Happy to hear all opinions!
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.
(un-auto-resolving so we can return to the conversation about these being explicitly listed as kwarg arguments and/or in the UI - I don't have any strong feelings right now, but suspect we'll want to give that some thought when this actually is ready to go in)
# get glue Data objects for the spectral cube and uncertainties | ||
[spectral_cube] = self._app.get_data_from_viewer( | ||
self._app._jdaviz_helper._default_flux_viewer_reference_name, | ||
include_subsets=False | ||
).values() | ||
[uncert_cube] = self._app.get_data_from_viewer( | ||
self._app._jdaviz_helper._default_uncert_viewer_reference_name, | ||
include_subsets=False | ||
).values() |
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.
will this become easier with get_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.
Probably/hopefully.
jdaviz/configs/cubeviz/plugins/spectral_extraction/spectral_extraction.py
Outdated
Show resolved
Hide resolved
Re: CI -- you can theoretically force the CI to install your glue-astronomy PR branch. However, given that your fork does not have proper tags, the glue-astronomy version number will look really old, so you cannot pin glue-astronomy in jdaviz as well. FYI. |
If you want it to be merged sooner, here is crazy idea. When astropy PR is merged upstream, you can:
This way, the PR has less chance to go stale. |
jdaviz/configs/cubeviz/plugins/spectral_extraction/spectral_extraction.py
Show resolved
Hide resolved
[spectral_cube] = self._app.get_data_from_viewer( | ||
self._app._jdaviz_helper._default_flux_viewer_reference_name, | ||
include_subsets=False | ||
).values() |
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 this cause issues if the user creates a moment map and sends it to be shown in the flux-viewer (as this plugin would then pull a 2d image instead of the flux cube)?
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.
Yes that would be problematic here. We wouldn't want the user to think they could extract a spectrum from a moment map... should we raise an error if the flux-viewer has >1 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.
Now reported as a bug 🐱 (although in a slightly different case where the assumption of a single data entry is causing an error)
jdaviz/configs/cubeviz/plugins/spectral_extraction/spectral_extraction.py
Outdated
Show resolved
Hide resolved
@@ -1086,7 +1089,7 @@ def __init__(self, *args, **kwargs): | |||
'spatial_subset_items', | |||
'spatial_subset_selected', | |||
'spatial_subset_selected_has_subregions', | |||
default_text='No Subset', | |||
default_text='Entire Cube', |
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.
272f40d
to
3401ccc
Compare
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #2039 +/- ##
==========================================
- Coverage 90.72% 90.61% -0.12%
==========================================
Files 157 159 +2
Lines 18017 18177 +160
==========================================
+ Hits 16346 16471 +125
- Misses 1671 1706 +35
☔ View full report in Codecov by Sentry. |
@kecnry Just to clarify, your checkbox above says "pin to 5.3.2," but the PR already disables the Spectral Extraction plugin for astropy<5.3.2. I've restored the astropy pin in this PR to its usual value in jdaviz. |
Ok, that works fine too. Maybe add a note in the plugin docs and then create an issue to remove it (and all the test-checks) whenever the pin otherwise gets update to at least 5.3.2? |
Description
I introduced ND array collapses along arbitrary dimensions with propagation of uncertainties, masks, and units in astropy/astropy#14175.
This PR implements a Spectral Extraction plugin for Cubeviz. Users can load a spectral cube, and collapse the entire cube or a spatial subset to a 1D spectrum via the following operations: sum, mean, min, or max. Uncertainties are propagated self-consistently, and logic is built in to flexibly handle masks (for example, do you want collapses along an axis to become masked if any data are masked, versus only if all data are masked? See astropy/astropy#14175 (comment) and related comments for use cases).
Demo
This demo uses a background calibration observation with MIRI. The related target is the bright A3 star HD 163466 (URI:
mast:JWST/product/jw01539-c1022_t004_miri_ch1-short_s3d.fits
)JDAT-3113.mov
Discussion points
Naming
In this POC, I've named the plugin "Spectral Extraction", which is an exact name collision with the plugin in Specviz2D:
jdaviz/jdaviz/configs/specviz2d/plugins/spectral_extraction/spectral_extraction.py
Line 33 in e57350c
That may be ok if we won't have 3D cubes and 2D spectra in the same helper. The only step I took to differentiate is to give the plugin a different name in the tray registry.
Do we want to give these distinct names?
Are pipeline uncertainties smaller than we want for model fitting?
The uncertainties in the
ERR
extension from the pipeline are quite small. For example, here is a simple comparison between the pipeline uncertainties and the square-root of the data in theSCI
extension, which is a proxy for the expected photon noise:Typical uncertainties are within a factor of three of the photon noise – but the RMS scatter in the spectra show noise that exceeds these errorbars.
Some options for moving forward include:
Related upstream PRs
In order to implement the plugin on the jdaviz side, I needed to do several upstream tweaks, outlined here:
Data
translatorSpectrum1D
to be translated to/from glueData
with only spectral coordinates in WCSThe astropy release calendar indicates that the astropy v5.3 release candidate should be out 2023-04-28, so this PR to jdaviz shouldn't be merged unless we add logic to hide the Spectral Extraction plugin from users with
astropy<5.3
, until some time in ~May.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.