roboforum.ru

А также в наличии на реальных изображениях других предметов, что немаловажно. =)

_________________
Все новости о моих проектах http://savethebest.ru

Образцы реальных изображений с маяками:

С радиокамеры:


С веб-камеры ноутбука:


Добавлено спустя 23 минуты 1 секунду:
Последовательность фильтров в фотошопе для эксперимента:
1. Перевод изображения в режим "градации серого";
2. Автоконтраст;
3. Заказной фильтр вот такой:

4. Перевод в ч-б изображение с отсечением по 50% яркости;

Добавлено спустя 2 минуты 18 секунд:
Вот что у меня получилось пока:

С радиокамеры:




С вебкамеры ноута:



Очевидно с радиокамеры всё вообще отлично, а в вебкамере ноута похоже производитель искусственно обработал изображение с целью поднять четкость, поэтому в нём очень много резких краёв и это даёт ложные срабатывания. Да и в целом картинка через чур контрастна., сейчас попробуем адаптироваться.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

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

Кстати, уровень отсечения теоретически должен быть больше 50%, чтобы не ловить углы.

А почему выделяется только нужная точка и чуть чуть шума, а не все точки этого контрастного маркера?


Какой смысл фильтра без отсечения уровня?


Это регулируется масштабом и сдвигом фильтра.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Dead, то что получилось - это хорошо, но хорошо бы еще понять, почему оно так получилось, чтобы управлять процессом... (условия ведь будут меняться - например проем окна может быть запросто гораздо контрастнее листа бумаги).

Конечно, нужный паттерн выделяется фильтром, кто бы спорил, но я вижу, что неплохо выделяются также и просто контрастные углы, а этого хочется избежать, не так ли?

Фильтр так или иначе будет симметричным (поскольку маркер симметричный).
Если ему показать не два угла а только один (например зачернить один из белых углов в паттерне),
то, очевидно, в идеальных условиях фильтр как раз и покажет ровно 50% от возможного максимума.
Вот что я имел в виду.

Добавлено спустя 26 минут 26 секунд:
Вы же сами видите, что даже на первых двух картинках выделились точки,
в которых, казалось бы, похожего паттерна нет... Да и потыркамшись "пипеткой"
несложно найти точки, которые лишь чуть-чуть меньше 50% от белого...

Понятно, что если вы введете еще и инвариантность к повороту, то вылезут максимумы и в других местах (например, черные точки тоже станут белыми) и вероятность словить ложный маркер поднимется.

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

Добавлено спустя 7 минут 40 секунд:

Например рассортировать подозрительные регионы по вероятности нахождения маркера...
Да мало ли...

Конечно с фильтром еще буду играться, заведу это всё добро в ORFA-терминал и там буду мучать, пока это была всего лишь предварительная проверка гипотезы в фотошопе

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Сквозь дымку облаков выглянуло солнышко... что-то так...

Вот итоги обработки этого изображения по указанному мной выше алгоритму, как видно подозрительных на маяк точек совсем немного, их можно быстро проверить:

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Я к тому, что контраст не всегда может быть в пользу маяка...
там кусок лайнтрейсерской трассы приложен к стене для сравнения - лазерником на бумаге...

А, с этим согласен, я пока думаю бороться с этим вводя функцию локального автоконтраста.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Вот, накидал локальный автоконтраст:


Добавлено спустя 6 минут 28 секунд:
А вот на изображении с яркими бликами:

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

Ага...
На первый взгляд должно помочь.

А интересно, если теперь обрезать по 50% до битового изображения,
пропадет ли размытость (нерезкость) маяка.

Еще можно центральную симметрию проверять в подозрительных точках
(корреляцией по зеркальным половинкам... или даже инверсным четвертинкам)
- это вроде бы не должно зависеть от поворота и перспективы

Добавлено спустя 6 минут 6 секунд:
нет, пожалуй, до битового не надо - грязи много вылезет.

Зачем убивать информацию (перевод в ч\б по сечению 50% яркости) на таком раннем этапе? Нам нужно убивать информацию переходя в биты только в самом конце, когда примемся выбирать точки в которых надо что-то проверить, до этого работаем фильтрами по всему полю.

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов

согласен

Я вот думаю как дальше само распознавание сделать.

Там такие подзадачи по идее есть:

1. Определение размера маяка (планирую по вертикали и по горизонтали от центра потенциального маяка пустить в стороны проверку, пока не уткнёмся в чисто светлую или чисто тёмную область. По всем четырем сторонам расстояние от центра до этих найденных точек должно быть примерно одинаковым - тогда их среднее арифметическое это и будет найденный размер маяка. В дальнейшем для точного определения размера маяка (а значит и расстояния до него) можно будет субпиксельные методы применить.

2. Чтение кода маяка - тут всё более менее просто, но надо будет наверное какие-то методы контроля целостности данных использовать. Я вижу пока три варианта, первые два - CRC с 1 и 2 битами контроля целостности данных, а последний - какой-нибудь код с исправлением 1 ошибки и детекцией 2 ошибок. Кто в теме - посоветуйте лучше всего конечно готовую библиотеку с набором кодов или просто с таблицей декодирования, чтобы не изучать эту тему еще сейчас

_________________
Проект [[Open Robotics]] - Универсальные модули для построения роботов