Да я опять без скринов ) на самом деле сижу жду пока произойдет выгрузка модели из 3дмакса ( 400к поликов ... )
Поэтому расскажу пока вот что
Дополненная реальность
итак пути развития есть 2
1 это решение в лоб
- получили картинку с камеры
- нашли на картинке все корнеры ( это границы, грани, очертания и т.д. )
- из того что нашли ( а найти мы можем реально много ) выбираем те которые образует между собой замкнутую область с 4 углами ( вычисляем теоритические маркеры )
- после чего полученные области можно отсечь путем подсчета размера ( к примеру совсем мелкие выкинуть и совсем крупные )
- теперь проверяем пару внутренних пикселей на черный цвет ( или какой у нас в маркере является "ободком" ), и выкидываем все те которые не подходят
- далее оставшиеся уже проверяем, после долгого поиска в гугле я нашел довольно интересный подход, а именно наш рект проецируется на экран, а именно убираются все искажения и получается плоская картинка, как будто наш кусок изображения не лежит на столе, а приклеен к камере, таким образом имея размеры нашего ректа мы можем его "прочитать"( кстати тут если мы знаем точные соотношения нашего маркера мы можем выкинуть еще парочку не подходящих квадратов ), самый простой способ создания маркера это черный белый квадрат, где черный означает битовый флаг сброшен, а белый установлен
в итоге мы получаем заветные наши 4 точки которые через solvePnP можно преобразить в два вектора tVec и rVec далее путем простой математики мы получаем матрицу для openGL
да я сейчас пишу очень поверхностно и без примеров кода и картинок ( на самом деле это пре-статья и я чуть позже напишу более развернуто все )
2 это решение через featureDetect
- получили картинку
- нашли на картинке точки ( определенным образом )
- далее ищем соответствия с просчитанными заранее точками маркера
- ну тут конечно нужно будет отсеять кучу не нужного, например - точки могут найтись там где фактически маркера нету. путь решения - считать длину ( не подходящую выкидывать ), и считать сколько точек сосредоточены в одном месте ( это кстати просто мысль ), судя по тестам ошибочные точки хаотичны и разбросаны по картинке поэтому если подсчитать сколько точек находятся наиболее тесно друг другу в одном месте можно понять нашли мы то что нужно или нет
- мобильная оптимизация, самым главным образом
1 на маркере ищем порядка 1500 точек
2 на кадре ищем порядка 100 точек ( кстати есть статья где говорится что достаточно искать 20 точек но что то мне не верится а времени проверить пока нет )
3 если мы нашли маркер то к следующему кадру мы готовим только найденные точки
- в итоге это позволяет сузить нагрузку но на сколько пока не ясно
- для найденных точек мы вызываем findHomography которая нам выдает матрицу 3х3
- далее по матрице можно а) найти 4 точки описывающие наш маркер, б) построить матрицу для openGL
что дальше ?
дальше для достижения устойчивости нужно заняться трекингом
что это
- трекинг это метод который уже работает не с маркером, а с кадром, то есть мы ищем смещение точек между кадрами по которым строим дополнительную матрицу смещения, соответственно если наш маркер выпадет из вида модель в openGL мы не утеряем !
- второй вариант трекинга это снятие данных с датчика ( типа акселерометр,гироскоп и т.д. ) и по ним уже расчет движения камеры
все это больше похоже конечно на записку чем запись в блоге ) так что считаем это убиением времени и промежуточным вариантом статьи )
Поэтому расскажу пока вот что
Дополненная реальность
итак пути развития есть 2
1 это решение в лоб
- получили картинку с камеры
- нашли на картинке все корнеры ( это границы, грани, очертания и т.д. )
- из того что нашли ( а найти мы можем реально много ) выбираем те которые образует между собой замкнутую область с 4 углами ( вычисляем теоритические маркеры )
- после чего полученные области можно отсечь путем подсчета размера ( к примеру совсем мелкие выкинуть и совсем крупные )
- теперь проверяем пару внутренних пикселей на черный цвет ( или какой у нас в маркере является "ободком" ), и выкидываем все те которые не подходят
- далее оставшиеся уже проверяем, после долгого поиска в гугле я нашел довольно интересный подход, а именно наш рект проецируется на экран, а именно убираются все искажения и получается плоская картинка, как будто наш кусок изображения не лежит на столе, а приклеен к камере, таким образом имея размеры нашего ректа мы можем его "прочитать"( кстати тут если мы знаем точные соотношения нашего маркера мы можем выкинуть еще парочку не подходящих квадратов ), самый простой способ создания маркера это черный белый квадрат, где черный означает битовый флаг сброшен, а белый установлен
в итоге мы получаем заветные наши 4 точки которые через solvePnP можно преобразить в два вектора tVec и rVec далее путем простой математики мы получаем матрицу для openGL
да я сейчас пишу очень поверхностно и без примеров кода и картинок ( на самом деле это пре-статья и я чуть позже напишу более развернуто все )
2 это решение через featureDetect
- получили картинку
- нашли на картинке точки ( определенным образом )
- далее ищем соответствия с просчитанными заранее точками маркера
- ну тут конечно нужно будет отсеять кучу не нужного, например - точки могут найтись там где фактически маркера нету. путь решения - считать длину ( не подходящую выкидывать ), и считать сколько точек сосредоточены в одном месте ( это кстати просто мысль ), судя по тестам ошибочные точки хаотичны и разбросаны по картинке поэтому если подсчитать сколько точек находятся наиболее тесно друг другу в одном месте можно понять нашли мы то что нужно или нет
- мобильная оптимизация, самым главным образом
1 на маркере ищем порядка 1500 точек
2 на кадре ищем порядка 100 точек ( кстати есть статья где говорится что достаточно искать 20 точек но что то мне не верится а времени проверить пока нет )
3 если мы нашли маркер то к следующему кадру мы готовим только найденные точки
- в итоге это позволяет сузить нагрузку но на сколько пока не ясно
- для найденных точек мы вызываем findHomography которая нам выдает матрицу 3х3
- далее по матрице можно а) найти 4 точки описывающие наш маркер, б) построить матрицу для openGL
что дальше ?
дальше для достижения устойчивости нужно заняться трекингом
что это
- трекинг это метод который уже работает не с маркером, а с кадром, то есть мы ищем смещение точек между кадрами по которым строим дополнительную матрицу смещения, соответственно если наш маркер выпадет из вида модель в openGL мы не утеряем !
- второй вариант трекинга это снятие данных с датчика ( типа акселерометр,гироскоп и т.д. ) и по ним уже расчет движения камеры
все это больше похоже конечно на записку чем запись в блоге ) так что считаем это убиением времени и промежуточным вариантом статьи )
Комментариев нет:
Отправить комментарий