Хочу прицепить видеокамеру к LPC2468. Нашел кое что с цифровым выходом но без встроенного кодека JPEG.
Поискал исходники в интеренете, так сразу ничего не нашел. Мож кто знает где поискать?
Полная версия этой страницы: JPEG кодек на ARM
В 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.
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.
Цитата(Vitaliy_ARM @ May 29 2008, 17:43) 
Поискал исходники в интеренете, так сразу ничего не нашел. Мож кто знает где поискать?
Лежит на самом видном месте.
Цитата
Это, конечно, первоисточник. Но уж очень сия библиотека громоздка и требует менеджера кучи для работы. Я бы рекомедовал делать так - из этой библиотеки взять быстрый целочисленный DCT, из ftp://havefun.stanford.edu/pub/jpeg/JPEGv1.2.1.tar.Z - понимание остального (тут код, конечно, менее оптимальный, но зато - понятнее), и из этого слепить свой кодер. Кроме того, обязательно читать ITU T.81 - собственно стандарт.
Очень не рекомендую гнаться за универсальностью - в результате получится нечто, напоминающее jpegsrc.v6b. Надо для начала ограничиться монохромной картинкой, использовать основной метод sequential DCT-based, не делать динамического Хаффмана, а ограничиться заранее заданными табличками(см. T.81). Потом можно добавлять цвет и прочее.
Цитата(Rst7)
Я бы рекомедовал делать так...
Поделились бы сразу своим творением. Авось кому пригодится. Мне например 
Цитата
Поделились бы сразу своим творением.
На принципах GPL пойдет?
Перенес свой AVR'овский кодер на ARM. Если верить симулятору в IAR'е, то 320*240ч/б жмет примерно за 4 миллиона тактов. Причем относительное время нахождения в процедурах примерно соответствует, что на AVR, что на ARM. Правда, надо подумать, как битстрим на ARM реализовать покрасивее, все-таки, в отличии от AVR есть сдвиги на произвольное количество бит.
Можно в Google поискать...
http://www.google.ru/search?aq=f&compl...1%D0%BA&lr=
Для RST7: имя у Вас от Zilog?
http://opencores.org/projects.cgi/web/jpeg/overview
Это для железки, но есть ссылки на документы.
http://www.google.ru/search?aq=f&compl...1%D0%BA&lr=
Для RST7: имя у Вас от Zilog?
http://opencores.org/projects.cgi/web/jpeg/overview
Это для железки, но есть ссылки на документы.
Ну, и кстати, к вопросу о качестве.
Вот исходное изображение:
Нажмите для просмотра прикрепленного файла
Вот результат упаковки:
Нажмите для просмотра прикрепленного файла
От i8080. Можно в гугле поискать
Вот исходное изображение:
Нажмите для просмотра прикрепленного файла
Вот результат упаковки:
Нажмите для просмотра прикрепленного файла
Цитата(Sergei_Ilchenko @ Jun 1 2008, 18:15)
Для RST7: имя у Вас от Zilog?
От i8080. Можно в гугле поискать
Цитата(Rst7 @ Jun 1 2008, 19:00)
...320*240 ч/б жмет примерно за 4 миллиона тактов.
Т.е. цветное 4:2:2 будет сжимать примерно за 8 MIPS'ов.BF, все же, быстрее..
Цитата
Т.е. цветное 4:2:2 будет сжимать примерно за 8 MIPS'ов.
Ну не MIPS, а MIP тогда
а то почти как "узлы в час" получается ))И, кстати, видимо не 8, а 6. У нас данных по каждому цвету в 4 раза меньше, значит будет 4+1+1=6.
ЗЫ Тогда вообще даже MI
Цитата(Rst7 @ Jun 1 2008, 19:49)
Ну не MIPS, а MIP тогда а то почти как "узлы в час" получается ))
Нет сил возражать.. а то почти как "узлы в час" получается )) Вы правы, MI.Цитата(Rst7 @ Jun 1 2008, 19:49)
И, кстати, видимо не 8, а 6. У нас данных по каждому цвету в 4 раза меньше, значит будет 4+1+1=6.
Так я же уточнил, что цвет 4:2:2, а не 4:2:0, так что 4+2+2=8.На BF'е, как я уже говорил, 5 MI.
Цитата(GetSmart @ May 31 2008, 14:43)
Поделились бы сразу своим творением. Авось кому пригодится. Мне например
Вот повставлял в исходники необходимые упоминания про GPL и выкладываю... Теперь посмотрим, какие новые поделки с камерами за бабло появятся
Нажмите для просмотра прикрепленного файла
Ну я просил чисто посмотреть. Мне пока и применить-то некуда. Я щас сам шлифую mpg123 для АРМа. Не менее интересная тема.
Классика жанра : исходники Стэнфордского университета. Хорошо комментированы и понятно написаны.
Цитата
Так я же уточнил, что цвет 4:2:2, а не 4:2:0, так что 4+2+2=8.На BF'е, как я уже говорил, 5 MI.
Немного поплясал с бубном, вспомнив, что среди результатов квантизации почти 75% нулей (это для всех картинок, так сама идея кодера задумана), следовательно, можно неплохо выиграть, правильно написав условия (т.е. обеспечить кратчайшее время при 0). После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.
Кстати, бекпорт оптимизированного кодера привел к результату 8561325 на AVR (было около 12 миллионов).
И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно).
Цитата(Rst7 @ Jun 2 2008, 21:01)
После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.
Вот видите, можете поблагодарить меня за предоставленный стимул.. 
Цитата
Вот видите, можете поблагодарить меня за предоставленный стимул..
Спасибо. Кстати, получается, что разрыв с BF сократили до 30%. Я считаю - есть над чем подумать... (не нам с Вами, а тем, кто сейчас чешет репу с вопросом "какую бы каменюку мне в проект заложить";) )
Цитата(Rst7 @ Jun 2 2008, 21:59)
Я считаю - есть над чем подумать...
Подумать всегда есть над чем, но нужно не забывать, что конвейер в BF - 10 тактов, а рабочая частота ядра - 600 МГц.
Для быстрого сжатия можно использовать:
1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)
2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.
1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)
2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.
Цитата(etoja @ Jun 3 2008, 08:10)
Для быстрого сжатия можно использовать:
1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)
2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.
1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)
2) аппаратное сжатие. У Xilinx есть свободно распространяемый пример сжатия со скоростью 24 кадра в секунду.
1) насколько мне известно, алгоритм JPEG-LS жмет в 3-4 раза, что, IMHO, недостаточно для многих приложений.
2) А что за кадры? Размер кадра? Цвет?
И сколько стоит реализация на FPGA? Есть оценки?
Цитата
1) алгоритм JPEG-LS, в котором нет дискретного косинусного преобразования (смотри приложение)
Вы думаете, что DCT - это самое зло? Вы ошибаетесь. Обработка результатов DCT занимает столько же времени, что и само преобразование (хотя бы потому, что необходимо каждую гармонику (а их всего столько же, сколько пикселей) разделить на коэффициент) - причем, это с учетом всех оптимизаций (деление заменено на умножение на 1/q; если делимое меньше делителя, сразу исполняется быстрая обработка нулевого результата). А вот в LS надо над каждым пикселем поплясать немало.
Ну и часто необходим больший коэффициент сжатия.
Цитата(Rst7 @ Jun 2 2008, 19:01)
И вот еще что - отношение количества тактов на AVR к ARM можно рассматривать как ориентировочную цифру увеличения производительности чисто за счет разрядности - 2.6 раза (при одинаковых тактовых, конечно).
Очень интересное число. Для общего развития не можете назвать получившееся при этом соотношение размеров кода?
Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.
Цитата
Для общего развития не можете назвать получившееся при этом соотношение размеров кода?
ARM: 2 232 bytes in segment CODE
AVR: 2 026 bytes in segment CODE
AVR32: 1 910 bytes in segment CODE32
ARM в арме. Тумбу даже пробовать не буду, регистров не хватит, будет дупа по производительности.
Цитата(etoja @ Jun 3 2008, 09:00)
Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.
Вы читаете то, что я пишу? Если выбросить DCT, то времени займет только в 2 раза меньше
Конечно, если у Вас плохо дело с оптимизацией самого DCT - тогда да.
Цитата(etoja @ Jun 3 2008, 10:00)
Если вместо DCT применить преобразование Уолша (Walsh transform), то кадровая скорость сжатия возрастёт в 4 раза. Правда это будет нестандартный JPEG.
Для BF по моим оценкам, затраты на DCT -15%, а на сжатие Huffman'ом и все остальное - 85%.Где тут можно получить выигрыш в 4 раза?
Цитата
По моим оценкам, затраты на DCT -25%, а на сжатие Huffman'ом - 75%.
Это на BF. Там DCT конечно лучше должно получиться, все-таки несколько MAC за такт.
А на AVR/ARM/AVR32 соотношение 50 на 50.
DCT и преобразование Уолша проверены на реальном продаваемом оборудовании
http://telekadr.by.ru
http://telekadr.by.ru
Цитата(Rst7 @ Jun 3 2008, 08:04)
ARM: 2 232 bytes in segment CODE
AVR: 2 026 bytes in segment CODE
AVR32: 1 910 bytes in segment CODE32
AVR: 2 026 bytes in segment CODE
AVR32: 1 910 bytes in segment CODE32
Совершенно привычные соотношения. Cпасибо.
Цитата
ARM в арме. Тумбу даже пробовать не буду...
Это правильно
Гм... Вообщем, нельзя доверять этим симуляторам в иаре... AVR'овский правильно такты считает, а ARM - слишком льстит - B за 1 такт вместо 3, ST за 1 такт вместо 2, LD за 2 такта вместо 3х.. AVR32 тоже далек от правды, причем в другую сторону... Ну для AVR32 я студию выйму, посмотрю, чего она насчитает, а вот для ARM'а... Чем бы таким посимулить поумнее?
Это говорит только о том, что Вы не в теме И оптимизацию, как сейчас модно говорить, ниасилили.
Щас будем пересматривать...
Цитата
DCT и преобразование Уолша проверены на реальном продаваемом оборудовании
Это говорит только о том, что Вы не в теме
И оптимизацию, как сейчас модно говорить, ниасилили.Цитата
Очень интересное число.
Щас будем пересматривать...
Цитата(Rst7 @ Jun 3 2008, 10:41)
Чем бы таким посимулить поумнее?
Эксперимент с RVDS 2.2 дал такие цифры:
Код
CODE 2456
CLOCKS 5215498
CLOCKS 5215498
Для Rst7: не симулируй.
Цитата(etoja @ Jun 3 2008, 10:30)
DCT и преобразование Уолша проверены на реальном продаваемом оборудовании
Тогда, если не секрет, сообщите, плиз, реальные характеристики оборудования, т.е: количество кадров/сек., размер кадров, формат цвета. И, заодно, какой там используется процессор, если, конечно, речь не идет о сжатии на FPGA.
Цитата(aaarrr @ Jun 3 2008, 09:56)
Эксперимент с RVDS 2.2 дал такие цифры:
Код
CODE 2456
CLOCKS 5215498
CLOCKS 5215498
Выкладываю последнюю ревизию. Попробуйте посимулить ее, и дайте листинг, чего он там накомпилил.
Нажмите для просмотра прикрепленного файла
Цитата(etoja @ Jun 3 2008, 10:01)
Для Rst7: не симулируй.
Ну нету у меня под рукой ARM7 живого, а на ARM9 (да еще и под многозадачкой) - чистота экперимента будет нарушена.
Цитата(Rst7 @ Jun 3 2008, 11:14)
Выкладываю последнюю ревизию. Попробуйте посимулить ее, и дайте листинг, чего он там накомпилил.
Код
CODE 2452
CLOCKS 4379723
CLOCKS 4379723
Нажмите для просмотра прикрепленного файла
Цитата
dump.txt ( 44.17кб )
А вменяемый листинг можно положить? С сишным исходником в каментах? И кстати, рекомендую выключить инлайн функций, может нехватать регистров.
Прогонял исходники 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. Заметно что вклад "вычисления коэффициентов" и "разборки результатов" примерно равен. Различия в выходных картинка не замечаю, хотя материал немного не тот. В прикреплении пожатые картинки.
Нажмите для просмотра прикрепленного файла
Вот что получилось по соотношению %времени/процессы.
Сжатие кадра 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. Заметно что вклад "вычисления коэффициентов" и "разборки результатов" примерно равен. Различия в выходных картинка не замечаю, хотя материал немного не тот. В прикреплении пожатые картинки.
Нажмите для просмотра прикрепленного файла
Цитата(Rst7 @ Jun 3 2008, 11:42)
А вменяемый листинг можно положить? С сишным исходником в каментах?
Вменяемый листинг получить нельзя.
Цитата(Rst7 @ Jun 3 2008, 11:42)
И кстати, рекомендую выключить инлайн функций, может нехватать регистров.
Он и так выключен. Включение, кстати, картину немного улучшает:
Код
CODE 2208
CLOCKS 4290777
CLOCKS 4290777
Коммерчески ценные исходники никто никогда никуда не выкладывает.
Цитата
Вменяемый листинг получить нельзя.
а objdump -S out.elf?
Ну и так, кстати, видно, что качество кода IAR'у уступает...
Цитата
Коммерчески ценные исходники никто никогда никуда не выкладывает.
Ваши исходники никто не просит, у Вас просят общее описание - какое железо, количество FPS, во сколько раз пакует...
Цитата(Rst7 @ Jun 3 2008, 12:25)
а objdump -S out.elf?
Не совсем так, но: Нажмите для просмотра прикрепленного файла
Цитата(Rst7 @ Jun 3 2008, 12:25)
Ну и так, кстати, видно, что качество кода IAR'у уступает...
Очень сильно в этом сомневаюсь. Впрочем, IAR'а у меня нет, сравнить не получится.
Цитата
Не совсем так
Во, почти получилось. Выключите, плиз, инлайн нафиг, и будет хороший листинг.
Цитата(Rst7 @ Jun 3 2008, 12:47)
Во, почти получилось. Выключите, плиз, инлайн нафиг, и будет хороший листинг.
Так и быть
Нажмите для просмотра прикрепленного файла
Цитата(Rst7 @ Jun 2 2008, 21:01)
После этого на моей тестовой картинке 3235931 такта. Больше видимо уже не удасться выжать.
Цитата(aaarrr @ Jun 3 2008, 12:06)
Включение, кстати, картину немного улучшает: CLOCKS 4290777
Так чему в итоге верить? 
Цитата
Так чему в итоге верить?
Видимо не мне. Потому как выше отписал, как IAR'овский симулятор льстит по тактам
Надо бы в реальном железе проверить. Кто возьмется?
Сейчас попробую сделать доброе дело...
События развиваются так быстро, что не успеваю переваривать.
Может тогда осветить вопрос наиболее подходящих камер для подобных проектов?
Выкладываю даташит на одну из них.
Может тогда осветить вопрос наиболее подходящих камер для подобных проектов?
Выкладываю даташит на одну из них.
Готово. SAM7, все из RAM, картинка во флеш:
Все вполне соответствует симулятору.
Код
FWS=0 4361472
FWS=1 4438400
FWS=1 4438400
Все вполне соответствует симулятору.
Цитата
Очень сильно в этом сомневаюсь.
Да, вроде ничего, сейчас внимательнее рассмотрел. Есть спорное место о замене загрузки непосредственного операнда и умножения на 3 сложения. Дело в том, что операнд <256, следовательно, умножение выполняется 2 такта + 1 такт MOV, значит, по тактам - одинаково, но зато лишнее слово. А это - потенциальная потеря скорости (например, из-за MAM на LPC, или промаха мимо кеша).
А в остальном вроде особых граблей нет, правда местами он лишнего из цикла повыносил с потерей общего быстродействия (это я специально при помощи goto обманывал).
Цитата(aaarrr @ Jun 3 2008, 13:47)
Все вполне соответствует симулятору.
70000 лишних тактов откуда-то набежало только.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.