Haarcascade operates on 348x288 images only? - c++

I am using opencv and c++. Which face detector algorithm to use if I have 348x288 face images. In the paper for Haarcascade http://www.vision.caltech.edu/html-files/EE148-2005-Spring/pprs/viola04ijcv.pdf, it is said that haarcascade operates on 348x288 pixel images. Does that mean I cannot use haarcascade to detect the faces in my images?

It can be used for your images as long as you setup the correct parameters for CascadeClassifier::detectMultiScale(), especially the following three:
scaleFactor – Parameter specifying how much the image size is reduced at each image scale.
minSize – Minimum possible object size. Objects smaller than that are ignored.
maxSize – Maximum possible object size. Objects bigger than that are ignored.

Related

Increasing image scale and maximizing resolution using opencv?

I've just started looking into OpenCV, I've looked at some similar questions but I haven't found the answers helpful. I have a number of images with the pixel dimensions of 50 wide and 50 heigh (thumb nail size).
I'm slightly confused regarding the following:
Q. By increasing the scale of these images, am I automatically increasing the resolution? Or do I need to be performing another function?
Its essential that I get the maximum resolution possible whilst increasing the scale of the images.
I'm using the below function:
int IncreaseScale()
{
char *image_name {"./image/my_image.jpg"};
cv::Mat Image;
Image = cv::imread(image_name, 1);
if(!Image.data)
{
//Cant find image
return 0;
}
const float rescale_value {4.10};
cv::Mat Image2;
cv::resize(Image, Image2, cvSize(0, 0), rescale_value, rescale_value);
return 1;
}
As previously stated by people here, using interpolation is very limited when increasing the size of the image. You are using pixels from the previous resolution to guess on what their values are when you increase the resolution of your image. Though the image will be of higher resolution, it won't be any better in quality.
One technique that has been proposed to overcome this is the idea of super resolution. The idea of this is that when you look at a scene, you take several different images looking at different view point. Each image offers some slight differences in information that the other images have not seen before. You determine what's unique about each view point then you combine this information together to make an enhanced stream of images that are of better quality. This unfortunately does not work with a single image as there is no additional information to extract from the stream of images. You can however use multiple images of the same view point. The noise profile that is introduced at the camera sensor should be enough to provide different information to the super resolution algorithm in order to produce an upscaled image of higher quality. In fact, the idea of super resolution is to take several images that are of "low quality" and to create a high quality result by combining their information together into a final image. This idea has been around for some time, not just related to image processing but in various areas of microscopy and imaging in science.
Using just a single image goes into the area of artificially creating super resolution images, which may or may not work depending on the image. Having a stream of images will have a higher probability of success. You can read more details about Super Resolution here: http://www.infognition.com/articles/what_is_super_resolution.html
Fortunately, OpenCV does have a module that implements Super Resolution and it's found in the Super Resolution module. You do need to feed in a series of images and the output will be a series of images that are of higher quality at the desired higher resolution you want.
A code example on how to use the Super Resolution module can be found here on OpenCV's Github repo: https://github.com/opencv/opencv/blob/master/samples/gpu/super_resolution.cpp. Don't be fooled on where the source is located. Even though it's placed under GPU examples, the code is designed to handle both CPU and GPU cases as you can see in the if statements. The code simply takes in a video feed and with a desired resolution, it outputs a super-resolution based result.
Yes, this code is effectively doing a 4.1x "digital zoom", so the output image should have resolution 205 x 205, or something like that. When left unspecified, resize uses bilinear interpolation for upsampling. The result will have higher resolution, but will not be any sharper than the original low-resolution image.

opencv clahe parameters explanation

I would like to know proper explanation of the clahe parameters
i.e clipLimit and tileGridSize.
and how does clipLimit value effects the contrast of the image and what factors(like image resolution, object sizes) to be considered to select tileGridSize.
Thanks in advance
this question is for a long time ago but i searched for the answer and saw this,then i found some links which may help,obviously most of below information are from different sites.
AHE is a computer image processing technique used to improve contrast in images. It differs from ordinary histogram equalization in the respect that the adaptive method computes several histograms, each corresponding to a distinct section of the image, and uses them to redistribute the lightness values of the image. It is therefore suitable for improving the local contrast and enhancing the definitions of edges in each region of an image.
and , AHE has a tendency to over-amplify noise in relatively homogeneous regions of an image ,A variant of adaptive histogram equalization called contrast limited adaptive histogram equalization (CE) prevents this by limiting the amplification.
for first one this image can be useful:
CLAHE limits the amplification by clipping the histogram at a predefined value (called clip limit)
tileGridSize refers to Size of grid for histogram equalization. Input image will be divided into equally sized rectangular tiles. tileGridSize defines the number of tiles in row and column.
it is opencv documentation about it's available functions:
https://docs.opencv.org/master/d6/db6/classcv_1_1CLAHE.html
and this link was good at all:
https://en.wikipedia.org/wiki/Adaptive_histogram_equalization#Contrast_Limited_AHE
http://www.cs.utah.edu/~sujin/courses/reports/cs6640/project2/clahe.html
clipLimit is the threshold value.
tileGridSize defines the number of tiles in row and column.
More Information

Dilation Gradient w/ different ROI's (blob optimization) OPENCV

I'm working on a dilation problem in c++ with opencv. I've captured videoframes of a car park and in order to obtain the best blobs I came up with this.
Erosion (5x5 kernel rectangular), 3 iterations
Dilation GRADIENT (think of it like a color gradient along the y-axis)
So what did I do to get this working? First I needed to know 2 points (x,y) and 2 good dilate kernelsizes at those points. With this information one can inter and extrapolate those values over the whole image. So I calculated ROI's (size and dilation kernelsize) from those parameters. So each ROI has its own predefined kernelsize used for dilation. Note that there isn't any space between two consecutive ROI's (opencv rectangles). Everything is working fine, but there are two side effects:
Buldges on the sides of the blobs. The black line is de border of the ROI!
buldges picture
Blobs which are 'cut off' from the main blob. These aren't actually cut off but the ROI under the one of the blob above dilates (gets pixel information from the above ROI, I think) into blobs who are seperated. It should be one massive blob. blob who shoudn't be there picture
I've tried everything on changing the ROI sizes and left some space between them but the disadvantage is that the blob between 2 seperated ROI's is not dilated.
So my questions are:
What causes those side effects exactly?
What do I have to do to make them go away?
EDIT
So I found my solution: when you call the opencv dilate function, one needs to be sure if the same cv::Mat can be used as destination image. If not you'll be using parts of the original and new image. So all I had to do was including a destination cv::Mat.
This doesn't answer your first question (What causes those side effects for sure), but to make them go away, you can do some variant of the following, assuming the ROI parameters are discrete and not continuous (as seems to be the case).
You can compute the dilation for the entire image using every possible kernel size. Then, after all of those binary images are computed, you can combine them together taking the correct samples from the correct image to get the desired output image. This absolutely will waste a good deal of time, but it should work with no artifacts.
Once you've confirmed that the results you've gotten above (which are pretty much guaranteed to be of as-good-as-possible quality) you can start trying to optimize. One thing I'd try is expanding each of the ROI sizes for computing the dilation by the size of the kernel size. This might get around artifacts that can arise from strange boundary conditions.
This leads to my guess as to what causes the artifacts in the first place: Whenever you take a finite image and run a convolution (or morphological operator) you need to choose what you'll do with the edge pixels. Normally, accessing the pixel at (-4, -1) is meaningless, but to perform the operator you'll have to if your kernel overlaps with it. If OpenCV is doing this edge padding for your subregions, it very easily could give you the artifacts you're seeing.
Hope this helps!

Image comparison method with C++ and OpenCV

I am new to OpenCV. I would like to know if we can compare two images (one of the images made by photoshop i.e source image and the otherone will be taken from the camera) and find if they are same or not.
I tried to compare the images using template matching. It does not work. Can you tell me what are the other procedures which we can use for this kind of comparison?
Comparison of images can be done in different ways depending on which purpose you have in mind:
if you just want to compare whether two images are approximately equal (with a few
luminance differences), but with the same perspective and camera view, you can simply
compute a pixel-to-pixel squared difference, per color band. If the sum of squares over
the two images is smaller than a threshold the images match, otherwise not.
If one image is a black-white variant of the other, conversion of the color images is
needed (see e.g. http://www.johndcook.com/blog/2009/08/24/algorithms-convert-color-grayscale). Afterwarts simply perform the step above.
If one image is a subimage of the other, you need to perform registration of the two
images. This means determining the scale, possible rotation and XY-translation that is
necessary to lay the subimage on the larger image (for methods to register images, see:
Pluim, J.P.W., Maintz, J.B.A., Viergever, M.A. , Mutual-information-based registration of
medical images: a survey, IEEE Transactions on Medical Imaging, 2003, Volume 22, Issue 8,
pp. 986 – 1004)
If you have perspective differences, you need an algorithm for deskewing one image to
match the other as well as possible. For ways of doing deskewing look for example in
http://javaanpr.sourceforge.net/anpr.pdf from page 15 and onwards.
Good luck!
You should try SIFT. You apply SIFT to your marker (image saved in memory) and you get some descriptors (points robust to be recognized). Then you can use FAST algorithm with the camera frames in order to find the coprrespondent keypoints of the marker in the camera image.
You have many threads about this topic:
How to get a rectangle around the target object using the features extracted by SIFT in OpenCV
How to search the image for an object with SIFT and OpenCV?
OpenCV - Object matching using SURF descriptors and BruteForceMatcher
Good luck

HOG in OpenCV for classification of entire images

I understand that Histograms of Gradients in OpenCV are typically used on image patches in order to detect and classify objects in an image.
However, I would like to use HOG to build a feature vector that can be used to classify an entire image. Using the following:
std::vector<float> temp_FV_out;
cv::HOGDescriptor hog;
hog.compute(img_in, temp_FV_out);
gives very long feature vectors each of different lengths, due to the varying size of the image - larger images have more 64 x 128 windows, and each of these contributes to the feature vector's length.
How can I get OpenCV to give a short feature vector (about 5-20 bins) from each image, where the length of the feature vector remains constant regardless of the image's size? I would rather not use bag of words to build a dictionary of HOG 'words'.
First step is to normalize the image size - choose the smallest size you want to process,and resize the rest to this base size. You can also establish a small size as default (100x100, by example) You may need to crop them, if they do not have the same aspect ratio.
Next, you can select a number of features from your vector, based on various algorithms: PCA, decision trees, Ada boost, etc - which can help you extract the most significant values from your data.