Eugeno

Отличная ссылка. Остановился на теоретико-числовых преобразованиях. Для входных целых данных никаких погрешностей при вычислениях. А по скорости вычислений - можно реализовать не медленней остальных преобразований.

А не подскажет ли кто, можно ли найти свёртку двух сигналов быстрыми методами не через преобразование Фурье, а через другие ортагональные преобразования? :unsure:

Появился недавно Code Composer Studio 3. Хочется для него написать небольшой плагинчик, но SDK к нему выдаётся только "третьим сторонам" :( :smile3046: Может есть у кого такая штука?

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

Проверил, как TI компилирует сохранение long-a, который у них 40-битный, но, естественно, при обменен с памятью сохраняет-считывает в регистровую пару все 64 бита (8 байт). Так вот, в зависимости от установленного в опциях endian-a сохраняет по разному. Т.е. получается, что все восемь байт будут при этом идти по разному и при попытки обратится как к массиву из int-ов 32-битных для разного endiana получим разные результаты! :( Это если сам разводишь плату (или влияешь на этот процесс).

Если программа работает c данными только на одной платформе, то проблем меньше. Endian-о зависимые участки кода локализуются и переписываются для разных Endian-ов, далее под разные платформы выбираются (линкуются) разные варианты. :angry2: Другой момент - обмен данными между устройствами (процессорами), у которых разный endian. Частный случай - если данные как-либо сохраняются в одном типе, а считываются уже на платформе с другим типом. Проблемы возникают тоько при обмене и только если данные процессором беруться из канала обмена (или из файла) не по байтам, а бОльшими порциями. Одно из решений (не самое лучшее по скорости работы, но лучшее в смысле переносимости) - передавать и принимать данные побайтно. Т.е. если надо передать 2х байтное слово, то выделяем и передаём сначала старший байт, далее младший; на приёмной стороне обратный процесс - считываем один байт, другой, и из двух этих байтов формируем сдвигами нужное нам число. Переносимость стопроцентная. То же можно организовать при сохранении/считывании данных на/с долговременных носителей. Если же нужна скорость, то при передаче данных всё равно кто-то должен делать перекодировку endiana, и выбирается та сторона, которой можно потормозить больше.

На выходных дочитался: необходимую корреляцию изображений делает сама микросхема-сенсор. Вот что написано про последжнее слово техники - микросхему ADNS-3060 ( http://main.soobcha.org/hard/spravka/teh/mouse.html ): Т.е. для реализации задуманного необходима всего лишь одна микросхема, которая являет в себе и сенсор, и процессор данных. Собирается схемка, делается ПО - как для сканера с указанного мной ранее сайта http://o-d-v.nm.ru/optical_mouse (только там микруха другая ADNS-2051) и всё готово! :)

Проблемы будут с выбором железа - лёгкая видеокамера с динамической фокусировкой, процессор и его программирование, проблемы энергопотребления и т.п. Нашёл неплохой сайт на эту тему - что видит сенсор мыши, использование её в роли сканера - http://o-d-v.nm.ru/optical_mouse

Intel-овский компилятор очень успешно работает с SSE. Можно заоптимизировать цикл близко к оптимальному используя лишь разные pragm-ы и написав цикл особым образом. Сам компилятор можно настроить, что б выдавал рекомендации и замечания к циклу, это помогает не гадать, почему он плохо компилирует, а сразу идти к результату. Есть интеловская библиотека работы с матрицами. Поэлементное умножение, солжение с умножением одного слагаемого на константу и т.п., FFT и т.п. - всё это сделано и очень круто заоптимизировано под любые SSE и MMX (можно настроить библиотеку, чтоб выбирала нужный вариант динамически при запуске или линковались версии жёстко на нужный варант процессора). Этот путь мне кажется более перспективным. Надо очень неплохо знать архитектуру современных процессоров, что б обставить компилятор (при условии того, что компилятор тебя понял).

Алгоритм - обычная NCC корреляция. Камера - обычная бытовая цифровая с выдачей PAL стандарта. Работает в модели на Intel P4 2600 c частотой обработки ~ 10 кадров в секунду (кроме корреляции сюда входит приём видео по 1394, его отрисовка, перекодировки и т.п.). По оценкам то же самое должно работать на TMS320C64 1Gh, но обработка будет вестись не всего кадра в оригинальном масштабе, а центральной части с достаточным уменьшением. Суть алгоритма - строим корреляцию между учатском прошлого кадра и участком текущего кадра, далее в коррелограмме искался максимум, вокруг максимума проводилась апроксимация поверхности коррелограммы и находился максимум уже с большей точностью. Именно. Если изображение, поступающее на вход камеры будет малоконтрастным, то пик коррелограммы будет очень плоским и вершина не будет определятся точно, будет плавать даже на стоячем изображении.

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

Оригинальней ничего не надо. Задача самодостаточна. По четырём точкам можно найти однозначную апроксимацию участка кривой полиномом третьей степени x(t) = a*t*t*t + b*t*t + c*t*t + d*t + e; Производную полинома приравниваем к нулю и вуаля - результат. Полином третьей степени имеет хорошую устойчивость в силу своей простоты, а решение по четырём точкам однозначно - это тоже больщое преимущество.

Попробуй в файле "mconf.h" в строке 130 раскоментировать строку #define IBMPC 1 и соответственно в строке 143 закоментировать #define UNK 1 Для персоналок это должно помочь, т.к. при неизвестном компьютере он делает допущения о плавающих числах немного (для меня) странные.

Можно и самому посчитать, если известна схема вычисления БПФ и ты хорошо понимаешь, сколько бит информации мы теряем при сложении и умножении чисел. Но проще взять оценочно из книг. Тем более если для препода - даже лучше будет.

:glare: Вероятно, ему хочется, что б ты просчитал, какой шум привнесёт эта схема преобразования сигнала по сравнению с "теоретически-безпогрешной". Шум вносит само преобразование плюс твои некоторые операции. Если это так, то нужно оценить шум, если он слишком большой, то увеличить точность fft (на точность влияют и схема вычислений, и точность представления чисел). Если шум в нормальных пределах (зависит от уровня и типа обрабатываемого сигнала), то просто это всё обосновать.