# Questions about background subtraction and reference catalog

**URL:** <https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660>\
**Category:** Data Management\
**Created:** [April 12, 2019, 3:16pm UTC](https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660 "2019-04-12T15:16:53Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![sfu](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/sfu/32/3060_2.png) [@sfu](https://www.rubin.community/u/sfu)\
**Post date:** [April 12, 2019, 3:16pm UTC](https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660/1 "2019-04-12T15:16:53Z")

</div>

Dear all, I was wondering if I could ask some questions about LSST DM. I was reprocessing DECam archive data with `obs_decam` in weekly release `w_2019_05`.

1. `calexp`s are generated at different steps of the pipeline: `processCcd`, `assembleCoadd`, `detectCoaddSources`, etc. Are those `calexp` images all background-subtracted (default)? However, I found the config of `detectCoaddSources` has

```auto
# Do temporary wide (large-scale) background subtraction before footprint detection?                               
config.detection.doTempWideBackground=True

# Enable temporary local background subtraction? (see tempLocalBackground)                                         
config.detection.doTempLocalBackground=True

```

But the config of processCcd has

```auto
config.charImage.detection.doTempLocalBackground=False
config.charImage.detection.doTempWideBackground=False
config.calibrate.detection.doTempLocalBackground=False
config.calibrate.detection.doTempWideBackground=False

```

and the config of assembleCoadd has

```auto
config.clipDetection.doTempWideBackground=False
config.clipDetection.doTempLocalBackground=False

```

Do these mean that the `calexp`s generated by `processCcd` and `assembleCoadd` are not background-subtracted? Is the “background subtraction” used for the output catalog or for the generated `calexp` images?

1. For reference catalogs (Gaia, PS1, SDSS), which calibrate astrometry and photometry, they are used in `processCcd`, `jointcal`, `measureCoaddSources`. In `processCcd`, it is given by

```auto
config.calibrate.astromRefObjLoader
config.calibrate.photoRefObjLoader

```

In `jointcal`, it is given by

```auto
config.astrometryRefObjLoader
config.photometryRefObjLoader

```

But in `measureCoaddSources`, it is only given by (does it include both astrometry and photometry?)

```auto
config.match.refObjLoader

```

Are `processCcd`, `jointcal`, and `measureCoaddSources` the only three places we should import reference catalog?  
A related question is, how to import color terms (to convert color info from reference catalog to DECam)? In `processCcd`, we have

```auto
config.calibrate.photoCal.applyColorTerms = True
config.calibrate.photoCal.colorterms

```

But I don’t know how to include them in `jointcal` and `measureCoaddSources` configs. Can the color terms for these steps be inherited from `processCcd`?

Thank you.

---

<div class="post-metadata">

**Author:** ![parejkoj](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/parejkoj/32/138_2.png) [@parejkoj](https://www.rubin.community/u/parejkoj)\
**Post date:** [April 12, 2019, 6:45pm UTC](https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660/2 "2019-04-12T18:45:36Z")

</div>

> [@sfu](#):
>
> But I don’t know how to include them in `jointcal` and `measureCoaddSources` configs. Can the color terms for these steps be inherited from `processCcd` ?

First off, do you have decam colorterms? The alert pipelines group at UW would be very interested to get those into the stack!

Once you have decam colorterms for a given reference catalog (see `obs_subaru/configs/hsc/colorterms.py` for a working example), the only change you should need to make to use them with `jointcal` is to add a line like the following to the decam `jointcal` config:

```auto
config.colorterms.load(os.path.join(getPackageDir("obs_decam"), "config", "colorterms.py"))

```

---

<div class="post-metadata">

**Author:** ![mrawls](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/mrawls/32/2810_2.png) [@mrawls](https://www.rubin.community/u/mrawls)\
**Post date:** [April 12, 2019, 7:34pm UTC](https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660/3 "2019-04-12T19:34:57Z")

</div>

Excellent questions, Shenming! Welcome to the community forums.

For (1), My understanding is that the `doTempWideBackground` and `doTempLocalBackground` config settings are for special cases of how to handle background subtraction, and that all calexps (i.e., processed visit images) are typically background subtracted. But maybe others can chime in here with more details about this.

Regarding (2), I have only just realized that `obs_decam` lacks the color terms you describe. If you have DECam color terms for PS1 reference catalogs, I would be thrilled to add them as @parejkoj describes so we can both use them in `processCcd`. (Right now I believe it tries to apply color terms, but doesn’t find any, so effectively skips that step.)

---

<div class="post-metadata">

**Author:** ![sfu](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/sfu/32/3060_2.png) [@sfu](https://www.rubin.community/u/sfu)\
**Post date:** [April 12, 2019, 7:43pm UTC](https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660/5 "2019-04-12T19:43:20Z")

</div>

Thank you!

I was using DECam color terms (PS1 to DECam) from “grz Photometry” in [http://legacysurvey.org/dr7/description/](http://legacysurvey.org/dr7/description/)

I haven’t found other color terms for DECam yet. I will let you know once I find it.

---

<div class="post-metadata">

**Author:** ![sfu](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/sfu/32/3060_2.png) [@sfu](https://www.rubin.community/u/sfu)\
**Post date:** [April 12, 2019, 7:50pm UTC](https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660/6 "2019-04-12T19:50:28Z")

</div>

Thank you Meredith! This is my first time to post on community forum. Thanks for your answer to (1). For (2) I only have color terms from Legacy survey’s website. I will try to find other color terms and let you know.

---

<div class="post-metadata">

**Author:** ![jbosch](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/jbosch/32/12_2.png) [@jbosch](https://www.rubin.community/u/jbosch)\
**Post date:** [April 15, 2019, 2:00pm UTC](https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660/7 "2019-04-15T14:00:14Z")

</div>

> [@mrawls](#):
>
> For (1), My understanding is that the `doTempWideBackground` and `doTempLocalBackground` config settings are for special cases of how to handle background subtraction, and that all calexps (i.e., processed visit images) are typically background subtracted. But maybe others can chime in here with more details about this.

These options are primarily used when detecting on very deep coadd images; they’re different (not mutually exclusive) ways of intentionally, temporarily oversubtracting the wings of real objects in order to make blends smaller. I believe they should both be disabled for single-epoch processing. And even if they are enabled, after detection is completed those subtractions are reverted, so they should only affect the detected footprints, not the final background.

---

<div class="post-metadata">

**Author:** ![ebellm](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/ebellm/32/771_2.png) [@ebellm](https://www.rubin.community/u/ebellm)\
**Post date:** [April 19, 2019, 10:20pm UTC](https://www.rubin.community/t/questions-about-background-subtraction-and-reference-catalog/3660/8 "2019-04-19T22:20:44Z")

</div>

[https://iopscience.iop.org/article/10.3847/1538-4365/aaa3e2/pdf](https://iopscience.iop.org/article/10.3847/1538-4365/aaa3e2/pdf) provides a slightly more comprehensive set of DeCAM-PS1 color terms.
