You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an enhancement suggestion, and a place to discuss the issues involved. Previously this idea was hand-written in a notebook, so not as accessible.
It is an extension of the idea of a line-spread function, i.e. the uncertainty associated with the spectral_axis.
It reduces convolution and deconvolution to matrix multiplication. For example, model spectra can be convolved via the resolution matrix for comparison to the data (the extracted spectrum).
It simplifies the process of resampling a spectrum to a different spectral_axis.
Discussion is welcome. In particular, opinions on whether this should be included in the core specutils, or implemented as survey-specific subclasses of specutils objects. The latter will probably happen anyway, at least at first.
It would also be interesting to compare implementations. I know of DESI's (Guy et al. 2024), but would be interested to hear of others.
The text was updated successfully, but these errors were encountered:
Just an off-hand comment... Although it might not be as relevant in specutils, there are probably applications for tracking spatial resolution as well (?), so I would be wary of a scheme that's difficult to generalize. Maybe consider whether the new attribute(s) could also go in NDData in some form and how different axes would be addressed? Of course spatial resolution may be less stable & harder to characterize.
This is an enhancement suggestion, and a place to discuss the issues involved. Previously this idea was hand-written in a notebook, so not as accessible.
The resolution matrix as defined in Bolton & Schlegel (2010) has a number of useful properties:
spectral_axis
.spectral_axis
.Discussion is welcome. In particular, opinions on whether this should be included in the core specutils, or implemented as survey-specific subclasses of specutils objects. The latter will probably happen anyway, at least at first.
It would also be interesting to compare implementations. I know of DESI's (Guy et al. 2024), but would be interested to hear of others.
The text was updated successfully, but these errors were encountered: