Jump to content
Compvision.ru

Nuzhny

Пользователи
  • Content count

    1,415
  • Joined

  • Last visited

  • Days Won

    174

Nuzhny last won the day on December 15 2020

Nuzhny had the most liked content!

Community Reputation

238 Эксперт

2 Followers

About Nuzhny

  • Rank
    Эксперт

Profile Information

  • Пол
    Мужской
  • Расположение
    Санкт-Петербург

Recent Profile Visitors

4,665 profile views
  1. Если пишешь на С++, то всё просто. Контуры представляются в виде векторов (std::vector), поэтому можно просто добавить точки из всех векторов в один и для него вызвать cv::convexHull
  2. А что такое сдвиги? Матрица гомографии хранит сдвиг центра в координатах H[0, 2] и H[1, 2]. Понятно, что с учётом поворота, наклона и изменения размера, для каждого пикселя будет свой сдвиг. И чтобы его получить, надо дополненные координаты пикселя умножить на матрицу гомографии. То есть [xi_new, yi_new, 1] = H * [xi, yi, 1]. Ещё можно предположить, что требуется найти разложение матрицы гомографии на составляющие (на роизведение матриц для отдельных преобразований): сдвиг, вращение, скейл... Это тоже решается, но, кажется, не однозначно.
  3. Гомография же задаёт в общем случае перспективное преобразование. В этом случае, между плоскостями двух снимков есть 2 угла: поворота и наклона. И они, кажется, связаны друг с другом. Если мы имеем дело с аффинным преобразованием, то да - у нас есть один угол поворота и всё.
  4. 1. Радианы. Но в общем случае твой способ может не работать. 2. Сдвиг - это H[0, 2] и H[1, 2]. Но для разных пикселей он разный.
  5. Предлагаю начать либо с голого tesseract-ocr, либо с примеров из opencv_text. А потом по результатам.
  6. всем привет, может есть у кого пример кода захвата видео с нескольких ip-камер на с++ opencv

  7. На Питоне вряд ли, зачем на нём делать? Но это всё просто, сам можешь сделать
  8. Тогда и правда лучше проверь версии поновей, они с ffmpeg хорошо дружат. Ну и сам ffmpeg из командной строки можешь проверить - умеет ли он h.264
  9. Кажется, что на сшитом уже ничего особо не сделаешь - раньше надо было делать то, что используется в stitching методах. А тут разве что классический deblocking может зайти, чтобы не попортить информацию. Debloking - это просто фильтр вдоль границ склейки по сути.
  10. Кажется, что на представленном рисунке не CLAHE, а простой equalizeHist. Только лучше с этим поэкспериментировать. Минимум это: RGB изображение -> split по каналам -> equalizeHist для каждого канала -> merge. Но возможно, что лучше сработает перевод картинки в другое цветовое пространство, например HSV, а там делать эквализацию не для всех каналов, а только для насыщенности. Или для насыщенности и яркости. Короче, надо экспериментировать. Но и CLAHE может зайти, потому что эквализация - это довольно жёсткое преобразование и может сильно исказить (зато без потери информации).
  11. В OpenCV в модуле opencv_stitching для этого есть класс ExposureCompensator. Лучше изучи, как работает пример stitching_detailed. Там весь пайплайн сшивки панорамы и все необходимые кусочки есть.
  12. Кажется, что лучшее решение - это всё таки 3D реконструкция, например smf. Скормите ему все свои картинки и получите координаты камеры в 3D для каждого снимка.
  13. Я бы делал сегментацию пола грузовика. Калибровка камеры не нужна, если известен размер кузова. То есть знаем площадь, знаем объём свободного места от сегментации - профит.
  14. Согласен, надо ставить breakpoint до падения, чтобы убедиться, что хотя бы каскад загружен и вообще почему падает. Не исключено, что в той версии OpenCV были ошибки или UB, а тут новый компилятор и они стрельнули.
×