SR's profile - activity

For a fair comparison you should use cv::resize with the INTER_AREA interpolation mode as that's what you should use for downsampling.

In general, if any kind of edge detection is desired it would avoid blurring as it actually makes the edge detection only harder. If filtering is needed then use a median or a bilateral filter as these are edge-preserving.

I think this is a bug. Canny should not "modify" the edge, it should only find the ridge.

Yep, that was my stupid mistake. Thanks for the hint! But: Why does cv::Ptr<cv::ORB> allow implicit conversion to cv::ORB*? That behaviour is dangerous and misleading. The conversion should be made explicit via a get() function.

With OpenCV 3 I get a SegFault when running the detect() function of either the ORB or AKAZE detector although the pointer is not null. I assume that something is not initialized. But my compiler is unable to find the previously necessary cv::initModule_features2d();. What do I need to do to initialize the feature detectors properly?

The code is roughly like the following:

   cv::FeatureDetector* detector = cv::ORB::create();
   CV_Assert( detector != NULL );
   vector<cv::KeyPoint> kpts1;
   detector->detect(img, kpts, cv::Mat());

I tried both 8uc3 and 8uc1 images, both ORB and AKAZE and it always segfaulted. Tested on OS X 10.10.

See here

The descriptors are vectors but directions are given in the "feature space", not in 2D. Consider them as arrays of values describing image patches.

FLANN allows to match descriptors by computing the approximate Euclidean distance between the descriptor vectors.

Before you refer to a variable with global it must exist. Therefore, assign a value to it right after the imports.

Yes that makes it expclit. The values is never rounded but truncated to [0, 255] though. I do not know if that's correct for your application.

You should not scale the classification window but do a multi-scale search on the input image. That is, you incrementally downsize the input image while your classification window size is kept fixed.

You are mixing types. You have a float * centroidPtr but assign it to one element of destPix[j] in destPix[j][0] = *centroidPtr++;. However, destPix[j] is a uchar so the values are truncated and meaningless.

Hello,

I know this has been asked many times and I've gone over the docs here but cannot seem to find an answer to my specific issue. I am trying to map the results from k-means clustering back into an image with reduced colors.

My old code works and does this using the Mat.at accessor, but it is very slow. I am trying to re-write this using pointers to improve performance, but right now the clustered image has many diagonal lines and the colors/pixels are not in the right place.

This works but is slow

for( int y = 0; y < resized.rows; y++ ){
    for( int x = 0; x < resized.cols; x++ ){
        {
            pixelPos =y + x*resized.rows;
            cluster_idx = labels.at<int>(pixelPos,0);
            clusteredImg.at<Vec3b>(y,x)[0] = centers.at<float>(cluster_idx, 0);
            clusteredImg.at<Vec3b>(y,x)[1] = centers.at<float>(cluster_idx, 1);
            clusteredImg.at<Vec3b>(y,x)[2] = centers.at<float>(cluster_idx, 2);
        }
    }

}

EDIT: The below code is working I had a silly mistake where I forgot that labels was M*Nx1 rather than MxNx1.

If there is any room for improvement please let me know!

for (int i = 0; i < resized.rows; ++i)
{
    cv::Vec3b* destPix = clusteredImg.ptr<cv::Vec3b>(i);
    int* labelPix = labels.ptr<int>(i);
    for (int j = 0; j < resized.cols; ++j)
    {
        pixelPos = i + j*resized.rows;
        cluster_idx = *labels.ptr<int>(pixelPos,0);
        float * centroidPtr = centers.ptr<float>(cluster_idx);

        destPix[j][0] = *centroidPtr++;
        destPix[j][1] = *centroidPtr++;
        destPix[j][2] = *centroidPtr++;
    }
}

Sorry if this is a stupid question, I am very new to C++.

I'm sure I have something wrong with how the destination data is assigned. I've checked the source data by printing debug statements and that seems to be correct.

Thanks for your comment as it preserves some knowledge. The original slides are not available anymore...

That's true. Now it looks correct, but it did not show up in the first place.

When editing a question, the one who edits it will be the new "original poster". The timestamp of editing is also wrong.

The forum system is wrong. I did not ask this question, I just edited the question.

How can ı find operating logic, fundamentals, application areas and matlab codes of FAST Algorithm.

See http://imagine.enpc.fr/~monasse/Stere...

AFAIK std::auto_ptr<> is not suitable for STL containers.

Is it safe to use cv::Ptr<> within STL containers e.g. as std::vector< cv::Ptr<MyObject> >?

If you want to "fill the container with your frame" then there is no way around allocating matrix and copying your data into that matrix. However, if you just want to wrap your data pointer by a cv::Mat object (provided that the data organization of this kind makes sense) you can simply call the wrapper constructor:

//! constructor for matrix headers pointing to user-allocated data
Mat(int rows, int cols, int type, void* data, size_t step=AUTO_STEP);

You can wrap your frame as simple as

Mat wrapped(MatrixRows, MatrixCols, MatrixType, MyDataBuffer);

Note that the destruction of wrapped does not free your buffer! You need to manage the underlying memory yourself.

If you then want to obtain a real copy it is probably the easiest to do

Mat copy = wrapped.clone();

See also http://docs.opencv.org/modules/core/doc/basic_structures.html#mat-mat

You may simplify the inner part of the first loop to buf[i] = cv::saturate_cast<unsigned char>((((i - midBright) * contrast) / 256) + midBright + bright);

A quick and dirty contrast enhancement via matrix expressions and a linear transformation:

 float alpha, beta = ...
 Mat image = imread( argv[1] );
 image += beta;
 image *= alpha;

For instance, set beta to -(minimum value) and alpha to (maximum value - minimum value).