OpenCV 2.4.5 face detection

Your header asks for optimization, but your question asks for any ideas for improving the code. I'll answer the latter. If you need to optimize in terms of execution speed or memory use, I recommend using a profiler to measure what the critical path is.

Overall design

Your program uses a very C-like structure. Using an object-oriented approach can usually offer many benefits. For example, it will limit the scope of your global variables, since they can be member variables instead.

Your program uses both C++ and C-style IO. I strongly advice you to pick one of them. My recommendation is C++ iostreams, as they are type-safe.

Inconsistent style

Your programming style is inconsitent; you do different things in different parts of the program. That looks very untidy. For example, at one point you do:

if (!capture.isOpened())  // check if we succeeded
    return -1;

whereas later in the same function, another one-line if gets braces:

if (27 == char(c))
{
    break;
}

Personally, I prefer to write if statements like this:

if (!capture.isOpened()) return -1;

or over multiple lines and with braces. This avoids the risk of code like this:

if (!foo.bar())
    printf(" --(!) No captured frame -- Break!");
    foo.cleanup()

(In the previous snippet, foo.cleanup() is likely supposed to be run only if the if triggers, but will be run regardless.)

Another example is that at one point you do return -1;, but later you do return (-1);. Prefer the former; return is not a function.

Readability

Some of your variables have very poor names. Instead of this:

size_t ic = 0; // ic is index of current element

do this:

std::size_t index_current = 0;

Another thing that greatly boosts readability is avoiding literals in function calls. For example:

face_cascade.detectMultiScale(frame_gray, faces, 1.1, 2,
        0 | CASCADE_SCALE_IMAGE, Size(30, 30));

What's 1.1? 2? Why is the size 30x30? What do they mean? Are they correct? What possible values can they have? I think it's much better to define symbolic constants instead:

const float size_factor = 1.1;
const std::size_t num_buffers = 2;
const Size face_size(30, 30);

face_cascade.detectMultiScale(frame_gray, faces, size_factor, num_buffers, 0 | CASCADE_SCALE_IMAGE, face_size);

(The names I have given them are likely not what they actually mean. This is just an example.) An addition benefit with this is that code like this:

const float percentage = 20000f;
do_something(some_file, percentage);

Is more likely to be picked up as a possible error than this:

do_something(some_file, 20000f);

On the same note, 0 | CASCADE_SCALE_IMAGE is always exactly the same as CASCADE_SCALE_IMAGE, so you can skip the superfluous 0 |.

Comments

I think comments above the relevant line is more readable than comments beside the relevant line. In other words, prefer

// Get the area of biggest element, at beginning it is same as "current" element
ab = roi_b.width * roi_b.height;

Over

ab = roi_b.width * roi_b.height; // Get the area of biggest element, at beginning it is same as "current" element

Also, some of your comments are unnecessary. Comments should explain why, rather than what or how. Comments should not repeat what the code is already saying. // Function main is a great example of a comment that does not add information. Another example is // check if we succeeded.

Personally, I think brief statements of what is going on are good, as long as it doesn't get too much. For example the // Detect faces comment -- I think that's OK.

Small smells and other details

• Avoid polluting the global namespace with using directives.
• In C++, int main(void) and int main() is exactly the same. Drop void -- this is not C.
• I personally don't like Yoda Conditions, but that's just a matter of preference.
• Limit the scope of variables as much as possible. For example, ic should be restricted to the for loop, as should filename.
• Your program has very little error handling.
• If C++11 is an option, consider using a range-based (foreach-style) for loop

Like this:

for (auto const& face : faces)
{
    roi_c.x = face.x;
    roi_c.y = face.y;

    // ...
}

This is rather messy code, lots of inconsistencies and I doubt it really works. It looks like something you have written and not bothered to review yourself. Writing code is normally an iterative process (for me anyway), whereby you write something and then consider whether it is any good. Then you refine the solution and consider again. Your idea of what is "any good" will develop over time, but inconsistency and repetition are clearly not good.

A few observations:

Embedded paths: It is best not to embed paths in your code. For example the include file paths should be defined during the build (with -I) and the face_cascade_name variable should get its value some other way, eg through arguments to main.

roi_c.x = faces[ic].x;
roi_c.y = faces[ic].y;
roi_c.width = (faces[ic].width);
roi_c.height = (faces[ic].height);

ac = roi_c.width * roi_c.height; // area of current element

roi_b.x = faces[ib].x;
roi_b.y = faces[ib].y;
roi_b.width = (faces[ib].width);
roi_b.height = (faces[ib].height);

ab = roi_b.width * roi_b.height; // area of biggest element

if (ac > ab)
{
    ib = ic;
    roi_b.x = faces[ib].x;
    roi_b.y = faces[ib].y;
    roi_b.width = (faces[ib].width);
    roi_b.height = (faces[ib].height);
}
crop = frame(roi_b);

But roi_c is never used again and roi_b is assigned the same value twice! My guess is the second assignment should be of roi_c to roi_b, but the whole would be better as:

int area_c = faces[ic].width * faces[ic].height;
int area_b = faces[ib].width * faces[ib].height;

if (area_c > area_b) {
    roi = faces[ic];
} else {
    roi = faces[ib];
}
crop = frame(roi);

Your coud also pass by reference to frame instead of passing by value. And you might add an area method to the Rect class.