# Why was detection.includeThresholdMultiplier=10 for old ProcessCcdTask? **URL:** \ **Category:** Data Management\ **Tags:** dm-dev\ **Created:** [January 25, 2016, 10:10pm UTC](https://www.rubin.community/t/why-was-detection-includethresholdmultiplier-10-for-old-processccdtask/500 "2016-01-25T22:10:47Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![rowen](https://sea2.discourse-cdn.com/flex002/user_avatar/www.rubin.community/rowen/32/52_2.png) [@rowen](https://www.rubin.community/u/rowen)\ **Post date:** [January 30, 2016, 12:51am UTC](https://www.rubin.community/t/why-was-detection-includethresholdmultiplier-10-for-old-processccdtask/500/7 "2016-01-30T00:51:16Z")
> [@price](#): > > I think the best way around that is to modify the PSF estimation to take only the brightest N (or F% of) sources. I hope you can move things in this direction, for it would make the pipeline much more stable (and get rid of the need for my includeThresholdMultiplier hack). PSF estimation is now done in `CharacterizeImageTask` and this uses the old detection config values of `includeThresholdMultiplier = 10` and `thresholdValue = 5`, thus only bright stars. The `CalibrationTask` now only measures sources for the `Src` catalog and for astrometric and photometric calibration. At the moment it uses `includeThresholdMultiplier = 1` and `thresholdValue = 5`, since @jbosch had suggested 5 sigma. I wonder if such a low threshold multiplier is asking for trouble (e.g. footprints that are too small). I figured we’d tweak these settings based on the results from running on real data, as will be reported [here](http://www.rubin.community/t/testing-dm-4692-the-new-processccdtask/507) but if you have any suggestions, please let me know. --- _[View the full topic](https://www.rubin.community/t/why-was-detection-includethresholdmultiplier-10-for-old-processccdtask/500)._