roboforum.ru

[EDV]

=DeaD=": Я себе вижу интерфейс таким образом:

1. Создание распознавалки как класса с созданием внутри всех необходимых структур данных;

Код: Выделить всё • Развернуть

#include "AssociativeMemory.h"

CvAssociativeMemory32S* pAM = new CvAssociativeMemory32S;
                         ...
                        if(mpAM) { delete mpAM; }

2. Сохранение всей внутренней структуры в файл, загрузка из файла.

Заголовочный файл: "AssociativeMemory.h"

Код: Выделить всё • Развернуть

// Saving of recognition data
bool Save(char* aFileName, bool aSaveWithoutOptimization = false);
// Loading of recognition data
bool Load(char* aFileName);

3. Добавление образа для распознавания.

Код: Выделить всё • Развернуть

// Set an image for processing
void SetImage(const void* apSrcImg, const void* apObjMaskImg = NULL);
// Writing to associative memory cell
void Write(CvRect aInterestArea, long* apData, bool aDeepLearning = true);

4. Распознавание всех образов, которые знаем, на заданном изображении.

Код: Выделить всё • Развернуть

// Set an image for processing
void SetImage(const void* apSrcImg, const void* apObjMaskImg = NULL);
// Object recognition
void ObjectRecognition(CvRcgAMFunc32S RcgAMFunc, void *args = NULL);
void ObjectTracking(CvRcgAMFunc32S RcgAMFunc, void *args = NULL,
           bool   aTrainingDuringTracking = true,
           double aSimilarityUpTrd = cAM_SimilarityUpTrd,
           double aSimilarityDnTrd = cAM_SimilarityDnTrd);

5. Распознавание 1 вида образов, который знаем, на заданном изображении.

Код: Выделить всё • Развернуть

// Definition of associative memory operation function
typedef bool (*TYPE_AMFunc32S)(CvSize  aRcgMxSize, short* apRcgMx, long* apData,
                      uint64 aIndex, uint64 aHitCounter,
            int aContainBasesTotal, short aLevel, void* args);

Можно просмотреть все распознанные объекты в функции call-back (RcgAMFunc) и выбрать только те объекты, у которых необходимый нам индекс объекта (long* apData).

6. Удаление образа из распознаваемых.

Такого пока что нету. У каждого ассоциативного ядра есть свой уникальный индекс (uint64 aIndex), так что несложно будет сделать удаление ядра с заданным индексом.

Итог: необходимо добавить один метод DeleteAssociativeBase(uint64 aIndex) в класс CvAssociativeMemory32S.

[=DeaD=]

Немного не так себе представляю.

Заводим интерфейс iPatternRecognition, у него конструктор без параметров, деструктор так же без параметров, сохранение в файл, загрузка из файла (с параметром имя файла - char* fileName).

Методы:

1. Добавление образа для распознавания: iError addPattern(long int patternId, IplImage* pattern, IplImage* mask); - используется фрагмент обозначенный ROI;

2. Распознавание всех образов на изображении: iPatternFound* findPatternsOnImage(IplImage* image);

3. Распознавание 1 образа на изображении: iPatternFound* findPatternOnImage(IplImage* image, long int patternId);

4. Удаление образа для распознавания: iError delPattern(long int patternId);

iPatternFound:

• long int patternId;
• int x_offset, y_offset; - левый нижний угол образа на изображении;
• int vect1_x, vect1_y; - первый опорный вектор образа (если не обрабатываем повороты, тогда это vect1_x>0, vect1_y=0);
• int vect2_x, vect2_y; - второй опорный вектор образа (если не обрабатываем повороты, тогда это vect2_x=0, vect2_y>0);
• iPatternFound* next;

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

Я ничего критически важного для ассоциативной памяти не убил?

[EDV]

"=DeaD=":
> Заводим интерфейс iPatternRecognition, у него конструктор без параметров, деструктор, сохранение в файл,
> загрузка из файла (без всяких параметров все эти методы).

А сохранение в файл и загрузка из файла тоже без параметров? А как же имя файла?

"=DeaD=":
> Методы:

> 1. Добавление образа для распознавания: iError addPattern(long int patternId, IplImage* pattern,
> IplImage* mask); - используется фрагмент обозначенный ROI;

У меня в AVM используется функция интегрирования изображения (cvIntegral), которая рассчитывается для текущего кадра один раз (вызов метода CvAssociativeMemory32S::SetImage), а потом можно обучать AVM на несколько фрагментов изображения, используя метод CvAssociativeMemory32S:: Write.

Если будет несколько вызовов подряд функции addPattern для одного и того же изображения с разными ROI, тогда как быть? Вычислять cvIntegral по каждому вызову? Но это потеря быстродействия.

[=DeaD=]

А сохранение в файл и загрузка из файла тоже без параметров? А как же имя файла?

Гоню save/load(char* fileName), поправил выше.

Если будет несколько вызовов подряд функции addPattern для одного и того же изображения с разными ROI, тогда как быть? Вычислять cvIntegral по каждому вызову? Но это потеря быстродействия.

Насколько часто мы извне будем вызывать обучение новому образу? Понятно, что, если мы делаем универсальный интерфейс - мы можем потерять в быстродействии, это необходимое зло. К тому же сколько времени этот интеграл считается? Копейки ведь? Если я не ошибаюсь, по вычислительной сложности он никак не больше O(W*H)?

Добавлено спустя 2 минуты 5 секунд:
2EDV: Кстати, а внутри твоих структур исходные образы, которым обучали, - хранятся или нет?

[EDV]

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

Если вся проблема в интерфейсе, то не проще ли его поменять и учесть эту особенность ещё на этапе разработки?

> К тому же сколько времени этот интеграл считается? Копейки ведь? Если я не ошибаюсь,
> по вычислительной сложности он никак не больше O(W*H)?

В циклах эти копейки складываются в рубли, а быстродействие это такой ресурс, которого всегда не хватает. Так зачем его тогда разбазаривать так по-глупому?

> Кстати, а внутри твоих структур исходные образы, которым обучали, - хранятся или нет?

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

Но зато есть указатель на коэффициенты матрицы распознавания:

Код: Выделить всё • Развернуть

// Definition of associative memory operation function
typedef bool (*TYPE_AMFunc32S)(CvSize  aRcgMxSize, short* apRcgMx, long* apData,
                     uint64 aIndex, uint64 aHitCounter,
                int aContainBasesTotal, short aLevel, void* args);

CvSize aRcgMxSize – размер матрицы распознавания;
short* apRcgMx – указатель на коэффициенты матрицы распознавания.

[Vorral]

2EDV: с какой целью вы взялись за навигацию? распространить свой алгоритм распознавания? Не думали ли вы, что популязация вашего алгоритма должна пойти другим путём? Самостоятельным .Это когда алгоритм настолько хорош и НУЖЕН людям, что они готовы его даже купить, если сейчас этого не происходит, это повод задуматься

[=DeaD=]

Если вся проблема в интерфейсе, то не проще ли его поменять и учесть эту особенность ещё на этапе разработки?

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

В циклах эти копейки складываются в рубли, а быстродействие это такой ресурс, которого всегда не хватает. Так зачем его тогда разбазаривать так по-глупому?

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

По остальному вроде ясно.

[EDV]

2EDV: с какой целью вы взялись за навигацию? распространить свой алгоритм распознавания? Не думали ли вы, что популязация вашего алгоритма должна пойти другим путём? Самостоятельным .Это когда алгоритм настолько хорош и НУЖЕН людям, что они готовы его даже купить, если сейчас этого не происходит, это повод задуматься

Уже давно произошло, исходные тексты программы AVM приобрела одна европейская компания (сделка была заключена в преддверии нового года 2006-2007).

Фирма специализируется на алгоритмах идентификации личности с помощью биометрических данных (face identification, fingerprint identification), а так же на алгоритмах распознавания образов общего назначения (General object recognition for robotics and computer vision).

Моя основанья работа никак не связана с темой «Распознавания образов» и компьютерное зрение – это моё хобби. Мне интересен сам процесс исследований, а самое главное, что мне интересен конечный результат. Мне хотелось бы создать, то, что действительно можно было бы назвать "машинным зрением" (что бы машина действительно была способна видеть), и самое главное, хотелось бы успеть сделать это в течении моей жизни. Я убеждён, что ключевым в задаче "зрения" является память. "Зрячая" машина должна быть способна эффективно распознавать миллионы (а то и больше) образов в реальном масштабе времени.

[=DeaD=]

Уже давно произошло, исходные тексты программы AVM приобрела одна европейская компания (сделка была заключена в преддверии нового года 2006-2007).

А что ж ты молчал, искренние поздравления!

[EDV]

2 =DeaD=: Хорошо, будем считать, что про первый вариант интерфейса договорились. Я попробую реализовать его в ближайшее время.

[=DeaD=]

Ок, тогда идём дальше, это мы разобрали интерфейс для распознавалки образов, нам еще надо будет:
1. Функцию детектор наиболее удобных для следующего распознавания образов;
2. Интерфейс для optical-flow реконструктора;

По последней у меня есть наработки вот такие: [[Структура данных для локально измеренных расстояний до препятствий]]

Ну и видимо в процедуру надо будет передавать [[Структуры данных для описания (стерео)камеры]], хотя на самом деле процедура наверное должна будет вернуть векторное поле смещений (как в стерео-3Д-реконструкции), а уже другая более универсальная процедура превратить это поле смещений из параметров сдвига камеры и времени между снимками и параметров камеры в результат измерений в локальных координатах.

Добавлено спустя 1 минуту 18 секунд:
Для функции детектора видимо надо будет передавать ей картинку с установленным ROI (мы же проехать хотим, поэтому будем брать ROI такой, который планируем что попадет в следующий кадр).

Функция должна будет вернуть набор прямоугольников, которые по её мнению являются лучшими кандидатами на такие образы.

Добавлено спустя 1 минуту 22 секунды:
2Vorral: А может всё-таки оффтоп по тому надо или нет EDV'у заниматься распознаванием именно так - в другой ветке?

[=DeaD=]

Не было "наиболее удобные", было берём "тупо" в центре пару квадратов. А это как раз не разумно.

Не надо путать Optical-Flow и привязку к естественным маякам, читаем внимательней.

[Vorral]

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

[=DeaD=]

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

1. Карту в смысле маяков и глобальных координат робота строим путём привязки к образам (которые выбираем путём детектора уже указанного выше) и вычисления расстояний до них через линейное изменение размеров при перемещении робота. При этом можно держать карту не в виде глобальных координат, а в виде некой системы уравнений, как в WORLD OF GOO . Пока не прорабатывал эту тему.

2. Препятствия обнаруживаем с помощью Optical-Flow построенного на распознавалке.

[=DeaD=]

По поводу построения карты привязок на базе обнаруженных визуальных маяков отдельно создал тему: viewtopic.php?f=35&t=6029

Добавлено спустя 2 часа 52 минуты 48 секунд:
Итак тут набросаем эскиз:
1. Детектор хороших естественных маяков на исходном изображении;

Вопрос скорее всего к EDV'у - какие образы лучше всего будут распознаваться? Есть мысль брать небольшие (скажем 5-10% от кадра по каждому измерению) контрастные фрагменты, не повторяющиеся в этом кадре.

2. Проверялка на то что маяк не рассыпался при перемещении и запоминалка его в банке памяти маяков.

Это просто берём с предыдущего 1-2 положений то что пытались принять маяками и проверяем в текущем положении - если они живы, тогда фиксируем их как маяки и по смещению определяем расстояния до них и направление на них по положению в кадре.

3. Распознавалка имеющихся в банке памяти маяков на изображении полученном с камеры.

Это та самая распознавалка образов, которая уже есть.

4. Optical-Flow для избегания препятствий строим распознаванием фрагментов предыдущего кадра на этом кадре.