[Vitaliy_ARM 0]

Может брал кто уже под NDA? Поделитесь пожалуйста.

А то лежат LZ0P39HA, не знаю как подступиться...

 

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

[singlskv 0]

Может брал кто уже под NDA? Поделитесь пожалуйста.

А то лежат LZ0P39HA, не знаю как подступиться...

А вот это не подходит ?

http://hw.cz/files/redaktor130/LZ0P39HA_SP...NS_20071108.pdf

[_4afc_ 25]

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

 

Вам она больше подойдёт несомненно, поскольку жмёт в JPEG сама.

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

Причём доступ к многим регистрам в MT9D131 через узенькую дырочку.

 

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

 

 

А вот это не подходит ?

http://hw.cz/files/redaktor130/LZ0P39HA_SP...NS_20071108.pdf

 

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

 

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

 

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

 

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

Изменено 10 июня, 2008 пользователем _4afc_

[Vitaliy_ARM 0]

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

 

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

[_4afc_ 25]

Вот повставлял в исходники необходимые упоминания про GPL и выкладываю... Теперь посмотрим, какие новые поделки с камерами за бабло появятся

 

Что-то у меня с JPEG никак отношения не ладятся.

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

Округления? Инты, шорты, чары? Структуры?

Исходная картинка - таже.

[Rst7 5]

что не так, визуально?

 

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

 

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

[Rst7 5]

Что-то у меня с JPEG никак отношения не ладятся.

 

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

#define _WRITE_BITS_N(LEN,SYM) \
  { \
    if ((REG)(__bs_bit-=LEN)>0) \
    { \
      __bs_buf|=SYM<<__bs_bit; \
    } \
    else \
    { \
      UREG c; \
      __bs_buf|=SYM>>(__bs_bit=0-__bs_bit); \
      c=__bs_buf>>24; \
      if ((*__bs_bytep++=c)==0xFF) *__bs_bytep++=0; \
      c=__bs_buf>>16; \
      if ((*__bs_bytep++=c)==0xFF) *__bs_bytep++=0; \
      c=__bs_buf>>8; \
      if ((*__bs_bytep++=c)==0xFF) *__bs_bytep++=0; \
      c=__bs_buf>>0; \
      if ((*__bs_bytep++=c)==0xFF) *__bs_bytep++=0; \
      if (__bs_bit) __bs_buf=SYM<<(__bs_bit=32-__bs_bit); else {__bs_buf=0; __bs_bit=32;}\
    } \
  } \

 

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

[yes 6]

Т.е. цветное 4:2:2 будет сжимать примерно за 8 MIPS'ов.

BF, все же, быстрее.. ;)

 

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

[blackfin 23]

а как в 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.

[yes 6]

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

 

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

[blackfin 23]

собственно интересно [можно ли]

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

[Rst7 5]

Самостоятельно - нет. Дал ковырятся местному программисту, но он увяз.

Слабак :) шютка

 

Ваш вариант работает. У вашего кодера чуть больше артефактов, чем у Cristi Cuturicu - вероятно из-за целочисленных вычислений, правда у Cristi Cuturicu файл больше.

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

[_4afc_ 25]

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

Я сначала подумал, что чем больше коэф. - тем хуже качество :)

Кстати, замена усечения на округление - улучшает резкость.

#define MUL_U16(a,b) ( (unsigned int)( ( ((UINT32)(a)*(b))+0x8000 )>>16 ) )

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

[Rst7 5]

Кстати, замена усечения на округление - улучшает резкость.

 

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

 

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

 

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

[SimpleSoft 0]

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

 

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

encode_image и decode_image