Question about background subtraction near bright and giant objects

Data Management
#1

Dear all,

We are using LSST DM v18 to process the data of galaxy clusters from DECam. We are mainly using the default settings of DM, and for background subtraction we just use the default setting.

We find in the output of processCCd (calexp) and assembleCoadd (deepCoadd/band_name/tract_number/patch_number.fits), the outer envelopes of bright giant galaxies and bright stars are over-subtracted. Here are some examples.

Example1: on the left is a coadded patch near the center of a cluster (r band), and on the right is a temporary exposure generated by makeCoaddTempExp (at the same patch).

fig1
fig1843×423 247 KB

Example2: a coadded image and a temporary exposure of another cluster. The cluster’s center galaxy (BCG) is at top right, one elliptical galaxy is the center, and a bright star is at bottom left. The black lines near the BCG comes from the edge of a CCD (the bleed trail from a bright star touched the edge of the CCD and caused this on the raw image).

fig2
fig21326×664 658 KB

Example3: stars.

fig3
fig31381×689 654 KB

How should we adjust the config files (of processCcd and coaddition) to avoid these?

Thank you.

PS: We also notice sometimes there are some diffuse faint vertical light perpendicular to the bleed trail: please see the two bright stars at top left (this is g band and we notice it in u band). Can it be cleaned by background subtraction?

fig4
fig41596×774 911 KB

Sometime we could see on calexp the background of one CCD chip was divided into 4 parts (top left, top right, bottom left, bottom right) but the difference is small. Do we need to adjust some settings in the config file to correct it? (Perhaps coaddition could automatically fix this?)

fig5
fig5523×1009 88.7 KB

Thanks.

#2

Just a note that most people are away for the holidays, so you may not get much of a response until after New Year’s.

#3

Thank you.

#4

Dear Shenming, I am having the same issue with a completely different dataset and tool. In my case, I am using Magellan/MegaCam and Sextractor+scamp+swarp to coadd the individual fits, but the haloes are also oversubtracted and look very similar to your posted images. I have tried nearly all parameters for bg subtraction but still am not totally convinced about the result. However my first guess would be to increase the mesh size for background determination, or use a constant bg value (perhaps from empty areas in the “sky” of your CCDs?).
Best wishes,
Matias Gomez.

#5

Dear Matias, thank you. We are not very sure about what parameters we should use and how to adjust the parameters for background measurement and subtraction in LSST DM config files (e.g. Which parameters could be related to the over-subtraction? If we adjust some parameters, would that affect de-blending? Should we add some background flux back after measurement?).

#6

Dear Shenming,
I wish I could be of more help, but actually I am myself rather new to this pipeline (in my case MegaCam) so I am not sure which of the many parameters I recommend you to change. That being said, in my images I have seen that over-subtraction comes from an ill-defined background. This happens for instance when you have large galaxy haloes and assume a mesh size that is comparable to this scale. I would in this case use as large a filter size as possible. You can also try to use a constant value (e.g. derived from the corners or any “empty” areas of your individual CCDs). I don’t think deblending should be affected, but like I said I am not an expert, so really wish someone can give more light on this.
Best wishes for 2020!

1 Like
#7

Thank you very much Matias. Happy New Year! Hopefully next week more researchers will be back and give advice on this.

#8

Dear Shenming,

This is an issue that appears in many contemporary imaging surveys and something I’ve been looking at for a while now. Matias is correct in that this type of oversubtraction is usually caused by an overly-aggressive sky subtraction algorithm that mistakenly assigns real source flux as sky, and attempts to subtract it. Owing to the manner in which a sky model is constructed, i.e., usually via an n-th order polynomial fit to the “sky” pixels, this leads to oversubtraction around bright sources, manifesting as negative-flux haloes or ‘divots’. In addition, it also leads to oversubtraction between bright objects in crowded fields, creating negative flux bridges.

An attempt to rectify this issue was made for HSC-SSP DR2, as can be seen in Figure 5 in Aihara et al. 2019 here: https://arxiv.org/abs/1905.12221. However, testing is still ongoing as to the best way to resolve this issue. In the short term, I agree with Matias that growing the background sky estimation window to a size of at least ~3x larger than your largest object of interest seems to resolve this issue for the most part. However, estimating sky on these large scales does leave you vulnerable to small-scale (high frequency) sky variations, and therefore may not be appropriate for smaller objects.

I am also new to the DM code base, and so can’t point you specifically to which flags you may want to change, but perhaps the discussion in Aihara et al. 2019 will help.

Best,
Lee Kelvin

2 Likes
#9

It’s important to recognise that this is a common problem (e.g., SDSS, Pan-STARRS, HSC, …) because sky subtraction is not trivial. You need to set the super-pixel size for the sky model to something appropriate for your particular science goals (e.g., small for point-sources, large for extended sources) and experiment to ensure you’re removing the sky, the whole sky, and nothing but the sky. The configuration options you want to play with for processCcd.py are:

  • charImage.background.binSize: super-pixel size for sky measurement
  • charImage.background.useApprox: approximate sky model using a Chebyshev?
  • charImage.background.approxOrderX: polynomial order for approximation

I would also encourage you to try the full-camera sky subtraction feature. To my knowledge, it hasn’t been applied to any camera other than HSC yet, but I don’t know of any reason it shouldn’t work, though it might take some fiddling and certainly some trial and error to discover suitable parameters.

2 Likes