Live video идёт без задержек. Через интервалы времени происходит цикл SOTA — по результатам на видео рисуются прямоугольники захваченого текста.
Новые прямоугольники приходят с запозданием- т.е. если камера телефона сместилась, то прямоугольники приходят по старым координатам.

Все телефоны предоставляют api сенсора гироскопа и ускорения.

Вопрос: какие есть формулы, возможно готовые функции OpenCV, которые из аккумулированного вектора ускорения и вращения просчитают transformation matrix 2d для прямоугольников захваченного текста для того, чтобы компенсировать смещение видео в пикселах или в % от dimension?

Здравствуйте, Артём, Вы писали:

Аё>Вопрос: какие есть формулы, возможно готовые функции OpenCV, которые из аккумулированного вектора ускорения и вращения просчитают transformation matrix 2d для прямоугольников захваченного текста для того, чтобы компенсировать смещение видео в пикселах или в % от dimension?
Готовых, что из ускорений и вращений тебе всё посчитают, насколько я помню нет. Но более элементарные функции там есть, заюзав которые, ты сможешь сделать компенсацию. Но не забывай, что и сам объект в пространстве может изменить свое положение.
И не забывай, что IMU не дорогие (в телефонах они) шумят очень сильно и придется еще их сигналы фильтровать. И может оказаться, что будет лучше через Калмана (а только приличный учебник по Калмановской фильтрации страниц 600) сразу считать эти матрицы трансформации.
Вообще темка не простая и вот так сходу я тебе не расскажу. У меня только 2-3 недели уйдет, чтобы повспоминать нужное в этой теме.

Здравствуйте, Артём, Вы писали:

Аё>Вопрос: какие есть формулы, возможно готовые функции OpenCV, которые из аккумулированного вектора ускорения и вращения просчитают transformation matrix 2d для прямоугольников захваченного текста для того, чтобы компенсировать смещение видео в пикселах или в % от dimension?

А не проще по изображению свести?
https://learnopencv.com/image-alignment-ecc-in-opencv-c-python

Здравствуйте, Артём, Вы писали:

Аё>Вопрос: какие есть формулы, возможно готовые функции OpenCV, которые из аккумулированного вектора ускорения и вращения просчитают transformation matrix 2d для прямоугольников захваченного текста для того, чтобы компенсировать смещение видео в пикселах или в % от dimension?

Готового нет, потому что оно не так всё просто, соглашусь с Вжиком. Решение проблемы — это visual SLAM, который на основании картинки и датчиков строит траекторию камеры и карту местности. Это сложно, у гугла был проект, извини за тавтологию, Project Tango, который как раз и позволял смартфону определять себя в пространстве. Его закрыли.
Почему нельзя просто так закладываться на датчики? Потому что ты не знаешь расстояние до объекта. Измеряя только угловое движение ты не получишь точности относительно объекта на неизвестном расстоянии.
Вопреки опасениям Вжика относительно точности телефонных IMU на них вполне можно полагаться на десятки миллисекунд. Но не зная расстояние до цели они никак тебе не помогут.

kov_serg советует делать трекинг по картинке — вот с этим соглашусь, метод работает. Тут уже зависит от разных вещей:
1. ECC alignment будет слишком медленным, как мне кажется. Хотя можно сделать downscale картинки, тогда будет полегче.
2. Можно взять лёгкий детектор точек — у тебя же там текст, точки гарантированно будут. И sparse pyramidal optical flow вполне осилит любой смартфон, оно намного быстрее детекции.
3. Можно брать также лёгкий детектор точек, искать их на соседних кадрах, соответствие между ними (cv::findHomography).
4. Если тебе не надо отслеживать текст на всём кадре, а надо одну небольшую область кадра с одной надписью, то можноо вообще отслеживать только её, это отдельная группа алгоритмов.

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

P.S. Решение для плоскости в принципе простое. Если же будет объект в 3D (надписи на разных плоскостях), то придётся помучаться, тут даже VR очки лажают

Здравствуйте, Nuzhny, Вы писали:

N>Вопреки опасениям Вжика относительно точности телефонных IMU на них вполне можно полагаться на десятки миллисекунд.
Без отлаженной под конкретное железо фильтрации всё одно фигня будет. Я же о шуме (поверю, что дрифта у них нет).
А у него еще в 3-мерном пространстве происходит — это своих сложностей добавит (ббоксы-то у него на плоскости проекции).

Здравствуйте, Nuzhny, Вы писали:

N>Почему нельзя просто так закладываться на датчики? Потому что ты не знаешь расстояние до объекта. Измеряя только угловое движение ты не получишь точности относительно объекта на неизвестном расстоянии.

Расстояние 20-30см из юз кейсов, размер надписи (кода) тоже несильно варьируется. Наибольшая разница в физическом размере экрана.
Если сделать в гуи какой-то аналог настройки, как у Wii, с ползунками, и пооученные цифры констант для формул сохранить в профили для телефона и таблета.

https://developer.mozilla.org/en-US/docs/Web/API/WebXR_Device_API#browser_compatibility

Поигрался с этим на телефоне андроиде- работает. Яблодевайсы не поддерживают.

Здравствуйте, Nuzhny, Вы писали:

Кстати, по поводу трекинга камеры. То есть по видео распознать траекторию движения камеры. Почему-то в топовых программах для спец-эффектчиков, типа АфтерЭффект или Nuke, это распознавание крайне всрато работает. Оно работает если все видео в одной локации. Но если например снимать переход из одного угла квартиры в другой — все, они теряются и дохнут. Тут я например пользуюсь тулзами, использующими AR. Например CamTrackAR или VirtuCamera. Они используют и АР данные и акселерометры для точного определения положения камеры в 3D. Выходит очень точно. И тут это критично. Потому что если наложишь спецэффект хоть немного сдвинутый, то все посыпется в визуале

Здравствуйте, Hоmunculus, Вы писали:

H>Здравствуйте, Nuzhny, Вы писали:

H>Кстати, по поводу трекинга камеры. То есть по видео распознать траекторию движения камеры.
Достаточно легко, если точно известны мировые координаты того, что видит камера.
Безумно сложно решить задачу восстановление из 2d проекций 3d мира — она решаема в теории, но то, что получается в продуктах ты уже попробовал.

Здравствуйте, Hоmunculus, Вы писали:

H>Кстати, по поводу трекинга камеры.
Кстати до сих пор нет рабочих решений и более простой задачи. Из чертежей (полного и непротиворечивого набора) построить 3d тело.
Теоретические научные статьи попадаются.

Здравствуйте, Vzhyk2, Вы писали:


V>Кстати до сих пор нет рабочих решений и более простой задачи. Из чертежей (полного и непротиворечивого набора) построить 3d тело.
V>Теоретические научные статьи попадаются.

Может нужды нет. Сейчас процесс построения-то обратный — сначала тридэшку строят, а из нее чертежи получают.

Здравствуйте, Hоmunculus, Вы писали:

H>Может нужды нет. Сейчас процесс построения-то обратный — сначала тридэшку строят, а из нее чертежи получают.
Вот ты и сам ответил на свой предыдущий вопрос.

Здравствуйте, Артём, Вы писали:

Аё>Live video идёт без задержек. Через интервалы времени происходит цикл SOTA — по результатам на видео рисуются прямоугольники захваченого текста.
Аё>Новые прямоугольники приходят с запозданием- т.е. если камера телефона сместилась, то прямоугольники приходят по старым координатам.

Аё>Все телефоны предоставляют api сенсора гироскопа и ускорения.

Аё>Вопрос: какие есть формулы, возможно готовые функции OpenCV, которые из аккумулированного вектора ускорения и вращения просчитают transformation matrix 2d для прямоугольников захваченного текста для того, чтобы компенсировать смещение видео в пикселах или в % от dimension?

А как ручные 3-d сканеры работают, я думаю их принципы позиционирования относительно объекта тут можно использовать.

Здравствуйте, Vzhyk2, Вы писали:

V>Здравствуйте, Hоmunculus, Вы писали:

H>>Может нужды нет. Сейчас процесс построения-то обратный — сначала тридэшку строят, а из нее чертежи получают.
V>Вот ты и сам ответил на свой предыдущий вопрос.

И кинематографистов и спец-эффектчиков есть нужда по видео трекать путь камеры. Сейчас просто лишние девайсы для этого используют

Здравствуйте, Hоmunculus, Вы писали:

H>И кинематографистов и спец-эффектчиков есть нужда по видео трекать путь камеры. Сейчас просто лишние девайсы для этого используют
Значит имеющиеся решения проще и дешевле, чем ты предлагаешь.

Здравствуйте, Vzhyk2, Вы писали:

V>Здравствуйте, Hоmunculus, Вы писали:

H>>И кинематографистов и спец-эффектчиков есть нужда по видео трекать путь камеры. Сейчас просто лишние девайсы для этого используют
V>Значит имеющиеся решения проще и дешевле, чем ты предлагаешь.

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

Сейчас решение — прикреплять айфон к профессиональной камере и снимать одновременно. Получается хорошо. Но что-то сомневаюсь что у Голливуде делают так

Здравствуйте, Nuzhny, Вы писали:

N>P.S. Решение для плоскости в принципе простое. Если же будет объект в 3D (надписи на разных плоскостях), то придётся помучаться, тут даже VR очки лажают

Что не так с тз трекинга? Нижний разве что искажает изображение заодно.

Здравствуйте, Sharov, Вы писали:

S>Что не так с тз трекинга? Нижний разве что искажает изображение заодно.

На верхнем видно, что точки-вектора на верхнем видео детектируются не на каждом кадре и трекаются между кадрами. И они довольно сильно отстают, видно что или трекинг их не справляется, или математическая модель (условный фильтр Калмана) слишком инертен. На нижнем видео точки движутся практически чётко с руками

Здравствуйте, Nuzhny, Вы писали:

N>На верхнем видно, что точки-вектора на верхнем видео детектируются не на каждом кадре и трекаются между кадрами. И они довольно сильно отстают, видно что или трекинг их не справляется, или математическая модель (условный фильтр Калмана) слишком инертен. На нижнем видео точки движутся практически чётко с руками
Если о фильтре Калмана, то почти везде в обработке видео его применяют сильно неправильно. Фильтр Калмана требует жестко, чтобы шум был белым, а иначе фильтровать будет плохо.
Там или физическую модель сложной делать или работать в мировых 3d координатах нужно.

Здравствуйте, Vzhyk2, Вы писали:

V>Там или физическую модель сложной делать или работать в мировых 3d координатах нужно.

Понятное дело, что в мировых координатах и с хорошей моделью будет лучше. У меня есть надежда, что VR устройства так и делают. Потому что простой вариант детектора точек с оптическим потоком и Калманом в пикселях на картинке делается на OpenCV с полпинка (мой старый ответ на SO с видео). В реальных продуктах надо сильно улучшать, делать нормальный трекинг и математическую модель.

Здравствуйте, Nuzhny, Вы писали:

N> простой вариант детектора точек с оптическим потоком и Калманом в пикселях на картинке делается на OpenCV

Фильтр Калмана в пикселах- это ж затормозит девайс? У меня юз кейс возник как раз из-за того, что SOTA не риалтайм- т.е. фильтр Калмана не только ещё больше затормозит SOTA, но и сам нефакт, что в реалтайм будет поспевать. Потому идея использовать акселерометр- ничего не стоит в вычислениях.

Здравствуйте, Артём, Вы писали:

Аё>Фильтр Калмана в пикселах- это ж затормозит девайс? У меня юз кейс возник как раз из-за того, что SOTA не риалтайм- т.е. фильтр Калмана не только ещё больше затормозит SOTA, но и сам нефакт, что в реалтайм будет поспевать.

Ну, это уже зависит от конкретно твоих условий. Я надеюсь, что твоя нейронка работает на GPU или NPU, а CPU в это время если не простаивает, то более-менее свободен. Если так, то лёгкий трекинг или детекцию ключевых точек вполне можно на нём запускать

Здравствуйте, Nuzhny, Вы писали:

N>На верхнем видно, что точки-вектора на верхнем видео детектируются не на каждом кадре и трекаются между кадрами. И они довольно сильно отстают, видно что или трекинг их не справляется, или математическая модель (условный фильтр Калмана) слишком инертен. На нижнем видео точки движутся практически чётко с руками

Блин, даже внимания не обратил. Но на нижнем видео большая дисторсия изображения вокруг рук, это ведь тоже не здорово.

Здравствуйте, Артём, Вы писали:

Аё>Вопрос: какие есть формулы, возможно готовые функции OpenCV, которые из аккумулированного вектора ускорения и вращения просчитают transformation matrix 2d для прямоугольников захваченного текста для того, чтобы компенсировать смещение видео в пикселах или в % от dimension?

Новая работа в ml, или по роду деятельности приходится сталкиваться на старой работе?

Здравствуйте, Nuzhny, Вы писали:

N>Понятное дело, что в мировых координатах и с хорошей моделью будет лучше. У меня есть надежда, что VR устройства так и делают.
Ты сильно оптимистичен. Это всё требует наличия реальных спецов, а это опровергают принципы современного найма в мире. Кроме того, такое разрабатывать долго и дорого, что повышает расходы.
А хомячки потребляют не по качеству, а по маркетингу.

Здравствуйте, Sharov, Вы писали:

S>Но на нижнем видео большая дисторсия изображения вокруг рук, это ведь тоже не здорово.

У меня есть подозрение, что они так склеивают видео с двух камер в одно панорамное. Скорее всего каждое в отдельности более менее норм, но в процессе склейки они не заботятся о качестве панорманого видео, а только лишь о качестве картинки рук. Вот вокруг них всё и плывёт. Это всё только предположения

Здравствуйте, Артём, Вы писали:

Аё>Фильтр Калмана в пикселах- это ж затормозит девайс?
Нет, типичный прост, как валенок и с ним справляются и ардуинки. Но работает он неправильно, но вот это и есть мелочь.
И этот простой Калман великолепен, но только в случае простой модели движения и белого шума.

Здравствуйте, Vzhyk2, Вы писали:

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

Ну да, где же Apple возьмёт хороших спецов? Негде.

Здравствуйте, Nuzhny, Вы писали:

N>Ну да, где же Apple возьмёт хороших спецов? Негде.
Достаточно внимательно посмотреть на их продукты и ты поймешь, где у них спецы и в чем.

З.Ы. И ради бога только не начинай тянучку про то, что вкус блюда может оценить только повар, что его приготовил.

Здравствуйте, Sharov, Вы писали:

S>Новая работа в ml, или по роду деятельности приходится сталкиваться на старой работе?

Просто прототипная фича в продукте, неготовая к релизу.

Здравствуйте, Vzhyk2, Вы писали:

V>З.Ы. И ради бога только не начинай тянучку про то, что вкус блюда может оценить только повар, что его приготовил.

Мне иногда кажется, что ты отвечаешь кому-то другому или в момент ответа думаешь о чём-то постороннем. То считаешь, что граждане Великобритании не могут быть индусами, тут вообще про тянучку. Я не знаю, что тебе ответить, правда. Тема про трекинг объекта между детекциями. Тема актуальная, используется много где, решается по-разному и с разным качеством. Обычно математиками и программистами, а не поварами.