Перейти к содержимому
Compvision.ru

Nuzhny

Пользователи
 Профиль  Активность

  • Количество публикаций

    1 427

  • Зарегистрирован

  • Посещение

  • Days Won

    176

Сообщения, опубликованные пользователем Nuzhny

  1. Опубликовано · Report reply

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

    Не исключено, что в той версии OpenCV  были ошибки или UB, а тут новый компилятор и они стрельнули.

  4. Опубликовано · Report reply

    Я пока попробовал 2 репозитория (пока лень самому писать):

    1. https://jugit.fz-juelich.de/mlz/lmfit

    2. https://github.com/yinzixuan126/polynomial_fitting/blob/master/src/polyfit_node.cpp

    Первый (Левенберга-Марквардта) работает точнее, второй быстрее. Нашёл ещё, но не пробовал ( https://github.com/gpufit/Gpufit, https://github.com/wojdyr/fityk).

    Потестирую, если будет медренно, то надо будет реализовывать самому и оптимизировать.

  5. Опубликовано · Report reply

    1 hour ago, Pavia00 said:

    Нету, так как такая операция для кривовй уже на 5-7 степени упирается в точность Single.

    Всегда можно взять и double, если придётся (но вряд ли точности не хватит). Сплайны и Безье - это не то, что мне надо. Я бы хотел из траектории движения объекта за несколько секунд (скажем, 100 кадров) получить уравнение движения. Логично получить кубическое, чтобы ускорение тоже было не константным. Теоретически, в OpenCV это можно сдлать через Levenberg-Marquardt solver (cv::LMSolver), можно взять ceres solver, но там везде надо дописывать свои целевые функции. Или что-то с Гитхаба специализированное. Не сильно хочется самому тянуть дополнительные зависимости для, казалось бы, вполне типичной задачи.

    За ссылки спасибо, посмотрю, потестирую, как оно работает.

  7. Опубликовано · Report reply

    Точки могут дрожать, например, из-за того, что маленькое разрешение, а угол попадает между пикселями. Можно попробовать вызывать cv::findCornersSubpix.

    Я когда-то для лицевых точек прмкручивал оптический поток и Калмана.

    • Like 1

  8. Опубликовано · Report reply

    Я про свертку не писал - редукция же. Каждый второй поток складывает полезные результаты в свой кусочек памяти и запоминает сколько и где, потом каждый четвёртый за двумя предыдущими и т.д. Теоретически, это должно сработать быстро.

  9. Опубликовано · Report reply

    Техника называется reduction, когда сначала все потоки пишут свои значения в результат, потом половина из них пишет валидные значения, затем ещё половина и т.д. Пока не останется один поток, определяющий финальный размер результата.

  11. Опубликовано · Report reply

    Да, обучать OpenCV не умеет, только использовать - inference.

    Информации, кстати, много. Я по стандартным примера уже года 2 точно пользуюсь, также совместно с OpenVINO для ускорения на CPU. Просто при сборке OpenCV надо выставить BUILD_EXAMPLES, стандартные примеры небольшие ю и информативные.

  16. Опубликовано · Report reply

    На джетсоне, если ты имеешь в виду Nano, всё должно быть иначе, потому что на нём нет выделенной видеопамяти, она общая системная.

    Ну и его использовать можно иначе: подключать не ip камеру, а веб или промышленную, получать с неё сразу несжатое видео.

  18. Опубликовано · Report reply

    3 hours ago, Pechkin80 said:

      

    
    std::cout << avcodec_get_name(fmt_ctx->streams[video_stream_index]->codecpar->codec_id) << ": " << fmt_ctx->streams[video_stream_index]->codecpar->codec_id << std::endl;

    Выдаёт:

    mpeg4: 13

    У меня на файл со сжатием h264 пишет: h264: 27. Ну и на ip-камеру, для которой всё это и делалось, аналогично.

    А команда "ffmpeg -hwaccels" даёт:

    Quote

    Hardware acceleration methods:
    cuda
    opencl
    cuvid

     

    3 hours ago, Pechkin80 said:

    Сама структура ...->streams[video_stream_index]->codec; определена как деприкейтед и на замену предлогают  

    
streams[video_stream_index]->codecpar

    Это да, никто codec и не предлагал использовать.

     

    Ещё раз повторюсь, что я брал за точку старта код из OpenCV, в нём реализовано всё необходимое. И уже его модифицировал под свои задачи.

  19. Опубликовано · Report reply

    Я за точку старта брал код для работы с ffmpeg из OpenCV, потому что точно знаю, что он работает. Вариант не идеальный, но, повторюсь, рабочий.

    Кстати, проверь для видео стрима, который ты получил, что он правильный: 

    std::cout << avcodec_get_name(stream->codecpar->codec_id) << ": " << stream->codecpar->codec_id << std::endl;

    Вообще, программировать с ffmpeg то ещё удовольствие, документация так себе, до правильного ответа приходится доходить чуть ли не методом тыка. Я не уверен, что всё делал правильно, но оно заработало. Эталонный вариант типа ffplay очень сложен: много тысяч строк в одном файле, всё смешано, куча goto.

  21. Опубликовано · Report reply

    Smorodov, это то, что называется re-id.  Кажется, что оно может плохо работать, ведь сеть обучается не различать отдельные объекты между собой, а отличать типы объектов. Кажется, что все люди будут близки друг с другом, машины друг с другом, а надо ещё и их различать между собой. Впрочем, я тут ещё не экспериментировал, надо попробовать, раз уж YOLO в проект проинтегрировано, благо и образец имеется.

    Надо ещё из OpenVINO потестить, у них есть обученная модель на "Identify Someone in Different Videos". Но это опять таки же сеть специально обученная различать пешеходов между собой. Также там есть "face reidentification" - различать лица между собой.

  22. Опубликовано · Report reply

    У меня в этом вопросе есть нерешённая проблема с расстояниями, а именно с тем, как нормировать расстояние между центрами объектов или как для него выбирать правильный порог, не зная физической модели объектов.

    Если мы наблюдаем за людьми со стационарной камеры, висящей на потолке помещения, то отличной метрикой будет служить IoU (Жаккара), которое есть отношение площади пересечения прямоугольников к площади объединения и расстояние это будет лежать в интервале [0, 1]. Всё круто: объекты крупные, двигаются медленно, метрика адекватная.

    Но тут мы вешаем камеру повыше на улицу, объекты становятся меньше, где-то проносятся машины на большой скорости. Пролетела птица возле камеры и каждый её прямоугольник не пересекается с предыдущим. Или птица летит вдалеке и её прямоугольник настолько мал, что пересечения минимальны или также равны нулю. Поэтому мы начинаем измерять не IoU, а расстояние между центрами прямоугольников на текущем и предыдущем кадрах. Расстояние в пикселях и мы берём порог, равный десятой части кадра, например. Типа объект не может двигаться так быстро, чтобы пролететь/проехать слишком далеко. Но тут появляются сразу две проблемы:

    1. Почему мы взяли 10-ю часть кадра? Очевидно, что для далёких объектов это слишком много, а для близких может быть и мало. Такое ощущение, что порог должен быть свой для каждого детектируемого объекта в зависимости от его размеров и  расстояния до камеры. А если мы распознаём тип объекта, то и для типа: автомобиль может проехать с одной максимальной скоростью, а человек нет.

    2. Если мы хотим использовать в качестве расстояния не только расстояние между центрами на текущем и предыдущем кадрах, а ещё и расстояние между, скажем, гистограммами, то получится, что они имеют совершенно разные размерности. Одно в пикселях, а другое относительно. Хочется первое тоже как-то нормировать от [0, 1], но непонятно как. Разделить на диагональ кадра будет слишком круто, значения окажутся черезчур маленькими. Как нормировать расстояние в пикселях?

    Кажется, что проблему так сходу не решить или решить только костылями. Делать калибровку камеры и считать расстояния не в пикселях, а в метрах. Это может помочь, если бы мы знали тип объекта и его размер, так как посчитать расстояние до него по одной камере не всегда возможно. То есть для людей и машин на одной плоскости это может быть хорошо, а с птицами на расстоянии 10 и 100 метров от камеры будет всё плохо. Да и откалибровать камеру редко когда можно.

    Хорошее распознавание может помочь: для людей, легковушек, велосипедов и т.п. можно задать средние размеры и средние скорости, строить модели движения и пороги индивидуально. Но это тоже не всегда выход, если нам надо детектировать всё движение и/или маленькие объекты. Нейросети плохо себя чувствуют, когда есть объект в 4-8 пикселей размером, их либо не задетектит, либо будет ооочень медленно. Да и не во всех задачах нейросети применимы.

    Напрашивается ещё решение: применять сначала какой-то средний порог в зависимости от размера объекта. Типа объект не может сдвинуться дальше, чем, скажем, три его диагонали. А далее брать из фильтра Кальмана его скорость и корректировать этот порог исходя ещё из скорости. соответственно и нормировать можно на него.

    Вооот. получился не столько вопрос, сколько рассуждения. Если у кого-то есть какие-нибудь мысли или успешный опыт решения проблемы - welcome.

  23. Опубликовано · Report reply

    А точно, просто увидел твой текст про опции линковки и пропустил про рантайм.

    Статья трёхлетней давности, кто его знает, правильно там или нет. Почему ты не собираешь стандартые примеры из репозитория TF? Зачем начинать с левой статьи?

  24. Опубликовано · Report reply

    Возможно, что в pip-пакете что-то не так. Ты смотрел таблицу экспорта? Есть там все функции или нет?

    Я  помню, что после сборки запускал стандартные примеры и они работали. Далее для удобства использовал cmake обвязку: то ли эту, то ли ту.

  25. Опубликовано · Report reply


    Непонятно, что за эксперименты ты проводил. Я кидал выше ссылку с экспериментом с рукой, он работает и там сказано, что означает каждый из коэффициентов - каждое из расстояний. Разумеется, что 0 не обязательно означает абсолютное совпадение. Например, корреляции совпадение будет равно 1.

    Далее, похожесть по цвету в RGB выразить трудно или невозможно.

    Размывать гистограмм у можно, хуже не будет. Но можно просто взять размер бина побольше, что будет равносильно box фильтру.

    Ну игистограммы не идеальны, тут никто не спорит, но проблема не в OpenCV. На OpenCV проще с ними экспериментировать, потому что почти всё необходимое уже реализовано.

    Последнее: гистограммы должны быть только частью веса ребра графа, поток в котором мы ищем. Повторюсь, что надо комбинировать признаки.

    • Like 1
×