// NR - the number of directions. the loop on x below that computes Lr assumes that NR == 8.
// if you change NR, please, modify the loop as well.
intD2=D+16,NRD2=NR2*D2;//4e: Somewhere in code we need d+1, so D+1. One of simplest solutuons is increasing D-dimension on 1. But 1 is 16, when storage should be aligned.
intD2=D+16,NRD2=NR2*D2;
// the number of L_r(.,.) and min_k L_r(.,.) lines in the buffer:
// for 8-way dynamic programming we need the current row and
// the previous row, i.e. 2 rows in total
constintNLR=2;//4e: We assume, that we need one or more previous steps in our linear dynamic(one right here).
constintLrBorder=NLR-1;//4e: for simplification of calculations we need border for taking previous dynamic solutions.
constintNLR=2;
constintLrBorder=NLR-1;
// for each possible stereo match (img1(x,y) <=> img2(x-d,y))
// we keep pixel difference cost (C) and the summary cost over NR directions (S).
// we also keep all the partial costs for the previous line L_r(x,d) and also min_k L_r(x, k)
size_tcostBufSize=width1*D;
size_tCSBufSize=costBufSize*(fullDP?height:1);//4e: For HH mode it's better to keep whole array of costs.
size_tminLrSize=(width1+LrBorder*2)*NR2,LrSize=minLrSize*D2;//4e: TODO: Understand why NR2 per pass instead od NR2/2 (Probably, without any reason. That doesn't make code wrong)
size_ttotalBufSize=(LrSize+minLrSize)*NLR*sizeof(CostType)+// minLr[] and Lr[]
costBufSize*(hsumBufNRows+1)*sizeof(CostType)+// hsumBuf, pixdiff //4e: TODO: Why we should increase sum window height one more time?
CSBufSize*2*sizeof(CostType)+// C, S //4e: C is Block sum of costs, S is multidirectional dynamic sum with same size
width*16*img1.channels()*sizeof(PixType)+// temp buffer for computing per-pixel cost //4e: It is needed for calcPixelCostBT function, as "buffer" value
if(y>0)//4e: We calculate horizontal sums and forming full block sums for y coord by adding this horsums to previous line's sums and subtracting stored lowest
{//4e: horsum in hsumBuf. Exception is case y=0, where we need many iterations per lines to create full blocking sum.
for(k=0;k<width1*D;k++)//4e: only on first pass, so it keep old information, don't be confused
for(k=0;k<width1*D;k++)
S[k]=0;
}
// clear the left and the right borders
memset(Lr[0]-NRD2*LrBorder-8,0,NRD2*LrBorder*sizeof(CostType));//4e: To understand this "8" shifts and how they could work it's simpler to imagine pixel dislocation in memory
memset(Lr[0]+width1*NRD2-8,0,NRD2*LrBorder*sizeof(CostType));//4e: ...00000000|NRD2-16 of real costs value(and some of them are zeroes too)|00000000...
//TODO: Assumation: Let's pretend, that we allocate memory for pixDiff and tempBuf independently in each thread, with full size, needed for original calcBT
//TODO: Redo size of this arrays even if situation with independent allocation will still.
if(y>0)//4e: We calculate horizontal sums and forming full block sums for y coord by adding this horsums to previous line's sums and subtracting stored lowest
{//4e: horsum in hsumBuf. Exception is case y=0, where we need many iterations per lines to create full blocking sum.
@@ -987,8 +962,8 @@ struct CalcVerticalSums: public ParallelLoopBody
}
else
{
for(x=(x1+1)*D;x<x2*D;x+=D)//4e: Calcluates horizontal sums if (y==0). This piece of code is calling SH2+1 times and then result is used in different way
{//4e: to create full blocks sum. That's why this code is isolated from upper case.
CV_Assert(D%16==0);//TODO: Are you sure? By the way, why not 8?
CV_Assert(D%16==0);
// NR - the number of directions. the loop on x below that computes Lr assumes that NR == 8.
// if you change NR, please, modify the loop as well.
intD2=D+16;//4e: Somewhere in code we need d+1, so D+1. One of simplest solutuons is increasing D-dimension on 1. But 1 is 16, when storage should be aligned.
intD2=D+16;
// the number of L_r(.,.) and min_k L_r(.,.) lines in the buffer:
// for 8-way dynamic programming we need the current row and
// for dynamic programming we need the current row and
// the previous row, i.e. 2 rows in total
constintNLR=2;//4e: We assume, that we need one or more previous steps in our linear dynamic(one right here).
constintLrBorder=NLR-1;//4e: for simplification of calculations we need border for taking previous dynamic solutions.
constintNLR=2;
// for each possible stereo match (img1(x,y) <=> img2(x-d,y))
// we keep pixel difference cost (C) and the summary cost over NR directions (S).
// we keep pixel difference cost (C) and the summary cost over 4 directions (S).
// we also keep all the partial costs for the previous line L_r(x,d) and also min_k L_r(x, k)
size_tcostBufSize=width1*D;
size_tCSBufSize=costBufSize*height;
size_tminLrSize=(width1+LrBorder*2),LrSize=minLrSize*D2;//TODO: We don't need LrBorder for vertical passes and we don't need Lr buffer for horizontal passes.
size_tminLrSize=width1,LrSize=minLrSize*D2;
inthsumBufNRows=SH2*2+2;
size_ttotalBufSize=(LrSize+minLrSize)*NLR*sizeof(CostType)+// minLr[] and Lr[]
costBufSize*hsumBufNRows*sizeof(CostType)+// hsumBuf //4e: TODO: Why we should increase sum window height one more time?
CSBufSize*2*sizeof(CostType)+1024;// C, S //4e: C is Block sum of costs, S is multidirectional dynamic sum with same size
