bhornde's profile - activity

If you want to resize any given Rect by e.g. 20 px, without changing its center, you just have to

// move origin 10 px to top and left
r.x -= 10;
r.y -= 10;
// add 20px 
r.height += 20;
r.width += 20;

and as function:

inline cv::Rect blow(cv::Rect r, int byPx) {
    return cv::Rect(r.x-(byPx/2),r.y-(byPx/2),r.height+byPx,r.width+byPx);
}

@berak Thanks, I submitted a new issue (https://github.com/opencv/opencv/issu...) :)

Consider this Code:

std::vector<int> lin = {1,2,3,4,5};
cv::Mat linmat = cv::Mat(lin).reshape(0,1);

At this point, we should have the Mat

[1,2,3,4,5]

So far so good. When applying cv::repeat to it in 2.4 like

cv::repeat(linmat,5,1,linmat);

The result in 2.4.8 was (like it should be):

[1,2,3,4,5,
 1,2,3,4,5,
 1,2,3,4,5,
 1,2,3,4,5,
 1,2,3,4,5]

But in 3.2, some memory-corruption happens when src = dst. The result is some memory-garbage. When I use a second Mat as dst, everything works fine. Is this supposed to be like this or is this a bug?

Full Code for 2.4.X

std::vector<int> lin = {1,2,3,4,5};
cv::Mat linmat = cv::Mat(lin).reshape(0,1);
cv::repeat(linmat,5,1,linmat);

"Workaround" Code for 3.2

std::vector<int> lin = {1,2,3,4,5};
cv::Mat temp = cv::Mat(lin).reshape(0,1), linmat;
cv::repeat(temp,5,1,linmat);

Use some propper dilate/erode, extract skeletons and search for your minutia (bifurcations, endpoints, etc) with an propper 2D Filter (1,2,4,128,256,8,64,32,16) and convolution (http://www.christoph-busch.de/files/H... Page 94-97)

@berak isn't opencv row-col -> mat.at(row,col)?

word.data[(b*word.cols)+n] = 0xFF; helps a bit... word.at(b,n) = 0xFF somehow sets raw.at<uchar>(b*blockSize.width+w,0) = 0xFF, but only inside the scope of the function. Idk.

Hello Community. I've got that litte snipped here. As you can see, Im accessing the pixel value kind of block-wise and use the columns pixel values as bits for a unsigned int. Block number and unsigned int serve as coordinates for another pixel in another image, set to 255.

cv::Mat1b devideAndConquer(const cv::Mat1b &raw, cv::Size2i &blockCount, cv::Size2i &blockSize){
    int wordBlockSize = std::pow(2,blockSize.height);
    cv::Mat1b word = cv::Mat1b::zeros(blockCount.width,wordBlockSize);
    for(uint8_t b = 0; b < blockCount.width; ++b) {
        for (uint8_t w = 0; w < blockSize.width; ++w) {
            unsigned int n = 0;
            for (uint8_t h = 0; h < (blockSize.height); ++h) {
                std::cout << (int)(raw.at<uchar>(b*blockSize.width+w,h));
                n = (n << 1) + (raw.at<uchar>(b*blockSize.width+w,h) > 0 ? 1 : 0);
            }
            std::cout <<":"<< n << "\t";
            word.at<uchar>(b,n) = 0xFF;
        }
    }
    std::cout << std::endl;
    return word;
}

I've tested everything. After hours of debugging I've found the following: Sometimes the return value of raw.at<uchar>(b*blockSize.width+w,h) is inconsistent between calls of devideAndConquer. I used this Code to test my assumptions:

cv::Size2i blockCount(13,1);
blockSize.height = 10;
blockSize.width = 16;
cv::Mat1b dummy(blockCount.height*blockSize.height,blockCount.width*blockSize.width);
do{
    cv::randu(dummy, 0, 2);
} while(cv::countNonZero(dummy) == 0);
do{
    cv::Mat1b a = devideAndConquer(dummy,blockCount,blockSize);
    cv::Mat1b b = devideAndConquer(dummy,blockCount,blockSize);
    cv::Mat1b c;
    cv::compare(a,b,c,CV_COMP_BHATTACHARYYA);
    cv::imshow("Window",c);
    cv::waitKey();
}while(cv::countNonZero(c) != 0);

In theses inconsistend cases, the output of the first call for one block is 0000000000:0, on the second call its 255000000000:512. So the return value of on .at call that should be 0 is 255. dummy isn't touched. When I CV_COMP_BHATTACHARYYA on the Dummy before the calls and after the Calls, the result is 0 nonZero Pixels. On 3th and 4th call, even more values are flipped but they are consistently flipped.

Do I miss something? Have I made an error? Or is there some bogus magic happening thats flipping pixels? Latest OpenCV 2.4 and 3.2 (both causing the same error) is used on an MacBookPro (13", Mid2011) with 4GB RAM and i7.