Will there be 20 `meas_extension_*` packages?

Data Management
, ,
#1

It’s great to see the recent additions of photometry packages. In particular having implementations of “standard” reference photometry algorithms is really helpful.

Is the plan that each of these will get its own package? Will there be 20 different meas_extension_* packages?

#2

I don’t think we’ve really decided how to handle packaging for plugin implementations. I like the idea of migrating “extensions” packages into the core system when they become part of the default pipeline configuration, but that implies a lot of package churn just too keep up with configuration churn, which is bad. Right now the split between what is in meas_base and what is in an extensions package is pretty arbitrary. We also don’t have a way of distinguishing between extensions packages that provide measurement plugins (kron, shapeHSM, simpleShape) and those that provide something else (psfex).

I’d love to have someone RFC a proposal for how to organize these (and hopefully include something about what other packages should depend on them). I don’t have a coherent proposal in my head right now for how we ought to do it.

1 Like
#3

Our measurement framework is purposely designed as a plugin system so that additional measurement algorithms may be easily added. This is very different from systems such as SExtractor where the measurements are all integral to the main code and it is difficult to add new measurements.

The origin of the meas_extensions_* packages landing on LSST recently is HSC, and we’ve about exhausted our list:

  • meas_extensions_multiShapelet: measurement plugin used to support what is now meas_modelfit, but I think it’s been renamed in LSST;
  • meas_extensions_photometryKron: measurement plugin for Kron photometry, proposed for lsst_distrib;
  • meas_extensions_psfex: not a measurement plugin, but a PSF plugin, now used as the default PSF for LSST;
  • meas_extensions_rotAngle: measurement plugin to provide detector orientation, unnecessary given Wcs so not ported;
  • meas_extensions_shapeHSM: measurement plugin for HSM shapes from GalSim, will soon be in lsst_distrib;
  • meas_extensions_shapeMiyatake: measurement plugin for measuring shapes by Hironao Miyatake, is very slow and won’t be ported; and
  • meas_extensions_simpleShape: measurement plugin for Gaussian-weighted shapes, has been ported, will be used for HSC but I don’t see it being proposed for lsst_distrib.
#4

This is already in lsst_apps.