ngmix centroid: switched to WCS in #741 — confirm correct, and any reason to keep HSM? #767
Description
Activity
Hey,
Let's make a little clarification, what is called WCS centroid is actually the coadd centroid. I think it would be better to call it this to make more explicit where it comes from.
So, this centroid is actually the one used to get the stamps in the first place and I think it would be good to see how this is done:- Coadd x,y locations are transformed to ra, dec
- ra, dec are transformed to single exposures x, y
- Those x, y are rounded in
sf_tools - A stamp is extracted around the rounded locations with a fixed size (meaning that there is padding if the object is close to an edge)
Using the coadd centroids is fine as long as the locations are computed in the exact same way as in
sf_tools. To do that, there are several options, some cleaner than others:- Looking into
sf_toolsand copy/paste how the rounding is done and be careful to handle the padding correctly - When extracting the stamp with
sf_tools, also extract the x, y location and more importantly the rounded part - Stop using
sf_tools(I am not sure if Sam still support the library so it might be good to switch), re-implement the stamp extraction and implement the propagation of the locations at the same time
Using the HSM centroid by-pass all this. It gives a pretty good prior and unlikely to fail (but can still fail in some cases, might be better to do it within the mcal loop). For very faint objects it might be tricky to get a prior. Using weighted moments would be significantly better than using adaptive moments because they cannot fail. The HSM centroid is not the only thing that get used though, it also gives a prior on the size and fluxe which can be very useful to make the fit faster and more stable. That being said, they are probably overwritten by the ngmix prior..
- added a commit that references this issue
on Jun 30, 2026 Hello Axel, thank you for clarifying the coadd centroid propagation procedure. This is what I did and I can confirm that the rounding is very deterministic and not jumpy, I did not investigate the padding in particular but I don't see why it would add instability.
I do not understand why the HSM path is a robust strategy, it feels to me like, in particular for faint objects, it adds a lot of noisiness as your centroid is tied to the noise realization and you discard all the astrometry information which connects different exposures. Please let me know if you see where my understanding is flawed.
thank you @aguinot. i understand your concern about calculating the coadd centroids consistently and have opened PR #811 that re-implements the
sf_toolsstamp extraction inshapepipe, wiring the rounded centroid through the vignette such that it is consumed directly by ngmix. i have also switched the nomenclature from "WCS centroid" to "coadd centroid" as you suggested. please take a look!Reacted by Axel Guinot- added a commit that references this issue
on Aug 31, 2026
Following Fabian's recommendation, #741 switches the ngmix metacal centroid from HSM adaptive-moment re-centering to the WCS (the catalog sky position projected through the WCS). Opening this to confirm with the group that the WCS centroid is the right choice, and to ask whether there's any reason to keep the HSM approach around before we remove that code path entirely (a separate, non-blocking PR).
For context — reassuringly, this is not a v2.0 regression: HSM moment-centroiding is long-standing inherited behavior, first introduced in 2020 (
bde89f5f) and carried through the 2023 module overhaul (441797e2) into bothdevelopand v2.0; the recent v2.0 work only made the centroid source selectable (0ee0e944).developcurrently uses HSM unconditionally — the WCS option arrives with #741.cc @aguinot
— Claude on behalf of Cail