Page History

...

The main entry point for the new measurement framework is the new SingleFrameMeasurementTask class (in meas_base), which is intended as an almost drop-in replacement for the current SourceMeasurementTask (in meas_algorithms).  It's not drop-in replacement, because it has different plugins, a slightly different slot system, and an entirely different output schema - so we will use it everywhere SourceMeasurementTask was used before, but many when changing other additional configuration settings from their defaults - particularly those that deal with the measurement algorithms or their outputs, you'll need to be modified when retargeting the measurement task to keep it all workingcareful to use configuration values that are consistent with the measurement tasks you're useing.  We've provided configuration instructions to make that easy, as described in the next section.

...

For the present, you will continue to support the measurement.py task in meas_algorithms.  The measurement task used by processCcd and processCoadd is controlled by configurations items in CalibrateConfig and ProcessImageConfig, and can be retargeted back to the original meas_algorithms framework using the following python code:

from lsst.meas.algorithms.measurement import SourceMeasurementTask

root.calibrate.initialMeasurement.retarget(SourceMeasurementTask)

root.calibrate.measurement.retarget(SourceMeasurementTask)

root.measurement.retarget(SourceMeasurementTask)

Please note that the old measurement task writes tables with version=0 schemataschemas, and expects the plugins and fieldnames to use the old naming conventions.  For example, you must refer to the SdssCentroid plugin as 'centroid.sdss' and the value it stores in the output table will be afw.geom.PointD type with the name 'centroid.sdss'.  See the section "Schema Changes and Versioning" below below.

Some care has been taken to make all of the tasks called by processImage sensitive to which measurement framework and schema version are in use, so that the pipeline will work with either measurement task.  However, the developer should be careful when accessing or adding fields to the schemas to know which measurement task and which naming conventions are in effect.  For new code, we encourage the use of the meas_base measurement framework and schema version=1 tables.

NOTE:  If you are reading this document prior to the changeover to the end of Summer 14, just the opposite instructions will hold for using the New Framework.  That is, you must retarget the above 3 tasks using the SingleFrameMeasurementTask, which resides in lsst.meas.base.sfm.

Schema Changes and Versioning

...

• Names should start with "<package-abbr>_<class>", where "<package-abbr>" is an abbreviated version of the package name that provides enough information to specify the package location.  For instance, plugins in meas_base use "base" as their prefix, while those in ip_diffim would use simply "diffim".  The "class" part of the name is simply the name of the class that defines the algorithm, minus any explict "Plugin" or "Algorithm" suffix.  For instance, the field name prefix used by meas_base's SdssShapeAlgorithm class would be "base_SdssShape".
• Flux measurements should end with "_flux", even if that's repetitive with the name of the class (e.g. "base_PsfFlux_flux").
• Position measurements should consist of two fields, ending in "_x" and "_y".
• Ellipse measurements should be saved using the "Quadrupole" parametrization (even if they aren't measured as moments), using fields ending with "_xx", "_yy", and "_xy".
• Uncertainties on individual fields should be saved with names that end in "_<p>Sigma", where "<p>" is the suffix of the field the uncertainty corresponds to (e.g. "_fluxSigma" or "_xSigma").
• Uncertainty covariances should be saved with names that end in "_<p1>_<p2>_Cov", such as "_x_y_Cov" for the uncertainty on "_x" and "_y".
• Flag fields should have names like "_flag_<reason>", where "reason" is a camelCase string identifying what went wrong.  A special flag that is simply the algorithm prefix + "_flag" is additionally set for any fatal error (but this will likely be changed on

  Jira
  server JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 9da94fb6-5771-303d-a785-1b6c5ab0f2d2 key DM-464

  prior to the S14 release).

Aliases and Slots

We have added an alias feature to the Schema class, via an AliasMap object it holds.  Aliases are handled simply as an extra stage in Key lookup - when a Key is requested via a string, its beginning is compared against all aliases to see if it should be replaced.  Partial replacements are allowed, but only at the beginning, and multiple replacements are not.  For example, if the AliasMap includes the mapping "slot_PsfFlux"->"base_PsfFlux", then a Key lookup on "slot_PsfFlux_flux" will resolve to "base_PsfFlux_flux", but a lookup on "r_slot_PsfFlux_flux" will not be affected.  Because Key lookup happens implicitly when getting a value from a record via string, this makes it even more important to do Key lookup once in advance rather than use a string to access the same value repeatedly.

...

Note that this means that slot values can now be accessed via string, just like any normal measurement.

Forced Photometry

The new measurement framework adds several new Task classes for forced photometry, including the capability to perform forced photometry on coadds (long present on the HSC fork of the codebase but absent on the LSST side).  The new Tasks are:

• ForcedMeasurementTask, an analogue of SingleFrameMeasurementTask for forced measurements, used as a subtask by the command-line tasks below.  Users should rarely if ever have to use it directly, aside from configuring it as a part of those command-line tasks.
• BaseReferencesTask and CoaddSrcReferencesTask, which (respectively) define an interface for retrieving reference objects that correspond to a patch of sky and implement that interface using ProcessCoaddTask outputs as the reference objects.
• ForcedPhotImageTask, ForcedPhotCcdTask, and ForcedPhotCoaddTask are command-line driver tasks that mirror pipe_task's ProcessImageTask (base class; most of the implementation), ProcessCcdTask (specialization for CCD-level processing), and ProcessCoaddTask (specialization for coadd-level processing).  These delegate most of their work to the above two subtasks.

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

Simultaneous Multi-Object Measurement

...