Consolidate with specutils

[pllim]

There might be some overlap with specutils, which is an affiliated astropy package. When this package is stable, consolidate redundancy between its API and ours.

http://specutils.readthedocs.org/en/latest/ https://github.com/astropy/specutils

[pllim]

Revisiting this and still see that there is no easy way to do this. Holding off for now. Need to think on this more.

[eteq]

@pllim - The core problem here is that in synphot a spectrum can be analytic, while Spectrum1D assumes it's data, right? What about having a model that basically wraps a Spectrum1D and interpolates over it?

There are a lot of use cases worth considering here, but the most straightforward one is basically "I have a spectrum from some random place, and want to extract synthetic photometry from it". That should be like a 1- or 2-liner. In most practical spectra I know of, you can do pretty well even with really pretty simplistic interpolation because the errors are likely to be dominated by spectral calibration issues anyway.

[pllim]

Empirical data with interpolation is essentially Tabular1D model that is already in astropy.modeling.tabular. It makes little sense for me to create a wrapper around Spectrum1D for this very specific case when it can already be done with Tabular1D.

If you started out with Spectrum1D, it takes one line to re-cast it as Tabular1D (it is just wavelength and flux data transfer from one class to another). As far as actual calculations is concerned, thus far, extra things supported in specutils like WCS and header metadata are unnecessary.

tl;dr -- I don't have a compelling use case to motivate me to wrap SourceSpectrum around Spectrum1D.

[eteq]

Oh, I meant it the other way around: use that to turn a Spectrum1D into a SourceSpectrum (and perhaps vice-versa when possible, although of course it won't always be). I see your point that it's a lot of work to re-factor, so I was offering this as a way to sort of get both at the same time.

I'm considering the typical user who has never read the astropy.modeling docs but does know what a spectrum is. They'll not think to create a model of that spectrum and pass it through, but if they already have a spectrum object, they might know to pass that in.

Or am I misunderstanding some subtlety @pllim ?

(Also, it might not be worth doing any of this until the specutils APE is done and through anyway... just in case something in Spectrum1D changes again)

[eteq]

To be very explicit, what I'm thinking is maybe a classmethod along the lines of SourceSpectrum.from_spectrum1d, and a doc example of using that to do just the use case I was describing above. I recognize this might be a "put my code where my mouth is" moment, though 😉

[pllim]

SourceSpectrum.from_spectrum1d

That is very possible. But I agree that we should wait till Spectrum1D public API is somewhat stable first. Maybe the timeline would emerge at the coordination meeting?

Thanks for the idea!