УЗИ обработка

.

Jurgis Armanavichius snipped-for-privacy@medelkom.com пишет в сообщении: snipped-for-privacy@p2.f.n5020.z2.ftn...

Впpочем, сейчас темпы технического пpогpесса в этой области настолько > велики, что пока я бyдy осваивать пpемyдpости SSE, появится пpоцессоp > гига на 2-3 :-)

Здравствуйте! Меня зовут Олег Дерин, я работаю в Институте информатики РАН и имею значительный опыт разработки и внедрения радарных и телевизионных систем обработки и распознавания объектов. Поэтому Ваша задача мне достаточно близка. Мне кажется, вы идете в не вполне правильном направлении. По моему опыту в такой задаче Вас будет тормозить не процессор и его команды, а оперативная память. Мы недавно сдали систему автоматического распознавания и сопровождения отдельных людей в толпе, и процессор 3ГГц часть времени простаивал по этой причине. Это происходит из за того, что при последовательном выполнении матричных операций (например - пространственная интерполяция) промежуточные результаты - матрицы - слишком велики, чтобы влезть в кэш процессора, и последний работает в режиме постоянных кэш-промахов. Есть два пути решения:

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

пихается

в FPGA. Бо на процессоре общего назначения накладно получается или

вообще

невозможно.

Также не вполне верно, что в этой области программно ничего не делается. Для FPGA писать конечно проще (меньше ограничений), но дорого (применяется в основном в некоммерческих изделиях). Современные процессоры позволяют вести достаточно глубокую обработку realtime для видео, по крайней мере интерполяцию - с большим запасом. Для небольших серий мат плата с процессором выйдет дешевле выполняющей аналогичною функции платы с FPGA примерно на порядок. Для Вашего - чисто коммерческого - случая я бы рекомендовал попробовать использовать смешанный метод - на входе стоит небольшая FPGA, управляющая сенсором, получающая от него данные и сбрасывающая их с минимальной обработкой внутрь РС, может быть даже сформировать аналоговый видеосигнал и подать его на встроенный в мат. плату видеозахватчик (их можно довольно лихо программировать на прием "не вполне ТВ сигнала"). Затем написать обработчик в виде фильтра DirectX (подсистема DirectX гораздо ближе к реалтайму, чем что - либо в виндах). Писать фильтр DirectX очень просто - берется пример такого фильтра и переписывается только подпрограмма обработки видеоданных. Затем пишется пресловутый "медиаплеер" - программу, строящую граф с участием написанного фильтра, также путем минимальой правки любой готовой программы медиаплеера с исходникми . Пойдя этим путем Вы, по моему мнению, сократите себе работу раза в три...

С Уважением О.А.Дерин, СПИИРАН derin<злой знак>mail<знак>rcom<знак>ru

Reply to
invalid unparseable
Loading thread data ...

Добрый день ДеринОА.

09 Сен 06 07:23, ДеринОА -> All:

Д> значительный опыт разработки и внедрения радарных и телевизионных Д> систем обработки и распознавания объектов. Поэтому Ваша задача мне

Давно размышлял, но не у кого было спросить. Если красить ресницы металсодержащей тушью и ловить ее отражение, общий смысл - мышь которая движется взглядом. Hа существующей элементной базе и попсовой схемотехнике (вроде RFID для которой много чего напридумывали) такую штуку, насколько понимаю, нельзя сделать? Подпись: Озеров Е.М.

Reply to
Evgeny_Ozerov

Добрый день Aleksandr.

09 Сен 06 17:37, Aleksandr Konosevich -> Evgeny_Ozerov:

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

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

Подпись: Озеров Е.М.

Reply to
Evgeny_Ozerov

Д> Мне кажется, вы идете в не вполне правильном направлении. По моему Д> опыту в такой задаче Вас будет тормозить не процессор и его команды, а Д> оперативная память. Мы недавно сдали систему автоматического Д> распознавания и сопровождения отдельных людей в толпе, и процессор Д> 3ГГц часть времени простаивал по этой причине. Это происходит из за Д> того, что при последовательном выполнении матричных операций (например Д> - пространственная интерполяция) промежуточные результаты - матрицы - Д> слишком велики, чтобы влезть в кэш процессора, и последний работает в Д> режиме постоянных кэш-промахов.

Это точно. Сам недавно столкнулся, когда производительность быстрого процессора растворилась в постоянных SDRAM page miss.

Д> Есть два пути решения: Д> 1.применить максимально быструю ОЗУ не считаясь с расходами.

SRAM оказалась неприемлема.

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

А вот изменение алгоритма помогло.

Hедавно прочитал интересную статью "Memory Architecture for Efficient Utilization of SDRAM: A Case Study of the Computation/Memory Access Trade-Off". В ней обсуждается выбор алгоритма и архитектуры памяти для трехмерной визуализации данных с медицинских сканеров (компьютерная томография). Требования были такие - обеспечить 25 fps при отрисовке 2 миллионов треугольников. При первой реализации скорость получилась всего 3-4 fps. А в конце - 58 fps.

Reply to
Victor Bazhenov

Hello Evgeny_Ozerov!

Д>> значительный опыт разработки и внедрения радарных и телевизионных Д>> систем обработки и распознавания объектов. Поэтому Ваша задача мне

EO> Давно размышлял, но не у кого было спросить. Если красить ресницы EO> металсодержащей тушью и ловить ее отражение, общий смысл - мышь EO> которая EO> движется взглядом. Hа существующей элементной базе и попсовой EO> схемотехнике EO> (вроде RFID для которой много чего напридумывали) такую штуку, EO> насколько EO> понимаю, нельзя сделать?

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

Reply to
Aleksandr Konosevich

Пpиветствую, Victor!

Д>> Есть два пути решения: Д>> 1.применить максимально быструю ОЗУ не считаясь с расходами. VB> SRAM оказалась неприемлема. Обычная асинхронная ? А всякие синхронные SRAM, ZBT SRAM пробовал прикинуть ?

VB> Hедавно прочитал интересную статью "Memory Architecture for Efficient VB> Utilization of SDRAM: A Case Study of the Computation/Memory Access VB> Trade-Off". Урлом поделишься ? Или на мыло mixx собака nightmail точка ru Мне скоро эта тема (быстрое озу) будет очень актуальна.... Michael Tulupov ...

Reply to
Michael Tulupov

Hello Evgeny_Ozerov!

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

EO> Hасколько разбираюсь, там ИК в глаз бьет, а у меня миопия. Да и EO> точности EO> у приемников должно хватать только чтобы их на оправу очков вешать.

Сколь помню видеосюжет, там одна (или две ?) вебкамеры с близкого расстояния "смотрели" на лицо (глаза) оператора, всё остальное делал софт.

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

Reply to
Aleksandr Konosevich

Д>>> Есть два пути решения: Д>>> 1.применить максимально быструю ОЗУ не считаясь с расходами. VB>> SRAM оказалась неприемлема.

MT> Обычная асинхронная ?

MT> А всякие синхронные SRAM, ZBT SRAM пробовал прикинуть ?

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

VB>> Hедавно прочитал интересную статью "Memory Architecture for VB>> Efficient Utilization of SDRAM: A Case Study of the VB>> Computation/Memory Access Trade-Off".

MT> Урлом поделишься ? Или на мыло mixx собака nightmail точка ru MT> Мне скоро эта тема (быстрое озу) будет очень актуальна....

formatting link

Reply to
Victor Bazhenov

Hello Michael Tulupov!

Д>>> Есть два пути решения: Д>>> 1.применить максимально быструю ОЗУ не считаясь с расходами. VB>> SRAM оказалась неприемлема. MT> Обычная асинхронная ? MT> А всякие синхронные SRAM, ZBT SRAM пробовал прикинуть ? VB>> Hедавно прочитал интересную статью "Memory Architecture for VB>> Efficient VB>> Utilization of SDRAM: A Case Study of the Computation/Memory Access VB>> Trade-Off". MT> Урлом поделишься ? Или на мыло mixx собака nightmail точка ru MT> Мне скоро эта тема (быстрое озу) будет очень актуальна....

Ещё во времена появления 3DNow! в наборы команд были введены операции для легальной работы с кэшем (параллельная с работой загрузка строк кэша и так далее) - думаю, что подобные фичи есть в нынешних камнях как у Intel, так и у AMD. Hеужто это никто не пользует ?

Reply to
Aleksandr Konosevich

Д>>>> Есть два пути решения: Д>>>> 1.применить максимально быструю ОЗУ не считаясь с расходами. VB>>> SRAM оказалась неприемлема. MT>> Обычная асинхронная ? MT>> А всякие синхронные SRAM, ZBT SRAM пробовал прикинуть ? VB>>> Hедавно прочитал интересную статью "Memory Architecture for VB>>> Efficient VB>>> Utilization of SDRAM: A Case Study of the Computation/Memory VB>>> Access Trade-Off". MT>> Урлом поделишься ? Или на мыло mixx собака nightmail точка ru MT>> Мне скоро эта тема (быстрое озу) будет очень актуальна....

AK> Ещё во времена появления 3DNow! в наборы команд были введены операции AK> для легальной работы с кэшем (параллельная с работой загрузка строк AK> кэша и так далее) - думаю, что подобные фичи есть в нынешних камнях AK> как у Intel, так и у AMD. Hеужто это никто не пользует ?

Ты про что???

Reply to
Victor Bazhenov

AK>> Ещё во времена появления 3DNow! в наборы команд были введены AK>> операции для легальной работы с кэшем (параллельная с работой AK>> загрузка строк кэша и так далее) - думаю, что подобные фичи есть AK>> в нынешних камнях как у Intel, так и у AMD. Hеужто это никто не AK>> пользует ?

VB> Ты про что???

А, понял, про Software Prefetching.

Reply to
Victor Bazhenov

Hello Victor Bazhenov!

AK>>> Ещё во времена появления 3DNow! в наборы команд были введены AK>>> операции для легальной работы с кэшем (параллельная с работой AK>>> загрузка строк кэша и так далее) - думаю, что подобные фичи есть AK>>> в нынешних камнях как у Intel, так и у AMD. Hеужто это никто не AK>>> пользует ?

VB>> Ты про что???

VB> А, понял, про Software Prefetching.

Разумеется (извращённые варианты загрузки кэшей через TR'ы и т.п. - не рассматриваем, т.к. они требуют привелегий и нехилого знания самой архитектуры 8-)

PS Вопрос остаётся в силе ;-)

Reply to
Aleksandr Konosevich

AK>>>> Ещё во времена появления 3DNow! в наборы команд были введены AK>>>> операции для легальной работы с кэшем (параллельная с работой AK>>>> загрузка строк кэша и так далее) - думаю, что подобные фичи AK>>>> есть в нынешних камнях как у Intel, так и у AMD. Hеужто это AK>>>> никто не пользует ?

VB>>> Ты про что???

VB>> А, понял, про Software Prefetching.

AK> Разумеется (извращённые варианты загрузки кэшей через TR'ы и т.п. - AK> не рассматриваем, т.к. они требуют привелегий и нехилого знания самой AK> архитектуры 8-)

Ага, интересно. Правда правильное применение кэша тоже требует знания архитектуры. :)

AK> PS Вопрос остаётся в силе ;-)

Попробую на текущей задаче, для меня это как раз актуально (правда не на x86, но там тоже есть PREFETCH).

Reply to
Victor Bazhenov

Пpиветствую, Aleksandr!

AK> Ещё во времена появления 3DNow! в наборы команд были введены операции AK> для легальной работы с кэшем А как это относится к обсуждаемому треду ?

Michael Tulupov ...

Reply to
Michael Tulupov

Привет!

Thu Sep 14 2006 12:34, Aleksandr Konosevich wrote to Michael Tulupov:

AK>>> Ещё во времена появления 3DNow! в наборы команд были введены AK>>> операции для легальной работы с кэшем MT>> А как это относится к обсуждаемому треду ? AK> Сколь помню, Юргис использует х86-совместимую платформу для проведения AK> основных вычислений в своём приборе, а аналогичные фичи были не только AK> у AMD, но и у Intel (да и вообще, у разных DSP с кэшем я тоже подобное AK> видел)

Совершенно верно. Правда, пока я еще не освоил "высший пилотаж" для проводимых вычислений, обхожусь только целочисленной математикой. Hо главное, почему мы применили PC-совместимую материнку, - это поддержка USB 2.0 и простая и качественная работа с графическими панелями. Как представлю, что я в своей самопальной плате сооружаю интерфейс с TFT панелью - в дрожь бросает... :-)

Юргис

Reply to
Jurgis Armanavichius

Hello Michael Tulupov!

AK>> Ещё во времена появления 3DNow! в наборы команд были введены AK>> операции AK>> для легальной работы с кэшем

MT> А как это относится к обсуждаемому треду ?

Сколь помню, Юргис использует х86-совместимую платформу для проведения основных вычислений в своём приборе, а аналогичные фичи были не только у AMD, но и у Intel (да и вообще, у разных DSP с кэшем я тоже подобное видел)

Reply to
Aleksandr Konosevich

Пpиветствую, Aleksandr!

MT>> А как это относится к обсуждаемому треду ? AK> Сколь помню, Юргис А причём тут Юргис, если тред начат Victor Bazhenov, у которого эта SDRAM, как я понял, подключена к FPGA ? А процессор - BlackFin....Лучше б по делу чего сказал.

Michael Tulupov ...

Reply to
Michael Tulupov

MT>>> А как это относится к обсуждаемому треду ? AK>> Сколь помню, Юргис

MT> А причём тут Юргис, если тред начат Victor Bazhenov, MT> у которого эта SDRAM, как я понял, подключена к FPGA ? MT> А процессор - BlackFin....Лучше б по делу чего сказал.

:) В Blackfin кстати есть кэш и software prefetch. Только вот прикинул, для моей задачи это вряд ли чем поможет. Чтобы уменьшить кэш промахи надо по-другому хранить данные в памяти, не построчно, а секциями. И чтобы секция помещалась в кэш строку. Хотя конечно software prefetch в некоторых случаях может быть полезен, не отрицаю.

Reply to
Victor Bazhenov

Hi Jurgis !

Совсем недавно 14 Sep 06 10:00, Jurgis Armanavichius писал к Aleksandr Konosevich:

JA> Hо главное, почему мы применили PC-совместимую материнку, - это JA> поддержка USB 2.0 и простая и качественная работа с графическими JA> панелями. Как представлю, что я в своей самопальной плате сооружаю JA> интерфейс с TFT панелью - в дрожь бросает... :-) А что здесь такого? Ставишь эпсоновский коннтроллер дисплея, ucGUI, и вперед. Глаза боятся- руки делают. :) В этом интерфейсе самое хитрое- это разъемчики и шлейфики, ну и про преобразователь для питания подсветки не забудь. Конечно, если не отпугивает шаг ножек 0.4мм. :) Да и USB2.0 встроенная сейчас не редкость. Включил ПДП - и жарь.

WBRgrds Ruslan

Reply to
Ruslan Mohniuc

Привет!

Fri Sep 15 2006 06:15, Ruslan Mohniuc wrote to Jurgis Armanavichius:

JA>> Hо главное, почему мы применили PC-совместимую материнку, - это JA>> поддержка USB 2.0 и простая и качественная работа с графическими JA>> панелями. Как представлю, что я в своей самопальной плате сооружаю JA>> интерфейс с TFT панелью - в дрожь бросает... :-) RM> А что здесь такого? Ставишь эпсоновский коннтроллер дисплея, ucGUI, RM> и вперед. RM> Глаза боятся- руки делают. :)

Возможно :-) Только как-то надоело самому делать видеовывод... Взять готовое - намного проще.

RM> В этом интерфейсе самое хитрое- это разъемчики и шлейфики, ну и про RM> преобразователь для питания подсветки не забудь. Конечно, если не RM> отпугивает шаг ножек 0.4мм. :)

При нынешнем уровне технологии на Западе (точнее, на дальнем Юго-Востоке ;-) такой шаг уже не проблема.

RM> Да и USB2.0 встроенная сейчас не редкость. Включил ПДП - и жарь.

Вот мы и посмотрели. Чип графики, память, процессор нужно помощнее, USB2.0, без FPGA не обойтись, всякая дополнительная обвязка... Выходит, что поставить готовую материнку заметно дешевле и несравненно проще :-)

Юргис

Reply to
Jurgis Armanavichius

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.