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

Nuzhny

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

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

  • Посещение

  • Days Won

    176

Все публикации пользователя Nuzhny

  1. Можно у Capture посмотреть свойство CAP_PROP_BACKEND.
  2. Напиши на github в issues. Разработчики откликаются, исправляют/добавляют.
  3. Вот. Надо использовать LSTM сеть из С++ кода и почти всегда исполняться будет на CPU. Кроссплатформенно, на Windows в том числе. По результатам исследований: 1. Caffe практически перестал развиваться, не перспективно. Что на нём с LSTM непонятно из-за отсутствия примеров и документации. 2. Caffe 2 сырой, стандартный пример с LSTM не работал, потом глюк исправили, но шаг влево, шаг вправо - опять не работает. На issues на Гитхабе не отвечают, площадки для обсуждения нет. 3. TensorFlow официально не поддерживает С++ API под Windows. Собрать самому можно по инструкциям со SO, но не все доступные опции заработали. 4. Тут хавалят MXNet. Стоит ли пробовать? Вроде как на нём можно и обучать и использовать в продакшене. 5. Неожиданно выяснилось, что OpenCV умеет на CPU и быстро использовать сети, обученные в том же TF и Torch. Это было бы удобно. Кто что использует или посоветует для подобных целей? Что лучше выбрать 4 или 5?
  4. Это для всех сетей. Мы для кастомной LSTM так делали - заработало.
  5. Попробуй принудительно изменить backend у capture: CAP_FFMPEG, CAP_DSHOW или CAP_VFW. Они выбираются по очереди, какой первый подойдёт. Возможно, что у тебя первый в списке как раз не аппаратный.
  6. Сейчас же в OpenVINO есть предобученная сетка для поиска номера (там можно ещё тип и цвет машины распознавать). На процессоре работает намного быстрее.
  7. Можно более формально описать задачу и оставить один работающий способ. При вызове того же matchTemplate указывается метрика, по которой сравнение происходит. Запусти его на всех твоих возможных данных и посмотри итоговые значения, при которых всё находится правильно. Ещё можно посмотреть на результаты в малой окрестности. Так можно определиться с минимальнылм порогом и понять, что это именно он. Далее уже самому написать цикл, в котором пробегаться по всей картинке и сравнивать. Причём можно сравнивать не весь кусочек целиком, а делать быстрый выход, если мы превысим порог по метрике на первых пикселях. То есть решать именно твою задачу.
  8. Хоть как-то на распознавании (inference) или хоть как-то на обучении (train)? Для обучения лучше 8 Гб памяти и больше.
  9. Ммм, он и правда быстрый, просто у тебя задача по-другому формулируется. Мне, например, интересно, что значит "первое нахождение заданного шаблона". Там же куча метрик, совпадение пиксель-в-пиксель в реальных приложениях явно не возможно. В смысле, чтобы значение каждого пикселя совпало и метрика стала нулевой. Также понятно, что минимум врядли будет находиться в одной точке. Скорее всего, будет что-то похожее на параболоид - если визуализировать результат работы сравнения в 3D. И тут вопрос, насколько он пологий. Если сильно пологий, то не исключено, что результат ложный. То есть мало получить значение метрики ниже какого-то порога, надо ещё и проанализировать окрестность, чтобы убедиться в том, что минимум настоящий. У меня был опыт в нахождении таких штук: надо было определиться куда сместились блоки по 16х16 пикселей. Такие блоки на границах объектов, на чистом небе, на регулярных структурах (окна дома вдалеке) давали совершенно неожиданные результаты. Приходилось выдумывать сложные метрики и анализ.
  10. Понятно. Тогда MatchTemplate просто делает не то, что требуется: ищет не первое вхождение (видимо, по какому-то порогу), а карту всех вхождений. Отсюда и низкая скорость. Честно говоря, я не уверен, что подходящая функция в OpenCV есть. Но и реализация не должна быть сложно, разве нет?
  11. Мне кажется, что надо начать с элементарного, MatchTemplate. Там никакого распознавания не происходит, работает быстро. Пусть это будет точка, от которой можно отталкиваться по скорости работы.
  12. Курсы помогут в самом начале, чтобы можно было ориентироваться в том, что есть. Ну и не дадут упустить важную тему. Кажется, что при достаточном опыте, они уже не нужны.
  13. Ошибка при сборке

    Только что скачал свежую версию, скомпилировал с WITH_OPENMP и твой пример отработал без ошибок. Возможно, оно проявляется только у тебя или нужна именно твоя картинка.
  14. Ошибка при сборке

    Хорошо, спасибо.
  15. Ошибка при сборке

    Хм. Это не так просто повторить. можешь подсказать с каким-нибудь стандартным примером из поставки? Какие параметра подавать в тот же example_aruco_detect_markers, например. Я как раз засылал им один PR по поводу openmp для 4.0. Если баг в parallel_for, то хотелось бы его убрать, чтобы в других местах не проявилось. Всё таки я использую OpenCV в критических приложениях.
  16. Ошибка при сборке

    А пример можешь выслать? Я тоже использую openmp, но она в Windows не развивается (поддерживает стандарт 2.0 при существующем 5.0). Поэтому разработчики OpenCV традиционно делают упор на TBB.
  17. Ошибка при сборке

    Попробуй запустить cmake-gui, там это найти наглядней.
  18. Ошибка при сборке

    OPENCV_EXTRA_MODULES_PATH правильно указан?
  19. В CMake OPENCV_EXTRA_MODULES_PATH=что-то-там/opencv_contrib/modules
  20. Если с OpenCV, то все байты уже у вас, уложены по строкам в IplImage в поле imageData: https://docs.opencv.org/3.4/d6/d5b/structIplImage.html
  21. Откуда взялся String?!! Изображение где лежит, в каком виде ты его получаешь, по сети, с диска, rgb, jpeg - где начало цепочки? Изображение - это явно не строка. В этом форуме чаще всего используют библиотеку OpenCV, которая как раз и переводит изображение из какого-то своего формата (например, jpeg на диске) в удобный для обработки порядок байт.
  22. Изображение - это и есть байты. Мне кажется, что вопрос надо конкретизировать.
  23. В Линуксе nvidia-smi. Наверное в Windows тоже что-то подобное должно быть. И nvtop тоже: https://github.com/Syllo/nvtop
  24. Дрожат - не страшно, потому что ты всё равно сглаживать будешь. В ссылке из первого поста используют moving average, но можно и экспоненциальное сглаживание, и Кальмана прикрутить. Дрожь это всё будет убирать. Да, это известная проблема. Поэтому надо либо сегментировать сразу, либо кластеризовать уже вектора и строить несколько "траекторий" для каждого кластера. Если один кластер станет больше того, по которому строится текущая траектория, то сразу на него не переключаться. Всё просто: в кадре два больших плана: передний и задний, которые движутся неравномерно. Видимо, строится гомография между кадрами, поэтому всё так глючит. Если бы строили только сдвиг или сдвиг и ресайз, то всё было бы нормально. В стабилизации произвольного видео надо уметь вовремя прекратить стабилизацию или понизить число степеней свободы - перейти на более простую модель: с гомографии или аффинного к сдвигу, например. Лучше совсем не стабилизировать, чем портить видео.
  25. Нет, стабилизировать по векторам движения, как обычно (блоки, оптический поток - пофиг). Но брать эти вектора только из правильных областей. Если у тебя это лицо, то на лице. Или ты используешь глобальные методы вычисления движения? Типа фазовой коррреляции или глобального Лукаса-Канаде ( https://github.com/Nuzhny007/image-align )?
×