+1 on removing orphaned code nobody uses.

If we do need a second algorithm, we should a new write one. SdssCentroid has its own problems, in particular that it's rather difficult to read/modify.

When I was a kid, statements like "always preferred' deserved some sort of testing, verification, and review.  I was not on the CC list for this one.  I have no problem dumping all but the "best" centroiding algorithm, but I would feel better if there was some sort of direct algorithm vs. algorithm test on LSS-ish data to use as the basis for such a decision.

Thanks for chiming in David Monet; I deliberately made you a "Watcher" on this RFC to solicit your opinion since I remembered this was your algorithm.
I thought you compared GaussianCentroid, SdssCentroid, NaiveCentroid and SExtractor once upon a time, and found that GaussianCentroid, SdssCentroid and SExtractor all performed about the same. Are you concerned that the comparison wasn't done on images from a large-aperture telescope, or on 30 sec images, or something else?

Thanks for including me as a Watcher.  One of the joys of being senile is that I forget the good and the bad equally.  It is not impossible that sometime in the distant past that I did some sort of 3-way comparison.  Rummaging through my e-mail archive does not find such a report.  Given the importance of the LSST centroiding algorithm, it seems reasonable to do the comparison again.  In my primitive world, I know how to use SExtractor on an image, but I know of no analagous way to use the LSST stack centroid or SDSS centroid algorithms.  I can try to find the time to do such a comparison, but I need assistance on how to get centroids from images.  It would seem reasonable to borrow some DEcam or Suprime images for such a test.  The images ought to be as similar to LSST as possible.  I think that the goal is to have written documentation of how the centroid choice was made that can be presented to the LSST user commuity as justification.  Were I in LSST management, I would want the images and results to be in the public domain so that if (when!) some clever youngster makes noise about why some other algorithm would be better, that the comparison can be repeated with the proposed algorithm.  I fear villagers armed with torches and pikes surrounding the LSST castle seeking revenge for almost all critical decisions.

A search of my e-mail revealed the attached plot you sent 2012-10-08, based on DECam 30-sec images processed with the LSST stack and SExtractor:

And the captions:

Top Panel: The black lines (filled symbol for X, open for Y) come from
the SExtractor solution and the magenta from centroid_naive.
Not a surprise. The FITS binary table header comments say
that the "naive" algorithm is "unweighted 3x3 first moment".
It is well known that functional fits produce better centroids
than image moments. This panel just quantifies this.

Middle Panel: X solutions (i.e., the 2K direction of the DECam CCDs)
for the four remaining algorithms. Note that the scale
is expanded compared to the top panel. Black is for
SExtractor, red for SDSS, green for GAUSS, and blue for
SHAPE.

Bottom Panel: Y (i.e., the 4K direction) solutions with same scale and
symbols as middle panel.

Gasp!  I am always humiliated when I see how clever I was in the past and how far I have fallen.  Yes, it appears that a reasonable test was done courtesy of Paul, Robert, and others.  The e-mail thread also discusses the astrometric impact of short exposures taken with DECam that found their way into the LSST SRD.  Perhaps I should take the Action Item to prepare a better document than the 10 year old e-mail thread and dump it somewhere in the LSST documentation quagmire.  The Executive Summary seems to be that Paul can proceed to dump the columns for a second centroid if he promises that the code has not changed in the last decade.

I had a quick look through the git commit logs for GaussianCentroid.cc (in meas_base and meas_algorithms) and I don't see any functional changes since 2012.

Adopted since David Monet agrees and no-one dissents.

Paul Price I think this ticket can be marked as implemented.