ryhor

ну если надо точно - калибровка проводится после сборки камеры - т.е. после того как объектив прицепили. смещение центра линзы относительно центра картинки/матрицы - оно может очень быть интересным :). если камера в сборе - обычно на "заводе" ее калибруют и в общем среднем или из камеры "читается" или должно прилагаться.

примерно так - понять что нужно видеть в результате - т.е. какую область в рыбо-глазной картинке - предварительно рассчитаная таблица: от окна наблюдения точка -> какую точку взять в рыбо-глазой картинке - интерполяция там же в таблице заложена. по итогу коррекция в реальном времени будет через простой LUT Это если просто картинку расправить. Если надо поточнее - то надо учитывать параметры каждой рыбо-глазой камеры (производители их предоставляют) и таблица "при страте" рассчитывается под конкретную камеру.

Значит обновили воспоминания :). Это тестовая реализация mpeg4-2 от момусиса так сказать. Причем походу дела там был распил бабла класический - т.е. универы что "принимали" участие в написании стандарта слегка пользовали студентов для написания кода. В итоге я так сильно плевался глядя на декодер, что энкодер уже был написал самостоятельно и без пользования референсных, простите фекалий. Почему так грубо - потому что от референсного варианта ожидается если не качества реализации, то хотя бы понятность. Т.е. пусть люди не умеют программировать, но они знают что делает алгоритм или же пусть они хорошо программируют, но им не понятен алгоритм. Но когда оба пункта совмещаются своей худшей стороной и это называется референс реализация - это как бы никуда не годится. Для вас самое интересное в документе. Причем его даже номер не понятен, а то что есть сейчас в интырнете на него очень похожее, уже не содержит так сказать содержательной части. Поэтому смотрите приложеный файл - найдете там про таблицы ближе к середине. Про декодер - посмотрите и сможете оценить масштабы бедствия. И это еще вычещеная часть - уже отделенная для дальнейшего "обогощения". Вот это обогощение и достанется вам в нагрузку :). Все что будет со словами "LMP1000" - это аппартно-зависимые вставки для делавшегося чипа. В кристалле были аппаратные ускорители, которые заменяли целые вычислительные блоки (аля DCT/iDCT). В принципе вы можете найти где то в природе и незамутненую реализацию от MoMuSys - тут уж как вам будет удобне. вам будут интересны файлы vm_get_blk.c vm_vlc_dec.c и все что "к ним" / "от них" ведет. Будут вопросы - задавайте, попробую еще что то вспомнить. wXXXX.zip vm_dec.zip

VLC удобнее и быстрее всего декодировать через таблицу. Где то в интырнете есть double table decoding... что то в этом духе кажется для MPEG4-2. Я когда то делал по этой статье или там даже где то были исходники таблиц - надо поискать. Суть метода простая - вход в таблицу - т.е. индекс строки это кусок ваших бит - скажем штук 11. Каждая строка имеет полей типа: - сколько бит "используется" - кодовые слова для этих бит - может быть 1 или даже 2 - флаг что вы декодировали кодовое слово или же что ваших 11 бит мало (типа что то длинное попалось) и тогда дается ссылка на таблицу второго уровня. такой метод работает очень быстро - потому что вы вынимаете за обращение к памяти одно или два кодовых слова. И потребляет не так много памяти - потому что таблица двухуровневая и индексы не становятся магически огромными. Второй момент - то что редко (реже) встречается требует немного больше возни со вторым обращением к памяти, но на то оно и редко встречается. для какого стандарта декодируете? потому что повторюсь для MPEG4-2 у меня оно должно быть где то в закромах.

ну теперь если с выходом и входом не напутано - т.е. - "пикали" на макс громкости - захватывали на той чувствительности что будет работать микрофон то можно сказать что акустического эха у вас нет :) И как следствие можно вообще ничего не делать в этом направлении. Проверьте все еще раз на всякий случай. Один из вариантов - проговариваете в динамик речь и пишете что слышит микрофон. Если вы ИХ правильно намеряли записанная речь должна быть в теже дБ что на картинке меньше.

Вот - половина (большая) дела сделана. Теперь вы знаете длительность ИХ и соотвественно все понятно по длине фильтра. Но картинки ваши настораживают вот по таким пунктам - что это за ассиметричный сигнал в 8000 (*2^-15) амплитуды? к нему два вопроса: 1. самый главный - почему он ассиметричный если это внешний звук или шум 2. он слишком большой - ИХ имеет слишком большую амплитуду - т.е. все сказанное из динамика с амп 1 попадает в микрофон и после оцифровки получается размахом во всю шкалу. Это очень интересно - и очень плохо :) что надо поделать - посмотрите не стоит ли у вас АРУ где то в канале в том или ином виде - с АРУ надо осторожно, если вообще надо в вашем случае - порегулировать коэфф усиленя микрофона - он слишком чувствительный у вас прямо сейчас - разобраться откуда ассимитрия "шумового/внешнего" сигнала При таком уровне соотношения амплитуд (2^-15*) 8000..6000/32000 = 0.25 вы больше ~-12-15дБ подавления не получите. Еще интересно - ИХ более менее симметричная в +и-, а вот это "нечто" сугубо в одну сторону - там явно где то косяк. UPD - вот первая картинка не плохо выглядит в качестве как бы "тишины", а выбросы положительные это что от не то.

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

добавьте к сигналу ближней стороны скажем -20дБ шума и посмотрите куда ваш NLMS сойдется и как быстро он будет это делать. ало внимание - у нас голос :) Шуметь придется в свой динамик что бы свой микрофон поймал сигнал - посему: - причем тут канал? - как можно не слышать шум из динамика своего телефона? - как его услышит микрофон если его не слышит ухо? - как громко надо шуметь что бы быть эффективным на фоне внешних шумов? На самом деле этот метод не используют по причинам - не красиво - канал меняется и пшикать надо будет регулярно - самое важное - на голосе эхоподавитель тоже нормально сходится - качество подавления ограничены внешними шумами - скорость схождения ограничены внешними шумами а так - теоретически все правильно, пошуметь всегдя приятно. Если автор захочет в последствии ускорить сходимость или качество - есть гораздо более действенные решения чем "шуметь" да я уже план-график расписал чего делать и как. :) Что значит я уверен или не уверен? я тут не причем - это все природа. Хочет меняет хочет не меняет :). Т.е. как бы дело не в уверенности или не уверенности, а в том что практика говорит (в прямом смысле в этом случае :) ). Т.е. еще раз параметры эхоканала - меняются (считайте что это дано). Ну а так ваш план-график не сильно отличается от моего, но мне не нравится делать LMS не пытаясь даже понять чего им будет компенсироваться. - алгоритмы не сложные - нет проблем с синхронизацией - цель измерения увидеть форму и длину ИХ - работы на пару часов кодить и 5 минут смотреть на данные - то что надо сделать практически было уже три раза написано, бездумно лепить LMS с малым коэфф и компенсировать это "решение" шипением в свой динамик - это как бы... даже слов нету что :)

умилительно читать ваше словоблудие :) - нет с вам спорить никак не есть самоцель чисто пытаюсь уберечь людей от: - измерения ИХ посредством LMS - веры что NLMS сходится всегда и быстро независимо от окружения :) я покажусь занудой но задача стоит - сделать Акустический Эхо Подавитель я спрошу только один вопрос - вы точно делали акустический эхо подавитель (на цифровом или что как бы есть одно и тоже что и без канала связи)? - потому что судя по потоку мыслей вы делали что то другое. Отсюда видимо и советы а-ля измерять ИХ посредством LMS или ненужности DD при (N B)LMS алгоритмах. Так же радует глаз уверенность в невозможности изменения эхоканала в процессе работы - бывает конечно что он и стоит как вкопанный, но чаще нет и именно пока несут к уху он и меняется. NLMS, LMS никогда не сойдутся ни к -30 и ни к -20дБ если в момент поднятия трубки (что есть начало работы адаптаро) в микрофон будет попадать сторонний (не из эхоканала) звук. Не сойдется он ровно на столько на сколько будет ему мешать этот сторонний источник. Я тут не причем - это природа такая, а теория ее только описывает. Как ни странно практика ее подтверждает. И именно поэтому было придумано средство - не адаптироваться в случае звука не из эхоканала. - адаптироваться как можно быстрее в случае звука из эхоканала. Этот подход тоже имеет проблеммы, но он более живуч в практике чем то что предлагаете вы. Т.е. я немного критикую подход в котором мы - пробуем радостно пооадаптировться 1 сек в начале, получим при этом фильтр ни имеющий ничего общего с эхоканалом (из-за вот этих сторонних шумов) - и потом медленно и печально с малым (кстатит каким?) шагом адаптации будем "перетянуть" коэфф фильтра в правильную форму. Чтобы этот подход дал приемлимый результа - надо делать несколько непростительных для реальной этой задачи предположений. Это не будет работать в средне-нормальном случае применения для автора топика - лучше сразу сделать все по уму и потом наслаждаться результатом.

Ну как любят мух отдельно от каклет - смешивать фильтр и адаптивный алгоритм - это на любителя :) Адаптация 20дБ за 1 сек - это очень и очень хорошо - это даже вроде по какому то ИТУшному стандарту, но LMS и даже NLMS ее в среднем обеспечить не могут. Обычно надо несколько секунд. Потом пулять самому шум из своего динамика это конечно тема, но часто вы видели шипяще щелкающие телефоны в природе? Обычно пока дальняя сторона наговаривает нам в динамик местный фильтр успевает настроится и обеспечить отсутсвие эха для нее. Далее - акустический эхо канал устанавливается постепенно - например после того как пару динамик-микрофон к голове приложили он может и поменяться и в дальнейшем опять может поменяться - поэтому примораживать адаптацию на совсем немного "опасно". Про "двойной разговор" - Почему это нет DD пока клиент снимает трубку? это типа дано? в реальности к сожалению это совсем не так. - Любой посторонний шум (речь, звуки) попадающий в микрофон при включенном адаптаторе будут его так сказать неправильно информировать :) - на что он будет хладнокровно подстраивать фильтр - в никуда. А то что коэфф адаптации маленький - это только как бы говорит что адаптатор почти выключен. Т.е. получается что "двойной разговор" "безопасен" когда нет адаптации, а если она все время нужна и достаточно активно? Начнем с конца - какой длинны LMS ему таки нужен? :) Хватит 32 тапа? или там все 200мс эха? Ну и как бы ИХ меряется очень просто - посредством измерения ИХ :). Кстати не вижу какие там проблеммы с синхронизацие? пикнул и пиши звук. а вот LMS с малым коэф. может намерять такого что никакой ИХ не снилось. Как долго давать адаптироваться? Ну в общем то в сферическом (в вакууме) случае они конечно сойдутся к одному и тому же, но все же лучше дейстовать прямыми методами, тем более что они проще и гораздо менее подвержены ошибкам.

да ладно 3-4 строчки на КИХ хватит :) ну там проверить не нули ли пришли в гости - но это лабуда NLMS в целых числах - 5 строчек считая вместе с "for(..." ну там да - пару строчек до и пару после Т.е. согласен - на все про все КИХ + NLMS 30-40 строчек в самый раз. UPD - да пересмотрел - действительно что бы быстро и точность не сильно губить в 16 битах приходится немного цикл развернуть (unroll) и пошаманить. Однако у автора плавующие звери. плавающая точка - это хорошо, но скорость адаптации все равно радует именно побыстрее. Т.е. если у вас фильтр адаптивный будет пару минут сходится к 20дБ подавления - то можно считать что его и нет. А малый коэфф адаптации именно это и подарит. ну и детектор двойного разговора - точнее его отсутствие - будет "разносить" фильт в случае чего на ура - ибо он (фильтер) будет пытаться подстроится под подавление звука который совсем даже не из динамика пришел.

ну тогда первая строка гугла на запрос "импульсная характеристика" http://ru.wikipedia.org/wiki/Импульсная_переходная_функция т.е. как бы импульс для импульсной характеристики вполне определенная "весч". Что есть дельта функция для вас? - это один такой отсчет макс аплитуды (можно меньше) вокруг которого тишина... как звук попадает в микрофон? - через динамик как звук попадает в динамик? - вы его в него и посылаете через ЦАП ну вот и приготовьте правильную посылку в ЦАП и пошлите ее да - не шумите в комнате когда будете ИХ мерять и так же уберите возможные доп акустические каналы :). Ну на стол не ложите например - т.е. должен быть реальный акустисческий канал - подумайте как у вас там звук бегает - по воздуху - по плате - по корпусу ... я немного повторюся - для акустического канала вам надо 1. найти ИХ - в частности ее длину - отсюда станет ясна длина вашего адаптивного КИХ фильтра. 2. поглядеть АЧХ - насколько оно линейное - т.е вы в него синус - а оно вам в ответ насколько не синус? но тут если уж совсем каких то косяков железячных нет - все должно быть более менее - посему это больше как упражнение на разминку. 3. читаем про LMS и NLMS адаптивные фильтры. 4. Делаем реализацию фильтра с КИХ (3-4 строчки?) и реализацию "адаптатора" этого КИХ фильтра алгоритмом NLMS - столько же строчек по существу вопроса. 5. смотрим на результат - радуемся или плачем - в зависимости от успеха 6. думаем про "детектор двойного разговора" 7. конец ... через какое то время 8. если хочется бооольшего подавления - начинаем читать про RLS алгоритмы адаптации Никакие готовые проекты вам не помогут - точнее они не нужны ибо сил на их анализ и привязывание к вашей ситуации надо гораздо больше чем сделать самом. Т.е. или вы осознаете что вам надо или нет: если нет - готовые решения не помогут если да - они вам не нужны :) - вот такие пироги. По сути же вопроса (если не вдаваться в теорию по уши как говорится) - надо реализовать два алгоритма каждый из которых математически выражается одной строчкой. Один это КИХ, второй это NLMS. Но не вдаваясь в теорию "совсем ни капли"- вы не сможете их правильно применить - получается надо таки разобраться . Можно глубоко, можно "по месту" - вот реализация КИХ с NLMS - это нормальное такое начало для получения более менее годного для практического применения результата без погреения себя в дебрях обработки сигналов.

хз что тут с форумом - меня самого не пускает к личным сообщениям - хотя там горит что их 2 штуки - написал админам - ответу нету. ваше мыло в профайле ругается - типа не правильно отпишитесь ryhor (одна собака) tut.by что бы измерить длинну Импульной Характеристики (ИХ) надо видимо вспомнить определение ИХ. И потом все таки взять себя в руки и подать таки Импульс в систему - что бы увидеть как она его пережовывает- т.е. какова ИХ системы? :) забудьте слово гибрид - у вас есть: - акустическое эхо - и цифровой канал передачи данных - и нету гибрида :) ну или он вам не заметен Запостите картинку ИХ - интересно посмотреть кстати на какой часатоте работает звуковая система? 8кГц?

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

Итак у вас техас 28хх серии для всего с голосом (микрофонить и говорить) и телефон в качестве модема с передачей данных по CSD, при это вам нравится непрозрачный режим. понятно. а какой именно телефон? - ну это уже чисто любопытсво. немного в сторону -а чем не нравится вот такое решение? http://www.signal-com.ru/ru/prod/phones/phones_345/index.php чисто софт пописать? но тем не менее - к делу первое и самое главное вам надо узнать АЧХ акустического эхоканала вашего телефона (назовем это так). Особенно полезно знать длину Импульсной Характеристики. как только станет ясна длина - все станет сразу понятно по ресурсам. как только станет ясно с линейностью - сразу станет ясно насколько хорошо будет работать адаптивный фильтр с алгоритмом адаптации NLMS - что есть простое и эффективное решение во многих (простых :) ) случаях. получите цифры и картинки - покажите а там и готово уже почти.