2Виталий: Да ничем не лучше и EDV не утверждал этого просто он у него унифицированный - и образы распознает и feature-detector, вот и всё. Он же не выступает на научной конференции с докладом об открытии нового метода навигации доселе науке неведомого
Но что самое интересное, что для SLAM его метод не нужен, есть ведь и другие - открытые методы детектирования особенностей. =) Или может EDV нам объяснит, чем же его метод лучше других? (Это не вопрос-противопоставление, мне действительно интересно).
Да ничем не лучше, метод как метод. Матрицы, декомпозиции, дерево поиска всё как обычно. А закрытый ну просто, потому что мне за него деньги платят (коммерческий софт). Ну а там уже на любителя, какой метод использовать, лишь бы работало (вот AVM работает, это вот точно).
Как выделяются эти самые фрагменты? Например, как она обработает чёрную букву "Ж" на белом фоне, конкретно интересуют две антенки в виде V, от средней палки.
Ну, так они сами всё протестировали и приняли решение приобрести исходные тексты алгоритма AVM. Я их не заставлял.
Vorral писал(а):Как выделяются эти самые фрагменты? Например, как она обработает чёрную букву "Ж" на белом фоне, конкретно интересуют две антенки в виде V, от средней палки.
Запоминаем по сетке квадратные фрагменты изображения (80x80 пикселей) на предыдущем кадре, а потом на следующем ищем (в окрестности) куда каждый из них сдвинулся.
А с буквой “Ж” всё нормально будет, потому что её усики слева и с право на 180 градусов повёрнуты относительно друг друга (смотрят в разные стороны), а алгоритм AVM к повороту не инвариантен (так что эти усики для него разные объекты). Я бы больше волновался с повторяющимися символами типа «>>>>>» вот тут точно проблема возникнет.
Мне кажется, что быстрее будет работать, если брать не области 80x80(или 40х40 в случаи 320х240). А множество различных точек(что типа "особых" точек). Весь вопрос по какому критерию это лучше сделать. И уже на следующем кадре пытаться их найти. Я именно с такого способа начну вникать в Optical-flow. С перемещениями вверх/вниз, вправо/влево ясно. А как у неё получается найти дальше/ближе? Ведь квадрат может либо увеличиваться, либо уменьшаться?
Добавлено спустя 16 минут 21 секунду: У себя для стереозрения я ликвидировал проблему повторяемости «>>>>>». Но там другие условия, тут надо тоже какую-нибудь хитрость придумать, потому как считаю, что это проблема крайне серьёзная.
В пределах увеличилось/уменьшилось на 25% AVM распознает, а вот если больше, то нужно будет дополнительное сканирование устраивать при поиске (уменьшенными и увеличенными областями интереса).
Мне кажется, что быстрее будет работать, если брать не области 80x80(или 40х40 в случаи 320х240). А множество различных точек(что типа "особых" точек).
Вся суть алгоритма от EDV - это как раз компромисс между этими двумя решениями как я понимаю. С одной стороны особые точки хорошо, но вот непонятно, что быстрее найти особые точки или сработать по области.
Так особые точки тоже по разному могут находится, для этого всё равно, нужно осмотреть соседние пиксели(можно тем же квадратом 40х40, хотя мне он кажется слишком крупным). Один их вид, мне подсказал Dead, это центр массы монотонной фигуры со значением инерции(в некоторых ситуациях они будут неплохо срабатывать, когда фигура не приближается/удаляется/поворачивается). Остаются зоны с резкой сменой цвета. Их я предполагаю тоже выделить в фигуры и подробить(если они окажутся больше порога). Мне кажется, чем больше точек будет, тем лучше, как говорил EDV важна общая статистика, а не надежда в виде пары маяков. Лишние точки просто можно запросто откинуть. Я сторонник уменьшения блока с 40х40, например на 16х16