\section{Miscellaneous Image Transformations}

\ifCPy

\cvCPyFunc{AdaptiveThreshold}
Applies an adaptive threshold to an array.

\cvdefC{
void cvAdaptiveThreshold(
\par const CvArr* src,\par CvArr* dst,\par double maxValue,\par
int adaptive\_method=CV\_ADAPTIVE\_THRESH\_MEAN\_C,\par
int thresholdType=CV\_THRESH\_BINARY,\par
int blockSize=3,\par double param1=5 );
}

\cvdefPy{AdaptiveThreshold(src,dst,maxValue, adaptive\_method=CV\_ADAPTIVE\_THRESH\_MEAN\_C, thresholdType=CV\_THRESH\_BINARY,blockSize=3,param1=5)-> None}

\begin{description}
\cvarg{src}{Source image}
\cvarg{dst}{Destination image}
\cvarg{maxValue}{Maximum value that is used with \texttt{CV\_THRESH\_BINARY} and \texttt{CV\_THRESH\_BINARY\_INV}}
\cvarg{adaptive\_method}{Adaptive thresholding algorithm to use: \texttt{CV\_ADAPTIVE\_THRESH\_MEAN\_C} or \texttt{CV\_ADAPTIVE\_THRESH\_GAUSSIAN\_C} (see the discussion)}
\cvarg{thresholdType}{Thresholding type; must be one of
\begin{description}
\cvarg{CV\_THRESH\_BINARY}{xxx}
\cvarg{CV\_THRESH\_BINARY\_INV}{xxx}
\end{description}}
\cvarg{blockSize}{The size of a pixel neighborhood that is used to calculate a threshold value for the pixel: 3, 5, 7, and so on}
\cvarg{param1}{The method-dependent parameter. For the methods \texttt{CV\_ADAPTIVE\_THRESH\_MEAN\_C} and \texttt{CV\_ADAPTIVE\_THRESH\_GAUSSIAN\_C} it is a constant subtracted from the mean or weighted mean (see the discussion), though it may be negative}
\end{description}

The function transforms a grayscale image to a binary image according to the formulas:

\begin{description}
\cvarg{CV\_THRESH\_BINARY}{\[ dst(x,y) = \fork{\texttt{maxValue}}{if $src(x,y) > T(x,y)$}{0}{otherwise} \]}
\cvarg{CV\_THRESH\_BINARY\_INV}{\[ dst(x,y) = \fork{0}{if $src(x,y) > T(x,y)$}{\texttt{maxValue}}{otherwise} \]}
\end{description}

where $T(x,y)$ is a threshold calculated individually for each pixel.

For the method \texttt{CV\_ADAPTIVE\_THRESH\_MEAN\_C} it is the mean of a $\texttt{blockSize} \times \texttt{blockSize}$ pixel neighborhood, minus \texttt{param1}.

For the method \texttt{CV\_ADAPTIVE\_THRESH\_GAUSSIAN\_C} it is the weighted sum (gaussian) of a $\texttt{blockSize} \times \texttt{blockSize}$ pixel neighborhood, minus \texttt{param1}.

\cvCPyFunc{CvtColor}
Converts an image from one color space to another.

\cvdefC{
void cvCvtColor(
\par const CvArr* src,
\par CvArr* dst,
\par int code );
}\cvdefPy{CvtColor(src,dst,code)-> None}

\begin{description}
\cvarg{src}{The source 8-bit (8u), 16-bit (16u) or single-precision floating-point (32f) image}
\cvarg{dst}{The destination image of the same data type as the source. The number of channels may be different}
\cvarg{code}{Color conversion operation that can be specifed using \texttt{CV\_ \textit{src\_color\_space} 2 \textit{dst\_color\_space}} constants (see below)}
\end{description}

The function converts the input image from one color
space to another. The function ignores the \texttt{colorModel} and
\texttt{channelSeq} fields of the \texttt{IplImage} header, so the
source image color space should be specified correctly (including
order of the channels in the case of RGB space. For example, BGR means 24-bit
format with $B_0, G_0, R_0, B_1, G_1, R_1, ...$ layout
whereas RGB means 24-format with $R_0, G_0, B_0, R_1, G_1, B_1, ...$
layout).

The conventional range for R,G,B channel values is:

\begin{itemize}
\item 0 to 255 for 8-bit images
\item 0 to 65535 for 16-bit images and
\item 0 to 1 for floating-point images.
\end{itemize}

Of course, in the case of linear transformations the range can be
specific, but in order to get correct results in the case of non-linear
transformations, the input image should be scaled.

The function can do the following transformations:

\begin{itemize}
\item Transformations within RGB space like adding/removing the alpha channel, reversing the channel order, conversion to/from 16-bit RGB color (R5:G6:B5 or R5:G5:B5), as well as conversion to/from grayscale using:
\[
\text{RGB[A] to Gray:} Y \leftarrow 0.299 \cdot R + 0.587 \cdot G + 0.114 \cdot B
\]
and
\[
\text{Gray to RGB[A]:} R \leftarrow Y, G \leftarrow Y, B \leftarrow Y, A \leftarrow 0
\]

The conversion from a RGB image to gray is done with:
\begin{lstlisting}
cvCvtColor(src ,bwsrc, CV_RGB2GRAY)
\end{lstlisting}

\item RGB $\leftrightarrow$ CIE XYZ.Rec 709 with D65 white point (\texttt{CV\_BGR2XYZ, CV\_RGB2XYZ, CV\_XYZ2BGR, CV\_XYZ2RGB}):
\[
\begin{bmatrix}
X \\
Y \\
Z
\end{bmatrix}
\leftarrow
\begin{bmatrix}
0.412453 & 0.357580 & 0.180423\\
0.212671 & 0.715160 & 0.072169\\
0.019334 & 0.119193 & 0.950227
\end{bmatrix}
\cdot
\begin{bmatrix}
R \\
G \\
B
\end{bmatrix}
\]
\[
\begin{bmatrix}
R \\
G \\
B
\end{bmatrix}
\leftarrow
\begin{bmatrix}
3.240479 & -1.53715 & -0.498535\\
-0.969256 &  1.875991 & 0.041556\\
0.055648 & -0.204043 & 1.057311
\end{bmatrix}
\cdot
\begin{bmatrix}
X \\
Y \\
Z
\end{bmatrix}
\]
$X$, $Y$ and $Z$ cover the whole value range (in the case of floating-point images $Z$ may exceed 1).

\item RGB $\leftrightarrow$ YCrCb JPEG (a.k.a. YCC) (\texttt{CV\_BGR2YCrCb, CV\_RGB2YCrCb, CV\_YCrCb2BGR, CV\_YCrCb2RGB})
\[ Y \leftarrow 0.299 \cdot R + 0.587 \cdot G + 0.114 \cdot B \]
\[  Cr \leftarrow (R-Y) \cdot 0.713 + delta \]
\[  Cb \leftarrow (B-Y) \cdot 0.564 + delta \]
\[  R \leftarrow Y + 1.403 \cdot (Cr - delta) \]
\[  G \leftarrow Y - 0.344 \cdot (Cr - delta) - 0.714 \cdot (Cb - delta) \]
\[  B \leftarrow Y + 1.773 \cdot (Cb - delta) \]
where
\[
delta = \left\{
\begin{array}{l l}
128 & \mbox{for 8-bit images}\\
32768 & \mbox{for 16-bit images}\\
0.5 & \mbox{for floating-point images}
\end{array} \right.
\]
Y, Cr and Cb cover the whole value range.

\item RGB $\leftrightarrow$ HSV (\texttt{CV\_BGR2HSV, CV\_RGB2HSV, CV\_HSV2BGR, CV\_HSV2RGB})
in the case of 8-bit and 16-bit images
R, G and B are converted to floating-point format and scaled to fit the 0 to 1 range
\[ V \leftarrow max(R,G,B) \]

\[ S \leftarrow \fork{\frac{V-min(R,G,B)}{V}}{if $V \neq 0$}{0}{otherwise} \]
\[ H \leftarrow \forkthree
{{60(G - B)}/{S}}{if $V=R$}
{{120+60(B - R)}/{S}}{if $V=G$}
{{240+60(R - G)}/{S}}{if $V=B$} \]
if $H<0$ then $H \leftarrow H+360$

On output $0 \leq V \leq 1$, $0 \leq S \leq 1$, $0 \leq H \leq 360$.

The values are then converted to the destination data type:
\begin{description}
\item[8-bit images]
\[ V \leftarrow 255 V, S \leftarrow 255 S, H \leftarrow H/2 \text{(to fit to 0 to 255)} \]
\item[16-bit images (currently not supported)]
\[ V <- 65535 V, S <- 65535 S, H <- H \]
\item[32-bit images]
H, S, V are left as is
\end{description}

\item RGB $\leftrightarrow$ HLS (\texttt{CV\_BGR2HLS, CV\_RGB2HLS, CV\_HLS2BGR, CV\_HLS2RGB}).
in the case of 8-bit and 16-bit images
R, G and B are converted to floating-point format and scaled to fit the 0 to 1 range.
\[ V_{max} \leftarrow {max}(R,G,B) \]
\[ V_{min} \leftarrow {min}(R,G,B) \]
\[ L \leftarrow \frac{V_{max} + V_{min}}{2} \]
\[ S \leftarrow \fork
{\frac{V_{max} - V_{min}}{V_{max} + V_{min}}}{if $L < 0.5$}
{\frac{V_{max} - V_{min}}{2 - (V_{max} + V_{min})}}{if $L \ge 0.5$} \]
\[ H \leftarrow \forkthree
{{60(G - B)}/{S}}{if $V_{max}=R$}
{{120+60(B - R)}/{S}}{if $V_{max}=G$}
{{240+60(R - G)}/{S}}{if $V_{max}=B$} \]
if $H<0$ then $H \leftarrow H+360$
On output $0 \leq L \leq 1$, $0 \leq S \leq 1$, $0 \leq H \leq 360$.

The values are then converted to the destination data type:
\begin{description}
\item[8-bit images]
\[ V \leftarrow 255 V, S \leftarrow 255 S, H \leftarrow H/2 \text{(to fit to 0 to 255)} \]
\item[16-bit images (currently not supported)]
\[ V <- 65535 V, S <- 65535 S, H <- H \]
\item[32-bit images]
H, S, V are left as is
\end{description}

\item RGB $\leftrightarrow$ CIE L*a*b* (\texttt{CV\_BGR2Lab, CV\_RGB2Lab, CV\_Lab2BGR, CV\_Lab2RGB})
in the case of 8-bit and 16-bit images
R, G and B are converted to floating-point format and scaled to fit the 0 to 1 range
\[ \vecthree{X}{Y}{Z} \leftarrow \vecthreethree
{0.412453}{0.357580}{0.180423}
{0.212671}{0.715160}{0.072169}
{0.019334}{0.119193}{0.950227}
\cdot
\vecthree{R}{G}{B} \]
\[ X \leftarrow X/X_n, \text{where} X_n = 0.950456 \]
\[ Z \leftarrow Z/Z_n, \text{where} Z_n = 1.088754 \]
\[ L \leftarrow \fork
{116*Y^{1/3}-16}{for $Y>0.008856$}
{903.3*Y}{for $Y \le 0.008856$} \]
\[ a \leftarrow 500 (f(X)-f(Y)) + delta \]
\[ b \leftarrow 200 (f(Y)-f(Z)) + delta \]
where
\[f(t)=\fork
{t^{1/3}}{for $t>0.008856$}
{7.787 t+16/116}{for $t<=0.008856$} \]
and
\[ delta = \fork{128}{for 8-bit images}{0}{for floating-point images} \]
On output $0 \leq L \leq 100$, $-127 \leq a \leq 127$, $-127 \leq b \leq 127$

The values are then converted to the destination data type:
\begin{description}
\item[8-bit images]
\[L \leftarrow L*255/100, a \leftarrow a + 128, b \leftarrow b + 128\]
\item[16-bit images] currently not supported
\item[32-bit images]
L, a, b are left as is
\end{description}

\item RGB $\leftrightarrow$ CIE L*u*v* (\texttt{CV\_BGR2Luv, CV\_RGB2Luv, CV\_Luv2BGR, CV\_Luv2RGB})
in the case of 8-bit and 16-bit images
R, G and B are converted to floating-point format and scaled to fit 0 to 1 range
\[ \vecthree{X}{Y}{Z} \leftarrow \vecthreethree
{0.412453}{0.357580}{0.180423}
{0.212671}{0.715160}{0.072169}
{0.019334}{0.119193}{0.950227}
\cdot
\vecthree{R}{G}{B} \]
\[ L \leftarrow \fork
{116 Y^{1/3}}{for $Y>0.008856$}
{903.3 Y}{for $Y<=0.008856$} \]
\[ u' \leftarrow 4*X/(X + 15*Y + 3 Z) \]
\[ v' \leftarrow 9*Y/(X + 15*Y + 3 Z) \]
\[ u \leftarrow 13*L*(u' - u_n) \quad \text{where} \quad u_n=0.19793943 \]
\[ v \leftarrow 13*L*(v' - v_n) \quad \text{where} \quad v_n=0.46831096 \]
On output $0 \leq L \leq 100$, $-134 \leq u \leq 220$, $-140 \leq v \leq 122$.

The values are then converted to the destination data type:
\begin{description}
\item[8-bit images]
\[L \leftarrow 255/100 L, u \leftarrow 255/354 (u + 134), v \leftarrow 255/256 (v + 140) \]
\item[16-bit images] currently not supported
\item[32-bit images] L, u, v are left as is
\end{description}

The above formulas for converting RGB to/from various color spaces have been taken from multiple sources on Web, primarily from
the Ford98
at the Charles Poynton site.

\item Bayer $\rightarrow$ RGB (\texttt{CV\_BayerBG2BGR, CV\_BayerGB2BGR, CV\_BayerRG2BGR, CV\_BayerGR2BGR, CV\_BayerBG2RGB, CV\_BayerGB2RGB, CV\_BayerRG2RGB, CV\_BayerGR2RGB}) The Bayer pattern is widely used in CCD and CMOS cameras. It allows one to get color pictures from a single plane where R,G and B pixels (sensors of a particular component) are interleaved like this:

\[
\newcommand{\Rcell}{\color{red}R}
\newcommand{\Gcell}{\color{green}G}
\newcommand{\Bcell}{\color{blue}B}
\definecolor{BackGray}{rgb}{0.8,0.8,0.8}
\begin{array}{ c c c c c }
\Rcell&\Gcell&\Rcell&\Gcell&\Rcell\\
\Gcell&\colorbox{BackGray}{\Bcell}&\colorbox{BackGray}{\Gcell}&\Bcell&\Gcell\\
\Rcell&\Gcell&\Rcell&\Gcell&\Rcell\\
\Gcell&\Bcell&\Gcell&\Bcell&\Gcell\\
\Rcell&\Gcell&\Rcell&\Gcell&\Rcell
\end{array}
\]

The output RGB components of a pixel are interpolated from 1, 2 or
4 neighbors of the pixel having the same color. There are several
modifications of the above pattern that can be achieved by shifting
the pattern one pixel left and/or one pixel up. The two letters
$C_1$ and $C_2$
in the conversion constants
\texttt{CV\_Bayer} $ C_1 C_2 $ \texttt{2BGR}
and
\texttt{CV\_Bayer} $ C_1 C_2 $ \texttt{2RGB}
indicate the particular pattern
type - these are components from the second row, second and third
columns, respectively. For example, the above pattern has very
popular "BG" type.
\end{itemize}

\cvCPyFunc{DistTransform}
Calculates the distance to the closest zero pixel for all non-zero pixels of the source image.

\cvdefC{
void cvDistTransform( \par const CvArr* src,\par CvArr* dst,\par int distance\_type=CV\_DIST\_L2,\par int mask\_size=3,\par const float* mask=NULL,\par CvArr* labels=NULL );
}
\cvdefPy{DistTransform(src,dst,distance\_type=CV\_DIST\_L2,mask\_size=3,mask=None,labels=NULL)-> None}

\begin{description}
\cvarg{src}{8-bit, single-channel (binary) source image}
\cvarg{dst}{Output image with calculated distances (32-bit floating-point, single-channel)}
\cvarg{distance\_type}{Type of distance; can be \texttt{CV\_DIST\_L1, CV\_DIST\_L2, CV\_DIST\_C} or \texttt{CV\_DIST\_USER}}
\cvarg{mask\_size}{Size of the distance transform mask; can be 3 or 5. in the case of \texttt{CV\_DIST\_L1} or \texttt{CV\_DIST\_C} the parameter is forced to 3, because a $3\times 3$ mask gives the same result as a $5\times 5 $ yet it is faster}
\cvarg{mask}{User-defined mask in the case of a user-defined distance, it consists of 2 numbers (horizontal/vertical shift cost, diagonal shift cost) in the case ofa  $3\times 3$ mask and 3 numbers (horizontal/vertical shift cost, diagonal shift cost, knight's move cost) in the case of a $5\times 5$ mask}
\cvarg{labels}{The optional output 2d array of integer type labels, the same size as \texttt{src} and \texttt{dst}}
\end{description}

The function calculates the approximated
distance from every binary image pixel to the nearest zero pixel.
For zero pixels the function sets the zero distance, for others it
finds the shortest path consisting of basic shifts: horizontal,
vertical, diagonal or knight's move (the latest is available for a
$5\times 5$ mask). The overall distance is calculated as a sum of these
basic distances. Because the distance function should be symmetric,
all of the horizontal and vertical shifts must have the same cost (that
is denoted as \texttt{a}), all the diagonal shifts must have the
same cost (denoted \texttt{b}), and all knight's moves must have
the same cost (denoted \texttt{c}). For \texttt{CV\_DIST\_C} and
\texttt{CV\_DIST\_L1} types the distance is calculated precisely,
whereas for \texttt{CV\_DIST\_L2} (Euclidian distance) the distance
can be calculated only with some relative error (a $5\times 5$ mask
gives more accurate results), OpenCV uses the values suggested in
\cite{Borgefors86}:

\begin{tabular}{| c | c | c |}
\hline
\texttt{CV\_DIST\_C}  & $(3\times 3)$ & a = 1, b = 1\\ \hline
\texttt{CV\_DIST\_L1} & $(3\times 3)$ & a = 1, b = 2\\ \hline
\texttt{CV\_DIST\_L2} & $(3\times 3)$ & a=0.955, b=1.3693\\ \hline
\texttt{CV\_DIST\_L2} & $(5\times 5)$ & a=1, b=1.4, c=2.1969\\ \hline
\end{tabular}

And below are samples of the distance field (black (0) pixel is in the middle of white square) in the case of a user-defined distance:

User-defined $3 \times 3$ mask (a=1, b=1.5)

\begin{tabular}{| c | c | c | c | c | c | c |}
\hline
4.5 & 4 & 3.5 & 3 & 3.5 & 4 & 4.5\\ \hline
4 & 3 & 2.5 & 2 & 2.5 & 3 & 4\\ \hline
3.5 & 2.5 & 1.5 & 1 & 1.5 & 2.5 & 3.5\\ \hline
3 & 2 & 1 &     & 1 & 2 & 3\\ \hline
3.5 & 2.5 & 1.5 & 1 & 1.5 & 2.5 & 3.5\\ \hline
4 & 3 & 2.5 & 2 & 2.5 & 3 & 4\\ \hline
4.5 & 4 & 3.5 & 3 & 3.5 & 4 & 4.5\\ \hline
\end{tabular}

User-defined $5 \times 5$ mask (a=1, b=1.5, c=2)

\begin{tabular}{| c | c | c | c | c | c | c |}
\hline
4.5 & 3.5 & 3 & 3 & 3 & 3.5 & 4.5\\ \hline
3.5 & 3 & 2 & 2 & 2 & 3 & 3.5\\ \hline
3 & 2 & 1.5 & 1 & 1.5 & 2 & 3\\ \hline
3 & 2 & 1 & & 1 & 2 & 3\\ \hline
3 & 2 & 1.5 & 1 & 1.5 & 2 & 3\\ \hline
3.5 & 3 & 2 & 2 & 2 & 3 & 3.5\\ \hline
4 & 3.5 & 3 & 3 & 3 & 3.5 & 4\\ \hline
\end{tabular}

Typically, for a fast, coarse distance estimation \texttt{CV\_DIST\_L2},
a $3\times 3$ mask is used, and for a more accurate distance estimation
\texttt{CV\_DIST\_L2}, a $5\times 5$ mask is used.

When the output parameter \texttt{labels} is not \texttt{NULL}, for
every non-zero pixel the function also finds the nearest connected
component consisting of zero pixels. The connected components
themselves are found as contours in the beginning of the function.

In this mode the processing time is still O(N), where N is the number of
pixels. Thus, the function provides a very fast way to compute approximate
Voronoi diagram for the binary image.

\cvclass{CvConnectedComp}

\ifC
\begin{lstlisting}
typedef struct CvConnectedComp
{
    double area;    /* area of the segmented component */
    CvScalar value; /* average color of the connected component */
    CvRect rect;    /* ROI of the segmented component */
    CvSeq* contour; /* optional component boundary
                      (the contour might have child contours corresponding to the holes) */
} CvConnectedComp;

\end{lstlisting}
\fi

\ifPy
Connected component, represented as a tuple (area, value, rect), where
area is the area of the component as a float, value is the average color
as a \cross{CvScalar}, and rect is the ROI of the component, as a \cross{CvRect}.
\fi

\cvCPyFunc{FloodFill}
Fills a connected component with the given color.

\cvdefC{
void cvFloodFill(\par CvArr* image,\par CvPoint seed\_point,\par CvScalar new\_val,\par
                  CvScalar lo\_diff=cvScalarAll(0),\par CvScalar up\_diff=cvScalarAll(0),\par
                  CvConnectedComp* comp=NULL,\par int flags=4,\par CvArr* mask=NULL );

}
\cvdefPy{FloodFill(image,seed\_point,new\_val,lo\_diff=(0,0,0,0),up\_diff=(0,0,0,0),flags=4,mask=NULL)-> comp}

\begin{description}
\cvarg{image}{Input 1- or 3-channel, 8-bit or floating-point image. It is modified by the function unless the \texttt{CV\_FLOODFILL\_MASK\_ONLY} flag is set (see below)}
\cvarg{seed\_point}{The starting point}
\cvarg{new\_val}{New value of the repainted domain pixels}
\cvarg{lo\_diff}{Maximal lower brightness/color difference between the currently observed pixel and one of its neighbors belonging to the component, or a seed pixel being added to the component. In the case of 8-bit color images it is a packed value}
\cvarg{up\_diff}{Maximal upper brightness/color difference between the currently observed pixel and one of its neighbors belonging to the component, or a seed pixel being added to the component. In the case of 8-bit color images it is a packed value}
\ifC % {
\cvarg{comp}{Pointer to the structure that the function fills with the information about the repainted domain.
Note that the function does not fill \texttt{comp->contour} field. The boundary of the filled component can be retrieved from the output mask image using \cvCPyCross{FindContours}}
\else % }{
\cvarg{comp}{Returned connected component for the repainted domain. Note that the function does not fill \texttt{comp->contour} field. The boundary of the filled component can be retrieved from the output mask image using \cvCPyCross{FindContours}}
\fi % }
\cvarg{flags}{The operation flags. Lower bits contain connectivity value, 4 (by default) or 8, used within the function. Connectivity determines which neighbors of a pixel are considered. Upper bits can be 0 or a combination of the following flags:
\begin{description}
  \cvarg{CV\_FLOODFILL\_FIXED\_RANGE}{if set, the difference between the current pixel and seed pixel is considered, otherwise the difference between neighbor pixels is considered (the range is floating)}
  \cvarg{CV\_FLOODFILL\_MASK\_ONLY}{if set, the function does not fill the image (\texttt{new\_val} is ignored), but fills the mask (that must be non-NULL in this case)}
\end{description}}
\cvarg{mask}{Operation mask, should be a single-channel 8-bit image, 2 pixels wider and 2 pixels taller than \texttt{image}. If not NULL, the function uses and updates the mask, so the user takes responsibility of initializing the \texttt{mask} content. Floodfilling can't go across non-zero pixels in the mask, for example, an edge detector output can be used as a mask to stop filling at edges. It is possible to use the same mask in multiple calls to the function to make sure the filled area do not overlap. \textbf{Note}: because the mask is larger than the filled image, a pixel in \texttt{mask} that corresponds to $(x,y)$ pixel in \texttt{image} will have coordinates $(x+1,y+1)$ }
\end{description}

The function fills a connected component starting from the seed point with the specified color. The connectivity is determined by the closeness of pixel values. The pixel at $(x,y)$ is considered to belong to the repainted domain if:

\begin{description}

\item[grayscale image, floating range] \[
src(x',y')-\texttt{lo\_diff} <= src(x,y) <= src(x',y')+\texttt{up\_diff} \]

\item[grayscale image, fixed range] \[
src(seed.x,seed.y)-\texttt{lo\_diff}<=src(x,y)<=src(seed.x,seed.y)+\texttt{up\_diff} \]

\item[color image, floating range]
\[ src(x',y')_r-\texttt{lo\_diff}_r<=src(x,y)_r<=src(x',y')_r+\texttt{up\_diff}_r \]
\[ src(x',y')_g-\texttt{lo\_diff}_g<=src(x,y)_g<=src(x',y')_g+\texttt{up\_diff}_g \]
\[ src(x',y')_b-\texttt{lo\_diff}_b<=src(x,y)_b<=src(x',y')_b+\texttt{up\_diff}_b \]

\item[color image, fixed range]
\[ src(seed.x,seed.y)_r-\texttt{lo\_diff}_r<=src(x,y)_r<=src(seed.x,seed.y)_r+\texttt{up\_diff}_r \]
\[ src(seed.x,seed.y)_g-\texttt{lo\_diff}_g<=src(x,y)_g<=src(seed.x,seed.y)_g+\texttt{up\_diff}_g \]
\[ src(seed.x,seed.y)_b-\texttt{lo\_diff}_b<=src(x,y)_b<=src(seed.x,seed.y)_b+\texttt{up\_diff}_b \]
\end{description}

where $src(x',y')$ is the value of one of pixel neighbors. That is, to be added to the connected component, a pixel's color/brightness should be close enough to the:
\begin{itemize}
  \item color/brightness of one of its neighbors that are already referred to the connected component in the case of floating range
  \item color/brightness of the seed point in the case of fixed range.
\end{itemize}

\cvCPyFunc{Inpaint}
Inpaints the selected region in the image.

\cvdefC{
void cvInpaint( \par const CvArr* src, \par const CvArr* mask, \par CvArr* dst,
                \par double inpaintRadius, \par int flags);

}\cvdefPy{Inpaint(src,mask,dst,inpaintRadius,flags) -> None}

\begin{description}
\cvarg{src}{The input 8-bit 1-channel or 3-channel image.}
\cvarg{mask}{The inpainting mask, 8-bit 1-channel image. Non-zero pixels indicate the area that needs to be inpainted.}
\cvarg{dst}{The output image of the same format and the same size as input.}
\cvarg{inpaintRadius}{The radius of circlular neighborhood of each point inpainted that is considered by the algorithm.}
\cvarg{flags}{The inpainting method, one of the following:
\begin{description}
\cvarg{CV\_INPAINT\_NS}{Navier-Stokes based method.}
\cvarg{CV\_INPAINT\_TELEA}{The method by Alexandru Telea \cite{Telea04}}
\end{description}}
\end{description}

The function reconstructs the selected image area from the pixel near the area boundary. The function may be used to remove dust and scratches from a scanned photo, or to remove undesirable objects from still images or video.

\cvCPyFunc{Integral}
Calculates the integral of an image.

\cvdefC{
void cvIntegral(
\par const CvArr* image,
\par CvArr* sum,
\par CvArr* sqsum=NULL,
\par CvArr* tiltedSum=NULL );
}\cvdefPy{Integral(image,sum,sqsum=NULL,tiltedSum=NULL)-> None}

\begin{description}
\cvarg{image}{The source image, $W\times H$, 8-bit or floating-point (32f or 64f)}
\cvarg{sum}{The integral image, $(W+1)\times (H+1)$, 32-bit integer or double precision floating-point (64f)}
\cvarg{sqsum}{The integral image for squared pixel values, $(W+1)\times (H+1)$, double precision floating-point (64f)}
\cvarg{tiltedSum}{The integral for the image rotated by 45 degrees, $(W+1)\times (H+1)$, the same data type as \texttt{sum}}
\end{description}

The function calculates one or more integral images for the source image as following:

\[
\texttt{sum}(X,Y) = \sum_{x<X,y<Y} \texttt{image}(x,y)
\]

\[
\texttt{sqsum}(X,Y) = \sum_{x<X,y<Y} \texttt{image}(x,y)^2
\]

\[
\texttt{tiltedSum}(X,Y) = \sum_{y<Y,abs(x-X+1)\leq Y-y-1} \texttt{image}(x,y)
\]

Using these integral images, one may calculate sum, mean and standard deviation over a specific up-right or rotated rectangular region of the image in a constant time, for example:

\[
\sum_{x_1<=x<x_2, \, y_1<=y<y_2} = \texttt{sum}(x_2,y_2)-\texttt{sum}(x_1,y_2)-\texttt{sum}(x_2,y_1)+\texttt{sum}(x_1,x_1)
\]

It makes possible to do a fast blurring or fast block correlation with variable window size, for example. In the case of multi-channel images, sums for each channel are accumulated independently.

\cvCPyFunc{PyrMeanShiftFiltering}
Does meanshift image segmentation

\cvdefC{

void cvPyrMeanShiftFiltering( \par const CvArr* src, \par CvArr* dst,
     \par double sp, \par double sr, \par int max\_level=1,
     \par CvTermCriteria termcrit=\par cvTermCriteria(CV\_TERMCRIT\_ITER+CV\_TERMCRIT\_EPS,5,1));

}\cvdefPy{PyrMeanShiftFiltering(src,dst,sp,sr,max\_level=1,termcrit=(CV\_TERMCRIT\_ITER+CV\_TERMCRIT\_EPS,5,1))-> None}

\begin{description}
\cvarg{src}{The source 8-bit, 3-channel image.}
\cvarg{dst}{The destination image of the same format and the same size as the source.}
\cvarg{sp}{The spatial window radius.}
\cvarg{sr}{The color window radius.}
\cvarg{max\_level}{Maximum level of the pyramid for the segmentation.}
\cvarg{termcrit}{Termination criteria: when to stop meanshift iterations.}
\end{description}

The function implements the filtering
stage of meanshift segmentation, that is, the output of the function is
the filtered "posterized" image with color gradients and fine-grain
texture flattened. At every pixel $(X,Y)$ of the input image (or
down-sized input image, see below) the function executes meanshift
iterations, that is, the pixel $(X,Y)$ neighborhood in the joint
space-color hyperspace is considered:

\[
(x,y): X-\texttt{sp} \le x \le X+\texttt{sp} , Y-\texttt{sp} \le y \le Y+\texttt{sp} , ||(R,G,B)-(r,g,b)||  \le  \texttt{sr}
\]

where \texttt{(R,G,B)} and \texttt{(r,g,b)} are the vectors of color components at \texttt{(X,Y)} and \texttt{(x,y)}, respectively (though, the algorithm does not depend on the color space used, so any 3-component color space can be used instead). Over the neighborhood the average spatial value \texttt{(X',Y')} and average color vector \texttt{(R',G',B')} are found and they act as the neighborhood center on the next iteration:

$(X,Y)~(X',Y'), (R,G,B)~(R',G',B').$

After the iterations over, the color components of the initial pixel (that is, the pixel from where the iterations started) are set to the final value (average color at the last iteration):

$I(X,Y) <- (R*,G*,B*)$

Then $\texttt{max\_level}>0$ , the gaussian pyramid of
$\texttt{max\_level}+1$ levels is built, and the above procedure is run
on the smallest layer. After that, the results are propagated to the
larger layer and the iterations are run again only on those pixels where
the layer colors differ much ( $>\texttt{sr}$ ) from the lower-resolution
layer, that is, the boundaries of the color regions are clarified. Note,
that the results will be actually different from the ones obtained by
running the meanshift procedure on the whole original image (i.e. when
$\texttt{max\_level}==0$ ).

\cvCPyFunc{PyrSegmentation}
Implements image segmentation by pyramids.

\cvdefC{
void cvPyrSegmentation(\par IplImage* src,\par IplImage* dst,\par
                        CvMemStorage* storage,\par CvSeq** comp,\par
                        int level,\par double threshold1,\par double threshold2 );
}\cvdefPy{PyrSegmentation(src,dst,storage,level,threshold1,threshold2)-> comp}

\begin{description}
\cvarg{src}{The source image}
\cvarg{dst}{The destination image}
\cvarg{storage}{Storage; stores the resulting sequence of connected components}
\cvarg{comp}{Pointer to the output sequence of the segmented components}
\cvarg{level}{Maximum level of the pyramid for the segmentation}
\cvarg{threshold1}{Error threshold for establishing the links}
\cvarg{threshold2}{Error threshold for the segments clustering}
\end{description}

The function implements image segmentation by pyramids. The pyramid builds up to the level \texttt{level}. The links between any pixel \texttt{a} on level \texttt{i} and its candidate father pixel \texttt{b} on the adjacent level are established if
$p(c(a),c(b))<threshold1$.
After the connected components are defined, they are joined into several clusters.
Any two segments A and B belong to the same cluster, if $p(c(A),c(B))<threshold2$.
If the input image has only one channel, then $p(c^1,c^2)=|c^1-c^2|$.
If the input image has three channels (red, green and blue), then
\[
  p(c^1,c^2) = 0.30 (c^1_r - c^2_r) +
               0.59 (c^1_g - c^2_g) +
               0.11 (c^1_b - c^2_b).
\]

There may be more than one connected component per a cluster. The images \texttt{src} and \texttt{dst} should be 8-bit single-channel or 3-channel images or equal size.

\cvCPyFunc{Threshold}
Applies a fixed-level threshold to array elements.

\cvdefC{
double cvThreshold(
\par const CvArr* src,
\par CvArr* dst,
\par double threshold,
\par double maxValue,
\par int thresholdType );
}
\cvdefPy{Threshold(src,dst,threshold,maxValue,thresholdType)-> None}

\begin{description}
\cvarg{src}{Source array (single-channel, 8-bit or 32-bit floating point)}
\cvarg{dst}{Destination array; must be either the same type as \texttt{src} or 8-bit}
\cvarg{threshold}{Threshold value}
\cvarg{maxValue}{Maximum value to use with \texttt{CV\_THRESH\_BINARY} and \texttt{CV\_THRESH\_BINARY\_INV} thresholding types}
\cvarg{thresholdType}{Thresholding type (see the discussion)}
\end{description}

The function applies fixed-level thresholding
to a single-channel array. The function is typically used to get a
bi-level (binary) image out of a grayscale image (\cvCPyCross{CmpS} could
be also used for this purpose) or for removing a noise, i.e. filtering
out pixels with too small or too large values. There are several
types of thresholding that the function supports that are determined by
\texttt{thresholdType}:

\begin{description}
\cvarg{CV\_THRESH\_BINARY}{\[ \texttt{dst}(x,y) = \fork{\texttt{maxValue}}{if $\texttt{src}(x,y) > \texttt{threshold}$}{0}{otherwise} \]}
\cvarg{CV\_THRESH\_BINARY\_INV}{\[ \texttt{dst}(x,y) = \fork{0}{if $\texttt{src}(x,y) > \texttt{threshold}$}{\texttt{maxValue}}{otherwise} \]}
\cvarg{CV\_THRESH\_TRUNC}{\[ \texttt{dst}(x,y) = \fork{\texttt{threshold}}{if $\texttt{src}(x,y) > \texttt{threshold}$}{\texttt{src}(x,y)}{otherwise} \]}
\cvarg{CV\_THRESH\_TOZERO}{\[ \texttt{dst}(x,y) = \fork{\texttt{src}(x,y)}{if $\texttt{src}(x,y) > \texttt{threshold}$}{0}{otherwise} \]}
\cvarg{CV\_THRESH\_TOZERO\_INV}{\[ \texttt{dst}(x,y) = \fork{0}{if $\texttt{src}(x,y) > \texttt{threshold}$}{\texttt{src}(x,y)}{otherwise} \]}
\end{description}

Also, the special value \texttt{CV\_THRESH\_OTSU} may be combined with
one of the above values. In this case the function determines the optimal threshold
value using Otsu's algorithm and uses it instead of the specified \texttt{thresh}.
The function returns the computed threshold value.
Currently, Otsu's method is implemented only for 8-bit images.

\includegraphics[width=0.5\textwidth]{pics/threshold.png}

\fi

\ifCpp

\cvCppFunc{adaptiveThreshold}
Applies an adaptive threshold to an array.

\cvdefCpp{void adaptiveThreshold( const Mat\& src, Mat\& dst, double maxValue,\par
                        int adaptiveMethod, int thresholdType,\par
                        int blockSize, double C );}
\begin{description}
\cvarg{src}{Source 8-bit single-channel image}
\cvarg{dst}{Destination image; will have the same size and the same type as \texttt{src}}
\cvarg{maxValue}{The non-zero value assigned to the pixels for which the condition is satisfied. See the discussion}
\cvarg{adaptiveMethod}{Adaptive thresholding algorithm to use,
   \texttt{ADAPTIVE\_THRESH\_MEAN\_C} or \texttt{ADAPTIVE\_THRESH\_GAUSSIAN\_C} (see the discussion)}
\cvarg{thresholdType}{Thresholding type; must be one of \texttt{THRESH\_BINARY} or \texttt{THRESH\_BINARY\_INV}}
\cvarg{blockSize}{The size of a pixel neighborhood that is used to calculate a threshold value for the pixel: 3, 5, 7, and so on}
\cvarg{C}{The constant subtracted from the mean or weighted mean (see the discussion); normally, it's positive, but may be zero or negative as well}
\end{description}

The function transforms a grayscale image to a binary image according to the formulas:

\begin{description}
\cvarg{THRESH\_BINARY}{\[ dst(x,y) = \fork{\texttt{maxValue}}{if $src(x,y) > T(x,y)$}{0}{otherwise} \]}
\cvarg{THRESH\_BINARY\_INV}{\[ dst(x,y) = \fork{0}{if $src(x,y) > T(x,y)$}{\texttt{maxValue}}{otherwise} \]}
\end{description}

where $T(x,y)$ is a threshold calculated individually for each pixel.

\begin{enumerate}
    \item
For the method \texttt{ADAPTIVE\_THRESH\_MEAN\_C} the threshold value $T(x,y)$ is the mean of a $\texttt{blockSize} \times \texttt{blockSize}$ neighborhood of $(x, y)$, minus \texttt{C}.
    \item
For the method \texttt{ADAPTIVE\_THRESH\_GAUSSIAN\_C} the threshold value $T(x, y)$ is the weighted sum (i.e. cross-correlation with a Gaussian window) of a $\texttt{blockSize} \times \texttt{blockSize}$ neighborhood of $(x, y)$, minus \texttt{C}. The default sigma (standard deviation) is used for the specified \texttt{blockSize}, see \cvCppCross{getGaussianKernel}.
\end{enumerate}

The function can process the image in-place.

See also: \cvCppCross{threshold}, \cvCppCross{blur}, \cvCppCross{GaussianBlur}

\cvCppFunc{cvtColor}
Converts image from one color space to another

\cvdefCpp{void cvtColor( const Mat\& src, Mat\& dst, int code, int dstCn=0 );}
\begin{description}
\cvarg{src}{The source image, 8-bit unsigned, 16-bit unsigned (\texttt{CV\_16UC...}) or single-precision floating-point}
\cvarg{dst}{The destination image; will have the same size and the same depth as \texttt{src}}
\cvarg{code}{The color space conversion code; see the discussion}
\cvarg{dstCn}{The number of channels in the destination image; if the parameter is 0, the number of the channels will be derived automatically from \texttt{src} and the \texttt{code}}
\end{description}

The function converts the input image from one color
space to another. In the case of transformation to-from RGB color space the ordering of the channels should be specified explicitly (RGB or BGR).

The conventional ranges for R, G and B channel values are:

\begin{itemize}
 \item 0 to 255 for \texttt{CV\_8U} images
 \item 0 to 65535 for \texttt{CV\_16U} images and
 \item 0 to 1 for \texttt{CV\_32F} images.
\end{itemize}

Of course, in the case of linear transformations the range does not matter,
but in the non-linear cases the input RGB image should be normalized to the proper value range in order to get the correct results, e.g. for RGB$\rightarrow$L*u*v* transformation. For example, if you have a 32-bit floating-point image directly converted from 8-bit image without any scaling, then it will have 0..255 value range, instead of the assumed by the function 0..1. So, before calling \texttt{cvtColor}, you need first to scale the image down:
\begin{lstlisting}
img *= 1./255;
cvtColor(img, img, CV_BGR2Luv);
\end{lstlisting}

The function can do the following transformations:

\begin{itemize}
 \item Transformations within RGB space like adding/removing the alpha channel, reversing the channel order, conversion to/from 16-bit RGB color (R5:G6:B5 or R5:G5:B5), as well as conversion to/from grayscale using:
 \[
 \text{RGB[A] to Gray:}\quad Y \leftarrow 0.299 \cdot R + 0.587 \cdot G + 0.114 \cdot B
 \]
 and
 \[
 \text{Gray to RGB[A]:}\quad R \leftarrow Y, G \leftarrow Y, B \leftarrow Y, A \leftarrow 0
 \]

The conversion from a RGB image to gray is done with:
\begin{lstlisting}
cvtColor(src, bwsrc, CV_RGB2GRAY);
\end{lstlisting}

Some more advanced channel reordering can also be done with \cvCppCross{mixChannels}.

 \item RGB $\leftrightarrow$ CIE XYZ.Rec 709 with D65 white point (\texttt{CV\_BGR2XYZ, CV\_RGB2XYZ, CV\_XYZ2BGR, CV\_XYZ2RGB}):
 \[
 \begin{bmatrix}
 X \\
 Y \\
 Z
 \end{bmatrix}
 \leftarrow
 \begin{bmatrix}
0.412453 & 0.357580 & 0.180423\\
0.212671 & 0.715160 & 0.072169\\
0.019334 & 0.119193 & 0.950227
 \end{bmatrix}
 \cdot
 \begin{bmatrix}
 R \\
 G \\
 B
 \end{bmatrix}
 \]
 \[
 \begin{bmatrix}
 R \\
 G \\
 B
 \end{bmatrix}
 \leftarrow
 \begin{bmatrix}
3.240479 & -1.53715 & -0.498535\\
-0.969256 &  1.875991 & 0.041556\\
0.055648 & -0.204043 & 1.057311
 \end{bmatrix}
 \cdot
 \begin{bmatrix}
 X \\
 Y \\
 Z
 \end{bmatrix}
 \]
$X$, $Y$ and $Z$ cover the whole value range (in the case of floating-point images $Z$ may exceed 1).

 \item RGB $\leftrightarrow$ YCrCb JPEG (a.k.a. YCC) (\texttt{CV\_BGR2YCrCb, CV\_RGB2YCrCb, CV\_YCrCb2BGR, CV\_YCrCb2RGB})
 \[ Y \leftarrow 0.299 \cdot R + 0.587 \cdot G + 0.114 \cdot B \]
 \[  Cr \leftarrow (R-Y) \cdot 0.713 + delta \]
 \[  Cb \leftarrow (B-Y) \cdot 0.564 + delta \]
 \[  R \leftarrow Y + 1.403 \cdot (Cr - delta) \]
 \[  G \leftarrow Y - 0.344 \cdot (Cr - delta) - 0.714 \cdot (Cb - delta) \]
 \[  B \leftarrow Y + 1.773 \cdot (Cb - delta) \]
where
 \[
  delta = \left\{
  \begin{array}{l l}
  128 & \mbox{for 8-bit images}\\
  32768 & \mbox{for 16-bit images}\\
  0.5 & \mbox{for floating-point images}
  \end{array} \right.
 \]
Y, Cr and Cb cover the whole value range.

 \item RGB $\leftrightarrow$ HSV (\texttt{CV\_BGR2HSV, CV\_RGB2HSV, CV\_HSV2BGR, CV\_HSV2RGB})
  in the case of 8-bit and 16-bit images
  R, G and B are converted to floating-point format and scaled to fit the 0 to 1 range
  \[ V \leftarrow max(R,G,B) \]

\[ S \leftarrow \fork{\frac{V-min(R,G,B)}{V}}{if $V \neq 0$}{0}{otherwise} \]
\[ H \leftarrow \forkthree
{{60(G - B)}/{S}}{if $V=R$}
{{120+60(B - R)}/{S}}{if $V=G$}
{{240+60(R - G)}/{S}}{if $V=B$} \]
if $H<0$ then $H \leftarrow H+360$

On output $0 \leq V \leq 1$, $0 \leq S \leq 1$, $0 \leq H \leq 360$.

The values are then converted to the destination data type:
\begin{description}
\item[8-bit images]
\[ V \leftarrow 255 V, S \leftarrow 255 S, H \leftarrow H/2 \text{(to fit to 0 to 255)} \]
\item[16-bit images (currently not supported)]
\[ V <- 65535 V, S <- 65535 S, H <- H \]
\item[32-bit images]
H, S, V are left as is
\end{description}

 \item RGB $\leftrightarrow$ HLS (\texttt{CV\_BGR2HLS, CV\_RGB2HLS, CV\_HLS2BGR, CV\_HLS2RGB}).
  in the case of 8-bit and 16-bit images
  R, G and B are converted to floating-point format and scaled to fit the 0 to 1 range.
  \[ V_{max} \leftarrow {max}(R,G,B) \]
  \[ V_{min} \leftarrow {min}(R,G,B) \]
  \[ L \leftarrow \frac{V_{max} + V_{min}}{2} \]
  \[ S \leftarrow \fork
    {\frac{V_{max} - V_{min}}{V_{max} + V_{min}}}{if $L < 0.5$}
    {\frac{V_{max} - V_{min}}{2 - (V_{max} + V_{min})}}{if $L \ge 0.5$} \]
  \[ H \leftarrow \forkthree
  {{60(G - B)}/{S}}{if $V_{max}=R$}
  {{120+60(B - R)}/{S}}{if $V_{max}=G$}
  {{240+60(R - G)}/{S}}{if $V_{max}=B$} \]
  if $H<0$ then $H \leftarrow H+360$
On output $0 \leq L \leq 1$, $0 \leq S \leq 1$, $0 \leq H \leq 360$.

The values are then converted to the destination data type:
\begin{description}
\item[8-bit images]
\[ V \leftarrow 255\cdot V, S \leftarrow 255\cdot S, H \leftarrow H/2\; \text{(to fit to 0 to 255)} \]
\item[16-bit images (currently not supported)]
\[ V <- 65535\cdot V, S <- 65535\cdot S, H <- H \]
\item[32-bit images]
H, S, V are left as is
\end{description}

 \item RGB $\leftrightarrow$ CIE L*a*b* (\texttt{CV\_BGR2Lab, CV\_RGB2Lab, CV\_Lab2BGR, CV\_Lab2RGB})
  in the case of 8-bit and 16-bit images
  R, G and B are converted to floating-point format and scaled to fit the 0 to 1 range
\[ \vecthree{X}{Y}{Z} \leftarrow \vecthreethree
{0.412453}{0.357580}{0.180423}
{0.212671}{0.715160}{0.072169}
{0.019334}{0.119193}{0.950227}
\cdot
\vecthree{R}{G}{B} \]
\[ X \leftarrow X/X_n, \text{where} X_n = 0.950456 \]
\[ Z \leftarrow Z/Z_n, \text{where} Z_n = 1.088754 \]
\[ L \leftarrow \fork
{116*Y^{1/3}-16}{for $Y>0.008856$}
{903.3*Y}{for $Y \le 0.008856$} \]
\[ a \leftarrow 500 (f(X)-f(Y)) + delta \]
\[ b \leftarrow 200 (f(Y)-f(Z)) + delta \]
where
\[f(t)=\fork
{t^{1/3}}{for $t>0.008856$}
{7.787 t+16/116}{for $t\leq 0.008856$} \]
and
\[ delta = \fork{128}{for 8-bit images}{0}{for floating-point images} \]
On output $0 \leq L \leq 100$, $-127 \leq a \leq 127$, $-127 \leq b \leq 127$

The values are then converted to the destination data type:
\begin{description}
\item[8-bit images]
\[L \leftarrow L*255/100,\; a \leftarrow a + 128,\; b \leftarrow b + 128\]
\item[16-bit images] currently not supported
\item[32-bit images]
L, a, b are left as is
\end{description}

 \item RGB $\leftrightarrow$ CIE L*u*v* (\texttt{CV\_BGR2Luv, CV\_RGB2Luv, CV\_Luv2BGR, CV\_Luv2RGB})
  in the case of 8-bit and 16-bit images
  R, G and B are converted to floating-point format and scaled to fit 0 to 1 range
  \[ \vecthree{X}{Y}{Z} \leftarrow \vecthreethree
{0.412453}{0.357580}{0.180423}
{0.212671}{0.715160}{0.072169}
{0.019334}{0.119193}{0.950227}
\cdot
\vecthree{R}{G}{B} \]
\[ L \leftarrow \fork
{116 Y^{1/3}}{for $Y>0.008856$}
{903.3 Y}{for $Y\leq 0.008856$} \]
\[ u' \leftarrow 4*X/(X + 15*Y + 3 Z) \]
\[ v' \leftarrow 9*Y/(X + 15*Y + 3 Z) \]
\[ u \leftarrow 13*L*(u' - u_n) \quad \text{where} \quad u_n=0.19793943 \]
\[ v \leftarrow 13*L*(v' - v_n) \quad \text{where} \quad v_n=0.46831096 \]
On output $0 \leq L \leq 100$, $-134 \leq u \leq 220$, $-140 \leq v \leq 122$.

The values are then converted to the destination data type:
\begin{description}
\item[8-bit images]
\[L \leftarrow 255/100 L,\; u \leftarrow 255/354 (u + 134),\; v \leftarrow 255/256 (v + 140) \]
\item[16-bit images] currently not supported
\item[32-bit images] L, u, v are left as is
\end{description}

The above formulas for converting RGB to/from various color spaces have been taken from multiple sources on Web, primarily from the Charles Poynton site \url{http://www.poynton.com/ColorFAQ.html}

 \item Bayer $\rightarrow$ RGB (\texttt{CV\_BayerBG2BGR, CV\_BayerGB2BGR, CV\_BayerRG2BGR, CV\_BayerGR2BGR, CV\_BayerBG2RGB, CV\_BayerGB2RGB, CV\_BayerRG2RGB, CV\_BayerGR2RGB}) The Bayer pattern is widely used in CCD and CMOS cameras. It allows one to get color pictures from a single plane where R,G and B pixels (sensors of a particular component) are interleaved like this:

\[
\newcommand{\Rcell}{\color{red}R}
\newcommand{\Gcell}{\color{green}G}
\newcommand{\Bcell}{\color{blue}B}
\definecolor{BackGray}{rgb}{0.8,0.8,0.8}
\begin{array}{ c c c c c }
\Rcell&\Gcell&\Rcell&\Gcell&\Rcell\\
\Gcell&\colorbox{BackGray}{\Bcell}&\colorbox{BackGray}{\Gcell}&\Bcell&\Gcell\\
\Rcell&\Gcell&\Rcell&\Gcell&\Rcell\\
\Gcell&\Bcell&\Gcell&\Bcell&\Gcell\\
\Rcell&\Gcell&\Rcell&\Gcell&\Rcell
\end{array}
\]

The output RGB components of a pixel are interpolated from 1, 2 or
4 neighbors of the pixel having the same color. There are several
modifications of the above pattern that can be achieved by shifting
the pattern one pixel left and/or one pixel up. The two letters
$C_1$ and $C_2$
in the conversion constants
\texttt{CV\_Bayer} $ C_1 C_2 $ \texttt{2BGR}
and
\texttt{CV\_Bayer} $ C_1 C_2 $ \texttt{2RGB}
indicate the particular pattern
type - these are components from the second row, second and third
columns, respectively. For example, the above pattern has very
popular "BG" type.
\end{itemize}

\cvCppFunc{distanceTransform}
Calculates the distance to the closest zero pixel for each pixel of the source image.

\cvdefCpp{void distanceTransform( const Mat\& src, Mat\& dst,\par
                        int distanceType, int maskSize );\newline
void distanceTransform( const Mat\& src, Mat\& dst, Mat\& labels,\par
                        int distanceType, int maskSize );}
\begin{description}
\cvarg{src}{8-bit, single-channel (binary) source image}
\cvarg{dst}{Output image with calculated distances; will be 32-bit floating-point, single-channel image of the same size as \texttt{src}}
\cvarg{distanceType}{Type of distance; can be \texttt{CV\_DIST\_L1, CV\_DIST\_L2} or \texttt{CV\_DIST\_C}}
\cvarg{maskSize}{Size of the distance transform mask; can be 3, 5 or \texttt{CV\_DIST\_MASK\_PRECISE} (the latter option is only supported by the first of the functions). In the case of \texttt{CV\_DIST\_L1} or \texttt{CV\_DIST\_C} distance type the parameter is forced to 3, because a $3\times 3$ mask gives the same result as a $5\times 5$ or any larger aperture.}
\cvarg{labels}{The optional output 2d array of labels - the discrete Voronoi diagram; will have type \texttt{CV\_32SC1} and the same size as \texttt{src}. See the discussion}
\end{description}

The functions \texttt{distanceTransform} calculate the approximate or precise
distance from every binary image pixel to the nearest zero pixel.
(for zero image pixels the distance will obviously be zero).

When \texttt{maskSize == CV\_DIST\_MASK\_PRECISE} and \texttt{distanceType == CV\_DIST\_L2}, the function runs the algorithm described in \cite{Felzenszwalb04}.

In other cases the algorithm \cite{Borgefors86} is used, that is,
for pixel the function finds the shortest path to the nearest zero pixel
consisting of basic shifts: horizontal,
vertical, diagonal or knight's move (the latest is available for a
$5\times 5$ mask). The overall distance is calculated as a sum of these
basic distances. Because the distance function should be symmetric,
all of the horizontal and vertical shifts must have the same cost (that
is denoted as \texttt{a}), all the diagonal shifts must have the
same cost (denoted \texttt{b}), and all knight's moves must have
the same cost (denoted \texttt{c}). For \texttt{CV\_DIST\_C} and
\texttt{CV\_DIST\_L1} types the distance is calculated precisely,
whereas for \texttt{CV\_DIST\_L2} (Euclidian distance) the distance
can be calculated only with some relative error (a $5\times 5$ mask
gives more accurate results). For \texttt{a}, \texttt{b} and \texttt{c}
OpenCV uses the values suggested in the original paper:

\begin{tabular}{| c | c | c |}
\hline
\texttt{CV\_DIST\_C}  & $(3\times 3)$ & a = 1, b = 1\\ \hline
\texttt{CV\_DIST\_L1} & $(3\times 3)$ & a = 1, b = 2\\ \hline
\texttt{CV\_DIST\_L2} & $(3\times 3)$ & a=0.955, b=1.3693\\ \hline
\texttt{CV\_DIST\_L2} & $(5\times 5)$ & a=1, b=1.4, c=2.1969\\ \hline
\end{tabular}

Typically, for a fast, coarse distance estimation \texttt{CV\_DIST\_L2},
a $3\times 3$ mask is used, and for a more accurate distance estimation
\texttt{CV\_DIST\_L2}, a $5\times 5$ mask or the precise algorithm is used.
Note that both the precise and the approximate algorithms are linear on the number of pixels.

The second variant of the function does not only compute the minimum distance for each pixel $(x, y)$,
but it also identifies the nearest the nearest connected
component consisting of zero pixels. Index of the component is stored in $\texttt{labels}(x, y)$.
The connected components of zero pixels are also found and marked by the function.

In this mode the complexity is still linear.
That is, the function provides a very fast way to compute Voronoi diagram for the binary image.
Currently, this second variant can only use the approximate distance transform algorithm.

\cvCppFunc{floodFill}
Fills a connected component with the given color.

\cvdefCpp{int floodFill( Mat\& image,\par
               Point seed, Scalar newVal, Rect* rect=0,\par
               Scalar loDiff=Scalar(), Scalar upDiff=Scalar(),\par
               int flags=4 );\newline
int floodFill( Mat\& image, Mat\& mask,\par
               Point seed, Scalar newVal, Rect* rect=0,\par
               Scalar loDiff=Scalar(), Scalar upDiff=Scalar(),\par
               int flags=4 );}
\begin{description}
\cvarg{image}{Input/output 1- or 3-channel, 8-bit or floating-point image. It is modified by the function unless the \texttt{FLOODFILL\_MASK\_ONLY} flag is set (in the second variant of the function; see below)}
\cvarg{mask}{(For the second function only) Operation mask, should be a single-channel 8-bit image, 2 pixels wider and 2 pixels taller. The function uses and updates the mask, so the user takes responsibility of initializing the \texttt{mask} content. Flood-filling can't go across non-zero pixels in the mask, for example, an edge detector output can be used as a mask to stop filling at edges. It is possible to use the same mask in multiple calls to the function to make sure the filled area do not overlap. \textbf{Note}: because the mask is larger than the filled image, a pixel $(x, y)$ in \texttt{image} will correspond to the pixel $(x+1, y+1)$ in the \texttt{mask}}
\cvarg{seed}{The starting point}
\cvarg{newVal}{New value of the repainted domain pixels}
\cvarg{loDiff}{Maximal lower brightness/color difference between the currently observed pixel and one of its neighbors belonging to the component, or a seed pixel being added to the component}
\cvarg{upDiff}{Maximal upper brightness/color difference between the currently observed pixel and one of its neighbors belonging to the component, or a seed pixel being added to the component}
\cvarg{rect}{The optional output parameter that the function sets to the minimum bounding rectangle of the repainted domain}
\cvarg{flags}{The operation flags. Lower bits contain connectivity value, 4 (by default) or 8, used within the function. Connectivity determines which neighbors of a pixel are considered. Upper bits can be 0 or a combination of the following flags:
\begin{description}
  \cvarg{FLOODFILL\_FIXED\_RANGE}{if set, the difference between the current pixel and seed pixel is considered, otherwise the difference between neighbor pixels is considered (i.e. the range is floating)}
  \cvarg{FLOODFILL\_MASK\_ONLY}{(for the second variant only) if set, the function does not change the image (\texttt{newVal} is ignored), but fills the mask}
\end{description}}
\end{description}

The functions \texttt{floodFill} fill a connected component starting from the seed point with the specified color. The connectivity is determined by the color/brightness closeness of the neighbor pixels. The pixel at $(x,y)$ is considered to belong to the repainted domain if:

\begin{description}

\item[grayscale image, floating range] \[
\texttt{src}(x',y')-\texttt{loDiff} \leq \texttt{src}(x,y) \leq \texttt{src}(x',y')+\texttt{upDiff} \]

\item[grayscale image, fixed range] \[
\texttt{src}(\texttt{seed}.x,\texttt{seed}.y)-\texttt{loDiff}\leq \texttt{src}(x,y) \leq \texttt{src}(\texttt{seed}.x,\texttt{seed}.y)+\texttt{upDiff} \]

\item[color image, floating range]
\[ \texttt{src}(x',y')_r-\texttt{loDiff}_r\leq \texttt{src}(x,y)_r\leq \texttt{src}(x',y')_r+\texttt{upDiff}_r \]
\[ \texttt{src}(x',y')_g-\texttt{loDiff}_g\leq \texttt{src}(x,y)_g\leq \texttt{src}(x',y')_g+\texttt{upDiff}_g \]
\[ \texttt{src}(x',y')_b-\texttt{loDiff}_b\leq \texttt{src}(x,y)_b\leq \texttt{src}(x',y')_b+\texttt{upDiff}_b \]

\item[color image, fixed range]
\[ \texttt{src}(\texttt{seed}.x,\texttt{seed}.y)_r-\texttt{loDiff}_r\leq \texttt{src}(x,y)_r\leq \texttt{src}(\texttt{seed}.x,\texttt{seed}.y)_r+\texttt{upDiff}_r \]
\[ \texttt{src}(\texttt{seed}.x,\texttt{seed}.y)_g-\texttt{loDiff}_g\leq \texttt{src}(x,y)_g\leq \texttt{src}(\texttt{seed}.x,\texttt{seed}.y)_g+\texttt{upDiff}_g \]
\[ \texttt{src}(\texttt{seed}.x,\texttt{seed}.y)_b-\texttt{loDiff}_b\leq \texttt{src}(x,y)_b\leq \texttt{src}(\texttt{seed}.x,\texttt{seed}.y)_b+\texttt{upDiff}_b \]
\end{description}

where $src(x',y')$ is the value of one of pixel neighbors that is already known to belong to the component. That is, to be added to the connected component, a pixel's color/brightness should be close enough to the:
\begin{itemize}
  \item color/brightness of one of its neighbors that are already referred to the connected component in the case of floating range
  \item color/brightness of the seed point in the case of fixed range.
\end{itemize}

By using these functions you can either mark a connected component with the specified color in-place, or build a mask and then extract the contour or copy the region to another image etc. Various modes of the function are demonstrated in \texttt{floodfill.c} sample.

See also: \cvCppCross{findContours}

\cvCppFunc{inpaint}
Inpaints the selected region in the image.

\cvdefCpp{void inpaint( const Mat\& src, const Mat\& inpaintMask,\par
              Mat\& dst, double inpaintRadius, int flags );}

\begin{description}
\cvarg{src}{The input 8-bit 1-channel or 3-channel image.}
\cvarg{inpaintMask}{The inpainting mask, 8-bit 1-channel image. Non-zero pixels indicate the area that needs to be inpainted.}
\cvarg{dst}{The output image; will have the same size and the same type as \texttt{src}}
\cvarg{inpaintRadius}{The radius of a circlular neighborhood of each point inpainted that is considered by the algorithm.}
\cvarg{flags}{The inpainting method, one of the following:
\begin{description}
\cvarg{INPAINT\_NS}{Navier-Stokes based method.}
\cvarg{INPAINT\_TELEA}{The method by Alexandru Telea \cite{Telea04}}
\end{description}}
\end{description}

The function reconstructs the selected image area from the pixel near the area boundary. The function may be used to remove dust and scratches from a scanned photo, or to remove undesirable objects from still images or video. See \url{http://en.wikipedia.org/wiki/Inpainting} for more details.

\cvCppFunc{integral}
Calculates the integral of an image.

\cvdefCpp{void integral( const Mat\& image, Mat\& sum, int sdepth=-1 );\newline
void integral( const Mat\& image, Mat\& sum, Mat\& sqsum, int sdepth=-1 );\newline
void integral( const Mat\& image, Mat\& sum, \par Mat\& sqsum, Mat\& tilted, int sdepth=-1 );}
\begin{description}
\cvarg{image}{The source image, $W \times H$, 8-bit or floating-point (32f or 64f)}
\cvarg{sum}{The integral image, $(W+1)\times (H+1)$, 32-bit integer or floating-point (32f or 64f)}
\cvarg{sqsum}{The integral image for squared pixel values, $(W+1)\times (H+1)$, double precision floating-point (64f)}
\cvarg{tilted}{The integral for the image rotated by 45 degrees, $(W+1)\times (H+1)$, the same data type as \texttt{sum}}
\cvarg{sdepth}{The desired depth of the integral and the tilted integral images, \texttt{CV\_32S},  \texttt{CV\_32F} or \texttt{CV\_64F}}
\end{description}

The functions \texttt{integral} calculate one or more integral images for the source image as following:

\[
\texttt{sum}(X,Y) = \sum_{x<X,y<Y} \texttt{image}(x,y)
\]

\[
\texttt{sqsum}(X,Y) = \sum_{x<X,y<Y} \texttt{image}(x,y)^2
\]

\[
\texttt{tilted}(X,Y) = \sum_{y<Y,abs(x-X+1)\leq Y-y-1} \texttt{image}(x,y)
\]

Using these integral images, one may calculate sum, mean and standard deviation over a specific up-right or rotated rectangular region of the image in a constant time, for example:

\[
\sum_{x_1\leq x < x_2, \, y_1 \leq y < y_2} \texttt{image}(x,y) = \texttt{sum}(x_2,y_2)-\texttt{sum}(x_1,y_2)-\texttt{sum}(x_2,y_1)+\texttt{sum}(x_1,x_1)
\]

It makes possible to do a fast blurring or fast block correlation with variable window size, for example. In the case of multi-channel images, sums for each channel are accumulated independently.

As a practical example, the next figure shows the calculation of the integral of a straight rectangle \texttt{Rect(3,3,3,2)} and of a tilted rectangle \texttt{Rect(5,1,2,3)}. The selected pixels in the original \texttt{image} are shown, as well as the relative pixels in the integral images \texttt{sum} and \texttt{tilted}.

\begin{center}\includegraphics[width=0.8\textwidth]{pics/integral.png}\end{center}

\cvCppFunc{threshold}
Applies a fixed-level threshold to each array element

\cvdefCpp{double threshold( const Mat\& src, Mat\& dst, double thresh,\par
                  double maxVal, int thresholdType );}
\begin{description}
\cvarg{src}{Source array (single-channel, 8-bit of 32-bit floating point)}
\cvarg{dst}{Destination array; will have the same size and the same type as \texttt{src}}
\cvarg{thresh}{Threshold value}
\cvarg{maxVal}{Maximum value to use with \texttt{THRESH\_BINARY} and \texttt{THRESH\_BINARY\_INV} thresholding types}
\cvarg{thresholdType}{Thresholding type (see the discussion)}
\end{description}

The function applies fixed-level thresholding
to a single-channel array. The function is typically used to get a
bi-level (binary) image out of a grayscale image (\cvCppCross{compare} could
be also used for this purpose) or for removing a noise, i.e. filtering
out pixels with too small or too large values. There are several
types of thresholding that the function supports that are determined by
\texttt{thresholdType}:

\begin{description}
\cvarg{THRESH\_BINARY}{\[ \texttt{dst}(x,y) = \fork{\texttt{maxVal}}{if $\texttt{src}(x,y) > \texttt{thresh}$}{0}{otherwise} \]}
\cvarg{THRESH\_BINARY\_INV}{\[ \texttt{dst}(x,y) = \fork{0}{if $\texttt{src}(x,y) > \texttt{thresh}$}{\texttt{maxVal}}{otherwise} \]}
\cvarg{THRESH\_TRUNC}{\[ \texttt{dst}(x,y) = \fork{\texttt{threshold}}{if $\texttt{src}(x,y) > \texttt{thresh}$}{\texttt{src}(x,y)}{otherwise} \]}
\cvarg{THRESH\_TOZERO}{\[ \texttt{dst}(x,y) = \fork{\texttt{src}(x,y)}{if $\texttt{src}(x,y) > \texttt{thresh}$}{0}{otherwise} \]}
\cvarg{THRESH\_TOZERO\_INV}{\[ \texttt{dst}(x,y) = \fork{0}{if $\texttt{src}(x,y) > \texttt{thresh}$}{\texttt{src}(x,y)}{otherwise} \]}
\end{description}

Also, the special value \texttt{THRESH\_OTSU} may be combined with
one of the above values. In this case the function determines the optimal threshold
value using Otsu's algorithm and uses it instead of the specified \texttt{thresh}.
The function returns the computed threshold value.
Currently, Otsu's method is implemented only for 8-bit images.

\includegraphics[width=0.5\textwidth]{pics/threshold.png}

See also: \cvCppCross{adaptiveThreshold}, \cvCppCross{findContours}, \cvCppCross{compare}, \cvCppCross{min}, \cvCppCross{max}

\cvCppFunc{watershed}
Does marker-based image segmentation using watershed algrorithm

\cvdefCpp{void watershed( const Mat\& image, Mat\& markers );}
\begin{description}
\cvarg{image}{The input 8-bit 3-channel image.}
\cvarg{markers}{The input/output 32-bit single-channel image (map) of markers. It should have the same size as \texttt{image}}
\end{description}

The function implements one of the variants
of watershed, non-parametric marker-based segmentation algorithm,
described in \cite{Meyer92}. Before passing the image to the
function, user has to outline roughly the desired regions in the image
\texttt{markers} with positive ($>0$) indices, i.e. every region is
represented as one or more connected components with the pixel values
1, 2, 3 etc (such markers can be retrieved from a binary mask
using \cvCppCross{findContours}and \cvCppCross{drawContours}, see \texttt{watershed.cpp} demo).
The markers will be "seeds" of the future image
regions. All the other pixels in \texttt{markers}, which relation to the
outlined regions is not known and should be defined by the algorithm,
should be set to 0's. On the output of the function, each pixel in
markers is set to one of values of the "seed" components, or to -1 at
boundaries between the regions.

Note, that it is not necessary that every two neighbor connected
components are separated by a watershed boundary (-1's pixels), for
example, in case when such tangent components exist in the initial
marker image. Visual demonstration and usage example of the function
can be found in OpenCV samples directory; see \texttt{watershed.cpp} demo.

See also: \cvCppCross{findContours}

\cvCppFunc{grabCut}
Runs GrabCut algorithm

\cvdefCpp{void grabCut(const Mat\& image, Mat\& mask, Rect rect,\par
                       Mat\& bgdModel, Mat\& fgdModel,\par int iterCount, int mode );}
\begin{description}
\cvarg{image}{The input 8-bit 3-channel image.}
\cvarg{mask}{The input/output 8-bit single-channel mask. Its elements may have one of four values. The mask is initialize when \texttt{mode==GC\_INIT\_WITH\_RECT}}
\begin{description}
    \cvarg{GC\_BGD}{Certainly a background pixel}
    \cvarg{GC\_FGD}{Certainly a foreground (object) pixel}
    \cvarg{GC\_PR\_BGD}{Likely a background pixel}
    \cvarg{GC\_PR\_BGD}{Likely a foreground pixel}
\end{description}
\cvarg{rect}{The ROI containing the segmented object. The pixels outside of the ROI are marked as "certainly a background". The parameter is only used when \texttt{mode==GC\_INIT\_WITH\_RECT}}
\cvarg{bgdModel, fgdModel}{Temporary arrays used for segmentation. Do not modify them while you are processing the same image}
\cvarg{iterCount}{The number of iterations the algorithm should do before returning the result. Note that the result can be refined with further calls with the \texttt{mode==GC\_INIT\_WITH\_MASK} or \texttt{mode==GC\_EVAL}}
\cvarg{mode}{The operation mode}
\begin{description}
    \cvarg{GC\_INIT\_WITH\_RECT}{The function initializes the state and the mask using the provided rectangle. After that it runs \texttt{iterCount} iterations of the algorithm}
    \cvarg{GC\_INIT\_WITH\_MASK}{The function initializes the state using the provided mask. Note that \texttt{GC\_INIT\_WITH\_RECT} and \texttt{GC\_INIT\_WITH\_MASK} can be combined, then all the pixels outside of the ROI are automatically initialized with \texttt{GC\_BGD}}.
    \cvarg{GC\_EVAL}{The value means that algorithm should just resume.}
\end{description}
\end{description}

The function implements the \href{http://en.wikipedia.org/wiki/GrabCut}{GrabCut} image segmentation algorithm.
See the sample grabcut.cpp on how to use the function.

\fi


\documentclass{article}

\usepackage[top=.75in, bottom=.75in]{geometry}

\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{xcolor}

\begin{document}

\newcommand{\tda}[1]{\textcolor{red}{#1}}
\newcommand{\tdb}[1]{\textcolor{orange}{#1}}
\newcommand{\tdc}[1]{\textcolor{blue}{#1}}
\newcommand{\unk}[1]{\textcolor{red}{#1}}
\newcommand{\der}[1]{\textcolor{orange}{#1}}
\newcommand{\off}[2]{\textnormal{\emph{Off}}_{#1\rightarrow#2}}

\section*{Setup:} Assume 3 polypoint tags (A, B, C), all 1~m from each other.

\begin{itemize}
  \item $t_A$ = tx delay for tag A (unknown)
  \item $r_A$ = rx delay for tag A (unknown)
  \item $\lambda$ = time of flight for 1~m ($\lambda = \frac{1}{c}\times\textnormal{\texttt{DWT\_TIME\_UNITS}}$)
  \item $\epsilon$ = precise delay before sending the next packet (i.e.\ 5\,ms)
\end{itemize}

The goal is to determine the calibration factor for a tag, $cal_A = t_A + r_A$.

\section*{Protocol:}

The following sequence will recover the $cal_C$. Note that timestamps from
local clocks are not synchronized, nor can the clocks be assumed to be running
at exactly the same speed.

\bigskip

\noindent
\begin{minipage}{.35\textwidth}
  \begin{enumerate}
    \item Tag A sends a packet
    \item Tag C sends a packet after $\epsilon$
    \item Tag C sends a packet after $\epsilon$
  \end{enumerate}
\end{minipage}%
~~~~~%
\begin{minipage}{.65\textwidth}
  \includegraphics[width=\linewidth]{calibration_diagram}
\end{minipage}

\begin{align}
  BRX1 &= ATX1 + t_A + \lambda + r_B \\
  BRX2 &= ATX1 + t_A + \lambda + r_C + \epsilon_C + t_C + \lambda + r_B \\
  BRX2-BRX1 = \Delta_B &= r_C + t_C + \epsilon_C + \lambda \\
  ~\nonumber\\
  k_{C\rightarrow B} &= \frac{BRX3-BRX2}{CTX3-CTX2} \\
  ~\nonumber\\
  r_C + t_C &= \Delta_B - \epsilon_C \times k_{C\rightarrow B} - \lambda
\end{align}

\end{document}


\chapter{Conclusions}\label{ch6}
\setlength{\epigraphrule}{0pt}
\setlength{\epigraphwidth}{0.75\textwidth}
\epigraph{\textit{The true delight is in the finding out rather than in the knowing.}}{Isaac Asimov}

In this work we have introduced the \acrlong{v2dm} to solve the many-body problem.
The \acrfull{2dm} contains all necessary information to describe such a system, and the expectation value of one- or two-particle operators
can be expressed as a linear function of the \gls{2dm}.
Unlike the more conventional quantum mechanical methods, the wave function is never used. This method itself has a long history and attracted quite some attention in the second half of
the previous century. At first glance, it has many interesting properties: the \gls{2dm} has a much better scaling than the wave function,
and the method is strictly variational. Unlike wavefunction-based methods, it produces a strict lower bound on the energy (instead of an
upper bound).
Unfortunately, the complexity of the many-body problem has not disappeared, but is shifted to the $N$-representability problem: what are the
necessary and sufficient conditions for a \gls{2dm} to be derivable from an ensemble of many-fermion wave functions?
In the 1960's, there was still hope that this problem could be solved in some way, but time has learned that it is a very hard problem (see
later).

% vim: spell spelllang=en syntax=tex tw=140


\chapter{Characterization of the grating testing setup}

\section{Monochromator}

%Cartoon of overall layout
\begin{figure}
\begin{center}
    \includegraphics[width=0.48\textwidth]{question_mark.ps}
  \end{center}
  \caption[DK480 monochromator layout]{Spectral products' DK480 monochromator layout.  The monochromator is an SP DK480 with selectable 300 g/mm and 150 g/mm gratings on the grating assembly.  Table 1 summarizes the expected properties of the monochromator.  The image is from \url{http://www.spectralproducts.com}.}
\end{figure}

First, let's work out the expected resolution of the monochromator.  The monochromator has 2 gratings, one with a blaze peak at 2.0 $\mu$m and one with a blaze peak at 4.0 $\mu$m.  For the purposes of this document we will concern ourselves with the 2.0 $\mu$m blazed grating because this one is in the $1.5 < \lambda/\mu\rm{m} <\;2.5$ range of the IGRINS instrument.  The monochromator table summarizes the properties of these gratings.  There we see that the 2 $\mu$m grating is 300 grooves/mm, or $\sigma$=3.3 $\mu$m.  The grating has a blaze angle of 17.5$^\circ$, operates in first order, and has $\beta \sim 8^\circ$ so $\cos{\beta} \sim 1$.  From classical diffraction grating theory (Schroeder 2000) we can calculate the angular dispersion, and then calculate the linear dispersion at the exit slit with the monochromator focal length (480 mm):
\begin{eqnarray}
  \frac{d\beta}{d\lambda}&=& \frac{m}{\sigma \cos{\beta}}      \nonumber \\
  \frac{dx}{d\lambda}&=& \frac{d\beta}{d\lambda} \times f = \frac{f}{\sigma}  \nonumber\\
  	&\sim& 480 / (3.3 \times 10^{-3}) \sim 1.5 \times 10^{5}
\end{eqnarray}
For example, a 1 mm slit will cover approximately 7 nm of spectral bandwidth, and the entire visible portion of the spectrum $(\Delta \lambda = 300 \;\rm{nm})$ should cover about 4 cm at the focal plane, which is consistent with visual inspection.  The minimum slitwidth of 10 $\mu$m should provide a resolution of 0.07 nm, which is equivalent to a resolution $R=\frac{\lambda}{\delta \lambda}=30,000$.  However, diffraction and optical aberrations limit the resolution to $R<30,000$.  Specifically, the resolution for a given number $N$ of illuminated grooves in order $m$ is given by $R=mN$, with the number of illuminated grooves given by $N=W/\sigma$, where $W=68$ mm is the width of the grating in the DK480.  $R=20,000$, which is the same as saying $\delta x = \lambda/W \times f \sim 14\;\mu$m for $\lambda=2\;\mu$m.  This spot size is comparable to the minimum slitwidth, and so this spot size and grating limited resolution is convolved with the slit function.  To take all these contributions into account, we add the $\delta \lambda$'s in quadrature:
\begin{eqnarray}
	 \delta \lambda_{net}^2 &=& \delta \lambda_{disp}^2 + \delta \lambda_{grat}^2
\end{eqnarray}

In any case, the delivered resolution will be somewhat less than the predicted resolution due to optical aberrations.  The delivered resolution was measured with a HeNe laser at the factory, and is listed in the table.  For the 10 $\mu$m slit the average delivered resolution is 0.25 nm or $R=2500$.  The figure below shows the expected and delivered resolution as a function of slit width.  In the next section on the camera and detector system, we study how the finite angular resolution of the camera system provides a related limitation to our spectral resolution.

%Table of monochromator properties
\input{gta_CA1_tab_SP_monch.tex}

%Efficiency as a function of wavelength for the 300 g/mm grating
\begin{figure}
\begin{center}
    \includegraphics[width=0.8\textwidth]{question_mark.ps}
  \end{center}
  \caption[Absolute efficiency of the 300 g/mm grating in the DK480 monochromator]{Absolute efficiency of the 300 g/mm grating in the DK480 monochromator.  The light intensity delivered to the optic is the product of the efficiencies of the light source spectral energy distribution, the filter curves, the gratings in the monochromator, the post slit lenses and mirrors, and the detector efficiency.}
\end{figure}

\begin{figure}
\begin{center}
    \includegraphics[width=0.8\textwidth]{question_mark.ps}
  \end{center}
  \caption[Absolute efficiency of the 300 g/mm grating in the DK480 monochromator, part II. ]{Absolute efficiency of the 300 g/mm grating in the DK480 monochromator over the wavelength range 0.5 to 2.5 $\mu$m.}
\end{figure}

\begin{figure}
  \centering
  \subfloat[Visible lamp]{\label{fig:vis_curve}\includegraphics[width=0.5\textwidth]{GTA_eff_vis_clear_2um_PbS}}
  \subfloat[NIR lamp]{\label{fig:nir_curve}\includegraphics[width=0.5\textwidth]{GTA_eff_nir_clear_2um_PbS}}
  \caption[Predicted relative spectral efficiency of experimental setup- visible and near-IR]{Expected relative efficiency for the specified combination of monochromator light source, monochromator grating, and detector.  We assume no filter is in the beam path.  The relative efficiency is roughly what we've seen from experiments.  The left plot demonstrates the visible lamp light source which has a color temperature of 3100 K, the right plot demonstrates the near-IR light source which has a color temperature of 950$^\circ$ C.  The visible light source lamp was used in experiments 8 and 9, and the NIR lamp was used primarily in more recent experiments.  Experiments employing the visible light source will demonstrate order-overlap since there is quite a bit of blue second order light overlapping.  We do not know if the PbS detector is sensitive below 1.0 $\mu$m.  It's important to note that these are (predicted) relative efficiencies, not absolute efficiencies.  The visible lamp may be brighter at any given near-IR wavelength, depending on its power, and coupling to the entrance slit.  This plot is merely to inform the design of experiments, and over what wavelength ranges we can expect to achieve relatively high signal to noise.  It looks like 1.5 to 2.5 $\mu$m has relatively smoothly variable signal in both scenarios.}
  \label{fig:GTA_layout}
\end{figure}

\subsection{Filterwheel and filters}
The filter wheel is the AB300-T from Spectral Products.  The AB300-T is connected to the DK480 monochromator by a serial cable, and can be commanded through the DK480's connection to the computer.  The AB300-T has five slots sized for 1 inch filters.  Commercially available 1-inch filters generally are unthreaded and need to be secured with a 1-inch retaining ring such as Thorlabs part number SM1RR, and then tightened or loosened with a pin spanner wrench like Thorlabs part number SPW602.  On November 15, 2011 I identified that the filter wheel was unresponsive to the DK480 commands issued from the computer.  I  contacted Spectral Products to troubleshoot the issue.  I will send the filter wheel back to Spectral Products.

%Table of filter wheel slots
\input{gta_CA1_tab_filters.tex}

%Efficiency as a function of wavelength for the AB Filters
\begin{figure}
    \includegraphics[width=1.0\textwidth]{question_mark.ps}
  \caption[Spectral products filter curves]{Filter curves for the AB series filters provided by Spectral Products.  We have two low pass filters from Spectral products- AB3190, AB3300. The filter curve for AB3300 is not shown, and was not included in their supplied filter curves data.  The online table indicates that AB3300 is a low pass filter with transition wavelength of 3000 nm, with a transition tolerance of 50nm.  We also have a Melles Griot 10 nm FWHM interference filter.  See the table on filter properties.  It is important to use order blocking filters because second order light could overlap and mimic ghost orders, or throw off the calibration with reference mirrors.  Since we want to measure efficiencies at the few percent levels, we probably should use order blocking filters unless it is demonstrated the order overlap is negligible.}
\end{figure}

%Efficiency as a function of wavelength for the AB Filters
\begin{figure}
    \includegraphics[width=0.9\textwidth]{exp48_49}
  \caption[FEL1450 LP filter]{The need for order blocking filters.  The left panel shows the raw data with and without the FEL1450 LP filter.  The light blue and purple curves are scans of an Al mirror with the visible light source before and after the green curve scan, which is a scan of the identical system, but with an FEL1450 Thorlabs low-pass filter placed directly behind the post-slit collimating lens (optic number 10 in the diagram of our optical bench configuration).  In subsequent trials employing the FEL1450 filter we placed the filter on an easily removable flip mount post at position 11, which is roughly the position of the image of the grating since it is almost one focal length behind the post-slit lens.  The FEL1450 has an cut-on wavelength of 1450 nm.  The primary purpose of this filter is to block second order light from the bright visible lamp from blanketing the first order infrared light.  The presence of this pernicious second order visible light is clear in the figure on the right, in which the efficiency approaches 100\% at 2900 nm, which is where second order 1450 nm light will cut on.  The blue curve on the right panel is the ratio of the green and light blue curves on the right, so with and without the FEL1450 filter.  The solid red curve is the manufacturer-provided specification data for the cut-on filter efficiency in the range $1400 < \lambda(\mathrm{nm}) < 1650 $.  The dotted red curve is the extrapolation of that curve from the manufacturer claim that the the minimum peak efficiency is 70\% through 2200 nm.  It is not clear how the filter performs after this wavelength.  It is also surprising that the observed flux ratio just after the cut-on wavelength at 1500$-$1700 nm exceeds the manufacturer provided efficiency data.  Either our filter is out-performing the specification or there is additional second order light falling at 1500 nm, which would be coming from 750 nm.  The filter properties at that short of a wavelength are not known, but this scenario is unlikely anyways since the detector and grating are inefficient at these wavelengths.}
\end{figure}

\section{Camera System and Differential lens/detector motion}
\subsection{Angular resolution of the camera system}
It is important to understand the camera system's angular resolution, because our system must be able to separate adjacent diffraction orders of the diffraction gratings we seek to measure.  The pixel sizes for our detectors are listed in the table detailing detector properties in the appendix.  We have two camera lenses- with focal lengths of 110 mm and 200 mm.  Note that examination of the pixel is deceiving because the active detecting area is actually much smaller than the entire surface area of the metallic surface seen in visual inspection.  The next figure demonstrates the sub-area which is active.  Experiments 26, 27, 28, 31, and 32 probed the demonstrated slit image width.  We were surprised to find that experiments 26, 27 and 28 demonstrated a big dip in the center of the convolved intensity profile.

One cause of angular resolution loss and a potential cause of systematic error is the differential camera lens and detector motion.  In our design the camera lens and detector system share a common axis which pivots about the axis rotation, which through the immersion grating.  The next figure shows a cartoon of the geometry of the differential lens and detector motion.

\begin{figure}
  \centering
  \subfloat[Dispersion relation]{\includegraphics[width=0.5\textwidth]{question_mark.ps}}
  \subfloat[160 $\mu$m slit with CA1a, 2D profile]{\includegraphics[width=0.5\textwidth]{question_mark.ps}} \\
    \subfloat[160 $\mu$m slit with Al mirror]{\includegraphics[width=0.5\textwidth]{question_mark.ps}}
      \subfloat[160 $\mu$m slit with CA1a, 1D profile]{\includegraphics[width=0.5\textwidth]{question_mark.ps}}
  \caption[Dispersion for $f$=200 mm camera]{Dispersion for the $f$=200 mm camera, as measured by the $\alpha$NIR focal plane array.  The $\alpha$NIR detector has small (39 $\mu$m) pixels and does not require detector motion, so these values are accurate unconvolved profiles of the dispersion relation.  The light blue solid line in the upper left panel is the expected behavior for perfect imaging optics- the imaged width would be about twice the slit width, assuming a 2:1 camera to collimator focal length ratio.}
\end{figure}

\begin{figure}
\begin{center}
    \includegraphics[width=0.8\textwidth]{question_mark.ps}
  \end{center}
  \caption[Differential camera motion]{Cartoon of the camera's differential motion}
\end{figure}

We can work out the amplitude of the differential camera motion in the following way.  First, notice in the previous figure in the first and third panel that beams diffracted from the grating at an angle $\theta_{d} = \theta_{a}$ from the optical axis are centered on the detector and so centroids of diffracted beams are undeviated.  The apparent angular widths are deviated by a factor involving the geometric values of the system.  Specifically, we are interested in case 2 in the figure, in which $\theta_{d} \ne \theta_{a}$.  In this case the focused spot position is one focal length behind the lens, parallel to the incoming beam.

\begin{eqnarray}
	%x_{lens}&=&L \cos{\theta_a} \nonumber \\
	y_{lens}&=&L \sin{\theta_a} \nonumber \\
	x_{spot}&\sim&(L+f_c)\cos{\theta_a}  \nonumber \\
	y_{spot}&=&y_{lens} \nonumber \\
	\tan{\theta_d} &=& \frac{y_{spot}}{x_{spot}} \sim \frac{L \sin{\theta_a}}{ (L+f_c)\cos{\theta_a}}  \nonumber
\end{eqnarray}

What we really want is $d\theta_d/d\theta_a$:

\begin{eqnarray}
	\frac{d}{d\theta_a} \tan{\theta_d} &=& \frac{d}{d\theta_a} \frac{1}{1+\frac{f_c}{L}} \tan{\theta_a} \nonumber \\
	\frac{d\theta_d}{d\theta_a} &=& k  \nonumber \\
	\mathrm{with \;}k=\frac{1}{1+\frac{f_c}{L}}  \nonumber
\end{eqnarray}

What is it we are actually measuring?  The output signal, which we will call $h(\theta)$, from the detector is the convolution of many angular and spectral functions:
\begin{description}
\item[$s(\theta)$]	The exit slit function. Set by the slit width, a negligibly weak function of $\lambda$.
\item[$b(\theta)$]	The blur spot of the optics. Principally from intentional defocusing at the detector plane.
\item[$g(\theta, \lambda)$]	The grating dispersion function.  This is a function of wavelength and angle.
\item[$p(\theta)$]	The pixel response function.  Looks like a tophat, but can have sub-pixel efficiency variations.
\end{description}

In principle, everything is a weak function of wavelength, for example the blur spot will change as a function of wavelength through chromatic aberrations.  We ignore these negligible wavelength dependent effects, except for the the grating which disperses the finite bandwidth beam into an angular spread (see previous figures).  For the purposes of figuring out the effect of the differential camera motion, will group $s$, $b$, and $g$, and any other heretofore unaccounted for (albeit negligible) angular and spectral functions, into a single delivered focal plane intensity profile, $f(\theta, \lambda)=g \convolution b \convolution s$.  First, let's consider the case in which the beam is monochromatic, so that $g(\theta, \lambda)=g(\theta)\delta(\lambda)$.  Let us further compare two different cases of angular motion.  In case 1 the beam and lens are stationary and only the detector moves steadily through the focal plane, pivoting about the axis of rotation centered on the immersion grating.  In case 2 both the lens and detector move along the same rigid arm, so that the image spot and detector are moving, albeit at different angular rates.  Let $\tau=\theta_a$ represent the angular position of the swing arm holding the detector for case 1, or lens and detector for case 2, with $\tau=0^\circ$ equal to the principal ray of the diffracted beam.  The angular center position of the focused spot in the detector plane is $\theta_d$, with $\theta_d= k \theta_a$ with $k$ defined above.

\begin{figure}
\begin{center}
    \includegraphics[width=1.0\textwidth]{question_mark.ps}
  \end{center}
  \caption[Immersion grating transfer function]{Cartoon of the immersion grating transfer function.  The grating transfer function $g=g(\theta, \lambda)$ is a function of angle and wavelength.}
\end{figure}

Case 1: Detector motion only, lens fixed
\begin{eqnarray}
	h(\tau) = \int_{-\infty}^{\infty} f(\theta) p(\tau - \theta)\,\mathrm{d}\theta  \nonumber \\
	h(\tau)=f(\theta) \convolution p(\theta)  \nonumber
\end{eqnarray}

Case 2: Detector and lens differential motion
\begin{eqnarray}
	h(\tau) = \int_{-\infty}^{\infty} f(\theta_d - \theta) p(\theta_a - \theta)\,\mathrm{d}\theta  \nonumber \\
%	\mathrm{Which\; is\; the\; same\; as:\;}  \nonumber \\
	h(\tau) = \int_{-\infty}^{\infty} f(\theta) p([1-k]\tau-\theta)\,\mathrm{d}\theta  \nonumber \\
	h([1-k]\tau)=f(\theta) \convolution p(\theta) \nonumber
\end{eqnarray}

Case 1 is a pure convolution, which is consistent with our intuition of smearing pixels with PSFs.  No problemo.  Case 2 is similar, the output function $h(\theta)$ is a convolution of $f$ and $p$, except stretched out by a factor of $1-k$.  Neat.  If the input signal is polychromatic, then $g(\theta)$ is a strong function of wavelength, but in fact the convolution proceeds the same way, stretching convolution of $g$ and $p$ by the factor $1-k$.  At the end of the day what we really want is the ratio, $r$, of the integrated intensity of a single monochromatic order from the immersion grating to the integrated intensity of a monochromatic beam from a reference mirror.  In terms of the quantities already defined, $r= \int h_{g}(\theta)/h_{m}(\theta)\,\mathrm{d}(\theta)$.  The area under the curve of a convolution is the product of the areas under the curves, so the pixel function (which is common to both the denominator and numerator in the ratio $r$), cancels out, as do all other common factors like $s$ and $b$.  Evidently $r$ is indifferent to the differential camera motion, which was not initially obvious to me, but now makes intuitive sense since the effect of the differential camera motion is merely a stretching of the pixel function.  To get a sense for the magnitude of the stretching, let us predict the factor $1-k$ for the geometry of our system under its two different operation modes.  For these modes $L=20.5$ and $f=110 \mathrm{\;or\;} 200$ mm.  The angular profiles will be stretched by factors of 2.9 and 2.0, respectively.  That there is less stretching for the longer focal length camera can be understood since it is more similar to the scenario of the detector moving freely from the lens, or in other words the relative motion is faster.  This whole angular rates problem is analogous to the difference between sidereal and synoptic rates in the apparent motion of celestial bodies in the solar system- Mars moves more slowly through the sky than does Jupiter even though Mars' angular space motion relative to the sun is faster than that of Jupiter.

\begin{figure}
\begin{center}
    \includegraphics[width=0.8\textwidth]{exp45_46}
  \end{center}
  \caption[Angular resolution experiment]{Experiment 45 and experiment 46 angular resolution experiments- observed instrumental profiles.  The width of the mirror slit is a few times smaller than the pixel width so that these profiles mostly indicate the instrumental pixel and motion response.The left panel is the instrumental profile of a monochromatic mirror beam with the lens mounted to the optical bench.  The right panel is the instrumental profile of a monochromatic mirror beam with the lens mounted to the swinging arm along the same axis as the detector.  The last panel is the latter experiment with its $x-$axis shrunk by a factor of 2, which is predicted from the differential motion and geometry of the system.  The match is good.  Based on the first panel we can directly estimate the effective width of the pixel- the $0.16^\circ$ width translates into 0.54 mm pixel width, but strictly less than this value since there is also some small contribution from the convolution of the slit.  This width is almost half as small as the 1 mm width we had been assuming based on the specs of comparable detectors and the limited information we had about our model. Our operational instrumental profile is the second panel, which has an angular width of about $0.30^\circ$.}
\end{figure}

In experiments 45 and 46 I directly measured the stretching factor for the system with $L=205$mm and $f_C=200$mm.  In experiment 45 I mounted the camera lens to the static optical bench so that the lens did not move with the swing arm, but the detector swung about the optical axis.  Experiment 46 had the lens mounted to the camera swing arm.  The angular scan profiles are shown in the next figure, with raw signal plotted against angular position, that is the angle of the arm.  The first panel shows experiment 45, the second panel shows experiment 46, and the last panel shows experiment 46 with its $x-$ scale compressed by a factor of 2, as predicted above for this camera system.

\begin{figure}
\begin{center}
    \includegraphics[width=0.45\textwidth]{question_mark.ps}
  \end{center}
  \caption[Observed and predicted slit functions]{The observed slit function for the 110 mm focal length camera system.  The pixel demonstrates non-uniform sub-pixel response, up to a factor of 20\%.}
\end{figure}

\section{Detectors}
%Table of single pixel detector properties
\input{gta_CA1_tab_detectors.tex}

\begin{figure}
\begin{center}
    \includegraphics[width=0.8\textwidth]{question_mark.ps}
  \end{center}
  \caption[PbS detector pixel geometry]{PbS detector pixel geometry.  The active area of the pixel is a subset of the entire metallic surface.  The dashed white lines show the detector's active area.  The ruler numbers demonstrate centimeters with sub-ticks equal to 1 mm.  The thick white bars near the pixel on the blow up image represent 3 and 1 mm.  The long axis of the detector active area must be parallel to the image long axis.  This requirement is tricky to accommodate with simple mountings, however, since the detector mounting set-screw is perpendicular to the long axis.  Casey Deen pointed out these issues in the geometry on October 31, 2011.  Experiments I performed before this date should not demonstrate sharp top-hat function PSFs.}
\end{figure}

\begin{figure}
  \centering
  \subfloat[Slit image]{\label{fig:GTA_slit}\includegraphics[width=0.5\textwidth]{question_mark.ps}}
  \subfloat[Pupil image]{\label{fig:GTA_im01}\includegraphics[width=0.5\textwidth]{question_mark.ps}}
  \caption[Slit and pupil image compared to single pixel detector size]{

  \emph{Left-} Layout of the IR detector areas compared to the image of the slit, as produced with a reference mirror and the current optical camera configuration, which includes a $f=110$mm focal length lens.  The blue dashed line is the footprint of the $\alpha$NIR 2D focal plane array, which has 316 $\times$ 252 array of 39 $\mu$m square pixels.  The solid red line is the single pixel detector which is 1 $\times$ 3 mm, as shown in the previous figure.  The background shows a filled contour plot of the slit image taken with the $\alpha$NIR from 100 combined dark subtracted frames, with the $f=110$ mm focal length camera lens, 250 $\mu$m slit width and the minimum slit height provided by the monochromator, with $\lambda$=1.6 $\mu$m.  Apparently the minimum slit height the monochromator provides is not sufficiently small to capture the full slit image height.  Either the slit height should be reduced or the camera lens focal length should be reduced to capture all the incident light.

  \emph{Right-} Same as the previous figure, except the background shows a filled contour plot of an image of the light source lamp filament with a 2.9 mm slit width and the maximum slit height provided by the monochromator, with $\lambda$=1.6 $\mu$m.  The contours on the image are black-blue-light blue with 10, 20, 40, 80, 160, 320 counts/pixel, with the noise floor at 5.4 counts with $\sigma=$ 2.5 counts/pixel.  The single pixel detector cannot capture all the light of the grating image onto the single pixel detector.  I discourage the choice of this image, since the image width does not shrink appreciably with decreasing slit size, meaning we lose light off the sides of the detector, and we lose angular resolution.}
\end{figure}

\begin{figure}
  \centering
  \subfloat[PbS and PbSe detectors]{\label{fig:PbS_det_eff}\includegraphics[width=0.8\textwidth]{question_mark.ps}} \\
  \subfloat[InGaAs and Ge detectors]{\label{fig:Ge_det_eff}\includegraphics[width=0.8\textwidth]{question_mark.ps}}
  \caption[Relative efficiency of single pixel detectors]{Relative efficiency of detectors comparable to but different from the models in our lab.  See the table with information on the detectors. The data are from \url{http://www.newport.com}.}
\end{figure}

\section{Equipment operation and performance}
The measurement system presents some challenges, specifically aligning and collimating the low intensity invisible monochromatic beam, and scanning the diffracted orders with a small single pixel detector.  In this section we characterize the measurement equipment through tests of the resolution and delivered optical and electronic performance.  We scrutinize the experimental strategy for sources of systematic errors.

\subsection{Repeatability}
A key limitation in our measurement strategy is the repeatability and stability of the optical alignment, and electronic and lamp conditions.  Specifically, our strategy is to take reference beam or reference mirror measurements before and after the scans of our grating or optic of interest.  Since our scans last up to 30 hours or more, reference calibration measurements can be temporally separated by several days.  The measured signal can drift for many reasons, for example drift in the lamp filament temperature or detector temperature, or mechanical sag of mirror mounts induced by thermal expansion or vibration.  Ideally our measurement strategy would take contemporaneous calibrations or near-contemporaneous calibrations on scales much shorter than the thermal drift time scale.  Our measurement system's structural design currently makes contemporaneous reference measurements prohibitive.  In principle the addition of a motorized retractable mirror or a beam splitter could provide near-contemporaneous or contemporaneous reference measurement, but these hardware upgrades are not going to be pursued at this time.  In this section we quantify the delivered repeatability of our measurements.  Naturally, we can repeat measurements many times to average out the variations in repeatability, but of course this adds to the measurement timescale and turnaround.  Our goal is to achieve about 5\% repeatability of measurements.  This level of uncertainty is comparable to what is delivered in industry applications (as noted from our experience with II-VI Infrared, who reported a 3\% systematic error in their wafer witness samples for the JWST project, for example).  Furthermore, 5\% is a fair estimate for our other systematic errors arising from vignetting of optical components or chromatic aberrations, among milliard other factors, so doing much better than this in any single experiment is likely just fooling ourselves.

The next figure demonstrates the repeatability of experiment 22 and 24.  These experiments served as the pre- and post- reference mirror calibrations for experiment 23.  The measurements were separated by 4 days, specifically from a experiment 22 was started on Friday November 17, 2011 and experiment 24 was started on Monday November 21, 2011.  Both experiments took 20 hours to complete.  One aspect of the experimental setup was altered over this time- the necessary swapping of the reference mirror for the CA1 immersion grating, and the subsequent re-replacement of the mirror.  This process has its own affiliated repeatability limitations, but notably our mount was designed to be stable by using a 2-pin ball stud plate and 2-hole base plate.  The repeatability of this mount has not be independently examined, but in principle could be tested to a few arcseconds with a simple laser.  In any case when replacing the ball stud plate I typically monitor the instantaneous signal reported on the lock-in amplifier front panel, and I carefully attempt to torque the ball stud plate.  I did not notice any change in the instantaneous signal.

\begin{figure}
\begin{center}
    \includegraphics[width=0.7\textwidth]{exp22-24_plusdif}
  \end{center}
  \caption[Repeatability experiment]{Experiment 22 and experiment 24 overplotted to demonstrate the level of the repeatability of the measurements separated by 4 days.  The bottom panel shows the fractional difference of two curves which was computed as the absolute value of the difference divided by the sum of the two experiments, which is the same as half of the difference divided by the mean of the two experiments.  Blue line is the raw data, overplotted in black with a 21 pixel boxcar smooth.  The yellow dashed line is 5\% fractional difference from the mean.  The repeatability is better than 5\% over 1.5 $-$ 2.5 $\mu$m, which is our wavelength range of interest.}
\end{figure}

\begin{figure}
\begin{center}
    \includegraphics[width=1.0\textwidth]{exp25and30}
  \end{center}
  \caption[Stability experiment]{Experiment 25 and experiment 30 overplotted to demonstrate the level of the stability of measurements at $\lambda = 2.0 \; \rm{ and } \;2.3\; \mu$m. \emph{Left:} The measured signal normalized to its starting value as a function of time.  No changes were made to the experimental setup over the duration of the experiment.  Experiment 25 lasted 17.6 hours, experiment 30 lasted 52.9 hours.  The standard deviations over those times was about 9\% and 2\%, with peak to valley amplitudes of and 91\% and 23\%.  Experiment 25 shows about 4.5 times as much instability as does experiment 30, despite the fact that experiment 25 is 3 times shorter than experiment 30.  This level of instability is demonstrated in the previous figure, where the curves at $\lambda=2.3 \; \mu$m match to 0.3\%, but the difference at $\lambda=2.0\;\mu$m is about 2\%.  It's not clear what is the cause of the wavelength-dependent instability, but my guess is that the near-IR lamp is warming or cooling and since 2.0 $\mu$m is on the Wein side of the black body curve, it is much more sensitive to minute temperature differences than the 2.3 $\mu$m measurements, which are close to the blackbody peak.  The sampling rates were semi-regular, with delivered mean time steps and standard deviations of $15.86\pm0.34$ and $15.85\pm0.09$ s, but maximum separations of up to 29 and 20 seconds respectively.  \emph{Right:} The power spectrum of experiment 30, normalized to its peak value, with the DC component removed.  The red dashed line is an unweighted linear fit to the data frequencies less than 0.001 Hz, excluding the DC component.  Since the sampling was not strictly regular, we interpolated (i.e. \emph{interpol()} in IDL) the time samples onto a 5 times finer grid than the semi-regular native sampling.  The fitted power law slope is -1.4, which is consistent with 1/$f$ ``flicker" noise.}
\end{figure}

\section{Early Experiments}

\begin{figure}
  \centering
  \subfloat[Early polychromatic beam profile experiment]{\label{fig:exp7}\includegraphics[width=0.45\textwidth]{dat07_wls_1}}
  \subfloat[90$^\circ$ Rotated PbS detector]{\label{fig:rot_detect}\includegraphics[width=0.45\textwidth]{exp7_vs_ex8_norm}}
  \caption[Rotating the PbS detector improved the angular resolution by a factor of 3]{ \emph{Left-} Experiment 7 polychromatic detector profiles.  These profiles were taken before we rotated the slit so its long axis was perpendicular to the direction of the angular scanning, and before improvements to the optical quality, particularly the focus.  \emph{Right-} Factor of 3 improvement in angular resolution from correct detector mounting. Experiment 7 and 8 detector profiles for $\lambda = 2.5 \; \mu$m.  Between experiment 7 and 8 I rotated the PbS detector so that the long axis of the photosensitive detector area was perpendicular to the axis of the swinging arm.  The detector area is 1 $\times$ 3 mm$^{2}$, so with our $f=$ 110 mm camera lens and PbS detector configuration we expect 1.8$^\circ$ and 0.6$^\circ$ field of view for experiments 7 and 8, respectively.  The measured FWHM of the PSFs for experiments 7 and 8 are 1.8$^\circ$ and 0.63$^\circ$.  Notice the sidelobes on experiment 8, these came from calibration problems, specifically a background scan was subtracted off of this scan, but the background scan was not taken with a dark aperture cover and so this PSF is really the difference of two PSFs.  Still the width of the feature is unaffected, and the improved spectral resolution from rotating is demonstrated.}
\end{figure}

\begin{figure}
\begin{center}
    \includegraphics[width=0.6\textwidth]{question_mark.ps}
  \end{center}
  \caption[Factor of 50-100 improvement in signal from optical and electronic improvements]{Voltage as a function of wavelength for a 100 $\mu$m slit width, during experiments 1-5 and experiment 7$-$ experiments 1-5 are clustered below 1 mV, whereas experiment 7 is well above 10 mV.  The optical setup was unchanged during experiments 1-5.  I aborted experiment 6 because the scanning was goofed up.  Before experiment 7 I increased the on-detector gain setting by a factor of 5, maximized the signal by nulling the signal to 0 and then adding 90$^\circ$ of phase, increased the chopper frequency from 80 to 180 Hz, reset the lock-in amplifier pre- and post- measurement time-constant to steady the signal reported on the LCD display, fine adjusted the detector focus and height by comparison to the lock-in amplifier LCD display.  I also fine adjusted the exit-slit collimator lens, coarse-adjusted the input light source positioning on the lab jack, and triggered the TE cooler for the detector.  It is not clear if these last 3 changes had any effect, but all the changes combined to improve the signal by a factor of 50-100.  The beam profile also improved, although they are still not flat-topped.  See the figure of the beam profiles.}
\end{figure}

%------------------------------------------------------------------------------------------
%Long Tables
%------------------------------------------------------------------------------------------
\input{gta_CA1_tab_exper_parms.tex}
\input{gta_CA1_tab_experlog2.tex}