JPEG кодек на ARM, есть ли исходники или открытые проекты Опции

[Vitaliy_ARM]

Хочу прицепить видеокамеру к LPC2468. Нашел кое что с цифровым выходом но без встроенного кодека JPEG.

Поискал исходники в интеренете, так сразу ничего не нашел. Мож кто знает где поискать?

[mai]

В uc/GUI есть поддержка вывода jpeg на дисплей. Правда, сам я ее не пробовал использовать. Вот цитата из мануала

9.2.1 Supported JPEG compression methods
This software implements JPEG baseline, extended-sequential, and progressive compression
processes. Provision is made for supporting all variants of these processes,
although some uncommon parameter settings aren’t implemented yet. For legal reasons,
code for the arithmetic-coding variants of JPEG is not distributed. It appears
that the arithmetic coding option of the JPEG spec is covered by patents owned by
IBM, AT&T, and Mitsubishi. Hence arithmetic coding cannot legally be used without
obtaining one or more licenses. For this reason, support for arithmetic coding has not
been included to the free JPEG software. (Since arithmetic coding provides only a
marginal gain over the unpatented Huffman mode, it is unlikely that very many
implementations will support it.) So far as we are aware, there are no patent restrictions
on the remaining code.
The library does cot contain provision for supporting the hierarchical or lossless processes
defined in the standard.

Сообщение отредактировал mai - May 30 2008, 21:33

[aaarrr]

Поискал исходники в интеренете, так сразу ничего не нашел. Мож кто знает где поискать?

Лежит на самом видном месте.

[Rst7]

http://www.ijg.org/

Это, конечно, первоисточник. Но уж очень сия библиотека громоздка и требует менеджера кучи для работы. Я бы рекомедовал делать так - из этой библиотеки взять быстрый целочисленный DCT, из ftp://havefun.stanford.edu/pub/jpeg/JPEGv1.2.1.tar.Z - понимание остального (тут код, конечно, менее оптимальный, но зато - понятнее), и из этого слепить свой кодер. Кроме того, обязательно читать ITU T.81 - собственно стандарт.
Очень не рекомендую гнаться за универсальностью - в результате получится нечто, напоминающее jpegsrc.v6b. Надо для начала ограничиться монохромной картинкой, использовать основной метод sequential DCT-based, не делать динамического Хаффмана, а ограничиться заранее заданными табличками(см. T.81). Потом можно добавлять цвет и прочее.

[GetSmart]

Я бы рекомедовал делать так...

Поделились бы сразу своим творением. Авось кому пригодится. Мне например

[Rst7]

Поделились бы сразу своим творением.

На принципах GPL пойдет?

[Rst7]

Перенес свой AVR'овский кодер на ARM. Если верить симулятору в IAR'е, то 320*240ч/б жмет примерно за 4 миллиона тактов. Причем относительное время нахождения в процедурах примерно соответствует, что на AVR, что на ARM. Правда, надо подумать, как битстрим на ARM реализовать покрасивее, все-таки, в отличии от AVR есть сдвиги на произвольное количество бит.

[Sergei_Ilchenko]

Можно в Google поискать...

http://www.google.ru/search?aq=f&compl...1%D0%BA&lr=

Для RST7: имя у Вас от Zilog?

http://opencores.org/projects.cgi/web/jpeg/overview

Это для железки, но есть ссылки на документы.

[Rst7]

Ну, и кстати, к вопросу о качестве.

Вот исходное изображение:
 input.bmp ( 76.05 килобайт ) Кол-во скачиваний: 243


Вот результат упаковки:

Для RST7: имя у Вас от Zilog?

От i8080. Можно в гугле поискать

[blackfin]

...320*240 ч/б жмет примерно за 4 миллиона тактов.

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

[Rst7]

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

Ну не MIPS, а MIP тогда а то почти как "узлы в час" получается ))

И, кстати, видимо не 8, а 6. У нас данных по каждому цвету в 4 раза меньше, значит будет 4+1+1=6.

ЗЫ Тогда вообще даже MI

[blackfin]

Ну не MIPS, а MIP тогда а то почти как "узлы в час" получается ))

Нет сил возражать.. Вы правы, MI.

И, кстати, видимо не 8, а 6. У нас данных по каждому цвету в 4 раза меньше, значит будет 4+1+1=6.

Так я же уточнил, что цвет 4:2:2, а не 4:2:0, так что 4+2+2=8.
На BF'е, как я уже говорил, 5 MI.

[Rst7]

Поделились бы сразу своим творением. Авось кому пригодится. Мне например

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

 JPEGcoderARM.zip ( 85.48 килобайт ) Кол-во скачиваний: 652

[GetSmart]

Ну я просил чисто посмотреть. Мне пока и применить-то некуда. Я щас сам шлифую mpg123 для АРМа. Не менее интересная тема.

[etoja]

Классика жанра : исходники Стэнфордского университета. Хорошо комментированы и понятно написаны.

Прикрепленные файлы

 JPEGv1.2.1.tar.gz ( 169.27 килобайт ) Кол-во скачиваний: 470

 

[Rst7]

Так я же уточнил, что цвет 4:2:2, а не 4:2:0, так что 4+2+2=8.На BF'е, как я уже говорил, 5 MI.

Немного поплясал с бубном, вспомнив, что среди результатов квантизации почти 75% нулей (это для всех картинок, так сама идея кодера задумана), следовательно, можно неплохо выиграть, правильно написав условия (т.е. обеспечить кратчайшее время при 0). После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.

Кстати, бекпорт оптимизированного кодера привел к результату 8561325 на AVR (было около 12 миллионов).

И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно).

[blackfin]

После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.

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

[Rst7]

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

Спасибо. Кстати, получается, что разрыв с BF сократили до 30%. Я считаю - есть над чем подумать... (не нам с Вами, а тем, кто сейчас чешет репу с вопросом "какую бы каменюку мне в проект заложить";) )

[blackfin]

Я считаю - есть над чем подумать...

Подумать всегда есть над чем, но нужно не забывать, что конвейер в BF - 10 тактов, а рабочая частота ядра - 600 МГц.

[etoja]

Для быстрого сжатия можно использовать:
1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)
2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.

Прикрепленные файлы

 ljpg.zip ( 234.85 килобайт ) Кол-во скачиваний: 295

 

[blackfin]

Для быстрого сжатия можно использовать:
1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)
2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.

1) насколько мне известно, алгоритм JPEG-LS жмет в 3-4 раза, что, IMHO, недостаточно для многих приложений.
2) А что за кадры? Размер кадра? Цвет?
И сколько стоит реализация на FPGA? Есть оценки?

[Rst7]

1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)

Вы думаете, что DCT - это самое зло? Вы ошибаетесь. Обработка результатов DCT занимает столько же времени, что и само преобразование (хотя бы потому, что необходимо каждую гармонику (а их всего столько же, сколько пикселей) разделить на коэффициент) - причем, это с учетом всех оптимизаций (деление заменено на умножение на 1/q; если делимое меньше делителя, сразу исполняется быстрая обработка нулевого результата). А вот в LS надо над каждым пикселем поплясать немало.

Ну и часто необходим больший коэффициент сжатия.

[zltigo]

И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно).

Очень интересное число. Для общего развития не можете назвать получившееся при этом соотношение размеров кода?

[etoja]

Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.

[Rst7]

Для общего развития не можете назвать получившееся при этом соотношение размеров кода?

ARM: 2 232 bytes in segment CODE
AVR: 2 026 bytes in segment CODE
AVR32: 1 910 bytes in segment CODE32

ARM в арме. Тумбу даже пробовать не буду, регистров не хватит, будет дупа по производительности.

Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.

Вы читаете то, что я пишу? Если выбросить DCT, то времени займет только в 2 раза меньше

Конечно, если у Вас плохо дело с оптимизацией самого DCT - тогда да.

[blackfin]

Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.

Для BF по моим оценкам, затраты на DCT -15%, а на сжатие Huffman'ом и все остальное - 85%.
Где тут можно получить выигрыш в 4 раза?

Сообщение отредактировал blackfin - Jun 3 2008, 06:17

[Rst7]

По моим оценкам, затраты на DCT -25%, а на сжатие Huffman'ом - 75%.

Это на BF. Там DCT конечно лучше должно получиться, все-таки несколько MAC за такт.

А на AVR/ARM/AVR32 соотношение 50 на 50.

[etoja]

DCT и преобразование Уолша проверены на реальном продаваемом оборудовании
http://telekadr.by.ru

[zltigo]

ARM: 2 232 bytes in segment CODE
AVR: 2 026 bytes in segment CODE
AVR32: 1 910 bytes in segment CODE32

Совершенно привычные соотношения. Cпасибо.

ARM в арме. Тумбу даже пробовать не буду...

Это правильно

[Rst7]

Гм... Вообщем, нельзя доверять этим симуляторам в иаре... AVR'овский правильно такты считает, а ARM - слишком льстит - B за 1 такт вместо 3, ST за 1 такт вместо 2, LD за 2 такта вместо 3х.. AVR32 тоже далек от правды, причем в другую сторону... Ну для AVR32 я студию выйму, посмотрю, чего она насчитает, а вот для ARM'а... Чем бы таким посимулить поумнее?

DCT и преобразование Уолша проверены на реальном продаваемом оборудовании

Это говорит только о том, что Вы не в теме И оптимизацию, как сейчас модно говорить, ниасилили.

Очень интересное число.

Щас будем пересматривать...

[aaarrr]

Чем бы таким посимулить поумнее?

Эксперимент с RVDS 2.2 дал такие цифры:

Код

CODE      2456
CLOCKS    5215498

[etoja]

Для Rst7: не симулируй.

[blackfin]

DCT и преобразование Уолша проверены на реальном продаваемом оборудовании

Тогда, если не секрет, сообщите, плиз, реальные характеристики оборудования, т.е: количество кадров/сек., размер кадров, формат цвета.
И, заодно, какой там используется процессор, если, конечно, речь не идет о сжатии на FPGA.

[Rst7]

Эксперимент с RVDS 2.2 дал такие цифры:

Код

CODE      2456
CLOCKS    5215498

Выкладываю последнюю ревизию. Попробуйте посимулить ее, и дайте листинг, чего он там накомпилил.
 JPEGcoderARM.zip ( 85.57 килобайт ) Кол-во скачиваний: 665

Для Rst7: не симулируй.

Ну нету у меня под рукой ARM7 живого, а на ARM9 (да еще и под многозадачкой) - чистота экперимента будет нарушена.

[aaarrr]

Выкладываю последнюю ревизию. Попробуйте посимулить ее, и дайте листинг, чего он там накомпилил.

Код

CODE      2452
CLOCKS    4379723

 dump.txt ( 44.17 килобайт ) Кол-во скачиваний: 536

[Rst7]

 dump.txt ( 44.17кб )

А вменяемый листинг можно положить? С сишным исходником в каментах? И кстати, рекомендую выключить инлайн функций, может нехватать регистров.

[AKimbo]

Прогонял исходники jpeg-6b на симуляторе в ИАРе V4, ARM7.
Вот что получилось по соотношению %времени/процессы.
Сжатие кадра 720*576, размер выходного 28Кб, коэф сжатия 25, цвет 4:2:2.

1) Использовался "быстрый" DCT

30 rgb_ycc_convert
40 forward_DCT
19 jpeg_fdct_ifast
16 encode_mcu_huff

2) Использовался "точный" DCT

24 rgb_ycc_convert
43 forward_DCT
26 jpeg_fdct_islow
15 encode_mcu_huff

Фц. jpeg_fdct_??? непосредственно вычисляет коэффициенты, является частью forward_DCT. Заметно что вклад "вычисления коэффициентов" и "разборки результатов" примерно равен. Различия в выходных картинка не замечаю, хотя материал немного не тот. В прикреплении пожатые картинки.
 jpeg6b_out_25.rar ( 54.51 килобайт ) Кол-во скачиваний: 282


Сообщение отредактировал AKimbo - Jun 3 2008, 07:52

[aaarrr]

А вменяемый листинг можно положить? С сишным исходником в каментах?

Вменяемый листинг получить нельзя.

И кстати, рекомендую выключить инлайн функций, может нехватать регистров.

Он и так выключен. Включение, кстати, картину немного улучшает:

Код

CODE      2208
CLOCKS    4290777

[etoja]

Коммерчески ценные исходники никто никогда никуда не выкладывает.

[Rst7]

Вменяемый листинг получить нельзя.

а objdump -S out.elf?

Ну и так, кстати, видно, что качество кода IAR'у уступает...

Коммерчески ценные исходники никто никогда никуда не выкладывает.

Ваши исходники никто не просит, у Вас просят общее описание - какое железо, количество FPS, во сколько раз пакует...

[aaarrr]

а objdump -S out.elf?

Не совсем так, но:  jprocess.txt ( 69.73 килобайт ) Кол-во скачиваний: 373

Ну и так, кстати, видно, что качество кода IAR'у уступает...

Очень сильно в этом сомневаюсь. Впрочем, IAR'а у меня нет, сравнить не получится.

[Rst7]

Не совсем так

Во, почти получилось. Выключите, плиз, инлайн нафиг, и будет хороший листинг.

[aaarrr]

Во, почти получилось. Выключите, плиз, инлайн нафиг, и будет хороший листинг.

Так и быть
 jprocess.txt ( 76.58 килобайт ) Кол-во скачиваний: 559

[blackfin]

После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.

Включение, кстати, картину немного улучшает: CLOCKS 4290777

Так чему в итоге верить?

[Rst7]

Так чему в итоге верить?

Видимо не мне. Потому как выше отписал, как IAR'овский симулятор льстит по тактам

Надо бы в реальном железе проверить. Кто возьмется?

[aaarrr]

Сейчас попробую сделать доброе дело...

[Vitaliy_ARM]

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

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

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

[aaarrr]

Готово. SAM7, все из RAM, картинка во флеш:

Код

FWS=0    4361472
FWS=1    4438400

Все вполне соответствует симулятору.

[Rst7]

Очень сильно в этом сомневаюсь.

Да, вроде ничего, сейчас внимательнее рассмотрел. Есть спорное место о замене загрузки непосредственного операнда и умножения на 3 сложения. Дело в том, что операнд <256, следовательно, умножение выполняется 2 такта + 1 такт MOV, значит, по тактам - одинаково, но зато лишнее слово. А это - потенциальная потеря скорости (например, из-за MAM на LPC, или промаха мимо кеша).

А в остальном вроде особых граблей нет, правда местами он лишнего из цикла повыносил с потерей общего быстродействия (это я специально при помощи goto обманывал).

[aaarrr]

Все вполне соответствует симулятору.

70000 лишних тактов откуда-то набежало только.

[Rst7]

Готово.

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

70000 лишних тактов откуда-то набежало только.

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

[Vitaliy_ARM]

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

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

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

Прикрепленные файлы

 LZ0P39HA_SPECIFICATIONS_20071108.part1.rar ( 1.39 мегабайт ) Кол-во скачиваний: 161
 LZ0P39HA_SPECIFICATIONS_20071108.part2.rar ( 340.4 килобайт ) Кол-во скачиваний: 151

 

[Rst7]

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

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

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

[Vitaliy_ARM]

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

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

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

[dENIM]

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

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

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

Очинь апасна

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

[Vitaliy_ARM]

Очинь апасна

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

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

[_4afc_]

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

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

[Vitaliy_ARM]

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

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

[_4afc_]

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

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

[etoja]

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

[Vitaliy_ARM]

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

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

[singlskv]

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

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

[_4afc_]

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

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

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

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

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

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

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

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

Сообщение отредактировал _4afc_ - Jun 10 2008, 07:17

[Vitaliy_ARM]

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

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

[_4afc_]

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

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

Эскизы прикрепленных изображений

 

[Rst7]

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

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

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

[Rst7]

Что-то у меня с 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]

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

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

[blackfin]

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

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

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

[blackfin]

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

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

[Rst7]

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

Слабак шютка

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

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

[_4afc_]

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

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

Код

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

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

[Rst7]

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

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

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

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

[SimpleSoft]

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

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

[VAI]

НО в папке encode есть кодировщик и в папке decode раскодировщик.
Эсть готовые функции encode_image и decode_image

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

[SimpleSoft]

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

Прикрепленные файлы

 gspcagui.rar ( 327.31 килобайт ) Кол-во скачиваний: 371

 

[VAI]

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

Спасибо.

[BaRaGoZ]

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

Сообщение отредактировал BaRaGoZ - Dec 20 2014, 21:56

[WitFed]

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

Прикрепленные файлы

 jpgcoder.zip ( 274.25 килобайт ) Кол-во скачиваний: 73