# public documents.sextractor_doc

## [/] [detect_background.tex] - Blame information for rev 19

Line No. Rev Author Line
1 19 gam
\section{Background estimation}
2
\label{chap:backest}
3
The value measured at each pixel is a function of the sum of a background''
4
signal and light coming from the objects of interest. To be able to detect
5
the faintest of these objects and also to measure accurately their fluxes, one needs
6
to have an accurate estimate of the background level in any place of the image,
7
a \emph{background map}.  Strictly speaking, there should be one background map per
8
object, that is, what would the image look like if that object was absent.
9
But, at least for detection, we may start by assuming that most discrete sources do not
10
overlap too severely, which is generally the case for high galactic latitude fields.
11
 
12
To construct the background map, {\sc SExtractor} makes a first pass through the pixel
13
data, computing an estimator for the local background in each mesh of a grid
14
that covers the whole frame.
15
The background estimator is a combination of $\kappa\,\sigma$ clipping and mode estimation,
16
similar to the one employed in Stetson's DAOPHOT program (see e.g. Da Costa 1992).
17
Briefly, the local background histogram is clipped iteratively until convergence at
18
$\pm 3\sigma$ around its median; \gam{Is the factor 3 configurable?} if $\sigma$ is changed by less than 20\% during that process,
19
we consider that the field is not crowded and we simply take the mean of the clipped histogram
20
as a value for the background; otherwise we estimate the mode with:
21
22
\label{eq:mode}
23
  \mbox{Mode} = 2.5 \times \mbox{Median} - 1.5 \times \mbox{Mean}
24
25
This expression is different from the usual approximation
26
27
  \mbox{Mode} = 3 \times \mbox{Median} - 2 \times \mbox{Mean}
28
29
(e.g. Kendall and Stuart 1977), but was found to be more accurate with our clipped
30
distributions, from the simulations we made. Fig. \ref{fig:modevsmean} shows that the expression of
31
the mode above is considerably less affected\footnote{Obviously in some very unfavorable cases
32
(like small meshes falling on bright stars), it leads to totally inaccurate results.} by crowding
33
than a simple clipped mean --- like the one used in FOCAS (Jarvis and Tyson 1981)
34
or by Infante (1987) --- but is $\approx 30\%$ noisier.
35
% For this reason
36
This is why
37
we revert to the clipped
38
mean in non-crowded fields.
39
 
40
%---------------------------------- Fig.modevsmean  --------------------------------
41
   \begin{figure}[htbp]
42
      \centerline{\includegraphics[width=12cm]{ps/modevsmean.ps}}
43
      \caption{
44
              Simulations of $32\times32$ pixels background meshes polluted by random Gaussian profiles.
45
              The true background lies at 0 ADU. While being slightly noisier, the clipped Mode''
46
              gives a more robust estimate than a clipped Mean in crowded regions.
47
              }
48
      \label{fig:modevsmean}
49
   \end{figure}
50
 
51
 
52
Once the grid is set up, a median filter can be applied to suppress possible
53
local overestimations due to bright stars. \gam{But sometimes the user will
54
  want to have the bright star be part of the background!} The resulting background map is then simply a (natural)
55
bicubic-spline interpolation between the meshes of the grid.
56
In parallel with the making of the background map, an \emph{RMS background map}, that is, a map of the
57
background noise in the image is produced. It will be used if the {\tt WEIGHT\_TYPE} parameter is
58
set different from {\tt NONE} (see \S\ref{chap:weighttype}).
59
 
60
\subsection{Configuration parameters and tuning}.
61
The choice of the mesh size ({\tt BACK\_SIZE}) is very important.
62
If it is too small, the background estimation is affected by the presence of objects and
63
random noise. Most importantly, part of the flux of the most extended
64
objects can be absorbed into the background map. If the mesh size is too large,
65
it cannot reproduce the small scale variations of the background. Therefore
66
a good compromise has to be found by the user. Typically, for reasonably
67
sampled images, a width\footnote{{\sc SExtractor} offers the
68
possibility of rectangular background meshes; but it is advised to use
69
square ones, except in some very special cases (rapidly varying background
70
in one direction for example).} of 32 to 256 pixels works well. The user has
71
some control over the background map by specifying the size
72
of the median filter ({\tt BACK\_FILTERSIZE}). A width
73
and height of 1 means that no filtering will be
74
applied to the background grid. Usually a size of $3\times3$ is enough, but it
75
may be necessary to use larger dimensions, especially to compensate, in part, for
76
small background mesh sizes, or in the case of large artefacts in the images.
77
Median filtering also helps reducing possible ringing effects of the bicubic-spline
78
around bright features. In some specific cases it might be desirable to median-filter
79
only background meshes whose original values exceed some threshold above the filtered-value.
80
This differential threshold is set by the {\tt BACK\_FILTERTHRESH} parameter, in ADUs.
81
It is important to note that all {\tt BACK\_} configuration parameters also affect the
82
background-RMS map.
83
 
84
By default, the computed background map is automatically subtracted
85
from the input image.  But there are some situations where it is more
86
appropriate to subtract a {\em constant} from the image (e.g., images
87
where the background noise distribution is strongly skewed).  The {\tt
88
BACK\_TYPE} configuration parameter (set by default to AUTO'') can
89
be switched to {\tt MANUAL} to allow for the value specified by the
90
{\tt BACK\_VALUE} parameter to be subtracted from the input
91
image. The default value is 0.
92
 
93
\gam{Describe {\tt MINIBACK}}
94
\label{chap:miniback}
95
 
96
\subsection{CPU cost}.
97
The background estimation operation can take a considerable time on the largest images,
98
e.g. a few minutes minutes for a $32000\times32000$ frame on a 2GHz
99
processor.
100
\gam{Update time?}
101