Для распознавания лиц данный метод подойдет ограниченно. Вот статья, habrahabr.ru/post/103107/
где такое описывается. Но в таком виде, как оно там представлено — использовать в реальности не получиться, потому что очень сильно зависит от угла зрения.
//А Вы не занимались распознованием натуральных изображений в качестве маркеров?
//Я давно этой темой занимаюсь, и хороших людей в комманду найти не могу =(
Посмотрел видео — да интересно, вроде бы и здорово. Но это проект на свободную часть дня и больше ради удовольствия. А я к сожалению сейчас себе регулярно этого не могу позволить. А было бы интересно.
Вроде бы согласен, но вроде бы и не так. Пятно найти — да, согласен. А потом внутри пятна — обесцветить, перевсти в ЧБ, найти угол и т.д. Комбинация маленьких алгоритмов.
Преобразование Хафа: Картинка планировалась, но потом оказалось что нужно несколько картинок и еще одна страница беглого объяснения к ним. А двоеточие то осталось. Вот ссылка на хорошую статью об этом методе www.waset.org/journals/waset/v42/v42-9.pdf.
C механикой не все так просто. Уровень квалификации решает. Такие очки позволят снизить «порог» входа в механики. Но согласен, на вскидку — выглядит мутно. Единственное — это может помочь монополизировать сферу ремонта авто. Хочешь открыть мастерскую — купи комплект, в бумаге уже не выдаем. Только так — дорого и удобно. Эдакий макдональдс. Где работают не повара, а рабочие.
Плюс человеческий фактор. Наверное тонны пластиковых замочков переломаны молодыми неопытными механиками.
т.е. создание произвольного маркера. Тут проблема в том, что произвольный маркер должен обладать свойствами для «быстрого и надежного» распознавания. Т.е. он должен быть контрастным, и т.д. Отдельная песня — разная цветопередача и сегментация. Т.е. получается что для каждого изображения нужно делать свой распознаватель. И пока, то с чем я сталкивался, подсказывает мне что для разных изображений понадобятся разные комбинации простых алгоритмов.
А про BMW — жаль что не существовало… Вот тут автор расказывает что у американских военных разрабатывается что-то подобное. graphics.cs.columbia.edu/projects/armar/index.htm Потому я и подумал что не фейк.
А вообще — при распознавании всегда заужается область и ограничивается задача. Взять хоть файнридер, хоть распознавание номеров автомобиля…
Да, есть такие проблемы. Но тут идея какая — должна быть почти идеальная ситуация — т.е. хорошо напечатанный маркер без засветов, нормальное освещение.
А фильтрация — да, именно потому внутрь квадрата добаляют простой идентификатор, который потом распознают. Как распознают, чтобы быстрее — это тема для отдельной статьи, притом на любителя.
В OpenCV есть функция approxPolyDP, которая работает по этому алгоритму. Можно с ней поиграться на разных изображениях.
Да, я когда писал статью смотрел в исходники этой библиотеки. На основе OpenCV делаются графические преобразования, а математика как в ARToolkit. Учитывая развитие графических функций OpenCV, она может даже производительнее чем написанные реализации ARtoolkit.
Lighting. Посмотрел в GIMP — они перевели как «светлота». Еще можно как «освещенность». Не знаю какой термин более уместный. Выбрал «светлота» — она ближе пользователям GIMP'а
Я уже писал про оптимизации компилятора. Она работает несколько иначе. Код оптимизирован под процессор(я вводил core2) но не использовались -O — потому что они анализируют код убирая «лишние» вызовы и т.п., при этом особо не трогает тело функции. В С я работаю исключительно с памятью. И компилятор старается тоже так делать. А в ассемблерной вставке — регистры. Кроме того несколько уменьшается количество команд.
// Определяем ключевые точки
surfDetDes(img, ipts, false, 4, 4, 2, 0.001f);
вот через ipts можно получить структура, которую потом сохранить в БД.
где такое описывается. Но в таком виде, как оно там представлено — использовать в реальности не получиться, потому что очень сильно зависит от угла зрения.
developer.android.com/sdk/tools-notes.html
Пишут, что в новом SDK, начиная с 4.0 версии андроид вебкамера работает.
developer.android.com/sdk/tools-notes.html
В тоже время в официальной документации пишут, что ограничение для эмулятора — получение видеоданных с устройства.
developer.android.com/guide/developing/devices/emulator.html (В самом низу).
Потому не стал рыть дальше и использовал велосипед.
lambdajive.wordpress.com/2008/12/20/cross-compiling-for-iphone/
И тогда ArUco.
www.uco.es/investiga/grupos/ava/node/26
И еще, ссылочка в догонку:
www.jonathansaggau.com/iOSAugmentedReality2011Boston.pdf
//Я давно этой темой занимаюсь, и хороших людей в комманду найти не могу =(
Посмотрел видео — да интересно, вроде бы и здорово. Но это проект на свободную часть дня и больше ради удовольствия. А я к сожалению сейчас себе регулярно этого не могу позволить. А было бы интересно.
Прозрачно = Понятно.
Плюс человеческий фактор. Наверное тонны пластиковых замочков переломаны молодыми неопытными механиками.
А про BMW — жаль что не существовало… Вот тут автор расказывает что у американских военных разрабатывается что-то подобное. graphics.cs.columbia.edu/projects/armar/index.htm Потому я и подумал что не фейк.
А вообще — при распознавании всегда заужается область и ограничивается задача. Взять хоть файнридер, хоть распознавание номеров автомобиля…
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.6036&rep=rep1&type=pdf
А фильтрация — да, именно потому внутрь квадрата добаляют простой идентификатор, который потом распознают. Как распознают, чтобы быстрее — это тема для отдельной статьи, притом на любителя.
В OpenCV есть функция approxPolyDP, которая работает по этому алгоритму. Можно с ней поиграться на разных изображениях.