Skip to content
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

Create classes/functions to replicate flux calibration a la IRAF standard/sensfunc tasks #533

Open
eteq opened this issue Oct 10, 2019 · 0 comments

Comments

@eteq
Copy link
Member

eteq commented Oct 10, 2019

This is a follow-on from #165. That issue asked for several IRAF functions, most of which probably belong better in specreduce. But the one part that I think belongs in specutils on that list is flux-calibration. My thinking is that specreduce sort of "ends" when you have an extracted spectrum, and standard/sensfunc and related flux calibration tasks are generally done on the already-extracted spectra.

So this is issue is to create the relevant functionality in specutils. The minimal version of this functionality is just an example in the docs or tutorial that starts with 1) an uncalibrated (i.e. unit of "counts" or similar) spectrum and 2) an uncalibrated standard star with the same observation setup, and 3) a calibrated spectrum (i.e. in flux units). It would then just use the ratio of 3/2 to create a sensitivity "spectrum" that is "flux per counts", and then multiple that by 1.

One step further is to replicate some of the options in sensfunc that amount to a fancier version of "take the 3/2 ratio", including things like sigma clipping, specifying regions to ignore, or fitting a polynomial model instead of using the spectrum directly. That is probably best implemented as a specutils.manipulation class, although the surrounding steps would still need to be documented as described above.

The final piece would be to actually include some "standard" standard spectra, like what IRAF comes packaged with. That requires some data-management considerations, and some discussion about what the best standard are these days.

The above could/should be broken into several issues, but I'm starting this one now to prompt discussion on the broad plan here

cc @keflavich @crawfordsm @camipacifici @nmearl @jradavenport

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants