The question of how the refExtendedness column in the DP0.2 Objects table is calculated came up during the Delegate’s Assembly today, but we could not immediately answer it or find more information about it.
Could any DM/RDP team member help in either explaining how this parameter was calculated, or how we would trace back to the code where it was calculated?
We know from the DP0.2 Object table schema that refExtendedness is “Set to 1 for extended sources, 0 for point sources. Reference band.”, and that there are also per-band extendedness parameters.
We also know from the Forum topic on the Star-galaxy classifier that the paper Slater et al. (2020), “Morphological Star-Galaxy Separation” is generally a good resource for learning more about star/galaxy separation, and that the Data Management Science Pipelines Design Document (ls.st/ldm-151) has Section 6.20 on star/galaxy separation (which says this parameter will be a probability in the future, not boolean).
Objects are considered not extended if the product of the model flux with a configurable ratio is less than the PSF flux (see classification.py in meas_base). The default model flux in obs_lsst is cModel, and the ratio is 0.985 (see here), as it is in obs_subaru for HSC data.
Thank you Dan, that answered my question! Think I’m still misunderstanding something, though.
I found [ugrizy]_cModelFlux and [ugrizy]_psfFlux in the Objects table. But [ugrizy]_extendedness only approximately depends on the ratio of these two, there is still some overlap. In case I got the wrong column, I also iterated through all other combinations of cModelFlux, psfFlux, free_psfFlux, kronFlux, gaapOptimalFlux. Are the fluxes in the table and those going into the extendedness calculated at a different stage of processing, or what am I missing?
Hi all, I’ve been investigating the extendedness parameter, so thanks to @ktl, @dtaranu, and @chraab for chiming in on this.
I’ve started a new directory named “extendedness/” in the delegate-contributions-dp02 repo. I added one executed notebook that explores how the extendedness parameter is calculated. Additional notebooks exploring extendedness from other delegates would be very welcome in that directory.
Section 4 of that notebook might be particularly relevant to you @chraab, especially the last two figures in the notebook.
In S.4.1, I also find that the psfFlux / cModelFlux ratio being > 0.985 does not always mean the extendedness parameter is 0 in filters g, r, and i. Like you mention in your post above. I’m still not entirely sure why – maybe someone else can shed some light on this?
However, in S.4.2 I find that when I only consider the refBand – the reference band used for the refExtendedness parameter – then the psfFlux / cModelFlux ratio being > 0.985 does mean the refExtendedness parameter is 0.
The single-band extendedness ({band}_extendedness) is pre-computed from the ratio of {band}_free_cModelFlux and {band}_free_psfFlux in the measurement step. If you have a look at the schema for objectTable_tract, you’ll see that these columns all come from the meas table (i.e. deepCoadd_meas). Note that because of the definition of extendedness above, there are objects with negative psfFluxes that are considered extended; these are probably not reliable detections and you should generally use the refExtendedness instead anyway.
The non-free {band}_*Flux columns come from forced measurements, where the free parameters for each model are fixed to the values from the reference band. There is no single-band extendedness column based on those fluxes, in part because you can compute it yourself and/or adjust the threshold if necessary. Also, it would just be the same as refExtendedness in the reference band anyway, since the forced fluxes in the reference band are the same as the free fluxes.
I believe @jeffcarlin was looking into this recently but I’m not sure what he found.
Hi, do you know what is the aperture used to measured the fluxes used in the definition of extendedness? In fact, what is the aperture used for the calculation of all the magnitudes?
Hi @spedrosa, I think the answer is that the definition of extendedness does not use apertures, but model fits: the cModel and the PSF model fluxes. I believe all the aperture-based fluxes in the Object catalog are identified by their column name in the schema (e.g., g_ap03Flux is defined as the “Flux within 3.0-pixel aperture. Forced on g-band.”).
Dear @babel ,
This is indeed an interesting question: although the pipeline code that calculates extendedness describes it as a binary measure, the datatype for extendedness in the code is that of a Double ("D"). My impression is that there are no plans for changing the extendedness values from binary to a continuous range from 0 to 1, but the option to do so is available in the unlikely event that the need ever arises in the future. (Others who are more closely involved with writing the pipeline code should correct me if I am wrong! Thanks!)
We are transitioning over to the SingleFrameMomentsClassifierPlugin (@erykoff@arunkannawadi for more info) which should produce a more continuous measure, as it’s based on the chi2 of a fit.
Thanks @ktl for the doc link! I was confused why it wouldn’t show up, but that’s the reason!
Also, this does not use any of the work of Slater et al. (2020) since it is focused on the initial star selection for single-band, non-coadd images, so we have much more limited information (and the images are not nearly as deep).