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
The Dragon functionality from Gemini already works on NDData-like data, but it should be investigated if some of the functionality can be contributed directly to specreduce with a more agnostic approach to the use of NDData supported objects.
Just a couple of quick notes here to bring things up to date regarding the extra stuff we hang on our NDData-like objects (AstroData) that functions use.
We have a variance attribute that returns an ndarray, making life much easier when using the noise properties to perform the necessary mathematics. Since we store the variance as a VarianceUncertainty instance, this is straightforward to implement, but I've suggested in API enhancement: Provide a standard "variance" property in all NDUncertainty classes, accessible to the parent NDData astropy#10128 that this be a read-only attribute of NDData. (It's settable in our framework but the functions of interest here don't use that functionality.)
We have "descriptors" (callables that are attributes of the AstroData object) that provide information, e.g., dispersion_axis() describes the direction in which the spectrum is dispersed in a 2D spectrogram. I plan (once I have some time to do so) to remove these calls from the functions and instead have them as parameters of the function and decorate the functions in such a way that the parameter values get provided by the descriptors if an AstroData object, rather than an NDData object, is passed.
The Dragon functionality from Gemini already works on NDData-like data, but it should be investigated if some of the functionality can be contributed directly to specreduce with a more agnostic approach to the use of NDData supported objects.
@chris-simpson
The text was updated successfully, but these errors were encountered: