Errata

> To create a sequence entry, you first provide the string name for the entry, and then the entry itself.

The sequence does not have string name. It should be "map"?
"To create a sequence entry" -> "To create a map entry"

"(i.e., j \in [0,k-1])" is really not a "that is" enhance of the preceding sentence. I'd just drop it, but maybe it could be changed to something useful.

In the Last paragraph of the page

"in our previous example,if it.nplanes were 4,then it.size would have been 16"
There is no example matching that description also the example code in the preceding doesnt fully explain the use of NaryMatIterator. Since the number of it.nplanes is always 1,it doesn't make much point to run a "for loop" which only execute once.
Example should at least present one case that the array is noncontinuous and therefor generating multiple planes and that way make the plane iterator usefull

createTrackbar("Position", "Example 2-4", &g_slider_position, frames, onTrackbarSlide);

should be

cv::createTrackbar("Position", "Example 2-4", &g_slider_position, frames, onTrackbarSlide);

(as full code in Example 2-4)

( i_0, i_i, ...,i_{N_d-1})

Shouldn't it be the following?

( i_0, i_1, ...,i_{N_d-1})

(2nd i's index: i -> 1)

The first line of the code snippet,

cv::Mat m = cv::Mat::eye( 10, 10, 32FC1 );

should it be the following?

cv::Mat m = cv::Mat::eye( 10, 10, CV_32FC1 );

If so, the same applied to the first code snippet of page 79 (32FC2 -> CV_32FC2).

Should

const cv::SparseMat_<t>*

be instead

const cv::SparseMat_<T>*

?

cv::arrToMat

should be

cv::cvarrToMat

Original text:

The algorithm used by cv::fillComvexPoly() is ...

Correct text:

The alogrihtm used by cv::fillConvexPoly() is ...

1) "covariation" should be "covariance"
2) "rotate back to your original basis..." This does not correctly describe how to weight a vector of IID zero mean variables to have a given covariance. You don't rotate and don't even think about bases. You multiply by a square root, S (in the sense of S*S^T=covariance) of the covariance. That typically has nothing to do with a rotation or change of basis.

"cv::Mat::empty()==true". Strange mix of static member function notation to describe a situation with a non-static member function. Better would be something like "empty() returns true" or just drop the parenthetical phrase -- it's hardly seems necessary.

The same thing happens on some other page and maybe pages. Search for them.

"returns true only if grab was successful" should be something like "returns true if grab was successful and false otherwise". As stated, grab could be successful and return false.

"The returned value is an enumerated type..." should be
"The returned value is a sum of enumerators..."

"filters (also called kernels)" I've heard of kernels loosely referred to as filters just as shorthand for the filter implemented when the kernel is used in a cross-correlation filter. However, if asked, no one would ever say that the kernel is the filter or that that filter is the kernel. It would be better to keep the terms separate. The problem may be elsewhere also, so search and modify would be good.

"linear kernels". Do a google search of:
"linear kernel" -learn -learning
and you'll quickly see that nobody uses the term "linear kernels" in regard to filtering. It is only used in learning and classifiers. So, the discussion of them ought to be modified to remover that term.

Grammar problems:

OpenCV offers five different smoothing operations, each with its own associated library function, which each accomplish slightly different kinds of smoothing.

Possibly this could be the correct version:

OpenCV offers five different smoothing operations, each with its own associated library function, with each accomplishing slightly different kinds of smoothing.

"pixel values covered by the kernel"

You never defined what you mean by "covered". If you already know, it is obvious that it means in the kernel's support (though the definition of support was relegated to a dismissive footnote, so you might just have to redo the zero/non-zero discussion). If you don't already know I'm sure it is not obvious at all.

"(i,j) \in kernel" So it looks like you are equating kernel and the support of a kernel. Describing this morphology-specific notion of "kernel" seems to have slipped through the cracks.

"Ellipse" should be "Elliptical disk" or "Filled ellipse".

"n^2log(n)" should be n^2log^2(n).

cv::getDerivKernel() should be cv::getDerivKernels().

The numerator should have "/2" instead of just "2".
.

the A \equv ... B\equiv ... string of equations is very difficult to understand at a glance (or even under close inspection). It would be simple to read if extra space or a comma with space were inserted before the B, T, X and X'.

"quadrangle". Though Stanford has a nice quadrangle, the right word here is quadrilateral.

"Trapezoids" should be "Quadrilaterals".

"-(1-alpha)*center_y" should not have the leading "-".

"(generally) some rhombus" would not be so jarring as "a quadrilateral (often a rhombus)"

The f's in "(x=f*X/Z,f*Y/Z)" don't belong here.

"or type cv::U8" should be "of depth cv::8U". The cv:U8 part of the errors has already be noted in the errata.

Correction to earlier correction. I said:

"or type cv::U8" should be "of depth cv::8U". The cv:U8 part of the errors has already be noted in the errata.

But the cv::8U should be CV_8U (as has been previous properly corrected by others)

Using these integral images, you may calculate sums, means, and standard deviations
over arbitrary upright or “tilted” rectangular regions of the image. As a simple example,
to sum over a simple rectangular region described by the corner points (x^1, y^1)
and (x^2, y^2), where x^2 > x^1 and y^2 > y^1, we’d compute:

In this paragraph, the number 1 and 2 are superscripts. But the equation right below the paragraph which is related to this explanation uses 1 and 2 as subscripts.
I think they should be the same format. Which is the right expression?

Should cv::Array be cv::Mat?

This uses: cv:U8C1 instead of CV_8UC1. The single : makes it a slightly different typo than in earlier errata. Possibly something different to search for.

class ShapeContextDistanceExtractor : public ShapeDistanceExtractor {

should be:

class ShapeDistanceExtractor : public Algorithm

"method" should be "class"

"Here we are using mathematician's definition of compact,"
should be
"Here we are not using the mathematician's definition of compact,"

On the off chance that this is a technical mistake and not a typo, I'll just note that any finite set of pixels is compact and in the continuous plane, any set bounded by a simple contour is compact if and only if the contour is completely included in the set (making the set bounded and closed). Neither of these is anything like the usage of "compact" in the first paragraph.

"apply()(" should be "apply(".

Also an earlier errata correctly says to eliminate footnote 18. This is just a reminder that you also need to add the "=0" 's in the member function declarations.

"Here, the second constructor ..." There is only one constructor (and that is only some sort-of-constructor-like function). The talk of two constructors continues to the end of the paragraph.

The unnecessary introduction of time and time derivatives of the 1D case of pages 501-503 continues on in the 2D case.

I googled around about optical flow and found out that the use of time and time derivatives is quite common. Wondering how that could be, I checked the original 1981 LK DARPA paper. It doesn't mention time or time derivatives (hey, it even uses h for the offset). Neither does Jean-Yves Bouguet's 2001 "Pyramidal Implementation of the Lucas Kanade Feature Tracker Description of the algorithm." But sometime someone applying the LK technique to optic flow decided to inject superfluous equations from continuous vector flow analysis into an otherwise simple algorithm derivation involving two images shifted with respect to each other. Regardless of who did it or when, it's a good idea to quit doing it now.

"average per-pixel change" should be something like
"average per-pixel absolute value of change"

Probably you ought to explicitly say here (or somewhere) that whenever a function uses an associated keypoint vector and descriptor matrix that keypoint i goes with matrix row i. A reader should certainly guess that this would be true, but good to say it anyway.

In at least seven places what could or should be "descriptor" is instead the incorrect "keypoint" or the OK but long "keypoint descriptor". Just check each usage of keypoint to be sure it is what you really want.

Now "autocorrelation" is applied to matrix that has absolutely nothing to do with autocorrelation. The matrix M is matrix of 2nd moments (assuming the w_{i,j} are greater than zero, sum to one, and are to be treated as a probability mass function). Maybe "M" is for "Moments"? I don't know. "autocorrelation" in this context shows up at least eight times.

Also, the last paragraph of pg 53 mentions "Hessian." Hessians deal with second derivatives, not second moments of first derivatives.

The discussion of nOctaveLayer is a bit confusing. 1) It is the first mention of an image pyramid, but that is referred to as "the image pyramid" as though it had already been discussed somewhere. Probably good to bring it in earlier. 2) nOctaveLayer is defined as "how many layers..." and right after that the definition is contradicted with nOctaveLayers now being "how many layers..." minus 3. It would be better to say something like: "nOctaveLayers is the number of DoG layers per octave in which extreme values are found. Two extra DoG layers sandwich these so that full 3x3x3 regions are always tested. To generate these nOctaveLayer+2 DoG layers, the algorithm needs to compute nOctaveLayer+3 smoothed images per octave.

"must be a reference to an STL-style vector"
The user cannot specify that an argument is a reference, so the above should be just
"must be an STL-style vector"

"should always be of type CV_8U"
should be
"should always be of depth CV_8U"

The next usage of "type" (for the mask) is probably OK but would be more clear with a CV_8UC1 instead of (the equivalent) CV_8U.

"autocorrelation" in three places. These refer back to a section where autocorrelation was used in two distinct ways (nether of which actually was an autocorrelation) so it is hard (though probably possible) to pin down what the word is now referring to. Some rewording would probably help.

"gradients (they are divided by their mean) that give the orientation of the gradient direction"
should be something like:
"moments (they are divided by the mean) that give the orientation"

"The second form is just a convenience, which is useful when you want to visualize the response to many different match computations at once."

It's also useful for visualizing the single same match computations done in knnMatch and radiusMatch.

"...arguments to the create function"
No create function is shown other than createOptFlow_DualTVL1() which has no arguments. But there really is a create( blah, blah) member function that has the arguments. It's just not shown.

The use of "model" for the state is highly nonstandard. Almost always, model refers to the coefficients of the Kalman filter. Further, the first use of model only makes sense if it refers to the estimated mean. Later uses make more sense if they refer to the mean and covariance. So, "model" ought to be swapped out for mean and covariance (as appropriate) of the a posteriori state distribution.

The footnote's definition of "maximizes the a posteriori probability" is just wrong. The a posteriori probability is a probability density and that isn't the most likely of anything by any measure of likeliness. It just is -- and it is computed by the Kalman filter. The mean does maximize a Gaussian probability distribution and that is what "maximizes the a posteriori probabilitty" refers to, the mean part of the Kalman filter.

In just these paragraphs, "state" is used incorrectly. "State" is never used to mean the combination of mean and covariance (though it is the state of the Kalman filter equations, that potential usage is never used). Better to stick with mean and covariance. Just to better see the problem, the last line of pg 616 says: "the state at time k multiplied by some matrix F". If the state were the mean and covariance, that would make no sense. If the state is just the mean state or the mean (like it really means here), it does make sense.

"It turn out this product is another Gaussian distribution"
should be
"It turn out this product is proportional to another Gaussian distribution"

Again, "the model that has the highest probability of being correct" is just wrong. The Kalman filter computes the correct distribution, period, no probability of being correct is involved. The mean maximizing that distribution is something different.

Two errors in the equation for \vec{x_k^-}:

1) The star superscript is missing from \vec{x_{k-1}}. The x without a star is the true state, not the estimated mean.
2) The " + \vec{w_k} " shouldn't be there. The estimate can't include unknown noises.

The \vec{x_k} is missing the star superscript that distinguishes the true state from the estimated mean.

\vec{x_k} is missing the star superscript.

Many of the right hand side symbols do not match what came earlier. There weren't any hats in the earlier text.

r with a overhead arrow is defined as a row vector in the text and then used as a column vector in the equation for R. Some transposing is needed somewhere.

I cannot see how the s referred to in the footnote is the product of other s'es. To me it looks like the equation of [x y 1]^T sets it's s, call it s', to a specific value. Suppose the equation for H uses that same s', then the s in the equation for \vec{q} would have to be 1.0. Suppose the equation for H used a different arbitrary s, call it s'', the the s in the equation for \vec{q} would have to be s'/s''. Or you could not require the 3rd component of \vec{q} to be 1 and then the final s could be anything.

In any case, I don't see any product of s'es involved.

"..if K>=2 then this equation can be solved..." That should be K>=3 since V is 2Kx6. You need to at least get to 6x6.

"\lambda -1/...." should be "\lambda = 1/..."

"overfitting" It might better be known as "ignoring prior uncertainties".

A paragraph and a footnote are approximately repeated. The 2nd paragraph on pg 700 is like the 2nd one of pg 702. Footnotes 7 and 9 are similar.

"We'll now summarize some facts ....
Order is preserved"

That is only true for some surfaces (and who knows what else). Look at puffed up hair (or close in to lots of small branches) and you'll see lots of order not being preserved. So this is often a good assumption, but somewhat less than a "fact".

Let’s pick one set of coordinate systems, left or right, to work in and do our calcula‐
tions there. Either one is just as good, but we’ll choose the coordinates centered on O l
-> of the left camera. In these coordinates, the location of the observed point is p l ->
and the origin of the other camera is located at O →

" the origin of the other camera is located at O ->" should be "T"?

There is a typo in the first row of the S-matrix. The matrix is skew-symmetric, so -T_x must be -T_z.

Example 19-2. Computing the fundamental matrix using RANSAC

should be

Example 19-2. Computing the fundamental matrix using Eight-point algorithm.

In Example 20-1, we mentioned briefly the possibility that the data might be arranged in the space in a highly asymmetrical way.

No, we did not mention it even briefly.

The methods of cv::StatModel provide mechanisms for reading and writing...

should read

The methods of cv::Algorithm provide mechanisms for reading and writing...