Comments 2
Давно на смотрел на практические либы в этой теме но их развитие вполне предсказуемо - вместо того чтобы сложным образом строить метки - готовим сразу, предрасчитваем и потом осуществляем просто детектирование.
А вы сами пробовали переопределять метки, алгоритмы детекции, описания итд?
Ну смотря о чём речь. Если прям Image Target Tracking, без детекции через OpenCV чего-то вроде QR кода и т.п. — нет, так как в целом практические либы устраивают по своим параметрам. А если аналоги простых методов, то тут маркером смотря что считать. Если брать определение реперной точки (с пафосным названием фидуциальный маркер), то на OpenCV можно много под что написать конкретный классификатор. Некое обобщённое решение делать не пробовал. Но скажем, чтобы в качестве маркера выступала лента из последовательности цветов — конечно.
Так как бывают разные условия, требования к качеству и к точности. Допустим нет возможности в систему установить камеру высокого разрешения или рассчитывать на камеру высокого разрешения. Поэтому мы сразу отметаем сложные и детальные маркеры, так как они из-за разрешения камеры не будут распознаваться. Пока если честно просто не встречал задачи, где это было бы необходимо. Единственная интересная область — это веб, так как остальных случаях коробки работают хорошо. А веб без допила всегда и стабильно тормозит, если вообще не иметь экспертизы в компьютерном зрении.
Там же есть ещё одна проблема в плане разрешения. Даже если мы первичный классификатор детектор делаем, который для начала находит метки на кадре (ну так работает сейчас почти любой современный алгоритм) Нюансы в плане разрешения связаны ещё с требуемой производительностью же и сложностью анализа кадра. Поэтому писать свой велосипед я вижу смысл для веба сейчас, так как там есть много нюансов. А вот в остальных случаях достаточно как раз понимать принцип работы алгоритма на мой взгляд, чтобы понимать почему не работает. Маркерный трекинг всё же с нюансами можно считать решённой задачей, у которой не так много проблем. Свой SLAM писать поинтереснее будет :) Хотя тоже лень пока этим заниматься :)
Так как бывают разные условия, требования к качеству и к точности. Допустим нет возможности в систему установить камеру высокого разрешения или рассчитывать на камеру высокого разрешения. Поэтому мы сразу отметаем сложные и детальные маркеры, так как они из-за разрешения камеры не будут распознаваться. Пока если честно просто не встречал задачи, где это было бы необходимо. Единственная интересная область — это веб, так как остальных случаях коробки работают хорошо. А веб без допила всегда и стабильно тормозит, если вообще не иметь экспертизы в компьютерном зрении.
Там же есть ещё одна проблема в плане разрешения. Даже если мы первичный классификатор детектор делаем, который для начала находит метки на кадре (ну так работает сейчас почти любой современный алгоритм) Нюансы в плане разрешения связаны ещё с требуемой производительностью же и сложностью анализа кадра. Поэтому писать свой велосипед я вижу смысл для веба сейчас, так как там есть много нюансов. А вот в остальных случаях достаточно как раз понимать принцип работы алгоритма на мой взгляд, чтобы понимать почему не работает. Маркерный трекинг всё же с нюансами можно считать решённой задачей, у которой не так много проблем. Свой SLAM писать поинтереснее будет :) Хотя тоже лень пока этим заниматься :)
Sign up to leave a comment.
Обзор технологий трекинга: AR маркеры