-
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
support specreduce 1.3 #1889
support specreduce 1.3 #1889
Conversation
I think you also need astropy/specreduce#151 |
that isn't merged yet, so I don't know if it'll make 1.3 or not. What changes would that need on the jdaviz-side? (With the exception of the unit errors that I'm working to address, all tests pass locally) |
For that test file, the mask returned |
See #1877 (comment) |
To be sure, you can temporarily add back dev specreduce job here. |
fff6770
to
0936816
Compare
* revert this commit once glue handles non-linear wavelength scaling
0936816
to
75c4660
Compare
035166b
to
9e2aedc
Compare
I don't see any testing against specreduce dev, does this mean specreduce 1.3 is released? |
Yes, specreduce 1.3 has been released and pinned as part of this PR. The temporary testing against dev has therefore been removed. |
|
||
if add_data: | ||
self.bg_spec_add_results.add_results_from_plugin(spec, replace=False) | ||
|
||
# TEMPORARY: override spectral axis to be in pixels until properly supporting plotting |
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 issue will fix this? Is this future work?
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 the general effort to support wavelengths (waiting for glue/bqplot work in order to sync the axes correctly). So yes, this is intentionally added to keep the current behavior.
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 say we get this in now to get the CI green and worry about little bugs later.
Just to clarify - CI on main/other PRs should not be broken as we pin a minor version of specreduce. This PR just aims to make use of the new functionality and cleaner API in specreduce 1.3 and keep us up-to-date. |
Hmm... Pretty sure specviz2d auto-collapse failed for me locally so I thought I need this, but maybe my env was dirty... Would you rather not get this in sooner than later? |
Found one other place that needs fixing/updating: if using Horne extraction on the original data (not "From Plugin"), then specreduce fails with the following error: To reproduce:
EDIT: fixed in commit below, marked back as ready-for-review. |
c371981
to
69574d6
Compare
Codecov ReportBase: 88.45% // Head: 88.48% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #1889 +/- ##
==========================================
+ Coverage 88.45% 88.48% +0.02%
==========================================
Files 95 95
Lines 10533 10550 +17
==========================================
+ Hits 9317 9335 +18
+ Misses 1216 1215 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
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 installed this PR and successfully grabbed specreduce=1.3.0. Running pytest jdaviz
resulted in no errors.
My only thought is whether you wanted to add a new test to cover the case you found in #1889 (comment)?
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.
The code included so far looks good to me. Was the choice to leave out Chebyshev models intentional? I'll hold off on the approval in case the answer is no because I think it would be good to have parity in the available trace models.
I can get the UI to stop responding for several seconds if I change trace parameters too quickly. Can you replicate that? I don't see any unexpected warnings, and I'm guessing part of the issue is lag from FitTrace
's calculation of fits in certain scenarios. (@PatrickOgle already mentioned it at the specreduce
repository in a review of polynomial tracing.)
I honestly can't remember, but it's trivial to expose (now or later). @PatrickOgle @camipacifici - do we want all supported models in jdaviz or just some subset. I think specreduce's
Yes, with binning disabled, the interactivity can start to feel laggy. It was largely for this reason that I have binning enabled by default, even though it isn't enabled by default in |
* separate messages shown if binning is disabled or if nbins > 20
@ojustino - I added Chebyshev support and also a warning in the plugin for possible slow behavior. I think I'd rather defer a possible spinner until we see how it performs in the wild. |
RTD was passing before and no changes were made to docs since, so I think that is safe to ignore for now. |
I restarted RTD, just to see if it is transient. |
Description
This pull request makes necessary changes to support the (upcoming) 1.3 release of specreduce.
This combines (and replaces) #1695 and #1847.
This will
specutils.Spectrum1D
objects as input/output to specreduce from Better handled Spectrum1D images across classes astropy/specreduce#144. This will also enable us to support keeping the spectral-axis/WCS throughout the spectral extraction process (although that is temporarily disabled here until the proper plotting support is implemented upstream).model_type
from theFitTrace
implementation in Introducing polynomial tracing astropy/specreduce#128.Todo:
test_parser
Once specreduce 1.3 is released, this PR should pin that new release and should then be tested (although it does currently seem to work as expected with the current state of the PR branch).
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.