Page History

...

More information on forced photometry can be found in the Doxygen documentation for the meas_base package.

Simultaneous Multi-Object Measurement

While the old SourceMeasurementTask processed sources in the order set by the catalog it was given, SingleFrameMeasurementTask and ForcedMeasurementTask instead iterate over deblend families; within each family, the children are processed individually first, followed by the parent.  After the individual source measurements, plugins are then given an opportunity to measure all the children at once at once, using an interface that was not present in the old framework, using the same pixel values used in the parent measurement but writing outputs to per-child records.  This allows us to support plugins that fit multiple objects simultaneously (possibly using the earlier non-simultaneous measurements as input).

...

Currently we have no plugins that use this API.  Of our current algorihtmsalgorithms, only the PSF flux and the galaxy model flux are likely to ever be usable in this mode.

Python and C++ Measurement Plugins

TODO

Error-Handling and Diagnostics

While the new framework allows plugins to be written in Python, we expect that essentially all production plugins will be implemented in C++.  As a result, we've put much more effort into reducing the amount of boilerplate necessary to implement a C++ plugin (see the meas_base Doxygen documentation) than we have into reducing boilerplate for pure-Python plugins.  Even so, we're not entirely happy with this C++ interface, and plan to investigate some alternate designs in W15.  We also plan (in W15) to give the pure-Python plugin-writing experience much more attention - while the Python plugin interface itself will not change, we plan to add helper classes that will make it easier to implement new plugins.

Error-Handling and Diagnostics

One of the main areas we hope to improve on in the new framework is in the handling of errors in measurement algorithms.  Our first goal in this area is to ensure that no errors go unreported in detail: known failure modes should be reported as problem-specific flags, and any unexpected exception should result in a warning-level log message that would enable the problem to be tracked down as a bug.  These known failures are indicated by throwing an instance of lsst.meas.base.MeasurementError, which stores information about a problem-specific flag that should be set.  All other exceptions that propagate up to the measurement task will be logged as warnings.  For configuration errors that affect all sources to be measured on an exposure (i.e. running an algorithm that requires a Psf on an Exposure with no Psf), we will also provide custom exceptions that will be treated as fatal by the measurement framework (see 

For measurements accessed via slots, however, problem-specific flags are not available, and the user is forced to rely only on the "general failure" flag that is common to all algorithms.  This flag is often ambiguous, however, as it is used both when an algorithm has completely failed and has no valid output, and when a more minor error occurred that yields a valid but slightly less trustworthy result (for example, the SdssShape algorithm typically uses Gaussian-weighted moments, but can fall back to unweighted moments).  To address this, we plan to add a "general suspect" flag to all algorithms and the slot system, in addition to the "general failure" flag.  The failure flag (likely renamed to "*_flag_failed" from simply "*_flag") will be used to indicate a complete failure, and the new "suspect" flag ("*_flag_suspect").  This is slated for 

Missing Features and Known Problems

...