Nuzhny

У него проверяется. Дело скорее в отсутствии символа & перед cap.

Добавлю, что пример обращения к массиву там всё таки есть в цикле при удалении - по индексу. Можно ещё с помощью итераторов.

Правильней будет создавать изображения стандартными средствами (cvCreateImage, cvLoadImage, ...) и хранить массив указателей. Например так: #include <deque> ... std::deque<IplImage *> images; //сам массив //Создаём и добавляем новый элемент IplImage *img = cvLoadImage("file.jpg"); if (img) images.push_back(img); ... //Удаление всех изображений for (size_t i = 0; i < images.size(); ++i) { cvReleaseImage(&images); } images.clear();

Захватить по цвету/текстуре получается? Если да, то найди основные моменты (cvMoments) и посмотри на их значения - возможно этого хватит для определения сжатой/несжатой ладони.

Несоответствия типов там нет. Приведи лучше полный текст ошибки. Если же ты эту строку уберёшь, то, разумеется, появятся новые ошибки из-за обращения к пустому массиву по индексу - в него же ничего не добавляется.

Да, с суффиксом d

Обычно сначала делают приведение к unsigned char: unsigned char *img_data = (unsigned char *)img->imageData; //А после уже img_data[x + y * img->widthStep]

img->imageData[x + y * img->widthStep] Можно реализовать простую сегментацию на основе связности (восьми- или четырёхсвязности). Я, правда, не в курсе, есть ли она в OpenCV.

Сразу скажу, что не являюсь специалистом по распознаванию лиц. Но рассуждая логически, угол поворота лица можно узнать, зная расположение носа (рта, глаз, не важно, главное, чтобы можно было найти центр лица), а также границы лица. По расстояниям от центра лица до его краёв можно оценить угол поворота. Правда, подозреваю, что точность нахождения угла будет небольшой, зависит от расстояния до камеры. P.S. Идеальным вариантом представляется работа по стереоизображению. P.S2. Smorodov: мысль пришла одновременно.

Использовать несколько классификаторов: для фронтальных лиц, для профиля. И отправлять на распознавание только в случае сработки фронтального классификатора.

Фон отсекать как раз нельзя, каскад должен знать типичные отрицательные признаки. Грубо говоря, при проходе по каскаду подсчитывается сумма весов для каждой haar-feature. Значение очередной haar-feature сверяется с некоторым порогом. Если оно больше порога, то к сумме прибавляется один вес, если меньше - другой. Веса могут быть либо отрицательными, либо положительными в зависимости от того, удовлетворяет значение искомому объекту или нет. Веса и пороги формируются при обучении. Если ты затираешь фон, то значения весов, соответствующие ложной сработке, будут равны нулю (или почти нулю). А они должны быть отрицательными. Соответственно сумма всех весов будет больше, чем должна; отсюда ложные сработки. Следовательно, что для корректной работы необходимо выбрать большую выборку разнообразных положительных образов, а также большую выборку разнообразных отрицательных.

Поддерживает-то оба, но с бинарной совместимостью объектов С++ всегда была проблема. Собственно, имеется её решение - COM-объекты в Windows. Я думаю, ты знаешь, что там слишком навороченно для того, чтобы их просто так использовать. Где об этом почитать... Многостраничные обсуждения на форумах и собственный опыт. С контурами наверняка та же проблема, ты же передаёшь std::vector. Это легко проверить - перекомпилируй OpenCV и ошибки должны исчезнуть. С заголовком окна у меня так и было: взял изначальные dll - ошибка есть; перекомпилировал - исчезла. Впрочем, в отладчике тоже это видно - память затирается.

Тут вот какое дело. Для использования С++ API необходимо, чтобы dll и exe были собраны одним компилятором с одинаковыми опциями. Например, ошибка с заголовком окна. namedWindow принимает параметром std::string. В момент вызова namedWindow("Trulala"); в твоём exe создаётся объект класса std::string, который бинарно не совпадает с объектом std::string, который уже скомпилирован в dll. Тут даже в рамках одного компилятора debug и release варианты STL не идентичны. Поэтому, повторюсь, использование С++ возможно только в одном случае: ты компилируешь OpenCV с определёнными опциями компилятора и с теми же опциями компилируешь свой exe. Теперь они совместимы.

В виде строки 'CV_32S' получить нельзя (только если ты сам захочешь сделать ассоциативный массив). Да и зачем? По идее, достаточно получить числовое значение через mat.depth(). В крайнем случае посмотреть в файле cxtypes.h соответствие.

Если посмотреть на функцию: cv::RotatedRect cv::fitEllipse( const Mat& points ) { CV_Assert(points.isContinuous() && (points.depth() == CV_32S || points.depth() == CV_32F) && ((points.rows == 1 && points.channels() == 2) || points.cols*points.channels() == 2)); CvMat _points = points; return cvFitEllipse2(&_points); } то можно увидеть, что, во-первых, тип элементов матрицы должен быть CV_32S или CV_32F, и, во-вторых, её размерность должна быть: 1 строка, два канала, или 1 столбец, два канала, или, 2 столбца, один канал. Ты же подаёшь ей на вход матрицу другого типа, не подходящую по размерам. Вот оно а падает на ассерте.

Посмотри, что реализовано в модуле ml (Machine Learning): * Normal Bayes Classifier * K Nearest Neighbors * Support Vector Machine * Decision Trees * Boosting * Random Trees * Expectation-Maximization * Neural Networks Можешь этим пользоваться.

Для меня C API банально привычней. А что за эксепшен? Не смотрел в отладчике кто его кидает? Могу вечерком глянуть, сейчас ничего под рукой нет.

Это в самой последней версии так сделано - ты имеенно её используешь? Я пока на 1.1 сижу - там OpenMP поддерживается. Хотя, зная политику Интела, использование TBB не должно быть медленней. Может быть ты в CMake не указал использование TBB?

Гхм!!! У нас ребята неделю сидели, выбирали. Мой личный опыт (но никак не знание теории) подсказывает, что лучше обучать на минимальных объектах. Впрочем, здравый смысл говорит мне о том же.

Должно быть 7000 объектов, а не картинок. А описаний столько, сколько самих картинок. Если на одном изображении присутствует, например 2 объекта, то описание будет выглядеть так:

Да, именно так. Это означает, что на изображении 0018.bmp присутствует 1 искомый объект, причём его кординаты: x = 90, y = 22, width = 55, height = 68. Всё просто!

Я в детали не вдавался, но стандартный пример blob_tracking работает, мягко говоря, не очень быстро. Особенно ужасными тормоза становятся при выставлении опции сопровождения CCMSPF. Приведённый RinOS пример, на первый взгляд, довольно неплох. Однако для него необходимо провести предварительную бинаризацию, что не всегда возможно. Например, при сопровождением лиц.

Скорость разная на разных алгоритмах. Судя по официальной информации, максимальный прирост скорости наблюдается на медианном фильтре - 12 раз. OpenCV задействует другие ядра, если скомпилирована с использованием OpenMP.

Ну так надо было посмотреть, что именно не так с указателями (скорее всего проблема в них). Но, если нет желания разбираться, то ладно.

Это из-за IPP на интелах такая скорость. Без IPP будет тормозить.