Ну что-же. Тогда пересматриваем цифры. Значит, до BF'а нам еще 80%, почти в 2 раза хуже. С другой стороны, соотношение с тактов у AVR с тактами у ARM уменьшилось - так что выигрыш за счет 32хразрядной архитектуры стал около 2х.



да хрен с ними, на 4х миллионах то...

События развиваются так быстро, что не успеваю переваривать.

Может тогда осветить вопрос наиболее подходящих камер для подобных проектов?

Выкладываю даташит на одну из них.

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

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

Собственно озу предолагалось метров на 64. Теперь буду думать над оптимизацией.

Очинь апасна

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

Не совсем секрет. Устройство, очень похожее на хороший фотоаппарат. Ничего монстроузорного в 2 Мпикселях нет.

Нет ли у кого более подробной информации по LZ0P39HA или LZ0P3954?
Всмысле I2C и режимов работы. Конструктив мне понятен.

Все остальное, вроде, под NDA дается.

Может брал кто уже под NDA? Поделитесь пожалуйста.
А то лежат LZ0P39HA, не знаю как подступиться...

NDA - это соглашение о неразглашении информации. Из подписавших никто не даст из-за последствий.

А если попробовать VS6724?

А вот это не подходит ?
http://hw.cz/files/redaktor130/LZ0P39HA_SP...NS_20071108.pdf

Вам она больше подойдёт несомненно, поскольку жмёт в JPEG сама.
Меня больше интересует изображение в YUV420 ибо камеры на самом деле, в частности MT9D131, выдают JFIF без заголовков и коэфициентов, которые надо формировать самому. Т.е. надо или работать с постоянными коэф. или вычитывать их по I2C.
Причём доступ к многим регистрам в MT9D131 через узенькую дырочку.

PS: VS6724 мне понравилась, жаль раньше не видел. И дока подробная.




Это есть в нескольких местах в интернете, и естественно я получил этот документ при покупке модулей.

Прочитав документ я не нахожу ответа что такое адреса 5e4-5eb, неясно каким образом осуществляется 5 кратный зум и перевороты картинки.

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

И регулировка автофокуса не ясна. Данные о наличии или отсутствии фокуса должны идти с камеры, даже если я сам кручу мотором. Если мне самаму придётся обрабатывать кадр - это уже ручной фокус.

Для полного счастья не хватает примеров работы. Нашел только какие-то обрывки кода для получения данных на STR9... Жудко нехороший процессор

Что-то у меня с JPEG никак отношения не ладятся.
Откомпилировал ваш исходник в DEV-C++ под винду - результат конвертации ошеломляет. Может кто подскажет - что не так, визуально?
Округления? Инты, шорты, чары? Структуры?
Исходная картинка - таже.

Разная обработка сдвигов в ARM и в x86. Разный результат у сдвигов на 32 бита.

Для ARM кодер собирается и работает, так что пользуйте. Не забывая про GNU

Ну как? Разобрались? Если нет - то в версии для x86 замените _WRITE_BITS_N на это


Собственно говоря, актуален последний if.

а как в JPEG/JFIF записать 4:2:2? вроде бы все примеры, которые я встречал, используют 4:2:0

Стандарт JFIF фиксирует кол-во цветов (1 или 3) и их представление (Ci = YCbCr). Формат MCU, кол-во scan'ов и interleaving зависит от Вас. Цвет можно сделать любой: 4:2:0, 4:2:2 или 4:4:4.

собственно интересно [можно ли] в неиннтерлейсном режиме 3 цвета, что писать в SOF и как MCU (если не ошибаюсь - прямоугольник 8х16) кодируется

Можно, читайте стандарт.

Слабак шютка


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

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

В теме проскакивали тесты на скорость - ваш исходник скомпилированный влоб на VDSP5 под BF жмёт ч/б 640х480 за 42 миллиона тактов, что неплохо.

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



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

В прошлые выходные реализовал JPEG . Честно признаюсь, не написал ни строчки кода Хотя и разобрался как работает, всё увёл из http://mxhaard.free.fr/spca50x/Download/sp...20060127.tar.gz . Это драйвера для вебкамер под линукс. НО в папке encode есть кодировщик и в папке decode раскодировщик.

Эсть готовые функции
encode_image и decode_image

В этом архиве нет папок "encode" и "decode". И нет функций "encode_image" и "decode_image".
Может Вы ошиблись ссылкой?

Сорри... в аттаче

Спасибо.

Добрый вечер, у меня вопрос по кодеку JpegCoderARM, я его перед тем как переносить на МК, попробовал в Windows, что то не выходит картинка, на вход давал картинку 320*240 grayscale, в том числе пробовал и фотку из архива, в чем может быть причина, картинка получается, по размеру файл сжатый, но ооочень неправильная, непонятно что изображено, может как то алгоритм по другому под виндой работает? Просто боюсь все переносить на МК, ощущение непонимания возникает! )

Выложу свои летние опыты -- в MS-Студию-08 всё заехало успешно, картинка с пацаном размноженным конвертится нормально.