Nuzhny

А что такое сдвиги? Матрица гомографии хранит сдвиг центра в координатах H[0, 2] и H[1, 2]. Понятно, что с учётом поворота, наклона и изменения размера, для каждого пикселя будет свой сдвиг. И чтобы его получить, надо дополненные координаты пикселя умножить на матрицу гомографии. То есть [xi_new, yi_new, 1] = H * [xi, yi, 1]. Ещё можно предположить, что требуется найти разложение матрицы гомографии на составляющие (на роизведение матриц для отдельных преобразований): сдвиг, вращение, скейл... Это тоже решается, но, кажется, не однозначно.

Гомография же задаёт в общем случае перспективное преобразование. В этом случае, между плоскостями двух снимков есть 2 угла: поворота и наклона. И они, кажется, связаны друг с другом. Если мы имеем дело с аффинным преобразованием, то да - у нас есть один угол поворота и всё.

1. Радианы. Но в общем случае твой способ может не работать. 2. Сдвиг - это H[0, 2] и H[1, 2]. Но для разных пикселей он разный.

Предлагаю начать либо с голого tesseract-ocr, либо с примеров из opencv_text. А потом по результатам.

На Питоне вряд ли, зачем на нём делать? Но это всё просто, сам можешь сделать

Тогда и правда лучше проверь версии поновей, они с ffmpeg хорошо дружат. Ну и сам ffmpeg из командной строки можешь проверить - умеет ли он h.264

A x264 работает?

Кажется, что на сшитом уже ничего особо не сделаешь - раньше надо было делать то, что используется в stitching методах. А тут разве что классический deblocking может зайти, чтобы не попортить информацию. Debloking - это просто фильтр вдоль границ склейки по сути.

Кажется, что на представленном рисунке не CLAHE, а простой equalizeHist. Только лучше с этим поэкспериментировать. Минимум это: RGB изображение -> split по каналам -> equalizeHist для каждого канала -> merge. Но возможно, что лучше сработает перевод картинки в другое цветовое пространство, например HSV, а там делать эквализацию не для всех каналов, а только для насыщенности. Или для насыщенности и яркости. Короче, надо экспериментировать. Но и CLAHE может зайти, потому что эквализация - это довольно жёсткое преобразование и может сильно исказить (зато без потери информации).

В OpenCV в модуле opencv_stitching для этого есть класс ExposureCompensator. Лучше изучи, как работает пример stitching_detailed. Там весь пайплайн сшивки панорамы и все необходимые кусочки есть.

Кажется, что лучшее решение - это всё таки 3D реконструкция, например smf. Скормите ему все свои картинки и получите координаты камеры в 3D для каждого снимка.

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

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

Кажется, что прямо на OpenCV этого из коробки нет, но в dlib есть.

Я пока попробовал 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). Потестирую, если будет медренно, то надо будет реализовывать самому и оптимизировать.

Приветствую! А в OpenCV есть что-нибудь для аппроксимации набора точек полиномом произвольной степени? Есть fitLine для прямой, а что-то большее?

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

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

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

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

Не проверял на jetson, надо попробовать.

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

В OpenCV уже давно есть модуль для нейросетей opencv_dnn, есть специализированный для детекции на dnn, а сейчас есть и dnn на CUDA. Так что он актуальности своей терять не собирается, не хороните

Перевести в HSV и обнулить калан H?

Да