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

[Гром]

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

Мне нужны:
1. Алгоритмы для обработки графических данных.
2. Любые документы по работе с графикой (математика, алгоритмирование, теория, практика, примеры, ваш опыт)...
3. Возможно готовые программы с сорсами, которые могут анализировать все это...
4. Документация к SDK которая это делает... Видимо DirectX.

Огромная просьба всем - накидать инфы побольше...

Заранее спасибо.

[MOPO3]

Хмм, к сожалению всё чем могу помочь - это класс написаный на ПХП.

Умеет :
- создавать картинки с бэкграундом
- писать текст на картинках
- ресайзить картинки (GIF, JPG, PNG)
- аплоадить всё енто чудо на сервер

Для работы необходима библиотека GD версии 2.0 как минимум

[Гром]

Увы - не php это ....
Мне надо в реал тайм все это делать - таким образом, С - С++ и технологии.

[MOPO3]

       

[Lex]

Гром, зайди на http://www.nvidia.com в раздел разработчиков.
Там есть такая штука как NvToolKit кучас вясих утилиток и библиотек с исходниками. В том числе и библиотека по загрузке картинок из GIF, JPG, TGA, TIFF,  PNG. Это что могу сказать сходу. Лучший хелп по DX это DXSDK как ни странно это звучит.

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

[Гром]

А нвидиа работает с другими картинками.
Тут ведь суть не в выводе их на экран а в анализе, т.е. перевод к нужному формату и анализу, резкльтатом которого будет управление, а не рисование на экран.

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

[Lex]

Гром, я так и не понял, что за анализ тебе нужен?
Напиши подробнее.

[Гром]

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

Съемка происходит полотна трассы с разметкой - надо анализировать наезд на линию...

Вот примерно такой прикол.

[Lex]

Гм, это тебе надо распознавание образов. Слегка другая направленность.
Хорошо, попробую посмотреть, чего у меня дома есть на эту тему.

[Гром]

Lex, спасибо, там не только это.
Распознание образов - это после капчуринга - ведь надо организвоать прием формата DV потом захват картинки + в нужный формат, и только после этого работать по распознаванию образов - желательно   вот стока действий сразу...

[grozny]

занимался (распознавание) и занимаюсь  (ДХ, ОпенЖЛ и пр.)

Как-то приходилось искать зрачок на ч/б видеосъёмке глаза и ставить крестик в центре зрачка.

МАТЛАБ хорош для разработки и тестирования алгоритмов распознавания - там есть специальный Image Processing toolkit.

Ещё у Интела есть хоть и бардачная, но полезная Image Processing Library.

Из методов распознавания контуров - я пользовал Собеля с небольшой модификацией. Собирался сделать SUSAN, но задача иссякла и без того. Линки не под рукой, но если интересно - могу кинуть. Есть код основных фильтров, прилагался к книжке Image Processing. Немного устарело - 1998 года издания.

[Антон (LogRus)]

grozny, мне интересно. Еще нейроные сети интересно в свете текущей темы. А также интересно распознавание образов нейронными сетями и вообще.

[grozny]

вот нейронными сетями не занимался - статейки только читал.

Простые фильтры теории распознавания - тупой перебор по пикселам с неким арифметическим действием. Ну я вечером (счас типа работаю   ) просмотрю свои ссылки и выложу, чё найду. Где-то и код завалялся, как минимум на МАТЛАБе

[Гром]

grozny, Все вышесказанное нужно с поддержкой VxWorks

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

[grozny]

VxWorks - не знаком, увы. Всё делал под виндами. Я так понимаю, что разрабатывать алгоритм всё равно под чем, т.е. начать эксперименты луче на МАТЛАБе под виндами, над контрольными кадрами. А потом задвинуть под VxWorks.

Если правильно помню, под VxWorks есть OpenGL, в т.ч. в драйверах, ускоренных на железках нВидии. Не в курсе, мож и ДХ есть, но я как-то сомневаюсь.

Чем больше деталей, тем луче

[Гром]

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

[grozny]

Basic Image Processing Demos http://robotics.eecs.berkeley.edu/~mayi/imgproc/index.html

SUSAN Low Level Image Processing

SUSAN is an acronym for Smallest Univalue Segment Assimilating Nucleus. The SUSAN algorithms cover image noise filtering, edge finding and corner finding

http://www.fmrib.ox.ac.uk/~steve/susan/index.html

Computer Vision Depository
http://www-2.cs.cmu.edu/afs/cs/project/cil/ftp/html/v-source.html

[grozny]

Распознавание образов (в частном случае геометрических фигур)
http://www.cs.sunysb.edu/~algorith/files/shape-similarity.shtml

Используют нейронную сеть
http://www-ra.informatik.uni-tuebingen.de/SNNS/

Или либу на С:
http://www.cs.sunysb.edu/~algorith/implement/turn/implement.shtml

[Антон (LogRus)]

grozny, Спасибо. Я уже домой. В следущий раз почитаю. Что почем, хокей с мячом.

[grozny]

очень краткий курс по обработке изображений на основе МАТЛАБ:

http://www.matlab.su/imageprocess/book2/index.asp

и список русскоязычной литературы
http://www.matlab.su/imageprocess/liter/liter.asp

ну а всё остальное гуглится по конкретному алгоритму (Minkowski sum, binary convolution, Canny, Haussian edge detector etc.)

[RXL]

Кстати, в зависимости от предпологаемой максимальной/минимальной скорости перемещения объекта по кадру, можно выкинуть часть кадров - дело пойдет быстрее.
Работа с DV: не знаю что будет выдавать API работы с ним, но физически по нему приходит поток jpeg картинок (mjpeg). По крайней мере, если подключена обычная цифровая видеокамера (по этому интерфейсу можно гонять что угодно - firewire). А тут тоже возможна оптимизация - распаковывать jpeg до YUV и использовать только яркостную составляющую,  если, конечно, не нужен цвет. Разрешение по Y в два раза больше чем по цветовым компонентам.

[Гром]

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

[grozny]

 А тут тоже возможна оптимизация - распаковывать jpeg до YUV и использовать только яркостную составляющую,  если, конечно, не нужен цвет. Разрешение по Y в два раза больше чем по цветовым компонентам.

Именно-именно. я бы даже сказал, что в YUV - предпочтительнее искать. Главная причина существования и применения YUV - в том, что глаз намного более чувствителен к градиенту яркости, а не к градиенту цветов. За счёт чего и можно загрубить цветоразностные каналы (U и V).

Так что в первом приближении можно U и V просто выкинуть, анализировать только Y

[Гром]

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

Что вы об этом думаете?

[Lex]

Гром, Обращайся, если что.

[Гром]

Lex, спасибо, буду иметь ввиду.

[RXL]

Наткнулся на интересный проект:

Motion is a software motion detector. It grabs images from video4linux devices and/or from webcams (such as the axis network cameras). Motion is the perfect tool for keeping an eye on your property keeping only those images that are interesting. Motion is strictly command line driven and can run as a daemon with a rather small footprint.

http://motion.sourceforge.net/
http://sourceforge.net/projects/motion/
По крайней мере если не применить (GPL), то хоть посмотреть как они делают можно.

[Гром]

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

Нужно все очень быстро.

[RXL]

Иначе говоря, нужно обнаружить объекты на двух кадрах и удостовериться в их идентичности?

Судя по ответам, у нас тут спецов по таким делам нет, к сожалению.
Ты смотрел ссылки что grozny накидал - нет ли чего там подходящего на первый взгляд?

[Гром]

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

Массив известных фоток выложен. Вот так то

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

[grozny]

а ты не пугайся МАТЛАБа: во-первых, это почти С по синтаксису, во-вторых в нём есть СДК, позволяющий исполнять программки на МАТЛАБе вне всякой среды и компилировать в обычные ехе.

Ну, да и без МАТЛАБа можно решить.

Делаешь Фурье и сравниваешь спектры, например. Высокие частоты режешь или с маленьким весом берёшь при сравнении, чтобы убрать шум и разницу в освещении.

посмотрю ссылки чуть позже.

[Гром]

grozny, я матлаба не боюсь...
Мне надо именно без него.
Делается алгоритм для DSP какой там матлаб...

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

Мне придется адаптировать это потом, под реальное время ...

Жду ссылки...

Вопрос Фурье  - поподробнее какой его алгоритм по спектру название полное желательно...

[grozny]

он-лайн книжка по ДСП и распознаванию образов:
http://www.dspguide.com/pdfbook.htm

особенно вот эта глава
http://www.innerlighttheory.com/ch24.pdf

-------
Wavelets Search Algorithm  
http://www.ma.utexas.edu/undergrad/gregng/wavelets/algorithm.html

CANDID: Comparison Algorithm for Navigating Digital Image Databases
http://www.c3.lanl.gov/~kelly/ml/pubs/1994_ssdbm/paper.pdf

``Show me all images of areas with landcover that is similar to this example.'' http://public.lanl.gov/kelly/CANDID/tm/index.shtml

[grozny]

а чё с BMP? ты в курсе, что там пикселы сразу за хедером лежат   ?

[AlexanderV]

Для начала - совершенно бесплатная Intel Image Processing Library - на сайте Intel. Есть бинарники, оптимизированные под всё, что можно, есть и сорц.
http://www.fftw.org/ - Быстрое преобразование Фурье. Почти по-любому пригодится.
И почитай по вэйвлетам - в рунете есть статьи. Я сейчас не помню где, если у себя найду - подкину. Но, лучше через Гугла на свой вкус. И одна ссылочка всё-же завалялась http://www.matlab.ru/wavelet/index.asp
Удачи

[Гром]

AlexanderV, спасибо. Обязательно почитаю все.
Гугл - я нашел кое-что но не всегда то, что надо.
grozny,

а чё с BMP? ты в курсе, что там пикселы сразу за хедером лежат

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

[RXL]

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

[Гром]

Ну что ж - пока всем спасибо.
Тестовое задение с вашей помощью выполнил - немного отдышусь и сделаю откзыв на эту работу, по причине этой и не появлялся собственно.
За 4 дня совершили переворот

[oapopov]

Рекомендую OpenCV Library - библиотека Intel по Computer Vision отпущена в OpenSource
http://sourceforge.net/projects/opencvlibrary/
OpenCV courses - презентация PowerPoint с демонстрацией возможностей библиотеки
http://umn.dl.sourceforge.net/sourceforge/opencvlibrary/CVPR01_course.zip

[Vatslav]

   8)  :twisted:
есть СДК по ДиректХ 9 - откачаный.
НО! - аглицкий.
НО!! - с примерами.

_______
Yours, Vatslav.
vpe@library.kr.ua
ICQ 135377385 - invisible

[Гром]

   8)  :twisted:
есть СДК по ДиректХ 9 - откачаный.
НО! - аглицкий.
НО!! - с примерами.

_______
Yours, Vatslav.
vpe@library.kr.ua
ICQ 135377385 - invisible

А для какой системы - Виндовс,его можно скачать с их сайта.

[Dimka]

Гром, у мя зав.кафедры в РОиОИ (Распознавание образов и обработка изображений) - человек известный, можно сказать с мировым именем. Предмет нам этот читался, есть всякие лекции, книжки, материалов куча, но я их все, разумеется, не читал. Чистая теория, математика, подходы и пр., программирования, а вот программирования мало. (Если математикой владеешь, то организовать данные и написать код уже не так сложно - логика такая). В общем, даже в архиве это порядка 150 Мб весит. На ящик кидать, думаю, жестоко. Как бы это тебе передать всё? Дома у меня канал выделенный, есть фтп, если по аське договоримся - можешь прям у меня взять. Или свой фтп скажи, куда положить можно было бы. Аська моя 159464963. Тока до 8 декабря решайся, а то мож в командировку в Питер уеду на месяц примерно.

[Гром]

Пошел в аську.

[Гром]

Эгей, привет.
Опять к вам и опять по поводу работы с этой самой графикой.
Другая стартовая задачка под Винду.
Надо определять рассточние до объекта по имеющимся стандартным фоткам.
Все сделать под вин и побыстрее.

Имеется фото скажем номера машны, на расстояния 10 1 и 5 и 20 метров, и надо по текущей фотографии, определить текущее расстояние.
Скачал DXSDK нихрена в ней не понял, нет там работы с изображениями в таком виде, как можно работать внутри винды с графикой типа jpeg & gif и делать анализы фотографий. Где брать библиотеки???

Кто знаком отзывайтесь, Грозный это тебе вопрос в основном то - как к опытному товарищу (господину   )

[Lex]

Гром, для jpeg и gif лучше взять NVidia toolkit. там есть либы для загрузки файлов с исходиками. Еще есть Intel JPEG library и Intel Image Processing library. первая может грузить jpg и бесплатная, вторая может осуществлять всякие манипуляции с картинками, на счет бесплатности не помню.

[Гром]

Lex, эти либы просто подключаются к проекту???
И грузить формат я так понял - переводить в bmp формат?

[Lex]

Гром, да они просто цепляются к проекту причем все либы только С\С++ стандартный используют. грузить jpg это считывать его из файла. Можно в DIB или BMP а можно просто картинку как массив точек без всяких заголовков.

[Гром]

Lex, понял - буду искать. Буду пробовать.

[Джон]

Имеется фото скажем номера машны, на расстояния 10 1 и 5 и 20 метров, и надо по текущей фотографии, определить текущее расстояние.

Ну вот так сразу кажется очень легко (или только кажется?).
Из первых узнаёшь линейные размеры объекта, можно в условных единицах, хотя лучше взять стандартные данные, думаю размеры номерных знаков нормированы, тогда и предыдущие фотки не нужны.
А потом делаешь пропорцию - если на расстоянии 1 - ширина знака <Стандарт>, то на каком расстоянии ширина знака <Измеренное значение>. По-моему так. Ну конечно если съёмка ведётся не "в лоб", то придётся учесть поправку на угол.

А ты часом не радарную систему изобретаешь, чтоб потом "превышателей" скорости отлавливать?  А то мы тут тебе насоветуем...

[Гром]

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

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

[Гром]

Блин - где примеры захвата изображений с видео потока в DXSDK

[Джон]

Гром,  эт я прикололся. Я так и понял. Года 4 назад мы делали один проект с Jaguar. К теме это не относилось речь шла о продаже машин, но в проспектах ихних стояла такая система. По-моему на ультразвуке. Мерила расстояние до впереди идущей машины в зависимости от скорости и давала сигнал. А вообще здесь очень много ведётся разработок в этом направлении. К сожалению, ничего конкретного (а поэтому и для тебя полезного). Общая инфа, видел много передачек, в реальном режиме происходит отслеживание перемещения объекта. Так что, чтоб тебя подбодрить - это реализуемо. Но народ тут такой, что никто тебе ничего не объяснит. Я было стал народу про харды рассказвать, что такое кластеры, и зачем надо большие на партишны разбивать, так они на меня как на дурака смотрели. Типа как эт так? знаниями делится? Если спросишь, то в большинстве случаев услышишь - не знаю. Зато если шеф спросит, откуда только у них знания берутся. Так и прёт. Уже столько раз такую картину наблюдал. В принципе понимаешь их, но всё-равно противно. Правда бывают исключения. Ну ладно эт уже поехал оффтопик.

Если тебя интересует общая инфа, то могу посмотреть, но ничего конкретного не обещаю. Чё нить на уровне "Очевидного-невероятного"

[Джон]

Слушай ну VirtualDub же open source. Посмотри у них. Или эт не то?

[Гром]

Джон, я объясню.

Проблема очень нетривиальна, т.е. прикол что тестовую мне надо сдать за две недели, максимум три, а вот потом долгий проект.

Но тест идет на винде, а вся система пойдет на VxWorks и все системы типа Дуба и вин ДиректХ не покатят.
Придется капчуринг делать руками с их утилитами.

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

[Mouse]

Гром, не нашел еще? Посмотри тут: http://archives.math.utk.edu/images.html
Здесь куча ссылок на образовательные сайты, мож там чего найдешь. Удачи!

[grozny]

Авралил, не читал последнюю неделю. счас немного отгребли.

Всё уже закончилось без меня   ? Если нет, то для работы только с пикселами ДХ не самая удачная штука - это всё-таки 3Д АПИ. Хотя PNG, JPEG понимает в хелперной либе D3DX - см. D3DXCreateTextureFromFile, D3DXCreateSurfaceFromFile и типа того.

Для чтения/записи битмапов пользую CxImage - он понимает кучу форматов и оччень прост. http://www.codeproject.com/bitmap/cximage.asp

Джон идею правильно обрисовал. "Пропорция" будет работать только для углов (между лучом зрения и плашкой с номером),  близких к прямому и на расстояних, много больших размеров номера. Т.е. я думаю практически всегда.

Ну если теорию разводить, то обратное перспективное преобразование называется. Т.е. есть матрица прямой перспективы (написана в ДХСДК, например, ну или в ОпенЖЛ), описывающая преобразование из объектного пр-ва в экранное, она из 3Д модели сделает картинку (плюс глубина). А тут надо наоборот, из экранного пр-ва преобразовать в объектное. Соответственно, обращаем матрицу перспективы, подставляем то, что знаем и далее вычисляем глубину. Наилучшее объяснение, что такое перспектива и всевозможные виды (в приложении к задаче машинного зрения, к тому же) видел в книжке Раушенбах "Теория перспективы". Не в курсе, существует ли электронный вариант.

Пример закачки видео в текстуру на ДХ9 - см. {DX90SDK}\Samples\C++\DirectShow\Capture\CaptureTex9,
{DX90SDK}\Samples\C++\DirectShow\Capture\CaptureTex

[Гром]

grozny, Интересно - ты ничего не пропустил - я как раз в работе.
Взял пример капчуринга в DXSDK где работают и берут кадры StillCap назывется.

Теперь делаю свою программку, которая должна будет делать это же - но тут получается одна проблема.

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

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

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

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

Пока все что написано для меня темный лес.

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

[Lex]

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

[Гром]

Lex, а остальное - ручками?

[Lex]

Угу. DX заточен под 3D причем для игр. Он изначально задумывался как API для разработчика игр. Для тебя оптимальным будет imho отработка алгоритмов в матлабе, благо он умеет картинки грузить и с видео работать, а затем реализация этого алгоритма на C\C++ в выходные попробую посмотреть по поводу захвата видео в виндах. делать это можно через DX или VfW(Video for Windows). VfW дает тебе последовательность bmp'шек с опредленной частотой.
Кстати я не совсем понял что у тебя на входе камера, с которой надо захват вести ли ведеофайл (avi), из которого тебе надо кадры тянуть и обрабатывать?

[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 внутри себя.

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

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

[Гром]

grozny, ну я собственно так и делаю.

[Ninetta]

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

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

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

помогите пожалуйста и мне с покадровым видеозахватом, а именно с коллбек функцией - в каком месте её надо вызывать и как?
class FrameGrabCallback : public ISampleGrabberCB
{
...
STDMETHODIMP SampleCB(double SampleTime, IMediaSample *pSample) 
...
}

...
hr = pGraphBuilder->QueryInterface(IID_IMediaEvent, (void **)&pEvent);
hr = pGraphBuilder->QueryInterface(IID_IMediaControl, (void **)&pControl);

hr = pGrabber->SetBufferSamples(FALSE);
FrameGrabCallback m_FrameGrabCallback;
m_FrameGrabCallback.Width=640;
m_FrameGrabCallback.Height=480;
m_FrameGrabCallback.framenum=1;
hr = pGrabber->SetCallback (& m_FrameGrabCallback, 1 );
hr=pControl->Run();

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