roboforum.ru

=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, у него конструктор без параметров, деструктор, сохранение в файл,
> загрузка из файла (без всяких параметров все эти методы).

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

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

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

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

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

"=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 – указатель на коэффициенты матрицы распознавания.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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