Siegfried's profile - activity

Hi. The "flickering" is a normal behavior. Since the HoGDetector (and all other algorithms for pedestrian detection) does not detect every person in each image of a video. In this video someone runs the opencv_gpu_hog example on the example video from opencv. As you can see, even in the opencv example you can some "flickering".

The reason why the videos are played at slower rate is that HoG needs a lot of computational power. If you want more fps you can tune the parameters of the detectMultiScale(...) method. Reduce the resolution of the video (the opencv example video has only a resolution of 768x576 pixel). Or use the CUDA HoGDetector.

One error is in the last line. You cast a float value to an int.

Hi everyone, I just want to read a value from each pixel of the oIMG mat, but it is failed. Can you help to explain where is my errors in below code:

Mat oIMG[3];
for (int i = 0; i < 3; ++i)
{
    oIMG[i] = Mat(vSize, hSize, CV_32FC(1), Scalar::all(255));
}
int hh = oIMG[0].at<float>(0, 0);

Hi,

I agree with the comment from StevenPuttemans. You should not use different models and try to combine them. To detected the lane markers use a model which approximates the lane markers good enough and which can be easily calculated (e.g. BSplines). Then after detecting the lane markers you can use this information to get the drive lane.

At DARPA Urban Challenge the Team Caltech developed an approach which works very good and runs in real-time.

See website from Mohamed Aly here.There he also presents pictures and videos of the results.

He also published a paper

Mohamed Aly, Real time Detection of Lane Markers in Urban Streets, IEEE Intelligent Vehicles Symposium, Eindhoven, The Netherlands, June 2008.

The paper is available here and the source code here.

Hi, Point Cloud Library is a library quite similar to OpenCV. Or in other words, what OpenCV for computer vision is, is Point Cloud Library for point cloud processing. It's also an Open Source project released under BSD license. So you can use it in commercial applications. Do you really have not initial guess about the scan position? My experience says that scan robust scan matching with not initial guess and noisy data (as in your example) is very very hard.

Hi, you problem is called scan matching or point cloud registration and is a well known problem in robotics. In applications as yours typically an initial guess at which location the laser scan was located is available (the pose from the last time step, odometry data, ...) . So you can also use the most used algorithm, ICP or variants of it (see here, here and here ).

An implementation of ICP (GICP) from pointcloud library can be found here and a full scan matching component from ROS here.

If you have no initial guess the problem is much harder, one solution then be the algorithm presented in this video

Hi, take a look at the cv::compareHist(...) documentation. In the documentation of the enum cv::HistCompMethods all the math of the comparison methods is shown.

Do you mean: reducing greyscale to binary image (black and white)? Since, greyscale and monochrome are quite similar. If you want to get an binary image you can use cv::threshold. Here you can find an OpenCV tutorial about thresholding with some examples.

Hi. Can you tell us please whats the problem with the found locations? The found locations are in relation to the downscaled image. If you want the locations in relation to the input image you have to upscale the found locations (position and size) by the scale factor scale.

Typically ICP (Iterative Closest Point) algorithm is used to solve such a problem. As far as I know, there exist no ICP in OpenCV. If you can use Point Cloud Library in your project, you can easily adapt the code from the ICP tutorial on the PCL website (see here) to solve your problem.

Hi. We run the GPU HoG with a descriptor size of 18x36 and 48x96 in our application without "stalling". The application was tested on a Tegra K1 and on a Geforce GTX 650 using the master branch of OpenCV 3.0 repository.

Hi. To skip the first scales you can downscale the image before running detectMultiScale using resize method.

//assuming img is your input image

// 1. compute scale
const double scale = pow(1.05,13); // scale factor per level = 1.05 and 13 levels to skip
cv::Mat smallerImg;

// 2. compute downscaled roi
const cv::Size sz(cvRound(img.cols/scale), cvRound(img.rows/scale));

// 3. resize image to downscaled roi
resize(img, smallerImg, sz);

// 4. run detectMultiScale

Hi, in our test we got also different results for GPU and CPU HOG Implementation (See my question here ).

I don't think that you have to invert the image. Since the HoG implementation in OpenCV 2.4.11 doesn't consider the sign of the gradient. The reason is that in a typical pedestrian detection scenario the color of the clothing of the pedestrian is unknown (e.g. bright clothing on dark background or dark clothing on bright background). In your scenario the person typically will be brighter than the background. Dalal wrote in his paper (section 6.3) that using signed gradients does help significantly. In OpenCV 3.0 C++ HoG implementation you can set an flag if the descriptor use signed or unsigned gradients. But then, you can not use the default descriptor anymore and you have to train your own descriptor.

Hi,

its not only the number of cells in the descriptor window multiplied by the number of bins. You have also to consider the block stride. The following code is from the implementation of HOGDescriptor::getDescriptorSize() of OpenCV CPU HoG (see here).

(size_t)nbins*
(blockSize.width/cellSize.width)*
(blockSize.height/cellSize.height)*
((winSize.width - blockSize.width)/blockStride.width + 1)*
((winSize.height - blockSize.height)/blockStride.height + 1);

This image show the structure of the HoG Descriptor and how it is build (source: slide 18 from B. Triggs talk at icvss http://class.inrialpes.fr/tutorials/triggs-icvss1.pdf). The overlap of blocks is what is missing in your computation.

Your are right, the differences are minor. In the OpenCV HoG example its possible to switch between the CPU and the GPU implementation and both use the same model (default people detector). The detection results looks quite similar. So there could be no big differences, but I wondering what is the reason for the "small" difference in the descriptor. Probably your right and its an floating point issue (for example 16bit float vs. 32bit float).

Hi. Are you sure that you have checked this source code? Your code in the question will not compile, it contains a lot of syntax errors.

Hi,

we evaluate the performance improvement of the GPU implementation of the HOGDescriptor against the CPU implementation. During the tests, we compared the computed Descriptors of the GPU and the CPU implementation and saw that they are different. Why the Descriptors are different? Is this a bug?

The following code show our test application. We use the default people detector with default parameters on an frame from the OpenCV example video. The OpenCV version is opencv-2.4.10 and CUDA 6.5. The descriptor was computed at Rect(130, 80, 64, 128).

#include <iostream>
#include <opencv2/opencv.hpp>
#include <opencv2/gpu/gpu.hpp>

using namespace std;
using namespace cv;

int main()
{
    //load image and upload to gpu
    Mat img(imread("frame_7.png", CV_LOAD_IMAGE_GRAYSCALE), Rect(130, 80, 64, 128));
    gpu::GpuMat gpu_img; gpu_img.upload(img);

    //initialize detector and HOGDescriptor
    vector<float> detector = HOGDescriptor::getDefaultPeopleDetector();
    gpu::HOGDescriptor gpu_hog(Size(64, 128), Size(16, 16), Size(8, 8), Size(8, 8),9);
    HOGDescriptor cpu_hog(Size(64, 128), Size(16, 16), Size(8, 8), Size(8, 8), 9);
    gpu_hog.setSVMDetector(detector); cpu_hog.setSVMDetector(detector);

    //get descriptor vector -- cpu
    vector<float> cpu_descriptor, gpu_descriptor_vec;
    cpu_hog.compute(img, cpu_descriptor, Size(8, 8), Size(0, 0));

    //get descriptor vector -- gpu
    gpu::GpuMat gpu_descriptor_temp;
    gpu_hog.getDescriptors(gpu_img, Size(8, 8), gpu_descriptor_temp);
    Mat gpu_descriptor(gpu_descriptor_temp);
    gpu_descriptor.copyTo(gpu_descriptor_vec);

    //compare cpu_descriptor <--> gpu_descriptor
    for(int i=0;i<cpu_descriptor.size();i++){
        cout << i << " : " << cpu_descriptor[i] << " <--> " << gpu_descriptor_vec[i] << endl;
    }
    return 0;
}

Here is the test frame.

If we visualize the descriptors with the method from here. They look very similar but if you take a look at block (0,0) you see differences in magnitude and in block (3,5) different orientations.

CPU HOGDescriptor visualization

GPU HOGDescriptor visualization

Could anyone give me some hints why the descriptors are different?

Best regards,

Siegfried

Since you already compute the bounding box of the contours, you can do something like this

std::vector<cv::Mat> contour_rois;
for(int i = 0; boundRect.size(); i++)
{
    cv::Mat roi( binaryImg, boundRect[i]);
    contour_rois.push_back(roi);
}

You are right, the structure is a standard vector containing a standard vector of cv::Point2f. And cv::Point2f is a 2D point with data type float. OpenCV has a template class for 2D points (see here). For convenience there are some aliases

typedef Point_<float> Point2f;
typedef Point_<int> Point2i;
typedef Point2i Point;
typedef Point_<double> Point2d;

Hi, this is the behavior as described in the original SIFT paper Distinctive Image Features from Scale-Invariant Keypoints from David Lowe in section: 5 Orientation assignment on page 13.

When I do pedestrian detection width Hog + SVM in OpenCV ,I try to using it in two thread to improve the detect speed.But I got OpenCV error: Assertion failed<s >=0> in unknown function,file ..\..\..\opencv\modules\core\src\matrix.cpp,line 116

My code:

DWORD WINAPI DetectFrame1(LPVOID lpPrarmeter){
    HOGDescriptor hog1;
    hog1.setSVMDetector(HOGDescriptor::getDefaultPeopleDetector());

    while(true){
        WaitForSingleObject(g_hEvent1,INFINITE);        

        int temp;
        hog1.detectMultiScale(detImg1, found1, 0, cv::Size(8,8), cv::Size(0,0), 1.08, 2);  
        //cout<<"得到一帧near :"<<frame<<endl;
        //temp=frame;       // 标志当前处理帧 [9/26/2014 pan]

        if(!detImg1.empty()){
            imshow("det1",detImg1);
        }
        waitKey(10);
        cout<<"1——检测到行人："<<found1.size()<<endl;
        SetEvent(g_hEvent1);
    }
    return 0;
}
DWORD WINAPI DetectFrame2(LPVOID lpPrarmeter){
    HOGDescriptor hog2;
    hog2.setSVMDetector(HOGDescriptor::getDefaultPeopleDetector());         // 该函数不能并发 [9/26/2014 pan]
    while(true){    
        WaitForSingleObject(g_hEvent2,INFINITE);    
        int temp;
        //cout<<"得到一帧far :"<<frame<<endl;
        //temp=frame;           // 标志当前处理帧 [9/26/2014 pan]
        hog2.detectMultiScale(detImg2, found2, 0, cv::Size(8,8), cv::Size(0,0), 1.08, 2);  

        if(!detImg2.empty()){
            imshow("det2",detImg2);
        }
        waitKey(10);
        cout<<"2——检测到行人："<<found2.size()<<endl;
        SetEvent(g_hEvent2);        // 变为有信号状态 [9/26/2014 pan]
    }
    return 0;
}

Can anyone help me ,thanks.

Hi, check the parameter you put into cv::fillPoly(...). In the documentations of fillPoly other types are used as in your code.

An example how to use fillPoly can be found in the opencv tutorials section here. There is also a question on stackoverflow regarding on how to draw a contour / polygon (using cv::fillPoly(...)).

You should use the C++ API and avoid the old (deprecated) c API. Especially, when starting a new project.