zerog80's profile - activity

Hi to everybody! Is there any future plan about incorporating Structure from Motion open-source code (Bundler + PMVS2 + CMVS...) into OpenCV 3.x? Since all the code is freely available, tt could a really nice addition and smoothly integrated into the calib3d module workflow.

More info here...

There is a common technique used in OCR software that does the following (pseudocode):

threshold the image with an automatic global method (i.e. Otsu)
foreach (angle in angleRange)
{
    rotate original image by angle degrees
    count the number of white pixels (background) in each row
    store this number in a vector together with the associated angle
}
find the angle corresponding to the maximum value in the vector

This works because when the image is straight, in every row there is the maximum value of background pixels.

Another filter with effect similar to morphological opening is the median... did you try it with a small radius? It should remove the majority of the noise while retaining the main shapes.

Hi, I'm installing OpenCV 2.4.8 on a Ubuntu-based machine and I am about to compile the source codes. I have a NVIDIA Quadro K600 with drivers properly installed as well as both CUDA and OpenCL support libraries.

When calling cmake -D CMAKE_BUILD_TYPE=RELEASE -D WITH_CUDA=ON .., the config summary reports that both CUDA and OpenCL are enabled.

I would like to know if this can lead to runtime problems when calling "CL" functions from OpenCV code, because it can decide the acceleration layer to use.

Thanks

Yes, that was intended, in fact I stated "relatively to axis origin (0,0)", because I am scaling the whole coordinate system because of a camera calibration factor (px/mm). If I wanted to scale the Rect relatively to its top-left corner I should have done as Steven suggested.

Hi,

I was trying to scale a Rect relatively to axis origin (0,0) by a fixed factor, and I was expecting that this would work, for example:

float factor = 1.75f;
Rect originalRect(10, 15, 100, 200);
Rect scaledRect = originalRect * factor;

but the binary * operator is not defined for Rect and the compiler correctly reports an error.

I had to manually scale each coordinate:

Rect scaledRect;
scaledRect.x = originalRect.x * factor;
scaledRect.y = originalRect.y * factor;
scaledRect.width = originalRect.width * factor;
scaledRect.height = originalRect.height * factor;

which takes a lot more lines of code ;)

Is this simple addition to Rect class planned to be implemented in a future OpenCV version?

Hi, actually OpenCV 2.4.5 supports only one method (Otsu) for automatic global thresholding, but many more of them exist and their source is freely available from here: Auto Threshold methods

Some of them are useful for microscopy image segmentation, while others are better suited for other situations with uneven illumination, so I think it would be an useful addition for OpenCV and the implementation is straightforward since the provided source code is Java code converted from C++.

Best regards,

Guido

FFT works in frequency domain, blurriness is a spatial characteristic and it's better if you approximate it with the magnitude of horizontal and vertical derivatives as explained here.

Did you check if you linked the correct version of OpenCV library? The file you indicated refers to the 2.2.0 version.

Hi, I'm currently using OpenCV 2.4.3 with Qt 4.8.3 inside Qt Creator on a Linux system and once the OpenCV library was linked inside the Qt Project file, everything is working properly, I can call every OpenCV and Qt function after including "opencv2/opencv.hpp" and "QtGui".

Have you tried to import your VS project inside Qt Creator and rebuild it in there?

The usual one is the Gaussian Blur, because a low-pass filter can reduce the detection of false circles. However, take into account that the Hough Circles function incorporates a Canny edge detector that is applied before the actual detection, so maybe you have to better tweak its threshold parameters.

The full example can be found here.

Woa, that's a lot! I suppose that's the primary reason for the slow down... have you tried LIBLINEAR (http://www.csie.ntu.edu.tw/~cjlin/liblinear)? Radial-basis functions are the most general kernels, but if your problem can be well described even with linear kernels, you can benefit from greater speed using this optimized SVM library.

You're welcome :)

Are you setting the correct parameters for JPG compression while saving image? Regards to the second question, there is no better "quality" than the original image (i.e. no JPEG compression) ;) Any other processing (filtering, sharpening, histogram stretching) would "invent" pixels not exisiting in the original image... you may "perceive" better contrast or definition, but you are actually losing quality.

How many features are you extracting for each window?

Hi, it is not so difficult, the basic steps are the following:

1. Convert image to grayscale (cvtColor function).
2. Apply an edge detector (Canny or Sobel, for example) to obtain a binary image (0 on the background, 1 on edges).
3. Run the Probabilistic Hough Line Transform (better suited for finding few long lines) with the HoughLinesP function to obtain a vector of lines (you have to tweak the parameters to accomodate your scenario).
4. Iterate through this vector to keep only lines with angles similar to 0° or 90° (supposing your page is almost perpendicular to axes).
5. For each pair of lines with perpendicular angles, find the intersection point (here is better to solve the equivalent system of line equations for more robustness).
6. You have a bunch of points for each of the four page corners, you must run a distance threshold filtering to merge them to obtain at most 4 of them.

Two excellent tutorials for the first three steps are part of the OpenCV documentation and you can find here and here.

It is created as Point2f because even if you start from Point2i, a rotation can produce floating-point coordinates and rounding them to integers can lead to accuracy loss. Given all the optimization involved in OpenCV at compile time, I don't think using floating point instead of integers can be a performance issue, since both are typedef of the same Point_ class as explained here.

At most, you can be afraid of memory occupation if integers are 16 bits and floating point are 32 bits.

I think a better and more robust way to find page corners is applying a Hough Line Transform, look for lines of sufficient length and compute intersections between each pair of them.

http://docs.opencv.org/doc/tutorials/imgproc/imgtrans/hough_lines/hough_lines.html

Actually only some Blob Analysis libraries for OpenCV exists (cvBlob, cvBlobsLib and BlobLib) and even if they are working fine, they seem to be outdated by now and they do not support the new OpenCV structures like Mat. Even if it is possible to use findContours() to identify connected components, you still need external libraries for computing basic blob measures, like centroid, bounding box, axes, eccentricity, etc...

Is there any effort planned to embed these functionalities into the core OpenCV functions?

Many thanks!

Thanks, I'll take a look at it! :)

Hi! :) Is an OpenCV implementation of the TLD Real Time Tracker planned for a future release? http://info.ee.surrey.ac.uk/Personal/Z.Kalal/tld.html

OpenTLD is an already written C++ implementation that could be easily integrated into OpenCV: http://www.ohloh.net/p/opentld