Fix Version/s: None
Sprint:DRP S17-5, DRP S17-6
Team:Data Release Production
The Statistics class predates many of the classes that we now use with it, and its design has slowly become a pain point that we tend to work around rather than fix. It's time for a redesign.
One centerpiece of that redesign should probably be
DM-2415: use ndarray instead of the image classes as the primary data class Statistics interacts with. That'd let us clean up a lot of helper classes (since it's easy to get an ndarray::Array from an Image, but hard to do the reverse in general). I'd also like to see Statistics interoperate with the new SpanSet functor interface somehow, which would let us compute statistics on a set of pixels whether those pixels are in an Image, a 2-d array, or a flattened 1-d array from e.g. a HeavyFootprint. And it'd be nice to address DM-3156 (support using a column from a Catalog even when that catalog is not contiguous) as well.
We should also update how Statistics is configured: since the Statistics was written, we've switched to a new configuration package (pex_config; yes, at one point it was new) that brings with it a new convention for configuring C++ objects. We've also made it possible to use keywords arguments in Python interfaces, which may make some configuration interfaces palatable that were not before.
Statistics also plays an important role in coaddition, because we use it to compute the value of each coadd pixel from the warped CCD-level pixels at the same position. There are currently some problems with this captured in
DM-4158 (provide more options for statistics to use in coaddition) and DM-9953 (we need more control over how we use the mask values of input pixels to set the mask values over output pixels). So this redesign will also include redesigning (to perhaps a lesser degree) the afw::math::statisticsStack functions that do this work.
Beyond those requirements, we of course need to keep at least most of the functionality of the current design; if you see something you think is vestigial, please check before removing it.
I do not think we want to be constrained by the current interface in any way - as long as the same functionality is supported somehow, breaking backwards compatibility is acceptable (and expected).
This ticket is to more concretely gather requirements from features of the current codebase and the above feature requests, and to produce an initial design sketch to meet those features. Implementation should be on one or more additional tickets.