Instantiate Spectrum1D object with bin edges instead of bin centers

[eblur]

Want to be able to instantiate a Spectrum1D object with bin edges instead of bin centers.

For example, a particularly nasty X-ray spectrum might have:

import numpy as np
import astropy.units as u
ebin_edges = np.array([1.0, 2.0, 2.3, 3.0]) * u.keV
bin_counts = np.array([5.0, 8.0, 6.0]) # dimensionless "counts"

[eteq]

Bringing back this topic because it's hit a breaking point on the need to deal with #427 and #461 which both need to address this (the former is basically exactly this issue, while #461 it's more about defining a new "output" spectrum even though the input might be in "bin center" form)

The core problem is that some spectral conventions have the bin edges "implicit" meaning the edge is taken to be the average of the centers (and the edges are then inferred from the second-from-edge center). But that's not sufficient if you really know the bin edges (e.g. #427, meaning X-ray spectra).

But the WCS machinery at least right now assumes bin centers. What's not clear to me is if it's a relatively simple internal change to make it account for bin edges, or a major refactor. If the former, we should just do it, if the later, we should find a way to paper-over it to proceed with #427 and make a better fix later if possible.

cc @nmearl @astrofrog @SaOgaz @eblur

[eteq]

Note this also connects to the SpectralFrame discussions in that that might be the most natural place to deal with this. The end goal would be to make something like spec.wavelength.bin_edges possible. XRaySpectrum could then just point to that and do spec.bin_lo which is derived from that, ensuring everything all works smoothly together but keeping @eblur's goal of an xray-convenient object

[nmearl]

Note that currently, the fits wcs adapter class has a bin_edges property that calculates the edge from the bin centers (i.e. doesn't solve the issue of when you know what they are explicitly). Calling returns the pixel_to_world transformation using the edges instead of the centers.

[eteq]

Gotcha, @nmearl . So in principle it's an "implementation detail" whether the edges are stored or the centers are stored, so if we can make it work with the WCS/GWCS machinery maybe it's my "easier" case? Of course we still have to keep the initialization machinery as it stands (since users in OIR land are used to bin centers), but that could be changed to internally convert to the implicit edges (and transparently convert back to the centers as long as its all self-consistent)

Regardless, we need to write down somewhere what the center/edge conventions are, I'm realizing. But that can be a separate issue once we hash out the implementation details here.

[nmearl]

@eblur is this use case solved by the new bin edge support in #645?

[rosteen]

This capability has existed for a while, closing.