Работа по анализу фотографий.

[RXL]

Честно говоря, я не понимаю - при чем тут DX? Речь же идет о захвате и дальнейшей обработки массива пикселов. Понимаю, что в DX, возможно, есть такая фича, но, как описано в задании, нужно будет работать совсем на другой ОС.

Пробовал, на днях, найти в инете хотя бы упоминание о том, через какое API можно работать с DV - кроме как по Linux-у ни чего не нашел. Можно подумать, что это большой секрет. Искал так: "(ieee1394|dv) (api|sdk|program)".

По самому алгоритму:
о попиксельном сравнении речь, imho, вообще идти не может;
свертка тут не поможет - при удалении объекта, его частотный спектр сместится;
можно использовать алгоритм для обнаружения границ (3x3 edge modification) - в частности edge detection -, а далее... ну как-то разложить на геометрические фигуры или линии, с которыми управляться проще.
Возможно есть лучший метод.

[Гром]

Lex, на входе стоит видеокамера, а сохранять поток не надо - надо на лету выхватывать.

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

А дальше анализ фотки - выделение номера - в виде прямоугольника, и потом определение расстояния...

[grozny]

groznyВопрос - будет ли там идти распознавание образов - так как съемка идет тыла машины, с разных точек, машина может подпрыгивать менять угол - немного - объезжать впереди идущую - т.е. фотки надо приводить не к сравнению расстояния до объекта произвольно , а до объекта номера именно на фотографии. Поиск его сначала.

Я не нашел где в DX это вообще сравнивают.

Если чуть откатить назад и для чайника пояснить - как DX работает с изображением захваченным с видео и как можно с его помощью сравнивать два имеющихся???

увы-увы, ДХ (как и ОпенЖЛ) - низкоуровневый АПИ для 3Д и довесок в виде ДиректШоу - низкоуровневый АПИ для ввода-вывода видеопотоков. Ориентирован ДХ на игрушки и мультимедиа. ОпенЖЛ ориентирован более на приложения, упор делается на точность отображения. В реальности разница практически отсутствует. Например, недавно с удивлением обнаружил, что простые 3Д тесты рендерятся с той же скоростью и практически пиксел-в-пиксел что на ДХ9, что на ОпенЖЛ. Так что выбор АПИ всё больше вопрос привычки и платформы.

Любые высокоуровневые операции  типа распознавания образов надо ваять самому. Что в ДХ, что в ОпенЖЛ. Это не их уровень абстракции.

В общем, твоём деле ДХ полезен только для больших видеопотоков или синтеза изображений из 3Д моделей, когда упираешься в железяку и хочется выжать как можно больше.

Для чтения поверхностей в ДХ делается Lock() - он тебе вернёт адрес куска памяти, с геометрией, описанной в объекте (D3DTexture или D3DSurface). Текстуры могут быть многоуровневыми (мип-мэппинг), тебе это не надо (если видео в текстуру заливать), а потому выключай автомипмаппинг и создание пирамиды текстур где только можно.

В обсчем, кроме как захвата, ДХ вряд ли тебе будет особо полезен.

Кстати, для анализа я полагаю тебе достаточно определить _углы номера_ (имеются в виду вершины, не угол между направлениями). Где-то попадался фильтр, который в изображении умеет выделять изломы (углы т.е.). На вход подаёшь ч/б картинку, на выходе - точки там, где углы объектов. Ну и самому можно простой определитель написать - идти некоторым окном и смотреть, если в окно попадает излом (верхний левый угол):
 - прошли немного строк от края до края без флуктуаций
 - попалась строка(и) с большим и длинным скачком (верхний край номера)
 - далее идут строки с одним коротким скачком (вертикальный край)

для нижнего левого - та же фигня в обратном порядке.  И т.п.

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

[Гром]

Пока для этого пытаюсь использовать Вейвлет.

Для полного счастья не хватает двух ответов.

1. Где взять матлаб - для винды 2000 дабы просмотреть алгоритмы и перевести их на С++.

2. Как запретить в винде захват видео, с обязательным выводом видео на экран - иначе так тормозит - что ужас...

Если надо - могу выслать код, в котором идет захват.

[grozny]

1. в осле. P2P такой. лучший клиент - eMule (http://emule-project.net/). Если долго или проблемы с поиском матлаба через ослика - могу кинуть. Матлаб13 - 3 кду-хи (неполных). Около 1 Гб.

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

[Гром]

grozny, ок...

[Гром]

выслал на почту проектик и данные куда залить матлаб.

Огромное спасибо...
Почту брал с этого форума с твоего профиля...

[grozny]

ок, забрал, разбираюсь

[grozny]

не могу зайти на фтп - фар говорит, что ошибка сокета, эксплорер - не может прочитать фолдер, а SecureFX:

Control connection could not be established (10060).

[grozny]

(тут раньше были сырые мысли)

Короче, уменьши задержку в GraphThreadFunc(). С 2000 до 2-х или 1. Эта ф-ция раз в кадр вызывается, там задержка более 10мс просто убивает весь процесс... У меня всё полетело. Всё ещё есть вторичные задержки (то быстро, то немного медленнее), но радикально быстрее.

[Гром]

grozny, немного не понял?
По алгоритму на данный момеент я цепляю кадр 1 раз в 2 секунды - отсюда и задержка треда на 2000 мс.
А захват идет в самом грабере.
Задержку ставлю именно дабы поспать процессу 2 секунды не нагружая проц.

ФТП открыл - но забыл оставить комп включенным - уже исправился.

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

Пока же в тестовом варианте 1 раз в 1-2 секунды мне вполне хватит для демки...

[Гром]

И еще - в указанной сслыке по Вевлету есть код матлаба для разных матриц A & B.

Ссылка: http://www.ma.utexas.edu/undergrad/gregng/wavelets/algorithm.html
В них указано, что происходит привеление матриц к 0 и вычисление корелляций, по след. алгоритму:

A0 = A - mean(mean(A));  % Adjust A to have average zero
B0 = B - mean(mean(B));  % Adjust B to have average zero
c = sum(sum(A0 .* B0));

Который работает только ДЛЯ ОДНОРАЗМЕРНЫХ МАТРИЦ.
кто-нибудь что нибудь понимает, если учесть что матрицы - это и есть сравниваемые картинки.

[grozny]

grozny, немного не понял?
По алгоритму на данный момеент я цепляю кадр 1 раз в 2 секунды - отсюда и задержка треда на 2000 мс.
А захват идет в самом грабере.
Задержку ставлю именно дабы поспать процессу 2 секунды не нагружая проц.

ага, мысль-то я понял, что захват видеопотока - отдельно, а сэмплинг-отдельно. Чего пока не понял - чё именно тормозит  :?: . Я думал - сэмплинг. Но в сэмплинге твоя спецом поставленная задержка и всё, нету особых тормозов. В захвате есть пара мест, но судя по тому, что у меня хватает кадры на частоте кадров - те места не критичны. Ещё мне *показалось* вчера, что трэд захвата блокируется, пока ты не заберёшь буфер. Видимо, это не так, ага? (давно мульти-трэд не отлаживал)

Не смотрел, как часто и с каким интервалом  вызывается CSampleGrabberCB::BufferCB()

У тебя такой эффект (сэмплинг на частоте кадров при уменьшении задержки до 10 мс) наблюдается или нет?

Сэмплингом я обзываю любые нетривиальные действия с буфером кадра в GraphThreadFunc(). Ты же там будешь обработку делать?

насчёт одномерного массива в МАТЛАБе - я полагаю, автор алгоритма рассчитывает иметь пикселы в пошлом одномерном массиве а-ля С, pixels[height*width], а не  pixels[height][width]. В МАТЛАБе есть многомерные массивы произвольной размерности.

Продолжу вечером, я счас на работе

[Гром]

grozny,

трэд захвата блокируется, пока ты не заберёшь буфер

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

Не смотрел, как часто и с каким интервалом вызывается CSampleGrabberCB::BufferCB()

Оно вызывается я так понял покадрово, иначе никак.
Но тут прикол видимо в том, что это грабер сам так работает через колбэк не хоршо.
Я люблю сам влиять на потоке а ДХ не дает.

У тебя такой эффект (сэмплинг на частоте кадров при уменьшении задержки до 10 мс) наблюдается или нет?

Да в том то и дело - хотя процессор не грузится на полную.
В СДК написано , что так вроде должно быть - я гляну завтра - напишу как там написано.

насчёт одномерного массива в МАТЛАБе - я полагаю, автор алгоритма рассчитывает иметь пикселы в пошлом одномерном массиве а-ля С, pixels[height*width], а не pixels[height][width]. В МАТЛАБе есть многомерные массивы произвольной размерности.

Нте там по другому, я уже разобрался. они дополняют нулями и потом делают

Продолжу вечером, я счас на работе

Да конечно.
Ты только потом поставь залить матлаб - надо кое что отладить.
Главное - это Wavelet Toolbox
Он содержит те вейвлеты, которые мне надо.
Если есть окнчено.

[grozny]

матлаб льётся, 120Мб ушло. Примерно 11 часов осталось.

Wavelet Toolbox - имеется

[grozny]

вот елы-палы, пришла пора на рождественские каникулы отъезжать . Извини, не сумел на код глянуть ещё разок  :oops: . Приеду под НГ. Ты пиши, как чего откроешь, интересно.

[Гром]

grozny, ок - напишу.
Желаю тебе хорошего отдыха.

[grozny]

Спасибо, Гром  8)

Матлаб залил, напиши, если не работает.

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

Завтра попробую с совсем другой стороны видеозахват пощупать - через текстуру. Для сравнения.

[Jack]

Кто-нибудь может подсказать как  организовать drag&drop в VC++. Перетаскивание элементов из списка ToolBar во View? Также как это сделано в MicroCap или других программах по построению принципиальных схем.

[Гром]

grozny, классно - рад что ты так "разнообразно" отдохнул   ъ
Матлаб бегает.
Я не понял зачем там третий диск, но первые два прекрасно встали и заработало.

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

Думаю что матлаб как интерпретатор проигрывает нормальному коду на С++ - но очень нервничаю - вдруг не будет успевать.

[Anonymous]

Это я Гром, забыл войти
Привет еще раз.

И снова проблемы.
1. Транслирование кода стандартных функций матлаба на С++.
Где бы достать такую библиотеку из вейвлет тулбокса, которая работает с матрицами - но уже на С++.

2. Если первого нет - то мне нужен простейший - самый простой алгоритм нахожнеия прямоугольника в фотографии - причем одноцветного, который бы можно было написать или адаптировать в течении нескольких дней - иначе просто невозможно ничего сдать - вейвлет получается достаточно объемным по коду, и для бесплатного примера не катит.

Заранее благодарен всем - ребятушки - напрягитесь - очень надоть.!!!!

[RXL]

Есть какая-то библиотека wlvt - исходники на С для unix и dos (к вин, я думаю, адаптировать можно). Это подойдет?
http://www.wavelet.org/phpBB2/viewtopic.php?t=3004
http://www.cs.ubc.ca/nest/imager/contributions/bobl/wvlt/top.html

[Гром]

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

[grozny]

конечно, матлаб намного тормознее С++. Это интерпретатор. Можно скомпилировать матлабную программу в ЕХЕ (компилятор в тулах зарыт). Будет быстрее.

Можно переписать на С++, используя МХ и МЕХ библиотеки. Будет ещё быстрее.

Конечно, грамотно написанная спец. библитотека для вэйвлетов (без всяких заморочек для совместимости с интерпретируемым матлабом, как в МХ и МЕХ) будет самым быстрым вариантом.

По поводу алгоритма: а почему бы не попробовать свёртку прямоугольника (например, заданного ф-цией) с картинкой, переведённой в ч/б?

[Гром]

RXL, просмотрел скачал - никаких нужных фунций пока не нашел...
Жаль.

grozny, дело не в компиляторе - хотя если б он компилировал либу в стандартный формат - было бы здорово - можно получить экспорт существующих в матлабе функций в виде библиотеки для VC :?:

По поводу алгоритма: а почему бы не попробовать свёртку прямоугольника (например, заданного ф-цией) с картинкой, переведённой в ч/б?

Что сие ... :?:

[grozny]

дело не в компиляторе - хотя если б он компилировал либу в стандартный формат - было бы здорово - можно получить экспорт существующих в матлабе функций в виде библиотеки для VC :?:

дык! конешно можно. Загляни в директорию extern/examples/cppmath - там есть  примерчики...

Вообще в этой директории (extern) лежит всё необходимое для связи МАТЛАБа с внешним миром программным способом. Включая документацию

По поводу алгоритма: а почему бы не попробовать свёртку прямоугольника (например, заданного ф-цией) с картинкой, переведённой в ч/б?

1. Берём ф-цию 1 (f): тестовая картинка, в которой где-то зарыт прямоугольник - ф-ция задана как набор скаляров на регулярной сетке (битмап) - (исходно цветная, мы её неким фильтром приводим в ч/б вид, 1 бит на пиксел или в 8-бит оттенков серого)

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

3. вычисляем результат свёртки 2-х ф-ций: f*g

Теория нам обещает, что если ф-ция g коррелирует с f (в переводе на условие задачи - есть квадратик близкого размера в исходной картинке),  то свёртка будет ненулевая (т.е. будут белые пикселы). Конешно, будет шум, а потому надо не просто до первого белого пиксела проверять свёртку, а пройтись неким шумодавом, например тупым усреднением в квадрате.

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

[Гром]

Плохо дело.
При компиляции Вейвлетов функции witch, matlabpath и некоторые другие - говорят что доступны только в MEX моде. То ли я чего то не понимаю то ли ....

[grozny]

их много, этих ф-ций? Затычками заткнуть. Большинство из них наверняка типа служебных и мостиков к ОС, не связанных напрямую с вычислениями.

МЕХ - это плагин в МАТЛАБ, не та мода, которая нужна.

[Гром]

grozny, да нет тут хуже.
Смотри - есть функция dwt2 - двумерная свертка. В ней вызывается функция which и хрен его знает кому и как она нужна.
Я сделал так уже как ты говоришь - ремарк этой строке - обратил внимание что я тот мод не использую в котором она по case выполняется.

Кстати - я так и не понял каким образом может быть run-time error если я в эту выборку вообще не вхожу  

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

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

Вот такие вот дела. НО УДАЧА - ОНА БУДЕТ С НАМИ! Она ведь всегда с нами!  :!:  8)

[grozny]

- я полагаю, матлабовская либа тоже использует which внутри себя.

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

 - всё получится. Успехов!  :!: